Video is the heaviest payload in IoT by an enormous margin, and surveillance is where it meets the awkward truth of cellular economics: a camera can generate more data in an afternoon than a thousand sensors generate in a year. Connected CCTV over cellular is nonetheless a thriving and growing category, construction sites, temporary infrastructure, remote assets, rapid-deployment security, anywhere fixed lines are absent, slow to install or not worth the civils. The deployments that work are the ones designed around video’s appetite rather than in denial of it.
This guide covers the three design decisions that determine whether a cellular camera estate is economical and reliable: architecture, bandwidth modelling, and SIM strategy.
First decision: what does the video actually need to do?
Surveillance architectures sit on a spectrum, and position on it changes data consumption by two orders of magnitude.
Continuous streaming to the cloud sends everything off-site as it is captured. Maximum evidential completeness and remote visibility, maximum data cost; over cellular it is justified mainly where the feed itself is the product or the site risk demands it.
Event-driven upload records locally (edge storage on the camera or an on-site recorder) and transmits only triggered clips: motion, analytics detections, alarms. This is the architecture most cellular CCTV converges on, because it aligns data cost with informational value. Modern edge analytics sharpen it further by reducing false triggers before they become uploads.
On-demand pull keeps everything local until an operator requests footage or a live view. Minimum routine data, with the requirement that inbound access to the camera works, which has network design implications covered below.
Most real estates blend the modes: event clips plus occasional live view plus periodic health imagery. Writing the blend down per camera class is the design act everything else depends on.
Modelling the bandwidth honestly
Video maths is mercifully simple once the architecture is set; the discipline is using your real parameters rather than optimistic ones. Consumption follows bitrate and duration: as worked arithmetic, a stream encoded at 1 Mbps consumes roughly 450 MB per hour, around 2 Mbps roughly 900 MB per hour, scaling linearly. From there:
A continuous remote stream at around 1 Mbps runs to roughly 320 GB per month per camera, which is the number that explains why continuous cellular streaming is a deliberate choice rather than a default. An event-driven camera producing, say, 30 one-minute clips a day at 2 Mbps consumes on the order of 13 to 14 GB a month, and halving either the trigger count or the bitrate halves it. A health-and-pull camera might idle at well under 1 GB monthly until someone asks for footage.
These figures are arithmetic from stated assumptions, not benchmarks: substitute your encoder settings, resolution, trigger rates and retention policy, and apply the same overhead and exceptional-event thinking as any data forecast (our forecasting guide covers the method, and our video telematics piece applies it to vehicle-mounted video). Two camera-specific multipliers deserve respect: night-time and high-motion scenes encode larger at the same settings, and a misconfigured motion zone, a tree, a flag, a busy road edge, is the classic way an event-driven camera quietly becomes a streaming one.
Commercially, this consumption shape argues strongly for pooled data across the camera estate, since per-site variance is high, and for per-SIM caps and alerting as the guardrail against the misconfigured-trigger scenario: a camera consuming triple its class profile is a configuration ticket, and you want it surfacing as an alert rather than an invoice.
Uptime: designing for the moment the camera matters
A surveillance camera has an unusual reliability profile: it can be quietly unimportant for months and then become the most important device the organisation owns, retroactively, for an incident window nobody scheduled. Designing for that profile means layering protections.
Network resilience at the SIM. Cameras live where they are needed, not where coverage is best, and sites change around them. Multi-network SIMs using Multi-IMSI with non-steered selection attach to the strongest available network at each site and re-select as conditions change, which converts pole-by-pole coverage variance into behaviour the SIM handles. For temporary and relocating deployments (construction being the canonical case) this is close to mandatory, since every site move is a new coverage lottery.
Local recording as the evidential backstop. Edge storage means a connectivity interruption costs remote visibility, not evidence; the footage uploads when the connection returns. Architecture choice and uptime design are the same decision viewed twice.
Health monitoring on the camera path. A camera that died quietly is the failure mode that surfaces during the incident. Periodic health check-ins, monitored per SIM with alerts on silence, turn dead cameras into maintenance tickets instead of discoveries. Real-time per-SIM visibility, session state, consumption, network attachment, is the platform capability this layer consumes; OV ONE provides it as standard, with API access so camera health can feed whatever monitoring stack the estate already runs.
Inbound access designed, not improvised. Live view and on-demand pull require reaching the camera, which over cellular means either persistent outbound tunnels to a relay or fixed IP addressing within a private APN. The choice has security as well as plumbing dimensions, surveillance footage being exactly the traffic many organisations refuse to route over the public internet, and the trade-offs are covered in our private APN and fixed IP guide. Decide it at design time; retrofitting reachability across a deployed estate is miserable work.
SIM strategy for camera estates
Compressing the above into a specification: multi-network access (Multi-IMSI, non-steered) for site-by-site resilience; data plans pooled across the estate with per-SIM caps and alerts; private APN with fixed IP where inbound access or footage isolation is required; and management through a platform with real-time per-SIM visibility and full API access for health integration. Coverage breadth matters more than usual because camera estates sprawl and relocate: OV’s footprint across 180+ countries and 600+ networks under one agreement means a camera redeployed across a border is an address change, not a procurement.
The validation step is the same as ever, only more so given video’s costs: trial SIMs in real cameras, at hard sites, with the real trigger configuration, measured for two weeks against the model. A free SIM trial at design stage is the cheapest line in the whole project.
Frequently asked questions
How much data does a 4G CCTV camera use per month?
It depends almost entirely on architecture: continuous streaming at around 1 Mbps works out near 320 GB monthly as straightforward arithmetic, while an event-driven camera uploading tens of short clips daily typically lands in the low tens of gigabytes, and on-demand designs can idle below 1 GB. Model from your own bitrate, trigger rate and retention settings rather than any typical figure.
Can CCTV run reliably over cellular instead of fixed broadband?
Yes, and it routinely does on construction sites, temporary infrastructure and remote assets, provided the design respects video economics and uptime layering: event-driven or hybrid architecture, local recording as the evidential backstop, multi-network SIMs for site resilience, and health monitoring per camera.
Do surveillance cameras need a static IP?
Only when live view or on-demand footage pull requires inbound access to the camera and a relay architecture is not preferred. Where it is needed, fixed IP is normally delivered within a private APN, which also addresses the common requirement to keep surveillance traffic off the public internet.
What stops an event-driven camera consuming like a streaming one?
Configuration discipline and guardrails: well-tuned motion zones and analytics thresholds at the camera, plus per-SIM data caps and consumption alerts at the connectivity layer so a misfiring trigger surfaces as an alert within days rather than as an invoice at month end.
