> 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/introduction.md).
# Introduction
Every workflow in this section runs on the same GXC Onyx private 5G platform. What changes between them is not the radio - it is the **acceptance criteria**.
A broadcast camera needs 25 Mbps of *sustained uplink* inside a 200 ms glass-to-glass budget. An AGV needs 2 Mbps inside a *10 ms* budget with no handover gap. Those two requirements produce different TDD patterns, different QoS policies, and different RU layouts on the same hardware. These pages document that difference, workflow by workflow.
## How to read a workflow page
Every page follows the same structure, so you can compare workflows directly. The first half answers *how it works*; the second answers *how to deploy it*.
| Section | What it answers |
| -------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **Overview** | What the workflow replaces, and why private 5G is the right transport for it |
| **How It Works** | |
| · Reference architecture | A diagram of what connects to what |
| · What each component does | One line per block in the diagram |
| · The path, hop by hop | Every hop from source to destination - the actual interface at each one, and what happens there |
| · Where the latency goes | The end-to-end budget broken down by stage |
| · The decision that defines the design | The one architectural choice that determines whether the deployment works |
| **Network Requirements** | Throughput, latency, jitter, loss, availability, and 3GPP 5QI mapping |
| **Deploying It** | The sequence that gets it running, from survey to teardown |
| **Devices & Ecosystem** | The endpoint and application classes that terminate the workflow |
| **Design Considerations** | The decisions that determine whether the deployment succeeds |
| **Validation Checklist** | What to measure before you declare the workflow production-ready |
Every diagram is also kept as an editable draw\.io source alongside the published page.
## Workflows by industry
### Broadcast & Live Events
{% content-ref url="/pages/208b0990886c6de7e8838aa524c5e99f027f5329" %}
[Live Video Production](/usecases-workflows/events-and-venues/live-video-production.md)
{% endcontent-ref %}
{% content-ref url="/pages/795dd0eef72cd3b796a5c94566fc948075f49152" %}
[Wireless Intercom and Talkback](/usecases-workflows/events-and-venues/wireless-intercom-and-talkback.md)
{% endcontent-ref %}
### Manufacturing
{% content-ref url="/pages/213c64ae32689da21c39aeeef57b60aba0554ea5" %}
[AGV and AMR fleet control](/usecases-workflows/manufacturing/agv-and-amr-fleet-control.md)
{% endcontent-ref %}
{% content-ref url="/pages/93a199c90de5f59c226338b486f9685977241b0a" %}
[Visual Daily Inspection](/usecases-workflows/manufacturing/visual-daily-inspection.md)
{% endcontent-ref %}
### Construction & Infrastructure
{% content-ref url="/pages/180c5b2ff112799b46bec3344de0a7668755fc43" %}
[Drone Site Inspection](/usecases-workflows/construction-and-infrastructure/drone-site-inspection.md)
{% endcontent-ref %}
{% content-ref url="/pages/9b51d9ffca6664ef7729462cc2a3f11a4c7af351" %}
[Jobsite Surveillance and Progress Capture](/usecases-workflows/construction-and-infrastructure/jobsite-surveillance-and-progress-capture.md)
{% endcontent-ref %}
### Enterprise & Campus
{% content-ref url="/pages/1e019997f70561d4c085c6b1394ffc8c2aa78c30" %}
[AR Remote Expert Assist](/usecases-workflows/enterprise-and-campus/ar-remote-expert-assist.md)
{% endcontent-ref %}
{% content-ref url="/pages/7eba8621bdc759cdf827635281c796818c5425e8" %}
[Campus Video Surveillance](/usecases-workflows/enterprise-and-campus/campus-video-surveillance.md)
{% endcontent-ref %}
## The three properties that carry every workflow
Across all ten workflows, the same three platform properties do the heavy lifting.
**Local breakout at the edge.** Onyx Edge integrates the 5G Core with the CU and DU in a single on-site appliance. Application traffic never leaves the site, so the latency budget is set by the radio and the application - not by a backhaul link to a regional data centre. For AGV control and live talkback, this is the difference between working and not working.
**Shared cell, not many cells.** The Onyx shared-cell architecture presents multiple RUs as a single logical cell under one DU. Devices moving across a factory floor, a warehouse aisle, or an outside broadcast compound do not perform inter-cell handover, because there is no cell boundary to cross. Handover gaps are the most common cause of dropped video frames and stalled AGVs - this architecture removes the failure mode rather than tuning around it.
**Per-workflow QoS.** Onyx maps each application to a 3GPP 5QI with its own priority, packet delay budget, and error rate. A camera contribution flow, a push-to-talk floor grant, and a bulk firmware download share the same spectrum without competing for it. The [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md) page lists the mapping for every workflow in this section.
## Where to go next
These pages describe what each workflow *demands* of a network. Turning that into a design - a radio count, an architecture, and a bill of materials - is the subject of the Getting Started section.
| Next | Why |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| [**Plan Your Network**](https://docs.gxc.io/plan-your-network) | Take a workflow's requirements through Capacity → Coverage → Architecture → Accessories to a preliminary BoM |
| [**Is Onyx right for you?**](https://docs.gxc.io/is-onyx-right-for-you) | Check the fit before designing - private cellular against Wi-Fi, and LTE against 5G |
| [**Private 5G Spectrum**](https://docs.gxc.io/private-5g-spectrum) | Which band you can obtain, and what channel bandwidth it gives you to work with |
| [**Deploy Your First Network**](https://docs.gxc.io/deploy-your-first-network) | The sequence from installed hardware to a network carrying the workflow |
| [**End Devices**](https://docs.gxc.io/devices) | Whether the endpoints a workflow depends on support your band |
Where a workflow's requirements are tighter than a single cell can deliver, the [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) covers how multiple RUs combine into one logical cell.
## Contact GXC
To get in touch with GXC, please visit .
---
# 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/introduction.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.