Mobilkommunikationsnetze - Quality of Service€¦ · – Anpassung von Datenströmen an gegebene QoS-Parameter • Scheduling – Auswahl zu übertragender Pakete (bspw. nach Priorität)

MobilkommunikationsnetzeVorlesung

1

Prof. Dr.-Ing. habil. Andreas Mitschele-ThielFachgebiet Integrierte Kommunikationssystemewww.tu-ilmenau.de/iks

Mobilkommunikationsnetze- Quality of Service -

Vorlesung

Andreas Mitschele-Thiel


2


Quality of Service (QoS)?• Allgemein: Beschreibung der Dienstgüte eines

Netzwerkes durch– Datenrate– Fehlerrate– Latenz– Latenzvariabilität (Jitter)

• Im engeren Sinn: Sicherstellung einer bestimmten Dienstgüte unabhängig von Einflüssen wie konkurrierendem Traffic oder Linkqualitätà Ziel eines QoS-fähigen Netzes


3


QoS-Mechanismen

• Reservierung von Ressourcen für eine Verbindung (bspw. in leitungsvermittelten Netzen oder mittels IntServ)

• Differenzierung (und Priorisierung) der Nutzung einer gemeinsamen Ressource (Beispiel: DiffServ)

• Overprovisioning (Überdimensionierung) einer Ressource, d.h. Auslegung auf den größten möglichen Lastfall


4


Funktionsblöcke• Admission Control

– Verwaltung von Ressourcen, Erteilung/Verweigerung des Zugriffs (bspw. bei Reservierungen)

• Traffic-Klassifizierung– Zuweisung von Datenpaketen zu unterschiedlichen

Klassen• Traffic Conditioning (Shaping & Policing)

– Anpassung von Datenströmen an gegebene QoS-Parameter

• Scheduling– Auswahl zu übertragender Pakete (bspw. nach Priorität)

• Überlaststeuerung– Vermeidung von Überlasten im Netz (bspw. durch

Verwerfen von Paketen)


5


Beispiel QoS-Anforderungen• Videochat

– hohe Datenrate– mittlere Fehlerrate– sehr geringe Latenz– sehr geringer Jitter

• Videostreaming/IP-TV– sehr hohe Datenrate– mittlere bis geringe Fehlerrate– mittlere bis hohe Latenz– mittlerer Jitter


6


Beispiel QoS-Anforderungen• Dateidownload

– sehr hohe Datenrate– geringe Fehlerrate– Latenz (fast) unwichtig– geringer Jitter

• E-Mail– geringe Datenrate– geringe Fehlerrate– Latenz unwichtig– Jitter unwichtig


7


Grundlagen – Beispiel UMTSMedium Anwendung Symetrie Datenrate QoS-Parameter

Latenz* Jitter Fehlerrate

Audio Telefonat Bidirektional 4-25kb/s <150ms(bevorzugt)<400ms

(Maximum)

<1msInnerhalbeiner

Verbindung

<3%FER**

Video Videotelefonie Bidirektional 32-384kb/s

<150ms(bevorzugt)<400ms

(Maximum)

<1%FER

Daten Telemetrie/Steuerung

Bidirektional <28,8 kb/s <250ms keineFehler

Audio Anruf-beantworter

Hauptsächlichunidirektional

4-13kb/s <1s(Abruf)<2s

(Aufzeichnung)

<3%FER


8


Grundlagen – Beispiel UMTSMedium Anwendung Symetrie Datenrate QoS-Parameter

Latenz* Jitter Fehlerrate

Daten Webbrowsing hauptsächlichunidirektional

<4sproSeite keineFehler

Daten transaktions-basierteDienste

bidirektional <4s keineFehler

Daten E-Mail hauptsächlichunidirektional

<4s keineFehler

Audio HQ-Audio-streaming

hauptsächlichunidirektional

32-128kb/s <10s <1 ms <1 %FER

Daten Transfer großerDatenmengen

hauptsächlichunidirektional

<10s keineFehler


9


Grundlagen• Ende-zu-Ende-QoS als Resultat einzelner Teil-QoS

Ende-zu-Ende

ISP Backbone Backbone ISP

Edge-to-Edge Edge-to-Edge Edge-to-Edge Edge-to-Edge

LinkNetzwerkschicht-QoS

MAC-Schicht-QoS


10


Edge-to-Edge QoS• Latenz

– Verarbeitungslatenz (processing delay) in Routern– Übertragungslatenz (transmission delay) über jeden Link

• Jitter– entsteht durch Konkurrenz mehrerer Datenströme um

gemeinsame Ressource (bspw. Links) à queueing delay• Paketverlust

– hauptsächlich durch Überlaufen von Warteschlangen in Routern

à Routereinfluss dominiert erreichbares QoS


11


