> 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/enterprise-and-campus/ar-remote-expert-assist.md).
# AR Remote Expert Assist
## Overview
Specialist expertise is scarce, and it is almost never in the same building as the problem. A machine goes down, and the person who understands it is three time zones away. The options are to fly them in — losing a day or a week of production — or to talk the local technician through it on a phone call, which works about as well as describing a knot over the radio.
Remote expert assist replaces the phone call with shared sight. The technician wears a headset or holds a tablet; the expert sees exactly what they see, in real time, and annotates it — drawing on the actual component, placing an arrow on the actual valve, overlaying the schematic on the actual panel. The annotation stays anchored to the object as the technician moves. Hands stay on the work.
This is the workflow with the tightest latency requirement in this section, and the reason is human perception rather than machine control. An annotation that lags the technician's head movement does not merely feel wrong; it induces discomfort within minutes and the headset comes off. The 10 ms packet delay budget of the low-latency eMBB QoS class exists for exactly this class of application, and it is only achievable with the rendering and session infrastructure on the edge, next to the radio.
## How It Works
### The latency chain
### What each component does
| Component | Role in this workflow |
| --------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| **Headset or tablet** | The technician's endpoint at the asset. Captures the live view, displays annotations anchored to real components |
| **Onyx RU** | Coverage where the equipment is — plant rooms, machine halls, basements, roof plant. Rarely where coverage is best |
| **FHM / shared cell** | The technician walks around the machine without handover, so the spatial anchor and the session hold |
| **Onyx Edge — 5G Core** | 5QI 80: non-GBR low-latency eMBB with a **10 ms** packet delay budget — the 3GPP class defined for augmented reality |
| **Session and rendering service** | **On the Onyx Edge.** This is the component that makes the budget achievable at all |
| **Expert workstation** | On site, at a regional support centre, or at a vendor's support desk |
| **Content library** | Pre-authored overlays — schematics, exploded views, work instructions, torque specifications |
| **CMMS / EAM** | Sessions and outcomes recorded against the asset |
| **Onyx Portal** | Latency, jitter, and throughput per session, so a poor session is diagnosed rather than tolerated |
### The session path, hop by hop
| # | From → To | Interface | What happens |
| - | ------------------------ | --------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| 1 | Technician → Headset | Camera + IMU | Live view captured; head pose tracked |
| 2 | Headset → Onyx RU | **5G NR Uu**, symmetric | 10–25 Mbps per session on the 5QI 80 bearer. Roughly balanced up and down, unlike most workflows here |
| 3 | RU → Onyx Edge | eCPRI, aggregated fronthaul | No handover as the technician moves around the asset |
| 4 | UPF → Session service | **N6 local breakout** | Session and rendering on the appliance beside the core |
| 5 | Session service → Expert | IP | Expert receives the technician's live view |
| 6 | Expert → *annotates* | Annotation on the shared spatial anchor | Arrows, outlines, and text attached to real components |
| 7 | → Rendered at the edge | Composition | Overlay composed against the current head pose |
| 8 | → Headset | Downlink on the same bearer | Annotation appears anchored to the object and stays anchored as the technician moves |
### The budget, stage by stage
| Stage | Typical contribution |
| ----------------------------- | ------------------------------------------------- |
| Capture | 3–5 ms |
| 5G uplink | 4–6 ms |
| Edge render | 3–6 ms |
| 5G downlink | 4–6 ms |
| Display | 2–4 ms |
| **Motion-to-photon** | **< 20 ms** |
| End-to-end annotation latency | < 100 ms from expert action to technician display |
### Why 20 ms is a threshold, not a target
Above roughly 20 ms motion-to-photon, users report discomfort within minutes and the headset comes off. This is not a quality target that can be traded for capacity — it is the point at which the workflow stops being used, and everything else on this page is subordinate to it.
Which is why edge rendering is not an optimisation here. A wide-area round trip to a cloud region consumes the entire budget before any processing happens. If the session and rendering infrastructure cannot be hosted on the Onyx Edge, the right answer is a **tablet-based workflow with a relaxed budget** — not a headset experience that will be rejected.
**A tablet delivers most of the value anyway.** It works everywhere, needs no head-mounted hardware in a hard-hat area, and removes the motion-to-photon constraint almost entirely. Start with tablets; add headsets where hands-free is genuinely required.
## Network Requirements
| Parameter | Target |
| --------------------------------- | ----------------------------------------------------------------------------------- |
| Per-session throughput | 10–25 Mbps, roughly symmetric |
| Aggregate, 10 concurrent sessions | 100–250 Mbps |
| One-way network latency | < 20 ms |
| Motion-to-photon latency | < 20 ms for headset-rendered content |
| End-to-end annotation latency | < 100 ms from expert action to technician display |
| Jitter | < 10 ms |
| Packet error rate | 10-6 |
| Availability during a session | 99.9% |
| AR QoS | **5QI 80** — non-GBR, low-latency eMBB, 10 ms PDB, 10-6 PER, priority 68 |
| Conversational video QoS | **5QI 2** — GBR, 150 ms PDB |
| Voice QoS | **5QI 1** — GBR, 100 ms PDB |
| TDD pattern | Symmetric or lightly uplink-weighted, `DDSUU` |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Define eligible procedures
Identify where the workflow pays — high-value assets where downtime is expensive, procedures needing rarely-available expertise, commissioning and acceptance. Then define which procedures are approved for remote support and which require physical attendance regardless. That is a competence and safety decision, agreed with plant safety before deployment, so the boundary is not decided under pressure during a breakdown.
{% endstep %}
{% step %}
### Prepare content
Schematics, exploded views, work instructions, torque specifications, safety procedures. Live annotation is the baseline; pre-authored overlays are where the return multiplies, because they work without an expert on the call.
{% endstep %}
{% step %}
### Deploy on the edge
Session and rendering infrastructure on the Onyx Edge. AR subscriber group on 5QI 80, with 5QI 2 for the conversational video component and 5QI 1 for voice. Symmetric or lightly uplink-weighted TDD — AR carries substantial traffic both ways.
{% endstep %}
{% step %}
### Design coverage to the equipment
Plant rooms, machine halls, roof plant, basements. Survey those, not the office floor.
{% endstep %}
{% step %}
### Onboard devices
SIMs for headsets and tablets in Onyx Portal. Configure the connection to the on-site session service and to the expert endpoint — on site, at a regional centre, or at a vendor's support desk.
{% endstep %}
{% step %}
### Define the external expert path deliberately
Live video of production equipment leaving the site to a vendor's support desk is a security and commercial decision. Define the path, the authentication, the recording policy, and what the external party may retain — before the first session, not during an outage.
{% endstep %}
{% step %}
### Run sessions and record them
The technician works hands-free; the expert confirms each step visually rather than by description. Where a procedure exceeds remote support it escalates to attendance — with the diagnosis already complete, which is a saving even when travel still happens. Record findings and actions against the asset in the CMMS.
{% endstep %}
{% step %}
### Build the library
Each session is content. Recorded sessions and authored overlays accumulate until later technicians complete the same procedure without an expert on the call. Budget authoring time from the start and name an owner — this is where the largest return sits.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **AR headsets** — hands-free, and where the environment demands it, intrinsically safe or hard-hat mounted.
* **Rugged 5G tablets** — the pragmatic alternative where a headset is impractical or unwelcome; most of the value at a fraction of the friction.
* **Remote expert platform** — session management, annotation, and recording, hosted on Onyx Edge.
* **Expert workstation** — on site, at a regional support centre, or at a vendor's support desk.
* **Content authoring** — for pre-built overlays, work instructions, and 3D models.
* **CMMS / EAM integration** — sessions and outcomes recorded against the asset.
* **Digital twin or 3D model source** — where overlays are generated from engineering models rather than authored by hand.
## Design Considerations
**The latency budget is a human factors requirement.** Above roughly 20 ms motion-to-photon, users report discomfort, and headsets come off. This is not a quality target that can be relaxed for capacity; it is the threshold at which the workflow stops being used. Everything else on this page is subordinate to it.
**Edge rendering is what makes the budget achievable.** The wide-area round trip to a cloud region consumes the entire budget before any processing happens. The session and rendering infrastructure must be on the Onyx Edge. If it cannot be, choose a tablet-based workflow with a relaxed budget instead of shipping a headset experience that will be rejected.
**Coverage where the equipment is.** Plant rooms, machine halls, basements, and roof plant are where this workflow happens and where coverage is typically weakest. Survey those, not the office floor.
**AR is symmetric; most of this site's workflows are not.** A campus TDD pattern optimised for surveillance uplink will handicap the downlink that carries annotations and overlays. Where AR is a primary workflow, plan the TDD split for it — and where it shares a carrier with heavy uplink workflows, verify the AR session under that load rather than in isolation.
**A tablet delivers most of the value.** Headsets are better when they fit the environment and the technician accepts them. Tablets work everywhere, need no head-mounted hardware in a hard-hat area, and remove the motion-to-photon constraint almost entirely. Start with tablets, add headsets where hands-free is genuinely required.
**Design the external expert path deliberately.** Live video of production equipment leaving the site to a vendor's support desk is a security and commercial decision. Define the path, the authentication, the recording policy, and what the external party may retain — before the first session, not during an outage.
**The library is the compounding return.** Live assist saves a trip. A library of recorded sessions and authored overlays saves the call. Budget authoring time from the start, and treat each session as an opportunity to add to it.
**Approve procedures explicitly.** Some work requires a qualified person physically present regardless of how good the video is. Define which procedures are eligible for remote support with plant safety and competence management before deployment, so the boundary is not decided under pressure during a breakdown.
## Validation Checklist
* [ ] Eligible procedures defined and approved with plant safety and competence management
* [ ] Session and rendering infrastructure deployed on Onyx Edge, not in a cloud region
* [ ] Motion-to-photon latency measured under 20 ms at the furthest working position
* [ ] End-to-end annotation latency measured under 100 ms
* [ ] AR traffic on 5QI 80; session quality verified concurrently with the site's other workflows at full load
* [ ] TDD pattern validated for symmetric traffic, or AR session verified under the uplink-heavy pattern in use
* [ ] Coverage validated in plant rooms, machine halls, basements, and roof plant
* [ ] Spatial anchoring verified while the technician moves around the asset — no anchor drift, no session loss
* [ ] Concurrent-session load tested at the planned maximum
* [ ] Headset suitability confirmed for the environment, including hard-hat and any hazardous-area requirement
* [ ] Tablet fallback path validated for positions where headsets are impractical
* [ ] External expert path defined, authenticated, reviewed, and retention policy agreed
* [ ] Session recording policy agreed, including consent where the technician is recorded
* [ ] CMMS integration verified — sessions and outcomes recorded against the asset
* [ ] Content authoring process and owner identified for the overlay library
## Related reading
* [Visual Daily Inspection on 5G](broken://pages/73a08cefa3f4fc438d6e2f741c95a2c639881ee2)
* [Campus Video Surveillance on 5G](broken://pages/020a11e7ac5353c6c98f200247ad8867caf03ca4)
* [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/enterprise-and-campus/ar-remote-expert-assist.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.