Engineering an 800-Camera Campus Video System with TCB Alpha VMS

Reference requirements and design assumptions

This design assumes 800 IP cameras distributed across several campus buildings, parking areas, entrances, service areas, and perimeter locations. Buildings are interconnected by fiber. The baseline calls for continuous recording, 30 days of retention, a measured average main-stream bitrate of 4 Mb/s, a lower-bitrate viewing stream from each camera, centralized camera administration, and authenticated viewing from a security center and approved remote devices.

The final design must replace every assumption with a camera schedule and site survey. Resolution, frame rate, codec, scene motion, nighttime noise, analytics, audio, retention, evidence requirements, fiber routes, power, rack space, cooling, and failure tolerance all affect the result. Camera count alone is not an acceptance criterion.

• Full-quality main stream: sized for recording and evidence, preferably copied without continuous transcoding.
• Substream: sized for multi-camera layouts, remote browsers, mobile users, and health previews.
• Time source: redundant campus NTP with camera, recorder, database, access, and alarm timelines aligned.
• Availability target: local recording continues when a building loses its campus uplink, provided local power and equipment remain available.
• Security boundary: no camera administration page, ONVIF service, or RTSP endpoint is directly exposed to the public internet.

Campus architecture at a glance

Twenty or more managed PoE access switches connect the cameras in building and outdoor telecommunications spaces. Each camera network routes only to its assigned TCB recorder, approved management services, time and monitoring services, and explicitly authorized failover paths. Eight primary Linux recording nodes each target approximately 100 cameras. Two failover nodes provide temporary ingest capacity while a failed primary is repaired.

A redundant pair of campus core switches connects building distribution, recording cells, the security operations network, and central Alpha VMS services. The central layer maintains the camera registry, users, roles, layouts, health, incidents, and federated playback references without requiring every full-resolution stream to pass through one management server continuously.

Place cameras into operational classes

Not all 800 cameras should receive identical settings. Interior overview cameras, entrances, cash or transaction areas, parking lanes, license-plate positions, loading areas, thermal cameras, PTZ units, and perimeter views have different evidence goals. Each camera record should identify its purpose, expected subject distance, required image detail, lighting conditions, frame rate, bitrate range, retention, audio policy, privacy constraints, analytics, and nearby events.

Critical identification and license-plate cameras may require higher bitrates or specialized streams. Quiet interior overview cameras may require less. Variable bitrate can save storage, but busy scenes, trees, rain, snow, low-light noise, or frequent vehicle movement can increase the average. The storage model therefore uses observed bitrate from representative scenes and preserves margin for seasonal and configuration changes.

Bandwidth and storage model

For continuous recording, one megabit per second produces approximately 10.8 gigabytes per day. At the 4 Mb/s planning average, 800 cameras create 3.2 Gb/s of main-stream ingest, 34.56 TB per day, and approximately 1.04 PB over 30 days. These are decimal planning values before filesystem use, array protection, indexes, exports, rebuild reserve, and operating headroom.

The engineering design should reserve at least 20 to 30 percent network headroom and avoid operating storage pools at their theoretical maximum. Main streams stay within their local recording cells during normal operation, so the campus core is not forced to carry all 3.2 Gb/s to one central recorder. The core still needs sufficient capacity for viewing, playback, replication where selected, management, and temporary failover ingest.

Build eight independent recording cells

Each primary recording node is assigned a target of approximately 100 cameras, normally grouped by building or geographic zone. At the 4 Mb/s baseline, one cell ingests about 400 Mb/s and writes approximately 4.32 TB per day, or 129.6 TB over 30 days. A node should be accepted by measured bitrate and tested workload rather than allowed to exceed its limits merely because the database permits another camera record.

A practical storage reference for each cell is twelve 20 TB enterprise or surveillance-class drives in dual-parity protection, installed in a chassis with room for a hot spare and future service capacity. Twelve active drives provide 240 TB raw and approximately 200 TB before filesystem overhead under a two-drive parity model. Reserving 15 percent for operations leaves roughly 170 TB, which supports the 129.6 TB baseline with meaningful variation and rebuild margin. Final usable capacity depends on the actual controller, filesystem, units, spare policy, and protection scheme.

