Einfhrung in die Berechnung

der Bandbreiten fr VoIP

Netzwerke
Sead Causevic
sead.causevic@web.de
14.12.2006/V2
 Agenda
Teil 1 (Diese Prsentation)
1. Einfhrung in den Problembereich
2. Dimensionierung der Sprachkanle
Definitionen
Elang B (Systeme mit Verlusten)
3. Queuing Analysis und Dimensionierung der Datenkanle
Definitionen
Pollaczek-Khinchin Formula
4. Ein Fallbeispiel
Teil 2 (Nach Bedarf)
1. Quality of Service for VoIP

2
 Warum diese Einfhrung?
Immer wiederkehrende Frage: Auf welchen Grundlagen werden die
Schtzungen der WAN Bandbreiten fr die VoIP Netzwerke gemacht?
Die Angaben der Firma Nortel oder die Methoden sind unvollstndig oder
zu generell oder auch manchmal falsch
Das ist genau so bei anderen Anbieter
Das Problem hat keine exakte Lsung (wird noch erklrt)
Motivation: Wenn die Basismechanismen bekannt sind, ist es viel
einfacher qualifizierte Schtzungen zu machen und damit grobe Fehler zu
vermeiden .
Habe zu schnell Ja nach einem guten Abendessen mit den Kunden gesagt

3
 Die Ziele der Prsentation
Nortel Basic Recommendations for VoIP in LAN/WAN
Recommendations (*) Value (*)

Network Media Switched Network

Slow Link (Data-Link < 1 MB/s) Fast Link (Data-Link > 1 MB/s) Teil 1 der
Prsentation:
Bandwith reserve ~ 0.5 * (X+Y)% Bandwith reserve ~ 0.3 * (X+Y)%
Bandwith and
Auf welchen
Speed of Data Link calc. Bandwith for voice= Y% calc. Bandwith for voice= Y% Grundlagen
basieren diese
used Bandwith for Data= X% used Bandwith for Data= X% Empfehlungen?

End to End Delay < 150 ms

IP net Delay < 90 (100) ms Wie kann man

mit diesen Anforde-
Packet Loss < 0,1% rungen umgehen?

Jitter 20 - 25 ms
Teil 2 (!):
QoS Layer 2/Layer 3 with QoS 802.1p/Q &Diffserv, MPLS,Call Admission... Technology

* = basic Recomendations for IP-Telephony (VoIP)

4
 Neu: Sprach- und Daten- Konvergenz
Media
Gateway

Sprach- Daten-
Netzwerk LAN
Netzwerk (Backbone)
Digital IP
Telefon Telefon

Lokale Sprach- Daten- Daten- Daten-

Leitung Bndel Link Access Bitstrom
Leitung

In VoIP Netzwerken werden die Sprach- und Datendienste integriert

Jeder Dienst hat eigene Merkmale und spezifische Anforderungen an
die Netzwerkressourcen
Diese Anforderungen mssen durch entsprechende Engineering-
Massnahmen erfllt werden

5
 Neu: Sprach- und Daten- Konvergenz
Media
Gateway

Sprach- Daten-
Netzwerk LAN
Netzwerk (Backbone)
Digital IP
Telefon Telefon
Lokale Sprach- Daten- Daten- Datenbit-
Leitung Bndel Link Access Strom
Leitung

Vom Mund zum Ohr: maximal 150 ms

Transport im TDM Netz Codec Transport im IP Netz Jitter Buffer Codec

~ <10 ms 10 ms 100-110 ms 10-20 ms 10 ms

6
 Kontrollierte und unkontrollierte Beeintrchtigungen
(impairments) in den Paketnetzwerken
?

Nortel: Essentials of Real-Time Networking, p38

7
 Vergleich zwischen Sprach- und
Datenvermittlung
Klassische Sprachvermittlung
Bei einem einkommenden Anruf wird
dem Anrufer ein freier Kanal mit sofortiger Einkommende Erfolgreiche
Service-Verfgbarkeit zugeteilt, oder Anrufe Anrufe
falls kein Kanal frei ist, wird der Anruf Service
abgewiesen Funktion
Whrend der Dauer der Verbindung bleibt n Kanle (n>1)
der 64 kbit/s Kanal vollstndig und
permanent dieser Verbindung zugeteilt
Es sind multiple Kanle verfgbar Abgewiesene
Die Qualitt des Gesprches ist exzellent Anrufe
und konstant (Verluste)

