Fifty Terabytes Per Stadium: The Uplink Problem Nobody Designs For

Here is a number that reframes what a stadium is: spectators were expected to use over 50 terabytes of data inside a single stadium during one match.

Not the broadcast feed. Not the operations network. Fans, on their phones, in the seats.

Getting that to work required Verizon — the tournament’s official telecommunications sponsor — to add spectrum boosting capacity by an estimated three to five times across host stadiums, install thousands of antennas under the seats, mount large spherical antennas aimed at the upper tiers, and deploy nearly 140 small cells and temporary sites to cover transit and community areas outside the venue. AT&T made more than 2,000 network upgrades across the 11 US host cities, extending to airports, team camps and fan festivals. T-Mobile leaned on AI-driven network optimisation and real-time monitoring around the same footprint.

The engineering here is worth understanding even if you never build a network, because the failure modes in a dense venue are the failure modes in any system where demand is spatially concentrated and synchronised — and the intuition most engineers carry into it is backwards.

Dense venues break the usual assumptions#

A normal cell site serves a wide area with users spread across it. Capacity planning is about coverage and average demand. Stadiums invert every part of that.

Density, not distance. Seventy thousand devices in a bowl a few hundred metres across. Coverage is trivial; the problem is that every device is contending for the same air. Adding transmit power makes this worse, not better, because power that reaches further creates interference with the neighbouring sector. The correct answer is the opposite of intuition: smaller cells, more of them, deliberately constrained. Hence antennas under the seats, radiating a few rows each. You are not trying to cover the stadium. You are trying to slice it into hundreds of small, quiet cells.

Synchronisation. Demand is not just high, it is correlated. Nobody uploads during play. Everyone uploads in the ninety seconds after a goal. Your peak is not a busy hour, it is a burst measured in tens of seconds, triggered by an event you cannot schedule.

The traffic is upstream. This is the part that catches teams out. Consumer network planning has assumed a download-heavy asymmetry for thirty years, and spectrum allocations, TDD frame configurations and backhaul designs all encode that assumption. A stadium full of people livestreaming, video-calling and uploading to social feeds inverts it. The scarce resource is uplink, and uplink is harder — phones have small antennas and limited power budgets, so they cannot simply shout louder.

This is why Verizon’s uplink and latency performance was singled out in independent measurement of the host cities while other carriers led on raw download speed. Download speed is the number in the marketing. Uplink is the number that decides whether the video call from row 214 connects.

The pattern generalises to anything with an edge site#

You may never provision spectrum. You will absolutely build systems with the same shape, and the same three mistakes recur.

Mistake one: planning from averages. “We have 70,000 users and 10 Gbps, that is 143 kbps each” is a calculation that describes a state the system is never in. The relevant figure is the burst: what fraction of users transmit simultaneously in the worst ten seconds, and what does each of them send? Averages hide correlated demand, and correlated demand is the only kind that breaks things.

Mistake two: designing for the download. Applications that work beautifully in testing collapse in the field because testing happened on a symmetric office connection. If your field application uploads photos, syncs video, or pushes large diagnostic payloads, it is uplink-bound, and every consumer network it runs on is optimised against you. Test on a constrained uplink deliberately. We set a 1 Mbps up / 20 Mbps down shaper on staging for any client with field devices, and it finds problems no amount of load testing in a data centre will.

Mistake three: no graceful degradation. The network will saturate at the peak. The question is what your application does about it. An app that queues, batches, and retries with jitter survives. An app that retries immediately and aggressively turns a congestion event into a self-sustaining outage — every client hammering a saturated link keeps it saturated. Exponential backoff with jitter is not a nicety; at scale it is the difference between recovery and collapse.

Where we hit this in client work#

Hospital Management System, in the building. Ward tablets, bedside carts, imaging transfers, and now increasingly video consults all share the same in-building distributed antenna system and Wi-Fi. Radiology pushing a study is a large uplink event, and it competes with clinical documentation. Hospitals also have the worst possible RF environment — dense construction, shielded rooms, metal everywhere. The stadium answer applies exactly: many small cells, deliberately constrained, rather than a few powerful access points.

School ERP, on results day. A thousand parents in the same catchment refreshing the same page over the same handful of cell sites is a dense-venue traffic pattern that happens to be spread across a suburb. Payload discipline matters more than server capacity here: a portal page that ships 4 MB of JavaScript is a network problem before it is ever a server problem. The fastest fix we have deployed for results-day complaints was not scaling the backend — it was cutting the page weight by an order of magnitude and serving it from an edge cache.

Field operations anywhere rural. Uplink-bound, intermittent, and unforgiving of applications that assume connectivity. Design for store-and-forward from the start; retrofitting offline support into an online-first application is one of the most expensive rewrites in our catalogue.

The checklist#

Before your next high-density or field deployment:

1. What is the burst concurrency in the worst ten seconds, not the average over an hour?
2. What is the uplink requirement per client, and have you tested against a realistic uplink cap?
3. What happens on saturation — does the client back off with jitter, or amplify?
4. Can the client function degraded, queueing work locally, or does it simply fail?
5. Is the payload as small as it can be? Every kilobyte you do not send is capacity you do not have to buy.

Fifty terabytes per stadium, per match, is what happens when you get all five right. The alternative is a network that works perfectly in the empty stadium during commissioning and dies at kickoff.

---

Capacity plans built from averages fail at exactly the moment anyone is watching. We size systems from bursts and rehearse the peak. Tell us about your worst ten seconds.