Expedited Forwarding (EF) in Telekommunikationsnetzen

April 17 2026, Von Paul Waite
10 min Lesezeit

Expedited Forwarding (EF) ist das DiffServ-QoS-Verhalten, auf das Telekommunikationsbetreiber setzen, um Echtzeitdienste über IP- und MPLS-Backbones zu priorisieren. Ob Sie VoIP, VoLTE, VoNR, WebRTC-Audio oder 5G-Kontrolldaten übertragen, EF verwendet fast immer DSCP 46 und ist darauf ausgelegt, eine geringe Verzögerung, geringen Jitter und geringen Verlust für Pakete zu gewährleisten, die keine Warteschlangen tolerieren können.

In konvergenten Netzen, in denen SIP/RTP-Medien die Infrastruktur mit Best-Effort-Internetverkehr teilen, bietet EF den Mechanismus, der die Sprachqualität während der Hauptverkehrszeiten garantiert. Stellen Sie sich einen Tier-1-Mobilfunkbetreiber vor, der 50.000 gleichzeitige VoLTE-Anrufe über ein Metronetz abwickelt – ohne EF, das einer strengen Prioritätswarteschlange zugeordnet ist, würden diese Anrufe mit Streaming-Video und Massendaten konkurrieren, was zu Abschneiden, Echo und verlorenen Silben führen würde.

Dieser Artikel richtet sich an Telekommunikationsingenieure, Netzwerkarchitekten und Betriebsteams, die für das QoS-Design und die Fehlerbehebung zuständig sind. Wir behandeln die differenzierte Dienstarchitektur, DSCP-Markierungswerte, Per-Hop-Verhaltensspezifikationen, Konfigurationsabläufe und Überwachungsstrategien, die sicherstellen, dass Ihr EF-Verkehr wie vorgesehen funktioniert.

DiffServ-Grundlagen und die Rolle von EF

Differentiated Services, definiert in RFC 2474 und RFC 2475, bietet skalierbares Edge-to-Edge-QoS ohne Per-Flow-Status. Die Architektur verwendet ein 6-Bit-DSCP-Feld im DS-Feld des IP-Headers – die signifikanten Bits, die früher als IPv4-ToS-Oktett oder IPv6-Traffic-Class-Byte bekannt waren –, um eingehende Pakete in Verhaltensaggregate zu klassifizieren.

Schlüsselkonzepte:

DiffServ-Architektur: Netzwerkgeräte wenden eine konsistente Behandlung von Paketen basierend auf ihren Codepunkten an, was skalierbares QoS über große Backbones ermöglicht
PHBs (Per-Hop-Behaviors): Definieren, wie Router jede Verkehrsklasse an jedem Hop im Weiterleitungspfad behandeln
Efs Position: Neben den Assured-Forwarding (AF)-Klassen und Default-Forwarding (DF/Best-Effort) ist das Expedited-Forwarding-PHB für Echtzeit-, verlustempfindliche Flüsse optimiert

Verkehrstypen, die in Telekommunikationsnetzen EF zugeordnet sind:

RTP-Medien für SIP-Trunks (G.711, Opus-Codecs)
VoLTE/VoNR-Trägerverkehr (3GPP QCI 1 / 5QI 1, zugeordnet DSCP 46)
Echtzeit-Kollaborations-Audio (Microsoft Teams, WebRTC)
Ausgewählte Netzwerksteuerungsprotokolle, die eine garantierte Latenz erfordern

EF DSCP-Markierung und Header-Werte

Das EF-PHB ist in RFC 3246 mit einem empfohlenen Codepunkt von DSCP 46 (binär 101110) standardisiert und wird weltweit in Telekommunikationsnetzen übernommen. Dieser PHB-Codepunkt entspricht einem IP-Precedence-Wert von 5 in älteren Begriffen und gewährleistet die Abwärtskompatibilität mit älteren Geräten, die auf IP-Precedence basierend klassifizieren.

Wenn nur DS-Semantik angewendet wird, führt DSCP 46 zu einem ToS-Byte-Wert von 184 (0xB8 in Hex). Die binäre Darstellung ist 101110xx, wobei xx die beiden ECN-Bits darstellt.

Zusammenfassung der EF DSCP-Zuordnung:

DSCP dezimal: 46
Binär: 101110 (gefolgt von ECN-Bits)
ToS/Traffic Class Byte: 184 (0xB8)
Typische Warteschlangenzuweisung: Prioritätswarteschlange / Low-Latency-Warteschlange

