Réseau Et Service Mobile

Cycle de formation des ingnieurs en Tlcommunications
Option :
Rseaux et Services Mobiles (RSM)
Rapport de Projet de fin dtudes

Thme :
Stratgie dintroduction du concept IMS dans un rseau de tlcommunication Etude de cas Tunisie Tlcom
Ralis par :
Naouel Ghanmi
Encadr par:
M. Jamel Sakka M. Rached Hamza

Travail propos et ralis en collaboration avec
Anne universitaire : 2005/2006
Projet de fin dtude
Ddicace
A ma chre grand-mre A mon pre Abbs et ma mre Chfia A mon frre Rami et ma s ur Nouha A toute ma famille A toi Amor A mes amies Sameh, Raja et Refka A tous ceux qui nous sont chers Que vous trouvez dans ce modeste travail l'expression de ma reconnaissance, mon amour, mon amiti et mon estime
Naouel
Avant propos
Ce travail a t ralis dans le cadre de notre projet de fin dtudes lcole suprieure des communications de Tunis, en collaboration avec loprateur Tunisie Tlcom, pour lobtention du diplme dingnieur en tlcommunication option Rseaux et Services Mobiles. Ce stage tant parvenu terme, je maperois que le temps a vite pass, heureusement que les connaissances, les bons souvenirs font toujours durer la rjouissance. Et cest en aveu du succs de ce stage que mes fervents mercis se vouent, Mr Rached Hamza, matre assistant SUPCOM, pour sa serviabilit et ses hautes qualits morales, pour son soutien et ses conseils aviss. Je tiens galement prsenter mes sincres remerciements et ma profonde gratitude Mr Jamel Sakka, chef division Tunisie Tlcom, pour sa disponibilit, sa collaboration, sa modestie et sa sympathie, pour ses comptences, sa pdagogie et ses directives fructueux quils na cess de me prodiguer tout au long de ce projet, quil soit avis ici de mes sincres mercis. Jadresse aussi ma plus vive reconnaissance tous mes enseignants de SUPCOM pour la formation quils mont donn ainsi qu'aux membres de jury qui ont accept de juger mon travail. Finalement, je remercie tous ceux qui n'ont pargn aucun effort, de prs ou de loin, pour me permettre d'accomplir mon travail et j'espre que a sera le bon dpart pour des travaux ultrieurs.
ii
Rsum
Face lvolution des rseaux de tlcommunication vers un concept tout IMS, les oprateurs sont confronts, aujourdhui, une mutation majeure : le coeur de leur rseau doit voluer pour acheminer des trafics varis et tre compatible avec des offres de services rgulirement renouveles dans un contexte IMS. Les travaux mens dans le cadre de ce projet ont cern l'tude des concepts NGN et IMS, les stratgies de migrations vers ces concepts et les rgles de planification et de dimensionnement des rseaux IMS. Les rsultats de cette tude ont permis le dveloppement d'un outil informatique d'aide au dimensionnement des rseaux IMS. En particulier, nous avons arrt une stratgie optimale pour lintroduction de ce concept dans le rseau de Tunisie Tlcom. Ensuite nous avons appliqu notre outil de dimensionnement au futur rseau IMS de notre oprateur historique, et on a fini par la proposition dune liste de recommandations prendre en compte lors dune migration vers IMS.
Mots cls : IMS, NGN, rseau c ur, convergence fixe/mobile, voix/data, stratgie de migration, modle de trafic, dimensionnement, MGW, MGCF, CSCF.
iii
Table des matires

Introduction gnrale ........................................................................................................ 1 Chapitre I: Etude des concepts NGN et IMS .............................................. 3
Introduction ..................................................................................................................... 3 1. Le contexte et les enjeux des rseaux et des services de nouvelle gnration ............ 3 1.1. Les volutions profondes du secteur des tlcommunications .................................. 3 1.2. Le dveloppement de nouvelles gammes de services ............................................... 4 1.3. Progressions technologiques denvergure dans le domaine des rseaux de donnes . 4 2. Etude du concept NGN ................................................................................................ 5 2.1. Approche gnrale du concept NGN ....................................................................... 5 2.2. Modle darchitecture en couche ............................................................................. 7 2.3. Evolution des entits et des protocoles du c ur de rseau NGN .............................. 8 2.3.1. Principe gnral et vue densemble................................................................... 8 2.3.2. Les entits principales du c ur de rseau NGN ................................................ 9 2.3.3. Les familles de protocoles dun rseau NGN ...................................................11 3. Les rseaux NGN dans le contexte d une autre volution technologique majeure : Etude du concept IMS ....................................................................................................13 3.1. Brve dfinition de lIMS.......................................................................................13 3.2. NGN/IMS et convergence fixe/mobile ...................................................................14 3.3. Impacts de lIMS pour les utilisateurs dun rseau NGN ........................................14 3.4. Architecture IMS ...................................................................................................15 3.4.1. Structuration en couche de larchitecture IMS .................................................15 3.4.2. IMS et SIP.......................................................................................................16 3.4.3. Les principales entits du rseau IMS ..............................................................17 Conclusion.......................................................................................................................20
iv
Chapitre II: Scnarios de migration vers IMS.......................................... 21

Introduction ....................................................................................................................21 1. Approches de migration: Etat de l art .......................................................................21 1.1. Concept de migration .............................................................................................21 1.2. Principaux scnarios de migration vers les rseaux de nouvelles gnrations..........22 2. Scnarios de migration vers NGN ..............................................................................23 2.1. Migration des rseaux PSTNs ................................................................................23 2.1.1. Etat actuel du rseau PSTN .............................................................................23 2.1.2. Typologie des scnarios de migration dun rseau PSTN.................................25 2.1.3. Scnarios de migration du c ur du rseau PSTN/ISDN vers NGN ..................26 2.2. Migration des rseaux mobiles ...............................................................................30 2.2.1. Du GSM 2G vers GPRS 2.5G..........................................................................30 2.2.2. Du GPRS 2.5G vers lUMTS...........................................................................31 2.2.3. Nouvelle architecture du rseau mobile dans une approche NGN ....................33 2.3. Migration des rseaux commutation de paquets ...................................................34 2.3.1. Situation actuelle .............................................................................................34 2.3.2. Migration IPv6 .............................................................................................35 2.3.3. Exigence dun mcanisme de garantie de qualit de service.............................36 3. Scnarios de migration vers IMS ...............................................................................36 3.1. Etape 1 : Convergence des services fixe et mobile..................................................36 3.2. Etape 2 : Convergence des bases de donnes des rseaux fixe et mobile .................37 3.3. Etape 3 : Migration vers le tout IMS.......................................................................38 3.3.1. Scnario 1 : partir du rseau mobile ..............................................................38 3.3.2. Scnario 2 : partir du rseau fixe ...................................................................39 Conclusion.......................................................................................................................40
Chapitre III: Dimensionnement et stratgie de migration vers IMS - Etude de cas : Tunisie Tlcom............................................................................. 42
Introduction ....................................................................................................................42 1. Dveloppement d une stratgie de migration vers IMS : Etude de cas de Tunisie Tlcom ...........................................................................................................................42 1.1. Topologie du rseau existant ..................................................................................42 1.1.1. Le Rseau IP ................................................................................................43 1.1.2. Le rseau tlphonique classique ...............................................................43 1.1.3. Le rseau mobile GSM................................................................................44 1.2. Rgles principales pour une migration optimale .....................................................46 1.3. Migration du rseau de Tunisie Tlcom vers IMS.................................................47 1.3.1. Migration vers NGN....................................................................................47 1.3.2. Migration vers IMS .....................................................................................52 2. Evaluation du trafic niveau accs...............................................................................54 2.1. Les classes de service .............................................................................................55 2.1.1. Services de type conversationnel ...............................................................56 2.1.2. Services flux continu................................................................................56 2.1.3. Services Interactifs ......................................................................................56 2.1.4. Services en mode tlchargement ou background ....................................57 2.2. Modlisation du trafic ............................................................................................57 2.2.1. Modle de trafic pour le service conversationnel.....................................57 2.2.2. Modle de trafic pour le service flux continu ........................................58 2.2.3. Modle de trafic pour le service interactif ................................................58 2.2.4. Modle de trafic pour les services darrire plan .....................................59 2.3. Scnarios retenus ...................................................................................................59 2.4. Calcul du trafic du rseau daccs...........................................................................60 2.4.1. Dtermination du nombre dabonns par technologie..............................60 2.4.2. Dtermination du trafic achemin au niveau accs ..................................62 3. dimensionnement de quelques entits du rseau IMS ...............................................65
vi
3.1. Gnralit sur le dimensionnement.........................................................................65 3.2. Processus de dimensionnement ..............................................................................65 3.2.1. Dimensionnement des MGWs ....................................................................65 3.2.2. Dimensionnement de MGCF ......................................................................67 3.2.3. Dimensionnement de CSCF ........................................................................68 Conclusion.......................................................................................................................68
Chapitre IV: Dveloppement d un outil de dimensionnement du c ur de rseau IMS et son application au rseau de Tunisie Tlcom .................. 69
Introduction ....................................................................................................................69 1. Spcifications de l outil ...............................................................................................69 1.1. Donnes de dimensionnement ................................................................................69 1.1.1 Donnes dentre ..........................................................................................70 1.1.2 Rsultats de sortie.........................................................................................70 1.2. Synoptique de linterface utilisateur de loutil ........................................................70 1.3. Outil de dveloppement..........................................................................................72 2. Ralisation de l outil ...................................................................................................72 2.1 Au dmarrage..........................................................................................................72 2.2. Spcifications des paramtres gnraux..................................................................73 2.3. Configuration du rseau .........................................................................................73 2.3.1. Spcification du modle de trafic data ......................................................74 2.3.2. Configuration des diffrentes zones du rseau .........................................75 2.3.3. Spcification des paramtres du codeur audio..........................................76 2.4. Affichage des rsultats du dimensionnement ..........................................................77 3. Etude de cas : dimensionnement du rseau IMS de Tunisie Tlcom ......................78 3.1. Les paramtres gnraux de dimensionnement .......................................................78 3.2. Rpartition des abonns par zone ...........................................................................78 3.3. Spcification des paramtres de la voix classique ...................................................79
vii
3.4. Modle de trafic data..............................................................................................80 3.5. Rsultats et analyse du dimensionnement ...............................................................82 4. Listes de recommandations ........................................................................................84 Conclusion.......................................................................................................................85
Conclusion gnrale ......................................................................................................... 86 Annexe A: Calcul du dbit d accs................................................................................... 88 Bibliographie................................................................................................................... 91 Glossaire ...........................................................................................................................93
viii
Liste des figures
Figure I-1 : Vue globale dun rseau NGN...........................................................................6 Figure I-2 : Architecture en couche dun rseau NGN..........................................................8 Figure I-3 : Architecture simplifie dun rseau NGN ..........................................................9 Figure I-4 : Larchitecture de Rseau et de Service IMS.....................................................15 Figure II-1 : Description dun rseau RTC .........................................................................24 Figure II-2: Scnario 1 .......................................................................................................28 Figure II-3 : Scnario 2 ......................................................................................................29 Figure II-4: Scnario 3 .......................................................................................................30 Figure II-5: Migration du rseau GSM vers GPRS .............................................................31 Figure II-6 Migration vers UMTS release 99......................................................................32 Figure II-7 : Migration vers UMTS release 5 ....................................................................32 Figure II-8 : Convergence des services fixe et mobile ........................................................37 Figure II-9 : Mise en uvre dun SHLR dans le rseau PSTN............................................37 Figure II-10 : Interfonctionnement entre rseau fixe et rseau mobile ................................38 Figure II-11 : introduction de lIMS dans le rseau mobile.................................................39 Figure II-12 : migration vers un rseau tout IMS................................................................39 Figure II-13 : Migration du rseau fixe vers IMS ...............................................................40 Figure II-14 : Propagation de lIMS vers le rseau mobile..................................................40 Figure III-1 : Backbone IP/MPLS de Tunisie Tlcom.......................................................43 Figure III-2 : CTNs du rseau fixe de Tunisie Tlcom......................................................44 Figure III-3 : Rseau mobile de Tunisie Tlcom et interconnexion avec le rseau fixe......45
ix
Figure III-4 : Backbone IP/MPLS de Tunisie Tlcom dans un concept NGN....................47 Figure III-5 : Interconnexion des MGWs au rseau IP/MPLS.............................................48 Figure III-6 : Premier scnario de migration du rseau de Tunisie Tlcom vers NGN.......49 Figure III-7 : Deuxime scnario de migration du rseau de Tunisie Tlcom vers NGN ...50 Figure III-8 : Optimisation de la migration du rseau de Tunisie Tlcom vers NGN .........51 Figure III-9 : Le rseau c ur de Tunisie Tlcom dans une approche NGN .......................53 Figure III-10 : Evolution du softswitch vers IMS ...............................................................54 Figure III.11 : processus de calcul du nombre dabonns par technologie...........................61 Figure III.-12 : Calcul du trafic total niveau accs ..............................................................62 Figure III.13 : Dimensionnement de MGW........................................................................66 Figure IV-1 : Synoptique de linterface utilisateur..............................................................71 Figure IV-2 : Ecran de dmarrage ......................................................................................72 Figure IV-3 : Identification de ladministrateur ..................................................................72 Figure IV-4 : Spcification des paramtres gnraux du dimensionnement ........................73 Figure IV-5 : Configuration du rseau dimensionner .......................................................74 Figure IV-6 : Spcification du modle de trafic data ..........................................................74 Figure IV-7 : Configuration du rseau par zone..................................................................75 Figure IV-8 : Spcification des paramtres des rseaux GSM et POTS par zone ................75 Figure IV-9 : Spcification des paramtres des rseaux ADSL, EDGE et UMTS par zone .76 Figure IV-10 : Paqutisation du flux audio mode circuit ....................................................76 Figure IV-11 : Fentre daffichage des rsultats du processus du dimensionnement ...........77 Figure IV-12 : Rsultats de dimensionnement du rseau c ur de TT .................................82
Liste des tableaux

Tableau III-1 : Les diffrentes classes de service................................................................55 Tableau III-2 : Modlisation du trafic.................................................................................59 Tableau III-3 : Rpartition des abonns par service ............................................................60 Tableau III-4 : Services utiliss par chaque technologie .....................................................61 Tableau IV-1 : Rpartition des abonns par zone ...............................................................79 Tableau IV-2 : Modle de trafic des rseaux en mode circuit .............................................80 Tableau IV-3 : Modle de trafic des services data ..............................................................81 Tableau IV-4 : Taux dactivit des services par zone..........................................................81 Tableau IV-5 : Rsultat de dimensionnement par zone.......................................................83
xi
Introduction gnrale
Les tlcommunications font partie des technologies qui ont rvolutionn notre mode de vie au vingtime sicle. Du tlgraphe lInternet, de la tlphonie sans fil au tlphone cellulaire, les progrs tablis en la matire sont spectaculaires. Les informations transmises taient tout dabord codes en morse, puis des techniques de modulation et de codages analogiques ont permis de transmettre du son, puis des images. Ensuite la venue des techniques numriques a considrablement augment le dbit et la qualit des informations transmettre dun point un autre. Les rseaux de tlcommunications voluent aujourd'hui vers des nouvelles gnrations de rseaux (NGN). Ces derniers ont comme objectifs de faire converger les services voix, multimdia et donnes en utilisant un rseau de transport IP ou ATM et d'offrir des nouveaux services lis la mobilit des personnes. De plus, on est face, aujourdhui, une palette de services de plus en plus diversifis. En effet, le haut dbit a boulevers irrmdiablement lunivers des services en acclrant la convergence des tlcoms avec linformatique. La connectivit IP gnralise ouvre un univers toujours plus large de services indpendants de loprateur daccs. La substitution fixe mobile reste dactualit et la convergence fixe mobile sannonce comme une proche ralit. Dans ce cadre est apparu un nouveau concept : IMS (IP Multimedia Subsystem). Ce concept est conu pour rpondre toutes ces exigences en offrant aux utilisateurs la possibilit dtablir des sessions multimdia et en utilisant tout accs haut dbit et une commutation de paquets IP. Les oprateurs historiques sont ainsi confronts une mutation majeure : le coeur de leur rseau doit voluer pour acheminer des trafics varis et tre compatible avec des offres de services rgulirement renouveles dans un contexte concurrentiel de plus en plus rude.
Projet de fin d tudes - N. Ghanmi - Juin 2006
L'objectif de ce projet de fin dtude est dtudier le concept IMS et de proposer des scnarios de migration vers ce nouveau concept pour les oprateurs. En particulier, nous allons arrter une stratgie optimale pour lintroduction de ce concept dans le rseau de Tunisie Tlcom. Ensuite nous proposons un processus de dimensionnement qui sera automatis dans un outil informatique quon va appliquer au cas de notre oprateur historique. Le prsent rapport est organis en quatre chapitres : Le premier chapitre prsente une vue panoramique sur les concepts NGN et IMS, leurs principes, leurs architectures de base et lensemble des protocoles mis en uvre. Le deuxime chapitre traite la problmatique de la migration des rseaux de tlcommunication vers les rseaux de nouvelles gnrations. Dabord, on a trac les diffrentes approches dune telle migration, ensuite, on a propos des scnarios de migration vers les NGNs, puis des scnarios de migration vers un concept tout IMS. Le troisime chapitre sera consacr ltude de cas de loprateur Tunisie Tlcom Dabord, on va exploiter notre savoir faire pour arrter une stratgie de migration optimale vers IMS pour cet oprateur historique. Ensuite, on va passer dimensionner un rseau de tlcommunication bas sur un concept IMS. De ce fait, on va tablir un processus de dimensionnement bas sur lvaluation du trafic niveau accs et de la charge des quipements du rseau coeur. Finalement, dans le quatrime chapitre, on va prsenter les tapes de conception et dutilisation dun outil qui permet lautomatisation du processus de dimensionnement. Ensuite, on va appliquer cet outil au cas de Tunisie tlcom. Et on va finir par linterprtation des rsultats obtenus et par la proposition de quelques recommandations prendre en compte lors de toute migration vers IMS.
Chapitre I
Chapitre I
Etude des concepts NGN et IMS
Introduction
Lvolution progressive du monde des tlcommunications vers des rseaux et des services de nouvelle gnration est aujourdhui une tendance forte qui suscite lintrt dune majorit dacteurs. Elle rsulte de la conjonction dun ensemble de facteurs qui ont fortement excit la migration vers NGN (Next Generation Network) et puis vers IMS (IP Multimedia Subsystem). Dans ce premier chapitre, on va commencer par illustrer les diffrents enjeux et motivations qui ont pouss cette migration. Ensuite, on va passer donner une ide gnrale sur les concepts NGN et IMS, leurs principes, leurs architectures de base et lensemble des protocoles mis en uvre. Et on va finir par illustrer les nouveauts apportes par un rseau IMS et limportance de son dploiement dans un rseau de tlcommunication.
1. Le contexte et les enjeux des rseaux et des services de nouvelle gnration

1.1. Les volutions tlcommunications profondes du secteur des
Le secteur des tlcommunications a vcu des volutions importantes aucours de ces dernires annes. Ces volutions se manifestent par : La drgulation des marchs (du transport longue distance la boucle locale) : Le
cadre rglementaire actuel tend encourager la comptition et a permis un certain nombre doprateurs alternatifs de se positionner par rapport loprateur historique et de le concurrencer sur les marchs des donnes, de la voix, des services Internet et plus rcemment sur la boucle locale [1].
Chapitre I La recherche dconomies dchelle est une notion prsente dans plusieurs concepts
tlcoms qui font aujourdhui lactualit : lvolution de la tlphonie vers lIP, la convergence voix/donnes, la flexibilit rseau, les oprateurs virtuels et le partage dinfrastructure ou encore les nouvelles gnrations de rseaux mobiles conomes en ressources spectrales [1]. Lmergence de nouveaux acteurs et de nouveaux modles conomiques afin de
dvelopper de manire viable et optimise les services et les contenus : dveloppement du march des purs fournisseurs de services, partenariats entre les oprateurs de transport / accs et les fournisseurs de services. Cette tendance est favorise par les nouveaux standards (ex. : interfaces OSA Open Service Architecture en UMTS, et travaux du groupe Parlay) [1].
1.2. Le dveloppement de nouvelles gammes de services

