IoT Device Application Requirements

IoT Device Application Requirements

DAR1 In the case of an IoT Device Application which needs to send data very frequently the IoT Device Application should use an “always-on” connectivity mechanism instead of activating and deactivating network connections (a ‘network connection’ being the establishment of a radio connection between the Communications Module and the network) very frequently.
DAR2 The IoT Device Application should minimize the number of network connections between the IoT Device and the network.Data should be aggregated by the IoT Device Application into as big a chunk as possible before being compressed and sent over the communications network.If the IoT Device Application provides several IoT Services using the same Communications Module, the IoT Device Application should coordinate each of the IoT Services network communication to make efficient use of the network.
DAR3 If permissible for the IoT Service, the IoT Device Application should avoid synchronized behaviour with other IoT Devices and employ a randomized pattern for network connection requests.
DAR4 The IoT Device Application should be implemented securely. For example by following industry guidelines such as those provided by:

DAR5 The IoT Device Application should implement appropriate security measures to prevent unauthorized or insecure device management functionality (e.g. diagnostics, firmware updates) of the IoT Device software and firmware. Such security measures shall apply to all local and remote (over the air) device management functionality.
DAR6 If the IoT Service requires the use of ‘keep alive’ messages, the IoT Device Application should automatically detect the Mobile Network Operator’s TCP_IDLE value (NAT timers) when using push services.This can be achieved by increasing the IoT Device Application’s polling interval until a network timeout occurs and then operating just below the timeout value.The IoT Device Application should adapt to the new value as opposed to using a hard coding a polling interval set within the device.
DAR7 If the IoT Service requires the use of ‘keep alive’ messages, use of dynamic polling interval (ref. DAR6) is preferred. However, if a fixed polling interval is used, the IoT Device Application should use a time value specified by the Mobile Network Operator. If the preferred value of the Mobile Network Operator is unknown a default value of 29 minutes is recommended as the polling interval.If a fixed polling interval is used, the IoT Device Application should allow remote and/or local configuration of the interval.Note: The default value of 29 minutes is recommended because the routers used by many Mobile Network Operators’ will clear the Network Address Translation (NAT) entry for the IoT Device’s data session 30 minutes after the last communication is sent to/from the IoT Device.
DAR8 The IoT Device Application should be designed to cope with variances in mobile network data speed and latency considering the variety in performance of mobile communications technologies such as 2G, 3G and LTE.
DAR9 The IoT Device Application should be capable of adapting to changes in mobile network type and data speed at any given time.
DAR10 If data speed and latency is critical to the IoT Service the IoT Device Application should constantly monitor mobile network speed and connection quality in order to request the appropriate quality of content from the IoT Service Platform.
DAR11 The IoT Device Application should always be prepared to handle situations when communication requests fail.Communication retry mechanisms implemented within a IoT Device Application can vary and will depend on the importance and volume of downloaded data. Possible solutions can be: Simple counting of failed attempts since the data connection was first established (often the easiest solution). Monitoring the number of failed attempts within a certain period of time. For example, if the data connection is lost more than five times within an hour, then the request can be suspended. This can be a more reliable technique to avoid short but regular connection problems, such as when a device is moving away from one network cell to another. The data connection can be lost when the device switches between cells, but when the cell is providing good coverage; the request can be processed successfully.

 

Depending upon the IoT Service, no communication request by the IoT Device Application should ever be retried indefinitely – the request should eventually timeout and be abandoned.

Note: The requirements contained within section 5.2 of this document describe the functionality that, when implemented within the Communications Module to monitor IoT Device Application behaviour, ensures the retry mechanisms implemented within the IoT Device Application do not damage the mobile network.

DAR12 The IoT Device Application should monitor the number of network connections it attempts over a set period of time. If the number of connection attempts exceeds a maximum value the IoT Device Application should stop requesting network connectivity until the time period has expired.The maximum value shall be set by the IoT Service Provider.In the case the IoT Device exceeds the maximum value a report should be sent to the IoT Service Platform.
DAR13 The IoT Device Application should monitor the volume of data it sends and receives over a set period of time. If the volume of data exceeds a maximum value the IoT Device Application should stop sending and receiving data until the time period has expired.The maximum value shall be set by the IoT Service Provider.In the case the IoT Device exceeds the maximum value a report should be sent to the IoT Service Platform.
DAR14 The IoT Device Application should send a notification to the IoT Service Platform with relevant information when there is an unexpected power outage or unexpected battery power problem. This notification should follow the application scaling advice contained in Annex C.
DAR15 The IoT Device Application should use data transcoding and compression techniques, as per the intended QoS of the IoT Service, to reduce network connection attempts and data volumes.
DAR16 The IoT Device Application should be designed to ensure the application’s network communication activity is not concentrated during periods of high network utilisation (i.e. utilises “off-peak” hours as guided by the Mobile Network Operator).
DAR17 The IoT Device Application should minimise any geographical network loading problems and tolerate any geographical network loading problems that may still occur.
DAR18 Each time there is a need to send data over the mobile network the IoT Device Application should classify the priority of each communication. For example, the IoT Device Application should distinguish between data that requires instantaneous transmission and delay tolerant data that could be aggregated and/or sent during non-peak hours.
DAR19 The IoT Device Application should not frequently reset the Communications Modem.
DAR20 When an IoT Device Application does not need to perform regular data transmissions and it can tolerate some latency for its IoT Service, it should implement a ‘low power’ mode where the device and its Communication Module is effectively powered down between data transmissions. This will reduce the power consumption of the IoT Device and reduce network signalling.
DAR21 Data sent from the IoT Device Application and the IoT Service Platform should be end-to-end encrypted to a security strength appropriate to the IoT Service.
DAR22 The IoT Device Application should authenticate the IoT Service Platform prior to data communication. The strength of authentication used should be appropriate to the IoT Service.
DAR23 The IoT Service Platform should authenticate the IoT Device prior to data communication. The strength of authentication used should be appropriate to the IoT Service.
DAR24 The IoT Device Application should support a “reset to factory settings” via remote and local connection.
DAR25 The IoT Device Application should support “time resynchronisation” via remote and local connection.
DAR26 If the IoT Device supports more than one family of communications access technology (for example 3GPP, TD-SCDMA, Wireless LAN) the IoT Device Application should implement a protection mechanism to prevent frequent ‘Ping-Pong’ between these different families of communications access technologies.
DAR27 For mass deployments of IoT Devices (e.g. >10,000 devices within the same mobile network), if the IoT Device supports more than one family of communications access technology (for example 3GPP, TD-SCDMA, Wireless LAN) the IoT Device Application should employ a randomised delay before switching to a different family of access technology.