Ticketing and Point of Sale

Overview

A venue's revenue arrives through the smallest transactions on the network. A ticket scan is a few hundred bytes. A card payment is a few kilobytes. Neither is remotely demanding in isolation.

The difficulty is when they happen. Forty thousand people arrive through thirty gates in a forty-five minute window, and every one of them is scanned. Concessions then transact continuously through an interval that lasts fifteen minutes. The load is not sustained traffic; it is a wall of tiny, simultaneous, latency-sensitive sessions that appears and disappears on the event schedule.

Public networks fail at exactly that moment, and for a structural reason: the crowd that generates the revenue is the same crowd saturating the cell. Forty thousand phones streaming and posting are contending with the terminal trying to authorize a card. Venue Wi-Fi fails the same way, from device density in a confined space.

Private 5G removes the contention entirely. The terminals sit on a network that carries nothing but venue traffic, policed by the venue, sized for the peak the venue knows is coming. This workflow ran at the 2025 Australian Grand Prix, where a private network carried transactions alongside operations, security and media contribution for a seven day event.

---

How It Works

The aggregate is under 20 Mbps. The device count per radio constrains the design, along with the attach burst when the gates open.

What each component does

Component	Role in this workflow
Ticket scanner	Handheld or pedestal reader at the gate. Reads the barcode or NFC pass and needs a real-time answer before the turnstile releases
Payment terminal	Fixed at a till, handheld for roaming vendors, or a phone-based reader. Carries the SIM and holds the PDU session
Onyx RU	The radio. At a venue, placement follows where people queue, which is not where people sit
FHM	Aggregates RUs into one logical cell, so a roaming vendor crossing a concourse never hands over mid-transaction
Onyx Edge, 5G Core	Terminates the session and applies the subscriber group policy that keeps transactions ahead of bulk traffic
Local breakout	Puts transaction traffic on the venue network, and card data on the venue's segmented payment VLAN
Payment gateway	The acquirer connection. Usually the one hop in this chain that leaves the site
Ticketing platform	Validates the pass against the entitlement record and marks it used. Hosted on the edge where duplicate-entry checking has to be immediate
Onyx Portal	Per-terminal connectivity, session counts, and alerts, visible during the event rather than after it
Mesh Node	Wireless backhaul to RUs at temporary gates, car park kiosks and pop-up bars where no cable was ever pulled

The transaction path, hop by hop

#	From → To	Interface	What happens
1	Card or pass → Terminal	NFC, EMV, barcode	The credential is read. Milliseconds, and entirely local
2	Terminal → Onyx RU	5G NR Uu, uplink	A few kilobytes on the terminal's subscriber group. Small, but it must be scheduled promptly
3	Onyx RU → FHM → Onyx Edge	eCPRI, aggregated fronthaul	No handover decision. The vendor has not crossed a cell boundary because there is not one
4	Onyx Edge → UPF	internal	The session is terminated and the QoS policy applied
5	UPF → venue network	N6 local breakout	Traffic lands on site, card data on the segmented payment VLAN
6	Venue network → gateway or platform	IP	Ticketing validates on the edge. Payment authorization leaves for the acquirer
7	Response → Terminal	the same path back	The turnstile releases, or the receipt prints

Where the time goes

Stage	Typical
Card or barcode read	50 to 150 ms
Terminal to Onyx Edge, over the air	10 to 20 ms
Ticket validation on the edge	20 to 50 ms
Payment authorization to the acquirer and back	300 to 2000 ms
Receipt or gate release	50 to 100 ms

The acquirer round trip dominates, and you do not control it. You control everything either side of it, and whether the request reaches the acquirer promptly in the first place. On a congested public network the variable is not the acquirer, it is the seconds spent waiting for a scheduling slot before the request ever leaves the terminal.

The constraint is device count, not bandwidth

Add up the busiest ingress a venue will see. Five hundred terminals, a few kilobytes each, and the total is a handful of megabits. Bandwidth is not what limits this deployment.

Three other things do.

Connection count. An Onyx AP supports up to 96 simultaneous UE on LTE and 128 on 5G. Six hundred terminals and scanners across a concourse is a cell-planning problem measured in attached devices, not Mbps. This is the number that decides how many radios you buy.

The signaling burst at ingress. Every terminal powers on and attaches inside the same short window. Attach, authentication and session establishment are control-plane work, and they arrive together. A network sized comfortably for steady-state traffic can still struggle at the moment the gates open.

Latency turning into queue length. A payment that takes eight seconds instead of two does not fail. It adds six seconds to every transaction at that till. Across thirty gates and an arriving crowd, that becomes a physical queue out of the door and concession revenue that never gets spent. Latency is the mechanism; the symptom is people standing still.

---

Network Requirements

