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

i

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

ii

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.

iii

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

iv

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.2 Impacts sur l’architecture du réseau .................................................................. 26 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.1 Impacts sur l’architecture du réseau .................................................................. 28 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

v

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

vi

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

vii

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

viii

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

ix

Liste des organigrammes

Organigramme III.1 : Organigramme de calcul du trafic RTC/RNIS...................................... 37 Organigramme III.2 : Organigramme de calcul du trafic GSM/GPRS.................................... 37 Organigramme III.3 : Organigramme de dimensionnement des 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

x

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

xi

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

Introduction générale

1


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


2

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.

Architecture NGN : Du NGN Téléphonie au NGN Multimédia

3

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


4

» 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,


5

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.


6

� 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.


7

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.


8

� 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


9

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.


10

� 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


11

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


12

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


13

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).


14

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).


15

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.


16

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.


17

� 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.


18

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.


19

� 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


20

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.

Stratégies de migration des réseaux actuels vers NGN

21

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.


22

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

� Commutateur de classe 5 pour les commutateurs locaux.

� Commutateurs de classe 4 pour les commutateurs à autonomie 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.


23

� 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


24

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 II.2.2.1 Définition

L’opérateur choisit de mettre en place une architecture NGN qui a vocation également à

agréger le trafic local, et conserve son réseau d’accès traditionnel. Ce 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.


25

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 II.2.3.1 Définition

Les commutateurs de classe 5 constituent le point de raccordement avec l’abonné pour la

fourniture des services voix basiques. Les opérateurs historiques possèdent plusieurs milliers

de 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.


26


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.


27

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.


28


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


29

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.


30

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


31

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


32

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).


33

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.

Fonction UMTS Rôle Correspondance architecture NGN

CSCF (Call State Control Server)

Contrôle d’appel multimédia Dialogue avec le MGCF avec le protocole SIP-T

Serveur SIP évolué (ajout fonctions spécifiées par le 3GPP)

MGCF (Media Gateway Controller Function)

Contrôle de la ou des Media Gateways qui lui sont rattachées, avec le protocole H.248 (+ extensions 3GPP)

Media Gateway Controller (Cf. IEFT, groupe Megaco)

T-SGW (Transport Signalling Gateway)

Gestion de l’interfonctionnement de la signalisation avec le réseau commuté fixe (adaptation des couches basses)

Signalling Gateway

R-SGW (Roaming Signalling Gateway)

Gestion de l’interfonctionnement de l’itinérance entre le réseau UMTS R4/R5 et les réseaux UMTS R99, GSM et GPRS, avec adaptation des couches basses de signalisation

Signalling Gateway Spécifique mobile

MRF (Multimedia Ressource Function)

Gestion des appels multimédia multiparties et de conférence

Fonction MCU dans H.323 (fonction MCU ou utilisation du multicast dans SIP)

HSS (Home Subscriber Server)

Evolution du HLR pour incorporer la gestion du profil de services IP multimédia de l’utilisateur (fonction serveur UMS-User Mobility Server)

Fonction SIP register

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


34

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.

Processus de dimensionnement d’un réseau NGN

35

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


36

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,


37

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


38

� 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


39

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]

Soit 3600

iii

DMCTAHCα ×= (III.1)

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] :

convconv kN αα += (III.2)