Lvolution massive des services constate ces dernires annes est loin dtre termine. En effet, le march des systmes de communications lectroniques sapprte vivre encore de nouvelles rvolutions et des volutions fortes en terme de services proposs: Laccentuation du succs mondial dInternet et lexplosion du volume de donnes
gres, stockes et transfres. Le besoin toujours plus fort des utilisateurs dune accessibilit totale aux donnes et
aux services (Internet mobile, UMTS, WLAN, mobilit entre rseaux daccs ou terminaux de technologies diffrentes, ) potentiellement couple des services haute valeur ajoute utilisant la golocalisation. Le dveloppement de contenus et services multimdia, de plus en plus interactifs et
temps rel. Ils ncessitent techniquement dassurer diffrents modes daccs, et de dvelopper de nouveaux terminaux hybrides et multi-fonctions. Le dveloppement invitable du commerce lectronique, qui pose des problmes
techniques lis aux transactions temps rel, au paiement scuris, au dveloppement de solutions de porte-monnaie virtuel [1].
1.3. Progressions technologiques d envergure dans le domaine des rseaux de donnes

Lvolution des rseaux de transport, et notamment des couches optiques, vers le trs haut dbit (commutation optique, multiplexage en longueur donde WDM).
Chapitre I La gnralisation du protocole IP et lmergence de la nouvelle version de ce
protocole, IPv6, qui permettra notamment den amliorer les capacits dadressage et de gestion et de la scurit. Larrive maturit de technologies nouvelles comme le MPLS, qui permet de
vhiculer de manire diffrencie des flux IP avec une meilleure gestion de la qualit de service. Ces volutions permettent denvisager de manire souple la diffusion sur IP de
contenus temps rel avec des contraintes de qualit de service fortes [1]. Il rsulte de ce contexte le besoin et la faisabilit technique dune volution vers un nouveau modle de rseaux et de services appel NGN (Next Generation Networks).
2. Etude du concept NGN

2.1. Approche gnrale du concept NGN
LETSI a prsent les rseaux de nouvelle gnration comme un concept permettant de dfinir et dployer des rseaux volutifs et favorisant pour les fournisseurs de services et les oprateurs la cration et la gestion de services innovants. Ils reposent sur une architecture en couches indpendantes (transport, contrle, services) communiquant via des interfaces ouvertes et normalises. Les services doivent tre volutifs et accessibles indpendamment du rseau daccs utilis [2]. Cependant, on constate des variantes suivant lactivit et le positionnement des acteurs (constructeurs, oprateurs, fournisseurs de service). Notamment, au-del de la sparation entre domaine dorigine tlcoms ou donnes , on peut tout naturellement distinguer des thmes et des centres dintrt privilgis selon que lacteur est positionn principalement sur les couches basses (transport), moyennes (contrle) ou suprieures (services, et particulirement le domaine logiciel). Ces diffrentes visions ne sopposent pas mais se compltent. Pour cela, le concept des NGN sarticule autour de tendances globalement admises par tous ces acteurs. Au regard des rponses apportes, l'ensemble des acteurs s'accorde globalement pour dfinir les NGN comme un systme offrant des services multimdia en sappuyant sur un rseau support mutualis et caractris par plusieurs lments essentiels:
Chapitre I Un c ur de rseau unique et mutualis pour les diffrents types daccs et de services. Une architecture de c ur de rseau en 3 couches : Transport, Contrle et Services. Une volution du transport en mode paquet (IP, ou ATM court terme avec une convergence progressive vers IP) permettant la convergence des rseaux Voix/donnes et Fixe/Mobile. Des interfaces ouvertes et normalises entre chaque couche, et notamment au niveau des couches contrle et services afin de permettre la ralisation de services indpendants du rseau. Le support dapplications multiples, multimdia, temps rel, en mobilit totale, adaptables lutilisateur et aux capacits des rseaux daccs et des terminaux.
Figure I-1 : Vue globale d un rseau NGN Il existe trois types de rseau NGN : NGN class 4, NGN Class 5 et NGN Multimdia. Les NGN class 4 et class 5 sont des architectures de rseau offrant uniquement les services de tlphonie. Il sagit donc de NGN tlphonie. Dans le RTC, un commutateur class 4 est un centre de transit. Un commutateur class 5 est un commutateur daccs aussi appel centre autonomie dacheminement. Le NGN class 4 (respectivement NGN class 5) mule donc le rseau tlphonique au niveau transit (respectivement au niveau accs) en transportant la voix sur un mode paquet. Le NGN multimdia est une architecture offrant les services multimdia (exemple : messagerie vocale/vido, confrence audio/vido, Ring-back tone voix/vido) puisque l'usager a un terminal IP multimdia. Cette solution est plus intressante que les prcdentes
Chapitre I puisquelle permet loprateur dinnover en termes de services par rapport une solution NGN tlphonie qui se cantonne offrir des services de tlphonie [3].
2.2. Modle d architecture en couche

Afin de sadapter aux grandes tendances qui sont la recherche de souplesse dvolution de rseau, la distribution de lintelligence dans le rseau, et louverture des services tiers, les NGNs sont bass sur une volution progressive vers le tout IP et sont modliss en couches indpendantes dialoguant via des interfaces ouvertes et normalises : La couche Accs : regroupe les fonctions et quipements permettant de grer laccs des quipements utilisateurs au rseau, selon la technologie daccs (cble, cuivre, fibre optique, boucle locale radio, xDSL, tlphonie commute rseaux mobiles). Cette couche inclut par exemple les quipements DSLAM fournissant laccs DSL. La couche Transport : gre lacheminement du trafic, voix ou donnes, dans le ur de rseau vers sa destination. En bordure du rseau de transport, des media gateways et des signaling gateways grent respectivement la conversion des flux de donnes et de signalisation aux interfaces avec les autres ensembles rseau ou les rseaux tiers interconnects. La couche contrle : gre lensemble des fonctions de contrle des services en gnral, et de contrle dappel en particulier pour le service voix. Lquipement important ce niveau dans une architecture NGN est le serveur dappel, plus communment appel softswitch , qui gre dune part les mcanismes de contrle dappel (pilotage de la couche transport, gestion des adresses), et dautre part laccs aux services (profils dabonns, accs aux plates-formes de services valeur ajoute). La couche Services : regroupe les plates-formes dexcution de services et de diffusion de contenus. Elle communique avec la couche contrle du c ur de rseau via des interfaces ouvertes et normalises, indpendantes de la nature du rseau daccs utilis. Les services et contenus eux-mmes sont par ailleurs dvelopps avec des langages convergents et unifis.
Chapitre I
Figure I-2 : Architecture en couche d un rseau NGN Ces couches sont indpendantes et communiquent entre elles via des interfaces ouvertes. Cette structure en couches est sense garantir une meilleure flexibilit et une implmentation de nouveaux services plus efficace. La mise en place dinterfaces ouvertes facilite lintgration de nouveaux services dvelopps sur un rseau doprateur mais peut aussi savrer essentielle pour assurer linterconnexion dun rseau NGN avec dautres rseaux quils soient NGN ou traditionnels [1].
2.3. Evolution des entits et des protocoles du c ur de rseau NGN

2.3.1. Principe gnral et vue d ensemble
On rappelle que les principales caractristiques des rseaux NGN sont lutilisation dun unique rseau de transport en mode paquet (IP, ATM,) ainsi que la sparation des couches de transport des flux et de contrle des communications, qui sont implmentes dans un mme quipement pour un commutateur traditionnel. Concernant les quipements actifs du c ur de rseau NGN, ces grands principes se dclinent techniquement comme suit:
Chapitre I Remplacement des commutateurs traditionnels par deux types dquipements distincts : Dune part des serveurs de contrle dappel dits Softswitch ou Media Gateway Controller (correspondant schmatiquement aux ressources processeur et mmoire des commutateurs voix traditionnels). Et dautre part des quipements de mdiation et de routage dits Media Gateway (correspondant schmatiquement aux cartes dinterfaces et de signalisation et aux matrices de commutation des commutateurs voix traditionnels), qui sappuient sur le rseau de transport mutualis NGN. Apparition de nouveaux protocoles de contrle dappel et de signalisation entre ces quipements (de serveur serveur, et de serveur Media Gateway). Le schma suivant prsente le principe darchitecture physique dun rseau NGN.
Figure I-3 : Architecture simplifie d un rseau NGN
2.3.2. Les entits principales du c ur de rseau NGN

a) Media Gateway (MG) Un media gateway constitue un lment essentiel dploy dans un rseau NGN. Il peut par exemple se positionner entre le rseau de commutation circuit et le rseau de commutation de paquets. Dans ce cas, les media gateways transforment le trafic circuit TDM en paquets, la plupart du temps IP ou ATM, pour que ce trafic puisse ensuite tre gr par le rseau NGN. En consquence, plusieurs types de media gateway sont disponibles sur le march, en fonction du type de solution voix choisie par loprateur et du rle de ce media gateway :
Chapitre I Les passerelles VoIP pour convertir des lignes daccs TDM en flux IP, Les passerelles VoATM pour convertir des lignes daccs TDM en flux ATM, Les passerelles VoBB (DSL, cble, ) pour transformer des flux IP en signaux voix sur un rseau haut-dbit cble ou DSL. Dune manire gnrale, une passerelle de mdia a pour rle : Le codage et la mise en paquets du flux mdia reu du RTC et vice-versa (conversion du trafic TDM/IP). La transmission, suivant les instructions du Media Gateway Controller, des flux mdia reus de part et d'autre. b) Signaling Gateway (SG) La fonction Signaling Gateway a pour rle de convertir la signalisation change entre le rseau NGN et le rseau externe interconnect selon un format comprhensible par les quipements chargs de la traiter, mais sans linterprter (ce rle tant rserv au Media Gateway Controller). Notamment, elle assure ladaptation de la signalisation par rapport au protocole de transport utilis (ex. : adaptation TDM / IP). Cette fonction est souvent implmente physiquement dans le mme quipement que la Media Gateway, do le fait que ce dernier terme est parfois employ abusivement pour recouvrir les deux fonctions MG + SG. Les Gateways ont un rle essentiel : elles assurent non seulement lacheminement du trafic, mais aussi linterfonctionnement avec les rseaux externes et avec les divers rseaux daccs en ralisant : La conversion du trafic (entit fonctionnelle Media Gateway), La conversion de la signalisation associe (entit fonctionnelle Signalling Gateway). c) Le serveur d appel ou Media Gateway Controller (MGC) Dans larchitecture des rseaux NGN, le serveur dappel, aussi appel softswitch ou Media Gateway Controller (MGC) est le n ud central qui supporte lintelligence de communication. Il sagit d'un serveur informatique, dot d'un logiciel de traitement des appels vocaux. Il permet de grer : Lchange des messages de signalisation transmise de part et d'autre avec les passerelles de signalisation, et linterprtation de cette signalisation.
10
Chapitre I Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP, communication avec les serveurs dapplication pour la fourniture des services. Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge du rseau, etc. La rservation des ressources dans le MG et le contrle des connexions internes au MG (commande des Media Gateways). Physiquement, un softswitch peut tre implant sur un serveur ddi ou bien tre install directement sur un quipement diffrent comme un media gateway ou mme un commutateur traditionnel TDM. Dans ce cas, on parlera darchitecture compltement distribue [1].
2.3.3. Les familles de protocoles d un rseau NGN

Le fait dutiliser un rseau paquet pour transporter des flux multimdia, ayant des contraintes temps rel , a ncessit ladaptation de la couche Contrle. Il faut noter que ces rseaux en mode paquet taient gnralement utiliss comme rseaux de transport uniquement, en ce sens, ils noffraient pas de services permettant la gestion des appels et des communications multimdia. Cette volution a logiquement gnre de nouveaux protocoles, principalement concernant la gestion des flux multimdia, au sein de la couche Contrle. Nous les classerons en trois grandes familles : les protocoles de contrle dappels qui regroupent essentiellement H.323 et SIP, les protocoles de commande de Media Gateway constitus par MEGACO et MGCP et les protocoles de signalisation entre MGC : BICC, SIP-T, SIGTRAN. a) Les protocoles de contrle d appel Ils permettent ltablissement, dune communication entre deux terminaux ou entre un terminal et un serveur ; les deux principaux protocoles concurrents sont H.323, norme de lUIT, et SIP, standard dvelopp lIETF: La recommandation H.323 dcrit les procdures pour les communications audio et
vido sur des rseaux en mode paquet sans garantie de service. Les principales entits ncessaires la ralisation dun service de communication multimdia sur des rseaux de donnes sont :
11
Chapitre I o Les terminaux H.323 qui sont des systmes multimdia (tlphone, PC) permettant de communiquer en temps rel ; o Le getkeeper qui gre les terminaux H.323 (identification et traduction dadresses) et les tablissements dappels ; o La passerelle H.323 ou Gateway H.323 qui permet dinterfacer le rseau IP avec le rseau tlphonique classique ; o Lunit de contrle MCU (Multipoint Controller Unit) qui gre les connexions multipoint (exemple : appels de confrence). Il se dcompose en un Multipoint Controller (MC), affect la signalisation, et un Multipoint Processor (MP), ddi la transmission proprement dite. Le protocole SIP (Session Initiation Protocol) de lIETF, est un protocole de
signalisation pour ltablissement dappels et de confrences temps rel sur des rseaux IP. L'architecture de SIP est base sur des relations client/serveur. Les principales composantes sont le terminal (User Equipement), le Proxy Server, le Redirect Server et le Registrar. Les terminaux sont considrs comme clients lorsqu'ils effectuent une requte, et comme des serveurs lorsqu'ils y rpondent. Les terminaux peuvent communiquer directement entre eux ou par l'intermdiaire d'autres serveurs. Les serveurs SIP intermdiaires peuvent se comporter comme Proxy Serveur ou Redirect Server. b) Les protocoles de commande de Media Gateway Ces protocoles ont t engendrs par la sparation des couches transport et contrle et permettent au softswitch de grer les Media Gateway. MGCP (Media Gateway Control Protocol) de lIETF et MEGACO (MEdia GAteway COntroller) ou H.248, dvelopp conjointement par lUIT et lIETF, prdominent actuellement. Ces protocoles sont le canal de communication utilis pour coordonner le plan Contrle et le plan Transport. Les principales fonctions de ce canal sont : La rservation des ressources de la MG par le MGC ncessaire pour satisfaire les demandes reues par les messages de signalisation ; Le traitement des connexions dans la MG par le MGC ; La remonte par la MG des rponses aux actions demandes par le MGC ; La notification par le MG dvnements survenus au niveau mdia (dtection DTMF par exemple) ;
12
Chapitre I Le contrle du lien MG-MGC (scurit du lien, basculement vers un autre MGC ou MG) ; c) Les protocoles de signalisation entre les Softswitchs Linterconnexion des rseaux de donnes avec les rseaux existants TDM utilisant la signalisation SS7, a ncessit le dveloppement de protocoles ddis linterconnexion des rseaux et au transport de la signalisation SS7 sur des rseaux en mode paquet. Ces protocoles permettent la gestion du plan contrle. Ce sont essentiellement : BICC (Bearer Independant Call Control), SIP-T (SIP pour la Tlphonie) et H.323, au niveau du c ur de rseau ; SIGTRAN (SIGnalling TRANsport), linterconnexion avec les rseaux de signalisation SS7, gnralement via des passerelles de signalisation ou Signaling.
3. Les rseaux NGN dans le contexte d une autre volution technologique majeure : Etude du concept IMS
3.1. Brve dfinition de l IMS
Dfinie dans la spcification 3GPP Release 5 de l'UMTS, larchitecture IMS (IP Multimedia Subsystem) constitue une couche logique intermdiaire entre, d'un ct, les terminaux mobiles et les rseaux de transport orients IP et, de l'autre, les services applicatifs tlcoms grs par des serveurs oprs par loprateur ou des fournisseurs tiers. LIMS fournit un rseau IP multi-service, multi-accs, scuris et fiable : Multi-services : tout type de services dlivrs par un rseau c ur supportant diffrents niveaux de QoS pourra tre offerts lusager, Multi-accs: Tout rseau daccs large bande, fixe et mobile pourra sinterfacer lIMS. LIMS nest pas un unique rseau, mais diffrents rseaux qui interoprent grce des accords de roaming IMS fixe-fixe, fixe-mobile, mobile-mobile. LIMS est un enabler pour les fournisseurs de service afin doffrir : Des services de communication non temps rel, pseudo temps rel et temps rel suivant une configuration client-server ou entre entits paires.
13
Chapitre I La mobilit des services / Mobilit de lusager (Nomadisme). Plusieurs sessions et services simultanment sur la mme connexion rseau.
3.2. NGN/IMS et convergence fixe/mobile

Le 3GPP avait intgr dans le plan dvolution de ses spcifications techniques la capacit pour IMS de fonctionner galement avec la technologie daccs WLAN (3GPP Release 6) puis avec tout type daccs fixe ou mobile (3GPP Release 7). Le lien avec le fixe sest encore accentu avec la collaboration entre le 3GPP et le groupe TISPAN de lETSI, afin de permettre lintgration dIMS au sein du travail de standardisation des rseaux NGN fixes de lETSI. Pour les oprateurs historiques, la convergence fixe/mobile constitue une opportunit de lutter efficacement contre le phnomne de substitution fixe/mobile et un moyen de proposer des services forte diffrentiation par rapport aux oprateurs alternatifs fixes. Pour un oprateur ne disposant pas dactivits mobiles, les technologies IP sans-fil comme WiFi ou WiMAX peuvent tre une alternative. Dailleurs certains oprateurs ont toujours
considr WiFi comme une technologie cl dans son approche de convergence fixe/mobile
3.3. Impacts de l IMS pour les utilisateurs d un rseau NGN

Le principal avantage que doit amener IMS aux oprateurs rside dans sa capacit de facilitation dimplmentation et de lancement de nouveaux services. Sans IMS, la mise en oeuvre dun nouveau service implique de lourdes contraintes pour un oprateur sur son systme IT et son rseau : dveloppement et intgration de nouvelles interfaces rseaux, de nouvelles applications, de nouvelles interfaces de facturation, Autant dcueils que devrait permettre dviter IMS grce son architecture et lutilisation dinterfaces ouvertes standardises. A cela sajoute les nouvelles capacits lies lusage du protocole SIP permettant loprateur de proposer toute une gamme de services innovants. Au cours des sessions SIP inities par IMS, toutes sortes de contenus (voix, images, vido et texte) peuvent se coupler et tre changs entre deux personnes ou avec un groupe d'interlocuteurs. Aujourdhui, les premiers services IMS se limitent principalement la tlphonie sur IP dans le fixe et push-to-talk ou video sharing dans le mobile. Voici une liste non exhaustive de services gnriques IMS pouvant tre proposs : Projet de fin d tudes - N. Ghanmi - Juin 2006 14
Chapitre I Services de messagerie instantane. Services dchanges de contenus (messages, audio, vido). Services de vido tlphonie. Jeux multi-joueurs. Services Push-To-X (push-to-talk, push-to-view, push-to-video ). Services de confrence audio ou vido, supportant le partage de fichiers en temps rel.
3.4. Architecture IMS

Lintroduction de lIMS (IP Multimedia Subsystem) dans les rseaux fixe et mobile reprsente un changement fondamental dans les rseaux de tlcommunication de type voix. Les nouvelles capacits des rseaux et des terminaux, lassociation entre l Internet et la voix, le contenu et la mobilit donnent naissance des nouveaux modles de rseaux et surtout offrent un formidable potentiel pour dvelopper de nouveaux services. Dans cet objectif, lIMS est conu pour offrir aux utilisateurs la possibilit dtablir des sessions multimdia en utilisant tout accs haut dbit et une commutation de paquets IP [4].
3.4.1. Structuration en couche de l architecture IMS

A la manire de lapproche NGN, larchitecture IMS reprend une approche en couches reprsente par le schma suivant :
Figure I-4 : L architecture de Rseau et de Service IMS
15
Chapitre I Quatre couches importantes sont identifies : La couche accs peut reprsenter tout accs haut dbit tel que : UTRAN (UMTS Terrestrial Radio Access Network), CDMA2000 (technologie daccs large bande utilise dans les rseaux mobiles aux Etats-Unis), xDSL, rseau cble, Wireless IP, WiFi, etc. La couche transport reprsente un rseau IP. Ce rseau IP pourra intgrer des mcanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche transport consiste donc en des routeurs (edge router laccs et en core router en transit) relis par un rseau de transmission. Diffrentes piles de transmission peuvent tre considres pour le rseau IP: IP/ATM/SDH, IP/Ethernet, IP/SDH, etc. La couche contrle consiste en des contrleurs de session responsables du routage de la signalisation entre usagers et de linvocation des services. Ces n uds sappellent des CSCF (Call State Control Function). IMS Introduit donc un environnement de contrle de session sur le domaine paquet. La couche application introduit les applications (services valeur ajoute) proposes aux usagers. Loprateur peut se positionner grce sa couche contle en tant quagrgateur de services offerts par loprateur lui-mme ou par des tiers. La couche application consiste en des serveurs dapplication (AS, Application Server) et des MRF (Multimedia resource function) que les fournisseurs appellent serveurs de mdia IP (IP MS, IP Media Server).
3.4.2. IMS et SIP

