Introduction
When IoT deployments become large, the way each device interacts with the network can make all the difference — both for your device performance and for the overall stability of the Onomondo network. Small inefficiencies may go unnoticed at first, but at scale, they can lead to increased costs, reduced reliability, and even network disruptions. In addition, while a single or small number of misbehaving devices typically won’t impact other users, a large group of devices operating in a negative pattern consistently or at the same time may have a very adverse impact on network resources and therefore on other users.
At Onomondo, we want to empower you to build IoT solutions that are not only efficient and robust, but also network-aware and secure by design.
This IoT Code of Conduct outlines key best practices to help your devices operate optimally, even under challenging conditions. Following these guidelines will ensure your deployments are scalable, cost-effective, and ready for the future of global connectivity.
Key considerations
Based on IoT Device Connection Efficiency Guidelines presented by GSMA, here are the key considerations to be aware of.
APN Configuration
APN set to "onomondo" is a necessary prerequisite to attach a data connection via the Onomondo network.
Customers are responsible for the configuration of the APN in their device.
APN shall be configured in the device by the Customer.
Customer shall be able to re-configure the APN in the Device.
Leaving the APN blank or set to anything else than "onomondo" (all lower-case) can lead to problems with PDP context activation and establishing data connection.
Not sure how to define the APN? See this guide:
Avoid synchronized behaviour
Your fleet likely consists of hundreds or thousands of devices deployed simultaneously. Those devices should not try to connect to the mobile network at the same time to avoid excessive network congestion.
In formal terms:
The monolithic IoT Device Application shall avoid synchronized behavior with other IoT Devices or events, employing a randomized pattern (e.g. over period ranging from a few minutes to several hours, or days) to request a mobile network connection.
The triggering of data transmissions, the rebooting of the IoT Device hardware or sub-components (such as the communication module/chipset), or execution of device management commands shall not be synchronized.
In tiered IoT Devices, the embedded Service Enablement Layer shall implement these requirements in the same way as for monolithic IoT Device Applications.
A monolithic IoT Device Application refers to a software architecture design where the entire application logic for the IoT device is developed as a single, tightly-coupled unit.
In a monolithic architecture:
The firmware or software running on the IoT device is composed of one large program.
All features—such as sensor control, data processing, networking, security, storage, and communication—are bundled into a single binary.
Modules (even if logically separated) share the same memory space and are tightly interdependent.
Implementation of randomisation
Mirroring the above point, each device should wait for a random amount of time, ranging from minutes to hours or even days, before trying to connect. If the device fails to connect, it should be instructed to back-off for a period of time.
The monolithic IoT Device Application shall be designed to strive for asynchronous traffic behaviour.
When a Device connects to the network to access a service (data and/or SMS and/or voice), attempts shall be randomized between Devices of the same application both temporally and spatially. In other words, if devices need to upload data to the application server at a fixed interval, attempts should be randomized within at least fifteen percent (15%) of the transmission frequency.
For example, if the report frequency is 30 min, the device should use an approx. 4-5 minutes randomization window.
If an application fails to establish a packet data connection to the network or to its application server, then it shall introduce a random exponentially increasing back-off timer before it attempts to connect again.
The re-attempt shall be randomized across the group of Devices.
Example: Your application server fails with an error or times out prematurely.
If multiple Devices need to communicate with that server and they all make a repeat attempt to access the data service at the same time, they may all be unsuccessful, as the demand for resources may be exceeded, with the result that they then drop into a retry pattern with an effective self-created Denial of Service.
Zero-Byte Session Principle
Sometimes, an IoT device establishes a mobile data session but transmits no payload data, i.e. no user data is exchanged, even though the session is technically live. While this could occur due to server errors and misconfigured firmware, opening data sessions just to maintain presence on the network or test connectivity is undesirable.
The monolithic IoT Device Application shall only establish data sessions for the purpose of sending and receiving data.
An application which establishes a data session and then terminates it without sending data (a “zero-byte session”) on a regular basis may cause excessive network congestion.
You can easily spot zero byte sessions in the Onomondo Network Logs. Notice that both Upload and Download are at 0 bytes.
Use of "Always-on" Connectivity
Instead of instructing the device to attach and detach after each session, it is more optimal to allow it to stay attached and send data whenever it needs to.
If the monolithic IoT Device Application sends data very frequently (i.e. inactivity periods shorter than two hours), it shall use a persistent PDP/PDN connection with the mobile network instead of activating and deactivating said connectivity.
Behavior when Communication Requests Fail
Your device should know how and when to reattempt a connection if it was rejected by the network. Aggressive reconnection strategies come with a lot of unnecessary risk and may cause more harm than good, leaving your device "locked out". A balanced back-off strategy and respecting rejections is the recommended way to go.
The monolithic IoT Device Application shall always handle situations when communication requests fail in a way that does not harm the mobile network.
The mobile network may reject communication requests from the IoT Device with a 3GPPTM error cause code (refer to GSMA TS.34). When the IoT Device Application detects that its requests are rejected, it shall retry connection requests to the mobile network with an exponentially increasing back-off period.
The IoT Device Application shall not start an application-driven reboot of the communication module/chipset, attempting to ignore or override the mobile network’s decision. Communication requests from the monolithic IoT Device Application shall not be retried indefinitely – all requests must eventually time-out and be abandoned by the IoT Device Application.
Handling Loss of Service and Device Recovery
Even if the connection appears lost, it may not necessarily be due to problems with the connectivity layer. Consider multiple components that are at play when it comes to the data transmission that occurs between your device and the server. Whenever connection is dropped, it's worthwhile checking which component has failed.
The monolithic IoT Device Application shall always be prepared to recover lost end-to-end connectivity while camping on a roaming network.
This is implemented with a top-down, staged recovery algorithm diagnosing each protocol layer. In case of failing to re-establish one layer, the algorithm initiates the recovery procedure.
All re-establishment procedures shall be implemented in a reasonable way avoid excessive signaling to the network. This may include usage of randomized triggers and incremental, back-off retry mechanisms.
Threshold and timer values may depend on the IoT Service’s requirements.
Example: Re-establishing connectivity algorithm.
Step 1. Re-establish higher layer connectivity, fx. VPN tunnels or SSH sessions.
Step 2. Re-establish PDN connectivity or PDP context.
Step 3. Re-attach (data) to the network.
Step 4. Re-trigger automatic network selection.
Step 5. Complete reboot of the device.
Sometimes, the connection may be lost due to other reasons that occurred on the device level, rather than the Connectivity layer.
The monolithic IoT Device Applications shall implement a recovery method in case of unexpected behaviors such as a firmware failure or any similar event.
An example of a recovery method is a watchdog timer that resets the Device when a specific condition is encountered.
The Customer shall be able to reboot the device whenever it gets stuck in a bad state and connectivity cannot be restored remotely.
See this guide for more tips on how to implement recovery mode:
FPLMN clearing
FPLMN (aka forbidden list) is a standard component of a SIM. The list is stored on the SIM, but managed by the IoT device. According to standards (refer to GSMA TS), whenever a network connection is rejected, the device is obliged to add corresponding network credentials to the FPLMN list on the SIM and avoid this network in the future. If all local networks are added to the list, the device may find itself locked out of service.
The monolithic IoT Device Application shall contain embedded firmware logic for periodic FPLMN clearing.
The Customer shall be capable of clearing the entries on the FPLMN list.
More information on FPLMN and how to clear it can be found here:
PLMN Selection
For optimal device behavior - it is always recommended to maintain the device in automatic network selection mode. Toggling between automatic and manual selection is unadvisable as it may cause unwanted issues.
The monolithic IoT Device Applications communicating over 3GPPTM Mobile IoT access bearers, such as NB-IoT and LTE-M, shall avoid manual PLMN selection when possible.
It’s also highly recommended to avoid using AT+COPS command when roaming and use AT+CFUN instead and perform a "soft reset".
Summary
Each of the above guidelines helps ensure your devices:
Use network resources wisely
Recover smoothly from failures
Scale up reliably without causing network disruptions
Provide a seamless and robust service experience to end users
Behavior | Good | Bad |
Retry after network rejection | After exponential backoff | Immediate retry loops |
Interpret cause codes | Correctly & respectfully | Ignore them |
PSM/eDRX use during outages | Enabled | Disabled |
Handling of network errors | Stay registered, minimize signaling | Detach/reattach repeatedly |
OTA updates | Backoff retries | Immediate mass retries |
Recovery | Stable timers and backoff | Frequent reboots or resets |