Network architecture for AI video analytics defines how camera streams, analytics processing, storage, and alert delivery are segmented, routed, and secured across the organisation's network infrastructure. A well-designed network ensures reliable AI inference without degrading other network services, maintains security boundaries between camera infrastructure and corporate systems, and remains maintainable by the IT team after deployment. This guide covers VLAN segmentation, traffic flow models, bandwidth sizing, and the specific network issues that cause AI analytics deployments to underperform.
A well-designed network architecture ensures AI video analytics runs reliably without degrading other network services, maintains appropriate security boundaries between camera infrastructure and corporate systems, and is maintainable by the IT team after deployment.
Most video analytics network problems — dropped streams, inference gaps, unauthorised camera access — are preventable with the right architecture decisions made at design time. Retrofitting network architecture after deployment is significantly more expensive and disruptive than designing it correctly from the start.
For IT teams evaluating an AI video analytics deployment, the three core concerns are: network performance impact (will this degrade other traffic?), security (will camera network exposure create attack surface?), and maintainability (how do we support this ongoing?). This guide answers all three directly.
Cameras should be on a dedicated VLAN isolated from the corporate network. This achieves two things: it prevents camera compromise from becoming a corporate network threat (IP cameras are notoriously vulnerable to exploitation if not patched), and it limits broadcast domain traffic from cameras to the camera segment only. The AI analytics server or edge appliance connects to both the camera VLAN (to receive streams) and a management VLAN (to deliver alerts and provide the operator interface) via controlled inter-VLAN routing with explicit ACL rules.
Camera streams flow from the camera VLAN to the analytics server — this is the highest-bandwidth traffic in the system. Processed events and structured alerts flow from the analytics server to the management network (PSIM, operator console, notification systems) — this is low-bandwidth metadata traffic. Raw video does not flow to the corporate network — only structured event data does. This is the key bandwidth optimisation point that IT teams need to understand: the analytics server acts as a traffic reduction layer, converting gigabits of raw video into kilobits of event data.
On-premises deployments keep all camera traffic on-site. Only event metadata and alert notifications leave the local network — the WAN bandwidth impact is negligible. Cloud-connected deployments are different: either raw streams or AI-processed clips must be sent to the cloud. Raw stream upload requires significant WAN bandwidth (2–8 Mbps per camera). AI-triggered clip upload dramatically reduces this — typically to 5–15% of the continuous stream equivalent — because only detected events are uploaded rather than the full continuous feed.
IT teams need secure remote access to the analytics platform for monitoring and maintenance. The management interface should be behind a VPN or zero-trust access proxy — never directly internet-exposed. SSH access to the analytics server should follow the same policy. For multi-site deployments, a centralised management portal accessible over a secure WAN connection simplifies operations without exposing individual site infrastructure.
Managed switches with VLAN support on the camera network — unmanaged switches cannot provide the segmentation required for a secure deployment.
Sufficient switch port capacity and PoE budget for the camera count. Each IP camera requires one switch port and draws PoE power. Calculate the total PoE budget before specifying switches — do not assume a 24-port PoE switch can power 24 high-draw cameras.
Calculated bandwidth headroom on the camera VLAN. Total camera stream bandwidth should not exceed 70–80% of the available switch backplane and uplink capacity. Use the bandwidth calculator to size this accurately.
Firewall or ACL rules defining permitted traffic flows between the camera VLAN, analytics server, and management network. Default-deny between VLANs with explicit allow rules for required traffic only.
DNS resolution for the analytics platform management interface — if operators access the platform by hostname, DNS must resolve correctly from the management VLAN.
NTP synchronisation across cameras, analytics server, and PSIM. Timestamp accuracy is critical for event correlation and forensic investigation. All devices should synchronise to the same NTP source, and synchronisation status should be monitored.
Some IP cameras send excessive broadcast traffic if misconfigured — particularly during boot or when failing to reach their configured NTP or management server. On a flat network, this broadcast traffic affects all devices. On a large camera deployment (50+ cameras), a broadcast storm can saturate switch backplane capacity and degrade performance for all connected devices. Solution: enable broadcast storm control on all camera-facing switch ports (most managed switches support this as a per-port setting). Place cameras on a dedicated VLAN to contain the broadcast domain. Monitor broadcast traffic levels as part of routine network health checks.
High-resolution cameras, IR-illuminated cameras, and PTZ cameras draw significantly more PoE power than basic fixed models. A standard PoE switch (802.3af) provides 15.4W per port — sufficient for a basic fixed camera but insufficient for a PTZ with heater (which may draw 60W+). Total PoE draw across all ports often exceeds the switch's PoE budget on large deployments, causing cameras to power-cycle or fail to boot. Solution: calculate per-port and total switch PoE budget before specifying switches. Use PoE+ (802.3at, 30W per port) for standard cameras and PoE++ (802.3bt, 60–100W per port) for PTZ and high-draw cameras. Always verify the switch's total PoE power supply capacity — it is often less than the sum of per-port maximums.
Most business internet connections have significantly less upload than download bandwidth — a 100 Mbps/20 Mbps asymmetric connection is typical. Cloud-connected video analytics competes with all other upload traffic (email, file sync, VoIP). Uploading raw streams from even 10 cameras at 4 Mbps each saturates a 40 Mbps upload link. Solution: calculate the upload requirement using the bandwidth calculator and compare against contracted upload capacity. Implement QoS policies to prioritise analytics traffic over non-critical uploads. Alternatively, switch to AI-triggered clip upload to reduce upload volume by 80–95%. For large camera deployments, a dedicated internet connection for video analytics traffic may be warranted.
Cameras that lose NTP synchronisation develop timestamp drift. After a few days without NTP, a camera's clock can drift by 30 seconds or more. This makes multi-camera tracking impossible (the system cannot correlate detections across cameras with mismatched timestamps) and event correlation unreliable (a 02:14 detection on one camera should correlate with a 02:14 access control event — not a 02:14:45 detection). Solution: configure NTP on every camera individually — do not rely on the NVR or analytics platform to correct timestamps after the fact. Monitor synchronisation status as part of routine maintenance. Alert on drift above 5 seconds.
SafetyScope is designed to operate within a segmented network architecture. The platform connects to camera streams on the camera VLAN and delivers events and the operator interface on the management VLAN. No camera traffic is bridged to the corporate network.
The platform's stream ingestion engine is optimised for bandwidth efficiency — processing frames at the analytics server without requiring raw stream forwarding to additional systems. For cloud-connected deployments, SafetyScope uses AI-triggered clip upload by default, reducing WAN upload requirements by 85–95% compared to continuous stream upload.
NTP synchronisation is verified per camera during onboarding, and the platform alerts on detected timestamp drift. Bandwidth requirements per camera are documented in the deployment guide, and the online bandwidth calculator provides project-specific sizing.
Published: 2026-01-26 · Updated: 2026-04-02