Etude Et Dimensionnement Dâ ™un Reseau NGN

RAPPORT DE PROJET DE FIN DETUDES
Filire
Ingnieurs en Tlcommunications
Option
Rseaux et Services Mobiles

Etude et Dimensionnement dun
Rseau de Nouvelle Gnration (NGN)
Cas dtude : Tunisie Tlcom

Elabor par :
Abdessalem MRIBAH

Encadr par :
M. Rached HAMZA
M. Anouar ALEYA

Projet ralis en collaboration entre
Anne universitaire : 2005/2006
i
Ddicaces

A mes chers parents
pour leur soutien moral et financier durant mes tudes,

mes deux soeurs Nadia et Khadija
et mon frre Mohamed Ali
en leur souhaitant la russite dans leurs tudes et dans leurs vies,

tous mes amis de SupCom
pour les moments agrables que nous avons passs ensemble,
en leur souhaitant le succs dans leur vie aussi bien
professionnelle que familiale,

tous ceux qui mont aid afin de raliser ce travail,

et tous ceux que jaime et qui maiment.

A tous, je ddie ce travail

Abdessalem
ii
Remerciements
Le travail prsent dans ce rapport a t effectu au sein de la socit Tunisie Tlcom dans
le cadre de mon projet de fin dtudes pour lobtention du diplme dingnieur en
Tlcommunications option Rseaux et Services Mobiles lEcole Suprieure Des
Communications De Tunis (SupCom).

A son terme, je tiens exprimer ma profonde gratitude mon encadreur M. Anouar
ALEYA, ingnieur principal Tunisie Tlcom, qui na pargn aucun effort pour le bon
droulement de ce travail. Ses remarques et ses consignes ont t pour moi dun grand apport.

Je pense aussi mon encadreur SupCom M. Rached HAMZA qui ma aussi tant
encourag et donn de trs bons conseils tout au long de ce travail. Je tiens le remercier tout
particulirement.

Mes sincres remerciements iront aussi tous nos enseignants SupCom pour la qualit de
lenseignement quils nous ont prodigus durant nos trois annes dtudes afin de nous donner
une formation efficace, tout le personnel de ladministration de SupCom pour nous assurer
les meilleures conditions de travail.

iii
Table des Matires

Introduction gnrale.............................................................................................................. 1

Chapitre I : Architecture NGN : Du NGN Tlphonie au NGN Multimdia.................... 3
I.1 Introduction........................................................................................................................ 3
I.2 Dfinition ........................................................................................................................... 3
I.3 Pourquoi Le NGN ? ........................................................................................................... 4
I.4 Types de NGN ................................................................................................................... 5
I.5 Avantages du NGN............................................................................................................ 5
I.6 Architecture NGN.............................................................................................................. 6
I.6.1 Les entits fonctionnelles du coeur de rseau NGN.................................................... 7
I.6.1.1 La Media Gateway (MG)....................................................................................... 7
I.6.1.2 La Signalling Gateway (SG) .................................................................................. 7
I.6.1.3 Le serveur dappel ou Media Gateway Controller (MGC) ou Softswitch............. 7
I.6.2 Les familles de protocoles dun rseau NGN.............................................................. 8
I.6.2.1 Les protocoles de contrle dappel ........................................................................ 8
I.6.2.1.1 Le protocole historique : H.323 .................................................................... 8
I.6.2.1.2 Le protocole alternatif : SIP.......................................................................... 8
I.6.2.2 Les protocoles de commande de Media Gateway.................................................. 9
I.6.2.2.1 Le protocole historique : MGCP................................................................... 9
I.6.2.2.2 Le protocole alternatif : MEGACO/H.248 ................................................... 9
I.6.2.3 Les protocoles de signalisation entre les serveurs de contrle............................... 9
I.7 NGN Tlphonie.............................................................................................................. 10
I.7.1 Architecture NGN Tlphonie................................................................................... 10
I.7.2 Services dans le RTC versus Services dans le NGN Tlphonie .............................. 11
I.8 NGN Multimdia ou IMS (IPMultimedia Subsystem) .................................................... 12
I.8.1 Architecture IMS........................................................................................................ 12
I.8.2 Structuration en couche de larchitecture IMS .......................................................... 13
I.8.3 Entits de Rseau IMS............................................................................................... 14
I.8.3.1 Terminal IMS....................................................................................................... 14
I.8.3.2 Home Subscriber Server (HSS) ........................................................................... 14
I.8.3.3 Call State Control Function (CSCF) .................................................................... 14
I.8.3.4 MGCF, IMS-MGW et T-SGW : Interfonctionnement avec le RTC................... 16
I.8.3.4.1 L'IMS-MGW............................................................................................... 16
I.8.3.4.2 Le MGCF.................................................................................................... 17
I.8.3.4.3 Le T-SGW................................................................................................... 17
I.9 Les services offerts par les NGN..................................................................................... 18
I.9.1 La voix sur IP............................................................................................................. 18
I.9.2 La diffusion de contenus multimdia......................................................................... 19
I.9.3 La messagerie unifie................................................................................................. 19
I.9.4 Le stockage de donnes.............................................................................................. 19
I.9.5 La messagerie instantane.......................................................................................... 19
I.9.6 Les services associs la golocalisation.................................................................. 20
I.10 Conclusion ..................................................................................................................... 20
Chapitre II : Stratgies de migration des rseaux actuels vers NGN............................... 21
II.1 Introduction..................................................................................................................... 21
iv
II.2 Migration des rseaux fixes vers NGN........................................................................... 21
II.2.1 Scnario 1 : Mise en place de solutions NGN au niveau de transit ......................... 22
II.2.1.1 Dfinition.......................................................................................................... 22
II.2.1.2 Impacts sur larchitecture du rseau ................................................................. 23
II.2.1.2.1 Exemple 1 : Migration du trafic tlphonique international sur IP ........ 23
II.2.1.2.2 Exemple 2 : Migration du trafic de transit au niveau national ............... 24
II.2.2 Scnario 2 : Mise en place de solutions NGN jusquau commutateur de classe 4.. 24
II.2.2.1 Dfinition........................................................................................................... 24
II.2.2.2 Impacts sur larchitecture du rseau .................................................................. 24
II.2.3 Scnario 3 : Mise en place de solutions NGN jusquau classe 5.............................. 25
II.2.3.1 Dfinition........................................................................................................... 25
II.2.3.3 Raccordement de labonn ................................................................................ 27
II.2.4 Scnario 4 : Mise en place de solutions tout IP en overlay ...................................... 27
II.2.4.2 Les diffrentes phases de la stratgie de migration overlay .............................. 28
II.3 Migration des rseaux mobiles vers lIMS..................................................................... 29
II.3.1 UMTS release 99 : lhritage du GSM/GPRS......................................................... 30
II.3.2 UMTS releases R4/R5 : lvolution vers le tout IP multimdia.............................. 31
II.3.2.1 UMTS Release R4 : sparation des couches transport et contrle ................... 31
II.3.2.2 UMTS Release R5 : ajout du domaine IP multimdia ..................................... 31
II.3.3 Influence de lUMTS sur la stabilisation du concept NGN..................................... 34
II.4 Conclusion...................................................................................................................... 34

Chapitre III : Processus de dimensionnement dun rseau NGN..................................... 35
III.1 Introduction ................................................................................................................... 35
III.2 Dimensionnement dans le NGN Tlphonie................................................................. 35
III.2.1 Architecture cible du NGN Tlphonie................................................................. 35
III.2.2 Scnario de migration retenu................................................................................. 36
III.2.3 Modle de trafic du rseau daccs ....................................................................... 36
III.2.4 Mthodologie de dimensionnement ...................................................................... 37
III.2.4.1 Organigrammes de dimensionnement du rseau NGN Tlphonie .............. 37
III.2.4.2 Calcul du trafic gnr par les rseaux daccs............................................. 38
III.2.4.3 Calcul du nombre de liens CT-MG et MSC-MG.......................................... 40
III.2.4.4 Dimensionnement des Media Gateways ....................................................... 40
III.2.4.5 Dimensionnement des softswitchs ................................................................ 40
III.2.4.6 Optimisation du rseau de transport.............................................................. 41
III.3 Dimensionnement dans le NGN Multimdia ................................................................ 43
III.3.1 Architecture cible du rseau UMTS...................................................................... 43
III.3.2 Scnario de migration retenu................................................................................. 43
III.3.3 Modle de trafic du rseau daccs ....................................................................... 43
III.3.3.1 Les diffrentes classes de qualit de service ................................................. 44
III.3.3.1.1 Classe des services conversationnels ................................................. 44
III.3.3.1.2 Classe des services flux continu ou Streaming................................ 44
III.3.3.1.3 Classe des services interactifs ............................................................ 44
III.3.3.1.4 Classe des services en mode tlchargement ou background ............ 45
III.3.3.2 Modles de trafic........................................................................................... 45
III.3.3.2.1 Modle de trafic pour le service conversationnel............................... 45
III.3.3.2.2 Modle de trafic pour le service flux continu.................................. 45
III.3.3.2.3 Modle de trafic pour le service interactif.......................................... 45
III.3.3.2.4 Modle de trafic de la classe Background.......................................... 46
III.3.4 Mthodologie du dimensionnement ...................................................................... 46
v
III.3.4.1 Les hypothses du dimensionnement ............................................................ 46
III.3.4.2 Organigramme de dimensionnement du rseau NGN Multimdia............... 47
III.3.4.3 Calcul du trafic gnr par le rseau daccs ................................................ 47
III.3.4.4 Dimensionnement des entits du rseau........................................................ 49
III.3.4.4.1 Dimensionnement des M_MGWs...................................................... 49
III.3.4.4.2 Dimensionnement des IMS_MGWs .................................................. 49
III.3.4.4.3 Dimensionnement de MGCF.............................................................. 49
III.3.4.4.4 Dimensionnement de MSC Server ..................................................... 50
III.3.4.4.5 Dimensionnement des SGSNs............................................................ 50
III.3.4.4.6 Dimensionnement des GGSNs........................................................... 50
III.3.4.5 Optimisation du rseau de transport.............................................................. 51
III.4 Conclusion..................................................................................................................... 51

Chapitre IV : Outil de dimensionnement et validation sur des scnarios........................ 52
IV.1 Introduction................................................................................................................... 52
IV.2 Cahier de charges de loutil........................................................................................... 52
IV.2.1 Objectif de l'outil de dimensionnement ................................................................ 52
IV.2.2 Paramtres d'entre ............................................................................................... 52
IV.2.2.1 NGN Tlphonie ........................................................................................... 52
IV.2.2.2 IMS................................................................................................................ 53
IV.2.3 Paramtres de sortie .............................................................................................. 53
IV.2.3.1 NGN Tlphonie ........................................................................................... 53
IV.2.3.2 IMS................................................................................................................ 54
IV.2.4 Interface Utilisateur............................................................................................... 54
IV.3 Environnement de dveloppement ................................................................................ 54
IV.4 Fonctionnalits de loutil............................................................................................... 55
IV.4.1 Organigramme fonctionnel de loutil.................................................................... 55
IV.4.2 Modules dvelopps.............................................................................................. 55
IV.4.2.1 Module destimation de la charge de trafic pour le NGN Tlphonie.......... 55
IV.4.2.2 Module destimation de la charge de trafic pour le NGN Multimdia ......... 56
IV.4.2.3 Module doptimisation du rseau de transport.............................................. 56
IV.4.2.4 Module de prvision de trafic ....................................................................... 57
IV.5 Interface utilisateur dveloppe .................................................................................... 57
V.5.1 Fentre principale de loutil.................................................................................... 57
V.5.2 Menu NGN Tlphonie .......................................................................................... 59
V.5.3 Menu NGN Multimdia ......................................................................................... 59
V.5.4 Menu Prvision....................................................................................................... 59
V.5.5 Menu Aide.............................................................................................................. 60
IV.6 Validation sur scnarios ................................................................................................ 60
IV.6.1 Cas du rseau NGN Tlphonie............................................................................ 60
IV.6.1.1 Acquisition des paramtres et donnes dentre ........................................... 60
IV.6.1.2 Rsultats obtenus........................................................................................... 63
IV.6.2 Cas du rseau NGN Multimdia ........................................................................... 68
IV.6.2.1 Acquisition des paramtres et donnes dentre ........................................... 68
IV.6.2.2 Rsultats obtenus........................................................................................... 71
IV.7 Conclusion..................................................................................................................... 78

Conclusion gnrale .............................................................................................................. 79

Bibliographie ......................................................................................................................... 80

vi
Liste des figures

Figure I.1 : Principe gnral darchitecture dun rseau NGN.................................................. 4
Figure I.2 : Architecture simplifie des NGN........................................................................... 7
Figure I.3 : Les familles de protocoles dun rseau NGN....................................................... 10
Figure I.4 : Exemple darchitecture NGN Tlphonie............................................................ 11
Figure I.5 : Services dans le RTC............................................................................................ 11
Figure I.6 : Services dans le NGN Tlphonie........................................................................ 12
Figure I.7 : Exemple darchitecture NGN Multimdia ........................................................... 14
Figure I.8 : Entits de Rseau IMS.......................................................................................... 16
Figure I.9 : Interfonctionnement entre RTC et IMS................................................................ 18
Figure II.1 : Hirarchie des commutateurs du rseau RTC..................................................... 22
Figure II.2 : Architecture dune solution NGN pour le trafic de transit international ............ 23
Figure II.3 : Architecture dune solution NGN pour le trafic de transit national.................... 24
Figure II.4 : Architecture dune solution NGN de classe 4..................................................... 25
Figure II.5 : Architecture dun rseau NGN de classe 5 ......................................................... 27
Figure II.6 : Architecture overlay VoIP .................................................................................. 28
Figure II.7 : Les diffrentes phases de la stratgie de migration overlay................................ 29
Figure II.8 : Architecture domaine circuit UMTS release R4................................................. 31
Figure II.9 : Architecture de rfrence Release 5.................................................................... 32
Figure III.1 : Mise en place de scnario de migration retenu.................................................. 36
Figure III.2 : Exemple dune liaison A-C du rseau cur ...................................................... 42
Figure III.3 : Calcul de la capacit totale fournir sur la liaison A-C.................................... 42
Figure III.4 : Architecture fonctionnelle du rseau cur UMTS............................................ 43
Figure IV.1 : Fentre principale de loutil............................................................................... 58
Figure IV.2 : Fentre de cration dun nouveau projet ........................................................... 58
Figure IV.3 : Fentre A propos ............................................................................................... 60
Figure IV.4 : Authentification de lutilisateur......................................................................... 60
Figure IV.5 : Ajout des donnes de loprateur ...................................................................... 61
Figure IV.6 : Saisie des donnes dentre de la zone3-CT1 ................................................... 62
Figure IV.7 : Saisie des donnes dentre de la zone3-CT2 ................................................... 62
Figure IV.8 : Calcul du trafic total gnr par les rseaux daccs......................................... 63
Figure IV.9 : Rpartition du trafic RTC/RNIS entre les deux CT de la zone 3 ...................... 63
Figure IV.10 : Rpartition du trafic GSM/GPRS entre les trois MSC de la zone 3................ 64
Figure IV.11 : dtermination des charges des MGs et des softswitchs................................... 64
Figure IV.12 : Calcul du nombre des MGs et des softswitchs ................................................ 65
Figure IV.13 : Optimisation du rseau de transport de la zone 3............................................ 65
Figure IV.14 : Prvision du trafic RTC/RNIS de la zone 3 .................................................... 66
Figure IV.15 : Prvision du trafic GSM/GPRS de la zone 3................................................... 66
Figure IV.16 : Prvision des charges des MGs et des softswitchs de la zone 3...................... 67
Figure IV.17 : Extrait du rapport rcapitulatif de dimensionnement de la zone 3.................. 67
Figure IV.18 : Modle de trafic du rseau daccs.................................................................. 68
Figure IV.19 : Fixation des paramtres gnraux ................................................................... 69
Figure IV.20 : Rpartition des paramtres dentre par zone.................................................. 70
Figure IV.21 : trafic conversationnel en mode circuit issu des rseaux RTC et GSM........... 71
Figure IV.22 : Calcul du trafic total gnr par les abonns EDGE et UMTS ....................... 71
Figure IV.23 : Rpartition du trafic EDGE entre les cinq zones............................................. 72
Figure IV.24 : Rpartition du trafic UMTS entre les cinq zones ............................................ 72
vii
Figure IV.25 : Dtermination des charges des entits fonctionnelles ..................................... 72
Figure IV.26 : Dtermination du nombre des entits fonctionnelles ...................................... 73
Figure IV.27 : Optimisation du rseau de transport pour les cinq zones ................................ 74
Figure IV.28 : Prvision du trafic EDGE des cinq zones........................................................ 74
Figure IV.29 : Prvision du trafic UMTS des cinq zones ....................................................... 75
Figure IV.30 : Prvision des charges des entits fonctionnelles ............................................. 75
Figure IV.31 : Courbe de prvision des charges des M-MGW et IMS-MGW....................... 75
Figure IV.32 : Courbe de prvision des charges des MSC Server et MGCF.......................... 76
Figure IV.33 : Courbe de prvision des charges des SGSNs et GGSNs................................. 76
Figure IV.34 : Rapport Technique de dimensionnement des cinq zones................................ 77

viii
Liste des tableaux

Tableau II.1 : Architecture de rseau UMTS R5..................................................................... 33
Tableau IV.1 : Paramtres dentre de la zone 3..................................................................... 61
Tableau IV.2 : Rpartition des abonns EDGE et UMTS....................................................... 69
Tableau IV.3 : Pourcentages dattachement des abonns EDGE et UMTS............................ 70
Tableau IV.4 : Taux dactivit des services ............................................................................ 70

ix
Liste des organigrammes

Organigramme III.1 : Organigramme de calcul du trafic RTC/RNIS...................................... 37
Organigramme III.2 : Organigramme de calcul du trafic GSM/GPRS.................................... 37
Organigramme III.3 : Organigramme de dimensionnement des entits .................................. 38
Organigramme III.4 : Organigramme doptimisation du rseau de transport .......................... 38
Organigramme III.5 : Organigramme rcapitulatif du dimensionnement................................ 47
Organigramme III.6 : Rpartition de trafic de la classe conversationnelle.............................. 48
Organigramme IV.1 : Principe de fonctionnement de loutil................................................... 55
Organigramme IV.2 : Estimation de la charge de trafic cas NGN Tlphonie........................ 56
Organigramme IV.3 : Estimation de la charge de trafic cas NGN Multimdia ....................... 56

x
Liste des abrviations

AAL2 ATM Adaptation Layer2
ADSL Asymmetric Digital Subscriber Line
AS Application Server
ATM Asynchronous Transfert Mode
BER Bit Error Rate
BLR Boucle Locale Radio
CSCF Call State Control Function
CT Commutateur de Transit
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
DSLAM DSL Access Multiplexer
EDGE Enhanced Data Rates for GSM Evolution
FTTH Fiber To The Home
GGSN Gateway GPRS Support Node
3GPP 3
rd
Generation Partnership Project
GPRS General Packet Radio Services
GSM Global System for Mobile Communications
GTP GPRS Tunnel Protocol
HFC Hybrid Fiber Coax
IETF Internet Engineering Task Force
IN Intelligent Network
IP Internet Protocol
ISUP ISDN User Part
MAP Mobile Application Part
MG Media gateway
MMS Multimedia Messaging Service
MPLS Multi-Protocol Label Switching
MSC Mobile Switching Center
PABX Private Automatic Branch Exchange
PDP Packet Data Protocol
PoS Packets over SDH
PSTN Public Switched Telephon Network
xi
RADIUS Remote Access Dial In User Service
RNC Radio Network Controller
RNIS Rseau Numrique Intgration de Services
RTC Rseau Tlphonique Commut
RTP Real Time Protocol
SDH Synchronous Digital Hierarchy
SDP Session Description Protocol
SGSN Serving GPRS Support Node
SIGTRAN SIGnalling TRANsport
SMS Short Messaging Service
TDM Time Division Multiplexing
UIT Union Internationale des Tlcommunications
UMTS Universal Mobile Telecommunication System
UTRAN UMTS Terrestrail Radio Access Network
WDM Wavelength Division Multiplexing
WiFi Wireless Fidelity
Introduction gnrale
1
Introduction gnrale

