> 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/events-and-venues/wireless-intercom-and-talkback.md).
# Wireless Intercom and Talkback
## Overview
Wireless intercom has run on DECT for two decades. Clear-Com FreeSpeak II and Riedel Bolero both work at 1.9 GHz, with beltpacks roaming between transceivers — each transceiver a small cell, each roam a handoff. It works well, and its limits are structural: coverage reaches wherever transceivers were cabled to, capacity is bounded by the RF channel plan and the base station's beltpack count, and every transceiver needs a cable run back to a base or splitter.
Moving the beltpacks onto the site's private 5G network changes the RF layer without changing the operating model. The production still works in partylines and talk keys, IFB and remote mic kill, answerback and call signal. Underneath, the Onyx RUs already carrying cameras and production data now carry the intercom too — and because those RUs form a single shared cell, the beltpacks do not hand off at all.
This is not theoretical. **Clear-Com FreeSpeak Cell** is a shipping beltpack — the FSC-BP-C — running over 4G LTE and 5G, with dual SIM so a production can hold a private network as primary and a public carrier as fallback, registering to an Arcadia Central Station or an Eclipse HX matrix through the E-IPA-HX card.
{% hint style="info" %}
Product and company names here are trademarks of their respective owners. Nothing on this page asserts a certification or partnership between GXC and any intercom vendor. Validate interoperability for your specific system and firmware with the manufacturer.
{% endhint %}
## How It Works
### Reference architecture
### What each component does
| Component | Role in this workflow |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Beltpack** | The operator's endpoint. Captures mic audio, encodes it, and holds an open full-duplex path. Five to nine assignable talk/listen keys with per-key crosspoint level control. Carries a SIM — dual SIM on FreeSpeak Cell. |
| **Onyx RU** | The radio cell. Runs the O-RAN 7.2x low-PHY and provides the air interface the beltpack attaches to. Multiple RUs are deployed for coverage. |
| **FHM** | Aggregates all RUs into **one logical cell** and distributes IEEE 1588v2 PTP and SyncE timing so every RU is frame-aligned. This is what removes handoff. |
| **Onyx Edge — DU / CU** | High-PHY, MAC, RLC in the DU; RRC and PDCP in the CU. Because every RU is one cell, there is no handover decision to make. |
| **Onyx Edge — 5G Core** | Terminates the PDU session and enforces the QoS flow. Each beltpack's bearer is 5QI 1 GBR, reserved bidirectionally. |
| **Local breakout** | Puts intercom audio onto the production LAN on site. Audio never traverses a WAN or a public network. |
| **Intercom matrix** | Arcadia Central Station, or Eclipse HX with the E-IPA-HX card. Routes and mixes: for each destination it sums the sources that destination's keys have open, at that destination's levels. Applies IFB ducking, remote mic kill, and call signal. |
| **Plant interfaces** | 4-wire analogue to wired panels; AES67, Dante, or SMPTE ST 2110-30 to the venue audio network. |
### The audio path, hop by hop
One operator speaks; another hears them. This is every hop in between.
| # | From → To | Interface | What happens |
| -- | ------------------------ | ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Headset → Beltpack | XLR-4M / XLR-5F analogue | Mic audio captured, gain applied, encoded to a low-delay voice codec |
| 2 | Beltpack → Onyx RU | **5G NR Uu**, uplink | Encoded audio as RTP inside the beltpack's PDU session, on its 5QI 1 GBR bearer. The scheduler grants uplink resource continuously — the path is open whether or not a key is pressed |
| 3 | Onyx RU → FHM | **eCPRI**, O-RAN 7.2x fronthaul | RU completes the low-PHY. FHM aggregates every RU into one logical cell and holds PTP timing |
| 4 | FHM → Onyx Edge DU | Aggregated fronthaul | High-PHY, MAC, RLC. **No handover decision exists** — the beltpack has not crossed a cell boundary because there isn't one |
| 5 | DU → CU → UPF | F1 / N3, internal to Onyx Edge | RRC and PDCP at the CU; the UPF terminates the session and polices the QoS flow |
| 6 | UPF → Production LAN | **N6 local breakout** | Audio exits onto the venue LAN, on site |
| 7 | LAN → Matrix | **IP / RTP** | The matrix receives one uplink stream per beltpack |
| 8 | *Inside the matrix* | — | **Routing and mixing.** For each destination, the matrix sums the sources whose keys that destination has open, at that destination's crosspoint levels, then applies IFB ducking, RMK, and call signal |
| 9 | Matrix → LAN → UPF | IP / RTP | **One personalised downlink mix per beltpack** — not a copy of a shared bus |
| 10 | UPF → CU → DU → FHM → RU | Reverse of 5→3 | Downlink on the same reserved GBR bearer |
| 11 | Onyx RU → Beltpack | 5G NR Uu, downlink | Beltpack receives its mix |
| 12 | Beltpack → Headset | Jitter buffer, decode, D/A | The operator hears the talker |
**Branches off hop 8.** The matrix is also where the wireless domain meets everything else: 4-wire analogue out to wired panels, AES67 / Dante / ST 2110-30 to the venue audio network, and — in a hybrid estate — DECT transceivers still serving FreeSpeak II or Bolero beltpacks alongside the cellular ones.
### Where the latency goes
Mouth-to-ear is a chain. The 5G segment is a minority of it, which is the point most often missed.
| Stage | Typical contribution |
| --------------------------------------- | ---------------------------------------- |
| Headset capture, beltpack encode | 5–15 ms |
| 5G uplink — scheduling and transmission | 5–15 ms |
| Fronthaul and Onyx Edge processing | 1–3 ms |
| Matrix routing and mix | 2–10 ms |
| 5G downlink | 5–15 ms |
| Beltpack jitter buffer and decode | 10–30 ms |
| **Total mouth-to-ear** | **\~30–90 ms typical, < 150 ms maximum** |
The two terms worth tuning are the jitter buffer and the scheduler. Everything else is largely fixed by the equipment.
### Two architectural models
The intercom engine's architecture determines what the 5G network is asked to carry, and the two models differ more than they first appear.
**Matrix-based** — Clear-Com Arcadia and Eclipse HX, Riedel Artist. Mixing happens centrally, so each beltpack is exactly one uplink stream and one downlink mix. N beltpacks means 2N unicast streams. This maps directly onto 5G unicast bearers and scales linearly.
**Decentralised** — Green-Go. There is no central matrix and no single point of failure; devices are peers, and each subscribes directly to the channels it listens to, addressing 32 channels plus a programme channel and a direct user channel. Architecturally this removes the matrix as a failure domain. But it is **multicast**, and 5G does not carry IP multicast natively without Multicast-Broadcast Services. Absent MBS, each multicast stream is replicated as unicast to every subscribed listener, and downlink load multiplies with listener count. Resolve it deliberately — an MBS-capable configuration, or a multicast-to-unicast gateway hosted on the Onyx Edge — and size the downlink to match.
### What changes relative to DECT
| | DECT — FreeSpeak II, Bolero | 5G — FreeSpeak Cell on Onyx |
| ------------------ | ----------------------------------------------- | --------------------------------------------------- |
| RF layer | 1.9 GHz DECT | 5G NR — n77, n78, n48 |
| What a cell is | Each transceiver | All RUs together, as one shared cell |
| Mobility | Handoff between transceivers | **No handoff** — there is no cell boundary |
| Extending coverage | Cable another transceiver and splitter | Beltpack works wherever the network already reaches |
| Capacity ceiling | RF channel plan and base station beltpack count | GBR capacity of the carrier |
| Infrastructure | Dedicated transceivers, splitters, cabling | Shares RUs with cameras and production data |
| Spectrum | Licence-exempt 1.9 GHz | Licensed or CBRS, coordinated |
| Fallback path | None | Dual SIM to a public carrier |
## Network Requirements
| Parameter | Target |
| ---------------------------------- | --------------------------------------------------------------------------------------- |
| Per-beltpack bearer, uplink | 64–150 kbps depending on codec |
| Per-beltpack bearer, downlink mix | 64–150 kbps |
| Per-beltpack total, symmetric | \~150–300 kbps including overhead |
| Aggregate, 100-beltpack production | 15–30 Mbps symmetric |
| Aggregate, 300-beltpack production | 45–90 Mbps symmetric |
| Concurrency model | **Every registered beltpack, always** — full-duplex paths are open continuously |
| One-way network latency | < 30 ms |
| Mouth-to-ear latency, end to end | < 100 ms target, < 150 ms maximum |
| Jitter | < 10 ms |
| Packet error rate | 10-3 |
| Availability during show window | 99.999% |
| Primary QoS | **5QI 1** — GBR, conversational voice, 100 ms PDB, priority 20 |
| Priority / emergency paths | **5QI 65** — GBR, 75 ms PDB, priority 7 |
| Signalling QoS | **5QI 69** — non-GBR, 60 ms PDB, priority 5 |
| TDD pattern | Symmetric, e.g. `DDSUU`; avoid heavily uplink-weighted patterns on the intercom carrier |
| Bands | Any Onyx-supported band; may share the production carrier |
{% hint style="warning" %}
The concurrency row is the one that catches people out. Push-to-talk is sized for concurrent talkers — typically 5–10% of the fleet. Full-duplex partyline is sized for **every beltpack, continuously**. A 200-beltpack production is 200 open bidirectional GBR paths, not twelve.
{% endhint %}
## Deploying It
The architecture above is the *what*. This is the sequence that gets it running.
{% stepper %}
{% step %}
### Design channels and keys
Partylines, key layouts per role, point-to-point paths, IFB feeds. Define remote mic kill, stage announce, and call signal authority, and who can override whom.
{% endstep %}
{% step %}
### Deploy the intercom engine
Matrix on the venue LAN behind local breakout, or the decentralised peer network with multicast resolved. Plan 4-wire, AES67, Dante, or ST 2110-30 interfaces to the rest of the plant.
{% endstep %}
{% step %}
### Configure the network
Intercom subscriber group bound to 5QI 1, GBR reserved for every registered beltpack, symmetric TDD pattern, signalling on its own low-latency bearer.
{% endstep %}
{% step %}
### Provision beltpacks
SIM or eSIM per beltpack in Onyx Portal. Define the dual-SIM fallback policy explicitly. Label by production role and record role-to-beltpack-to-IMSI in the runsheet.
{% endstep %}
{% step %}
### Survey and rehearse
Every crew route including back-of-house, plant rooms, and truck park. Verify beltpacks stay on the private network rather than silently falling back. Run a full-crew rehearsal with every partyline open, concurrently with full camera load.
{% endstep %}
{% step %}
### Monitor in show
Per-beltpack latency and throughput against reservation, public-SIM fallback alerts, and fleet battery state.
{% endstep %}
{% step %}
### Tear down
Suspend SIMs, export performance data as the venue's baseline, archive the role mapping.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
### Clear-Com
* **FreeSpeak Cell** — the FSC-BP-C beltpack over 4G LTE and 5G, dual SIM for private-primary and public-fallback. The most direct fit for this architecture today.
* **Arcadia Central Station** and **Eclipse HX** with the **E-IPA-HX** card — the matrix the beltpacks register to.
* **FreeSpeak II** (1.9 / 2.4 GHz) and **FreeSpeak Edge** (5 GHz) — the DECT and 5 GHz estate, supported alongside cellular beltpacks in hybrid deployments.
* **Agent-IC** and **Station-IC** — IP intercom clients for remote and occasional users, over the same bearer.
* **LQ series** and **HelixNet** — IP linking and digital partyline for fixed positions and site-to-site.
### Green-Go (Riedel)
* **Decentralised IP intercom** — no central matrix, no single point of failure. Beltpacks address 32 channels plus a programme channel and a direct user channel.
* **PoE-powered wired stations** (802.3af) for fixed positions.
* **Dante Interface X** — converts up to eight Dante or AES67 streams to and from the Green-Go network.
### Riedel
* **Bolero** — 1.9 GHz wireless beltpack, deployable integrated with an **Artist** matrix, in standalone link mode, or in **Standalone 2110 (AES67)** mode building an ST 2110 network with no matrix required.
* **Bolero Mini** — the compact beltpack introduced at IBC 2025, with 5G filtering to resist desensitisation from high-power cellular transmitters.
### Also in this space
**RTS (Bosch)** and **Pliant Technologies** offer wireless intercom families with IP matrix integration; **Unity Intercom** and similar app-based systems run as IP clients over the same bearer. Where a production standardises on interfaces rather than vendors, the ones that matter are **AES67**, **Dante**, **SMPTE ST 2110-30**, **4-wire analogue**, and **SIP**.
## Design Considerations
**Full-duplex partyline is not push-to-talk, and the difference is the whole capacity model.** Industrial PTT is sized for concurrent talkers and uses floor control to arbitrate one speaker per group — see [Connected Worker Push-to-Talk on 5G](broken://pages/0a6b0edb7806bd8650c6931f9196e03ccbdce6da). Broadcast intercom holds an open bidirectional path per beltpack, continuously. Size GBR for the full registered fleet.
**Resolve multicast before rehearsal, not during it.** If the intercom engine is decentralised, the multicast question above is the single largest risk to the deployment, and it does not surface until enough listeners subscribe to the same channel.
**Plan DECT and 5G coexistence in hybrid deployments.** FreeSpeak II and Bolero at 1.9 GHz have no co-channel conflict with n77, n78, or n48. The risk is receiver desensitisation: a high-power RU near a DECT beltpack can degrade its front end, which is why Bolero Mini ships with added 5G filtering. Plan physical separation between RUs and DECT transceivers, and validate the DECT system with 5G at full load rather than in isolation.
**Decide the dual-SIM fallback policy before the show.** Public fallback helps a beltpack that strays outside private coverage. It also silently moves production audio onto a congested public network with no QoS guarantee — during exactly the event that is congesting it. Decide whether it is permitted, and alert when a beltpack takes it.
**Capacity claims are network claims.** "Hundreds of beltpacks" is stated by vendors as network-dependent, and that dependency is the design work here: GBR capacity of the carrier, the TDD split, and the modulation available at the worst crew position.
**Intercom does not go on the guest network.** Its own subscriber group, its own guaranteed bearers, isolated from crew data and public access.
**Battery logistics will cause more show faults than the network will.** Plan charging, hot-swap, and spares as carefully as the RF, and monitor fleet battery state centrally.
## Validation Checklist
* [ ] Partylines, key layouts, IFB feeds, and point-to-point paths documented and agreed with the production
* [ ] Remote mic kill, stage announce, call signal, and override authority defined and tested
* [ ] Intercom engine reachable through local breakout — Arcadia, Eclipse HX with E-IPA-HX, Artist, or Green-Go peer network
* [ ] Multicast handling resolved for decentralised systems, with downlink sized accordingly
* [ ] GBR reserved for **every registered beltpack**, not an estimated concurrent-talker count
* [ ] Symmetric TDD pattern configured, or downlink mix capacity verified under the pattern in use
* [ ] Priority and emergency paths mapped to distinct 5QI and ARP values, verified under induced congestion
* [ ] Coverage validated on every crew route including back-of-house, plant rooms, and truck park
* [ ] Beltpacks confirmed to remain on the private network; public-SIM fallback policy defined and alerting configured
* [ ] Mouth-to-ear latency measured end to end at the furthest crew position, under 150 ms
* [ ] Full-crew rehearsal with every beltpack registered and every partyline open
* [ ] Concurrent test with full camera contribution load
* [ ] DECT estate validated with 5G at full load where hybrid; RU and transceiver separation planned
* [ ] 4-wire, AES67, Dante, or ST 2110-30 interfaces validated in both directions
* [ ] Edge HA failover exercised with intercom live; audio paths restored without re-registration
* [ ] Beltpacks labelled by production role; mapping in the runsheet
* [ ] Battery charging, hot-swap, and spares plan in place with central fleet monitoring
## Related reading
* [Live Video Production on 5G](broken://pages/207f99a8de4d76dd8a635680d4fa1ea522ce280f)
* [Connected Worker Push-to-Talk on 5G](broken://pages/0a6b0edb7806bd8650c6931f9196e03ccbdce6da) — the push-to-talk model, and how it differs
* [Network Requirements at a Glance](broken://pages/d8ba02440bfd0f056f057fd9b67a87d38f1d8507)
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.gxc.io/usecases-workflows/events-and-venues/wireless-intercom-and-talkback.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.