5 ways to detect connection errors and how to resolve them

30.09.2021
guide-image

Cellular communication is the most stable wide-area wireless technology available today. The technology uses reserved frequency bands and commercial, well-maintained infrastructure. Having said that, there are several scenarios where your devices can experience connectivity issues. For example: 

  • The wireless module does not support the parameters of a specific network.
  • The sequence of AT-commands is not optimal to establish a data connection under varying radio conditions.
  • A mobile network whose signal is the strongest has issues such as uplink interference or core network outages.

 

Instead of relying on only one network in a country, EMnify global IoT SIM cards always use multiple networks, increasing the connectivity availability. Nevertheless, as outlined above there are still reasons for why devices may not be able to send data. In this post, you will learn about five functionalities that will help you detect and solve connectivity issues in real-time:

  1. Detect Issues: Event Alerts 
  2. Detect Issues: Data volumes and device status
  3. Understand Issues: Network Events 
  4. Resolve Issues: Network Reset
  5. Resolve Issues: Network Blacklisting

Event alerts

Log in to the EMnify Portal and check the Dashboard. Click on the tab EVENTS. 
You will see all the network events related to your SIM cards and organization. By clicking on the severity, you can filter for all warning and critical events that have an impact on the connectivity. 

You can then proactively see which devices have identifiable connectivity issues. When clicking on the event, you will find a description that specifies the typical root cause of the issue and how it can be solved. 

Real-time data volumes and device status

In case you have a specific device that is troublesome you can log in to the EMnify Portal and go to Connected Devices, then search for your device via ICCID, IMEI, or Name and click on detail.

The device status shows a simple categorization of the current connectivity state. 

Blocked: The device has been blocked due to device policies (e.g. that the volume limit is reached). You can unblock the device by changing the policies.

Attached: The device has done a registration and location update with the network in the past. It can send and receive SMS in this state, but cannot establish a data session. This could be due to the wrong APN setting or roaming misconfiguration. Note that the device stays in Attached status even if it is powered off because the device does not notify the home network when turning off.
Online: The device currently has a data session  
Offline: The device is no longer attached to a network and has not been trying to connect to a network for 24-48 hours. 

The next thing you can check is data statistics on device details. For example, if your sensor sends data every 15 mins you will be able to see when it sends the data for the last time. 

Understand issues with network events

A device will always use the same event sequence to establish a data connection - in the following order:
  1. Update location - meaning that the device has registered and/or updated its location on the signaling network.
  2. Update GPRS location - meaning that the device has registered and/or updated its location on the data network.
  3. Create PDP context - meaning the device has established a data session.
  4. Delete PDP context - meaning the device has disconnected the data session.

Update location and update GRPS location can also happen multiple times before a data session / PDP context is created. When any of these events is rejected, this indicates a connectivity problem that can either fix itself or in some cases, needs intervention. You can filter for warning and critical events and see how to resolve the problem in the event description by clicking on the event. 


Ensure that the events are happening in the frequency that you expect them to happen. For example, if your device firmware is configured to register and send data over a network every hour, you can check the actual behavior in the events. 

Other problems that do not have a root cause in the network but in the device can also be diagnosed by looking at the events and their timestamps. Let's take a look at the following scenarios.

Scenario 1: Many location updates in a short timeframe without PDP context creation
This indicates that the device commands to register to a network (AT+COPS) are executed too frequently. The registration procedure can take anything from seconds to a couple of minutes and during that time no re-registration request should be done.

Scenario 2: Normal location and GPRS location updates but no PDP context creation
Change the APN setting to "em" or "emnify".

Scenario 3: PDP context created and deleted but no data transmitted:
You can check the volume sent over the data session in the PDP deletion event. For NB-IoT and LTE-M devices this behavior can happen when the device automatically connects to any network - rather specify the network to be used with the `AT+COPS` command in the device. Verify that the network is on EMnify's NB-IoT or LTE-M coverage map. 
This can also indicate some errors in the command to establish the PDP, e.g. AT+QIACT (a Quectel specific command) instead of using AT+CGACT. 

Resolve issues: Network reset

There are many reasons why connection issues arise. For example:

  1. The device executes the wrong procedures due to a bad firmware update.
  2. The device executes network registration too frequently that the network no longer allows it to register.
  3. You have simply changed a policy due to a blocked device. 
In these cases, you can do a network reset - which basically deletes the state information the network has about the device. This allows the device to re-attach and try a fresh start - similar to a reset on your hardware. 

To do a network reset, you need to go to Connected Devices, then search for the device and click on the network reset button.  

