IP-camera’s zonder netwerkstress: bandbreedte, PoE, VLAN-segmentatie en opslagpiek

“Video is tegenwoordig de grootste bandbreedteverbruiker in veel bedrijfsnetwerken.”
– Cisco, Video Surveillance Design Guide (algemeen principe uit Cisco’s ontwerpdocumentatie)

Meer camera’s ophangen lijkt vaak een kwestie van “nog een switch bijplaatsen”. In 2026 klopt dat zelden. Hogere resoluties, slimmere compressie met variabele bitrate, continu opnemen én piekmomenten bij incidenten zorgen ervoor dat een cameranetwerk zich anders gedraagt dan klassieke IT-traffic. Bij uitbreidingen, renovaties of verhuizingen duiken voor camera systemen vaak dezelfde vragen op: kan de uplink het aan, is het PoE-budget voldoende, en waarom loopt de opslag plots sneller vol dan voorzien?

Onderstaande aanpak helpt je een ontwerp vooraf te valideren met een helder rekenmodel. Je krijgt cijfers die zowel IT als facility en security begrijpen, en die je later kan hergebruiken als netwerkdocument bij uitbreiding of vervanging.

Begin met een mini-inventaris die echt telt

Voor je gaat rekenen, verzamel je per camera vier dingen. Dit lijkt banaal, maar hier loopt het in de praktijk vaak mis:

1. Resolutie en fps (bijvoorbeeld 4MP/15fps of 4K/25fps)
2. Codec en instellingen (H.264 of H.265, CBR/VBR, GOP-structuur)
3. Scenario van opname (continu, motion detection, of event-based met prebuffer)
4. Voeding (PoE, PoE+ of PoE++ en eventueel heaters/IR)

Maak meteen onderscheid tussen:

• camera’s in rustige zones (magazijngang, nachtregime),
• camera’s met veel beweging (onthaal, parking, productie),
• camera’s met analytics (people counting, nummerplaat herkenning, objectdetectie).

Die verschillen bepalen later je videobewaking bitrate per camera en vooral de pieken.

Van “gok” naar getal: IP-cameraverkeer berekenen met een eenvoudig rekenmodel

Wie IP-camera bandbreedte wil berekenen, komt best los van één vaste bitrate. In realiteit heb je minstens drie waardes nodig: gemiddeld, piek, en “incident-piek” (meerdere camera’s tegelijk veel detail, plus live viewing).

Stap 1: bepaal bitrate per cameratype

Gebruik bij voorkeur gemeten waarden (testopstelling of vendor-tools). Heb je die niet, werk dan met conservatieve aannames.

Voor elk cameratype noteer je:

• gemiddelde bitrate Mbps (Bavg)
• piek bij veel beweging/complex beeld Mbps (Bpeak)

Voorbeeld (indicatief, sterk afhankelijk van settings):

• 4MP H.265 15fps: Bavg 2–4 Mbps, Bpeak 6–10 Mbps
• 4K H.265 25fps: Bavg 6–10 Mbps, Bpeak 15–25 Mbps

Stap 2: tel gelijktijdigheid mee

Niet elke camera piekt tegelijk. Daarom is een CCTV netwerk rekenmodel met gelijktijdigheid realistischer dan “alles op max” te laten staan.

Definieer:

• N = aantal camera’s
• G = gelijktijdigheidsfactor (0,2 tot 0,8, afhankelijk van context)

Richtwaarden:

• kantoor met beperkte beweging: G = 0,3–0,5
• productie/retail: G = 0,5–0,7
• incidentscenario (alarm, evacuatie): G = 0,8 of hoger

Stap 3: reken totale videoload

Een bruikbare formule:

• Totale gemiddelde load = Σ(B_avg per camera)
• Totale ontwerp-load (met piek) = Σ(Bavg) + G × Σ(Bpeak − B_avg)

Voeg daarna overhead toe voor netwerkheaders, RTSP/ONVIF, en management:

• Overheadfactor: reken 10–20% extra, afhankelijk van encapsulation en tooling.

Dit is je basis om uplink capaciteit te berekenen tussen access-switches en core of serverruimte.

Uplink en backbone: wanneer 1G niet meer “rustig” is

Een veelgemaakte fout is de uplink te dimensioneren op gemiddelde load. Camera’s gedragen zich echter als een continue stroom, en microbursts kunnen buffers doen vollopen.

Praktische richtlijnen:

• Hou uplinks bij voorkeur onder 60–70% bezetting in het piekmodel.
• Denk aan extra verkeer: live viewing (meerdere streams), exports, firmware-updates, VMS-metadata.

Wanneer is een glasvezel-uplink tussen patchkasten logisch?

Zodra je merkt dat:

• meerdere kasten tegelijk richting serverruimte streamen,
• je afstand of elektromagnetische storingen koper lastig maken,
• je wil opschalen naar 10G zonder herbekabeling,

dan is een glasvezel uplink tussen patchkasten vaak de meest nuchtere keuze. Het maakt je ontwerp ook toekomstvaster, zeker bij renovaties waar je later opnieuw aan plafonds en goten zou moeten.

PoE-budget: reken niet met “het zal wel passen”

Een camera “neemt 8 watt” op papier, totdat IR, heater, motorzoom inschakelt. Daarom is PoE budget per switch een aparte berekening, los van bandbreedte.

