IoT Hacking Series #7: How to Correctly Configure and Debug IoT Devices

Every IoT business starts small and with just a few devices. Getting those devices connected is usually not much of an issue. However, when your business begins scaling and production ramps up, then shortcuts made in the early days might come to haunt. It’s much more painful to fix those issues afterward when you have thousands or tens of thousands of devices already rolled out.

In this article, we are focusing purely on connectivity matters that you, as an IoT device maker or service provider, need to consider from day 1. Proper connectivity backup implementations need to be addressed together with the system of using and testing SIM cards throughout the production phase.

Correct technical implementation of cellular data connection

For a successful cellular data connectivity setup, you need to follow the 3GPP technical specification document precisely. The universal paper ensures a standardised and interoperable solution around the world. We suggest to have a look at the material yourself, but as it is very technical and includes many abbreviations, we will give you a summary.

The Packet Data Protocol (PDP) context activation procedure is used to establish a data session with the network. A PDP context can be established from the device or theoretically also by the network. As IoT devices want to create a data session logically themselves, let's have a look at the required steps.

1. First, the device will send an Activate PDP Context Request to the operators' network. Activate PDP Context Request carries the information of PDP type, data bearer, IMEI (device identification number), IMSI, APN, etc.

2. On the operator's network, the request is received at the Serving GPRS Support Node (SGSN) whose responsibility is to handle the information that comes into the network. The SGSN will route the request to the responsible network element. In this case, SGSN will read the APN (Access Point Name) address information and accordingly forward the Create PDP Context Request to the correct GGSN.

3. Gateway GPRS Support Node (GGSN) is responsible for interworking between the operators GPRS network and external networks, like the Internet. GGSN ensures that all the information received in the operator's network is routed to the correct place outside the operator network; in this case, the Internet. If the parameters passed with the PDP context Request satisfies the service requirements, the GGSN will send a "create" response. Otherwise, it will reject the request.

4. The GGSN will reply with a Create PDP Context Response, which is an acknowledgment to the create PDP request.

5. The end device will receive an Activate PDP Context Accept message, telling the device that it is allowed on the network to have a data session.

6. After this, the device has established a data session successfully and is connected to the Internet.

The deactivation process for closing a data session is similar, the difference being that not an activation message is sent, but a deactivation message instead.

The correct implementation of cellular connectivity relies on the procedures explained above. Misconfigured devices which for example may activate the PDP context without deactivating it first can quickly start having connectivity problems and regarded as misbehaving cellular devices in the eyes of telecom operators (especially by roaming networks). Such non-standard behavior has a direct impact on the operator's network, and in some cases, the operator may ban your device from the network. Secondly, it will affect the device's data usage and power consumption remarkably.

Thinking of PLAN B

Even though you might have set up the data session correctly at first, there can always be firmware updates for the device or cellular module that might break things up. Therefore, it is crucial to think through possible backup plan or checklist for actions when data connectivity is down. The last thing you need is deployed devices that you can't communicate with because of no data connectivity.

One possible PLAN B would be to implement basic functions through SMS. For example, restarting device, handling, and reporting network registration status, setting hardware-level PLMN list (PLMN codes specify operators within a given country) or sending current location could be done via SMS. The remote access to the device via SMS can be helpful to fix configuration issues and re-establish the PDP session.

A slightly different approach for PLAN B would be to have a fallback radio access technology. It's a hardware-level alternative as the cellular module needs to support a fallback technology. Once your primary bearer fails to connect, it will try to use a fallback bearer. A solution could be a 3G cellular modem with a fallback to 2G or even more important is to have NB-IoT/CAT-M1 with fallback to 2G/3G/4G.

Organizing devices at manufacturing

Imagine a situation where you know that your devices are not working in a country X. As there is no connectivity you cannot tell exactly which SIM cards (ICCIDs) or devices need to be reset or debugged. Therefore while manufacturing or deploying new devices, it is vital to group or tag SIMs/devices in a clear and structured way. It can be done with 1oT's Terminal or also through our API.

It's up to every IoT device maker or service provider to decide what makes the most sense in their production, but we have seen excellent results when grouping devices per production patch, deployment patch and also adding tags with the device location or hardware specifics. Grouped or tagged production patches can easily be identified, and the problem evaluation or fix can be quicker even if you have a significant amount of devices deployed around the world.

Because you have thought of PLAN B and devices are fitly organized, you can send SMS commands directly from the 1oT Terminal with only a few clicks. Also, be assured that you are solving the issue of the correct patch of SIMs. Without a well-thought system, it would make applying configurations more complicated. Even if you know how to solve the connectivity issue, you can't be sure if you fixed it for all the SIMs/devices that were affected.

Connectivity troubleshooting checklist

Once you run into data connectivity issues, there are some steps to try at first. Here is our checklist for our customers to go through to solve potential connectivity issues.

• Are you using the SIM card for the first time?
  Make sure you have activated the SIM card from 1oT's SIM management platform Terminal.

• What APN are you using?
  Make sure that you have configured the correct APN.

• Have you tried turning it on and off again?
  May sound silly, but most often this is the solution to the problem. Make sure you turn the device completely off! Offline or power savings modes will not have the same effect.

• Try a secondary device.
  If it is a removable SIM card, plug it into another device you know is working correctly. PS! Don't forget the APN settings.

• Do a SIM reset from 1oT Terminal.
  Under the SIM edit options, you will find a possibility to perform a SIM reset. It will initialise the SIM as it would be new. Keep in mind that you will need to complete a device restart right after SIM reset for changes to take effect. Otherwise, PLMN rules (that can be refreshed only by turning the device on and off) will override network level configurations.

• Check the operator selection and network registration status on the device.
  Verify whether the device can see networks if it is connected to a network or is trying to attach to a network. Depending on the device this can be different, but most often if you have AT interface access you can verify it with AT+COPS=? command.
• IMEI lock?
  Make sure that your SIM is not IMEI locked. If you used the same affected SIM in a test device, and then in another device, the IMEI and SIM card will not have a match. Therefore SIM will not be able to establish a network connection.

What can be seen on the network level?

Operators might be able to see more information from the network level. However, it will require a considerable amount of resources, and the problem needs to have an impact on a big scale. What is more scary, debugging by the operator can sometimes take 1-2 days to carry out.

Here are the information operators are usually able to provide you with:

• Live tracing
  Set up an active trace to gather logs about a specific IMSI.

• Verify APN that is used to connect
  Operators can make sure that the APN configured at the device level is also what reaches to the network.

• Source IP, destination IP
  Operators network see where the request is coming from and also if it is forwarded to the expected destination.

• Radio Access Technology
  Operators can make sure the device is connecting on the right bearer, for example, 2G/3G/4G.

• Error code created on the network level

The cellular module can provide information regarding errors sent back from the network, but network-level error codes can be more useful.

If you reached this far with reading, you probably understand that there are many moving parts involved. The cause and the nature of issue depends on many things like deployed country, network (roaming vs. home), device, firmware, and numerous other uncontrollable parameters.

Sometimes, it can be tricky to figure out the exact cause. However, if you think two steps ahead and are ready to present the whole story (with ICCIDs, timestamps, etc.) to the operator, it will speed up the fixing process significantly.

We hope that the insight into the correct technical implementation of PDP context and the checklist of common issues can help you in troubleshooting. If nothing doesn't help make sure to contact 1oT through sales[at]1oT.mobi.