Etude Et Dimensionnement D'un Réseau NGN

RAPPORT DE PROJET DE FIN D’ETUDES
Filière
Ingénieurs en Télécommunications
Option
Réseaux et Services Mobiles
Etude et Dimensionnement d’un

Réseau de Nouvelle Génération (NGN)
Cas d’étude : Tunisie Télécom
Elaboré par :
Abdessalem MRIBAH
Encadré par :
M. Rached HAMZA
M. Anouar ALEYA
Projet réalisé en collaboration entre
Année universitaire : 2005/2006

Dédicaces
A mes chers parents

pour leur soutien moral et financier durant mes études,
à mes deux soeurs Nadia et Khadija

et à mon frère Mohamed Ali
en leur souhaitant la réussite dans leurs études et dans leurs vies,
à tous mes amis de Sup’Com

pour les moments agréables que nous avons passés ensemble,
en leur souhaitant le succès dans leur vie aussi bien
professionnelle que familiale,
à tous ceux qui m’ont aidé afin de réaliser ce travail,
et à tous ceux que j’aime et qui m’aiment.
A tous, je dédie ce travail
Abdessalem
i
Remerciements
Le travail présenté dans ce rapport a été effectué au sein de la société Tunisie Télécom dans
le cadre de mon projet de fin d’études pour l’obtention du diplôme d’ingénieur en
Télécommunications option Réseaux et Services Mobiles à l’Ecole Supérieure Des
Communications De Tunis (Sup’Com).
A son terme, je tiens à exprimer ma profonde gratitude à mon encadreur M. Anouar

ALEYA, ingénieur principal à Tunisie Télécom, qui n’a épargné aucun effort pour le bon
déroulement de ce travail. Ses remarques et ses consignes ont été pour moi d’un grand apport.
Je pense aussi à mon encadreur à Sup’Com M. Rached HAMZA qui m’a aussi tant
encouragé et donné de très bons conseils tout au long de ce travail. Je tiens à le remercier tout
particulièrement.
Mes sincères remerciements iront aussi à tous nos enseignants à Sup’Com pour la qualité de
l’enseignement qu’ils nous ont prodigués durant nos trois années d’études afin de nous donner
une formation efficace, à tout le personnel de l’administration de Sup’Com pour nous assurer
les meilleures conditions de travail.
ii
Table des Matières
Introduction générale.............................................................................................................. 1
Chapitre I : Architecture NGN : Du NGN Téléphonie au NGN Multimédia.................... 3
I.1 Introduction........................................................................................................................ 3
I.2 Définition ........................................................................................................................... 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 entités fonctionnelles du coeur de réseau 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 d’appel ou Media Gateway Controller (MGC) ou Softswitch............. 7
I.6.2 Les familles de protocoles d’un réseau NGN .............................................................. 8
I.6.2.1 Les protocoles de contrôle d’appel ........................................................................ 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 contrôle............................... 9
I.7 NGN Téléphonie .............................................................................................................. 10
I.7.1 Architecture NGN Téléphonie ................................................................................... 10
I.7.2 Services dans le RTC versus Services dans le NGN Téléphonie .............................. 11
I.8 NGN Multimédia ou IMS (IPMultimedia Subsystem) .................................................... 12
I.8.1 Architecture IMS........................................................................................................ 12
I.8.2 Structuration en couche de l’architecture IMS .......................................................... 13
I.8.3 Entités de Réseau 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 multimédia......................................................................... 19
I.9.3 La messagerie unifiée................................................................................................. 19
I.9.4 Le stockage de données.............................................................................................. 19
I.9.5 La messagerie instantanée.......................................................................................... 19
I.9.6 Les services associés à la géolocalisation .................................................................. 20
I.10 Conclusion ..................................................................................................................... 20
Chapitre II : Stratégies de migration des réseaux actuels vers NGN ............................... 21
II.1 Introduction..................................................................................................................... 21
iii
II.2 Migration des réseaux fixes vers NGN........................................................................... 21
II.2.1 Scénario 1 : Mise en place de solutions NGN au niveau de transit......................... 22
II.2.1.1 Définition.......................................................................................................... 22
II.2.1.2 Impacts sur l’architecture du réseau ................................................................. 23
II.2.1.2.1 Exemple 1 : Migration du trafic téléphonique international sur IP ........ 23
II.2.1.2.2 Exemple 2 : Migration du trafic de transit au niveau national ............... 24
II.2.2 Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur de classe 4.. 24
II.2.2.1 Définition........................................................................................................... 24
II.2.2.2 Impacts sur l’architecture du réseau .................................................................. 24
II.2.3 Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5.............................. 25
II.2.3.1 Définition........................................................................................................... 25
II.2.3.3 Raccordement de l’abonné ................................................................................ 27
II.2.4 Scénario 4 : Mise en place de solutions tout IP en overlay ...................................... 27
II.2.4.2 Les différentes phases de la stratégie de migration overlay .............................. 28
II.3 Migration des réseaux mobiles vers l’IMS..................................................................... 29
II.3.1 UMTS release 99 : l’héritage du GSM/GPRS......................................................... 30
II.3.2 UMTS releases R4/R5 : l’évolution vers le tout IP multimédia.............................. 31
II.3.2.1 UMTS Release R4 : séparation des couches transport et contrôle ................... 31
II.3.2.2 UMTS Release R5 : ajout du domaine IP multimédia ..................................... 31
II.3.3 Influence de l’UMTS sur la stabilisation du concept NGN..................................... 34
II.4 Conclusion ...................................................................................................................... 34
Chapitre III : Processus de dimensionnement d’un réseau NGN..................................... 35
III.1 Introduction ................................................................................................................... 35

III.2 Dimensionnement dans le NGN Téléphonie................................................................. 35
III.2.1 Architecture cible du NGN Téléphonie................................................................. 35
III.2.2 Scénario de migration retenu................................................................................. 36
III.2.3 Modèle de trafic du réseau d’accès ....................................................................... 36
III.2.4 Méthodologie de dimensionnement ...................................................................... 37
III.2.4.1 Organigrammes de dimensionnement du réseau NGN Téléphonie .............. 37
III.2.4.2 Calcul du trafic généré par les réseaux d’accès............................................. 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 réseau de transport.............................................................. 41
III.3 Dimensionnement dans le NGN Multimédia ................................................................ 43
III.3.1 Architecture cible du réseau UMTS...................................................................... 43
III.3.2 Scénario de migration retenu................................................................................. 43
III.3.3 Modèle de trafic du réseau d’accès ....................................................................... 43
III.3.3.1 Les différentes 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 téléchargement ou background ............ 45
III.3.3.2 Modèles de trafic ........................................................................................... 45
III.3.3.2.1 Modèle de trafic pour le service conversationnel............................... 45
III.3.3.2.2 Modèle de trafic pour le service à flux continu.................................. 45
III.3.3.2.3 Modèle de trafic pour le service interactif.......................................... 45
III.3.3.2.4 Modèle de trafic de la classe Background.......................................... 46
III.3.4 Méthodologie du dimensionnement ...................................................................... 46
iv
III.3.4.1 Les hypothèses du dimensionnement ............................................................ 46
III.3.4.2 Organigramme de dimensionnement du réseau NGN Multimédia ............... 47
III.3.4.3 Calcul du trafic généré par le réseau d’accès ................................................ 47
III.3.4.4 Dimensionnement des entités du réseau........................................................ 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 réseau de transport.............................................................. 51
III.4 Conclusion..................................................................................................................... 51
Chapitre IV : Outil de dimensionnement et validation sur des scénarios........................ 52
IV.1 Introduction ................................................................................................................... 52

IV.2 Cahier de charges de l’outil........................................................................................... 52
IV.2.1 Objectif de l'outil de dimensionnement ................................................................ 52
IV.2.2 Paramètres d'entrée ............................................................................................... 52
IV.2.2.1 NGN Téléphonie ........................................................................................... 52
IV.2.2.2 IMS................................................................................................................ 53
IV.2.3 Paramètres de sortie .............................................................................................. 53
IV.2.3.1 NGN Téléphonie ........................................................................................... 53
IV.2.3.2 IMS................................................................................................................ 54
IV.2.4 Interface Utilisateur............................................................................................... 54
IV.3 Environnement de développement ................................................................................ 54
IV.4 Fonctionnalités de l’outil............................................................................................... 55
IV.4.1 Organigramme fonctionnel de l’outil.................................................................... 55
IV.4.2 Modules développés.............................................................................................. 55
IV.4.2.1 Module d’estimation de la charge de trafic pour le NGN Téléphonie.......... 55
IV.4.2.2 Module d’estimation de la charge de trafic pour le NGN Multimédia ......... 56
IV.4.2.3 Module d’optimisation du réseau de transport.............................................. 56
IV.4.2.4 Module de prévision de trafic ....................................................................... 57
IV.5 Interface utilisateur développée .................................................................................... 57
V.5.1 Fenêtre principale de l’outil.................................................................................... 57
V.5.2 Menu NGN Téléphonie .......................................................................................... 59
V.5.3 Menu NGN Multimédia ......................................................................................... 59
V.5.4 Menu Prévision....................................................................................................... 59
V.5.5 Menu Aide .............................................................................................................. 60
IV.6 Validation sur scénarios ................................................................................................ 60
IV.6.1 Cas du réseau NGN Téléphonie............................................................................ 60
IV.6.1.1 Acquisition des paramètres et données d’entrée ........................................... 60
IV.6.1.2 Résultats obtenus........................................................................................... 63
IV.6.2 Cas du réseau NGN Multimédia ........................................................................... 68
IV.6.2.1 Acquisition des paramètres et données d’entrée ........................................... 68
IV.6.2.2 Résultats obtenus........................................................................................... 71
IV.7 Conclusion..................................................................................................................... 78
Conclusion générale .............................................................................................................. 79
Bibliographie ......................................................................................................................... 80
v
Liste des figures
Figure I.1 : Principe général d’architecture d’un réseau NGN.................................................. 4

Figure I.2 : Architecture simplifiée des NGN ........................................................................... 7
Figure I.3 : Les familles de protocoles d’un réseau NGN....................................................... 10
Figure I.4 : Exemple d’architecture NGN Téléphonie ............................................................ 11
Figure I.5 : Services dans le RTC............................................................................................ 11
Figure I.6 : Services dans le NGN Téléphonie........................................................................ 12
Figure I.7 : Exemple d’architecture NGN Multimédia ........................................................... 14
Figure I.8 : Entités de Réseau IMS.......................................................................................... 16
Figure I.9 : Interfonctionnement entre RTC et IMS................................................................ 18
Figure II.1 : Hiérarchie des commutateurs du réseau RTC..................................................... 22
Figure II.2 : Architecture d’une solution NGN pour le trafic de transit international ............ 23
Figure II.3 : Architecture d’une solution NGN pour le trafic de transit national.................... 24
Figure II.4 : Architecture d’une solution NGN de classe 4..................................................... 25
Figure II.5 : Architecture d’un réseau NGN de classe 5 ......................................................... 27
Figure II.6 : Architecture overlay VoIP .................................................................................. 28
Figure II.7 : Les différentes phases de la stratégie de migration overlay................................ 29
Figure II.8 : Architecture domaine circuit UMTS release R4................................................. 31
Figure II.9 : Architecture de référence Release 5.................................................................... 32
Figure III.1 : Mise en place de scénario de migration retenu.................................................. 36
Figure III.2 : Exemple d’une liaison A-C du réseau cœur ...................................................... 42
Figure III.3 : Calcul de la capacité totale à fournir sur la liaison A-C .................................... 42
Figure III.4 : Architecture fonctionnelle du réseau cœur UMTS ............................................ 43
Figure IV.1 : Fenêtre principale de l’outil............................................................................... 58
Figure IV.2 : Fenêtre de création d’un nouveau projet ........................................................... 58
Figure IV.3 : Fenêtre A propos ............................................................................................... 60
Figure IV.4 : Authentification de l’utilisateur......................................................................... 60
Figure IV.5 : Ajout des données de l’opérateur ...................................................................... 61
Figure IV.6 : Saisie des données d’entrée de la zone3-CT1 ................................................... 62
Figure IV.7 : Saisie des données d’entrée de la zone3-CT2 ................................................... 62
Figure IV.8 : Calcul du trafic total généré par les réseaux d’accès......................................... 63
Figure IV.9 : Répartition du trafic RTC/RNIS entre les deux CT de la zone 3 ...................... 63
Figure IV.10 : Répartition du trafic GSM/GPRS entre les trois MSC de la zone 3................ 64
Figure IV.11 : détermination 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 réseau de transport de la zone 3............................................ 65
Figure IV.14 : Prévision du trafic RTC/RNIS de la zone 3 .................................................... 66
Figure IV.15 : Prévision du trafic GSM/GPRS de la zone 3................................................... 66
Figure IV.16 : Prévision des charges des MGs et des softswitchs de la zone 3...................... 67
Figure IV.17 : Extrait du rapport récapitulatif de dimensionnement de la zone 3 .................. 67
Figure IV.18 : Modèle de trafic du réseau d’accès.................................................................. 68
Figure IV.19 : Fixation des paramètres généraux ................................................................... 69
Figure IV.20 : Répartition des paramètres d’entrée par zone.................................................. 70
Figure IV.21 : trafic conversationnel en mode circuit issu des réseaux RTC et GSM ........... 71
Figure IV.22 : Calcul du trafic total généré par les abonnés EDGE et UMTS ....................... 71
Figure IV.23 : Répartition du trafic EDGE entre les cinq zones............................................. 72
Figure IV.24 : Répartition du trafic UMTS entre les cinq zones ............................................ 72
vi
Figure IV.25 : Détermination des charges des entités fonctionnelles ..................................... 72
Figure IV.26 : Détermination du nombre des entités fonctionnelles ...................................... 73
Figure IV.27 : Optimisation du réseau de transport pour les cinq zones ................................ 74
Figure IV.28 : Prévision du trafic EDGE des cinq zones........................................................ 74
Figure IV.29 : Prévision du trafic UMTS des cinq zones ....................................................... 75
Figure IV.30 : Prévision des charges des entités fonctionnelles ............................................. 75
Figure IV.31 : Courbe de prévision des charges des M-MGW et IMS-MGW ....................... 75
Figure IV.32 : Courbe de prévision des charges des MSC Server et MGCF.......................... 76
Figure IV.33 : Courbe de prévision des charges des SGSNs et GGSNs................................. 76
Figure IV.34 : Rapport Technique de dimensionnement des cinq zones................................ 77
vii
Liste des tableaux
Tableau II.1 : Architecture de réseau UMTS R5..................................................................... 33

Tableau IV.1 : Paramètres d’entrée de la zone 3..................................................................... 61
Tableau IV.2 : Répartition des abonnés EDGE et UMTS....................................................... 69
Tableau IV.3 : Pourcentages d’attachement des abonnés EDGE et UMTS............................ 70
Tableau IV.4 : Taux d’activité des services ............................................................................ 70
viii
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 entités .................................. 38
Organigramme III.4 : Organigramme d’optimisation du réseau de transport.......................... 38
Organigramme III.5 : Organigramme récapitulatif du dimensionnement................................ 47
Organigramme III.6 : Répartition de trafic de la classe conversationnelle .............................. 48
Organigramme IV.1 : Principe de fonctionnement de l’outil................................................... 55
Organigramme IV.2 : Estimation de la charge de trafic cas NGN Téléphonie........................ 56
Organigramme IV.3 : Estimation de la charge de trafic cas NGN Multimédia ....................... 56
ix
Liste des abréviations
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 3rd 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
x
RADIUS Remote Access Dial In User Service
RNC Radio Network Controller
RNIS Réseau Numérique à Intégration de Services
RTC Réseau Téléphonique 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 Télécommunications
UMTS Universal Mobile Telecommunication System
UTRAN UMTS Terrestrail Radio Access Network
WDM Wavelength Division Multiplexing
WiFi Wireless Fidelity
xi
Introduction générale
Un réseau peut être vu comme un ensemble de ressources mises en place pour offrir un
ensemble de services. C’est l’évolution des services et des trafics qui en découlent qui a
piloté, dans les dernières années, l’évolution technologique permettant d’augmenter la
capacité et les fonctionnalités des ressources des réseaux. Ainsi, par exemple, le succès des
services de l’Internet a engendré une explosion de trafic ; ce qui a mené les opérateurs à
utiliser de nouvelles technologies dans le coeur des réseaux telles que l’IP sur ATM, le PoS,
l’IP sur WDM et le MPLS.
Les évolutions récentes ont également été fortement influencées par la dérégulation. La
concurrence a amené une baisse des prix de la plupart des services classiques, ce qui a réduit
les revenus des opérateurs. Dès lors que la différenciation par les prix devient difficile, celle-
ci ne peut se faire que par les services et leur qualité. L’offre de services innovants et
l’amélioration de la qualité des services existants, tels que la navigation du Web, requièrent
souvent une évolution de la bande passante à l’accès. Ainsi, des technologies comme le
xDSL, la BLR et les réseaux HFC, se sont développées.
Un point essentiel dans l’évolution de l’offre de services concerne la capacité à regrouper
l’ensemble des services dont le client a besoin et de les lui offrir, si possible de manière
convergente, à travers une interface unique. Cela pousse dans la direction de bâtir des réseaux
multiservices avec convergence entre services. Dans cette situation, le terme "convergence"
(des techniques et des services) est largement utilisé pour désigner la fusion des services et
des techniques. La convergence s'observe ainsi entre la télévision et les télécommunications,
les réseaux fixes et les réseaux mobiles, les télécommunications et l'information, les
ordinateurs et l'électronique grand public. De la convergence découle la nécessité de disposer
d'architectures, de réseaux, d'équipements et d'outils de gestion permettant de répondre aux
besoins des consommateurs, en ce qui concerne les services proposés, et aux besoins
techniques observés au niveau des réseaux pour ce qui est des interfaces entre les
équipements, les réseaux et les services. La nouvelle génération d’architectures de réseaux :
NGN (Next Generation Networks) semblent bien adaptées pour la mise en place de la
convergence voix/données.
Dans ce contexte l’objectif de notre projet de fin d’études est de faire une étude détaillée des
caractéristiques de l’architecture des réseaux NGN et de la migration vers ces nouveaux types
1
de réseaux ainsi que le dimensionnement des entités fonctionnelles de cette architecture en

