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
Hi Doug.
Are you thinking of waking up the device when it's in standby mode? Can you take a look at this then? I'm guessing by "mobile terminated (MT) data calls" you mean SMS?
Is your device in PSM mode? Because as far as i know its not possible to wake up a device from PSM mode. The device has to be in RCC-IDLE. You can perhaps use a eDRX interval that has a fitting "low power periode", where the device will turn on the receiver to see if it should awake and do something.
Best regards,
Andreas
Hi Doug.
Are you thinking of waking up the device when it's in standby mode? Can you take a look at this then? I'm guessing by "mobile terminated (MT) data calls" you mean SMS?
Is your device in PSM mode? Because as far as i know its not possible to wake up a device from PSM mode. The device has to be in RCC-IDLE. You can perhaps use a eDRX interval that has a fitting "low power periode", where the device will turn on the receiver to see if it should awake and do something.
Best regards,
Andreas
No, not SMS. SMS is not reliable.
The goal is to have the radio in the lowest power state to receive an incoming connect request. The device would not have an active connection, eDRX would work (via the paging cycle) for an MT. I don't want the firmware having to set up a connection, connect to the cloud and then find out it doesn't have anything to do. That's expensive power-wise.
So, can I receive an MT while in eDRX mode? If so, how? If not, will this be supported in the future? Thanks.
Doug
Hi Doug.
I have to ask someone in the development team about this.
I will come back to you if that's ok :-)
Best regards,
Andreas
Hi again Doug.
I got a reply from the development team:
Unknown said:
This is normal data use-case and is naturally supported by our device.
With normal setup modem will monitor if there is incoming data for the device at every eDRX/DRX cycle so that part will be handled automatically on modem domain.
There just needs to be a client who is ready to receive data from modem when it arrives, otherwise modem will simply drop it. The application will be implemented so that it will likely first communicate with the server once it is taken into use, then it starts to listen a socket (could be same that was used for communication or a new one) -> server side will send the trigger message with whatever protocol on top of IP. This data will be routed to that socket that client is listening (normal routing from IP level, address, port, IP version).
SMS might actually be OK as well, it is not so unreliable as people think. One very good thing with SMS is that server side does not need to know much about wakeup periods of the device, i.e. when it will be awake to receive data next time. SMS center will take care of re-sending the message if device is not awake when it was send by the server. Maybe there could be issues with SMS if there are strict latency requirements after trigger is sent... but that is valid with IP data as well if device could be in long eDRX sleep when server sends the trigger message. Networks do buffer MT traffic a bit also in case of eDRX and PSM so exact knowledge of times when device is awake is not needed in IP data case either.
Hope you finds this helpful.
Best regards,
Andreas
My concern with this method is that the M33 must be active with a live connection to poll for events from the cloud. Having a very low power method of fielding events would be quite helpful for battery powered situations.
Perhaps the miscommunication here is that I lack visibility into the state of M33 while the system is in the eDRX mode. Perhaps the eDRX power is equivalent to a connected state (or frequent connect/disconnect cycles). However, if this isn't the case, the system is forced to poll (connect, check, disconnect) at the maximum allowable latency for event handling. I would expect this to use much more power than eDRX mode.
Doug
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
