Earthquake aftershocks, financial shocks and a phone trying to connect share an unexpected mathematical link. IIT Madras researchers are using it to understand how 5G networks can become burdened by their own unfinished work.

An earthquake can trigger aftershocks. A sharp fall in share prices can be followed by further waves of market activity. A phone trying to join a 5G network seems to belong in a different story altogether.

Yet here, too, one event can lead to more. A connection attempt that goes unfinished may be followed by another attempt. If the network is already struggling, that extra work can deepen the delay and invite still more retries. The effort to recover begins to feed the problem.

Mathematicians call this kind of behaviour self-excitation. A family of models known as Hawkes processes describes how earlier events can increase the likelihood of further events. Earlier study patterns such as earthquake aftershocks and clustered financial events, the same mathematical idea offers a way to examine what happens when a mobile network starts generating extra work through retries.

At IIT Madras, PhD Scholar Sooraj Subramanian M. S. and Professor Krishna M. Sivalingam have investigated that hidden workload inside the 5G Core. Their question sounds simple: when connection attempts multiply, are more people trying to get online, or are earlier requests coming back because they have not been completed?

Beyond the tower

The tower is the part of a mobile network we can see. It is also only part of the story. A radio base station connects nearby devices to the network over the air. Together, these base stations and their associated equipment form the Radio Access Network, or RAN.

Behind that radio connection sits the 5G Core. Its software services check a subscriber’s identity, manage connections and arrange the paths along which data will travel. While a base station serves a local radio coverage area, core services can be shared by users arriving through many base stations. Trouble in a shared core function can therefore reach far beyond a single tower’s coverage.

Before a phone can use a data connection, the network has some arrangements to make. It must recognise the device and establish its registration, then set up a data session. This coordination belongs to the control plane. The actual data, such as the contents of a webpage or video, travels through the user plane.

From the phone’s side, getting connected looks like one task. Inside the Core, it is a succession of exchanges among cooperating software components. A request can make progress in one component while waiting for another. That is where the apparent simplicity of “try again” starts to unravel.

The cost of trying again

Networks need retries. A message can be lost or an operation can stall, and a timer allows another attempt rather than an indefinite wait. But a missing response does not always mean that the earlier work has disappeared. It may still be waiting or running somewhere inside the system.

In that case, the retry can arrive on top of the unfinished work. More work can mean longer waits; longer waits can provoke further retries. Even a steady stream of new requests can become a growing burden inside the Core.

Think of the sudden squeal when a microphone picks up its own loudspeaker. The sound is fed back, amplified and picked up again. No one else has started speaking; the equipment is recirculating its own output. The analogy is feedback, not the audible echo sometimes heard on a phone call. In this study, what returns is a signalling request, not someone’s voice.

For a network operator, the distinction matters. A surge of fresh demand and a surge of repeated attempts can both make a network look busy. Measurements of delay and successful connections reveal the strain, but cannot, on their own, explain how much of the workload is returning from earlier unfinished attempts.

To tell those stories apart, the researchers had to follow the requests.

They developed a method called protocol-causal transaction reconstruction. It brings together records of messages exchanged across different parts of the network and links them into the history of an individual attempt: where it began, which exchanges belonged to it, and whether it completed or remained unresolved. Where the evidence permits, a later retry is also linked to the earlier incomplete work.

The method covers both Registration, through which a device becomes known to the network, and PDU Session Establishment, which sets up its data connectivity. Instead of a single count of messages, the researchers can examine individual attempts and the relationships between them.

This is where the Hawkes model enters. Applied to the reconstructed Registration attempts, it helps quantify two sources of activity: fresh requests arriving from outside the system, and the additional activity associated with earlier attempts. The reconstruction supplies the evidence linking events; the model describes the strength of the self-exciting pattern.

The team studied three open-source 5G Core implementations: Open5GS, OAI 5G CN and free5GC. Their experiments showed that controlling the rate of new device requests did not necessarily control the rate of attempts inside the Core. As unfinished work accumulated, retries could push internal activity above the incoming demand.

The systems did not struggle in identical ways. In the tested configurations, the onset of retry amplification and the patterns of waiting and incomplete work differed. Registration gave the clearest view of the feedback. Difficulties in setting up data sessions showed how the strain affected the work that followed.

Knowing what to watch

Following every request in this much detail is valuable for an investigation. Doing so continuously is a heavier commitment. An operator also needs a practical way to recognise the problem while the network is running.

That detailed view can then be used to work out what a live monitor needs to watch. The team checked a smaller set of signals — rates of requests and completions, delays, accumulating work and waiting within the software — against the reconstructed transactions. These signals offer a less demanding way to recognise the same retry-amplified strain, without following every message continuously.

Professor Mythili Vutukuru of IIT Bombay highlighted this connection between detailed offline analysis and lightweight online monitoring in her assessment of the work. “This paper solves a real problem that 5G core operators face today using clever ideas, and backs up the modeling exercise with evaluation using open-source 5G core frameworks.”

The work is a diagnostic tool, not a cure for every slow connection. It makes visible a distinction that matters for any response: extra demand from new users and extra work from repeated attempts are not the same problem.

For the person holding the phone, a busy network is useful only if it gets them connected. Following the requests helps explain why those two things — more activity and more people connected — can come apart.

Article by Akshay Anantharaman
Click here for the original link to the paper