End-to-End Verzgerungszeiten sind extrem

klein (Synchrone TDM Netzwerke)

8
 Vergleich zwischen Sprach- und
Datenvermittlung
Service Abgnge
Klassische Datenbertragung Anknfte Funktion (Departures)
(Arrivals) Buffer
Store & Forward Prinzip (Speichern/Senden)
Einkommen des Datenpakets:
A 1 Kanal mit
Bei einem freien Datenkanal wird das Kapazitt C
Datenpaket empfangen und sofort gesendet, oder
Warte-
das Datenpaket wird in die Warteschlange verschoben Positionen Transmission
(der Datenkanal besetzt) (Serialisation)
(Queue)
nach einer gewissen Zeit wird das Datenpaket aus der
Warteschlange geholt und gesendet A< C Bedingung fr ein stabiles System
Alle Daten werden ber einen Datenkanal
vermittelt Die Daten werden durch den Datenkanal
mit durchschnittlicher Verzgerungszeit Td
Fehler in der Transmission oder Bufferoverflows
verursachen Datenpaket-verluste gesendet :
Td = Tw + Tt + Tp
Jitter durch unregelmssige Transmissionszeiten
der Datenpakete Tw Durchschnittliche Wartezit in der
und Transmissionsfehler Warteschlange
Tt bertragungszeit des Datenpakets ber
den Datenkanal
Tp Signal-Ausbreitungsgeschwindigkeit
~ 5 ms/1000 km =1000/(2/3*300.000)9
 Konsequenzen
Erfolgreiche Service Abgnge
Einkommende Anknfte Funktion (Departures)
Anrufe Buffer
Anrufe (Arrivals)
Service
Funktion
A 1 Kanal mit
n Kanle (n>1) Kapazitt C
Warte-
GoS = Abgewiesene/Einkommende A.
Positionen Transmission
(Queue) (Serialisation)
Abgewiesene
Anrufe
(Verluste) Beispiel IP Telefonie ohne
Verkehrskontrollen (z.B. Skype)
Beispiel TDM Telefonie
Die Bandbreite fr n=10 Datenstrme
n=10 Kanle
(Kanle) vorhanden (dimensioniert)
Alle 10 Kanle sind benutzt (10
Alle 10 Kanle sind benutzt (10 Anrufe
Anrufe bereits im System)
bereits im System)
Es kommen weitere Anrufe: 11-ter,
Es kommen weitere Anrufe: 11-ter, 12-ter
12-ter usw.
usw.
11-ter, 12-ter usw. Anruf wird
11-ter, 12-ter usw. Anruf wird zugelassen
abgewiesen ()
(Warteschlange)
Bereits etablierte Anrufe spren
Bereits etablierte Anrufe werden
nichts davon
beeinflust d.h. alle Anrufe im System
spren die Qualittsverluste

10
 Engineering-Grundlagen
Engineering der Sprachnetze
Wie viele Sprachkanle brauche ich,
um Verkehrsverluste innerhalb der
Vorgaben zu halten?
Variablen
Anzahl der einkommenden Anrufe pro
Zeiteinheit
Dauer der Anrufe
Ankunfts- und Abgangs- Verteilungen der
Anrufe
Tolerierbare Verluste (Grade of service,
GOS)
Anzahl der Sprachkanle
Engineering der Datennetze
Welche Bandbreite brauche ich,
um Verzgerungszeiten innerhalb
der Vorgaben zu halten?
Variablen
Anzahl der einkommenden
Datenpaketen pro Zeiteinheit
Die Lnge der Datenpakete
Ankunfts- und Abgangs- Verteilungen
der Datenpakete
Wartezeit auf die bertragung
bertragungszeiten
Bandbreite (Kapazitt) des
Datenkanals
Jitter (Varianzen der
Zwischenankunftszeit)
11
 Problemdefinition und Lsungsansatz
Problemdefinition
Input: Bekanntes Verkehrsvolumen im TDM Netzwerk
Problem: Wie berechnet man die notwendige Bandbreite (Kapazitt) des
Datenkanals, um dieses Verkehrsvolumen innerhalb definierten
Vorgaben (GoS) zu bertragen?