prenant pour notre cas d’étude le réseau de Tunisie Télécom. Ce processus de
dimensionnement débouchera sur le développement d’un outil universel de dimensionnement
d’un réseau NGN.
Le présent rapport est organisé en quatre chapitres :
Le premier chapitre trace les principales caractéristiques des réseaux NGN en
s'appuyant sur un découpage synthétique de la notion même de réseau nouvelle
génération ; nous nous sommes efforcés de décrire les principales couches, les entités
fonctionnelles, les protocoles mis en jeu, les différents types de réseaux NGN pour
enfin citer les services offerts par les NGN.
Le deuxième chapitre est scindé en deux parties ; dans la première partie, nous avons
essayé de proposer un ensemble de solutions de migration des réseaux fixes vers
l'architecture nouvelle génération tandis que la deuxième partie donne une solution de
migration des réseaux mobiles en s'appuyant sur l'architecture des réseaux de
troisième génération. Dans l'optique d'une stratégie de migration des réseaux mobiles,
nous n'avons pas manqué de décortiquer les spécifications de la 3GPP.
Le troisième chapitre est consacré essentiellement pour détailler le processus du
dimensionnement du réseau NGN. En effet, nous avons décrit les différentes étapes à
suivre pour atteindre notre objectif.
Le dernier chapitre décrit l’outil universel de dimensionnement développé dont le
fonctionnement est basé sur la méthodologie présentée dans le chapitre 3. Une étape
de validation de cet outil sera faite par des scénarios de dimensionnement.
Enfin, nous avons retenu dans une conclusion générale les grandes lignes de ce qui, à notre
sens, mérite une attention toute particulière de la part des lecteurs.
2
Architecture NGN : Du NGN Téléphonie au NGN Multimédia
Chapitre I
Architecture NGN : Du NGN Téléphonie
au NGN Multimédia
I.1 Introduction
Depuis de nombreuses années, l’industrie des télécommunications cherche à orienter sa
technologie de manière à aider les opérateurs à demeurer compétitifs dans un environnement
caractérisé par la concurrence et la déréglementation accrues.
Les réseaux de la prochaine génération (NGN ou Next Generation Networks en anglais), avec
leur architecture répartie, exploitent pleinement des technologies de pointe pour offrir de
nouveaux services sophistiqués et augmenter les recettes des opérateurs tout en réduisant leurs
dépenses d’investissement et leurs coûts d’exploitation.
Ce premier chapitre est consacré à la présentation des réseaux de nouvelle génération. Dans
une première section nous nous sommes intéressés à l’architecture des réseaux NGN, aux
différents éléments qui le composent ainsi qu’aux différents protocoles en concurrence. La
deuxième section met l’accent sur les deux types des réseaux NGN : NGN Téléphonie et
NGN Multimédia (IMS). Enfin, une troisième section qui sera dédiée aux services offerts par
les NGN.
I.2 Définition
Les NGN sont définis comme un réseau de transport en mode paquet permettant la
convergence des réseaux Voix/données et Fixe/Mobile; ces réseaux permettront de fournir des
services multimédia accessibles depuis différents réseaux d’accès.
Afin de s’adapter aux grandes tendances qui sont la recherche de souplesse d’évolution de
réseau, la distribution de l’intelligence dans le réseau, et l’ouverture à des services tiers, les
NGN sont basés sur une évolution progressive vers le « tout IP » et sont modélisés en couches
indépendantes dialoguant via des interfaces ouvertes et normalisées. [1]
La couche « Accès », qui permet l’accès de l’utilisateur aux services via des supports
de transmission et de collecte divers : câble, cuivre, fibre optique, boucle locale radio,
xDSL, réseaux mobiles.
La couche « Transport », qui gère l’acheminement du trafic vers sa destination. En
bordure du réseau de transport, des « Media Gateways » et des « Signalling Gateways
3
» gèrent respectivement la conversion des flux de données et de signalisation aux

interfaces avec les autres ensembles réseau ou les réseaux tiers interconnectés.
La couche « Contrôle », qui se compose de serveurs dits « Softswitch » gérant d’une
part les mécanismes de contrôle d’appel (pilotage de la couche transport, gestion des
adresses), et d’autre part l’accès aux services (profils d’abonnés, accès aux plates-
formes de services à valeur ajoutée).
La couche « Services », qui regroupe les plates-formes d’exécution de services et de
diffusion de contenus. Elle communique avec la couche contrôle du coeur de réseau
via des interfaces ouvertes et normalisées, indépendantes de la nature du réseau
d’accès utilisé. Les services et contenus eux-mêmes sont par ailleurs développés avec
des langages convergents et unifiés.
La figure suivante présente le principe général d'architecture d'un réseau NGN.
Figure I.1 : Principe général d’architecture d’un réseau NGN
I.3 Pourquoi Le NGN ?

Dans certaines parties du monde, le trafic de données prend rapidement le pas sur le trafic
vocal et la tendance est nettement à l’augmentation en bande passante pour les données, tandis
que la voix peut se satisfaire d’une bande passante de 64 kbit/s, voire moindre. Les opérateurs
possédant les deux types de réseaux (réseau voix et réseau de données) utilisent cet argument
pour commencer à les unifier. Il est clair d’après les limites du réseau TDM (Time Division
Multiplexing) que le réseau de données survivra alors que le réseau TDM quittera la scène.
Facteur non moins important : le nouveau besoin chez les usagers d’une variété encore plus
grande d’applications et de services sophistiqués (Push-to-talk, conférence audio et vidéo,
messagerie unifiée, chat) dont la plupart n’étaient même pas envisagés lors de la conception
des réseaux actuels. Pour les opérateurs, l’accès et le transport ne sont plus assez lucratifs et,
4
pour rester compétitif, il leur faudra donc offrir aux usagers toute une gamme de services
utiles, faciles à utiliser et rémunérateurs. Par conséquent, les NGN seront axés sur les
services, et fourniront tous les moyens nécessaires pour en offrir de nouveaux et adapter les
existants pour augmenter les recettes.
Les opérateurs entrants (opérateurs ADSL) pourront envisager d’investir dans une solution
d’emblée NGN. Pour un opérateur établi, l’important est de définir les conditions de
migration de leur réseau téléphonique commuté actuel vers le NGN.
I.4 Types de NGN

Il existe trois types de réseau NGN : NGN Class 4, NGN Class 5 et NGN Multimédia.
Les NGN Class 4 et Class 5 sont des architectures de réseau offrant uniquement les services
de téléphonie. Il s’agit donc de NGN téléphonie. Dans le RTC, un commutateur Class 4 est un
centre de transit. Un commutateur Class 5 est un commutateur d’accès aussi appelé centre à
autonomie d’acheminement. Le NGN Class 4 (respectivement NGN Class 5) émule donc le
réseau téléphonique au niveau transit (respectivement au niveau accès) en transportant la voix
sur un mode paquet.
Le NGN Multimédia est une architecture offrant les services multimédia (messagerie
vocale/vidéo, conférence audio/vidéo, Ring-back tone voix/vidéo) puisque l'usager a un
terminal IP multimédia. Cette solution est plus intéressante que les précédentes puisqu’elle
permet à l’opérateur d’innover en termes de services par rapport à une solution NGN
téléphonie qui se cantonne à offrir des services de téléphonie.
Le Class 4 NGN permet :
Le remplacement des centres de transit téléphoniques (Class 4 Switch).
La croissance du trafic téléphonique en transit.
Le Class 5 NGN permet :
Le remplacement des centres téléphoniques d’accès (Class 5 Switch).
La croissance du trafic téléphonique à l’accès.
La voix sur DSL/ Voix sur le câble.
Le NGN Multimédia permet d’offrir des services multimédia à des usagers disposant d’un
accès large bande tel que xDSL, câble, WiFi/WiMax, EDGE/UMTS, etc.
I.5 Avantages du NGN

Cette nouvelle topologie offre les avantages suivants :
Grâce au NGN, l’opérateur dispose d’un réseau multiservice permettant d’interfacer
n’importe quel type d’accès (Boucle locale, PABX, Commutateur d’accès
téléphonique, accès ADSL, accès mobile GSM ou UMTS, téléphone IP, etc.).
L’opérateur n’aura plus à terme qu’à exploiter un seul réseau multiservice.
5
Elle utilise le transport comme l’IP ou l’ATM ignorant les limites des réseaux TDM
(Time Division Multiplexing) à 64 kbit/s. En effet le TDM perd son efficacité dès lors
que l’on souhaite introduire des services asymétriques, sporadiques ou à débit binaire
variable.
C’est une topologie ouverte qui peut transporter aussi bien les services téléphoniques
que les services de multimédia (vidéo, données temps réel).
Elle dissocie la partie support du réseau de la partie contrôle, leur permettant d’évoluer
séparément et brisant la structure de communication monolithique. En effet, la couche
transport peut être modifiée sans impact sur les couches contrôle et application.
Elle utilise des interfaces ouvertes entre tous les éléments, permettant à l’opérateur
d’acheter les meilleurs produits pour chaque partie de son réseau.
I.6 Architecture NGN

Les principales caractéristiques des réseaux NGN sont l’utilisation d’un unique réseau de
transport en mode paquet (IP, ATM,…) ainsi que la séparation des couches de transport des
flux et de contrôle des communications, qui sont implémentées dans un même équipement
pour un commutateur traditionnel.
Ces grands principes et concernant les équipements actifs du coeur de réseau NGN se
déclinent techniquement comme suit :
Remplacement des commutateurs traditionnels par deux équipements distincts :
D’une part des serveurs de contrôle d’appel dits Softswitch ou Media Gateway
Controller (correspondant schématiquement aux ressources processeur et
mémoire des commutateurs voix traditionnels).
D’autre part des équipements de médiation et de routage dits Media Gateway
(correspondant schématiquement aux cartes d’interfaces et de signalisation et
aux matrices de commutation des commutateurs voix traditionnels), qui
s’appuient sur le réseau de transport mutualisé NGN.
Apparition de nouveaux protocoles de contrôle d’appel et de signalisation entre ces
équipements (de serveur à serveur, et de serveur à Media Gateway).
La figure I.2 présente la structure physique d’un réseau NGN avec les différentes entités
fonctionnelles, les principaux réseaux d’accès ainsi que les différents protocoles mis en
oeuvre.
6
Figure I.2 : Architecture simplifiée des NGN
I.6.1 Les entités fonctionnelles du coeur de réseau NGN

I.6.1.1 La Media Gateway (MG)
La Media Gateway est située au niveau du transport des flux média entre le réseau RTC et les
réseaux en mode paquet, ou entre le coeur de réseau NGN et les réseaux d’accès. Elle a pour
rôle :
Le codage et la mise en paquets du flux média reçu du RTC et vice-versa (conversion
du trafic TDM / IP).
La transmission, suivant les instructions du Media Gateway Controller, des flux média
reçus de part et d'autre.
I.6.1.2 La Signalling Gateway (SG)
La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le
réseau NGN et le réseau externe interconnecté selon un format compréhensible par les
équipements chargés de la traiter, mais sans l’interpréter (ce rôle étant dévolu au Media
Gateway Controller). Notamment, elle assure l’adaptation de la signalisation par rapport au
protocole de transport utilisé (exemple : adaptation TDM / IP).
I.6.1.3 Le serveur d’appel ou Media Gateway Controller (MGC) ou Softswitch
Dans un réseau NGN, c’est le MGC qui possède « l'intelligence ». Il gère :
L’échange des messages de signalisation transmise de part et d'autre avec les
passerelles de signalisation, et l’interprétation de cette signalisation.
Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP,
communication avec les serveurs d’application pour la fourniture des services.
Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du
réseau, etc.
7
La réservation des ressources dans le MG et le contrôle des connexions internes au

MG (commande des Media Gateways).
I.6.2 Les familles de protocoles d’un réseau NGN
La convergence des réseaux voix/données ainsi que le fait d’utiliser un réseau en mode paquet
pour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessité
l’adaptation de la couche contrôle. En effet ces réseaux en mode paquet étaient généralement
utilisés comme réseau de transport mais n’offraient pas de services permettant la gestion des
appels et des communications multimédia. Cette évolution a conduit à l’apparition de
nouveaux protocoles, principalement concernant la gestion des flux multimédia, au sein de la
couche Contrôle.
I.6.2.1 Les protocoles de contrôle d’appel
Les protocoles de contrôle d’appel permettant l’établissement, généralement à l’initiative d’un
utilisateur, d’une communication entre deux terminaux ou entre un terminal et un serveur ; les
deux principaux protocoles sont H.323, norme de l’UIT et SIP, standard développé à
l’IETF.[2]
I.6.2.1.1 Le protocole historique : H.323
La recommandation H.323 de l’UIT décrit les procédures pour les communications audio et
vidéo point à point ou multipoint sur des réseaux en mode paquet. C’est une adaptation des
procédures de vidéoconférence sur RNIS (H.320) aux réseaux sans garantie de service.
Plusieurs entités sont nécessaires à la réalisation d’un service de communication multimédia
sur des réseaux de données :
Les terminaux H.323 sont des systèmes multimédia (téléphone, PC) permettant de
communiquer en « temps réel ».
Le gatekeeper gère les terminaux H.323 (identification et traduction d’adresses) et les
établissements d’appels.
La passerelle H.323 (gateway) permet d’interfacer le réseau IP avec le réseau
téléphonique classique.
L’unité de contrôle MCU (Multipoint Controller Unit) gère les connexions multipoint
(ex. : appels de conférence). Il se décompose en un Multipoint Controller (MC),
affecté à la signalisation, et un Multipoint Processor (MP), dédié à la transmission
proprement dite.
I.6.2.1.2 Le protocole alternatif : SIP
SIP (Session Initiation Protocol) est un protocole de contrôle qui peut établir, modifier et
terminer des sessions multimédia, aussi bien des conférences que des appels téléphoniques sur
des réseaux mode paquets. Il est sous forme de texte, tout comme http ou SMTP, et a pour
8
rôle d’initier des sessions de communications interactives. Ces sessions peuvent inclure aussi
bien de la voix, de la vidéo, des jeux interactifs...
L'architecture de SIP est basée 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 l’adresse SIP du terminal appelé et
la ou les adresses où il pourra effectivement être joignable.
Le Proxy Server remplit la même la fonction qu’un Redirect Server.
Le Registrar est essentiel dans tout réseau SIP ou l’on 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 séparation entre les couches
Transport et Contrôle et permet au Softswitch ou Media Gateway Controller de gérer les
passerelles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de
l’IETF et H.248/MEGACO, développé conjointement par l’UIT et l’IETF, sont actuellement
les protocoles prédominants.
I.6.2.2.1 Le protocole historique : MGCP
Le Media Gateway Control Protocol (MGCP), protocole défini par l’IETF, a été conçu pour
des réseaux de téléphonie IP utilisant des passerelles VoIP. Il gère la communication entre les
Media Gateway et les Media Gateway Controller. Ce protocole traite la signalisation et le
contrôle des appels, d’une part, et les flux média d’autre 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
compléter les travaux sur le protocole MGCP au sein de l’IETF.
Depuis 1999, l’UIT et l’IETF travaillent conjointement sur le développement du protocole
MEGACO/H.248 ; c’est un standard permettant la communication entre les Media Gateway
Controller (MGC) et les Media Gateway (MG). Il est dérivé de MGCP et possède des
améliorations par rapport à celui-ci :
Support de services multimédia et de vidéoconférence.
Possibilité d’utiliser UDP ou TCP.
Utilise le codage en mode texte ou binaire.
I.6.2.3 Les protocoles de signalisation entre les serveurs de contrôle
Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway Controller)
permettant la gestion du plan contrôle :
Au niveau du coeur de réseau avec des protocoles tels que BICC (Bearer Independant
Call Control), SIP-T (SIP pour la téléphonie) et H.323.
9
A l’interconnexion avec les réseaux de signalisation SS7, généralement via des

passerelles de signalisation ou Signalling Gateways par l’utilisation de protocole tel
que SIGTRAN. De plus, l’interconnexion de ces réseaux de données avec les réseaux
existants de téléphonie (TDM avec signalisation SS7) a nécessité le développement de
protocoles dédiés à l’interconnexion des réseaux et au transport de la signalisation SS7
sur des réseaux en mode paquet.
La figure I.3 illustre les niveaux auxquels sont utilisés les différents protocoles cités
précédemment.
Figure I.3 : Les familles de protocoles d’un réseau NGN
I.7 NGN Téléphonie

Comme nous l’avons définit précédemment, le NGN téléphonie est une architecture de réseau
NGN offrant uniquement les services de téléphonie (voix,…).
I.7.1 Architecture NGN Téléphonie
La figure I.4 montre un exemple d’architecture NGN Téléphonie. Les équipements existants
(exemple : commutateur d’accès téléphonique ou BTS/BSC du réseau GSM) sont reliés à une
couche de transport IP ou ATM par le biais de Media Gateways (couche transport).
L’établissement des canaux de communication IP ou ATM entre les Media Gateways est la
responsabilité du MGC appartenant à la couche contrôle.
Le MGC est un serveur d’appel qui contient l’intelligence liée au contrôle de l’appel et pour
ce faire possède un modèle d’appel complet. Le MGC identifie les usagers, détermine le
niveau de service pour chaque usager et l’acheminement de trafic. Par ailleurs, il fournit
toutes les informations permettant la taxation des appels et la mesure des performances du
réseau. Aussi, le MGC s’interface aux serveurs d’applications.
Dans l’architecture NGN Téléphonie, le protocole de contrôle tel que MGCP ou MEGACO
ne fait que décrire les interactions entre le MGC et le MG. Si un MGC doit contrôler un MG
10
qui est sous la responsabilité d’un autre MGC, il est nécessaire que les MGCs s’échangent de
la signalisation.
Une fois la connexion établie, le MG convertira les signaux audio transportés dans les circuits
de parole (terminaison circuit) en paquets IP qui seront transportés dans le réseau IP
(terminaison IP) ou en cellules ATM dans le cas d’un transport ATM.[3]
Figure I.4 : Exemple d’architecture NGN Téléphonie
I.7.2 Services dans le RTC versus Services dans le NGN Téléphonie

