Just wanted to follow-up on Reuben’s comment with some more information after several of us discussed this thread.
Support for Cat-M1 features like eDRX and other power saving modes on inbound connections is a little bit of a multi-faceted problem at the moment, with a combination of simultaneous issues :
- Cat-M1 deployments are relatively new to several carriers, and still being rolled out for others
- network equipment vendors and gateways are catching up in deploying extended power saving support at the packet delivery level
- many networks do not currently implement the store-and-forward features proposed for M1 deployments
- specifications around latency and other timings diverge from those of 3G and higher-category LTE
We are finishing the full implementation of eDRX and necessary network changes to accommodate modified timings needed for modules to wake up from Cat-M1 power saving states and receive inbound socket connections. These enhancements for Cat-M1 provide a similar experience as store-and-forward support would have provided, allowing inbound connection requests to go through quickly and successfully even for modules that were in an idle state on the radio channel at the time. This does not affect device-originated outbound connections, or the ability to leverage power savings in general, which are implemented. The upcoming improvements specifically address the waking of modules with device-terminated inbound connections (e.g. SpaceBridge or packets sent via API) and the ability to ensure the opening of a socket connection succeeds quickly and successfully with better handling of edge cases.
We pushed a preview of the upcoming improvements this week to help improve the experience for those who have programmed modules to listen on a socket over Cat-M1 and who were experiencing connection timeouts, by adjusting timings and improving error messages to be more helpful while troubleshooting. This is one of several improvements that we’re pushing out for Cat-M1 inbound connections support as we accommodate trending and now-maturing Cat-M1 operator deployments, noting that we are pushing changes out in phases, like the first one this week, to afford ample testing across a variety of operators and regions. (Also note that these changes are, again, only related to connections originating over SpaceBridge or our API and terminate on sockets that devices are listening on, but do not affect device-initiate outbound connections.)