> 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/jobsite-surveillance-and-progress-capture.md).
# Jobsite Surveillance and Progress Capture
## Overview
A construction site is the hardest environment a network gets asked to serve, and the one with the least infrastructure to serve it. There is no structured cabling, because the building that would carry it is what is being built. Power is temporary. The site layout changes every week, and so does the RF environment as steel goes up and concrete goes in. Fixed-line broadband, if it arrives at all, arrives late in the programme.
The usual answer is a collection of independent 4G cameras, each with its own SIM on a public network, each billed separately, each uploading to a different vendor's cloud. It works until the site gets busy — which is when the public cell serving the site gets congested by the same crowd of workers and deliveries — and it produces evidence that lives in five portals.
A private 5G network on the site is a single deployable asset that solves the whole problem: security cameras, progress capture, site Wi-Fi backhaul for the site office, connected plant, and worker communications on one network, under the contractor's control, with footage that stays on site. It moves as the site moves, and it goes up in the first weeks of the programme rather than the last.
## How It Works
### Site architecture
### What each component does
| Component | Role in this workflow |
| ------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Onyx Edge** | In the site office or a secure container. 5G Core, local breakout, VMS and edge analytics, and on-site recording. Footage never leaves the site |
| **RU on a tower crane** | Height and power, already there. Plan the succession — the crane comes down before the end of the job |
| **RU on a mast, cabled** | The stable position, where fibre can actually be pulled |
| **RU on the perimeter** | Where no conduit is possible, reached by **Mesh Node** wireless backhaul |
| **Mesh Node** | Wireless backhaul across an active site, removing trenching from the cost of a position |
| **Perimeter and gate cameras** | Continuous, on 5QI 72. This is the security case, and it matters most out of hours |
| **Progress capture cameras** | **Fixed framing for the entire programme.** Their value is comparability across the job |
| **Helmet and vehicle cameras** | Inspection, snagging, incident capture, tagged to location and works package |
| **Site office CPE** | Backhauls the site Wi-Fi, so office and camera networks share one connection |
| **Onyx Portal** | Camera and network diagnostics without a site visit — a construction site rarely has IT staff |
### The video path, hop by hop
| # | From → To | Interface | What happens |
| - | --------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | Camera → *encode* | H.265 | 4–12 Mbps per camera. Local storage buffers against network interruption |
| 2 | Camera → Onyx RU | **5G NR Uu**, uplink | On the Surveillance group's 5QI 72 bearer |
| 3 | RU → Onyx Edge | eCPRI, or **Mesh Node backhaul** where no conduit exists | Perimeter and outbuilding RUs reach the edge without trenching |
| 4 | UPF → VMS | **N6 local breakout** | Recording and analytics on site |
| 5 | *Edge analytics* | Zone rules | On an active site continuous motion is the normal state during working hours — useful alerting comes from **zone rules**, not motion |
| 6 | Alert → Security provider | Out-of-hours path | Where perimeter surveillance earns most of its return, given plant and material theft |
| 7 | Progress capture → Project record | Scheduled upload | Assembles into a time-lapse and a dated visual record against the programme |
### Coverage has a time dimension
This is what separates a construction network from every other workflow in this section. Every other page designs once for a fixed environment. Here the environment is under construction by definition, and the site at week 4 and the site at week 40 are different RF environments.
| Phase | What changes |
| ------------------------ | ------------------------------------------------------------------------------------------------------- |
| **Groundworks** | Open ground, long clear paths, few obstructions |
| **Structure** | The steel frame and concrete floors become the obstruction. **Coverage validated at week 4 fails here** |
| **Envelope and fit-out** | RUs relocate inside; the crane comes down and its RU needs a successor position |
| **Handover** | Demobilise to the next project — the network is a reusable asset, not a sunk cost |
Re-survey at every phase boundary, and build that trigger into the site's change-management process.
### Why the record is evidentiary from day one
Construction footage ends up in delay claims, variation disputes, and incident investigations. That changes the requirements: set retention from the contractual and legal need rather than a default, verify upload integrity, ensure timestamps are trustworthy, and define chain of custody before the first incident rather than after.
It is also why progress-capture positions must not move. The value of a progress record is comparability across the whole programme; a camera repositioned at week 20 splits the sequence into two incomparable halves, and its value in a dispute drops accordingly.
## Network Requirements
| Parameter | Target |
| ------------------------------------ | -------------------------------------------------------- |
| Uplink per fixed camera, 1080p H.265 | 4–8 Mbps |
| Uplink per fixed camera, 4K H.265 | 10–12 Mbps |
| Aggregate uplink, 40 cameras mixed | \~250 Mbps |
| Progress capture burst | 20–100 MB per capture point per event |
| Mobile capture uplink | 4–10 Mbps per device |
| One-way network latency | < 150 ms |
| Jitter | < 40 ms |
| Packet error rate | 10-4 |
| Availability | 99.9% overall; higher for perimeter cameras out of hours |
| Surveillance QoS | **5QI 72** — GBR, live uplink streaming, 300 ms PDB |
| Tolerant/bulk streams QoS | **5QI 76** — GBR, 500 ms PDB, or non-GBR **5QI 6** |
| Scheduled bulk upload QoS | Non-GBR **5QI 8 / 9** |
| TDD pattern | Uplink-weighted, `DDSUU` or `DSUUU` |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Plan coverage in phases against the construction programme
Identify when RUs will need to relocate. Confirm mast, crane, and container-mount positions with power availability, and plan the crane RU's succession.
{% endstep %}
{% step %}
### Fix the capture point design
Perimeter and access control; progress capture with framing locked for the programme; activity and safety at lifting zones, excavations, and edge protection; mobile capture for inspections and snagging.
{% endstep %}
{% step %}
### Deploy the network
Onyx Edge in the site office or a secure container with local breakout. Uplink-weighted TDD — this workflow is almost entirely uplink. Surveillance group on 5QI 72 or 76, with a lower-priority non-GBR bearer for scheduled bulk upload. Mesh Node backhaul to RU positions cable cannot reach. Confirm spectrum authorisation.
{% endstep %}
{% step %}
### Onboard cameras
SIMs in Onyx Portal; record camera position and view in the site record. Specify local storage so an interruption produces a delayed upload rather than a gap. Configure retention against the contract and legal requirement. Configure zone-based analytics rules.
{% endstep %}
{% step %}
### Fit local UPS at RU and camera positions
Temporary site power gets isolated, tripped, and rerouted; UPS prevents a fifteen-minute power event becoming a fifteen-minute gap in the perimeter record.
{% endstep %}
{% step %}
### Post signage and consult
Site surveillance records workers as well as intruders. Define retention and access, restrict who can view footage and for what purpose, and confirm the approach against local privacy and employment obligations.
{% endstep %}
{% step %}
### Relocate and re-survey
As the structure progresses. At handover, either demobilise to the next project or transition to the completed building's permanent network, and archive the visual record with the handover documentation.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **Fixed 5G cameras** — perimeter, progress, and activity positions; IP66-rated, with local storage as a buffer against network interruption.
* **PTZ cameras** — for large open areas and for security operator control out of hours.
* **Rapid-deploy CCTV towers** — solar or generator-powered mobile units with an integrated 5G link, for perimeter positions with no power.
* **Helmet and vehicle cameras** — inspection, snagging, and incident capture.
* **5G CPE for the site office** — backhauling site Wi-Fi, so the office network and the camera network share one connection.
* **Connected plant telematics** — excavators, dumpers, and lifting equipment reporting utilisation and location over the same network.
* **VMS and analytics** — hosted on Onyx Edge; edge analytics avoids streaming everything off site to be analysed.
* **Progress capture platform** — assembling scheduled captures into a time-lapse and a dated project record.
## Design Considerations
**Design for a moving site.** This is the defining constraint. Every other workflow in this section designs once for a fixed environment. Here, the environment is under construction by definition. Plan coverage in programme phases, budget for RU relocation, and re-survey after every significant structural milestone.
**The structure will block the coverage that worked last month.** A steel frame and concrete floors are effective RF obstructions. Coverage validated across open ground during groundworks tells you nothing about coverage once the frame is up. Re-validate at each phase boundary.
**Uplink is essentially all of it.** Forty cameras streaming uplink and almost nothing coming down. Configure the TDD pattern accordingly, and quote camera bitrates at the modulation achievable at the worst camera position, not at the best.
**Keep progress capture positions fixed for the whole programme.** The record's value is comparability. A repositioned camera at week 20 splits the sequence into two incomparable halves, and its value in a dispute drops accordingly.
**Treat the footage as evidence from day one.** Construction footage ends up in delay claims, variation disputes, and incident investigations. Set retention from that requirement, verify upload integrity, ensure timestamps are trustworthy, and define chain-of-custody before the first incident rather than after.
**Power is less reliable than the network.** Temporary site power gets isolated, tripped, and rerouted. Local UPS at RU and camera positions prevents a fifteen-minute power event from becoming a fifteen-minute gap in the perimeter record.
**Signage and consultation are not optional.** Site surveillance records workers as well as intruders. Post signage, define retention and access, restrict who can view footage and for what purpose, and consult with the workforce. Confirm the approach against local privacy and employment obligations before deployment.
**Cost the network as a reusable asset.** Compared against per-camera public data plans across a multi-year programme, a private network that then moves to the next project changes the business case substantially. Make that comparison explicitly.
## Validation Checklist
* [ ] Coverage planned in phases against the construction programme, with relocation points identified
* [ ] RU positions confirmed with power availability and mounting, including crane succession planning
* [ ] Spectrum authorisation in place for the site
* [ ] Uplink-weighted TDD pattern configured
* [ ] All cameras streaming concurrently at configured bitrate for a sustained period
* [ ] Camera bitrates validated at the worst planned camera position, not the best
* [ ] Progress-capture positions fixed and documented; framing recorded for the programme duration
* [ ] Retention period set from contractual and legal requirement, not left at default
* [ ] Upload integrity verified; timestamp source trustworthy; chain-of-custody documented
* [ ] Analytics zone rules configured — alerting is zone-based, not motion-based
* [ ] Out-of-hours alerting path to the security provider tested
* [ ] Local UPS at RU and camera positions; a simulated power event produces no gap in the record
* [ ] Mobile capture validated on an inspection walk-through of the full site
* [ ] Signage posted, access restricted, and workforce consultation completed
* [ ] Re-survey scheduled at each programme phase boundary
* [ ] Demobilisation and redeployment plan agreed as part of the business case
## Related reading
* [Drone Site Inspection on 5G](broken://pages/a78ef429ef3774489c6a5d748a3d5d48a30388b4)
* [Campus Video Surveillance on 5G](broken://pages/b49f69b2014544828b93e4ef2e42847c36f0a9ac)
* [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/construction-and-infrastructure/jobsite-surveillance-and-progress-capture.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.