Modélisation, estimation et contrôle, pour les réseaux de

Modélisation, estimation et contrôle
pour
les réseaux de télécommunication
MGR 815
Prof. Zbigniew Dziong
Plan
 Introduction du prof.
 Introduction aux MGR-815
 VoIP (Voix sur IP) : exemple de système
qui sera utilisé pour l'illustration des
algorithmes de modélisation, estimation
et contrôle.
 Modélisation de VoIP : exemple
1997 - 2003 Bell Labs, Lucent Technologies,
High Performance Communication Systems Dep.,
Holmdel, New Jersey, USA
Consultant pour divers départements dans le domaine de la
performance, des protocoles, de l'architecture et de la gestion
des ressources pour la prochaine génération des réseaux
optiques, IP, ATM, Ethernet, et sans fil.
Projets chez Bell Labs:
 Conception d'architecture et des algorithmes de
recouvrement de panne de liens à implémenter dans
Lambda Unite, le nouveau commutateur avancé et brasseur
de conduits (ou cross-connect) SONET pour les réseaux
optiques.
 Contribution au développement d'une nouvelle architecture
de réseau où le nuage de MPLS est introduit dans le réseau
ATM. Cette architecture permet une réduction du coût dans
l'évolution vers les réseaux multi-service. En particulier, la
conception du cadre et des algorithmes pour le routage QoS
et la gestion des ressources.
 Dérivation du modèle de rendement pour le chargement de
CPU dans le commutateur Ethernet MPLS conçu à Lucent.
 Développement d'algorithmes de routage pour réseaux
optiques avec des routes partagées, ce qui a réduit de 30%
le coût du réseau.
 Contribution à la conception d'un commutateur multi-térabit
indépendant du protocole, qui a permis d'augmenter le débit
de 50%.
Projets chez Bell Labs (cont.):
 Conception d'un outil nécessaire dans la conception pour
localisation du secteur (location area) dans les réseaux GSM
ce qui a amélioré significativement la planification du réseau.
 Dérivation des modèles de précision de géolocalisation pour
les réseaux assistés par GPS dans les réseaux UMTS.
 Analyse de la performance de plusieurs algorithmes pour un
système d'ordonnancement pour CDMA 2000.
 Conception de l'architecture de mesure de la capacité et de
la performance des systèmes sans fil de la troisième
génération.
 Conception des algorithmes d'admission d'appel adaptifs
basés sur les systèmes d'exploitation pour les commutateurs
ATM.
 Conception des modèles de performance pour le contrôle de
surcharge dans les systèmes de CDMA qui ont fourni une
nouvelle implémentation d'algorithme.
Les réalisations mentionnées ci-dessus sont documentées dans 14
applications de brevet et plusieurs publications dans des journaux et des
conférences, ainsi que dans des rapports.
1987 – 1997 INRS-Telecommunications,
Montreal, Canada
 Collaboration à l'obtention et la réalisation de plusieurs contrats
de recherche de BNR (Nortel) et de plusieurs subventions CRSNG
et ICRT.
 Développement de modèles de contrôle, de performance et de
dimensionnement des réseaux divers comme les réseaux à
commutation de paquets rapide (ATM) et les réseaux sans fil.
 Obtention du prix STENTOR 1993 pour la recherche et la
contribution dans le domaine de l'acheminement dynamique
dans les réseaux à commutation de circuits.
 Les résultats majeurs de la recherche sont publiés dans le livre
``ATM network resource management``, 1997 McGraw Hill.
Plan
 Introduction du prof.
 Introduction aux MGR-815
 VoIP (Voix sur IP) : exemple de système
qui sera utilisé pour l'illustration des
algorithmes de modélisation, estimation
et contrôle.
 Modélisation de VoIP : exemple
MGR 815: Problématique
SYSTÈME DE SERVICE
DE DEMANDES
ENTRÉ
SORTIE
SUPERVISION
des demandes
SUPERVISION
de la performance
(Estimation, Prevision)
(Estimation, Prevision)
MODÈLE
(analitique
ou
simulation)
CONTRÔLE
(admission,
paramètres
de système)
performance
du modèle
(en ou hors ligne)
OBJECTIFS
de la
performance
MGR 815: Applications
 Systèmes de télécommunications comme:
 réseaux IP
 réseaux MPLS
 réseaux VoIP
 Système de services avec les fils d’attente comme:
 magasins
 cliniques
MGR 815: Description sommaire
 Fournir à l’étudiant les connaissances requises pour mesurer,
