Articles in this section

Good practices and guidelines for devices deployed on the EMnify network

Avatar
Jorge Merino
  • Updated
Follow

Any customer deploying a large number of devices (e.g. 1000 devices or more) on the EMnify network must ensure that these devices operate following the good practices described in this article. These practices are put in place to guarantee that the devices deployed by our customers do not impact network services for all users of the mobile networks.

(The references in brackets are to the sections of GSMA’s document TS.34 - IoT Device Connection Efficiency Guidelines)

  1. Back-off strategy in case the device cannot establish a data connection (PDP session): If your devices have already reached the monthly limit or the application server is not reachable, your devices should introduce a random back off timer and not try to connect every few seconds. An example of a proper back off strategy would be:
    • Failed connection attempt
    • (wait 1 minute)
    • Failed connection attempt
    • (wait 2 minutes)
    • Failed connection attempt
    • (wait 4 minutes)
    • ...
    • Stop upon a successful connection attempt or after a cap of 30min waiting time is reached.
      (TS.34_4.0_REQ_003, TS.34_4.2_REQ_003)
  2. Optimal IMSI switch handling: Please ensure that your devices are capable of working with multi-IMSI SIM cards. Please visit this article for additional information.
  3. Connection attempt randomization: Your devices should not try to connect all of them at the same time. The attempt must be randomized. For example, if you are planning that your devices should call the application server once a day, please randomize it over a period of time. (TS.34_4.0_REQ_003, TS.34_4.2_REQ_003)
  4. If your devices need to send data very frequently, they should use an “always-on” connectivity mechanism instead of activating and deactivating network connections (TS.34_4.0_REQ_001, TS.34_4.2_REQ_001)
  5. Your devices should minimize the number of network connections between the device and the cellular networks by aggregating the data into as big a chunk as possible before being compressed and sent over the network. (TS.34_4.0_REQ_002, TS.34_4.2_REQ_002)
  6. Your devices should be able to cope with variances in mobile network data speed and latency considering the variety in performance of mobile communications technologies such as 2G, 3G, LTE, LTE-M, and NB-IoT. They should be be capable of adapting to changes in mobile network type and data speed at any given time. If data speed and latency is critical for your application, your device should constantly monitor mobile network speed and connection quality in order to request the appropriate quality of content from the network. (TS.34_4.0_REQ_008, TS.34_4.0_REQ_009, TS.34_4.0_REQ_010, TS.34_4.2_REQ_008, TS.34_4.2_REQ_009, TS.34_4.2_REQ_010)
  7. Your devices should always be prepared to handle situations when communication requests fail. Communication retry mechanisms implemented within the device can vary and will depend on the importance and volume of downloaded data. Possible solutions can be:
    (TS.34_4.0_REQ_011, TS.34_4.2_REQ_011)
    • 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.
  8. No communication request by the device should ever be retried indefinitely – the request should eventually timeout and be abandoned.
    (TS.34_4.0_REQ_011, TS.34_4.2_REQ_011)
  9. Your devices should send a notification to the cellular network with relevant information when there is an unexpected power outage or unexpected battery power problem. (TS.34_4.0_REQ_014, TS.34_4.2_REQ_014)
  10. The IoT Device Application should not frequently reset the cellular communications modem unnecessarily. The timer value for resetting the modem should be configured in accordance with the IMSI switch operation explained in this article (TS.34_4.0_REQ_019, TS.34_4.2_REQ_019).
  11. If your devices support more than one family of communications access technology (for example 3GPP, TD-SCDMA, Wireless LAN) the devices should implement a protection mechanism to prevent frequent "Ping-Pong" between these different families of communications access technologies. (TS.34_4.0_REQ_026, TS.34_4.2_REQ_026, TS.34_5.2_REQ_002)
  12. 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 devices should employ a randomised delay before switching to a different family of access technology. (TS.34_4.0_REQ_027, TS.34_4.2_REQ_027)
  13. Your device application shall check that communication issues to the server are not caused by higher layer communications (like TCP/IP, UDP, etc.) before starting to reset the communication module or re-establish the RRC Connection. Higher layers mechanisms shall then try to re-establish the connection with the server. (TS.34_4.0_REQ_029, TS.34_4.2_REQ_029)
  14. If your devices communicate over NB-IoT, they should NOT use MQTT or HTTP messaging/management protocols, as these are not optimized for NB-IoT, e.g., as they are based on TCP/IP connections. (TS.34_4.0_REQ_031, TS.34_4.2_REQ_031)
  15. When your devices detect that the IoT Device’s memory is full, for example, due to the amount of collected data, the IoT Device Application shall not reboot the IoT Device or the communication module/chipset. (TS.34_4.0_REQ_032, TS.34_4.2_REQ_032)
  16. When your devices detect that the GNSS coverage is lost, and the GNSS receiver is hosted on the communication module/chipset hardware, the IoT Device Application shall not reboot the IoT Device or the communication module/chipset. (TS.34_4.0_REQ_034, TS.34_4.2_REQ_034)
  17. When your devices detect that LAN connectivity with peripheral devices is lost, and the LAN connectivity function is hosted on the communication module/chipset, the IoT Device Application shall not reboot the IoT Device or communication module/chipset. (TS.34_4.0_REQ_036, TS.34_4.2_REQ_036)
  18. When your devices detect that an in-built sensor or actuator malfunctions, the IoT Device Application shall not reboot the IoT Device or the communication module/chipset. (TS.34_4.0_REQ_038, TS.34_4.2_REQ_038)
  19. Activate the SIM cards before plugging them in. Please ensure that you have activated the SIM and created a Connected Device in the portal before you plug it in. This will ensure that your device is ready to establish a data connection right after you turn it on.
  20. Unplug suspended SIM cards: Even if you suspend a SIM card, your device still can try to attach to a network. In case you are not planning to use a SIM card any longer, please make sure to unplug it from the device to avoid creating unnecessary signalling events.
  21. Proper device recovery: In case of an unexpected event, your devices should be able to recover automatically. Please do not forget to set a watchdog timer that will reset your device in such cases.
  22. Proper shut down procedure: Please follow the procedures specified by your modem manufacturer, so that it de-registers from the network before it powers down.
  23. The IoT cellular Communications Module used in your devices shall be compliant with 3GPP specifications. (TS.34_5.1_REQ_001, TS.34_5.2_REQ_001)
  24. Legal and regulatory compliance requirement: Please ensure that your devices are certified to be used in the countries where you are planning to deploy them. (TS.34_5.1_REQ_003)
    Certification implies that the devices meet the initial inspection requirements on many topics, especially:


    • Individual Network Protocols
    • TRP – Total Radiated Power
    • RSE – Radiated Spurious Emissions
    • Idle Mode Emissions,
    • Sim Specifications
    • Specific Absorption Rate, etc.


    The authorised organizations are guiding the process of certifications, those are empowered by commissions, industry consortiums or sometimes by the network operators. The way how the certification process is built is different across geographies. 


    The Certification process in North America, consisting of three layers:
    • General or governmental level, which ensures that the device is properly regulated in terms of the level of radiating the energy and radio frequency spectrum. The authorised body in the USA is the Federal Communications Commission (FCC). In many cases, depending on the behaviour of the devices, the FCC certification is enough to identify them in the networks of different operators, but that might be insufficient when it comes to some mobile network operators
    • Operating level on mobile networks, and here is the primary certification authority is PTCRB, which has mobile network operators and related industry participants, such as Rogers Telecommunication, Bell and Telus in Canada, and T-Mobile, AT&T and Sprint in the USA.
    • Certification separately by some carriers. For example, if you would like your devices to operate under the Verizon network in the USA, they need to be independently certified by this carrier. Another example is AT&T, which for some use cases might require own additional certification.

    The Certification process in Europe is from the first view seems to be relatively easy. The primary two certification process in Europe is driven by the Global Certification Forum (GCF) and European Conformity (CE).

    “Test once, use everywhere” is the motto of GCF, that ensures working of the devices across the different cellular networks in Europe and Worldwide, which have adopted the 3GPP Standard. Based on the use case of the M2M and IoT devices, the manufacturer can select from the different type of certifications and be compliant for it. That also affects the pricing of certification.

    The CE certification ensures that the devices to be launched in European countries are compliant with the requirements of the European Commission directives. This certification is applicable to many types of devices and also for radio and telecommunications equipment. Similar to GCF certification, once the CE certification is done, the device can operate in any mobile network within Europe. Based on the different test scenarios and use cases, the manufacturer might select the certification either from CE or GCF.

  25. The IoT Cellular Communications Module shall support 15 digit Directory Numbers/MSISDNs. (TS.34_5.9_REQ_001)
  26. The IoT Cellular Communications Module shall support 2 and 3 digit based Mobile Network Codes IMSIs. (TS.34_5.9_REQ_002)
  27. The IoT Cellular Communications Module should be capable of handling SIM Toolkit communications such as POLL INTERVAL and REFRESH proactive commands as specified in 3GPP TS31.111.
  28. Cellular modems should be in compliance with 3GPP Release 6 specs as minimum to be able to use eUICC SIMs such as emnify's v7 SIMs.
  •  

 

 

Related articles

Comments

0 comments

Please sign in to leave a comment.