Connectivity powers all IoT devices and establishes the connection between modems and SIMs on the network. But it isn’t always stable, and you need to prime your IoT device to deal with any potential loss of connectivity. In this blog we look at the different connectivity issues your device may face and how it should manage them.
Standards form the basis of any effective process. That’s why it’s important that your modem complies with all relevant standards, including Third Generation Partnership Project (3GPP) standards and Global System for Mobile Communications Association (GSMA) guidelines.
Your modem should also be Global Certification Forum (GCF) certified, which means it should have processes in place to manage network selection, location updates, IMSI attaches and detaches, PDP activations and deactivations, and abnormal releases and rejects.
There are many reasons why your modem would lose a connection or fail to connect to the network. Let’s take a closer look at eight of the most common connectivity scenarios and how your device should deal with them.
- The network experiences an outage: If a connection to one network (Carrier A) is problematic, your device should select an alternative network (Carrier B). If the device wants to switch back to Carrier A, it should wait at least five minutes to avoid excessive switching back and forth (and the associated signalling overhead).
- Interacting with roaming network: If a device tries to connect to a blocked or non-partner network, it will get a “PLMN Not Allowed” (Reject Code 11) or “Roaming Not Allowed” (Reject Code 13). Public Land Mobile Network (PLMN) is the unique code for each telecom operator in a specific country. It comprises a unique country code and operator code within that country (for example, Ireland’s country code is 272 and Vodafone’s operator code in Ireland is 01). In this instance, your device should try to connect to an alternative network.
- When a network returns “PLMN Not Allowed”, your device should add this network to the “forbidden PLMN” or FPLMN list on the SIM, so that it will not retry these networks. The SIM will clear the FPLMN list each time the device is fully powered down and restarted. If your device is rarely powered off you should include a scheduled or on-demand routine to clear the FPLMN list. Clearing the FPLMN list is an important part of your device/SIM effectiveness, particularly if you expect to alter the network your device/SIM can attach to in a different country. If you have SIMs on a restrictive profile but need to open up access to more networks, those SIMs may not attach because of a previous “PLMN Not Allowed” reject (the reject has been cached in FPLMN). This can happen even if the network profile no longer blocks the connection.
- Non-preferred network: If a device tries to connect to an available but non-preferred network, it will get an “Unexpected Data Value” (Reject Code 17). Although the device could connect to this network, it should try a preferred network first. There is usually an underlying reason why a network would be deemed non-preferred, including higher costs or an issue between carriers.
- Issues with data connection: If your device is unable to send or receive data from a server after setting up a data connection, it should either try to verify data connectivity against a separate/public server or reset the data connection by doing a Packet Data Protocol (PDP) deactivation and reactivation.
- Failure to get a PDP context: If the device fails to get a PDP context, you should limit the number of retries and backoff for an extended period of time, for example, four retries one minute apart, then at 15 mins, 30 minutes, 60 minutes and then at 60-minute intervals after that.
- Issues with network registration: In the case of a network registration or network attach issue, you should reboot the modem and try registration again. Space out the timings here to avoid overwhelming the network, for example, once every five minutes no more than four times, then backoff to 30 minutes, 60 minutes and no more than every 60 minutes after that.
- No or low throughput: Throughput may fluctuate and even drop to zero for a period of time. This is usually down to an issue with an application server or a network. To avoid unnecessary retries, your device should wait for a minimum of one minute for a response in the event of zero throughput before re-establishing a connection.
Spacing out connectivity retries is important for the overall health of the system. Too many retries at the same time can overload the system. This can cause your failover to fail because the backup can’t handle the sudden load, or the system itself can struggle to come back online because it’s under too much pressure.
Connectivity dos and don’ts
- Do anticipate the number of PDP requests devices are likely to make. The frequency should be less than one per second per 10,000 devices.
- Do take the time to understand what typical usage (in terms of MB and SMS) will look like.
- Do ensure that your device supports the specific radio frequencies of the regions or countries it will be deployed in.
- Do regular cleanups on your system and disable, or remove and destroy unused or end-of-life SIMs.
- Don’t synchronise activity across devices against time. This can cause a spike in simultaneous connections. Instead, stagger scheduled events by a random amount of time +/- against the “scheduled” time to run.
- Don’t test or use a large number of devices within a confined geographical space like a production or testing facility. This can cause congestion on the local radio site and associated connectivity issues.
For your application to provide a consistent and reliable service to your end users, your modem’s ability to react to connectivity issues is vital. Your modem needs to be programmed to handle edge cases, that’s where extensive testing can be effective. If you’re unsure where to start when it comes to device testing or the specific testing requirements you need to comply with, we’re here to help. Contact Thinglabs at info@thinglabs.ie or +353 44 967 5000.