5 Communication Module Requirements (Normative Section)

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:

  • Neighbour Discovery Protocol (apart from the exceptions noted in 3GPP TS 23.060 (3G) or TS 23.401 (LTE)
  • Stateless Address Auto Configuration
  • ICMPv6 protocol
  • IPv6 addressing architecture
  • IPv6 address text representation
IP5 The IoT Communications Module should support the following IPv6 functionality:

  • Privacy Extensions for Stateless Address Auto-configuration in IPv6
  • ROHC for IPv6
  • IPv6 Router Advertisement Flags Options
  • Path MTU discovery
  • IPsec version 2 tunnel mode (IKE2)

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:

  • 5 to 10 (the specific value in range is to be defined by Mobile Network Operator) seconds for networks with PCH RRC State support (URA-PCH or Cell PCH)
  • Trigger disabled for networks without PCH RRC State support (URA-PCH or Cell PCH)

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.