> 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/campus-video-surveillance.md).
# Campus Video Surveillance
## Overview
Campus surveillance is a cabling problem wearing a security badge. Every camera on a hospital, university, airport, port, or corporate campus needs a cable run back to a switch, and the cost of a camera position is dominated by the civils — the trench across the car park, the conduit through the listed facade, the core drilled through a fire compartment. Positions that would improve coverage get dropped because the cable run cannot be justified, and the perimeter, the outbuildings, and the car parks end up under-covered precisely because they are furthest from the comms room.
Private 5G removes the cable from the equation for the positions where the cable is the problem. A camera needs power and coverage; where power is available and cable is not, the camera goes up in an afternoon. Where neither is available, a solar or battery position with a 5G link is still viable. Existing cabled cameras stay exactly where they are — this is an extension strategy, not a replacement one, and the practical deployment is nearly always hybrid.
What makes it work at campus scale is that the same network carries the rest of the campus estate: access control, emergency communications, connected building systems, and mobile workers. Surveillance justifies the network; everything else uses it.
## How It Works
### Hybrid topology
### What each component does
| Component | Role in this workflow |
| --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Existing cabled cameras** | Stay exactly where they are. This is an extension strategy, not a replacement one |
| **5G cameras** | The positions cable cannot reach economically — perimeter, car parks, service yards, outbuildings, inter-building routes. **Local storage** buffers against interruption |
| **Onyx RU** | Campus coverage, also serving patrol officers moving between buildings |
| **Mesh Node** | Wireless backhaul to outbuilding RUs where fibre would need civils |
| **FHM / shared cell** | Continuous coverage across open campus for mobile users, with no handover interruption |
| **Onyx Edge — 5G Core** | Per-group QoS: cameras on 5QI 72 or non-GBR 6; access control and building systems on their own class so cameras cannot starve a door controller |
| **Local breakout to the security VLAN** | Recording and analytics on campus; surveillance never traverses a public network |
| **Edge analytics** | Object and behaviour detection at the edge. **Events leave, video does not** |
| **Campus VMS** | Treats 5G cameras as ordinary IP cameras — from the VMS's perspective the transport is not special |
| **Onyx Portal** | Bulk provisioning of hundreds of camera SIMs, with per-camera diagnostics and alerting — no truck roll |
### The video path, hop by hop
| # | From → To | Interface | What happens |
| - | -------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| 1 | Camera → *encode + buffer* | H.265, local SD or onboard storage | 3–10 Mbps. The buffer is what converts an outage into a delayed upload rather than a gap |
| 2 | Camera → Onyx RU | **5G NR Uu**, uplink | On 5QI 72 for cameras whose stream must be continuous, or non-GBR 5QI 6 where a buffered stream is acceptable |
| 3 | RU → Onyx Edge | eCPRI, or Mesh Node backhaul for outbuildings | Aggregated into the shared cell |
| 4 | UPF → Security VLAN | **N6 local breakout** | Segmented from campus IT at the core — surveillance is its own security domain |
| 5 | *Edge analytics* | Object and behaviour detection | Centralising analytics for hundreds of cameras multiplies the traffic; edge inference sends **events**, not streams |
| 6 | → Campus VMS | IP | Recording, retrieval, and integration with access control |
| 7 | VMS → Control room | Operator interface | Monitor by exception rather than watching walls of video |
| 8 | VMS → Officer handheld | Over the same 5G network | Live views on patrol — only useful if outdoor and inter-building coverage was designed for it |
### Decide GBR per camera, not per system
A perimeter camera at a critical asset warrants a guaranteed bearer. A car park camera with a 24-hour local buffer does not. Mixing the two lets a campus support far more cameras per carrier than treating every camera as critical — and this is the decision that most affects how many positions a given spectrum allocation can carry.
**Aggregate uplink is the capacity question.** Two hundred cameras is roughly a gigabit of sustained uplink; five hundred approaches two. This is the most bandwidth-hungry workflow in this section by aggregate, and it needs carrier and spectrum planning to match — potentially multiple carriers across the campus.
### Why the hybrid framing matters commercially
Presented as a replacement for structured cabling, this invites an unwinnable comparison — cable is cheaper where cable already runs. Presented as the way to light up positions cable cannot reach economically, it is both accurate and where the return is.
Cost each proposed position two ways: cabled including civils and reinstatement, and 5G-connected. The comparison usually justifies the network on the hard-to-cable positions alone. And the advantage compounds: once the network exists, an additional camera position costs a camera and a mount, so positions that were previously uneconomic — a temporary construction compound, a car park extension, an event perimeter — become routine.
## Network Requirements
| Parameter | Target |
| ------------------------------------- | ------------------------------------------------------------ |
| Uplink per camera, 1080p H.265 | 3–6 Mbps |
| Uplink per camera, 4K H.265 | 8–10 Mbps |
| Aggregate uplink, 200 cameras mixed | \~1 Gbps |
| Aggregate uplink, 500 cameras mixed | up to \~2 Gbps |
| One-way network latency | < 200 ms |
| Jitter | < 50 ms |
| Packet error rate | 10-6 |
| Availability | 99.9%; higher for perimeter and critical-asset cameras |
| Local buffer at camera | Sized for the longest tolerable interruption, typically 24 h |
| Continuous-stream QoS | **5QI 72** — GBR, live uplink streaming, 300 ms PDB |
| Buffered-stream QoS | Non-GBR **5QI 6** — 300 ms PDB, 10-6 PER |
| Access control / building systems QoS | **5QI 70** or non-GBR **5QI 8** |
| TDD pattern | Uplink-weighted, `DDSUU` or `DSUUU` |
| Bands | n77, n78, n48 (CBRS), n40 |
## Deploying It
{% stepper %}
{% step %}
### Audit and cost
Identify the gaps in existing cabled coverage — almost always perimeter, car parks, service yards, outbuildings, and inter-building routes. Cost each proposed position both ways. Design radio coverage to camera positions **and** to the campus areas where mobile devices will be used.
{% endstep %}
{% step %}
### Configure the network
Onyx Edge in the campus data centre or security control room, local breakout to the security VLAN, uplink-weighted TDD. Surveillance group on 5QI 72 or non-GBR 6 per the per-camera decision above; separate groups for access control, building systems, and mobile workers.
{% endstep %}
{% step %}
### Segment at the core
Cameras are a well-known intrusion vector. Their own subscriber group, their own segment, SIM-based authentication, and no path to the general campus network.
{% endstep %}
{% step %}
### Deploy cameras
SIMs in Onyx Portal; record camera ID, position, and field of view in the security system's records. Specify local storage. Configure retention against legal and policy requirement. Configure analytics zones and rules.
{% endstep %}
{% step %}
### Integrate
5G cameras into the campus VMS as ordinary IP cameras. Analytics at the edge. Integrate with access control so a door event brings up the relevant camera, and with the campus incident workflow.
{% endstep %}
{% step %}
### Establish evidence handling
Incident footage retrieval, export, integrity verification, and chain of custody — defined before it is needed, since surveillance footage is used in disciplinary, insurance, and criminal proceedings.
{% endstep %}
{% step %}
### Govern privacy properly
Signage, retention limits, role-based access over who can view and export, a documented purpose, and a defined process for subject access requests. On a hospital or university campus this is not optional — confirm the requirements applicable to the campus and its jurisdiction before deployment.
{% endstep %}
{% step %}
### Document the expansion process
What it takes to add a position once the network exists. That is where the model's return accrues over time.
{% endstep %}
{% endstepper %}
## Devices & Ecosystem
* **Fixed 5G cameras** — perimeter, entrance, car park, and asset positions, with local storage as an interruption buffer.
* **PTZ cameras** — for large open areas under operator control.
* **Rapid-deploy and temporary positions** — event perimeters, construction compounds, and incident response, on solar or battery towers.
* **5G bridges for existing cameras** — a compact 5G unit backhauling one or several existing IP cameras, so a cable-fed cluster can be relocated without new civils.
* **VMS** — hosted on campus, treating 5G cameras identically to cabled ones.
* **Edge analytics** — object and behaviour detection running on the Onyx Edge or an adjacent GPU host.
* **Access control and building systems** — sharing the network on their own QoS class.
* **Security officer handhelds** — live views, incident capture, and push-to-talk on one device.
## Design Considerations
**This is a hybrid architecture, and should be designed as one.** Cabled cameras where cable already exists; 5G where it does not. Presenting it as a replacement for structured cabling invites an unwinnable comparison. Presenting it as the way to light up the positions that cable cannot reach economically is both accurate and where the return is.
**Aggregate uplink is the capacity question.** Two hundred cameras is a gigabit of sustained uplink. This is the most bandwidth-hungry workflow in this section by aggregate, and it needs carrier and spectrum planning to match — potentially multiple carriers across the campus.
**Use local storage to convert outages into delays.** A camera with a 24-hour buffer that uploads on reconnection produces a delayed record, not a missing one. For an evidentiary system, that distinction matters more than raw availability.
**Decide GBR per camera, not per system.** A perimeter camera at a critical asset warrants a guaranteed bearer. A car park camera with a local buffer does not. Mixing the two lets a campus support far more cameras per carrier than treating every camera as critical.
**Keep analytics at the edge.** Centralising analytics for hundreds of cameras multiplies the traffic the network has to carry. Edge inference keeps the video local and sends events rather than streams.
**Segment surveillance from campus IT.** Cameras are a well-known intrusion vector. Keep them in their own subscriber group, their own segment, and their own security domain, with SIM-based authentication and no path to the general campus network.
**Privacy governance is part of the deployment.** Signage, retention limits, access control over who can view and export footage, a documented purpose, and a defined process for subject access requests. On a hospital or university campus, this is not optional and it is not an afterthought — confirm the requirements applicable to the campus and its jurisdiction before deployment.
## Validation Checklist
* [ ] Existing cabled coverage audited and gaps identified
* [ ] Each proposed position costed both ways — cabled with civils, and 5G-connected
* [ ] Coverage designed to camera positions **and** to patrol routes, including between buildings
* [ ] Uplink-weighted TDD pattern configured; aggregate uplink capacity verified against full camera count
* [ ] Camera GBR/non-GBR classification decided per camera and documented
* [ ] All cameras streaming concurrently at configured bitrate, sustained
* [ ] Local camera storage sized and verified: an induced outage produces a delayed upload, not a gap
* [ ] Surveillance segmented from campus IT at the core; no path to the general network
* [ ] Access control, building systems, and mobile workers on separate QoS classes; camera load does not affect door events
* [ ] Edge analytics validated; event traffic, not video, leaves the edge
* [ ] VMS integration verified — 5G cameras behave as ordinary IP cameras
* [ ] Mobile live-view tested on patrol routes in real conditions
* [ ] Retention configured to policy; export and chain-of-custody procedure documented and tested
* [ ] Signage posted, access restricted by role, purpose documented, subject access process defined
* [ ] Expansion process documented — what it takes to add a position once the network exists
## Related reading
* [Jobsite Surveillance & Progress Capture on 5G](broken://pages/15c4a621379d405e094078d0e39bd66e57322959)
* [AR Remote Expert Assist on 5G](broken://pages/5b0e8103f6aceedf0c88c0cba77f82afa29a9736)
* [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/campus-video-surveillance.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.