analyser et contrôler les performances des réseaux de
télécommunication.
 L’introduction aux processus stochastiques incluant les éléments de
la théorie des files d’attente.
 Étude de l’estimation en présence de bruit.
 Éléments de théorie de la décision en présence de bruit.
 Modèle de décision de Markov pour maximiser la revenue.
 Théorie du jeu pour avoir la performance équitable.
 Applications des modèles mathématiques pour contrôler le trafic
(contrôle d’admission, contrôle du flou, acheminement) et gestion
des ressources dans les réseaux basés sur les technologies
différentes.
 Exemples des applications incluant les réseaux IP, MPLS.
Objectifs du cours
À la fin de ce cours, l'étudiant sera capable de :
 Comprendre et appliquer les notions d’estimation, modélisation,
et contrôle dans les réseaux de télécommunications à fin de
contrôler la performance et qualité de service, QdS.
 Concevoir et implémenter une méthode d’estimation et contrôle
de trafic et performance dans le réseau particulier
(préférablement associée avec le sujet de la recherche).
SYS 861, Prof. Zbigniew Dziong
11
Stratégie pédagogique
Les connaissances seront transmises par :
 Un enseignement hebdomadaire sous la forme d'un cours
magistral.
– Le cours va donner l’introduction aux plusieurs sujets de bases qui sont
nécessaire pour adresser les problèmes d’estimation, modélisation, et
contrôle dans les réseaux de télécommunications. La présentation
évitera orientation purement théorique et sera plutôt à mi-chemin
entre théorie et pratique.
 Le projet d’implémentations
– Dans le projet d’implémentations, l’étudiant analysera un système de
service en utilisant des méthodes de modélisation, d’estimation et
prévision, et de contrôle de trafic et performance. L’utile préféré est
Matlab.
Contenu du cours (1,2)
1) Introduction:
a. L’introduction aux problématiques de modélisation,
estimation et contrôle dans les réseaux de
télécommunications
b. VoIP (Voice over IP) : exemple de système qui sera
utilisé pour l'illustration des algorithmes de
modélisation, estimation et contrôle.
2) Introduction aux processus aléatoires et la
simulation:
a.
b.
c.
d.
Les concepts de base de probabilité.
Les variables aléatoires.
Les processus aléatoires.
L’introduction à la simulation
Contenu du cours (3,4,5)
3) Modèles de séries chronologiques:
a.
b.
c.
MA, AR, ARMA, ARIMA
Estimation
Prévision
i
ii
Extrapolation
Lissage exponentiel - ``Exponential Smoothing``.
4) Filtre de Kalman:
a.
b.
L'introduction au filtre de Kalman
Application de filtre de Kalman pour prédiction de trafic.
5) Architecture de la gestion des ressources,
basée sur la représentation multicouche du
trafic et les réseaux virtuels.
a. MPLS : exemple du protocole utilisé pour la gestion des ressources.
Contenu du cours (6,7,8)
6) Processus de Markov
a. avec le temps discret
b. avec le temps continu
c. formule d'Erlang
7) Introduction aux processus de décision de
Markov
a. avec le temps discret
b. avec le temps continu
c. Trois modèles pour obtenir une solution
8) L'admission des appels et routage dynamique
a. modèle économique basé sur le prix caché
b. les exemples
Contenu du cours (9,10,11,12)
9) Introduction à la théorie de file d'attend
a. Little's Formula
b. file d'attend M/M/1,c,oo
c. file d'attend M/G/1
10) ``Fair queuing``.
11) Théorie du jeu pour avoir la performance
équitable.
12)
Présentation des projets.
- Le contenu peut être adapté selon les besoin des projets
des étudiants.
Projets
1. Analyse des séries chronologiques
a. Simulation du système de service pour obtenir
des séries chronologiques
b. Estimation et prévision des séries
2. Modélisation et contrôle
a. Application de processus de décision de Markov
pour modéliser et contrôler un système de
service
Organisation des Projets
•
Groups de deux étudiants (trois dans les cas exceptionnels)
–
–
•
Chaque group aura un coordinateur (fonctions: coordination
de taches et de charge, communication avec le prof).
Il y aura un changement du coordinateur après chaque phase
du projet.
Évaluation du projet basé sur
–
Rapport, présentation,
Évaluation
1) Test 1
20%
2) Test 2
30%
3) Projet
50%
(rapport – 35%, présentation – 15%)
Références bibliographiques
1) Chris Chatfield. The analysis of time
series: an introduction. Chapman & Hall,
2003.
2) Henk C. Tijms. Stochastic models : an
algorithmic approach. Wiley, 1994.
3) Zbigniew Dziong. ATM network resource
management. McGraw-Hill, 1997.
4) Sanjay Bose. An introduction to queuing
systems.
Kluwer
Academic/Plenum
Publishers. 2001
Consultations
Je serai disponible pour les consultations tous les
mardi de 19h à 20h dans la salle A-3334
Zbigniew Dziong:
local 2482
[email protected]
tél : 396 8686
Plan
 Introduction du prof.
 Introduction aux MGR-815
 VoIP (Voix sur IP) : exemple de
