Smart Campus: Edge or Cloud for 800 Cameras
Riverside University is deploying a smart-campus system across 40 buildings: 800 1080p cameras at 4 Mbps each, 2,000 environmental and energy sensors reporting every 60 seconds, 350 smart locks, and 120 Modbus energy meters. The only WAN link to the cloud is a 200 Mbps fiber. The security office requires face-recognition alerts within 300 ms of a person entering a restricted corridor; the research group wants to train and retrain models centrally and to keep 90 days of video. An integrator proposes sending every camera stream to the cloud and doing all processing there, quoting a low hardware price. The network team reports the WAN already runs at 60% utilization at peak from administrative traffic. Budget is tight, but the university expects a 10-year service life and cannot accept camera outages during WAN maintenance.
1. Is the integrator's all-cloud design viable? Quantify the problem and state where processing should run.
Read the worked answer
Not viable. Aggregate video is 800 x 4 Mbps = 3.2 Gbps. The WAN gives 200 Mbps, of which roughly 40% (80 Mbps) is free at peak, so the design is oversubscribed about 40:1 before any sensor traffic. Even transcoding to 1 Mbps per stream leaves 800 Mbps.
The 300 ms alert budget also fails: WAN round-trip time plus queueing plus cloud inference is neither small enough nor deterministic when the link is busy with administrative traffic.
Recommended split:
- Edge AI gateways per building cluster (about one per 16-24 cameras) run inference locally, so alert latency is tens of milliseconds and only events plus short clips (a few Mbps campus-wide) cross the WAN.
- The cloud keeps model training and distribution, fleet and device management, the 90-day archive (event clips and reduced-frame-rate video only), dashboards and cross-building analytics.
- Local storage buffers 24-48 hours so WAN maintenance does not blind security.
Rule applied: latency-critical, high-bandwidth, privacy-sensitive processing belongs at the edge; storage, training and global coordination belong in the cloud.
2. List the functions the edge gateway must provide and the protocol conversions required by the four device types.
Read the worked answer
The gateway is not just a switch; it must be a small runtime with these functions:
- Device connectivity: RTSP/ONVIF ingest for cameras, Modbus RTU or Modbus TCP polling for meters, BLE or Zigbee for smart locks, MQTT or CoAP/LwM2M for environmental sensors.
- Protocol adaptation to one northbound format, normally MQTT with JSON payloads, including an object model that maps Modbus registers and sensor readings to named properties.
- Local rule engine: threshold alarms, door-forced-open logic and face-recognition events evaluated on-site, so decisions do not depend on WAN RTT.
- Store-and-forward buffer with timestamps, replaying data after an outage without inventing gaps.
- Offline credential cache for locks and doors, so badge access still works when the WAN is down.
- Security and lifecycle: mutual TLS to the cloud, local device authentication, certificate storage, OTA proxy for downstream devices, NTP time sync and watchdog recovery.
A gateway that only converts protocols but cannot act locally would still fail the 300 ms and offline requirements.
3. What must happen to locks, sensors and alarms if the WAN fails for six hours, and what design decisions enforce it?
Read the worked answer
Design for graceful degradation, not for cloud dependence:
- Locks: local controller holds a hashed credential cache and an access policy (who, which door, which time window). Entry decisions run locally; events queue with timestamps and sync later. Fail-secure versus fail-safe must be decided per door, because a fire exit cannot lock on network loss.
- Sensors and meters: the gateway continues polling, timestamps each sample using a local RTC disciplined by NTP while the link was up, and buffers. With 2,000 sensors at one sample per minute, six hours is 720,000 samples, small enough for local flash if the payload is compact.
- Alarms: intrusion and temperature alarms are evaluated at the edge and drive local sounders or relays; the cloud copy is for recording and escalation, not for detecting.
- Recovery: on reconnect, replay in time order, mark late data, and let the platform deduplicate on device ID plus sequence number.
Consequence for sizing: gateway storage, RTC holdover and a documented offline policy are requirements in the bill of materials, not optional extras.