SIP est un protocole de signalisation dfini par lIETF (Internet Engineering Task Force) permettant ltablissement, la libration et la modification de sessions multimdias. SIP est utilis dans lIMS comme protocole de signalisation pour le contrle de sessions et le contrle de service. Il remplace donc la fois les protocoles ISUP (ISDN User Part) et INAP (Intelligent Network Application Part) du monde de la tlphonie en apportant la capacit multimdia. Il hrite de certaines fonctionnalits des protocoles HTTP (Hyper Text Transport Protocol) utilis pour naviguer sur le WEB, et SMTP (Simple Mail Transport Protocol) utilis pour transmettre des messages lectroniques (E-mails). SIP sappuie sur un modle transactionnel client/serveur comme HTTP. Ladressage utilise le concept dURL SIP (Uniform Resource Locator) qui ressemble une adresse E-mail. Chaque participant dans un rseau SIP est donc adressable par une URL SIP. Par ailleurs, les requtes SIP sont acquittes par des rponses identifies par un code numrique. Dailleurs, la plupart des Projet de fin d tudes - N. Ghanmi - Juin 2006 16
Chapitre I codes de rponses SIP ont t emprunts au protocole HTTP. Par exemple, lorsque le destinataire nest pas localis, un code de rponse 404 Not Found est retourn. Une requte SIP est constitue de headers comme une commande SMTP. Enfin SIP comme SMTP est un protocole textuel.
3.4.3. Les principales entits du rseau IMS

a) Terminal IMS Il sagit dune application sur un quipement de lusager qui met et reoit des requtes SIP. Il se matrialise par un logiciel install sur un PC, sur un tlphone IP ou sur une station mobile UMTS (UE, User Equipment). b) Home Subscriber Server (HSS) Lentit HSS (Home Subscriber Server) est la principale base de stockage des donnes des usagers et des services auxquels ils ont souscrit. Les principales donnes stockes sont les identits de lusager, les informations denregistrement, les paramtres daccs et les informations permettant linvocation des services de lusager. Lentit HSS interagit avec les entits du rseau travers le protocole Diameter. c) Call State Control Function (CSCF) Le contrle d'appel initi par un terminal IMS doit tre pris en charge dans le rseau nominal (rseau auquel lusager a souscrit ses services IMS) car l'usager correspondant peut souscrire un grand nombre de services et certains d'entre eux peuvent ne pas tre disponibles ou peuvent fonctionner diffremment dans un rseau visit, notamment suite des problmes dinteraction de service. Cela a induit la dfinition de trois entits CSCF : PCSCF (Proxy CSCF), I-CSCF (Interrogating CSCF) et S-CSCF (Serving-CSCF). Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS. Son adresse est dcouverte par le terminal lors de l'activation d'un contexte PDP pour lchange de messages de signalisation SIP. Le P-CSCF se comporte comme un Proxy Server SIP lorsqu'il relaye les messages SIP vers le destinataire appropri et comme un User Agent SIP lorsqu'il termine l'appel (e.g, suite une erreur dans le message SIP reu). Les fonctions ralises par l'entit P-CSCF comprennent : L'acheminement de la mthode SIP REGISTER mise par le terminal l'entit ICSCF partir du nom du domaine nominal.
17
Chapitre I L'acheminement des mthodes SIP mises par le terminal au S-CSCF dont le nom a t obtenu dans la rponse la procdure d'enregistrement. Le routage des mthodes SIP ou rponses SIP au terminal. La gnration de CDRs (Call Detailed Record). La compression / dcompression des messages SIP. L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un rseau d'oprateur pour toutes les sessions destines un utilisateur de cet oprateur. Il peut exister plusieurs I-CSCF au sein d'un rseau. Les fonctions ralises par l'entit I-CSCF comprennent : L'assignation d'un S-CSCF un utilisateur s'enregistrant. L'acheminement des mthodes SIP reues depuis un autre rseau, au S-CSCF. L'obtention de l'adresse du S-CSCF auprs du HSS. La gnration de CDRs. Le Serving-CSCF (S-CSCF) prend en charge le contrle de la session. Il maintient un tat de session afin de pouvoir invoquer des services. Dans un rseau d'oprateur, diffrents S-CSCF peuvent prsenter des fonctionnalits diffrentes. Les fonctions ralises par le S-CSCF pendant une session comprennent : L'mulation de la fonction Registrar puisqu'il accepte les mthodes SIP d'enregistrement et met jour le HSS. L'mulation de la fonction Proxy Server puisqu'il accepte les mthodes SIP et les achemine. L'mulation de la fonction User Agent puisqu'il peut terminer des mthodes SIP par exemple lorsqu'il excute des services complmentaires. L'interaction avec des serveurs d'application aprs avoir analys les critres de dclenchement des services correspondants. La gnration de CDRs Avant de pouvoir utiliser les services du domaine IMS, tels qu'tablir une session multimdia ou recevoir une demande de session, un usager doit s'enregistrer au rseau. Que l'usager soit dans son rseau nominal ou dans un rseau visit, cette procdure fait intervenir un P-CSCF. Par ailleurs, tous les messages de signalisation mis par le terminal ou
18
Chapitre I destination du terminal sont relays par le P-CSCF ; le terminal n'a jamais la connaissance des adresses des autres CSCFs (i.e., I-CSCF et S-CSCF) [4]. d) MGCF, IMS-MGW et T-SGW : Interfonctionnement avec le RTC Le domaine IMS doit interfonctionner avec le RTCP afin de permettre aux utilisateurs IMS d'tablir des appels avec le RTCP. L'architecture d'interfonctionnement prsente un plan de contrle (signalisation) et un plan d'usager (transport). Dans le plan usager, des passerelles (IMS-MGW, IMS-Media Gateway) sont requises afin de convertir des flux RTP en flux TDM. Ces passerelles ne traitent que le mdia. Des entits sont responsables de crer, maintenir et librer des connexions dans ces passerelles; il s'agit de contrleurs de passerelles (MGCF, Media Gateway Control Function). Par ailleurs, ce mme MGC termine la signalisation ISUP du ct RTC qu'il convertit en signalisation SIP qui est dlivre au domaine IMS. Les messages ISUP provenant du RTC sont d'abord achemins sur SS7 une passerelle de signalisation (T-SGW, Trunking Signaling Gateway) qui les relaye au MGC sur un transport SIGTRAN. L'interfonctionnement entre le domaine IMS et le RTCP est donc assur par trois entits : L'IMS-MGW (IP Multimedia Subsystem Media Gateway Function), MGCF (Media Gateway Control Function) et T-SGW (Trunking Signaling Gateway Function). L'IMS-MGW : o Reoit un trafic de parole du RTCP et l'achemine sur un rseau IP. Le trafic audio est transport sur RTP/UDP/IP. o Supporte gnralement des fonctions de conversion du mdia et de traitement du mdia (annulation d'cho, pont de confrence). o Est contrl par le MGCF travers le protocole MEGACO/H.248. Le MGCF o Comme les entits CSCF, n'appartient qu'au plan de contrle et non au plan mdia. o Contrle l'IMS-MGW afin d'tablir, maintenir et librer des connexions dans l'IMS-MGW. Une connexion correspond par exemple une association entre une terminaison TDM (terminaison du ct RTC) et une terminaison RTP/UDP/IP. Un transcodage de la parole doit aussi avoir lieu au niveau de l'lMS-MGW pour convertir la parole reue et qui est encode l'aide du codec G.711, en parole
19
Chapitre I encode en utilisant le codec AMR (UMTS) si le terminal IMS est un mobile UMTS. o Assure la conversion des messages ISUP (Signalisation RTC) en des messages SIP (Signalisation IMS). o Slectionne le CSCF appropri afin de remettre la signalisation SIP qu'il gnre, au sous-systme IMS. Le T-SGW o Assure la conversion du transport pour l'acheminement de la signalisation ISUP entre le commutateur tlphonique et le MGCF. La signalisation ISUP est change sur SS7 entre le commutateur et le T-SGW et sur SIGTRAN entre le TSGW et le MGCF o Par contre, n'analyse pas les messages d'application ISUP.
Conclusion
Grce lIMS, les rseaux fixes et mobiles ne se contentent plus dtre un rseau tlphonique classique. LIMS permet dtablir des communications entre multiples terminaux / utilisateurs, et il permet dintgrer des services temps-rel et non temps-rel dans une mme session. De plus, il est possible de crer de nouveaux usages en utilisant des interactions entre ces services. LIMS offre ainsi des solutions pour rsoudre les problmes des rseaux de tlcommunication traditionnels. De ce fait, une migration vers un rseau IMS est devenue une ncessit pour certains oprateurs. Par ailleurs, lIMS peut tre dploy par un oprateur mobile pour offrir des services avancs et multimdia ses usagers GPRS/EDGE/UMTS, par un oprateur daccs filaire (xDSL, cble) ou par un oprateur virtuel qui dploie lIMS en sappuyant sur les rseaux daccs doprateurs tiers. Ces oprateurs peuvent dployer leurs propres services IMS et ouvrir leur architecture des ASP qui interfacent alors leur propre serveur dapplication. Cependant, la migration vers IMS doit tre progressive et elle varie dun oprateur un autre suivant la stratgie adopte par loprateur. Dans notre tude on va surtout nous intresser au cas de Tunisie Tlcom et on va essayer dans ce qui suit dlaborer une stratgie de migration la plus adapte cet oprateur historique.
20
Chapitre II
Chapitre II
Scnarios de migration vers IMS
Introduction
Les rseaux IMS, avec leur architecture rpartie, exploitent pleinement des technologies de pointe pour offrir de nouveaux services sophistiqus et augmenter les recettes des oprateurs tout en rduisant leurs dpenses d'investissement et leurs cots d'exploitation. L'volution d'un rseau existant vers cette nouvelle structure ncessite une stratgie de migration progressive visant rduire au minimum les dpenses d'investissement pendant la phase de transition, tout en tirant parti trs tt des avantages qu'elle prsente. De plus, une migration directe vers IMS est un peu risque car IMS est un standard non pas encore mature par rapport la technologie NGN. Dautre part, une architecture NGN base sur des softswitchs peut tre facilement amliore vers IMS. Cest ainsi que le passage par une phase NGN base sur des softswitchs est fortement conseille lors de la migration vers IMS. Dans ce chapitre, on va tout dabord prsenter les diffrentes approches dune telle migration. Ensuite, on va prsenter quelques scnarios de migration vers les rseaux NGN en abordant les diffrentes tapes de migration des rseaux commutation de circuit, des rseaux commutation de paquets et des rseaux mobiles. Et on va finir par proposer un scnario de migration vers le tout IMS.
1. Approches de migration: Etat de l art

1.1. Concept de migration
La migration vers les NGN apparat comme un processus invitable du fait de la double convergence voix/donnes et fixe/mobile. Elle est dj enclenche par un certain nombre dacteurs en France, en Europe et sur dautres continents, et ses impacts doivent
21
Chapitre II donc tre analyss et anticips. Cependant elle sannonce longue (une chelle de temps de 10 20 ans semble raisonnable), incomplte (cohabitation invitable avec les architectures dites traditionnelles) et difficile court terme du fait de lexistence de solutions concurrentes ayant des niveaux de fonctionnalits et de maturit diffrents, et des problmatiques dinteroprabilit de bout en bout. La pertinence des solutions NGN est variable selon les types dacteurs : Les oprateurs et fournisseurs de services pour lesquels les solutions NGN semblent les plus pertinentes sont les futurs nouveaux acteurs (non encore tablis), les acteurs du monde des donnes souhaitant diversifier leurs activits (notamment les ISP), les oprateurs anticipant une forte croissance et/ou une diversification rapide de leurs activits (ex. : oprateurs BLR ou xDSL), les oprateurs prvoyant une forte baisse de leur trafic voix au profit du trafic donnes, et les oprateurs mobiles. Les acteurs qui semblent les plus en retrait par rapport aux solutions NGN sont ceux ayant investi fortement et rcemment dans des infrastructures de commutation voix traditionnelle TDM, et les oprateurs ayant dj un accs boucle locale bas dbit et des commutateurs daccs. A noter aussi quil nexiste pas darchitecture standard pour un NGN, ni mme darchitecture, qui, de fait, simpose tous. Dans la pratique, chaque oprateur adopte une stratgie NGN en fonction des caractristiques de son march fixe, de son positionnement dans le mobile, du niveau de concurrence et de la vtust de son rseau.
1.2. Principaux scnarios de migration vers les rseaux de nouvelles gnrations

Les gains dOPEX dpendent du scnario de migration vers les rseaux de nouvelles gnrations choisi par loprateur. En effet, les cots de transition varient selon lapproche retenue. Dans ce cadre, on peut distinguer deux approches : Les stratgies d'overlay, consistant dployer un rseau NGN en parallle du rseau commut existant, sont trs coteuses pour les oprateurs qui les dploient, mme si les gains dOPEX terme sont importants. Loprateur doit faire face une augmentation de ses cots pendant la phase de migration, o le rseau NGN est dploy et le rseau TDM existant est maintenu. Les gains dOPEX arrivent ensuite, lorsque loprateur commence grer son trafic vocal sur le rseau overlay quil a Projet de fin d tudes - N. Ghanmi - Juin 2006 22
Chapitre II construit, tout en diminuant le volume de trafic support par son rseau traditionnel, sur lequel il ninvestit presque plus. Les stratgies de remplacement, consistant remplacer progressivement les commutateurs traditionnels en fin de vie par des softswitchs NGN, prsentent un bnfice plus immdiat pour les oprateurs qui les retiendront. La plupart des oprateurs ayant concrtement envisag de dployer des solutions de type NGN ont quasiment tous retenu la deuxime approche de migration. Cest ainsi quon va sintresser dans ce qui suit des approches bases sur des stratgies de remplacement.
2. Scnarios de migration vers NGN

Tous les scnarios de migration vers NGN se basent sur la sparation des fonctionnalits de transport, de contrle, de service et de gestion. Ces scnarios dvolution suggrent une ou plusieurs tapes dpendant de limportance et du degr des sparations implmentes. Chaque oprateur de rseau, voulant migrer vers le NGN, choisira potentiellement un chemin de migration diffrent suivant ses ressources actuelles. Ainsi, suivant les catgories des oprateurs, on dfinit diffrents types de migration : Migration des rseaux commutation de circuit utiliss pour les services de tlphonie. Migration des rseaux mobiles. Migration des rseaux commutation de paquet utilis pour les services data. Dans le cas de Tunisie Tlcoms, on dispose dun rseau data, un rseau fixe et un rseau mobile. Il est donc ncessaire de prendre en considration ces diffrents types de migration.
2.1. Migration des rseaux PSTNs

2.1.1. Etat actuel du rseau PSTN
Le rseau tlphonique traditionnel utilise la commutation de circuits do son nom de Rseau Tlphonique Commut (RTC) (PSTN en anglais pour Public Switched Telephone Network). Aujourdhui, les rseaux PSTNs peuvent tre caractriss comme suit :
23
Chapitre II TDM et SS7 : Dans ce rseau, le trafic de la voix est transport sur TDM et contrl par une hirarchie de commutateurs locaux (LE ou classe 5) et de transit (TE ou classe 4). La signalisation dappel (ISUP ou INAP) est supporte par le rseau de signalisation SS7. Services du rseau intelligent : On fournit les services valeur ajoute par le biais du rseau intelligent. Ce dernier propose une gamme trs varie de services savoir le prpayer et le transfert dappel. accs Internet : Avec lexpansion du nombre des utilisateurs dInternet, les oprateurs proposent la connectivit aux fournisseurs daccs Internet ou ISP (Internet service provider) soit par le biais des services dialup bande troite
(RTC ou RNIS) soit par l'introduction de services bande large ADSL (avec voix dtache comme un service spar). On remarque quune telle architecture de rseau est similaire celle du rseau tlphonique commut de Tunisie Tlcom, ce qui va nous aider normment lors de llaboration dune stratgie de migration pour cet oprateur. Gnralement, dans les rseaux commutation de circuits, les commutateurs sont relis entre eux par des circuits et aux abonns par des lignes dabonns. Les commutateurs sont hirarchiss. Selon la terminologie de quelques oprateurs, et daprs la figure II-1 le rseau RTC est ainsi divis en plusieurs sous-ensembles : Les commutateurs de classe 3 qui dsignent les centres de transit international. Les commutateurs de classe 4 qui dsignent les centres de transit rgional et national. Les commutateurs de classe 5 qui dsignent les commutateurs locaux (LE Local Exchange).
Figure II-1 : Description d un rseau RTC Projet de fin d tudes - N. Ghanmi - Juin 2006 24
Chapitre II
2.1.2. Typologie des scnarios de migration d un rseau PSTN

La mise en place darchitectures NGN dans un rseau PSTN peut se faire avec une plus ou moins grande ampleur, selon que lutilisation des technologies NGN sapproche ou non au plus prs de lutilisateur final. Le choix de dploiement retenir conditionne en grande partie les bnfices attendre de la mise en place dun rseau NGN du point de vue de lconomie de cot. Troix grands scnarios peuvent ainsi tre dgags : Scnario 1 : Mise en place de solutions NGN en transit. Scnario 2 : Mise en place de solutions NGN jusquau classe 5. Scnario 3 : Mise en place de solutions tout IP en overlay. a) Scnario 1 : Mise en place de solutions NGN en transit Dans ce scnario, loprateur applique le concept NGN au niveau de la couche transport de son rseau, mais ds que lon sapproche des commutateurs de classe 5, le trafic continue tre support par le rseau traditionnel. Cette dmarche est mise en place par un grand nombre doprateurs mondiaux, prcisment sur ses fonctions de transit que ce soit au niveau rgional, national ou international. Il sagit de la premire tape de la migration dun rseau traditionnel vers un rseau NGN pour nombre dentre eux. Concrtement, il sagit dinstaller des passerelles media (Media Gateway) assurant linterface entre le rseau IP de transport de donnes avec le rseau tlphonique TDM traditionnel. Les passerelles sont alors administres distance par un softswitch dans le cadre dune architecture centralise en utilisant en gnral les protocoles MGCP/H.248. b) Scnario 2:Mise en place de solutions NGN jusqu au commutateur de classe 5 Loprateur choisit de mettre en place une architecture NGN qui a vocation galement agrger le trafic local. Ce scnario constitue une prolongation naturelle du premier. Dun point de vue architectural, il sagit de la mme solution que pour le scnario prcdent un niveau diffrent du rseau plus proche de labonn. En effet un commutateur de classe 5 ne diffre dun commutateur de classe 4 ou de niveau hirarchique suprieur uniquement par sa capacit de traitement de donnes. Il nintgre aucune intelligence rseau. Les commutateurs de classe 5 constituent le point de raccordement avec labonn pour la fourniture des services voix basiques. Les oprateurs historiques possdent plusieurs
25
Chapitre II milliers de ces commutateurs et de part leur position stratgique dans leur rseau ont t peu enclins jusqu prsent les remplacer par une solution NGN. Toutefois, compte tenu de la forte progression de la pntration des services haut dbit et du dclin de la demande en services de tlphonie traditionnelle, les oprateurs considrent de plus en plus lopportunit de faire converger leur infrastructure daccs vers une plate-forme IP commune. Dans le cadre dune migration de classe 5, loprateur ralise une migration complte en remplaant ses commutateurs locaux TDM par des softswitchs de classe 5. Ainsi, tout le trafic transitant dans le rseau sera support par une architecture NGN. Cette approche permet la fourniture de bout en bout de services VoIP condition que lutilisateur final utilise un quipement IP. En conclusion, une migration de classe 5 savre tre un vritable big bang au niveau du rseau de loprateur et cela est dautant plus coteux et complexe que le rseau est important. c) Scnario 3 : Mise en place de solutions tout IP en overlay Dans ce cas, loprateur dploie une architecture entirement base sur IP, qui na pas besoin de se connecter au rseau de commutation existant, ceci en parallle du rseau traditionnel, qui continue vivre sa vie indpendamment. Ce type de solution est particulirement adapt aux oprateurs historiques qui sont confronts une forte chute des revenus de tlphonie classique et qui, pour protger leur base de clientle, doivent lancer des solutions innovantes bass sur des technologies alternatives (DSL, FTTH, cble, ). Le rseau paquet en overlay fournit les services valeur ajoute tandis que le rseau TDM traditionnel continue dassurer le support des services tlphoniques de base. Les deux rseaux sinterconnectent via le dploiement de passerelles afin de garantir une terminaison dappel sur un tlphone classique alors que lappelant utilise un tlphone IP et inversement. Les rseaux VoIP et PSTN restent clairement spars, au niveau du transport du trafic et de la signalisation.
2.1.3. Scnarios de migration du c ur du rseau PSTN/ISDN vers NGN