Un rseau peut tre vu comme un ensemble de ressources mises en place pour offrir un
ensemble de services. Cest lvolution des services et des trafics qui en dcoulent qui a
pilot, dans les dernires annes, lvolution technologique permettant daugmenter la
capacit et les fonctionnalits des ressources des rseaux. Ainsi, par exemple, le succs des
services de lInternet a engendr une explosion de trafic ; ce qui a men les oprateurs
utiliser de nouvelles technologies dans le coeur des rseaux telles que lIP sur ATM, le PoS,
lIP sur WDM et le MPLS.
Les volutions rcentes ont galement t fortement influences par la drgulation. La
concurrence a amen une baisse des prix de la plupart des services classiques, ce qui a rduit
les revenus des oprateurs. Ds lors que la diffrenciation par les prix devient difficile, celle-
ci ne peut se faire que par les services et leur qualit. Loffre de services innovants et
lamlioration de la qualit des services existants, tels que la navigation du Web, requirent
souvent une volution de la bande passante laccs. Ainsi, des technologies comme le
xDSL, la BLR et les rseaux HFC, se sont dveloppes.
Un point essentiel dans lvolution de loffre de services concerne la capacit regrouper
lensemble des services dont le client a besoin et de les lui offrir, si possible de manire
convergente, travers une interface unique. Cela pousse dans la direction de btir des rseaux
multiservices avec convergence entre services. Dans cette situation, le terme "convergence"
(des techniques et des services) est largement utilis pour dsigner la fusion des services et
des techniques. La convergence s'observe ainsi entre la tlvision et les tlcommunications,
les rseaux fixes et les rseaux mobiles, les tlcommunications et l'information, les
ordinateurs et l'lectronique grand public. De la convergence dcoule la ncessit de disposer
d'architectures, de rseaux, d'quipements et d'outils de gestion permettant de rpondre aux
besoins des consommateurs, en ce qui concerne les services proposs, et aux besoins
techniques observs au niveau des rseaux pour ce qui est des interfaces entre les
quipements, les rseaux et les services. La nouvelle gnration darchitectures de rseaux :
NGN (Next Generation Networks) semblent bien adaptes pour la mise en place de la
convergence voix/donnes.
Dans ce contexte lobjectif de notre projet de fin dtudes est de faire une tude dtaille des
caractristiques de larchitecture des rseaux NGN et de la migration vers ces nouveaux types
Introduction gnrale
2
de rseaux ainsi que le dimensionnement des entits fonctionnelles de cette architecture en
prenant pour notre cas dtude le rseau de Tunisie Tlcom. Ce processus de
dimensionnement dbouchera sur le dveloppement dun outil universel de dimensionnement
dun rseau NGN.
Le prsent rapport est organis en quatre chapitres :
Le premier chapitre trace les principales caractristiques des rseaux NGN en
s'appuyant sur un dcoupage synthtique de la notion mme de rseau nouvelle
gnration ; nous nous sommes efforcs de dcrire les principales couches, les entits
fonctionnelles, les protocoles mis en jeu, les diffrents types de rseaux NGN pour
enfin citer les services offerts par les NGN.
Le deuxime chapitre est scind en deux parties ; dans la premire partie, nous avons
essay de proposer un ensemble de solutions de migration des rseaux fixes vers
l'architecture nouvelle gnration tandis que la deuxime partie donne une solution de
migration des rseaux mobiles en s'appuyant sur l'architecture des rseaux de
troisime gnration. Dans l'optique d'une stratgie de migration des rseaux mobiles,
nous n'avons pas manqu de dcortiquer les spcifications de la 3GPP.
Le troisime chapitre est consacr essentiellement pour dtailler le processus du
dimensionnement du rseau NGN. En effet, nous avons dcrit les diffrentes tapes
suivre pour atteindre notre objectif.
Le dernier chapitre dcrit loutil universel de dimensionnement dvelopp dont le
fonctionnement est bas sur la mthodologie prsente dans le chapitre 3. Une tape
de validation de cet outil sera faite par des scnarios de dimensionnement.
Enfin, nous avons retenu dans une conclusion gnrale les grandes lignes de ce qui, notre
sens, mrite une attention toute particulire de la part des lecteurs.

Architecture NGN : Du NGN Tlphonie au NGN Multimdia
3
Chapitre I
Architecture NGN : Du NGN Tlphonie
au NGN Multimdia