Zo pak je het aan

Per switch:

1. Noteer het PoE-budget van de switch (bijvoorbeeld 370W, 740W).
2. Noteer per camera:

• P_avg (typisch verbruik)
• P_max (maximaal verbruik, zeker bij IR/heater)

1. Reken met een veiligheidsmarge.

Een praktische vuistregel:

• Dimensioneer op Σ(P_max) × 1,1 (10% marge) voor camera’s met IR/heater.
• Bij “gewone” indoor camera’s volstaat vaak Σ(P_avg) × 1,2, omdat pieken minder uitgesproken zijn.

Let op: PoE is ook warmte. Een volle PoE-switch in een kleine kast zonder ventilatie kan throttling, uitval of versnelde slijtage geven. Neem dit mee in je sitevoorbereiding.

Wie twijfelt over switch keuze voor IP-camera’s, doet er goed aan ook te kijken naar buffercapaciteit, PoE-standaarden (802.3af/at/bt), uplinkmogelijkheden (SFP/SFP+), en beheerfuncties. 

VLAN’s en QoS: maak cameraverkeer voorspelbaar

Een netwerkontwerp voor beveiligingscamera’s wordt pas echt beheersbaar wanneer videostreams logisch gescheiden en correct geprioriteerd zijn.

VLAN-segmentatie voor een cameranetwerk

Met VLAN segmentatie in camera netwerken bereik je drie dingen:

• minder broadcast en “ruis” op je kantoornetwerk,
• eenvoudiger troubleshooting,
• betere security (camera’s hoeven niet door iedereen bereikbaar te zijn).

Praktische opzet:

• één dedicated VLAN voor camera’s,
• één VLAN voor VMS/NVR-servers,
• optioneel een apart VLAN voor viewing-stations of security-workstations,
• strikte firewallregels tussen segmenten (minimaal noodzakelijke poorten).

QoS voor videostreaming zonder verrassingen

QoS is geen magische knop, maar het helpt wel om video niet te laten verdringen door piekende dataflows, of omgekeerd.

Aanpak in het kort:

• Classificeer cameraverkeer (bijvoorbeeld via Quality of Service).
• Geef video een passende queue, maar vermijd dat je het hele netwerk “video-first” maakt.
• Beperk live view en exports waar nodig met policies of scheduling.

In omgevingen met gemengde workloads, zoals VoIP, ERP en WiFi-backhaul, is QoS voor videostreaming vaak het verschil tussen een netwerk dat “meestal werkt” en een netwerk dat voorspelbaar blijft bij drukte.

Opslag: NVR-dimensionering draait om dagen, pieken en retention

Bij NVR opslagdimensionering gaat het niet alleen om totale TB’s. Je wil weten of je bij incidenten, langere retentie of hogere resolutie onverwacht tegen de limiet loopt.

Basismodel voor opslag

Per camera:

• Opslag per dag (GB) = (bitrate in Mbps × 86.400) / 8 / 1.000
  (benadering met decimale GB, prima voor planning)

Daarna:

• vermenigvuldig met aantal dagen retentie,
• tel overhead en bestandsstructuren mee (5–15%),
• neem het opnameprofiel mee (continu vs motion).

Vergeet de opslagpiek niet

Opslag piekt niet alleen door “meer Mbps”, maar ook door:

• meer streams die tegelijk op hogere kwaliteit worden opgeslagen (incidentprofiel),
• extra substreams of dual recording,
• langere prebuffer bij alarmscenario’s,
• exports door operators.

Daarom is het verstandig om in je ontwerp twee profielen te zetten:

1. normaal bedrijf (dagelijks),
2. incidentmodus (piekbelasting).

Die vertaalslag maakt je document bruikbaar voor capaciteitsplanning van videobewaking.

Van rekenblad naar een netwerkdocument dat teams samenbrengt

Een sterk resultaat is geen Excel die alleen IT begrijpt, maar een beknopt dossier met:

• lijst camerazones en cameratypes,
• berekende gemiddelde load, piekload en gelijktijdigheid,
• uplinkplanning per kast (1G/10G en groeipad),
• PoE-berekening per switch inclusief marge,
• VLAN- en firewallmatrix,
• QoS-principes,
• opslagberekening met retentie en incidentprofiel,
• testplan: meten, valideren, bijsturen.

Connectivity Solutions maakt dit soort trajecten concreet met sitevoorbereiding, resourceplanning, documentatie, testen en certificering. Vanuit onze ervaring sinds 1996 in tele- en datacommunicatie-infrastructuren vertalen we cameravereisten naar een ontwerp dat je later zonder giswerk kan uitbreiden. 

Besluit: minder “brandjes”, meer voorspelbaarheid

Een camera-uitbreiding die pas na oplevering begint te haperen, kost dubbel: tijd, discussie tussen teams, en vaak ook extra hardware die je liever meteen juist had gekozen. Door vooraf je bandbreedte, PoE, segmentatie en opslag te modelleren, bouw je een cameranetwerk dat rustig blijft, ook wanneer het beeld druk wordt.

Wil je dat we jouw plannen toetsen aan een praktisch rekenmodel en er een helder netwerkdocument van maken voor IT én security? Neem dan contact op via de pagina contact, dan bekijken we samen welke stappen het meeste opleveren in jouw gebouw en jouw planning.