> 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/construction-and-infrastructure/drone-site-inspection.md).
# Drone Site Inspection
## Overview
Drones have already changed how sites are surveyed. What has not kept up is the link. Most inspection flights still use a proprietary point-to-point radio between aircraft and controller, which ties the flight to line of sight from one operator position, keeps the video on the pilot's screen rather than in front of the people who need to see it, and offers no path to the aircraft from anywhere else.
Private 5G replaces that link with the site's own network. Video and telemetry arrive at the Onyx Edge and are distributed to whoever needs them — site office, remote engineer, client — in real time. Flights can be conducted from a fixed ground control station rather than from wherever the radio reaches. And because the network belongs to the site, coverage is designed for the flight envelope instead of being whatever the nearest public cell happens to provide at altitude.
The applications follow directly: structural and facade inspection, stockpile and earthworks volumetrics, progress capture from angles no fixed camera can hold, thermal survey of roofs and electrical infrastructure, and inspection of assets that would otherwise need scaffolding, a rope team, or a shutdown.
{% hint style="warning" %}
**Aviation regulation governs this workflow, and it governs it first.** Rules for command-and-control links, beyond-visual-line-of-sight operation, flights over people, and the use of cellular networks for C2 differ by jurisdiction and change frequently. Nothing on this page authorises an operation. Confirm the applicable national aviation authority's requirements, and hold the necessary approvals, before planning a flight around any network capability described here.
{% endhint %}
## How It Works
### Dual-bearer architecture
### What each component does
| Component | Role in this workflow |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| **Inspection aircraft** | Visual, thermal, or LiDAR payload, with a 5G module and antenna sited clear of the airframe |
| **Onyx RU** | The cell serving the flight envelope. Its antennas are **downtilted for ground users**, so the aircraft is served by sidelobes |
| **FHM / shared cell** | The aircraft crosses the site without handover, so neither video nor C2 suffers a handover gap |
| **Video bearer — 5QI 71** | GBR, 150 ms budget, 15–40 Mbps uplink. Bursty and large |
| **C2 bearer — 5QI 84** | Delay-critical GBR, 30 ms budget, 50–200 kbps symmetric. Small and time-critical |
| **Post-flight bearer — 5QI 8/9** | Non-GBR. 5–50 GB per flight, scheduled and out of the way of live traffic |
| **Onyx Edge** | Local breakout to the ground control station and to viewers; photogrammetry and volumetrics on site; imagery stays under site control |
| **Ground control station** | On the site network rather than tied to wherever a proprietary radio reaches |
| **Live viewers** | Site office, client, and the **remote engineer** — the capability that most changes how inspection works |
| **Onyx Portal** | Link performance logged per flight, so a degraded inspection is explained rather than guessed at |
### The flight path, hop by hop
| # | From → To | Interface | What happens |
| - | ---------------------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| 1 | Payload → *encode* | H.265 | Encoded **to the worst point in the envelope**, not to the camera's maximum |
| 2 | Aircraft → Onyx RU | **5G NR Uu**, two bearers | Video on 5QI 71; C2 and telemetry on 5QI 84. Separate, always |
| 3 | RU → FHM → Onyx Edge | eCPRI, aggregated fronthaul | No handover as the aircraft crosses the site |
| 4 | UPF → Ground control station | **N6 local breakout** | Pilot's C2 path, monitored independently of video |
| 5 | UPF → Live viewers | Local breakout + distribution | Remote engineer directs the pilot to positions of interest in real time |
| 6 | *Post-flight* | Non-GBR bulk upload | Full-resolution imagery transfers on a low-priority bearer |
| 7 | → Photogrammetry | On the edge | Point clouds, orthomosaics, stockpile volumes; findings tagged to asset and raised into the inspection or CMMS workflow |
**Running independently:** the aircraft's own link-loss failsafe — return to home, hover, or land. That, not the network, is the safety mechanism.
### Why air coverage is a separate design problem
Ground coverage does not imply air coverage, and this is the most consequential technical point on the page.
RU antennas are downtilted to serve users on the ground. An aircraft at 60 m is therefore served by **antenna sidelobes** — at lower gain, from further away, and from more cells simultaneously than a ground device would see. It both suffers more interference and causes more of it.
The practical consequence: **survey the envelope by flying it.** Fly a test profile with a logging device and record RSRP, SINR, and achievable uplink throughput through the volume. Identify altitudes and positions where coverage is marginal and treat them as no-stream zones or exclude them from the plan. A ground survey tells you nothing useful here.
### Why C2 and video never share a bearer
Video is bursty and large; C2 is small and time-critical. On a shared bearer, a 40 Mbps video burst delays the control message — and it does so at exactly the moment the aircraft is doing something demanding, because that is when the video bitrate peaks. Separate 5QIs, separate bearers, verified under full video load rather than in isolation.
## Network Requirements
| Parameter | Target |
| ----------------------------------- | ------------------------------------------------------------------------ |
| Uplink per aircraft, 1080p H.265 | 15–25 Mbps |
| Uplink per aircraft, 4K H.265 | 25–40 Mbps |
| Command-and-control telemetry | 50–200 kbps, symmetric |
| Aggregate, 4 concurrent aircraft | 60–160 Mbps uplink |
| Post-flight bulk upload | 5–50 GB per flight |
| One-way latency, video | < 50 ms |
| One-way latency, C2 | < 20 ms |
| Jitter | < 15 ms |
| Packet error rate | 10-5 |
| C2 link-loss tolerance | Aircraft-defined; typically 1–3 s before failsafe |
| Availability within flight envelope | 99.99% |
| Video QoS | **5QI 71** — GBR, live uplink streaming, 150 ms PDB, 10-6 PER |
| C2 QoS | **5QI 84** — delay-critical GBR, 30 ms PDB, 10-5 PER |
| Post-flight upload QoS | Non-GBR **5QI 8 / 9** |
| Altitude band to validate | Ground level to the ceiling of the intended envelope |
| TDD pattern | Uplink-weighted, `DSUUU` |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Establish what is permitted first
Confirm the authorisations required for the intended operation, including any specific approval to use a cellular network for command and control. Complete the operational risk assessment the jurisdiction requires. Confirm insurance and pilot competency for the specific operation.
{% endstep %}
{% step %}
### Define and survey the envelope
Lateral extent, altitude band, and the specific inspection positions where the aircraft will hover and stream at full rate — then fly it, as described above.
{% endstep %}
{% step %}
### Agree the flight plan with site management
Exclusion zones, crane and lifting operations, ground crew positions, and the conditions under which flying stops.
{% endstep %}
{% step %}
### Configure the network
Aerial subscriber group with two distinct bearers. Uplink-weighted TDD. Where the site permits, dedicate spectrum or a carrier to the flight window rather than contending with ground workflows during a critical inspection.
{% endstep %}
{% step %}
### Onboard the aircraft
5G module and SIM in Onyx Portal. Configure video encoding to the network budget. Put the ground control station on the site network through local breakout. **Verify link-loss behaviour by inducing loss, on the ground, before the first flight.**
{% endstep %}
{% step %}
### Pre-flight each time
Confirm coverage at the planned positions on the day — site structures change, and a facade in coverage last month may be shadowed by a new frame. Confirm weather, airspace, and site conditions against the agreed stop criteria. Brief ground crew. Verify the video path end to end to every intended viewer before the aircraft leaves the ground.
{% endstep %}
{% step %}
### Fly and monitor
The pilot monitors link quality continuously and aborts to the aircraft's safe behaviour on degradation, per the operating procedure.
{% endstep %}
{% step %}
### Process and compare
Photogrammetry on the edge; findings into the inspection or CMMS workflow. Compare against previous flights over the same profile — the value compounds when the profile is repeatable.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **5G-equipped inspection aircraft** — either a factory 5G option or an integrated module, with the antenna sited clear of the airframe.
* **Payloads** — high-resolution visual for facade and defect inspection; thermal for roofs, electrical assets, and heat loss; LiDAR where the deliverable is a point cloud rather than imagery.
* **Ground control station** — on the site network, reaching the aircraft through local breakout.
* **Remote viewing** — the site office, the client, and the remote engineer, all receiving the same live feed.
* **Photogrammetry and volumetrics** — hosted on the edge, producing orthomosaics, models, and stockpile volumes.
* **Inspection and CMMS integration** — so a finding becomes a work item rather than a note in a flight report.
* **Ground survey reference** — control points for volumetric accuracy where the output is used commercially.
## Design Considerations
**Regulation is the first design input, not a compliance step at the end.** What is permitted — particularly for beyond-visual-line-of-sight operation and for cellular command and control — determines the operation. Establish it before designing anything else.
**Air coverage is a separate design problem from ground coverage.** Downtilted antennas serve altitude through sidelobes. An aerial device sees more cells, at lower gain, from further away, and both suffers and causes more interference than a ground device. Survey the envelope by flying it.
**Never share a bearer between C2 and video.** This is the single most important network decision here. Video is bursty and large; C2 is small and time-critical. On a shared bearer, the video burst delays the control message. Separate 5QIs, separate bearers, verified under full video load.
**The aircraft's failsafe is the safety mechanism — not the network.** Design the network to keep the link up, and design the operation to be safe when it does not. Verify link-loss behaviour by inducing loss, on the ground, before the first flight, and again after any configuration change.
**Encode to the worst point in the envelope.** A stream configured for the camera's maximum will fail where coverage is weakest — which, on a facade or structural inspection, is precisely where the aircraft needs to be.
**Make the flight profile repeatable.** Most of the value in inspection is comparative: this month's facade against last month's, this week's stockpile against last week's. A repeatable profile makes comparison automatic; an improvised flight makes every inspection a one-off.
**Give post-flight upload its own low-priority path.** Fifty gigabytes moving off the aircraft after landing should not contend with a camera contribution feed or an AGV control loop. Non-GBR, scheduled, and out of the way.
## Validation Checklist
* [ ] Applicable aviation authorisations confirmed and held, including any approval for cellular C2
* [ ] Operational risk assessment completed and stop criteria agreed with site management
* [ ] Flight envelope defined with lateral extent, altitude band, and inspection positions
* [ ] Envelope surveyed **in the air**, with uplink throughput recorded through the volume
* [ ] Marginal-coverage positions identified and excluded or designated no-stream
* [ ] C2 and video on separate bearers; C2 latency verified under full video load
* [ ] C2 latency measured under 20 ms and video latency under 50 ms across the envelope
* [ ] Link-loss failsafe verified by induced loss, on the ground, before first flight
* [ ] Video encoding configured to the worst point in the envelope, not the camera maximum
* [ ] End-to-end video path verified to every intended viewer before takeoff
* [ ] Uplink-weighted TDD pattern configured; concurrent-aircraft load tested if more than one flies
* [ ] Post-flight bulk upload on a non-GBR bearer, verified not to affect live workflows
* [ ] Flight profile documented as repeatable, with control points where volumetric accuracy matters
* [ ] Coverage re-validated at each site phase boundary, as structures change the envelope
* [ ] Findings integration verified into the site inspection or CMMS workflow
## Related reading
* [Jobsite Surveillance & Progress Capture on 5G](/usecases-workflows/construction-and-infrastructure/jobsite-surveillance-and-progress-capture.md)
* [Visual Daily Inspection on 5G](/usecases-workflows/manufacturing/visual-daily-inspection.md)
* [Network Requirements at a Glance](/usecases-workflows/network-requirements-at-a-glance.md)
---
# 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/construction-and-infrastructure/drone-site-inspection.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.