ThingSpace reachability service provides callback notifications when devices are online and offline. The service relies on a network service called MONTE from the SCEF element. Since this relies on the network for notifications, the device does not necessarily need to be instrumented with a “check-in” or “heartbeat” to monitor whether it is online or not, but rather the Reachability notifications will provide a change of state - i.e. Reachable or Not-reachable.
More recent 4G devices for IoOT applications such as Category M (aka CAT M or LTE M) and Narrowband IoT (NB- IoT) devices in the market are more power efficient for IoT applications. The reduction in consumption of battery power is enabled through the ability for such devices to periodically enter a deep sleep mode for extended durations in which it is not possible to reach out (e.g., from an application server) to the devices for packet data, or SMS communications. Note, however, that such devices can at any time initiate such communication from their end to the application server. This behavior is very useful for many IoT applications where an enterprise IoT application only needs to read data from a device periodically (e.g., once a month electricity meter readings from homes) while communication initiated by a device on an exception basis (e.g., a smoke alarm triggered by a detector in a home) is always possible. For any server-based application, it becomes evident that knowledge of when the device becomes reachable or unreachable for communications enables an application to be programmed more intelligently. For example, the enterprise application can issue a command to the device when it receives a notification indicating the device is reachable.
4G CAT M/NB IOT devices compliant with 3GPP LTE standards can conserve battery by limiting the power consumption of the device to a very small fraction of its normal power consumption when not doing any form of data transmission (SMS, IP Data or Non-IP Data Delivery). Effectively the device “sleeps” for a set duration when not actively exchanging data and wakes up periodically to listen for pages from the network (The network pages the device when there is data waiting to be sent to the device). If there is data waiting to be sent to the device, the device responds to the page and becomes active (awake) and receives (and sends) data. If there is no page from the network, the device goes back to sleep after staying active (but idle) for some minimum duration. On the other hand, if the device ever wishes to transmit data to the network at any time, it can wake itself up from sleep, become active and perform the data transfer, after which it goes back to sleep. The challenge for the enterprise application (effectively on the network side) is that it will not know when a specific device (and there could be millions of such IOT devices deployed) wakes up so it can be paged. The Device Reachability API solves this issue by providing real time notifications to the application when a devices wakes up or even when it disconnects due to going to sleep.
CAT M/NB IOT devices have two different sleep modes: PSM and eDRX. In each of these modes, the device cycles periodically through the sleep and wake up states, the duration of time device sleeps and stays awake is determined by device configurable settings. Currently, customers must work with the device manufacturers to select the sleep mode and set the sleep and stay awake durations when the device operates in PSM mode.
Besides power-conserving application, this reachability aids in monitoring devices that are, in principle, powered on all the time for fixed wireless activations.
For example:
If these devices are disconnected from the network either gracefully or unexpectedly, the reachability service will provide callback notifications for reachable and not-reachable state changes. This aids in remote management for these applications without having to instrument the device with a client for monitoring.
The Device Reachability API allows an enterprise application two ways of interacting with deep-sleep-capable devices:
Request – response mode: In this mode, the enterprise application can call the Reachability API with a single response (called a monitoring event). If the device is reachable for Data or SMS communications (or both), the API will provide an immediate response that the device is reachable. If the device is not reachable, the response is delayed until the device becomes reachable (i.e., it wakes up from deep sleep).
Continuous monitoring mode: In this mode, the enterprise application can arm a trigger via the API for continuously receiving reachability notifications for a specifiable time duration up to 10 years (such a trigger can be canceled at any time). The application will receive callback notifications whenever the device becomes reachable, either because it woke up from its deep-sleep periodic cycle or because it initiated some communications from its end.
The Device Reachability API also allows an application to be notified in similar modes when the device becomes Disconnected (i.e., unavailable to communicate) from the network for Data or SMS communications (or both).