> 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/network-requirements-at-a-glance.md).
# Network Requirements at a Glance
This page puts all ten workflows side by side. Use it to size a network that has to carry more than one of them, and to check that a proposed spectrum and TDD configuration can satisfy the tightest requirement in the mix.
{% hint style="info" %}
The 5QI values below are the 3GPP standardised values from TS 23.501 Table 5.7.4-1. Onyx Portal applies them per subscriber group, so a camera, a push-to-talk handset, and a laptop on the same cell are policed independently.
{% endhint %}
## Traffic profile
| Workflow | Dominant direction | Per-device rate | Typical devices per site | Aggregate (typical) |
| ---------------------------- | ------------------------ | -------------------------------------------- | ------------------------ | -------------------- |
| Live Video Production | Uplink | 8–15 Mbps HD · 25–50 Mbps UHD | 4–16 cameras | 120–400 Mbps UL |
| Wireless Intercom & Talkback | Symmetric | 150–300 kbps per beltpack, always open | 20–300 beltpacks | 15–90 Mbps symmetric |
| AGV & AMR Fleet Control | Symmetric, small packets | 0.5–2 Mbps control · 4–8 Mbps optional video | 10–100 vehicles | 20–150 Mbps |
| Visual Daily Inspection | Uplink, bursty | 5–20 Mbps during capture | 5–50 capture points | 50–200 Mbps UL peak |
| Connected Worker PTT | Symmetric | 32–64 kbps per active talker | 50–500 handsets | < 15 Mbps |
| Asset & Forklift Tracking | Uplink, small packets | 5–50 kbps | 200–5,000 tags | < 20 Mbps |
| Jobsite Surveillance | Uplink | 4–12 Mbps per camera | 10–60 cameras | 80–400 Mbps UL |
| Drone Site Inspection | Uplink | 15–40 Mbps video · 100 kbps C2 | 1–6 aircraft | 30–200 Mbps UL |
| Campus Video Surveillance | Uplink | 3–10 Mbps per camera | 50–500 cameras | 200 Mbps–2 Gbps UL |
| AR Remote Expert Assist | Symmetric | 10–25 Mbps per session | 2–20 sessions | 40–300 Mbps |
## Latency, loss, and QoS mapping
| Workflow | One-way network latency | Jitter | Residual loss | Availability | Primary 5QI | Resource type |
| ---------------------------- | ----------------------------------- | ------------ | --------------- | ---------------------- | -------------------------------- | ---------------------------- |
| Live Video Production | < 20 ms | < 10 ms | 10-6 | 99.999% in show window | **71** (150 ms PDB) | GBR |
| Wireless Intercom & Talkback | < 30 ms | < 10 ms | 10-3 | 99.999% in show window | **1** (100 ms PDB) | GBR |
| AGV & AMR Fleet Control | < 10 ms | < 3 ms | 10-4 | 99.999% | **82 / 83** (10 ms PDB) | Delay-critical GBR |
| Visual Daily Inspection | < 100 ms | not critical | 10-6 | 99.9% | **4** or **72** | GBR |
| Connected Worker PTT | < 50 ms | < 20 ms | 10-2 | 99.99% | **65 / 66** | GBR |
| Asset & Forklift Tracking | < 100 ms telemetry · < 30 ms safety | < 20 ms | 10-6 | 99.99% | **70** telemetry · **84** safety | Non-GBR · Delay-critical GBR |
| Jobsite Surveillance | < 150 ms | < 40 ms | 10-4 | 99.9% | **72 / 76** | GBR |
| Drone Site Inspection | < 50 ms video · < 20 ms C2 | < 15 ms | 10-5 | 99.99% | **71** video · **84** C2 | GBR · Delay-critical GBR |
| Campus Video Surveillance | < 200 ms | < 50 ms | 10-6 | 99.9% | **72** or **6** | GBR · Non-GBR |
| AR Remote Expert Assist | < 20 ms | < 10 ms | 10-6 | 99.9% | **80** (10 ms PDB) | Non-GBR, low-latency eMBB |
### Reference: standardised 5QI values used above
| 5QI | Resource type | Priority | Packet delay budget | Packet error rate | 3GPP example service |
| --- | ------------------ | -------- | ------------------- | ----------------- | ---------------------------------------------- |
| 1 | GBR | 20 | 100 ms | 10-2 | Conversational voice |
| 2 | GBR | 40 | 150 ms | 10-3 | Conversational video (live streaming) |
| 4 | GBR | 50 | 300 ms | 10-6 | Non-conversational video (buffered streaming) |
| 6 | Non-GBR | 60 | 300 ms | 10-6 | Video (buffered streaming), TCP-based |
| 65 | GBR | 7 | 75 ms | 10-2 | Mission-critical user-plane push-to-talk voice |
| 66 | GBR | 20 | 100 ms | 10-2 | Non–mission-critical push-to-talk voice |
| 67 | GBR | 15 | 100 ms | 10-3 | Mission-critical video user plane |
| 70 | Non-GBR | 55 | 200 ms | 10-6 | Mission-critical data |
| 71 | GBR | 56 | 150 ms | 10-6 | Live uplink streaming |
| 72 | GBR | 56 | 300 ms | 10-4 | Live uplink streaming |
| 76 | GBR | 56 | 500 ms | 10-4 | Live uplink streaming |
| 80 | Non-GBR | 68 | 10 ms | 10-6 | Low-latency eMBB, augmented reality |
| 82 | Delay-critical GBR | 19 | 10 ms | 10-4 | Discrete automation |
| 83 | Delay-critical GBR | 22 | 10 ms | 10-4 | Discrete automation |
| 84 | Delay-critical GBR | 24 | 30 ms | 10-5 | Intelligent transport systems |
## TDD configuration by workflow mix
Private 5G in n77, n78, and n48 (CBRS) is TDD, so the uplink/downlink split is a design decision, not a given. The default downlink-weighted pattern is wrong for most of the workflows in this section — eight of the ten are uplink-dominant.
| Workflow mix | Suggested TDD pattern (2.5 ms period) | Approximate UL share |
| --------------------------------------- | ------------------------------------- | ---------------------------------------------- |
| Surveillance, inspection, tracking | `DDDSU` | \~20% |
| Mixed production and enterprise traffic | `DDSUU` | \~40% |
| Camera-heavy contribution, drone video | `DSUUU` | \~60% |
| AGV control with light video | `DDSUU` with short SSB periodicity | \~40%, latency-optimised |
| Full-duplex intercom, AR sessions | `DDSUU` | \~40%, symmetric — avoid uplink-heavy patterns |
{% hint style="warning" %}
All cells sharing a band at a site — and any neighbouring operator in the same band — must use the same TDD pattern and frame timing. Changing the uplink split for one workflow changes it for every workflow on that carrier. Where two workflows have incompatible splits, separate them onto different carriers rather than compromising both.
{% endhint %}
## Sizing rules of thumb
* **Size the uplink, then check the downlink.** For nine of the ten workflows here, the uplink is the binding constraint. A cell that comfortably delivers 600 Mbps downlink may offer only 100 Mbps uplink under a default TDD pattern.
* **Budget for cell-edge, not cell-centre.** Quote sustained rates at the modulation available at the worst planned coverage point, not at peak MCS. Device transmit power (typically 23 dBm) sets the uplink range, and it is well below the RU's downlink power.
* **Reserve GBR headroom.** Keep committed GBR flows below roughly 70% of the cell's uplink capacity so that retransmissions, mobility, and interference have room to absorb variation.
* **Count concurrent talkers for push-to-talk — but not for full-duplex intercom.** Push-to-talk scales with simultaneous active talkers, a small fraction of the fleet: two hundred handsets rarely exceed ten concurrent floor grants. Full-duplex broadcast intercom is the opposite. Every registered beltpack holds an open bidirectional path continuously, so a two-hundred-beltpack production is two hundred reserved GBR paths. Confusing the two models under-sizes an intercom deployment by more than an order of magnitude.
* **Treat firmware and backup traffic as a workflow.** Give it a low-priority non-GBR 5QI (8 or 9) and a schedule, or it will contend with production traffic at the worst possible moment.
## Related reading
* [Plan Your Network](https://docs.gxc.io/plan-your-network) — capacity planning, coverage principles, and RF fundamentals
* [5G Onyx Architecture Solution Brief](https://docs.gxc.io/docs/solution-briefs/5g-onyx-architecture-solution-brief) — platform components and functional capabilities
* [5G Onyx Shared Cell / Super Cell Architecture Solution Brief](https://docs.gxc.io/docs/solution-briefs/5g-onyx-shared-cell-super-cell-architecture-solution-brief) — handover-free mobility
---
# 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/network-requirements-at-a-glance.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.