You can also reset the connectivity on multiple devices simultaneously. To do so, select devices on the Connected Devices overview page, and click on RESET in the top action bar:

Resolve issues: Network blacklisting

There are several reasons why devices may not be able to register or establish a data session over a specific network:

  1. The module firmware does not support specific network parameters.
  2. The network or base station of a specific operator has been upgraded and is faulty, meaning devices are allowed to attach but can not establish a data connection. 
  3. Devices can attach to the network because of good downlink quality, but the uplink quality is too poor to send data.

In these cases, it is possible to block the problematic mobile network so devices can no longer register with this network. The device will then automatically use a different network, which can resolve the connectivity issue. 
To blacklist a network for a specific device you can go within the EMnify Portal to Connected Devices, then search for the device (ICCID, IMEI, etc.). Next, go to Details and add an operator to the Operator Blacklist.
snip_blacklist

Alternatively, you can block a network on multiple devices using the bulk action on the EMnify Portal. To do so, select devices on the Connected Devices overview page and find the Blacklist Operators option in the top action bar:

bulk-network-blacklist

Summary

While cellular connectivity is the most stable and secure wireless technology available, with thousands of devices in the field, you need to be able to detect and fix even very infrequent issues. We presented five mechanisms that will help you to recover devices from connectivity issues. 
Image of Christian Henke

Christian Henke

If you want to understand how emnify customers are using the platform Christian has the insights. With a clear vision to build the most reliable and secure cellular network that can be controlled by IoT businesses Christian is leading the emnify product network team.

Related Posts

Image for post DNS Filtering with EMnify Cloud Connect and AWS Route53

DNS Filtering with EMnify Cloud Connect and AWS Route53

20.08.2021 –

IoT devices come in various shapes and sizes. And with that, security can vary from device to device depending on the platform, components, OS, firmware and application. In this post, I will use a mobile phone (Android/ iOS) as a payment terminal and outline how you can use DNS filtering to restrict internet access on all such devices in a centralized way.
Image for post LwM2M vs MQTT: Which one is the best for IoT Solutions?

LwM2M vs MQTT: Which one is the best for IoT Solutions?

13.12.2021 –

