Connectivity resilience

Why does mobile data fail in crowds?

Mobile data fails in crowds because every phone in a cell shares that cell's radio resources, which the base station's scheduler divides between them, and every phone also has to win access to the network before it can send at all. When a crowd gathers in a few cells, each phone gets a smaller share, the access channel can be overloaded, and the operator may restrict access to protect the network, so the signal looks strong while data barely moves.

Learning objectives

After reading this article you will be able to:

  • Explain how a cell's scheduler divides radio resources among phones in a crowd
  • Describe how access class barring protects an overloaded access channel
  • List what operators and apps can do when a crowd overloads mobile data

A cell is shared

A mobile network covers an area with cells, and each phone talks to the base station serving its cell. Everything that phone sends or receives over the air uses that cell’s radio resources, and so does everything every other phone in the cell sends or receives.

The 5G specification describes how that sharing works. In 3GPP TS 38.300, the base station includes dynamic resource schedulers that allocate physical layer resources for the downlink and the uplink. The schedulers assign resources between the devices, taking into account how much data each one has waiting, its quality of service requirements and its radio conditions. What gets assigned is a set of resource blocks.

That works well when people are spread across many cells. When a crowd packs into a stadium or square, those phones share the same few cells. The scheduler still divides the same resources; each phone’s share simply gets smaller.

Three places a crowd causes trouble

The radio link. With more active phones in a cell, each gets fewer resource blocks or waits longer for them. Pages and uploads slow down, and apps start to time out.

Getting on the network at all. An idle phone has to make an access attempt before it can send. 3GPP’s service accessibility specification, TS 22.011, recognises that this step can be overwhelmed. It lets operators broadcast, cell by cell, which classes of subscribers are barred from access, so they can prevent overload of the access channel under critical conditions; the specification says this is not intended for normal operation. Every phone belongs to one of ten randomly allocated access classes, numbered 0 to 9, and special classes 11 to 15 cover groups such as emergency services and network staff. Another mechanism, extended access barring, lets operators restrict access from devices configured as more tolerant of access restrictions while still admitting others “in congestion situations”.

Behind the cell. The traffic still has to leave the cell site and cross the operator’s network. If that link or the core is overloaded, the result is ordinary network congestion: queues fill, packets are dropped, and retries add more load.

The effect, from the user’s side, is the familiar one: the phone shows a strong signal, but messages sit unsent and pages do not load.

What operators do about it

Operators have a few tools.

  • More capacity on the day. Operators can bring temporary cell sites to a location. FirstNet, the US public safety network, lists deployables including Cells on Wheels (COWs), SatCOLTs and Compact Rapid Deployables, intended for critical coverage during disasters, large-scale events and emergencies.
  • Access control. As above, the network can bar classes of devices from access attempts for a period, to prevent overload of the access channel.
  • Priority for responders. In the United States, CISA runs the Wireless Priority Service, which gives authorised devices priority calling on cellular networks, and GETS, which gives priority access on landline networks. CISA says WPS calls do not preempt calls in progress or deny the general public use of the network.

Access barring and priority services decide who gets the capacity that exists; they do not create more of it for everyone else.

What an app can do in a crowd

If an app is meant for a stadium, a festival, a march or an evacuation, design it to work with little or no mobile data.

  • Send less. Small messages and compact records need fewer radio resources than large uploads.
  • Back off. Retrying in a tight loop adds load to a network that is already full. Use exponential backoff with limits, and queue work on the device instead of failing it.
  • Keep local work local. Scanning a ticket, checking a wristband or passing a message to someone a few metres away does not need the mobile network. Phones can exchange data directly over Bluetooth LE without any cell, and the Offline Protocol SDK, for example, carries that local peer-to-peer traffic between nearby phones without a tower. How are tickets checked at a gate with no internet? walks through one case.
  • Sync later. Hold records until the crowd thins or the device reaches Wi-Fi, then reconcile with the backend.

Frequently asked questions

Why do I have full bars but no data at a concert?

Signal strength and capacity are different things. In a crowd the limit can be capacity and access rather than signal, because the cell's radio resources are shared with everyone else nearby and the access channel is handling their attempts to connect too.

Do emergency responders get priority?

In the United States, authorised users can subscribe to CISA's Wireless Priority Service, which gives priority calling on cellular networks, and GETS, which does the same on landline networks. CISA says these calls do not preempt calls in progress.

Sources

Build it with Offline Protocol

The quickstart runs two physical phones that exchange an encrypted message over Bluetooth LE, with no account, API key or internet relay, which is the basic local path for nearby devices.

Read the quickstart