système qui sera utilisé pour
l'illustration des algorithmes de
modélisation, estimation et contrôle.
 Modélisation de VoIP : exemple
Understanding VoIP Networks
• White Paper
• Stefan Brunner, Senior Network Security Consultant
• Akhlaq A. Ali, Senior Marketing Engineer
•
•
•
•
•
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
408 745 2000 or 888 JUNIPER
www.Juniper.net
Why VoIP?
• Cost-effectiveness
• Convergence of voice and data networks
• VoIP promises to deliver many nice new features,
such as:
–
–
–
–
–
–
advanced call routing,
computer integration,
integrated information services,
long-distance toll bypass,
encryption.
Integration of other media services, like video or even
electronic white boards,
VoIP Components
•
•
•
•
Call Processing Server/IP PBX
User End-Devices
Media/VOIP Gateways
IP network
Call Processing Server/IP PBX
• Call Processing Server/IP PBX
Call Processing Server Signaling
User End-Devices
Media/VOIP Gateways/Gatekeepers
POTPlain
Old
Telephone
Media/VOIP Gateways/Gatekeepers
• Trunking gateways that interface between the telephone network
and a VoIPnetwork. Such gateways typically manage a large number
of digital circuits.
• Residential gateways that provide a traditional analog interface to a
VoIP network. Examples of residential gateways include cable
modem/cable set-top boxes, xDSL devices and broadband wireless
devices.
• Access media gateways that provide a traditional analog or digital
PBX interface to a VoIP network. Examples include small-scale
(enterprise) VoIP gateways.
• Business media gateways that provide a traditional digital PBX
interface or an integrated soft PBX interface to a VoIP network.
• Network access servers that can attach a modem to a telephone
circuit and provide data access to the Internet.
IP Network
• IP network must treat voice and data traffic differently.
• Class of service (CoS) ensures that packets of a specific
application are given priority.
• This prioritization is required for real-time VoIP
applications to ensure that the voice service is
unaffected by other traffic flows.
VoIP Signaling Protocols
Standards bodies: ITU and IETF
More implementations on the ITU specifications than
those of the IETF.
• H.323 (ITU)
• MGCP (IETF)
• SIP (IETF)
• Megacao/H.246 (IETF and ITU)
• Transport protocols
– RTP
– RTCP
H.323
H.323
• Gateways serve as both the H.323 termination endpoint
and interface with non-H.323 networks, such as the
PSTN.
• Gatekeepers function as a central unit for call admission
control, bandwidth management and call signaling.
Although the gatekeeper is not a required element in
H.323, it can help H.323 networks to scale to a larger
size, by separating call control and management
functions from the gateways.
H.323
• First to classify and solve multimedia delivery issues over LAN
technologies.
• H.323 is heavier (due to chattiness, in terms of control
signaling).
• Shortcomings in scalability, especially in large-scale
deployments.
• H.323 is dependant on TCP-based (connection-oriented)
signaling. There is a challenge in maintaining large numbers of
TCP sessions because of the substantial overhead involved.
• May not be well suited in service provider spaces, it is well
positioned to deploy enterprise VoIP applications.
Media Gateway Control Protocol (MGCP)
Media Gateway Control Protocol (MGCP)
• It breaks up the role of traditional voice switches into the
components of media gateway, media gateway controller (call
agent) and signaling gateway functional units. This facilitates the
independent managing of each VoIP gateway as a separate entity.
• MGCP is a master-slave control protocol that coordinates the
actions of media gateways.
• The call agent manages the call-related signaling control
intelligence, while the media gateway informs the call agent of
service events.
• The call agent instructs the media gateway to create and tear down
connections when the calls are generated. In most cases, the call
agent informs the media gateways to start an RTP session between
two endpoints.
Session Initiation Protocol (SIP)
Session Initiation Protocol (SIP)
• Client-server signaling protocol that handles the setup and tear down of
multimedia sessions between speakers; these sessions can include multimedia
conferences, telephone calls, and multimedia distribution.
• SIP is a text-based signaling protocol transported over either TCP or UDP, and is
designed to be lightweight. It inherited some design philosophy and
architecture from the Hypertext Transfer Protocol (HTTP) and Simple Mail
Transfer Protocol (SMTP) to ensure its simplicity, efficiency and extensibility.
• SIP uses invitations to create Session Description Protocol (SDP) messages to
carry out capability exchange and to setup call control channel use. These
invitations allow participants to agree on a set of compatible media types.
• SIP supports user mobility by proxying and redirecting requests to the user's
current location. Users can inform the server of their current location (IP
address or URL) by sending a registration message to a registrar. This function
is powerful and often needed for a highly mobile voice user base.
Session Initiation Protocol (SIP)
Megaco/H.248
• Megaco/H.248 is a current draft standard and
represents a cooperative proposal from the IETF and
ITU standards bodies.
• Megaco has many similarities to MGCP and borrows
the same naming conventions for the VoIP elements.
• The Megaco architecture defines media gateways
that provide media conversion and sources of calls,
while media gateway controllers provide call control.
Megaco/H.248 goals
• Provides a path for rapid expansion to support
sophisticated business telephony features.
• Allows for a wide range of telephones and similar
devices to be defined from very simple to very
feature rich.
• Implements a simple, minimal design.
• Allows device cost to be appropriate to capabilities
provided.
• Package and termination types have characteristics
that enable reliability.
Real-time Transport Protocol (RTP)
• RFC 1889 and RFC 1890 cover the Real-time Transport Protocol
(RTP), which provides end-to-end delivery services for data with
real-time characteristics, such as interactive audio and video.
• Ability to reconstruct timing, loss detection, security, content
delivery and identification of encoding schemes.
• RTP is an application service built on UDP, so it is connectionless,
with best-effort delivery.
• Although RTP is connectionless, it does have a sequencing
system that allows for the detection of missing packets.
Real-time Transport Protocol (RTP)
Real-time Transport Protocol (RTP)
• RTP Payload Type field includes the encoding scheme that
the media gateway uses to digitize the voice content.
• This field identifies the RTP payload format and
determines its interpretation by the CODEC in the media
gateway.
• A profile specifies a default static mapping of payload
type codes to payload formats. These mappings represent
the ITU G series of encoding schemes.
ITU G series of encoding schemes
Real-time Transport Control Protocol (RTCP)
• RTCP enables administrators to monitor the quality of a call
session by tracking packet loss, latency (delay), jitter, and
other key VoIP concerns. This information is provided on a
periodic basis to both ends and is processed per call by the
media gateways.
• If using RTCP (or a vendor-specific implementation) in the
network, the organization needs to take into account
bandwidth calculations for the protocol.
• RFC specifications recommend that the fraction of the session
bandwidth allocated to RTCP be fixed at five percent of RTP
traffic.
A general view
• and the result…
RTP/RTCP and RTSP (from server)
multimedia protocols for the Internet
Projet Planète; INRIA Rhône-Alpes
[email protected]
August 29th, 2001
VoIP Service Considerations
•
•
•
•
•
•
Latency
Jitter
Bandwidth
Packet loss
Reliability
Security
Latency
• The end-to-end latency should be less than 150
ms for toll quality phone calls.
• To ensure that the latency budget remains below
150 ms, administrators need to take into account
the following primary causes of latency.
“packetization” delays
• Caused by the amount of time it takes to fill a packet
with data.
• Generally, the larger the packet size, the greater the
amount of time it takes to fill it.
• Packetization delay is governed by the CODEC
standard being used.
• Nominal operation of any media gateway unit should
not exceed 30 ms.
Serialization (transmission) delay
• Another source of latency is the delay it takes to serialize the digital data
onto the physical links of the interconnecting equipment.
• This delay is inversely proportional to the link speed. In other words, the
faster the media, the lower the latency.
• For example, it takes 125 microseconds to place one byte on a 64-Kb circuit.
• The same byte placed on an OC-3/STM-1 circuit takes 0.05 microseconds.
• Although this delay is unavoidable (regardless of the bandwidth used),
keeping the number of intervening links small and using high bandwidth
interfaces reduces the overall latency.
Propagation delay
• Propagation delay is the time it takes an electrical (or photonic)
signal to traverse the length of a conductor. The speed of these
signals is always slower than that of the speed of light.
• There is always propagation delay; however, it only becomes an
issue when the signal (or packet) travels a great distance.
• The accepted formula for calculating propagation delay is as
follows.
– Propagation delay = Circuit km / (299,300 km x .6)
• Example: Calculation of one-way propagation delay of a 6,000 km
fiber run (discounting any signal repeaters in between)
– 0.0334 sec = 6000 km / (299,300 km x .6)
By this calculation, the latency contributed by just propagation delay
would be 33.4 ms.
Queuing delay
• A queuing delay, which is a large source of latency, is the amount of time
that a packet remains buffered in a network element while it awaits
transmission.
• Network traffic loads result in variable queuing delays.
• The amount of buffer that a queue uses is usually a configurable
parameter, with a smaller number being better for latency values.
• However, this delay is also based on the amount of traffic the element is
trying to pass through a given link, and therefore it increases with network
load.
• Hence, you need to set aside adequate bandwidth and resources for voice
traffic. If the queue used for voice traffic is not serviced fast enough and
that queue is allowed to grow too large, the result is greater latency.
Packet forwarding delay
• Packet forwarding delay is the time it takes a network device
(router, switch, firewall, etc.) to buffer a packet and make the
forwarding decision.
• Included in that decision could be which interface to forward the
packet to, whether to drop or forward the packet against an
Access Control List (ACL) or security policy, etc.
• Packet forwarding delay is variable and depends on the function
and architecture of the networking device.
• If a packet must be further buffered as a part of its processing,
greater latency is incurred.
Jitter
• The greatest culprit of jitter is queuing variations caused by
dynamic changes in network traffic loads.
• Another cause is packets that might sometimes take a different
equal-cost link that is not physically (or electrically) the same
length as the other links.
• Media gateways have play-out buffers that buffer a packet
stream, so that the reconstructed voice waveform is not affected
by packet jitter.
• Play-out buffers can minimize the effects of jitter, but cannot
eliminate severe jitter.
• Although some amount of jitter is to be expected, severe jitter
can cause voice quality issues because the media gateway might
discard packets arriving out of order.
• In this condition, the media gateway could starve its play-out
buffer and cause gaps in the reconstructed waveform.
Packet Loss
• The protocols used by non-real-time applications, usually TCP, are
tolerant to some amount of packet loss because of their
retransmission capabilities.
• Real-time applications based on UDP are significantly less tolerant
to packet loss. UDP does not have retransmission facilities,
however, retransmissions would almost never help.
• Although packet loss of any kind is undesirable, some loss can be
tolerated. As long as the amount of packet loss is less than five
percent for the total number of calls, the quality generally is not
adversely affected.
• It is best to drop a packet, versus increasing the latency of all
delivered packets by further buffering them.
Bandwidth
• If an administrator allocates too little bandwidth for voice service,
there might be unacceptable quality issues.
• Another consideration is that voice services are less tolerant to
bandwidth depletion than that of Internet traffic. Therefore,
bandwidth for voice services and associated signaling must take a
priority over that of best-effort Internet traffic.
• VoIP networks that employ compression and silence suppression
could actually use less bandwidth than a similar circuit-switched
network.
Bandwidth
• Allocations of network bandwidth are based on
projected numbers of calls at peak hours. Any
over-subscription of voice bandwidth can cause a
reduction in voice quality.
• Also, you must set aside adequate bandwidth for
signaling to ensure that calls are complete and to
reduce service interruptions.
Bandwidth example
• 2,000 full-duplex G.711 encoded voice channels that have a
packet creation rate of 20 ms, with a packet size of 200 bytes (40
byte IP header + 160 byte payload)
– 160 Mbps = 50 x 200 x 2,000 x 8
does not take in account the overhead used by the transporting
media (links between the routers) and data-link layer protocols.
• Signaling bandwidth requirements vary depending on the rate at
which the calls are generated and the signaling protocol used.
– If a large number of calls are initiated in a relatively short period, the peak
bandwidth needs for the signaling could be quite high.
– A general guideline for the maximum bandwidth requirement that an IP signaling
protocol needs is roughly three percent of all bearer traffic.
– Using the previous example, signaling bandwidth requirements, if all 2,000 calls
were initiated in one second, would be approximately 4.8 Mbps (3 percent of 160megabits).
Plan
 Introduction du prof.
 Introduction aux MGR-815
 VoIP (Voix sur IP) : exemple de système
qui sera utilisé pour l'illustration des
algorithmes de modélisation, estimation
et contrôle.
 Modélisation de VoIP : exemple