n Sprachkanle
mit Datenstrom Lsungsansatz:
xx bit/s pro
Sprachkanal
Bekanntes 1 Datenkanal
1. Berechnung der Anzahl der
Verkehrs- mit Kapazitt Kanle und einzelnen
volumen C bit/s Datenstrme. (Erlang B Tabellen,
Nortel Tool/Tabellen)
TDM VoIP 2. Summieren der einzelne
Datenstrme, um auf die
Gesamtbandbreite zu kommen
Daten- 3. Delay Faktor berechnen
Sprach- Netzwerk (Pollaczek-Khinchin Formel) oder
Netzwerk (Backbone) schtzen und die Bandbreite
entsprechend korrigieren.

12
 Ohne ein bisschen Theorie geht es nicht
Verkehrsterminologie (Definitionen)
Zeit zwischen den Anrufe
(Inter-arrival Time)

Besetzt
(Busy)

Service-Zeit oder Ruhezeit

Haltezeit (Idle Time)
Nicht Besetzt (Holding or Service)
(Idle) Time)

Ankunftszeit Abgangszeit
(Arrival Time) (Deprature Time)

Arrivals = Calls = eingehendee Anrufe (calls/s, Anrufe/s)

Holding Time = Call Duration = Anrufdauer, Service Time (s, min, hours)
Traffic= Load= Verkehr=(Erlang im Sprachengineering)
13
 Verkehrsterminologie (Statistische Werte)

Statistische Verteilung der Ankunftszeiten

(Distribution of inter-arrival times)
Besetzt
(Busy)

Nicht Besetzt
(Idle)

Statistische Verteilung der Anrufsdauer (Haltezeiten)

oder Statistische Verteilung der Service-Zeiten
(Distribution of Holding or Service Times)

Kendalls notation for quieing systems:

A/B/C
A Statistische Verteilung der Ankunftszeiten
B Statistische Verteilung der Anrufsdauer (Haltezeiten)
C Anzahl Parallele Kanle (Servers)

Beispiele:
M/M/1 Typisch fr IP Datenverbindungen
M/D/1 Typisch fr ATM Datenverbindungen

M Exponentiale Verteilungsfunktion
D Deterministische Verteilungsfunktion
1 1 Datenkanal
14
 Beispiel fr eine Illustration der
vorherigen Definitionen
Ausgangslage:

30 Anrufe/ Stunde mit einer durchschnittlichen Dauer von 2 Minuten

Verkehrsvolumen = A = 30 Anrufe/Std x 2/60 Std = 1 (Erlang)

Frage:

Wie viele Leitungen braucht man, um diesen Verkehr mit weniger als 1%
Verlusten zu bedienen?

Antwort:

Ideen?

15
 Beispiel 1: Statistische Abhngigkeiten
Gleichfrmige Zugangsrate der Anrufe Beispiel: Outbound Dialer in einem CC
(Smooth Call Arrival Pattern)
30 Sequenzielle Anrufe mit je 2
Minuten Dauer
1 Trunk

Stossartige Zugangsrate der Anrufe Beispiel: Fernsehspiele oder Abstimmen

(Peaked Call Arrival Pattern)
30 Anrufe mit je 2 Minuten Dauer
innerhalb kurzen Zeit
bis 30 Trunks

Rein zufllige Zugangsrate der Anrufe Beispiel: Normale Telefonanrufe

(Random Call Arrival Pattern)
30 Anrufe mit je 2 Minuten Dauer
innerhalb 1 Stunde
5 Trunks (Erlang B)

Antwort:
Die Anzahl der Kanle ist von der statistischen Verteilungen der Zugangsraten und
Servicezeiten (Dauer der Anrufe, Haltezeiten) abhngig ! Die Verteilungen mssen
bekannt sein!
Quelle: Cisco
16
 Definition des Verkehrsvolumens
A (oder: a) Offeriertes Verkehrsvolumen in Erlang (Traffic Load)
l - Durchschnittliche Anzahl der Anrufe pro Zeiteinheit (Call Intensity)
m - Durchschnittliche Dauer des Anrufes (Mean Service Time)
A = l xm
Beispiel:
Bei durchschnittlich 2.5 Anrufen pro Minute und einer durchschnittliche Dauer der Anrufe von 3
Minuten betrgt das offerierte Verkehrsvolumen:
A = 2.5 x 60 Min x 3/60 Min = 7.5 Erlang ( )
Die Einheit Erlang hat keine Dimension

1 Erlang = 60 call minutes = 3600 call seconds = 36 centum call seconds CCS (hundred call seconds, wird
meistens in die USA verwendet)

1 CCS=1/36 Erlang, 1 Erlang=36 CCS