Per-transaction payload	0.5 to 5 KB
Per-terminal sustained rate	< 50 kbps
Aggregate at peak	typically under 20 Mbps, even for a large venue
Concurrent devices	200 to 2,000 terminals, scanners and handhelds
Transaction round trip, excluding the acquirer	< 100 ms
Jitter	< 50 ms
Residual loss	10-6, a retried payment is a reconciliation problem
Availability	99.99% within the event window
Transaction QoS	5QI 70, non-GBR, mission-critical data, 200 ms PDB
Reconciliation and updates QoS	5QI 8 or 9, non-GBR, scheduled outside the event

Read the concurrent-device row, not the bandwidth row. It is the line that drives the radio count.

---

Deploying It

1

Survey to the queues, not to the seats

Coverage has to be strongest where people stop moving: gate lines, concession counters, merchandise stands, car park kiosks. Those are usually at the perimeter and under structures, not in the bowl where the RF plan naturally concentrates.

2

Count terminals per coverage area

For every gate cluster and concourse, count every device that will attach: scanners, tills, handheld readers, vendor phones. Compare against the per-AP device limit. This count, not the throughput, sets the radio count.

3

Separate the traffic classes

Put transactions in their own subscriber group on 5QI 70. Put firmware updates, reporting and reconciliation on 5QI 8 or 9 and schedule them outside the event window. Without this, a terminal fleet pulling an update at the wrong moment competes with live payments.

4

Segment the card data

Card traffic breaks out locally onto the venue's payment VLAN, segmented from everything else at the Onyx Edge. Bring your PCI assessor into the design rather than the audit.

5

Rehearse the ingress burst

Test the moment the gates open, not steady state. Power on the full terminal fleet together and confirm every device attaches and transacts. This is the test that finds control-plane limits, and it is the one most often skipped.

6

Watch it during the event

Terminal connectivity and session counts in Onyx Portal, visible to the operations room while the event is running. A till that has silently dropped off the network is a queue forming before anyone reports it.

7

Reconcile and tear down

Reconcile transactions, then release the temporary gates and kiosks. At a seasonal venue the network is a reusable asset, not a sunk cost.

---

Devices and Ecosystem

• 5G payment terminals: fixed tills and handheld readers with an eSIM, from the usual payment hardware vendors.
• Ticket scanners: handheld and pedestal readers, barcode and NFC.
• Vendor phones and tablets: roaming sellers in the stands and the concourse.
• 5G CPE at fixed points: backhauling a cluster of wired tills behind one router where the tills themselves are not cellular.
• Ticketing platform: hosted on Onyx Edge so validation and duplicate-entry checks resolve locally.
• Payment gateway connection: the acquirer link, usually the only hop that leaves site.
• Mesh Nodes: for temporary gates, overflow car parks and pop-up bars.

---

Design Considerations

Ticketing and payment fail differently, and the design has to respect that. A payment terminal can store a transaction and forward it when the link returns. A ticket scanner cannot: validating a pass offline means accepting the risk of the same pass being used twice at another gate. Ticketing needs live validation, so it is the workflow that sets the availability requirement.

Size for ingress, not for the average. The busiest forty-five minutes of the day carry almost all of the attach load and much of the transaction load. A network sized on average event traffic will be comfortable for ninety percent of the event and fail during the part that matters.

SIM credentials are a real security improvement over shared Wi-Fi. Hundreds of terminals on a shared passphrase is a credential that cannot be rotated in practice and cannot be revoked per device. SIM-based authentication gives each terminal its own credential, revocable centrally the moment a device goes missing. Combined with IMEI binding, a stolen SIM in an unauthorized terminal does not attach at all.

The acquirer link is the single point of failure you do not own. Everything else in this chain can be made resilient on site. Plan the fallback for when that link degrades, and confirm what your terminals do when authorization times out.

Temporary venues justify the deployment on their own. A circuit or a festival ground used twenty days a year cannot economically cable every gate. Mesh backhaul to temporary positions is what makes those positions viable at all.

---

Validation Checklist

• Coverage confirmed at gate lines, counters and kiosks, not just in the bowl
• Device count per coverage area measured against the per-AP limit
• Full-fleet attach test from cold, simulating the gates opening
• Transaction round trip measured under that peak, not at rest
• Transactions and bulk traffic on separate subscriber groups and QoS classes
• Card traffic segmented onto the payment VLAN, reviewed by the PCI assessor
• Ticket validation confirmed to resolve on the edge
• Duplicate-entry rejection verified across two different gates
• Terminal behavior confirmed when acquirer authorization times out
• Portal alerting routed to the operations room for the event duration
• Roaming vendor tested across the full concourse with no session loss

---

Next steps

• Size it. Take these requirements through Plan Your Network: capacity, coverage, architecture, and a preliminary bill of materials.
• Compare it. Network Requirements at a Glance puts every workflow side by side, for sites carrying more than one.
• Talk to us. For a validated design and a quote, contact GXC.

Related reading

• Live Video Production : media contribution over the same venue network
• Network Requirements at a Glance : all workflows side by side

Contact GXC

To get in touch with GXC, please visit https://gxc.io/contact-us/.