I.1 Introduction
Depuis de nombreuses annes, lindustrie des tlcommunications cherche orienter sa
technologie de manire aider les oprateurs demeurer comptitifs dans un environnement
caractris par la concurrence et la drglementation accrues.
Les rseaux de la prochaine gnration (NGN ou Next Generation Networks en anglais), avec
leur architecture rpartie, exploitent pleinement des technologies de pointe pour offrir de
nouveaux services sophistiqus et augmenter les recettes des oprateurs tout en rduisant leurs
dpenses dinvestissement et leurs cots dexploitation.
Ce premier chapitre est consacr la prsentation des rseaux de nouvelle gnration. Dans
une premire section nous nous sommes intresss larchitecture des rseaux NGN, aux
diffrents lments qui le composent ainsi quaux diffrents protocoles en concurrence. La
deuxime section met laccent sur les deux types des rseaux NGN : NGN Tlphonie et
NGN Multimdia (IMS). Enfin, une troisime section qui sera ddie aux services offerts par
les NGN.
I.2 Dfinition
Les NGN sont dfinis comme un rseau de transport en mode paquet permettant la
convergence des rseaux Voix/donnes et Fixe/Mobile; ces rseaux permettront de fournir des
services multimdia accessibles depuis diffrents rseaux daccs.
Afin de sadapter aux grandes tendances qui sont la recherche de souplesse dvolution de
rseau, la distribution de lintelligence dans le rseau, et louverture des services tiers, les
NGN sont bass sur une volution progressive vers le tout IP et sont modliss en couches
indpendantes dialoguant via des interfaces ouvertes et normalises. [1]
La couche Accs , qui permet laccs de lutilisateur aux services via des supports
de transmission et de collecte divers : cble, cuivre, fibre optique, boucle locale radio,
xDSL, rseaux mobiles.
La couche Transport , qui gre lacheminement du trafic vers sa destination. En
bordure du rseau de transport, des Media Gateways et des Signalling Gateways
4
grent respectivement la conversion des flux de donnes et de signalisation aux
interfaces avec les autres ensembles rseau ou les rseaux tiers interconnects.
La couche Contrle , qui se compose de serveurs dits Softswitch grant dune
part les mcanismes de contrle dappel (pilotage de la couche transport, gestion des
adresses), et dautre part laccs aux services (profils dabonns, accs aux plates-
formes de services valeur ajoute).
La couche Services , qui regroupe les plates-formes dexcution de services et de
diffusion de contenus. Elle communique avec la couche contrle du coeur de rseau
via des interfaces ouvertes et normalises, indpendantes de la nature du rseau
daccs utilis. Les services et contenus eux-mmes sont par ailleurs dvelopps avec
des langages convergents et unifis.
La figure suivante prsente le principe gnral d'architecture d'un rseau NGN.
Figure I.1 : Principe gnral darchitecture dun rseau NGN
I.3 Pourquoi Le NGN ?
Dans certaines parties du monde, le trafic de donnes prend rapidement le pas sur le trafic
vocal et la tendance est nettement laugmentation en bande passante pour les donnes, tandis
que la voix peut se satisfaire dune bande passante de 64 kbit/s, voire moindre. Les oprateurs
possdant les deux types de rseaux (rseau voix et rseau de donnes) utilisent cet argument
pour commencer les unifier. Il est clair daprs les limites du rseau TDM (Time Division
Multiplexing) que le rseau de donnes survivra alors que le rseau TDM quittera la scne.
Facteur non moins important : le nouveau besoin chez les usagers dune varit encore plus
grande dapplications et de services sophistiqus (Push-to-talk, confrence audio et vido,
messagerie unifie, chat) dont la plupart ntaient mme pas envisags lors de la conception
des rseaux actuels. Pour les oprateurs, laccs et le transport ne sont plus assez lucratifs et,
5
pour rester comptitif, il leur faudra donc offrir aux usagers toute une gamme de services
utiles, faciles utiliser et rmunrateurs. Par consquent, les NGN seront axs sur les
services, et fourniront tous les moyens ncessaires pour en offrir de nouveaux et adapter les
existants pour augmenter les recettes.
Les oprateurs entrants (oprateurs ADSL) pourront envisager dinvestir dans une solution
demble NGN. Pour un oprateur tabli, limportant est de dfinir les conditions de
migration de leur rseau tlphonique commut actuel vers le NGN.
I.4 Types de NGN
Il existe trois types de rseau NGN : NGN Class 4, NGN Class 5 et NGN Multimdia.
Les NGN Class 4 et Class 5 sont des architectures de rseau offrant uniquement les services
de tlphonie. Il sagit donc de NGN tlphonie. Dans le RTC, un commutateur Class 4 est un
centre de transit. Un commutateur Class 5 est un commutateur daccs aussi appel centre
autonomie dacheminement. Le NGN Class 4 (respectivement NGN Class 5) mule donc le
rseau tlphonique au niveau transit (respectivement au niveau accs) en transportant la voix
sur un mode paquet.
Le NGN Multimdia est une architecture offrant les services multimdia (messagerie
vocale/vido, confrence audio/vido, Ring-back tone voix/vido) puisque l'usager a un
terminal IP multimdia. Cette solution est plus intressante que les prcdentes puisquelle
permet loprateur dinnover en termes de services par rapport une solution NGN
tlphonie qui se cantonne offrir des services de tlphonie.
Le Class 4 NGN permet :
Le remplacement des centres de transit tlphoniques (Class 4 Switch).
La croissance du trafic tlphonique en transit.
Le Class 5 NGN permet :
Le remplacement des centres tlphoniques daccs (Class 5 Switch).
La croissance du trafic tlphonique laccs.
La voix sur DSL/ Voix sur le cble.
Le NGN Multimdia permet doffrir des services multimdia des usagers disposant dun
accs large bande tel que xDSL, cble, WiFi/WiMax, EDGE/UMTS, etc.
I.5 Avantages du NGN
Cette nouvelle topologie offre les avantages suivants :
Grce au NGN, loprateur dispose dun rseau multiservice permettant dinterfacer
nimporte quel type daccs (Boucle locale, PABX, Commutateur daccs
tlphonique, accs ADSL, accs mobile GSM ou UMTS, tlphone IP, etc.).
Loprateur naura plus terme qu exploiter un seul rseau multiservice.
6
Elle utilise le transport comme lIP ou lATM ignorant les limites des rseaux TDM
(Time Division Multiplexing) 64 kbit/s. En effet le TDM perd son efficacit ds lors
que lon souhaite introduire des services asymtriques, sporadiques ou dbit binaire
variable.
Cest une topologie ouverte qui peut transporter aussi bien les services tlphoniques
que les services de multimdia (vido, donnes temps rel).
Elle dissocie la partie support du rseau de la partie contrle, leur permettant dvoluer
sparment et brisant la structure de communication monolithique. En effet, la couche
transport peut tre modifie sans impact sur les couches contrle et application.
Elle utilise des interfaces ouvertes entre tous les lments, permettant loprateur
dacheter les meilleurs produits pour chaque partie de son rseau.
I.6 Architecture NGN
Les principales caractristiques des rseaux NGN sont lutilisation dun unique rseau de
transport en mode paquet (IP, ATM,) ainsi que la sparation des couches de transport des
flux et de contrle des communications, qui sont implmentes dans un mme quipement
pour un commutateur traditionnel.
Ces grands principes et concernant les quipements actifs du coeur de rseau NGN se
dclinent techniquement comme suit :
Remplacement des commutateurs traditionnels par deux quipements distincts :
Dune part des serveurs de contrle dappel dits Softswitch ou Media Gateway
Controller (correspondant schmatiquement aux ressources processeur et
mmoire des commutateurs voix traditionnels).
Dautre part des quipements de mdiation et de routage dits Media Gateway
(correspondant schmatiquement aux cartes dinterfaces et de signalisation et
aux matrices de commutation des commutateurs voix traditionnels), qui
sappuient sur le rseau de transport mutualis NGN.
Apparition de nouveaux protocoles de contrle dappel et de signalisation entre ces
quipements (de serveur serveur, et de serveur Media Gateway).
La figure I.2 prsente la structure physique dun rseau NGN avec les diffrentes entits
fonctionnelles, les principaux rseaux daccs ainsi que les diffrents protocoles mis en
oeuvre.
7
Figure I.2 : Architecture simplifie des NGN
I.6.1 Les entits fonctionnelles du coeur de rseau NGN
I.6.1.1 La Media Gateway (MG)
La Media Gateway est situe au niveau du transport des flux mdia entre le rseau RTC et les
rseaux en mode paquet, ou entre le coeur de rseau NGN et les rseaux daccs. Elle a pour
rle :
Le codage et la mise en paquets du flux mdia reu du RTC et vice-versa (conversion
du trafic TDM / IP).
La transmission, suivant les instructions du Media Gateway Controller, des flux mdia
reus de part et d'autre.
I.6.1.2 La Signalling Gateway (SG)
La fonction Signalling Gateway a pour rle de convertir la signalisation change entre le
rseau NGN et le rseau externe interconnect selon un format comprhensible par les
quipements chargs de la traiter, mais sans linterprter (ce rle tant dvolu au Media
Gateway Controller). Notamment, elle assure ladaptation de la signalisation par rapport au
protocole de transport utilis (exemple : adaptation TDM / IP).
I.6.1.3 Le serveur dappel ou Media Gateway Controller (MGC) ou Softswitch
Dans un rseau NGN, cest le MGC qui possde l'intelligence . Il gre :
Lchange des messages de signalisation transmise de part et d'autre avec les
passerelles de signalisation, et linterprtation de cette signalisation.
Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP,
communication avec les serveurs dapplication pour la fourniture des services.
Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du
rseau, etc.
8
La rservation des ressources dans le MG et le contrle des connexions internes au
MG (commande des Media Gateways).
I.6.2 Les familles de protocoles dun rseau NGN
La convergence des rseaux voix/donnes ainsi que le fait dutiliser un rseau en mode paquet
pour transporter des flux multimdia, ayant des contraintes de temps rel , a ncessit
ladaptation de la couche contrle. En effet ces rseaux en mode paquet taient gnralement
utiliss comme rseau de transport mais noffraient pas de services permettant la gestion des
appels et des communications multimdia. Cette volution a conduit lapparition de
nouveaux protocoles, principalement concernant la gestion des flux multimdia, au sein de la
couche Contrle.
I.6.2.1 Les protocoles de contrle dappel
Les protocoles de contrle dappel permettant ltablissement, gnralement linitiative dun
utilisateur, dune communication entre deux terminaux ou entre un terminal et un serveur ; les
deux principaux protocoles sont H.323, norme de lUIT et SIP, standard dvelopp
lIETF.[2]
I.6.2.1.1 Le protocole historique : H.323
La recommandation H.323 de lUIT dcrit les procdures pour les communications audio et
vido point point ou multipoint sur des rseaux en mode paquet. Cest une adaptation des
procdures de vidoconfrence sur RNIS (H.320) aux rseaux sans garantie de service.
Plusieurs entits sont ncessaires la ralisation dun service de communication multimdia
sur des rseaux de donnes :
Les terminaux H.323 sont des systmes multimdia (tlphone, PC) permettant de
communiquer en temps rel .
Le gatekeeper gre les terminaux H.323 (identification et traduction dadresses) et les
tablissements dappels.
La passerelle H.323 (gateway) permet dinterfacer le rseau IP avec le rseau
tlphonique classique.
Lunit de contrle MCU (Multipoint Controller Unit) gre les connexions multipoint
(ex. : appels de confrence). Il se dcompose en un Multipoint Controller (MC),
affect la signalisation, et un Multipoint Processor (MP), ddi la transmission
proprement dite.
I.6.2.1.2 Le protocole alternatif : SIP
SIP (Session Initiation Protocol) est un protocole de contrle qui peut tablir, modifier et
terminer des sessions multimdia, aussi bien des confrences que des appels tlphoniques sur
des rseaux mode paquets. Il est sous forme de texte, tout comme http ou SMTP, et a pour
9
rle dinitier des sessions de communications interactives. Ces sessions peuvent inclure aussi
bien de la voix, de la vido, des jeux interactifs...
L'architecture de SIP est base sur des relations client/serveur. Les principales composantes
sont :
Les terminaux sont des appareils pouvant mettre et recevoir de la signalisation SIP.
Le Redirect Server tablit la correspondance entre ladresse SIP du terminal appel et
la ou les adresses o il pourra effectivement tre joignable.
Le Proxy Server remplit la mme la fonction quun Redirect Server.
Le Registrar est essentiel dans tout rseau SIP ou lon veut utiliser les services de
localisation.
I.6.2.2 Les protocoles de commande de Media Gateway
Les protocoles de commande de Media Gateway sont issus de la sparation entre les couches
Transport et Contrle et permet au Softswitch ou Media Gateway Controller de grer les
passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de
lIETF et H.248/MEGACO, dvelopp conjointement par lUIT et lIETF, sont actuellement
les protocoles prdominants.
I.6.2.2.1 Le protocole historique : MGCP
Le Media Gateway Control Protocol (MGCP), protocole dfini par lIETF, a t conu pour
des rseaux de tlphonie IP utilisant des passerelles VoIP. Il gre la communication entre les
Media Gateway et les Media Gateway Controller. Ce protocole traite la signalisation et le
contrle des appels, dune part, et les flux mdia dautre part.
I.6.2.2.2 Le protocole alternatif : MEGACO/H.248
Le groupe de travail MEGACO (MEdia GAteway COntrol) a t constitu en 1998 pour
complter les travaux sur le protocole MGCP au sein de lIETF.
Depuis 1999, lUIT et lIETF travaillent conjointement sur le dveloppement du protocole
MEGACO/H.248 ; cest un standard permettant la communication entre les Media Gateway
Controller (MGC) et les Media Gateway (MG). Il est driv de MGCP et possde des
amliorations par rapport celui-ci :
Support de services multimdia et de vidoconfrence.
Possibilit dutiliser UDP ou TCP.
Utilise le codage en mode texte ou binaire.
I.6.2.3 Les protocoles de signalisation entre les serveurs de contrle
Les protocoles de signalisation entre les serveurs de contrle (ou Media Gateway Controller)
permettant la gestion du plan contrle :
Au niveau du coeur de rseau avec des protocoles tels que BICC (Bearer Independant
Call Control), SIP-T (SIP pour la tlphonie) et H.323.
10
A linterconnexion avec les rseaux de signalisation SS7, gnralement via des
passerelles de signalisation ou Signalling Gateways par lutilisation de protocole tel
que SIGTRAN. De plus, linterconnexion de ces rseaux de donnes avec les rseaux
existants de tlphonie (TDM avec signalisation SS7) a ncessit le dveloppement de
protocoles ddis linterconnexion des rseaux et au transport de la signalisation SS7
sur des rseaux en mode paquet.
La figure I.3 illustre les niveaux auxquels sont utiliss les diffrents protocoles cits
prcdemment.
Figure I.3 : Les familles de protocoles dun rseau NGN
I.7 NGN Tlphonie
Comme nous lavons dfinit prcdemment, le NGN tlphonie est une architecture de rseau
NGN offrant uniquement les services de tlphonie (voix,).
I.7.1 Architecture NGN Tlphonie
La figure I.4 montre un exemple darchitecture NGN Tlphonie. Les quipements existants
(exemple : commutateur daccs tlphonique ou BTS/BSC du rseau GSM) sont relis une
couche de transport IP ou ATM par le biais de Media Gateways (couche transport).
Ltablissement des canaux de communication IP ou ATM entre les Media Gateways est la
responsabilit du MGC appartenant la couche contrle.
Le MGC est un serveur dappel qui contient lintelligence lie au contrle de lappel et pour
ce faire possde un modle dappel complet. Le MGC identifie les usagers, dtermine le
niveau de service pour chaque usager et lacheminement de trafic. Par ailleurs, il fournit
toutes les informations permettant la taxation des appels et la mesure des performances du
rseau. Aussi, le MGC sinterface aux serveurs dapplications.
Dans larchitecture NGN Tlphonie, le protocole de contrle tel que MGCP ou MEGACO
ne fait que dcrire les interactions entre le MGC et le MG. Si un MGC doit contrler un MG
11
qui est sous la responsabilit dun autre MGC, il est ncessaire que les MGCs schangent de
la signalisation.
Une fois la connexion tablie, le MG convertira les signaux audio transports dans les circuits
de parole (terminaison circuit) en paquets IP qui seront transports dans le rseau IP
(terminaison IP) ou en cellules ATM dans le cas dun transport ATM.[3]
Figure I.4 : Exemple darchitecture NGN Tlphonie
I.7.2 Services dans le RTC versus Services dans le NGN Tlphonie
Dans le contexte du Rseau Tlphonique Commut, le commutateur ralise deux fonctions
essentielles :
La commutation de la voix (Media).
Le contrle de lappel (tablissement / libration dappel).
Les services valeur ajoute sont mis en oeuvre par le rseau intelligent travers les entits
SCP (Service Control Point) / SRP (Specialized Resource Point).
Les services complmentaires sont mis en oeuvre directement par le commutateur daccs
(Class 5 Switch).
Figure I.5 : Services dans le RTC
12
Dans le monde NGN, la commutation de la voix est ralise par le MG entre le rseau
tlphonique commut et le rseau de transport du NGN. Dans le rseau de transport, ce sont
les commutateurs ATM / Routeurs IP qui assurent le transport de la voix paqutise jusquau
MG de sortie qui commute la parole reconvertie, sur un circuit de parole sortant.
Le contrle de lappel (tablissement / libration dappel) est pris en charge par le MGC. Un
MGC Class 4 mule le point smaphore dun Class 4 Switch. Un MGC Class 5 mule le point
smaphore dun Class 5 Switch.
Les services valeur ajoute sont pris en charge par le SCP lgataire du rseau intelligent ou
par un serveur dapplication SIP et par un serveur de media (appel Multimedia Resource
Function) qui fonctionne en voix sur IP (il met des annonces vocales et collecte
linformation de lusager sur des canaux RTP/UDP/IP).
Figure I.6 : Services dans le NGN Tlphonie
I.8 NGN Multimdia ou IMS (IPMultimedia Subsystem)
L'IMS normalis par le monde des tlcommunications est une nouvelle architecture base sur
de nouveaux concepts, de nouvelles technologies, de nouveaux partenaires et un nouvel
cosystme. LIMS supporte sur un rseau tout IP les sessions applicatives temps rels (voix,
vido, confrence,) et non temps rel (Push To Talk, Prsence, messagerie instantane,).
LIMS intgre de plus le concept de convergence de services supports indiffremment par
des rseaux de natures diffrentes : fixe, mobile ou Internet. LIMS est galement dsign
sous le vocable de NGN Multimdia. [4]
I.8.1 Architecture IMS
Lintroduction de lIMS (IP Multimedia Subsystem) dans les rseaux fixe et mobile
reprsente un changement fondamental dans les rseaux de tlcommunication de type voix.
Les nouvelles capacits des rseaux et des terminaux, le mariage entre l Internet et la voix, le
contenu et la mobilit donnent naissance des nouveaux modles de rseaux et surtout offrent
un formidable potentiel pour dvelopper de nouveaux services. Dans cet objectif, l IMS est
13
conu pour offrir aux utilisateurs la possibilit dtablir des sessions multimdia en utilisant
tout accs haut dbit et une commutation de paquets IP.
LIMS fournit un rseau IP multi-service, multi-accs, scuris et fiable :
Multi-services : tout type de services dlivrs par un rseau coeur supportant diffrents
niveaux de QoS pourront tre offerts lusager.
Multi-accs: tout rseau daccs large bande, fixe et mobile pourra sinterfacer
lIMS.
LIMS nest pas un unique rseau, mais diffrents rseaux qui interoprent grce des
accords de roaming IMS fixe-fixe, fixe-mobile, mobile-mobiles.
LIMS est un enabler pour les fournisseurs de service afin doffrir :
Des services de communication non temps-rel, pseudo temps-rel et temps rel
suivant une configuration client-server ou entre entits paires.
La mobilit des services / Mobilit de lusager (Nomadisme).
Plusieurs sessions et services simultanment sur la mme connexion rseau.
I.8.2 Structuration en couche de larchitecture IMS
Larchitecture IMS peut tre structure en couches. Quatre couches importantes sont
identifies :
La couche accs peut reprsenter tout accs haut dbit tel que : UTRAN (UMTS
Terrestrial Radio Access Network), CDMA2000 (technologie daccs large bande
utilise dans les rseaux mobiles aux Etats-Unis), xDSL, rseau cble, Wireless IP,
WiFi, etc.
La couche transport reprsente un rseau IP. Ce rseau IP pourra intgrer des
mcanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste
donc en des routeurs (edge router laccs et en core router en transit) relis par un
rseau de transmission. Diffrentes piles de transmission peuvent tre considres
pour le rseau IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc.
La couche contrle consiste en des contrleurs de session responsables du routage
de la signalisation entre usagers et de linvocation des services. Ces noeuds sappellent
des CSCF (Call State Control Function). IMS Introduit donc un environnement de
contrle de session sur le domaine paquet.
La couche application introduit les applications (services valeur ajoute)
proposes aux usagers. Loprateur peut se positionner grce sa couche
CONTRLE en tant quagrgateur de services offerts par loprateur lui-mme ou par
des tiers. La couche application consiste en des serveurs dapplication (AS,
Application Server) et des MRF (Multimedia Resource Function) que les fournisseurs
appellent serveurs de mdia IP (IP MS, IP Media Server).
14
Larchitecture globale IMS est dcrite la figure I.7.
Figure I.7 : Exemple darchitecture NGN Multimdia
I.8.3 Entits de Rseau IMS
I.8.3.1 Terminal IMS
Il sagit dune application sur un quipement de lusager qui met et reoit des requtes SIP. Il
se matrialise par un logiciel install sur un PC, sur un tlphone IP ou sur une station mobile
UMTS (UE, User Equipment).
I.8.3.2 Home Subscriber Server (HSS)
Lentit HSS (Home Subscriber Server) est la principale base de stockage des donnes des
usagers et des services auxquels ils ont souscrit. Les principales donnes stockes sont les
identits de lusager, les informations denregistrement, les paramtres daccs et les
informations permettant linvocation des services de lusager. Lentit HSS interagit avec les
entits du rseau travers le protocole Diameter.
I.8.3.3 Call State Control Function (CSCF)
Le contrle d'appel initi par un terminal IMS doit tre pris en charge dans le rseau nominal
(rseau auquel lusager a souscrit ses services IMS) car l'usager correspondant peut
souscrire un grand nombre de services et certains d'entre eux peuvent ne pas tre disponibles
ou peuvent fonctionner diffremment dans un rseau visit, notamment suite des problmes
dinteraction de service. Cela a induit la dfinition de trois entits CSCF : P-CSCF (Proxy
CSCF), I-CSCF (Interrogating CSCF) et S-CSCF (Serving-CSCF).
15
Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS. Son adresse
est dcouverte par le terminal lors de l'activation d'un contexte PDP pour lchange de
messages de signalisation SIP.
Le P-CSCF se comporte comme un Proxy Server SIP lorsqu'il relaye les messages SIP vers le
destinataire appropri et comme un User Agent SIP lorsqu'il termine l'appel (exemple : suite
une erreur dans le message SIP reu).
Les fonctions ralises par l'entit P-CSCF comprennent :
L'acheminement de la mthode SIP REGISTER mise par le terminal l'entit I-
CSCF partir du nom du domaine nominal.
L'acheminement des mthodes SIP mises par le terminal au S-CSCF dont le nom a
t obtenu dans la rponse la procdure d'enregistrement.
Le routage des mthodes SIP ou rponses SIP au terminal.
La gnration de CDRs (Call Detailed Record).
La compression / dcompression des messages SIP.
L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un rseau d'oprateur pour
toutes les sessions destines un utilisateur de cet oprateur. Il peut exister plusieurs I-CSCF
au sein d'un rseau.
Les fonctions ralises par l'entit I-CSCF comprennent :
L'assignation d'un S-CSCF un utilisateur s'enregistrant.
L'acheminement des mthodes SIP reues depuis un autre rseau, au S-CSCF.
L'obtention de l'adresse du S-CSCF auprs du HSS.
La gnration de CDRs.
Le Serving-CSCF (S-CSCF) prend en charge le contrle de la session. Il maintient un tat de
session afin de pouvoir invoquer des services. Dans un rseau d'oprateur, diffrents S-CSCF
peuvent prsenter des fonctionnalits diffrentes.
Les fonctions ralises par le S-CSCF pendant une session comprennent :
L'mulation de la fonction Registrar puisqu'il accepte les mthodes SIP
d'enregistrement et met jour le HSS.
L'mulation de la fonction Proxy server puisqu'il accepte les mthodes SIP et les
achemine.
L'mulation de la fonction User Agent puisqu'il peut terminer des mthodes SIP par
exemple lorsqu'il excute des services complmentaires.
L'interaction avec des serveurs d'application aprs avoir analys les critres de
dclenchement des services correspondants.
La gnration de CDRs.
16
Avant de pouvoir utiliser les services du domaine IM, tels qu'tablir une session multimdia
ou recevoir une demande de session, un usager doit s'enregistrer au rseau. Que l'usager soit
dans son rseau nominal ou dans un rseau visit, cette procdure fait intervenir un P-CSCF.
Par ailleurs, tous les messages de signalisation mis par le terminal ou destination du
terminal sont relays par le P-CSCF ; le terminal n'a jamais la connaissance des adresses des
autres CSCFs (idem I-CSCF et S-CSCF).
Figure I.8 : Entits de Rseau IMS
I.8.3.4 MGCF, IMS-MGW et T-SGW : Interfonctionnement avec le RTC
Le domaine IMS doit interfonctionner avec le RTCP afin de permettre aux utilisateurs IMS
d'tablir des appels avec le RTCP. L'architecture d'interfonctionnement prsente un plan de
contrle (signalisation) et un plan d'usager (transport). Dans le plan usager, des passerelles
(IMS-MGW, IMS - Media Gateway) sont requises afin de convertir des flux RTP en flux
TDM.
Ces passerelles ne traitent que le mdia. Des entits sont responsables de crer, maintenir et
librer des connexions dans ces passerelles; il s'agit de contrleurs de passerelles (MGCF,
Media Gateway Control Function). Par ailleurs, ce mme MGC termine la signalisation ISUP
du ct RTC qu'il convertit en signalisation SIP qui est dlivre au domaine IMS. Les
messages ISUP provenant du RTC sont d'abord achemins sur SS7 une passerelle de
signalisation (T-SGW, Trunking Signaling Gateway) qui les relaye au MGC sur un transport
SIGTRAN.
L'interfonctionnement entre le domaine IMS et le RTCP est donc assur par trois entits :
L'IMS-MGW (IP Multimedia Subsystem Media Gateway Function), MGCF (Media Gateway
Control Function) et T-SGW (Trunking Signaling Gateway Function).
I.8.3.4.1 L'IMS-MGW
Reoit un trafic de parole du RTCP et l'achemine sur un rseau IP. Le trafic audio est
transport sur RTP/UDP/IP.
17
Supporte gnralement des fonctions de conversion du mdia et de traitement du
mdia (annulation d'cho, pont de confrence).
Est contrl par le MGCF travers le protocole MEGACO/H.248.
I.8.3.4.2 Le MGCF
Comme les entits CSCF, n'appartient qu'au plan de contrle et non au plan mdia.
Contrle l'IMS-MGW afin d'tablir, maintenir et librer des connexions dans l'IMS-
MGW. Une connexion correspond par exemple une association entre une
terminaison TDM (terminaison du ct RTC) et une terminaison RTP/UDP/IP. Un
transcodage de la parole doit aussi avoir lieu au niveau de l'lMS-MGW pour convertir
la parole reue et qui est encode l'aide du codec G.711, en parole encode en
utilisant le codec AMR (UMTS) si le terminal IMS est un mobile UMTS.
Assure la conversion des messages ISUP (Signalisation RTC) en des messages SIP
Signalisation IMS).
Slectionne le CSCF appropri afin de remettre la signalisation SIP qu'il gnre, au
sous-systme IMS.
I.8.3.4.3 Le T-SGW
Assure la conversion du transport pour l'acheminement de la signalisation ISUP entre
le commutateur tlphonique et le MGCF. La signalisation ISUP est change :
Sur SS7 entre le commutateur et le T-SGW.
Sur SIGTRAN entre le T-SGW et le MGCF.
Par contre, n'analyse pas les messages d'application ISUP.
La figure I.9 reprsente un appel initi par le RTCP et destination d'un terminal dans le
sous- systme IMS.
Le commutateur du RTC rserve un circuit de parole qu'il partage avec l'IMS-MGW et met
un message ISUP IAM sur un transport SS7 au T-SGW (Trunking Signaling Gateway). Le
TSGW est responsable de la conversion du transport du message ISUP. Ce message est relay
l'entit MGCF sur SIGTRAN.
Le MGCF cre un contexte dans l'entit IMS-MGW en utilisant le protocole
MEGACO/H.248. Ce contexte consiste en une association entre une terminaison TDM et une
terminaison RTP. La terminaison TDM termine le circuit de parole que l'IMS-MGW partage
avec le commutateur tlphonique. La terminaison RTP termine les canaux RTP entre l'IMS-
MGW et le terminal IMS.
L'IMS-MGW retourne une rponse l'entit MGCF ; cette rponse contient un "local
descriptor" qui correspond la description SDP associe sa terminaison RTP.
18
L'entit MGCF gnre une mthode SIP INVITE contenant la description SDP retourne par
l'IMS-MGW. Cette mthode est envoye au sous-systme IMS qui se charge de la dlivrer au
terminal IMS appel.
Figure I.9 : Interfonctionnement entre RTC et IMS
I.9 Les services offerts par les NGN
Les NGN offrent les capacits, en termes dinfrastructure, de protocole et de gestion, de crer
et de dployer de nouveaux services multimdia sur des rseaux en mode paquet.
La grande diversit des services est due aux multiples possibilits offertes par les rseaux
NGN en termes de :
Support multimdia (donnes, texte, audio, visuel).
Mode de communication, Unicast (communication point point), Multicast
(Communication point-multipoint), Broadcast (diffusion).
Mobilit (services disponibles partout et tout le temps).
Portabilit sur les diffrents terminaux.
Parmi ces services offerts nous citons :
I.9.1 La voix sur IP
La voix sur IP est un service directement li lvolution vers les rseaux NGN. Cest une
application qui est apparue depuis longtemps mais qui na pas encore eu le succs escompt,
et cela pour diffrentes raisons :
La jeunesse des protocoles de signalisation (SIP, H.323, MEGACO) de voix sur IP et
la gestion de la qualit de service qui commence seulement maintenant tre mature
ne permettaient pas de dployer de services tlphoniques sur IP.
Le seul fait de transporter la voix sur IP napporte pas de valeur ajoute pour
lutilisateur final, par rapport au service de voix classique. Les services associs la
voix sur IP nont pas encore la maturit ncessaire pour pousser lvolution vers ces
nouveaux rseaux.
19
La ncessit dinterconnecter les rseaux IP aux rseaux TDM/SS7 implique des cots
lis aux quipements dinterconnexion (passerelles) et le prix des terminaux (IP
phones) annihile lavantage financier apport par le transport en IP.
Le cot des terminaux IP reste encore suprieur celui des quipements classiques
(pas encore dconomies dchelle suffisantes).
Cependant lvolution de la technologie et des protocoles et lapparition de services associs
au monde IP devraient permettre lmergence de la voix sur IP. De plus, lvolution des
terminaux communicants multimdia est un argument supplmentaire lvolution des
rseaux tlphoniques vers la voix sur IP ; ainsi lUMTS, dans la release 5, gnralise le
transport en IP au rseau voix.
I.9.2 La diffusion de contenus multimdia
La diffusion de contenu multimdia regroupe deux activits ; lune focalise sur la mise en
forme des contenus multimdia, lautre centre sur lagrgation de ces divers contenus via des
portails.
Les outils technologiques, tels que le multimdia streaming (gestion dun flux multimdia en
termes de bande passante et de synchronisation des donnes) et le protocole multicast, doivent
permettre de fournir un service de diffusion de contenu aux utilisateurs finaux.
I.9.3 La messagerie unifie
Le service de messagerie unifie est lun des services les plus avancs : cest le premier
exemple de convergence et daccs linformation partir des diffrents moyens daccs. Le
principe est de centraliser tous les types de messages, vocaux (tlphoniques), crits (email,
SMS), multimdia sur un serveur ; ce dernier ayant la charge de fournir un accs aux
messages adapt au type du terminal de lutilisateur. Ainsi un email peut tre traduit en
message vocal par une passerelle text-to-speech ou inversement un message vocal sera
traduit en mode texte.
I.9.4 Le stockage de donnes
Laugmentation de capacit des rseaux et la gestion des flux permettent de proposer des
services de stockage de donnes, en tant que sauvegarde de donnes critiques sur des sites
protgs, mais aussi en tant quaccs local un contenu (serveur proxy ou cache ).
En effet, les volumes de donnes voluant de faon exponentielle, la ncessit doffrir les
services partir des serveurs locaux semble indispensable. Cet aspect semble notamment
indispensable pour les applications de tlvision interactive et de video on demand.
I.9.5 La messagerie instantane
Cette application a dj un grand succs auprs des internautes : elle permet de dialoguer en
temps rel, plusieurs, sur un terminal IP (gnralement un PC) ayant accs Internet via une
20
interface texte. Cependant, il est ncessaire dinstaller sur son terminal un logiciel propritaire
permettant de se connecter un fournisseur daccs ; il nest alors possible de communiquer
quavec les utilisateurs souscrivant au mme service. Lvolution des rseaux devrait
permettre la standardisation de cette application et la communication entre tous (ouverture du
service) partir de nimporte quel terminal.
Cest lvolution du service SMS, par lapport de linteractivit et du multimdia (MMS).
I.9.6 Les services associs la golocalisation
La possibilit de localiser gographiquement les terminaux mobiles a t rapidement perue
comme une source de revenus supplmentaires. En effet, la golocalisation permet de
proposer aux utilisateurs finaux des services trs cibls haute valeur ajoute lis au contexte
(exemple : horaire, climat) et au lieu.
Actuellement plusieurs solutions techniques existent et sont mme en cours dimplmentation
dans les rseaux doprateurs mobiles. Cependant, si ces solutions offrent la capacit de
localiser les terminaux mobiles, il nexiste pas encore dinterfaces permettant lexploitation de
ces donnes par les applications de services, ou de relle volont des oprateurs douvrir leurs
serveurs de localisation des fournisseurs de services tiers, afin dutiliser cette fonction de
localisation comme service capability server (lment de base servant de support la
ralisation des services).
I.10 Conclusion
La connaissance des principes sur lesquels sont fonds les NGN, les types des rseaux NGN
existants ainsi que les diffrents services rellement pertinents dans ce cadre, sont des tapes
ncessaires pour pouvoir comprendre les stratgies d'volution des rseaux actuels fixes ou
mobiles vers une architecture multiservice.
L'objectif du chapitre suivant est justement la proposition de stratgies de migration des
rseaux actuels vers une architecture de type NGN en tenant compte des problmes lists dans
ce chapitre.
Stratgies de migration des rseaux actuels vers NGN
21
Chapitre II
Stratgies de migration des rseaux actuels
vers NGN

