Connected Worker Push-to-Talk
Overview
Most distribution centres run on two-way radio and have done for decades. It works, and it has three persistent limitations: coverage is whatever the repeater reaches, capacity is whatever the channel plan allows, and the radio system is entirely separate from every other system in the building. A picker cannot receive a task on the same device they use to call for help.
Push-to-talk over private 5G removes the separate infrastructure. The same network that carries the WMS handhelds, the forklift terminals, and the tracking tags also carries voice, with a guaranteed bearer per active talker, priority handling that lets a supervisor or an emergency call preempt routine chatter, and coverage that follows the network rather than a repeater's line of sight. Freezer rooms, mezzanines, trailer bays, and the yard all get the same treatment.
This is the push-to-talk model: one talker per group at a time, arbitrated by floor control, sized for concurrent talkers. It is deliberately different from the full-duplex partyline model used in broadcast, see Wireless Intercom & Talkback, where every beltpack holds an open bidirectional path continuously and the capacity model is an order of magnitude larger. Choose the model that matches how the site actually communicates; a warehouse does not need two hundred open duplex paths, and a gallery cannot work with a single floor grant.
How It Works
The floor control loop
What each component does
Handset
Rugged 5G PTT device with a physical key, glove-operable. Often also the WMS client and barcode scanner
Onyx RU
Coverage designed to the building (freezers, mezzanines, trailer bays, the yard) rather than to a repeater's line of sight
FHM / shared cell
No inter-cell handover to clip the start or end of a transmission as a worker moves
Onyx Edge · 5G Core
Maps priority bands to distinct 5QI and ARP values, so preemption is enforced by the scheduler under congestion rather than merely decided in the application
Floor Control Service
On the Onyx Edge. Resolves each floor request against group policy and current state: grant, queue, or preempt
Media relay
On the Onyx Edge. Gates the talker's path and distributes audio to group members
Admin console
Identity, talkgroup membership, and policy: bulk CSV at warehouse scale, with RBAC and a workforce-system integration so starters and leavers are handled by process
Onyx Edge HA
Single-active ownership with floor state replicated to standby: a three-shift site has no free restart window
Onyx Portal
Bulk SIM provisioning and per-handset diagnostics at warehouse scale
The grant sequence, step by step
1
Handset → Floor Control Service
Key press becomes a floor request, carried over the 5G bearer
2
Inside the FCS
Resolved against group policy and current floor state: is anyone talking, and does this requester outrank them?
3
FCS → Handset
Grant, queue behind the active talker, or preempt the active talker if the requester holds a higher priority band
4
Grant → Microphone
The grant gates the microphone at the client. No grant, no transmit: this is what stops a handset talking over a supervisor
5
FCS → Media relay
Talker path opened
6
Media relay → Group members
Audio distributed to every affiliated handset
Target: under 300 ms from key press to talk permitted, and under 500 ms end to end for emergency call setup.
Alongside the core loop: scan surfaces the highest-priority active talkgroup so a picker on outbound still hears an all-site announcement; late join gives a handset powering on mid-call the current floor state immediately; do-not-disturb suppresses routine calls while remaining transparent to emergency traffic; text and call alert reach one worker without taking the floor.
Where the latency goes
Key press → request on air
10–30 ms
5G uplink
5–15 ms
Floor resolution at the edge
5–20 ms
Grant returned downlink
5–15 ms
Client unmutes and begins encoding
20–60 ms
Key press to talk permitted
~50–140 ms, target < 300 ms
Mouth-to-ear once talking
< 150 ms round trip
Why this is not the broadcast intercom model
Floor control exists to arbitrate a single talker per group, so capacity is sized for concurrent talkers, typically 5–10% of the fleet, with a floor of twelve. A 500-handset site might see six simultaneous grants on a routine shift.
Full-duplex broadcast intercom does the opposite: every beltpack holds an open bidirectional path continuously, whether anyone is speaking or not, and capacity is sized for the entire registered fleet. See Wireless Intercom & Talkback. Confusing the two under-sizes an intercom deployment by more than an order of magnitude: or wastes most of a carrier on a warehouse that never needed it.
Fail safe means fail closed. If the floor control service cannot reach policy state, it must deny the floor rather than grant it. A handset transmitting without a valid grant talks over whoever else is speaking.
Network Requirements
Bearer rate per active talker
32–64 kbps
Aggregate for a 500-handset site
< 15 Mbps
Concurrent active talkers to provision
5–10% of handset count, minimum 12
One-way network latency
< 50 ms
Mouth-to-ear latency
< 150 ms round trip
Jitter
< 20 ms
Packet error rate
10-2
Floor grant time
< 300 ms from key press
Emergency call setup
< 500 ms end to end
Availability
99.99%
Voice QoS
5QI 65: GBR, mission-critical PTT voice, 75 ms PDB, priority 7
Routine voice QoS
5QI 66: GBR, 100 ms PDB
Signaling QoS
5QI 69: non-GBR, 60 ms PDB
Task/data traffic on same handset
5QI 70 or non-GBR 5QI 8
Bands
n77, n78, n48 (CBRS), n40
Deploying It
Map talkgroups to how the site operates: inbound, outbound, replenishment, yard, maintenance, security, all-site. Define priority bands: routine at the bottom, supervisors above, emergency at the top with the right to preempt an active talker and reach every handset in scope. Make membership follow shift assignment automatically rather than requiring manual channel selection.
Deploy the PTT server on Onyx Edge with HA and floor state replicated to standby: a three-shift DC has no maintenance window in which a restart is free. Verify fully offline operation; site voice should not depend on a WAN link a contractor can cut.
Provision at scale. SIMs in Onyx Portal on 5QI 65 for voice plus a low-latency non-GBR bearer for signaling. Identity and talkgroups by CSV import with RBAC. Where handsets are pooled on a charging rack, provision the role and let workers sign in at shift start: binding identity to the device is wrong in that model.
Validate coverage where two-way radio already fails: the freezer, the trailer bay, the far end of the yard. That is where the business case was written and where the new system will be judged.
Integrate with the work. Route WMS task assignments, exception alerts, and pick confirmations to the same handset, on a separate, lower-priority bearer than voice. Consolidating devices is the point; consolidating bearers is a mistake.
Plan the LMR migration, not a cutover. A radio gateway bridging talkgroups across both systems turns a cutover into a migration and provides a fallback while coverage is proven.
Monitor. Concurrent floor grants against provisioned capacity; coverage by talkgroup, since a group working in the freezer will show problems a site-wide average hides. Route Onyx Portal and PTT server alarms to the same on-site engineer.
Devices & Ecosystem
Rugged 5G PTT handsets: with a physical PTT key, glove-operable, and rated for the drop and dust environment of a DC.
5G handheld terminals: where the site consolidates the scanner, the WMS client, and PTT onto one device.
Vehicle-mounted units: for forklift and reach-truck operators, with an external speaker/microphone and a wired PTT control.
Dispatch console: a software console for the shift office: talkgroup overview, priority override, emergency broadcast, and location context where tracking is deployed.
Radio gateway: an interface to an existing LMR or DMR fleet during a phased transition, so both systems reach the same talkgroups.
Lone-worker and man-down accessories: where the site's safety policy requires them.
Design Considerations
Coverage in the places two-way radio already fails. The business case for this workflow is usually written by the freezer, the trailer bay, and the far end of the yard. Survey those first: they are where the incumbent system's weakness is felt, and where the new one will be judged.
Provision for the incident, not the average. Voice capacity scales with concurrent talkers. On a routine shift, a 500-handset site might see six simultaneous grants; during an evacuation it will see many times that, from people who all key up at once. Provision 5–10% with a floor of twelve, and test at that level.
Preemption must be enforced by the core. An application-layer priority decision does not survive a congested cell. Map priority bands to distinct 5QI and ARP values and verify preemption under induced congestion, not on a quiet network.
Pooled devices need role-based sign-in. In a DC where handsets live on a charging rack and are picked up at shift start, binding identity to the device is wrong. Bind it to the worker, and let them sign in to whatever device they take.
Keep voice separate from the WMS traffic on the same handset. Consolidating devices is the point; consolidating bearers is a mistake. A batch of task assignments should never be able to delay a floor grant.
Plan the LMR transition rather than the LMR cutover. Sites rarely switch a whole workforce in one night. A radio gateway that bridges talkgroups across both systems turns a cutover into a migration, and gives you a fallback while coverage is proven.
Validation Checklist
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
Wireless Intercom and Talkback : the same floor-control problem at a live event
Asset and Forklift Tracking : position reporting across the same warehouse network
Network Requirements at a Glance : all workflows side by side
Was this helpful?