IoT Device Application Requirements
Communication Module Requirements
Standards Compliance
MSC1 | The Communications Module shall be compliant with 3GPP specifications [1] unless otherwise stated within this document. |
MSC2 | The Communications Module shall be certified by the GCF and/or the PTCRB. |
MSC3 | The Communications Module shall investigate, and meet as required, the mobile network operator requirements for the target market(s). |
Network Efficiency Requirements
NER1 | The Communications Module shall support (dependent upon the target mobile network operator) at least one of the following requirements:1) Radio Policy Manager (as defined in section 8 ) implemented within the Radio Baseband Chipset;OR
2) Connection Efficiency requirements (as defined in section 7) implemented within the Communication Module Firmware; OR 3) 3GPP Connection Efficiency features (as defined in section 9) implemented within the Radio Baseband Chipset. Note: Option 3 requires the target mobile network operator to have implemented the required 3GPP optional features. |
NER3 | If the Communications Module supports more than one family of communications access technology (for example 3GPP, TD-SCDMA, Wireless LAN) the device should implement a protection mechanism to prevent frequent ‘Ping-Pong’ between these different families of communications access technologies. |
NER4 | When camping on a cell, the Communication Module shall support the mechanism to control the number of RRC Connection Establishment and temporal offset for cell selection as defined in 3GPP TS36.331 [3] |
IPv6 Requirements for Communication Modules that Support IPv6
The following requirements are only applicable to Communication Modules that support IPv6.
IPv6 is the only perennial solution to IPv4 address exhaustion (public and private).
- The final target is IPv6 only connectivity, once most of the Internet will be IPv6.
- Remaining IPv4 services will be reachable through NAT64.
- Before IPv6 only connectivity stage is reached, a dual stack will be used to push migration towards IPv6.
- During the dual stack period, IPv4 rationalization solutions will be used.
IP1 | The IoT Communications Module should not send unsolicited messages (Router Solicitation for example). |
IP2 | The IoT Communications Module should send only a AAAA DNS Query. |
IP3 | The IoT Communications Module management system should be IPv6 based. |
IP4 | The IoT Communications Module shall support the following IPv6 functionality:
|
IP5 | The IoT Communications Module should support the following IPv6 functionality:
|
Requirements for Communication Modules that Support LTE
The following requirements are only applicable to Communication Modules that support LTE.
CML1 | If voice calling over LTE is required by the IoT Service, the Communication Module should support VoLTE (Voice over LTE). |
Requirements for Communication Modules that Support Fast Dormancy
The following requirements are only applicable to Communication Modules that support Fast Dormancy.
CFD1 | The Fast Dormancy algorithm within the Communications Module should be triggered based on IoT Device data inactivity following suggested time parameters:
The Communications Module should ensure that background IP or IMS data flows would not be suspended by the Signalling Connection Release Indication (SCRI). Fast Dormancy best practices from GSMA TS.18 “Fast Dormancy Best Practices” [14] shall be followed. |
(U)SIM Interface Requirements
MSI1 | The Communications Module shall support (U)SIM OTA management. See 3GPP TS31.102 [4] |
MSI2 | The Communications Module should support remote provisioning as defined in GSMA SGP.01 “Remote Provisioning Architecture for Embedded UICC Technical Specification“ [5]. |
Security Requirements
MSR1 | The Communications Module shall implement a unique global IMEI and protect it against tampering. For details, please refer to 3GPP document TS 22.016 [6]. |
MSR2 | The Communications Module shall detect the removal of a powered UICC and terminate all network connections and services authenticated by the (U)SIM application on that UICC.Upon the removal of a powered UICC all temporary network authentication data related to the UICC should be deleted by the Communications Module. |
MSR3 | The Communications Module shall implement appropriate security measures to prevent unauthorized management (such as diagnostics, firmware updates etc) of the Communications Module. |
MSR4 | The Communications Module shall implement a SIM lock function which allows the IoT Device to be locked to a specific UICC or range of UICCs. The state of the lock shall be configurable. |
DM1 | The Communications Module should support a standards based over the air device management protocol such as OMA DM [8] or OMA LightweightM2M [15]. |
DM2 | The Communications Module should support a standards based firmware update mechanisms such as OMA FUMO [9]. |
DM3 | The Communications Module should support a “reset to factory settings” via remote and local connection. [Should also be a corresponding DAR requirement for the application] |
DM4 | The Communications Module should support “time resynchronisation” via remote and local connection. [Should also be a corresponding DAR requirement for the application] |
Subscription Identifier Requirements
Given the large potential number of IoT Devices, some national numbering and identification plans have been extended to avoid numbering exhaustion. The structure of these identifiers (MSISDN/Directory numbers, IMSIs) are defined in ITU-T Recommendations E.164 and E.212, and 3GPP TS 23.003.
IR1 | The Communications Module shall support 15 digit Directory Numbers/MSISDNs. |
IR2 | The Communications Module shall support 2 and 3 digit based Mobile Network Codes IMSIs. |
IoT Service Provider Requirements (Normative Section)
MCR1 | If permissible for the IoT Service, any IoT Service Platform which communicates to multiple IoT Devices shall avoid synchronized behaviour and employ a randomized pattern for accessing the IoT Devices within the IoT Service Platform’s domain. |
MCR2 | If the (U)SIM subscription associated with an IoT Device is to be placed in a temporarily inactive state (i.e. the subscription is to be disabled for a fixed period of time), the IoT Service Provider shall first ensure that the IoT Device is temporarily disabled to restrict the device from trying to register to the network once the SIM is disabled.Before the (U)SIM subscription associated with an IoT Device is changed to a permanently terminated state, the IoT Service Provider shall ensure that the IoT Device is permanently disabled to stop the device from trying to register to the network once the SIM is permanently disabled.Note: The IoT Service Provider should carefully consider permanently terminating IOT devices which are not easily serviceable as it would require manual intervention (i.e. a service call) to re-enable the IoT Device. |
MCR3 | If the IoT Service Platform uses SMS triggers to wake up its IoT Devices, the IoT Service Platform should avoid sending multiple SMS triggers when no response is received within a certain time period. |
MCR4 | The IoT Service Platform should be aware of the state of the IoT Device and only send ‘wake up’ triggers when the IoT Device is known to be attached to the mobile network. |