Mobile Terminated calls

[dboling]

While I know the 9160 does not support voice calls, I would like to know if the 9160 will accept mobile terminated (MT) data calls.  If so, how is that represented in the firmware or modem software?

The goal would be to 'wake up' a device to collect data without having the controller poll the cloud for a flag on when to do this.  Thanks.

Doug

[AndreasF]

Hi Doug.

Sorry for the late reply.

The M33 will be woken up by IPC when IP data is received, i.e. the application can sleep while modem domain handles polling with LTE network.

The device (modem) do not need to enter connected mode to know if there is incoming data from network/server side. It wakes up to monitor a so called paging channel on a certain (very short) moment to see if there is something coming for the device, otherwise also the modem will be sleeping. If the page for the device is there, the modem will set up a radio connection, receive data and forward it to the application domain. This is when the application domain would wake up from the sleep and could continue the application use-case using the same radio connection that was set up to fetch the data from the network.

Of course the application and server that are used for this must support this kind of "shoulder tap", e.g. if there is a session then sessions should not expire too quickly, maybe even so that they would only expire based on unanswered "shoulder tap".

eDRX cycles should be negotiated with the network based on latency requirements from the use-case because the device would not receive messages from the network while sleeping between eDRX paging cycles. Naturally the application could do the poll itself (connect + check + disconnect) at any time but that would not be power efficient.

eDRX cycle lengths go from 5,12 seconds to 2621,44 seconds in LTE-M and from 20,48s to 10485,76s in NB-IoT. It is not any value between those but there are some that can be used I have copied the numbers below. The application should select a cycle that is the best fit for the use-case and configure modem to use that (AT+CEDRXS). Please note that often the best fit comes from multiple cycles of one value and the results of eDRX negotiation should be checked, i.e. what the network decided. In our device this can be done by using AT%XMONITOR.

5,12 seconds          LTE-M
10,24 seconds        LTE-M
20,48 seconds        Both
40,96 seconds        Both
61,44 seconds        LTE-M
81,92 seconds        Both
102,4 seconds        LTE-M
122,88 seconds      LTE-M
143,36 seconds      LTE-M
163,84 seconds      Both
327,68 seconds      Both
655,36 seconds      Both
1310,72 seconds    Both
2621,44 seconds    Both
5242,88 seconds    NB-IoT
10485,76 seconds  NB-IoT

Modifying the value will always trigger a radio connection to re-negotiate it with the network so it would not be a good idea to try to combine different values for short term use-cases.

Best regards,

Andreas

[dboling]

Andreas,

Thanks for the detailed reply. I'll review and get back to you.

Doug