Pour simplifier notre tude, on va donner une reprsentation simplifie du rseau PSTN/ISDN, celle de la figure II-2, o le c ur de rseau est constitu par un ensemble de
26
Chapitre II commutateurs locaux (LEs) et de transit (TEs) auxquels peuvent accder lensemble des lments suivants : UAM, PABX et AN Il ny a pas une stratgie unique pour la migration de ce rseau vers NGN. Suivant le choix de loprateur, un scnario particulier peut tre adopt. Dans ce cadre, trois scnarios de migration ont t proposs : a) Scnario 1 Ce scnario, dcrit dans la figure II-2, suppose une coexistence entre PSTN/ISDN et PSN (Paquet Switched Network) durant la priode de transition. Cette approche comprend deux tapes: Etape 1 : Certains commutateurs locaux LEs sont remplacs par des passerelles daccs AGs (Access Gateways). Quelques lments daccs comme les UAMs, les RUAMs, et les PABXs, qui sont originalement connects aux LEs supprims, deviennent directement connects aux AGs. Des AGs supplmentaires peuvent tre dploys pour supporter de nouveaux abonns. Des TGs et des SGs sont aussi dploys pour assurer linterconnexion entre le PSN et les TEs dautres rseaux PSTNs/ISDNs. Les passerelles daccs et de transit (AGs et TGs) sont tous les deux contrles par le softswitch. Etape 2: Les LEs restants sont remplacs par des AGs. les TEs sont enlevs et leurs fonctions de contrle sont assures par le softswitch. Les passerelles daccs et de transit (AGs et TGs) sont toutes les deux contrles par le softswitch.
27
Chapitre II
Figure II-2: Scnario 1 b) Scnario 2 Ce scnario consiste en deux tapes comme illustr sur la figure II-3 : Etape 1 : Le rseau PSTN/ISDN est remplac par un rseau PSN et les fonctions des TEs sont assures par les TGs et les SGs sous le contrle du softswitch Les LEs sont connects au PSN travers des passerelles de transit TGs et des passerelles de signalisation SGs. Des TGs et des SGs sont dploys pour assurer linterconnexion entre PSN et les PSTN/ISDN dautres oprateurs.
28
Chapitre II Etape 2 : les LEs et certains des lments daccs comme les UAMs et les RUAM sont enlevs et leurs fonctions sont assures par les passerelles daccs AGs et le softswitch. Les rseaux daccs (ANs) sont soient remplacs par des passerelles daccs AGs soient connects aux passerelles daccs AGs. Les passerelles de transit et de signalisation (TG et SG) sont dployes pour assurer linterconnexion entre PSN et dautres PSN/ISDN. Les passerelles daccs et de transit (AGs et TGs) sont toutes les deux contrles par le softswitch.
Figure II-3 : Scnario 2 c) Scnario 3 Dans ce scnario, le PSN/ISDN est remplac par un rseau commutation de paquet PSN en une seule tape comme le montre la figure 11-4. Les LEs sont remplacs par des AGs et leurs fonctions sont divises entre les AGs et le softswitch. Spcifiquement, les Projet de fin d tudes - N. Ghanmi - Juin 2006 29
Chapitre II fonctions de contrle dappel sont toutes transfres au softswitch. Tous les lments daccs comme les UAMs, les RUAMs et les PABXs sont connectes aux passerelles daccs AGs. Les rseaux daccs ANs sont soient remplacs par des AGs soient connects un rseau bas sur paquets travers des AGs. Les passerelles de transit TGs, sous le contrle du softswitch et des passerelles de signalisation SGs, sont dployes pour remplacer les fonctions de TE et assurer linterconnexion entre PSN et dautres PSTNs/ISDNs.
Figure II-4: Scnario 3
2.2. Migration des rseaux mobiles

2.2.1. Du GSM 2G vers GPRS 2.5G
Comme le rseau PSTN, GSM est un rseau commutation de circuit, principalement destin fournir des services de tlphonie avec lajout de fonctionnalits daccs radio et de mobilit. Comme dans le cas des rseaux PSTNs, des sessions de donnes ont t rendues possibles, mais avec des contraintes de commutation de circuit (utilisation faible de la bande passante et bas dbits).
30
Chapitre II La migration vers GPRS a men au lancement de plusieurs services GPRS qui permettent de supporter un trafic de donnes de manire plus efficace. Comme illustr dans la figure ci-dessous, l'innovation de GPRS est dintroduire un rseau commutation de paquets dans le rseau de l'oprateur mobile, permettant lactivation des sessions de
donnes bases sur la commutation de paquets [6].
Figure II-5: Migration du rseau GSM vers GPRS
2.2.2. Du GPRS 2.5G vers l UMTS

A l'heure actuelle, l'UMTS est phase en diffrentes versions ou "releases" dnommes R3 (ou R99), R4, R5 et R6. Larchitecture UMTS est constitue dune partie accs (UTRAN) qui repose sur les principes de l'ATM (Asynchronous Transfer Mode), et dune partie rseau de base appele CN (Core Network). Les trois releases de larchitecture UMTS (R3, R4, R5) considrent une mme partie accs. Par contre, la partie rseau de base (CN) est diffrente dune release lautre [5]. La Release 3 (Aussi appele Release 99) des spcifications de lUMTS labore dans le cadre du projet de partenariat de 3me gnration (3GPP, 3rd Generation Partnership Project) a dfini deux domaines pour la partie CN : Le domaine de commutation de circuits (CS, Circuit Switched), Le domaine de commutation de paquets (PS, Packet Switched). Le rseau de base UMTS R3 s'appuie sur celui du GSM/GPRS.
31
Chapitre II
Figure II-6 Migration vers UMTS release 99 L'UMTS R4 concerne l'volution du domaine CS sur la base du NGN (Next Generation Network). La R4 prsente des avantages pour le rseau de base en termes de flexibilit et d'volution. En effet, la R4 peut rutiliser le backbone IP du domaine PS pour le transport de la voix. Par ailleurs, la R4 dissocie les plans de contrle et de transport, leur permettant dvoluer sparment la diffrence des commutateurs voix qui sont des structures monolithiques. Enfin, la R4 permet l'volution vers un rseau tout IP o la voix est directement paqutise sur la station mobile de l'usager et transporte de bout en bout sur IP. Avec la R4, la voix est transporte sur IP dans le rseau de base uniquement. Le tout IP est l'objectif des releases R5 et R6.
Figure II-7 : Migration vers UMTS release 5
32
Chapitre II Les Releases 5 et 6 permettent l'tablissement de sessions multimdia, un transport de tout type de mdia de bout en bout sur IP, et une offre de nouveaux services. Ces capacits sont prises en charge par un nouveau domaine appel IMS (IP Multimedia Subsystem) qui se rajoute aux domaines CS et PS. Le domaine IMS qui se superpose au domaine PS, s'appuie sur le protocole SIP (Session Initiation Protocol) pour le contrle de sessions multimdia. SIP permet aussi l'accs aux plates-formes de services. Ce protocole est incontournable en raison de sa capacit s'intgrer aux rseaux mobiles un cot minimal.
2.2.3. Nouvelle architecture du rseau mobile dans une approche NGN