II.1 Introduction
Lvolution dun rseau existant vers la nouvelle structure ncessitera une stratgie de
migration progressive visant rduire au minimum les dpenses dinvestissement pendant la
phase de transition, tout en tirant parti trs tt des avantages quelle prsente. Toute dmarche
entreprise lors de cette tape de transition devra simplifier lvolution du rseau vers
larchitecture NGN commutation de paquets. Pendant plusieurs annes encore, les services
de commutation traditionnels vont devoir coexister avec des lments de rseau mettant en
oeuvre de nouvelles technologies.
La premire partie de ce chapitre est consacre la migration des rseaux fixes vers une
architecture NGN. Dans la deuxime partie, nous proposons diffrentes solutions de migration
des rseaux mobiles vers une architecture NGN Multimdia (IMS) avec une tude des
volutions majeures au sein du coeur du rseau UMTS.
II.2 Migration des rseaux fixes vers NGN
Dans cette partie, nous proposons un ensemble de solutions correspondant au besoin de
nimporte quel type doprateurs de rseau voulant voluer son rseau tlphonique
commutation de circuits vers une architecture NGN commutation de paquets.
La mise en place darchitectures NGN peut se faire avec une plus ou moins grande ampleur,
selon que lutilisation des technologies NGN sapproche ou non au plus prs de lutilisateur
final. Le choix de dploiement retenir conditionne en grande partie les bnfices attendre
de la mise en place dun rseau NGN du point de vue de lconomie de cot. Quatre grands
scnarios peuvent ainsi tre dgags [5] :
Scnario 1 : Mise en place de solutions NGN en transit.
Scnario 2 : Mise en place de solutions NGN jusquau commutateur de classe 4.
Scnario 3 : Mise en place de solutions NGN jusquau classe 5.
Scnario 4 : Mise en place de solutions tout IP en overlay.
22
Dans ce qui suit, nous utiliserons la terminologie suivante (figure II.1) :
Commutateur de classe 5 pour les commutateurs locaux.
Commutateurs de classe 4 pour les commutateurs autonomie dacheminement
(CAA).
Commutateurs de classe 3 pour tous les commutateurs situs dans les zones de transit
(rgional, national ou international).
Figure II.1 : Hirarchie des commutateurs du rseau RTC
II.2.1 Scnario 1 : Mise en place de solutions NGN au niveau de transit
II.2.1.1 Dfinition
Dans ce scnario, loprateur utilise des technologies NGN pour son coeur de rseau, mais
ds que lon sapproche des commutateurs de classe 4, le trafic continue tre support par le
rseau traditionnel. Cette dmarche est mise en place par un grand nombre doprateurs
mondiaux, prcisment sur ces fonctions de transit que ce soit au niveau rgional, national ou
international. Il sagit de la premire tape de la migration dun rseau traditionnel vers un
rseau NGN pour nombre dentre eux. Le principal bnfice pour un oprateur est la
rduction de cot sur les communications internationales et nationales.
A linternational, pour un oprateur tranger, limplmentation dune solution NGN au
niveau transit permet dutiliser un lien IP afin de transporter des communications
vocales plutt que davoir recours la location dune liaison loue auprs de
loprateur historique local.
23
Au niveau national, un oprateur pourra rduire galement ses cots sil loue ses liens,
en particulier car il aura besoin de moins de lien physiques du fait de labsence de
ncessit dun rseau maill.
II.2.1.2 Impacts sur larchitecture du rseau
Ce type de solution impacte le trafic entre les commutateurs de transit au niveau national ou
international. Concrtement, il sagit dinstaller des passerelles media (Media Gateway)
assurant linterface entre le rseau IP de transport des donnes avec le rseau tlphonique
TDM traditionnel. Les passerelles sont alors administres distance par un softswitch dans le
cadre dune architecture centralise en utilisant en gnral les protocoles de signalisation
MGCP/H.248.
II.2.1.2.1 Exemple 1 : Migration du trafic tlphonique international sur IP
Pour un oprateur souhaitant dployer une solution VoIP pour son trafic international il suffit
dimplmenter (voir figure II.2) :
Un softswitch qui centralisera le contrle 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 Prsence) situs dans les pays o
loprateur veut sinterconnecter au rseau national TDM.

Figure II.2 : Architecture dune solution NGN pour le trafic de transit international
24
II.2.1.2.2 Exemple 2 : Migration du trafic de transit au niveau national
Au niveau national, lapproche est similaire sauf que ce sont les commutateurs de classe 3 et
de niveau hirarchiques suprieurs qui seront remplacs par un ou plusieurs softswitch et
passerelles media. Evidemment les commutateurs TDM de classe 4 et 5 sont conservs et
assurent la livraison des communications tlphoniques TDM de manire tout fait classique
aux abonns.
Figure II.3 : Architecture dune solution NGN pour le trafic de transit national
II.2.2 Scnario 2 : Mise en place de solutions NGN jusquau commutateur
de classe 4
II.2.2.1 Dfinition
Loprateur choisit de mettre en place une architecture NGN qui a vocation galement
agrger le trafic local, et conserve son rseau daccs traditionnel. Ce scnario constitue une
prolongation naturelle du premier.
Le trafic entre commutateurs d'abonns TDM traditionnels est en fait dtourn sur une
infrastructure VoIP. Pour cela, loprateur connecte ses commutateurs d'abonns des
gateways VoIP et des softswitchs de classe 4. Dun point de vue architectural, il sagit de la
mme solution que pour le scnario prcdent un niveau diffrent du rseau plus proche de
labonn. En effet un commutateur de classe 4 ne diffre dun commutateur de classe 3 ou de
niveau hirarchique suprieur uniquement par sa capacit de traitement de donnes. Il
nintgre aucune intelligence rseau. Du coup, pour le rseau NGN, la diffrence se traduira
uniquement par la nature des capacits supportes par les media gateways et softswitchs.
25
Figure II.4 : Architecture dune solution NGN de classe 4
Cette tape permet en fait de fusionner les infrastructures longue distance voix et donnes sur
une mme pine dorsale IP. Ultrieurement, l'oprateur peut remplacer ses commutateurs
locaux d'abonns TDM par des softswitchs de classe 5. Deux oprateurs peuvent interoprer
leur rseau NGN de classe 4 en sinterconnectant au niveau dun softswitch pour lchange de
signalisation relative lacheminement du trafic. Le trafic transite alors par un lien IP (non
reprsent sur la figure) entre les deux infrastructures de coeur de rseau IP. A court terme,
cette dmarche permet galement de conserver des class 5 traditionnels qui disposent de
certaines capacits quil est difficile de rendre avec des solutions logicielles (prise de ligne au
dcrochage par exemple).
II.2.3 Scnario 3 : Mise en place de solutions NGN jusquau classe 5
II.2.3.1 Dfinition
Les commutateurs de classe 5 constituent le point de raccordement avec labonn pour la
fourniture des services voix basiques. Les oprateurs historiques possdent plusieurs milliers
de ces commutateurs et de part leur position stratgique dans leur rseau ont t peu enclins
jusqu prsent les remplacer par une solution NGN. Toutefois, compte tenu de la forte
progression de la pntration des services haut dbit et du dclin de la demande en services de
tlphonie traditionnelle, les oprateurs considrent de plus en plus lopportunit de faire
converger leur infrastructure daccs vers une plate-forme IP commune.
Dans le cadre dune migration de classe 5, loprateur ralise une migration complte, et tout
le trafic transitant dans le rseau sera support par une architecture NGN. Cette approche
permet la fourniture de bout en bout de services VoIP condition que lutilisateur final utilise
un quipement IP. De loin la plus complexe, cette tape est aujourdhui assez peu rpandue.
26
L'oprateur remplace ses commutateurs locaux TDM par des softswitchs de classe 5. A la
diffrence des solutions de classe 4, les serveurs dappels de classe 5 peuvent supporter tous
les types de services proposs par les commutateurs traditionnels locaux et servir tous les
types de terminaux raccords au rseau IP, directement ou par lintermdiaire de MSAN (
MultiService Access Node ).
Le commutateur de classe 5 commute le trafic localement et le transfre vers le rseau de
transit sil nest pas en mesure de se connecter directement au commutateur de classe 5 du
destinataire de lappel. Comme les fonctions logiques de concentrateur et de commutateur
local sont souvent intgres au sein dun unique quipement, traditionnellement ils sont
fournis par le mme quipementier et la signalisation entre ces lments est souvent
propritaire. Cest une manire de garder un client captif pour un vendeur si bien que les
interfaces standardises (V5.1 et V5.2) sont rarement disponibles sur les commutateurs
actuellement en service dans les rseaux RTC des oprateurs historiques.
Du coup, le passage un rseau NGN en classe 5 savre plus compliqu car faire migrer les
commutateurs locaux revient galement faire voluer les concentrateurs qui leur sont
rattachs. En outre, au-del du service vocal basique, un rseau RTC fournit de nombreux
services valeur ajoute, comme par exemple :
Identification du numro de lappelant.
Messagerie vocale.
Appel en attente.
Interception dappel.
Horloge parlante.
La fourniture de ces services est assure par les commutateurs TDM de classe 5 auxquels le
rseau IN sinterconnecte. Par consquent, la suppression dun commutateur de classe 5
rompt le lien avec le rseau intelligent existant. Limplmentation du softswitch doit prendre
ces lments en compte et garantir la continuit de services pour labonn soit en re-crant le
lien IN soit en implmentant les mmes services sur une nouvelle plate-forme IN. Dans la
perspective stratgique de loprateur visant utiliser une solution NGN comme support de
nouveaux services, la deuxime solution sera privilgie mais ncessitera des investissements
additionnels. Il en va de mme au niveau du systme de facturation galement raccord au
commutateur de classe 5. Limplmentation dun nouveau systme de facturation pour la
solution NGN nest en soit pas trs onreuse mais sassurer de sa bonne intgration avec les
systmes de facturation existants est autrement plus complique.
En conclusion, une migration de classe 5 savre tre un vritable big bang au niveau du
rseau de loprateur et cela est dautant plus coteux et complexe que le rseau est important.
27
II.2.3.3 Raccordement de labonn
Dans le cadre dune migration NGN de classe 5, le raccordement des abonns se fait avec un
lien IP. Possdant rarement des infrastructures TDM, les oprateurs alternatifs fournissent des
services VoIP bass sur les technologies daccs haut dbits DSL ou FTTH et les administrent
via le dploiement de softswitchs assumant les fonctionnalits de commutateurs de classe 4 et
5.
Les oprateurs historiques, eux, doivent aussi garantir la continuit de leurs services TDM
actuels. Certains oprateurs ont ainsi choisi de conserver leurs commutateurs TDM et de les
quiper de nouvelles cartes afin de faire migrer graduellement le rseau traditionnel vers une
architecture NGN de classe 5 tandis que loprateur dploiera directement de nouveaux
softswitchs pour supporter de nouveaux services bass sur des technologies haut dbit. On
voit apparatre une nouvelle gnration dquipements daccs haut dbit baptiss IMAP
(Integrated Multiservice Access Platforms) ou MSAN (Multiservice Access Node) qui savent
grer aussi bien des lignes haut dbit que des accs RNIS ou analogiques. Ces quipements se
connectent au rseau IP de l'oprateur et offrent le service tlphonique sous le contrle du
softswitch de classe 5. Ils permettent aux oprateurs historiques de continuer fournir des
services traditionnels, et de continuer remplir leurs obligations rglementaires, tout en tirant
parti des solutions de softswitch IP.
Figure II.5 : Architecture dun rseau NGN de classe 5
II.2.4 Scnario 4 : Mise en place de solutions tout IP en overlay
Dans ce cas, loprateur dploie une architecture entirement base sur IP, qui na pas besoin
de se connecter au rseau de commutation existant, ceci en parallle du rseau traditionnel,
qui continue vivre sa vie indpendamment. Ce type de solution est particulirement adapt
aux oprateurs historiques qui sont confronts une forte chute des revenus de tlphonie
classique et qui, pour protger leur base de clientle, doivent lancer des solutions innovantes
bass sur des technologies alternatives (DSL, FTTH, cble, ).
Ce type dapproche est bien videmment plus rpandue auprs doprateurs alternatifs, qui
dans la plupart des cas nont pas de rseau traditionnel administrer.
28
Le rseau paquet en overlay fournit les services valeur ajoute tandis que le rseau TDM
traditionnel continue dassurer le support des services tlphoniques de base. Les deux
rseaux sinterconnectent via le dploiement de passerelles (les media gateways dans la figure
ci-dessous) afin de garantir une terminaison dappel sur un tlphone classique alors que
lappelant utilise un tlphone IP et inversement. Les rseaux VoIP et PSTN restent
clairement spars, au niveau du transport du trafic et de la signalisation.
Figure II.6 : Architecture overlay VoIP
II.2.4.2 Les diffrentes phases de la stratgie de migration overlay
La stratgie overlay est intimement lie la stratgie de dploiement du rseau daccs haut
dbit de loprateur. En effet, de la vitesse de dploiement du rseau DSL et du rythme des
abonnements haut dbit dpendent la date de migration complte des abonns RTC vers le
rseau NGN.
Il ny a pas de migration active des abonns RTC existants court terme. Toutefois, plus
long terme, quand le rseau RTC deviendra trop coteux entretenir, la migration pourra tre
acclre afin de procder la fermeture complte du rseau RTC. Des initiatives
commerciales pourront tre mises en place cet effet par loprateur. Malgr tout, mme si
les abonns de la nouvelle plate-forme vont essentiellement utiliser des services VoIP, il nen
demeure pas moins que certains dentre eux voudront conserver un accs un service RTC et
continuer utiliser leur tlphone traditionnel. En consquence, des interfaces RTC devront
tre conserves sur les passerelles rsidentielles.
Ci-aprs est prsente la stratgie typique de migration, avec mise en place dun rseau IP,
envisage par les grands oprateurs (Figure II.7) :
Phase 1 : Le DSL tel quil est dploy aujourdhui permet de supporter sur une mme
ligne des services vocaux RTC classiques et des services de donnes en haut dbit sur
29
une mme paire de cuivre grce lusage de filtres. La carte de la ligne dabonn est
localise dans le concentrateur local.
Phase 2 : Le DSLAM est remplac par un MSAN (Multi-Service Access Nodes)
supportant la fois les technologies TDM et ATM/IP. Les cartes RTC et DSL sont
maintenant localises dans le MSAN et la signalisation seffectue entre le MSAN et le
commutateur RTC de classe 5 via les interfaces V5.1 ou V5.2. Les nouveaux abonns
DSL devraient tre raccords cette nouvelle plate-forme pour les services vocaux et
donnes.
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
dsormais ncessaire puisque le commutateur de classe 5 nest plus reli directement
au MSAN. Une passerelle media doit aussi tre ajoute au rseau afin dassurer la
connexion entre le rseau RTC existant et la plate-forme IP pour supporter les appels
IP vers RTC. Les abonns existants et les nouveaux abonns migrent automatiquement
vers la VoIP, mme si le service quils reoivent est toujours de type RTC.
Phase 4 : Une fois que la migration a attir suffisamment dutilisateurs et que
loprateur est prt, le reste des abonns RTC peut tre transfr sur la nouvelle plate-
forme IP et le rseau RTC peut alors tre dfinitivement abondonn.
Figure II.7 : Les diffrentes phases de la stratgie de migration overlay
II.3 Migration des rseaux mobiles vers lIMS
Les rseaux mobiles sont confronts aux contraintes de flexibilit de gestion, douverture de
services mais aussi de dploiements dquipements. En outre, ce sont les mme besoins que
les rseaux fixes qui ont gnrs ce besoin de convergence; savoir : une volution
technologique denvergure et une demande pour un rseau de services universel.
30
Lvolution des rseaux mobiles vers une architecture multiservice a suivie une tendance plus
rgulire aussi bien au niveau technologique que sur le plan de la normalisation. En effet,
partant du rseau GSM pour le transport de la voix et qui est bas sur la commutation de
circuits, le besoin de convergence voix/donnes a donn naissance au GPRS. Ce fut une
volution majeure du GSM par lutilisation de la commutation de paquets et laugmentation
des dbits, la gnration 2.5, le GPRS, a ouvert la porte aux applications multimdia et
implicitement une transition vers les rseaux de troisime gnration : lUMTS est n. Ce
dernier est le premier systme qui inclut dans ses spcifications une volution vers
larchitecture du futur : le NGN.
Dans cette partie, nous allons prsenter les volutions majeures au sein du coeur du rseau
UMTS.
II.3.1 UMTS release 99 : lhritage du GSM/GPRS
Larchitecture UMTS telle que dcrite dans la release 99 du 3GPP sappuie sur une nouvelle
interface radio, lUTRA, et une volution des coeurs de rseau GSM et GPRS (adaptation des
quipements existants ou nouveaux quipements) pour grer les flux des domaines circuit et
paquet.
Dans larchitecture UMTS R99 :
Les interfaces de lUTRA avec le coeur de rseau sont bases sur un transport ATM
(AAL2 pour la voix, AAL5 pour les donnes).
Le transport dans le coeur de rseau peut ensuite tre effectu (au choix de
loprateur) soit en ATM pour lensemble des flux, soit en ATM puis TDM pour les
flux circuit et en IP pour les flux paquet. La signalisation linterface avec lUTRA
est transporte soit dans des circuits virtuels ATM, soit avec le protocole de transport
de SS7 sur IP SIGTRAN.
Les appels multimdia sont supports, mais de manire transparente. En effet, les
messages de signalisation multimdia sont transports de manire transparente dans
une connexion circuit ou dans un contexte PDP (tunnel GTP entre SGSN et GGSN),
ce qui vite dintroduire des fonctions multimdia dans les quipements GSM et
GPRS, limitant les impacts aux terminaux et lajout de serveurs multimdia
(gatekeepers). Les protocoles de contrle dappel multimdia retenus sont H.323 pour
le domaine paquet et H.324-M pour le domaine circuit, choix plus conforme la
maturit actuelle des protocoles (par rapport SIP). Cependant, le transport de la
signalisation multimdia tant transparent, SIP pourrait a priori tre support de la
mme manire.
La R99 prpare donc lvolution vers la solution cible tout IP en introduisant ds les dbuts de
lUMTS un transport convergent des flux voix et donnes. Les versions ultrieures de la
31
norme UMTS intgrent une volution encore plus nette vers une architecture de type NGN.
La release R4 (ex-R99) est la premire tape vers un coeur de rseau tout IP, et la release R5
finalise cette volution.
II.3.2 UMTS releases R4/R5 : lvolution vers le tout IP multimdia
Alors que la release 99 UMTS a principalement pour vocation de grer une transition douce
avec le GSM/GPRS, la release 4 (anciennement dnomme release 2000) de lUMTS propose
une architecture rsolument novatrice afin dvoluer vers le tout IP multimdia.
Suite aux discussions techniques au sein du 3GPP et afin de prendre en compte la maturit des
produits et solutions nouvelles, les volutions de lUMTS prvues dans cette version ont t
chelonnes dans le temps et rparties sur deux versions successives, rebaptises R4 et R5. [6]
II.3.2.1 UMTS Release R4 : sparation des couches transport et contrle
Conformment lun des concepts de base des NGN, la version R4 de la norme UMTS
prvoit une volution optionnelle du domaine circuit, sous la forme dune restructuration
fonctionnelle des MSC pour introduire une sparation des couches transport (Media Gateway)
et contrle dappel (MSC server).
Le MSC server a les mmes caractristiques quun MGC (Media Gateway Controller),
avec en complment des fonctions spcifiques mobile. 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 avec les HLR.
La signalisation de commande entre MSC server et MGW utilise le protocole H.248
avec des extensions spcifies par le 3GPP.
Cette signalisation peut tre transporte en utilisant le protocole MTP3b si le transport
sappuie sur une couche ATM, ou SIGTRAN (SCTP) si le transport sappuie sur IP.
Figure II.8 : Architecture domaine circuit UMTS release R4
II.3.2.2 UMTS Release R5 : ajout du domaine IP multimdia
La release R5 introduit un nouveau domaine, lIP Multimdia (IM) Subsystem, sappuyant sur
les services du domaine paquet pour fournir des services de communications convergents
(voix sur IP, donnes, multimdia) en IP natif. Ainsi, les communications multimdia ne
32
sont plus supportes de manire transparente mais deviennent le mode de communication
cible de lUMTS. Ce nest que pour des raisons de compatibilit avec les rseaux GSM/GPRS
et UMTS R99 et avec les terminaux non IP multimdia que le domaine circuit (MSC servers
et MGW associes) est maintenu.
Le coeur de rseau UMTS IP multimdia utilise le protocole SIP pour grer les sessions IP
multimdia, et le protocole IP pour le transport du trafic et de la signalisation associs. Il
supporte linterfonctionnement avec les rseaux voix et donnes IP fixes et mobile existants, y
compris Internet.
Le choix du protocole de contrle dappel pour les appels VoIP et multimdia a fait lobjet de
longues discussions, mais SIP a fini par simposer au 3GPP grce son caractre IP natif et
son apparente simplicit compar H.323. Le protocole SIP de lIETF doit cependant tre
enrichi pour prendre en compte certaines volutions spcifies par le 3GPP pour un usage
dans le coeur de rseau UMTS, notamment concernant les spcificits lies la gestion de la
mobilit.
Figure II.9 : Architecture de rfrence Release 5
Pour assurer le contrle dappel et la gestion de la signalisation dans ce nouveau domaine, de
nouvelles entits sont ajoutes, ou des quipements existants sont modifis. Le tableau II.1 en
fait une synthse, ainsi quune correspondance avec les fonctions NGN prsentes dans le
rapport.
En terme de gestion de la mobilit, le HSS UMTS est charg de la mise jour du profil
utilisateur, et peut intgrer ou cooprer avec des entits standards dans le monde IP, comme
un serveur distant dauthentification et dautorisation (RADIUS) ou un serveur grant la
rsolution dadresse et lallocation dynamique dadresse IP (fonctions DNS et DHCP).
33
Avec la R5 UMTS, le transport IP se gnralise progressivement lensemble du rseau, et
IPv6 est introduit dans le coeur de rseau :
Il est noter que les interfaces de transport en sortie de lUTRA, qui taient de type
ATM en R99, voluent en IP en R5 (lvolution du transport en IP au sein de lUTRA
et sur la voie radio tant prvue pour des tapes ultrieures de la norme).
Le protocole de transport spcifi pour le domaine paquet est IP (entre RNC, SGSN et
GGSN), avec support des options IPv4 et IPv6.
Au sein du domaine IP Multimdia (lments IP multimdia du coeur de rseau +
quipements terminaux associs), la norme spcifie lutilisation exclusive dIPv6, et
un usage optimal dIPv6 doit tre fait.
Interoprabilit IPv4/IPv6 : les quipements terminaux IP multimdia doivent pouvoir
accder des applications IPv4 et IPv6, et le coeur de rseau doit assurer si ncessaire
linteroprabilit entre son transport IPv6 et un rseau IPv4 externe.
Fonction UMTS Rle
Correspondance architecture
NGN
CSCF (Call State
Control Server)
Contrle dappel multimdia
Dialogue avec le MGCF avec le
protocole SIP-T
Serveur SIP volu (ajout
fonctions spcifies par le
3GPP)
MGCF (Media
Gateway Controller
Function)
Contrle de la ou des Media
Gateways qui lui sont rattaches,
avec le protocole H.248 (+
extensions 3GPP)
Media Gateway Controller
(Cf. IEFT, groupe Megaco)
T-SGW (Transport
Signalling Gateway)
Gestion de linterfonctionnement
de la signalisation avec le rseau
commut fixe (adaptation des
couches basses)
Signalling Gateway
R-SGW (Roaming
Signalling Gateway)
Gestion de linterfonctionnement
de litinrance entre le rseau
UMTS R4/R5 et les rseaux UMTS
R99, GSM et GPRS, avec
adaptation des couches basses de
signalisation
Signalling Gateway
Spcifique mobile
MRF (Multimedia
Ressource Function)
Gestion des appels multimdia
multiparties et de confrence
Fonction MCU dans H.323
(fonction MCU ou
utilisation du multicast dans
SIP)
HSS (Home
Subscriber Server)
Evolution du HLR pour incorporer
la gestion du profil de services IP
multimdia de lutilisateur
(fonction serveur UMS-User
Mobility Server)
Fonction SIP register
Tableau II.1 : Architecture de rseau UMTS R5
34
II.3.3 Influence de lUMTS sur la stabilisation du concept NGN
LUMTS aura un rle potentiel fort sur lmergence et la stabilisation du concept NGN.
LUMTS est le premier systme global qui intgre dans ses spcifications futures (releases
R4/R5) des options dvolution vers une architecture rellement NGN.
Les protocoles choisis terme par le 3GPP sont :
SIP pour le contrle dappel.
MEGACO/H.248 pour le contrle des Media Gateways.
SIGTRAN pour le transport de la signalisation SS7 sur IP.
Pour la signalisation entre Media Gateway Controllers, le choix reste ouvert, mais le
protocole BICC est cit nommment et semble mis en avant.
Si lUMTS rencontre un dveloppement et un succs important, et si les rseaux UMTS
migrent rapidement vers une architecture conforme aux spcifications des versions R4/R5, les
choix technologiques effectus par le 3GPP ne manqueront pas dinfluer sur le choix global
des protocoles dans un rseau NGN, tous domaines confondus, fixe et mobile. Cela semble
particulirement vrai pour les protocoles SIP et IPv6.
II.4 Conclusion
Les rseaux mobiles semblent prendre en compte l'volution vers les NGN de manire plus
explicite en termes de normalisation (la normalisation du systme UMTS), la maturit des
offres de produits fait que les premiers dploiements NGN s'effectuent plutt dans le domaine
des rseaux et services fixes.
Dans ce chapitre, nous nous sommes efforcs de proposer des solutions adaptables a tout
oprateur fixe ou mobile dsirant migrer son rseau vers NGN; ce dernier devra donc
dimensionner son rseau NGN en fonction de ses prvisions en trafic aussi bien voix et
donnes que multimdia. Le chapitre suivant dcrit cet effet, le processus de
dimensionnement dans un rseau NGN.

