Implementing IoT devices involves a multitude of factors to ensure successful deployment and operation. From regulatory compliance to network connectivity and data management, each aspect requires careful consideration.
To help streamline this process, we’ve compiled a comprehensive checklist covering critical areas of IoT device implementation. This checklist serves as a guide to ensure that all necessary steps are taken for a seamless and efficient deployment of IoT devices.
Below, you will find detailed recommendations across key categories essential for a successful IoT implementation.
| Category | Recommendations for implementation |
|---|---|
| Compliance & Interoperability | (Required) Check with regional regulations and ensure that the device has obtained all necessary certifications (PTCRB, FCC, CE, etc.). Depending on the region, additional certifications may be strongly recommended even if not strictly required. |
| (Strongly recommended) Check with vendors to ensure that the device or communications module complies with 3GPP and GSMA standards. | |
| (Strongly recommended) Choose IoT devices or communications modules where network interoperability has been tested and validated. Check if the MNO has additional certification requirements, and ensure that the device or communications module has appropriate carrier certification. | |
| When using a Soracom SIM that provides coverage with multiple networks, select an appropriate IoT device or communications module that is compatible with the supported networks. | |
| Network connection behavior | Avoid excessive connections and disconnections. If network connections will occur at regular intervals, implement a mechanism to distribute or vary the timing of the connections. |
| Avoid synchronous connections of large numbers of devices. Implement a mechanism to distribute the timing at which each device connects to a network so that a large number of devices will not attempt to connect at the same time. | |
| Understand wireless access technology and the behavior of the communications module with regards to network search. Ensure that an IoT device allows its communication module sufficient time (at least 2-3 minutes; longer if using radio technologies such as NB-IoT, a mix of radio technologies, or multiple frequency bands) to perform a network search procedure. Do not implement a mechanism that restarts the device or module during a network search procedure. | |
| Understand the behavior of the communications module with regards to network selection. When possible, allow a module to utilize its default automatic network selection behavior (such as AT+COPS=0). Do not implement a mechanism that forces a module to connect to a specific network as it may result in unwanted side effects. | |
| In case of a network connection failure, avoid continuous reconnection attempts. Implement a mechanism that exponentially increases the time between reconnection attempts, or ceases attempts after a threshold number of attempts. | |
| Ensure that a device will only connect to a network when its SIM is in the Active status. If the SIM status is to be changed to Suspended or Terminated, ensure that the device will not continuously attempt to reconnect, or power off the device completely. | |
| Network connection management & data transfer behavior | Reduce the number of network connections per device. Avoid connecting to a network unless required, and implement a mechanism to minimize the number of network connections needed to transfer data. |
| Select a data protocol that is appropriate for both the application or use case as well as the network technology. When using a heartbeat or keep-alive function, ensure that the duration is set just below the network connection timeout threshold. Do not implement a heartbeat or keep-alive function with a high frequency as it counteracts the network connection timeout behavior and may result in unwanted side effects. When using NB-IoT, try to prevent the use of TCP or other protocols based on TCP. | |
| Where possible, reduce the amount of data transfer required. Implement a mechanism that transfers only the portion of data that has changed since a previous transfer, rather than repeating the same data. Utilize data formats such as binary, and consider leveraging features such as Soracom Binary Parser to maintain interoperability with IoT platforms or services. | |
| Avoid synchronous data transfer of large numbers of devices. Implement a mechanism to distribute the timing at which each device transfers data (or data is transferred to each device) so that a large number of devices will not transfer data at the same time. | |
| When devices need to be powered off, ensure that they shutdown gracefully by first disconnecting from a network in order to reduce network resource usage. | |
| Device recoverability | Implement a mechanism that enables FOTA update functionality. Ensure that both the IoT Device Application firmware and Communications Module firmware are able to receive FOTA updates. Ensure that the FOTA functionality incorporates data compression, differential updates, and other techniques for minimizing data usage. When performing FOTA updates, implement a mechanism that distributes the timing at which each device receives the FOTA update so that a large number of devices are not updated at the same time. |
| Implement a mechanism that allows the SIM to receive OTA updates (including but not limited to Subscription Containers). Ensure that the device will maintain a network connection of suitable duration so that an OTA procedure can be completed. | |
| Understand the behavior of the communications module with regards to Forbidden PLMN (FPLMN) and its effect on connecting to a network. Implement a mechanism to allow the FPLMN to be manually or automatically cleared, such as a user-accessible reset button or based on a suitable timer. Do not rely solely on a mechanism for remotely clearing the FPLMN, as when a device is unable to connect to any network, a remote procedure cannot be used. |
In general, the security of the wireless portion of a cellular network connection is provided by the network according to 3GPP standards. However, without taking appropriate precautions measures to secure the device itself, an attacker may be able to hijack a device and force it to behave in ways that are disruptive to a network, undoing all of the steps taken above.
While specific recommendations for implementing device security are out of the scope of these guidelines, additional care should be taken to test security measures and validate that devices are sufficiently protected from abuse or misuse.
These measures may include using embedded SIM (eSIM) modules in order to thwart SIM theft and unauthorized SIM usage, employing of X.509 certificates or strong password practices to prevent a single compromised device from exposing an entire fleet, and implementing signature verification for FOTA updates in order to block an attacker from installing malicious code.
Which measures are appropriate will depend on your device, application, and use case, however as a start you may like to refer to these existing guidelines:
Besides cellular network security and device security, internet, cloud, or other IP infrastructure security is also an important part of designing and implementing a robust application.
Soracom also provides several services which aide in improving and simplifying IP network security, from automatically encrypting data before it is sent over the internet, to building an isolated network to connect to your private cloud or datacenter.
To ensure the proper device operation and connectivity, IoT Device Applications must be aware of the resources used, including their corresponding protocols and parameters, and should manage them appropriately.
For example, when implementing SMS communication in an application, the application must coordinate the management of SMS storage on the SIM and the timing of the communications module connecting to a network.
If a SIM does not have enough storage, the module might reject an SMS, and if the device does not remain online long enough, the SMS might never reach it. The application must handle these resources properly to ensure successful SMS delivery.
The specifics of how the application should coordinate these resources will depend on many factors, such as whether the communications module uses a specific technology or feature such as Power-Saving Mode (PSM) — a feature that allows the module to stay connected to the network and receive an incoming SMS before transitioning to a low-power sleep mode, rather than completely shutting down and being unreachable — and whether or not the MNO supports the feature.
While device applications should be designed to leverage these capabilities as cellular networks and wireless technologies continue to evolve, they should also take into account the global phase-out of 2G and 3G networks.
All SIMs include an International Mobile Subscriber Identity (IMSI) number which acts as a globally unique ID that a network uses for deciding whether or not to allow a device to connect, determining how data should be routed, and keeping track of data usage.
While that’s very much the case for Soracom IoT SIMs, Soracom also provides a feature called Subscription Containers that allows Soracom SIMs to have multiple IMSIs and automatically switch between them where advantageous.
Having a second or third IMSI can allow a device to connect to more networks in more countries, to switch to cheaper networks when available, or to fall back to networks provided by a different IMSI when the networks covered by one IMSI are unavailable.
When leveraging Soracom Subscription Containers for these benefits, IoT Devices should be designed according to the Over-The-Air (OTA) mechanism that the Subscription Container feature uses for remotely installing and managing IMSIs.
As the OTA procedure may take several minutes to complete, a device that is designed to disconnect from the network or shut down too quickly will be unable to fully receive the OTA, and as a result the procedure may take several days or may even fail, leaving the device stuck with only the original IMSI available.
Implementing a suitable OTA mechanism is recommended, such as sending a command to the device to instruct it to remain powered on for a longer duration (a minimum of 5 minutes is recommended for a Subscription Container installation procedure to complete) whenever an OTA is required.
While suspending or terminating a SIM will have the effect of instructing a network to reject a connection, there are also many other scenarios where a device may not be able to connect to a network, such as temporary cellular network problems.
While rare, some scenarios may further result in the communications module adding the network to the Forbidden PLMN (FPLMN) list — a list stored in the SIM that the module uses to determine which networks it should ignore — due to being unable to connect.
This can have a significant effect on the IoT device, such as losing connectivity even after a temporary network issue has been resolved.
3GPP Standard Release 10 and above defines a procedure for a communications module to automatically clear the FPLMN list at a specific interval in order to recover from such scenarios. However, modules that only support Release 9 or below might not be able to clear the list automatically, and may therefore be unable to reconnect without manually clearing the FPLMN list or rebooting the device.
Depending on requirements, implementing a suitable recovery mechanism is recommended. For example, if a device has a user-accessible reset button, the IoT Device Application should be designed to actively clear the FPLMN list as part of its reset procedure.
For devices that will operate autonomously, the application should automatically clear the FPLMN list if the device has not been able to connect to a network for a long time (e.g.: 2 days). Note that if a device has completely lost connectivity, remotely triggering a reset procedure would not be possible and, therefore, would not be a suitable recovery mechanism on its own.
If power to a module is suddenly cut, from the perspective of the network, the MNO cannot differentiate whether the sudden lack of communication from the device is simply due to temporary signal loss such as interference, or due to the device being powered off.
Since temporary signal loss can be quite common, especially for mobile applications, cellular network infrastructure is designed to retain the connection information so that once a device is back within coverage, the connection can be resumed immediately without needing a complete reconnection procedure.
However, if a device is being powered off, there is no intention that the device will be resuming the connection and as a result the network will be needlessly maintaining the connection information and using up network resources.
Although the network will eventually remove the connection after a timeout, the network resources will remain blocked during this time.
Therefore, when a device is to be powered off, the application and indeed the device itself should be designed to allow the communications module to first disconnect from the network before completely powering off the module and other components.
When an IoT Device attempts to connect to a network using a SIM that has been suspended or terminated, the network will reject the connection accordingly.
Even though no connection is made, numerous signals are still exchanged with the network, which if repeated will increase the load on the entire network, similar to connecting and disconnecting excessively.
For this reason, IoT Devices should be implemented such that the device does not continuously repeat connection requests when the SIM is suspended or terminated, such as exponentially increasing the duration between reconnection attempts, or ceasing reconnection after a set number of attempts.
If a device fails to connect to a network, check the error cause code indicated by the communication module and ensure that the failure is not a result of a rejected network connection based on the status of the SIM.
Suspended status instead.Active will simply tell the network to allow any subsequent connection attempt, but does not initiate the connection itself. In order to do so, the device must be manually rebooted or power-cycled in order to clear the FPLMN list and allow the communications module to resume network connections. Therefore, before utilizing the Suspended status, ensure that you will be able to access the device in order to restart it.Soracom also provides a Terminated status, which will also result in the same permanent reject cause network behavior as the Suspended status. The functional difference between these statuses is that Terminated status SIMs cannot be reactivated. If you will no longer use a Soracom SIM, terminating the SIM will ensure that it cannot be accidentally reactivated later.
IoT Devices will inevitably encounter situations where network communication requests fail. When considering how to handle those failures, IoT Device Applications should be designed with the understanding that the IoT Communication Module’s normal behavior is to maintain a cellular connection.
Much like the previous section, when some kind of communication failure occurs, interrupting or forcing the module to behave differently than its normal operation is counterproductive for both the device and the network, and as recommended in TS.34_4.0_REQ_011, 012, 019, and 029, developers should take care how their device applications handle communication failures.
Applications should not retry failed communication requests indefinitely, but should eventually time out or abandon the request.
Similarly, frequent rebooting or reconnecting should be avoided, as communication failures may be due to a different part of the application other than the cellular network (for example, the application is unable to resolve DNS, or a server is temporarily offline), and forcing the communications module to restart is unnecessary and only serves to put additional strain on the network.
Instead, devices should check for issues elsewhere first and employ techniques for buffering or storing data internally, exponentially backing off between retries, or even waiting until “off peak” hours or days to transmit data when the network is not as busy, as recommended in TS.34_4.0_REQ_016, 018, and 025, before resorting to manual manipulation of the IoT Communications Module.
This also applies to use cases that incorporate other types of wireless technologies. For example, GNSS is a common choice for location-tracking applications, and many communications modules also support GNSS using the same receiver that is used for cellular connectivity.
However, as described in TS.34_4.0_REQ_034, loss of a GNSS signal should never result in restarting the cellular portion of the module, and device applications should leverage features like eDRX so that the receiver can be freed to evaluate GNSS signals without disconnecting or restarting the cellular module.
The same extends to devices that also have other connections, such as LAN (TS.34_4.0_REQ_036), WiFi (037), or connected sensors (038). The application should handle each communication separately, with each connection being independently restartable without having to restart the communications module.
In the worst-case scenario, when a device neglects these considerations and carelessly overrides the standard behavior of the communications module, MNOs may decide to blacklist the device outright to prevent further harm to the network.
Depending on the type of blacklisting, there may be no way to recover other than to replace the entire module or device.
While it’s important to understand how different connectivity technologies behave and how to design your IoT Device Application to work with the IoT Communications Module and adapt accordingly, the application should also be designed to avoid imposing too much manual control over the module.
For example, all communications modules include an AT+COPS command which can be used to instruct the module to connect to a specific network, bypassing the need to search for other networks in the area.
While the device application can leverage this command to significantly speed up the network connection procedure, this command also overrides the module’s default ability to search for and switch to a different network that may have a stronger signal and better performance.
When the IoT Device is located in an area where the pre-selected network’s signal is low, forcing the communications module to connect to this network anyway not only jeopardizes the application’s ability to transmit data successfully but risks stressing the network due to communication failures all while other more capable networks are available but ignored.
This also applies to situations where a network has a temporary outage. If the module is forced to connect to that particular network, the device will not be able to switch to other available networks and will lose connectivity during that time. Worse, if the device is no longer allowed to connect to that network (due to blacklisting or loss of coverage), the connectivity loss will become permanent.
Some modules support a hybrid version of the AT+COPS command, allowing you to manually specify a particular network to connect to, but automatically falling back to the normal network search process in case the specific network is not available or suitable.
Knowing the capabilities and behaviors of your communications module becomes even more important for use cases where devices will be deployed globally, as devices will have to contend with a much wider range of connectivity technologies, available frequency bands, network scan conditions where each device is located, and so on.
Knowing how network search time varies between different connectivity technologies is also important when designing IoT Devices.
For example, the time it takes an IoT Communications Module to find an NB-IoT network increases nearly linearly with the size of the band being used. A 10MHz band (such as Band 13) takes around 4 seconds to scan, while a 60MHz band (such as Band 1 or Band 2) takes six times longer to scan.
Thus, a communications module that has enabled NB-IoT Bands 1, 2, and 13 will need to scan for roughly 50 seconds before connecting to a network — or 10 times longer (or even more) with more bands enabled, or when signal quality is poor.
This compares to 2G, 3G, and LTE technologies, where a communications module can typically complete a full network search and connect to a network within 2-3 minutes. An IoT Device Application that assumes the module should be connected within 3 minutes and is designed to restart if not, may never be able to successfully finish scanning NB-IoT networks.
This is why NB-IoT is described as being suited for devices that will be installed in a permanent location, as it avoids the need to constantly search for networks the way devices in mobile use cases do when they move around.
As many LPWAN communications modules support LTE-M, NB-IoT, and 2G technologies, developing IoT Device Applications that adjust timeouts according to the connectivity technology, as well as limiting the number of bands to use and adapting the application to technology-specific behaviors (such as NB-IoT network latency and Coverage Enhancement), is critical to success, as recommended in TS.34_4.0_REQ_008 and 009.