Beim Erfassen von EF-Paketen mit Wireshark auf einem SIP-Trunk zwischen zwei Session Border Controllern sehen Sie im IP-Header entweder ToS 184 oder DSCP 46, je nach Ihren Anzeigeeinstellungen. Beide Werte weisen auf dieselbe Markierung hin – Netzwerkprobes und Traffic-Generatoren referenzieren üblicherweise eines der beiden Formate.

EF Per-Hop-Verhalten und Warteschlangen in Telekommunikationsnetzen

Das Expedited Forwarding (EF) Per-Hop-Verhalten erfordert, dass Pakete an jedem Hop eine minimale Warteschlangenverzögerung erfahren. RFC 3246 spezifiziert, dass EF-Warteschlangenimplementierungen eine geringe begrenzte Verzögerung, geringe Verzögerungsvariation (Jitter) und geringe Verlustwahrscheinlichkeit selbst bei Überlastungsereignissen bieten müssen.

In Telekommunikations-Routern von Cisco, Juniper, Nokia und Huawei wird EF typischerweise einer strikten Prioritäts- oder Low-Latency-Warteschlange zugeordnet, die vor anderen Warteschlangen geplant wird. Dies stellt sicher, dass Sprachpakete die EF-Klassen und Best-Effort-Verkehr unabhängig von der Schnittstellenüberlastung verlassen.

RFC 3246-Anforderungen:

Geringe Warteschlangenverzögerung und -variation über den gesamten Pfad
Konfigurierbare minimale Weiterleitungsrate (abonnierte Rate)
Schutz vor Aushungerung durch anderen Verkehr mittels Policing
Garantierte Bandbreite für das EF-Aggregat

Backbone-Beispiel: In einem 10-Gbit/s-Aggregationsrouter, der IPTV, Internet und Unternehmens-VPN-Verkehr überträgt, begrenzen Betreiber den EF-Sprachverkehr typischerweise auf 10-15 % der Schnittstellenbandbreite (1-1,5 Gbit/s) mit strenger Prioritätsplanung. Dies unterstützt etwa 10.000 gleichzeitige VoIP-Anrufe mit jeweils 100 kbit/s, während sichergestellt wird, dass andere Verkehrsklassen ihren konfigurierten Anteil erhalten.

EF vs. Assured Forwarding Kontrast:

Merkmal	EF	AF
Warteschlangenbehandlung	Strenge Priorität	Gewichtetes faires Queuing
Abwurfprioritäten	Einzelne Klasse	Drei pro AF-Klasse
Zugangskontrolle	Erforderlich	Optional
Anwendungsfall	Echtzeit-Sprache/Video	Geschäftsdaten, Signalisierung

Die konzeptionelle Warteschlangenhierarchie platziert EF (PQ/LLQ) an oberster Stelle, gefolgt von AF-Klassen (z. B. AF41 für Video), Signalisierungsverkehr (CS3) und schließlich Standard/Best-Effort am unteren Ende.

Konfigurieren von Expedited Forwarding für VoIP und Echtzeit-Traffic

Telekommunikationsbetreiber implementieren EF-Richtlinien über Zugangs-, Aggregations- und Kernschichten. Eine Fehlkonfiguration an einem beliebigen Hop kann die End-to-End-Dienstqualität beeinträchtigen – ein einziger Router, der DSCP 46 auf 0 ummarkiert, kann die Sprachqualität für Tausende von Benutzern ruinieren.

Unternehmens-/Carrier-SBC-Umgebungen:

Auf einem Cisco ISR oder ASR, der für SIP-Trunking verwendet wird, wird EF üblicherweise über eine Class-Map konfiguriert, die DSCP EF entspricht, und eine Policy-Map mit einer Priorität von 10 Prozent. Die Service-Policy wird dann auf WAN-Schnittstellen ausgehend angewendet.

MPLS-VPN-Backbones:

Für Carriern, die Sprachtrunks über L3VPNs transportieren, muss DSCP 46 beibehalten oder explizit in MPLS EXP/TC-Bits (101 binär) übertragen werden. PE-Router klassifizieren und reihen Pakete basierend auf diesen Werten ein und stellen eine konsistente Behandlung über den Label-Switched Path sicher.

Mobile Core-Netzwerke:

VoLTE/IMS-Verkehr, der über S1-U- oder N3-Schnittstellen übergeben wird, verwendet QCI 1-Bearer, die die Anforderungslevel für konversationelle Sprache definieren. Diese werden am Packet Gateway oder der User Plane Function mit DSCP 46 markiert, bevor sie in den IP/MPLS-Core gelangen.

Konfigurations-Checkliste:

Klassifizieren Sie RTP mithilfe von UDP-Ports 16384-32767 oder DSCP-Matching
Markieren Sie Pakete mit DSCP 46 am Ingress (Telefone, SBCs, gNodeB)
Ordnen Sie sie einer strikten Prioritätswarteschlange auf allen Schnittstellen im Weiterleitungspfad zu
Wenden Sie Policing an, um EF auf 20-30 % (Unternehmen) oder 5-15 % (Carrier Core) zu begrenzen
Synchronisieren Sie Richtlinien über Unternehmens-LAN, WAN-Anbieter und Carrier-Verbindungen

Best Practices für Telecom EF-Bereitstellungen

Zuerst Kapazitätsplanung: Verwenden Sie Traffic-Engineering-Tools, um die EF-Abonnementrate zu modellieren, bevor Sie Prioritätswarteschlangen aktivieren.
Zulassungskontrolle: Konfigurieren Sie CAC auf Call Managern und SBCs, um Überzeichnung zu vermeiden – halten Sie die EF-Auslastung unter 15 % der Link-Kapazität.
Strenger EF-Umfang: Reservieren Sie EF ausschließlich für Echtzeit-Audio/Video; markieren Sie keine Massendaten oder Signalisierung mit DSCP 46.
Konsistente Markierungen: Behalten Sie DSCP 46 in allen IP-Domänen bei; vermeiden Sie ein Ummarkieren an Verbindungspunkten, es sei denn, dies ist explizit dokumentiert.
Dokumentation: Erfassen Sie EF-Richtlinien in Netzwerkdesign-Anleitungen mit Änderungsmanagement-Tracking.

Eine Einführung im Jahr 2025 durch einen europäischen Betreiber standardisierte EF-Richtlinien über Metro Ethernet und IP/MPLS-Cores unter Verwendung identischer DSCP-zu-Warteschlangen-Zuordnungen, wodurch ein Paketverlust von unter 1 % und ein Jitter von 5 ms auf transkontinentalen Sprachtrunks erreicht wurde.

EF in mobilen und festen Telekommunikationsarchitekturen

EF wird konsistent in mobilen, festen und Unternehmensarchitekturen angewendet, wobei die Implementierungsdetails je nach Domäne variieren.

Mobiler Kern und RAN-Backhaul:

3GPP-Spezifikationen ordnen QCI 1 (LTE) und 5QI 1 (5G) DSCP 46 für konversationelle Sprache zu. Von 2024-2026 stellen die meisten Tier-1-Betreiber sicher, dass VoLTE- und VoNR-Bearer-Traffic auf S1-U-, N3- und Backhaul-Links als EF markiert wird, wobei Policing gemäß 3GPP-Richtlinien konfiguriert wird, um eine Überlastung des RAN-Backhauls zu verhindern.

Festnetz-Breitbandnetze:

Sprach-VLANs in FTTH- und DOCSIS-Bereitstellungen bewahren EF-Markierungen von den Endgeräten des Kunden bis zum Broadband Network Gateway. IMS-basierte VoIP-Dienste verwenden DSCP 46 für RTP, während Best-Effort-Internetverkehr bei DSCP 0 verbleibt, um sicherzustellen, dass Sprachpakete niemals verworfen werden, wenn der Switch oder Router überlastet ist.

Enterprise SIP-Interconnects:

SIP-Trunks zwischen Unternehmens-SBCs und Carrier-SBCs legen SLAs für maximale One-Way-Verzögerung (<150 ms), Jitter (<30 ms) und Paketverlust (<0,1 %) gemäß MEF 10.3 Carrier Ethernet-Standards fest. Dual-Stack-Bereitstellungen müssen identische DSCP 46-Semantik im IPv6-Traffic-Class-Feld anwenden.

Zusammenspiel von EF mit MPLS und Segment Routing

In MPLS- und Segment-Routing-Umgebungen, die in Telekom-Cores üblich sind, beeinflusst DSCP 46 aus dem IP-Header die Label-QoS durch EXP/TC-Bits. Betreiber pflegen in den Jahren 2025-2026 einheitliche Modelle, bei denen EF-IP-Pakete auf hochwertige LSPs mit vorreservierter Bandbreite über RSVP-TE oder SR Flex-Algo abgebildet werden.

QoS-Transparenz über L2VPN- und L3VPN-Dienste stellt sicher, dass EF-Markierungen aus Kundennetzen entweder respektiert oder explizit ummarkiert werden – niemals mehrdeutig gelassen. Dies verhindert, dass Tunnelpakete ihre Prioritätsbehandlung auf dem Weg verlieren.

Überwachung, Test und Fehlerbehebung von EF-Traffic

EF ist nur dann effektiv, wenn sein Verhalten unter realen Verkehrsbedingungen kontinuierlich überwacht wird, nicht nur bei Labortests. Netzwerkbetriebsteams benötigen eine kontinuierliche Transparenz der Verzögerungs-, Jitter- und Verlustmetriken für die EF-Klasse.