1 Sprachkanal hat eine Kapazitt von 1 Erlang

17
 Beispiel 2: Statistik
Die Call Records aus einer PBX Anlage stellen uns folgende Info zur Verfgung:
Es gibt 200 Teilnehmer (TN), die an diese PBX Anlage angeschlossen sind
Gesamtdauer aller Anrufe im Hauptverkehrsstunde (HVSt) betrgt 480 Minuten.
Alle Anrufe sind extern (d.h. keine lokale Anrufe!)

Gesucht:
Anzahl der Trunks, um diese PBX an das PSTN mit einem Grade of Service (GoS) 1% anzubinden?

Einfache Berechnungen:
Durchschnittliches Anrufdauer/Teilnehmer innerhalb der HVSt:
Anrufdauer/Teilnehmer =480 Minuten/200 TNs
=2.4 Minuten/Benutzer=2.4/60=0.04 Erlang/Teilnehmer
Das Telefonverkehr in HVSt betrgt:
a = 480 Min./60Min.=8 Erlangs (1 Trunk1 Erlang Max.)

Also 8 Trunks
Ja, wenn wir alle Anrufer irgendwie steuern knnen, oder
Stimmt diese Aussage? wenn die Anrufer geduldig an die Leitung warten!

Beispiel: Vermittler fr die internationale Anrufe.

Fr eine PBX Anlage stimmt diese Aussage generell nicht.

18
 Beispiel: Annahme Binomial Verteilung der Anrufe
Anzahl der aktiven Benutzer
B'(x,s,h)
0.16000

0.14000

0.12000

0.10000

B(x,s,h) Die Wahrscheinlichkeit, 0.08000

dass x von 200 Teilnehmer gleichzeitig 0.06000

aktiv (d.h. Telefonieren) und s-x nicht 0.04000

aktiv sind 0.02000

0.00000
a Verkehr innerhalb der HVSt 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

120.0000%
= h*s = 8 Erlang (Durchschnitt!)
s Anzahl Teilnehmer = 200
h Durchschnittliche Dauer der 100.0000%
Anrufe/Tln =2.4 Min (0.04 Erlang)

Konkret: fr GoS =1% 80.0000%

Bei welcher Anzahl der aktiven
Teilnehmer (Trunks) ist die
60.0000%
Wahrscheinlichkeit 1%, dass die
restliche Teilnehmer nicht
Telefonieren? 40.0000%

Antwort: 15 Check mit Erlang Calculator:

20.0000%
So viele Trunks braucht man um
15 gleichzeitige Anrufe weiterzuleiten
und die Verluste unter 1% zu halten 0.0000%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

19
 Erlang Verteilung und Erlang B Formel
Kein Angst, alles wurde bereits vor 100 Jahren berechnet!

Angebotener bertragener
Verkehr (Erlang) Verkehr (Erlang)

Einkommende Erfolgreiche
Anrufe Anrufe

1
Service
Funktion 2
B(c,a) Verkehrsverluste
n Kanle a Angebotener
Abgewiesene (n>1) Verkehr in Erlang
Anrufe
(Verluste) Messbar! c Anzahl der Kanle
Agner Krarup Erlang
3 1878 - 1929