Best-Effort-Router• n Eingangsströme• 1 Warteschlange (FIFO)• 1 Ausgangsstrom• Σ Eingänge > Ausgang à steigende Latenz,

Paketverlust

FIFO Ausgangzpps

Eingang1xpps

Eingang2y pps

LängeFIFOà PufferkapazitätQueueing Delay


12


QoS-fähiger Router• Klassifizierung von Paketen in unterschiedliche

Warteschlangen– unterschiedliche Strategien bei Überlast in verschiedenen

Klassen• Scheduler zur Steuerung der Ausgabe

– Priorisierung möglich

Queue

Queue

Queue

Queue

Eingang1x pps

Eingang2ypps

SchedulerKlassifizierung

Ausgangzpps


13


Grundlegende QoS-Funktionen• Shaping

– Begrenzung einer Klasse auf einen maximalen Durchfluss über die Zeit → mit Queuing bei Überschreitung

• Policing– harte Begrenzung des Durchflusses → zusätzlicher Traffic

wird verworfen• Markieren

– Pakete werden bei Überschreiten bestimmter Grenzen markiert → können verworfen oder mit niedriger Priorität später übertragen werden

• Umsortieren– Pakete innerhalb einer Queue können umsortiert werden

(bspw. anhand Priorität)


14


Grundlegende QoS-Funktionen• Metering

– Entscheidung, ob einzelne Pakete im Traffic-Profil liegen (bspw. anhand Durchsatz)

– Beispiel: Token Bucket Meter• Markierung einer

durchschnittlichenPaketrate mit definierten Bursts

Token

Token

Token

Token

Token

Token

Paket

MarkierungeinesPakets:Tokenvorhanden→entnehmen, Paketist„inprofile“kein Token→Paket ist „outofprofile“

TokenwerdenmitfesterRateXhinzugefügt→durchschnittlichePaketrate

Bucket festerGrößeY→maximaleBurst-länge


15


Grundlegende QoS-Funktionen• Tocken Bucket Meter

– nur Markierung à Paketbehandlung ist Aufgabe von Shaping oder Policing!

Tokenrateinprofile outof profile inprofile

Ankunftsrate(P

akete/s)

t


16


Grundlegende QoS-Funktionen• Strategien zum Verwerfen von Paketen

– Random Early Detection (RED) à zufälliges Verwerfen vor Maximalfüllung der Queue für bessere CongestionAvoidance

0%0

1

Queue-Belegung

Wahrscheinlichkeitdes

Verw

erfensvonPaketen

min max

100%


17


Grundlegende QoS-Funktionen• Strategien zum Verwerfen von Paketen

– Weighted Random Early Detection

0% 100%0

1

Queue-Belegung

Wahrscheinlichkeitdes

Verw

erfensvonPaketen

min1 max1min2 max2

PaketeniedrigererPrioritär


18


QoS in IP-Netzen – Type of Service (TOS)• Feld im IP-Header• Verschiedene Interpretationen im Laufe der Zeit

– Type of Service (RFC 791)– DSCP (RFC 2474)– DSCP + ECN (RFC 3168)– Beispiel TOS nach RFC 791:

• Vorrang: Priorität/Bevorzugung des betreffenden Pakets als abstrakte Klasse (bspw. 001 - Priority, 111/110 - Network Ctrl)

• D, T, R: Paket mit bevorzugt geringem Delay (D), hoher Datenraten (T) und/oder hoher Zuverlässigkeit (R) übertragen

0 1 2 3 4 5 6 7

Vorrang D T R 0 0


19


Komplexere QoS-Konzepte• Integrated Services (IntServ, RFC 1633 u.a.)

– Ende-zu-Ende Reservierungen– typisch: 1 Flow à 1 Reservierung– gute Isolation einzelner Flows gegeneinander– schlechte Skalierbarkeit

• Differentiated Services (DiffServ, RFC 2475 u.a.)– Markierung einzelner Pakete mit lokal (d.h. in einer

DiffServ-Domain) gültigen Klassen– Ende-zu-Ende-QoS als Resultat aus Folge von Per-Hop-

Behaviours (Realisierung pro Domain ggf. unterschiedlich)– Reservierung/Verteilung der Spezifikationen undefiniert


20


Komplexere QoS-Konzepte – Gemeinsamkeiten

• Netzwerkarchitektur

Edge-RouterCore-Router

Links


21


Komplexere QoS-Konzepte – Gemeinsamkeiten

• Edge Router– Netzübergänge– Klassifizierung, Policing, Markierung von einfließendem

Traffic– ggf. Ablehnung eintreffender Requests (Admission

Control)• Core Router

– leiten Pakete innerhalb des Netzes weiter– Differenzierung von Traffic nur zur Behandlung

auftretender Stausituationen– typischerweise höhere Belastung als Edge Router


22