Dans le contexte du Réseau Téléphonique Commuté, le commutateur réalise deux fonctions
essentielles :
La commutation de la voix (Media).
Le contrôle de l’appel (établissement / libération d’appel).
Les services à valeur ajoutée sont mis en oeuvre par le réseau intelligent à travers les entités
SCP (Service Control Point) / SRP (Specialized Resource Point).
Les services complémentaires sont mis en oeuvre directement par le commutateur d’accès
(Class 5 Switch).
Figure I.5 : Services dans le RTC
11
Dans le monde NGN, la commutation de la voix est réalisée par le MG entre le réseau
téléphonique commuté et le réseau de transport du NGN. Dans le réseau de transport, ce sont
les commutateurs ATM / Routeurs IP qui assurent le transport de la voix paquétisée jusqu’au
MG de sortie qui commute la parole reconvertie, sur un circuit de parole sortant.
Le contrôle de l’appel (établissement / libération d’appel) est pris en charge par le MGC. Un
MGC Class 4 émule le point sémaphore d’un Class 4 Switch. Un MGC Class 5 émule le point
sémaphore d’un Class 5 Switch.
Les services à valeur ajoutée sont pris en charge par le SCP légataire du réseau intelligent ou
par un serveur d’application SIP et par un serveur de media (appelé Multimedia Resource
Function) qui fonctionne en voix sur IP (il émet des annonces vocales et collecte
l’information de l’usager sur des canaux RTP/UDP/IP).
Figure I.6 : Services dans le NGN Téléphonie
I.8 NGN Multimédia ou IMS (IPMultimedia Subsystem)

L'IMS normalisé par le monde des télécommunications est une nouvelle architecture basée sur
de nouveaux concepts, de nouvelles technologies, de nouveaux partenaires et un nouvel
écosystème. L’IMS supporte sur un réseau tout IP les sessions applicatives temps réels (voix,
vidéo, conférence,…) et non temps réel (Push To Talk, Présence, messagerie instantanée,…).
L’IMS intègre de plus le concept de convergence de services supportés indifféremment par
des réseaux de natures différentes : fixe, mobile ou Internet. L’IMS est également désigné
sous le vocable de NGN Multimédia. [4]
I.8.1 Architecture IMS
L’introduction de l’IMS (IP Multimedia Subsystem) dans les réseaux fixe et mobile
représente un changement fondamental dans les réseaux de télécommunication de type voix.
Les nouvelles capacités des réseaux et des terminaux, le mariage entre l ’Internet et la voix, le
contenu et la mobilité donnent naissance à des nouveaux modèles de réseaux et surtout offrent
un formidable potentiel pour développer de nouveaux services. Dans cet objectif, l ’IMS est
12
conçu pour offrir aux utilisateurs la possibilité d’établir des sessions multimédia en utilisant
tout accès haut débit et une commutation de paquets IP.
L’IMS fournit un réseau IP multi-service, multi-accès, sécurisé et fiable :
Multi-services : tout type de services délivrés par un réseau coeur supportant différents
niveaux de QoS pourront être offerts à l’usager.
Multi-accès: tout réseau d’accès large bande, fixe et mobile pourra s’interfacer à
l’IMS.
L’IMS n’est pas un unique réseau, mais différents réseaux qui interopèrent grâce à des
accords de roaming IMS fixe-fixe, fixe-mobile, mobile-mobiles.
L’IMS est un « enabler » pour les fournisseurs de service afin d’offrir :
Des services de communication non temps-réel, pseudo temps-réel et temps réel
suivant une configuration client-server ou entre entités paires.
La mobilité des services / Mobilité de l’usager (Nomadisme).
Plusieurs sessions et services simultanément sur la même connexion réseau.
I.8.2 Structuration en couche de l’architecture IMS
L’architecture IMS peut être structurée en couches. Quatre couches importantes sont
identifiées :
La couche « accès » peut représenter tout accès haut débit tel que : UTRAN (UMTS
Terrestrial Radio Access Network), CDMA2000 (technologie d’accès large bande
utilisée dans les réseaux mobiles aux Etats-Unis), xDSL, réseau câble, Wireless IP,
WiFi, etc.
La couche « transport » représente un réseau IP. Ce réseau IP pourra intégrer des
mécanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste
donc en des routeurs (edge router à l’accès et en core router en transit) reliés par un
réseau de transmission. Différentes piles de transmission peuvent être considérées
pour le réseau IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc.
La couche « contrôle » consiste en des contrôleurs de session responsables du routage
de la signalisation entre usagers et de l’invocation des services. Ces noeuds s’appellent
des CSCF (Call State Control Function). IMS Introduit donc un environnement de
contrôle de session sur le domaine paquet.
La couche « application » introduit les applications (services à valeur ajoutée)
proposées aux usagers. L’opérateur peut se positionner grâce à sa couche
CONTRÔLE en tant qu’agrégateur de services offerts par l’opérateur lui-même ou par
des tiers. La couche application consiste en des serveurs d’application (AS,
Application Server) et des MRF (Multimedia Resource Function) que les fournisseurs
appellent serveurs de média IP (IP MS, IP Media Server).
13
L’architecture globale IMS est décrite à la figure I.7.
Figure I.7 : Exemple d’architecture NGN Multimédia
I.8.3 Entités de Réseau IMS

I.8.3.1 Terminal IMS
Il s’agit d’une application sur un équipement de l’usager qui émet et reçoit des requêtes SIP. Il
se matérialise par un logiciel installé sur un PC, sur un téléphone IP ou sur une station mobile
UMTS (UE, User Equipment).
I.8.3.2 Home Subscriber Server (HSS)
L’entité HSS (Home Subscriber Server) est la principale base de stockage des données des
usagers et des services auxquels ils ont souscrit. Les principales données stockées sont les
identités de l’usager, les informations d’enregistrement, les paramètres d’accès et les
informations permettant l’invocation des services de l’usager. L’entité HSS interagit avec les
entités du réseau à travers le protocole Diameter.
I.8.3.3 Call State Control Function (CSCF)
Le contrôle d'appel initié par un terminal IMS doit être pris en charge dans le réseau nominal
(réseau auquel l’usager 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 différemment dans un réseau visité, notamment suite à des problèmes
d’interaction de service. Cela a induit la définition de trois entités CSCF : P-CSCF (Proxy
CSCF), I-CSCF (Interrogating CSCF) et S-CSCF (Serving-CSCF).
14
Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS. Son adresse
est découverte par le terminal lors de l'activation d'un contexte PDP pour l’échange 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 reçu).
Les fonctions réalisées par l'entité P-CSCF comprennent :
L'acheminement de la méthode SIP REGISTER émise par le terminal à l'entité I-
CSCF à partir du nom du domaine nominal.
L'acheminement des méthodes SIP émises par le terminal au S-CSCF dont le nom a
été obtenu dans la réponse à la procédure d'enregistrement.
Le routage des méthodes SIP ou réponses SIP au terminal.
La génération de CDRs (Call Detailed Record).
La compression / décompression des messages SIP.
L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un réseau d'opérateur pour
toutes les sessions destinées à un utilisateur de cet opérateur. Il peut exister plusieurs I-CSCF
au sein d'un réseau.
Les fonctions réalisées par l'entité I-CSCF comprennent :
L'assignation d'un S-CSCF à un utilisateur s'enregistrant.
L'acheminement des méthodes SIP reçues depuis un autre réseau, au S-CSCF.
L'obtention de l'adresse du S-CSCF auprès du HSS.
La génération de CDRs.
Le Serving-CSCF (S-CSCF) prend en charge le contrôle de la session. Il maintient un état de
session afin de pouvoir invoquer des services. Dans un réseau d'opérateur, différents S-CSCF
peuvent présenter des fonctionnalités différentes.
Les fonctions réalisées par le S-CSCF pendant une session comprennent :
L'émulation de la fonction Registrar puisqu'il accepte les méthodes SIP
d'enregistrement et met à jour le HSS.
L'émulation de la fonction Proxy server puisqu'il accepte les méthodes SIP et les
achemine.
L'émulation de la fonction User Agent puisqu'il peut terminer des méthodes SIP par
exemple lorsqu'il exécute des services complémentaires.
L'interaction avec des serveurs d'application après avoir analysé les critères de
déclenchement des services correspondants.
La génération de CDRs.
15
Avant de pouvoir utiliser les services du domaine IM, tels qu'établir une session multimédia
ou recevoir une demande de session, un usager doit s'enregistrer au réseau. Que l'usager soit
dans son réseau nominal ou dans un réseau visité, cette procédure fait intervenir un P-CSCF.
Par ailleurs, tous les messages de signalisation émis par le terminal ou à destination du
terminal sont relayés 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 : Entités de Réseau 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 présente un plan de
contrôle (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 média. Des entités sont responsables de créer, maintenir et
libérer des connexions dans ces passerelles; il s'agit de contrôleurs de passerelles (MGCF,
Media Gateway Control Function). Par ailleurs, ce même MGC termine la signalisation ISUP
du côté RTC qu'il convertit en signalisation SIP qui est délivrée au domaine IMS. Les
messages ISUP provenant du RTC sont d'abord acheminés 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 entités :
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
Reçoit un trafic de parole du RTCP et l'achemine sur un réseau IP. Le trafic audio est
transporté sur RTP/UDP/IP.
16
Supporte généralement des fonctions de conversion du média et de traitement du