Each recorder should also use mirrored enterprise SSDs for the operating system, application, database cache or local indexes as appropriate; redundant power supplies; monitored fans and temperatures; and dual network interfaces. Two 10 Gb/s links provide ample normal ingest capacity and a maintenance path, while CPU and memory are sized from the tested media pipeline. A GPU is optional for selected analytics or transcoding—not required merely to copy supported encoded streams to storage.

• Target normal CPU, memory, disk, and network utilization below tested saturation thresholds, with at least 25 percent capacity margin.
• Keep camera assignment and local recording state in the Alpha VMS registry so a failed group can be rehomed deliberately.
• Use RAID or equivalent protection for availability, but export critical evidence and back up configuration because RAID is not a backup.
• Keep replacement drives, a validated system image, configuration backups, and documented recorder replacement procedures available.

Engineer the fiber and camera networks for failure containment

Use routed building boundaries or tightly controlled VLANs rather than one campus-wide camera broadcast domain. Cameras in each building connect to managed PoE switches, which connect through redundant 10 Gb/s fiber uplinks to building distribution or the campus core. Large outdoor or parking groups can terminate in weather-appropriate field cabinets with protected power, environmental monitoring, and redundant fiber routes where the consequence justifies them.

The campus core should use two independent switches with 40 or 100 Gb/s interconnect and uplinks appropriate to the number of buildings and failover paths. Where possible, fiber paths should be physically diverse; two strands in the same conduit do not protect against a single excavation or fire. Layer-3 routed links reduce the blast radius of loops and broadcast faults, while dynamic routing or an equivalent tested design provides controlled path recovery.

Normal camera traffic should remain local to its assigned recorder. If one recorder fails, one of the two failover nodes can temporarily ingest that cell across the fiber network. Network calculations must prove that a building uplink, core path, failover recorder, and storage target can carry the extra approximately 400 Mb/s baseline plus viewing and safety margin during that condition.

• Separate camera, recorder, management, viewing, storage, and general business traffic with mapped, enforced data flows.
• Permit cameras to reach only required recorder, time, name, update, and monitoring services.
• Monitor optical power, errors, discards, link changes, PoE draw, UPS runtime, cabinet temperature, and switch configuration drift.
• Document every fiber pair, patch panel, switch port, camera, recorder assignment, and alternate route.

Keep remote viewing out of the recording path

Alpha VMS separates continuous recording from operator delivery. Recorders maintain the evidentiary main streams. Viewing gateways authenticate users, enforce campus and camera permissions, and deliver the selected live or recorded material to browser, mobile, desktop, or video-wall clients. An operator opening a 64-camera layout should normally receive appropriately sized substreams, not 64 full-resolution recording streams.

For example, 64 substreams averaging 0.5 Mb/s require about 32 Mb/s before protocol overhead, while 64 main streams at 4 Mb/s require 256 Mb/s and far more client decoding. Alpha VMS can request main-stream detail when the operator selects a camera, reviews an incident, or exports evidence. Limits on simultaneous views, playback jobs, and exports protect recording and shared network resources.

Remote users connect to the authenticated VMS service through an approved secure access path. They do not receive direct public access to camera web interfaces, ONVIF endpoints, or RTSP ports. Use multifactor authentication where appropriate, role-based camera access, short sessions for shared stations, audit history, and separate privileges for live view, playback, export, configuration, and system administration.

Design availability at every layer

A building fiber outage should isolate central viewing but not stop its local recording cell. A failed access switch affects only its attached camera group. A failed recorder triggers alarms and a controlled reassignment to one of two failover nodes when network paths remain available. The failover nodes need enough local buffer storage for the repair objective; they do not need to duplicate the entire campus retention archive unless the business requires that level of redundancy.

Central Alpha VMS application nodes run as a redundant service pair. The metadata database uses a primary and replica with tested backups and restore procedures. Viewing gateways are replaceable and horizontally expandable. Configuration, credentials, camera assignments, layouts, event mappings, and indexes receive separate protection from bulk video storage.

