How to use Signaling Logs | Onomondo Help Center

What are Signaling Logs?

Whenever your device attaches to a local network using an Onomondo SIM, the connection goes through multiple components of the local network and the Onomondo core network. Signaling Logs give you an instant overview of the packets sent between local RANs (Radio Access Networks) and the Onomondo Core.

The key thing that makes Signaling Logs valuable is visibility into a layer that is normally a "black box". When a device fails to connect or get data through, standard tools only tell you so much. With Onomondo, you can see the signaling information directly in the app, in real time, no matter where in the world the device is. The logs are also stored for historical review, 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 network authentication and registration events, Signaling Logs provide more information and detail.

What kind of information can I see?

In telecom, there are multiple different protocols used in signaling. Each of them corresponds to different cellular technologies and different parts of the connection. These are DIAMETER, GSM Map, GTP, and GTPv2.

Protocol	Technology	Connection Sequence
GSM MAP	GSM, 2G, 3G	Authentication / registration
DIAMETER	LTE, LTE-M, NB-IoT	Authentication / registration
GTP	2G, 3G	Data traffic
GTPv2	LTE, LTE-M, NB-IoT	Data traffic

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 types of messages

Here is an overview of the typical messages you would see in Signaling Logs and an explanation of how they relate to the connection sequence.

Message	Protocol	Definition
Authentication
invoke SendAuthenticationInfo, or Authentication Information Request / Answer	GSM MAP DIAMETER	The visited network asks Onomondo's Home Subscriber Server (HSS) for the cryptographic vectors needed to authenticate the SIM.
Registration / Location Update
invoke updateLocation, invoke updateGprsLocation, or Update Location Request / Answer	GSM MAP DIAMETER	The visited network's core (MSC/VLR or SGSN/MME) notifies Onomondo's HSS that the device has registered in a new location and requests the subscriber profile.
invoke insertSubscriberData	GSM MAP	Onomondo's HSS delivers the subscriber's service profile (APN, QoS, allowed services) to the visited network in response to a successful location update.
invoke cancelLocation, or Cancel Location Request / Answer	GSM MAP DIAMETER	Onomondo's HSS instructs the previously registered network to remove the device's registration record, typically because the device has moved to a new network.
Notify Request / Answer	DIAMETER	The visited Mobile Management Entity (MME) informs Onomondo's HSS of a change in the device's status — such as UE reachability or the assigned serving node — without triggering a full location update.
Data Session Lifecycle
Create PDP Context, or Create Session Request	GTP GTPv2	The visited network's gateway requests Onomondo's packet gateway (PGW) to open a data tunnel (bearer) so the device can send and receive IP traffic.
Delete PDP Context, or Delete Session Request	GTP GTPv2	Either network signals that the data session should be torn down, releasing the IP address and closing the tunnel between the two gateways.
Modify Bearer Request / Answer, or Update Bearer Command	GTPv2	The visited gateway notifies Onomondo's PGW of a change to an existing bearer — such as a handover to a new base station or a QoS parameter update — without restarting the session.
Deregistration / Clean-up
invoke PurgeMS, or Purge UE Request / Answer	GSM MAP DIAMETER	The visited network informs Onomondo's HSS that the device has been inactive long enough that its local registration record has been deleted, prompting the HSS to clean up its own state.

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. For example, if the device is designed to go online only periodically and send data in short bursts, the frequency of these events may be high, while the gap between each Create / Delete Session Request may be short. On the contrary, if the device is static and meant to stay online at all times, you may see very infrequent Create / Delete Session Request pairs, and the gap between them can last multiple days.

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].