It is almost 2 years to the week that we took our game changing approach to assured 5G for events to the road with DSIT funding. With the funding months late and all the kit delivered it was tempting to throw all the toys at it and test. But we had a job to do and so despite huge protest, we pushed ahead with just one CPE, one type of Radio, on one Private 5G core. It was the simplest to deploy, easiest to use and most reliable combination we had tested so far, and it just worked. Along with a lot of planning... https://www.linkedin.com/posts/christianborrman_future-smallcells-powercut-activity-7463899392945872896–w69
An event can look flawless on paper and still fail the moment thousands of devices try to connect at once. That is why an event connectivity planning checklist should be treated as part of core event operations, not a late-stage technical add-on. If ticketing, payment, production, staff comms, media upload, security systems or guest Wi-Fi depend on wireless performance, connectivity is now part of the event risk register.
However how real is that risk register? Every event organiser I have spoken to over the last few years is paranoid that “the mother of all storms” will happen connectivity or power wise. These low probability but high impact risks can be mitigated with onsite 5G that brings it’s own power which can last the entire event, and the most efficient way of doing that is a vehicle that runs on solar and can go anywhere in the event, so the connectivity goes (and can move) to exactly where it’s needed, not just where it’s size, obnoxious fumes or H&S other allowed it to be and you now need a few more as they cannot be where they need to be and… the costs spirals… However the risks that don’t seem to keep event organisers as awake at night are the high probability, high impact wi-fi risks. Wi-Fi has no QoS and the chips are cheap. Any amount of MiFi devices, or just sheer volume of wifi enabled phones can bring a wifi network down, no matter how many there are, or how well they are choreographed; it’s a question of when, not if, Wi-Fi will go down. Here is a some context and analogy from a colleague Sham Sanoon.
Too many teams still approach it backwards. They start by asking what kit to order or which provider has the strongest marketing claim. The better starting point is operational reality. What must work, for whom, where, at what time, and with what level of resilience? Once those questions are answered properly, the network design becomes much clearer.
What an event connectivity planning checklist needs to cover
A useful event connectivity planning checklist is not a shopping list. It is a structured way to make sure commercial, technical and operational decisions line up before site build starts. The checklist should force clarity on critical dependencies, user groups, traffic patterns, venue constraints, security posture and fallback options.
For example, a music festival, a trade exhibition and a temporary motorsport venue may all need strong wireless coverage, but the traffic profile is completely different. Festivals often see bursty consumer usage and dense crowd behaviour. Exhibitions have high exhibitor demand, payment terminals and media uploads spread across halls. Motorsport and live production environments may need low-latency operational links in moving, noisy and RF-heavy conditions. Treating these as the same problem is where expensive mistakes begin.
Start with operational use cases, not bandwidth guesses
The first job is to map what the connectivity is actually for. Guest Wi-Fi is only one part of the picture and often not the most critical one. Production teams, vendors, security personnel, broadcast crews, point-of-sale systems, access control, CCTV, telemetry and IoT devices can all sit on the same site with very different performance and security requirements.
This is where many planning exercises go wrong. A headline estimate such as “we need 1 Gbps” tells you very little. You need to understand concurrent users, application types, uplink versus downlink demand, peak time windows, and whether there are any genuinely business-critical services that cannot tolerate interruption. Card payments failing for ten minutes is not an inconvenience at scale. It is lost revenue, longer queues and reputational damage.
A sensible checklist should separate services into tiers. Some functions are mission-critical, some are commercially important, and some are best-effort. That distinction matters because not every traffic type deserves the same network treatment.
Site survey and RF reality come before final design
Temporary and semi-permanent event environments are full of variables that look minor until they are not. Metal structures, staging, LED walls, generators, catering compounds, vehicle movements and dense human crowds all affect wireless performance. A venue that appears straightforward during a quiet site visit can behave very differently during live operations.
That is why physical site review matters. You need to know where people will gather, where staff will operate, where uplinks can be brought in, where power is available, and where obstructions or interference are likely. Existing venue infrastructure may help, but it can also create false confidence if it was designed for light corporate use rather than event-scale demand.
If the site is remote, the stakes rise further. Public mobile networks may be inconsistent, congested or weak in exactly the areas that matter most. In those cases, the planning decision may involve a mix of fixed access, bonded links, dedicated temporary wireless, private LTE or private 5G, or carefully controlled segmentation across multiple technologies. There is no universal answer. It depends on density, criticality, geography, budget and deployment time.
Capacity planning is about behaviour, not just headcount
One of the weakest assumptions in event planning is that attendee numbers alone determine connectivity requirements. They do not. A crowd of 5,000 at a business conference behaves very differently from a crowd of 5,000 at a sporting event or music festival. Device counts, app usage, video sharing, roaming profiles, media upload habits and dwell patterns all change the load.
A proper checklist should ask how many users will connect, how many devices per user are realistic, which applications they will use, and when peaks will occur. Registration periods, headline acts, race starts, breaks between sessions and emergency incidents all produce different traffic spikes. Staff and vendor traffic should be modelled separately from public usage because operational devices need protection from consumer demand.
It is also worth deciding early whether everyone really needs internet access. In some environments, local application access, private operational connectivity or segmented service delivery is far more sensible than broad open access.
The event connectivity planning checklist for resilience
If a service matters, plan for failure. That sounds obvious, but resilience is still commonly treated as an optional cost rather than a design principle. For events, that is risky thinking. A short outage can interrupt entry, stop trading, disrupt safety operations or break live production workflows.
Resilience planning starts with identifying single points of failure. That could be a sole backhaul provider, one power source, a single core network component, an exposed cabinet position or an unmanaged dependency on venue infrastructure. Once identified, you can decide what needs redundancy and what does not.
Not every event requires full duplication of everything. For some, a secondary circuit and local failover for payment and access control may be enough. For others, especially where safety, government, defence, broadcast or premium live operations are involved, the tolerance for disruption is much lower. In those cases, layered resilience is justified.
Failover also needs testing. A backup that has never been exercised is only a theory.
Security, segmentation and access control
Event networks often bring together temporary staff, third-party suppliers, unmanaged devices and public users in compressed timelines. That creates a large attack surface. Security cannot be bolted on after deployment.
At minimum, the checklist should define who needs access to what, whether devices are managed or unmanaged, how credentials will be issued, and how different traffic groups will be segmented. Guest access should not sit alongside production systems without clear separation. Payment, CCTV, operational comms and staff applications should have their own policies and protections.
The right architecture depends on the event profile. A closed enterprise event in a controlled venue is one thing. A public event with contractors, roaming staff, temporary devices and rapid on-site changes is another. Simplicity matters, but oversimplifying can create avoidable risk.
Vendor coordination is usually where timelines slip
Connectivity planning is rarely blocked by one dramatic technical issue. More often, it slips because responsibilities are vague. Who owns backhaul delivery, on-site RF design, LAN build, Wi-Fi deployment, SIM provisioning, support escalation, change control and live monitoring? If that is not clear early, people make assumptions and gaps appear.
This is especially true when venues, event agencies, mobile operators, IT teams, broadcast suppliers and specialist connectivity partners are all involved. Good planning means documenting dependencies and decision points before procurement locks in the wrong path. The cheapest line item can become the most expensive problem if it delays live operations.
Support model and live-day operations
A network that works in testing can still fail operationally if support is weak. Events are dynamic. Device counts change, traffic patterns move, users ignore access instructions, and field teams improvise under pressure. The support model needs to reflect that.
That means deciding who monitors performance, who handles first-line faults, how incidents are escalated, what spare equipment is on site, and how changes are approved during live operation. For larger events, network visibility is not optional. If you cannot see what is happening, you will end up troubleshooting by guesswork while queues build and stakeholders lose patience.
This is where experienced planning pays back quickly. The value is not only in selecting technology. It is in anticipating operational friction before it becomes a live issue.
A practical way to use the checklist
The most effective way to use an event connectivity planning checklist is as a decision document shared across technical, operational and commercial stakeholders. It should be completed early, reviewed at key milestones, and updated when the event scope changes. If the event adds a sponsor activation, cashless payments, temporary CCTV or a new media zone, the connectivity plan should change with it.
For higher-stakes events, specialist review is often the difference between a workable design and a costly assumption. Christian Borrman’s kind of operator-grade, execution-focused input is particularly relevant where private networks, multi-operator strategy, temporary critical infrastructure or recovery from a failing plan are involved.
Connectivity is now part of the event experience, the operating model and the commercial outcome. Treat it with that level of seriousness, and problems become manageable rather than public.