Processus de dimensionnement dun rseau NGN
35
Chapitre III
Processus de dimensionnement dun rseau
NGN

III.1 Introduction
Ltape de dimensionnement des quipements et interfaces dun rseau de communication est
trs importante. Elle permet de dterminer le volume des quipements, logiciels et autres
moyens (capacits de transmission) acqurir et dployer pour la fourniture des services
de tlcommunications. Le concepteur de rseau ou lingnieur en tltrafic qui souhaite
dimensionner un rseau commutation de paquets ou commutation de circuits sintresse
principalement aux paramtres suivants : dbit utile du rseau, charge des diffrents lments
du rseau, dlais de transit des informations dans le rseau et probabilit de perte dune partie
ou de toute linformation. [7]
Dans notre prsent projet, nous traitons une nouvelle architecture de rseau savoir le NGN
qui est caractris entre autre par lmergence de nouveaux quipements et logiciels offrant de
nouvelles fonctionnalits. Alors nous avons dcid de nous intresser uniquement au
dimensionnement du Hardware de cette architecture.
Lobjectif de ce chapitre est dintroduire les outils de base permettant le dimensionnement des
principaux quipements et interfaces dun rseau NGN. Ce chapitre traite tout dabord le cas
du dimensionnement dans un rseau NGN Tlphonie. La seconde partie sera consacre au
dimensionnement dans un rseau NGN Multimdia (IMS) o nous avons pris le cas de
larchitecture du rseau UMTS selon le concept IMS.
III.2 Dimensionnement dans le NGN Tlphonie
Comme nous lavons mentionn dans le premier chapitre, le NGN Tlphonie est une
architecture de rseau offrant uniquement des services de tlphonie des usagers disposant
dun accs en mode circuit (Commutateur daccs tlphonique, accs mobile GSM,
PABX). Dans notre cas, nous allons nous contenter des rseaux daccs suivants :
RTC/RNIS et GSM/GPRS.
III.2.1 Architecture cible du NGN Tlphonie
Dans notre processus de dimensionnement, le rseau NGN Tlphonie considr est
reprsent schmatiquement par la figure I.4 dans le premier chapitre. Cest un rseau dorsal
36
IP qui relie diffrents rseaux daccs : dune part RTC/RNIS et dautre part GSM/GPRS par
le biais de Media Gateways. Un Softswitch situ au niveau de la couche contrle qui gre le
contrle des appels ainsi que laccs aux services au niveau de la couche application.
III.2.2 Scnario de migration retenu
Nous avons bien dcrit dans le chapitre prcdent les diffrents scnarios de migration des
rseaux traditionnels de tlphonie fixe et mobile vers une architecture NGN que nous
rappelons brivement :
Scnario 1 : Mise en place de solutions NGN en transit.
Scnario 2 : Mise en place de solutions NGN jusquau commutateur de classe 4.
Scnario 3 : Mise en place de solutions NGN jusquau classe 5.
Scnario 4 : Mise en place de solutions tout IP en overlay.
Dans ce qui suit, nous avons opt pour le premier scnario de migration qui est la mise en
place de solutions NGN au niveau des liens de transit car il permet loprateur dacheminer
les communications internationales et nationales au niveau des commutateurs de transit et par
la suite une rduction de cot sur ces communications.
La figure III.1 illustre larchitecture gnrale dune solution NGN au niveau des
commutateurs de transit national ct RTC/RNIS ainsi quau niveau des commutateurs du
service mobile (MSC) ct GSM/GPRS.
Figure III.1 : Mise en place de scnario de migration retenu
III.2.3 Modle de trafic du rseau daccs
La spcification de la charge dun rseau suppose une connaissance pralable des
caractristiques des services du point de vue trafic. Un modle de trafic est un objet
mathmatique ou algorithmique qui prsente des caractristiques souvent statistiques,
37
similaires au trafic rel. Il sert mieux connatre et dcrire le trafic vhicul et permet de
dimensionner les files dattentes dans les rseaux.
Le processus de Poisson modlise bien le trafic transactionnel ou encore le trafic dappel
tlphonique qui arrive sur un commutateur de circuit. Il est donc la base de la plupart des
lois de tltrafic utilises en tlcommunications et les lois dErlang en particulier. [7]
III.2.4 Mthodologie de dimensionnement
III.2.4.1 Organigrammes de dimensionnement du rseau NGN Tlphonie
Les organigrammes suivants dcrivent les diffrentes tapes suivre afin de dterminer les
besoins matriels pour lcoulement du trafic des rseaux daccs RTC/RNIS et GSM/GPRS.
Etape 1 : Calcul de trafic du rseau daccs RTC/RNIS
Organigramme III.1 : Organigramme de calcul du trafic RTC/RNIS

Etape 2 : Calcul de trafic du rseau daccs GSM/GPRS
Organigramme III.2 : Organigramme de calcul du trafic GSM/GPRS
38
Etape 3 : Dimensionnement des entits du rseau NGN Tlphonie
Organigramme III.3 : Organigramme de dimensionnement des entits
Etape 4 : Optimisation du rseau de transport
Organigramme III.4 : Organigramme doptimisation du rseau de transport
III.2.4.2 Calcul du trafic gnr par les rseaux daccs
Pour pouvoir calculer le trafic total gnr par les rseaux daccs RTC/RNIS et GSM/GPRS,
nous devons rassembler dabord les donnes doprateur suivantes :
La dure moyenne des communications (DMC) en secondes pour tous les types de
trafic (conversationnel, interactif ou streaming).
Le nombre de tentatives dappels lheure charge (TAHC) par heure par service
(conversationnel, interactif ou streaming).
Le grade de service (Grade of Service : GoS) souhait au niveau de linterface
commutateur de transit-Media Gateway (CT-MG) ou MSC-Media Gateway (MSC-
MG). En effet, les diffrents rseaux daccs connects au rseau de transport offrent
39
dj un certain GoS fix par loprateur en dimensionnant ce rseau; donc il faut viter
un goulot dtranglement au niveau des commutateurs de transit (CT) ou MSC
concentrant le plus de trafic car ce sont ces derniers qui seront connects la MG.
Premire tape : Dtermination du trafic engendr par un CT (respectivement un
MSC)
Le comportement global des usagers est exprim par le nombre de tentatives dappels
lheure charge (TAHC) par heure et par la dure moyenne des communications (DMC) en
secondes. [8]
Soit
3600
i i
i
DMC TAHC
1

