Admission Control (CAC) ist im Voice- und Video-Engineering der Mechanismus, der aus einer theoretischen QoS-Architektur ein belastbares Serviceversprechen macht. QoS priorisiert Pakete, aber QoS kann keine Physik überlisten: Wenn zu viele Echtzeitströme gleichzeitig über einen Engpass laufen, steigen Delay und Jitter, und irgendwann kommen Drops hinzu – mit sofort hörbaren oder sichtbaren Qualitätsproblemen. Genau deshalb existiert Call Admission Control: Das System entscheidet beim Aufbau einer Session, ob genügend Ressourcen verfügbar sind, um die gewünschte Qualität zu halten. In der Praxis stehen Betreiber dabei vor einer harten Wahl, die zugleich eine Produktentscheidung ist: Call Blocking vs. Quality Degradation. Blocking bedeutet, dass neue Calls (oder Video-Sessions) abgewiesen werden, damit bestehende Gespräche sauber bleiben. Degradation bedeutet, dass das System die Qualität reduziert (z. B. niedrigere Videoauflösung, niedrigerer Codec, weniger Streams, FEC aus, geringere Bitrate) oder Traffic in eine weniger priorisierte Klasse verschiebt, statt hart zu blocken. Beide Ansätze haben klare Vor- und Nachteile: Blocking schützt QoE zuverlässig, ist aber aus Nutzersicht frustrierend, weil es „gar nicht geht“. Degradation hält Kommunikation am Laufen, kann aber die Nutzererfahrung schrittweise verschlechtern und im Worst Case in einen Qualitätskollaps führen, wenn die Degradation nicht sauber begrenzt wird. Ein professionelles CAC-Design definiert deshalb klare SLOs, setzt Budgets pro Klasse (Voice, Video, Business) fest, verknüpft diese Budgets mit Messdaten (Queue-Delay, Loss, Jitter) und implementiert eine abgestufte Policy: erst degradieren, wo es sinnvoll ist, und erst blocken, wenn die Servicequalität sonst nicht mehr beherrschbar ist.
Warum CAC mehr ist als „Anzahl Calls begrenzen“
Viele Teams verstehen CAC als einfache Zählregel: „Maximal 20 Calls pro Site“. Das ist ein Start, aber nicht robust. In modernen Netzen schwankt die effektive Kapazität: Access-Raten variieren, Overhead ändert sich durch Tunnels, Failover bündelt Traffic, und Video-/Screen-Share erzeugen zusätzliche Streams. Außerdem ist nicht jede Session gleich: Ein Audio-only Call ist planbarer als ein Video-Meeting mit dynamischer Bitrate und mehreren empfangenen Streams. Ein gutes CAC berücksichtigt daher nicht nur Zählwerte, sondern Ressourcenmodelle und Zustandsindikatoren: verfügbare Bandbreite, Voice-/Video-Budgets (LLQ/Serviceklasse), Headroom, aktuelle Queue-Delay-Perzentile und Loss. Dadurch wird CAC zu einem Schutzmechanismus gegen das klassische Problem „Overbooking ohne Guardrails“.
- Ressourcenmodell: on-the-wire Bandbreite inkl. Overhead, Packetization, RTCP und ggf. Tunnel.
- Klassenbudgets: Voice-LLQ-Limit und Video-/Business-Reservierungen sind die harte Realität am Engpass.
- Zustand: Queue-Delay, Jitter und Loss zeigen, ob das Netz gerade „gesund“ ist.
- Failover: CAC muss Schutzpfade berücksichtigen, sonst bricht Qualität genau im Störfall ein.
Call Blocking: QoE schützen durch harte Grenzen
Call Blocking ist das klassische CAC-Modell: Wenn Ressourcen nicht ausreichen, wird eine neue Session abgewiesen oder in eine Warteschleife geführt. Der große Vorteil ist Vorhersehbarkeit. Bestehende Calls bleiben stabil, weil die Echtzeitklasse nicht über ihr Budget hinaus wächst. Das ist besonders wichtig bei Voice, weil Voice auf Drops und Jitter sehr empfindlich reagiert und weil „ein bisschen schlechter“ oft nicht akzeptiert wird – ein Call ist entweder brauchbar oder frustrierend. Im Provider-Kontext ist Blocking zudem produktlogisch: Es entspricht einem SLA, das Qualität priorisiert und Ressourcen fair auf Kunden verteilt. Der Nachteil liegt in der Nutzerwahrnehmung: Blocking fühlt sich wie ein Ausfall an, selbst wenn es technisch eine Schutzmaßnahme ist.
- Pro: stabile Qualität für bestehende Sessions, klare SLA-Fähigkeit, geringe Risikoakkumulation.
- Pro: verhindert Starvation und schützt Control Traffic indirekt.
- Contra: Nutzerfrust („Call geht nicht raus“), besonders in Peaks oder bei All-Hands.
- Contra: erfordert saubere Kommunikation und ggf. Alternativpfade (PSTN, Backup-Path).
Quality Degradation: Kommunikation erhalten, Qualität kontrolliert reduzieren
Quality Degradation verfolgt ein anderes Ziel: Der Dienst soll weiter nutzbar bleiben, aber bei Ressourcenknappheit in eine niedrigere Qualitätsstufe wechseln. Bei Video ist das ein natürlicher Mechanismus, weil viele Clients ohnehin adaptiv sind (ABR, weniger Streams, niedrigere Auflösung). Bei Voice kann Degradation über Codec-Wechsel (z. B. von breitbandig zu schmalbandig), geringere Bitraten, Anpassung von FEC/Redundanz oder im Extremfall über Umklassifizierung (degrade DSCP/PHB) erfolgen – wobei letzteres bei Voice riskant ist. Der Vorteil ist eine höhere Dienstverfügbarkeit aus Nutzersicht: „Es geht noch irgendwie“. Der Nachteil ist operative Komplexität: Sie müssen klar definieren, wie weit Degradation gehen darf, damit Sie keinen schleichenden Qualitätskollaps erzeugen, bei dem am Ende alle Calls mittelmäßig bis schlecht sind.
- Pro: höhere Erfolgsrate beim Sessionaufbau, weniger „harter“ Ausfall.
- Pro: besonders gut für Video und Screen Share, weil Nutzer Degradation eher akzeptieren.
- Contra: Risiko von QoE-Drift – viele Sessions werden gleichzeitig schlechter.
- Contra: erfordert klare Stufen, Metriken und Guardrails, sonst eskaliert es.
Die Kernfrage: Welche Erfahrung ist „weniger schlimm“?
Die Entscheidung Blocking vs. Degradation ist letztlich eine Produkt- und Kulturfrage: Ist es akzeptabler, dass 5% der Calls geblockt werden, dafür aber 95% hervorragend sind? Oder ist es akzeptabler, dass 100% durchkommen, aber in Peaks viele „okay“ statt „gut“ sind? In kritischen Umgebungen (Notruf, Leitstellen, Trading-Floors, industrielle Steuerung) ist Blocking oft vorzuziehen, weil schlechte Kommunikation gefährlicher sein kann als keine. In Wissensarbeit und Kollaboration (Meetings, Remote Work) ist Degradation häufig akzeptabler, besonders bei Video, weil niedrige Auflösung oft weniger schlimm ist als gar keine Verbindung. Ein professionelles CAC-Design definiert diese Prioritäten explizit und übersetzt sie in Policies und SLOs.
- Mission Critical Voice: eher Blocking oder sehr konservative Degradation, um Verlässlichkeit zu garantieren.
- Collaboration Video: eher Degradation in Stufen, weil Nutzer Anpassung erwarten.
- Hybrid: Voice strikt schützen, Video degradieren, Best Effort flexibel halten.
CAC-Mechanismen: Wo Admission Control praktisch umgesetzt wird
CAC kann an unterschiedlichen Stellen implementiert werden. In klassischen VoIP-Umgebungen übernehmen Call Manager, SBCs oder Gateways die Entscheidung auf Basis von Standortprofilen und Bandbreitenbudgets. In SD-WAN/SASE kann CAC als Policy-Steering auftreten: Wenn ein Pfad die SLA nicht erfüllt, wird Traffic umgelenkt oder gedrosselt, und neue Sessions werden ggf. auf einen anderen Pfad gelegt oder abgewiesen. In Provider-Netzen kann CAC auch implizit über Service-Policer und Profile wirken (weniger wünschenswert für Voice, weil Drops), oder über kontrollierte Ressourcenreservierung in Managed Services. Entscheidend ist: CAC muss dort sitzen, wo Sie die beste Sicht auf Ressourcen und Pfadqualität haben.
- Call Control Ebene: SBC/Call Manager entscheidet pro Standort oder Trunk, oft am zuverlässigsten für Voice.
- Network Edge: SD-WAN Edge oder WAN-Router entscheidet nach Pfad-SLAs und Klassenbudgets.
- Provider Profile: Policer/Service-Profile begrenzen, aber sind für Echtzeit nur mit Degradation/Guardrails sinnvoll.
Stufenmodell für Degradation: „Graceful Degradation“ statt Chaos
Wenn Sie Degradation nutzen, brauchen Sie Stufen. Ohne Stufen wird Degradation zu einem unkontrollierten „alle werden schlechter“-Phänomen. Ein gutes Stufenmodell definiert klare Qualitätslevel, die an messbare Bedingungen geknüpft sind (SLA-Schwellen, Queue-Delay, Loss, verfügbare Bandbreite). Für Video können Stufen Auflösung/Framerate/Stream-Anzahl steuern. Für Voice sind Stufen heikler, aber möglich: z. B. Deaktivieren von FEC/Redundanz zuerst (wenn Bandbreite knapp, aber Loss niedrig), dann Codec-Bitrate reduzieren oder auf schmalbandige Profile wechseln. Wichtig ist die Hysterese: Stufenwechsel dürfen nicht „flappen“, sonst steigt Jitter und Nutzererlebnis wird unruhig.
- Stufe 0: Normalbetrieb – volle Qualität, definierte Budgets.
- Stufe 1: leichte Degradation – Videoauflösung runter, weniger Empfangsstreams, Screen Share begrenzen.
- Stufe 2: stärkere Degradation – Video framerate/bitrate runter, ggf. Audio priorisieren.
- Stufe 3: Schutzmodus – neue Video-Sessions blocken, Audio-only zulassen.
- Stufe 4: harte Grenze – neue Calls blocken, um bestehende Voice-Sessions zu retten.
Admission Control und QoS-Budgets: LLQ-Limit als „harte Wahrheit“
Im Netz ist die wichtigste Grenze oft das Echtzeitbudget: die Voice-LLQ oder die Realtime-Klasse im HQoS. Dieses Budget sollte nicht durch spontane Lastspitzen überschritten werden, sonst entstehen Drops oder Starvation. CAC muss deshalb mit QoS-Budgets gekoppelt sein: Wenn LLQ-Auslastung nahe am Limit ist (insbesondere p95/p99 in kurzen Fenstern), sollten neue Calls nicht mehr zugelassen oder müssen auf alternative Pfade gelenkt werden. Für Video gilt analog: Wenn die Videoklasse ihre Mindestanteile nicht mehr erfüllt oder wenn Drops steigen, sollten neue Video-Streams degradiert oder geblockt werden, bevor Voice und Business kollabieren.
- Voice: LLQ-Limit + Headroom = maximale gleichzeitige Calls im Engpass.
- Video: gewichtete Klasse + Overbooking-Guardrails = maximale gleichzeitige Streams.
- Best Effort: AQM/ECN stabilisiert, aber ersetzt CAC nicht bei echten Engpässen.
Warum Blocking oft „ehrlicher“ ist als späte Degradation
In vielen Umgebungen ist eine späte Degradation schlechter als frühzeitiges Blocking, weil sie die Qualität vieler Sessions gleichzeitig verschlechtert. Ein geblockter Call betrifft einen Nutzer. Ein Qualitätskollaps betrifft alle in einer Meetingwelle. Besonders bei Voice ist das riskant: Wenn Sie zu lange degradieren, steigen Jitter und Loss, und am Ende sind alle Gespräche schlecht. Blocking ist dann die „ehrliche“ Entscheidung, um die Servicequalität für bestehende Sessions zu schützen. Degradation ist am sinnvollsten dort, wo Nutzer sie akzeptieren (Video) oder wo eine klare, begrenzte Qualitätsreduktion möglich ist, ohne dass die Kommunikation unbrauchbar wird.
- Voice: eher früh schützen, weil QoE schnell nichtlinear kippt.
- Video: Degradation ist natürlicher, weil ABR und Layout ohnehin dynamisch sind.
- Guardrails: ohne harte Grenzen wird Degradation zum Dauerzustand.
Failover, Wartung und Peak-Events: CAC muss Worst Case beherrschen
CAC ist besonders dann wertvoll, wenn die Infrastruktur unter Stress steht: Linkausfälle, TE-Reoptimierung, Wartungsfenster oder All-Hands-Events. Genau dann ist Kapazität knapper und Last konzentrierter. Ein gutes CAC-Modell hat daher einen „Degraded Mode“: Bei Failover werden konservativere Budgets aktiv, Degradation-Stufen greifen früher, und ggf. wird früher geblockt. So verhindern Sie, dass ein Netz im Störfall zwar „alles zulässt“, aber dadurch die Qualität für alle zerstört.
- Failover-Budgets: reduzierte Kapazität = reduzierte zulässige Sessions.
- Event-Guardrails: All-Hands/Trainings separieren, Video begrenzen, Audio schützen.
- Hysterese: Stabilität der CAC-Entscheidungen ist wichtiger als „schnelles Umschalten“.
Messbarkeit: Wie Sie CAC-Erfolg nachweisen
Ob Blocking oder Degradation „besser“ ist, lässt sich nur mit Messdaten entscheiden. Für Blocking sind Call-Setup-Failure-Rate, Block-Reason-Codes und Nutzerbeschwerden relevant. Für Degradation sind Quality-Level-Verteilungen, Quality Switches, Rebuffering (bei Video), sowie Voice-KPIs (Jitter, late loss, concealment) entscheidend. Auf Netzseite sind Queue-Delay p95/p99, Drops/Marks pro Klasse und LLQ-Auslastung die wichtigsten Indikatoren. Ein starkes Signal für gutes CAC ist: In Busy Hour steigen Blockings oder Degradationsstufen, aber die QoE der zugelassenen Sessions bleibt stabil.
- Blocking-KPIs: Block-Rate, Ursachen, zeitliche Cluster, „Bad Minutes“.
- Degradation-KPIs: Anteil Sessions je Qualitätsstufe, Wechselhäufigkeit (Flapping vermeiden).
- Netz-KPIs: Queue-Delay/Drops pro Klasse, LLQ-Auslastung, AQM/ECN-Mark-Raten.
- QoE-KPIs: RTP-jitter, late packets, concealment events, Video quality switches.
Typische Failure Patterns bei CAC
Viele CAC-Implementierungen scheitern nicht am Konzept, sondern an der Ausführung. Häufige Probleme sind: zu statische Grenzwerte (ignorieren Overhead, Failover, Video-Streams), falsche Messbasis (Mittelwerte statt Perzentile), fehlende Hysterese (CAC flapt), oder CAC sitzt an der falschen Stelle (keine Sicht auf den echten Engpass). Ebenso kritisch: Degradation ohne klare Stufen führt zu dauerhaft „mittelmäßiger“ Qualität, die schwer zu debuggen ist.
- Zu optimistische Limits: Calls werden zugelassen, aber QoE kippt in Busy Hour.
- Keine Hysterese: ständige Wechsel zwischen Pfaden/Qualitätsstufen erhöht Jitter.
- Falscher Engpass: CAC misst Downlink, aber Uplink ist das Problem.
- Degradation ohne Guardrails: alle Sessions werden schlechter statt wenige geblockt.
Blueprint: CAC als kontrolliertes System aus Budgets, Stufen und harten Grenzen
Ein belastbares CAC-Design beginnt mit klaren Servicezielen: Was ist „akzeptable“ Voice- und Videoqualität, gemessen in Perzentilen und Bad-Minutes-Budgets? Danach definieren Sie Budgets pro Klasse am Engpass: Voice-LLQ-Limit mit Headroom, Videoklasse mit Mindestanteil und Overbooking-Grenzen, Best Effort mit AQM/ECN gegen Bufferbloat. Darauf setzen Sie ein Stufenmodell: Video wird bei Degradation zuerst reduziert, Voice bleibt so lange stabil wie möglich. Blocking wird als letzte, aber klare Schutzmaßnahme definiert, wenn die Budgets sonst überschritten würden. Das Ganze wird mit Hysterese und Failover-Modi stabilisiert und über Telemetrie validiert: Queue-Delay/Drops, LLQ-Auslastung, Degradation-Level-Verteilungen und Block-Reason-Codes. So wird Admission Control nicht zum „Bösewicht, der Calls blockt“, sondern zum Mechanismus, der in Spitzenlasten gezielt entscheidet: lieber wenige Sessions ablehnen oder kontrolliert degradieren, als alle Sessions gleichzeitig unbrauchbar zu machen.
