QoS für Wholesale-Kunden ist ein Klassiker im Telco-Geschäft – und gleichzeitig eine der häufigsten Ursachen für teure SLA-Diskussionen, wenn Begriffe, Messmethoden und Verantwortlichkeiten nicht sauber definiert sind. Wholesale unterscheidet sich von „normalen“ Endkundendiensten, weil Sie nicht nur eine technische Leistung erbringen, sondern ein Bauteil in der Servicekette Ihres Partners sind. Der Partner verkauft die Leistung weiter (Resale), kombiniert sie mit eigenen Komponenten (z. B. SBC/IMS, UC-Plattformen, SD-WAN, Contact Center) und erwartet, dass Ihre QoS-Klassen und Prioritäten über die Übergabepunkte hinweg konsistent greifen. Genau hier entstehen Konflikte: Sie garantieren „Low Latency“, der Partner misst RTT statt One-Way Delay. Sie definieren Jitter als Durchschnitt, der Partner bewertet 99.-Perzentile. Sie liefern eine Voice-Klasse, der Partner schickt plötzlich Video oder Bulk-Daten als EF und bläht Premium-Queues auf. Oder Markierungen werden an einer NNI/Peering-Stelle neutralisiert, sodass End-to-End-Kriterien nicht eingehalten werden, obwohl Ihr Netz intern sauber arbeitet. Ein professioneller Wholesale-SLA-Ansatz beantwortet deshalb drei Fragen glasklar: Welche QoS-Klassen sind Bestandteil des Produkts (Semantik)? Welche Leistungskennzahlen gelten je Klasse und an welchen Messpunkten (SLA-Metriken und Messgrenzen)? Und wie werden diese Kennzahlen nachweisbar gemessen, inklusive Ausnahmen, Messfenstern und Eskalationsprozess (SLA-Messverfahren)? Dieser Artikel zeigt, wie Sie SLAs für QoS im Wholesale sauber definieren und so messen, dass beide Seiten verlässlich vergleichen können – ohne Markierungschaos und ohne „messbare Überraschungen“.
Warum Wholesale-QoS besondere SLA-Disziplin erfordert
Wholesale ist eine Domänenübergabe. Das bedeutet: Sie kontrollieren nur einen Teil des End-to-End-Pfads, aber der Partner bewertet die Gesamtqualität. Daraus ergeben sich typische Anforderungen:
- Klare Messgrenze: Wo beginnt und endet Ihre Verantwortung (z. B. UNI, NNI, PoP, Hand-off-Router)?
- Interoperabilität: DSCP/CoS/MPLS-TC muss über die Übergabe hinweg konsistent gemappt sein.
- Mehrtenant-Fairness: QoS pro Kunde/Service muss isoliert werden, damit ein Tenant nicht die Premiumklassen „aufbläst“.
- Nachweisbarkeit: Partner erwarten Reports, Perzentile, Incident-Korrelation und reproduzierbare Messungen.
Ohne diese Disziplin wird QoS im Wholesale schnell zu einem Streit über Definitionen – nicht über Technik.
Die gemeinsame Sprache: QoS-Klassenmodell für Wholesale-Produkte
Der wichtigste Schritt ist, QoS-Klassen als Produktbestandteil zu definieren: Was ist „Voice“, was ist „Video“, was ist „Control“? Ein schlankes Modell ist operativ am stabilsten:
- Voice Real-Time: Audio-Medien (RTP/SRTP), sehr niedrige Latenz, strict priority (LLQ) mit hartem Limit.
- Signaling/Control: SIP/IMS-Signaling, DNS/AAA/Steuertraffic, hoch priorisiert gewichtet.
- Interactive Video: Video Calls/WebRTC/UC, gewichtet, bursttolerant.
- Best Effort: Standarddatenverkehr.
- Background (optional): Updates/Backups, klar niedriger priorisiert.
Zu viele Klassen erhöhen die Wahrscheinlichkeit von Mapping-Löchern. Gerade im Wholesale ist „weniger Klassen, dafür sauber“ oft wirtschaftlich besser als „viele Klassen mit Drift“.
Markierungen als Vertragsbestandteil: DSCP, CoS und MPLS-TC festschreiben
Im Wholesale müssen Markierungen nicht nur technisch funktionieren, sondern vertraglich definiert sein. Dazu gehört:
- DSCP-Definition je Klasse: welche DSCP-Werte sind erlaubt, welche sind ungültig?
- CoS/802.1p Mapping: falls Ethernet-Übergaben genutzt werden, welche PCP-Werte gelten?
- MPLS-TC Mapping: wenn die Leistung über MPLS/SR erbracht wird, wie wird DSCP in TC transportiert und zurückgemappt?
- Trust Boundary: werden Partner-Markierungen übernommen, bedingt übernommen oder normalisiert?
Best Practice im Wholesale: Conditional Trust. Markierungen werden akzeptiert, aber nur innerhalb definierter Profile und Budgets. Überschuss wird remarkt oder in eine niedrigere Klasse verschoben, damit Premium-Inflation nicht Ihre SLA-Klasse zerstört.
SLA-Metriken richtig wählen: Was Voice und Video wirklich brauchen
Ein SLA ist nur so gut wie seine Metrik. Für QoS-Klassen sollten Sie mindestens diese Kategorien definieren:
- Delay: idealerweise One-Way Delay (OWD); alternativ RTT mit klarer Einschränkung.
- Jitter: als Variation der One-Way Delay, nicht als „Ping-Jitter“.
- Paketverlust: als Rate und möglichst als Cluster-Indikator (Drops in kurzen Fenstern), weil Cluster Echtzeit stärker schädigen.
- Verfügbarkeit: Link/Service Availability je Messgrenze (UNI/NNI), getrennt von QoS-Qualität.
Für Wholesale ist es besonders wichtig, Perzentile zu definieren (z. B. 95./99.), weil Echtzeitprobleme oft in Peaks auftreten und Durchschnittswerte SLA-Diskussionen provozieren.
One-Way Delay vs. RTT: Warum Messmethode Teil des SLA sein muss
Viele Streitfälle entstehen, weil Partner RTT messen und daraus One-Way interpretieren. In asymmetrischen Netzen ist das nicht valide. Ein sauberes SLA definiert:
- Messgröße: One-Way Delay (bevorzugt) oder RTT (wenn OWD nicht möglich ist).
- Messrichtung: A→B und B→A getrennt, nicht nur „hin und zurück“.
- Zeitbasis: wenn OWD genutzt wird, muss Zeit synchronisiert sein (NTP/PTP) oder Messpunkte müssen segmentiert sein.
- Messfenster: Sekundenfenster für Peaks vs. 5-Minuten-Aggregate für Reporting.
Je genauer Sie das festschreiben, desto weniger Raum bleibt für interpretationsbasierte Konflikte.
SLA-Grenzen festlegen: Messpunkte, Verantwortung und Exclusions
Wholesale-SLAs scheitern oft daran, dass die Messgrenze unklar ist. Definieren Sie eindeutig:
- UNI: Übergabe zum Partner (Customer/Partner Edge), inklusive Layer und Interface.
- NNI/PoP: Übergabe zwischen Netzen oder internen Domänen (z. B. Metro→Core).
- Messpfad: welcher Pfad ist „SLA-relevant“ (Primary/Backup), wie werden Failover-Fälle bewertet?
- Exclusions: Wartungsfenster, Force Majeure, Partnerseitige Ursachen (z. B. falsche Markierung, Überlast am Partner-Edge).
Wichtig: Exclusions sollten nicht „alles“ ausklammern, sondern konkret und prüfbar sein. Sonst verliert das SLA Vertrauen und erzeugt mehr Tickets statt weniger.
QoS-Profile und Bandbreitenbudgets: SLA muss Kapazität implizit abbilden
QoS ohne Budgets ist im Wholesale riskant. Wenn der Partner unbegrenzt „Voice“ einspeisen kann, wird jede LLQ irgendwann instabil. Deshalb gehören Profile ins Produkt:
- Per-Class CIR: garantierte Bandbreite je Klasse (z. B. Voice/Control/Video) pro Anschluss oder pro Kunde.
- Per-Class PIR: maximale Bandbreite je Klasse, damit Überschuss kontrolliert degradiert wird.
- Überschussbehandlung: remarken statt droppen (besonders für Video), Voice-Überschuss nicht in LLQ belassen.
Ein SLA, das nur „Delay/Jitter/Loss“ nennt, aber keine Budgets vorsieht, lädt Premium-Inflation und Streitfälle ein.
Messmethoden im Wholesale: Passive Monitoring vs. aktive Probes
Für SLA-Messung gibt es zwei Grundansätze, die im Wholesale oft kombiniert werden sollten:
- Active Probing: synthetische Tests (z. B. UDP/TWAMP-ähnliche Probes) pro Klasse, um Delay/Jitter/Loss kontrolliert zu messen.
- Passive Telemetrie: Queueing Delay, Drops pro Klasse, Policer/Shaper Events, DSCP-Verteilungen, Classify-Hits.
Active Probing zeigt, ob die Strecke die Qualitätsziele erfüllt. Passive Telemetrie zeigt, warum nicht. Für SLA-Streitfälle ist diese Ursachenebene extrem wertvoll, weil sie Differenzen zwischen „Netz war ok“ und „Service war schlecht“ auflösen kann.
Messdesign pro Klasse: Wie Sie Voice und Video „richtig“ testen
Wholesale-SLAs sollten nachweisen, dass Klassen nicht nur existieren, sondern wirken. Bewährt haben sich Probes pro Klasse:
- Voice-Probe: kleine Pakete, fester Takt (z. B. 20 ms), DSCP Voice-Klasse, Messung von OWD/Jitter/Loss in Sekundenfenstern.
- Video-Probe: moderater Durchsatz plus optionale Bursts (Keyframe-Simulation), Messung von Loss-Clustern und Throughput-Stabilität.
- Control-Probe: geringe Rate, hohe Priorität, Fokus auf Delay-Spitzen unter Last.
- BE-Referenz: zeigt, wie BE degradiert, ohne Premium zu beeinflussen.
Wichtig: Probes müssen an der SLA-Grenze starten/enden (UNI/NNI), nicht „irgendwo intern“, sonst messen Sie am Vertrag vorbei.
Reporting: Wie SLA-Berichte Vertrauen schaffen statt Diskussionen
Ein guter Wholesale-SLA-Report ist nicht nur eine Monatszahl, sondern eine nachvollziehbare Darstellung:
- Perzentile: 95./99. für Delay/Jitter, nicht nur Durchschnitt.
- Loss als Rate und Cluster: z. B. „max. Loss in 1s/10s Fenstern“ als Hinweis auf Drop-Cluster.
- Segmentierung: wenn möglich, Teilstrecken oder PoPs ausweisen, um Hotspots zu erkennen.
- Ereigniskorrelation: Wartungsfenster, Failover-Events, Interconnect-Congestion, Policer-Events.
- Transparente Methodik: Messintervalle, Probe-Profile, Messpunkte, Ausnahmen klar dokumentiert.
So wird SLA-Reporting zu einem Instrument der kontinuierlichen Verbesserung statt zu einem monatlichen Streitgespräch.
Typische Streitfälle und wie Sie sie durch SLA-Design vermeiden
- Partner misst RTT, SLA definiert OWD nicht: Ergebnis sind falsche Interpretationen bei asymmetrischen Pfaden.
- Partner sendet alles als EF: Premium-Inflation, LLQ wird groß, Voice dropt – beide Seiten geben sich die Schuld.
- DSCP wird an Übergängen verändert: Mapping-Drift; der Partner sieht „BE“, Sie sehen „EF“ am Ingress.
- Keine klare Messgrenze: Partner misst hinter eigener Firewall/SBC, Sie messen am NNI – Zahlen passen nie zusammen.
Die Lösung ist fast immer: klare Trust Boundaries, standardisierte Mappings, definierte Budgets und eine Messmethodik, die beide Parteien akzeptieren.
Abnahme vor Produktivbetrieb: SLA-Verifikation als Go-Live-Kriterium
Bevor ein Wholesale-QoS-SLA live geht, sollte ein Abnahmeplan existieren, der die wichtigsten Risiken eliminiert:
- Mapping-Abnahme: DSCP/CoS/TC end-to-end, inklusive IPv6 und Tunnel Outer/Inner.
- Classify-Hits: pro Klasse nachweisen, dass Traffic tatsächlich in den vorgesehenen Queues landet.
- Engpass-Tests: kontrollierte Last, um Queueing Delay und Drops pro Klasse zu validieren.
- Failover-Tests: Umschalten ohne EF-Drops, keine massiven Jitterpeaks.
- Probe-Alignment: Partner und Telco nutzen abgestimmte Probe-Profile oder mindestens abgestimmte Metrikdefinitionen.
Diese Abnahme spart später enorm viel Incident-Zeit, weil sie die typischen „SLA-Überraschungen“ vor dem ersten Monatsreport findet.
Praxis-Blueprint: QoS-SLAs für Wholesale sauber definieren und messen
- Schritt 1: Produktklassen definieren (Voice, Control, Video, BE) inklusive erlaubter Markierungen und klarer Mappings.
- Schritt 2: Trust Boundary festschreiben (untrusted/conditional/trusted) und Premium-Budgets (CIR/PIR) pro Klasse definieren.
- Schritt 3: SLA-Metriken je Klasse definieren (OWD/RTT, Jitter, Loss, Perzentile, Clusterfenster) und Messfenster festlegen.
- Schritt 4: Messgrenzen (UNI/NNI) vertraglich eindeutig definieren, Exclusions und Verantwortlichkeiten klar dokumentieren.
- Schritt 5: Messverfahren festlegen: aktive Probes pro Klasse + passive Telemetrie (Queueing Delay/Drops/Remarking/Policer Events).
- Schritt 6: Abnahme durchführen (Mapping, Hits, Engpass, Failover) und Probe-Alignment mit dem Partner sicherstellen.
- Schritt 7: Reporting standardisieren (Perzentile, Segmentierung, Ereigniskorrelation) und Eskalationsprozesse definieren.
Häufige Fragen zu Wholesale-QoS-SLAs
Welche Messpunkte sind im Wholesale am sinnvollsten?
Typischerweise die eindeutigen Übergabepunkte: UNI (Partnerzugang) und NNI/PoP (Netzübergabe). Die Messung sollte genau an diesen Grenzen stattfinden, weil dort Verantwortung und Vertrag beginnen bzw. enden. Messungen „hinter“ Partnerkomponenten (Firewall/SBC) sind für den Vergleich oft ungeeignet, wenn sie nicht explizit Teil der SLA-Grenze sind.
Wie verhindere ich Premium-Inflation durch Partner-Markierungen?
Mit Conditional Trust und Budgets: akzeptieren Sie Markierungen nur aus definierten Quellen und nur innerhalb profilierter CIR/PIR-Werte. Überschuss wird remarkt (z. B. Video→BE) statt in Premiumqueues belassen oder hart gedroppt. Zusätzlich sollten SLA-Dokumente klar festlegen, welche Markierungen zulässig sind und welche als Fehlmarkierung gelten.
Was ist der wichtigste Unterschied zwischen „QoS liefern“ und „QoS als SLA verkaufen“?
Die Messbarkeit. Ein SLA braucht eindeutige Metrikdefinitionen (OWD vs. RTT, Perzentile, Clusterfenster), klare Messgrenzen (UNI/NNI) und ein abgestimmtes Messverfahren. Ohne diese drei Elemente ist QoS zwar technisch vorhanden, aber wirtschaftlich nicht sauber vertraglich abbildbar – und genau dann entstehen die teuren Diskussionen.