1. Offered Traffic (Busy Hour Call Attempts (BHCA) Berechnungstools:

2. Carried Traffic (Busy Hour Call Completions (BHCC)) www.erlang.com
3. Rejected (Lost Calls Cleared) Traffic oder
ITU-T Tabellen
Grade of Service:
GoS = Rejected Traffic/Offered Traffic, z.B. GoS = 0.01 (P01)
GoS (%) = Rejected Traffic/Offered Traffic x 100 %, z.B. GoS = 1%

20
 Pollaczek-Khinchin Formel
Td fr ein M/M/1 System
Service Abgnge
Anknfte Funktion (Departures) (z.B. IP Datenkanal):
(Arrivals) Buffer

1
Td = Tt x
A 1 Kanal mit 1 - A/C
Kapazitt C
Warte-
Positionen Transmission
(Serialisation)
Td fr ein M/D/1 System
(Queue)
A< C Bedingung fr ein stabiles System
(z.B. ATM Datenkanal):
1
Td = Tw + Tt + Tp Td = Tt x x
Td Durchschnittliche Verzgerung im System 1 - A/C
Tw Durchschnittliche Wartezeit in der
Warteschlange Weiter ist:
Tt bertragungszeit des Datenpakets ber
den Datenkanal
Lm
Tp ~5 ms/1000 km Signal-Ausbreitungsgeschwindigkeit Tt =
A Einkommender Datenstrom in bit/s C
C Kapazitt des Datenkanals in bit/s Channel
Lm Datenpaketlnge in bit
Lm x N p Utilisation
U = A/C = Faktor
Np Max. Anzahl der Datenpakete pro Zeiteinheit C
21
 Beispiel
Bytes Bits
1
Packet Length 300 2400 Td = Tt x
1 - A/C
C (Link speed) 2'048'000 Bit/s Anzahl der
Meldungen In
der Warteschlange

Input Pakets/s Bits/s Tt (s) A/C (Load) Td (s) Td/Tt

700 1'680'000 0.001172 0.8203125 0.00652174 6

750 1'800'000 0.001172 0.8789063 0.00967742 8

800 1'920'000 0.001172 0.9375 0.01875 16

850 2'040'000 0.001172 0.9960938 0.3 256

851 2'042'400 0.001172 0.9972656 0.42857143 366

852 2'044'800 0.001172 0.9984375 0.75 640

853 2'047'200 0.001172 0.9996094 3 2560

22
Datenpaket-Verzgerungszeit v/s
Utilisation Faktor

23
Transport Path Diagram: Grosse der VoIP Meldungen

VoIP
Payload
(160 Bytes)

RTP Protokoll
(12 Bytes)
IP Protokoll
Overhead (28)

Transport
Overhead
(variable)

24
VoIP Datenpaket

=200 Bytes

=230 Bytes

=206 Bytes

>265 Bytes
0.16 IP
Payload
G.711 VoIP Codec (20ms voice sample) for Ethernet, Frame Relay and ATM networks fehlt!
25
 Fallbeispiel
Stao B
LAN Vorsicht!
CS 1000E
VoIP, nicht TDM!

Daten-
PSTN Netzwerk LAN
LAN
WAN

Stao C

CS 1000E L2 Router
Switch
Stao A
Core Data
Netzwerk:
Fiber, ATM, FR...

Mit heutiger LAN-Switch Technologie sind die LAN-Bandbreiten relativ

einfach und gnstig zu sichern d.h. diese sind nicht kritisch.
Die Vernetzung der Standorte verlangt WAN- Verbindungen. Diese
Verbindungen sind kritisch.
Signalsierungsverkehr verlangt wenig Bandbreite und beeinflusst kaum
die Berechnungen

26
 Fallbeispiel
Ausgangslage
Stao A - Stao B (A-B): 90 Anrufe/HVStd, Durchschnittliche Dauer 4 Min
Stao A - Stao C (A-C): 60 Anrufe/HVStd, Durchschnittliche Dauer 3 Min
Stao B Stao C (B-C): 30 Anrufe/HVStd, Durchschnittliche Dauer 2 Min
G.711 Codec, Paketdauer 20 ms, keine Silence Kompression, IP Link
Kein Datenverkehr (Alle PCs ausgeschaltet!)

Verkehrsvolumen Zwischen Stao A, B und C

A (A-B) = 90 x 4/60 =6 Erlang
A (A-C) = 60 x 3/60 =3 Erlang
Stao B
A (C-B) = 30 x 2/60 =1 Erlang
LAN

CS 1000E
6 Erl 1 Erl
Daten-
PSTN Netzwerk LAN
LAN
WAN
3 Erl Stao C

Stao A HVSt-Hauptverkehrsstunde

27
 Fallbeispiel
Verkehrsvolumen fr Stao A, B, C
A (Stao A)= A (A-B) + A (A-C) = 6 + 3= 9 Erlang
A (Stao B)= A (A-B) + A (C-B) = 6+ 1 =7 Erlang
A (Stao C)= A (A-C) + A (C-B) =3 +1 = 4 Erlang Tools:
www.erlang.com
oder
Anzahl der Trunks pro Stao:
ITU-T Tabellen
A (Stao A)= 9 Erlang17 Trunks (Datenstrme)
A (Stao B)= 7 Erlang14 Trunks
A (Stao C)= 4 Erlang10 Trunks Stao B
LAN
CS 1000E

9 Erl 7 Erl
Daten-
PSTN Netzwerk LAN
LAN
WAN
4 Erl Stao C

Stao A

28
 VoIP Codecs und Bandbreiten
G.711 (no VAD) Demand exceeds 100%! (can't do it!)
Demand exceeds 70% (caution)
<-!! Demand exceeds 100%! (can't do it!)
<-* Demand exceeds 70% (caution)
Fr ein Point-To-Point IP-Link:
G.711 w/ 10ms Packetization G.711 w/ 20ms Packetization
Bandwidth Total Link Bandwidth Total Link
over Full/Half Link Speed per trunk Bandwidth Utilization per trunk Bandwidth Utilization
Link Type

VoIP over Ethernet LAN

Duplex (kbps) (bps) (bps) (%) (bps) (bps) (%)
Link A: 17*80 kbit/s=1.36 Mbit/s
VoIP 802.3 Half 10'000 252'800 4'297'600 43% 190'400 3'236'800 32%
VoIP
VoIP
802.3
802.3
Half
Full
100'000
100'000
252'800
126'400
4'297'600
2'148'800
4%
2%
190'400
95'200
3'236'800
1'618'400
3%
2%
Link B: 14*80 kbit/s=1.12 Mbit/s
Link C: 10*80 Kbit/=0.8 Mbit/s
VoIP over Frame Relay w/o RTP Header Compression
VoIP Frame Relay Full 56 100'800 1'713'600 3060% <-!! 82'400 1'400'800 2501%
VoIP Frame Relay Full 64 100'800 1'713'600 2678% <-!! 82'400 1'400'800 2189%
VoIP Frame Relay Full 128 100'800 1'713'600 1339% <-!! 82'400 1'400'800 1094%
VoIP Frame Relay Full 256 100'800 1'713'600 669% <-!! 82'400 1'400'800 547%
VoIP Frame Relay Full 512 100'800 1'713'600 335% <-!! 82'400 1'400'800 274%
VoIP Frame Relay Full 768 100'800 1'713'600 223% <-!! 82'400 1'400'800 182%
VoIP
VoIP
VoIP
Frame Relay
Frame Relay
Frame Relay
Full
Full
Full
1'024
1'536
3'072
100'800
100'800
100'800
1'713'600
1'713'600
1'713'600
167%
112%
56%
<-!!
<-!!
82'400
82'400
82'400
1'400'800
1'400'800
1'400'800
137%
91%
46%
Angenommen, dass diese
VoIP Frame Relay Full 6'144 100'800 1'713'600 28% 82'400 1'400'800 23%
VoIP
VoIP
VoIP
Frame Relay
Frame Relay
Frame Relay
Full
Full
Full
9'216
12'288
15'360
100'800
100'800
100'800
1'713'600
1'713'600
1'713'600
19%
14%
11%
82'400
82'400
82'400
1'400'800
1'400'800
1'400'800
15%
11%
9%
Bandbreiten tatschlich so
VoIP
VoIP
Frame Relay
Frame Relay
Full
Full
18'432
43'008

VoIP over PPP link w/o RTP Header Compression

100'800
100'800
1'713'600
1'713'600
9%
4%
82'400
82'400
1'400'800
1'400'800
8%
3% implementieret sind, wird die
VoIP
VoIP
VoIP
PPP
PPP
PPP
Full
Full
Full
56
64
128
102'400
102'400
102'400
1'740'800
1'740'800
1'740'800
3109%
2720%
1360%
<-!!
<-!!
<-!!
83'200
83'200
83'200
1'414'400
1'414'400
1'414'400
2526%
2210%
1105%
Lsung funktionieren?
VoIP PPP Full 256 102'400 1'740'800 680% <-!! 83'200 1'414'400 553%
VoIP PPP Full 512 102'400 1'740'800 340% <-!! 83'200 1'414'400 276%
VoIP PPP Full 768 102'400 1'740'800 227% <-!! 83'200 1'414'400 184%
VoIP PPP Full 1'024 102'400 1'740'800 170% <-!! 83'200 1'414'400 138%
VoIP PPP Full 1'536 102'400 1'740'800 113% <-!! 83'200 1'414'400 92%

VoIP in ATM/AAL-5
VoIP
VoIP
ATM (AAL-5)
ATM (AAL-5)
Full
Full
1'536
3'072
127'200
127'200
2'162'400
2'162'400
141% <-!!
70% <-*
106'000
106'000
1'802'000
1'802'000
117%
59%
Was ist mit den Queuing Delays?
VoIP ATM (AAL-5) Full 6'144 127'200 2'162'400 35% 106'000 1'802'000 29%
VoIP ATM (AAL-5) Full 9'216 127'200 2'162'400 23% 106'000 1'802'000 20%
VoIP ATM (AAL-5) Full 12'288 127'200 2'162'400 18% 106'000 1'802'000 15%
VoIP ATM (AAL-5) Full 15'360 127'200 2'162'400 14% 106'000 1'802'000 12%
VoIP
VoIP
VoIP
ATM (AAL-5)
ATM (AAL-5)
ATM (AAL-5)
Full
Full
Full
18'432
43'008
50'112
127'200
127'200
127'200
2'162'400
2'162'400
2'162'400
12%
5%
4%
106'000
106'000
106'000
1'802'000
1'802'000
1'802'000
10%
4%
4%
In Spitzenzeiten Delay >>100 ms
VoIP ATM (AAL-5) Full 150'336 127'200 2'162'400 1% 106'000 1'802'000 1%
VoIP
VoIP
VoIP
ATM (AAL-5)
ATM (AAL-5)
ATM (AAL-5)
Full
Full
Full
601'344
2'405'376
4'810'752
127'200
127'200
127'200
2'162'400
2'162'400
2'162'400
0%
0%
0%
106'000
106'000
106'000
1'802'000
1'802'000
1'802'000
0%
0%
0%
Keine Gesprche sind mglich!
VoIP ATM (AAL-5) Full 9'621'504 127'200 2'162'400 0% 106'000 1'802'000 0%

VoIP over Frame Relay w/ RTP Header Compression

VoIP Frame Relay Full 56 72'800 1'237'600 2210% <-!! 68'400 1'162'800 2076%
VoIP Frame Relay Full 64 72'800 1'237'600 1934% <-!! 68'400 1'162'800 1817%
VoIP Frame Relay Full 128 72'800 1'237'600 967% <-!! 68'400 1'162'800 908%
VoIP Frame Relay Full 256 72'800 1'237'600 483% <-!! 68'400 1'162'800 454%
VoIP
VoIP
VoIP
Frame Relay
Frame Relay
Frame Relay
Full
Full
Full
512
768
1'024
72'800
72'800
72'800
1'237'600
1'237'600
1'237'600
242%
161%
121%
<-!!
<-!!
<-!!
68'400
68'400
68'400
1'162'800
1'162'800
1'162'800
227%
151%
114%
Nortel VoIP
VoIP Frame Relay Full 1'536 72'800 1'237'600 81% <-* 68'400 1'162'800 76%
VoIP
VoIP
VoIP
Frame Relay
Frame Relay
Frame Relay
Full
Full
Full
3'072
6'144
9'216
72'800
72'800
72'800
1'237'600
1'237'600
1'237'600
40%
20%
13%
68'400
68'400
68'400
1'162'800
1'162'800
1'162'800
38%
19%
13%
Bandwith Tool
VoIP Frame Relay Full 12'288 72'800 1'237'600 10% 68'400 1'162'800 9%
VoIP Frame Relay Full 15'360 72'800 1'237'600 8% 68'400 1'162'800 8%
VoIP Frame Relay Full 18'432 72'800 1'237'600 7% 68'400 1'162'800 6%
VoIP Frame Relay Full 43'008 72'800 1'237'600 3% 68'400 1'162'800 3%

VoIP over PPP link w/ RTP Header Compression

VoIP PPP Full 56 74'400 1'264'800 2259% <-!! 69'200 1'176'400 2101%
VoIP PPP Full 64 74'400 1'264'800 1976% <-!! 69'200 1'176'400 1838%

G.711: 8000 samples/s x 1Byte (8 bit) => 64 kbit/s-->1 ms pro sample Source: Nortel
G.711 Codec:80 samples@ 1 Byte (8bit) @64 kbit/s=10msIP overhead reduction
29
 Empfehlung: Delay-bedingte
Overprovisioning
Berechnete Bandbreiten
Link A: 17*80 kbit/s=1.36 Mbit/s
Link B: 14*80 kbit/s=1.12 Mbit/s
Link C: 10*80 Kbit/=0.8 Mbit/s

Empfohlen +30%:
Link A: 1.768 Mbit/s
Link B: 1.456 Mbit/s
Link C: 1.04 Mbit/s

Diese Bandbreiten sind in Datennetzen nicht beliebig, sondern in Stufen whlbar.

Z.B. es kann sein, dass fr das Link A zwei Optionen offeriert sind: 1.5 und 3.0 Mbit/s. Einzige
richtiges Auswahl ist dann 3.0 Mbit/s.
Diese Overprovisioning ist nicht die Lsung fr das QoS Problem! Es ist nur die
Voraussetzung fr eine richtige Funktionieren der QoS Mechanismen!

30
 Call Admission Control (Zones)
Call Admission Control is required if
the VoIP traffic might exceed the
available bandwidth.

For example if there is only 256K of

class 1 MPLS bandwidth to a site with
50 users, then Call Admission Control
is required to restrict the number of
VoIP calls attempting to use that
WAN connection.

(In MPLS networks such as BTs IP

Clear, VoIP packets will be discarded
if the subscribed bandwidth is
exceeded).
Einkommende Erfolgreiche
Anrufe Anrufe

Service
Scheint Ihnen dieses Funktion
Vorgehen irgendwie Available
bereits bekannt? Bandwidth
Abgewiesene
Anrufe
(Verluste)

31
 Sprache und Daten zusammen
CS 100E Router

Frage: Core Data

Netzwerk:
Fiber, ATM, FR...
Was passiert wenn wir die PCs jetzt
einschalten?
Konsequenzen
Anknfte
Wir brauchen mehr Bandbreite (Arrivals)

A1 (Sprache) Prio 1: Sprache Service Abgnge

Die Datenpakete mssen priorisiert Funktion (Departures)
werden
A2 Daten Prio 2: Daten
Verzgerungszeiten
1 Kanal mit
Jitter wird hher Kapazitt C

Paketverluste auch (buffer overflows) Warte- Transmission

Positionen (In-Service)
Technology muss entsprechend A1 + A2 < C (Queue)
angepasst werden (QoS)

32
 Beispiel: sunrise IP VPN
Effizient und sicher
Mit dem Virtual Private Network (VPN) von sunrise verbinden Sie alle
Niederlassungen Ihres Unternehmens effizient und sicher.
Die Quality of Service (QoS) im sunrise IP VPN erlaubt es, nahezu alle
Anwendungen ber eine Netzinfrastruktur zu betreiben. Bandbreiten von 64kbps bis
155Mbps fr die direkte Anbindung bieten eine optimale Abstimmung auf Ihre
Bedrfnisse.
ber das eigene Glasfasernetz und dem Equipment vom fhrenden Hersteller Cisco
betreibt sunrise die modernste IP-Netzinfrastruktur. Mit der auf Multi Protocol Label
Switching (MPLS) basierenden Plattform erhalten Sie einen Service fr die hchsten
Ansprche zu einem attraktiven Preis.
Ihre Vorteile
Der end-to-end Service garantiert den zuverlssigen Betrieb von Ihrem WAN
inklusive der vor Ort installierten Router fr den bergang zu Ihrem lokalen Netz.
Einfacher und flexibler Ausbau bis zur any-to-any Kommunikation in Ihrem VPN.
Mit dem sunrise ip vpn sind Sie bereit fr die Integration von Sprache, Daten und
Video.
Die Einbindung vom Internet ist eine kostengnstige Ergnzung und erfolgt ber eine
dedizierte Firewall fr die hchste Sicherheit in Ihrem Netz.
Mit sunrise ip remote erweitern Sie den geschtzten Zugriff auf Ihre Daten, E-Mails
und Applikationen fr mobile Mitarbeitende oder Partner.
Die Auslastung im Netz von sunrise ist zu jedem Zeitpunkt bekannt und ein Ausbau
der Infrastruktur wird proaktiv geplant und durchgefhrt. Dadurch kann ein
Hchstmass an Qualitt und Performance gewhrleistet werden.
Hauptmerkmale
Mit der heute dominierenden Technologie Multi Protocol Label Switching (MPLS) wird
Ihre Netzstruktur in einem Virtual Private Network zusammengefasst.
Access Bandbreiten von 64kbps bis 155Mbps bieten eine optimale Abstimmung auf
Ihre Bedrfnisse.
Performance Reporting, Service Management und Verschiedene Support-Levels fr
die berwachung und den zuverlssigen Betrieb.
sunrise konzipiert, installiert, betreibt und berwacht Ihren Service mit
ausgezeichneten

33
 Teil 2: Quality of Service in
Datenentze
Vorsetzung nach Bedarf...

34
 Referenzen
1. Hans Kruse, Ohio University: Introduction to Traffic Engineering
2. Diverse Nortel, Cisco und ITU-T Documentation

35