How to use Signaling Logs? | Onomondo Help Center

What are Signaling Logs?

There is a lot of ongoing signaling between the RAN and Onomondo when a device connects to a network. The signaling logs allow you to see all of that communication in real time. Normally, you would not be able to see this information unless you request it directly from an operator. Thanks to Onomondo, you are able to see the signaling information directly in the app, no matter where in the world the device is. The logs are also stored historically, so you can dive into them anytime.

You can think of Signaling Logs as a level deeper than Network Logs. While the latter offers a simplified overview of all events related to network authentications and registrations, Signaling Logs provide more information and detail.

What kind of information can I see?

Onomondo captures packets from various signaling protocols, each of them corresponding to different cellular technologies. These are Diameter, GSM Map, GTP, and GTPv2.

Protocol	Technology	Connection Sequence
GSM MAP	GSM, 2G, 3G	Authentication
DIAMETER	LTE, LTE-M, NB-IoT	Authentication
GTP	2G, 3G	Registration
GTPv2	LTE, LTE-M, NB-IoT	Registration

The communication takes place between different components of the network (HSS, HLR, VLR, SGSN, etc.). Interpreting the information displayed in Signaling Logs requires some knowledge of telecommunication and networking. You can only see a short description of each log item in the Onomondo app. In order to dig deeper, it is advised to download the logs as a PCAP file and open them in a network protocol analyzer, e.g., Wireshark.

Common events, patterns and issues

Although it is difficult to boil down all combinations of events you may encounter in Signaling Logs, there are some frequent occurrences that are worth being aware of before diving deeper into debugging.

Data session loops

When you see a loop of:

Create Session Request / Create Session Response
Delete Session Request / Delete Session Response

or

Create PDP Context Request / Create PDP Context Response
Delete PDP Context Request / Delete PDP Context Response

it means that the device is continuously opening and closing data sessions (or tunnels) on the network.

These loops indicate normal behaviour, although the length and frequency of these events is highly dependent on the firmware logic on the module and local network behavior.

Network authentication loops

When a device wants to join a network, it will be asked by the RAN to identify itself through an authentication request, which you will see in the logs as invoke sendAuthenticationInfo. The request will include an authentication challenge sent to your device. The device will then use secret keys stored on the SIM to prove its identity and send a response. Once delivered (returnResultLast), the device is granted permission to register the network.

In most cases, the above sequence should lead to a network registration (updateLocation and insertSubscriberData in signaling). However, in some cases, it may lead the RAN to send the same authentication request again, and the sequence goes on a loop. If this process repeats itself multiple times, it can be classified as a so-called "authentication loop". This successfully prevents the device from joining the network.

When using AT Commands on the device and checking for registration status, this would lead to a response of +CREG / +CGREG / +CEREG: 2 (i.e. the device is not registered, but UE is currently trying to attach or searching an operator to register to).

Signaling authentication loops like this indicate that either:

The device is in a bad state and should be reset.
The local network is rejecting the device (e.g. for load balancing, or due to a lack of available cells) and the problem might resolve itself with time.
The network already has subscription information from the last time the device has registered on it. Therefore, the network does not need to send a new updateLocation request to inform the device that it's registered. Solving this problem might require you to quickly deactivate and reactivate the SIM in the Onomondo app. Effectively, the RAN will have to erase subscriber information from its memory and this should allow the device to establish a new registration.

If you do need to deactivate and reactivate the SIM, do so at your own risk and in quick succession (max. few seconds). This should be sufficient to send a cancelLocation request to the RAN, while making sure that the device does not write local networks onto the FPLMN list on the SIM while attempting to reconnect.

Modify Bearer Request loops

Simply put, Modify Bearer Request event occurs when the local operator updates Onomondo on something related to an ongoing data session (e.g. cell tower switching). It is not out of the ordinary for signaling to include Modify Bearer notifications and suggests normal behavior.

PurgeUE / PurgeMS requests

A Purge Request is normally sent by the RAN when a device becomes inactive for a longer period of time and stops attempting to come online.

Unexpected Purge requests

While the above occurrence is a standard part of signaling, sometimes the request will be sent almost immediately after the last data session has closed.

An unexpected Purge Request is commonly caused by:

Sub-optimal device firmware configuration (e.g., short timeouts, or triggering attach on CREG instead of CEREG / CGREG for data connections).
The device is not handling DNS on a specific network. This is a device-specific error which happens before any data is sent.
The network actively closing the connection.

If there has been data transferred in the last sessions, you will need to use Traffic Monitor to capture a packet trace next time the device comes online to know why you are not receiving it.

Frequent Purge requests

If you notice that your device displays a loop of authentication requests, but no data sessions are opened and instead the RAN sends the Purge requests to the device - it may suggest that the APN on the device has been set incorrectly and/or data roaming is disabled.

Make sure that the APN is set to: onomondo and that data roaming has been enabled.

returnError

Sometimes, a request sent by the RAN can result in an error. When you see a returnError event in Signaling Logs, you will need to export them as a PCAP file and open the logs (e.g. in Wireshark) to view the error code and identify possible root causes.

Here is an overview of most frequent errors and potential solutions:

Error	Interpretation	Suggested solution
operatorDeterminedBarring / roamingNotAllowed	The RAN rejects the connection because the network is stored on the SIM's forbidden list (FPLMN).	The FPLMN list needs to be cleared. Here is a FPLMN clearing guide.
absentSubscriber	The SMS cannot be delivered to the device, as it is currently offline.	Make sure that your device is correctly registered on GSM. You can check this with the `AT+CREG?` command.
unknownSubscriber / unknown IMSI	The protection has kicked in or the IMSI is actively being blocked.	Perform a manual network scan using `AT+COPS=?` command and check if other networks are available.
systemFailure / L_cancel	Generic error that indicates network or device issues. Most likely, it is related to SMS, like `absentSubscriber`.	Make sure that your device is correctly registered on GSM. You can check this with the `AT+CREG?` command.

If you have any more questions or problems with interpreting Signaling Logs, you are welcome to reach out to us at [email protected].