= (III.1)
le trafic de type i (conversationnel, interactif ou streaming) engendr par un CT du rseau
RTC/RNIS.
Le trafic total issu de chaque CT sera lagrgation de ces trois types de trafic.
Lunit de trafic conversationnel tant lErlang alors que pour celui interactif ou streaming est
le Kbits. Afin de pouvoir effectuer cette sommation, il faut que nous convertissions ce trafic
conversationnel en Kbits. Pour ce faire, nous calculons tout dabord le nombre de circuits
pouvant supporter ce type de trafic laide de la formule de Rigault [8] :
conv conv
k N o o + = (III.2)
Avec ) ( log
/ 10 / RNIS RTC RNIS RTC
GoS k = (III.3)
Ensuite nous dterminons en premier lieu le nombre de liens E0 ncessaire pour couler
conv
o , puis le nombre de liens E1 sachant que 1E1=32E0=32*64 Kbits=2048 Kbits. La
conversion de
conv
o de lErlang en Kbits est donne par lquation (III.4) :
( ) ( ) Kbits N N Kbits A
conv
4096 2048
32
64
= = (III.4)
Donc le trafic total en Kbits gnr par un CT est donn par :
stream er conv
A CT total Trafic o o + + =
int
_ _ (III.5)
Le mme calcul suivre dans le cas dun MSC.
Deuxime tape : Calcul du trafic total gnr par le rseau daccs RTC/RNIS :
Le trafic total gnr par le rseau daccs RTC/RNIS sera la somme de tous les trafics
engendrs par chaque CT :
CT total Trafic (Kbits) RTC/RNIS r_rseau Trafic_gn
CT
_ _
= (III.6)
Troisime tape : Calcul du trafic total gnr par le rseau daccs GSM/GPRS :
De mme, nous calculons le volume de trafic gnr par le rseau daccs GSM/GPRS en
suivant la dmarche prcdente sauf que nous remplaons cette fois les CT par les MSC :
40
MSC total Trafic s) GPRS (Kbit GSM r_rseau Trafic_gn
MSC
_ _ /

= (III.7)
Quatrime tape : Calcul du trafic total gnr par les rseaux daccs RTC/RNIS et
GSM/GPRS :
Nous pouvons maintenant dduire le trafic total gnr par les rseaux daccs RTC/RNIS et
GSM/GPRS qui sera donn par lquation (III.8) :
(Kbits) RTC/RNIS r_rseau Trafic_gn al (Kbits) Trafic_tot =
Kbits) GSM/GPRS ( r_rseau Trafic_gn + (III.8)
III.2.4.3 Calcul du nombre de liens CT-MG et MSC-MG
Dans notre logique de conception, nous ne pouvons tolrer de pertes avant larrive du trafic
dans le rseau de transport ; ce qui revient une fourniture de capacit entre le MSC ou le
commutateur du fixe et la MG ; ce qui nous amne donc dimensionner les liens entre ces
entits. Le nombre de liens en E1 ncessaires pour couler le trafic prvu est dtermin par :
2048
MG - CT
al_CT Trafic_tot
N = (III.9)
Dans le cas du rseau daccs GSM/GPRS, le nombre de liens MSC-MG en E1 est calcul
comme suit:
2048
MG - MSC
al_MSC Trafic_tot
N = (III.10)
III.2.4.4 Dimensionnement des Media Gateways
Le dimensionnement des Media Gateways consiste dterminer le nombre des MGs
ncessaires pour supporter le trafic total gnr par les rseaux daccs RTC/RNIS et
GSM/GPRS. Le nombre des MGs ncessaires pour vhiculer ce trafic est donn par :
G Capacit_M
al (Kbits) Trafic_tot
Nombre_MG = (III.11)
Dans cette tape de dimensionnement, nous allons nous limiter au calcul de la charge des
Media Gateways car nous ne savons pas leur capacit qui est un paramtre laiss au choix de
loprateur.
La charge des MG est calcule comme suit :
al (Kbits) Trafic_tot s) e_MG (Kbit Ch = arg (III.12)
III.2.4.5 Dimensionnement des softswitchs
Dimensionner cet quipement, qui reprsente la couche contrle, revient dterminer la
capacit de traitement de son processeur en terme de nombre total de tentatives dappels
lheure charge (TAHC) quil pourra vhiculer :

+ =
MSC i
i
CT i
i
TAHC TAHC C) ch (en TAH e_Softswit Charg (III.13)
41
III.2.4.6 Optimisation du rseau de transport
Nous nous intressons dans cette partie loptimisation du rseau de transport en mode
paquet. En effet, le dploiement de services tlphoniques et loffre de services interactifs en
temps rel de bout en bout dans un rseau commutation de paquets IP, amnent
sinterroger sur la possibilit de pouvoir offrir la mme qualit de service (Quality of Service :
QoS) et le mme dlai de transmission bouche-oreille que sur le PSTN, les exigences de QoS
tant exprimes ici par le temps dempaquetage, la gigue, le taux de perte de paquets. Garantir
cette qualit de service ncessitera une ingnierie de trafic rigoureuse et la fourniture de
capacit, cest--dire lattribution dune bande passante suffisante dans le rseau pour
transporter le trafic prvu.
La nature des rseaux commutation de paquets impose un contrle dadmission de
connexion. En effet, si le nombre dappels actifs venait dpasser le nombre maximal de
connexions pour lequel le rseau est dimensionn, il sensuivrait une dgradation de la QoS
pour tous les appels actifs. Il en est tout autrement dans les rseaux commutation de circuits
o un manque de ressources pour ltablissement de connexions supplmentaires se traduit
par un blocage et ne touche donc quun seul utilisateur du rseau.
La mthodologie que nous allons dcrire sapplique au rseau IP, constitu dun nombre
arbitraire de routeurs de coeur et de routeurs priphriques. Cest un rseau constitu de
boucles SDH de 2,5 10 Gbits. Chaque routeur priphrique est reli une MG qui peut
prendre en charge un nombre connu d'appels N
MG
; le dbit que ncessite un appel de service i
(conversationnel, interactif ou streaming) B
communication,i
sera un paramtre donner par
loprateur. Ce dbit, exprim initialement dans le contexte TDM, sera converti dans le
contexte IP en utilisant les codecs spcifiques.
Par exemple, si le dbit dune communication type voix en mode TDM est 64 Kbps alors nous
utilisons le codec G.711 pour le convertir en mode IP. Dans ce cas le temps dchantillonnage
est 20 ms (50 paquets par seconde) et le dbit en mode IP sera gal :
Kbps , bits
bits /
B
ion communicat
625 79 8 50 40
8
50 1024 64
= |
.
|
\
|
+
= (III.14)
Supposons quun canal de trafic soit tabli entre deux routeurs priphriques pour couler le
trafic tlphonique entre les MG correspondantes. Soit B
canal
la capacit totale du canal
donne par :
=
i
i ion communicat i canal canal
B N B
, ,
(III.15)
Avec N
canal,i
le nombre de communications pouvant tre coules simultanment sur ce canal.
Ce nombre doit satisfaire cette relation qui exprime la probabilit que le contrle dadmission
42
refuse une demande de communication entre les deux passerelles considres parce que le
canal achemine dj N
canal,i
communications :
( )
( )
( )
GoS
k A
N
A
N A P
i canal
i canal
N
k
k
i
i canal
N
i
i canal i blocage
= s =
=
c
,
,
0
,
,
! /
!
, (III.16)
Avec A
i
le trafic total par service i (conversationnel, interactif ou streaming) engendr par les
usagers des rseaux daccs RTC/RNIS et GSM/GPRS.
Si un canal de trafic semblable est tabli pour chaque paire possible de MG, on dispose dun
maillage complet de canaux pour le transport du trafic tlphonique sur le rseau de base IP.
Pour chaque liaison du rseau coeur, la capacit totale fournir se compose alors de la somme
de toutes les bandes passantes B
canal
de tous les canaux passant par cette liaison.
canal n
B C bits) bone_IP (K otale_back Capacit_t =
2
(III.17)
avec n dsigne le nombre total de routeurs priphriques dans le rseau de transport.
La figure III.2 montre un exemple simple pour une liaison A-C. Dans cet exemple, quatre
chemins (les plus courts) passent par la liaison A-C : les chemins correspondant aux canaux
de trafic 2-4, 1-4, 4-6, et 2-5. Les bandes passantes respectives sont notes B
2-4
, B
1-4
, B
4-6
, B
2-5

(figure III.3). [8]
Par consquent, la capacit fournir sur la liaison A-C est :
5 2 6 4 4 1 4 2
+ + + = B B B B B
AC
(III.18)
Figure III.2 : Exemple dune liaison A-C du rseau cur
Figure III.3 : Calcul de la capacit totale fournir sur la liaison A-C
43
III.3 Dimensionnement dans le NGN Multimdia
Dans cette partie, nous nous intressons au dimensionnement dun rseau IMS qui permet
doffrir des services multimdia des usagers disposant dun accs large bande tel que xDSL,
cble, WiFi/WiMax, EDGE/UMTS, etc Nous allons prendre le cas de larchitecture du
rseau UMTS selon le concept IMS.
III.3.1 Architecture cible du rseau UMTS
La figure III.4 reprsente les diffrentes entits dimensionner dans le cas du rseau coeur
UMTS selon le concept IMS qui sont :
GGSN, SGSN, MSC Server et MGCF qui appartiennent la couche contrle.
Mobile-MGW et IMS-MGW faisant partie de la couche connectivit.
Figure III.4 : Architecture fonctionnelle du rseau cur UMTS
III.3.2 Scnario de migration retenu
Nous avons adopt le scnario UMTS release R5 qui permet l'tablissement de sessions
multimdia, un transport de tout type de mdia de bout en bout sur IP, et une offre de
nouveaux services. Ces capacits sont prises en charge par le nouveau domaine IMS (IP
Multimedia Subsystem) qui se rajoute aux domaines CS (Circuit Switched) et PS (Packet
Switched). Le domaine IMS qui se superpose au domaine PS, s'appuie sur le protocole SIP
(Session Initiation Protocol) pour le contrle de sessions multimdia ; SIP permet aussi l'accs
aux plates-formes de services. Ce protocole est incontournable en raison de sa capacit
s'intgrer aux rseaux mobiles un cot minimal. [6]
III.3.3 Modle de trafic du rseau daccs
Lvaluation du volume de trafic total dans le rseau coeur ncessite une tude pralable des
modles de trafic de chacune des classes de service. Dans ce paragraphe, nous allons donner
44
un bref aperu sur les diffrentes classes de services ainsi que les modles de trafic qui
rgissent ces classes pour pouvoir retenir un scnario pour chaque classe et calculer par la
suite la charge de trafic dans le rseau coeur. A noter que la modlisation classique des
services par des processus de Poisson nest pas valide ds quil sagit de la transmission des
donnes. Cette modlisation a t longtemps adopte pour le calcul de la charge des rseaux
tlphoniques, et qui reste toujours valable pour les communications de type voix.
III.3.3.1 Les diffrentes classes de qualit de service
Selon les spcifications de 3GPP, il est possible de partitionner, sur la base de la qualit de
service, lensemble 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 tlchargement ou background. [9]
Le critre de classification le plus prpondrant est la sensibilit au dlai de transmission. Les
deux premires classes sont prvues pour les services du type temps rel alors que les deux
autres classes concernent les applications non temps rel, ces dernires se caractrisent par
une tolrance aux dlais de transmission. Lautre contrainte respecter essentiellement pour
les deux dernires classes de service est le seuil du BER (Bit Error Rate).
III.3.3.1.1 Classe des services conversationnels
Les applications de cette classe ncessitent un service bidirectionnel en temps rel impliquant
deux utilisateurs humains ou plus. Les contraintes dpendent donc de la perception humaine :
la limite sur le dlai maximum tolr est une limite stricte car toute dgradation sur le dlai
induirait une perte de qualit notable dans la perception humaine du signal. Les exemples de
ce type dapplications sont la tlphonie, la vidophonie, la voix sur IP, les jeux interactifs.
III.3.3.1.2 Classe des services flux continu ou Streaming
Les applications de cette classe impliquent un utilisateur humain et un serveur de donnes. Ce
sont des applications temps rel asymtriques o les donnes sont transfres du rseau vers
les mobiles. Le manque dinteractivit entre lutilisateur et la source de donnes autorise des
dlais un peu plus importants que dans les cas des applications de type conversationnel, et ce
sans perturber la QoS. Les exemples dapplications de type Streaming sont les nouvelles
applications issues de lInternet, telles que les applications audio ou vido sur demande.
III.3.3.1.3 Classe des services interactifs
Les applications de cette classe impliquent un utilisateur (machine ou humain) dialoguant
avec un serveur de donnes ou dapplications. Contrairement aux deux classes prcdentes,
les performances temps rel ne sont pas ncessaires, il sagit seulement dattendre un certain
temps pour rpondre aux requtes. Par contre les informations ne doivent pas tre altres.
Les exemples dapplications de type interactif sont la navigation sur lInternet, laccs aux
bases de donnes ainsi quaux serveurs dapplications.
45
III.3.3.1.4 Classe des services en mode tlchargement ou background
Les applications de cette classe impliquent un utilisateur, le plus souvent un quipement
terminal, ralisent lenvoi et la rception de donnes en tche de fond. Labsence
dinteractivit pour ces applications fait que lutilisateur `a lorigine de la requte nest pas en
attente dune rponse dans une limite de temps fixe. Ce sont donc les applications les moins
sensibles au dlai, mais sont trs sensibles aux erreurs sur linformation transfres. Les
exemples dapplications sont le mail, le transfert de messages courts (SMS pour Short
Messages Services), le tlchargement de donnes ou de fichiers.
III.3.3.2 Modles de trafic
III.3.3.2.1 Modle de trafic pour le service conversationnel
Un exemple dun service conversationnel est la communication tlphonique. Les
communications tlphoniques constituent le service le plus classique dont le comportement
statistique a t matris. Le comportement dun utilisateur exploitant ce service au cours du
temps est modlis par un processus markovien du type ON-OFF. Les caractristiques de ce
modle sont :
Loccurrence des appels tlphoniques est un processus de poisson caractris par un
taux moyen dappel de valeur typique 0.8 appels par heure.
La dure dun appel suit un processus exponentiel de moyenne typique b telle que 1/b
= 150 s.
La dure de lappel est une alternance de priodes dactivit et de priodes de silence.
Ces priodes suivent chacune une distribution exponentielle. La valeur typique pour le
taux dactivit des sources est 0.5.
III.3.3.2.2 Modle de trafic pour le service flux continu
Un exemple typique dun service flux continu est le tlchargement dune squence vido.
Le flux des squences vido correspond une srie de trames de donnes de mme dure
raison de 25 trames par secondes. Il existe neuf types diffrents de trames. Loccurrence de
ces diffrents types de trames est gre par un processus de Markov neuf tats.
La distribution de la dure de chaque classe de contenu suit une loi Gamma dordre 2. Nous
avons retenu pour ce modle les caractristiques suivantes :
Loccurrence des sessions 0.17 appels/ heure
La dure dune session 120 s
Le taux dactivit de la source est de 0.58
III.3.3.2.3 Modle de trafic pour le service interactif
Lexemple typique de ce service est la consultation des pages Web. Le flux de donnes, selon
ce modle, peut tre dcompos en plusieurs sessions de consultation du Web. Pendant
chaque session, lutilisateur consulte un ensemble de sites Web se ramenant un appel des
46
pages HTMLs correspondantes. Le tlchargement de ces pages HTMLs est matrialis par la
transmission de plusieurs datagrammes de taille variable. Un temps de lecture est ncessaire
avant damorcer la consultation dune autre page Web. Les caractristiques statistiques de ce
modle sont les suivantes :
Loccurrence de sessions est un processus de poisson de valeur typique 0.17
appels/heure
Pour chacune de session :
Le nombre dappel de pages HTML suit une distribution gomtrique 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 gomtrique de
moyenne typique 10 datagrammes/appel.
La dure dinter-arrive de datagrammes suit une distribution exponentielle
dont la moyenne est en fonction du dbit.
La taille des datagrammes suit une distribution de Pareto.
III.3.3.2.4 Modle de trafic de la classe Background
Les services de cette classe sont insensibles au dlai, ils sont considrs de type Best Effort.
Ils sont transmis en dehors des priodes charges du rseau coeur, cest--dire au cours des
priodes dinactivits des autres classes de services. Dune autre manire, ses services ne
contribuent pas la charge du rseau.
III.3.4 Mthodologie du dimensionnement
III.3.4.1 Les hypothses du dimensionnement
Pour dimensionner le rseau coeur UMTS, nous allons nous intresser au trafic pendant
lheure de pointe, qui est dfinie comme tant lheure prsentant un maximum du trafic
pendant une journe (une semaine, un mois). Nous supposons dans la suite que le modle de
trafic du rseau daccs correspond lheure la plus charge pour le rseau coeur UMTS. De
mme, nous admettons que la rpartition du trafic de la classe conversationnelle entre mode
paquet et mode circuit (Pourcentage GSM et PSTN) est fixe malgr que la distribution du
trafic mme entre les deux systmes du mode circuit varie avec le temps (la distribution de
lheure de pointe est utilise comme rfrence).
Les taux de pntration des rseaux UMTS et EDGE sont fixs, indpendamment de la
distribution des abonns. Concernant la mobilit des abonns entre les zones de couverture de
lUMTS et celles couvertes par le spectre GSM, nous supposons que le pourcentage
dabonns qui passent de la couverture UMTS vers EDGE est le mme qui passent de
lEDGE vers UMTS. Enfin, nous avons considr que tout abonn localis sous la couverture
47
UMTS doit utiliser uniquement cette technologie avec un dbit de 2 Mbits/s. Il en est de
mme pour les abonns EDGE mais avec un dbit de 384 Kbits/s.
III.3.4.2 Organigramme de dimensionnement du rseau NGN Multimdia
Organigramme III.5 : Organigramme rcapitulatif du dimensionnement
III.3.4.3 Calcul du trafic gnr par le rseau daccs
Nous devons dabord estimer le nombre dabonns UMTS et EDGE, ceci est possible
travers des estimations et des tudes marketing. Soit le S ration_UMT taux_pnt , le
pourcentage de couverture du rseau UMTS, donc le nombre total dabonns UMTS est
donn par :
S ration_UMT taux_pnt onns_GSM Nombre_ab nns_UMTS Nombre_abo = (III.19)
Quant aux abonns utilisant les services multimdia et rsidant dans les zones non couvertes
par lUMTS, ncessairement des abonns du rseau EDGE, leur nombre total sera gal :
( ) ns_UMTS ombre_abon nns_GSM-N Nombre_abo nns_EDGE Nombre_abo =
E ration_EDG taux_pnt (III.20)
Vu que lutilisation des services varie selon leur nature dune part et selon la technologie
utilise dautre part (UMTS, EDGE), ltape suivante consiste dterminer le nombre
dabonns actifs N
ij
par technologie i et par service j (conversationnel ou interactif ou
48
streaming). Soit A
i
le nombre dabonns

de

technologie i et T
j
le taux dactivit de service j.
N
ij
est donn par :
j i ij
T A N = (III.21)
Par la suite, nous dterminons le trafic gnr par service pour les rseaux UMTS et EDGE :
j j j j UMTS j UMTS
service imal dbit appel dure appels taux N Kbits Trafic _ max _ _ _ ) (
, ,
=
J
source activits taux _ _ (III.22)
j j j j EDGE j EDGE
service imal dbit appel dure appels taux N Kbits Trafic _ max _ _ _ ) (
, ,
=
J
source activits taux _ _ (III.23)
Pour calculer le trafic total par service, il faut souligner que le trafic de la classe
conversationnelle est rparti en trafic interne dfini comme tant le trafic paquet qui englobe
les communications entre UMTS et EDGE cest--dire trafic interne lIMS, et trafic externe
destin vers le monde circuit.
Organigramme III.6 : Rpartition de trafic de la classe conversationnelle
Donc, pour les services interactif et streaming, leurs volumes de trafic gnrs sont les mmes
calculs par les quations III.24 et III.25 :
( )
eractif UMTS eractif UMTS
Trafic Kbits fic_gnr Volume_tra
int , int ,
=
( )
g strea UMTS g strea UMTS
Trafic Kbits fic_gnr Volume_tra
min , min ,
=
Tandis que pour le service conversationnel, le volume de trafic gnr est calcul comme
suit :
( )
conv UMTS conv UMTS
erne Trafic_ Kbits fic_gnr Volume_tra
, ,
int =
GSM e Pourcentag externe Trafic
conv UMTS
_ _
,
+
RTC e Pourcentag externe Trafic Trafic
conv UMTS conv UMTS
_ _
, ,
= (III.24)
Avec e circuit ers %trafic v Trafic erne Trafic_ext
UMTS,conv UMTS,conv
mod = (III.25)
De mme, nous calculons le volume de trafic gnr par service dans le cas du rseau EDGE.
Ensuite, il suffit deffectuer la somme de tous les trafics gnrs pour chaque service pour
dterminer le volume de trafic global.
49

= =
+ =
3
1
,
3
1
,
_ _ _ _
J
j EDGE
J
j UMTS
r trafic_gn Volume r trafic_gn Volume total trafic Volume
(III.26)
III.3.4.4 Dimensionnement des entits du rseau
III.3.4.4.1 Dimensionnement des M_MGWs
Pour dterminer le nombre des M_MGWs ncessaires pour vhiculer le trafic paquet, il faut
calculer le trafic interne dans les rseaux UMTS et EDGE ainsi que le trafic externe destin
aux abonns GSM. Puis leur ajouter le trafic du service conversationnel A
conv
(voir quation
III.4) issu du rseau GSM destin aux abonns UMTS et EDGE. Ce dernier est calcul
comme nous lavons vu dans la partie NGN Tlphonie.
Le nombre des M_MGWs sera gal alors :
_ M
_ _
_ M _
MGW Capacit
A total trafic Volume
MGWs Nombre
conv
+
= (III.27)
Comme dans le cas de dimensionnement dans le NGN Tlphonie, nous allons calculer la
charge des M_MGWs seulement. La capacit reste au choix de loprateur.
La charge des M_MGWs est calcule comme suit :
A total trafic Volume bits) eM_MGWs (K Ch
conv
+ = _ _ arg (III.28)
III.3.4.4.2 Dimensionnement des IMS_MGWs
Pour calculer le nombre des IMS_MGWs, nous considrons le volume de trafic vhicul entre
le rseau RTC et le rseau UMTS/EDGE et ce dans les deux sens. Le volume du trafic du
rseau UMTS/EDGE vers le rseau RTC est donn par :
( ) e circuit ers %trafic v Trafic Trafic Kbits RTC vers trafic Volume
conv EDGE conv UMTS
mod ) ( _ _ _
, ,
+ =
RTC e Pourcentag _
(III.29)
Tandis que celui vhicul du rseau RTC vers le rseau UMTS/EDGE, A
conv
(voir quation
III.4) est calcul comme dans le cas du NGN- Tlphonie.
Le nombre des IMS-MGWs est donn par :
MGW IMS Capacit
A RTC trafic Volume
MGWs IMS Nombre
conv
_ _
_ _
_ _
+
= (III.30)
III.3.4.4.3 Dimensionnement de MGCF
La charge de MGCF est estime en nombre total des communications issues du rseau RTC.
( ) onnel conversati appel taux N N MGCF e Ch
conv EDGE conv UMTS
_ _ _ arg
, ,
+ =
RTC e Pourcentag e circuit ers %trafic v _ mod
(III.31)

50
III.3.4.4.4 Dimensionnement de MSC Server
Afin de dterminer le nombre de MSC Server, nous devons calculer la capacit de traitement
de son processeur, autrement dit le nombre total des communications issues du rseau GSM.
( ) onnel conversati appel taux N N Server MSC e Ch
conv EDGE conv UMTS
_ _ _ _ arg
, ,
+ =
GSM e Pourcentag e circuit ers %trafic v _ mod (III.32)
III.3.4.4.5 Dimensionnement des SGSNs
Le dimensionnement des SGSNs dpend du nombre dabonns simultanment attachs (SAU
: Simultaneously attached User), du nombre de paquets par seconde (PPS : Packet Per
Second), la taille moyenne des paquets, etc
Pour dterminer le nombre des SGSNs, nous allons nous baser sur le paramtre SAU et ceci
pour des raisons de simplification du dimensionnement. Une caractristique importante que
nous risquons de ngliger, puisque nous navons pas ralis le dimensionnement du rseau
daccs, cest la capacit du SGSN en terme de RNC connect. Aprs le calcul du nombre des
SGSNs requis, nous devons vrifier que la capacit de chaque SGSN en terme de RNC na
pas t dpasse. Dans telle situation, il faut prendre la valeur maximale entre le nombre des
SGSNs requis selon le paramtre SAU et le nombre selon le paramtre RNC. Nous utilisons
le mode paquet (pas le mode circuit) o tous les abonns sont connects. Le nombre de SAU
EDGE et celui de SAU UMTS sont donns par :
EDGE SAU e pourcentag EDGE s Abonn Nombre EDGE SAU Nombre _ _ _ _ _ _ = (III.33)
UMTS SAU e pourcentag UMTS s Abonn Nombre UMTS SAU Nombre _ _ _ _ _ _ = (III.34)
Ltape dernire consiste choisir une configuration matrielle des SGSNs de la part de
loprateur pour calculer le nombre des SGSNs :
( )
SGSN capacit
UMTS SAU Nombre EDGE SAU Nombre
SGSNs Nombre
_
_ _ _ _
_
+
= (III.35)
III.3.4.4.6 Dimensionnement des GGSNs
Le paramtre cl de dimensionnement des GGSNs est le contexte PDP. Le nombre de
contextes PDP est donn par le nombre de sessions gnres par les abonns (un abonn peut
gnrer plusieurs sessions). En effet, chaque session est caractrise par un contexte PDP. De
plus, pour activer une session, un abonn doit tre attach au rseau paquet. Pour dterminer
le nombre de contextes PDP, nous oprons ainsi :
Calculer le nombre de contextes PDP gnrs par les abonns UMTS
( ) ( tionnel e_conversa it_servic taux_activ nns_UMTS Nombre_abo _UMTS Nombre_PDP =
eractif ce_ vit_servi taux_ acti int +
) g ce_strea vit_servi taux_ acti min + (III.36)

51
Calculer le nombre de contextes PDP gnrs par les abonns EDGE
( ) ( tionnel e_conversa it_servic taux_activ _EDGE Nombre_SAU _EDGE Nombre_PDP =
eractif ce_ vit_servi taux_ acti int +
) g ce_strea vit_servi taux_ acti min + (III.37)
Le nombre total de contextes PDP activ
_EDGE Nombre_PDP _UMTS Nombre_PDP _total Nombre_PDP + = (III.38)
Par la suite, nous dterminons le nombre des GGSNs selon la capacit choisie par
loprateur :

_GGSN
_ _
_
capacit
total PDP Nombre
GGSNs Nombre = (III.39)
III.3.4.5 Optimisation du rseau de transport
Pour pouvoir dimensionner les artres du rseau de transport, nous suivons la mme dmarche
adopte dans le cas du NGN Tlphonie, sauf que dans le cas de NGN multimdia, nous
avons deux types de trafic prsents au niveau du rseau de transport :
Le trafic interne coul entre les rseaux UMTS et EDGE ainsi que le trafic externe
vers les rseaux RTC ou GSM : pour ces types de trafic le dbit dune communication
Bcommunication ne sera pas converti de mode TDM en mode IP puisque il en y est
dj.
Le trafic issu des rseaux RTC et GSM : la Bcommunication sera convertie de mode
TDM en mode IP en utilisant des codecs bien dtermins.
III.4 Conclusion
Dans ce chapitre, nous avons abord le processus de dimensionnement dans les rseaux
NGN : Tlphonie et Multimdia. Nous avons essay de prsenter les diffrents outils
mathmatiques et algorithmiques utiliss pour russir ce dimensionnement.
Le dernier chapitre sera consacr pour la prsentation de notre outil universel de
dimensionnement et son valuation par des exemples de scnarios de dimensionnement tout
en se basant sur les quations de ce troisime chapitre.

Outil de dimensionnement et validation sur des scnarios
52
Chapitre IV
Outil de dimensionnement et validation sur
des scnarios

IV.1 Introduction
Au cours du chapitre prcdent, nous avons tudi le processus de dimensionnement dun
rseau NGN : Tlphonie ainsi que Multimdia.
Dans ce chapitre, il sera essentiellement question de loutil universel de dimensionnement que
nous devons dvelopper et de son valuation. Pour ce faire, nous commencerons par spcifier
le cahier des charges et prsenter lenvironnement de dveloppement qui nous permettra
datteindre les objectifs de ce cahier des charges. Ensuite nous prsenterons lorganigramme
fonctionnel de loutil en dcrivant les fonctionnalits de ses modules et les tapes de son
fonctionnement. Enfin la dernire partie de ce rapport sera consacre une valuation de
loutil base sur une tude de cas.
IV.2 Cahier de charges de loutil
IV.2.1 Objectif de l'outil de dimensionnement
Le but de cette tude est de dvelopper un outil universel de dimensionnement dun rseau
NGN et dun rseau IMS. Cet outil devra tre capable dautomatiser les oprations de
dimensionnement et doptimisation, illustres dans le chapitre prcdent. Son objectif nous
apparat utile mme si, eu gard au caractre volutif des problmes des tlcommunications,
des modifications plus ou moins brve chance sont susceptibles d'affecter les rgles ou les
procdures.
IV.2.2 Paramtres d'entre
Notre outil devra accepter les paramtres suivants comme variables d'entre :
IV.2.2.1 NGN Tlphonie
Tentatives dappels lheure charge TAHC : nombre dappels excuts pendant
lheure de pointe pour chaque service. Ce paramtre sera introduit par CT ou MSC et
par zone.
Dure moyenne des communications DMC pour chaque service exprim en secondes.
Elle sera introduite par CT ou MSC et par zone.
53
GoS (Grade of Service) : exprime la probabilit de blocage fixe par loprateur au
niveau de linterface CT-MG ou MSC-MG.
Nombre de routeurs : cest un paramtre saisir lors de loptimisation du rseau de
transport.
Bande de communication exprime en Kbits/s : reprsente le dbit dune type de
communication (voix, donne ou vido).
La capacit de MG et celle de softswitch : elle est utilise pour dterminer le nombre
de ces deux entits. Ces deux capacits varient selon le fournisseur.
IV.2.2.2 IMS
Taux dappels : reprsente le rapport entre le nombre de tentatives dappels par heure
et le nombre dabonns total pour chaque service.
Taux dactivit source par service : cest le taux doccupation du canal selon le
service.
DMC.
GoS : probabilit de blocage fixe dans le rseau UMTS/EDGE.
Nombre dabonns GSM, EDGE et UMTS, rpartis par zone.
Pourcentage SAU EDGE et SAU UMTS : ce sont les abonns paquet simultanment
attachs chaque technologie.
Taux dactivit pour chaque service.
Pourcentage du trafic sortant vers le mode circuit : cest le trafic conversationnel
sortant du mode IP vers mode circuit et qui sera rparti entre les rseaux GSM et RTC.
La capacit des entits M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN.
IV.2.3 Paramtres de sortie
Nous pensons quil est possible davoir les donnes suivantes comme sortie de notre outil de
dimensionnement :
IV.2.3.1 NGN Tlphonie
Trafic total gnr par les rseaux daccs RTC/RNIS et GSM/GPRS rparti entre les
CT (respectivement les MSC) et les zones.
Nombre des jonctions MIC par CT ou MSC.
Charge des MGs et softswitchs par zone.
Nombre des communications couler simultanment dans le rseau de transport.
Capacit totale en Kbits fournir pour le rseau de transport.
Prvision du trafic de chaque CT ou MSC et de charges des MGs et softswitchs sur
cinq ans.

54
IV.2.3.2 IMS
Trafic total en Kbits gnr par les rseaux EDGE et UMTS pour chaque zone.
Rsultat de dimensionnement des entits M-MGW, IMS-MGW, MSC Server, MGCF,
SGSN et GGSN en terme de charge et nombre.
Nombre des communications couler simultanment dans le rseau de transport.
Capacit totale en Kbits fournir pour le rseau de transport.
Prvision du trafic et des charges des entits sur cinq ans.
IV.2.4 Interface Utilisateur
Notre outil de dimensionnement devrait prsenter une interface graphique agrable et facile
manipuler. L'utilisateur devra introduire les paramtres d'entre d'une faon aise, ainsi que la
visualisation des rsultats. Il devra aussi manipuler les menus du logiciel sans problme.
Notre outil sera capable denregistrer ces paramtres d'entre et leurs rsultats dans des
rapports et de les afficher exhaustivement.
Nous jugeons utile doffrir plus de libert l'utilisateur de loutil en lui donnant la possibilit
d'introduire le type de dimensionnement de son choix.
IV.3 Environnement de dveloppement
Le langage que nous avons choisi pour dvelopper notre outil de dimensionnement est le J#
(JSharp). J# est un des derniers langages introduits dans la famille du framework.Net, il est
maintenant directement intgr dans Visual Studio .Net 2003.
C'est un langage orient objet cr par Microsoft pour les dveloppeurs Java souhaitant faire
des applications et des services sur le framework.Net. De ce fait, les dveloppeurs peuvent
utiliser tous les avantages du framework .Net comme :
Un modle unifi de programmation (les applications Windows, les applications Web
et les applications Mobile Web) sur diffrents types de machines et de systmes
d'exploitation.
La prise en charge native des services Web XML, ADO.Net et ASP.Net et Windows
Forms.
Une interaction totale avec les langages (et donc les applications) orients .Net.
De plus, les dveloppeurs voulant exploiter les fonctionnalits du framework .Net et de Visual
Studio pour leurs anciennes applications, peuvent le faire grce diffrents outils de
conversions, mise disposition, pour les programmes en Java ou en J++. Ainsi, l'utilisation de
JSharp nous permet de dcomposer facilement le moteur de simulation en packages
indpendants. Et comme chaque package peut tre dvelopp sans aucune relation avec les
autres, la gestion du projet, mise en place, devrait tre trs efficace. En somme, cest toutes
ces caractristiques runies qui ont motiv le choix du J# comme langage de dveloppement.
55
IV.4 Fonctionnalits de loutil
Loutil dont il est question est un outil de dimensionnement dun rseau NGN. Son but est
daider les oprateurs trouver la meilleure configuration de leur rseau en terme
dquipements ncessaires et de charges tout en garantissant une qualit de service donne.
IV.4.1 Organigramme fonctionnel de loutil
Les fonctionnalits de notre outil sont reprsentes par lorganigramme suivant :
Organigramme IV.1 : Principe de fonctionnement de loutil
IV.4.2 Modules dvelopps
Pour grer les entres et les sorties de cet outil de dimensionnement, nous avons dvelopp
quatre modules principaux.
IV.4.2.1 Module destimation de la charge de trafic pour le NGN Tlphonie
Ce module a pour objectif de dterminer la charge de trafic dune zone tudie pour chaque
CT (respectivement MSC). Il rpartit ce trafic par type de service et dtermine par la suite le
nombre des jonctions MIC entre un CT (respectivement MSC) et une MG. Enfin, il permet
dagrger toutes les charges de trafic issu de lensemble des CT (respectivement MSC) pour
le dimensionnement des MGs et softswitchs.
56
Organigramme IV.2 : Estimation de la charge de trafic cas NGN Tlphonie
IV.4.2.2 Module destimation de la charge de trafic pour le NGN Multimdia
Ce module soccupe du calcul de la charge de trafic pour une zone donne et pour chaque
service (conversationnel, interactif ou streaming) dans les rseaux UMTS et EDGE ce qui
permet de dimensionner les diffrentes entits suivantes : M-MGW, IMS-MGW, MSC
Server, MGCF, SGSN et GGSN.
Organigramme IV.3 : Estimation de la charge de trafic cas NGN Multimdia
IV.4.2.3 Module doptimisation du rseau de transport
Ce module permet de calculer dune part le nombre des communications simultanes
couler dans le rseau de transport et dautre part la capacit totale fournir suivant
lalgorithme dcrit dans lorganigramme III.4.
57
IV.4.2.4 Module de prvision de trafic
Lextension des rseaux demande lapprovisionnement des quipements des centraux, des
faisceaux de jonctions et des circuits. Cependant, il pourrait y avoir un temps entre
lidentification des besoins futurs et le moment de ralisation. La dure de temps entre
lidentification du besoin et son approvisionnement est considrable. Pour viter les longues
priodes dattente et la congestion leve, il est prfrable de dterminer les besoins
lavance. Cela rend possible lextension du matriel au bon moment parce que laction
ncessaire peut tre effectue en temps appropri.
Une prvision devrait, cependant, produire premirement lestimation exacte des demandes
futures pour les quipements des tlcommunications.
Ce module sintresse la prvision du trafic des rseaux daccs RTC/RNIS et GSM/GPRS
dans le cas du NGN Tlphonie et des rseaux UMTS et EDGE pour le NGN Multimdia.
Ainsi cette partie estime la prvision de la charge des MGs et softswitchs dans le premier cas
et les entits : M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN dans le deuxime
cas.
Nous avons choisi la mthode de prvision tendancielle qui consiste supposer que le
dveloppement devrait suivre la courbe qui a t ajuste des donnes historiques existantes.
Pour des raisons de simplification, nous allons nous limiter la mthode de tendance linaire
donne par la formule suivante :
( ) b t a t y + = (IV.1)
Avec
y(t) : rsultat de la prvision lanne t
a : la pente de la courbe
b : le trafic ou charge t=0
IV.5 Interface utilisateur dveloppe
V.5.1 Fentre principale de loutil
Lors du dmarrage de lapplication, nous apercevons la fentre principale (Figure IV.1) qui
affiche une barre de menus compose de :
NGN Tlphonie
NGN Multimdia
Prvision
Aide
58
Figure IV.1 : Fentre principale de loutil
Cette fentre comporte son tour une barre doutils contenant :
Nouveau : il permet lutilisateur de crer un nouveau projet de dimensionnement. En
effectuant cette tche, lutilisateur a le choix entre un dimensionnement dun rseau de
type NGN Tlphonie ou bien NGN Multimdia (voir figure IV.2) et selon ce choix il
active de facto les autres menus (NGN Tlphonie ou bien NGN Multimdia) et
pourra ainsi commencer son projet.
Figure IV.2 : Fentre de cration dun nouveau projet
Ouvrir : ce bouton permet de charger en mmoire un projet existant : videmment il y
a deux types de projets le premier dextension .tel et le deuxime dextension .ims.
59
Cette opration douverture affiche tous les paramtres dentre saisis, par
lutilisateur, ainsi que les rsultats de dimensionnement dans des rapports.
Sauvegarder : il permet de sauvegarder les nouveaux projets.
V.5.2 Menu NGN Tlphonie
Ce menu concerne le dimensionnement dans le cas du rseau NGN Tlphonie. Il comporte
trois parties essentielles. :
La premire, pour la saisie de paramtres dentre. Elle contient un seul sous menu
appel Donnes Oprateurs .
La deuxime, sintresse au calcul et laffichage des rsultats de dimensionnement.
Elle comprend quatre sous menus qui sont :
Calcul du trafic : permet de calculer le trafic gnr par les rseaux daccs
RTC/RNIS et GSM/GPRS.
Rpartition du trafic : sert afficher les valeurs du trafic par CT
(respectivement MSC) et par service.
Nombre de liens : sous menu qui permet de calculer le nombre de liens
MIC entre un CT (respectivement MSC) et une MG.
Dimensionnement de MG et softswitch : pour la dtermination de la charge
ou bien du nombre de ces deux entits.
La dernire, soccupe de loptimisation du rseau de transport. Elle se compose dun
seul sous menu Rseau de transport .
V.5.3 Menu NGN Multimdia
Cest le menu qui va nous permettre de visualiser les rsultats obtenus dans le processus de
dimensionnement dun rseau NGN Multimdia en terme de trafic gnr par le rseau
UMTS/EDGE et du nombre de M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN.
Comme dans le cas du NGN Tlphonie, ce menu comprend trois parties :
La premire est consacre la saisie des donnes dentre par lutilisateur. Elle
contient deux sous menus : Donnes Oprateurs et Donnes EDGE/UMTS .
La deuxime contient trois sous menus : Calcul du trafic , Rpartition du trafic
et Dimensionnement des entits.
La dernire est un sous menu appel Rseau de transport .
V.5.4 Menu Prvision
La fonction prise en compte par ce menu est la prvision du trafic des rseaux daccs et de
charges des entits fonctionnelles des rseaux NGN Tlphonie et Multimdia. Il est constitu
de deux sous menus : le premier ddi la prvision dans le cas du NGN Tlphonie alors
que le second est rserv la prvision dans le NGN Multimdia.
60
V.5.5 Menu Aide
Le menu Aide , comme son nom lindique, permet dafficher une aide contextuelle. Il
comprend un volet Aide et un volet A propos qui permet laffichage de la fentre
didentification de lapplication (voir Figure IV.3).
Figure IV.3 : Fentre A propos
IV.6 Validation sur scnarios
Dans ce paragraphe, il sera essentiellement question de la prsentation des rsultats de
dimensionnement dun rseau NGN partir de notre outil informatique. Pour ce faire, nous
allons excuter deux scnarios de dimensionnement, le premier concerne le rseau NGN
Tlphonie tandis que lautre sera consacr au rseau NGN Multimdia.
IV.6.1 Cas du rseau NGN Tlphonie
IV.6.1.1 Acquisition des paramtres et donnes dentre
Dans ce premier scnario, nous assimilerons la zone 3 qui reprsente la zone du Sahel. Nous
allons prsenter ce scnario laide des diffrentes interfaces de notre outil de
dimensionnement.
En effet, la premire tape aprs lexcution de lapplication cest lauthentification par le
biais dun Login et dun Mot de passe. Cette interface permet de limiter laccs
lapplication.
Figure IV.4 : Authentification de lutilisateur
61
Une fois laccs est autoris linterface de la fentre principale apparat (Figure IV.1). Nous
choisissons par la suite un nouveau projet de type NGN Tlphonie (voir figure IV.2), le
menu NGN Tlphonie sera activ et il suffit dy accder pour aborder les diffrentes tapes
du dimensionnement. Le tableau IV.1 rsume les diffrents paramtres dentre pour ce
scnario de dimensionnement concernant la zone du Sahel. Elle est compose de deux CT et
trois MSC qui seront relis aux MGs : CT de Sousse (CT1), CT de Moknine (CT2), MSC1
Sousse, MSC2 Sousse, MSC Moknine (MSC3).
Tableau IV.1 : Paramtres dentre de la zone 3
Nous passons ensuite la fixation de ces paramtres dentre du dimensionnement dans
linterface Ajout Donnes Oprateur appartenant au sous menu Donnes Oprateur .
En premier lieu lutilisateur saisit le GoS souhait au niveau de linterface CT-MG
(respectivement CT-MSC), le nombre de zones, le nom de chaque zone ainsi que le nombre
de CT et MSC quelle contient.
Figure IV.5 : Ajout des donnes de loprateur
GoS
(%)
TAHC
voix
DMC
voix
TAHC
donne
DMC
donne
TAHC
vido
DMC
vido
CT1 3 101944 70 s 1861 1194 s 0 0
Rseau
RTC/RNIS
CT2 3 30461 70 s 0 0 0 0
MSC1 3 39014 43 s 0 0 0 0
MSC2 3 92785 33 s 0 0 0 0
Rseau
GSM/GPRS
MSC3 3 90000 33 s 0 0 0 0
62
En cliquant sur le bouton Ajouter , les cases de saisie de TAHC et DMC pour chaque
service seront actives, lutilisateur pourra faire entrer les valeurs de ces paramtres pour la
zone3-CT1 puis la zone3-CT2 et enfin valider. Les figures IV.6 et IV.7 illustrent les tapes de
cette saisie.
Figure IV.6 : Saisie des donnes dentre de la zone3-CT1
Figure IV.7 : Saisie des donnes dentre de la zone3-CT2
63
Les mmes tapes suivre pour la saisie des paramtres dentre du rseau daccs
GSM/GPRS.
IV.6.1.2 Rsultats obtenus
Ltape suivante excute par notre outil sera le calcul du trafic total gnr par les deux
commutateurs de transit et les trois MSC dans la zone 3. Ce trafic sera gal 20.251 Gbits
comme le montre la figure IV.8.

Figure IV.8 : Calcul du trafic total gnr par les rseaux daccs
Nous avons procd la rpartition de ce trafic total en calculant le trafic par service ainsi que
le total engendr par chaque CT (respectivement MSC) dans la zone 3.
Figure IV.9 : Rpartition du trafic RTC/RNIS entre les deux CT de la zone 3
Linterface suivante donne la rpartition du trafic total du rseau daccs GSM/GPRS entre
MSC1 Sousse, MSC2 Sousse et MSC de Moknine (MSC3).
64
Figure IV.10 : Rpartition du trafic GSM/GPRS entre les trois MSC de la zone 3
Ltape importante dans ce processus de dimensionnement sera le calcul du nombre des MGs
et softswitchs mettre en place pour assurer le fonctionnement du rseau NGN Tlphonie.
Linterface de la figure IV.11 nous permet de dterminer la charge des MGs en Kbits et celle
des softswitchs en tentatives dappels pour la zone 3.
Figure IV.11 : dtermination des charges des MGs et des softswitchs
Le calcul nous donne une charge des MGs gale 20.251 Gbits et celle des softswitchs de
356065 tentatives dappels lheure charge (TAHC).
Si loprateur veut calculer le nombre des MGs et des softswitchs, il doit cliquer sur le bouton
Avanc pour saisir la capacit de MG en Kbits ainsi que celle de softswitch en TAHC puis
sur le bouton Calcul pour afficher leur nombre. Par exemple, si loprateur opte pour les
media gateways de type Cisco MGX 8800 Series dune capacit de 2.2 Gbps et les
softswitchs Cisco PGW 2200 Softswitch gateway de capacit de traitement gale 40000
TAHC, nous aurons : 10 MGs et 9 softswitchs. [12]
65
Figure IV.12 : Calcul du nombre des MGs et des softswitchs
Concernant loptimisation du rseau de transport, loprateur doit saisir le nombre des
routeurs priphriques constituant le rseau de transport, la bande de communication de
chaque type de services et le codec convenable pour la conversion de cette bande de mode
TDM en mode IP.
Notre outil sera capable de calculer le nombre des communications gnres sur un canal
reliant deux MGs et la capacit totale fournir pour couler ce nombre. La figure IV.13
montre un exemple doptimisation du rseau de transport de la zone 3.
Figure IV.13 : Optimisation du rseau de transport de la zone 3
66
Le prsent scnario de dimensionnement dun rseau NGN Tlphonie de la zone 3 dcrit
dans cette partie, seffectue le 10 juin 2006. Pour pouvoir raliser la prvision du trafic des
rseaux RTC/RNIS et GSM/GPRS ainsi que celle des charges des MGs et des softswitchs,
nous avons besoin du trafic et charges dans un autre jour futur, partir duquel loprateur
dsire faire la prvision qui sera opre par dfaut sur cinq ans.
Dans notre cas, nous allons supposer que nous sommes aujourdhui le 4 dcembre 2006 et que
nous voulons effectuer la prvision partir de ce jour sur cinq ans. Ensuite, nous faisons le
scnario de dimensionnement au jour du 4 dcembre 2006. La prvision du trafic ainsi que
celle des charges des MGs et des softswitchs sont donnes par les figures IV.14, IV.15 et
IV.16 :

Figure IV.14 : Prvision du trafic RTC/RNIS de la zone 3

Figure IV.15 : Prvision du trafic GSM/GPRS de la zone 3
67
Figure IV.16 : Prvision des charges des MGs et des softswitchs de la zone 3
Enfin, nous avons rcapitul lensemble des donnes dentre et de sortie de notre outil
concernant ce projet de dimensionnement de la zone 3 dans un rapport technique illustr par
la figure IV.17.
Figure IV.17 : Extrait du rapport rcapitulatif de dimensionnement de la zone 3
68
IV.6.2 Cas du rseau NGN Multimdia
IV.6.2.1 Acquisition des paramtres et donnes dentre
Nous allons aborder le dimensionnement du rseau UMTS selon le concept NGN Multimdia
en adoptant lapproche par zones. En se basant sur les caractristiques du rseau GSM, le
territoire Tunisien est divis en cinq zones de concentration de trafic (zone1 : Grand Tunis,
zone2 : CapBon, zone3 : Sahel, zone4 : Sud, zone5 : Nord West). Vue que chaque zone a ses
propres caractristiques (rpartition des abonns GSM, taux dactivit des services, rpartition
de trafic, rpartition des abonns WCDMA, etc. . .), lapproche par zone parait trs
intressante.
La premire tape du dimensionnement du rseau UMTS sera la spcification des modles de
trafic pour chaque service. Elle nous a permis de retenir un modle pour chaque service qui
constituerait des valeurs typiques que nous allons prendre pour dterminer la contribution de
chaque service dans la charge totale du trafic dans le rseau coeur. Ces valeurs ne sont pas
fixes, pour autant. Lutilisateur de notre outil dvelopp, peut intervenir pour changer ces
paramtres. Linterface IV.18 nous permet de fixer le modle de trafic du rseau daccs et le
GoS souhait dans le rseau EDGE/UMTS.
Figure IV.18 : Modle de trafic du rseau daccs
69
Dans linterface suivante, lutilisateur doit saisir le nombre dabonns GSM, le taux de
pntration de lUMTS, le taux de pntration EDGE, le nombre de zones relatives la
rpartition du trafic et des abonns et la rpartition du trafic total gnr par les abonns
EDGE et UMTS du service conversationnel. En fait, ce dernier paramtre sera utilis pour le
dimensionnement des M-MGWs. Nous prenons 70% de ce trafic conversationnel sortant vers
le mode circuit qui est rparti son tour entre GSM et RTC selon les pourcentages suivants :
40% vers RTC et 60% vers GSM.
Figure IV.19 : Fixation des paramtres gnraux
En validant ltape prcdente, lutilisateur est invit saisir les paramtres concernant :
La rpartition des abonns EDGE et UMTS : pour rpartir les abonns EDGE et
UMTS sur les cinq zones de concentration du trafic, nous utilisons les pourcentages du
tableau IV.2. A partir de ces pourcentages, nous calculons le nombre dabonns par
zone et par la suite nous dterminons le trafic paquet gnr pour chaque classe de
service ainsi que le trafic total.
Zone1 Zone2 Zone3 Zone4 Zone5
Pourcentage UMTS (%) 50 16 14 10 10
Pourcentage EDGE (%) 48 11 11 15 15
Tableau IV.2 : Rpartition des abonns EDGE et UMTS
Pourcentages dattachement des abonns : nous avons dj prsent le processus du
dimensionnement des SGSNs. Pour cela, il suffit de calculer pour chaque zone le
70
nombre de SAU simultanment pour EDGE et UMTS. Le calcul se fait en considrant
les pourcentages du tableau IV.3.
Abonns paquet attachs (%)
(Pourcentage SAU UMTS)
100 90 90 80 90
Abonns paquet attachs (%)
(Pourcentage SAU EDGE)
50 35 39 32 33
Tableau IV.3 : Pourcentages dattachement des abonns EDGE et UMTS
Les taux dactivit des services : chaque zone ses propres taux dactivit des
services ; le comportement des abonns envers les services diffre dune zone une
autre. Pour ce scnario, nous utilisons les taux du tableau IV.4.
Conversationnel (%) 70 30 30 30 25
Interactif (%) 68 38 40 35 37
Streaming (%) 30 13 12 13 10
Tableau IV.4 : Taux dactivit des services
Figure IV.20 : Rpartition des paramtres dentre par zone
La dernire interface de saisie des donnes dentre concerne le trafic en mode circuit cest
dire le trafic conversationnel des rseaux RTC et GSM destin aux abonns UMTS et EDGE.
Il sagit de calculer pour chaque zone le trafic externe conversationnel issu des rseaux RTC
et GSM quelle va recevoir. Pour ce faire nous devons saisir les paramtres suivants pour
71
chaque rseau : TAHC, DMC et GoS. Dans ce scnario nous ne tenons pas compte de ce
trafic.

Figure IV.21 : trafic conversationnel en mode circuit issu des rseaux RTC et GSM
IV.6.2.2 Rsultats obtenus
Les rsultats du dimensionnement sont donns par la fentre de la figure IV.22. En effet, les
abonns UMTS et EDGE gnrent un trafic total de lordre 22612.70 Gbits. Ce trafic est
rparti entre les trois services de la manire suivante : 19547.731 Gbits service
conversationnel, 860.211 Gbits service Interactif et 2204.764 Gbits pour le service Streaming.

Figure IV.22 : Calcul du trafic total gnr par les abonns EDGE et UMTS
Les quatre interfaces des figures IV.23, IV.24, IV.25 et IV.26 sintressent la rpartition de
ce trafic total entre les cinq zones ainsi quau calcul des charges et nombre des M-MGW,
IMS-MGW, MSC Server, MGCF, SGSN, GGSN dans chaque zone.
72
Figure IV.23 : Rpartition du trafic EDGE entre les cinq zones
Figure IV.24 : Rpartition du trafic UMTS entre les cinq zones
Figure IV.25 : Dtermination des charges des entits fonctionnelles
73
Une fois que les diffrentes charges des entits fonctionnelles sont dtermines, loprateur
peut calculer le nombre de ces entits en introduisant la capacit de chaque entit exprime en
Kbits pour lIMS-MGW, M-MGW et en TAHC pour le MSC Server et MGCF. Pour cela il
doit cliquer sur le bouton Avanc . Linterface suivante nous montre un exemple de calcul
de ces entits.
Figure IV.26 : Dtermination du nombre des entits fonctionnelles
Zone 1 : Cest la zone la plus dense en abonns (presque la moiti des abonns). Elle
engendre le plus du trafic : 15870 Gbits (13757.78 Gbits service conversationnel,
1563.33 Gbits service streaming et 549 Gbits pour linteractif). Pour satisfaire les
exigences de cette zone, loprateur Tunisien doit installer 5 M-MGW, 2 IMS-MGW,
1 MGCF, 1 MSC Server, 1 GGSN et 1 SGSN.
Zone 2 : elle gnre 2053 Gbits (1759.71 Gbits conversationnel, 202.193 Gbits
streaming et 91.71 Gbits interactif). La configuration requise selon ce scnario est la
suivante : 1 M-MGW, 1 IMS-MGW, 1 MGCF, 1 MSC Server, 1 GGSN et 1 SGSN.
Zone 3 : dans cette zone, les services multimdia offerts (conversationnel, streaming et
interactif) gnrent respectivement (1579.86 Gbits, 167.55 Gbits et 86.66 Gbits). Le
trafic total est 1834.09 Gbits qui ncessite 1 M-MGW, 1 IMS-MGW, 1 MGCF, 1
MSC Server, GGSN et SGSN pour tre vhicul.
Zone 4 : ses abonns gnrent un trafic de 1554.225 Gbits (1336 conversationnel,
153.55 streaming et 64.151 Interactif). Tunisie Tlcom doit installer 1 M-MGW, 1
IMS-MGW, 1 MGCF, 1 MSC Server, 1 GGSN et 1 SGSN.
Zone 5 : cette zone ncessite 1 M-MGW, 1 IMS-MGW, 1 MGCF, 1 MSC Server, 1
SGSN et 1 GGSN pour vhiculer le trafic paquet. Le trafic gnr par ses abonns est
de 1299.70 Gbits (1113.76 service conversationnel, 118.122 service streaming et
67.81 service interactif).
74
Donc le nombre total des quipements ncessaires pour couler le trafic total gnr par les
abonns EDGE et UMTS sont :
9 M-MGW : 5 zone 1, 1 zone 2, 1 zone 3, 1 zone 4, 1 zone 5.
6 IMS-MGW : 2 zone 1, 1 pour chaque zone (2, 3, 4, 5).
5 GGSN : un par zone.
5 SGSN : un par zone.
5 MGCF : un par zone.
5 MSC Server : un par zone.
Figure IV.27 : Optimisation du rseau de transport pour les cinq zones
Pour la prvision du trafic et des charges des entits fonctionnelles du NGN Multimdia, nous
allons estimer la prvision du 4 dcembre 2006 sur cinq ans successifs.
Figure IV.28 : Prvision du trafic EDGE des cinq zones
75
Figure IV.29 : Prvision du trafic UMTS des cinq zones
Figure IV.30 : Prvision des charges des entits fonctionnelles
Figure IV.31 : Courbe de prvision des charges des M-MGW et IMS-MGW
76
Figure IV.32 : Courbe de prvision des charges des MSC Server et MGCF
Figure IV.33 : Courbe de prvision des charges des SGSNs et GGSNs
Ces courbes donnent une illustration graphique du module de prvision des charges des
entits M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN. Par exemple dans la
figure IV.31, la courbe en noire reprsente lvolution de la charge en Kbits des IMS-MGW
77
installer dans la zone du Grand Tunis sur une priode de cinq ans partir du 4 dcembre
2006. Quant la courbe en rouge, elle traduit lvolution de la charge en Kbits des M-MGW
au cours de cinq ans.
Pour rsumer ce scnario de dimensionnement, nous avons utilis des rapports rcapitulatifs
qui contiennent la fois les paramtres dentre saisis par lutilisateur et les rsultats
correspondants.

Figure IV.34 : Rapport Technique de dimensionnement des cinq zones
78
IV.7 Conclusion
Dans ce chapitre, nous avons prsent notre outil de dimensionnement dun rseau NGN. Une
description dtaille des modules de loutil a t faite, suivie dune prsentation des interfaces
dveloppes. Aussi modeste quil soit, cet outil prsente deux avantages majeurs : son
extensibilit et sa facilit dutilisation.
Dans la dernire partie de ce chapitre, nous avons test notre outil par lintermdiaire des
scnarios de dimensionnement.

Conclusion gnrale
79
Conclusion gnrale

Dans le cadre de ce projet de fin dtudes, nous nous sommes intresss ltude et
dimensionnement dun rseau de nouvelle gnration (NGN) avec en perspective, dabord de
proposer des solutions concrtes de stratgies de migrations des rseaux actuels vers
larchitecture de nouvelle gnration ; ensuite ltude exhaustive du processus de
dimensionnement et enfin la conception et la ralisation dun outil de dimensionnement avec
validation de cet outil par des scnarios.
A lissue de ce travail, nous voulons insister sur limportance des deux concepts : NGN
Tlphonie et NGN Multimdia. Les apports de ces concepts sont clair travers : la
transformation de la topologie du rseau avec rduction du nombre de liens entre
commutateurs, une solution reposant sur le dploiement des Media Gateways, softswitchs
ncessite moins dquipements, moins de sites et moins de personnel, dveloppement de
nouveaux services et des gains raliser par loprateur.
A travers les rsultats obtenus dans les deux scnarios de dimensionnement, nous
recommandons fortement le dploiement de ces deux concepts.
Au del de ce projet de fin dtudes, loutil est susceptible de plusieurs extensions :
Le dimensionnement de la signalisation pourra tre inclus.
Un algorithme doptimisation plus performant pour le rseau de transport qui prendra
en compte tous les routeurs et les capacits exactes des liaisons inter-routeurs.
Lenrichissement de la mthode de dimensionnement en spcifiant par exemple
d'autres paramtres non tenus en compte dans le processus de dimensionnement.
La prise en compte dautres rseaux daccs.

Bibliographie
80
Bibliographie

[1] Rapport de lETSI-NGN Starter Groupe, compte-rendu de lassemble GA38 des 20-
21/11/01.

[2] Cabinet Acrome, Etude technique, conomique et rglementaire de lvolution vers les
rseaux de nouvelle gnration, ART, Septembre 2002.
http:// www.art-telecom.org/ngnsep02.pdf

[3] Simon ZNATY, Jean-Louis DAUPHIN, Architecture NGN : Du NGN Tlphonie au
NGN Multimdia, EFORT, 2005.
http://www.efort.com

[4] Simon ZNATY, Jean-Louis DAUPHIN, IP Multimedia Subsystem : Principes et
Architecture, EFORT, 2005.

[5] Cabinet Ovum, L'volution du coeur de rseau des oprateurs fixes, ARCEP, Janvier
2006.

[6] Simon ZNATY, Next Generation Network (NGN) dans les rseaux mobiles, EFORT,
2005.

[7] Sami Tabbane, Ingnierie des rseaux cellulaires, HERMES Science Publications,
Paris 2002.

[8] G. Van Hoey, S. Van den Bosch, P. de La Valle Poussin, H. De Neve, G. Petit, Le
dimensionnement des futurs rseaux de transport pour les applications tlphoniques en
temps rel, Revue des Tlcommunications dAlcatel, 2
me
trimestre 2001.

[9] 3GPP, Quality of Service concept and architecture, TS 23.107, R5, Dcembre 2002.

[10] UIT, Incidences des nouvelles techniques sur les rseaux de tlcommunications, 14
novembre 2000

[11] Daniel Kofman, Synthse sur l'volution des rseaux de tlcommunications, ENST,
21 Septembre 2001.

[12] Cisco, Introducing the Cisco Voice Interworking Service Module, Release 2.1.
http://www.cisco.com/en/US/products/hw/switches/ps1938/
[13] Akhmad Ludfy, BHCA Softswitch Capacity, Telekomunikasi Indonesia, December
2005.
http://www.ristishop.com/portal_article_detail

Bibliographie
81
[14] Asia Pacific Telecommunications (APT), Contribution on NGN network planning,
Development Forum, July 2005.
http://www.APT-ADF/xE.doc

[15] Xavier Voisin, Tlphonie IP et volution des rseaux, UIT, Yaound, avril 2004.
[16] A. Krendzel, V. Derjavina, S. Lopatin, Tlphonie Method for Estimating Parameters
of NGN traffic, St.-Petersburg Research Institute of Telecommunications, Russia.
[17] Souheil Marine, New trends in telecommunications, UIT/BDI Arab rgional
workshop, Syria, July 2002.

Titre Titre Titre Titre
Etude et Dimensionnement dun Rseau de Nouvelle Gnration (NGN)
Cas dtude : Tunisie Tlcom
Rsum Rsum Rsum Rsum
La commutation tlphonique volue. Une nouvelle gnration darchitectures de rseaux
apparat permettant doffrir de nouveaux services mergents mixant voix, vido et donnes :
Les Next Generation Networks (NGN).
Larchitecture NGN vise deux modes de fonctionnement : NGN tlphonie pour lmulation
du RTC lors du remplacement des commutateurs tlphoniques et NGN multimdia (aussi
appel IMS) pour directement offrir des services multimdia partir daccs tels que xDSL, le
cble, lUMTS, etc.
Le but de ce projet de fin dtudes est de prsenter les principes, les architectures de rseau et
de service NGN et IMS et la migration vers ces architectures.
La ralisation dun outil universel de dimensionnement de rseaux NGN et une tude de cas
de dimensionnement utilisant ledit outil occupent une partie importante de ce rapport.
Mots cls Mots cls Mots cls Mots cls
NGN, IMS, transport, contrle, services, Media Gateway, Softswitch, convergence,
migration, dimensionnement, optimisation, prvision.

Etude Et Dimensionnement Dâ ™un Reseau NGN

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Etude Et Dimensionnement Dâ ™un Reseau NGN

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN DETUDES

Vous aimerez peut-être aussi