Power design includes per-closet PoE budgets, UPS runtime, monitored power distribution, generator coverage where required, orderly shutdown behavior, and startup sequencing. Cooling is calculated from switches, PoE losses, servers, and storage—not assumed from room size. Environmental, power, disk, stream, service, and time-synchronization alerts feed one health view with documented ownership and escalation.

Use ONVIF, RTSP, and MQTT as clear integration boundaries

TCB validates each camera model and firmware against the required ONVIF Profile T capabilities, RTSP main and substreams, codecs, keyframe behavior, authentication, reconnect behavior, timestamps, PTZ, audio, and events. ONVIF Profile M metadata can add standardized analytics events where supported. Cameras that are not formally conformant may still offer a usable RTSP stream, but every exception becomes a documented supported integration rather than an assumption.

MQTT carries normalized operational events rather than continuous video. Door access, alarms, help points, analytics, and other property systems can publish events with campus, building, device, time, severity, and correlation data. Alpha VMS associates those events with nearby cameras and recorded intervals so an operator receives a coherent incident instead of searching independent systems. Commands remain permissioned, expiring, and separate from observed state.

Apply security as an operating architecture

Network segmentation enforces the minimum communication paths required between cameras, recorders, management, viewing, and support services. NIST guidance describes segmentation and zoning by location or function as part of defense in depth. Segmentation is only effective when actual data flows are documented and switches, routers, firewalls, and service identities enforce them.

Give every camera and service a unique identity and credential. Remove default accounts, restrict administration, protect secrets, use encrypted management and viewing paths, maintain firmware and Linux updates, centralize security and health logs, and review access when staff or vendors change. Remote support uses an approved, authenticated path with least privilege and audit history rather than permanent broad network access.

Preserve privacy and evidence requirements through camera placement review, masking where appropriate, defined retention, export authorization, watermark or hash workflows when required, and documented custody. Analytics results are leads and metadata; their accuracy and acceptable use must be validated for the campus policy and application.

Deploy in measured campus phases

Begin with a complete camera schedule, fiber map, closet survey, power assessment, risk classification, and retention requirement. Build a laboratory group using every proposed camera family, firmware, codec, event type, and representative stream profile. Test continuous recording, reconnection, playback, export, clock changes, authentication, firmware upgrades, and failure recovery before purchasing the full fleet.

Deploy one representative building as the production pilot. Measure day and night bitrate, storage writes, PoE draw, optical levels, live-view demand, CPU, memory, disk latency, alert quality, and technician workflow. Adjust the reference cell, then add buildings in controlled waves of approximately 100 cameras. Capacity dashboards must show forecast exhaustion early enough to add drives, recorders, viewing gateways, or core bandwidth before service is constrained.

• Phase 1: requirements, camera schedule, fiber and power survey, threat model, and acceptance criteria.
• Phase 2: multi-vendor lab with approximately 20 representative cameras and the complete software path.
• Phase 3: one-building pilot with production retention and operator workflows.
• Phase 4: repeatable building waves, each accepted before the next group is assigned.
• Phase 5: campus failover exercise, security review, recovery exercise, documentation handoff, and operating baseline.

Define acceptance with evidence

Before acceptance, every camera must be mapped to its purpose, switch port, VLAN, fiber path, recorder, main and substream profile, time source, retention class, nearby events, and responsible owner. The system should demonstrate required image detail during representative day and night conditions, not only show that a camera is reachable.

Run a sustained recording test through at least one full storage and retention observation period where practical. Exercise a camera reboot, switch reboot, recorder restart, failed disk, primary-recorder failure, building uplink interruption, central application failover, database recovery, remote-view session, simultaneous operator wall, playback, and evidence export. Record measured recovery, missing intervals, alert delivery, system load, and corrective actions.

• Normal recorder and core utilization remains within the approved headroom under measured production streams.
• The oldest available footage meets the required retention after array overhead and operating reserve.
• Local recording continues during a campus-fiber interruption and becomes centrally discoverable after recovery.
• A recorder failure is detected, escalated, and rehomed within the documented recovery objective.
• Authorized operators can locate, play, and export a defined incident without administrator access to the camera.