Avec )(log /10/ RNISRTCRNISRTC GoSk −= (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) :

( ) ( ) KbitsNNKbitsAconv 409620483264 ×=××= (III.4)

Donc le trafic total en Kbits généré par un CT est donné par :

streamerconvACTtotalTrafic αα ++= int__ (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 :

CTtotalTrafic(Kbits) RTC/RNIS éré_réseauTrafic_génCT

__∑= (III.6)

� 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 :


40

MSCtotalTrafics)GPRS (Kbit GSMéré_réseauTrafic_génMSC

__/ ∑= (III.7)

� 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) :

(Kbits) RTC/RNIS éré_réseauTrafic_génal (Kbits)Trafic_tot =

Kbits)GSM/GPRS (éré_réseauTrafic_gén+ (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 :

2048MG-CTal_CTTrafic_totN = (III.9)

Dans le cas du réseau d’accès GSM/GPRS, le nombre de liens MSC-MG en E1 est calculé

comme suit:

2048MG-MSCal_MSCTrafic_totN = (III.10)

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 :

GCapacité_Mal (Kbits)Trafic_totNombre_MG = (III.11)

Dans cette étape de dimensionnement, nous allons nous limiter au calcul de la charge des

Media Gateways car nous ne savons pas leur capacité qui est un paramètre laissé au choix de

l’opérateur.

La charge des MG est calculée comme suit :

al (Kbits)Trafic_tots)e_MG (KbitCh =arg (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 :

∑∑∑∑ +=MSC i

iCT i

i TAHCTAHCC)ch (en TAHe_SoftswitCh arg (III.13)


41

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 à :

Kbps ,bits bits /B ioncommunicat 62579850408

50102464 =××

+×= (III.14)

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 :

∑ ×=i

iioncommunicaticanalcanal BNB ,, (III.15)

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


42

refuse une demande de communication entre les deux passerelles considérées parce que le

canal achemine déjà Ncanal,i communications :

( )( )

( )GoS

kA

NA

NAPicanal

icanal

N

k

ki

icanal

Ni

icanaliblocage =≤=

∑=

ε,

,

0

,,

!/

!, (III.16)

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.

canaln BCbits)bone_IP (Kotale_backCapacité_t ×= 2 (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 :

52644142 −−−− +++= BBBBBAC (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


43

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


44

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.


45

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 α telle que 1/α

= 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


46

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


47

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 Sration_UMTtaux_pénét , le

pourcentage de couverture du réseau UMTS, donc le nombre total d’abonnés UMTS est

donné par :

Sration_UMTtaux_pénétonnés_GSM Nombre_abnnés_UMTS Nombre_abo ×= (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 à :

( )nés_UMTSombre_abonnnés_GSM-NNombre_abo nnés_EDGE Nombre_abo =

Eration_EDGtaux_pénét× (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


48

streaming). Soit Ai le nombre d’abonnés de technologie i et Tj le taux d’activité de service j.

Nij est donné par : jiij TAN ×= (III.21)

Par la suite, nous déterminons le trafic généré par service pour les réseaux UMTS et EDGE :

jjjjUMTSjUMTS serviceimaldébitappelduréeappelstauxNKbitsTrafic _max___)( ,, ×××=

Jsourceactivitéstaux __× (III.22)

jjjjEDGEjEDGE serviceimaldébitappelduréeappelstauxNKbitsTrafic _max___)( ,, ×××=

Jsourceactivitéstaux __× (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 :

( ) eractifUMTSeractifUMTS TraficKbits fic_généréVolume_tra int,int, =

( ) gstreaUMTSgstreaUMTS TraficKbits fic_généréVolume_tra min,min, =

Tandis que pour le service conversationnel, le volume de trafic généré est calculé comme

suit :

( ) convUMTSconvUMTS erneTrafic_Kbits fic_généréVolume_tra ,, int=

GSMePourcentagexterneTrafic convUMTS __ , ×+

RTCePourcentagexterneTraficTrafic convUMTSconvUMTS __ ,, ×−= (III.24)

Avec e circuiters % trafic vTraficerneTrafic_ext UMTS,convUMTS,conv mod×= (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.


49

∑∑==

+=3

1,

3

1, ____

JjEDGE

JjUMTS érétrafic_génVolumeérétrafic_génVolumetotaltraficVolume

(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 :

_Mé__

_M_MGWCapacit

AtotaltraficVolumeMGWsNombre conv+

= (III.27)

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 :

AtotaltraficVolumebits)eM_MGWs (KCh conv+= __arg (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 :

( ) e circuiters % trafic vTraficTraficKbitsRTCverstraficVolume convEDGEconvUMTS mod)(___ ,, ×+=RTCePourcentag _×

(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 :

MGWIMSCapacitéARTCtraficVolume

MGWsIMSNombre conv

____

__+

= (III.30)

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.

( ) onnelconversatiappeltauxNNMGCFeCh convEDGEconvUMTS ___arg ,, ×+=

RTCePourcentage circuiters % trafic v _mod ××

(III.31)


50

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.

( ) onnelconversatiappeltauxNNServerMSCeCh convEDGEconvUMTS ____arg ,, ×+=

GSMePourcentage circuiters % trafic v _mod ×× (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 :

EDGESAUepourcentagEDGEsAbonnNombreEDGESAUNombre ___é___ ×= (III.33)

UMTSSAUepourcentagUMTSsAbonnNombreUMTSSAUNombre ___é___ ×= (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 :

( )SGSNcapacit

UMTSSAUNombreEDGESAUNombreSGSNsNombre_é

_____ += (III.35)

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

( ) ( tionnele_conversaité_servictaux_activnnés_UMTSNombre_abo _UMTS Nombre_PDP ×= eractifce_vité_servitaux_ acti int+

)gce_streavité_servitaux_ acti min+ (III.36)


51

� Calculer le nombre de contextes PDP générés par les abonnés EDGE

( ) ( tionnele_conversaité_servictaux_activ_EDGENombre_SAU _EDGE Nombre_PDP ×=

eractifce_vité_servitaux_ acti int+

)gce_streavité_servitaux_ acti min+ (III.37)

� Le nombre total de contextes PDP activé

_EDGE Nombre_PDP_UMTSNombre_PDP_total Nombre_PDP += (III.38)

Par la suite, nous déterminons le nombre des GGSNs selon la capacité choisie par

l’opérateur :

é_GGSN

___capacit

totalPDPNombreGGSNsNombre = (III.39)

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.

Outil de dimensionnement et validation sur des scénarios

52

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.


53

� 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.


54

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.


55

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.


56

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.


57

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 :

( ) btaty +×= (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


58

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.


59

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.


60

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


61

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).

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

GoS

(%)

TAHC

voix

DMC

voix

TAHC

donnée

DMC

donnée

TAHC

vidéo

DMC

vidéo

CT1 3 101944 70 s 1861 1194 s 0 0 Réseau RTC/RNIS

CT2 3 30461 70 s 0 0 0 0

MSC1 3 39014 43 s 0 0 0 0

MSC2 3 92785 33 s 0 0 0 0 Réseau GSM/GPRS

MSC3 3 90000 33 s 0 0 0 0


62

En cliquant sur le bouton « Ajouter », les cases de saisie de TAHC et DMC pour chaque

service seront 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


63

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).


64

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]


65

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


66

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


67

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


68

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


69

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


70

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 (%)

(Pourcentage SAU UMTS) 100 90 90 80 90

Abonnés paquet attachés (%)

(Pourcentage SAU EDGE) 50 35 39 32 33

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


71

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.


72

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


73

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).


74

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


75

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


76

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 à


77

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


78

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.

Conclusion générale

79

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.

Bibliographie

80

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. http://www.efort.com [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. http://www.efort.com [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

Bibliographie

81

[14] Asia Pacific Telecommunications (APT), ‘‘Contribution on NGN network planning’’, Development Forum, July 2005. http://www.APT-ADF/xE.doc [15] Xavier Voisin, ‘‘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.

TitreTitreTitreTitre Etude et Dimensionnement d’un Réseau de Nouvelle Génération (NGN)

Cas d’étude : Tunisie Télécom

RésuméRésuméRésumé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ésMots clésMots clésMots clés NGN, IMS, transport, contrôle, services, Media Gateway, Softswitch, convergence,

migration, dimensionnement, optimisation, prévision.

Documents

Etude et Dimensionnement d’un Réseau NGN