Integrated Services (IntServ)• 2(,5) Dienst-/Applikationsklassen:

– Controlled Load: emuliert ein wenig belastetes Netz– Guaranteed: harte QoS-Garantien– (Best Effort): keine Garantien, reines IP

• Realisierung durch– explizite Reservierung (Pfadaufbau)– QoS-Behandlung des Traffics eines Pfades in jedem

Router à nur „Edge-Router“• nur abstraktes Modell, Umsetzungsbeispiele:

– RSVP– NSIS


23


IntServ – RSVP• Resource reSerVation Protocol• unidirektional• sendergetrieben, empfängerreserviert

Sender Router Empfänger

Path-Nachricht

RESV-Nachricht

RESV-Nachricht

Path-NachrichtträgteigeneAdresseinPfadlisteein

• reserviertnotwendigeRessourcen

• lehntggf.ab


24


IntServ – RSVP• Path-Message

– von Sender in Richtung Empfänger– Router entlang des Pfades protokollieren sich– Inhalt

• Sender Template: Beschreibung des Traffics (Quelle, Ziel, etc.) des zu reservierenden Flows

• Sender TSPEC: Charakteristika der Reservierung (Datenrate etc.)

• (optional) Adspec: unterwegs anzupassende Datenstruktur zur Vorhersage des erreichbaren QoS („was ist gerade möglich“)


25


IntServ – RSVP• RESV-Message

– vom Empfänger zum Sender– nimmt gleichen Weg, wie Path-Msg.– Inhalt:

• Filter Spec: beschreibt Parameter zur Traffic-Klassifizierung (Quelle, Ziel, etc.) à aus Sender Template erstellt

• Flowspec: Beschreibung der QoS-Parameter à auf Basis der Sender TSPEC


26


IntServ – RSVP• Multicast

– RSVP unterstützt Multicast-Reservierungen– Empfänger abonnieren Multicastgruppe– Pfaddetektion durch periodische Path-Nachrichten in der

Gruppe– Reservierung durch Empfänger à kein Zustand am

Sender für jeden Empfänger• Soft State

– Zustände im Netz müssen periodisch erneuert werden– löst unnötig reservierte Ressourcen bei

• Pfadwechsel• Wegfall des Empfängers


27


IntServ – Next Steps In Signaling (NSIS)• Weiterentwicklung von RSVP u.a. zu allgemeiner

Signalisierungsinfrastruktur• Trennung: Signalisierungstransport (Weiterleitung von

Nachrichten) ↔ Signalisierungsanwendung (Interpretation der Nachrichten, bspw. QoS)

• Formulierung von IntServ Controlled Load und Guaranteed Service für NSIS (als Drafts)

• Infrastruktur als Overlay-Netz zwischen Netzknoten àviele Signalisierungen zwischen Nachbarn über eine Verbindung


28


IntServ – Zusammenfassung• Vorteile

– bestmögliches QoS durch vorherige Reservierung und Garantien je Flow

• Nachteile– Verlagerung des Zustandes ins Netz à Verletzung der

grundlegenden IP-Designziele– Skalierbarkeit: Core Router sind an Reservierung beteiligt

à ggf. Zustandsexplosion– Signalisierungsoverhead durch Soft State– keine faire Ressourcenverteilung bei mehreren

Anforderungen (wer zuerst kommt...) à durch geeignete Prioritätsmodelle anpassbar


29


Differentiated Services (DiffServ)• Löst Skalierbarkeitsprobleme bei IntServ

– komplexe Entscheidungen wieder in Richtung Netzgrenze verlagern à Core Router weniger belastet

– keine festen Reservierungen, E2E-QoS aus einzelnen Schritten in Core Routern gebildet

• BegriffeDSIngressNode DSInterior Node

DSEgress Node


30


DiffServ – Klassifizierung von Traffic• Core Router kennen nur begrenzte Menge an

Verhaltensweisen (Per-Hop-Behaviors, PHBs) à komplexe Dienstlandschaft muss am Ingress Router auf PHBs abgebildet werden

• 2 Klassifizierer– Behavior Aggregate: Klassifikation anhand DSCP-Feld (im

IP-TOS-Feld gespeichert)– Multi-Field: Klassifikation aufgrund verschiedener

Parameter (Quelle, Ziel, Protokoll etc.)• Innerhalb einer Domain: 1 DSCP = viele Datenströme

(Microflows)– DSCP = DiffServ Code Point


31


DiffServ – Traffic Conditioning• Grundlegendes Mittel zur Umsetzung eines PHB• PHB kann mit Gesamtreservierung verbunden sein

(bspw. „insgesamt 20 MBit/s für PHB 3“) à Trafficprofil• Verteilung der Profile bspw. durch Resource

Management in DiffServ (RFC 5977) möglich

Profile

RouterClassifier

Meter

