Have you ever struggled to connect a printer to a computer? If so, it shouldn’t be hard to recall the impatience and frustration that emerge from this connectivity issue. Now, transpose this struggle to when you have a multitude of IoT devices to install. All of the possible connectivity issues that can arise may certainly slow down deployment, negatively impact the user experience, and increase the number of customer complaints and merchandise returns.
Consequences of Cellular Connectivity Problems
If you’re lucky, you will notice the IoT device’s offline status during the installation. Most devices have status LEDs, a built-in display, a debug port, or connect over Bluetooth with a mobile app for diagnostic purposes, but it may take you a long time to work through all of the tools at your disposal to identify the cause of the problem, fix it, and finally connect the device successfully.
Loss of connection sometimes occurs days or months after installation, when you are no longer within range of the device. IoT devices are often installed in locations that are difficult to access, such as walls, underground, on vehicles, or in remote areas. A loss of cellular connection at this stage results in a break in service as well as delays and travel costs (often higher than the cost of the device itself). This could also result in battery drainage if the IoT devices are constantly sending attach requests to the network, resulting in additional maintenance visits to replace batteries prematurely.
1. UE SIM/eSIM authentication failure during field deployment
Problem:
Local carriers might reject attach requests from IoT devices in the field if their SIM/eSIM profiles are not configured as expected by the local carrier. This might happen when the Key or the IMEI is misconfigured or when the SIM and the network don’t support the same authentication algorithm. In these cases, the IoT devices would not be able to send or receive data even if they can detect the signal from nearby towers.
Roaming networks may issue different reject types (02 roaming not allowed) 03 Permanently forbidden Pico5G allows testing of all these to ensure robust handling by the modem/application.
Test:
The Pico5G supports Milenage, XOR, and TUAK authentication algorithms with physical testing SIM cards or pre-loaded eSIM with testing profiles.
Results:
If the authentication process on the IoT devices is correctly configured, the attach request will be accepted by Pico5G , and end-to-end connections will be established. The attach request message from the UE and its reception by the Pico5G will be displayed on the Pico5G GUI, in the log, or through the API. Otherwise, the attach request message from the UE and its rejection message by the Pico5G , as well as the reason for rejection, will be displayed on the Pico5G GUI, in the log, or through the API, so you can trace the cause of the problem.
2. IoT devices deployed on the cell edge
Problem:
IoT devices could be deployed in an area where the cellular service is sparse or too weak to establish a reliable connection. Construction, city obstructions, foliage, and snow in suburban or remote areas also affect radio waves. IoT devices are sometimes unable to complete the connection process or maintain the connection.
Test:
The Pico5G can simulate a poor cellular service scenario in which the downlink or uplink connection is unstable or disconnected. The coverage of the simulated network can be adjusted by controlling the RF transmitting power and receiving gains through the Pico5G command line interface (CLI) or API. The Pico5G can also simulate packet loss by randomly dropping some data packets directly at the PDN gateway.
Moreover, power saving features may cause the connection to be closed prematurely by the network, especially when the radio link is unstable. For PSM, the T3412 and T3324 timers are configurable. For eDRX, the cycle length duration and the paging window length are configurable. The number of retransmissions is also configurable. You can choose to ignore or accept UE’s requested PSM and eDRX parameters or force the network preset parameters.
Results:
You will be able to observe the device’s behaviour under those scenarios and develop your own power and data management strategy to address potential issues. The paging messages received by the Pico5G eNb show that the device is still connected or deliver idle messages when the connection is lost. These messages can be monitored with the command line interface (CLI) or API.
3. Datalink issues caused by APN misconfiguration
Problem:
An IoT device could have been preconfigured with an incorrect APN, which prevents the IoT device from sending or receiving any user data, even if the device has been attached to the network successfully. This can also happen during a firmware update.
Test:
The Pico5G can simulate a real network’s PDN gateway with different APN configurations in its EPC entity.
Results:
You can validate these configurations on your IoT devices before real-world deployment. You can establish an end-to-end data connection if the APNs are set correctly. Otherwise, you can see that the UE is registered without any data connection or IP address assigned.
4. Radio link issues on certain frequency bands
Problem:
From antennas with gains that vary according to the frequency, orientation, and reception circuits that are poorly shielded and subjected to all kinds of external interference to the interference generated by the circuit itself, there are many factors that negatively affect the quality of an IoT device’s radio link. The demand for low-cost IoT devices and the rise of pre-certified system-on-modules make IoT devices accessible to a broader range of designers, who are generally not RF experts.
Test:
Testing is the best way to find problems or confirm that the radio link is reliable despite less attention to RF design. The Pico5G operates on all LTE bands, which gives the IoT manufacturer the opportunity to test RF connectivity for all LTE bands required by cellular service providers and optimize their antenna and other RF-related design before field deployment.
Using the config file, up to 8 cells (4 intrabands, 2 bands) can be defined to operate simultaneously. The gain can be changed dynamically through the CLI or API to force the device to perform a handover in order to measure the radio link across multiple bands at once.
Results:
There are multiple ways to detect connectivity issues caused by radio link quality issues, such as registering the minimum cell gain required for establishing and maintaining a connection for each band. It is also common practice to rotate the device while performing this test.
In short, connectivity issues affecting thousands of devices are a nightmare for any IoT solution provider. Companies must invest massively in testing, self-diagnosis, and failover mechanisms to make sure that their profit margin isn’t eaten up by solving connectivity issues in the field. This is why the Pico5G has been designed.
