Capacity Planning für Video ist deutlich anspruchsvoller als „Audio mal Faktor X“, weil Videotraffic nicht nur mehr Bandbreite braucht, sondern vor allem variabler, burstiger und stärker von Nutzerverhalten abhängig ist. Während Voice oft mit relativ stabilen Profilen geplant werden kann, schwankt Video je nach Auflösung, Bildinhalt, Codec, Framerate, Adaptation (ABR), Anzahl gleichzeitiger Streams, Konferenzmodus (Grid vs. Speaker View) und sogar nach Tageszeit. Dazu kommt ein betrieblicher Realitätscheck: Kaum ein Netz wird 1:1 „durchreserviert“. Stattdessen arbeiten Provider, Enterprises und Plattformen mit Overbooking Modellen, die auf Statistik und QoE-Toleranzen beruhen. Genau hier liegt die Kunst: Sie müssen Peak Streams (Spitzenlasten) realistisch modellieren, Overbooking sauber begrenzen und gleichzeitig sicherstellen, dass die Qualität nicht in Busy Hour kollabiert. Ein gutes Capacity Planning für Video setzt daher nicht nur auf Durchschnittsbitrate, sondern auf Perzentile, Peak-to-Mean-Verhältnisse, Traffic-Klassen (Realtime Video vs. Streaming), Headroom für Microbursts sowie klare SLOs (Latenz/Jitter/Loss) – denn Video reagiert anders als Voice: Es toleriert etwas mehr Latenz, aber es leidet stark unter Loss-Spitzen und starken Throughput-Dellen. Der folgende Leitfaden zeigt, wie Sie Videokapazität planbar machen, Peak Streams abschätzen und Overbooking so gestalten, dass Business-Meetings, Telepresence und Streaming stabil bleiben.
Video ist nicht gleich Video: Konferenz, Streaming und „Live“ unterscheiden
Bevor Sie rechnen, müssen Sie definieren, welche Videoart Sie planen. Videokonferenzen sind interaktiv und latenzsensitiv, nutzen oft mehrere parallele Streams (Audio, Video, Screen Share) und reagieren auf Congestion mit Qualitätsreduktion, aber nicht beliebig: Unter Loss-Spitzen leidet die Bildqualität sofort (Freeze, Pixelation). Streaming (VOD/OTT) ist weniger latenzsensitiv, aber throughput-abhängig und stark von ABR-Profilen geprägt; es kann puffern, aber auch dort sind Throughput-Dellen sichtbar (Quality switches, Rebuffering). „Live“-Video (Broadcast/Webinar) sitzt dazwischen: weniger interaktiv als Konferenz, aber empfindlich gegenüber Jitter/Loss in Uplink-Szenarien.
- Video Conferencing: interaktiv, mehrere Streams, empfindlich auf Loss/Jitter, braucht stabile Perzentile.
- Streaming (ABR): throughput-dominiert, toleriert Latenz durch Buffer, aber empfindlich auf Dellen und Rebuffering.
- Live Uplink: oft ein kritischer Upstream-Stream; benötigt Headroom und stabile Behandlung.
Peak Streams: Warum die Spitze wichtiger ist als der Durchschnitt
Videotraffic wird oft mit Durchschnittswerten beschrieben („HD braucht 2–3 Mbit/s“). Für Capacity Planning ist das nur bedingt hilfreich, weil die Qualität in der Spitze entscheidet. Peaks entstehen durch gleichzeitige Meetings zu festen Zeiten (z. B. „zur vollen Stunde“), durch All-Hands-Events, durch Schulungen, durch Release-Trainings oder saisonale Spitzen. Zusätzlich gibt es technische Peaks: I-Frames, Szenenwechsel, Screen Share mit feinen Details und ABR-Umschaltungen erzeugen kurzfristig höhere Bitraten und Burstiness. Wenn Sie nur nach Mittelwert planen, laufen Sie in Busy Hour in Throughput-Dellen, die sich als „Video ist unscharf“ oder „Freeze“ äußern.
- Nutzungsverhalten: Kalender-getriebene Peaks (Startzeiten) erzeugen gleichzeitige Streams.
- Technische Peaks: I-Frames und Szenenwechsel erhöhen kurzfristig die Rate.
- Netzpeaks: Microbursts und Queueing-Events machen Peaks noch schädlicher.
Das Grundmodell: Streams × Profil × Overhead × Headroom
Ein praxistaugliches Modell startet mit einer einfachen Struktur: Gesamtbedarf = Anzahl gleichzeitiger Streams × Zielprofil (Bitrate) × Overheadfaktor × (1 + Headroom). Der Overheadfaktor deckt Protokoll-Overhead, Encapsulation (IPsec/GRE/VXLAN), L2/MPLS sowie mögliche FEC/Duplication ab. Headroom ist nicht „nice to have“, sondern entscheidend, weil Video unter Congestion nicht nur „langsamer“, sondern qualitativ schlechter wird. Anders als TCP-Downloads ist Video-QoE stark nichtlinear: Eine kleine Throughput-Delle kann einen sichtbaren Quality Switch oder Freeze auslösen.
- Streams: nicht nur „Teilnehmer“, sondern tatsächlich transportierte Video-/Share-Streams.
- Profil: Auflösung/Framerate/Codec/ABR-Target, plus Peak-to-Mean Annahmen.
- Overhead: Transport + Tunnel + Security + ggf. FEC.
- Headroom: Reserve für Peaks, Failover, Microbursts und Messunsicherheit.
Konferenzvideo: Warum „Teilnehmerzahl“ keine ausreichende Kapazitätszahl ist
Bei Videokonferenzen ist der entscheidende Punkt: Ein Endgerät empfängt oft mehrere Streams (z. B. Grid) oder einen dominanten Sprecherstream plus Zusatzstreams. Moderne Clients passen die Anzahl und Qualität der Streams dynamisch an. Dazu kommt Screen Share, der oft andere Profile nutzt (mehr Details, andere Framerate). Kapazitätsplanung sollte deshalb in „Stream-Typen“ denken: Audio (klein), Kamera-Video (mittel), Screen Share (variabel, oft burstig), optional mehrere empfangene Streams bei großen Meetings. Für Sites und Hubs ist außerdem wichtig, ob Traffic lokal breakout’t oder zentral über einen Hub/SASE-PoP geht – denn dann konzentrieren sich Streams.
- Uplink (Send): meist 1 Kamera + ggf. 1 Screen Share pro aktivem Nutzer, aber abhängig von Meetingtyp.
- Downlink (Receive): 1–N Streams, abhängig von Layout, Teilnehmerzahl und Client-Strategie.
- Hub-Konzentration: zentrale Breakouts oder Media-Relays bündeln Last und erzeugen Peak Domains.
Streaming/ABR: Overbooking ist hier normal – aber nicht grenzenlos
Bei ABR-Streaming wählen Clients aus mehreren Qualitätsstufen. Das bedeutet: Die momentane Bitrate pro Stream schwankt und passt sich an verfügbare Kapazität an. Das eröffnet Overbooking-Spielräume, weil nicht jeder Stream dauerhaft in höchster Qualität läuft. Gleichzeitig ist Overbooking riskant, wenn alle Streams gleichzeitig in hohe Stufen wechseln (z. B. nach einer kurzen Congestion-Phase oder nach einem Pfadwechsel). Für Kapazitätsplanung ist daher wichtig, nicht nur die Durchschnittsbitrate zu planen, sondern die Verteilung der Qualitätsstufen und das Verhalten bei Ramp-up. Ein robustes Modell arbeitet mit Perzentilen: z. B. „p95 Aggregate Rate“ statt „Mean“ und mit einem Peak-Faktor, der ABR-Umschaltungen berücksichtigt.
- ABR-Verteilung: Streams verteilen sich über Qualitätsstufen, nicht alle sind „max“.
- Ramp-up Peaks: nach Congestion oder Start wechseln viele Streams gleichzeitig hoch.
- Rebuffering-Risiko: Overbooking zu aggressiv → Quality switches und Rebuffering steigen.
Overbooking Modelle: Wie Sie statistisch sicher dimensionieren
Overbooking bedeutet, dass Sie mehr „verkaufte“ oder theoretisch mögliche Streams zulassen, als die physische Kapazität bei Maximalprofilen hergeben würde, weil nicht alle Nutzer gleichzeitig Maximalverbrauch erzeugen. Das ist im Telco-Bereich etabliert, aber es braucht klare Grenzen und Messbarkeit. In der Praxis sind drei Overbooking-Modelle verbreitet: (1) feste Overbooking-Ratio (einfach, aber grob), (2) Perzentil-basiertes Overbooking (p95/p99), (3) Event-basiertes Overbooking mit Schutz für Peak-Ereignisse (All-Hands, Live-Streams). Je interaktiver der Videodienst, desto konservativer sollte Overbooking sein, weil QoE-Einbrüche schneller sichtbar und geschäftlich teurer sind.
- Fixed Ratio: z. B. 2:1 oder 3:1 – leicht zu kommunizieren, aber blind für Nutzungsänderungen.
- Perzentil-Modell: dimensioniert auf p95/p99 der Aggregatlast, mit zusätzlichem Headroom für Peaks.
- Event-Guardrails: separate Budgets für All-Hands/Webinare, um Overbooking-Spitzen zu isolieren.
Peak-to-Mean Faktor: Der unterschätzte Parameter für Video
Ein praktischer Engineering-Hebel ist der Peak-to-Mean Faktor: Wie viel höher sind kurzfristige Peaks im Vergleich zum Mittelwert? Bei Video kann dieser Faktor durch Codec-Mechanik, Szenenwechsel, Screen Share und ABR-Umschaltungen deutlich über 1 liegen. Für Netzplanung heißt das: Selbst wenn die durchschnittliche Aggregate Rate passt, können Peaks Queues füllen und zu Loss-Spitzen führen. Deshalb ist es sinnvoll, in der Planung zwei Größen zu führen: (1) geplante durchschnittliche Auslastung, (2) geplante Spitzenlast (Peak) als Multiplikator. Der Peak-Faktor ist stark domänenabhängig: In DC-Fabrics mit Microbursts ist er oft höher als in glatten WAN-Links mit gutem Shaping.
- Codec-Peaks: I-Frames und komplexe Szenen erhöhen Bitrate kurzfristig.
- ABR-Umschaltung: viele Clients wechseln gleichzeitig hoch → Aggregate Peak.
- Screen Share: kann bei Text/Details burstig sein und hohe Peaks erzeugen.
QoS für Video: Warum Video selten in die Voice-LLQ gehört
Ein häufiger Fehler ist, Video „wie Voice“ zu behandeln und in eine Priority Queue zu stecken. Video ist oft bandbreitenintensiv und kann damit Premiumqueues füllen, was Starvation-Risiko erzeugt. In robusten Designs bekommt Video eine eigene, gewichtete Echtzeitklasse mit Mindestbandbreite und klaren Queue-Limits. Voice bleibt in einer kleinen, strikt limitierten LLQ. Best Effort bekommt AQM/ECN, Bulk ist nachrangig. Für Capacity Planning bedeutet das: Sie planen nicht nur „wie viel Bandbreite“, sondern auch „welches Budget pro Klasse“. Video-Overbooking wird dann pro Videoklasse betrachtet, nicht als Teil der Voice-Reserve.
- Video-Klasse: gewichtete Queue mit Mindestanteil, keine unlimitierte Priorität.
- Voice-Klasse: strikt klein und strikt limitiert.
- Best Effort: AQM/ECN gegen Bufferbloat, damit Video nicht in einer aufgeblähten Datenqueue leidet.
Shaping, HQoS und AQM: Die Netz-Toolbox gegen Video-Peaks
Capacity Planning endet nicht bei einer Zahl – es muss in ein Betriebsmodell übersetzt werden. Für Video sind Shaping und HQoS besonders wichtig, weil sie Peaks glätten und Noisy Neighbor Effekte verhindern. AQM (z. B. CoDel/PIE) und ECN helfen, Queue-Längen stabil zu halten, sodass Video-Streams weniger unter Bufferbloat leiden und ABR nicht unnötig in niedrige Stufen gedrückt wird. Praktisch ist die Kombination entscheidend: Shaping bringt Congestion in den eigenen Einflussbereich, HQoS budgetiert pro Service/Site, AQM hält Queues kurz. So können Sie etwas Overbooking zulassen, ohne dass QoE sofort kollabiert.
- Egress Shaping: verhindert, dass Peaks beim Provider droppen; macht Verhalten reproduzierbar.
- HQoS: pro Site/Subscriber/Service budgetieren, dann innerhalb priorisieren.
- AQM/ECN: reduziert Latenzspitzen und Drop-Wellen, stabilisiert Mischlast.
Failover und Maintenance: Peak Streams unter weniger Kapazität
Viele Video-Planungen funktionieren im Normalbetrieb, brechen aber bei Failover. Das ist erwartbar: Traffic bündelt sich auf weniger Pfade, und Overbooking-Ratio wird plötzlich zu aggressiv. Deshalb muss Capacity Planning für Video immer einen Failover-Fall enthalten: Welche Kapazität bleibt, wenn ein Link oder ein PoP weg ist? Können Sie Video dann degradieren (niedrigere Profile), oder müssen Sie Admission/Policy-Guardrails aktivieren, um Quality Collapses zu verhindern? In Provider-Umgebungen ist das besonders wichtig an Metro-Ringen und Interconnects, wo Maintenance häufig Traffic auf weniger Segmente drückt.
- Failover-Headroom: zusätzliche Reserve, weil Schutzpfade enger sind.
- Policy-Degradation: Video-Profile bei Degradation reduzieren statt harte Drops zu erzeugen.
- Guardrails: Events und Maintenance als Auslöser für konservativere Overbooking-Settings.
Messbarkeit: Ohne Perzentile und QoE-Metriken ist Overbooking nicht steuerbar
Overbooking ist eine betriebliche Wette auf Statistik. Damit diese Wette kontrolliert bleibt, brauchen Sie Messgrößen, die Peak- und QoE-Effekte sichtbar machen. Für das Netz sind wichtig: Utilization p95/p99 pro Engpass, Queue-Delay p95/p99 pro Klasse, Drops/Marks pro Klasse, Microburst-Indikatoren und Event-Korrelation (Startzeiten, All-Hands, Failover). Für Video-QoE sind wichtig: Quality switches, Rebuffering-Events, effective bitrate, Frame drops, Meeting-Client KPIs. Erst wenn Sie diese Daten korrelieren, können Sie sagen, ob Ihre Overbooking-Ratio zu aggressiv ist oder ob Sie eher an Shaping/AQM drehen sollten.
- Netz-Perzentile: p95/p99 Auslastung und Queue-Delay zeigen, ob Peaks kontrolliert sind.
- Class Drops: Drops in der Videoklasse sind ein direkter QoE-Killer.
- AQM/ECN Marks: zeigen Congestion frühzeitig, bevor Drop-Wellen entstehen.
- Video-QoE: Rebuffering und Quality switches sind das Betriebsfeedback für Overbooking.
Typische Fehlerbilder im Video-Capacity-Planning
Viele Probleme sind vorhersehbar. Wenn Video in der Praxis „plötzlich“ schlecht wird, ist die Ursache oft ein Peak-Event, ein Pfadwechsel oder eine falsch gewählte Overbooking-Ratio. Ein Klassiker ist auch die Vermischung von Video-Typen: Konferenzvideo wird wie Streaming geplant, oder Screen Share wird ignoriert. Ebenso häufig ist „QoS falsch herum“: Video landet in Best Effort ohne Mindestanteil und leidet dann unter Bufferbloat, obwohl genug Bandbreite da wäre.
- Nur Durchschnitt geplant: Peaks führen zu Drops/Quality Switches in Busy Hour.
- Screen Share ignoriert: Meetings brechen bei Präsentationen ein, weil Burstiness nicht modelliert wurde.
- Video in LLQ: Starvation anderer Klassen oder instabile QoS unter Last.
- Failover vergessen: Maintenance erzeugt Overbooking-Überlast, QoE kollabiert.
- Keine QoE-Telemetrie: Overbooking wird „blind“ betrieben, bis Nutzer eskalieren.
Blueprint: Capacity Planning für Video als wiederholbarer Prozess
Ein belastbarer Prozess beginnt mit der Segmentierung: Konferenzvideo, Streaming und Live getrennt als Traffic-Typen modellieren. Danach definieren Sie Profile pro Typ: Zielbitrate, Peak-Faktor, typische Streamanzahl pro Session (inklusive Screen Share), und Overheadfaktoren für Ihre Transportdomänen. Anschließend bestimmen Sie Peak Streams über Nutzungsdaten: Busy-Hour, All-Hands, Startzeitcluster und Standortverteilungen. Auf dieser Basis wählen Sie ein Overbooking-Modell: perzentilbasiert mit Guardrails für Events und Failover. Dann übersetzen Sie die Planung in Netzmechanik: Videoklasse mit Mindestanteil, Shaping/HQoS an Engpässen, AQM/ECN gegen Bufferbloat. Abschließend etablieren Sie Monitoring mit Perzentilen und QoE-KPIs, sodass Sie Overbooking iterativ feinjustieren können. So wird Video-Capacity-Planning nicht zu einer einmaligen Excel-Schätzung, sondern zu einem messbaren, operativ steuerbaren Modell, das Peak Streams abfedert und Overbooking kontrolliert, ohne die Nutzerqualität zu opfern.