Praktische Überwachungsmethoden:

Bereitstellung von IP SLA- oder TWAMP-Sonden, die mit DSCP 46 markiert sind, um die One-Way-Verzögerung und den Jitter zwischen POPs zu messen
Pakete mit Wireshark erfassen, um zu überprüfen, ob RTP DSCP 46 (ToS 184) Ende-zu-Ende beibehält
Schnittstellen-Warteschlangenstatistiken, Prioritäts-Warteschlangenabwürfe und Policier-Konform/Non-Konform-Zähler überwachen
SNMP/gNMI-Telemetrie verfolgen, um Echtzeit-Einblicke in das EF-Verhalten über Netzwerkgeräte hinweg zu erhalten

Telekom-spezifische KPIs:

MOS-Grenzwert: >4.0 (Ziel >4.1 für Carrier-Grade-Sprache)
R-Faktor: >90 gemäß ITU-T G.107
One-Way-Verzögerung: <150 ms für internationale Sprache gemäß ITU-T G.114
Jitter: <30 ms für VoIP-Anwendungen

Fehlerbehebung bei Fehlmarkierungsszenarien:

IP-Telefone senden DSCP 0 aufgrund falscher Firmware oder QoS-Profile
Kunden-CE-Geräte markieren EF auf AF oder Standardklasse um
Zwischengeschaltete Carrier entfernen oder überschreiben DSCP-Werte an Verbindungspunkten
Policer sind falsch konfiguriert und verursachen übermäßig viele verworfene Pakete

Häufige EF-Konfigurationsfehler in der Telekommunikation

Überzeichnung: Mehr als 20-30 % der Link-Bandbreite EF ohne Zugangskontrolle zuzuweisen, führt zu Selbstüberlastung und untergräbt die geringen Latenzgarantien. Ein Ausfall im Jahr 2025 während eines großen Sportereignisses trat auf, als unkontrollierte VoIP-Spitzen 40 % der Link-Kapazität erreichten und zu Audio-Clipping führten.
Gemischte Signalisierungs- und Medienmarkierung: Die Markierung von SIP-Signalisierung (die CS3/DSCP 24 verwenden sollte) mit demselben EF-DSCP wie RTP-Medien führt zu einer schlechten Priorisierung bei hohem Anrufaufkommen.
Inkonsistente Vertrauensgrenzen: Wenn CE-Geräte vertraut werden, aber PE-Geräte ummarkieren, erleben Benutzer eine inkonsistente Qualität, abhängig vom Verkehrspfad.
Hersteller-Standardeinstellungen: IP-Telefone oder CPE mit werkseitigen DSCP-Werten (oft DSCP 0), die im Widerspruch zum Netzwerkdesign stehen – immer überprüfen, ob die QoS-Profile des Geräts korrekt konfiguriert sind.

Standards, Designrichtlinien und zukünftige Trends

Relevante Standards:

RFC 3246: EF PHB-Definition
RFC 4594: Empfehlungen für Enterprise QoS, die DSCP 46 für Sprache bestätigen
RFC 8622: Aktualisierte DiffServ-Richtlinien
ITU-T G.114/G.107: Sprachverzögerungs- und Qualitätsschwellenwerte

Große Telekommunikationsbetreiber richten interne QoS-Blaupausen an diesen Dokumenten aus und führen zwischen 2020 und 2026 konsistente Designs in globalen Netzwerken ein.

Neue Trends:

5G-Netzwerk-Slicing: Per-Slice-QoS, das EF-Verhalten mit strengeren SLAs emuliert (3GPP Rel-16+)
Echtzeit-AR/VR-Verkehr: Erfordert dynamische Telemetrie über gNMI/gRPC für Closed-Loop-EF-Anpassungen
IPv6-native Cores: Anwendung des identischen DSCP 46 in der Traffic Class für Dual-Stack-VoNR-Bereitstellungen
Automatisierung: Streaming-Analysen, die Echtzeit-EF-Richtlinienanpassungen basierend auf Überlastungssignalen ermöglichen

Richtig entwickeltes EF bleibt ein zentraler Baustein für Carrier-Grade-Sprach- und Echtzeitdienste. Da sich die Verkehrsmuster hin zu immersiven Kommunikationen verschieben und sich die Netzwerkarchitekturen mit 5G-Slicing und SRv6 weiterentwickeln, sollten Telekommunikationsteams ihre QoS-Designs kontinuierlich überprüfen, um sicherzustellen, dass die EF-Richtlinien den aktuellen und zukünftigen Serviceanforderungen entsprechen.