Ben Ammar Raja

Cycle de formation des ingnieurs en Tlcommunications
Option :
Rseaux et services Mobiles (RSM)
Rappor t de Pr oj et de f i n dt udes
Thme :
Etude et dimensionnement des diffrentes
entits dune plate-forme de services
dans un concept IMS
Ralis par :
Ben Ammar Rajaa
Encadrant (s) :
Mr Rached Hamza
Mr Jamel Sakka
Travail propos et ralis en collaboration avec
Anne universitaire : 2005/2006
i
La connaissanceest unenavigation dans un ocan dincertitude
travers des archipels decertitude
EdgarMorin, Les sept savoir ncessaire
lEducation du futur
ii
Ddicaces
Amon cher preSalah
et ma chremreFatma,
Aucun hommagenepourrait tre la hauteur del'amour
Et del'affection dont ils necessent demecombler.
Qu'ils trouvent dans cetravail
Un Tmoignagedemon profond amour et ternellereconnaissance.
Quedieu leur procurebonnesantet longuevie.
A mes chers frres : Majed et Amin (Mayna) ;
A mes chres surs : Imen et Latifa ;
A toutema famille;
A mes amies : Naouel, Refka et Sameh
Atous mes ami (e) s;
A tous ceux qui m'aiment ;
A tous ceux quejaime.
J eddiecettefleur.
Rajaa
iii
Remerciements
J e ne peux commencer ce rapport sans prsenter mes remerciements les plus sincres
tous ceux qui, de prs ou de loin, ont contribu sa ralisation. Ce travail est làgrgat des
rsultats des trois annes de formation SUP`COM en ce sens que cèst grce aux
connaissances acquises durant toutes ces annes de formation que jài pu raliser ce travail.
A cet effet, le minimum de justice impose que làpport de chacun des acteurs soit
reconnu ne serait-ce que par de remerciements : Jàdresse mes remerciements les plus
sincres Mr. RACHED HAMZA, Matre Assistant Sup`Com, pour son encadrement, sa
disponibilit et ses conseils fructueux quìl mà prodigues le long de mon projet.
J àdresse aussi mes remerciements Mr. JAMEL SAKKA, chef division Tunisie
Tlcom, qui nà cess de me guider et de me faire bnficier de son grand savoir ;
J e remercie galement tout le staff de l`cole plus particulirement le Directeur et le
Secrtaire Gnral de l`cole, tout le corps enseignant pour leurs connaissances quìl a bien
voulu me les partager ;
J e remercie aussi tous les membres de jury qui ont accept de juger mon travail.
J e ne saurais terminer sans adresser un mot de reconnaissance toute ma famille pour
son soutien sans faille.
iv
Avant Propos
Le travail prsent dans ce rapport a t effectu dans le cadre de la prparation du
diplme dìngnieur en Tlcommunication option Rseaux et Service Mobiles l`cole
suprieure des communications de Tunis (SupCom).
Le projet quòn a men a pour but tudier et de dimensionner les diffrentes entits
une plate-forme de services dans un concept IMS. Lòbjectif principal tant de trouver
une solution dìnteroprabilit de la plate-forme de services de concept IMS avec la plate-
forme IN classique de lòprateur Tunisie Tlcom, et de dimensionner les diffrentes
entits de la plate-forme de services de concept IMS tout en automatisant le processus de
dans un outil de dimensionnement.
v
Rsum
Rsum:
Dans ce projet, nous nous sommes intresss au rseau intelligent dans le concept IMS et
plus particulirement la migration du rseau existant vers le concept IMS.
Aprs une prsentation des principes et de làrchitecture du rseau IMS, nous avons propos
une stratgie de migration de la plate-forme de services existante de Tunisie Tlcom vers une
plate-forme de services dans un concept IMS.
Par la suite, nous avons dtaill le processus suivre afin dèffectuer le dimensionnement des
diffrentes entits de la nouvelle plate-forme de service.
Egalement, nous avons automatis ce processus dans lòutil IMS-
Plateform_Entities_Dimensionning.
Dans la dernire partie, nous avons appliqu notre outil au futur rseau de Tunisie Tlcom.
Mots cls:
IMS, IN, SCP, M-MGW, SG, MGCF, CSCF, INAP, CAMEL, Softswitch, MSC Server, modle de
trafic, dimensionnement.
vi
TABLE DES MATIERES
Introduction Gnrale........................................................... 1
CHAPITRE I : Les rseaux de nouvelle gnration............... 3
I.1 Introduction............................................................................... 3
I.2 Dfinition et description dun rseau NGN............................. 3
I.2.1 Modle dàrchitecture en couche..........................................................3
I.2.2 Rle des entits fonctionnelles de làrchitecture NGN.........................5
I.2.2.1 Rle dùn softswitch dans une architecture NGN...................................... 5
I.2.2.2 Rle des media gateways dans une architecture NGN.............................. 5
I.2.2.3 La Signalling Gateway (SG) ....................................................................... 6
I.2.3 Les familles de protocoles dùn rseau NGN .......................................6
I.2.3.1 Les protocoles de commande de Media Gateway...................................... 6
I.2.3.2 Les protocoles de signalisation entre les Softswitchs................................ 7
I.2.3.3 Les protocoles de contrle dàppel ............................................................. 7
I.3 Relations entre NGN et IP Multimedia Subsystem (IMS) ..... 8
I.4 IP Multimedia Subsystem (IMS) ............................................. 8
I.4.1 Structuration en couches de lÌMS .......................................................9
I.4.2 Entits de Rseau IMS.......................................................................10
I.4.2.1 Terminal IMS............................................................................................. 10
I.4.2.2 Home Subscriber Server (HSS) ................................................................ 10
I.4.2.3 Call State Control Function (CSCF)......................................................... 10
I.4.2.4 MGCF, IMS-MGW et T-SGW : Inter fonctionnement avec le RTC..... 12
I.4.3 Les Impacts de lÌMS.........................................................................14
I.5 Conclusion............................................................................... 15
CHAPITRE II : Etude dune plate-forme IN de la nouvelle
gnration ( IN NGN).......................................................... 16
II.1 Introduction........................................................................... 16
II.2 Objectif du concept du Rseau intelligent ........................... 16
II.3 Le modle conceptuel du rseau intelligent ......................... 17
II.3.1 Le plan service (SP, Service Plane)...................................................17
vii
II.3.2 Le plan fonctionnel global (GFP, Global Functional Plan)................18
II.3.3 Le plan fonctionnel rparti (DFP, Distributed Functional Plane) ......19
II.3.4 Le plan physique (PP, Physical Plane) ..............................................20
II.3.5 Relation entre plans ..........................................................................20
II.4 Architecture du rseau intelligent........................................ 21
II.5 Exemples de services ............................................................. 22
II.5.1 Service de tlphone gratuit ..............................................................23
II.5.2 La carte Prpaye (PPC) ...................................................................23
II.5.3 Service du Rseau Priv Virtuel (VPN) ............................................23
II.6 Evolution du Rseau Intelligent et de la gestion de service 23
II.6.1 Architecture de la plate-forme IN NGN............................................24
II.6.2 Les plates-formes Unifier de service et interfaces ouvertes...............25
II.6.2.1 Architecture du modle OSA/PARLAY................................................. 25
II.6.2.2 Architecture de service SIP...................................................................... 27
II.6.2.3 Mises en ouvre des services......................................................................... 27
II.7 INAP....................................................................................... 28
II.7.1 Ensemble de capacits ......................................................................28
II.7.2 Architecture du protocole INAP .......................................................28
II.8 CAMEL.................................................................................. 29
II.8.1 CAMEL phase1................................................................................29
II.8.2 CAMEL phase2................................................................................30
II.8.3 CAMEL phase3................................................................................31
II.9 SIP.......................................................................................... 31
II.9.1 Architecture du protocole SIP...........................................................31
II.10 Conclusion ........................................................................... 32
CHAPITRE III : Stratgie de migration de la plate-forme de
services existante de TUNISIE TLCOM vers une plate-
forme de concept IMS........................................................ 33
III.1 Introduction ......................................................................... 33
III.2 Objectifs de Tunisie Tlcom.............................................. 33
III.3 Intgration dune plate-forme IN/IMS dans
environnement existant de loprateur Tunisie Tlcom........ 34
viii
III.3.1 Phase1 : Coexistence des rseaux existants avec le rseau NGN.....36
III.3.1.1 Etape1 : Migration vers le NGN ............................................................ 36
III.3.1.2 Etape2 : volution graduelle vers lÌMS................................................ 42
III.3.2 Phase2 : Rseau IMS disposant de la totalit de service ..................45
III.4 Conclusion............................................................................ 47
CHAPITRE IV : Analyse de trafic et dimensionnement des
entits de la plate-forme de services IMS......................... 48
IV.1 Introduction.......................................................................... 48
IV.2 Modle de trafic du rseau daccs..................................... 48
IV.2.1 Les diffrentes classes de qualit de service ....................................48
IV.2.1.1 La classe conversationnelle (conversational)........................................ 49
IV.2.1.2 La classe Streaming................................................................................ 49
IV.2.1.3 La classe Interactive ............................................................................... 50
IV.2.1.4 La classe background.............................................................................. 50
IV.2.2 Modle de trafic de la classe conversationnelle ...............................51
IV.2.3 Modle de trafic de la classe Streaming...........................................51
IV.2.4 Modle de trafic de la classe Interactive..........................................51
IV.2.5 Modle de trafic de la classe Background........................................53
IV.3 Dimensionnement des entits du plate-forme de services
IMS................................................................................................ 53
IV.3.1 Dimensionnement MGCF ...............................................................54
IV.3.2 Dimensionnement du CSCF............................................................55
IV.3.3 Dimensionnement des serveurs dàpplication..................................56
IV.4 Spcification et prsentation de loutil IMS-
Plateforme_Entities-Dimensioning ............................................. 56
IV.4.1 La conception de lòutil de dimensionnement .................................56
IV.4.2 Utilisation de lòutil ........................................................................57
IV.5 Etude de cas : dimensionnement des entits de la plate-
forme de services IMS de rseau Tunisie Tlcom.................... 60
IV.5.1 Paramtres de dimensionnement .....................................................60
IV.5.1.1 Les paramtres gnraux de dimensionnement .................................... 60
IV.5.1.2 Modle de trafic ...................................................................................... 61
IV.5.1.3 Rpartition des abonns par services..................................................... 61
IV.6 Rsultats du dimensionnement ........................................... 62
ix
IV.7 Liste de recommandations................................................... 64
IV.8 Conclusion............................................................................ 65
Conclusion gnrale........................................................... 66
Bibliographie
Glossaire
x
LISTE DES FIGURES
Figure I.1 - Architecture en couche du rseau NGN............................................................... 5
Figure I.2 - Architecture en couche de lÌMS ....................................................................... 10
FigureI.3 - Inter fonctionnement entre RTC et IMS.............................................................. 14
Figure II.1 - Interface du rseau Intelligent...........................17
Figure II.2 - Relation entre entits fonctionnelles ................................................................. 20
Figure II.3 - Modle conceptuel du rseau intelligent ........................................................... 21
Figure II.4 - Architecture du Rseau Intelligent.................................................................... 22
Figure II.5 - Architecture de la plateforme IN NGN............................................................. 25
Figure II.6 - Dtail de l'interface OSA/Parlay....................................................................... 26
Figure II.7 - Architecture de la fonction CAMEL................................................................. 30
Figure II.8 - Architecture du protocole SIP .......................................................................... 32
Figure III.1 - Objectif de la migration vers les services IMS................................................. 34
Figure III.2 - Plate-forme de service de rseau PSTN........................................................... 35
Figure III.3 - Plate-forme de services GSM.......................................................................... 35
Figure III.4 - Stratgie de TT de migration vers une plate-forme de services IMS.........36
Figure III.5 - Evolution du rseau GSM vers le rseau de concept NGN...........37
Figure III.6 - Interconnexion du rseau PSTN avec le rseau NGN...................................... 38
Figure III.7 - Ralisation du premier scnario ...................................................................... 39
Figure III.8 - Ralisation du deuxime scnario ................................................................... 39
Figure III.9 - Premire tape de la premire phase................................................................ 40
Figure III.10 - Evolution du PR............................................................................................ 40
Figure III.11 - Etape 1: Migration vers le rseau NGN.....................41
Figure III.12 - Convergence des bases de donnes fixe-mobile............................................. 42
Figure III.13 - Etape 2: Evolution graduelle vers IMS......................43
Figure III.14 - Deuxime tape de la premire phase.....................44
Figure III.15 -Convergence de couche contrle.................................................................... 44
Figure III.16 - Migration du Softswitch................................................................................ 45
Figure III.17 - Intgration du SCP dans un serveur dàpplication ......................................... 45
Figure III.18 - Rseau IMS disposant de la totalit de services ..................46
Figure III.19 - PhaseII de la stratgie de migration............................................................... 47
Figure IV.1 - Rpartition des services .................................................................................. 53
Figure IV.2 - Les trafics a travers MGCF............................................................................. 54
Figure IV.3 - Les trafics travers CSCF .............................................................................. 55
Figure IV.4 - Diagramme de concept de l'outil de dimensionnement ...............57
Figure IV.5 - Fentre de choix de lèntit dimensionner .................................................... 58
Figure IV.6 - Fentre de dimensionnement de MGCF ...................... 58
Figure IV.7 - Fentre de dimensionnement de CSCF ...................... 59
Figure IV.8 - Fentre de dimensionnement des serveurs dàpplication ................................. 60
Figure IV.9 - Rsultat de dimensionnement de MGCF......................................................... 63
Figure IV.10 - Rsultat de dimensionnement du CSCF ........................................................ 63
xi
LISTE DES TABLEAUX
Tableau IV.1 - Tableau des diffrents classes de qualit de service ...................................... 50
Tableau IV.2 - Modle de trafic ........................................................................................... 61
Tableau IV.3- Services du rseau intelligent ........................................................................ 61
Tableau IV.4 - Les future Services de Tunisie Tlcom....................................................... 62
Tableau IV.5 - Rsultats de dimensionnement des serveurs dàpplication ............................ 64
Int r oduct ion Gnr al e
Pr oj et de Fin dEt ude Ben Ammar Raj aa- 2006 1
Introduction Gnrale
Dans certaines parties du monde, le trafic de donnes prend rapidement le pas sur le
trafic vocal et la tendance est nettement làugmentation de la bande passante pour les
donnes, tandis que pour la voix, la bande passante est de 64 kbit/s, voire dùne moindre
peut suffire.
Les oprateurs possdant les deux types de rseaux (rseau voix et rseau de donnes)
utilisent cet argument pour commencer les unifier.
Pour les oprateurs, làccs et le transport ne sont plus assez lucratifs et, pour rester
comptitif, il leur faudra donc offrir aux usagers toute une gamme de services utiles, faciles
utiliser et rmunrateurs. Par consquent, les NGN seront axs sur les services, et
fourniront tous les moyens ncessaires pour en offrir de nouveaux et adapter les existants
pour augmenter les recettes.
L'IMS IP Multimedia Subsytem- galement dsign sous le vocable de NGN
Multimedia est une nouvelle architecture base sur de nouveaux concepts, de nouvelles
technologies, de nouveaux partenaires et un nouvel cosystme. LÌMS supporte sur un
rseau tout IP les sessions applicatives temps rels (voix, vido, confrence,.) et non
temps rel (Push To Talk, Prsence, messagerie instantane,.) et intgre de plus le concept
de convergence de services supports indiffremment par des rseaux de natures
diffrentes : fixe, mobile ou Internet.
L`volution du rseau intelligent vers les nouvelles gnrations de rseaux NGN relve
des concepts dj existants dans le rseau intelligent, tels que l'environnement de cration de
service mais aussi de nouveaux concepts, le concept IMS , la convergence fixe/mobile et
lìntroduction des nouveaux protocoles.
Cèst dans ce contexte que dcline lòbjectif de notre projet de fin d`tude, propos dans
le cadre dùne collaboration entre l`cole suprieure des communications de Tunis
(Sup`Com) et lòprateur Tunisie Tlcom pour lìmplantation dùne plate-forme de service
dans un concept IMS et lòffre dùne solution de dimensionnement des entits
fonctionnelles de la couche application du rseau IMS.
Int r oduct ion Gnr al e
Il sàgit dans ce projet, de faire tout dàbord une tude des principes sur lesquels sont
bass les NGN et IMS. Ensuite, de prsenter la plate forme IN dans le cadre des volutions
des rseaux NGN vers un nouveau concept IMS en dcrivant les diffrents protocoles mis
en jeu.
Nous proposons par la suite une stratgie de migration de la plate-forme de service
existante de lòprateur Tunisie Tlcom vers une plate-forme de service IMS pour finir par
offrir un outil de dimensionnement des entits de cette plate-forme
Le prsent rapport est organis en quatre chapitres :
- Le premier chapitre trace, en premier lieu les principales caractristiques des rseaux
NGN. En deuxime lieu il est consacr pour l`tude du rseau IMS en tant quùn
rseau NGN volu. Nous nous somme efforc de dcrire les entits fonctionnelles
et les protocoles mis en jeu.
- Le deuxime chapitre est scind en deux parties : la premire donne un aperu sur le
modle conceptuel du rseau intelligent tandis que dans la deuxime partie, nous
avons prsent làrchitecture de la nouvelle plate-forme IN en dcrivons les
protocoles mis en jeu.
- Le troisime chapitre traitera la stratgie de migration de la plate-forme de service
existante de lòprateur Tunisie Tlcom vers une plate-forme de service dans un
concept IMS.
- Le quatrime chapitre est consacr essentiellement pour dtailler le processus du
dimensionnement des entits du plate-forme de services propose aprs avoir
modliser le trafic du rseau puisque nous ne pouvons pas dimensionner des entits
sans caractriser le trafic gnrer par les abonnes.
Chapit r e I
CHAPITRE I
Les rseaux de nouvelle
gnration
I.1 Introduction
Vu que notre projet a pour objectif d`tudier et de dimensionner une plate forme de
services selon le concept IMS (Rseau intelligent de la nouvelle gnration), il est
primordial de commencer par prsenter le concept NGN et le NGN multimdia appel
encore IMS (IP-Multimedia Subsystem). Donc, nous prsentons, dans ce chapitre une
description dtaille de làrchitecture en couche du NGN, les entits fonctionnelles et leurs
rles ainsi que la famille de protocole du NGN.
La deuxime partie de ce chapitre est consacre pour la prsentation de lÌMS en tant
quùn rseau NGN volu et cèst le rseau qui nous intresse dans notre projet.
I.2 Dfinition et description dun rseau NGN
Tout dàbord, rappelons que làcronyme NGN (Next Generation Network) est un terme
gnrique qui englobe diffrentes technologies visant mettre en place un concept, celui
dùn rseau convergent multiservices.
I.2.1 Modle darchitecture en couche
Le passage une architecture de type NGN est notamment caractris par la sparation
des fonctions de commutation physique et de contrle dàppel.
Làrchitecture NGN introduit un modle en couches, qui scinde les fonctions et quipements
responsables du transport du trafic et du contrle. Il est possible de dfinir un modle
architectural bas sur cinq couches successives (cf. Figure I.1) :
- La couche daccs, qui regroupe les fonctions et quipements permettant de grer
làccs des quipements utilisateurs au rseau, selon la technologie dàccs
(tlphonie commute, DSL, cble). Cette couche inclut par exemple les
quipements DSLAM fournissant làccs DSL.
Chapit r e I
- La couche de transport, qui est responsable de làcheminement du trafic voix ou
donnes dans le cour de rseau, selon le protocole utilis.
L`quipement important ce niveau dans une architecture NGN est le MGW (Media
GateWay) responsable de làdaptation des protocoles de transport aux diffrents
types de rseaux physiques disponibles (RTC, IP, ATM, .).
- La couche de contrle, qui gre lènsemble des fonctions de contrle des services
en gnral, et de contrle dàppel en particulier pour le service voix.
L`quipement important ce niveau dans une architecture NGN est le serveur
dàppel, plus communment appel softswitch , qui fournit, dans le cas de
services vocaux, l`quivalent de la fonction de commutation dans un rseau NGN
[1].
- La couche dexcution des services, qui regroupe lènsemble des fonctions
permettant la fourniture de services dans un rseau NGN.
En termes d`quipements, Cette couche regroupe deux types d`quipements : les
serveurs dàpplication (ou application servers) et les enablers , qui sont des
fonctionnalits, comme la gestion de lìnformation de prsence de lùtilisateur,
susceptibles d`tre utilises par plusieurs applications.
- La couche application, pour les diffrents services et applications susceptibles
d`tre offerts dans une architecture NGN. Il peut naturellement sàgir de services IP,
mais les oprateurs sàttacheront aussi supporter les services vocaux existants de
rseau intelligent (renvoi dàppel, etc.) dans le cadre dùne migration vers une
architecture NGN. Cette couche applications regroupe aussi lènvironnement de
cration de services, qui peut tre ouvert des fournisseurs de services tiers. Le
dveloppement dàpplications sàppuie sur les serveurs dàpplication de la couche
dèxcution des services.
Ces couches sont indpendantes et communiquent entre elles via des interfaces
ouvertes. Cette structure en couches permet de garantir une meilleure flexibilit et une
implmentation de nouveaux services plus efficaces.
La mise en place dìnterfaces ouvertes facilite lìntgration de nouveaux services
dvelopps sur un rseau dòprateur mais peut aussi sàvrer essentielle pour assurer
lìnterconnexion dùn rseau NGN avec dàutres rseaux quìls soient NGN ou
traditionnels.
Chapit r e I
Figure I.1 - Architecture en couche du rseau NGN
I.2.2 Rle des entits fonctionnelles de larchitecture NGN
I.2.2.1 Rle dun softswitch dans une architecture NGN
Dans une infrastructure NGN, un softswitch est un serveur informatique, dot d'un
logiciel de traitement des appels vocaux [2]. Le trafic voix est en gnral paquetis par le
media gateway, et pris en charge par les routeurs de paquets du rseau de lòprateur. Un
softswitch va identifier les paquets voix, analyser leur contenu pour dtecter le numro vers
lequel ils sont destins, confronter ces numros avec une table de routage (qui indique ce
que le softswitch doit faire en fonction de chaque numro), puis excuter une tche (par
exemple transmettre ou terminer).
I.2.2.2 Rle des media gateways dans une architecture NGN
Les media gateway constituent le deuxime lment essentiel dploy dans un rseau
NGN. Un media gateway peut 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, pour que ce trafic puisse ensuite tre gr
par le rseau NGN.
Chapit r e I
I.2.2.3 La Signalling Gateway (SG)
La fonction Signalling Gateway est la conversion de la signalisation change entre le
rseau de transport et le rseau externe interconnect selon un format comprhensible par
les quipements chargs de la traiter, mais sans en faire l'interprtation. Elle assure
notamment, làdaptation de la signalisation par rapport au protocole de transport utilis
(exemple : adaptation TDM/IP).
I.2.3 Les familles de protocoles dun rseau NGN
Le fait dùtiliser un rseau paquet pour transporter des flux multimdias, ayant des
contraintes temps rel , a ncessit làdaptation 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 nòffraient pas de services permettant la gestion des appels et des
communications multimdia.
Cette volution a logiquement gnr de nouveaux protocoles, principalement
concernant la gestion des flux multimdias, au sein de la couche contrle. Nous les
classerons en trois grandes familles : les protocoles de contrle dàppel qui regroupent
essentiellement H.323 et SIP, les protocoles de commande de Media Gateway constitus par
MEGACO (MEdia GAteway COntroller) et MGCP (Media Gateway Control Protocol) et
les protocoles de signalisation entre MGC : BICC, SIP-T, SIGTRAN.
I.2.3.1 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 de lÌETF et MEGACO ou
H.248, dvelopps conjointement par lÙIT et lÌETF, prdominent actuellement [3]. Ces
protocoles reprsentent 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 les MG par le MGC ;
- La remonte par les MG des rponses aux actions demandes par le MGC ;
- La notification par le MG d`vnements survenus au niveau mdia (dtection DTMF
par exemple) ;
Chapit r e I
- Le contrle du lien MG-MGC (scurit du lien, basculement vers un autre MGC ou
MG) ;
I.2.3.2 Les protocoles de signalisation entre les Softswitchs
Lìnterconnexion des rseaux de donnes avec les rseaux existants TDM utilisant la
signalisation SS7, a ncessit le dveloppement de protocoles ddis lìnterconnexion des
rseaux et au transport de la signalisation SS7 sur des rseaux en mode paquet.
Ces protocoles permettant 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 cour de rseau ;
- SIGTRAN (SIGnalling TRANsport), lìnterconnexion avec les rseaux de
signalisation SS7, gnralement via des passerelles de signalisation ou Signalling.
I.2.3.3 Les protocoles de contrle dappel
Ils permettent l`tablissement, dùne communication entre deux terminaux ou entre un
terminal et un serveur ; les deux principaux protocoles concurrents sont H.323, norme de
lÙIT et SIP, standard dvelopp lÌETF. tudions leurs spcifications respectives:
I.2.3.3.1 H.323
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 dùn service de communication
multimdia sur des rseaux de donnes sont :
- Les terminaux H.323 qui sont des systmes multimdia (tlphone, PC) permettant
de communiquer en temps rel ;
- Le Gatekeeper qui gre les terminaux H.323 (identification et traduction dàdresses)
et les tablissements dàppels ;
- La passerelle H.323 ou Gateway H.323 qui permet dìnterfacer le rseau IP avec le
rseau tlphonique classique.
Lùnit de contrle MCU (Multipoint Contrler Unit) qui gre les connexions
multipoints (Exemple : appels de confrence. Il se dcompose en un MC (Multipoint
Contrler), affect la signalisation, et un MP (Multipoint Processo ), ddi la
transmission proprement [4].
Chapit r e I
I.2.3.3.2 SIP
Le protocole SIP (Session Initiation Protocol) de lÌETF, est un protocole de
signalisation pour l`tablissement dàppels 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.
I.3 Relations entre NGN et IP Multimedia Subsystem (IMS)
Dfinie dans la spcification 3GPP Release 5 de l'UMTS, làrchitecture IMS 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 applicatrices tlcoms grs par des serveurs
oprs par lòprateur ou des fournisseurs tiers.
IMS introduit de nouvelles fonctions logiques devant tre intgres au cour de rseau de
lòprateur mobile. Parmi toutes ces nouvelles fonctions, le CSCF fait plus particulirement
le lien avec làpproche NGN puisquìl est responsable du contrle des sessions grce
lùtilisation du protocole SIP (dfini par lÌETF). La notion de commutation disparat au
profit de la notion de sessions tablies avec des serveurs d'applications multiples, un peu
l'image des serveurs softswitchs qui grent la tlphonie sur IP dans les rseaux NGN.
I.4 IP Multimedia Subsystem (IMS)
Lìntroduction de lÌMS (IP Multimedia Subsystem) dans les rseaux fixe et mobile
reprsente un changement fondamental dans les rseaux de tlcommunication de type voix.
Les nouvelles capacits des rseaux et des terminaux, le mariage entre lÌnternet 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 [5].
Dans cet objectif, lÌMS est conu pour offrir aux utilisateurs la possibilit d`tablir des
sessions multimdia en utilisant tout accs haut dbit et une commutation de paquets IP.
LÌMS fournit un rseau IP multiservice, multi-accs, scuris et fiable :
- Multiservices : tout type de services dlivrs par un rseau cour supportant
- Diffrents niveaux de QoS pourront tre offerts lùsager,
Chapit r e I
- Multi-accs: Tout rseau dàccs large bande, fixe et mobile pourra sìnterfacer
lÌMS.
LÌMS nèst pas un unique rseau, mais diffrents rseaux qui inter oprent grce des
accords de roaming IMS fixe-fixe, fixe-mobile, mobile-mobiles LÌMS permet dòffrir :
Des services de communication non-temps-reel, pseudo temps-rel et temps rel
suivant une configuration client-server ou entre entits paires.
La mobilit des services / Mobilit de lùsager (Nomadisme).
Plusieurs sessions et services simultanment sur la mme connexion rseau.
I.4.1 Structuration en couches de lIMS
Làrchitecture IMS peut tre structure en couches [6]. Quatre couches importantes sont
identifies :
- La couche Accs peut reprsenter tout accs haut dbit tel que : UTRAN (UMTS
Terrestrial Radio Access Network), CDMA2000 (technologie dàccs large bande
utilise dans les rseaux mobiles aux Etats-Unis), xDSL, rseau cble, Wireless IP,
WiFi, etc..
- La couche Transport reprsente un rseau IP ou driv. Ce rseau IP pourra
intgrer des mcanismes de QoS avec MPLS, Diffserv, RSVP, etc. La couche
transport consiste donc en des commutateurs / routeurs relis par un rseau de
transmission.
Diffrentes piles 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 lìnvocation des services. Ces nouds
sàppellent 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. Lòprateur peut se positionner grce sa couche contrle en
tant quàgrgatif de services offerts par lòprateur lui-mme ou par des tiers. La
couche application consiste en des serveurs dàpplication (AS, Application Server)
et serveurs de mdia IP (IP MS, IP Media Server). LÌP Media Server est aussi
appel MRF(Multimedia Resource Function).
Chapit r e I
Le domaine IMS doit inter fonctionner avec le RTCP/GSM afin de permettre aux
utilisateurs IMS d'tablir des appels avec le RTCP/GSM.
La figure I.2 illustre une reprsentation de làrchitecture en couche du rseau IMS.
Figure I.2 - Architecture en couche de lIMS
I.4.2 Entits de Rseau IMS
I.4.2.1 Terminal IMS
Il sàgit dùne application sur un quipement de lùsager qui met et reoit des requtes
SIP. Il se matrialise par un logiciel install sur un PC, sur un tlphone IP ou sur une
station mobile UMTS (UE, User Equipment).
I.4.2.2 Home Subscriber Server (HSS)
Lèntit 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 lùsager, les informations dènregistrement, les paramtres dàccs et les
informations permettant lìnvocation des services de lùsager. Lèntit HSS interagit avec
les entits du rseau travers le protocole Diameter.
I.4.2.3 Call State Control Function (CSCF)
Le contrle d'appel initi par un terminal IMS doit tre pris en charge dans le rseau
nominal (rseau auquel lùsager 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
Chapit r e I
des problmes dìnteraction 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 l'change
de messages de signalisation SIP.
Les fonctions ralises par l'entit P-CSCF comprennent :
L'acheminement de la mthode SIP REGISTER mise par le terminal l'entit I-
CSCF partir du nom du domaine nominal.
L'acheminement des mthodes SIP mises par le terminal au S-CSCF dont le nom
a t obtenu dans la rponse la procdure d'enregistrement.
Le routage des mthodes SIP ou rponses SIP au terminal.
La gnration de CDRs (Call Detailed Record).
La compression / dcompression des messages SIP.
L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un rseau d'oprateur
pour toutes les sessions destines un utilisateur de cet oprateur. Il peut exister plusieurs
ICSCF 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 peut 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.
Chapit r e I
La gnration de CDRs.
Avant de pouvoir utiliser les services du domaine IM, tels qu'tablir une session
multimdia ou recevoir une demande de session, un usager doit s'enregistrer au rseau. Que
l'usager soit dans son rseau nominal ou dans un rseau visit, cette procdure fait intervenir
un PCSCF.
Par ailleurs, tous les messages de signalisation mis par le terminal ou destination du
terminal sont relays par le P-CSCF ; le terminal n'a jamais la connaissance des adresses des
autres CSCFs (i.e., I-CSCF et S-CSCF).
I.4.2.4 MGCF, IMS-MGW et T-SGW : Inter fonctionnement avec le RTC
Le domaine IMS doit inter fonctionner avec le RTCP afin de permettre aux utilisateurs
IMS d'tablir des appels avec le RTCP. L'architecture d'inter fonctionnement prsente un
plan de contrle (signalisation) et un plan d'usager (transport). Dans le plan usager, des
passerelles
(IMS-MGW, IMS - Media Gateway) sont requises afin de convertir des flux RTP en flux
TDM.
Ces passerelles ne traitent que le mdia. Des entits sont responsables de crer,
maintenir et librer des connexions dans ces passerelles; il s'agit de contrleurs de
passerelles (MGCF, Media Gateway Control Function). Par ailleurs, ce mme MGC
termine la signalisation ISUP du ct RTC qu'il convertit en signalisation SIP qui est
dlivre au domaine IMS. Les messages ISUP provenant du RTC sont d'abord achemins
sur SS7 une passerelle de signalisation (T-SGW, Trunking Signaling Gateway) qui les
relaye au MGC sur un transport SIGTRAN.
L'interfonctionnement entre le domaine IMS et le RTCP est donc assur par trois entits:
L'IMS-MGW (IP Multimedia Subsystem Media Gateway Function), MGCF (Media
Gateway Control Function) et T-SGW (Trunking Signaling Gateway Function).
I.4.2.4.1 L'IMS-MGW
Reoit un trafic de parole du RTCP et l'achemine sur un rseau IP. Le trafic audio est
transport sur RTP/UDP/IP :
Supporte gnralement des fonctions de conversion du mdia et de traitement du
mdia (annulation d'cho, pont de confrence).
Est contrl par le MGCF travers le protocole MEGACO/H.248.
Chapit r e I
I.4.2.4.2 Le MGCF
Comme les entits CSCF, n'appartient qu'au plan de contrle et non au plan mdia.
Contrle l'IMS-MGW afin d'tablir, maintenir et librer des connexions dans l'IMS-
MGW.
Une connexion correspond par exemple une association entre une terminaison TDM
(terminaison du ct RTC) et une terminaison RTP/UDP/IP. Un transcodage de la parole
doit aussi avoir lieu au niveau de l'lMS-MGW pour convertir la parole reue et qui est
encode l'aide du codec G.711, en parole encode en utilisant le codec AMR (UMTS) si le
terminal IMS est un mobile UMTS.
Assure la conversion des messages ISUP (Signalisation RTC) en des messages SIP
(Signalisation IMS).
Slectionne le CSCF appropri afin de remettre la signalisation SIP qu'il gnre, au
sous-systme IMS.
I.4.2.4.3 Le T-SGW
Assure la conversion du transport pour l'acheminement de la signalisation ISUP entre le
commutateur tlphonique et le MGCF. La signalisation ISUP est change :
Sur SS7 entre le commutateur et le T-SGW
Sur SIGTRAN entre le T-SGW et le MGCF
Par contre, n'analyse pas les messages d'application ISUP.
La figure I.3 reprsente un appel initi par le RTCP et destination d'un terminal dans le
sous-systme IMS.
Le commutateur du RTC rserve un circuit de parole qu'il partage avec l'IMS-MGW et
met un message ISUP IAM sur un transport SS7 au T-SGW.
Le TSGW est responsable de la conversion du transport du message ISUP. Ce message
est relay l'entit MGCF sur SIGTRAN.
Le MGCF cre un contexte dans l'entit IMS-MGW en utilisant le protocole
MEGACO/H.248. Ce contexte consiste en une association entre une terminaison TDM et
une terminaison
RTP. La terminaison TDM termine le circuit de parole que l'IMS-MGW partage avec le
commutateur tlphonique. La terminaison RTP termine les canaux RTP entre l'IMS-MGW
et le terminal IMS.
L'IMS-MGW retourne une rponse l'entit MGCF ; cette rponse contient un "local
Chapit r e I
descriptor" qui correspond la description SDP associe sa terminaison RTP.
L'entit MGCF gnre une mthode SIP INVITE contenant la description SDP retourne
par l'IMS-MGW. Cette mthode est envoye au sous-systme IMS qui se charge de la
dlivrer au terminal IMS appel.
FigureI.3 - Inter fonctionnement entre RTC et IMS
I.4.3 Les Impacts de lIMS
Le principal avantage que doit amener IMS aux oprateurs rside dans sa capacit de
facilitation dìmplmentation et de lancement de nouveaux services. Sans IMS, la mise en
oeuvre dùn nouveau service implique de lourdes contraintes pour un oprateur sur son
systme et son rseau : dveloppement et intgration de nouvelles interfaces rseaux, de
nouvelles applications, de nouvelles interfaces de facturation, . Autant d`cueils que
devrait permettre d`viter IMS grce son architecture et lùtilisation dìnterfaces ouvertes
standardises.
A cela sàjoute les nouvelles capacits lies lùsage du protocole SIP permettant
lòprateur 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.
Aujourd`hui, 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 :
- Services de messagerie instantane.
- Services d`changes de contenus (messages, audio, vido).
Chapit r e I
- 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.
I.5 Conclusion
Dans ce chapitre, nous avons trac les principales caractristiques du rseau NGN en
terme de protocole, et services. Pour offrir ces services, nous sommes appels dcrire le
processus d`volution des rseaux NGN vers un concept IMS.
Afin de mettre en ouvre une plate-forme de services intelligents dans les rseaux NGN
conformment au concept IMS, des volutions des protocoles de services du rseau
intelligent sont prvues par les normes.
L'objectif du chapitre suivant est justement l`tude dùne plate forme de services
intelligents.
Chapit r e II
CHAPITRE II
Etude dune plate-forme IN
de la nouvelle gnration ( IN NGN)
II.1 Introduction
Le Rseau Intelligent (RI) est un concept architectural de rseau qui vise faciliter
l'introduction rapide des services de tlcommunication [7]. Jusqu'ici, les normalisations et
les activits de recherches sur le RI ne concernent que ses spcifications fonctionnelles et sa
ralisation.
Dans ce chapitre on va prsenter le concept de rseau intelligent selon làrchitecture
dfinie par lÌTU-T.
Nous dterminons tout dàbord dans le paragraphe II.2 lòbjectif du concept du rseau
intelligent puis, nous dcrivons dans le paragraphe suivant le modle conceptuel de IN, ainsi
que son architecture. Dans le paragraphe II.5, nous tudierons l`volution du rseau
intelligent et de la gestion de service. Pour finir par prsenter les protocoles INAP, CAMEL
et SIP respectivement dans les paragraphe II.7, II.8 et II.9.
II.2 Objectif du concept du Rseau intelligent
L'introduction du concept RI a pour but de marquer la distinction entre l'aspect logiciel
(les services) et l'aspect matriel (les ressources manipules) d'un rseau de
tlcommunication.
Cette distinction permet ainsi de supporter l'introduction rapide de nouveaux services de
tlcommunication sans modifier l'architecture physique existante. Le concept peut tre
appliqu divers types de rseau de tlcommunication, comprenant: le rseau tlphonique
public commut (RTPC), le rseau public de donnes commutation de paquets (RPDCP),
les rseaux mobiles et les rseaux numriques intgration de services bande troite et
large bande (RNIS-BE et RNIS-LB).
Le RI comporte deux types dìnterface, parfois appeles interface A et interface B.
Chapit r e II
Le premier type dìnterface (interface A) concerne des interfaces de programmation, qui
permettent au rseau de devenir une sorte de plate-forme indpendante des services. Il est
alors possible dìntroduire des services plus rapidement sans devoir modifier cette plate-
forme. Le deuxime type dìnterface concerne des interfaces de commande de ressources
(interface B), qui permettent de contrler les ressources physiques de systmes des divers
fournisseurs [8].
La figure II.1 reprsente les deux types des interfaces de rseau intelligent.
Figure II.1 - Interfaces du rseau Intelligent
II.3 Le modle conceptuel du rseau intelligent
En vue de dcrire les diffrents lments du rseau intelligent, lÌTU-T a introduit un
modle conceptuel qui doit servir de cadre la spcification et la description de cette
architecture.
La figure II.3 dcrit les quatre plans du modle conceptuel du rseau intelligent (INCM,
Intelligent Network Conceptual Model). Chacun de ces plans correspond une abstraction
diffrente du rseau. Ce modle ne doit pas tre considr en soi comme une architecture. Il
sàgit dùn guide de rfrence conceptuel pour des concepteurs.
II.3.1 Le plan service (SP, Service Plane)
Il dcrit une vue qui ne prend en compte que les services. Un service est une offre
commerciale mise disposition par un fournisseur de service (qui peut tre un oprateur)
pour des abonns pour satisfaire un besoin de tlcommunication.
Le service est dcrit en langage naturel. Un service consiste en un ou plusieurs lments
de service (SF, Service Feature) ; Un lment de service tant la plus petite unit utilise
ce niveau. Un lment de service est un composant de service correspondant une partie du
service ou au service lui-mme. Cela signifie quùn lment de service peut lui-mme tre
un service, c'est--dire correspondre une offre commerciale. Gnralement, un lment de
Chapit r e II
service est indpendant dùn service donn. Cela est le cas par exemple des lments de
services pour authentification ou mise en file dàttente qui peuvent tre rutiliss
pour la cration de nombreux services RI.
II.3.2 Le plan fonctionnel global (GFP, Global Functional Plan)
Il modlise un rseau intelligent comme une seule entit. Cette entit est capable
dèffectuer un certain nombre de fonctions reprsentes par des blocs de construction
indpendants des services (SIB, Service Independent Building Block).
Un SIB est une capacit normalise rutilisable, dfinie indpendamment des services et
de la technologie. Un possde une entre logique, une ou plusieurs sorties logiques, et
requiert deux types de donnes :
- Les "donnes de soutien du service" : (SSD, Service Support Data) constitues de
donnes fixes, statiques, propres au service, elles permettent la configuration du SIB
(ex : le type de tarification appliquer).
- Les donnes d'instance d'appel : (CID, Call Instance Data) caractrisent chaque
appel au service et voluent dynamiquement (exp : le n de la ligne appelante).
Un SIB particulier reprsente la fonctionnalit du traitement dàppel (BCP, Basic Call
Process). Cèst partir de ce SIB que le service est gnralement initi.
Un service correspond dans le GFP un chanage de SIBs. Ce chanage commence un
endroit prcis dans le traitement dàppel. Ce point de dpart est appel point dìnitiation
(POI, Point Of Initiation). Dans lèxemple du service numro vert, le POI correspond la
dtection du prfixe 0800 .
Aprs excution de la squence de SIBs, le contrle est nouveau pass au BCP. Le
point dans le traitement dàppel o celui-ci reprend le contrle est appel point de retour
(POR, Point Of Return).
Une chane de SIBs pour un service donn, associ aux points d'initiation et de retour,
constitue une logique globale de service (GSL, Global Service Logic). En terme de
Chapit r e II
programmation, une logique globale de service est assimilable un script. Le GFP est pris
en charge par le concepteur de service.
II.3.3 Le plan fonctionnel rparti (DFP, Distributed Functional Plane)
Il modlise le rseau intelligent comme un ensemble dèntits fonctionnelles rparties
qui excutent des actions (FEA, Functional Entity Action). Une entit fonctionnelle (FE,
Functional Entity) peut tre assimile un objet de traitement.
Un SIB est matrialis dans le DFP par une squence dàctions FEAs excutes dans les
FEs. Certaines de ces actions FEAs peuvent induire des flux dìnformation (IF, Information
Flow) entre FEs.
Dfinition des entits fonctionnelles
Est considr comme une entit fonctionnelle un ensemble de un ensemble de fonctions
ralisant un service; Lòrganisation excutoire des entits fonctionnelles est ralise par des
flux dìnformations (Information Flow) dont la smantique est commune toutes les entits.
Les entits fonctionnelles principales sont :
- CCAF (Call Control Agent Function): fournit un accs au rseau l'utilisateur et
gre lìnterface entre lùtilisateur et le rseau;
- CCF (Call Control Function): se chargent des traitements d'appel et de connexion
(Commutateur standard);
- SCF (Service Control Function): assure le droulement conforme du module CFF;
- SSF (Service Switching Function): sert d'interface entre le SCF et le CCF.
- Permet au CCF d'tre pilot par le SCF. CCF et SSF sont insparables; un lment
de rseau possdant la fonction SSF doit possder la fonction CCF. C'est la raison
pour laquelle on retrouve frquemment la dnomination SSF/CCF;
- SRF (Specialized Resource Function): fournit des ressources spcifiques qui
peuvent tre utilises par d'autres entits du rseau.
La figure II.2 illustre la relation entre les diffrentes entits fonctionnelles de rseau
intelligent.
Chapit r e II
Figure II.2 - Relation entre entits fonctionnelles
II.3.4 Le plan physique (PP, Physical Plane)
Il modlise les aspects physiques du rseau intelligent. Il identifie les diffrentes entits
physiques (PE, Physical Entity) et protocoles qui existent dans le rseau intelligent rel. Il
spcifie par ailleurs les entits fonctionnelles implantes dans les diffrentes entits
physiques. Cette implantation doit respecter la rgle qu'une entit fonctionnelle ne peut tre
rpartie sur plusieurs entits physiques. Elle peut par contre tre duplique dans diffrentes
entits physiques [9].
Les flux dìnformation (IF) du DFP correspondent habituellement des protocoles
dàpplication. Dans le plan physique, on leur assigne la pile de protocoles sur laquelle ils
vont fonctionner.
Le plan physique est pris en charge par les quipementiers et les oprateurs de rseau.
II.3.5 Relation entre plans
Les lments de services (SF) dfinis dans le plan service (SP) sont traduits en logique
globale de service (GSL) dans le plan fonctionnel global (GFP). Une GSL est un
regroupement dùn POI, dùn chanage de SIBs et dùn POR. Un SIB du GFP est ralis
dans le plan fonctionnel rparti (DFP) par une squence dàctions dèntits fonctionnelles
(FEAs) excutes dans les entits fonctionnelles (FEs).
Chapit r e II
Les FEs sont traduits en entits physiques (PE) dans le plan physique Des
regroupements de FEs peuvent sòprer avant translation vers un PE donn. La figure ci
dessous rcapitule le modle conceptuel du rseau intelligent.
Figure II.3 - Modle conceptuel du rseau intelligent
II.4 Architecture du rseau intelligent
Cèst au niveau du plan physique du rseau intelligent que lìmplantation des entits
fonctionnelles est dcrite dans les entits physiques. Cette implantation doit respecter la
rgle quùne entit fonctionnelle ne peut tre rpartie sur plusieurs entits physiques. Elle
peut par contre tre duplique dans diffrentes entits physiques. Une entit physique, quant
elle, peut contenir plusieurs entits fonctionnelles, sous rserve quèlles soient de type
diffrent. Ainsi partir de làrchitecture fonctionnelle et en fonction des choix
dìmplantation, plusieurs schmas dàrchitectures physiques peuvent tre obtenus [10]. La
figureII.4 nèst donc quùn exemple dàrchitecture physique, qui reprsente les entits
physiques suivantes :
- Le point commutation de service (SSP, Service Switching Point) est un commutateur
de rseau intelligent, cèst dire quìl implante au minimum les entits SSF et CCF.
Si cèst un commutateur de rattachement des abonnes et non un commutateur de
transit, alors il implantera galement lèntit CCAF. Le SSP, outre sa fonction de
Chapit r e II
transport classique tout commutateur, est responsable de la dtection des appels
contenant une demande de service de rseau intelligent et de dclenchement du dit
service. Il est tlcommandable par le SCP.
- Le point commande de service (SCP, Service Control Point) est un serveur
responsable du traitement des services de rseau intelligent. Cèst une machine
temps rel trs haute disponibilit, qui accde des donnes et tlcommande les
SSPs. Le SCP est reli au SSPs via le rseau smaphore. Il implante lèntit SCF et
optionnellement lèntit SDF.
- Le point de gestion de service (SMP, Service Management Point) est responsable de
la gestion de service et des SCPs associs. Les fonctions ralises par le SMP sont
par exemple, la gestion de base de donnes, la surveillance et le test de rseau, ou
encore la gestion de trafic rseau. Le SMP implante lèntit SMF et optionnellement
les entits SMFA et SCEF. Il peut accder toutes les autres entits physiques.
- Le point dènvironnement de cration de service (SCEP, Service Creation
Environment Point ) est utilis pour dfinir, dvelopper, tester un service et lìnclure
au SMP. Il implante lèntit SCEF.
Figure II.4 - Architecture du Rseau Intelligent
II.5 Exemples de services
Indpendamment du rseau de transport, la plate-forme IN fournit les fonctionnalits
ncessaires au dploiement de nouveaux services dùne manire rapide et rentable : cration
Chapit r e II
des services, excution des services et gestion des services. LÌN offre une gamme de plus
en plus large de services axs sur les usagers. Cette plate forme inclue la tlphonie sur IP,
la visiophone, le Triple Play (service qui associe tlphonie, Internet et vido), le VPN,
etc.
II.5.1 Service de tlphone gratuit
Ce service permet aux utilisateurs dàppeler gratuitement làbonn au service par le
rseau de tlphone. Les appels sont facturs aux abonns au service.
Ce service utilise une base de donne stocke dans le point de commande service (SCP).
Cette base de donne va permettre de dterminer les diffrents paramtres pour le traitement
dùn appel. Cela permet un appel dirig vers un abonn au service d`tre achemin vers
diffrentes destinations dpendant de diverses conditions, telles que la situation
gographique de làppelant, l`heure et le jour de làppel.
II.5.2 La carte Prpaye (PPC)
Ce service permet un usager dùtiliser une carte prpaye avec un certain montant de
crdit pour l`tablissement de ses communications. Aprs lùtilisation du crdit ou aprs
expiration la carte devient inutilisable. Lùsager numrote un numro qui lui permet d`tre
pris en compte par le service. Choisi sa langue de dialogue puis sìdentifier par son numro
de carte.
II.5.3 Service du Rseau Priv Virtuel (VPN)
Le service VPN (Virtual Private Network) offre des rseaux publics conus pour tre
complts par des quipements et des installations de rseaux privs dèntreprise. Un VPN
est un service organis autour dùn rseau public permettant dìnterconnecter des sites de
lèntreprise (rgionaux, nationaux). Le service utilise le rseau public commut pour offrir
les fonctionnalits et les capacits dùn rseau priv telles que le Plan de Numrotation
Priv, Accs priv, Sites multiples et contrle du client sur làdministration rseau.
II.6 Evolution du Rseau Intelligent et de la gestion de service
La fourniture de services de tlcommunications l'usager, que ce soit des services de
type traditionnel comme des facilits de communication ou des services plus labors tels
que ceux offerts par Internet, ncessite d'avoir, au niveau des infrastructures de
tlcommunications, les moyens de mettre en ouvre, contrler et facturer les services, et
Chapit r e II
ceci dans un environnement htrogne, aussi bien en ce qui concerne les fournisseurs, que
les technologies et les modes de commercialisation.
Il faut pour cela tre capable de dfinir les architectures rseaux, processus, des objets
gnriques composant du service, et interfaces supportant les fonctions suivantes :
- Conception d'objets destins la conception modulaire des services,
- Outils de convergence du RI fixe et mobile, le choix de solutions techniques
diffrentes freine le dveloppement de services de convergence fixe mobile ,
- Prise en compte des ordres de service manant des systmes de gestion commerciale,
- Mise en ouvre des ressources ncessaires pour fournir le service,
- Supervision et contrle du service,
- Elaboration des lments de taxation.
Dans un contexte htrogne de fournisseurs et de technologies de communication, ces
fonctions doivent pouvoir tre mises en ouvre travers toute la chane de fourniture du
service, afin de matriser aussi bien la vision " grossiste " des fournisseurs d'lments de
service que la vision de bout en bout ncessaire au fournisseur du service complet, de type
dtaillant. Les problmatiques qui en dcoulent sont entre autres :
- Rseau smaphore n7 versus IP.
- Dveloppement de TINA C.
- Architectures de commande des rseaux.
- Performances.
- Utilisation de middleware (Corba, JavaBeans, COM/DCOM,...).
II.6.1 Architecture de la plate-forme IN NGN
Classiquement on a une plate forme IN par type de rseau. Dans le cadre du rseau
NGN, une solution complte t propose, axe sur les services, pour la cration, le
contrle et la gestion de services dÌN sur les rseaux fixes, mobiles et de donnes.
La figure II.5 illustre làrchitecture fonctionnelle du rseau intelligent dans un concept
NGN.
Chapit r e II
Figure II.5 - Architecture de la plateforme IN NGN
Actuellement, les services de rseaux intelligents ne sont pas limits au RTCP fixe.
Avec lèssor des rseaux radio, lÌN a progressivement pris en charge une large gamme de
services mobiles et de convergence fixe-mobile (FMC). Cet essor aboutira naturellement
des services de convergence fixe-mobile-donnes.
Cas des rseaux mobiles sàppuyant sur le protocole CAMEL et les rseaux fixes
sàppuyant sur le protocole INAP. Son expansion dans lùnivers du protocole Internet (IP)
amne lÌN adopter des protocoles IP, tels que le protocole dàpplication sans fil (WAP) et
offrir des services dans les environnements H.323 et SIP (Session Initiation Protocol).
II.6.2 Les plates-formes Unifier de service et interfaces ouvertes
Les rseaux de nouvelle gnration sont reprsents 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 existent deux types dàrchitectures pour les plate-formes de convergence et dàccs
aux services qui sont :
- Làrchitecture du modle OSA/Parlay.
- Làrchitecture de services SIP.
II.6.2.1 Architecture du modle OSA/PARLAY
Le modle OSA/PARLAY repose sur une architecture permettant aux applications de
services d'utiliser les ressources du rseau telles que le contrle d'appel, la gestion de
confrence, les informations de localisation.
Chapit r e II
Concrtement, l'interface standardise OSA/PARLAY:
- Est le lien des plates-formes de services avec la couche contrle pour la signalisation
(et avec la couche transport pour le trafic) et facilite l'accs au rseau pour les
applications de services.
- Offre des outils ncessaires au bon fonctionnement des services, tels que la gestion
de la scurit (authentification, autorisation), des utilisateurs (profil, tat) et le
contrle d'appel.
La 'passerelle OSA/Parlay se compose de diffrentes fonctions comme l'indiquent la
figure II.6
Figure II.6 - Dtail de l'interface OSA/Parlay
a) Le Framework: responsable du contrle d'accs aux services et de la gestion des
ressources attribues ces services. Il est indispensable au bon fonctionnement des services
car il gre:
les fonctions d'authentification des applications pour accder au rseau.
les fonctions d'autorisation pour les applications utiliser certains SCF (Service
Capability Features) et donnes clients, et, pour les clients, utiliser une
application (vrification d'inscription).
les fonctions de dcouverte des SCF, permettant aux applications d'obtenir des
informations sur les SCF accessibles.
la gestion d'tablissement de services pour les applications qui doivent accepter
'en ligne le contrat d'offre de services.
la gestion de l'intgrit des services: gestion de la qualit du service rendu.
la gestion de l'enregistrement des SCF.
b) Les SCS (Service Capability Servers): qui fournissent l'interface vers les applications.
Chapit r e II
II.6.2.2 Architecture de service SIP
Làrchitecture de service SIP de base est constitue de serveurs dàpplication, de serveurs
de mdia et de S-CSCF.
Le serveur d'application SIP excute des services (exp, Push To Talk, Prsence, Prpaid,
Instant messaging, etc.) et peuvent influencer le droulement de la session la demande du
service. Le serveur dàpplication correspond au SCP du Rseau Intelligent.
Le serveur de mdia SIP (appel dans les recommandations le MRF pour Multimedia
Resource Function) tablit des confrences multimdias, joue des annonces vocales ou
multimdia et collecte des informations utilisateur. Il sàgit de l`volution de lèntit SRP
(Specialized Resource Point) dans le monde multimdia.
Le serveur dàppel SIP (Proxy server) joue le rle de point depuis lequel un service peut
tre invoqu. Il dispose du profil de service de làbonn qui lui indique les services souscrits
par làbonn et sous quelle condition invoquer ces services. Il correspond au SSP de
làrchitecture Rseau Intelligent.
II.6.2.3 Mises en uvre des services
Làpproche dìntroduction du service dpend du type de service et de sa complexit.
Ainsi un service peut tre mis en ouvre sur le terminal SIP, le serveur de mdia SIP, le
serveur dàpplication ou le Proxy Server.
Certains services requirent des interactions complexes avec lùsager (exp, messagerie
unifie, IVR, etc.). Pour ces services vocaux une approche centralise est ncessaire avec les
entits AS SIP contenant la logique dàpplication et serveur de mdia SIP contenant le script
vocal.
Certains services requirent une base de donnes centralise. Pour ces services de
traduction de numro (service de numro abrg, service prpaid, service VPN), un AS SIP
contenant la logique dàpplication est ncessaire.
Certains services de routage flexible ncessitent un script personnalis par abonn. Le
langage CPL (Call Processing Language) peut tre utilis pour ce faire. Il est possible de
faire excuter ce script par un AS SIP ou par le proxy server.
Certains services ne se prtent pas bien un traitement centralis. L'apparition de
terminaux SIP reposant sur une machine Java a offert la possibilit de dvelopper des
services sur les terminaux :
Chapit r e II
- Le service sonnerie diffrentie permet de modifier la sonnerie du poste appel en
fonction de l'identit de l'appelant. Ce service basique est typiquement un service
qu'il faut dployer sur le poste.
- Le service filtrage d'appel est une variante du service prcdent dans laquelle
l'identit de l'appel sert dterminer si l'appel doit tre accept, renvoy ou refus.
- Le service annuaire montre l'intrt d'une connexion directe du terminal avec un
annuaire d'entreprise : il permet l'utilisateur de consulter un annuaire LDAP depuis
le tlphone, de slectionner un numro parmi les rsultats et de lancer un appel vers
ce numro.
II.7 INAP
II.7.1 Ensemble de capacits
Le dveloppement des recommandations du rseau intelligent est structur en plusieurs
phases, de faon prendre en compte les services et technologies existants et future. Chaque
phase correspond un ensemble de capacits (CS ; Capability Set).
Le CS-1, premier ensemble de capacits, concerne les services un seul utilisateur qui
sont activs un seul point et offre des possibilits trs limites pour la mobilit (une
interaction avec lùtilisateur ne peut avoir lieu que durant làppel). Les spcifications CS-1
font l`hypothse que le rseau est contrl par un seul oprateur et ne permette lìnter
fonctionnement de rseau.
Làrchitecture RI CS-1 ne peut tre dploy que sur le RTCP.
La premire volution est introduite par le CS-2. Cet ensemble contient les capacits
dfinies dans CS-1 en introduisant en plus des services de tlcommunication, des services
de gestion et des services de cration. Le CS-2 est applicable aux rseaux RTC, RNIS et
mobile, permet lìnter fonctionnement entre rseaux intelligent et lìnteraction avec
lùtilisateur hors du contexte dùn appel. Dans CS-3, il yà pris en charge du RNIS-LB et de
la portabilit des numros. Il permet une interaction entre lments de service. Le CS-4 fait
lòbjet de la convergence IN/Internet pour la migration des fonctionnalits IN vers le monde
IP.
II.7.2 Architecture du protocole INAP
La recommandation Q.1218 spcifie le protocole dàpplication de rseau intelligent
Chapit r e II
(INAP; Intelligent Network Application Protocol) utilis afin de prendre en charge
lènsemble des capacits CS-1. Ce protocole supporte les interactions entre les quatre entits
fonctionnelles SSF, SCF, SRF et SDF.
INAP utilise le protocole de signalisation SS7. En effet, les messages INAP sont
encapsuls dans des messages du protocole TCAP (Transaction Capabilities Application
Part) [Q771]. Ce dernier est structur selon les principes de la couche application OSI et
inclut notamment le protocole ROSE (Remote Operations Service Element) comme un des
lments dàpplications.
Làrchitecture du protocole INAP, se dcrit de la faon suivante :
Une entit physique peut avoir une interaction unique ou des interactions multiples
coordonnes avec dàutres entits physiques. Dans le cas dìnteraction unique, une fonction
de contrle dàssociation unique (SACF ; Single Association Control Function) coordonne
lùtilisation de lènsemble des ASEs. Dans le cas dìnteractions multiples coordonnes, une
fonction de contrle dàssociation multiple (MACF ; Multiple Association Control
Function) assure la fonction de coordination de plusieurs objets dàssociation unique (SAO ;
Single Association Objects). Un SAO est un ensemble dÀSEs avec leur SACF. Ainsi
TCAP est un ASE dùn SAO. TCAP utilise les services sans connexion du sous-systme de
connexion de signalisation (SCCP ; Signaling Connection Control Part).
II.8 CAMEL
Lòbjet de CAMEL, est de permettre un usager dàccder aux services spcifiques
offerts par son oprateur mme lorsquìl est accueilli sur un rseau tiers.
Le service CAMEL, accessible travers le protocole CAP (CAMEL Application Part), a
pour objet de spcifier une architecture et des mcanismes entirement bass sur les IN.
Dans le cadre de CAMEL, le SCP est appel CSE (CAMEL Service Environment). Il
peut y avoir plusieurs CSE dans le rseau. Chaque abonn qui a accs un service
spcifique dispose, dans son profil, dùn CSI (CAMEL Subscription Information), qui
identifie le service ainsi que làppellation globale du CSE concern. Il peut y avoir un CSI
pour làppel dpart et un autre CSI pour làppel arrive [11].
II.8.1 CAMEL phase1
CAMEL phase1 part les fonctions dcrites au dessus, il permet de lever pour les
services spcifiques oprateurs les problmes dìnter fonctionnement entre rseaux mobiles.
Les mcanismes rseau CAMEL phase 1 portent sur :
Chapit r e II
- Le traitement des appels dpart ( lèxclusion des appels dùrgence GSM) ;
- Le traitement des appels arrivs ;
- Le traitement des appels renvoys ;
- Lìnterrogation tout moment du HLR du rseau nominal ;
La mise en ouvre de CAMEL phase 1 repose sur un principe fondateur, lèxtermination
de la commande du traitement dàppel des commutateurs mobiles, permettant
d`homogniser les services spcifiques oprateur offerts aux abonns mobiles, notamment
lorsque ceux-ci se retrouvent en situation de roaming international. Cèst pour raliser cela
quùn serveur CAMEL (CAMEL SERVer ; CSERV ou gsmSCF) a t dfini.
Figure II.7 - Architecture de la fonction CAMEL
Le serveur CAMEL interagit avec la fonction commutateur dàccs aux services GSM
(gsmSSF) en utilisant le jeu dìnstructions dfini par le protocole CAP.
II.8.2 CAMEL phase2
La phase 2 de CAMEL, constitue une extension de CAMEL phase 1. Cette tape prvoit,
entre autres :
- Introduction et commande dùn priphrique intelligent ;
- De rajouter de nouveaux point de dclenchement (DP) ;
- Dìntroduire des critres de dclenchement conditionnels, pour ne faire appel au
serveur CAMEL que si certaines squences de numro sont composes;
- Contrle de taxation.
Chapit r e II
II.8.3 CAMEL phase3
CAMEL phase 3, intgr lÙMTS, constitue une extension de la phase 2. La partie voix
est sensiblement la mme. La partie donne sàppuie sur la notion de session qui se
modlise par 2 modles d`tat sur lesquels sont dvelopps les mcanismes RI :
- Le modle d`tat GPRS attach/detach,
- Le modle d`tat des contextes PDP individuels.
Lìntroduction de lÌMS dans le rseau NGN, la gestion des sessions multimdia, aussi
bien des confrences que des appels tlphoniques sur des rseaux mode paquets fait
apparatre un nouveau protocole nomm SIP ddi ces tches.
II.9 SIP
Le protocole d'initiation de session (SIP) est un protocole de signalisation appartenant
la couche application du modle OSI. Son rle est d'ouvrir, modifier et librer les sessions
ou appels ouverts entre un ou plusieurs utilisateurs. L'ouverture de ces sessions permet de
raliser de l'audio ou vidoconfrence, de l'enseignement distance, de la voix et de la
diffusion multimdia sur IP essentiellement. Pour ouvrir une session, l'utilisateur met une
invitation transportant un descripteur de session permettant aux utilisateurs souhaitant
communiquer de s'accorder sur la compatibilit de leur mdia. Ainsi SIP peut relier des
stations mobiles en transmettant ou redirigeant les requtes vers la position courante de la
station appele.
SIP possde l'avantage de ne pas tre attach un mdium particulier et est sens tre
indpendant du protocole de transport des couches basses. De plus il peut tre tendu et
s'adapter aux volutions futures.
II.9.1 Architecture du protocole SIP
Le protocole est bti sur une architecture Client/Serveur et utilise des messages textuels.
Les messages sont transports par les protocoles de transport rseaux TCP ou UDP. Le
message possde un en-tte et un corps. L'en-tte dfinit les paramtres ncessaires au
routage du message et l'tablissement de la session. Le corps dfinit les caractristiques de
la session l'aide d'un protocole de description de session. Les parties tablissement de
session et description de session sont spares (mais cooprent).
La figure II.7 illustre l'architecture du protocole SIP[12].
Chapit r e II
Figure II.8 - Architecture du protocole SIP
- RSVP: rservation des ressources rseaux,
- RTP (Real-time Transfert Protocol) : transport des informations en temps rel,
- RTCP (Real-Time Control Protocol) : assure le contrle de flux de donnes
multimdia,
- SDP (Session Description Protocol) : dcrit les sessions multimdia.
II.10 Conclusion
Dans ce chapitre nous avons tudi làrchitecture de la plate forme IN de la nouvelle
gnration. Nous avons, de plus, prsent ses services et ses protocoles (cas des rseaux
fixes sàppuyant sur le protocole INAP et les rseaux mobiles sàppuyant sur le protocole
CAP issu des spcifications CAMEL). Dans cette plate forme, le protocole SIP est mis en
vidence pour les services multimdias du rseau intelligent.
De mme, nous avons essay de donner les caractristiques des protocoles INAP,
CAMEL et SIP.
Chapit r e III
CHAPITRE III
Stratgie de migration de la plate-
forme de services existante de
TUNISIE TLCOM vers une plate-
forme de concept IMS
III.1 Introduction
Nous nous intressons dans ce chapitre l`volution de la plate-forme existante de
services vers une plate-forme convergente de services IMS
Le prsent chapitre sera structur comme suit : nous tudions ,tout dàbord, dans le
paragraphe III.2 lòbjectif de la migration vers une plate-forme de services IMS puis, nous
prsenterons dans le paragraphe III.3 notre stratgie de migration de services du rseau
Tunisie Tlcom que nous avons propos .
III.2 Objectifs de Tunisie Tlcom
La migration vers un rseau IMS apparat aujourd`hui comme un processus invitable du
fait de la convergence voix / donnes / images dùn ct et fixe / mobile dùn autre ct.
Aujourd`hui, Tunisie Tlcom opte vers une migration de son rseau classique vers un
rseau multiservices de nouvelle gnration. Elle souhaite assurer une migration de son
rseau vers la nouvelle gnration, tout en protgeant son investissement en lui permettant
une exploitation optimale des ressources et ce par làllocation dynamique de la bande
passante par le biais de la technologie de commutation des paquets.
La figure III.1 rcapitule les objectifs de la migration des services classiques vers les
services IMS que lòprateur Tunisie Tlcom dsire làtteindre.
Chapit r e III
Figure III.1 - Objectif de la migration vers les services IMS
III.3 Intgration dune plate-forme IN/IMS dans
environnement existant de loprateur Tunisie Tlcom
L`volution des applications pour fournir de nouveaux services de donnes et de
multimdia est considre comme un objectif absolu pour permettre lòprateur Tunisie
Tlcom, de gnrer des nouveaux revenu.
De ce fait, Tunisie Tlcom a toujours opt pour des choix stratgiques concernant la
modernisation de son rseau afin de permettre de le faire voluer rapidement vers le monde
de nouvelle gnration des tlcommunications et dànticiper les nouveaux besoins de ses
abonns tout en leur proposant les meilleurs services.
Nous allons, dans cette partie du projet, prsenter notre stratgie de migration qui a
comme objectif dòffrir une plate-forme de service sur laquelle les services de tlphonie
traditionnelle ainsi que les nouveaux services multimdia cohabitent.
Avant de dtailler cette stratgie il est utile dàvoir une ide sur le rseau actuel de
Tunisie Tlcom. Actuellement, les services sont ddis par type de rseau : services Rseau
Intelligent sur le rseau tlphonique pour les terminaux tlphoniques (fixes ou mobiles) et
services mail, web, news, sur les rseau IP. Lòprateur Tunisie Tlcom dispose de deux
rseaux : PSTN et GSM (voir figure III.2 et III.3) possdant chacun un rseau intelligent qui
Chapit r e III
se voulait un outil permettant une cration de services simple et une interoprabilit forte de
ces services entre rseaux.
Figure III.2 - Plate-forme de service de rseau PSTN
Figure III.3 - Plate-forme de services GSM
Notre stratgie de migration sèffectue en deux phases comme prsente lòrganigramme
suivant :
Chapit r e III
Figure III.4 - Stratgie de TT de migration vers une plate-forme de services IMS
III.3.1 Phase1 : Coexistence des rseaux existants avec le rseau NGN
Cette phase de la stratgie de migration vers une plate-forme de service IMS sèffectue
en deux tapes.
III.3.1.1 Etape1 : Migration vers le NGN
En parallle au dveloppement du rseau NGN, une volution vers NGN des rseaux
GSM et PSTN est ncessaire afin dàssurer la migration vers le NGN.
Dans une architecture NGN les applications et le rseau vont communiquer via des API.
Ainsi le dveloppement massif de nouvelles applications innovatrices est rendu possible
par la disponibilit de serveurs dàpplication et de terminaux multimdia ainsi que des outils
de dveloppement facile utiliser.
Chapit r e III
La ncessit dòffrir des services multi-rseaux et multi-terminaux est lòrigine du
dploiement de nouveaux protocoles et de nouvelles architectures qui feront le lien entre les
plates-formes de services et les utilisateurs connects aux rseaux NGN. Ces nouveaux
outils (architecture et protocoles) doivent tre utilisables dans des contextes trs divers et
seront donc des outils ouverts et convergents permettant de simplifier les communications
entre terminaux et entre terminaux et serveurs dàpplications.
Dans le cadre de l`volution du rseau GSM vers NGN, on opre de faon sparer les
deux plans : plan contrle et plan connectivit. Le MSC traditionnel serait clat en deux
entits : MSC Server (plan contrle) et MediaGateWay (MGW pour la connectivit) comme
montre la figure III.5
Figure III.5 - Evolution du rseau GSM vers le rseau de concept NGN
Dàutre part, pour assurer l`volution de rseau PSTN vers le concept NGN, on opre de
faon interconnecter le rseau existant avec le rseau NGN par lìmplmentation des
SG(Signalling Gateway) qui assure la conversion du transport pour làcheminement de la
signalisation ISUP entre les commutateurs tlphoniques et le softswitch.
Cette volution des rseaux existants doit garantir la cohabitation des services de la
tlphonie traditionnelle avec les nouveaux services de concept NGN. En tenant compte de
cette ncessit, nous allons, dans cette tape de la stratgie effectuer les interconnexions
suivantes :
CAMEL
Chapit r e III
- Interconnecter le Softswitch du rseau NGN avec le SCP du rseau PSTN par
lìntermdiaire du protocole INAP.
- Interconnecter le MSC server avec le SCP du rseau GSM par lìntermdiaire du
protocole CAMEL. Dans ce cadre le SCP du rseau GSM est appel CSE (CAMEL
Service Environnement).
Les figures III.6 reprsentent respectivement lìnterconnexion du rseau PSTN et le
rseau de concept NGN. L`volution du rseau GSM vers le concept NGN est dj prsent
par la figure III.5.
Figure III.6 - Interconnexion du rseau PSTN avec le rseau NGN
Cette interconnexion du SCP du rseau PSTN/GSM et le softswitch/MSC server peut se
faire selon deux scnarios :
Scnario 1
Dans ce scnario (voir figure III.7) on suppose la rutilisation de services IN existants
dans NGN par lìmplmentation des SSF dans le SS/MSC server. Dans ce cas les SS/MSC
server vont jouer le rle dùn SSP du rseau intelligent. On aura donc comme rsultat la
coexistence des services de rseaux classiques et les nouveaux services du rseau NGN
comme premire tape de l`volution vers les services IMS.
INAP
Chapit r e III
Figure III.7 - Ralisation du premier scnario
Scnario 2
Dans ce scnario un IVR est employ pour traiter le signal DTMF afin de fournir un
certain service intelligent dans PSTN/GSM. (cf. Figure III.8).
Figure III.8 - Ralisation du deuxime scnario
Dans notre stratgie, nous allons adopt le premier scnario parce que lìnfrastructure
existante de Tunisie Tlcom nèmploi pas un IVR.
Chapit r e III
Suite cette tape de la stratgie, le rseau de Tunisie Tlcom aura làrchitecture
prsente par la figure suivante.
Figure III.9 - Premire tape de la premire phase
En autre et toujours dans la premire tape de la stratgie et dans le cadre de l`volution
graduelle vers le rseau IMS, nous proposons dìntroduire une entit quivalente au HLR du
rseau mobile et au SDP du rseau fixe dans laquelle, les profits des utilisateurs fixes et
mobiles seront intgrs. Dans ce qui suit, nous allons nommer cette entit, Profiles Register
(PR) (cf. figure III.10).
Figure III.10 - Evolution du PR
Chapit r e III
Lòrganigramme prsent dans la figure III.11 rsume la premire tape de la stratgie de
migration vers une plate-forme de services IMS quàdoptera lòprateur Tunisie Tlcom
Figure III.11 - Etape 1 : Migration vers NGN
A lìssue de la premire tape de cette stratgie de migration vers les services de
concept IMS, Tunisie Tlcom va avoir une convergence des bases de donnes fixe et
mobile. En effet, lèntit PR regroupe aussi bien les profits des abonns du rseau fixe que
les profits les abonns du rseau mobiles.
La Figure III.12 illustre cette convergence des bases de donnes fixe-mobile.
Chapit r e III
Figure III.12 - Convergence des bases de donnes fixe-mobile
III.3.1.2 Etape2 : volution graduelle vers lIMS
Cette tape de la stratgie se manifeste par le dbut de lìntroduction de lÌMS ; deux
scnarios sont possibles :
- Scnario 1 : Commencer lìntroduction du concept IMS, par le rseau GSM.
- Scnario 2 : Commencer lìntroduction du concept IMS par le rseau PSTN.
Vue que lòprateur Tunisie Tlcom dtient monopole dans le domaine de la tlphonie
fixe et pour des raisons de concurrence nous allons adopter le premier scnario dans cette
tape.
Cette introduction du concept IMS dans le rseau GSM se traduit par :
- Evolution du PR vers un HSS
- Implmentation des entits de la couche contrle du concept IMS dans le rseau
GSM de lòprateur Tunisie Tlcom.
Afin dàssurer la cohabitation des services classiques et les nouveaux services, ces entits
implmentes seront interconnectes avec les entits existantes de la manire suivante :
- Interconnecter le MSC server avec le CSCF par lìntermdiaire du protocole SIP.
- Interconnecter le SCP du rseau GSM avec le MGCF par lìntermdiaire du
protocole CAMEL.
- Interconnecter le Softswitch du rseau PSTN avec le CSCF par lìntermdiaire du
protocole SIP.
- Interconnecter le SCP du rseau PSTN avec le MGCF par lìntermdiaire du
protocole INAP.
Chapit r e III
- Interconnecter le MGCF avec les SG par lìntermdiaire du protocole SIGTRAN.
Lòrganigramme prsent par la figure III.13 rsume la deuxime tape de la premire
phase de la stratgie de Tunisie Tlcom de migration vers une plate-forme de services IMS.
Figure III.13 - Etape2 : Evolution graduelle vers lIMS
La figure ci dessous prsente làrchitecture de rseau Tunisie Tlcom suite aux
modifications intgres dans la deuxime tape de la stratgie de migration.
Chapit r e III
Figure III.14 Deuxime tape de la premire phase
Procder la deuxime tape de la stratgie de migration, lòprateur Tunisie Tlcom
va avoir une convergence de la couche contrle, en effet, les mmes fonctionnalits de
contrle de service sont assures par diffrentes entits pour supporter aussi bien les
applications du rseau fixe que les applications du rseau GSM.
La figure III.15 illustre la convergence de couche contrle.
Figure III.15 -Convergence de couche contrle
Chapit r e III
III.3.2 Phase2 : Rseau IMS disposant de la totalit de service
Dans cette phase le rseau de Tunisie Tlcom arrive sa maturit suite une volution
du software du softswitch vers des entits fonctionnelles IMS. On parle, dans ce cas, dùne
migration du softswitch vers les entits IMS (voir figure III.16).
Figure III.16 - Migration du Softswitch
Aprs avoir implmenter le SSF du rseau IN dans la couche contrle, le point de
commande de service (SCP) sera intgr au serveur d'application et devient une partie du
serveur d'application. Ainsi, les services cres par l'environnement de cration de service
(SCE) peuvent tre directement chargs au module de SCP du serveur de nouvelle
application. La figure III.17 reprsente lìntgration du SCP du rseau intelligent dans un
serveur dàpplication.
Figure III.17 - Intgration du SCP dans un serveur dapplication
Chapit r e III
Tous les services valeur ajoute seront, fournis par des serveurs dàpplication et
lòprateur arrive donc raliser son objectif dàvoir un seul rseau disposant de la totalit
des services.
Lòrganigramme dans la figure III.18 dcrit la deuxime phase de notre stratgie de
migration vers une plate-forme de services du concept IMS.
Figure III.18 - Phase II : Rseau IMS disposant de la totalit de services
Cette migration vers un rseau de concept IMS permet Tunisie Tlcom de ragir
envers la croissance continu de la demande de service multimdia pour les rseaux mobiles
dùne part et faire face la concurrence dàutre part.
La figure III.19 rcapitule les tapes de la deuxime phase de la stratgie de migration
vers les services IMS quàdoptera lòprateur Tunisie Tlcom.
Chapit r e III
Figure III.19 - PhaseII de la stratgie de migration
III.4 Conclusion
Au cours de ce chapitre, on a dtaill la stratgie quòn a propos pour assurer la
migration de la plate-forme existante de services Tunisie Tlcom vers une plate-forme de
service IMS.
Dans la suite de ce rapport, nous essayerons de prsenter les rsultats de
dimensionnement des entits de la plate-forme de services IMS quòn a propos pour
lòprateur Tunisie Tlcom tout en proposant un outil de dimensionnement.
Chapit r e IV
CHAPITRE IV
Analyse de trafic et dimensionnement
des entits de la plate-forme de services
IMS
IV.1 Introduction
Aprs la prsentation de la stratgie de migration des services courant de Tunisie
Tlcom vers une plate-forme de services IMS, nous allons dimensionner les entits
fonctionnelles de cette plate-forme.
La premire partie de ce chapitre sera consacre la prsentation des diffrents modles
de trafic, vue quòn ne peut pas dimensionner ces derniers sans connatre le trafic du rseau
dàccs.
L`tape de dimensionnement est une tape trs importante puisquèlle nous permet
d`valuer le cot de lìnfrastructure dployer, de ce fait on va sìntresser dans la
deuxime partie de ce chapitre au dimensionnement des diffrentes entits de la plate-forme
des services du rseau IMS dvelopper. Puis, dans la troisime partie de ce chapitre nous
prsenterons un outil de dimensionnement de ces entits quòn làppliquera pour l`tude de
cas de Tunisie Tlcom. A la lumire des rsultats obtenus, nous proposons une liste de
recommandations prendre en considration lors de la mise en place de la nouvelle plate-
forme de services.
IV.2 Modle de trafic du rseau daccs
Le dimensionnement du rseau cour ncessite l`tude et l`valuation du trafic du rseau
dàccs. Afin dàccomplir cette phase, il faut dfinir un modle pour chaque classe de
service.
Dans ce qui suit, nous allons dfinir un modle de trafic pour chaque classe qui serait
utilise pour le dimensionnement, vue que les modles traditionnels ne sont plus valables.
IV.2.1 Les diffrentes classes de qualit de service
La QoS est gnralement assimile la discrimination des services, autrement dit la
dfinition de classes diffrencis de services. Le groupe 3GPP prvoit diffrents services
Chapit r e IV
dans les futurs systmes de troisime gnration susceptibles d`tre classs suivant quatre
catgories prsents dans le tableau IV.1 et qui sont : la classe Conversationnelle, la classe
Streaming, la classe Interactive et la classe Background. La diffrence entre ces classes de
services vient de la sensibilit de chacune par rapport au dlai : la classe conversationnelle
englobe les applications trs sensibles au dlai tandis que la classe Background englobe les
applications les moins sensibles au dlai. Ainsi les classes conversationnelles et Streaming
regroupent les applications avec des contraintes temps rel, la diffrence entre ces deux
classes vient uniquement de leur degr de sensibilit au dlai.
Les classes interactives et Background regroupent les applications traditionnelles de
lÌnternet comme la navigation sur le Web, le courrier lectronique, le transfert de fichiers.
Ces applications sont beaucoup moins sensibles au dlai que les classes conversationnelles
et Streaming mais sont en revanche beaucoup plus sensibles aux erreurs de transfert. La
principale diffrence entre les classes interactive et Background est que les applications de
type interactif sont des applications qui ncessitent une interaction, comme le cas du
courrier lectronique interactif ou de la navigation interactive sur lÌnternet, tandis que les
applications de Background sont des applications comme le tlchargement de courriers ou
le tlchargement de fichiers [13].
IV.2.1.1 La classe conversationnelle (conversational)
Les applications de cette classe ncessitent un service bidirectionnel en temps rel
impliquant deux utilisateurs humains ou plus. Les contraintes dpendent donc de la
perception humaine : la limite sur le dlai maximum tolr est une limite stricte car toute
dgradation sur le dlai induirait une perte de qualit notable dans la perception humaine du
signal. Les exemples de ce type dàpplications sont la tlphonie, la vidophonie, la voix sur
IP, les jeux interactifs.
IV.2.1.2 La classe Streaming
Les applications de cette classe impliquent un utilisateur humain et un serveur de
donnes.
Ce sont des applications temps rel asymtriques o les donnes sont transfres du rseau
vers les mobiles. Le manque dìnteractivit entre lùtilisateur et la source de donnes
autorise des dlais un peu plus importants que dans les cas des applications de type
conversationnel, et ce sans perturber la QoS. Les exemples dàpplications de type Streaming
Chapit r e IV
sont les nouvelles applications issues de lÌnternet, telles que les applications audio ou vido
sur demande.
IV.2.1.3 La classe Interactive
Les applications de cette classe impliquent un utilisateur (machine ou humain) dialoguant
avec un serveur de donnes ou dàpplications. Contrairement aux deux classes prcdentes,
les performances temps rel ne sont pas ncessaires, il sàgit seulement dàttendre un certain
temps pour rpondre aux requtes. Par contre les informations ne doivent pas tre altres.
Les exemples dàpplications de type interactif sont la navigation sur lÌnternet, làccs aux
bases de donnes ainsi quàux serveurs dàpplications.
IV.2.1.4 La classe background
Les applications de cette classe impliquent un utilisateur, le plus souvent un quipement
terminal, ralisant lènvoi et la rception de donnes en tache de fond. Làbsence
dìnteractivit pour ces applications fait que lùtilisateur lòrigine de la requte nèst pas
en attente dùne rponse dans une limite de temps fixe. Ce sont donc les applications les
moins sensibles au dlai, mais sont trs sensibles aux erreurs sur lìnformation transfres.
Les exemples dàpplications sont le mail, le transfert de messages courts (SMS pour Short
Messages Services), le tlchargement de donnes ou de fichiers.
Le tableau IV.1 illustre les diffrents classes de qualit de services.
Service Dlai
Exemple
application
Dbit
Tolrance des
erreurs
Visiophonie 32-384 kbps oui
Conversationnel
<< 1s
Jeux interactifs 1 kbps non
Audio haute qualit 32-128 kbps oui
Streaming
< 10s
Images fixes Non garantie non
Interactif Environ 1s
Commerce
lectronique,
Navigation sur Internet
Non garantie non
Fax Non garantie oui
Back ground
> 10s
E-mail(avec
acquittement)
Non garantie non
Tableau IV.1 - Tableau des diffrents classes de qualit de service
Chapit r e IV
IV.2.2 Modle de trafic de la classe conversationnelle
Le service de base de cette classe est la tlphonie. Le processus de poisson permet de
modliser cette classe. Le comportement de làbonn de ce service suit la loi markovienne
de type ON-OFF. Les caractristiques de ce modle sont :
- Occurrence des appels tlphoniques est modlise par un processus de poisson avec
un taux moyen dàppel 0.8 appels/heure.On rappelle que la loi de poisson de
paramtre est une variable alatoire discrte X valeurs positives dfinie par ses
probabilits d`tat :
[ ]
! n
n X P
n
= = pour n=0,1,2,. (IV.1)

- Un processus exponentiel caractrise la dure dùn appel de moyenne typique u tels
que 1/u=150s.Une variable alatoire "X" qui suit une loi exponentielle est dfinie comme
suit:
e
x

; si 0 x
e
x

1 ; si 0 x
;
= ) (x F
0 ; si non 0 ; si non
(IV.2)
O f(x) et F(x) sont respectivement la densit de probabilit et la fonction de rpartition de
la variable "X" qui suit la loi exponentielle. \i est la valeur moyenne.
- La rpartition des priodes dàctivit et de silence suit chacune une distribution
exponentielle avec un taux dàctivit de source de 0.5.
IV.2.3 Modle de trafic de la classe Streaming
On va considrer le modle relatif au tlchargement dùne squence vido. Or le flux
vido correspond une srie de trames de donnes ayant mme dure (25 trames par
secondes). Les caractristiques du modle sont :
- Occurrence des sessions 0.17 appels/heure.
- Dure dùne session 120 s.
- Taux dàctivit de source 0.58
IV.2.4 Modle de trafic de la classe Interactive
Le service de base de cette classe est la navigation sur le Web. On dcompose le flux de
donnes en un ensemble de sessions. Pour chaque session, lùtilisateur consulte plusieurs
pages HTML. Le tlchargement de ses pages correspond la transmission de plusieurs
= ) (x f
Chapit r e IV
datagrammes de taille variable. Un temps de lecture est ncessaire avant de tlcharger les
pages suivantes.
Les caractristiques du modle sont :
- Occurrence de sessions est un processus de poisson de valeur typique 0.17
appels/heure pour chaque session.
- Le nombre dàppels de pages HTML suit une distribution gomtrique de moyenne
5 appels/session. Une loi gomtrique est dfinie comme suit:
( ) p
x
p

1
; si { } ,... 1 , 0 x
( ) p
x
1
1
1
; si
0 x
( )= x p
;
( )= x F
0 ; si non 0 ; si non
p
p
=
1
;
p
p
2
2 1
=
; avec ( ) 1 , 0 p (IV.3)
O F(x) est la fonction de distribution et p(x) est la fonction de masse, et o
2
sont
respectivement la moyenne et la variance.
- Le temps de lecture suit une distribution exponentielle de moyenne tels que 1/ =
4 12s.
- Le nombre de datagrammes par appel suit une distribution gomtrique de moyenne
typique 10 datagrammes/appel.
- La dure dìnter arrive de datagrammes suit une distribution exponentielle dont la
valeur moyenne varie en fonction du dbit.
- La taille de datagrammes suit une distribution de Pareto. Une variable alatoire "X"
qui suit une loi de Pareto normale est dfinie de la manire suivante :
( ) ;
1
x
k
f
x
X +
k x
( )= x
F X ( )
x
k

1
; k x
1
k
; >1
( )( ) 1 2
2
2

k
; >2 (IV.4)
Chapit r e IV
O Fx et fx reprsentent respectivement la fonction de rpartition et la densit de
probabilit de la variable alatoire qui suit la loi de Pareto normale, u est le facteur de Fano.
et o
2
reprsentent respectivement la moyenne et la variance de la distribution de Pareto. k
reprsente la valeur minimale de la variable "X".
IV.2.5 Modle de trafic de la classe Background
Les services de cette classe sont insensibles au dlai, ils sont considrs de type Best
Effort. Ils sont transmis en dehors des priodes charges du rseau coeur, cèst--dire au
cours des priodes dìnactivits des autres classes de services. Dùne autre manire, ces
services ne contribuent pas la charge du rseau.
IV.3 Dimensionnement des entits du plate-forme de services
IMS
Dans ce qui suit, on va sìntresser au dimensionnement des diffrents entits suivantes :
- La couche contrle : MGCF et le CSCF.
- La couche application : les serveurs dàpplication.
Pour pouvoir dimensionner les entits de la couche application, il faut repartir les
services, selon leurs besoins en bande passante, en services bande troite et services large
bande comme montre la figure IV.1.
Figure IV.1 - Rpartition des services
Les services large bande englobent des services gourmands en bande passante tel que les
services de classe Streaming et dont le trafic sont supports par les entits CSCF de la
couche contrle.
Chapit r e IV
Les services bande troite sont notamment les services du rseau intelligent dont le
trafic est vhicul par le MGCF et le MCS server, dans notre cas nous allons considrer
uniquement le MGCF.
IV.3.1 Dimensionnement MGCF
Le MGCF est une passerelle (Gateway) qui assure les communications entre lÌMS et les
usagers du domaine circuit (CS), dans notre cas les usagers de la tlphonie classique fixe
(POTS ; Plain Old Telephone Service) et GSM. Tout trafic de signalisation (contrle
dàppel ou session) gnr par les utilisateurs du domaine circuit vers lÌMS passe par le
MGCF. Dàutre part le MGCF joue le rle dùn SSP qui assure le routage vers les services
bande troite, gnralement les services du rseau intelligent.
Figure IV.2 - Les trafics a travers MGCF
Dimensionner cet quipement, qui reprsente la couche contrle, revient dterminer la
capacit de traitement de son processeur, cèst dire dterminer le nombre des appels traits
par seconde (cps : call per second) ou par heure ( BHCA : Beasy Hour Call Attemps). Pour
valuer cette capacit, il faut calculer le nombre de communications vhiculer.
= ) ( _ _ _ cps MGCF traitement de Capacit
}
{

IN Service POTS GSM
I MHT
I SMT I R SAU I Nbre Sub
_ , , I
_
_ _ _ _ _
(IV.5)
Pour pouvoir dterminer la capacit de traitement par heur, on applique la formule (IV.6)
MGCF/ SSP
Trafic entrant de
signalisation
(GSM/POTS)
Trafic entrant de
signalisation
Accs aux services du rseau intelligent
Chapit r e IV
= ) ( _ _ _ BHCA MGCF traitement de Capacit
3600 ) ( _ _ _ cps MGCF traitement de Capacit
(IV.6)
Avec :
- Sub_Nbr : Subscriber Number,
- SAU_R : Simultaneously Attached User Rate,
- SMT : Subscriber Mean Traffic ,
- MHT : Mean Time Hondling
IV.3.2 Dimensionnement du CSCF
Tout le trafic de signalisation SIP issue ou vers le mobile passe travers cet lment.
Cette entit assure donc le routage vers les services large bande (Broad Band Service ;
BBS), de plus le CSCF supporte le trafic interne, dfini comme tant le trafic paquet qui
englobe les communications UMTS/UMTS et EDGE/UMTS, cèst dire trafic interne
lÌMS, donc cèst un trafic support par les M-MGWs.
Il supporte aussi le trafic externe destin vers le monde circuit.
Figure IV.3 - Les trafics travers CSCF
Dimensionner les CSCF revient dterminer la capacit de traitement de son processeur,
ce ci dpend de divers paramtres dont certain sont dduit du modle de trafic que nous les
avons dtaill dans le paragraphe prcdent.
Ainsi la formule (IV.7) dtermine la capacit de traitement du CSCF en (cps)
CSCF
Trafic entrant de
signalisation
(Tout type de trafic
daccs)
Trafic entrant de
signalisation
Accs aux services large bande
Chapit r e IV
} {
+

=

POTS GSM I
I MHT
I SMT I R SAU I Nbr Sub
cps CSCF traitement de Capacit
,
_
_ _ _ _ _
) ( _ _ _
} {

BBS ASL UMTS EDGE J
J CR J R SAU J Nbr Sub
, , ,
3600
_ _ _ _ _
(IV.7)
IV.3.3 Dimensionnement des serveurs dapplication
Un serveur dàpplication fournit un environnement dèxcution pour des applications, il
accueille et excute les services.
Le dimensionnement dùn serveur dàpplication dpend du nombre dàbonns
simultanment attachs et le taux dàppels qui correspond au nombre dàppel par abonnes
par seconde. Ainsi la capacit de traitement dùn serveur dàpplication en (cps) est donne
par la formule (IV.8)
3600
_ _
) ( _ _ _
CR R SAU Nbr Sub
cps SA traitement de Capacit

=
3600
) ( _ _ _ BHCA SA traitement de Capacit
=
(IV.8)
IV.4 Spcification et prsentation de loutil IMS-
Plateforme_Entities-Dimensioning
Notre objectif, une fois on a dtailler les rgles de dimensionnement des entits des
couches application et contrle du rseau IMS, est la conception et la ralisation dùn outil
de dimensionnement. Nous avons opt pour JAVA comme un langage de programmation
.Ce choix est motiv par sa simplicit et sa souplesse de manipulation.
IV.4.1 La conception de loutil de dimensionnement
Dans la conception de cet outil, lùtilisateur contribue de manire flexible au choix des
paramtres dèntres ; ceci a pour objectif de les rapprocher de ses besoins et pouvoir ainsi
obtenir des rsultats appliqus directement au processus de dimensionnement.
La conception de lòutil de dimensionnement de la plate-forme de service IMS est
reprsent par une succession d`tapes, en effet, chaque entits dimensionner sera
modlis par une fentre dans laquelle lùtilisateur introduit ses donnes spcifiques.
Chapit r e IV
Les tapes de dimensionnement seront faciles mettre en ouvre ds la premire
utilisation de notre outil de dimensionnement que nous avons essay d`y maintenir un
couplage entre lèfficacit et la simplicit.
Lùtilisation sera donc guide ds le dbut de lùtilisation de lòutil jusqu' la fin et
lòbtention des rsultats.
Figure IV.4 - Diagramme de concept de loutil de dimensionnement
IV.4.2 Utilisation de loutil
Une fois lùtilisateur est en face de la fentre de choix des entits dimensionner telle
que celle prsente par la figure IV.5, il doit spcifier lèntit a dimensionner.
Lùtilisateurs a donc le choix entre trois entits : MGCF, CSCF ou les serveurs
dàpplication.
Chapit r e IV
Figure IV.5 - Fentre d choix de lentit dimensionner
Une fois on a dtermin lèntit, on passe la fixation des paramtres du
dimensionnement, lùtilisateur saisi le nombre des abonns, le taux de simultanit, le trafic
moyen par abonn et la dure moyenne par appel.
Figure IV.6 - Fentre de dimensionnement de MGCF
Chapit r e IV
Une fois ceci est fait, et en cliquant sur lùn des deux boutons cps capacity ou
BHCA capacity , les rsultats des calculs sàffichent.
La figureIV.7 reprsente lìnterface permettant le dimensionnement du CSCF, ainsi
lùtilisateur saisi les paramtres dèntr et pourra donc, dterminer la capacit de traitement
du CSCF.
Figure IV.7 Fentre de dimensionnement de CSCF
En cliquant sur le bouton SA de lìnterface de choix des entits, une autre interface de
forme tabbedPane , renfermant lènsemble des services dimensionner, apparat et aura
la forme prsente par la figureIV.8.
Chapit r e IV
Figure IV.8 - Fentre de dimensionnement des serveurs dapplication
Suite au choix du service que lùtilisateur dsire dimensionner son serveur
correspondant, il sera invit saisir les paramtres dèntrer.
Une fois, les paramtres sont saisis, il pourra dterminer la capacit de traitement.
IV.5 Etude de cas : dimensionnement des entits de la plate-
forme de services IMS de rseau Tunisie Tlcom
Aprs la prsentation et lìmplmentation de lòutil de dimensionnement, nous allons
lèxploiter pour dimensionner la future plat-forme de services de lòprateur Tunisie
Tlcom.
Lòprateur historique Tunisien, voulant introduire lÌMS tout en cherchant rentabiliser
cet investissement. Par ailleurs, une architecture qui offre de nouveaux services de donnes
et de multimdia est la cible de cet oprateur.
IV.5.1 Paramtres de dimensionnement
IV.5.1.1 Les paramtres gnraux de dimensionnement
Vue que Tunisie Tlcom a tendance tendre son rseau GSM, on a fix le nombre
dàbonns GSM 4 000 000 bien que le nombre actuel est dj infrieur. En effet, en
parallle au dploiement et lòffre des services multimdia, le nombre dàbonns utilisant
UMTS et EDGE augmentent. La cration de nouveaux services gnre une augmentation du
nombre des abonns UMTS. De plus, le dbit important offert par la technologie sans fils et
la mobilit attire de plus en plus des nouveaux abonns. Les paramtres suivant sont
utiliss :
- Un nombre dàbonns GSM : 3 128 000.
Chapit r e IV
- Un nombre dàbonns UMTS : 320 000.
- Un nombre dàbonns EDGE : 552 000.
En plus, du rseau GSM, Tunisie Tlcom dispose dùn rseau de tlphonie fixe classique
POTS et dùn rseau haut dbit ADSL. Nous allons utiliser les paramtres suivants pour le
dimensionnement :
- Un nombre dàbonns POTS : 2 500 000
- Un nombre dàbonns ADSL : 1 000 000
IV.5.1.2 Modle de trafic
Pour modliser le trafic durant la phase de lancement des services multimdia, on utilise
les paramtres du tableau IV.2.
Service
Conversationnel
Service
Streaming
Service
Interactif
Taux appel/H 0.7 0.2 0.75
Dure dappel(s) 150 120 6
Activit Source 0.5 0.58 0.48
Tableau IV.2 - Modle de trafic
IV.5.1.3 Rpartition des abonns par services
Tunisie Tlcom dispose de services ddis un type de rseau : services Rseau
Intelligent sur le rseau tlphonique pour les terminaux tlphoniques ( fixes ou mobiles ).
Ces services sont illustrs dans le tableau IV.3
Nombre
abonns
Taux de
simultanit
Trafic moyen
(Erlang)
Dure moyen
un appel(s)
Ligne prpaye 1 000 000 0.5 0.11
147
Ligne post paye 350 000 0.52 0.12
150
Numro prfre 500 0.46 0.08
145
Tlvote 500 0.48 0.09
142
Filtrage dappel 500 0.48 0.085
139
Partage de charge 500 0.46 0.09
142
Multi-abonn 500 0.47 0.10
148
Tableau IV.3- Services du rseau intelligent
Chapit r e IV
En plus de ces services actuels prsents dans le tableau prcdent, lòprateur Tunisie
Tlcom est toujours la qute de làmlioration et du dveloppement de ses services,
travers lìntgration de nouveaux services avancs technologiquement. Le tableau IV.4
illustre lènsemble de services de concept IMS que Tunisie Tlcom dsir offrir sa
clientle.
Nombre dappel Taux dappel/H Taux de simultanit
Com dentreprise 10 000 0.7 0.48
VPN 500 0.69 0.42
VoIP 20 000 0.75 0.5
Golocalisation 15 000 0.72 0.49
Mssagrie Unifie 300 000 0.79 0.58
Msg Instantane 150 000 0.8 0.51
Diffusion de Contenu 20 000 0.25 0.52
IP Centrex 20 000 0.7 0.52
Tableau IV.4 - Les future Services de Tunisie Tlcom
Il est a not que le nombre de SAU va certainement suivre l`volution du nombre
dàbonns. En effet plus on a dàbonnements, plus est important la probabilit dàvoir des
attachements. La politique de lòprateur est un lment essentiel et dcisif au niveau de ce
point. En effet, làttachement peut tre li la facturation.
IV.6 Rsultats du dimensionnement
Selon les donnes cites dans le paragraphe prcdent, nous pouvons dterminer, en
utilisant lòutil IMS-Plateforme_Entities_Dimensionning, les capacits de traitement des
diffrentes entits de la nouvelle plate-forme de services de concept IMS.
La figure IV.9 et IV.10 illustrent les rsultats de dimensionnement des MGCF et CSCF
Chapit r e IV
Figure IV.9 - Rsultat de dimensionnement de MGCF
Figure IV.10 - Rsultat de dimensionnement du CSCF
Chapit r e IV
A lìssue de ces rsultats de dimensionnement, nous remarquons que les entits de la
couche contrle possdent des capacits de traitement trs importantes suite la sparation
des couches connectivit et contrle, ce qui insiste sur lìmportance du concept IMS.
Suite lùtilisation de lòutil IMS-Plateforme_Entities_Dimensionning pour le
dimensionnement des serveurs dàpplication, nous obtenons les rsultats fournis par le
tableau IV.5
Capacit de
traitement(cps
Capacit de
traitement (BHCA)
Com dentreprise 0.93 3 360
VPN 0.04 144.9
VoIP 2.083 7 500
Golocalisation 1.47 5 292
Mssagrie Unifie 38.18 137 460
Msg Instantane 17 61 200
Diffusion de Contenu 0.722 2 600
IP Centrex 2.022 7 280
Tableau IV.5 Rsultats de dimensionnement des serveurs dapplication
Le serveur de messagerie unifies possde la capacit de traitement la plus importante
parmis tous les services IMS figurs dans le tableau prcdent. En effet le service de
messagerie unifie appartient a la classe de service Interactif qui se caractrise par làbsence
de stockage de donnes et de sa courte dlai.
Pour les services de mme type : Conversationnel, Interactif ou Streaming, on remarque
que la capacit de traitement des serveurs correspondants suit l`volution du nombre
dàbonns.
IV.7 Liste de recommandations
Sous les hypothses faites et selon les rsultats obtenus, pour migrer vers une plate-forme
de services dans un concept IMS offrant des services multimdia, Tunisie Tlcom peut
procder ainsi :
- Installer des serveurs dàpplication et le HSS de lÌMS dans les zones les plus dense
en terme de population et dans les zones les plus active.
Chapit r e IV
- Offrir la clientle les services de tlcommunications les plus volus : Services
mobiles, transmission de donnes haut dbit, Internet haut dbit et favoriser leur
utilisation dans les activits socio-conomiques.
- Pour se prparer pour le NGN et tirer des recettes supplmentaires des nouveaux
services, Tunisie Tlcom peut mettre en place des passerelles dàpplication
(ApGW) avec des interfaces ouvertes (exp, OSA/Parlay) vers les serveurs
dàpplication (de tiers).
- Lòprateur historique est invit intgrer le service Triple Parlay dans la future
plate-forme de services dans le concept IMS. Il sàgit dùn abonnement haut dbit
comprenant : accs Internet, offre de tlphonies sur IP, offre de flux vido. Ce
service aura, pour Tunisie Tlcom, les avantages suivants :
Convergence de trois services en un seul offre.
Acqurir une nouvelle clientle de fournisseur de services.
Stimuler la demande pour làccs haut dbit.
IV.8 Conclusion
Dans ce chapitre, on a prsent les diffrents modles de trafic pour chaque classe de la
qualit de service ainsi que les rgles de dimensionnement de diffrentes entits de la plate-
forme de service IMS. Ensuite, nous avons automatis ce processus de dimensionnement
travers le dveloppement de lòutil IMS-Application_Level_Dimensionning.
Enfin, nous avons fait une tude de cas pour Tunisie Tlcom pour valider lòutil et le
processus de dimensionnement.
Concl usion gnr al e
Conclusion gnrale
Lòbjectif de ce projet est d`tudier et de dimensionner une plate-forme de service selon
le concept IMS (Rseau intelligent de la nouvelle gnration), tout en proposant une
solution dìnteroprabilit de cette plate-forme avec les plate-formes IN classique.
Dans ce but, nous avons tout dàbord accord un intrt l`tude des rseaux NGN ainsi
que les rseaux du concept IMS. Cette volution amne les rseaux intelligents offrir des
services dans lènvironnement SIP. En effet, nous nous sommes intress prsenter la
plate-forme de services intelligents et les protocoles mis jour savoir les protocoles INAP,
CAMEL et SIP.
Dans l`tape suivante, nous avons propos une stratgie de migration de la plate-forme
existante de services de lòprateur Tunisie Tlcom vers une plate-forme de service du
concept IMS.
Ensuite, nous avons ralis un outil de dimensionnement des diffrentes entits de la
nouvelle plate-forme de service du concept IMS.
A lìssue de ce travail, nous voulons insister sur lìmportance des concepts IMS et NGN.
Làpport de ces concepts est clair travers la capacit importante de traitement suite la
sparation des couches connectivit et contrle.
De plus le passage par ces deux concepts est une tape essentielle pour la convergence
des rseaux (fixe et mobile).
Dans la dernire tape, nous avons appliqu notre outil en se basant sur une tude de cas
de futur rseau du concept IMS de Tunisie Tlcom.
Comme perspective de ce travail, nous pouvons tendre notre outil par des fonctions
assurant le dimensionnement du cour du rseau, nous pouvons aussi l`tendre par des
fonctions assurant le dimensionnement de la capacit de stockage des serveurs
dàpplication.
Ce projet mà permis dàcqurir des connaissances dans le domaine des rseaux de
nouvelle gnration en matrisant les rgles dingnierie surtout celles ncessaire pour le
dimensionnement.
Bibl iogr aphie
Pr oj et de Fin dEt ude Ben Ammar Raj aa- 2006
B1
Bibliographie
[1]: Simon ZNATY et Jean-Louis DAUPHINEFORT http://www.efort.com, Architecture
NGN , 2000..
[2]: International Softswitch Consortium``, Reference Architecture, June 2002.
www.softswitch.org.
[3]: ALCATEL, 5020 Media Gateway Controller``, Release 2.0, 06/01/2005.
[4]: R. Uebele, M., Stratgie de migration des rseaux tlphoniques vers larchitecture
de la prochaine gnration``, Revue des Tlcommunications d'Alcatel 2002.
[5] : 3GPP, Documentation de normalisation de lÙMTS TS
[6] : Gonzalo Camarillo and Miguel a. Garcia-Martin The 3G IP Multimedia Subsystem,
Merging the Internet and the cellular worlds (2004).
[7] : R. Uebele, M., Stratgie de migration des rseaux tlphoniques vers larchitecture
de la prochaine gnration``, Revue des Tlcommunications d'Alcatel - 2002
[8]: N. DIENG, Le rseau Inteligent``, Sonatel 2003.
[9]: STEPHANE N., Network convergence for the provision of in services in the
Internet``, Facult Notre Dame de la Paix, Namur, 2001.
[10] : SIMON ZNATY & MARIE PIERRE GERVAIS., Les rseaux intelligents,
ingnierie des services de tlcommunication ``, 1999.
[11]: S. TABBANE, rseaux GSM DSC``, HERMES, 1999.
[12]: Z. NOUIR, SIP et architecture de services``, INT, 04-2003.
[13] : MIGEON F.-D. Congestion dheure de pointe sur des axes concurrents de diffrents
niveaux de service``. Mmoire de DEA de lÈHESS, 1994.
Gl ossair e
G1
Glossaire
3GPP 3rd Generation Partnership Project.
A
ADSL Asymmetric Digital Subscriber Line.
API Application Programming Interface.
ARP Address Resolution Protocol.
AS Application Server.
B
BE Best Effort.
C
CAMEL Customiser Application Mobile Enhanced Logic.
CAP Camel Application Part.
CCAF Call Control Agent Function.
CCF Call Control Function
CDR Call Detailed Record
CID Call Instance Data
CLP Call Processing Language
COPS Common Open Policy Service.
CS Capacity Set
CSCF Call Session Control Function
CSE CAMEL Service Environment
CSI CAMEL Subscription Information
D
DFP Distributed Functional Plane
DSL Digital Subscriber Line.
E
ETSI European Telecommunications Standards Institute
Gl ossair e
G2
F
FE Functional Entity
FEA Functional Entity Action
FTP File Transfer Protocol.
G
GFP Global Functional Plane
GPRS General Packet Radio System.
GSL Global Service Logic
GSMGlobal System for Mobile.
GWGateway.
H
HLR Home Location Register
HSS Home Subscriber Server
HTTP Hyper Text Transfer Protocol.
I
ICSCF Interrogating CSCF
IF Information Flow
IMS IP Multimedia SubSytem.
IN Interactive Network.
INAP Interactive Network Access Provider.
INCMIntelligent Network Conceptual Model
IP Internet Protocol.
ISDN Integrated Services Digital Network.
ISUP ISDN User Part.
ITU International Telecommunications Union.
M
MEGACO MEdia GAteway COntrol
MG Media Gateway.
MGC Media Gateway Control.
MGCF Media Gateway Control Function.
Gl ossair e
G3
MGCP Media Gateway Control Protocol.
MGF Media Gateway Function.
MRF Multimedia Resource Function
MSC Mobile Switching Center
N
NGN Next Generation Network.
O
OSA Open Service Access.
P
PCSCF Proxy CSCF
PDP Policy Decision Point.
PDU Protocol Data Unit.
PE Physical Entity
POI Point Of Initiation
POR Point Of Return
PP Physical Plane
PR Profile Register
PSTN Public Switched Telephonic Network.
Q
QoS Quality of Service.
R
RI Rseau Intelligent
ROSE Remote Operations Service Element
RT Real Time.
RTC Rseau Tlphonique Commut.
RTP Real-time Transfert Protocol
S
SACF Single Association Objects
Gl ossair e
G4
SAO Single Association Objects
SCCP Signaling Connection Control Part
SDP Session Description Protocol
SCE Service Creation Environnement.
SCEF Service Creation Environnement Function.
SCEP Service Creation Environment Point
SCF Service Control Function.
SCP Service Control Point.
SCS Service Capability Server.
SCSCF Serving CSCF
SCTP Signalling Control Transport Protocol.
SDF Service Data Function.
SDP Service Data Point
SF service Feature.
SG Signalling Gateway.
SI Service Information.
SIB Service Independent Building Block
SIGTRAN SIGnalling TRANsport
SIP Session Initiation Protocol.
SLEE Service Logic Execution Manager.
SMAF Service Management Agent Function;
SMAP Service Management Access Point
SMF Service Management Function
SMP Service Management Point
SNP Service Node Point
SP Service Plane
SRF Specialized Resource Function
SS7 Signalling System number 7.
SSD Service Support Data.
SSF Service Switching Function
SSP Service Switching Point.
T
Gl ossair e
G5
TCAP Transaction Capabilities Application Part
TCP Transmission Control Protocol.
T-SGWTrunking Signaling GateWay
U
UA User Agent.
UAS User Agent Server.
UE User Equipement
UMTS Universal Mobile Telephone Service.
UTRAN UMTS Terrestrial Radio Access Network
V
VoIP Voice over IP.
VPN Virtual Private Network.

Ben Ammar Raja

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ben Ammar Raja

Transféré par

Droits d'auteur :

Formats disponibles

Cycle de formation des ingnieurs en Tlcommunications

= = pour n=0,1,2,. (IV.1)

Vous aimerez peut-être aussi