Dans la Release R4, une approche NGN (Next Generation Network) est propose pour le domaine CS. Les noeuds MSC et GMSC sont dcomposs en deux entits pouvant tre dployes de manire distribue. Le MSC est dcompos en un MSC Server et un Circuit Switched Media Gateway (CS-MGW). Le GMSC est dcompos en un GMSC Server et un CS-MGW. L'change de signalisation relatif aux appels tlphoniques a lieu entre le BSC ou RNC et le MSC Server. La parole est transporte entre le BSC ou RNC et le CS-MGW. a) MSC Server Le MSC Server prend en charge les fonctions de contrle d'appel et de contrle de la mobilit du MSC. Il est associ un VLR afin de prendre en compte les donnes des usagers mobiles. Le MSC Server termine la signalisation usager-rseau (BSSAP ou RANAP) et la convertit en signalisation rseau-rseau correspondante. Par contre, il ne rside pas sur le chemin du mdia. Par ailleurs il contrle le CS-MGW afin d'tablir, maintenir et librer des connexions dans le CS-MGW. Une connexion reprsente une association entre une terminaison en entre et une terminaison en sortie du CS-MGW. Par exemple, la terminaison en entre peut correspondre une terminaison dun circuit de parole (Interface A) alors que la terminaison en sortie peut tre assimile un port de communication RTP/UDP/IP ou AAL2/ATM. b) CS-MGW Le CS-MGW reoit un trafic de parole du BSC ou du RNC et le route sur un rseau IP ou ATM. L'interface Iu-CS (Interface entre RNC et MSC) ou l'interface A (Interface
33
Chapitre II entre BSC et MSC) se connecte dornavant sur l'entit CS-MGW afin que le trafic audio puisse tre transport sur RTP/UDP/IP ou AAL2/ATM. Le transport sera typiquement assur par RTP/UDP/IP afin de rutiliser le backbone IP du rseau GPRS et ainsi minimiser les cots. c) GMSC Server Pour les appels tlphoniques entrants provenant du RTC, une entit GMSC est ncessaire, mise en oeuvre dans la R4 par un GMSC Server et un CS-MGW. Le GMSC Server prend en charge les fonctions de contrle d'appel et de contrle de la mobilit du GMSC. Le GMSC Server termine la signalisation du RTC, i.e., ISUP. Le GMSC Server interroge le HLR afin d'obtenir un numro de MSRN et de pouvoir ainsi acheminer l'appel. Par ailleurs, le GMSC-Server contrle le CS-MGW afin d'tablir, maintenir et librer des connexions dans le CS-MGW. Une connexion correspond une association entre une terminaison TDM (terminaison du ct RTC) et une terminaison RTP/UDP/IP ou AAL2/ATM. Un transcodage de la parole doit aussi avoir lieu au niveau du CS-MGW pour convertir la parole reue et qui est encode l'aide du codec G.711 en parole encode en utilisant le codec AMR (UMTS) ou l'aide du codec GSM, avant de router le trafic audio l'autre CS-MGW qui interface les noeuds BSC et RNC. Le protocole de contrle (contrle du mdia) entre le MSC-Server ou le GMSCServer et le CS-MGW est MEGACO/H.248 (Media Gateway Control Protocol) dfini conjointement par lITU-T et lIETF. Le protocole de signalisation (contrle d'appel) entre le MSC Server et le GMSCServer peut tre n'importe quel protocole de contrle d'appel. Le 3GPP suggre l'utilisation du protocole BICC (Bearer Independent Call Control) dfini par l'ITU-T. Le protocole BICC est une extension du protocole ISUP pour permettre la commande d'appel et de services tlphoniques sur un rseau de transport IP ou ATM. L'autre protocole de signalisation possible est SIP-T (Session Initiation Protocol for Telephones) propos par l'IETF.
2.3. Migration des rseaux commutation de paquets

2.3.1. Situation actuelle
Les rseaux de donnes commutation de paquets se basent sur plusieurs technologies et un certain nombre de piles de protocole sont employs selon le service Projet de fin d tudes - N. Ghanmi - Juin 2006 34
Chapitre II fourni et la fonctionnalit offerte par chaque protocole, par exemple IP over SDH over DWDM, ou IP over ATM over SDH over DWDM, ou IP over Ethernet over SDH over DWDM. La migration vers NGN pour ces types de rseaux signifie une simplification du rseau et plus de flexibilit. tablir un rseau NGN signifie galement que le rseau doit soutenir des services convergs comme la voix ou les applications temps rel. La migration des rseaux commutation de paquets vers NGN peut suivre plusieurs stratgies qui peuvent tre combines. Une migration a pu galement impliquer une volution vers la prochaine version du protocole IP, IPv6.
2.3.2. Migration IPv6

IPv6 est la version amliore de la version courante IPv4. Il a dj t entirement spcifi par l'IETF, mais n'a pas encore t largement implment. Les conducteurs principaux vers IPv6 sont l'espace adresse fourni et les dispositifs de mobilit implments IPv6. Dans un concept IMS, le client doit disposer de la connectivit IP pour accder aux services IMS. Par ailleurs, le protocole IPv6 est requis. La raison fondamentale qui justifie l'usage d'Ipv6 est l'insuffisance d'adresse IPv4 pour permettre chaque mobile (si lon considre lapplication de lIMS aux rseaux mobiles) de disposer d'une adresse IP avec un mode "accs permanent". Des solutions comme la traduction dadresse rseau (NAT, Network Address Translation) ne peuvent tre que temporaires. De nouveaux services comme laccs permanent, le tlchargement systmatique, lauto configuration, les applications en temps rel (tlphonie), la scurit, etc. dpasseront bientt les possibilits de la technologie NAT. Avec IPv6, les champs d'adresse ont une longueur de 16 octets la diffrence des adresses Ipv4 sur 4 octets. LIPv6 fournit donc un espace dadressage largi permettant dattribuer une adresse unique chaque quipement Internet mobile (une ncessit pour les quipements toujours connects ), LIPv6 permet de configurer automatiquement ladresse IP de la machine hte [sans avoir recours au protocole de configuration dynamique de la machine hte (DHCP Dynamic Host Configuration Protocol)], ce qui est intressant pour les quipements mobiles,
35
Chapitre II LIPv6 gre la scurit de bout en bout. Le rseau mobile peut tre considr comme un rseau ferm dont linter fonctionnement avec le rseau antcdent IPv4 peut tre assur la priphrie du rseau (avec des routeurs passerelles excutant des empilages IP doubles avec des tunnels IPv6-IPv4, etc.).
2.3.3. Exigence d un mcanisme de garantie de qualit de service

Sur Internet, le type de QoS fourni est best effort. Cela ne sera pas le cas avec lIMS. Les rseaux daccs et de transport de lIMS fournissent la QoS de bout-en-bout. A travers lIMS, le terminal ngocie ses capacits et exprime ses exigences de QoS durant la phase dtablissement de la session avec le protocole SIP. En parallle le terminal rserve les ressources ncessaires dans le rseau daccs en utilisant un protocole de rservation de ressources (RSVP, SM/GTP, etc).
3. Scnarios de migration vers IMS

Etant donn un rseau NGN, sa migration vers IMS est base sur un ensemble dtapes qui ont pour objectifs: Convergence complte des services fixe et mobile, Convergence des bases de donnes fixe et mobile vers une seule base de donnes HSS, Introduction des fonctionnalits de lIMS et amlioration du Softswitch comme un module du concept IMS.
3.1. Etape 1 : Convergence des services fixe et mobile

On a vu dans les paragraphes prcdents quelques scnarios pour la migration des rseaux PSTNs/ISDNs, et dautres pour la migration des rseaux mobiles. On na pas parl de la couche service. Mais, il est ncessaire de noter quune convergence des services fixe et mobile est essentielle pour la migration vers un rseau tout IMS. La figure II-8 illustre cette convergence.
36
Chapitre II
Figure II-8 : Convergence des services fixe et mobile Ainsi, dans une premire tape, le rseau de service mobile et le rseau de service fixe convergent vers un seul rseau de service.
3.2. Etape 2 : Convergence des bases de donnes des rseaux fixe et mobile
Les donnes des utilisateurs du rseau mobile sont enregistres dans la base de donnes nominale HLR. Pour les abonns du rseau PSTN, on va introduire une nouvelle base de donnes (SHLR) qui enregistre leurs donnes. Ce SHLR va tre li au softswitch via linterface MAP (DIAMETER).
Figure II-9 : Mise en uvre d un SHLR dans le rseau PSTN
37
Chapitre II Ensuite, on va combiner cette nouvelle base de donnes avec le HLR du rseau mobile de faon intgrer les donnes utilisateur fixe et mobile dans un seul HLR en assurant linterfonctionnement entre le rseau fixe et le rseau mobile.
Figure II-10 : Interfonctionnement entre rseau fixe et rseau mobile
3.3. Etape 3 : Migration vers le tout IMS

La migration vers un rseau tout IMS ncessite lintroduction des fonctionnalits de lIMS et lamlioration du Softswitch comme un module du concept IMS. Pour atteindre cet objectif, deux scnarios peuvent avoir lieu : le premier consiste introduire lIMS dans le rseau fixe dans une premire tape, et le propager vers le rseau mobile par la suite. Quant au deuxime scnario, il consiste dabord introduire les fonctionnalits de lIMS dans le rseau mobile puis les propager vers le rseau fixe.
3.3.1. Scnario 1 : partir du rseau mobile

Ce scnario renferme un ensemble dtapes : Introduction de l'IMS du ct du rseau mobile par lajout des fonctionnalits SCSCF, I-CSCF, P-CSCF et MGCF. Migration du HLR d'utilisateur). vers HSS (Le HSS peut contenir les donnes fixes
38
Chapitre II
Figure II-11 : introduction de l IMS dans le rseau mobile Propagation de lIMS vers le rseau fixe par lvolution du software du softswitch et lapparition des entits CSCF de lIMS.
Figure II-12 : migration vers un rseau tout IMS
3.3.2. Scnario 2 : partir du rseau fixe

Dans ce deuxime scnario, on va suivre les mmes tapes que le premier scnario sauf quon va commencer par introduire lIMS dans le rseau fixe, puis le propager vers le rseau mobile en suivant les tapes suivantes : Introduction de l'IMS du ct du rseau fixe par lamlioration du software du softswitch. Evolution du HLR vers HSS.
39
Chapitre II Interfonctionnement des deux rseaux fixe et mobile.
Figure II-13 : Amlioration du software du softswitch et migration du rseau fixe vers IMS Une fois le IMS est dploy dans le rseau fixe, on va le propager vers le rseau mobile pour obtenir une architecture tout IMS.
Figure II-14 : Propagation de l IMS vers le rseau mobile
Conclusion
La nouvelle architecture IMS ne remplace pas les rseaux existants, mais permet dtendre progressivement leurs capacits pour gnrer de nouveaux revenus grce la convergence voix/donnes et fixe/mobile. Un scnario de migration vers lIMS pour un
40
Chapitre II oprateur tabli vise aider ce dernier capitaliser sur son existant, tendre ses capacits de commutation et amplifier sa vitesse de transmission. Les oprateurs qui entrent dans le nouveau monde des tlcoms ont des origines, des inquitudes et des besoins diffrents. Vu cette diversification, des feuilles de route (Road Map) doivent tre proposes ces acteurs pour raliser la meilleure migration vers les rseaux de nouvelle gnration. Tunisie Tlcom est lun de ces oprateurs qui cherchent migrer vers ces rseaux de nouvelles gnrations. La question est alors de trouver une stratgie qui permet cet oprateur de migrer vers IMS de faon la plus optimale possible.
41
Chapitre III
Chapitre III
Dimensionnement et stratgie de migration vers IMS - Etude de cas : Tunisie Tlcom
Introduction
Depuis sa cration, TUNISIE TELECOM s'est orient vers l'exploitation de son savoir faire pour le suivi des volutions technologiques et ce, par le dveloppement des services de tlcommunication vers les nouvelles architectures avec diffrentes technologies opportunes pour elle en tant quoprateur historique. Dans ce chapitre, nous allons dcrire le rseau existant de Tunisie Tlcom, puis nous allons proposer une stratgie de migration de celui-ci vers un concept IMS. Une fois, nous avons fix une stratgie, nous allons passer au
dimensionnement de quelques entits du nouveau rseau en valuant le trafic au niveau du rseau daccs.
1. Dveloppement d une stratgie de migration vers IMS : Etude de cas de Tunisie Tlcom
Avant de proposer une stratgie de migration vers IMS du rseau de Tunisie Tlcom, il est ncessaire de bien tudier le rseau existant de cet oprateur historique.
1.1. Topologie du rseau existant

Tunisie Tlcom dispose actuellement dun rseau de tlcommunication form de :
42
Chapitre III Un rseau de transmission de donnes mode connect (ATM, FR ; etc) dont on ne va pas trop sintresser du fait quon a choisi de mettre en uvre une solution base sur IP. Deux plates formes de la nouvelle gnration pour le service voix. On ne va tenir compte de ces plates formes quau niveau de leur interconnexion avec la nouvelle architecture de rseaux quon va dployer. Un rseau IP. Un rseau tlphonique classique. Un rseau mobile GSM. Dans ce qui suit, on va sintresser seulement de ces trois derniers points qui nous servira lors de la migration vers les rseaux NGN puis IMS.
1.1.1. Le Rseau IP
Le rseau IP de Tunisie Tlcom est essentiellement un rseau IP/MPLS. En effet, limplmentation de MPLS dans un rseau de tlcommunication dun oprateur prsente des intrts majeurs, savoir la mise en place dune certaine qualit de service (QoS) moyennant une puissance de commutation et une flexibilit de routage. Le rseau IP de Tunisie Tlcom se compose essentiellement dun ensemble de routeurs Edge et priphriques et de 6 Giga Routeurs formant le niveau Core du rseau dont larchitecture se prsente dans la figure III-11.
Figure III-1 : Backbone IP/MPLS de Tunisie Tlcom
1.1.2. Le rseau tlphonique classique

Essentiellement TDM, le rseau tlphonique de Tunisie Tlcom est hirarchis en quatre niveaux: Le niveau 4 correspond aux centres locaux (centres avec autonomie
dacheminement).
43
Chapitre III Le niveau 3 correspond aux centres nodaux (centres combins). Ils sont placs la tte de chaque zone urbaine. Le niveau 2 correspond aux centres de transit rgional et national. Ils sont placs la tte dune ou de plusieurs zones urbaines. Le niveau 1 correspond aux centres de transit international. Vu que lobjectif de notre projet vise, dans une premire tape de migration, introduire le concept NGN C4 (Classe 4) dans notre rseau de tlcommunication, on va sintresser, uniquement, aux centres de transit national CTNs. En effet, Tunisie Tlcom dispose de 16 CTNs qui se trouvent Hached III, Ouerdia, Ben Arous, Bardo, Menzeh, Bizerte, Nabeul, Sousse, Moknine, Sfax-nord, Sfax-centre, Gabs, Mdenine, Gafsa, Kairouan et Bja. Ces CTNs sont interconnects avec une architecture maille:
Bardo Ben Arous Ouerdia Hached Menzeh
Nabeul Sfax-nord
Sfax-centre
Bizerte
Gab s Sousse Medenine Moknine Kairouan Gafsa
Bja
Figure III-2 : CTNs du rseau fixe de Tunisie Tlcom
1.1.3. Le rseau mobile GSM

Comme on a mentionn plus haut, tant donn que lobjectif de notre projet est dintroduire le concept NGN C4 dans notre rseau de tlcommunication, dans toute la suite de ce paragraphe on va sintresser seulement au niveau du rseau de commutation du rseau GSM. En effet, la couche commutation du rseau mobile GSM de Tunisie Tlcom est constitue de 25 MSCs situs Hached 1, Hached 2, Ouerdia, Kasbah, Ben Arous, Marsa, Menzah, Bardo, Bizerte, Bja 1, Bja 2, Nabeul 1, Nabeul 2,
44
Chapitre III Sousse1, Sousse 2, Moknine 1, Moknine 2, Kairouan, Sfax 1, Sfax 2, Gabs, Gafsa, Sidi Bouzid, Mdenine1 et Mdenine2. Chaque MSC est raccord un ou plusieurs MSCs et un ou plusieurs centres de transit du rseau RTCP.
Figure III-3 : Le rseau mobile de Tunisie Tlcom et son interconnexion avec le rseau fixe Ce schma illustre une partie du rseau existant de Tunisie Tlcom, on remarque bel et bien une certaine complexit de la topologie qui augmente exponentiellement si on tient compte de tout le rseau de Tunisie tlcom. La migration vers IMS va nous permettre donc de rduire cette complexit. Ainsi, disposant chacun dune infrastructure indpendante, la coexistence du rseau fixe, du rseau mobile et du rseau de transmission de donnes devient de plus en plus complexe surtout avec le dveloppement des usages autour des donnes, le besoin de crer de nouveaux services et applications et la ncessit de rduire les cots (CAPEX/OPEX).
45
Chapitre III Dans ce cadre, une migration vers IMS permettra de rsoudre lensemble de ces problmes en assurant une convergence fixe/mobile et voix/data.
1.2. Rgles principales pour une migration optimale

Certes, la stratgie adopte par un oprateur dans lvolution de son rseau vers des architectures de la nouvelle gnration dpend troitement de plusieurs lments, essentiellement, larchitecture du rseau existant et les services offrir. Dans ce cadre, on a tabli un ensemble de rgles qui tiennent compte de ces lments et quon va essayer de suivre dans notre stratgie de migration vers IMS: (1) On doit tenir compte des rseaux existants. Essentiellement, il est ncessaire dexploiter le backbone IP /MPLS existant qui reprsente la couche connectivit du rseau de la nouvelle gnration. (2) On doit dployer une architecture base sur des softswitchs qui facilitera le passage une architecture toute IMS. Pour des raisons de scurit, on va dployer au minimum deux softswitchs. (3) Il est ncessaire de ne plus investir dans la commutation TDM de niveau 2 (CTN). En effet, une fois on a commenc la migration vers IMS, toute extension du rseau classique doit faire partie du rseau IMS. (4) Pour les nouvelles crations de classe 5, au lieu de dployer des commutateurs locaux, on fera recours des MSANs qui peuvent supporter tous les types de services proposs par les commutateurs traditionnels locaux et servir tous les types de terminaux. Par exemple, les nouveaux abonns DSL devraient tre raccords cette nouvelle plate-forme pour les services vocaux et donnes. (5) Dans une approche NGN, les MSANs et les DSLAMs sont connects au rseau IP directement ou via une MGW. (6) La Migration doit tre progressive : a. Phase 1 : Coexistence des rseaux existants avec le rseau NGN. b. Phase 2 : Intgration des rseaux vers un seul rseau NGN offrant la multitude des services (voix, donnes, vido, etc.). c. Phase 3 : Migration vers IMS.
46
Chapitre III (7) La stratgie quon doit dployer doit tre optimale. En effet, on doit acheminer le maximum de trafic en utilisant un nombre minimum de mdia gateways. Pour cela on va fixer un seuil de 25 ans qui reprsente lge maximal dun commutateur. a. Remplacer les commutateurs trs gs (leur ge est suprieur 25 ans) b. Pour un commutateur assez rcent (son ge est infrieur 25 ans): i. Sil supporte une extension, on le fait voluer vers un MGW ii. Sinon, on le garde et on le rattache un MGW
1.3. Migration du rseau de Tunisie Tlcom vers IMS

La migration du rseau de Tunisie Tlcom doit tre progressive : migration vers NGN dans une premire tape, puis vers IMS.
1.3.1. Migration vers NGN

Loprateur historique Tunisien, voulant introduire le NGN, cherche la rentabilit de ce projet. Par ailleurs, une architecture qui offre plus de flexibilit et defficacit (qui assure la migration vers tout IP) est la cible de cet oprateur. Nous avons choisit une solution futuriste qui se base, dune part, sur la sparation entre les couches transport et contrle conformment au concept NGN et dautre part, sur la convergence des rseaux fixe et mobile premirement sur la couche transport et puis sur la couche contrle. a) Extension du rseau IP/MPLS
Figure III-4 : Backbone IP/MPLS de Tunisie Tlcom dans un concept NGN
47
Chapitre III Puisque Tunisie Tlcom dispose dj dun rseau IP/MPLS national couvrant tout le pays, il sera plus facile dorienter le nouveau rseau NGN vers ce backbone (rgle (1)). Ainsi, on va exploiter le rseau existant et on va gagner au niveau du cot dinvestissement dans ce domaine. Cependant, le rseau IP/MPLS existant ne peut pas supporter tout le trafic du rseau daccs. Une extension du backbone IP est donc ncessaire. Elle consiste ajouter la fois des routeurs Core et des routeurs Edge. Les ingnieurs de Tunisie Tlcom ont dj commenc la conception du nouveau rseau IP/MPLS illustr par la figure III-4. Le nouvel nuage MPLS est compos de dix-huit routeurs MPLS ou LSRs : neuf se trouvent dans le grand Tunis et plus prcisment Hached, Menzeh, Marsa, Belvdre, Ouardia, Badro, Ben Arous, Ariana et El Kasbah. Les neufs autres sont Nabeul, Bizerte, Bja, Moknine, Kairouan, Gafsa, Gabs, Sousse et Sfax. Dans ce qui suit, on va sintresser la migration du rseau existant de Tunisie Tlcom au niveau transit et au niveau accs. Ces deux types de migration peuvent se faire simultanment ou successivement selon le cas. b) Migration niveau transit et convergence des rseaux fixe et mobile sur le plan usager
Bardo Hached 1 Hached Ouerdia Ouerdia Bardo Menzeh Hached 2 Menzah
Ben arous Ben Arous Bardo Ouerdia Hached Menzah Kasba Blvdere
Hache Ouardi Souss
Beleved Kasba Sfax
Ariana
Ben arous Nabeul2 Nabeul Nabeul Bizerte Bja Nabeul1 Bizerte
Kasbah
Marsa
Marsa
Beja
Sousse
Kairouan
Moknine Kairouan
Gabes
Gabs Gafsa
Sfax
Sfax-nord Sfax1 Sfaxcentre
Bizerte Bja1 Bja Medenine Gafsa Moknine Moknine1 Kairouan mednine2 mednine1 Gafsa Sidi Bouzid Gab s Sousse Sousse2 Sousse1
Sfax2
Bja2
Gabs
Moknine2
Kairouan
Figure III-5 : Interconnexion des MGWs au rseau IP/MPLS
48
Chapitre III Dans notre stratgie de migration du rseau de Tunisie Tlcom, on a choisi de mettre en place une solution NGN de classe 4. Ce choix est d la facilit de son dploiement surtout lors dune premire phase de migration. Il consiste utiliser des technologies NGN pour le coeur de rseau, mais ds que lon sapproche des commutateurs de classe 5, le trafic continue tre support par le rseau traditionnel. Il sagit dinstaller des passerelles media (Media Gateway) assurant linterface entre le rseau IP de transport des donnes avec le rseau tlphonique TDM traditionnel (GSM et PSTN) et le rseau data (ADSL), comme cest illustr dans la figure III-5. Ainsi, le backbone IP/MPLS va assurer une convergence des rseaux fixe et mobile au niveau transport pour les services voix fixe, voix mobile et data. Les MGWs permettent laccs ce backbone en convertissant les flux TDM en IP et inversement. De ce fait, chaque routeur Edge on va associer un ou plusieurs MGWs. On distingue plusieurs scnarios pour lemplacement des MGWs et leur interconnexion avec les commutateurs de classe 4 du rseau classique : Scnario 1 :
Hached1 Bardo Hached2
Menzah
Ouerdia Ouerdia
Bardo
Hached Hached
Menzeh Menzah
Bardo Ben arous Ben Arous Ben arous Ouerdia
Hached Ouardia Sousse
Belevedr Kasbah Sfax
Ariana
Bevdaire Blvdere Kasba Kasbah
Nabeul
Nabeul Bizerte
Marsa Bja
Marsa
Nabeul1
Beja
Sousse
Kairouan
Moknine Kairouan
Gabes
Gabs Gafsa
Sfax Sfax-nord Sfax-centre Sfax1
Bizerte
Bizerte Bja1 Bja2 Bja Sousse Moknine Sousse2 Sousse1 Kairouan Gafsa mednine2 mednine1 Moknine1 Kairouan Moknine2 Gafsa Sidi Bouzid Medenine Gab s Gabs
Sfax2
Figure III-6 : Premier scnario de migration du rseau de Tunisie Tlcom vers NGN Dans ce scnario, on va prendre en compte deux aspects :
49
Chapitre III Lors de la migration du rseau mobile vers NGN, le MSC sclate en deux entits : un MSC Server et un MGW. Lors dune migration de classe 4 du rseau fixe, chaque CTN va tre remplac par un MGW et ses fonctionnalits de contrle vont tre assures par le softswitch. Etant donn un rseau mobile contenant 25 MSCs et un rseau fixe contenant 16 CTNs, leur migration vers NGN va ncessiter 41 MGWscomme cest illustr dans la figure III-6. Le nombre des MGWs peut se rduire en tenant compte de la rgle (7) o un MGW peut tre soit ajout un ancien commutateur, soit une simple volution de celui ci. Dans tous les cas, cette solution savre coteuse et nest pas optimale car un MGW peut supporter plus quun MSC ou un CTN. Scnario 2 : Dans ce scnario, on va utiliser 16 MGWs, chacun est li un routeur Edge, comme cest illustrdans la figure III-7. De plus, chacun des MSCs et des CTNs va tre connect au MGW le plus proche en tenant compte de la topologie du rseau de transmission.
Hached2 Menzah Hached Menzeh
Hached1 Bardo Bardo
Ouerdia Ouerdia
Bevdaire Ben arous Hached Bardo Ouerdia Ben Arous Ben arous Menzah Kasba
Hached Ouardia Sousse
Belevedr
Ariana Blvdere
Kasbah Sfax
Kasbah
Nabeul
Nabeul Bizerte
Marsa
Marsa
Nabeul2
Bja
Beja
Sousse
Kairouan
Moknine Kairouan
Gabes
Gabs Gafsa
Sfax
Nabeul1 Bizerte
Sfax-nord Sfax1 Sfax-centre
Bizerte Bja1 Bja Sousse Sousse2 Sousse1 Moknine1 Moknine2 Gafsa Sidi Bouzid Medenine Kairouan Gafsa mednine2 mednine1 Gabs Gabs Moknine
Sfax2
Bja2
Kairouan
Figure III-7 : Deuxime scnario de migration du rseau de Tunisie Tlcom vers NGN
50
Chapitre III Cette solution peut tre encore amliore en faisant voluer quelques CTNs en des MGWs (rgle (7)). Dans ce cas, on obtient le schma de la figure III-8. Dans une premire analyse, cette solution parait beaucoup plus importante de point de vue topologie. En effet, elle permet de rduire lencombrement du rseau (moins dquipements). Cependant, le cot dune volution est assez important et comparable au cot dun nouveau MGW. Cest pour cela quon a choisi dans notre stratgie dinvestir dans des nouveaux MGWs.
Hached1 Bardo Hached2 Menzah
Ouerdia Bevdaire Ben arous Bardo Hached Ouerdia Ouerdia Ben Arous Ben arous Nabeul2 Nabeul Nabeul Bizerte Bja Nabeul1 Bizerte Bardo Menzah Hached Menzeh Kasba
Hached Ouardi Sousse
Belevedr
Ariana Blvdere
Kasbah Sfax
Kasbah
Marsa
Marsa
Beja
Sousse
Kairouan
Moknine Kairouan
Gabes
Gabs Gafsa
Sfax
Sfax-nord Sfax-centre Sfax1
Bja Bizerte Bja1 Bja2 Sousse2 Sousse1 Moknine1 Moknine2 Kairouan Gafsa Sidi Bouzid mednine2 mednine1 Sousse Moknine Kairouan Gafsa Gabs Medenine Gab s Sfax2
Figure III-8 : Optimisation de la migration du rseau de Tunisie Tlcom vers NGN Dans le cadre dune architecture centralise, ces passerelles vont tre administres distance par un softswitch en utilisant en gnral les protocoles MGCP/H.248 (rgle (2)). c) Migration niveau accs et convergence des rseaux fixe et mobile sur les plans usager et contrle Lors de la migration du rseau de Tunisie Tlcom vers NGN, notre objectif est de garantir la continuit des services TDM actuels de cet oprateur historique, et encourager les services haut dbit tout en tirant parti des solutions de softswitch IP. Dans notre stratgie, on va utiliser des MSANs (Multiservice Access Node) qui savent grer aussi bien des lignes haut dbit que des accs RNIS ou analogiques. Ces quipements se connectent au rseau IP de l'oprateur et offrent le service tlphonique sous
51
Chapitre III le contrle du softswitch de classe 5. De plus, les nouveaux abonns DSL devraient tre raccords cette nouvelle plate-forme pour les services vocaux et donnes. Cest ainsi que ces quipements assurent la convergence des services voix fixe et data aussi bien sur le plan transport que le plan contrle. d) Introduction des services hauts dbits dans le rseau mobile Actuellement, Tunisie Tlcom dispose dun rseau mobile GSM qui noffre que le service de la voix classique. Loffre des services mobiles haut dbit ncessite la migration du rseau GSM vers GPRS ou EDGE ou bien lintroduction de lUMTS. Dans notre stratgie, on a combin ces deux approches. Dabord, pour rduire le cot dinstallation du rseau, on va introduire le rseau UMTS dans les zones fort trafic (hot spot et les grandes villes). A ce stade, on va sintresser aux releases 4 et 5 de lUMTS qui permettent doffrir un rseau tout IP. Il suffit dinstaller un rseau daccs (UTRAN) qui sinterconnecte au rseau IP via un ou plusieurs MGWs sans avoir besoin dinstaller des SGSNs et des GGSNs. Ensuite, pour les zones non couvertes par lUMTS, on va bnficier du rseau GSM pour dployer lEDGE afin doffrir des services multimdia des dbits acceptables. Pour ce faire, une mise jour du sous-systme radio du rseau GSM est ncessaire. e) Interconnexion avec les plateformes NGNs existantes Une fois le rseau de Tunisie Tlcom est migr vers NGN, on doit lui permettre dinterfonctionner avec lensemble des plateformes NGNs dj existantes. Dans ce cadre il suffit dinterconnecter les softswitchs des diffrents rseaux NGN moyennant les protocoles BICC, SIP-T et H323.
1.3.2. Migration vers IMS

Dans le chapitre prcdent, on a discut deux scnarios de migration dun rseau NGN vers un concept IMS : Scnario 1 : on commence introduire IMS dans le rseau mobile, puis on le propage vers le rseau fixe. Scnario 2 : on commence introduire IMS dans le rseau fixe, puis on le propage vers le rseau mobile. Dans le cas de Tunisie Tlcom, les deux scnarios sont techniquement applicables. Cependant, de point de vu marketing, le premier scnario est plus adquat que le deuxime. Projet de fin d tudes - N. Ghanmi - Juin 2006 52
Chapitre III En effet, Tunisie Tlcom, le seul oprateur de la tlphonie fixe en Tunisie, est soumis une forte concurrence au niveau du rseau et des services mobiles. Cest ainsi que Tunisie Tlcom cherche souvent innover dans le secteur mobile pour sopposer la concurrence en offrant une gamme complte de services de voix et de donnes aux clients rsidentiels et professionnels. Alors que toute innovation dans le rseau fixe ne peut tre que supplmentaire. Dans notre stratgie, on a mis en uvre une solution base sur des softswitchs pour
lensemble des rseaux fixe et mobile. En effet, les fonctionnalits du MSC Server supportant le contrle du rseau mobile va tre incluse dans le softswitch. De ce fait, un softswitch assure la fois le contrle du rseau fixe et celui du rseau mobile. La migration vers IMS va tre donc simultane aussi bien pour le rseau fixe que le rseau mobile. Le rseau c ur de Tunisie Tlcom, dans une approche NGN base sur des softsitchs, est prsent dans la figure III-9. Il repose sur 16 MGWs au niveau transport, chacune est lie au rseau IP via un routeur EDGE. Au niveau contrle, on a mis en uvre deux softswitchs. Ces derniers assure le contrle des MGWs, le contrle des commutateurs de classe 4 du rseaux traditionnel ainsi que le contrle des nouveaux MSANs quon a dploy dans le rseau.
Figure III-9 : Le rseau c ur de Tunisie Tlcom dans une approche NGN
53
Chapitre III La migration de ce rseau vers IMS intresse surtout la couche contrle. Ceci se manifeste par lvolution du software du softswitch pour supporter les modules de lIMS, et par lintroduction de nouveaux lments pour supporter les nouveaux services et fonctionnalits de ce concept. Dans ce cadre, on introduit une base de donnes HSS qui enregistre les informations sur les abonns et qui interagit avec les entits du rseau travers le protocole Diameter. On introduit aussi le CSCF qui permet de grer les services broadband du rseau et le MGCF qui permet linterconnexion du rseau RTC avec le rseau IMS. Sur le plan service, on peut intgrer de nouveaux serveurs dapplication SIP qui permettent de fournir de nouveaux services multimdia valeur ajoute. Le principe de cette migration est illustr par la figure III-10.
Figure III-10 : Evolution du softswitch vers IMS Par la migration vers un concept IMS, on a termin notre stratgie de migration. On doit donc passer ltape suivante qui consiste : Dterminer le trafic niveau accs Dimensionner les diffrentes entits du rseau
Dans ce qui suit, on va essayer de dtailler chacun de ces points.
2. Evaluation du trafic niveau accs

Pour tudier et valuer le trafic du rseau daccs, il faut tout dabord dfinir un ensemble de classes de services, ensuite les modliser.
54
Chapitre III
2.1. Les classes de service

La croissance exponentielle des services mobiles a t alimente par plusieurs facteurs, en particulier les grandes volutions technologiques dans le domaine des tlcommunications : de ce fait, on touche de nos jours une diversit au niveau des services mobiles. Selon les spcifications 3GPP, on distingue quatre classes de services en se basant sur la qualit offerte : La classe de trafic conversationnel (Conversational class), La classe de trafic flux continu (Streaming class), La classe de trafic interactif (Interactive class), La classe de trafic en mode tlchargement (Background Class).
Le tableau III-1 rsume les caractristiques de ces diffrentes classes de services :
Classe de trafic
Classe conversationnelle - Conversation en temps rel - Prserve le
Classe streaming - Diffusion en temps rel - Prserve le squencement entre les entits dinformation dans le flot
Classe interactive - Mode interactif au mieux - Motif de
Classe background - Pas de contraintes sur le temps darrive
Caractristiques essentielles
squencement entre les entits dinformation dans le flot - Dlai non perceptible - Voix
requte/rponse - Prserve le - Prserve le contenu contenu
- Vido en diffusion continue en temps rel
- Navigation sur le web
- Chargement de message lectronique
Applications
- Visiophonie
Tableau III-1 : Les diffrentes classes de service Le critre de classification le plus prpondrant est la sensibilit au dlai de transmission. Les deux premires classes sont prvues pour les services du type temps rel alors que les deux autres classes concernent les applications non temps rel, ces dernires se
55
Chapitre III caractrisent par une tolrance aux dlais de transmission. Lautre contrainte respecter essentiellement pour les deux dernires classes de service est le seuil du BER (Bit Error Rate).
2.1.1. Services de type conversationnel