Marker Shaper/Dropper

TrafficConditioner


32


DiffServ – Per-Hop-Behavior (PHB)• Beschreibung des extern sichtbaren Verhaltens eines

DS-Knotens für ein bestimmtes Behavior Aggregate (BA)– Resourcen (Datenrate, Puffergrößen, …)– Priorität im Verhältnis zu anderen PHBs– Charakteristika des Datenflusses (Latenz, Verlust, …)

• Edge-to-Edge-Service als Abfolge von PHBs• n DSCP à 1 PHB möglich• 2 standardisierte PHB (weitere möglich):

– Expedited Forwarding (EF, Fokus: geringe Latenz)– Assured Forwarding (AF, Fokus: Priorisierung)


33


DiffServ – Expedited Forwarding (EF)• Anforderung: Router verarbeitet EF-Pakete mindestens

mit der maximalen EF-Paketrate– Baustein für geringe Latenz, Verlust, Jitter im Edge-to-

Edge-Dienst– Beschränkung der EF-Rate am Ingress Router– EF-Bearbeitungsrate auf jedem Router >= erwartete EF-

Ankunftsrate– Isolation von EF-Traffic gegen andere Ströme

Queue

Queue

Queue

Queue

EF-DSCP

andereDSCP

Bearbeitungsrate>=EF-Ankunftsrate

Ausgang


34


DiffServ – Assured Forwarding (AF)• Gruppe von PHBs für Edge-to-Edge-Dienste mit

Priorisierung

• Parameter der Queues (Wahrscheinlichkeiten, Queuegröße, Schedulingparameter) extern gesetzt à Aufbau von Edge-to-Edge Diensten

Queue

Queue

Queue

Queue

REDproQueueN N N M M 0DSCP

ZuweisungzurQueue

Konfiguration derWahrscheinlichkeitskurve

Ausgang


35


DiffServ – Ende-zu-Ende-QoS• Ende-zu-Ende-QoS aus Edge-to-Edge aufgebaut• Netzübergänge durch Service Level Agreements (SLA)

geregelt à ggf. Mapping der DSCPs am Egress/Ingress-Router

BBBB BB

SLA1SLA2

• BB– Bandwidth Broker• vereinbarenSLAsmitenthaltenen

Dienstparametern• bilateraleAbstimmung


36


DiffServ – Zusammenfassung• viele verschiedene Dienste auf wenige Klassen

abgebildet• problemlose Erweiterung der Dienstlandschaft

(Einführung neuer DSCPs nur lokal)• Entkopplung Applikation ↔ Dienst• kein Zustand pro Datenstrom im Kernnetz à skalierbar!• Zusammenarbeit mit normalen IP-Netzen (QoS endet an

Netzgrenze, kein Einfluss auf angrenzende Netze)• Nachteil: keine Isolation einzelner Ströme


37


Kombination DiffServ – IntServ• IntServ zum Nutzer, DiffServ im Kernnetz• Ingress Router terminiert IntServ• weiß anhand SLA, ob DiffServ-Netz die notwendigen

Parameter ermöglichen kann– Weitersignalisierung im DiffServ-Netz ggf. via RMD

• Vorteil: Skalierbarkeit im Kernnetz, Reservierung zum Nutzer


38


QoS im Funknetz• Herausforderungen

– Funklink typischerweise limitierender Faktor– Fading à veränderliche Kapazitäten à Probleme mit

Garantien• Verwendung

– IntServ: kleine Menge an Verbindungen, bspw. Sprachkanäle einer Basisstation bei UMTS

– DiffServ: große Menge an Verbindungen, Resourcenrelativ günstig à Priorisierung Kernnetz

– Overprovisioning: Voraussetzung: Resourcen nahezu unbegrenzt (im Verhältnis zu Anforderungen)à typischerweise nicht im Funknetz


39


QoS im Funknetz - KASYMOSA• Integration einzelner Schichten• Beispiel: L3-Reservierungen treiben Layer-2-

Ressourcenverteilung (KASYMOSA)– einzelne Ströme als Reservierungen via IntServ

• Quelle, Ziel, Port, Datenrate, Traffic-Art– Reservierung passender Pfade zu Zielterminal auf L2

• Quellterminal, Zielterminal, Datenrate, ggf. Einfluss durch Latenz u. Dienstklasse

• Abbildung vieler IntServ-Reservierungen auf eine L2-Reservierung à vgl. IntServ + DiffServ mit RMD

– Benachrichtigung L2 à L3 bei Linkveränderungà Ende-zu-Ende-Information an Applikation, Aussetzen des Pfades

Documents

Mobilkommunikationsnetze - Quality of Service€¦ · – Anpassung von Datenströmen an gegebene QoS-Parameter • Scheduling – Auswahl zu übertragender Pakete (bspw. nach Priorität)