TABLE DES MATIERES
LISTE DES ABREVIATIONS ................................................................................................... iii
LISTE DES FIGURES.............................................................................................................. vii
LISTE DES TABLEAUX ........................................................................................................... ix
INTRODUCTION ....................................................................................................................... 1
CHAPITRE 1 : NOTIONS DE BASE SUR LE TRAFIC............................................................ 2
1.1 Télétrafic [1][2][3] ................................................................................................................. 2
1.1.1 Modélisation des instants d'arrivée d'appel ...............................................................................3
1.1.2 Modélisation des durées d’appels .................................................................................................7
1.1.3 Modélisation des processus d’apparition et de fin d’appels ..........................................................8
1.1.4 Probabilité de blocage et formule d’Erlang B ............................................................................ 10
1.1.5 Probabilité de mise en attente et formule d’Erlang C................................................................ 12
1.1.6 Cas d’une population finie et distribution d’Engset ................................................................... 13
1.1.7 Mesures de trafic........................................................................................................................ 13
1.2 Modélisation du trafic IP [3][4][5][6] .................................................................................. 14
1.2.1 Files d’attente............................................................................................................................. 14
1.2.2 Modèle M/G/∞............................................................................................................................ 18
1.3 Modèles de trafics pour les applications multimédias [2][5][7]............................................ 18
1.3.1 Applications audio...................................................................................................................... 19
1.3.2 Applications vidéo ...................................................................................................................... 20
1.3.3 Applications data........................................................................................................................ 21
1.4 Conclusion........................................................................................................................... 21
CHAPITRE 2 : SPECIFICITES DU NGN TELEPHONIE ET NGN MULTIMEDIA ............ 22
2.1 Généralités [8][9][10][12][13].............................................................................................. 22
2.1.1 Architecture ............................................................................................................................... 22
2.1.2 Types de NGN ........................................................................................................................... 24
2.1.3 Caractéristiques du NGN .......................................................................................................... 24
2.2 NGN Téléphonie [8][9][11][12] .......................................................................................... 28
2.2.1 Comparaison entre les services RTC et NGN Téléphonie........................................................... 28
2.2.2 Architecture NGN Téléphonie.................................................................................................... 29
2.3
Migration des réseaux fixes vers NGN [13][14] ............................................................. 30
2.3.1 Scenario 1................................................................................................................................... 31
2.3.2 Scenario 2 ................................................................................................................................ 34
2.3.3 Scenario 3 ................................................................................................................................ 35
i
2.3.4 Scenario 4 ................................................................................................................................ 37
2.4 NGN multimédia [8][13][14]................................................................................................ 40
2.5 Migration des réseaux mobiles vers IMS [14][15][16][16]................................................... 42
2.5.1 UMTS release 99 : l’héritage du GSM/GPRS ............................................................................ 42
2.5.2 UMTS releases R4/R5 : l’évolution vers le tout IP multimédia .................................................. 43
2.5.3 Influence de l’UMTS sur la stabilisation du concept NGN ........................................................ 45
2.6 Conclusion........................................................................................................................... 46
CHAPITRE 3 : ETUDE DU DIMENSIONNEMENT DU NGN .............................................. 47
3.1 Dimensionnement d’un réseau NGN téléphonie ................................................................. 47
3.1.1 Architecture cible du NGN Téléphonie ..................................................................................... 47
3.1.2 Scénario de migration retenu .................................................................................................... 47
3.1.3 Modèle de trafic du réseau d’accès............................................................................................ 48
3.1.4 Méthodologie de dimensionnement ........................................................................................... 49
3.2 Dimensionnement dans le NGN multimédia........................................................................ 53
3.2.1 Architecture cible du réseau UMTS ........................................................................................... 53
3.2.2 Modèle de trafic du réseau d’accès............................................................................................ 54
3.3 Simulation............................................................................................................................ 57
3.3.1 Présentation de « simsNGN v1 » ................................................................................................ 57
3.3.2 Cas de la téléphonie ................................................................................................................... 58
3.3.3 Cas du multimédia ..................................................................................................................... 66
3.4 Conclusion........................................................................................................................... 68
CONCLUSION GENERALE .................................................................................................... 70
REFERENCES ......................................................................................................................... 72
ANNEXES................................................................................................................................. 73
ANNEXE 1 : H323............................................................................................................................. 73
ANNEXE 2 : SIP................................................................................................................................ 74
ANNEXE 3 : SIGNALISATION SS7................................................................................................ 75
ANNEXE 4: ATM.............................................................................................................................. 76
RENSEIGNEMENTS SUR L’AUTEUR................................................................................... 77
Résumé ...................................................................................................................................... 78
ii
LISTE DES ABREVIATIONS
3GPP
3rd Generation Partenership Project
A
Trafic
AS
Application Server
ATM
Asynchronous Transfer Mode
BICC
Bearer Independant Call Control
CAA
Centre d’Acheminement d’Appel
CDMA
Code Division Multiple Access
CL
Commutateur Local
CSCF
Call State Control Function
CT
Centre de Transit
CTI
Centre de Transit International
CTP
Centre de Transit Principal
CTS
Centre de Transit Secondaire
DAPS
Dernier Arrivé Premier Servi
Ddonnée
durée de communication donnée
DSL
Digital Subscriber Line
DSLAM DSL Access Multiplexer
Dvoix
durée de communication conversationnelle
EDGE
Enhanced Data rates for GSM Evolution
GGSN
Gateway GPRS Support Node
GoS
Grade of Service
GPRS
General Packet Radio System
GSM
Global System for Mobile communication
iii
HLR
Home Locator Register
HSS
Home Subscriber Server
HTML
Hyper Text Markup Language
HTTP
Hyper Text Transfer Protocol
IETF
Internet Ingineering Task Force
IMAP
Integrated Multiservice Access Plateforms
IMS
IP Multimedia Subscriber
IN
Intelligent Network
IP
Internet Protocol
Nombre d’appels apprus
LAN
Local Area Network
MAP
Mobile Application Part
MEGACO
MEdia GAteway COntrol
MG
Media Gateway
MGC
Media Gateway Controller
MGCF
Media Gateway Control Function
MGCP
Media Gateway Controller Protocol
MPLS
MultiProtocol Label Switching
MRF
Multimedia Ressource Function
MSAN
MultiService Access Node
MSC
Mobile Switching Center
Taux d’occupation
Na
Nombre d’appels
Ndonnée
Nombre de communications interactives
NGN
New Generation Network
iv
Nvoix
Nombre de communications conversationnelles
OSI
Open System Interconnection
PAPS
Premier Arrivé Premier Servi
QoS
Quality of Service
RNIS
Réseau Numérique à Intégration de Service
RTC
Réseau Téléphonique Commuté
RTCP
Real Time Control Protocol
RTP
Real Time Protocol
SCP
Service Control Point
SG
Signalling Gateway
SGSN
Serving GPRS Support Node
SIGTRAN SIGnalling TRAnsport
SIP
Session Initiation Protocol
SMS
Short Messaging Sesvice
SMTP
Simple Mail Transfer Protocol
SRP
Specialized Resource Point
SS7
Signalisation Sémaphore n˚7
TCP
Transport Control Protocol
TDM
Time Division Multiplex
UE
User Equipment
Ta
temps d’attente
Tq
temps passé dans la queue
Ts
temps de service
Nombre d’appels qui se terminent
UIT
Union Internationale de Télécommunication
v
UMTS
Universal Mobile Telecommunication System
UTRAN
UMTS Terrestrail Radio Access Network
VoIP
WAN
Voix sur IP
World Area Network
vi
LISTE DES FIGURES
Figure 1.01 : Temps moyen entre appels
5
Figure 1.02 : Chaîne de transition d’état
9
Figure 2.01 : Architecture en couches du NGN
22
Figure 2.02 : Architecture physique du NGN
23
Figure 2.03 : Structure physique du NGN
25
Figure 2.04 : Familles de protocoles d’un réseau NGN
28
Figure 2.05 : Exemple d’architecture NGN Téléphonie
29
Figure 2.06 : Protocoles de contrôle (MGCP, MEGACO) et protocoles de signalisation (SIPT, BICC)
30
Figure 2.07 : Hiérarchie des commutateurs du réseau RTC
31
Figure 2.08 : Architecture d’une solution NGN pour le trafic de transit international
33
Figure 2.09 : Architecture d’une solution NGN pour le trafic de transit national
34
Figure 2.10 : Architecture d’une solution NGN de classe 4
35
Figure 2.11 : Architecture d’un réseau NGN de classe 5
37
Figure 2.12 : Architecture overlay VoIP
38
Figure 2.13: Les différentes phases de la stratégie de migration overlay
40
Figure 2.14 : Exemple d’architecture NGN Multimédia
41
Figure 2.15 : Architecture domaine circuit UMTS release R4
44
Figure 2.16 : Architecture de référence Release 5
45
Figure 3.01 : Mise en place de scénario de migration retenu
48
Figure 3.02 : Organigramme de calcul du trafic RTC/RNIS
49
Figure 3.03 : Organigramme de calcul du trafic GSM/GPRS
49
Figure 3.04 : Organigramme de dimensionnement des entités
50
Figure 3.04 : Architecture fonctionnelle du réseau cœur UMTS
54
vii
Figure 3.05 : Fenêtre d’accueil «simsNGN v1 »
58
Figure 3.06 : Fenêtre de saisie dans le cas de la téléphonie
59
Figure 3.07 : Exemple de trafic NGN téléphonie
60
Figure 3.08 : Exemple de répartition du trafic RTC/RNIS
61
Figure 3.09 : Exemple de dimensionnement de MGs et Softswitchs
61
Figure 3.10 : Exemple de courbe pour le cas 2
Figure 3.11 : Nmg et Nsoft en fonction du nombre d’appels conversationnels
62
63
Figure 3.12 : Nmg et Nsoft en fonction de dvoix
64
Figure 3.13 : Influence du taux de données envoyées par heure
65
Figure 3.14 : Fenêtre de saisie
66
Figure 3.15 : Exemple du résultat de trafic EDGE/UMTS
67
Figure 3.16 : M-MGW=f(dstream)
68
viii
LISTE DES TABLEAUX
Tableau 1.01 : Facteurs de Kendall
15
Tableau 1.02 : Notations utilisées
15
Tableau 1.03: Méthodes de services
16
Tableau 3.01 : Signification des onglets
59
Tableau 3.02 : Différentes courbes offertes
62
Tableau 3.03 : Valeurs de Nmg et Nsoft en fonction de Nvoix
63
Tableau 3.04 : Valeurs de Nmg et Nsoft en fonction de dvoix
64
Tableau 3.05 : Tableau des valeurs obtenues pour voir l’influence de
Tableau 3.06 : Signification des onglets
données
65
67
ix
INTRODUCTION
Depuis 1976, les réseaux de Télécommunications n’ont jamais cessé d’évoluer. Les services
offerts aux utilisateurs ont été diversifiés. Ainsi, en plus des services voix/données offerts par les
réseaux téléphoniques traditionnels à commutation de circuits (RTC/RNIS), les réseaux à
commutation par paquets proposent des applications multimédias. Néanmoins, ce type de
commutation a des exigences à respecter pour obtenir une qualité de service (QoS) adéquate
surtout pour les applications multimédias. En particulier, les applications temps réel de type audio
et vidéo ont des besoins stricts en terme de délai et de gigue.
Ainsi, les opérateurs en Télécommunications sont obligés de se fixer une qualité des services
proposés aux utilisateurs avant de les déployer sur leurs réseaux. Ceci nécessite une étude associée
à des lois de probabilité diverses. La fiabilité des résultats des mesures en grandeur réelle repose
essentiellement sur l’adéquation des modèles utilisés pour les applications ainsi que pour les
équipements réseaux.
A la fin des années 90, les acteurs des télécommunications ont introduit les concepts
fondamentaux des réseaux de nouvelle génération NGN (New Generation Network). La
recommandation UIT Y.2001 (Union Internationale de Télécommunication Year.2001) a défini le
NGN comme un réseau en mode paquet, capable d’assurer des services de télécommunication et
d’utiliser de multiples technologies de transport à large bande, à QoS imposée et dans lequel les
fonctions liées aux services sont indépendantes des technologies sous-jacentes liées au transport.
Notre thème de mémoire est axé sur le dimensionnement du NGN. Il s’intitule « Etude de
dimensionnement du réseau de nouvelle génération ».
Pour ce faire, ce rapport de mémoire est décomposé en trois chapitres. Le premier est consacré aux
notions de base du télétrafic et file d’attente. Les spécificités du NGN téléphonie et multimédia
sont traités dans le second. Et l’étude de dimensionnement du NGN suivie de la simulation sont
explicités dans le troisième.
1
CHAPITRE 1 : NOTIONS DE BASE SUR LE TRAFIC
Les Télécommunications font usage de théories et de méthodes issues du Calcul des Probabilités.
C’est le cas, lorsqu’on parle de trafic, c’est-à-dire la densité d’information sur un canal de
transmission. Cette information peut être de différents types tels la voix, les données et le
multimédia. Ce chapitre en donne les notions de base.
1.1 Télétrafic [1][2][3]
L’application du trafic dans le domaine des Télécommunications aboutit à la notion du télétrafic.
Ce terme couvre tous les types de trafic de communication. L'objet de la théorie du télétrafic peut
être défini comme suit: "rendre le trafic mesurable en unités bien définies par l'intermédiaire de
modèles mathématiques, et établir la relation entre la qualité de service et la capacité du système,
de telle sorte que la théorie devienne un outil de planification des investissements".
L'ingénierie du télétrafic doit donc permettre de mettre au point des systèmes aussi rentables que
possibles et présentant une qualité de service prédéfinie, lorsque l'on dispose de prévisions de la
demande future de trafic et lorsque l'on connaît la capacité des éléments du système. Par ailleurs,
la théorie du télétrafic doit permettre de définir des méthodes avec lesquelles il soit possible de
vérifier que la qualité de service effective répond au cahier des charges et d'élaborer des mesures
d'urgence pour les situations de surcharge du système ou de panne technique. Il faut donc pouvoir
prévoir la demande (par exemple, à partir de mesures du trafic), calculer la capacité des systèmes
et définir quantitativement la qualité du service.
Dans l'application de la théorie, il faut ensuite résoudre un certain nombre de problèmes
décisionnels concernant les mesures à prendre à court terme et à long terme. Les décisions à court
terme portent par exemple sur le calcul du nombre de circuits d'un faisceau, le nombre
d'opérateurs employés dans les centraux de commutation et la répartition des priorités dans le
système informatique.
Les décisions à long terme concernent par exemple le développement et l'extension des réseaux de
données et des réseaux de télécommunication, l'achat des câbles, systèmes de transmission,...
L'application de la théorie à la conception des nouveaux systèmes permet de comparer différentes
solutions et donc d'éliminer très rapidement les mauvaises solutions sans avoir à réaliser des
prototypes.
2
Lorsque l'on planifie un système de télécommunication, on cherche à dimensionner les
installations de manière à être en mesure de s'adapter à toute variation du trafic sans subir de
désagréments majeurs et en contenant, autant que possible, le coût des installations. Les
équipements doivent être utilisés dans les meilleures conditions de rentabilité économique.
L'ingénierie du télétrafic porte donc sur l'optimisation de la structure du réseau et l'adaptation, en
volume, des équipements, le tout en fonction de l'intensité du trafic.
L'explication du concept de trafic repose sur les notions de trafic acheminé, de trafic offert et de
trafic perdu. Pour chaque usager, le taux d'occupation
h[ Erlang ] =
de sa ligne téléphonique s’écrit
N a ´ Da
3600
(1.01)
où Na représente le nombre d'appels passés ou reçus par jour et Da la durée moyenne d'un appel en
secondes. Ce taux
représente le trafic de l'usager.
Ainsi, pour dimensionner son réseau, l'opérateur doit évaluer le nombre de ressources à mettre en
œuvre pour qu'avec une probabilité proche de 1, un usager qui décroche son téléphone puisse
disposer d'un circuit. Pour ce faire, les formules de probabilité de blocage interviennent, formules
qui demandent une modélisation statistique des instants de début et de fin d'appels ainsi que des
durées de ces appels.
1.1.1 Modélisation des instants d'arrivée d'appel
On considère que les appels arrivent de manière aléatoire. Le temps d’observation t est divisé en n
sous intervalles de durée t/n. La valeur de n doit être suffisamment grande pour que les conditions
suivantes soient respectées :
- Une seule arrivée d'appel peut survenir dans un intervalle t/n.
- Les instants d'arrivée d'appels sont indépendants les uns des autres.
- La probabilité qu'un appel arrive dans un sous intervalle est proportionnelle à la durée du sous
intervalle.
En appelant
ce coefficient de proportionnalité, la probabilité d’arrivée p1(1) d’un appel dans t/n
peut s’écrire :
p1 (1) =
l
t
n
(1.02)
3
D’après l’hypothèse, la probabilité d'avoir plusieurs appels dans un sous intervalle est nulle et l’on
a:
+¥
p2 (1) + p3 (1) + ... + pn (1) + ... = å pk (1) = 0
(1.03)
k =2
La probabilité de n'avoir aucun appel pendant ce t/n s'écrit donc :
p0 (1) = 1- p1 (1)
(1.04)
La probabilité d'avoir k arrivées d'appels durant n intervalles de temps s'obtient alors en
considérant le nombre de possibilités de choisir k intervalles parmi n. Pour chacune de ces
solutions on aura k intervalles avec une arrivée d'appel et (n – k) intervalles avec aucune arrivée
d'appel. La probabilité d'un de ces cas sera donc égale à p1(1)k.p0(1)n-k. La probabilité globale
s'obtient en sommant les probabilités de tous les cas, d’où :
pk ( n) = Cnk p1 (1) k p0 (1) n-k
(1.05)
En remplaçant les probabilités par leurs valeurs :
pk ( n) = Cnk (
lt k
lt
) (1- ) n-k
n
n
(1.06)
La limite de la probabilité pk (n) lorsque n tend vers l'infini va être égale à la probabilité d'avoir k
arrivées d'appel durant un intervalle de temps t. On note pk cette probabilité :
pk = lim pk ( n)
(1.07)
n®¥
pk =
(lt )k -lt
e
k!
(1.08)
Cette formule représente la probabilité d'observer k arrivées d'appels dans un intervalle de durée t.
Il s'agit d'une distribution de Poisson. Le paramètre
est le taux moyen d'arrivée d'appels.
Typiquement, il s'agit d'un nombre moyen d'appels par seconde. Ce paramètre représente bien le
nombre moyen d'appels durant une durée t. En effet, pour obtenir le nombre moyen, ayant la
distribution de probabilité, il faut calculer l'espérance statistique E [k].
+¥
E [ k ] = å k . pk
(1.09)
k =0
4
En reprenant alors l'expression de p k, il vient :
E [ k ] = lt
(1.10)
La variance s'exprime de la manière suivante :
Var[ k ] = lt
(1.11)
1.1.1.1 Temps moyen entre appels
Soit
la variable aléatoire représentant le temps séparant deux arrivées d’appels (figure 1.01).
Figure 1.01 : Temps moyen entre appels
On introduit la probabilité A(t) qui est la probabilité pour que le temps
soit inférieur ou égal à
une valeur t :
A(t ) = Pr(t £ t )
(1.12)
Or Prob(τ>t) représente la probabilité qu’il n’y ait aucune arrivée d’appels durant un temps t.
A(t ) = 1- e-lt
(1.13)
En introduisant la densité de probabilité a(t) de la variable aléatoire t, on obtient ainsi :
a(t ) = le-lt
(1.14)
5
L'expression de la densité de probabilité permet de calculer la durée moyenne E[τ] entre deux
arrivées d'appels :
E [t ] = ò
+¥
(1.15)
t.a(t )dt
0
En intégrant par partie, il vient :
E [t ] =
1
l
(1.16)
Ainsi, pour un taux d'arrivée de appels par seconde, le temps moyen entre appels est égal à 1/ .
1.1.1.2 Absence de mémoire du processus d’arrivée d’appels
On peut remarquer que, pour une loi exponentielle négative, le nombre d'appels présents jusqu'à
un temps t0 n'a pas d'influence sur le nombre d'appels qui vont arriver après t0.
Supposons qu'aucun appel ne soit arrivé jusqu'à un temps t 0 et calculons la probabilité qu'un appel
arrive durant une durée t après le temps t0. On doit donc calculer la probabilité d'avoir une durée
entre deux appels inférieure à t+t0 tout en étant supérieure à
t0. Cette probabilité s'écrit :
prob(τ≤t+t0/τ>t0). En utilisant la formule de Bayes sur les probabilités conditionnelles, il vient :
Pr(t £ t0 / t > t0 ) =
Pr(t0 < t £ t + t0 )
Pr(t > t0 )
(1.17)
En reprenant les expressions des différentes probabilités, on obtient finalement :
Pr(t £ t0 / t > t0 ) = 1- e-lt
(1.18)
On voit donc que la probabilité d'apparition d'un appel durant un temps t après une durée t 0
pendant laquelle aucun appel n'est arrivé est la même que la probabilité d'apparition d'un appel
pendant une durée t, indépendamment de ce qui a pu arriver avant. Par conséquent, la densité
exponentielle négative est sans mémoire.
6
1.1.2 Modélisation des durées d’appels
Pour étudier les lois de probabilité qui modélisent les durées des appels, on considère donc un
intervalle de temps de durée t que l'on décompose en n sous intervalles de durée t/n. On choisit n
suffisamment grand de telle sorte que les hypothèses suivantes restent justifiées :
- La probabilité qu'un appel se termine durant un sous intervalle est proportionnelle à la durée du
sous intervalle. On notera µt/n cette probabilité, expression dans laquelle µ représente le
coefficient de proportionnalité.
- La probabilité qu'un appel se termine durant un sous intervalle est indépendante du sous
intervalle considéré.
En introduisant la variable aléatoire
représentant la durée d'un appel, la probabilité H(t) pour que
la durée d'un appel soit inférieure ou égale à t est :
H (t ) = Pr(q £ t )
(1.19)
La probabilité qu’un appel ayant débuté à l’instant 0 ne se termine pas avant t s’écrit alors :
Pr(q > t ) = 1- H (t )
(1.20)
Cette probabilité est égale à la probabilité que l’appel ne se termine dans aucun des n sous
intervalles de durée t/n.
t
1- H (t ) = (1- m )n
n
(1.21)
Pour n tendant vers l’infini, et avec une approximation, on obtient l’expression de la probabilité
pour qu’un appel ait une durée inférieure ou égale à t :
H (t ) = 1- e-mt
(1.22)
La densité de probabilité associée, notée h(t) est :
h( t ) =
¶H (t )
¶t
(1.23)
7
La durée moyenne E[ ] d’appel s’obtient en calculant :
E[q ] = ò
+¥
(1.24)
t.h(t ).dt
0
En intégrant par partie, on obtient :
E[q ] =
1
m
(1.25)
En conclusion, on a µ appels qui cessent par seconde et on a une durée moyenne d'appel égale à
1/µ.
Les probabilités d'apparition d'appels et de fin d'appels qui ont été développées dans les deux
paragraphes précédents permettent de modéliser le processus complet d'apparition et de fin
d'appels.
1.1.3 Modélisation des processus d’apparition et de fin d’appels
A chaque instant, un certain nombre d'appels vont apparaître et d'autres vont se terminer. On peut
donc modéliser l'état où l'on se trouve à un instant donné comme une chaîne d'états. Chaque état
représente le nombre de communications en cours. Si, à un instant donné, il y a k communications,
les deux états adjacents sont les états k-1 et k+1. La probabilité de passer d’un état i à un état j
pendant un temps dt sera donc notée pij(dt).
Les probabilités de transition d'état suivantes peuvent être introduites :
Etant dans l'état k, la probabilité pk,k+1(dt) pour passer à l'état k+1durant un intervalle de temps dt
s'écrit
kdt.
Etant dans l'état k, la probabilité pk,k-1(dt) pour passer à l'état k-1durant un intervalle de temps dt
s'écrit µkdt.
Etant dans l'état k+1, la probabilité pk+1,k(dt) pour passer à l'état k durant un intervalle de temps dt
s'écrit µk+1dt
Etant dans l'état k-1, la probabilité pk-1,k(dt)pour passer à l'état k durant un intervalle de temps dt
s'écrit
k-1dt.
8
La figure 1.02 illustre cette chaine de transition d’état.
Figure 1.02 : Chaîne de transition d’état
Les grandeurs
k
et µk sont des taux d'apparition et de fin d'appels du même type que ceux utilisés
lors des paragraphes précédents. La seule différence tient au fait que ces taux ont en indice l'état
où se trouve le système.
On peut alors introduire la probabilité d'état, c'est à dire la probabilité d'être dans un état k à un
instant t. Notons pk(t) cette probabilité.
La variation de cette probabilité durant un intervalle de temps dt est alors égale à la probabilité de
rejoindre cet état en "venant" d'un état k-1 ou d'un état k+1 moins la probabilité de "quitter" cet
état pour aller vers un état k-1ou vers un état k+1.
On a donc :
dpk (t ) = lk -1dt. pk -1 (t ) + mk +1dt. pk +1 (t ) - (lk dt + mk dt ) pk (t )
(1.26)
En supposant le système stable, c’est-à-dire en supposant qu’il se stabilise sur des probabilités
d’état fixes lorsque le temps t tend vers l’infini, on peut écrire :
dpk (t )
= 0 lorsque t ® ¥
dt
(1.27)
On peut alors noter pk=pk(t), d’où finalement :
lk-1. pk -1 + mk +1 . pk +1 - (lk + mk ) pk = 0
Cette équation est vérifiée pour tout k ≥0 avec les conditions p-1= 0,
(1.28)
-1=0
et µ0=0.
La stabilité des probabilités signifie qu'il y a une probabilité égale de quitter l'état pk que de le
rejoindre.
9
En écrivant le système d'équations correspondant, on trouve :
µ1p1= 0p0
0p0+
µ2p2= ( 1+µ1)p1
1p1+
µ3p3=( 2+µ2)p2
(1.29)
En résolvant le système, on trouve :
k -1
li
) p0
i =0 mi +1
pk = (Õ
(1.30)
d’où
po =
1
(1.31)
¥ k -1
l
1 + åÕ i
k =1 i =0 mi +1
1.1.4 Probabilité de blocage et formule d’Erlang B
On s’intéresse ici à un système disposant de N canaux de communications. Si les N canaux sont
occupés, les appels qui arrivent sont alors perdus (absence de tonalité ou tonalité d'occupation par
exemple). Comment estimer cette probabilité de blocage en fonction du nombre de canaux
disponibles et du trafic ? Compte tenu de ce qui a été énoncé sur le caractère sans mémoire du
processus d'arrivée d'appels, on peut considérer que la probabilité
kdt
est indépendante de l'état
du système, d'où :
lk dt = l dt , "k £ N -1
(1.32)
Pour la probabilité de fin d’appel :
mk .dt = k .m.dt , "k < N
(1.33)
Cette probabilité de transition traduit juste que si k appels sont en cours, chacun a une probabilité
µdt de se terminer, d'où la somme qui donne kµdt. En toute rigueur, il faudrait soustraire à cette
probabilité les probabilités correspondantes à plusieurs appels qui se terminent dans l'intervalle dt.
10
Cependant,
on
peut
négliger
ces
probabilités
qui
sont
de
la
forme
k
å C (mdt )
i
k
i
i =2
En utilisant ces expressions de
et de µk dans les équations donnant pk et po, il vient :
k
p0 =
1
N
k -1
l
1 + åÕ
k =1 i =0 (i + 1)m
p0 =
1
N
l 1
1 + å ( )k
k!
k =1 m
(1.34)
(1.35)
Si l’on introduit alors la variable :
A=
l
m
(1.36)
qui représente le trafic, il vient :
p0 =
1
N
1+ å
k =1
Ak
k!
(1.37)
d’où
p0 =
1
Ak
å
k =0 k !
(1.38)
N
La probabilité de blocage d’un système disposant de N canaux et ayant un trafic A s’écrit alors
E(A,N). Elle est égale à la probabilité de se trouver dans l’état N et elle s’obtient grâce à
l’équation suivante :
AN
E ( A, N ) = NN ! i
A
å
i =0 i !
Cette formule est très importante en Télécommunications, c’est la formule d’Erlang-B.
11
(1.39)
Pour les grandes valeurs de N, on peut approcher le dénominateur par eA et la formule devient :
E ( A, N ) =
AN - A
e
N!
(1.40)
1.1.5 Probabilité de mise en attente et formule d’Erlang C
Si l’on considère un système pour lequel les appels bloqués peuvent être mis en file d’attente
avant d’être servis, on peut alors définir une probabilité de mise en attente.
Avec ce système on a toujours
lk dt = l dt
(1.41)
Mais, pour la probabilité de fin d’appel :
ìïk mdt , " 0 £ k < N
mk dt = ïí
ïïî N mdt , k ³ N
(1.42)
Pour k> N :
N -1
l k -1 l
pk = (Õ
Õ ) p0
i =0 (i + 1) m i = N N m
(1.43)
AN Ak -N
pk = (
) p0
N ! N k -N
(1.44)
ìï Ak
ïï
p , "0 £ k < N
ï k! o
ï
pk = í k
ïï A
ïï N N -k po , k ³ N
ïî N !
(1.45)
D’où finalement :
En utilisant l’expression de po (1.38) et en décomposant la sommation, il vient :
p0 =
1
A
Ak 1
+
å
k ! 1- A
k =0 k !
N
N -1
k
La probabilité C(N,A) de mise en file d’attente est égale à :
12
(1.46)
¥
C ( N , A) = å pk
(1.47)
k=N
D’où :
¥
C ( N , A) = å
k=N
Ak N -k
N
po
N!
(1.48)
Cette formule est aussi très importante, c’est la formule d’Erlang –C.
1.1.6 Cas d’une population finie et distribution d’Engset
Les calculs précédents ont considéré le cas d’un trafic de type Poisson généré par une population
infinie. Si l’on considère maintenant le cas d’une population finie constituée de M clients, la
probabilité d’apparition d’appels est fonction du nombre d’appels déjà en cours. On se retrouve
alors avec la configuration suivante (on se replace ici dans un cas sans mise en file d’attente, où
les appels sont perdus lorsque tous les canaux sont occupés et avec M>N) :
lk dt = (M - k )ldt , "k £ N -1
(1.49)
La probabilité de fin d’appel reste inchangée, la probabilité pk devient alors :
pk =
CMk Ak
(1.50)
N
åC
i
M
i
A
i =0
Cette formule représente la distribution d’Engset.
1.1.7 Mesures de trafic
Les mesures de trafic ont pour objectif de rassembler des informations quantitatives correspondant
à la charge d'un système, afin de pouvoir le dimensionner. Par mesure de trafic, on entend tout
type d'opération de collecte de données relatives à la charge de trafic du système considéré, lequel
peut être un système physique - ordinateur ou téléphone - ou encore un système fictif. La collecte
de données dans un modèle de simulation informatique correspond à des mesures de trafic. La
facturation des communications téléphoniques correspond également à des mesures de trafic
lorsque l'unité de mesure est un montant monétaire.
Le degré de détail, le type de mesure et les paramètres (caractéristiques de trafic) mesurés doivent,
dans chaque cas, être choisis en fonction de la demande, de telle sorte qu'un minimum d'efforts
techniques et administratifs donne un maximum d'informations et d'avantages. Selon la nature du
13
trafic, une mesure effectuée pendant un intervalle de temps limité correspond à l'enregistrement du
déroulement d'un événement de trafic.
Une mesure est donc un échantillonnage d'une ou de plusieurs variables stochastiques. La
répétition des mesures donne généralement des valeurs différentes, et l'on peut simplement dire
que le paramètre inconnu (paramètre de population, par exemple valeur moyenne du trafic
acheminé) se trouve avec une certaine probabilité dans un certain intervalle, dénommé intervalle
de confiance. La totalité de l'information correspond à la fonction de distribution du paramètre.
Dans la pratique, il suffit généralement de connaître la valeur moyenne et la variance, la
distribution elle-même étant relativement peu importante.
1.2 Modélisation du trafic IP [3][4][5][6]
Depuis la révélation par Paxson et Floyd de l’inadéquation du processus de Poisson pour la
modélisation du trafic des réseaux LAN et WAN, plusieurs études ont mis en évidence l’existence
de différents types de corrélations dans le trafic Internet et plus particulièrement des corrélations à
long terme. Toutefois, la diversité des applications déployées sur Internet ainsi que la nature
hétérogène des réseaux d’accès (filaire et sans fil) font évoluer les caractéristiques du trafic
Internet. La modélisation du trafic peut être distinguée en deux catégories d’approches qui sont la
modélisation au niveau flux et la modélisation au niveau paquet. Bien que l’approche flux soit très
bien adaptée à la modélisation de trafic comme un outil de gestion de ressources réseaux globales,
elle ne permet pas d’étudier la congestion du réseau au niveau paquet. Ainsi, la deuxième
approche consiste à modéliser le trafic au niveau paquet soit par un processus de comptage de
paquet, soit par un processus d’agrégats d’octets (ou de paquets).
La modélisation du trafic IP en se base sur la méthode d’agrégats d’octets où la trace IP est divisée
en tranches de temps constantes (slots) et on cherche à modéliser la quantité d’information qui
entre dans les réseaux par slots. Pour cela, on utilise le modèle M/G/∞ comme modèle support et
des distributions mélanges pour modéliser les distributions de taille de paquets et de taille de slots.
1.2.1 Files d’attente
1.2.1.1 File d’attente simple
Dans le paragraphe 1.1, à l'exception de l'analyse de la mise en file d'attente, le trafic considéré est
de nature téléphonique. Si l'on s'intéresse maintenant à un trafic de données, dans un échange
d'informations entre deux applications, on va souvent rencontrer un écart de débit entre les
14
systèmes locaux et les liens d'interconnexion. Les messages ne pourront pas tous être transmis et
vont être mis en file d'attente.
Les files d’attente sont en général décrites au moyen de la notation de Kendall qui est la suivante :
A/B/C/K/m/Z
Six facteurs sont ainsi précisés (Tableau 1.01) :
Lettre
Signification
A
Processus d'entrée
B
Processus de service
C
Nombre de serveurs
K
Capacité maximale
m
Population des usagers
Z
Discipline de service
Tableau 1.01 : Facteurs de Kendall
En outre, pour décrire les processus d'entrée (lettre A), on utilise les notations suivantes
(Tableau1.02):
Notation Signification
GI
Loi générale indépendante
G
Loi générale
Hk
Loi
hyper
exponentielle
d'ordre k
Ek
Loi d'Erlang k
M
Loi exponentielle
D
Loi constante
Tableau 1.02 : Notations utilisées
15
On s'intéressera essentiellement ici à des arrivées de type exponentiel et de paramètre . Il a été vu
que la loi exponentielle était sans mémoire et que le processus d'arrivée pouvait donc être
considéré comme un processus Markovien. C'est cette propriété qui explique l'emploi de la lettre
M pour la loi exponentielle.
Les principales méthodes de service sont les suivantes (Tableau 1.03) :
Méthode
Signification
PAPS
premier arrivé, premier servi (FIFO, first in first out)
DAPS
dernier arrivé premier servi (LCFS, last come fisrt served)
A
aléatoire (FIRO : first in random out)
Tableau 1.03: Méthodes de services
Remarque : Lorsque les trois derniers éléments de la notation de Kendall ne sont pas précisés, il
est sous entendu que Z est PAPS, par défaut (Z=PAPS, m ® ¥ et k ® ¥ )
Si les instants d'arrivée suivent une loi exponentielle de paramètre , il en est de même pour les
instants de départ des données en sortie de la file d'attente. Ces instants forment aussi un processus
Markovien. Enfin dans le cas où l'on suppose enfin qu'il n'y a qu’un seul processeur pour gérer la
file d'attente, cette dernière est dite de type M/M/1.
Dans un système M/M/1, on définit le temps de queue tq comme étant la somme du temps d'attente
ta et du temps de service ts.
tq = ta + ts
(1.51)
On définit alors la charge c du système comme le rapport entre le nombre d'items à traiter divisé
par la capacité de traitement du système en item. Cette capacité de traitement est aussi appelée le
taux de service S. C'est tout simplement l'inverse du temps de service. On a donc :
s=
On rappelle que
1
l
et c =
ts
ts
(1.52)
est le paramètre de la loi des instants d'arrivée et que c'est aussi le taux d'arrivée
de paquets par seconde dans la file d'attente.
16
Si on introduit la capacité de traitement du système D et que L représente la taille moyenne des
paquets, alors :
S=
1 D[bps ]
=
ts
L
(1.53)
En remplaçant dans l'expression de la charge c, on obtient :
c=
lL
D
(1.54)
On peut montrer que le temps d'attente dans la file d'attente à t se déduit du temps de services t et
de la charge c par la formule suivante :
ta =
c
ts
1- c
(1.55)
En considérant le temps passé dans la queue tq, on obtient finalement :
tq = ta + ts =
L
D -l L
(1.56)
On suppose ici que le débit D est supérieur au taux d'arrivée L. Dans le cas contraire, la file
d'attente déborde et le temps dans la queue n'est plus déterminé.
On rencontre assez souvent cette formule sous la forme :
tq =
1
D[bps ]
-l
L[bits]
(1.57)
1.2.1.2 Files d'attente en série
Lorsque deux files d'attente sont en série, si la première file d'attente est du type M/M/1 alors les
instants d'arrivée suivent une loi exponentielle et les instants de sortie aussi. L'entrée de la
deuxième file d'attente est aussi un processus Markovien. On a donc deux files M/M/1. Le temps
de queue global est la somme des temps de chaque file.
17
1.2.1.3 File d'attente à entrées multiples
Si l’on considère une file d'attente connectée à plusieurs sources de trafic alors, à condition d'avoir
des messages de même longueur sur toutes les entrées, on peut calculer le temps dans la queue en
utilisant un paramètre
égal à la somme des
i
des différentes entrées.
l = å li
(1.58)
i
1.2.2 Modèle M/G/∞
Le modèle M/G/∞ représente un processus d’occupation d’une file d’attente avec des clients qui
arrivent selon une loi de Poisson, une loi de service G et un nombre infini de serveurs.
Le processus d’occupation Xn (avec n=0, 1, 2,…) représente le nombre de clients dans le système
au début de l’intervalle temporel [n,n+1[. Le processus du serveur occupé résultant (Xn)n≥0 est
corrélé mais n’est pas stationnaire en général. Si on note
n,i la
durée de service du ième client dans
le système à la date n, on doit choisir les paramètres initiaux comme suit pour que le processus
M/G/∞ démarre dans le régime stationnaire :
X0 qui est le nombre de clients dans le système à la date n=0, est distribué selon une loi de
Poisson.
La variable aléatoire
0,i
est indépendante et identiquement distribuée avec une fonction de
probabilité.
r (k ) =
P(s ³ k )
E (s )
(1.59)
Selon ces conditions initiales, le processus d’occupation (Xn)n≥0 vérifie les propriétés suivantes :
· "n ³0 , la variable aléatoire Xn est distribuée selon une loi de Poisson avec le paramètre
E( ).
· La structure de corrélation associée avec le processus (Xn)n≥0 est entièrement définie par la
fonction de probabilité . En effet la fonction d’autocorrélation est donnée par :
r (k ) =
P(s ³ k )
E (s )
(1.60)
1.3 Modèles de trafics pour les applications multimédias [2][5][7]
La modélisation des traces de trafics ou du trafic agrégé ne prend pas en compte le comportement
de chaque source présente dans la trace. Toutefois, il est plus judicieux parfois de modéliser le
18
trafic par type d’application quand c’est possible. De tels modèles peuvent servir directement dans
la génération de la matrice de trafic surtout que ce type de modèle peut être utilisé dans des études
de caractérisation sur le trafic résultant de la superposition d’applications homogènes. En effet,
pour certains types d’applications, la superposition d’un nombre important de sources de trafics
peut conduire à des modèles de trafic plus simples et plus efficaces. On présente ici les modèles
unitaires et agrégés par type d’applications : audio, vidéo et données.
1.3.1 Applications audio
Les applications audio sont caractérisées par une alternance entre des périodes de paroles et des
périodes de silence. L’information audio est codée et encapsulée dans des paquets à taille fixe qui
sont transmis à intervalles constants. L’efficacité de codage et la prise en compte des périodes de
silence font que le débit d’une application audio peut varier entre 5 kbps et 64 kbps en fonction du
codec utilisé.
1.3.1.1 Modèle
Une application audio peut être modélisée par un processus markovien à deux états ON et OFF
avec un taux d’émission de paquets constant selon le type du codec et une inter-arrivée constante
durant la période ON. Le processus d’arrivée de paquets peut se calculer à partir du modèle
markovien. Soit T l’inter-arrivée constante durant la période ON et soit TON (TOFF respectivement)
la moyenne de la durée de la période ON (OFF respectivement). Deux inter-arrivées sont possibles
dans cette configuration :
· Une inter-arrivée T avec une probabilité
p=
n -1
n
(1.61)
Où n est nombre de paquets générés durant une phase ON+OFF.
· Une inter-arrivée T+TOFF avec une probabilité 1-p.
Ainsi, la fonction de distribution cumulée (CDF) des inter-arrivées de paquets peut s’écrire :
ïìï1,0 £ x < T
x-T
1- F ( x ) = ïí
ïï
TOFF
, x ³T
ïî(1- p)e
19
(1.62)
On s’intéresse à cette même distribution dans le cas de la superposition de N applications
homogènes. La fonction CDF des inter-arrivées de paquets dans ce cas prend la forme :
ì
x
ï
ï
(1- l ) N -1 , 0 £ x < T
ï
ï
N
ï
ï
x-NT
x
1- FN ( ) = ï
í (1- p ) N e TOFF
ï
N
ï
, x ³T
ï
T
N -1
ï
(
ï
+ 1- p)
ï
T
ï
OFF
ï
î
Lorsque N ® ¥ , on a 1- FN (
(1.63)
x
) ® e-l x . Ceci revient à dire que l’on peut statistiquement
N
remplacer la superposition de N applications homogènes par une loi exponentielle équivalente
quand N ® ¥ . Cette propriété est pratiquement vérifiée et valable pour un nombre N limité de
sources. En utilisant cette propriété, nous proposons un modèle agrégé peut remplacer la
superposition de N différents types d’applications audio. Ainsi, pour un nombre ni, i=1…N
d’applications par type de codec i et
ia,i
débit d’inter-arrivée moyen par type de codec, on génère
une loi exponentielle équivalente avec un débit Λia donné par :
Lia =
1
N
N
å
lia ,i
i =1
ni
(1.65)
1.3.1.2 Limitation et performance de l’approximation exponentielle
Bien que le modèle agrégé exponentiel pour la superposition d’application audio soit valide
statistiquement, il faut valider la performance du modèle en environnement réseaux. Pour cela, le
trafic généré par le modèle agrégé ainsi que le trafic superposé sont injectés dans une file d’attente
de type G/D/1/K représentant une interface de routeur à débit constant. La performance du modèle
et du trafic superposé est mesurée en fonction de la charge de la file.
1.3.2 Applications vidéo
Le trafic vidéo est issu de différents codecs et présente des caractéristiques très différentes en
fonction de la séquence vidéo codée. La majorité du trafic vidéo est codée par MPEG qui a
plusieurs versions MPEG1, MPEG2, MPEG4 et MPEG7. Le codage MPEG repose sur la notion
de GoP (Groupe of Pictures), ainsi un groupe d’images utilisant les redondances spatiales et
temporelles qui existent dans les séquences vidéo est généré toutes les demi-secondes.
20
1.3.3 Applications data
Les applications data concernent généralement le transfert de fichiers. Les fichiers peuvent être de
simples pages web, des e-mail, ou de grands fichiers. Le point commun entre toutes ces
applications est que le transfert n’a pas généralement de contraintes type temps réel mais plutôt
des contraintes de fiabilité et du débit nominal assuré. Etant donné que les réseaux IP sont des
réseaux sans connexion avec aucune garantie de réception ni d’ordre de livraison, la fonction de
fiabilité est généralement assurée avec des protocoles applicatifs comme TCP (Transmission
Control Protocol).TCP est un protocole avec contrôle en boucle fermée et par conséquent le profil
de génération de paquets ne peut pas être déterminé à la source parce qu’il dépend de la réponse
du réseau. Cette propriété rend la modélisation des applications data plus sophistiquées car elle
nécessite la reproduction du comportement du protocole TCP en fonction du réseau.
1.4 Conclusion
Ce chapitre a présenté un aperçu des méthodes de modélisation du trafic et des files d'attente. Un
certain nombre de formules ont été introduites. Elles permettent de dimensionner un réseau de
Télécommunications.
En général, pour le télétrafic, les lois utilisées pour la transmission de la voix sont celles de
Poisson et Markov. La loi de Poisson intervient dans la modélisation des arrivées d’appels et celle
de Markov dans la modélisation d’apparition et de fin d’appels, modélisation appelée aussi
processus de naissance et de mort. En outre, les formules d’Erlang servent à calculer la probabilité
de blocage dans le commutateur. Il y a la formule d’Erlang-B pour le système sans file d’attente et
celle d’Erlang-C pour le système avec file d’attente.
Pour la transmission de données sur IP, le système de file d’attente est de la forme M/G/∞. Cette
forme signifie que la loi est markovienne, le processus de service suit la loi générale et le nombre
de serveurs est infini.
Quant aux applications multimédias, la modélisation des traces de trafics ou du trafic agrégé ne
prend pas en compte le comportement de chaque source présente dans la trace.
21
CHAPITRE 2 : SPECIFICITES DU NGN TELEPHONIE ET NGN MULTIMEDIA
Depuis de nombreuses années, l’industrie des télécommunications cherche à orienter sa
technologie de manière à aider les opérateurs à demeurer compétitifs dans un environnement
caractérisé par la concurrence et la déréglementation accrues. Ce chapitre est consacré à la
présentation des réseaux de nouvelle génération.
2.1 Généralités [8][9][10][12][13]
2.1.1 Architecture
Les NGN (New Generation Network) sont définis comme un réseau de transport en mode
paquet
permettant
la convergence des réseaux Voix/données et Fixe/Mobile; ces réseaux
permettront de fournir des services multimédia accessibles depuis différents réseaux d’accès.
Afin de s’adapter aux grandes tendances qui sont la recherche de souplesse d’évolution de
réseau, la distribution de l’intelligence dans le réseau, et l’ouverture à des services tiers, les
NGN sont basés sur une évolution progressive vers le « tout IP » et sont modélisés en couches
indépendantes dialoguant via des interfaces ouvertes et normalisées (figure 2.01).
Figure 2.01 : Architecture en couches du NGN
22
La couche « Accès » permet l’accès de l’utilisateur aux services via des supports de
transmission et de collecte divers : câble, cuivre, fibre optique, boucle locale radio, xDSL,
réseaux mobiles.
La couche « Transport » gère l’acheminement du trafic vers sa destination. En bordure du
réseau de transport, des « Media Gateways » et des « Signalling Gateways» gèrent
respectivement la conversion des flux de données et de signalisation aux interfaces avec les
autres ensembles réseau ou les réseaux tiers interconnectés.
La couche « Contrôle » se compose de serveurs « Softswitch » gérant d’une part, les
mécanismes de contrôle d’appel (pilotage de la couche transport, gestion des adresses), et
d’autre part l’accès aux services (profils d’abonnés, accès aux plates- formes de services à
valeur ajoutée).
La couche « Services » regroupe les plates-formes d’exécution de services et de diffusion de
contenus. Elle communique avec la couche contrôle du cœur de réseau via des interfaces
ouvertes et normalisées, indépendantes de la nature du réseau d’accès utilisé. Les services et
contenus eux-mêmes sont par ailleurs développés avec des langages convergents et unifiés.
La figure 2.02 présente l’architecture physique du NGN.
Figure 2.02 : Architecture physique du NGN
23
2.1.2 Types de NGN
Trois types de réseau NGN existent NGN Class 4, NGN Class 5 et NGN Multimédia.
Les NGN Class 4 et Class 5 sont des architectures de réseau offrant uniquement les services de
téléphonie. Il s’agit donc de NGN téléphonie. Dans le RTC (Réseau Téléphonique Commuté), un
commutateur Class 4 est un Centre de Transit CT. Un commutateur Class 5 est un commutateur
d’accès appelé Centre à Autonomie d’Acheminement CAA. Le NGN Class 4 (respectivement
NGN Class 5) émule donc le réseau téléphonique au niveau transit (respectivement au niveau
accès) en transportant la voix en mode paquet.
Le NGN Multimédia est une architecture offrant les services multimédia (messagerie
vocale/vidéo, conférence audio/vidéo, Ring-back tone voix/vidéo) puisque l'usager a un
terminal IP multimédia. Cette solution est plus intéressante que les précédentes puisqu’elle
permet à l’opérateur d’innover en terme de services par rapport à une solution NGN
téléphonie qui se cantonne à offrir des services de téléphonie.
2.1.3 Caractéristiques du NGN
Les principales caractéristiques des NGN sont l’utilisation d’un unique réseau de transport
en mode paquet (IP, ATM,…) ainsi que la séparation des couches de transport des flux et de
contrôle des communications, qui sont implémentées dans un même équipement pour un
commutateur traditionnel.
Ces grands principes se déclinent techniquement comme suit :
·
Remplacement des commutateurs traditionnels par deux équipements distincts
D’une part, des serveurs de contrôle d’appel dits Softswitch ou Media Gateway Controller
(correspondant schématiquement aux ressources processeur et mémoire des commutateurs
voix traditionnels).
D’autre part, des équipements de médiation et de routage dits Media Gateway (correspondant
schématiquement aux cartes d’interfaces et de signalisation et aux matrices de commutation
des commutateurs voix traditionnels), qui s’appuient sur le réseau de transport mutualisé
NGN.
24
·
Apparition de nouveaux protocoles de contrôle d’appel et de signalisation entre ces
équipements (de serveur à serveur, et de serveur à Media Gateway)
La figure 2.03 présente la structure physique du NGN avec les différentes entités
fonctionnelles, les principaux réseaux d’accès ainsi que les différents protocoles mis en
œuvre.
Figure 2.03 : Structure physique du NGN
2.1.3.1 Entités fonctionnelles du cœur du NGN
2.1.3.1.1 Media Gateway (MG)
La Media Gateway est située au niveau du transport des flux média entre le réseau RTC et les
réseaux en mode paquet, ou entre le cœur du NGN et les réseaux d’accès. Elle a pour rôle :
·
·
Le codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion
du trafic TDM / IP).
La transmission, suivant les instructions du Media Gateway Controller, des flux média
25
reçus de part et d'autre.
2.1.3.1.2 Signalling Gateway (SG)
La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le
NGN et le réseau externe interconnecté selon un format compréhensible par les
équipements chargés de la traiter, mais sans l’interpréter (ce rôle étant dévolu au Media
Gateway Controller). Notamment, elle assure l’adaptation de la signalisation par rapport au
protocole de transport utilisé (exemple : adaptation TDM / IP).
2.1.3.1.3 Serveur d’appel ou Media Gateway Controller (MGC) ou Softswitch
Dans un NGN, c’est le MGC qui possède « l'intelligence ». Il gère :
·
·
L’échange des messages de signalisation transmise de part et
d'autre avec les passerelles de signalisation, et l’interprétation de cette signalisation.
Le traitement des appels : dialogue avec les terminaux H.323, SIP
voire MGCP, communication avec les serveurs d’application pour la fourniture des
·
·
services.
Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du
réseau, etc.
La réservation des ressources dans le MG et le contrôle des connexions internes au
MG (commande des Media Gateways).
2.1.3.2 Familles de protocoles d’un réseau NGN
La convergence des réseaux voix/données ainsi que le fait d’utiliser un réseau en mode paquet
pour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessité
l’adaptation de la couche contrôle. En effet, ces réseaux en mode paquet étaient généralement
utilisés comme réseau de transport mais n’offraient pas de services permettant la gestion des
appels et des communications multimédia. Cette évolution a conduit à l’apparition de
26
nouveaux protocoles, principalement concernant la gestion des flux multimédia, au sein de la
couche Contrôle. La figure 2.04 présente cette famille de protocoles.
2.1.3.2.1 Les protocoles de contrôle d’appel
Les protocoles de contrôle d’appel permettant l’établissement, généralement à l’initiative d’un
utilisateur, d’une communication entre deux terminaux ou entre un terminal et un serveur sont
H.323, norme de
l’UIT (Union Internationale de Télécommunication) et SIP, standard
développé à l’IETF (Internet Engineering Task Force) (voir Annexe 1).
2.1.3.2.2 Protocoles de commande de Media Gateway
Les protocoles de commande de Media Gateway sont issus de la séparation entre les couches
Transport et Contrôle et permettent au Softswitch ou Media Gateway Controller de gérer les
passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de
l’IETF. Le protocole H.248/MEGACO, développé conjointement par l’UIT et l’IETF, est
actuellement le protocole prédominant.
2.1.3.2.3 Protocoles de signalisation entre les serveurs de contrôle
Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway Controller)
permettent la gestion du plan contrôle :
·
·
Au niveau du cœur de réseau avec des protocoles tels que BICC (Bearer
Independant Call Control), SIP-T (Session Initiation Protocol) et H.323.
A
l’interconnexion
généralement
via
avec
les
réseaux
de
signalisation
SS7 (voir Annexe 2),
des passerelles de signalisation ou Signalling Gateways par
l’utilisation de protocole tel que SIGTRAN (SIGnalling TRANsport). De plus,
l’interconnexion de ces réseaux de données avec les réseaux existants de téléphonie
(TDM avec signalisation SS7) a nécessité le développement de protocoles dédiés à
l’interconnexion des réseaux et au transport de la signalisation SS7 sur des réseaux en
mode paquet.
27
Figure 2.04 : Familles de protocoles d’un réseau NGN
2.2 NGN Téléphonie [8][9][11][12]
2.2.1 Comparaison entre les services RTC et NGN Téléphonie
Dans le contexte du RTC, le commutateur réalise deux fonctions essentielles :
• La commutation de la voix (Media),
• Le contrôle de l’appel (établissement / libération d’appel).
Les services à valeur ajoutée sont mis en œuvre par le réseau intelligent à travers les entités SCP
(Service Control Point) / SRP (Specialized Resource Point).
Les services complémentaires sont mis en œuvre directement par le commutateur d’accès (Class 5
Switch).
Dans le NGN, la commutation de la voix est réalisée par la MG entre le RTC et le réseau de
transport du NGN. Dans le réseau de transport, ce sont les commutateurs ATM / Routeurs IP qui
assurent le transport de la voix paquétisée jusqu’au MG de sortie qui commute la parole
reconvertie, sur un circuit de parole sortant.
Le contrôle de l’appel (établissement / libération d’appel) est pris en charge par le MGC. Un MGC
Class 4 émule le point sémaphore d’un Class 4 Switch. Un MGC Class 5 émule le point
sémaphore d’un Class 5 Switch.
28
2.2.2 Architecture NGN Téléphonie
La figure 2.05 montre un exemple d’architecture NGN Téléphonie. Les équipements existants
(commutateur d’accès téléphonique ou BTS/BSC du réseau GSM) sont reliés à une couche de
transport IP ou ATM par le biais de MGs (couche d’adaptation). L’établissement des canaux de
communication IP ou ATM entre les MGs est la responsabilité du MGC appartenant à la couche
contrôle.
Figure 2.05 : Exemple d’architecture NGN Téléphonie
Le MGC est un serveur d’appels qui contient l’intelligence liée au contrôle de l’appel et pour ce
faire, il possède un modèle d’appel complet. Le MGC identifie les usagers, détermine le niveau de
service pour chaque usager et l’acheminement de trafic. Par ailleurs, il fournit toutes les
informations permettant la taxation des appels et la mesure des performances du réseau. Aussi, le
MGC s’interface aux serveurs d’applications. Le MGC a différentes appellations : l’UIT le
nomme Media Gateway Controller (MGC), l’IETF qui normalise les aspects relatifs à l’Internet a
utilisé le terme Call Agent au début mais l’appelle désormais MGC, le Softswitch Consortium
considère le terme Softswitch. Enfin, dans les solutions des fournisseurs tels que Nortel et
Ericsson, le MGC est appelé respectivement Call Server et Telephony Server.
29
Dans l’architecture NGN Téléphonie, le protocole de contrôle tel que MGCP ou MEGACO ne fait
que décrire les interactions entre le MGC et le MG. Si un MGC doit contrôler un MG qui est sous
la responsabilité d’un autre MGC, il est nécessaire que les MGCs s’échangent de la signalisation.
Deux protocoles de signalisation peuvent être utilisés : SIP-T (Session Initiation Protocol for
Telephones) et BICC (Bearer Independent Call Control). Le premier est une proposition de l’IETF
alors que BICC est spécifié par l’UIT. La figure 2.08 montre l’interface de contrôle qui est mise
en œuvre par le protocole MGCP ou MEGACO/H.248, et l’interface de signalisation réalisée par
le protocole SIP-T ou BICC.
Figure 2.06 : Protocoles de contrôle (MGCP, MEGACO) et protocoles de signalisation
(SIP-T, BICC).
Une fois la connexion établie, le MG convertira les signaux audio transportés dans les circuits de
parole (terminaison circuit) en paquets IP qui seront transportés dans le réseau IP (terminaison IP)
ou en cellules ATM dans le cas d’un transport ATM.
2.3
Migration des réseaux fixes vers NGN [13][14]
L’évolution d’un réseau existant vers la nouvelle structure nécessitera une stratégie de
migration progressive visant à réduire au minimum les dépenses d’investissement pendant la
30
phase de transition, tout en tirant parti très tôt des avantages qu’elle présente. Toute démarche
entreprise lors de cette étape de transition devra simplifier l’évolution du réseau vers
l’architecture NGN à commutation de paquets. Pendant plusieurs années encore, les services de
commutation traditionnels vont devoir coexister avec des éléments de réseau mettant en œuvre
de nouvelles technologies.
Dans ce qui suit, un ensemble de solutions est présenté et correspond au besoin de n’importe
quel type d’opérateurs de réseau voulant faire évoluer son réseau téléphonique à
commutation de circuits vers une architecture NGN à commutation de paquets. Le choix de
déploiement à retenir conditionne en grande partie les bénéfices à attendre de la mise en place
d’un réseau NGN du point de vue de l’économie de coût. Quatre grands Scenarios peuvent ainsi
être dégagés. Cependant, ces Scenarios tiennent compte de la hiérarchie des commutateurs du
RTC (figure 2.07).
Figure 2.07 : Hiérarchie des commutateurs du réseau RTC
2.3.1 Scenario 1
Le scenario 1 correspond à la mise en place de solutions NGN en transit
31
2.3.1.1 Définition
Dans ce scenario, l’opérateur utilise des technologies NGN pour son cœur de réseau, mais dès
que l’on s’approche des commutateurs de classe 4, le trafic continue à être supporté par le réseau
traditionnel. Cette démarche est mise en place par un grand nombre d’opérateurs mondiaux,
précisément sur ces fonctions de transit que ce soit au niveau régional, national ou international.
Il s’agit de la première étape de la migration d’un réseau traditionnel vers un NGN. Le
principal bénéfice pour un opérateur est
la réduction de coût sur les communications
internationales et nationales.
2.3.1.2 Impacts sur l’architecture du réseau
Ce type de solution agit sur le trafic entre les commutateurs de transit au niveau national ou
international. Concrètement, il s’agit d’installer des passerelles media (Media Gateway)
assurant l’interface entre le réseau IP de transport des données avec le réseau téléphonique
TDM traditionnel. Les passerelles sont alors administrées à distance par un softswitch dans le
cadre d’une architecture centralisée en utilisant en général les protocoles de signalisation
MGCP/H.248.
Exemple 1 : Migration du trafic téléphonique international sur IP
Pour un opérateur souhaitant déployer une solution VoIP pour son trafic international il suffit
d’implémenter (figure 2.08) :
32
·
Figure 2.08 : Architecture d’une solution NGN pour le trafic de transit international
Un softswitch qui centralisera le contrôle des appels, le routage du trafic et la gestion
des aspects de signalisation. Ce softswitch remplacera le (ou les) commutateur(s) de
·
transit international TDM existant(s).
Des passerelles media dans les PoP (Points de Présence) situés dans les pays où
l’opérateur veut s’interconnecter au réseau national TDM.
Exemple 2 : Migration du trafic de transit au niveau national
Au niveau national, l’approche est similaire sauf que ce sont les commutateurs de classe 3 et de
niveaux hiérarchiques supérieurs qui seront remplacés par un ou plusieurs softswitchs et
passerelles media. Les commutateurs TDM de classe 4 et 5 sont conservés et assurent la
livraison des communications téléphoniques TDM de manière tout à fait classique aux abonnés.
33
Figure 2.09 : Architecture d’une solution NGN pour le trafic de transit national
2.3.2 Scenario 2
Le scenario 2 correspond la mise en place de solutions NGN jusqu’au commutateur de classe 4.
2.3.2.1 Définition
L’opérateur choisit de mettre en place une architecture NGN qui a vocation également à
agréger le trafic local, et conserve son réseau d’accès traditionnel. Ce Scenario constitue une
prolongation naturelle du premier.
2.3.2.2 Impacts sur l’architecture du réseau
Le trafic entre commutateurs d'abonnés TDM traditionnels est en fait détourné sur une
infrastructure VoIP. Pour cela, l’opérateur connecte ses commutateurs d'abonnés à des
gateways VoIP et des softswitchs de classe 4. D’un point de vue architectural (figure 2.10), il
s’agit de la même solution que pour le Scenario précédent à un niveau différent du réseau plus
proche de l’abonné. En effet un commutateur de classe 4 ne diffère d’un commutateur de classe
3 ou de niveau hiérarchique supérieur uniquement que par sa capacité de traitement de
données. Il n’intègre aucune intelligence réseau. Du coup, pour le réseau NGN, la différence se
traduira uniquement par la nature des capacités supportées par les media gateways et softswitchs.
34
Figure 2.10 : Architecture d’une solution NGN de classe 4
Cette étape permet en fait de fusionner les infrastructures longue distance voix et données sur
une même épine dorsale IP. Ultérieurement, l'opérateur peut remplacer ses commutateurs
locaux d'abonnés TDM par des softswitchs de classe 5. Deux opérateurs peuvent interopérer
leur réseau NGN de classe 4 en s’interconnectant au niveau d’un softswitch pour l’échange de
signalisation relative à l’acheminement du trafic. Le trafic transite alors par un lien IP (non
représenté sur la figure 2.10) entre les deux infrastructures du cœur de réseau IP. A court
terme, cette démarche permet également de conserver des class 5 traditionnels qui disposent
de certaines capacités qu’il est difficile de rendre avec des solutions logicielles (prise de ligne au
décrochage par exemple).
2.3.3 Scenario 3
Le scenario 3 correspond à la mise en place de solutions NGN jusqu’au classe 5
2.3.3.1 Définition
Les commutateurs de classe 5 constituent le point de raccordement avec l’abonné pour la
fourniture des services voix basiques. Les opérateurs historiques possèdent plusieurs milliers de
35
ces commutateurs et de part leur position stratégique dans leur réseau, ils ont été peu enclins
jusqu’à présent à les remplacer par une solution NGN. Toutefois, compte tenu de la forte
progression de la pénétration des services hauts débits et du déclin de la demande en services de
téléphonie traditionnelle, les opérateurs considèrent de plus en plus l’opportunité de faire
converger leur infrastructure d’accès vers une plate-forme IP commune.
Dans le cadre d’une migration de classe 5, l’opérateur réalise une migration complète, et tout le
trafic transitant dans le réseau sera supporté par une architecture NGN. Cette approche
permet la fourniture de bout en bout de services VoIP à condition que l’utilisateur final utilise un
équipement IP.
2.3.3.2 Impacts sur l’architecture du réseau
L'opérateur remplace ses commutateurs locaux TDM par des softswitchs de classe 5. A la
différence des solutions de classe 4, les serveurs d’appels de classe 5 peuvent supporter tous les
types de services proposés par les commutateurs traditionnels locaux et servir tous les types
de terminaux raccordés au réseau IP, directement ou par l’intermédiaire de MSAN («
MultiService Access Node »).
Le commutateur de classe 5 commute le trafic localement et le transfère vers le réseau de
transit s’il n’est pas en mesure de se connecter directement au commutateur de classe 5 du
destinataire de l’appel.
Du coup, le passage à un réseau NGN en classe 5 s’avère plus compliquer car faire migrer les
commutateurs locaux revient également à faire évoluer les concentrateurs qui leur sont
rattachés. En outre, au-delà du service vocal basique, un réseau RTC fournit de nombreux
services à valeur ajoutée, comme par exemple :
identification
du
numéro
de
l’appelant,
messagerie vocale, appel en attente, interception d’appel, horloge parlante.
La fourniture de ces services est assurée par les commutateurs TDM de classe 5 auxquels le
réseau IN s’interconnecte. Par conséquent, la suppression d’un commutateur de classe 5
rompt le lien avec le réseau intelligent existant. L’implémentation du softswitch doit prendre ces
éléments en compte et garantir la continuité de services pour l’abonné soit en recréant le lien IN
soit en implémentant les mêmes services sur une nouvelle plate-forme IN. Dans la perspective
stratégique de l’opérateur visant à utiliser une solution NGN comme support de nouveaux
services, la deuxième solution sera privilégiée mais nécessitera des investissements additionnels.
36
Il en va de même au niveau du système de facturation également raccordé au commutateur de
classe 5.
2.3.3.3 Raccordement de l’abonné
Dans le cadre d’une migration NGN de classe 5, le raccordement des abonnés se fait avec un
lien IP. Possédant rarement des infrastructures TDM, les opérateurs alternatifs fournissent des
services VoIP basés sur les technologies d’accès hauts débits et les administrent via le
déploiement de softswitchs assumant les fonctionnalités de commutateurs de classe 4 et 5.
Les opérateurs historiques doivent aussi garantir la continuité de leurs services TDM actuels.
Certains opérateurs ont ainsi choisi de conserver leurs commutateurs TDM et de les équiper de
nouvelles cartes afin de faire migrer graduellement le réseau traditionnel vers une architecture
NGN de classe 5 (figure 2.11) tandis que l’opérateur déploiera directement de nouveaux
softswitchs pour supporter de nouveaux services basés sur des technologies haut débit. On
voit apparaître une nouvelle génération d’équipements d’accès haut débit baptisés IMAP
(Integrated Multiservice Access Platforms) ou MSAN qui savent gérer aussi bien des lignes haut
débit que des accès RNIS ou analogiques. Ces équipements se connectent au réseau IP de
l'opérateur et offrent le service téléphonique sous le contrôle du softswitch de classe 5. Ils
permettent aux opérateurs historiques de continuer à fournir des services traditionnels, et de
continuer à remplir leurs obligations réglementaires, tout en tirant parti des solutions de
softswitch IP.
Figure 2.11 : Architecture d’un réseau NGN de classe 5
2.3.4 Scenario 4
Le scenario 4 correspond à la mise en place de solutions tout IP en overlay.
37
Dans ce cas, l’opérateur déploie une architecture entièrement basée sur IP, qui n’a pas besoin de
se connecter au réseau de commutation existant, ceci en parallèle du réseau traditionnel, qui
continue à vivre sa vie indépendamment. Ce type de solution est particulièrement adapté aux
opérateurs historiques qui sont confrontés à une forte chute des revenus de téléphonie
classique et qui, pour protéger leur base de clientèle, doivent lancer des solutions innovantes
basés sur des technologies alternatives (DSL, FTTH, câble,…).
Ce type d’approche est bien évidemment plus répandu auprès d’opérateurs alternatifs, qui
dans la plupart des cas n’ont pas de réseau traditionnel à administrer.
2.3.4.1 Impacts sur l’architecture du réseau
Le réseau paquet en overlay fournit les services à valeur ajoutée tandis que le réseau TDM
traditionnel continue d’assurer le support des services téléphoniques de base. Les deux
réseaux s’interconnectent via le déploiement de passerelles afin de garantir une terminaison
d’appel sur un téléphone classique alors que l’appelant
utilise
un
téléphone
IP
et
inversement. Les réseaux VoIP et RTC restent clairement séparés, au niveau du transport du
trafic et de la signalisation.
Figure 2.12 : Architecture overlay VoIP
2.3.4.2 D ifférentes phases de la stratégie de migration overlay
La stratégie overlay est intimement liée à la stratégie de déploiement du réseau d’accès haut
débit de l’opérateur. En effet, de la vitesse de déploiement du réseau DSL (Digital Subscriber
38
Line) et du rythme des abonnements hauts débits dépendent la date de migration complète des
abonnés RTC vers le réseau NGN.
Il n’y a pas de migration active des abonnés RTC existants à court terme. Toutefois, à plus
long terme, quand le réseau RTC deviendra trop coûteux à entretenir, la migration pourra être
accélérée afin de procéder à la fermeture complète du réseau RTC. Des initiatives
commerciales pourront être mises en place à cet effet par l’opérateur. Malgré tout, même si les
abonnés de la nouvelle plate-forme vont essentiellement utiliser des services VoIP, il n’en
demeure pas moins que certains d’entre eux voudront conserver un accès à un service RTC et
continuer à utiliser leur téléphone traditionnel. En conséquence, des interfaces RTC devront
être conservées sur les passerelles résidentielles.
Ci-après est présentée la stratégie typique de migration, avec mise en place d’un réseau IP,
envisagée par les grands opérateurs (Figure 2.13) :
Phase 1 : Le DSL tel qu’il est déployé aujourd’hui permet de supporter sur une même ligne des
services vocaux RTC classiques et des services de données en haut débit sur une même paire de
cuivre grâce à l’usage de filtres. La carte de la ligne d’abonné est localisée dans le concentrateur
local.
Phase 2 : Le DSLAM (DSL Access Multiplexer) est remplacé par un MSAN supportant à la
fois les technologies TDM et ATM/IP. Les cartes RTC et DSL sont maintenant localisées dans
le MSAN et la signalisation s’effectue entre le MSAN et le commutateur RTC de classe 5 via les
interfaces V5.1 ou V5.2. Les nouveaux abonnés DSL devraient être raccordés à cette nouvelle
plate-forme pour les services vocaux et données.
Phase 3 : Le MSAN est mis à niveau pour devenir un pur équipement IP, qui assume la
terminaison des appels vocaux RTC et les convertit en VoIP. Un softswitch est désormais
nécessaire puisque le commutateur de classe 5 n’est plus relié directement au MSAN. Une
passerelle media doit aussi être ajoutée au réseau afin d’assurer la connexion entre le réseau
RTC existant et la plate-forme IP pour supporter les appels IP vers RTC. Les abonnés existants
et les nouveaux abonnés migrent automatiquement vers la VoIP, même si le service qu’ils
reçoivent est toujours de type RTC.
Phase 4 : Une fois que la migration a attiré suffisamment d’utilisateurs et que
l’opérateur est prêt, le reste des abonnés RTC peut être transféré sur la nouvelle plate- forme IP
et le réseau RTC peut alors être définitivement abandonné.
39
Figure 2.13: Les différentes phases de la stratégie de migration overlay
2.4 NGN multimédia [8][13][14]
La figure 2.14 montre un exemple d’architecture NGN Multimédia aussi appelé IMS (IP
Multimedia Subsystem). L’IMS introduit une nouvelle entité fonctionnelle dans le réseau, CSCF
(Call State Control Function). Elle joue le rôle de Proxy Server SIP, et ses principales fonctions
sont :
• La localisation des usagers en traduisant l'adresse SIP de destination en une adresse IP ;
• Le routage des messages SIP pour l'établissement, la modification et la libération de sessions
multimédias ;
• Le maintien des informations d'état de la session afin de pouvoir invoquer les services souscrits
par les usagers, afin de contrôler la session pendant sa durée de vie, et pour la facturation de la
session ;
L’architecture IMS peut être structurée en couches. Quatre couches importantes sont identifiées :
Ø La couche Accès peut représenter tout accès haut débit tel que : UTRAN (UMTS
Terrestrial Radio Access Network), CDMA2000 (technologie d’accès large bande utilisée
dans les réseaux mobiles aux Etats-Unis), xDSL, réseau câble, Wireless IP, WiFi, etc.
40
Ø La couche Transport représente un réseau IP ou dérivé. Ce réseau IP pourra intégrer des
mécanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste donc
en des commutateurs / routeurs reliés par un réseau de transmission. Différentes piles
peuvent être considérées pour le réseau IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc.
Ø La couche Contrôle consiste en des contrôleurs de session responsables du routage de la
signalisation entre usagers et de l’invocation des services. Ces nœuds sont des CSCF. IMS
Introduit donc un environnement de contrôle de session sur le domaine paquet.
Ø La couche Application introduit les applications (services à valeur ajoutée) proposées aux
usagers. L’opérateur peut se positionner grâce à sa couche CONTRÔLE en tant
qu’agrégateur de services offerts par l’opérateur lui-même ou par des tiers. La couche
application consiste en des serveurs d’application (AS, Application Server) et serveurs de
média IP (IP MS, IP Media Server). L ’IP Media Server est aussi appelé MRF (Multimedia
Resource Function).
Le domaine IMS doit interfonctionner avec le RTCP/GSM afin de permettre aux utilisateurs IMS
d'établir des appels avec le RTCP/GSM. L'architecture d'interfonctionnement présente un plan de
contrôle (signalisation) et un plan d'usager (transport). Dans le plan usager, des entités passerelles
(IMS-MG, IMS - Media Gateway Function) sont requises afin de convertir des flux RTP en flux
TDM. Ces passerelles ne traitent que le média. Des entités sont responsables de créer, maintenir et
libérer des connexions dans ces passerelles; il s'agit de contrôleurs de passerelles. Par ailleurs, ce
même MGC termine la signalisation ISUP du côté RTC/GSM qu'il convertit en signalisation SIP
qui est délivrée au domaine IMS.
Figure 2.14 : Exemple d’architecture NGN Multimédia
41
2.5 Migration des réseaux mobiles vers IMS [14][15][16][16]
Les réseaux mobiles sont confrontés aux contraintes de flexibilité de gestion, d’ouverture de
services mais aussi de déploiements d’équipements.
L’évolution des réseaux mobiles vers une architecture multiservice a suivi une tendance plus
régulière aussi bien au niveau technologique que sur le plan de la normalisation. En effet,
partant du réseau GSM pour le transport de la voix et qui est basé sur la commutation de
circuits, le besoin de convergence voix/données a donné naissance au GPRS. Ce fut une
évolution majeure du GSM par l’utilisation de la commutation de paquets et l’augmentation
des débits, la génération 2.5, le GPRS, a ouvert la porte aux applications multimédia et
implicitement une transition vers les réseaux de troisième génération : l’UMTS. Ce dernier
est
le
premier
système
qui
inclut
dans
ses
spécifications
une
évolution
vers
l’architecture NGN.
Dans cette partie, nous allons présenter les évolutions majeures au sein du coeur du réseau
UMTS.
2.5.1 UMTS release 99 : l’héritage du GSM/GPRS
L’architecture UMTS décrite dans la release 99 du 3GPP s’appuie sur une nouvelle interface
radio, l’UTRA, et une évolution des cœurs de réseau GSM et GPRS (adaptation des équipements
existants ou nouveaux équipements) pour gérer les flux des domaines circuit et paquet.
Dans l’architecture UMTS R99 ; les interfaces de l’UTRA avec le cœur de réseau sont basées
sur un transport ATM (AAL2 pour la voix, AAL5 pour les données). Le transport dans le
cœur de réseau peut ensuite être effectué (au choix de l’opérateur) soit en ATM pour
l’ensemble des flux, soit en ATM puis TDM pour les flux circuit et en IP pour les flux paquets.
La signalisation à l’interface avec l’UTRA est transportée soit dans des circuits virtuels ATM,
soit avec le protocole de transport de SS7 sur IP SIGTRAN. Les appels multimédia sont
supportés de manière transparente. En effet, les messages de signalisation multimédia sont
transportés de manière transparente dans une connexion circuit ou dans un contexte PDP
(tunnel GTP entre SGSN et GGSN), ce qui évite d’introduire des fonctions multimédias dans
les équipements GSM et GPRS, limitant les impacts aux terminaux et à l’ajout de
serveurs multimédias (gatekeepers). Les protocoles de contrôle d’appel multimédia retenus sont
H.323 pour le domaine paquet et H.324-M pour le domaine circuit, choix plus conforme à
42
la maturité actuelle des protocoles (par rapport à SIP). Cependant, le transport de la
signalisation multimédia étant transparent, SIP pourrait à priori être supporté de la même
manière.
La R99 prépare donc l’évolution vers la solution cible tout IP en introduisant dès le début de
l’UMTS un transport convergent des flux voix et données. Les versions ultérieures de la
norme UMTS intègrent une évolution encore plus nette vers une architecture de type NGN.
La release R4 (ex-R99) est la première étape vers un cœur de réseau tout IP, et la release R5
finalise cette évolution.
2.5.2 UMTS releases R4/R5 : l’évolution vers le tout IP multimédia
Alors que la release 99 UMTS a principalement pour vocation de gérer une transition douce
avec le GSM/GPRS, la release 4 (anciennement dénommée release 2000) de l’UMTS propose
une architecture résolument novatrice afin d’évoluer vers le tout IP multimédia.
Suite aux discussions techniques au sein du 3GPP et afin de prendre en compte la maturité des
produits et solutions nouvelles, les évolutions de l’UMTS prévues dans cette version ont été
échelonnées dans le temps et réparties sur deux versions successives, rebaptisées R4 et R5.
2.5.2.1 UMTS Release R4 : séparation des couches transport et contrôle
Conformément à l’un des concepts de base des NGN, la version R4 de la norme UMTS
prévoit une évolution optionnelle du domaine circuit, sous la forme d’une restructuration
fonctionnelle des MSC pour introduire une séparation des couches transport (Media Gateway) et
contrôle d’appel (MSC server).
Le MSC server a les mêmes caractéristiques qu’un MGC, avec en complément des fonctions
spécifiques mobiles. Il est ainsi en mesure de dialoguer avec les autres MSC server en
utilisant le protocole BICC ou SIP-T selon que le protocole de transport utilisé est ATM ou
IP, mais conserve notamment des liens de signalisation utilisant le protocole MAP (Mobile
Application Part) avec les HLR.
La signalisation de commande entre MSC server et MG utilise le protocole H.248 avec des
extensions spécifiées par le 3GPP. Cette signalisation peut être transportée en utilisant le
protocole MTP3b si le transport s’appuie sur une couche ATM, ou SIGTRAN (SCTP) si le
transport s’appuie sur IP.
43
Figure 2.15 : Architecture domaine circuit UMTS release R4
2.5.2.2 UMTS Release R5 : ajout du domaine IP multimédia
La release R5 introduit un nouveau domaine, l’IP Multimédia (IM) Subsystem, s’appuyant sur les
services du domaine paquet pour fournir des services de communications convergents (voix
sur IP, données, multimédia…) en IP natif. Ainsi, les communications multimédia ne sont
plus supportées de manière transparente mais deviennent le mode de communication cible de
l’UMTS. Ce n’est que pour des raisons de compatibilité avec les réseaux GSM/GPRS et UMTS
R99 et avec les terminaux non IP multimédia que le domaine circuit (MSC servers et MG
associées) est maintenu.
Le cœur de réseau UMTS IP multimédia utilise le protocole SIP pour gérer les sessions IP
multimédia, et le protocole IP pour le transport du trafic et de la signalisation associés. Il
supporte l’interfonctionnement avec les réseaux voix et données IP fixes et mobiles existants, y
compris Internet.
Le choix du protocole de contrôle d’appel pour les appels VoIP et multimédia a fait l’objet de
longues discussions, mais SIP a fini par s’imposer au 3GPP grâce à son caractère IP natif et
son apparente simplicité comparée à H.323. Le protocole SIP de l’IETF doit cependant être
enrichi pour prendre en compte certaines évolutions spécifiées par le 3GPP pour un usage
dans le cœur de réseau UMTS, notamment concernant les spécificités liées à la gestion de la
mobilité.
44
Figure 2.16 : Architecture de référence Release 5
Pour assurer le contrôle d’appel et la gestion de la signalisation dans ce nouveau domaine, de
nouvelles entités sont ajoutées, ou des équipements existants sont modifiés.
2.5.3 Influence de l’UMTS sur la stabilisation du concept NGN
L’UMTS aura un rôle potentiel fort sur l’émergence et la stabilisation du concept NGN.
L’UMTS est le premier système global qui intègre dans ses spécifications futures (releases
R4/R5) des options d’évolution vers une architecture réellement NGN.
Les protocoles choisis à terme par le 3GPP sont :
SIP pour le contrôle d’appel, MEGACO/H.248
pour le contrôle des MG et SIGTRAN pour le transport de la signalisation SS7 sur IP.
Pour la signalisation entre MGCs, le choix reste ouvert, mais le protocole BICC est cité
nommément et semble être mis en avant.
Si l’UMTS rencontre un développement et un succès important, et si les réseaux UMTS
migrent rapidement vers une architecture conforme aux spécifications des versions R4/R5, les
45
choix technologiques effectués par le 3GPP ne manqueront pas d’influer sur le choix global
des protocoles dans un réseau NGN, tous domaines confondus, fixe et mobile. Cela semble
particulièrement vrai pour les protocoles SIP et IPv6.
2.6 Conclusion
La connaissance des principes du NGN, les types de NGN existants ainsi que les différents
services réellement pertinents dans ce cadre, sont des étapes nécessaires pour pouvoir comprendre
les stratégies d'évolution des réseaux actuels fixes ou mobiles RTC/RNIS, GSM/GPRS/UMTS
vers une architecture multiservice. Il y a deux types de NGN : le NGN téléphonie et le NGN
multimédia. Le NGN téléphonie est spécifié dans la communication conversationnelle et
interactive. Les équipements pertinents dans ce type de service sont la MG qui est utilisée pour
assurer l’adaptation entre le trafic en mode TDM et le trafic IP, et le softswitch qui est un serveur
d’appel pour gérer la MG et SG. Pour le NGN multimédia, on peut envoyer en plus de la vidéo
(streaming).
Une des exigences du NGN est la transmission en temps réel étant donné que le transfert de
l’information se fait par paquets. C’est la raison pour laquelle on introduit les protocoles tels que
RTP (Real Time Protocol)/RTCP(Real Time Control Protocol).
Dans ce chapitre, plusieurs scenarios sont évoqués, ce sont des solutions adaptables à tout
opérateur fixe ou mobile désirant migrer vers le NGN. Mais, ceci ne peut se faire qu’à partir d’une
étude de dimensionnement du réseau en question avec une estimation du trafic éventuel.
46
CHAPITRE 3 : ETUDE DU DIMENSIONNEMENT DU NGN
Dans ce chapitre, les dimensionnements du réseau NGN téléphonie et NGN multimédia sont
traités. La simulation terminera ce chapitre.
3.1 Dimensionnement d’un réseau NGN téléphonie
L’étape de dimensionnement des équipements et interfaces d’un réseau de communication
permet de déterminer le nombre des équipements, logiciels et autres moyens (capacités de
transmission…) à acquérir et à déployer pour la fourniture des services de télécommunications.
Pour dimensionner un réseau NGN, on s’intéresse principalement aux paramètres suivants : débit
utile du réseau, charge des différents éléments du réseau, délais de transit des informations dans
le réseau et probabilité de perte d’une partie ou de toute l’information.
Le NGN Téléphonie est une architecture de réseau offrant uniquement des services de
téléphonie à des usagers disposant d’un accès en mode circuit (Commutateur d’accès
téléphonique, accès mobile GSM, PABX…).
3.1.1 Architecture cible du NGN Téléphonie
Dans notre processus de dimensionnement, le réseau NGN Téléphonie considéré est un
réseau dorsal IP qui relie différents réseaux d’accès : d’une part RTC/RNIS et d’autre part
GSM/GPRS par le biais de Media Gateways. Un Softswitch situé au niveau de la couche
contrôle gère le contrôle des appels ainsi que l’accès aux services au niveau de la couche
application.
3.1.2 Scénario de migration retenu
Dans le chapitre précédent (chap2, §2.5) les différents scénarios de migration des réseaux
traditionnels de téléphonie fixe vers une architecture NGN sont évoqués.
Dans ce qui suit, nous avons opté pour le premier scénario de migration qui est la mise en
place de solutions NGN au niveau des liens de transit car il permet à l’opérateur d’acheminer les
communications internationales et nationales au niveau des commutateurs de transit et par la suite
une réduction de coût sur ces communications.
La figure 3.01 illustre l’architecture générale d’une solution NGN au niveau des
47
commutateurs de transit national côté RTC/RNIS ainsi qu’au niveau des commutateurs du
service mobile (MSC) côté GSM/GPRS.
Figure 3.01 : Mise en place de scénario de migration retenu
3.1.3 Modèle de trafic du réseau d’accès
La spécification de la charge d’un réseau suppose une connaissance préalable des
caractéristiques des services du point de vue trafic. Un modèle de trafic est un objet
mathématique ou algorithmique qui présente des caractéristiques souvent statistiques,
similaires au trafic réel. Il sert à mieux connaître et décrire le trafic véhiculé et permet de
dimensionner les files d’attentes dans les réseaux.
Le processus de Poisson modélise bien le trafic transactionnel ou encore le trafic d’appel
téléphonique qui arrive sur un commutateur de circuit. Il est donc à la base de la plupart des
lois de télétrafic utilisées en télécommunications et les lois d’Erlang en particulier.
48
3.1.4 Méthodologie de dimensionnement
3.1.4.1 Organigrammes de dimensionnement du réseau NGN Téléphonie
Les organigrammes suivants décrivent les différentes étapes à suivre afin de déterminer les
besoins matériels pour l’écoulement du trafic des réseaux d’accès RTC/RNIS et GSM/GPRS.
Etape 1 : Calcul de trafic du réseau d’accès RTC/RNIS
Nvoix
dvoix
Ndonnée
Trafic des usagers
conversationnels
ddonnée
Trafic des usagers
interactifs
Trafic total
RTC/RNIS
Figure 3.01 : Organigramme de calcul du trafic RTC/RNIS
Etape 2 : Calcul de trafic du réseau d’accès GSM/GPRS
Nvoix
dvoix
Ndonnée
Trafic des usagers
conversationnels
ddonnée
Trafic des usagers
interactifs
Trafic total
GSM/GPRS
Figure 3.02 : Organigramme de calcul du trafic GSM/GPRS
49
Etape 3 : Dimensionnement des entités du réseau NGN Téléphonie
Figure 3.03 : Organigramme de dimensionnement des entités
3.1.4.2 Calcul du trafic généré par les réseaux d’accès
Pour pouvoir calculer le trafic total généré par les réseaux d’accès RTC/RNIS et GSM/GPRS,
nous devons rassembler d’abord les données d’opérateur suivantes :
·
·
·
La durée moyenne [ s ] des communications d i pour tous les types de
trafic (conversationnel, interactif).
Le nombre de tentatives d’appels à l’heure chargée par heure N i par service
(conversationnel, interactif).
Le grade de service (Grade of Service : GoS) souhaité au niveau de l’interface
commutateur de transit-Media Gateway (CT-MG) ou MSC-Media Gateway (MSCMG). En effet, les différents réseaux d’accès connectés au réseau de transport offrent
déjà un certain GoS fixé par l’opérateur en dimensionnant ce réseau; donc il faut éviter un
goulot d’étranglement au niveau des commutateurs de transit (CT) ouMSC
concentrant le plus de trafic car ce sont ces derniers qui seront connectés à la MG.
Première étape : Détermination du trafic engendré par un CT (respectivement un
MSC)
Le comportement global des usagers est exprimé par le nombre de tentatives d’appels à
l’heure chargée par heure et par la durée moyenne des communications en secondes.
50
ai =
Ni ´di
3600
(3.01)
Le trafic de type i (conversationnel, interactif) e s t engendré par un CT du réseau RTC/RNIS.
Le trafic total issu de chaque CT sera l’agrégation de ces trois types de trafic.
L’unité de trafic conversationnel étant l’Erlang alors que pour celui interactif ou streaming est le
kbit. Afin de pouvoir effectuer cette sommation, il faut que nous convertissions ce trafic
conversationnel en kbits. Pour ce faire, nous calculons tout d’abord le nombre de circuits N c
pouvant supporter ce type de trafic à l’aide de la formule de Rigault :
avec
Nc = aconv + k aconv
(3.02)
k RTC / RNIS = - log10 (GoS RTC / RNIS )
(3.03)
Ensuite nous déterminons en premier lieu le nombre de liens E0 nécessaire pour écouler
฀conv, puis le nombre de liens E1 sachant que
1E1=32E0=32*64 kbits=2048 kbits.
Le trafic total en kbits généré par un CT est donné par :
Trafic _ total _ CT = Aconv + aint er
(3.04)
Avec :
Aconv [kbits] = N c ´ 4096
(3.05)
Deuxième étape : Calcul du trafic total généré par le réseau d’accès RTC/RNIS :
Le trafic total généré par le réseau d’accès RTC/RNIS sera la somme de tous les trafics
engendrés par chaque CT :
Trafic _ généré _ réseau _ RTC / RNIS = å Trafic _ total _ CT
CT
51
(3.06)
Troisième étape : Calcul du trafic total généré par le réseau d’accès GSM/GPRS :
De même, nous calculons le volume de trafic généré par le réseau d’accès GSM/GPRS en
suivant la démarche précédente sauf que nous remplaçons cette fois les CT par les MSC :
Trafic _ généré _ réseau _ GSM / GPRS = å Trafic _ total _ MSC
(3.07)
CT
Quatrième étape : Calcul du trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS :
Nous pouvons maintenant déduire le trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS qui sera donné par l’équation (3.8) :
Trafic _ total (kbits ) = Trafic _ généré _ réseau _ GSM / GPRS + Trafic _ généré _ réseau _ GSM / GPRS
(3.08)
Dans notre logique de conception, nous ne pouvons tolérer de pertes avant l’arrivée du trafic
dans le réseau de transport ; ce qui revient à une fourniture de capacité entre le MSC ou le
commutateur du fixe et la MG ; ce qui nous amène donc à dimensionner les liens entre ces
entités. Le nombre de liens en E1 nécessaires pour écouler le trafic prévu est déterminé par :
N CT -MG =
Trafic _ total _ CT
2048
(3.09)
Dans le cas du réseau d’accès GSM/GPRS, le nombre de liens MSC-MG en E1 est calculé
comme suit:
N MSC-MG =
Trafic _ total _ MSC
2048
(3.10)
3.1.4.4 Dimensionnement des Media Gateways
Le dimensionnement des Media Gateways consiste à déterminer le nombre des MGs
nécessaires pour supporter le trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS. Le nombre des MGs nécessaires pour véhiculer ce trafic est donné par :
Nombre _ MG =
Trafic _ total (kbits)
Capacité _ MG
52
(3.11)
Dans cette étape de dimensionnement, nous allons nous limiter au calcul de la charge des
Media Gateways car nous ne connaissons pas leur capacité qui est un paramètre laissé au choix
de l’opérateur.
La charge des MG est calculée comme suit :
Ch arg e _ MG (kbits ) = Trafic _ total (kbits )
(3.12)
3.1.4.5 Dimensionnement des softswitchs
Dimensionner cet équipement, qui représente la couche contrôle, revient à déterminer la
capacité de traitement de son processeur en terme de nombre total de tentatives d’appels à
l’heure chargée (TAHC) qu’il pourra véhiculer :
Ch arg e _ Softswitch(enTAHC ) = åå TAHCi + åå TAHCi
CT
i
MSC
(3.13)
i
3.2 Dimensionnement dans le NGN multimédia
Dans cette partie, nous nous intéressons au dimensionnement d’un réseau IMS qui permet
d’offrir des services multimédia à des usagers disposant d’un accès large bande tel que xDSL,
câble, WiFi/WiMax, EDGE/UMTS, etc… Nous allons prendre le cas de l’architecture du
réseau UMTS selon le concept IMS.
3.2.1 Architecture cible du réseau UMTS
La figure 3.04 représente les différentes entités à dimensionner dans le cas du réseau cœur
UMTS selon le concept IMS qui sont :
GGSN, SGSN, MSC Server et MGCF qui appartenant à la couche contrôle.
Mobile-MGW et IMS-MGW faisant partie de la couche connectivité.
53
Couche service
Couche transport
Figure 3.04 : Architecture fonctionnelle du réseau cœur UMTS
3.2.2 Modèle de trafic du réseau d’accès
L’évaluation du volume de trafic total dans le réseau cœur nécessite une étude préalable des
modèles de trafic de chacune des classes de service. Dans ce paragraphe, nous allons donner un
bref aperçu sur les différentes classes de services ainsi que les modèles de trafic qui
régissent ces classes pour pouvoir retenir un scénario pour chaque classe et calculer par la
suite la charge de trafic dans le réseau cœur. A noter que la modélisation classique des
services par des processus de Poisson n’est pas valide dés qu’il s’agit de la transmission des
données. Cette modélisation a été longtemps adoptée pour le calcul de la charge des réseaux
téléphoniques, et qui reste toujours valable pour les communications de type voix.
3.2.2.1 Les différentes classes de qualité de service
Selon les spécifications de 3GPP, il est possible de partitionner, sur la base de la qualité de
service, l’ensemble des services en quatre classes : classe des services conversationnels,
classe des services à flux continu ou Streaming, classe des services interactifs, classe des
services en mode téléchargement ou background.
54
Le critère de classification le plus prépondérant est la sensibilité au délai de transmission. Les
deux premières classes sont prévues pour les services du type temps réel alors que les deux
autres classes concernent les applications non temps réel, ces dernières se caractérisent par
une tolérance aux délais de transmission. L’autre contrainte à respecter essentiellement pour les
deux dernières classes de service est le seuil du BER (Bit Error Rate).
3.2.2.1.1 Classe des services conversationnels
Les applications de cette classe nécessitent un service bidirectionnel en temps réel impliquant
deux utilisateurs humains ou plus. Les contraintes dépendent donc de la perception humaine : la
limite sur le délai maximum toléré est une limite stricte car toute dégradation sur le délai
induirait une perte de qualité notable dans la perception humaine du signal. Les exemples de ce
type d’applications sont la téléphonie, la vidéophonie, la voix sur IP, les jeux interactifs.
3.2.2.1.2 Classe des services à flux continu ou Streaming
Les applications de cette classe impliquent un utilisateur humain et un serveur de données. Ce
sont des applications temps réel asymétriques où les données sont transférées du réseau vers les
mobiles. Le manque d’interactivité entre l’utilisateur et la source de données autorise des délais
un peu plus importants que dans les cas des applications de type conversationnel, et ce sans
perturber la QoS. Les exemples d’applications de type Streaming sont les nouvelles
applications issues de l’Internet, telles que les applications audio ou vidéo sur demande.
3.2.2.1.3 Classe des services interactifs
Les applications de cette classe impliquent un utilisateur (machine ou humain) dialoguant
avec un serveur de données ou d’applications. Contrairement aux deux classes précédentes, les
performances temps réel ne sont pas nécessaires, il s’agit seulement d’attendre un certain temps
pour répondre aux requêtes. Par contre les informations ne doivent pas être altérées. Les
exemples d’applications de type interactif sont la navigation sur l’Internet, l’accès aux bases
de données ainsi qu’aux serveurs d’applications.
3.2.2.1.4 Classe des services en mode téléchargement ou background
Les applications de cette classe impliquent un utilisateur, le plus souvent un équipement
terminal, réalisent l’envoi et la réception de données en tâche de fond. L’absence
d’interactivité pour ces applications fait que l’utilisateur à l’origine de la requête n’est pas en
attente d’une réponse dans une limite de temps fixée. Ce sont donc les applications les moins
sensibles au délai, mais sont très sensibles aux erreurs sur l’information transférées. Les
55
exemples d’applications sont le mail, le transfert de messages courts (SMS pour Short
Messages Services), le téléchargement de données ou de fichiers.
3.2.2.2 Modèles de trafic
3.2.2.2.1 Modèle de trafic pour le service conversationnel
Un exemple d’un service conversationnel est
la communication téléphonique.
Les
communications téléphoniques constituent le service le plus classique dont le comportement
statistique a été maîtrisé. Le comportement d’un utilisateur exploitant ce service au cours du
temps est modélisé par un processus markovien du type ON-OFF. Les caractéristiques de ce
modèle sont :
L’occurrence des appels téléphoniques est un processus de poisson caractérisé par un taux
moyen d’appel de valeur typique 0.8 appels par heure.
La durée d’un appel suit un processus exponentiel de moyenne typique b telle que 1/b = 150 s.
La durée de l’appel est une alternance de périodes d’activité et de périodes de silence.
Ces périodes suivent chacune une distribution exponentielle. La valeur typique pour le taux
d’activité des sources est 0.5.
3.2.2.2.2 Modèle de trafic pour le service à flux continu
Un exemple typique d’un service à flux continu est le téléchargement d’une séquence vidéo. Le
flux des séquences vidéo correspond à une série de trames de données de même durée à raison
de 25 trames par secondes. Il existe neuf types différents de trames. L’occurrence de ces
différents types de trames est gérée par un processus de Markov à neuf états.
La distribution de la durée de chaque classe de contenu suit une loi Gamma d’ordre 2. Nous
avons retenu pour ce modèle les caractéristiques suivantes :
L’occurrence des sessions 0.17 appels/ heure
La durée d’une session 120 s
Le taux d’activité de la source est de 0.58
3.2.2.2.3 Modèle de trafic pour le service interactif
L’exemple typique de ce service est la consultation des pages Web. Le flux de données, selon ce
modèle, peut être décomposé en plusieurs sessions de consultation du Web. Pendant
chaque session, l’utilisateur consulte un ensemble de sites Web se ramenant à un appel des
56
pages HTMLs correspondantes. Le téléchargement de ces pages HTMLs est matérialisé par la
transmission de plusieurs datagrammes de taille variable. Un temps de lecture est nécessaire
avant d’amorcer la consultation d’une autre page Web. Les caractéristiques statistiques de ce
modèle sont les suivantes :
L’occurrence
appels/heure.
de
sessions
est
un
processus
de
poisson
de
valeur
typique
0.17
Pour chacune de session :
Le nombre d’appel de pages HTML suit une distribution géométrique de moyenne typique
5 appels/session.
Le temps de lecture suit une distribution exponentielle de moyenne a et de valeur typique
1/a = 4 à 12 s.
Le nombre de datagrammes par appel suit une distribution géométrique de moyenne typique
10 datagrammes/appel.
La durée d’inter-arrivée de datagrammes suit une distribution exponentielle dont la moyenne
est en fonction du débit.
La taille des datagrammes suit une distribution de Pareto.
3.2.2.2.4 Modèle de trafic de la classe Background
Les services de cette classe sont insensibles au délai, ils sont considérés de type Best Effort. Ils
sont transmis en dehors des périodes chargées du réseau cœur, c’est-à-dire au cours des
périodes d’inactivités des autres classes de services. D’une autre manière, ses services ne
contribuent pas à la charge du réseau.
3.3 Simulation
A partir des équations (III.1) à (III.13), le calcul du trafic pour chaque type de services (téléphonie
et multimédia) est effectué. A cet effet, le logiciel baptisé « simsNGN v1 », a été développé sous
C++ Builder de Borland.
3.3.1 Présentation de « simsNGN v1 »
Le logiciel simsNGN v1 différencie le service téléphonie du service multimédia. En effet, dans
les réseaux NGN type téléphonie, le logiciel permet de prévoir les nombres de MG (Media
Gateways) et de Softswitchs nécessaires. Dans le type multimédia, le nombre de MGCF (Media
57
Gateway Call Function) ainsi que d’autres paramètres peuvent être traités. La figure 3.1 représente
la page d’accueil.
Figure 3.05 : Fenêtre d’accueil «simsNGN v1 »
Suivant la sélection du bouton radio, les paramètres simulés sont différents ainsi que l’interface de
saisie.
3.3.2 Cas de la téléphonie
3.3.2.1 Fenêtre de saisie
Pour le service téléphonie, les paramètres GoS, Nvoix, dvoix, Ndonnées, ddonnées doivent être renseignés.
GoS représente la probabilité de blocage fixée par l’opérateur (en général 3%), Nvoix et dvoix
nombre et durée moyenne d’appels conversationnels par heure chargée, de même Ndonnées et
ddonnées nombre et durée moyenne du service interactif (figure 3.02). Après simulation, les nombres
de MG et de Softswitchs sont affichés.
58
Figure 3.06 : Fenêtre de saisie dans le cas de la téléphonie
Sous le menu « Outils », plusieurs possibilités sont offertes. Le tableau 3.01 récapitule leur
signification.
Onglet
Signification
Calcul du trafic NGN-Téléphonie
Résultats du trafic voix, données
Répartition du Trafic RTC/RNIS
Pourcentage du trafic suivant le centre
considéré
Dimensionnement des MGs et softswitchs
Nombres de MG et de Softswitchs obtenus
Courbe
Illustration des résultats en faisant varier
certains paramètres
Tableau 3.01 : Signification des onglets
59
3.3.2.2 Exemple de résultats
Les valeurs données dans la fenêtre de saisie vont servir dans tous les affichages suivants.
3.3.2.2.1 Calcul du Trafic NGN-Téléphonie
Le calcul du trafic NGN-Téléphonie permet d’afficher le trafic total conversationnel, le trafic total
interactif et le trafic total en kbits (figure 3.07).
Figure 3.07 : Exemple de trafic NGN téléphonie
3.3.2.2.2 Répartition du trafic RTC/RNIS
Dans le cas où l’on considère que le réseau est composé de différentes catégories de centre de
transit, les pourcentages de trafic par centre est affiché.
60
Figure 3.08 : Exemple de répartition du trafic RTC/RNIS
3.3.2.2.3 Dimensionnement des MGs et Softswitchs
La fenêtre 3.09 affiche les nombres de MGs et Softswitchs correspondants.
Figure 3.09 : Exemple de dimensionnement de MGs et Softswitchs
3.3.2.2.4 Courbes
Différentes courbes peuvent être obtenues (Tableau 3.02).
61
Cas
Ordonnées
Abscisses
Paramètres
1
Nombre de MGs
GoS
2
Nombre de MGs
Nombre d’appels par heure Durée
chargée
3
Nombre de Softswitchs
moyenne
de
communication
Nombre d’appels par heure
chargée
4
Nombre de MGs
Nombre d’appels en mode Durée
interactif
moyenne
communication
mode interactif
5
Nombre de Softswitchs
Nombre d’appels en mode
interactif
Tableau 3.02 : Différentes courbes offertes
La figure 3.10 montre un exemple de courbe pour le cas 2.
Figure 3.10 : Exemple de courbe pour le cas 2
62
de
en
Cette figure montre que le nombre de MGs varie linéairement avec le nombre d’appels et la durée
de communications en secondes. On peut déduire aussi que si Nvoix=0, le nombre de MGs est
toujours proche de 1.
3.3.2.3 Influences des différents paramètres
Dans toute la suite, le GoS est fixé à 3%.
3.3.2.3.1 Influence du nombre d’appels
Le tableau 3.03 présente quelques points obtenus à partir des résultats précédents en fixant
quelques paramètres (dvoix=70,
donnée=1000,
ddonnée=1000).
Nvoix
10
101
102
103
104
2*105
5*105
106
Nmg
1
1
1
1
4
8
19
37
Nsoft
1
1
1
1
3
6
13
26
Tableau 3.03 : Valeurs de Nmg et Nsoft en fonction de Nvoix
La figure 3.11 en illustre la variation des nombres de MGs et de Softswitchs en fonction du
nombre d’appels.
Figure 3.11 : Nmg et Nsoft en fonction du nombre d’appels conversationnels
63
D’après cette figure, dès que le nombre d’appels en heure chargée dépasse 105 appels, il faut
multiplier les nombres de MGs et de Softswitchs. Mais, quand ce nombre est inférieur à 105, les
nombres de MGs et Softswitchs sont très faibles. Du point de vue pratique, pour les petites villes
où le nombre d’abonné est faible, un MGs et un softswitchs suffisent pour bien assurer la
communication.
3.3.2.3.2 Influence de la durée moyenne d’appels
En variant la durée moyenne du trafic conversationnel, et en fixant les autres paramètres (tableau
3.4), on obtient la courbe de la figure 3.8. (
voix=10000,
donnée=1000,
ddonnée=1000).
dvoix
40
60
80
100
120
180
360
480
Nmg
3
4
5
6
7
10
19
26
Nsoft
3
3
3
3
3
3
3
3
Tableau 3.04 : Valeurs de Nmg et Nsoft en fonction de dvoix
Figure 3.12 : Nmg et Nsoft en fonction de dvoix
D’après la figure 3.12, la durée de communication n’influe pas sur le nombre de Softswitchs. Ce
n’est pas le cas pour le nombre de MGs.
64
3.3.2.3.2 Influence du nombre d’appels en mode interactif
En variant le nombre d’appels en mode interactif, et en fixant les autres paramètres (tableau 3.05),
on obtient la courbe de la figure 3.13. (dvoix=70,
voix=100000,
ddonnée=1000).
Ndonnées
10
100
10000
100000 1000000 10000000 2000000 40000000
Nmg
4
4
4
4
4
6
7
9
Nsoft
3
3
3
3
28
253
503
1003
Tableau 3.05 : Tableau des valeurs obtenues pour voir l’influence de
données
Figure 3.13 : Influence du taux de données envoyées par heure
D’après la figure 3.13, on obtient le cas inverse c’est-à-dire que le nombre de MGs ne varie
presque pas contrairement au nombre de Softswitchs.
En conclusion
Dans le cas de la téléphonie, les paramètres qui influencent le nombre de MGs sont le nombre
d’appels conversationnels en heure chargée Nvoix et la durée moyenne de communication dvoix. Par
65
contre, le nombre de Softswitchs dépend du nombre d’appels conversationnels en heure chargée
Nvoix et du nombre d’appels en mode interactif.
3.3.3 Cas du multimédia
La simulation peut aussi concerner le multimédia. Elle donne le trafic EDGE/UMTS, le nombre
M-MGW (Multimedia-MediaGateway), le nombre IMS-MGW (IP Multimedia SubsystemMediaGateway), le nombre MGCF (Media Gateway Call Function). Mais cette section n’est pas
développée dans cette étude. Malgré cela, dans ce paragraphe, nous présentons la fenêtre de saisie
ainsi que quelques résultats.
3.3.3.1 Fenêtre de saisie
La figure 3.14 présente la fenêtre de saisie.
Figure 3.14 : Fenêtre de saisie
66
3.3.3.2 Résultat
Sous le menu « Outils », plusieurs possibilités sont offertes. Le tableau 3.6 récapitule leur
signification.
Onglet
Signification
Calcul du trafic NGN-EDGE/UMTS
Résultats du trafic multimédia
Répartition du Trafic EDGE/UMTS
Pourcentage du trafic suivant le centre
considéré
Dimensionnement des entités
Nombres
de
quelques
équipements
nécessaires
Courbe
Illustration des résultats en faisant varier
certains paramètres
Tableau 3.06 : Signification des onglets
La figure 3.15 présente un exemple de résultat du trafic NGN-EDGE/UMTS.
Figure 3.15 : Exemple du résultat de trafic EDGE/UMTS
67
On peut voir dans cette fenêtre un exemple de résultat qui donne le trafic dans les différents
services (conversationnel, interactif et streaming) ainsi que dans les différents technique d’accès
(EDGE et UMTS).
3.3.3.3 Courbe
La figure 3.16 nous donne un exemple de courbe qui représente la variation M-MGW en fonction
de la durée moyenne streaming. Sur cette figure, on regarde tout simplement une variation de
durée jusqu’à 1000s.
Figure 3.16 : M-MGW=f(dstream)
La figure 3.16 nous montre que le nombre de M-MGW qu’on doit utiliser dans le NGN téléphonie
dépend de la durée moyenne streaming et on a bien constaté que cette variation est linéaire.
3.4 Conclusion
Ce chapitre montre l’étude de dimensionnement du NGN Téléphonie et NGN Multimédia. Pour
ce faire, les différents outils mathématiques et algorithmiques utilisés sont exposés. Après cette
étude, le logiciel de dimensionnement « simsNGN v1 » développé sous C++ Builder est présenté
avec les résultats.
68
Pour le NGN téléphonie, les paramètres entrants sont le nombre et la durée moyenne d’appels
pour chaque service et le GoS. Le logiciel permet alors de calculer le trafic et le nombre des MGs
et Softswitchs nécessaires pour assurer la communication. L’influence de ces paramètres sur ces
équipements est simulée. Ainsi, nous avons vu que les paramètres qui influencent le nombre de
MGs sont le nombre d’appels conversationnels en heure chargée Nvoix et la durée moyenne de
communication dvoix. Par contre, le nombre de Softswitchs dépend du nombre d’appels
conversationnels en heure chargée Nvoix et du nombre d’appels en mode interactif.
69
CONCLUSION GENERALE
En général, pour le télétrafic, les lois utilisées pour la transmission de la voix sont celles de
Poisson et Markov. La loi de Poisson intervient dans la modélisation des arrivées d’appels et celle
de Markov dans la modélisation d’apparition et de fin d’appels, modélisation appelée aussi
processus de naissance et de mort. En outre, les formules d’Erlang servent à calculer la probabilité
de blocage dans le commutateur. Il y a la formule d’Erlang-B pour le système sans file d’attente et
celle d’Erlang-C pour le système avec file d’attente.
Pour la transmission de données sur IP, le système de file d’attente est de la forme M/G/∞. Cette
forme signifie que la loi est markovienne, le processus de service suit la loi générale et le nombre
de serveurs est infini.
Quant aux applications multimédias, la modélisation des traces de trafics ou du trafic agrégé ne
prend pas en compte le comportement de chaque source présente dans la trace.
La connaissance des principes du NGN, les types de NGN existants ainsi que les différents
services réellement pertinents dans ce cadre, sont des étapes nécessaires pour pouvoir comprendre
les stratégies d'évolution des réseaux actuels fixes ou mobiles RTC/RNIS, GSM/GPRS/UMTS
vers une architecture multiservice. Il y a deux types de NGN : le NGN téléphonie et le NGN
multimédia. Le NGN téléphonie est spécifié dans la communication conversationnelle et
interactive. Les équipements pertinents dans ce type de service sont la MG qui est utilisée pour
assurer l’adaptation entre le trafic en mode TDM et le trafic IP, et le softswitch qui est un serveur
d’appel pour gérer la MG et SG. Pour le NGN multimédia, on peut envoyer en plus de la vidéo
(streaming).
Une des exigences du NGN est la transmission en temps réel étant donné que le transfert de
l’information se fait par paquets. C’est la raison pour laquelle on introduit les protocoles tels que
RTP (Real Time Protocol)/RTCP(Real Time Control Protocol).
Plusieurs scenarios sont évoqués, ce sont des solutions adaptables à tout opérateur fixe ou mobile
désirant migrer vers le NGN. Mais, ceci ne peut se faire qu’à partir d’une étude de
dimensionnement du réseau en question avec une estimation du trafic éventuel.
L’étude de dimensionnement du NGN Téléphonie et NGN Multimédia est effectuée. Pour ce
faire, les différents outils mathématiques et algorithmiques utilisés sont exposés. Après cette
étude, le logiciel de dimensionnement « simsNGN v1 » développé sous C++ Builder est présenté
avec les résultats.
70
Pour le NGN téléphonie, les paramètres entrants sont le nombre et la durée moyenne d’appels
pour chaque service et le GoS. Le logiciel permet alors de calculer le trafic et le nombre des MGs
et Softswitchs nécessaires pour assurer la communication. L’influence de ces paramètres sur ces
équipements est simulée. Ainsi, nous avons vu que les paramètres qui influencent le nombre de
MGs sont le nombre d’appels conversationnels en heure chargée Nvoix et la durée moyenne de
communication dvoix. Par contre, le nombre de Softswitchs dépend du nombre d’appels
conversationnels en heure chargée Nvoix et du nombre d’appels en mode interactif.
71
REFERENCES
[1] R. RAJAONARISON, Documents et techniques multimédias, Cours 4ème Année, ISGEI, A.U. :
2008-2009.
[2] B. Baynat: Théorie des files d'attente. Hermes, collection réseaux et télécommunications,
2000.
[3] http://www.caida.org/data/passive/index.xml Aout 2010
[4] E. Thibault. Analyses de traces de trafic réel. Technical report, INRIA, Nov 2002.
[5] : http://www.sciences.ch/htmlfr/mathssociales/mathssgestion01.php
[6] http://owenduffy.net/traffic/erlangc.htm
[7] http://members.iinet.net.au/~clark/models.htm
[9]
G.Pujolle, Cours Réseaux et Telecoms, Edition Eyrolles : Paris 2004
[10]
G.Pujolle, Les Réseaux, Edition Eyrolles : Paris 2003
[11]
D.Cedric, UMTS, 2004
[12]
http://www.effort.com
[13]
http://en.wikipedia.org/wiki/Next_Generation_Networking
[14]
A.Rattiers, La gestion des services sur réseau intelligent, Echo des recherches Num
172 : 1999
[15]
http://www.eivd.ch
[16]
C. Ovum, L'évolution du cœur de réseau des opérateurs fixes, ARCEP, Janvier 2006.
[17]
A. Krendzel, V. Derjavina, S. Lopatin, ‘‘Téléphonie Method for Estimating Parameters
of NGN traffic’’, St.-Petersburg Research Institute of Telecommunications, Russia.
[18]
L. Toutain, Réseaux, Techniques de l’ingénieur, Edition n°6
[19]
L. Toutain, Technologies de l’Internet, Techniques de l’ingénieur, Edition n°4
[20]
C. Delannoy, Programmer en langage C, groupe Eyrolles, 2002
72
ANNEXES
ANNEXE 1 : H323
H323 est la norme la plus utilisée pour faire passer la voix et la vidéo sur IP ou sur d'autres
réseaux ne garantissant pas une QoS optimale pour l'établissement d'une communication
multimédia. Cette norme a été mise en place par l'UIT en 1996, elle est reconnue et adoptée par de
nombreux fabricants tels que Cisco, IBM, Intel, Microsoft, etc. Ce standard concerne le contrôle
des appels, la gestion du multimédia, la gestion de la bande passante, la connectique pour les
conférences point à point ou multipoints, etc.
La norme H.323 a subi plusieurs modifications depuis sa création.
Actuellement la norme H.323 est à sa quatrième version.
Principe du protocole H.323
La norme H.323 définit plusieurs éléments de réseaux : les terminaux, les gatekeepers, les
passerelles (Gateways H.323 vers H.320/H.324/téléphones classiques) et les contrôleurs
multipoints (MCUs - MC, Multipoint Controller, MP - Multipoint Processor). Les terminaux de
type H.323 (figure A1.1) peuvent être intégrés dans des ordinateurs personnels ou implantés dans
des équipements autonomes tels que des vidéophones. La prise en charge de la parole est
obligatoire, tandis que celle des données et de la vidéo est facultative.
Figure A1.1 : Exemple de terminal H.323 (Mircosoft Netmeeting)
73
ANNEXE 2 : SIP
SIP est un protocole développé par le groupe de travail MMUSIC (Multiparty Multimedia Session
Control) de l’IETF (Internet Engineering Task Force). Il s’agit d’un protocole complémentaire aux
protocoles déjà développés par l’IETF comme RTP. Il est aujourd’hui le protocole qui attire le
plus l’attention des développeurs de logiciel VoIP, car il est sensiblement plus simple à exploiter
que H.323. On peut également rencontrer SIP comme protocole pour envoyer des messages
instantanés ou renseigner sur des évènements.
Dans un futur proche, les protocoles SIP et H.323 coexisteront, c’est pourquoi on parle
d’interconnexion SIP/H.323.
Comme avec H.323, les données multimédias transitent par le protocole RTP. La différence réside
dans le contrôle de signalisation.
SIP est décrit comme un protocole de contrôle de la couche application. Il établit, modifie et
termine des conversations multimédias. Il ressemble un peu en syntaxe, à HTTP (HyperText
Terminal Protocol) et à SMTP (Simple Mail Transfer Protocol), car il permet d’établir une session
entre deux interlocuteurs identifiés par des adresses similaires à des adresses email. De plus, les
messages échangés avec SIP sont au format texte et donc plus facile à comprendre et à modifier.
La mobilité personnelle est une des fonctionnalités de SIP. Un utilisateur peut garder le même
numéro malgré qu’il soit connecté à des terminaux d’adresses physiques différentes. Egalement,
comme avec le principe des emails, plusieurs adresses d’identificateurs peuvent référencer un
même terminal. Inversement, une adresse SIP peut référencer plusieurs terminaux différents.
Les éléments composants un réseau SIP sont les suivants :
Ø Agent,
Ø Serveur d’enregistrement,
Ø Serveur de localisation,
Ø Serveur de redirection,
Ø Proxy,
Ø Gateway
74
ANNEXE 3 : SIGNALISATION SS7
Le système de signalisation par canal sémaphore normalisé par le CCITT (Comité Consultatif
International de Télégraphique et Téléphonique) dans la série de recommandations Q700 est
couramment appelé CCITT n°7 ou SS7 (Signalisation Sémaphore 7, Signalling System number 7).
SS7 est un moyen d'échanger des informations entre les éléments du réseau téléphonique. Il est
caractérisée par des paquets de données à débit élevé, et une signalisation hors bande.
Le réseau et le protocole SS7 sont utilisés pour :
· l'établissement d'appels basiques, leur gestion et la libération de la ligne ;
· les services des réseaux mobiles comme les services de communication
personnelle, le roaming, et l'authentification de l'abonné ;
· les numéros gratuits du RTC et des réseaux mobiles ;
· les services complémentaires comme le transfert d'appel, l'identification de
l'appelant, la conférence à trois ;
· les télécommunications internationales fiables et sécurisées.
75
ANNEXE 4: ATM
ATM (Asynchronous Transfer Mode) est un service réseau à très haut débit conçu pour les
besoins de transfert de données, de voix et de la vidéo. L’information y est transportée en cellules.
Chaque cellule a une taille de 53 octets.
L’architecture ATM est illustrée par la figure A4.1:
Figure A4.1: Architecture ATM
Le rôle principal de ce nouveau modèle, dit modèle UIT-T, est de prendre en charge les
applications multimédias, c'est-à-dire la superposition de la voix, des données et de l'image. Le
modèle de référence OSI (Open System Interconnection) n'était bâti que pour les applications de
données et correspondait donc à l'architecture des réseaux d'ordinateurs.
Le modèle UIT-T ne s'intéresse qu'au transport de bout en bout de l'information, et non à son
traitement aux extrémités du réseau. Il est constitué de trois couches : la couche prenant en charge
le transport des cellules sur un support physique, la couche se préoccupant de l'acheminement des
cellules de bout en bout et la couche chargée de l'interface avec les couches supérieures et
regroupant les cellules pour les délivrer à l'utilisateur.
76
RENSEIGNEMENTS SUR L’IMPETRANTE
Nom : ANDRIANARIMALALA
Prénoms : Dina Mialinirina
Tél : +261337383816 / +261340198668
Titre du mémoire : « Etude de dimensionnement du réseau de nouvelles générations NGN »
Nombre de pages : 76
Nombre de tableaux : 9
Nombre de figures : 34
Mots clés : dimensionnement, gateway, interface, multimédia, NGN, réseau, service, softswitch,
téléphonie, trafic.
Directeur de mémoire :
Monsieur RAJAONARISON Tianandrasana Roméo
Tél : +261331429381
E-mail : poutsyrajao@yahoo.fr
77
Résumé
La migration du réseau à commutation de circuits vers le NGN nécessite une connaissance
approfondie de l’interface entre les deux. Dans cette étude, on s’est limité à évaluer le nombre des
équipements principaux de cette interface.
Pour le NGN téléphonie, il faut déterminer le nombre de MG (Media Gateway) et de Softswitchs.
Quant au NGN multimédia, les paramètres pertinents sont l’IMS-MG (IP Multimedia SubscriberMedia Gateway), la M-MG (Mobile-Media Gateway) et le MGCF (Media Gateway Control
Function).
Pour ce faire, le logiciel « simsNGNv1 » sous C++ Builder 6.0 de Borland a été développé. Le
nombre d’appels à heure chargée ainsi que leur durée moyenne constituent les paramètres
d’entrée.
Abstract
The migration of the network with circuit switching towards the NGN requires a thorough
knowledge of the interface between them. In this study, one limited oneself to evaluate the number
of the principal equipment of this interface.
For the NGN telephony, it is necessary to determine the number of MG (Media Gateway) and
Softswitchs. As for the multimedia NGN, the relevant parameters are the IMS-MG(IP Multimedia
Subscriber-Media Gateway), M-MG (Mobile-Media Gateway) and the MGCF (Media Gateway
Control Function).
With this intention, software “simsNGNv1” under C++ Builder 6.0 of Borland were developed.
The number of calls to hour charged and their average duration constitute the parameters of entry.
78