Cest lensemble des applications permettant la conversation directe entre plusieurs utilisateurs (voix, vidoconfrences,). Cette classe de services est caractrise par : Faible dlai de transmission, Taux de distorsion du signal limit, Conversion des relations temporelles du flux multimdia.
Pour ce type de service, la qualit de service est spcifie par rfrence la perception de lutilisateur qui permet de dgager des seuils dapprciation du service tels que la distorsion maximale tolre du signal audio/vido reu et le retard maximal la rception.
2.1.2. Services flux continu

Cest lensemble des applications temps-rel caractrises par un flux de donnes quasiment continu dans le temps, de grandes contraintes de QoS relatives la sensibilit aux erreurs et synchronisation entre les entits. Les applications relatives cette classe de service sont en gnral du type multimdia en mode diffusion. Parmi les exemples typiques de telles applications figurent les squences vido : clips, extraits de film, et audio : extraits de morceaux musicaux
2.1.3. Services Interactifs

Il sagit de lensemble des applications interactives classes non temps rel, cest dire qui ne prsentent pas des contraintes temporelles svres ou qui sont insensibles aux dlais de transmissions et aux contraintes de synchronisation. Dans cette classe de services, on trouve toutes les applications faisant intervenir la transmission de donnes en mode interactif telles que les consultations de bases de donnes distantes, navigation sur Internet Pour ce genre dapplications, la contrainte prpondrante est la reconstitution sans erreurs du message global partir du flux de donnes transmises. Pour un taux derreurs binaire dtermin lavance, il est impratif de mettre en oeuvre toutes les procdures de protection contre les erreurs, en particulier les procdures de retransmission.
56
Chapitre III
2.1.4. Services en mode tlchargement ou background

Cette classe de services inclut lensemble des applications non temps rel et qui ne sont pas interactives. Cela signifie que la transmission a lieu dans un seul sens de transmission et donc elle se caractrise par un flux trs asymtrique (Mode tlchargement). Au niveau de la qualit de service, la seule contrainte respecter est de pouvoir reconstituer la rception, le message transmis sans erreurs (en respectant un BLER seuil). Et linverse des applications interactives, aucune contrainte temporelle nest impose. Dans cette classe on trouve des applications comme le courrier lectronique, le transfert de fichiers, transfert de mesures etc
2.2. Modlisation du trafic

Lvaluation du volume de trafic total dans le rseau coeur ncessite une tude pralable des modles de trafic de chacune de ces classes de services. Dans ce paragraphe, nous allons donner un bref aperu sur les lois qui rgissent ces classes de services pour pouvoir retenir un scnario pour chaque classe et calculer par la suite la charge de trafic dans le rseau c ur. La modlisation classique des services par des processus de poisson nest pas valide ds quil sagit de la transmission des donnes. Cette modlisation a t longtemps adopte pour le calcul de la charge des rseaux tlphoniques, et qui reste toujours valable pour les communications de type voix. Pour les autres classes de services, dautres modlisations sont dfinies spcifiques aux caractristiques de lapplication. Par consquent, lvaluation de la charge du rseau ncessite la connaissance des diffrentes statistiques dcrivant lactivit de chaque type dapplication pour ne pas scarter de la ralit.
2.2.1. Modle de trafic pour le service conversationnel

Un exemple typique dun service conversationnel est la communication tlphonique. Les communications tlphoniques constituent le service le plus classique dont le comportement statistique a t matris. Le comportement dun utilisateur exploitant ce service au cours du temps est modlis par un processus markovien du type ON-OFF. Les caractristiques de ce modle sont [14] : Loccurrence des appels tlphoniques est un processus de poisson caractris par un taux moyen dappel de valeur typique 0.8 appels par heure.
57
Chapitre III La dure dun appel suit un processus exponentiel de moyenne typique telle que 1/ =150 s [14]. La dure de lappel est une alternance de priodes dactivit et de priodes de silence. Ces priodes suivent chacune une distribution exponentielle. La valeur typique pour le taux dactivit des sources est 0.5.
2.2.2. Modle de trafic pour le service flux continu

Un exemple typique dun service flux continu est le tlchargement dune squence vido. Le flux des squences vido correspond une srie de trames de donnes de mme dure raison de 25 trames par secondes. Il existe neuf types diffrents de trames. Loccurrence de ces diffrents types de trames est gre par un processus de Markov neuf tats. La distribution de la dure de chaque classe de contenu suit une loi Gamma dordre 2. Nous avons retenu pour ce modle les caractristiques suivantes [14] : Loccurrence des sessions 0.17 appels/ heure. La dure dune session 120 s. Le taux dactivit de la source est de 0.58.
2.2.3. Modle de trafic pour le service interactif

Lexemple typique de ce service est la consultation des pages Web. Le flux de donnes, selon ce modle, peut tre dcompos en plusieurs sessions de consultation du Web. Pendant chaque session, lutilisateur consulte un ensemble de sites Web se ramenant un appel des pages HTML correspondantes. Le tlchargement de ces pages HTML est matrialis par la transmission de plusieurs datagrammes de tailles variables. Un temps de lecture est ncessaire avant damorcer la consultation dune autre page Web. Les caractristiques statistiques de ce modle sont les suivantes [14] : Loccurrence de sessions est un processus de poisson de valeur typique 0.17 appels/heure. Pour chacune des sessions : o Le nombre dappels de pages HTML suit une distribution gomtrique de moyenne typique 5 appels/session. o Le temps de lecture suit une distribution exponentielle de moyenne et de valeur typique 1/ = 4 12 s.
58
Chapitre III o Le nombre de datagrammes par appel suit une distribution gomtrique de moyenne typique 10 datagrammes/appel. o La dure dinter-arrive de datagrammes suit une distribution exponentielle dont la moyenne est en fonction du dbit. o La taille des datagrammes suit une distribution de Pareto.
2.2.4. Modle de trafic pour les services d arrire plan

Les services darrire plan sont caractriss par un taux derreurs binaires svre, dautre part, ils sont insensibles au dlai de transmission. Les modles prcdents ne peuvent pas tre appliqus sur ce genre dapplications. Lors de lvaluation du volume de trafic au niveau de rseau coeur, leur contribution en terme de trafic peut tre ignore car ils sont des services BE (Best Effort). Le rseau coeur transmettra ces charges de trafic lors des priodes dinactivits enregistres dans les autres services. Dune autre manire, ses services ne contribuent pas la charge du rseau.
2.3. Scnarios retenus

Les modles de trafic, dcrits dans le paragraphe prcdent, correspondent aux services typiques de Tunisie tlcom. Pour la vido tlphonie, qui appartient la classe conversationnelle, nous allons prendre le modle de trafic du service vido en tenant compte du taux dactivit dans les deux sens, montant et descendant. Nous allons rcapituler, ces diffrents modles de trafic dans le tableau suivant : Service voix Un appel correspond
Description du modle
Service vido Un appel correspond une squence vido complte 0.17 appels/heure 120s 0.58
Service web Un appel correspond au tlchargement dune page web 0.85 appels/heure Dpend du dbit allant de 1 5s
une communication tlphonique
Taux d appel par utilisateur Dure moyenne un appel Taux d activit de la source
0.8 appels/heure 150s 0.5
0.48
Tableau III-2 : Modlisation du trafic Projet de fin d tudes - N. Ghanmi - Juin 2006 59
Chapitre III La spcification des modles de trafic pour chaque service nous a permis de retenir un profile utilisateur pour chaque service. Ce profile constituerait des valeurs typiques que nous allons prendre pour dterminer la contribution de chaque service dans la charge total du trafic dans le rseau coeur.
2.4. Calcul du trafic du rseau d accs

2.4.1. Dtermination du nombre d abonns par technologie
On dispose des donnes suivantes : Paramtre Nombre d abonns dans le rseau mobile Pourcentage des abonns GSM par rapport aux abonns mobiles Pourcentage des abonns EDGE par rapport aux abonns mobiles Pourcentage des abonns UMTS par rapport aux abonns mobiles Nombre d abonns dans le rseau PSTN Pourcentage des abonns MSAN par rapport aux abonns PSTN Pourcentage des abonns POTS par rapport aux abonns PSTN Pourcentage des abonns POTS par rapport aux abonns MSAN Nombre d abonns haut dbit Pourcentage des abonns ADSL par rapport aux abonns MSAN Nombre dabonns ADSL Nbabonns1 ( ADSL) Nbabonns ( ADSL) Pabonns ( ADSL / MSAN ) Pabonns ( POTS / MSAN ) Pabonns ( POTS / PSTN ) Nbabonns ( PSTN ) Pabonns (MSAN / PSTN ) Pabonns (UMTS / Mobile) Pabonns ( EDGE / Mobile) Dsignation Nbabonns (Mobile) Pabonns (GSM / Mobile)
Tableau III-3 : Rpartition des abonns par service
60
Chapitre III Lutilisation des services varie selon la nature du service (conversationnel, interactif, streaming) dune part et selon la technologie utilise dune autre part (GSM, EDGE, UMTS, POTS, ADSL). Ils sont rpartis suivant le tableau suivant : Services Technologies Mobile GSM EDGE UMTS ADSL POTS Conversationnel Streaming Interactif
Fixe
Tableau III-4 : Services utiliss par chaque technologie La premire tape consiste dterminer le nombre dabonns par
technologie comme suit:
Figure III.11 : processus de calcul du nombre d abonns par technologie Nbabonns (GSM ) = Nbabonns (Mobile) Pabonns (GSM / Mobile) Nbabonns ( EDGE ) = Nbabonns (Mobile) Pabonns ( EDGE / Mobile) Nbabonns (UMTS ) = Nbabonns ( Mobile) Pabonns (UMTS / Mobile) Nbabonns ( POTS ) = Nbabonns1 ( POTS ) + Nbabonns 2 ( POTS ) o o o Nbabonns1 ( POTS ) = Nbabonns ( PSTN ) Pabonns ( POTS / PSTN ) Nbabonns 2 ( POTS ) = Nbabonns ( MSAN ) Pabonns ( POTS / MSAN ) Nbabonns ( MSAN ) = Nbabonns ( PSTN ) Pabonns (MSAN / PSTN ) (III.1) (III.2) (III.3) (III.4) (III.5) (III.6) (III.7)
61
Chapitre III Nbabonns ( ADSL) = Nbabonns1 ( ADSL ) + Nbabonns 2 ( ADSL) o Nbabonns 2 ( ADSL) = Nbabonns ( PSTN ) Pabonns ( ADSL / MSAN )
(III.8) (III.9)
2.4.2. Dtermination du trafic achemin au niveau accs

Paramtres des abonns par technologie Modle de trafic du service conversationnel Modle de trafic du service streaming Modle de trafic du service interactif
Trafic gnr par le service conversationnel de la technologie I
Trafic gnr par le service streaming de la technologie I
Trafic gnr par le service interactif de la technologie I
P O T S
G S M
E D G E
U M T S
A D S L
U M T S
A D S L
E D G E
U M T S
A D S L
Trafic POTS
RE
Trafic GSM
(POTS)
RE
Trafic ADSL
(GSM)
RE
Trafic EDGE
RE
Trafic UMTS
RE
(ADSL)
(EDGE)
(UMTS)
Paqutisation
Trafic total achemin niveau core
Trafic total achemin niveau accs
Figure III.-12 : Calcul du trafic total niveau accs
62
Chapitre III Le diagramme de la figure III-12 montre les diffrentes tapes suivre pour dterminer le trafic achemin au niveau accs qui va servir pour le dimensionnement des diffrentes entits du rseau: Dabord, on dtermine le trafic gnr par chaque service et chaque technologie en appliquant un modle de trafic adquat pour chacun : Pour le POTS et le GSM, on na que le service de tlphonie classique (en mode circuit). Leur trafic, exprim en erlang, est dtermin par lquation suivante :
Trafic gnr ( I ) = Nbabonns ( I ) Traficmoyen / abonn ( I )
(III.10)
Avec o I : dsigne GSM ou POTS o Traficmoyen / abonn ( I ) dsigne le trafic moyen par abonn de la technologie I (POTS ou GSM). Pour les technologies ADSL et UMTS on dispose des services conversationnel, streaming et interactif. Alors que pour EDGE, on ne dispose que des services conversationnel et interactif. On doit tout dabord dterminer le nombre des abonns actifs par service et par technologie. Le nombre dabonns actifs est donn par lquation (III.11) : Nbabonns ( I , J ) = Nbabonns ( I ) activit ( J , I ) Avec o I dsigne EDGE, UMTS ou ADSL. o J dsigne le service Conversationnel, Interactif ou Streaming. o o activit ( J , I ) dsigne le taux dactivit du service J de la technologie I. Nbabonns ( I , J ) dsigne le nombre dabonns I actifs du service J. (III.11)
Dans ces conditions, le trafic gnr par le service J dans une technologie I est gnralement modlis par lquation suivante :
Traficgnr (J , I ) = Nbabonns (I , J ) appel ( J , I ) Tappel ( J , I ) Dmax (J , I ) activit _ s ( J , I )
(III.12)
Avec o
Traficgnr ( J , I )
dsigne le volume de trafic gnr par le service J du rseau
I (exprim en Kb/s)
63
Chapitre III o appel ( J , I ) est le taux dappel/heure/abonn du service J pour la technologie I (en appel/heure). o Tappel ( J , I ) est la dure dappel du service J pour la technologie I (en s/appel). o Dmax ( J , I ) est le dbit max du service J pour la technologie I (en Kb/s).
o activit _ s ( J , I ) est le taux dactivit de la source du service J de la technologie I. Gnralement, on calcule le trafic du service gnr en utilisant les paramtres correspondants la technologie utilise. Ensuite, on calcule le trafic gnr par chaque technologie (POTS, GSM, ADSL, EDGE, UMTS) :
Trafic gnr ( I ) =
J {conversationnel,interactif,streaming }
Trafic gnr ( J , I )
(III.13)
On suppose toujours que : o Traficgnr (interactif,GSM)= Traficgnr (streaming,GSM)= 0 o Traficgnr (interactif,POTS)= Trafic gnr (streaming,POTS)= 0 Enfin, et aprs avoir exprimer lensemble des valeurs des trafics gnrs par chaque technologie en Kb/s, il suffit deffectuer leur somme pour dterminer la charge totale du rseau daccs (en Kb/s).
Trafictotal _ gnr =
I { POTS ,GSM , ADSL , EDGE ,UMTS }
Traficgnr ( I )
(III.14)
Cependant, pour le dimensionnement des entits du rseau on va sintresser seulement au trafic sortant. En effet, ce nest pas tout le trafic qui va tre achemin travers le Media Gateway. Ainsi, si on dispose du coefficient de routage externe pour chaque technologie I CRE ( I ) , le trafic achemin par chacune est dtermin par lquation suivante :
Traficachemin ( I ) = Traficgnr ( I ) CRE ( I )
(III.15)
Ainsi, le trafic total achemin est la somme des trafics achemin par chaque technologie.
64
Chapitre III
Trafictotal_achemin =
I { POTS,GSM,ADSL,EDGE,UMTS }
Traficachemin (I)
(III.16)
3. dimensionnement de quelques entits du rseau IMS

3.1. Gnralit sur le dimensionnement
Le but du dimensionnement est de dterminer la qualit exacte de Hardware et la capacit ncessaire des interfaces qui satisferont la qualit de service requise. Le surdimensionnement est une perte pour loprateur car il aboutit une utilisation inefficace des quipements. Aussi, le sous-dimensionnement cause la congestion, engendre les dlais et dtriore les performances des services. Les entres pour le dimensionnement sont les donnes concernant les abonns, y incluent le modle de trafic ; les informations sur le rseau, la qualit de service (QoS) requise, et les informations sur les performances et les limites des quipements. Il est donc essentiel davoir un modle de trafic le plus raliste possible, se fixer une architecture exacte et avoir des connaissances sur les produits offerts par le fournisseur dquipement : configurations possibles, paquetages disponibles,
performances et limites ainsi que connatre les diffrentes versions software et hardware. La complexit du dimensionnement est fortement lie a lirrgularit au niveau des caractristiques du trafic de donnes (taux darrives, dbits,). Cest ainsi que le dimensionnement du trafic multimdia est plus complexe que le dimensionnement du trafic de parole. Le trafic de donnes est trait en mode paquet : les informations sont envoyes en datagrammes. La taille de ces datagrammes est variable en fonction du volume des donnes, dbit, etc Ltape de dimensionnement est une tape trs importante puisquelle nous permet dvaluer le cot de linfrastructure dployer. Cette partie va tre consacre au processus de dimensionnement des diffrentes entits dun rseau c ur IMS.
3.2. Processus de dimensionnement

3.2.1. Dimensionnement des MGWs
Le dimensionnement dun MGW consiste dterminer sa capacit de commutation ce qui revient dterminer la capacit de ses interfaces niveau accs et niveau core. La capacit de linterface niveau accs est gale au trafic total achemin travers ce MGW, dtermin par lquation (III.16).
65
Chapitre III Priode de paquetisation ( Tp )
Traficachemin (GSM) Traficachemin (EDGE) Traficachemin (UMTS) Traficachemin (POTS) Traficachemin (ADSL)
Capacit de commutation
MGW
Figure III.13 : Dimensionnement de MGW Le trafic mode paquet passe directement travers le MGW alors que le trafic mode circuit doit tre paquetis au niveau du MGW. Selon le dbit gnr par le codec audio et en tenant compte des diffrentes possibilits des priodes de paqutisation, on peut obtenir la taille des donnes audio. Ces donnes audio vont subir des encapsulations au niveau des diffrentes couches commenant par la couche transport jusqu arriver la couche liaison de donnes (Annexe A). Ainsi, la formule qui permet de calculer le dbit par appel est la suivante :
Dappel = ( Dbitcodec Tp + entteRTP /UDP / IP + entteliaison + enqueueliaison ) / Tp
(III.16)
Avec o o
Dappel : dbit par appel en Kbit/s
Dbitcodec : dbit gnr par le codec en Kbit/s
o Tp : la priode de paqutisation en ms o o o entteRTP /UDP / IP : la taille lentte RTP/UDP/IP ajouter en bits entteliaison : la taille de lentte du protocole de couche liaison en bits enqueueliaison : la taille de lenqueue du protocole de couche liaison en bits
Appliquons cette formule au trafic mode circuit (GSM et POTS), leur somme va tre additionne avec lensemble des trafics mode paquet. On obtient ainsi la capacit de linterface du MGW niveau core.
66
Chapitre III On peut aussi dterminer la capacit dun MGW en terme de nombre de chssis. En effet si on dispose de la capacit du chssis, le nombre de gateways sera dtermin comme suit :
NbMGW =
CapacitMGW Capacitchssis
(III.17)
3.2.2. Dimensionnement de MGCF

Le MGCF est une passerelle (Gateway) qui assure les communications entre lIMS et les usagers du domaine circuit (CS). Tout le trafic de signalisation (contrle dappels ou session) gnr par les utilisateurs du domaine circuit vers lIMS passe par le MGCF. Ce dernier assure la conversion entre protocoles ISDN User Part (ISUP) et Bearer Independent Call Control (BICC) vers le protocole SIP. Le dimensionnement de cet quipement se traduit en terme de capacit de traitement de son processeur. Il suffit donc de dterminer le nombre dappels vhiculer exprim en cps (call per second) ou en BHCA (Busy Hour Call Set up) tel que :
charge(en BHCA)=charge (en cps)3600

Gnralement, un MGCF fonctionne dans les deux cas suivant : o Lappel est initi par le mode circuit.
(III.18)
o Lappel est initi par le mode paquet et destin vers le mode circuit. Ce type dappel ne peut tre que du conversationnel. Do la formule suivante :
Ch arg eMGCF =
I {GSM , POTS }
[ Nbabonn ( I ) appel ( I )]
I { ADSL ,UMTS }
[ Nbabonn ( I , conversationnel ) appel ( I , conversationnel ) RE _ circuit ( I )]
(III.19)
Avec o Nbabonn ( I , conversationnel ) dsigne le nombre dabonns du rseau I activant le service conversationnel. o appel (conversationnel , I ) dsigne le taux dappel du service conversationnel dans la technologie I. o RE _ circuit est le taux de routage externe vers le mode circuit.
67
Chapitre III Certains de ces paramtres sont gnralement donns, les autres peuvent tre dduits partir dautres. Par exemple, le taux dappels par abonn est dtermin en fonction de la dure moyenne dun appel et le trafic moyen par abonn par la formule suivante :
appel = Traficmoyen / abonn Dureappel
(III.19)
3.2.3. Dimensionnement de CSCF

