Definition
Sleep refers to IoT devices entering a low-power state to save energy, pausing or significantly reducing activities such as communication, computation, and sensor data collection. Sleep is a core capability in narrowband NB-IoT, LoRa, and other low-power scenarios, implemented through mechanisms like PSM (Power Saving Mode) and eDRX. During sleep, the device is unreachable, and push and polling must wait for the device to wake up; waking up can be triggered by a timer or an external event (such as a sensor trigger). Sleep conflicts with second-level reporting, as second-level scenarios typically do not use sleep; when combined with remote meter reading, meters can remain asleep most of the time and wake up for readings.
In cross-border scenarios, sleeping devices need to complete positioning and data reporting within the wake-up window; multi-country single SIM can ensure multi-country connectivity after waking up.
Technical Features and Architecture
The sleep technology architecture includes: PSM — deep sleep, only the timer runs, wake-up cycles configurable; eDRX — extended discontinuous reception, the device periodically listens for paging; Wake-up sources — timers, GPIO, sensors, SMS, etc.; Wake-up window — after waking up, the device can receive push and respond to polling. When combined with event-triggered reporting, events can trigger wake-up and reporting; when combined with remote upgrades, upgrades must be completed within the wake-up window. In cross-border scenarios, sleep cycles need to consider multiple time zones and roaming paging.
Dormancy conflicts with real-time responsiveness; high real-time scenarios (such as real-time location ) usually do not use dormancy or use short dormancy.
Application in IoT and cross-border scenarios
Dormancy is widely applied in: smart meters —water meters, gas meters, electricity meters for remote meter reading , staying dormant most of the time and waking up during meter reading; logistics tracking — logistics trackers sleep when stationary and wake up to report location when moving; sensors —low-power sensors wake up periodically to collect data; cross-border deployment —dormancy strategies for overseas meters and cross-border logistics devices. Both cross-border smart meters and cross-border logistics tracking can use dormancy to extend battery life, One Card Multi Country ensures cross-border connectivity after waking up.
SimtoLink provides stable connections for IoT devices in dormancy scenarios, covering 200+ countries and regions, supporting low-power scenarios such as cross-border remote meter reading and logistics tracking .
Whether a device in a power-saving state is still listening to the network
In cellular IoT, sleep is not power-off. The module turns off most of the radio and the application processing, and wakes only on the agreed schedule. Power-saving mode leaves the device registered but almost deaf to paging, until a timer expires and it contacts the network itself. Extended discontinuous reception still wakes periodically to listen for paging, only with a longer interval. Both cut standby current for battery meters and stationary trackers. The cost is that the network cannot wake the device during the sleep window. If "online" on the platform only means the last attach has not expired, it will not match "able to receive a command right now."
After wake-up there is a very short window in which the device can communicate. In that window it must confirm whether it is still on the same network, whether it must attach again, send the backlog, and then decide whether to sleep immediately. If the visited network has changed during a cross-border trip, registration can consume the whole window. The application message never goes out, and the device still treats the cycle as reported.
Conditions for fixing the sleep cycle in a cross-border deployment
A cycle holds only if three things are true together: the network accepts the timer the module requested, the application can tolerate being unreachable during that interval, and the data due at wake-up fits inside the window. The network may reject or rewrite the sleep length the device proposed. If the firmware still schedules meter reads on the original cycle after that rewrite, whole reporting points are missed. A device that must open a valve remotely, send an emergency location, or report state within seconds should not enter deep sleep. At most it should use a shorter paging cycle, so the platform can still deliver a command in an acceptable time.
In roaming, also check whether paging is reachable across the border. Sleep parameters accepted by the home network may not be applied the same way on the visited network. A logistics tag can sleep for hours in a warehouse. Once it reaches a port it should wake more often, or location samples go missing for the whole network-change interval. The sleep policy has to follow the stage of the route. One timer for the whole world will not do.
Reading a failed sleep cycle as a suspended SIM
The easiest misread is a device that sends nothing for several cycles and then recovers as soon as it is rebooted. That is often not a dead SIM. The sleep timer is longer than the inspection interval, or registration failed after wake-up and the firmware marked the round complete without retrying. Another mistake is to "wake" a device in deep power saving, which is not listening for paging, with an SMS or a downlink command. The command queues in the core until it times out, and operations treats that as a private-network outage. A third is to put sleep and a live track in the same firmware profile. The vehicle starts moving and still sleeps on the stationary cycle, so the track is thinned to a sparse polyline.
Tell these apart from the sleep reason in the module log and from the timer value the network returned, not from how long the platform has shown the device offline. If the network shortened or lengthened the value, report the value that actually took effect, so the configuration screen and the air interface do not tell different stories. For meter reading that must wake on a predictable schedule, align the wake window with the status report slot. Do not assume the server can push a command into a module that is asleep.