While building IoT solutions, keeping the footprint small is of utmost importance. This requirement influences all design aspects of IoT solutions, including communication. Transferring data from your IoT devices to your application servers efficiently is important, but at the same time, you also need to have a lightweight way of doing so. In this post, I will compare MQTT and LwM2M communication protocols for IoT solutions. What are Communication Protocols? Simply put, communication protocols are rules that define how two connected systems communicate with each other. These protocols cover everything from authentication, signalling, security, data transfer, flow control to error detection and handling. The Internet of Things drives innovation in these protocols to make them more efficient and secure among other things. What is MQTT? MQTT stands for MQ Telemetry Transport where the MQ part comes from an IBM product called the MQ Series. MQTT is a protocol that was specifically built for M2M and IoT message transfer by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom). The protocol helps transfer messages using the publish and subscribe model which enables it to send messages to one or multiple subscribers. What is LwM2M? LwM2M stands for Light Weight M2M. It is a protocol designed by OMA SpecWork’s for device management but is also suitable for data transfer with the objective of attaining reduced power and data consumption. It is built on top of CoAP (Constrained Application Protocol) which increases its bandwidth efficiency. LwM2M has a transport agnostic design which by default uses UDP, but also supports TCP and SMS. Architecture MQTT As mentioned, MQTT has a publisher and subscriber model. There is no direct connection between the sender of the message and the receiver. There are 2 basic components in this architecture. Client Broker Clients can publish messages on topics to the broker. The broker then dispatches these messages to any clients that subscribe to that topic. Thus the broker decouples the publisher and the subscriber. MQTT brokers do not normally store messages, but do offer buffering of messages in some cases. MQTT uses TCP/IP to connect to the broker. The broker authenticates and authorizes the clients and maintains the session data of all active clients. The broker is responsible for receiving all messages, filtering the messages, determining who is subscribed to each message, and sending the message to these subscribed clients. LwM2M In an attempt to standardize device management and telemetry, LwM2M supports device management functions, in addition to data reporting (as MQTT does). Bootstrapping Device Configuration Firmware Update Fault Management Configuration & Control Reporting For all the above functions there are procedures defined, e.g. how the device registers at the server, or how the server initiates a client diagnosis. The common structure under all the above functions is a client - server model. The client initiates the connection with the server. The server then uses REST APIs to perform either of the above functions. Implementation MQTT An MQTT client can be any device that runs the MQTT library and connects to the MQTT broker and can have a very small footprint depending on the library used. An MQTT client usually sends data to the server, such as telemetry data. It contains scripts to publish messages to a topic. There are several MQTT client libraries available depending on your preferred programming language. An MQTT broker is the heart of this protocol and can handle millions of MQTT clients depending on the implementation. An MQTT broker needs to be highly scalable, integrated into your backend systems, and failure-resistant. The broker needs to receive, filter and forward all messages to the clients that subscribe to them. As mentioned earlier, it needs to maintain the data-sessions of all the clients connected to it. There are several implementations of the MQTT broker available as open-source or paid. LwM2M Depending on the function that you are using it for, there can be several implementations of the LwM2M client and server. The LwM2M client initiates a connection with the server. LwM2M uses a simple resource model with the core set of objects and resources defined in the specification. As an example, the device here is an object, with id 3 and the device has resources like firmware version, serial number, etc. which have a fix resource id. So to get information about a particular resource of the object device, the server can send a call like READ 3/3/0. The LwM2M client implementation contains code to initiate the connection with the server with credentials, sending the necessary data requested by the server, callback functions for LwM2M resource executions and send error events. It can also contain other functions depending on the use-case. The LwM2M server on the other hand needs to authenticate LwM2M clients, send correct requests using the REST API and process the requested information. There are several open-source as well as paid implementations available for the LwM2M client as well as server. LwM2M also has a Developer Toolkit which can be used to implement your own versions. Security MQTT MQTT supports various authentications and data security mechanisms. These mechanisms are configured on the broker and the client needs to comply with these mechanisms. MQTT uses TCP/IP and you can also leverage Transport Layer Security (TLS) to use secure the connection. LwM2M LwM2M also supports authentication and data transport security mechanisms. LwM2M uses CoAP which usually uses UDP as the transport protocol. When using UDP, LwM2M supports DTLS. CoAP also supports TCP and TLS accordingly. Use Cases MQTT MQTT is used for sending payload for low-power and constrained applications, thus making it a favorite choice for many IoT applications. MQTT brokers are a big component of Cloud based IoT solutions. Logistics - for connectivity and real-time monitoring of vehicles Manufacturing - For monitoring of manufacturing plants Smart Home - For energy monitoring, home security, home patient monitoring Oil and Gas - The use-case it was first built for, to monitor the oil pipelines Consumer products - Like smart appliances Urban Mobility - For city transportation systems, car sharing etc. LwM2M While LwM2M also supports sending telemetry data, it was built to standardize device management and provisioning, thus making it ideal for the 6 functions that it defines in its implementation. Bootstrapping - Enables headless device management, thus enabling shipping the devices without configuring them in the factory. Device Configuration - Enables device life cycle functionalities like enable, disable and update. Firmware Update - Enables FOTA/ SOTA for devices. Fault Management - Enables monitoring of statuses like battery level, memory, sw/hw version etc. Configuration & Control - Enables setting of APN and other functionalities for cellular connectivity, as well as activating, rebooting and disabling the device. Reporting - Enables error reporting from the devices Conclusion While deciding the right protocol for sending essential data from your connected devices to your application, the question is not whether you use MQTT or LwM2M. From the above description, you can see that both protocols were designed for different and specific purposes. So if your application needs a higher payload of data to be sent, you might choose MQTT and will have to implement functionalities like device provisioning, OTA on top of it. On the other hand, if the application needs to monitor critical statuses on the device, as well as needs the convenience of lightweight device management, you might want to choose LwM2M. Platforms like AWS IoT, Azure IoT Hub have an inbuilt version of the MQTT broker which you can use to send payload through your device. You then only have to configure the MQTT client on the device. The device management in AWS IoT and Azure IoT hub is then done through device shadow and device twins respectively. If you are hosting and managing your own cloud applications, you can use LwM2M for device management and build your own MQTT broker for messaging. There can also be use-cases where you might need to use a combination of both. In any case, it is important to understand that MQTT and LwM2M protocols are not replacements of one another but built for distinct use-cases. Stay glued to this space to see a comparison between MQTT and CoAP next. And if you wish to know more about protocols and IoT check out our Comprehensive Guide to IoT Protocols. Until then, Stay Connected!
Image for post How EMnify contributes to AWS Certification development

How EMnify contributes to AWS Certification development

25.08.2021 –

As EMnify operates all its systems on AWS, many of our colleagues hold one or more AWS certifications. Becoming certified not only proves a certain level of knowledge, but also helps the individual to focus their learnings on our cloud platform of choice – as there is a lot to learn when it comes to AWS.