Comme le MGCF, le dimensionnement dun CSCF se traduit par la capacit de traitement de son processeur qui sexprime en cps. La seule diffrence est que le MGCF traite des services narrow band (mode circuit), alors que le CSCF traite des services broad band (large bande). Cest pour cela quon ne va sintresser quaux technologies EDGE, UMTS et ADSL qui offrent des services data voir mme multimdia. Ainsi la charge dun CSCF sexprime comme suit :
Ch arg eCSCF =
I {EDGE , ADSL,UMTS }
[ Nbabonn ( I ) appel ( I )]
(III.18)
Avec Nbabonn ( I ) est le nombre dabonns simultans utilisant la technologie I
Conclusion
Le dimensionnement est une tape importante dans le dploiement du rseau IMS. Elle intervient dans le cadre de laide la dcision pour lintroduction du concept IMS. Pour atteindre notre objectif, nous avons men un travail de dimensionnement de ce rseau en tenant compte de son aspect multi-services. Cette tche consiste valuer le volume de trafic vhicul au niveau du rseau coeur ainsi que la dtermination de la capacit ncessaire des diffrentes entits du rseau pour supporter ce trafic. Notre objectif est la migration du rseau de Tunisie Tlcom vers IMS et lvaluation de son impact. On a dj propos une stratgie de migration dans ce chapitre, la ralisation dun outil de dimensionnement et son application au rseau de Tunisie Tlcom sera lobjectif du chapitre suivant. .
68
Chapitre VI
Chapitre IV :
Dveloppement dun outil de dimensionnement du c ur de rseau IMS et son application au rseau de Tunisie Tlcom
Introduction
Notre objectif une fois on a dtaill le processus de dimensionnement du rseau c ur IMS, est la conception et la ralisation dun outil qui implmente les diffrentes phases du processus. En effet, le dimensionnement est une tache assez complexe et un tel outil peut simplifier et automatiser cette tache aux administrateurs de rseau. Dans ce dernier chapitre, nous allons tout dabord spcifier loutil de dimensionnement quon a dvelopp en dcrivant ses fonctionnalits, son approche conceptuelle, et la mthodologie de son utilisation. Ensuite, on va utiliser cet outil pour dimensionner le rseau c ur de Tunisie Tlcom dans un concept IMS. On va dfinir les diffrents paramtres du processus de dimensionnement, et on va finir par linterprtation des rsultats obtenus et la proposition dune liste de recommandations qui serviront lors du dploiement du concept IMS.
1. Spcifications de l outil
1.1. Donnes de dimensionnement
Notre outil TunTel applique les rgles dingnierie de dimensionnement sur les donnes dentre de loutil, afin dvaluer la capacit des quipements au niveau du c ur du rseau et tablir larchitecture finale du rseau dimensionn.
69
Chapitre VI
1.1.1 Donnes d entre

Loutil TunTel a pour entres les donnes suivantes : Le nombre dabonns fixe et mobile dans le rseau dimensionner. Le nombre de zones dans le rseau dimensionner Caractrisation des diffrents modles du trafic data Description des diffrentes zones du rseau : Les technologies supportes par chaque zone et les caractristiques de chacune.
1.1.2 Rsultats de sortie

Loutil TunTel a pour sorties : Les quipements ncessaires pour la migration vers un concept IMS. Le trafic total achemin par technologie et par classe de service. Larchitecture finale du rseau IMS dans la zone dimensionne.
1.2. Synoptique de l interface utilisateur de l outil

Loutil TunTel fournit une interface utilisateur simple pour laide au dimensionnement des rseaux IMS. Lutilisateur de loutil doit suivre une dmarche hirarchique pour le dimensionnement de tout son rseau. Il doit tout dabord dfinir les caractristiques de son rseau : le nombre dabonns (fixe et mobile) et le nombre de zones desservir. Pour chaque zone, lutilisateur de loutil doit prciser les diffrentes
technologies utilises et le profil des abonns dans cette zone. Enfin, il passe la caractrisation de quelques donnes relatives la politique de loprateur (codeurs audio utiliss, priode de paqutisation) afin de dterminer la capacit de commutation des MGWs, le dbit total couler et la capacit des quipements niveau contrle (MGCF et CSCF). Cet outil permet un oprateur de fixer la plus part des paramtres de dimensionnement qui traduisent sa situation et sa politique doffre de services. De mme, cet oprateur bnficie de la libert de choix du modle du trafic du rseau daccs selon ses tudes et ses estimations. Cet outil permet aussi une grande prcision au niveau du dimensionnement : En effet, le rseau est dcoup en domaines, o chaque domaine reprsente, gnralement, une zone gographique ayant des caractristiques bien prcises. Les paramtres du rseau sont dtaills donc par domaine.
70
Chapitre VI
Figure IV-1 : Synoptique de l interface utilisateur
71
Chapitre VI
1.3. Outil de dveloppement

Nous avons choisi de travailler avec le langage Java. Les compilateurs les plus clbrs de ce langage sont le J2SDK, le Jbuilder et le NetBeans. Nous avons limin le J2SDK de la liste de nos choix parce quil est un compilateur trs simple, il nintgre pas un diteur propre lui, il convient juste pour le dveloppement des applications simples, par contre le NetBeans est plus quun compilateur, cest tout un environnement de dveloppement. En fait, NetBeans assure le support de lintgrit des langages pour le dveloppement en Java.
2. Ralisation de l outil
2.1 Au dmarrage
Lors du lancement de loutil TunTel ladministrateur se trouvera devant un cran de dmarrage, prsentant lapplication dveloppe.
Figure IV-2 : Ecran de dmarrage Aprs le dmarrage de loutil, ladministrateur est face une interface daccs lapplication, il doit sauthentifier laide dun identifiant et dun mot de passe.
Figure IV-3 : Identification de l administrateur Projet de fin d tudes - N. Ghanmi - Juin 2006 72
Chapitre VI Le programme vrifie lidentit tape par ladministrateur, si lun des champs est incorrect alors un message derreur apparat pour que ladministrateur vrifie ses identifiants, sinon il accde linterface de la premire fentre de loutil. Cette interface est celle prsente sur la figure VI-4.
2.2. Spcifications des paramtres gnraux
Figure IV-4 : Spcification des paramtres gnraux du dimensionnement Face cette interface, lutilisateur est invit saisir les paramtres gnraux du dimensionnement savoir le nombre dabonns du rseau mobile, le nombre dabonns du rseau fixe et le nombre de zones dans le rseau dimensionner. Les valeurs des deux premiers paramtres sont estimes et prvues par des statistiques (nombre dabonns futur et actuel). Le troisime paramtre, dsignant le nombre de zones dans le rseau, est dduit lors de ltablissement de la stratgie de migration. En effet, on dsigne par zone un ensemble de sous rseaux de diffrents technologies (POTS, GSM, EDGE, UMTS, ADSL) qui sont grs par un MGW. Dans notre cas, on a adopt une stratgie de migration qui se base sur 16 MGWs et donc on va diviser le rseau en 16 zones dont on doit dfinir les caractristiques de chacune. Une fois lutilisateur a fix ces trois paramtres, il appuie sur le bouton suivant pour passer la fentre suivante o il est invit configurer son rseau.
2.3. Configuration du rseau

Dans la phase de configuration du rseau, lutilisateur doit spcifier : Le modle de trafic data du rseau daccs. Les caractristiques des diffrentes zones. Les caractristiques du codeur audio utilis dans le mode circuit.
73
Chapitre VI
Figure IV-5 : Configuration du rseau dimensionner
2.3.1. Spcification du modle de trafic data

A travers cette interface, lutilisateur est amen fixer les paramtres du modle de trafic data du rseau daccs. Chaque type de service a ses propres paramtres en terme de taux dappel/abonn, dure dun appel et taux dactivit de la source. De plus, pour un mme service, la valeur dun mme paramtre peut changer dune technologie une autre (EDGE, UMTS et ADSL).
Figure IV-6 : Spcification du modle de trafic data Ce modle de trafic est commun pour lensemble des zones du rseau et va nous servir pour le calcul du trafic data au niveau accs de chacune de ces zones.
74
Chapitre VI
2.3.2. Configuration des diffrentes zones du rseau

Pour chaque zone, lutilisateur est amen lui assigner un nom, fixer le nombre dabonns mobile et le nombre dabonn fixe. Il fixe aussi les taux dactivits des services conversationnel, streaming et interactif pour cette zone.
Figure IV-7 : Configuration du rseau par zone Ensuite, lutilisateur de loutil passe dterminer lensemble des technologies actives dans cette zone en cochant les cases correspondantes. Puis, il passe la configuration de chacune de ces technologies en appuyant sur le bouton correspondant.
Figure IV-8 : Spcification des paramtres des rseaux GSM et POTS par zone Vu que les technologies GSM et POTS sont en mode circuit, elles vont tre traites de la mme manire, et de ce fait, elles ncessitent les mmes paramtres. Ainsi, pour
75
Chapitre VI chaque technologie, lutilisateur de loutil est invit fixer le pourcentage en nombre dabonns, le trafic moyen par abonn et le taux de routage externe.
Figure IV-9 : Spcification des paramtres des rseaux ADSL, EDGE et UMTS par zone En ce qui concerne la configuration des technologies ADSL, EDGE et UMTS, lutilisateur de loutil est invit fixer le pourcentage en nombre dabonn pour chaque technologie, le taux de routage externe et les diffrents dbits disponibles ainsi que leurs caractristiques. Ainsi, lutilisateur fixe les paramtres de chaque technologie lune aprs lautre et il les valide en appuyant sur le bouton valider . Une fois tous les paramtres de la zone sont fixs, lutilisateur passe la zone suivante en appuyant sur le bouton suivant . Une fois toutes les zones sont spcifies, lutilisateur valide ses donnes et revient la fentre principale (celle prsente dans la figure IV-5). Il passe ensuite la fixation des paramtres du codeur audio.
2.3.3. Spcification des paramtres du codeur audio
Figure IV-10 : Paqutisation du flux audio mode circuit Projet de fin d tudes - N. Ghanmi - Juin 2006 76
Chapitre VI Face cette interface, lutilisateur de loutil est invit fixer le type du codeur audio utilis dans le mode circuit (G.711, G.723 ou G.729). Le flux TDM audio va tre traduit en un flux RTP/UDP/IP, il est ainsi paquetis et encapsul niveau liaison (Annexe A). A travers cet outil, on laisse lutilisateur le choix du protocole utilis niveau liaison et de la priode de paqutisation. Pour le cas dtude, on utilise gnralement un codeur G.711 qui offre un dbit de 64 Kb/s. Et on va choisir lEthernet comme protocole du niveau liaison.
2.4. Affichage des rsultats du dimensionnement

Aprs la fixation de tous les paramtres de dimensionnement, on appelle le module de calcul de manire transparente tout en effectuant les diffrentes tapes ncessaires du processus de dimensionnement. Une fois tout le calcul est fait, il ne reste quafficher les rsultats obtenus du processus de dimensionnement. Ils sont prsents dans la fentre de la figure IV-11.
Figure IV-11 : Fentre d affichage des rsultats du processus du dimensionnement Pour valider notre outil de dimensionnement, une tude de cas permettant le dploiement du concept IMS dans le rseau de Tunisie Tlcom fera lobjet de la partie suivante.
77
Chapitre VI
3. Etude de cas : dimensionnement du rseau IMS de Tunisie Tlcom

Ltape de dimensionnement des rseaux est gnralement prcde par une tape de dfinition de la stratgie dployer. En effet, celle-ci est trs importante pour la spcification de la topologie du nouveau rseau, ce qui facilite la tache de dimensionnement. Dans le cas de Tunisie Tlcom, on a dj propos une stratgie de migration. Celleci est base sur un c ur de rseau unifi IP/MPLS, compos de 9 routeurs Core et 16 routeurs Edge. A chacun de ces routeurs est connect un MGW qui assure la convergence niveau transport des rseaux fixe et mobile en interconnectant les centres de transit rgional du rseau fixe et les MSCs du rseau mobile. Ce MGW achemine aussi le trafic data haut dbit provenant des MSANs et des DSLAMs du rseau ADSL. On a aussi envisag de dployer un rseau UMTS dans les grandes villes pour bnficier des services haut dbit mobile.
3.1. Les paramtres gnraux de dimensionnement

Vue que Tunisie Tlcom a tendance tendre ses rseaux fixe et mobile, on a fix le nombre dabonnes mobiles 5 000 000 et le nombre dabonns fixes 3 000 000 bien que le nombre actuel est dj infrieur. En effet, le nombre dabonns mobiles inclut les abonns GSM actuels et les abonns EDGE et UMTS futurs. Alors que le nombre dabonns fixes inclut les abonns POTS et ADSL actuels et estims dans le futur. Du fait que le dploiement de lIMS nest pas homogne dans tout le rseau, on va adopter une approche par zone. De plus, en se basant sur notre stratgie de migration, le territoire tunisien est dcompos en 16 zones : Hached, Menzah, Kasba, Marsa, Sfax, Gabs, Gafsa, Kairouan, Moknine, Sousse, Bja, Bizerte, Nabeul, Ben Arous, Ouerdia et Bardo. Chacune est gre par un MGW. Vue que chaque zone a ses propres caractristiques (rpartition des abonns, taux dactivit des services, rpartition de trafic, etc. . .), lapproche par zone parait trs intressante.
3.2. Rpartition des abonns par zone

Le nombre dabonns fixe et mobile diffre dune zone une autre suivant sa nature (urbaine, rurale, hotspot). Les valeurs de ces paramtres sont approximes par loprateur
78
Chapitre VI Tunisie Tlcom et sont exprimes en pourcentage par rapport au nombre total dabonns fixes et mobiles pour le futur rseau IMS de cet oprateur. Zone Rseau Mobile % Mobile % GSM % EDGE % UMTS % Fixe Rseau Fixe % POTS % ADSL 60% 80% 87% 73% 80% 65% 73% 87% 77% 77% 73% 73% 83% 60% 60% 83% 40% 20% 13% 27% 20% 35% 27% 13% 23% 23% 27% 27% 17% 40% 40% 17%
1 Hached 16,40% 75% 40% 25% 7% 2 Menzah 2,60% 83% 30% 17% 6% 3 Ouardia 6,87% 85% 30% 15% 4% 4 Kasbah 9,40% 88% 30% 12% 4% 5 Ben Arous 4,15% 85% 25% 15% 6% 6 Marsa 4,15% 83% 48% 17% 4% 7 Bardo 2,60% 100% 18% 7% 8 Bizerte 1,81% 100% 25% 4% 9 Bja 4,64% 100% 12% 6% 10 Nabeul 8,36% 92% 20% 8% 7% 11 Sousse 8,50% 80% 20% 20% 8% 12 Moknine 4,75% 100% 12% 5% 13 Kairouan 1,81% 100% 13% 5% 14 Sfax 10,51% 77% 40% 23% 12% 15 Gabs 8,25% 82% 32% 18% 11% 16 Gafsa 5,20% 100% 23% 4% Tableau IV-1 : Rpartition des abonns par zone
De plus, la rpartition des abonns par technologie diffre suivant la zone. Par exemple, dans notre stratgie, on a choisi de dployer lUMTS uniquement dans les zones haut trafic : Hached, Menzah, Ouardia, Ben Arous, Marsa, Nabeul, Sousse, Sfax et Gabs. Ainsi, pour chaque zone, une tude approximative nous donne le pourcentage en nombre dabonns GSM, EDGE et UMTS par rapport au nombre dabonns mobiles dans cette zone, et le pourcentage en nombre dabonns POTS et ADSL par rapport au nombre dabonns fixe. A partir des pourcentages inscrits dans le tableau IV-1, on calcule le nombre dabonns par zone et par technologie.
3.3. Spcification des paramtres de la voix classique

Le service de la voix classique est un service de base pour toutes les zones du rseau. Il reprsente essentiellement le service de la tlphonie mobile GSM et le service tlphonique analogique traditionnel POTS (Plain Old Telephone Service). Le dimensionnement du trafic gnr par ce service ncessite la connaissance de certains
79
Chapitre VI paramtres savoir, le trafic moyen par abonn (en erlang), la dure moyenne dun appel (en seconde) et le taux de routage externe de ce trafic. Le trafic moyen par abonns varie entre 0.09 et 0.12 Erlang/abonn pour le rseau fixe et entre 0.02 et 0.04 pour le rseau mobile. La dure moyenne dun appel est gnralement gale 150s. Plus de 60% du trafic dans chaque zone est destin vers lextrieur. Le tableau de la figure IV-2 illustre les valeurs de chacune des zones avec plus de prcision. POTS Zone 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Hached Menzah Ouardia Kasbah Ben Arous Marsa Bardo Bizerte Bja Nabeul Sousse Moknine Kairouan Sfax Gabs Gafsa
Trafic Dure moyen/ moyenne d'un abonn (Erg) appel(s) Taux de routage externe
GSM
Trafic Dure moyen/ moyenne d'un abonn (Erg) appel(s) Taux de routage externe
0,12 0,12 0,12 0.11 0,11 0.12 0,12 0,11 0,09 0,11 0,12 0,11 0,09 0,11 0,11 0,09
150 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
0,7 0,8 0,6 0,56 0,65 0,8 0,7 0,65 0,7 0,68 0,58 0,67 0,81 0,62 0,72 0,66
0,035 0,04 0,03 0,025 0,02 0,027 0,025 0,025 0,028 0,029 0,03 0,027 0,025 0,032 0,026 0,028
150 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
0,75 0,8 0,7 0,62 0,7 0,8 0,75 0,65 0,76 0,73 0,67 0,72 0,68 0,78 0,75 0,7
Tableau IV-2 : Modle de trafic des rseaux en mode circuit
3.4. Modle de trafic data