média (annulation d'écho, pont de conférence).
Est contrôlé par le MGCF à travers le protocole MEGACO/H.248.
I.8.3.4.2 Le MGCF
Comme les entités CSCF, n'appartient qu'au plan de contrôle et non au plan média.
Contrôle l'IMS-MGW afin d'établir, maintenir et libérer des connexions dans l'IMS-
MGW. Une connexion correspond par exemple à une association entre une
terminaison TDM (terminaison du côté 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 reçue et qui est encodée à l'aide du codec G.711, en parole encodée 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).
Sélectionne le CSCF approprié afin de remettre la signalisation SIP qu'il génère, au
sous-système IMS.
I.8.3.4.3 Le T-SGW
Assure la conversion du transport pour l'acheminement de la signalisation ISUP entre
le commutateur téléphonique et le MGCF. La signalisation ISUP est échangée :
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 représente un appel initié par le RTCP et à destination d'un terminal dans le
sous- système IMS.
Le commutateur du RTC réserve 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 crée 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 téléphonique. La terminaison RTP termine les canaux RTP entre l'IMS-
MGW et le terminal IMS.
L'IMS-MGW retourne une réponse à l'entité MGCF ; cette réponse contient un "local
descriptor" qui correspond à la description SDP associée à sa terminaison RTP.
17
L'entité MGCF génère une méthode SIP INVITE contenant la description SDP retournée par
l'IMS-MGW. Cette méthode est envoyée au sous-système IMS qui se charge de la délivrer au
terminal IMS appelé.
Figure I.9 : Interfonctionnement entre RTC et IMS
I.9 Les services offerts par les NGN

Les NGN offrent les capacités, en termes d’infrastructure, de protocole et de gestion, de créer
et de déployer de nouveaux services multimédia sur des réseaux en mode paquet.
La grande diversité des services est due aux multiples possibilités offertes par les réseaux
NGN en termes de :
Support multimédia (données, 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 différents terminaux.
Parmi ces services offerts nous citons :
I.9.1 La voix sur IP
La voix sur IP est un service directement lié à l’évolution vers les réseaux NGN. C’est une
application qui est apparue depuis longtemps mais qui n’a pas encore eu le succès escompté,
et cela pour différentes 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 déployer de services téléphoniques sur IP.
Le seul fait de transporter la voix sur IP n’apporte pas de valeur ajoutée pour
l’utilisateur final, par rapport au service de voix classique. Les services associés à la
voix sur IP n’ont pas encore la maturité nécessaire pour pousser l’évolution vers ces
nouveaux réseaux.
18
La nécessité d’interconnecter les réseaux IP aux réseaux TDM/SS7 implique des coûts
liés aux équipements d’interconnexion (passerelles) et le prix des terminaux (IP
phones) annihile l’avantage financier apporté par le transport en IP.
Le coût des terminaux IP reste encore supérieur à celui des équipements classiques
(pas encore d’économies d’échelle suffisantes).
Cependant l’évolution de la technologie et des protocoles et l’apparition de services associés
au monde IP devraient permettre l’émergence de la voix sur IP. De plus, l’évolution des
terminaux communicants multimédia est un argument supplémentaire à l’évolution des
réseaux téléphoniques vers la voix sur IP ; ainsi l’UMTS, dans la release 5, généralise le
transport en IP au réseau voix.
I.9.2 La diffusion de contenus multimédia
La diffusion de contenu multimédia regroupe deux activités ; l’une focalisée sur la mise en
forme des contenus multimédia, l’autre centrée sur l’agrégation de ces divers contenus via des
portails.
Les outils technologiques, tels que le multimédia streaming (gestion d’un flux multimédia en
termes de bande passante et de synchronisation des données) et le protocole multicast, doivent
permettre de fournir un service de diffusion de contenu aux utilisateurs finaux.
I.9.3 La messagerie unifiée
Le service de messagerie unifiée est l’un des services les plus avancés : c’est le premier
exemple de convergence et d’accès à l‘information à partir des différents moyens d’accès. Le
principe est de centraliser tous les types de messages, vocaux (téléphoniques), écrits (email,
SMS), multimédia sur un serveur ; ce dernier ayant la charge de fournir un accès aux
messages adapté au type du terminal de l’utilisateur. 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 données
L’augmentation de capacité des réseaux et la gestion des flux permettent de proposer des
services de stockage de données, en tant que sauvegarde de données critiques sur des sites
protégés, mais aussi en tant qu’accès « local » à un contenu (serveur « proxy » ou « cache »).
En effet, les volumes de données évoluant de façon exponentielle, la nécessité d’offrir les
services à partir des serveurs « locaux » semble indispensable. Cet aspect semble notamment
indispensable pour les applications de télévision interactive et de video on demand.
I.9.5 La messagerie instantanée
Cette application a déjà un grand succès auprès des internautes : elle permet de dialoguer en
temps réel, à plusieurs, sur un terminal IP (généralement un PC) ayant accès à Internet via une
19
interface texte. Cependant, il est nécessaire d’installer sur son terminal un logiciel propriétaire
permettant de se connecter à un fournisseur d’accès ; il n’est alors possible de communiquer
qu’avec les utilisateurs souscrivant au même service. L’évolution des réseaux devrait
permettre la standardisation de cette application et la communication entre tous (ouverture du
service) à partir de n’importe quel terminal.
C’est l’évolution du service SMS, par l’apport de l’interactivité et du multimédia (MMS).
I.9.6 Les services associés à la géolocalisation
La possibilité de localiser géographiquement les terminaux mobiles a été rapidement perçue
comme une source de revenus supplémentaires. En effet, la géolocalisation permet de
proposer aux utilisateurs finaux des services très ciblés à haute valeur ajoutée liés au contexte
(exemple : horaire, climat) et au lieu.
Actuellement plusieurs solutions techniques existent et sont même en cours d’implémentation
dans les réseaux d’opérateurs mobiles. Cependant, si ces solutions offrent la capacité de
localiser les terminaux mobiles, il n’existe pas encore d’interfaces permettant l’exploitation de
ces données par les applications de services, ou de réelle volonté des opérateurs d’ouvrir leurs
serveurs de localisation à des fournisseurs de services tiers, afin d’utiliser cette fonction de
localisation comme « service capability server » (élément de base servant de support à la
réalisation des services).
I.10 Conclusion
La connaissance des principes sur lesquels sont fondés les NGN, les types des réseaux NGN
existants ainsi que les différents services réellement pertinents dans ce cadre, sont des étapes
nécessaires pour pouvoir comprendre les stratégies d'évolution des réseaux actuels fixes ou
mobiles vers une architecture multiservice.
L'objectif du chapitre suivant est justement la proposition de stratégies de migration des
réseaux actuels vers une architecture de type NGN en tenant compte des problèmes listés dans
ce chapitre.
20
Stratégies de migration des réseaux actuels vers NGN
Chapitre II
Stratégies de migration des réseaux actuels
vers NGN
II.1 Introduction
L’évolution d’un réseau existant vers la nouvelle structure nécessitera une stratégie de
migration progressive visant à réduire au minimum les dépenses d’investissement pendant la
phase de transition, tout en tirant parti très tôt des avantages qu’elle présente. Toute démarche
entreprise lors de cette étape de transition devra simplifier l’évolution du réseau vers
l’architecture NGN à commutation de paquets. Pendant plusieurs années encore, les services
de commutation traditionnels vont devoir coexister avec des éléments de réseau mettant en
oeuvre de nouvelles technologies.
La première partie de ce chapitre est consacrée à la migration des réseaux fixes vers une
architecture NGN. Dans la deuxième partie, nous proposons différentes solutions de migration
des réseaux mobiles vers une architecture NGN Multimédia (IMS) avec une étude des
évolutions majeures au sein du coeur du réseau UMTS.
II.2 Migration des réseaux fixes vers NGN

Dans cette partie, nous proposons un ensemble de solutions correspondant au besoin de
n’importe quel type d’opérateurs de réseau voulant évoluer son réseau téléphonique à
commutation de circuits vers une architecture NGN à commutation de paquets.
La mise en place d’architectures NGN peut se faire avec une plus ou moins grande ampleur,
selon que l’utilisation des technologies NGN s’approche ou non au plus près de l’utilisateur
final. Le choix de déploiement à retenir conditionne en grande partie les bénéfices à attendre
de la mise en place d’un réseau NGN du point de vue de l’économie de coût. Quatre grands
scénarios peuvent ainsi être dégagés [5] :
Scénario 1 : Mise en place de solutions NGN en transit.
Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur de classe 4.
Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5.
Scénario 4 : Mise en place de solutions tout IP en overlay.
21
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 d’acheminement
(CAA).
Commutateurs de classe 3 pour tous les commutateurs situés dans les zones de transit
(régional, national ou international).
Figure II.1 : Hiérarchie des commutateurs du réseau RTC
II.2.1 Scénario 1 : Mise en place de solutions NGN au niveau de transit

II.2.1.1 Définition
Dans ce scénario, l’opérateur utilise des technologies NGN pour son coeur de réseau, mais
dès que l’on s’approche des commutateurs de classe 4, le trafic continue à être supporté par le
réseau traditionnel. Cette démarche est mise en place par un grand nombre d’opérateurs
mondiaux, précisément sur ces fonctions de transit que ce soit au niveau régional, national ou
international. Il s’agit de la première étape de la migration d’un réseau traditionnel vers un
réseau NGN pour nombre d’entre eux. Le principal bénéfice pour un opérateur est la
réduction de coût sur les communications internationales et nationales.
A l’international, pour un opérateur étranger, l’implémentation d’une solution NGN au
niveau transit permet d’utiliser un lien IP afin de transporter des communications
vocales plutôt que d’avoir recours à la location d’une liaison louée auprès de
l’opérateur historique local.
22
Au niveau national, un opérateur pourra réduire également ses coûts s’il loue ses liens,
en particulier car il aura besoin de moins de lien physiques du fait de l’absence de
nécessité d’un réseau maillé.
II.2.1.2 Impacts sur l’architecture du réseau
Ce type de solution impacte le trafic entre les commutateurs de transit au niveau national ou
international. Concrètement, il s’agit d’installer des passerelles media (Media Gateway)
assurant l’interface entre le réseau IP de transport des données avec le réseau téléphonique
TDM traditionnel. Les passerelles sont alors administrées à distance par un softswitch dans le
cadre d’une architecture centralisée en utilisant en général les protocoles de signalisation
MGCP/H.248.
II.2.1.2.1 Exemple 1 : Migration du trafic téléphonique international sur IP
Pour un opérateur souhaitant déployer une solution VoIP pour son trafic international il suffit
d’implémenter (voir figure II.2) :
Un softswitch qui centralisera le contrôle des appels, le routage du trafic et la gestion
des aspects de signalisation. Ce softswitch remplacera le (ou les) commutateur(s) de
transit international TDM existant(s).
Des passerelles media dans les PoP (Points de Présence) situés dans les pays où
l’opérateur veut s’interconnecter au réseau national TDM.
Figure II.2 : Architecture d’une solution NGN pour le trafic de transit international
23
II.2.1.2.2 Exemple 2 : Migration du trafic de transit au niveau national

Au niveau national, l’approche est similaire sauf que ce sont les commutateurs de classe 3 et
de niveau hiérarchiques supérieurs qui seront remplacés par un ou plusieurs softswitch et
passerelles media. Evidemment les commutateurs TDM de classe 4 et 5 sont conservés et
assurent la livraison des communications téléphoniques TDM de manière tout à fait classique
aux abonnés.
Figure II.3 : Architecture d’une solution NGN pour le trafic de transit national
II.2.2 Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur

de classe 4
L’opérateur choisit de mettre en place une architecture NGN qui a vocation également à
agréger le trafic local, et conserve son réseau d’accès traditionnel. Ce scénario constitue une
prolongation naturelle du premier.
Le trafic entre commutateurs d'abonnés TDM traditionnels est en fait détourné sur une
infrastructure VoIP. Pour cela, l’opérateur connecte ses commutateurs d'abonnés à des
gateways VoIP et des softswitchs de classe 4. D’un point de vue architectural, il s’agit de la
même solution que pour le scénario précédent à un niveau différent du réseau plus proche de
l’abonné. En effet un commutateur de classe 4 ne diffère d’un commutateur de classe 3 ou de
niveau hiérarchique supérieur uniquement par sa capacité de traitement de données. Il
n’intègre aucune intelligence réseau. Du coup, pour le réseau NGN, la différence se traduira
uniquement par la nature des capacités supportées par les media gateways et softswitchs.
24
Figure II.4 : Architecture d’une solution NGN de classe 4
Cette étape permet en fait de fusionner les infrastructures longue distance voix et données sur
une même épine dorsale IP. Ultérieurement, l'opérateur peut remplacer ses commutateurs
locaux d'abonnés TDM par des softswitchs de classe 5. Deux opérateurs peuvent interopérer
leur réseau NGN de classe 4 en s’interconnectant au niveau d’un softswitch pour l’échange de
signalisation relative à l’acheminement du trafic. Le trafic transite alors par un lien IP (non
représenté sur la figure) entre les deux infrastructures de coeur de réseau IP. A court terme,
cette démarche permet également de conserver des class 5 traditionnels qui disposent de
certaines capacités qu’il est difficile de rendre avec des solutions logicielles (prise de ligne au
décrochage par exemple).
II.2.3 Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5
Les commutateurs de classe 5 constituent le point de raccordement avec l’abonné pour la
fourniture des services voix basiques. Les opérateurs historiques possèdent plusieurs milliers
de ces commutateurs et de part leur position stratégique dans leur réseau ont été peu enclins
jusqu’à présent à les remplacer par une solution NGN. Toutefois, compte tenu de la forte
progression de la pénétration des services haut débit et du déclin de la demande en services de
téléphonie traditionnelle, les opérateurs considèrent de plus en plus l’opportunité de faire
converger leur infrastructure d’accès vers une plate-forme IP commune.
Dans le cadre d’une migration de classe 5, l’opérateur réalise une migration complète, et tout
le trafic transitant dans le réseau sera supporté par une architecture NGN. Cette approche
permet la fourniture de bout en bout de services VoIP à condition que l’utilisateur final utilise
un équipement IP. De loin la plus complexe, cette étape est aujourd’hui assez peu répandue.
25

L'opérateur remplace ses commutateurs locaux TDM par des softswitchs de classe 5. A la
différence des solutions de classe 4, les serveurs d’appels de classe 5 peuvent supporter tous
les types de services proposés par les commutateurs traditionnels locaux et servir tous les
types de terminaux raccordés au réseau IP, directement ou par l’intermédiaire de MSAN («
MultiService Access Node »).
Le commutateur de classe 5 commute le trafic localement et le transfère vers le réseau de
transit s’il n’est pas en mesure de se connecter directement au commutateur de classe 5 du
destinataire de l’appel. Comme les fonctions logiques de concentrateur et de commutateur
local sont souvent intégrées au sein d’un unique équipement, traditionnellement ils sont
fournis par le même équipementier et la signalisation entre ces éléments est souvent
propriétaire. C’est une manière de garder un client captif pour un vendeur si bien que les
interfaces standardisées (V5.1 et V5.2) sont rarement disponibles sur les commutateurs
actuellement en service dans les réseaux RTC des opérateurs historiques.
Du coup, le passage à un réseau NGN en classe 5 s’avère plus compliqué car faire migrer les
commutateurs locaux revient également à faire évoluer les concentrateurs qui leur sont
rattachés. En outre, au-delà du service vocal basique, un réseau RTC fournit de nombreux
services à valeur ajoutée, comme par exemple :
Identification du numéro de l’appelant.
Messagerie vocale.
Appel en attente.
Interception d’appel.
Horloge parlante.
La fourniture de ces services est assurée par les commutateurs TDM de classe 5 auxquels le
réseau IN s’interconnecte. Par conséquent, la suppression d’un commutateur de classe 5
rompt le lien avec le réseau intelligent existant. L’implémentation du softswitch doit prendre
ces éléments en compte et garantir la continuité de services pour l’abonné soit en re-créant le
lien IN soit en implémentant les mêmes services sur une nouvelle plate-forme IN. Dans la
perspective stratégique de l’opérateur visant à utiliser une solution NGN comme support de
nouveaux services, la deuxième solution sera privilégiée mais nécessitera des investissements
additionnels. Il en va de même au niveau du système de facturation également raccordé au
commutateur de classe 5. L’implémentation d’un nouveau système de facturation pour la
solution NGN n’est en soit pas très onéreuse mais s’assurer de sa bonne intégration avec les
systèmes de facturation existants est autrement plus compliquée.
En conclusion, une migration de classe 5 s’avère être un véritable « big bang » au niveau du
réseau de l’opérateur et cela est d’autant plus coûteux et complexe que le réseau est important.
26
II.2.3.3 Raccordement de l’abonné

Dans le cadre d’une migration NGN de classe 5, le raccordement des abonnés se fait avec un
lien IP. Possédant rarement des infrastructures TDM, les opérateurs alternatifs fournissent des
services VoIP basés sur les technologies d’accès haut débits DSL ou FTTH et les administrent
via le déploiement de softswitchs assumant les fonctionnalités de commutateurs de classe 4 et
5.
Les opérateurs historiques, eux, doivent aussi garantir la continuité de leurs services TDM
actuels. Certains opérateurs ont ainsi choisi de conserver leurs commutateurs TDM et de les
équiper de nouvelles cartes afin de faire migrer graduellement le réseau traditionnel vers une
architecture NGN de classe 5 tandis que l’opérateur déploiera directement de nouveaux
softswitchs pour supporter de nouveaux services basés sur des technologies haut débit. On
voit apparaître une nouvelle génération d’équipements d’accès haut débit baptisés IMAP
(Integrated Multiservice Access Platforms) ou MSAN (Multiservice Access Node) qui savent
gérer aussi bien des lignes haut débit que des accès RNIS ou analogiques. Ces équipements se
connectent au réseau IP de l'opérateur et offrent le service téléphonique sous le contrôle du
softswitch de classe 5. Ils permettent aux opérateurs historiques de continuer à fournir des
services traditionnels, et de continuer à remplir leurs obligations réglementaires, tout en tirant
parti des solutions de softswitch IP.
Figure II.5 : Architecture d’un réseau NGN de classe 5
II.2.4 Scénario 4 : Mise en place de solutions tout IP en overlay

Dans ce cas, l’opérateur déploie une architecture entièrement basée sur IP, qui n’a pas besoin
de se connecter au réseau de commutation existant, ceci en parallèle du réseau traditionnel,
qui continue à vivre sa vie indépendamment. Ce type de solution est particulièrement adapté
aux opérateurs historiques qui sont confrontés à une forte chute des revenus de téléphonie
classique et qui, pour protéger leur base de clientèle, doivent lancer des solutions innovantes
basés sur des technologies alternatives (DSL, FTTH, câble, …).
Ce type d’approche est bien évidemment plus répandue auprès d’opérateurs alternatifs, qui
dans la plupart des cas n’ont pas de réseau traditionnel à administrer.
27

Le réseau paquet en overlay fournit les services à valeur ajoutée tandis que le réseau TDM
traditionnel continue d’assurer le support des services téléphoniques de base. Les deux
réseaux s’interconnectent via le déploiement de passerelles (les media gateways dans la figure
ci-dessous) afin de garantir une terminaison d’appel sur un téléphone classique alors que
l’appelant utilise un téléphone IP et inversement. Les réseaux VoIP et PSTN restent
clairement séparés, au niveau du transport du trafic et de la signalisation.
Figure II.6 : Architecture overlay VoIP
II.2.4.2 Les différentes phases de la stratégie de migration overlay

La stratégie overlay est intimement liée à la stratégie de déploiement du réseau d’accès haut
débit de l’opérateur. En effet, de la vitesse de déploiement du réseau DSL et du rythme des
abonnements haut débit dépendent la date de migration complète des abonnés RTC vers le
réseau NGN.
Il n’y a pas de migration active des abonnés RTC existants à court terme. Toutefois, à plus
long terme, quand le réseau RTC deviendra trop coûteux à entretenir, la migration pourra être
accélérée afin de procéder à la fermeture complète du réseau RTC. Des initiatives
commerciales pourront être mises en place à cet effet par l’opérateur. Malgré tout, même si
les abonnés de la nouvelle plate-forme vont essentiellement utiliser des services VoIP, il n’en
demeure pas moins que certains d’entre eux voudront conserver un accès à un service RTC et
continuer à utiliser leur téléphone traditionnel. En conséquence, des interfaces RTC devront
être conservées sur les passerelles résidentielles.
Ci-après est présentée la stratégie typique de migration, avec mise en place d’un réseau IP,
envisagée par les grands opérateurs (Figure II.7) :
Phase 1 : Le DSL tel qu’il est déployé aujourd’hui permet de supporter sur une même
ligne des services vocaux RTC classiques et des services de données en haut débit sur
28
une même paire de cuivre grâce à l’usage de filtres. La carte de la ligne d’abonné est
localisée dans le concentrateur local.
Phase 2 : Le DSLAM 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 localisées dans le MSAN et la signalisation s’effectue entre le MSAN et le
commutateur RTC de classe 5 via les interfaces V5.1 ou V5.2. Les nouveaux abonnés
DSL devraient être raccordés à cette nouvelle plate-forme pour les services vocaux et
données.
Phase 3 : Le MSAN est mis à niveau pour devenir un pur équipement IP, qui assume
la terminaison des appels vocaux RTC et les convertit en VoIP. Un softswitch est
désormais nécessaire puisque le commutateur de classe 5 n’est plus relié directement
au MSAN. Une passerelle media doit aussi être ajoutée au réseau afin d’assurer la
connexion entre le réseau RTC existant et la plate-forme IP pour supporter les appels
IP vers RTC. Les abonnés existants et les nouveaux abonnés migrent automatiquement
vers la VoIP, même si le service qu’ils reçoivent est toujours de type RTC.
Phase 4 : Une fois que la migration a attiré suffisamment d’utilisateurs et que
l’opérateur est prêt, le reste des abonnés RTC peut être transféré sur la nouvelle plate-
forme IP et le réseau RTC peut alors être définitivement abondonné.
Figure II.7 : Les différentes phases de la stratégie de migration overlay
II.3 Migration des réseaux mobiles vers l’IMS

Les réseaux mobiles sont confrontés aux contraintes de flexibilité de gestion, d’ouverture de
services mais aussi de déploiements d’équipements. En outre, ce sont les même besoins que
les réseaux fixes qui ont générés ce besoin de convergence; à savoir : une évolution
technologique d’envergure et une demande pour un réseau de services universel.
29
L’évolution des réseaux mobiles vers une architecture multiservice a suivie une tendance plus
régulière aussi bien au niveau technologique que sur le plan de la normalisation. En effet,
partant du réseau GSM pour le transport de la voix et qui est basé sur la commutation de
circuits, le besoin de convergence voix/données a donné naissance au GPRS. Ce fut une
évolution majeure du GSM par l’utilisation de la commutation de paquets et l’augmentation
des débits, la génération 2.5, le GPRS, a ouvert la porte aux applications multimédia et
implicitement une transition vers les réseaux de troisième génération : l’UMTS est né. Ce
dernier est le premier système qui inclut dans ses spécifications une évolution vers
l’architecture du futur : le NGN.
Dans cette partie, nous allons présenter les évolutions majeures au sein du coeur du réseau
UMTS.
II.3.1 UMTS release 99 : l’héritage du GSM/GPRS
L’architecture UMTS telle que décrite dans la release 99 du 3GPP s’appuie sur une nouvelle
interface radio, l’UTRA, et une évolution des coeurs de réseau GSM et GPRS (adaptation des
équipements existants ou nouveaux équipements) pour gérer les flux des domaines circuit et
paquet.
Dans l’architecture UMTS R99 :
Les interfaces de l’UTRA avec le coeur de réseau sont basées sur un transport ATM
(AAL2 pour la voix, AAL5 pour les données).
Le transport dans le coeur de réseau peut ensuite être effectué (au choix de
l’opérateur) soit en ATM pour l’ensemble des flux, soit en ATM puis TDM pour les
flux circuit et en IP pour les flux paquet. La signalisation à l’interface avec l’UTRA
est transportée soit dans des circuits virtuels ATM, soit avec le protocole de transport
de SS7 sur IP SIGTRAN.
Les appels multimédia sont supportés, mais de manière transparente. En effet, les
messages de signalisation multimédia sont transportés de manière transparente dans
une connexion circuit ou dans un contexte PDP (tunnel GTP entre SGSN et GGSN),
ce qui évite d’introduire des fonctions multimédia dans les équipements GSM et
GPRS, limitant les impacts aux terminaux et à l’ajout de serveurs multimédia
(gatekeepers). Les protocoles de contrôle d’appel multimédia retenus sont H.323 pour
le domaine paquet et H.324-M pour le domaine circuit, choix plus conforme à la
maturité actuelle des protocoles (par rapport à SIP). Cependant, le transport de la
signalisation multimédia étant transparent, SIP pourrait a priori être supporté de la
même manière.
La R99 prépare donc l’évolution vers la solution cible tout IP en introduisant dès les débuts de
l’UMTS un transport convergent des flux voix et données. Les versions ultérieures de la
30
norme UMTS intègrent une évolution encore plus nette vers une architecture de type NGN.
La release R4 (ex-R99) est la première étape vers un coeur de réseau tout IP, et la release R5
finalise cette évolution.
II.3.2 UMTS releases R4/R5 : l’évolution vers le tout IP multimédia
Alors que la release 99 UMTS a principalement pour vocation de gérer une transition douce
avec le GSM/GPRS, la release 4 (anciennement dénommée release 2000) de l’UMTS propose
une architecture résolument novatrice afin d’évoluer vers le tout IP multimédia.
Suite aux discussions techniques au sein du 3GPP et afin de prendre en compte la maturité des
produits et solutions nouvelles, les évolutions de l’UMTS prévues dans cette version ont été
échelonnées dans le temps et réparties sur deux versions successives, rebaptisées R4 et R5. [6]
II.3.2.1 UMTS Release R4 : séparation des couches transport et contrôle
Conformément à l’un des concepts de base des NGN, la version R4 de la norme UMTS
prévoit une évolution optionnelle du domaine circuit, sous la forme d’une restructuration
fonctionnelle des MSC pour introduire une séparation des couches transport (Media Gateway)
et contrôle d’appel (MSC server).
Le MSC server a les mêmes caractéristiques qu’un MGC (Media Gateway Controller),
avec en complément des fonctions spécifiques 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 spécifiées par le 3GPP.
Cette signalisation peut être transportée en utilisant le protocole MTP3b si le transport
s’appuie sur une couche ATM, ou SIGTRAN (SCTP) si le transport s’appuie sur IP.
Figure II.8 : Architecture domaine circuit UMTS release R4
II.3.2.2 UMTS Release R5 : ajout du domaine IP multimédia

La release R5 introduit un nouveau domaine, l’IP Multimédia (IM) Subsystem, s’appuyant sur
les services du domaine paquet pour fournir des services de communications convergents
(voix sur IP, données, multimédia…) en IP natif. Ainsi, les communications multimédia ne
31
sont plus supportées de manière transparente mais deviennent le mode de communication

cible de l’UMTS. Ce n’est que pour des raisons de compatibilité avec les réseaux GSM/GPRS
et UMTS R99 et avec les terminaux non IP multimédia que le domaine circuit (MSC servers
et MGW associées) est maintenu.
Le coeur de réseau UMTS IP multimédia utilise le protocole SIP pour gérer les sessions IP
multimédia, et le protocole IP pour le transport du trafic et de la signalisation associés. Il
supporte l’interfonctionnement avec les réseaux voix et données IP fixes et mobile existants, y
compris Internet.
Le choix du protocole de contrôle d’appel pour les appels VoIP et multimédia a fait l’objet de
longues discussions, mais SIP a fini par s’imposer au 3GPP grâce à son caractère IP natif et
son apparente simplicité comparé à H.323. Le protocole SIP de l’IETF doit cependant être
enrichi pour prendre en compte certaines évolutions spécifiées par le 3GPP pour un usage
dans le coeur de réseau UMTS, notamment concernant les spécificités liées à la gestion de la
mobilité.
Figure II.9 : Architecture de référence Release 5
Pour assurer le contrôle d’appel et la gestion de la signalisation dans ce nouveau domaine, de

nouvelles entités sont ajoutées, ou des équipements existants sont modifiés. Le tableau II.1 en
fait une synthèse, ainsi qu’une correspondance avec les fonctions NGN présentées dans le
rapport.
En terme de gestion de la mobilité, le HSS UMTS est chargé de la mise à jour du profil
utilisateur, et peut intégrer ou coopérer avec des entités standards dans le monde IP, comme
un serveur distant d’authentification et d’autorisation (RADIUS) ou un serveur gérant la
résolution d’adresse et l’allocation dynamique d’adresse IP (fonctions DNS et DHCP).
32
Avec la R5 UMTS, le transport IP se généralise progressivement à l’ensemble du réseau, et

IPv6 est introduit dans le coeur de réseau :
Il est à noter que les interfaces de transport en sortie de l’UTRA, qui étaient de type
ATM en R99, évoluent en IP en R5 (l’évolution du transport en IP au sein de l’UTRA
et sur la voie radio étant prévue pour des étapes ultérieures de la norme).
Le protocole de transport spécifié pour le domaine paquet est IP (entre RNC, SGSN et
GGSN), avec support des options IPv4 et IPv6.
Au sein du domaine IP Multimédia (éléments IP multimédia du coeur de réseau +
équipements terminaux associés), la norme spécifie l’utilisation exclusive d’IPv6, et
un usage optimal d’IPv6 doit être fait.
Interopérabilité IPv4/IPv6 : les équipements terminaux IP multimédia doivent pouvoir
accéder à des applications IPv4 et IPv6, et le coeur de réseau doit assurer si nécessaire
l’interopérabilité entre son transport IPv6 et un réseau IPv4 externe.
Correspondance architecture
Fonction UMTS Rôle
NGN
Contrôle d’appel multimédia Serveur SIP évolué (ajout
CSCF (Call State
Dialogue avec le MGCF avec le fonctions spécifiées par le
Control Server)
protocole SIP-T 3GPP)
Contrôle de la ou des Media
MGCF (Media
Gateways qui lui sont rattachées, Media Gateway Controller
Gateway Controller
avec le protocole H.248 (+ (Cf. IEFT, groupe Megaco)
Function)
extensions 3GPP)
Gestion de l’interfonctionnement
T-SGW (Transport de la signalisation avec le réseau
Signalling Gateway
Signalling Gateway) commuté fixe (adaptation des
couches basses)
Gestion de l’interfonctionnement
de l’itinérance entre le réseau
R-SGW (Roaming UMTS R4/R5 et les réseaux UMTS Signalling Gateway
Signalling Gateway) R99, GSM et GPRS, avec Spécifique mobile
adaptation des couches basses de
signalisation
Fonction MCU dans H.323

MRF (Multimedia Gestion des appels multimédia (fonction MCU ou
Ressource Function) multiparties et de conférence utilisation du multicast dans
SIP)
Evolution du HLR pour incorporer
la gestion du profil de services IP
HSS (Home
multimédia de l’utilisateur Fonction SIP register
Subscriber Server)
(fonction serveur UMS-User
Mobility Server)
Tableau II.1 : Architecture de réseau UMTS R5
33
II.3.3 Influence de l’UMTS sur la stabilisation du concept NGN

L’UMTS aura un rôle potentiel fort sur l’émergence et la stabilisation du concept NGN.
L’UMTS est le premier système global qui intègre dans ses spécifications futures (releases
R4/R5) des options d’évolution vers une architecture réellement NGN.
Les protocoles choisis à terme par le 3GPP sont :
SIP pour le contrôle d’appel.
MEGACO/H.248 pour le contrôle des 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é nommément et semble mis en avant.
Si l’UMTS rencontre un développement et un succès important, et si les réseaux UMTS
migrent rapidement vers une architecture conforme aux spécifications des versions R4/R5, les
choix technologiques effectués par le 3GPP ne manqueront pas d’influer sur le choix global
des protocoles dans un réseau NGN, tous domaines confondus, fixe et mobile. Cela semble
particulièrement vrai pour les protocoles SIP et IPv6.
II.4 Conclusion
Les réseaux mobiles semblent prendre en compte l'évolution vers les NGN de manière plus
explicite en termes de normalisation (la normalisation du système UMTS), la maturité des
offres de produits fait que les premiers déploiements NGN s'effectuent plutôt dans le domaine
des réseaux et services fixes.
Dans ce chapitre, nous nous sommes efforcés de proposer des solutions adaptables a tout
opérateur fixe ou mobile désirant migrer son réseau vers NGN; ce dernier devra donc
dimensionner son réseau NGN en fonction de ses prévisions en trafic aussi bien voix et
données que multimédia. Le chapitre suivant décrit à cet effet, le processus de
dimensionnement dans un réseau NGN.
34
Processus de dimensionnement d’un réseau NGN
Chapitre III
Processus de dimensionnement d’un réseau
NGN
III.1 Introduction
L’étape de dimensionnement des équipements et interfaces d’un réseau de communication est
très importante. Elle permet de déterminer le volume des équipements, logiciels et autres
moyens (capacités de transmission…) à acquérir et à déployer pour la fourniture des services
de télécommunications. Le concepteur de réseau ou l’ingénieur en télétrafic qui souhaite
dimensionner un réseau à commutation de paquets ou à commutation de circuits s’intéresse
principalement aux paramètres suivants : débit utile du réseau, charge des différents éléments
du réseau, délais de transit des informations dans le réseau et probabilité de perte d’une partie
ou de toute l’information. [7]
Dans notre présent projet, nous traitons une nouvelle architecture de réseau à savoir le NGN
qui est caractérisé entre autre par l’émergence de nouveaux équipements et logiciels offrant de
nouvelles fonctionnalités. Alors nous avons décidé de nous intéresser uniquement au
dimensionnement du Hardware de cette architecture.
L’objectif de ce chapitre est d’introduire les outils de base permettant le dimensionnement des
principaux équipements et interfaces d’un réseau NGN. Ce chapitre traite tout d’abord le cas
du dimensionnement dans un réseau NGN Téléphonie. La seconde partie sera consacrée au
dimensionnement dans un réseau NGN Multimédia (IMS) où nous avons pris le cas de
l’architecture du réseau UMTS selon le concept IMS.
III.2 Dimensionnement dans le NGN Téléphonie

Comme nous l’avons mentionné dans le premier chapitre, le NGN Téléphonie est une
architecture de réseau offrant uniquement des services de téléphonie à des usagers disposant
d’un accès en mode circuit (Commutateur d’accès téléphonique, accès mobile GSM,
PABX…). Dans notre cas, nous allons nous contenter des réseaux d’accès suivants :
RTC/RNIS et GSM/GPRS.
III.2.1 Architecture cible du NGN Téléphonie
Dans notre processus de dimensionnement, le réseau NGN Téléphonie considéré est
représenté schématiquement par la figure I.4 dans le premier chapitre. C’est un réseau dorsal
35
IP qui relie différents réseaux d’accès : d’une part RTC/RNIS et d’autre part GSM/GPRS par
le biais de Media Gateways. Un Softswitch situé au niveau de la couche contrôle qui gère le
contrôle des appels ainsi que l’accès aux services au niveau de la couche application.
III.2.2 Scénario de migration retenu
Nous avons bien décrit dans le chapitre précédent les différents scénarios de migration des
réseaux traditionnels de téléphonie fixe et mobile vers une architecture NGN que nous
rappelons brièvement :
Scénario 1 : Mise en place de solutions NGN en transit.
Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur de classe 4.
Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5.
Scénario 4 : Mise en place de solutions tout IP en overlay.
Dans ce qui suit, nous avons opté pour le premier scénario de migration qui est la mise en
place de solutions NGN au niveau des liens de transit car il permet à l’opérateur d’acheminer
les communications internationales et nationales au niveau des commutateurs de transit et par
la suite une réduction de coût sur ces communications.
La figure III.1 illustre l’architecture générale d’une solution NGN au niveau des
commutateurs de transit national côté RTC/RNIS ainsi qu’au niveau des commutateurs du
service mobile (MSC) côté GSM/GPRS.
Figure III.1 : Mise en place de scénario de migration retenu
III.2.3 Modèle de trafic du réseau d’accès

La spécification de la charge d’un réseau suppose une connaissance préalable des
caractéristiques des services du point de vue trafic. Un modèle de trafic est un objet
mathématique ou algorithmique qui présente des caractéristiques souvent statistiques,
36
similaires au trafic réel. Il sert à mieux connaître et décrire le trafic véhiculé et permet de
dimensionner les files d’attentes dans les réseaux.
Le processus de Poisson modélise bien le trafic transactionnel ou encore le trafic d’appel
téléphonique qui arrive sur un commutateur de circuit. Il est donc à la base de la plupart des
lois de télétrafic utilisées en télécommunications et les lois d’Erlang en particulier. [7]
III.2.4 Méthodologie de dimensionnement
III.2.4.1 Organigrammes de dimensionnement du réseau NGN Téléphonie
Les organigrammes suivants décrivent les différentes étapes à suivre afin de déterminer les
besoins matériels pour l’écoulement du trafic des réseaux d’accès RTC/RNIS et GSM/GPRS.
Etape 1 : Calcul de trafic du réseau d’accès RTC/RNIS
Organigramme III.1 : Organigramme de calcul du trafic RTC/RNIS
Etape 2 : Calcul de trafic du réseau d’accès GSM/GPRS
Organigramme III.2 : Organigramme de calcul du trafic GSM/GPRS
37
Etape 3 : Dimensionnement des entités du réseau NGN Téléphonie
Organigramme III.3 : Organigramme de dimensionnement des entités

Etape 4 : Optimisation du réseau de transport
Organigramme III.4 : Organigramme d’optimisation du réseau de transport

III.2.4.2 Calcul du trafic généré par les réseaux d’accès
Pour pouvoir calculer le trafic total généré par les réseaux d’accès RTC/RNIS et GSM/GPRS,
nous devons rassembler d’abord les données d’opérateur suivantes :
La durée moyenne des communications (DMC) en secondes pour tous les types de
trafic (conversationnel, interactif ou streaming).
Le nombre de tentatives d’appels à l’heure chargée (TAHC) par heure par service
(conversationnel, interactif ou streaming).
Le grade de service (Grade of Service : GoS) souhaité au niveau de l’interface
commutateur de transit-Media Gateway (CT-MG) ou MSC-Media Gateway (MSC-
MG). En effet, les différents réseaux d’accès connectés au réseau de transport offrent
38
déjà un certain GoS fixé par l’opérateur en dimensionnant ce réseau; donc il faut éviter
un goulot d’étranglement au niveau des commutateurs de transit (CT) ou MSC
concentrant le plus de trafic car ce sont ces derniers qui seront connectés à la MG.
Première étape : Détermination du trafic engendré par un CT (respectivement un
MSC)
Le comportement global des usagers est exprimé par le nombre de tentatives d’appels à
l’heure chargée (TAHC) par heure et par la durée moyenne des communications (DMC) en
secondes. [8]
TAHC i × DMC i
Soit 1i = (III.1)
3600
le trafic de type i (conversationnel, interactif ou streaming) engendré par un CT du réseau
RTC/RNIS.
Le trafic total issu de chaque CT sera l’agrégation de ces trois types de trafic.
L’unité de trafic conversationnel étant l’Erlang alors que pour celui interactif ou streaming est
le Kbits. Afin de pouvoir effectuer cette sommation, il faut que nous convertissions ce trafic
conversationnel en Kbits. Pour ce faire, nous calculons tout d’abord le nombre de circuits
pouvant supporter ce type de trafic à l’aide de la formule de Rigault [8] :
N= conv +k conv (III.2)
Avec k RTC / RNIS = log10 (GoS RTC / RNIS ) (III.3)

Ensuite nous déterminons en premier lieu le nombre de liens E0 nécessaire pour écouler
conv , puis le nombre de liens E1 sachant que 1E1=32E0=32*64 Kbits=2048 Kbits. La
conversion de conv de l’Erlang en Kbits est donnée par l’équation (III.4) :
(
Aconv (Kbits ) = N × 64
32
)× 2048 = N × 4096Kbits (III.4)
Donc le trafic total en Kbits généré par un CT est donné par :

Trafic _ total _ CT = Aconv + int er + stream (III.5)
Le même calcul à suivre dans le cas d’un MSC.
Deuxième étape : Calcul du trafic total généré par le réseau d’accès RTC/RNIS :
Le trafic total généré par le réseau d’accès RTC/RNIS sera la somme de tous les trafics
engendrés par chaque CT :
Trafic_gén éré_réseau RTC/RNIS (Kbits) = Trafic _ total _ CT (III.6)
CT
Troisième étape : Calcul du trafic total généré par le réseau d’accès GSM/GPRS :
De même, nous calculons le volume de trafic généré par le réseau d’accès GSM/GPRS en
suivant la démarche précédente sauf que nous remplaçons cette fois les CT par les MSC :
39
Trafic_gén éré_réseau GSM / GPRS (Kbit s) = Trafic _ total _ MSC (III.7)

MSC
Quatrième étape : Calcul du trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS :
Nous pouvons maintenant déduire le trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS qui sera donné par l’équation (III.8) :
Trafic_total (Kbits) = Trafic_généré_réseau RTC/RNIS (Kbits)
+ Trafic_généré_réseauGSM/GPRS (Kbits) (III.8)
III.2.4.3 Calcul du nombre de liens CT-MG et MSC-MG
Dans notre logique de conception, nous ne pouvons tolérer de pertes avant l’arrivée du trafic
dans le réseau de transport ; ce qui revient à une fourniture de capacité entre le MSC ou le
commutateur du fixe et la MG ; ce qui nous amène donc à dimensionner les liens entre ces
entités. Le nombre de liens en E1 nécessaires pour écouler le trafic prévu est déterminé par :
Trafic_total_CT
N CT-MG = (III.9)
2048
Dans le cas du réseau d’accès GSM/GPRS, le nombre de liens MSC-MG en E1 est calculé
comme suit:
Trafic_total_MSC
N MSC-MG = (III.10)
2048
III.2.4.4 Dimensionnement des Media Gateways
Le dimensionnement des Media Gateways consiste à déterminer le nombre des MGs
nécessaires pour supporter le trafic total généré par les réseaux d’accès RTC/RNIS et
GSM/GPRS. Le nombre des MGs nécessaires pour véhiculer ce trafic est donné par :
Trafic_total (Kbits)
Nombre_MG = (III.11)
Capacité_MG
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 paramètre laissé au choix de
l’opérateur.
La charge des MG est calculée comme suit :
Ch arg e_MG (Kbits) = Trafic_total (Kbits) (III.12)
III.2.4.5 Dimensionnement des softswitchs
Dimensionner cet équipement, qui représente la couche contrôle, revient à déterminer la
capacité de traitement de son processeur en terme de nombre total de tentatives d’appels à
l’heure chargée (TAHC) qu’il pourra véhiculer :
Ch arg e_Softswitch (en TAHC) = TAHC i + TAHC i (III.13)
CT i MSC i
40
III.2.4.6 Optimisation du réseau de transport

Nous nous intéressons dans cette partie à l’optimisation du réseau de transport en mode
paquet. En effet, le déploiement de services téléphoniques et l’offre de services interactifs en
temps réel de bout en bout dans un réseau à commutation de paquets IP, amènent à
s’interroger sur la possibilité de pouvoir offrir la même qualité de service (Quality of Service :
QoS) et le même délai de transmission bouche-oreille que sur le PSTN, les exigences de QoS
étant exprimées ici par le temps d’empaquetage, la gigue, le taux de perte de paquets. Garantir
cette qualité de service nécessitera une ingénierie de trafic rigoureuse et la fourniture de
capacité, c’est-à-dire l’attribution d’une bande passante suffisante dans le réseau pour
transporter le trafic prévu.
La nature des réseaux à commutation de paquets impose un contrôle d’admission de
connexion. En effet, si le nombre d’appels actifs venait à dépasser le nombre maximal de
connexions pour lequel le réseau est dimensionné, il s’ensuivrait une dégradation de la QoS
pour tous les appels actifs. Il en est tout autrement dans les réseaux à commutation de circuits
où un manque de ressources pour l’établissement de connexions supplémentaires se traduit
par un blocage et ne touche donc qu’un seul utilisateur du réseau.
La méthodologie que nous allons décrire s’applique au réseau IP, constitué d’un nombre
arbitraire de routeurs de coeur et de routeurs périphériques. C’est un réseau constitué de
boucles SDH de 2,5 à 10 Gbits. Chaque routeur périphérique est relié à une MG qui peut
prendre en charge un nombre connu d'appels NMG; le débit que nécessite un appel de service i
(conversationnel, interactif ou streaming) Bcommunication,i sera un paramètre à donner par
l’opérateur. Ce débit, exprimé initialement dans le contexte TDM, sera converti dans le
contexte IP en utilisant les codecs spécifiques.
Par exemple, si le débit d’une 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 d’échantillonnage
est 20 ms (50 paquets par seconde) et le débit en mode IP sera égal à :
64 ×1024 bits / 50
Bcommunication = + 40 bits × 50 × 8 = 79 ,625 Kbps (III.14)
8
Supposons qu’un canal de trafic soit établi entre deux routeurs périphériques pour écouler le
trafic téléphonique entre les MG correspondantes. Soit Bcanal la capacité totale du canal
donnée par :
Bcanal = N canal ,i × Bcommunication ,i (III.15)
i
Avec Ncanal,i le nombre de communications pouvant être écoulées simultanément sur ce canal.
Ce nombre doit satisfaire cette relation qui exprime la probabilité que le contrôle d’admission
41
refuse une demande de communication entre les deux passerelles considérées parce que le
canal achemine déjà Ncanal,i communications :
( Ai )N canal , i
N canal ,i !
Pblocage ( Ai , N canal ,i ) = N canal ,i
= GoS (III.16)
( Ai ) k
/ k!
k =0
Avec Ai le trafic total par service i (conversationnel, interactif ou streaming) engendré par les
usagers des réseaux d’accès RTC/RNIS et GSM/GPRS.
Si un canal de trafic semblable est établi pour chaque paire possible de MG, on dispose d’un
maillage complet de canaux pour le transport du trafic téléphonique sur le réseau de base IP.
Pour chaque liaison du réseau coeur, la capacité totale à fournir se compose alors de la somme
de toutes les bandes passantes Bcanal de tous les canaux passant par cette liaison.
Capacité_totale_backbone_IP (Kbits) = C n2 × Bcanal (III.17)
avec n désigne le nombre total de routeurs périphériques dans le réseau 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 notées B2-4, B1-4, B4-6, B2-5
(figure III.3). [8]
Par conséquent, la capacité à fournir sur la liaison A-C est :
B AC = B2 4 + B1 4 + B4 6 + B2 5 (III.18)
Figure III.2 : Exemple d’une liaison A-C du réseau cœur
Figure III.3 : Calcul de la capacité totale à fournir sur la liaison A-C
42
III.3 Dimensionnement dans le NGN Multimédia

Dans cette partie, nous nous intéressons au dimensionnement d’un réseau IMS qui permet
d’offrir des services multimédia à des usagers disposant d’un accès large bande tel que xDSL,
câble, WiFi/WiMax, EDGE/UMTS, etc… Nous allons prendre le cas de l’architecture du
réseau UMTS selon le concept IMS.
III.3.1 Architecture cible du réseau UMTS
La figure III.4 représente les différentes entités à dimensionner dans le cas du réseau coeur
UMTS selon le concept IMS qui sont :
GGSN, SGSN, MSC Server et MGCF qui appartiennent à la couche contrôle.
Mobile-MGW et IMS-MGW faisant partie de la couche connectivité.
Figure III.4 : Architecture fonctionnelle du réseau cœur UMTS
III.3.2 Scénario de migration retenu

Nous avons adopté le scénario UMTS release R5 qui permet l'établissement de sessions
multimédia, un transport de tout type de média de bout en bout sur IP, et une offre de
nouveaux services. Ces capacités 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 contrôle de sessions multimédia ; SIP permet aussi l'accès
aux plates-formes de services. Ce protocole est incontournable en raison de sa capacité à
s'intégrer aux réseaux mobiles à un coût minimal. [6]
III.3.3 Modèle de trafic du réseau d’accès
L’évaluation du volume de trafic total dans le réseau coeur nécessite une étude préalable des
modèles de trafic de chacune des classes de service. Dans ce paragraphe, nous allons donner
43
un bref aperçu sur les différentes classes de services ainsi que les modèles de trafic qui
régissent ces classes pour pouvoir retenir un scénario pour chaque classe et calculer par la
suite la charge de trafic dans le réseau coeur. A noter que la modélisation classique des
services par des processus de Poisson n’est pas valide dés qu’il s’agit de la transmission des
données. Cette modélisation a été longtemps adoptée pour le calcul de la charge des réseaux
téléphoniques, et qui reste toujours valable pour les communications de type voix.
III.3.3.1 Les différentes classes de qualité de service
Selon les spécifications de 3GPP, il est possible de partitionner, sur la base de la qualité de
service, l’ensemble des services en quatre classes : classe des services conversationnels,
classe des services à flux continu ou Streaming, classe des services interactifs, classe des
services en mode téléchargement ou background. [9]
Le critère de classification le plus prépondérant est la sensibilité au délai de transmission. Les
deux premières classes sont prévues pour les services du type temps réel alors que les deux
autres classes concernent les applications non temps réel, ces dernières se caractérisent par
une tolérance aux délais de transmission. L’autre contrainte à respecter essentiellement pour
les deux dernières classes de service est le seuil du BER (Bit Error Rate).
III.3.3.1.1 Classe des services conversationnels
Les applications de cette classe nécessitent un service bidirectionnel en temps réel impliquant
deux utilisateurs humains ou plus. Les contraintes dépendent donc de la perception humaine :
la limite sur le délai maximum toléré est une limite stricte car toute dégradation sur le délai
induirait une perte de qualité notable dans la perception humaine du signal. Les exemples de
ce type d’applications sont la téléphonie, la vidéophonie, la voix sur IP, les jeux interactifs.
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 données. Ce
sont des applications temps réel asymétriques où les données sont transférées du réseau vers
les mobiles. Le manque d’interactivité entre l’utilisateur et la source de données autorise des
délais un peu plus importants que dans les cas des applications de type conversationnel, et ce
sans perturber la QoS. Les exemples d’applications de type Streaming sont les nouvelles
applications issues de l’Internet, telles que les applications audio ou vidéo sur demande.
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 données ou d’applications. Contrairement aux deux classes précédentes,
les performances temps réel ne sont pas nécessaires, il s’agit seulement d’attendre un certain
temps pour répondre aux requêtes. Par contre les informations ne doivent pas être altérées.
Les exemples d’applications de type interactif sont la navigation sur l’Internet, l’accès aux
bases de données ainsi qu’aux serveurs d’applications.
44
III.3.3.1.4 Classe des services en mode téléchargement ou background

Les applications de cette classe impliquent un utilisateur, le plus souvent un équipement
terminal, réalisent l’envoi et la réception de données en tâche de fond. L’absence
d’interactivité pour ces applications fait que l’utilisateur `a l’origine de la requête n’est pas en
attente d’une réponse dans une limite de temps fixée. Ce sont donc les applications les moins
sensibles au délai, mais sont très sensibles aux erreurs sur l’information transférées. Les
exemples d’applications sont le mail, le transfert de messages courts (SMS pour Short
Messages Services), le téléchargement de données ou de fichiers.
III.3.3.2 Modèles de trafic
III.3.3.2.1 Modèle de trafic pour le service conversationnel
Un exemple d’un service conversationnel est la communication téléphonique. Les
communications téléphoniques constituent le service le plus classique dont le comportement
statistique a été maîtrisé. Le comportement d’un utilisateur exploitant ce service au cours du
temps est modélisé par un processus markovien du type ON-OFF. Les caractéristiques de ce
modèle sont :
L’occurrence des appels téléphoniques est un processus de poisson caractérisé par un
taux moyen d’appel de valeur typique 0.8 appels par heure.
La durée d’un appel suit un processus exponentiel de moyenne typique b telle que 1/b
= 150 s.
La durée de l’appel est une alternance de périodes d’activité et de périodes de silence.
Ces périodes suivent chacune une distribution exponentielle. La valeur typique pour le
taux d’activité des sources est 0.5.
III.3.3.2.2 Modèle de trafic pour le service à flux continu
Un exemple typique d’un service à flux continu est le téléchargement d’une séquence vidéo.
Le flux des séquences vidéo correspond à une série de trames de données de même durée à
raison de 25 trames par secondes. Il existe neuf types différents de trames. L’occurrence de
ces différents types de trames est gérée par un processus de Markov à neuf états.
La distribution de la durée de chaque classe de contenu suit une loi Gamma d’ordre 2. Nous
avons retenu pour ce modèle les caractéristiques suivantes :
L’occurrence des sessions 0.17 appels/ heure
La durée d’une session 120 s
Le taux d’activité de la source est de 0.58
III.3.3.2.3 Modèle de trafic pour le service interactif
L’exemple typique de ce service est la consultation des pages Web. Le flux de données, selon
ce modèle, peut être décomposé en plusieurs sessions de consultation du Web. Pendant
chaque session, l’utilisateur consulte un ensemble de sites Web se ramenant à un appel des
45
pages HTMLs correspondantes. Le téléchargement de ces pages HTMLs est matérialisé par la
transmission de plusieurs datagrammes de taille variable. Un temps de lecture est nécessaire
avant d’amorcer la consultation d’une autre page Web. Les caractéristiques statistiques de ce
modèle sont les suivantes :
L’occurrence de sessions est un processus de poisson de valeur typique 0.17
appels/heure
Pour chacune de session :
Le nombre d’appel de pages HTML suit une distribution géométrique de
moyenne typique 5 appels/session.
Le temps de lecture suit une distribution exponentielle de moyenne a et de
valeur typique 1/a = 4 à 12 s.
Le nombre de datagrammes par appel suit une distribution géométrique de
moyenne typique 10 datagrammes/appel.
La durée d’inter-arrivée de datagrammes suit une distribution exponentielle
dont la moyenne est en fonction du débit.
La taille des datagrammes suit une distribution de Pareto.
III.3.3.2.4 Modèle de trafic de la classe Background
Les services de cette classe sont insensibles au délai, ils sont considérés de type Best Effort.
Ils sont transmis en dehors des périodes chargées du réseau coeur, c’est-à-dire au cours des
périodes d’inactivités des autres classes de services. D’une autre manière, ses services ne
contribuent pas à la charge du réseau.
III.3.4 Méthodologie du dimensionnement
III.3.4.1 Les hypothèses du dimensionnement
Pour dimensionner le réseau coeur UMTS, nous allons nous intéresser au trafic pendant
l’heure de pointe, qui est définie comme étant l’heure présentant un maximum du trafic
pendant une journée (une semaine, un mois). Nous supposons dans la suite que le modèle de
trafic du réseau d’accès correspond à l’heure la plus chargée pour le réseau coeur UMTS. De
même, nous admettons que la répartition du trafic de la classe conversationnelle entre mode
paquet et mode circuit (Pourcentage GSM et PSTN) est fixée malgré que la distribution du
trafic même entre les deux systèmes du mode circuit varie avec le temps (la distribution de
l’heure de pointe est utilisée comme référence).
Les taux de pénétration des réseaux UMTS et EDGE sont fixés, indépendamment de la
distribution des abonnés. Concernant la mobilité des abonnés entre les zones de couverture de
l’UMTS et celles couvertes par le spectre GSM, nous supposons que le pourcentage
d’abonnés qui passent de la couverture UMTS vers EDGE est le même qui passent de
l’EDGE vers UMTS. Enfin, nous avons considéré que tout abonné localisé sous la couverture
46
UMTS doit utiliser uniquement cette technologie avec un débit de 2 Mbits/s. Il en est de
même pour les abonnés EDGE mais avec un débit de 384 Kbits/s.
III.3.4.2 Organigramme de dimensionnement du réseau NGN Multimédia
Organigramme III.5 : Organigramme récapitulatif du dimensionnement
III.3.4.3 Calcul du trafic généré par le réseau d’accès

Nous devons d’abord estimer le nombre d’abonnés UMTS et EDGE, ceci est possible à
travers des estimations et des études marketing. Soit le taux_pénétration_UMTS , le
pourcentage de couverture du réseau UMTS, donc le nombre total d’abonnés UMTS est
donné par :
Nombre_abonnés_UMTS = Nombre_abonnés_GSM × taux_pénétration_UMTS (III.19)
Quant aux abonnés utilisant les services multimédia et résidant dans les zones non couvertes
par l’UMTS, nécessairement des abonnés du réseau EDGE, leur nombre total sera égal à :
Nombre_abonnés_EDGE = ( Nombre_abonnés_GSM-Nombre_abonnés_UMTS )
× taux_pénétration_EDG E (III.20)
Vu que l’utilisation des services varie selon leur nature d’une part et selon la technologie
utilisée d’autre part (UMTS, EDGE), l’étape suivante consiste à déterminer le nombre
d’abonnés actifs Nij par technologie i et par service j (conversationnel ou interactif ou
47
streaming). Soit Ai le nombre d’abonnés de technologie i et Tj le taux d’activité de service j.

Nij est donné par : N ij = Ai × T j (III.21)
Par la suite, nous déterminons le trafic généré par service pour les réseaux UMTS et EDGE :
TraficUMTS , j ( Kbits ) = N UMTS , j × taux _ appels j × durée _ appel j × débit _ max imal _ service j
× taux _ activités _ sourceJ (III.22)
Trafic EDGE , j ( Kbits ) = N EDGE , j × taux _ appels j × durée _ appel j × débit _ max imal _ service j
× taux _ activités _ sourceJ (III.23)

Pour calculer le trafic total par service, il faut souligner que le trafic de la classe
conversationnelle est réparti en trafic interne défini comme étant le trafic paquet qui englobe
les communications entre UMTS et EDGE c’est-à-dire trafic interne à l’IMS, et trafic externe
destiné vers le monde circuit.
Organigramme III.6 : Répartition de trafic de la classe conversationnelle
Donc, pour les services interactif et streaming, leurs volumes de trafic générés sont les mêmes
calculés par les équations III.24 et III.25 :
Volume_trafic_généréUMTS ,int eractif (Kbits ) = TraficUMTS ,int eractif
Volume_trafic_généréUMTS , strea min g (Kbits ) = TraficUMTS , strea min g
Tandis que pour le service conversationnel, le volume de trafic généré est calculé comme
suit :
Volume_trafic_généréUMTS ,conv (Kbits ) = Trafic_ int erneUMTS ,conv
+ Trafic _ externeUMTS ,conv × Pourcentage _ GSM
= TraficUMTS ,conv Trafic _ externeUMTS ,conv × Pourcentage _ RTC (III.24)
Avec Trafic_externeUMTS,conv = TraficUMTS,conv × % trafic vers mod e circuit (III.25)

De même, nous calculons le volume de trafic généré par service dans le cas du réseau EDGE.
Ensuite, il suffit d’effectuer la somme de tous les trafics générés pour chaque service pour
déterminer le volume de trafic global.
48
3 3
Volume _ trafic _ total = Volume _ trafic_généréUMTS , j + Volume _ trafic_généré EDGE , j
J =1 J =1
(III.26)
III.3.4.4 Dimensionnement des entités du réseau
III.3.4.4.1 Dimensionnement des M_MGWs
Pour déterminer le nombre des M_MGWs nécessaires pour véhiculer le trafic paquet, il faut
calculer le trafic interne dans les réseaux UMTS et EDGE ainsi que le trafic externe destiné
aux abonnés GSM. Puis leur ajouter le trafic du service conversationnel Aconv (voir équation
III.4) issu du réseau GSM destiné aux abonnés UMTS et EDGE. Ce dernier est calculé
comme nous l’avons vu dans la partie NGN Téléphonie.
Le nombre des M_MGWs sera égal alors :
Volume _ trafic _ total + Aconv
Nombre _ M _ MGWs = (III.27)
Capacité M _ MGW
Comme dans le cas de dimensionnement dans le NGN Téléphonie, nous allons calculer la
charge des M_MGWs seulement. La capacité reste au choix de l’opérateur.
La charge des M_MGWs est calculée comme suit :
Ch arg eM_MGWs (Kbits) = Volume _ trafic _ total + Aconv (III.28)
III.3.4.4.2 Dimensionnement des IMS_MGWs
Pour calculer le nombre des IMS_MGWs, nous considérons le volume de trafic véhiculé entre
le réseau RTC et le réseau UMTS/EDGE et ce dans les deux sens. Le volume du trafic du
réseau UMTS/EDGE vers le réseau RTC est donné par :
Volume _ trafic _ vers _ RTC ( Kbits ) = (TraficUMTS ,conv + Trafic EDGE ,conv )× % trafic vers mod e circuit
× Pourcentage _ RTC
(III.29)
Tandis que celui véhiculé du réseau RTC vers le réseau UMTS/EDGE, Aconv (voir équation
III.4) est calculé comme dans le cas du NGN- Téléphonie.
Le nombre des IMS-MGWs est donné par :
Volume _ trafic _ RTC + Aconv
Nombre _ IMS _ MGWs = (III.30)
Capacité _ IMS _ MGW
III.3.4.4.3 Dimensionnement de MGCF
La charge de MGCF est estimée en nombre total des communications issues du réseau RTC.
Ch arg e _ MGCF = (N UMTS ,conv + N EDGE ,conv ) × taux _ appel _ conversationnel
× % trafic vers mod e circuit × Pourcentage _ RTC

(III.31)
49
III.3.4.4.4 Dimensionnement de MSC Server

Afin de déterminer le nombre de MSC Server, nous devons calculer la capacité de traitement
de son processeur, autrement dit le nombre total des communications issues du réseau GSM.
Ch arg e _ MSC _ Server = (N UMTS ,conv + N EDGE ,conv ) × taux _ appel _ conversationnel
× % trafic vers mod e circuit × Pourcentage _ GSM (III.32)

III.3.4.4.5 Dimensionnement des SGSNs
Le dimensionnement des SGSNs dépend du nombre d’abonnés simultanément attachés (SAU
: Simultaneously attached User), du nombre de paquets par seconde (PPS : Packet Per
Second), la taille moyenne des paquets, etc…
Pour déterminer le nombre des SGSNs, nous allons nous baser sur le paramètre SAU et ceci
pour des raisons de simplification du dimensionnement. Une caractéristique importante que
nous risquons de négliger, puisque nous n’avons pas réalisé le dimensionnement du réseau
d’accès, c’est la capacité du SGSN en terme de RNC connecté. Après le calcul du nombre des
SGSNs requis, nous devons vérifier que la capacité de chaque SGSN en terme de RNC n’a
pas été dépassée. Dans telle situation, il faut prendre la valeur maximale entre le nombre des
SGSNs requis selon le paramètre SAU et le nombre selon le paramètre RNC. Nous utilisons
le mode paquet (pas le mode circuit) où tous les abonnés sont connectés. Le nombre de SAU
EDGE et celui de SAU UMTS sont donnés par :
Nombre _ SAU _ EDGE = Nombre _ Abonnés _ EDGE × pourcentage _ SAU _ EDGE (III.33)
Nombre _ SAU _ UMTS = Nombre _ Abonnés _ UMTS × pourcentage _ SAU _ UMTS (III.34)
L’étape dernière consiste à choisir une configuration matérielle des SGSNs de la part de
l’opérateur pour calculer le nombre des SGSNs :
Nombre _ SGSNs =
(Nombre _ SAU _ EDGE + Nombre _ SAU _ UMTS ) (III.35)
capacité _ SGSN
III.3.4.4.6 Dimensionnement des GGSNs
Le paramètre clé de dimensionnement des GGSNs est le contexte PDP. Le nombre de
contextes PDP est donné par le nombre de sessions générées par les abonnés (un abonné peut
générer plusieurs sessions). En effet, chaque session est caractérisée par un contexte PDP. De
plus, pour activer une session, un abonné doit être attaché au réseau paquet. Pour déterminer
le nombre de contextes PDP, nous opérons ainsi :
Calculer le nombre de contextes PDP générés par les abonnés UMTS
Nombre_PDP_UMTS = ( Nombre_abonnés_UMTS ) × (taux_activité_service_conversationnel
+ taux_ activité_service_ int eractif
+ taux_ activité_service_strea min g ) (III.36)
50
Calculer le nombre de contextes PDP générés par les abonnés EDGE

Nombre_PDP_EDGE = ( Nombre_SAU_EDGE ) × (taux_activité_service_conversationnel
+ taux_ activité_service_ int eractif
+ taux_ activité_service_strea min g ) (III.37)

Le nombre total de contextes PDP activé
Nombre_PDP_total = Nombre_PDP_UMTS + Nombre_PDP_EDGE (III.38)
Par la suite, nous déterminons le nombre des GGSNs selon la capacité choisie par
l’opérateur :
Nombre _ PDP _ total
Nombre _ GGSNs = (III.39)
capacité_GGSN
III.3.4.5 Optimisation du réseau de transport
Pour pouvoir dimensionner les artères du réseau de transport, nous suivons la même démarche
adoptée dans le cas du NGN Téléphonie, sauf que dans le cas de NGN multimédia, nous
avons deux types de trafic présents au niveau du réseau de transport :
Le trafic interne écoulé entre les réseaux UMTS et EDGE ainsi que le trafic externe
vers les réseaux RTC ou GSM : pour ces types de trafic le débit d’une communication
Bcommunication ne sera pas converti de mode TDM en mode IP puisque il en y est
déjà.
Le trafic issu des réseaux RTC et GSM : la Bcommunication sera convertie de mode
TDM en mode IP en utilisant des codecs bien déterminés.
III.4 Conclusion
Dans ce chapitre, nous avons abordé le processus de dimensionnement dans les réseaux
NGN : Téléphonie et Multimédia. Nous avons essayé de présenter les différents outils
mathématiques et algorithmiques utilisés pour réussir ce dimensionnement.
Le dernier chapitre sera consacré pour la présentation de notre outil universel de
dimensionnement et son évaluation par des exemples de scénarios de dimensionnement tout
en se basant sur les équations de ce troisième chapitre.
51
Outil de dimensionnement et validation sur des scénarios
Chapitre IV
Outil de dimensionnement et validation sur
des scénarios
IV.1 Introduction
Au cours du chapitre précédent, nous avons étudié le processus de dimensionnement d’un
réseau NGN : Téléphonie ainsi que Multimédia.
Dans ce chapitre, il sera essentiellement question de l’outil universel de dimensionnement que
nous devons développer et de son évaluation. Pour ce faire, nous commencerons par spécifier
le cahier des charges et à présenter l’environnement de développement qui nous permettra
d’atteindre les objectifs de ce cahier des charges. Ensuite nous présenterons l’organigramme
fonctionnel de l’outil en décrivant les fonctionnalités de ses modules et les étapes de son
fonctionnement. Enfin la dernière partie de ce rapport sera consacrée à une évaluation de
l’outil basée sur une étude de cas.
IV.2 Cahier de charges de l’outil

IV.2.1 Objectif de l'outil de dimensionnement
Le but de cette étude est de développer un outil universel de dimensionnement d’un réseau
NGN et d’un réseau IMS. Cet outil devra être capable d’automatiser les opérations de
dimensionnement et d’optimisation, illustrées dans le chapitre précèdent. Son objectif nous
apparaît utile même si, eu égard au caractère évolutif des problèmes des télécommunications,
des modifications à plus ou moins brève échéance sont susceptibles d'affecter les règles ou les
procédures.
IV.2.2 Paramètres d'entrée
Notre outil devra accepter les paramètres suivants comme variables d'entrée :
IV.2.2.1 NGN Téléphonie
Tentatives d’appels à l’heure chargée TAHC : nombre d’appels exécutés pendant
l’heure de pointe pour chaque service. Ce paramètre sera introduit par CT ou MSC et
par zone.
Durée moyenne des communications DMC pour chaque service exprimé en secondes.
Elle sera introduite par CT ou MSC et par zone.
52
GoS (Grade of Service) : exprime la probabilité de blocage fixée par l’opérateur au

niveau de l’interface CT-MG ou MSC-MG.
Nombre de routeurs : c’est un paramètre à saisir lors de l’optimisation du réseau de
transport.
Bande de communication exprimée en Kbits/s : représente le débit d’une type de
communication (voix, donnée ou vidéo).
La capacité de MG et celle de softswitch : elle est utilisée pour déterminer le nombre
de ces deux entités. Ces deux capacités varient selon le fournisseur.
IV.2.2.2 IMS
Taux d’appels : représente le rapport entre le nombre de tentatives d’appels par heure
et le nombre d’abonnés total pour chaque service.
Taux d’activité source par service : c’est le taux d’occupation du canal selon le
service.
DMC.
GoS : probabilité de blocage fixée dans le réseau UMTS/EDGE.
Nombre d’abonnés GSM, EDGE et UMTS, répartis par zone.
Pourcentage SAU EDGE et SAU UMTS : ce sont les abonnés paquet simultanément
attachés à chaque technologie.
Taux d’activité pour chaque service.
Pourcentage du trafic sortant vers le mode circuit : c’est le trafic conversationnel
sortant du mode IP vers mode circuit et qui sera réparti entre les réseaux GSM et RTC.
La capacité des entités M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN.
IV.2.3 Paramètres de sortie
Nous pensons qu’il est possible d’avoir les données suivantes comme sortie de notre outil de
dimensionnement :
IV.2.3.1 NGN Téléphonie
Trafic total généré par les réseaux d’accès RTC/RNIS et GSM/GPRS réparti 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 simultanément dans le réseau de transport.
Capacité totale en Kbits à fournir pour le réseau de transport.
Prévision du trafic de chaque CT ou MSC et de charges des MGs et softswitchs sur
cinq ans.
53
IV.2.3.2 IMS
Trafic total en Kbits généré par les réseaux EDGE et UMTS pour chaque zone.
Résultat de dimensionnement des entités M-MGW, IMS-MGW, MSC Server, MGCF,
SGSN et GGSN en terme de charge et nombre.
Nombre des communications à écouler simultanément dans le réseau de transport.
Capacité totale en Kbits à fournir pour le réseau de transport.
Prévision du trafic et des charges des entités sur cinq ans.
IV.2.4 Interface Utilisateur
Notre outil de dimensionnement devrait présenter une interface graphique agréable et facile à
manipuler. L'utilisateur devra introduire les paramètres d'entrée d'une façon aisée, ainsi que la
visualisation des résultats. Il devra aussi manipuler les menus du logiciel sans problème.
Notre outil sera capable d’enregistrer ces paramètres d'entrée et leurs résultats dans des
rapports et de les afficher exhaustivement.
Nous jugeons utile d’offrir plus de liberté à l'utilisateur de l’outil en lui donnant la possibilité
d'introduire le type de dimensionnement de son choix.
IV.3 Environnement de développement

Le langage que nous avons choisi pour développer 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 intégré dans Visual Studio .Net 2003.
C'est un langage orienté objet créé par Microsoft pour les développeurs Java souhaitant faire
des applications et des services sur le framework.Net. De ce fait, les développeurs peuvent
utiliser tous les avantages du framework .Net comme :
Un modèle unifié de programmation (les applications Windows, les applications Web
et les applications Mobile Web) sur différents types de machines et de systèmes
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) orientés .Net.
De plus, les développeurs voulant exploiter les fonctionnalités du framework .Net et de Visual
Studio pour leurs anciennes applications, peuvent le faire grâce à différents outils de
conversions, mise à disposition, pour les programmes en Java ou en J++. Ainsi, l'utilisation de
JSharp nous permet de décomposer facilement le moteur de simulation en packages
indépendants. Et comme chaque package peut être développé sans aucune relation avec les
autres, la gestion du projet, mise en place, devrait être très efficace. En somme, c’est toutes
ces caractéristiques réunies qui ont motivé le choix du J# comme langage de développement.
54
IV.4 Fonctionnalités de l’outil

L’outil dont il est question est un outil de dimensionnement d’un réseau NGN. Son but est
d’aider les opérateurs à trouver la meilleure configuration de leur réseau en terme
d’équipements nécessaires et de charges tout en garantissant une qualité de service donnée.
IV.4.1 Organigramme fonctionnel de l’outil
Les fonctionnalités de notre outil sont représentées par l’organigramme suivant :
Organigramme IV.1 : Principe de fonctionnement de l’outil
IV.4.2 Modules développés

Pour gérer les entrées et les sorties de cet outil de dimensionnement, nous avons développé
quatre modules principaux.
IV.4.2.1 Module d’estimation de la charge de trafic pour le NGN Téléphonie
Ce module a pour objectif de déterminer la charge de trafic d’une zone étudiée pour chaque
CT (respectivement MSC). Il répartit ce trafic par type de service et détermine par la suite le
nombre des jonctions MIC entre un CT (respectivement MSC) et une MG. Enfin, il permet
d’agréger toutes les charges de trafic issu de l’ensemble des CT (respectivement MSC) pour
le dimensionnement des MGs et softswitchs.
55
Organigramme IV.2 : Estimation de la charge de trafic cas NGN Téléphonie
IV.4.2.2 Module d’estimation de la charge de trafic pour le NGN Multimédia

Ce module s’occupe du calcul de la charge de trafic pour une zone donnée et pour chaque
service (conversationnel, interactif ou streaming) dans les réseaux UMTS et EDGE ce qui
permet de dimensionner les différentes entités suivantes : M-MGW, IMS-MGW, MSC
Server, MGCF, SGSN et GGSN.
Organigramme IV.3 : Estimation de la charge de trafic cas NGN Multimédia
IV.4.2.3 Module d’optimisation du réseau de transport

Ce module permet de calculer d’une part le nombre des communications simultanées à
écouler dans le réseau de transport et d’autre part la capacité totale à fournir suivant
l’algorithme décrit dans l’organigramme III.4.
56
IV.4.2.4 Module de prévision de trafic

L’extension des réseaux demande l’approvisionnement des équipements des centraux, des
faisceaux de jonctions et des circuits. Cependant, il pourrait y avoir un temps entre
l’identification des besoins futurs et le moment de réalisation. La durée de temps entre
l’identification du besoin et son approvisionnement est considérable. Pour éviter les longues
périodes d’attente et la congestion élevée, il est préférable de déterminer les besoins à
l’avance. Cela rend possible l’extension du matériel au bon moment parce que l’action
nécessaire peut être effectuée en temps approprié.
Une prévision devrait, cependant, produire premièrement l’estimation exacte des demandes
futures pour les équipements des télécommunications.
Ce module s’intéresse à la prévision du trafic des réseaux d’accès RTC/RNIS et GSM/GPRS
dans le cas du NGN Téléphonie et des réseaux UMTS et EDGE pour le NGN Multimédia.
Ainsi cette partie estime la prévision de la charge des MGs et softswitchs dans le premier cas
et les entités : M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN dans le deuxième
cas.
Nous avons choisi la méthode de prévision tendancielle qui consiste à supposer que le
développement devrait suivre la courbe qui a été ajustée à des données historiques existantes.
Pour des raisons de simplification, nous allons nous limiter à la méthode de tendance linéaire
donnée par la formule suivante :
y (t ) = a × t + b (IV.1)
Avec
y(t) : résultat de la prévision à l’année t
a : la pente de la courbe
b : le trafic ou charge à t=0
IV.5 Interface utilisateur développée

V.5.1 Fenêtre principale de l’outil
Lors du démarrage de l’application, nous apercevons la fenêtre principale (Figure IV.1) qui
affiche une barre de menus composée de :
NGN Téléphonie
NGN Multimédia
Prévision
Aide
57
Figure IV.1 : Fenêtre principale de l’outil
Cette fenêtre comporte à son tour une barre d’outils contenant :

Nouveau : il permet à l’utilisateur de créer un nouveau projet de dimensionnement. En
effectuant cette tâche, l’utilisateur a le choix entre un dimensionnement d’un réseau de
type NGN Téléphonie ou bien NGN Multimédia (voir figure IV.2) et selon ce choix il
active de facto les autres menus (NGN Téléphonie ou bien NGN Multimédia) et
pourra ainsi commencer son projet.
Figure IV.2 : Fenêtre de création d’un nouveau projet
Ouvrir : ce bouton permet de charger en mémoire un projet existant : évidemment il y

a deux types de projets le premier d’extension .tel et le deuxième d’extension .ims.
58
Cette opération d’ouverture affiche tous les paramètres d’entrée saisis, par
l’utilisateur, ainsi que les résultats de dimensionnement dans des rapports.
Sauvegarder : il permet de sauvegarder les nouveaux projets.
V.5.2 Menu NGN Téléphonie
Ce menu concerne le dimensionnement dans le cas du réseau NGN Téléphonie. Il comporte
trois parties essentielles. :
La première, pour la saisie de paramètres d’entrée. Elle contient un seul sous menu
appelé « Données Opérateurs ».
La deuxième, s’intéresse au calcul et à l’affichage des résultats de dimensionnement.
Elle comprend quatre sous menus qui sont :
« Calcul du trafic » : permet de calculer le trafic généré par les réseaux d’accès
RTC/RNIS et GSM/GPRS.
« Répartition 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 détermination de la charge
ou bien du nombre de ces deux entités.
La dernière, s’occupe de l’optimisation du réseau de transport. Elle se compose d’un
seul sous menu « Réseau de transport ».
V.5.3 Menu NGN Multimédia
C’est le menu qui va nous permettre de visualiser les résultats obtenus dans le processus de
dimensionnement d’un réseau NGN Multimédia en terme de trafic généré par le réseau
UMTS/EDGE et du nombre de M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN.
Comme dans le cas du NGN Téléphonie, ce menu comprend trois parties :
La première est consacrée à la saisie des données d’entrée par l’utilisateur. Elle
contient deux sous menus : « Données Opérateurs » et « Données EDGE/UMTS ».
La deuxième contient trois sous menus : « Calcul du trafic », « Répartition du trafic »
et « Dimensionnement des entités».
La dernière est un sous menu appelé « Réseau de transport ».
V.5.4 Menu Prévision
La fonction prise en compte par ce menu est la prévision du trafic des réseaux d’accès et de
charges des entités fonctionnelles des réseaux NGN Téléphonie et Multimédia. Il est constitué
de deux sous menus : le premier dédié à la prévision dans le cas du NGN Téléphonie alors
que le second est réservé à la prévision dans le NGN Multimédia.
59
V.5.5 Menu Aide

Le menu « Aide », comme son nom l’indique, permet d’afficher une aide contextuelle. Il
comprend un volet « Aide » et un volet « A propos » qui permet l’affichage de la fenêtre
d’identification de l’application (voir Figure IV.3).
Figure IV.3 : Fenêtre A propos
IV.6 Validation sur scénarios

Dans ce paragraphe, il sera essentiellement question de la présentation des résultats de
dimensionnement d’un réseau NGN à partir de notre outil informatique. Pour ce faire, nous
allons exécuter deux scénarios de dimensionnement, le premier concerne le réseau NGN
Téléphonie tandis que l’autre sera consacré au réseau NGN Multimédia.
IV.6.1 Cas du réseau NGN Téléphonie
IV.6.1.1 Acquisition des paramètres et données d’entrée
Dans ce premier scénario, nous assimilerons la zone 3 qui représente la zone du Sahel. Nous
allons présenter ce scénario à l’aide des différentes interfaces de notre outil de
dimensionnement.
En effet, la première étape après l’exécution de l’application c’est l’authentification par le
biais d’un Login et d’un Mot de passe. Cette interface permet de limiter l’accès à
l’application.
Figure IV.4 : Authentification de l’utilisateur
60
Une fois l’accès est autorisé l’interface de la fenêtre principale apparaît (Figure IV.1). Nous
choisissons par la suite un nouveau projet de type NGN Téléphonie (voir figure IV.2), le
menu NGN Téléphonie sera activé et il suffit d’y accéder pour aborder les différentes étapes
du dimensionnement. Le tableau IV.1 résume les différents paramètres d’entrée pour ce
scénario de dimensionnement concernant la zone du Sahel. Elle est composée de deux CT et
trois MSC qui seront reliés aux MGs : CT de Sousse (CT1), CT de Moknine (CT2), MSC1
Sousse, MSC2 Sousse, MSC Moknine (MSC3).
GoS TAHC DMC TAHC DMC TAHC DMC
Réseau (%) voix voix donnée donnée vidéo vidéo
RTC/RNIS CT1 3 101944 70 s 1861 1194 s 0 0
CT2 3 30461 70 s 0 0 0 0
MSC1 3 39014 43 s 0 0 0 0
Réseau
MSC2 3 92785 33 s 0 0 0 0
GSM/GPRS
MSC3 3 90000 33 s 0 0 0 0
Tableau IV.1 : Paramètres d’entrée de la zone 3
Nous passons ensuite à la fixation de ces paramètres d’entrée du dimensionnement dans

l’interface « Ajout Données Opérateur » appartenant au sous menu « Données Opérateur ».
En premier lieu l’utilisateur saisit le GoS souhaité au niveau de l’interface CT-MG
(respectivement CT-MSC), le nombre de zones, le nom de chaque zone ainsi que le nombre
de CT et MSC qu’elle contient.
Figure IV.5 : Ajout des données de l’opérateur
61
En cliquant sur le bouton « Ajouter », les cases de saisie de TAHC et DMC pour chaque
service seront activées, l’utilisateur pourra faire entrer les valeurs de ces paramètres 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 données d’entrée de la zone3-CT1
Figure IV.7 : Saisie des données d’entrée de la zone3-CT2
62
Les mêmes étapes à suivre pour la saisie des paramètres d’entrée du réseau d’accès
GSM/GPRS.
IV.6.1.2 Résultats obtenus
L’étape suivante exécutée par notre outil sera le calcul du trafic total généré 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 généré par les réseaux d’accès
Nous avons procédé à la répartition 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 : Répartition du trafic RTC/RNIS entre les deux CT de la zone 3
L’interface suivante donne la répartition du trafic total du réseau d’accès GSM/GPRS entre
MSC1 Sousse, MSC2 Sousse et MSC de Moknine (MSC3).
63
Figure IV.10 : Répartition du trafic GSM/GPRS entre les trois MSC de la zone 3
L’étape importante dans ce processus de dimensionnement sera le calcul du nombre des MGs
et softswitchs à mettre en place pour assurer le fonctionnement du réseau NGN Téléphonie.
L’interface de la figure IV.11 nous permet de déterminer la charge des MGs en Kbits et celle
des softswitchs en tentatives d’appels pour la zone 3.
Figure IV.11 : détermination 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 d’appels à l’heure chargée (TAHC).
Si l’opérateur 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 l’opérateur opte pour les
media gateways de type « Cisco MGX 8800 Series » d’une 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]
64
Figure IV.12 : Calcul du nombre des MGs et des softswitchs
Concernant l’optimisation du réseau de transport, l’opérateur doit saisir le nombre des

routeurs périphériques constituant le réseau 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 générées sur un canal
reliant deux MGs et la capacité totale à fournir pour écouler ce nombre. La figure IV.13
montre un exemple d’optimisation du réseau de transport de la zone 3.
Figure IV.13 : Optimisation du réseau de transport de la zone 3
65
Le présent scénario de dimensionnement d’un réseau NGN Téléphonie de la zone 3 décrit

dans cette partie, s’effectue le 10 juin 2006. Pour pouvoir réaliser la prévision du trafic des
réseaux 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 l’opérateur
désire faire la prévision qui sera opérée par défaut sur cinq ans.
Dans notre cas, nous allons supposer que nous sommes aujourd’hui le 4 décembre 2006 et que
nous voulons effectuer la prévision à partir de ce jour sur cinq ans. Ensuite, nous faisons le
scénario de dimensionnement au jour du 4 décembre 2006. La prévision du trafic ainsi que
celle des charges des MGs et des softswitchs sont données par les figures IV.14, IV.15 et
IV.16 :
Figure IV.14 : Prévision du trafic RTC/RNIS de la zone 3
Figure IV.15 : Prévision du trafic GSM/GPRS de la zone 3
66
Figure IV.16 : Prévision des charges des MGs et des softswitchs de la zone 3
Enfin, nous avons récapitulé l’ensemble des données d’entrée 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 récapitulatif de dimensionnement de la zone 3
67
IV.6.2 Cas du réseau NGN Multimédia

IV.6.2.1 Acquisition des paramètres et données d’entrée
Nous allons aborder le dimensionnement du réseau UMTS selon le concept NGN Multimédia
en adoptant l’approche par zones. En se basant sur les caractéristiques du réseau 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 caractéristiques (répartition des abonnés GSM, taux d’activité des services, répartition
de trafic, répartition des abonnés WCDMA, etc. . .), l’approche par zone parait très
intéressante.
La première étape du dimensionnement du réseau UMTS sera la spécification des modèles de
trafic pour chaque service. Elle nous a permis de retenir un modèle pour chaque service qui
constituerait des valeurs typiques que nous allons prendre pour déterminer la contribution de
chaque service dans la charge totale du trafic dans le réseau coeur. Ces valeurs ne sont pas
fixes, pour autant. L’utilisateur de notre outil développé, peut intervenir pour changer ces
paramètres. L’interface IV.18 nous permet de fixer le modèle de trafic du réseau d’accès et le
GoS souhaité dans le réseau EDGE/UMTS.
Figure IV.18 : Modèle de trafic du réseau d’accès
68
Dans l’interface suivante, l’utilisateur doit saisir le nombre d’abonnés GSM, le taux de
pénétration de l’UMTS, le taux de pénétration EDGE, le nombre de zones relatives à la
répartition du trafic et des abonnés et la répartition du trafic total généré par les abonnés
EDGE et UMTS du service conversationnel. En fait, ce dernier paramètre sera utilisé pour le
dimensionnement des M-MGWs. Nous prenons 70% de ce trafic conversationnel sortant vers
le mode circuit qui est réparti à son tour entre GSM et RTC selon les pourcentages suivants :
40% vers RTC et 60% vers GSM.
Figure IV.19 : Fixation des paramètres généraux
En validant l’étape précédente, l’utilisateur est invité à saisir les paramètres concernant :
La répartition des abonnés EDGE et UMTS : pour répartir les abonnés 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 d’abonnés par
zone et par la suite nous déterminons le trafic paquet généré 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 : Répartition des abonnés EDGE et UMTS
Pourcentages d’attachement des abonnés : nous avons déjà présenté le processus du

dimensionnement des SGSNs. Pour cela, il suffit de calculer pour chaque zone le
69
nombre de SAU simultanément pour EDGE et UMTS. Le calcul se fait en considérant

les pourcentages du tableau IV.3.
Abonnés paquet attachés (%)

100 90 90 80 90
(Pourcentage SAU UMTS)
Abonnés paquet attachés (%)

50 35 39 32 33
(Pourcentage SAU EDGE)
Tableau IV.3 : Pourcentages d’attachement des abonnés EDGE et UMTS
Les taux d’activité des services : chaque zone à ses propres taux d’activité des
services ; le comportement des abonnés envers les services diffère d’une zone à une
autre. Pour ce scénario, 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 d’activité des services
Figure IV.20 : Répartition des paramètres d’entrée par zone
La dernière interface de saisie des données d’entrée concerne le trafic en mode circuit c’est à
dire le trafic conversationnel des réseaux RTC et GSM destiné aux abonnés UMTS et EDGE.
Il s’agit de calculer pour chaque zone le trafic externe conversationnel issu des réseaux RTC
et GSM qu’elle va recevoir. Pour ce faire nous devons saisir les paramètres suivants pour
70
chaque réseau : TAHC, DMC et GoS. Dans ce scénario nous ne tenons pas compte de ce
trafic.
Figure IV.21 : trafic conversationnel en mode circuit issu des réseaux RTC et GSM
IV.6.2.2 Résultats obtenus

Les résultats du dimensionnement sont donnés par la fenêtre de la figure IV.22. En effet, les
abonnés UMTS et EDGE génèrent un trafic total de l’ordre 22612.70 Gbits. Ce trafic est
réparti entre les trois services de la manière 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 généré par les abonnés EDGE et UMTS
Les quatre interfaces des figures IV.23, IV.24, IV.25 et IV.26 s’intéressent à la répartition de
ce trafic total entre les cinq zones ainsi qu’au calcul des charges et nombre des M-MGW,
IMS-MGW, MSC Server, MGCF, SGSN, GGSN dans chaque zone.
71
Figure IV.23 : Répartition du trafic EDGE entre les cinq zones
Figure IV.24 : Répartition du trafic UMTS entre les cinq zones
Figure IV.25 : Détermination des charges des entités fonctionnelles
72
Une fois que les différentes charges des entités fonctionnelles sont déterminées, l’opérateur
peut calculer le nombre de ces entités en introduisant la capacité de chaque entité exprimée en
Kbits pour l’IMS-MGW, M-MGW et en TAHC pour le MSC Server et MGCF. Pour cela il
doit cliquer sur le bouton « Avancé ». L’interface suivante nous montre un exemple de calcul
de ces entités.
Figure IV.26 : Détermination du nombre des entités fonctionnelles
Zone 1 : C’est la zone la plus dense en abonnés (presque la moitié des abonnés). Elle
engendre le plus du trafic : 15870 Gbits (13757.78 Gbits service conversationnel,
1563.33 Gbits service streaming et 549 Gbits pour l’interactif). Pour satisfaire les
exigences de cette zone, l’opérateur Tunisien doit installer 5 M-MGW, 2 IMS-MGW,
1 MGCF, 1 MSC Server, 1 GGSN et 1 SGSN.
Zone 2 : elle génère 2053 Gbits (1759.71 Gbits conversationnel, 202.193 Gbits
streaming et 91.71 Gbits interactif). La configuration requise selon ce scénario 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 multimédia offerts (conversationnel, streaming et
interactif) génèrent respectivement (1579.86 Gbits, 167.55 Gbits et 86.66 Gbits). Le
trafic total est 1834.09 Gbits qui nécessite 1 M-MGW, 1 IMS-MGW, 1 MGCF, 1
MSC Server, GGSN et SGSN pour être véhiculé.
Zone 4 : ses abonnés génèrent un trafic de 1554.225 Gbits (1336 conversationnel,
153.55 streaming et 64.151 Interactif). Tunisie Télécom doit installer 1 M-MGW, 1
IMS-MGW, 1 MGCF, 1 MSC Server, 1 GGSN et 1 SGSN.
Zone 5 : cette zone nécessite 1 M-MGW, 1 IMS-MGW, 1 MGCF, 1 MSC Server, 1
SGSN et 1 GGSN pour véhiculer le trafic paquet. Le trafic généré par ses abonnés est
de 1299.70 Gbits (1113.76 service conversationnel, 118.122 service streaming et
67.81 service interactif).
73
Donc le nombre total des équipements nécessaires pour écouler le trafic total généré par les
abonnés 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 réseau de transport pour les cinq zones
Pour la prévision du trafic et des charges des entités fonctionnelles du NGN Multimédia, nous
allons estimer la prévision du 4 décembre 2006 sur cinq ans successifs.
Figure IV.28 : Prévision du trafic EDGE des cinq zones
74
Figure IV.29 : Prévision du trafic UMTS des cinq zones
Figure IV.30 : Prévision des charges des entités fonctionnelles
Figure IV.31 : Courbe de prévision des charges des M-MGW et IMS-MGW
75
Figure IV.32 : Courbe de prévision des charges des MSC Server et MGCF
Figure IV.33 : Courbe de prévision des charges des SGSNs et GGSNs
Ces courbes donnent une illustration graphique du module de prévision des charges des
entités M-MGW, IMS-MGW, MSC Server, MGCF, SGSN et GGSN. Par exemple dans la
figure IV.31, la courbe en noire représente l’évolution de la charge en Kbits des IMS-MGW à
76
installer dans la zone du Grand Tunis sur une période de cinq ans à partir du 4 décembre
2006. Quant à la courbe en rouge, elle traduit l’évolution de la charge en Kbits des M-MGW
au cours de cinq ans.
Pour résumer ce scénario de dimensionnement, nous avons utilisé des rapports récapitulatifs
qui contiennent à la fois les paramètres d’entrée saisis par l’utilisateur et les résultats
correspondants.
Figure IV.34 : Rapport Technique de dimensionnement des cinq zones
77
IV.7 Conclusion
Dans ce chapitre, nous avons présenté notre outil de dimensionnement d’un réseau NGN. Une
description détaillée des modules de l’outil a été faite, suivie d’une présentation des interfaces
développées. Aussi modeste qu’il soit, cet outil présente deux avantages majeurs : son
extensibilité et sa facilité d’utilisation.
Dans la dernière partie de ce chapitre, nous avons testé notre outil par l’intermédiaire des
scénarios de dimensionnement.
78
Conclusion générale
Conclusion générale
Dans le cadre de ce projet de fin d’études, nous nous sommes intéressés à l’étude et
dimensionnement d’un réseau de nouvelle génération (NGN) avec en perspective, d’abord de
proposer des solutions concrètes de stratégies de migrations des réseaux actuels vers
l’architecture de nouvelle génération ; ensuite l’étude exhaustive du processus de
dimensionnement et enfin la conception et la réalisation d’un outil de dimensionnement avec
validation de cet outil par des scénarios.
A l’issue de ce travail, nous voulons insister sur l’importance des deux concepts : NGN
Téléphonie et NGN Multimédia. Les apports de ces concepts sont clair à travers : la
transformation de la topologie du réseau avec réduction du nombre de liens entre
commutateurs, une solution reposant sur le déploiement des Media Gateways, softswitchs
nécessite moins d’équipements, moins de sites et moins de personnel, développement de
nouveaux services et des gains à réaliser par l’opérateur.
A travers les résultats obtenus dans les deux scénarios de dimensionnement, nous
recommandons fortement le déploiement de ces deux concepts.
Au delà de ce projet de fin d’études, l’outil est susceptible de plusieurs extensions :
Le dimensionnement de la signalisation pourra être inclus.
Un algorithme d’optimisation plus performant pour le réseau de transport qui prendra
en compte tous les routeurs et les capacités exactes des liaisons inter-routeurs.
L’enrichissement de la méthode de dimensionnement en spécifiant par exemple
d'autres paramètres non tenus en compte dans le processus de dimensionnement.
La prise en compte d’autres réseaux d’accès.
79
Bibliographie
Bibliographie
[1] Rapport de l’ETSI-NGN Starter Groupe, compte-rendu de l’assemblée GA38 des 20-
21/11/01.
[2] Cabinet Acrome, ‘‘Etude technique, économique et réglementaire de l’évolution vers les
réseaux de nouvelle génération’’, ART, Septembre 2002.
http:// www.art-telecom.org/ngnsep02.pdf
[3] Simon ZNATY, Jean-Louis DAUPHIN, ‘‘Architecture NGN : Du NGN Téléphonie au

NGN Multimédia’’, 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 réseau des opérateurs fixes’’, ARCEP, Janvier
2006.
[6] Simon ZNATY, ‘‘Next Generation Network (NGN) dans les réseaux mobiles’’, EFORT,
2005.
[7] Sami Tabbane, ‘‘Ingénierie des réseaux cellulaires‘‘, HERMES Science Publications,
Paris 2002.
[8] G. Van Hoey, S. Van den Bosch, P. de La Vallée Poussin, H. De Neve, G. Petit, ‘‘Le
dimensionnement des futurs réseaux de transport pour les applications téléphoniques en
temps réel’’, Revue des Télécommunications d’Alcatel, 2éme trimestre 2001.
[9] 3GPP, ‘‘Quality of Service concept and architecture’’, TS 23.107, R5, Décembre 2002.
[10] UIT, ‘‘Incidences des nouvelles techniques sur les réseaux de télécommunications’’, 14
novembre 2000
[11] Daniel Kofman, ‘‘Synthèse sur l'évolution des réseaux de télécommunications’’, 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
80
Bibliographie
[14] Asia Pacific Telecommunications (APT), ‘‘Contribution on NGN network planning’’,

Development Forum, July 2005.
http://www.APT-ADF/xE.doc
[15] Xavier Voisin, ‘‘Téléphonie IP et évolution des réseaux’’, UIT, Yaoundé, avril 2004.
[16] A. Krendzel, V. Derjavina, S. Lopatin, ‘‘Téléphonie Method for Estimating Parameters

of NGN traffic’’, St.-Petersburg Research Institute of Telecommunications, Russia.
[17] Souheil Marine, ‘‘New trends in telecommunications’’, UIT/BDI Arab régional

workshop, Syria, July 2002.
81
Titre
Etude et Dimensionnement d’un Réseau de Nouvelle Génération (NGN)
Cas d’étude : Tunisie Télécom
Résumé
La commutation téléphonique évolue. Une nouvelle génération d’architectures de réseaux
apparaît permettant d’offrir de nouveaux services émergents mixant voix, vidéo et données :
Les Next Generation Networks (NGN).
L’architecture NGN vise deux modes de fonctionnement : NGN téléphonie pour l’émulation
du RTC lors du remplacement des commutateurs téléphoniques et NGN multimédia (aussi
appelé IMS) pour directement offrir des services multimédia à partir d’accès tels que xDSL, le
câble, l’UMTS, etc.
Le but de ce projet de fin d’études est de présenter les principes, les architectures de réseau et
de service NGN et IMS et la migration vers ces architectures.
La réalisation d’un outil universel de dimensionnement de réseaux NGN et une étude de cas
de dimensionnement utilisant ledit outil occupent une partie importante de ce rapport.
Mots clés
NGN, IMS, transport, contrôle, services, Media Gateway, Softswitch, convergence,
migration, dimensionnement, optimisation, prévision.

Etude Et Dimensionnement D'un Réseau NGN

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Etude Et Dimensionnement D'un Réseau NGN

Enviado por

Direitos autorais:

Formatos disponíveis

RAPPORT DE PROJET DE FIN D’ETUDES

Réseaux et Services Mobiles

Etude et Dimensionnement d’un

Projet réalisé en collaboration entre

Année universitaire : 2005/2006

A mes chers parents

à mes deux soeurs Nadia et Khadija

à tous mes amis de Sup’Com

à tous ceux qui m’ont aidé afin de réaliser ce travail,

et à tous ceux que j’aime et qui m’aiment.

A tous, je dédie ce travail

A son terme, je tiens à exprimer ma profonde gratitude à mon encadreur M. Anouar

Chapitre I : Architecture NGN : Du NGN Téléphonie au NGN Multimédia.................... 3

Chapitre II : Stratégies de migration des réseaux actuels vers NGN ............................... 21

Chapitre III : Processus de dimensionnement d’un réseau NGN..................................... 35

III.1 Introduction ................................................................................................................... 35

Chapitre IV : Outil de dimensionnement et validation sur des scénarios........................ 52

IV.1 Introduction ................................................................................................................... 52

Conclusion générale .............................................................................................................. 79

Figure I.1 : Principe général d’architecture d’un réseau NGN.................................................. 4

Tableau II.1 : Architecture de réseau UMTS R5..................................................................... 33

Organigramme III.1 : Organigramme de calcul du trafic RTC/RNIS...................................... 37

AAL2 ATM Adaptation Layer2

de réseaux ainsi que le dimensionnement des entités fonctionnelles de cette architecture en

» gèrent respectivement la conversion des flux de données et de signalisation aux

Figure I.1 : Principe général d’architecture d’un réseau NGN

I.3 Pourquoi Le NGN ?

I.4 Types de NGN

I.5 Avantages du NGN

I.6 Architecture NGN

Figure I.2 : Architecture simplifiée des NGN

I.6.1 Les entités fonctionnelles du coeur de réseau NGN

La réservation des ressources dans le MG et le contrôle des connexions internes au

A l’interconnexion avec les réseaux de signalisation SS7, généralement via des

Figure I.3 : Les familles de protocoles d’un réseau NGN

I.7 NGN Téléphonie

Figure I.4 : Exemple d’architecture NGN Téléphonie

I.7.2 Services dans le RTC versus Services dans le NGN Téléphonie

Figure I.5 : Services dans le RTC

Figure I.6 : Services dans le NGN Téléphonie

I.8 NGN Multimédia ou IMS (IPMultimedia Subsystem)

L’architecture globale IMS est décrite à la figure I.7.

Figure I.7 : Exemple d’architecture NGN Multimédia

I.8.3 Entités de Réseau IMS

Figure I.8 : Entités de Réseau IMS

I.8.3.4 MGCF, IMS-MGW et T-SGW : Interfonctionnement avec le RTC

Supporte généralement des fonctions de conversion du média et de traitement du

Figure I.9 : Interfonctionnement entre RTC et IMS

I.9 Les services offerts par les NGN

II.2 Migration des réseaux fixes vers NGN

Dans ce qui suit, nous utiliserons la terminologie suivante (figure II.1) :

Figure II.1 : Hiérarchie des commutateurs du réseau RTC

II.2.1 Scénario 1 : Mise en place de solutions NGN au niveau de transit

II.2.1.2.2 Exemple 2 : Migration du trafic de transit au niveau national

II.2.2 Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur

Figure II.4 : Architecture d’une solution NGN de classe 4

II.2.3.2 Impacts sur l’architecture du réseau

II.2.3.3 Raccordement de l’abonné

Figure II.5 : Architecture d’un réseau NGN de classe 5

II.2.4 Scénario 4 : Mise en place de solutions tout IP en overlay

II.2.4.1 Impacts sur l’architecture du réseau

Figure II.6 : Architecture overlay VoIP

II.2.4.2 Les différentes phases de la stratégie de migration overlay