> For the complete documentation index, see [llms.txt](https://docs.gxc.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gxc.io/usecases-workflows/warehousing-and-logistics/connected-worker-push-to-talk.md).
# 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
One talker per group at a time. Floor control arbitrates the grant on the Onyx Edge, so the round trip stays on site.
### What each component does
| Component | Role in this workflow |
| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **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
| # | From → To | What happens |
| - | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| 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
| Stage | Typical contribution |
| ---------------------------------- | -------------------------------- |
| 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
| Parameter | Target |
| -------------------------------------- | ------------------------------------------------------------------ |
| 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
1. **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.
2. **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.
3. **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.
4. **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.
5. **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.
6. **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.
7. **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**](https://docs.gxc.io/devices/gxc-compatible-devices/smart-phones): with a physical PTT key, glove-operable, and rated for the drop and dust environment of a DC.
* [**5G handheld terminals**](https://docs.gxc.io/devices/gxc-compatible-devices/mobile-computer-scanner): 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
* [ ] Talkgroups mapped to shift structure; membership follows shift assignment automatically
* [ ] Priority bands defined, and emergency behavior agreed with site safety
* [ ] Coverage validated in freezers, mezzanines, trailer bays, plant rooms, and the full yard
* [ ] PTT server deployed on Onyx Edge; verified to operate with the WAN link disconnected
* [ ] Edge HA failover exercised with a call in progress; floor state preserved
* [ ] Priority bands mapped to distinct 5QI and ARP values; preemption verified under induced congestion
* [ ] Concurrent floor grants provisioned at 5–10% of handset count, minimum twelve, and load-tested at that level
* [ ] Floor grant time under 300 ms and emergency call setup under 500 ms, measured under load
* [ ] Mouth-to-ear latency under 150 ms round trip at the furthest point of coverage
* [ ] Scan, late join, do-not-disturb, and text/call-alert behaviors confirmed against policy
* [ ] Role-based sign-in tested on pooled devices
* [ ] Voice and WMS data verified on separate bearers; bulk task push does not delay a floor grant
* [ ] LMR gateway validated in both directions where a transition is in progress
* [ ] Lone-worker and man-down alerting tested end to end where deployed
* [ ] Full-site evacuation drill run on the system before it becomes the primary voice path
***
## Next steps
* **Size it.** Take these requirements through [Plan Your Network](https://docs.gxc.io/plan-your-network): capacity, coverage, architecture, and a preliminary bill of materials.
* **Compare it.** [Network Requirements at a Glance](https://docs.gxc.io/usecases-workflows/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](https://gxc.io/contact-us/).
## Related reading
* [Wireless Intercom and Talkback](/usecases-workflows/events-and-venues/wireless-intercom-and-talkback.md) : the same floor-control problem at a live event
* [Asset and Forklift Tracking](/usecases-workflows/warehousing-and-logistics/asset-and-forklift-tracking.md) : position reporting across the same warehouse network
* [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md) : all workflows side by side
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.gxc.io/usecases-workflows/warehousing-and-logistics/connected-worker-push-to-talk.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