Le trafic du rseau daccs est modlis par type de service (conversationnel, streaming et intractif) et par technologie ( EDGE, UMTS et ADSL). Cette diffrentiation est trs importante du fait quelle permet le calcul du trafic avec une haute prcision. Ainsi, les paramtres de chaque modle sont indiqus dans le tableau IV-3.
80
Chapitre VI EDGE Conv Stream Interac Taux d'appel/H Dure appel (s) Activit source UMTS ADSL Conv Stream Interac Conv Stream Interac 0,3 125 0,58 0,8 5 0,48
0,7 0,75 0,8 0,2 0,75 0,6 150 6 150 120 6 180 0,5 0,48 0,5 0,58 0,48 0,5 Tableau IV-3 : Modle de trafic des services data
Pour faciliter la tache de dimensionnement, on va appliquer ces modles pour toutes les zones du rseau. On va juste diffrencier ces zones par le taux dusage de chacun de ces services. En effet, chaque zone dispose de ses propres taux dactivit des services puisque le comportement des abonns envers les services diffre dune zone une autre. Dans notre tude, on va utiliser les taux du tableau IV-4. Taux d'activit des services (%) Conversationnel Streaming Interactif
Zone 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
35% 15% 38% Hached 50% 16% 40% Menzah 30% 8% 35% Ouardia 35% 15% 26% Kasbah 25% 12% 23% Ben Arous 45% 23% 35% Marsa 15% 12% 16% Bardo 8% 10% 10% Bizerte 10% 7% 20% Bja 27% 13% 36% Nabeul 40% 18% 43% Sousse 15% 9% 21% Moknine 10% 5% 12% Kairouan 45% 16% 43% Sfax 14% 8% 38% Gabs 11% 3% 20% Gafsa Tableau IV-4 : Taux d activit des services par zone
On note aussi que chaque flux en mode paquet peut tre gnr avec des diffrents dbits. Gnralement, les dbits des services EDGE ne dpassent pas 256 kb/s. Les services de lUMTS peuvent atteindre un dbit de de 2 Mb/s et ceux de lADSL peuvent atteindre un dbit de 4 Mb/s.
81
Chapitre VI Chaque groupe dabonns, dans une zone, utilisant le mme dbit dans une technologie bien dtermine (EDGE, UMTS, ADSL) est caractris par un taux de pntration par rapport au nombre total dabonns utilisant la mme technologie dans la zone considre et un taux de simultanit. La valeur de ces deux derniers paramtres peut varier dune zone une autre. Par exemple, on a plus tendance utiliser des dbits levs dans une zone industrielle que dans une zone rurale o les services conversationnels suffisent pour rpondre aux besoins des abonns.
3.5. Rsultats et analyse du dimensionnement
Figure IV-12 : Rsultats de dimensionnement du rseau c ur de Tunisie Tlcom dans un concept IMS Les rsultats gnraux de dimensionnement sont donns par la fentre de la figure IV-12. En effet, les abonns fixes (POTS et ADSL) et mobiles (GSM, EDGE et UMTS) gnrent un trafic total de lordre de 272186501 Kb/s au niveau accs. Il est rparti entre les trois services de la manire suivante : Projet de fin d tudes - N. Ghanmi - Juin 2006 82
Chapitre VI Le service conversationnel : 236729687 Kb/s Le service streaming : 26826796 Kb/s Le service interactif : 8630016 Kb/s Au niveau Core, ce trafic augmente pour atteindre une valeur de 307764296 Kb/s. Cette augmentation est due la paqutisation du trafic conversationnel en mode circuit, celui de GSM et POTS (Annexe A). Concernant la rpartition par technologie des abonns, on a 1447255 abonns EDGE, 4285019 abonns GSM, 714978 abonns UMTS, 2164797 abonns POTS et 835200 abonns ADSL. Cette rpartition donne une ide sur la politique de loprateur qui consiste augmenter les services data tout en gardant les services de la voix classique. Les rsultats spcifiques pour chaque zone sont prsents dans le tableau IV-5 : Zone 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Hached Menzah Ouardia Kasbah Ben Arous Marsa Bardo Bizerte Bja Nabeul Sousse Moknine Kairouan Sfax Gabs Gafsa Nombre d abonns Trafic
EDG UMT POT Total Total GSM ADSL Total GSM EDGE UMTS POTS ADSL E S S Accs Core
615000 328000 205000 126000 84000 1030000 1422038 7779332 23243748 99889516477429 49921444 53246446 107900 39000 22100 144000 36000 310000 285134 1306533 3655574 1141594 9639383 16028220 17987743 51525 104400 15600 463500 578673 2101609 4817004 827656 2487953 10812897 12744404 56400 87600 32400 590000 683107 3299008 6388977 636597 6291613 17299303 19111835 31124 144000 36000 387500 233042 873081 2626702 1046461 5105837 9885126 11642446 35275 78000 42000 327500 307204 3000358 5355583 61836310787623 20069134 21340345 0 153299 56700 340000 214709 237673 0 104400 15600 210500 149470 123446 0 138600 41400 412000 429155 195448 149254 1215314 5352773 7169726 9133775 25665 758684 893882 1951150 3198446
291974 103050 413600 141000 176375 172225 130000 90500 232000 384560 340000 237500 90500 51875 99600 23400 22625 27840 83600 85000 28500 11765
136224 824088 2591995 4176913 5898165
33440 161699 48300 628000 736767 1544490 3176828 1175082 7490642 14123811 16749617 85000 175200 64800 665000 673858 2303011 1127271013889401462598830264508 33097633 0 109500 40500 387500 423638 293277 0 124499 25500 240500 149470 80083 139926 795747 3630281 5282871 6957622 50343 740246 1467906 2488051 3710023
404635 210200 120865 216000 144000 885500 855424 6376960 1797494215696923529702462074045 45404792 338250 132000 260000 59800 74249 198000 132000 742500 581004 1332602 4215847 14388851134441418912753 21686945 0 99600 20400 380000 480949 458611 67125 1250204 1219529 3476421 5854053
Tableau IV-5 : Rsultat de dimensionnement par zone A priori on connat le nombre de MGWs dans le rseau (16 MGWs). Ce nombre est dtermin pendant la phase de llaboration de la stratgie de migration.
83
Chapitre VI Le dimensionnement permet dvaluer la capacit de commutation de chaque MGW, prsente dans les deux dernires colonnes du tableau IV-5. On remarque, ainsi, une concentration de trafic dans la zone de Hached. De plus cette zone renferme le plus grand nombre dabonns. On peut donc envisager dinstaller les serveurs de la couche contrle dans cette zone. En ce qui concerne le MGCF et le CSCF, ils prsentent respectivement une capacit de traitement de 8947657 BHCA et 8553235 BHCA. En cps (call per second), ces capacits sont de lordre de 2485.46 cps pour le MGCF et de 2375.8 cps pour le CSCF. Limportance des capacits de ces entits permet une concentration de trafic de tout le rseau. En effet, ces composants seront en commun entre les divers services offerts par loprateur, ce qui nous permet de rduire le nombre dquipements dployer dans le rseau et donc rduire le cot de linfrastructure installer. Certainement, Les rsultats obtenus ne sont pas dfinitifs notamment on a nglig pas mal daspects dans le processus du dimensionnement et dans le fonctionnement du rseau (Interconnexion avec le rseau intelligent, la mobilit des abonns, la charge de signalisation, etc. . .).
4. Listes de recommandations
Suivant les rsultats obtenus lors de ltape du dimensionnement, et en tenant compte des hypothses faites, notre oprateur historique pourra aisment migrer vers un concept IMS en suivant plusieurs recommandations : Commencer par llaboration dune stratgie de migration la plus optimale possible en partageant le rseau en diffrentes zones. Faire une tude statistique bien dtaille sur lensemble de ces zones ce qui permet de dimensionner le rseau avec plus de prcision. Equiper chaque zone par un MGW qui permet la convergence des rseaux fixe et mobile niveau transport. Les quiper aussi par des MSANs qui permettent tout type daccs (POTS, ADSL, RNIS). Pour rduire les cots de transmissions, placer les MGWs le plus prs possible du point de concentration de rseau daccs (RNC, BSC).
84
Chapitre VI On peut mettre en commun certains MGWs entre deux ou trois zones pour des raisons de scurit en cas de la surcharge du rseau. Installer les serveurs dapplications et le HSS de lIMS dans la zone la plus dense en terme de trafic. Dans notre cas, cest la zone de Hached qui va supporter ces serveurs. Encourager les services multimdia par le dploiement de lUMTS dans les zones haut trafic. Evoluer le rseau GSM existant pour quil supporte le EDGE. La tlphonie classique doit aussi migrer vers la tlphonie sur IP. Utiliser la technologie Wimax pour les zones peuples et forts trafics. Cette solution assure des dbits plus importants, une meilleure qualit et une capacit plus importante que la couverture UMTS. Wimax est pleinement compatible avec le rseau UMTS travers lindpendance du concept IMS de la technologie daccs.
Conclusion
Le dimensionnement des rseaux IMS est une tche dlicate et complexe, surtout que cette technologie nest pas trs adopte dans le rseau Tunisien. Loprateur doit donner une grande importance la tche de dimensionnement de son rseau. Il doit faire les prvisions exactes pour satisfaire les besoins de ses abonns en terme de dbit et de QoS long terme. Loutil TunTel , prsent dans ce chapitre, a pour rle dautomatiser la tche de dimensionnement du c ur de rseau IMS dun oprateur, et prcisment il permet dvaluer la capacit des quipements dployer. A laide de notre outil TunTel on a pu dimensionner le c ur de rseau de Tunisie Tlcom dans le cadre de sa migration vers un concept tout IMS. Lanalyse des rsultats de dimensionnement obtenus nous a permis de dgager une liste de recommandations prendre en considration lors de limplmentation de lIMS. Ainsi, cette tude de cas simple et relle nous a permis dune part de valider notre outil de dimensionnement, et dautre part dvaluer limpact dintroduction de lIMS dans le rseau de Tunisie tlcom.
85
Conclusion gnrale
Dans le cadre du besoin de plus en plus urgent des services multimdia, plusieurs oprateurs dans le monde ont test ou commenc dployer des architectures IMS qui permettent de satisfaire les besoins de leurs abonns. Cest dans ce cadre que sintitule notre projet de fin dtudes, dans lequel, on a propos une stratgie dintroduction du concept IMS dans le rseau de tlcommunication de Tunisie Tlcom. Nous avons commenc dans le premier chapitre par tudier les concepts NGN et IMS, leurs principes, leurs architectures de bases et les protocoles mis en nous avons propos des scnarios de migrations vers ces deux concepts Par la suite, nous avons propos une stratgie de migration du rseau de loprateur Tunisie Tlcom en fonction des caractristiques de son march fixe et de son positionnement dans le mobile tout en exploitant au maximum son rseau existant. Cette stratgie est base sur une migration en douceur du rseau actuel vers NGN, puis vers IMS. La migration vers NGN est base sur la sparation des couches transport et contrle. En effet, la couche contrle est gre par deux softswitchs pour des raisons de scurit. En ce qui concerne la couche transport elle se base sur un c ur de rseau IP/MPLS unifi qui constitue une extension du rseau IP existant de Tunisie Tlcom. De plus, on a adopt dans notre stratgie une solution base sur 16 MGWs assurant la convergence des rseaux fixe et mobile. Elle est base aussi sur le dploiement des MSANs, permettant tout type daccs du rseau fixe, et sur lintroduction de lUMTS dans les zones haut trafic et lintroduction de lEDGE dans le rseau GSM existant pour bnficier des services haut dbit de ces deux technologies. Pour la migration de notre rseau vers IMS, on a envisag lvolution du software des softwitchs dploys et lintroduction de nouveaux quipements pour supporter de nouveaux services multimdia. uvre. Ensuite,
86
Et pour valuer notre stratgie, nous avons pass au dimensionnement du futur rseau IMS de cet oprateur historique. En effet, nous avons commenc par la modlisation du rseau daccs en mode paquet, qui reprsente une tape indispensable pour le dimensionnement. Puis nous avons ralis un outil de dimensionnement et on la appliqu dans le cas de Tunisie Tlcom en se basant sur la connaissance de la rpartition spatiale du trafic fixe et mobile et la rpartition gographique des abonns. A travers les rsultats obtenus, nous avons dgag les gains de la migration vers IMS en termes de performance et doptimisation des cots. Cest ainsi quon insiste sur limportance du concept IMS et la ncessit de son dploiement aux seins du c ur de rseau de tout oprateur dans le cadre dune convergence fixe/mobile et voix/data et pour faciliter le dploiement de nouveaux services.
87
Annexe A: Calcul du dbit d accs

On peut calculer le dbit daccs un site en suivant les tapes suivantes : Calculer le dbit par appel Calculer le nombre de circuits
1. Dbit par appel

Le dbit daccs peut tre calcul en tenant compte des lments suivant : Les codecs audio utiliss au niveau de la couche application Les diffrentes encapsulations aux niveaux des diffrentes couches (transport, rseau) Les protocoles au niveau de la couche liaison.
1.1. Les codecs audio

Les codecs les plus utiliss pour la compression/dcompression de la voix sur IP sont : G.711 offrant un dbit de 64 Kbit/s G.723 offrant un dbit de 6.3 et 5.3 Kbit/s G.729 offrant un dbit de 8 Kbit/s Selon le dbit gnr par le codec et en tenant compte des diffrentes possibilits des priodes de paqutisation, on peut obtenir la taille des donnes audio. Ces donnes audio vont subir des encapsulations au niveau des diffrentes couches commenant par la couche transport jusqu arriver la couche liaison de donnes.
1.2. Les encapsulations au niveau transport et rseau

Les donnes audio de la couche application sont affectes au niveau de la couche transport dune entte RTP ayant une taille minimale de 12 octets, puis dune entte UDP avec 8 octets enfin la mise en paquet au niveau de la couche rseau ajoute 20 octets pour lentte IP. La figure suivante illustre le principe de la mise en paquet.
88
20B
40B 8B
12B
20B
IP
UDP
RTP
Payload
Figure A-1 : Encapsulation RTP /UDP/ IP Les 20 octets du protocole IP quon a considr ne tiennent pas compte des champs Options et Padding.
1.3. Les protocoles utiliss au niveau de la couche liaison

Lencapsulation doit tenir compte des diffrents protocoles en niveau de la couche liaison. Ethernet La technologie Ethernet est la technologie la plus rpondue dans les rseaux dentreprises (LAN). La structure de la trame Ethernet est donne par la figure suivante :
Figure A-2 : Format de trame Ethernet La signification des diffrents champs nest pas aussi importante que la taille des donnes quajoute chaque protocole. Le dbit gnr sur le support physique varie avec la variation des diffrents paramtres cits ci-dessus. Pour chaque site, on suppose quon a un choix uniforme entre les diffrents utilisateurs des diffrents paramtres : codec, priode de paqutisation, protocole de couche liaison. La formule qui permet de calculer le dbit par appel est la suivante :
Dappel = ( Dbitcodec Tp + entteRTP / UDP / IP + entteliaison + enqueueliaison ) / Tp

Avec o
Dappel : dbit par appel en Kbit/s
(A.1)
89
Dbitcodec : dbit gnr par le codec en Kbit/s
o Tp : la priode de paqutisation en ms o o o entteRTP /UDP / IP : la taille lentte RTP/UDP/IP ajouter en bits entteliaison : la taille de lentte du protocole de couche liaison en bits enqueueliaison : la taille de lenqueue du protocole de couche liaison en bits
2. Calcul du nombre de circuits

Lalgorithme de la formule dErlang inverse permet de dterminer le nombre de circuits mettre en oeuvre pour supporter un trafic donn avec une probabilit de blocage fixe [17]. On peut calculer la bande passante ncessaire partir du nombre de circuits et le dbit par appel.
Bande = Dbit appel nbcircuit
(A.2)
90
Bibliographie
[1] Cabinet Arcome Etude technique, conomique et rglementaire de lvolution vers les rseaux de nouvelle gnration (NGN, Next Generation Networks) , ART, septembre 2002. [2] Rapport de lETSI-NGN Starter Groupe, compte-rendu de l assemble GA38 , 20-21/11/01. [3] Simon ZNATY et Jean-Louis DAUPHIN, Architecture NGN : Du NGN Tlphonie au NGN Multimdia , EFORT. [4] Simon ZNATY et Jean-Louis DAUPHIN, IP Multimedia Subsystem : Principes et Architecture , EFORT. [5] Simon ZNATY, Next Generation Network (NGN) dans les rseaux mobiles , EFORT. [6] Deuoteam Siticom, Regulatory implications of the introduction of next generation networks and other new developments in electronic communications, 16th May 2003 [7] J.Rosenberg, H.Schulzrinne, SIP: Session Initiation Protocol , Request for Comments: 3261, June 2002 [8] [9] S.tabbane, Les Rseaux mobiles , Edition Hermes, Paris, 1997. Toni Jawenski, Traffic Analysis and design of wireless IP networks , Artech, 2003. [ 10 ] 3GPP TS 22.800, IMS Subscription and access scenarios , Release 6, 03-2004. [ 11 ] 3GPP TS 23.228. IP Multimedia Subsystem (IMS) , Stage 2. Release 6, 2004-06. [ 12 ] Jean-Franois Pillou, Technologies Internet-ADSL , 1998. [ 13 ] ALCATEL, 5020 Media Gateway Controller , Release 2.0, 06/01/2005 [ 14 ] S. Mazlout, Caractrisation de l accs en mode paquet dans les rseaux mobiles de troisime gnration , Mmoire de DEA lENIT, Fvrier 2003. [ 15 ] Haruno Akimaru and Konosoukuke Kawashima, Teletraffic : Theory and Applications , Germany 1993. [ 16 ] Study group 13, NGN FG Proceedings Part II , ITU-T 2005 [ 17 ] B.Baynat Thorie des files d attente , HERMES Sciences, 2000
91
[ 18 ] Cabinet Ovum, L'volution du coeur de rseau des oprateurs fixes , Janvier 2006. [ 19 ] E. Burger et. al., Basic Network Media Services , draftburger- sipping-netann11.txt, work in Progress, IETF.
92
Glossaire
A
ATM ADSL Adaptation Layer2 Asynchronous Digital
CS CSCF Function
Circuit Switched Call Session Control
Subscriber Line AS ASP Provider ATM Mode Asynchronous Transfer Application Server Application Service
D
DHCP Dynamic Host
Configuration Protocol DSLAM DSL Access Multiplexer
E
ETSI Basic Call Process Bearer Independant Call European
B
BCP BICC Control BSC BTS Base Station Controller Base Transciever Station
Telecommunications Standards Institute
F
FR Frame Relay
G
GGSN Node Gateway GPRS Support
C
CAMEL Customized Applications
HLR GPRS Service GSM
Home Location Register General Packet Radio
for Mobile network Enhanced Logic CAP CCAF Function CDRs COPS Service CS Capability Set Call Detailed Record Common Open Policy Camel Application Part Call Control Agent
Global System for Mobile
Communications HSS Home Subscriber Server
93
HSS
Home Subscriber Server
MSC
Mobile Switching Center
I
IETF Force IMS IN INAP IP Multimedia Subsystem Intelligent Network Intelligent Network Internet Engineering Task
N
NAT Translation NGN Next Generation Protocol Network Address
O
OSA/Parlay Open Service Architecture
Application Protocol IP IP MS ISC Internet Protocol IP Media Server IMS Service Control
P
PSTN Network Public Switched Telephon
M
MAP MC MCU MEGACO MG MGC MGCF Function MGCP Protocol MIC Codage MPLS Switching MRF function MRFC Multimedia Resource Multimedia resource Multi Protocol Label Modulation par Impulsion Media Gateway Control Mobile Application Part Multipoint Controller Multipoint Controller Unit MEdia GAteway COntrol Media Gateway Media Gateway Controller Media Gateway Control
PS
Packet Switched
R
RADIUS User Service RI RNC RNIS Rseau Intelligent Radio Network Controller Rseau Numrique Remote Access Dial In
Intgration de Services RTC Public Rseau Tlphonique
S
SCP SDH Hierarchy SG SGSN Node Resource Signalling Gateway Serving GPRS Support Service Control Point Synchronous Digital
Function Controller MRFP Multimedia
Function Processor Projet de fin d tudes - N. Ghanmi - Juin 2006 94
SIB
Service
Independent
XML Langage
eXtensible
Markup
Building Block SIGTRAN SIP SIP-T SS7 SSP SIGnalling TRANsport Session Initiation Protocol SIP-Telephony Signalling System N7 Service Switching Point
T
TDM Multiplexing Time Division
U
UE UIT User Equipment Union International des
Tlcommunications UMTS Universal Mobile
Telecommunication System UTRAN UMTS Terrestrail Radio
Access Network
V
VLR VoIP VoP VPN Visitor Location Register Voice over IP Voice over Packet Virtual Private Network
W
WDM Multiplex Wavelenght Division
95

Réseau Et Service Mobile

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Réseau Et Service Mobile

Încărcat de

Drepturi de autor:

Formate disponibile

Cycle de formation des ingnieurs en Tlcommunications

Rseaux et Services Mobiles (RSM)

Rapport de Projet de fin dtudes

M. Jamel Sakka M. Rached Hamza

Anne universitaire : 2005/2006

Projet de fin dtude

Table des matires

Chapitre II: Scnarios de migration vers IMS.......................................... 21

Liste des figures

Liste des tableaux

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Etude des concepts NGN et IMS

1. Le contexte et les enjeux des rseaux et des services de nouvelle gnration

Projet de fin d tudes - N. Ghanmi - Juin 2006

1.2. Le dveloppement de nouvelles gammes de services

1.3. Progressions technologiques d envergure dans le domaine des rseaux de donnes

Projet de fin d tudes - N. Ghanmi - Juin 2006

Chapitre I La gnralisation du protocole IP et lmergence de la nouvelle version de ce

2. Etude du concept NGN

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

2.2. Modle d architecture en couche

Projet de fin d tudes - N. Ghanmi - Juin 2006

2.3. Evolution des entits et des protocoles du c ur de rseau NGN

Projet de fin d tudes - N. Ghanmi - Juin 2006

Figure I-3 : Architecture simplifie d un rseau NGN

2.3.2. Les entits principales du c ur de rseau NGN

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

2.3.3. Les familles de protocoles d un rseau NGN

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

3.2. NGN/IMS et convergence fixe/mobile

3.3. Impacts de l IMS pour les utilisateurs d un rseau NGN

3.4. Architecture IMS

3.4.1. Structuration en couche de l architecture IMS

Figure I-4 : L architecture de Rseau et de Service IMS

Projet de fin d tudes - N. Ghanmi - Juin 2006

3.4.2. IMS et SIP

3.4.3. Les principales entits du rseau IMS

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Scnarios de migration vers IMS

1. Approches de migration: Etat de l art

Projet de fin d tudes - N. Ghanmi - Juin 2006

1.2. Principaux scnarios de migration vers les rseaux de nouvelles gnrations

2. Scnarios de migration vers NGN

2.1. Migration des rseaux PSTNs

Projet de fin d tudes - N. Ghanmi - Juin 2006

2.1.2. Typologie des scnarios de migration d un rseau PSTN

Projet de fin d tudes - N. Ghanmi - Juin 2006

2.1.3. Scnarios de migration du c ur du rseau PSTN/ISDN vers NGN

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Projet de fin d tudes - N. Ghanmi - Juin 2006

Figure II-4: Scnario 3

2.2. Migration des rseaux mobiles

Projet de fin d tudes - N. Ghanmi - Juin 2006

donnes bases sur la commutation de paquets [6].