Mise en place d’une plateforme de formation IMS

GAGLO Kokou Mise en place d’une plateforme de formation IMS
11
AAAA mon oncle Isaac Jogues GAGLO
DEDICACESDEDICACES

2
Je voudrais avant toutes choses rendre grâce à l’Eternel sans qui ce travail ne saurait
aboutir. Que son Saint Nom soit glorifié pour les siècles sans fin.
J’adresse également mes sincères remerciements à :
Son Excellence Isaac Jogues GAGLO, Evêque d’Aneho (TOGO) ;
Mon père, Feu Jean Marie Koffi GAGLO ;
Ma mère Patience Ayéwa LODONOU ;
Docteur Samuel OUYA notre professeur encadreur et maitre de stage, pour sa
rigueur, sa disponibilité et ses nombreuses recommandations ;
Tous les professeurs de l’ESMT et de l’ESP qui ont assuré ma formation ;
Tout le personnel de Réseaux et Techniques Numériques ;
Mon groupe de travail (JACAT team) composé de Terence VIGAN, Coura SY,
Akofa AMEGANDJIN, Marthe Eva NDIAYE ;
Ma famille, GAGLO, LODONOU, EKLU, KOUTOGLO ;
Toute la Communauté Arbre de Vie Divine de Dakar ;
Aux Sœurs Aimée de Jésus DAMAWUZAN, Marie Delphine KALI et Gildas
PLAKOO ;
Aux Pères Georges SOKPO et Patrick GABA ;
Ma promotion téléinformatique IGTT2 2009/2011
Toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce document
MERCI A TOUS!
REMERCIEMENTS

3
PRESENTATION DE l’ESMT
L’Ecole Supérieure Multinationale des Télécommunications (ESMT) est une institution
multinationale qui accueille 17 nationalités en formation initiale et continue liée au Sénégal
par un accord de siège qui lui confère un statut diplomatique.
L’ESMT recouvre plusieurs domaines dont :
les diplômes de Technicien Supérieur :
• diplôme de technicien supérieur en télécommunications : spécialités
technique et commerciale ;
• diplôme de technicien supérieur en téléinformatique : en partenariat avec
l’Ecole Supérieure Polytechnique de Dakar ;
• diplôme de technicien supérieur en réseaux et données ;
les diplômes d’Ingénieur :
• diplôme d’ingénieur des travaux télécoms (IGTT) : spécialités technique et
commerciale ;
• diplôme d’ingénieur téléinformatique, en partenariat avec l’ESP de Dakar ;
• diplôme d’ingénieur de conception ;
les diplômes Mastères :
• mastère en gestion des télécommunications ;
• mastère en réseaux télécoms ;
• mastère en téléinformatique en partenariat avec l’ESP de Dakar ;
les certifications :
• CISCO ;
• GVF ;
• FOA ;
• NSOFT ;
• Alcatel-Lucent ;
Elle est en cours de le devenir pour Oracle.
AVANT-PROPOS

4
PRESENTATION DE L’ESP
le département Génie Chimique ;
le département Génie Civil ;
le département Génie Electrique ;
le département de Gestion ;
le département Génie Mécanique ;
le département Génie Informatique.
Soucieux de la demande des entreprises évoluant dans le domaine de l’informatique et
des télécommunications, l’Ecole Supérieure Polytechnique (ESP) et l’Ecole Supérieure
Multinationale des Télécommunications (ESMT) ont mis en place une formation d’ingénieur
Technologue en Téléinformatique.
Dans le cadre de la formation qui s’étale sur deux ans, l’étudiant devra effectuer un
stage de quatre à six mois dans une entreprise ou un laboratoire ou il mettra à profit ses acquis
théoriques à l’issu duquel il devra présenter un mémoire de fin de cycle qui est le fruit du
travail effectué dans la structure d’accueil.
C’est dans cette optique que nous avions effectué un stage de 06 mois à Réseaux et
Techniques Numériques qui nous a value le thème : Mise en place d’une plateforme de
formation IMS.

5
AVANT-PROPOS................................................................................................................ 3
Table des Matières ........................................................................................................... 5
Sigles et Abréviations........................................................................................................ 8
Table des Figures .............................................................................................................. 9
Table des Tableaux ......................................................................................................... 12
Introduction.................................................................................................................... 13
1.................................................................................................PRESENTATION GENERALE
....................................................................................................................................... 14
1.1. Présentation de l’entreprise Réseaux et Technique Numérique ......................... 14
1.1.1. Mission de RTN .......................................................................................... 14
1.1.2. Domaine d’activité ..................................................................................... 14
1.1.3. Organigramme de RTN ............................................................................... 16
1.2. Présentation du sujet........................................................................................ 16
1.3. Problématique .................................................................................................. 16
1.3.1. Objectifs..................................................................................................... 17
2...........................................................................ETUDE DE L’IP MULTIMEDIA SUBSYSTEM
....................................................................................................................................... 18
2.1. Architecture du réseau IMS ............................................................................... 18
2.2. Description des entités IMS et leurs fonctionnalités........................................... 20
2.2.1. la gestion de session et le routage (CSCF).................................................... 21
2.2.1.1. Proxy Call Session Control Function (P-CSCF) ........................................... 22
2.2.1.2. Interrogating Call Session Control Function (I-CSCF)................................. 23
2.2.1.3. Serving Call Session Control Function (S-CSCF)......................................... 24
2.2.1.4. Emergency Call Session Control Function (E-CSCF) ................................... 25
2.2.2. HSS (Home Subscriber Server) : la base de données .................................... 25
2.2.3. MRF (Multimedia Resource Function)......................................................... 27
2.2.4. BGCF (Breakout Gateway Control Function)................................................ 27
2.2.5. IMS-MGW, MGCF et SGW........................................................................... 28
2.2.5.1. La passerelle de flux multimédia IMS-MGW (IMS-Media GateWay) ......... 28
2.2.5.2. Le contrôleur de passerelle MGCF (Media Gateway Control Function) ..... 29
2.2.5.3. La passerelle de signalisation SGW (Signaling GateWay).......................... 29
2.2.6. TrGW et IMS-ALG ....................................................................................... 30
2.2.7. Les serveurs d’application .......................................................................... 31
2.3. Les principaux protocoles et leurs interfaces..................................................... 31
Table des Matières

6
2.3.1. Les principaux protocoles ........................................................................... 31
2.3.2. Les interfaces ............................................................................................. 32
2.3.2.1. Interface Gm........................................................................................... 33
2.3.2.2. Interface Mw .......................................................................................... 33
2.3.2.3. Interface ISC (IMS Service Control) .......................................................... 34
2.3.2.4. Interface Cx ............................................................................................ 34
2.3.2.5. Interface Sh ............................................................................................ 35
2.3.2.5.1. La localisation .................................................................................... 35
2.3.2.5.2. La gestion des données des utilisateurs.............................................. 35
2.3.2.5.3. L’authentification des utilisateurs ...................................................... 36
2.3.2.5.4. Gestion des données.......................................................................... 36
2.3.2.5.5. Souscription/Notification................................................................... 36
2.4. Les identités IMS............................................................................................... 37
2.5. Enregistrement d’un terminal dans le réseau..................................................... 38
2.6. La fourniture de services dans l’IMS .................................................................. 39
2.6.1. Le profil utilisateur ..................................................................................... 40
2.6.2. Le profil de service ..................................................................................... 40
2.6.2.1. L'identification publique ......................................................................... 41
2.6.2.2. La politique media .................................................................................. 41
2.6.2.3. Le déclenchement des services................................................................ 41
3............................................................................................................. LES SERVICES IMS
....................................................................................................................................... 43
3.1. Présence ........................................................................................................... 43
3.1.1. Le service de présence dans l’IMS............................................................... 43
3.1.2. Publication des informations de présence................................................... 45
3.1.3. Souscription au service de présence ........................................................... 46
3.2. Gestion de groupe............................................................................................. 47
3.2.1. XML Configuration Access Protocol............................................................. 47
3.2.2. La liste de ressources.................................................................................. 48
3.3. Push to Talk Over Cellular.................................................................................. 50
3.3.1. Architecture du PoC.................................................................................... 51
3.3.1.1. Le serveur PoC ........................................................................................ 52
3.3.1.2. Le client PoC ........................................................................................... 53
3.4. IPTV.................................................................................................................. 53
3.4.1. Architecture de l’IPTV................................................................................. 54
3.4.2. Description de la plateforme IPTV basée sur l’IMS...................................... 54
4. MISE EN PLACE DE LA PLATEFORME IMS................................................................ 56
4.1. Architecture de la plateforme............................................................................ 56

7
4.2. Présentation et installation des logiciels utilisés ................................................ 56
4.2.1. OpenIMSCore............................................................................................. 56
4.2.1.1. Les CSCFs ................................................................................................ 58
4.2.1.1.1. Le P-CSCF ........................................................................................... 58
4.2.1.1.2. L’I-CSCF.............................................................................................. 58
4.2.1.1.3. Le S-CSCF ........................................................................................... 59
4.2.1.2. Le HSS..................................................................................................... 59
4.2.1.3. Installation d’OpenIMSCore .................................................................... 60
4.2.2. OPENSIPS................................................................................................... 61
4.2.2.1. Installation et configuration.................................................................... 61
4.2.2.2. Création de l’AS de présence au niveau du HSS........................................ 61
4.2.2.3. Simulation du service de présence .......................................................... 63
4.2.3. OPENXCAP ................................................................................................. 65
4.2.3.1. Installation et configuration.................................................................... 66
4.2.3.2. Simulation du service de mobilité............................................................ 67
4.2.4. La Video à la Demande (VoD)..................................................................... 70
4.2.4.1. Serveur media avec VLC media player ..................................................... 70
4.2.4.1.1. Installation et configuration............................................................... 70
4.2.4.1.2. Simulation des flux RTSP.................................................................... 70
4.2.4.2. IPTV AS avec UCT Advanced IPTV ............................................................ 71
4.2.4.2.1. Installation et configuration............................................................... 71
4.2.4.2.2. Création de l’AS VoD au niveau du HSS............................................... 71
4.2.4.2.3. Simulation du service VoD.................................................................. 73
CONCLUSION .................................................................................................................. 75
BIBLIOGRAPHIE || WEBOGRAPHIE.................................................................................. 76
ANNEXES ........................................................................................................................... i
A.1 Mise en place du plan de contrôle IMS et figures de l’interface FHoSS.........................iv
A.2 Installation d’OPENSIPS .............................................................................................vii
A.3 Installation d’ OPENXCAP.............................................................................................x
A.3.1 Installation............................................................................................................x
A.3.2 Configuration .......................................................................................................xi
A.4 Installation du media server VLC ................................................................................xii
A.5 Installation de UCT Advanced IPTV............................................................................xii
A.6 Installation de l’outil Siremis.....................................................................................xiii
A.7 Installation et paramétrage des clients IMS...............................................................xiv
A.8 Quelques captures Wireshark des flux échangés sur notre réseau IMS.......................xvi

8
Nous présentons ici certains sigles et abréviations que nous utiliserons dans le document.
Abréviations Descriptions
3GPP Third Generation Partnership Project
AS Application Server
CS Circuit Switched
CSCF Call Session Control Function
HSS Home Subscriber Server
GPRS General Packet Radio Service
HTTP Hypertext Transfer Protocol
I-CSCF Interrogating Call Session Control Function
IFC Initial Filter Criteria
IMS IP Multimedia Subsystem
IP Internet Protocol
MGCP Media Gateway Control Protocol
MRFP Media Resource Function Processor
NGN Next Generation Networks
P-CSCF Proxy Call Session Control Function
RTP Real Time Transport Protocol
S-CSCF Serving Call Session Control Function
SER SIP Express Router
SIP Session Initiation Protocol
SLF Subscriber Locator Function
UA User Agent
UE User Equipment
URI Universal Resource Identifier
VoIP Voice over IP
XML eXtensible Markup Language
Sigles et Abréviations

9
Figure 1.1 : Organigramme de RTN ................................................................................. 16
Figure 2.2 : Les serveurs CSCF.......................................................................................... 21
Figure 2.4 : Structure du HSS ........................................................................................... 26
Figure 2.5 : Interfonctionnement avec le RTC................................................................... 28
Figure 2.6 : Les serveurs IMS-ALG et TrGW ...................................................................... 30
Figure 2.7 : Les interfaces dans l’architecture IMS............................................................ 32
Figure 2.8 : Processus d’enregistrement d’un terminal..................................................... 39
Figure 2.9 : Structure d’un profil utilisateur ..................................................................... 40
Figure 2.10 : Structure d'un IFC........................................................................................ 41
Figure 3.1 : Aperçu de la présence ................................................................................... 43
Figure 3.2 : Architecture de la présence........................................................................... 45
Figure 3.3 : Publication de présence ................................................................................ 45
Figure 3.4 :Souscription aux informations de présence .................................................... 46
Figure 3.5 : Les opérations XCAP ..................................................................................... 48
Figure 3.6 : Exemple de flux de souscription avec RLS ...................................................... 49
Figure 3.8 : Exemple de liste de ressources ...................................................................... 50
Figure 3.9 : Push to Talk Over Cellular ............................................................................. 51
Figure 3.10 :Architecture du PoC ..................................................................................... 52
Figure 3.11 :Architecture du server PoC........................................................................... 53
Figure 3.12 : Architecture de réseaux convergents offrant les services d’IPTV................... 54
Figure 4.1 : Architecture de la plateforme ....................................................................... 56
Figure 4.2 : Architecture de l’OpenIMSCore ..................................................................... 57
Figure 4. 3: Open IMS Proxy-CSCF.................................................................................... 58
Figure 4. 4 : Open IMS Interrogating-CSCF....................................................................... 59
Figure 4. 5 : Open IMS Serving-CSCF ................................................................................ 59
Figure 4. 6 : Open IMS HSS .............................................................................................. 60
Figure 4.7 : Paramétrage du Service Profile de présence ................................................. 61
Figure 4.8 : Paramétrage de l’Application Server de présence.......................................... 62
Table des Figures

10
Figure 4.9 Le Trigger Point de présence ........................................................................... 62
Figure 4.10 : Paramétrage de l’Initial Filter Criteria de présence ...................................... 63
Figure 4.11 : L’utilisateur Alice souscrit aux informations de présence de Bob.................. 63
Figure 4.12 : L’utilisateur Bob souscrit aux informations de présence d’Alice.................... 64
Figure 4.13 : Liste des Watchers ...................................................................................... 65
Figure 4.14 : Liste des Presentities................................................................................... 65
Figure 4.15 : SIP SIMPLE Server ....................................................................................... 66
Figure 4.16 : Liste de contact de Samuel connecté sur un poste 1..................................... 67
Figure 4.17 : Liste de contact de Samuel connecté un poste 2.......................................... 68
Figure 4.18 : Liste de contact des utilisateurs stockée par le XMDS .................................. 69
Figure 4.19 : Détails du fichier properties-resource-list.xml de Samuel............................. 69
Figure 4.20 : Utilisation du navigateur firefox pour visualiser la vidéo référencée par ‘clip’
....................................................................................................................................... 70
Figure 4.21 : Flux vidéo précédent ouvert avec le lecteur totem de Linux.......................... 70
Figure 4.22 : Paramétrage du Service Profile de l’IPTV.................................................... 71
Figure 4.23 : Paramétrage de l’Application Server de l’IPTV............................................. 72
Figure 4.24 : Paramétrage du Trigger Point de l’IPTV....................................................... 72
Figure 4.25 : Paramétrage de l’Initial Filter Criteria de l’IPTV........................................... 73
Figure 4.26 : Demande du service IPTV par l’utilisateur James ......................................... 74
Figure A.1.1 : Interface de connexion au HSS ....................................................................vii
Figure A.1.2 : Page d’accueil du HSS.................................................................................vii
Figure A.6.1 : Interface web d’installation de Siremis.......................................................xiv
Figure A.7.1: UCTIMSCLIENT (Ubuntu 8.04).......................................................................xv
Figure A.7.2: MERCURO IMS CLIENT (Windows XP)..........................................................xv
Figure A.7.3 : myMOSTER................................................................................................xvi
Figure A.8.1 : Capture générale de tous les appels VoIP dans le réseau............................xvi
Figure A.8.2 : Enregistrement de Bob .............................................................................xvii
Figure A.8.3 : Bob appelle Alice......................................................................................xvii
Figure A.8.4 : Analyse graphique de l’appel de Bob vers Alice........................................xviii
Figure A.8.5 : Chat entre Bob et Alice ............................................................................xviii
Figure A.8.6 : Utilisation du service VoD de James .........................................................xviii

11
Figure A.8.7 : Analyse graphique de la demande VoD par James......................................xix

12
Tableau 2.1: Les interfaces IMS ......................................................................................... ii
Tableau 2.1 (suite): Les interfaces IMS............................................................................... ii
Tableau 2.2: Commandes Cx ............................................................................................ iii
Tableau 2.2 (suite): Commandes Cx...................................................................................iv
Tableau 2.3 : Commandes Sh.............................................................................................iv
Table des Tableaux

13
Le monde de la télécommunication est en train de subir un changement fondamental
et les éléments catalyseurs de ce changement sont les technologies d’Internet. L’utilisation du
protocole IP (Internet Protocol) pour la voix, les données, le multimédia est en train
d’entrainer la convergence dans les réseaux ; que ce soit le fixe, le mobile, le sans fil et autres.
La convergence des réseaux est le moyen par lequel les opérateurs faciliteront à leurs
clients un accès facile à leurs services et leurs proposeront des applications innovantes (VoIP,
vidéoconférence, messagerie instantanée, jeux multi-joueurs,…). C’est ce défi de
convergence entre fixe et mobile que relève la technologie IMS (IP Multimedia Subsystem)
en permettant d’être joignable où que l’on soit, sur un ordinateur comme sur un mobile ou
autre terminale bénéficiant de l’étendue de l’offre multimedia.
C’est ainsi que RTN, intervenant dans le domaine des télécoms, anticipe l’avènement
effectif de la convergence en mettant en place une plateforme de formation IMS qui ciblera
non seulement les opérateurs qui migreront leurs réseaux vers cette technologie mais
également toute autre structure s’y intéressant.
Dans le but de restituer le travail effectué, ce document est divisé en quatre (4)
chapitres. Le premier chapitre présentera la structure d’accueil (RTN), le second exposera la
technologie IMS. Le troisième quant présentera les services IMS, ensuite viendra enfin le
quatrième chapitre qui détaillera la séquence de déploiement de la plateforme.
Introduction

14
1. PRESENTATION GENERALE
Ce chapitre fera l’objet de présentation de la structure Réseaux et Techniques Numériques
où nous avons effectué notre stage. Il définit également le contexte de notre sujet, sa
problématique ainsi que ses objectifs.
1.1.Présentation de l’entreprise Réseaux et Technique Numérique
Réseaux et Techniques Numériques (R.T.N) est une société dirigée par une équipe de
professionnels qualifiés, spécialisée en logiciels libres et centrée sur les services
informatiques, techniques numériques et télécommunications.
Cette société offre une gamme de formations se basant sur des supports de cours, fruits de
recherches approfondies. Ces supports testés et avérés permettent aux apprenants d’être
aussitôt opérationnels.
1.1.1. Mission de RTN
La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation
des composantes informatiques, logicielles et réseaux constituants le système d'information de
ces derniers. Cela leur confère des gains importants en produisant plus et mieux à budget
réduit, grâce à l’exploitation de la puissance des logiciels libres existants et ceci, sans rupture
des cycles d'exploitation de service de ces entreprises et sans remise en cause
organisationnelle. Leur principal objectif est de conseiller et de former le personnel des
entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi
les coûts d' investissements en réseaux informatiques tout en leur apportant une sécurité
avancée.
1.1.2. Domaine d’activité
La société RTN offre une palette de solutions dans le domaine de la technologie de
l’information et de la communication. Les solutions de RTN sont orientées Open Source et
réalisées selon les besoins et l'exploration des opportunités d'entreprise. Elles répondent par
conséquent aux problèmes réels.
RTN met également un accent particulier sur les suites bureautiques de Linux
(traitement de texte, tableurs et logiciels de présentation de conférence et de traitement
CHAPITRE 1

15
d’images), le développement des services à valeurs ajoutées, les serveurs sécurisés libres
(DNS, APACHE, DHCP, LDAP, SENDMAIL, POSTFIX, WEBMAIL, VPN, etc.) et
l’interconnexion des réseaux Linux et Windows, participant ainsi à la cohabitation et
l’harmonisation des réseaux hétérogènes Linux-Windows.
RTN intervient dans les domaines suivants :
• Formation et encadrement des personnels des entreprises;
• Mise à niveau du personnel des entreprises sur les technologies de l’information et de
la communication ;
• Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise
dynamique ;
• Formation de professionnels spécialisés en câblage de réseaux informatiques.
RTN dispense également un éventail de formations dont la liste non exhaustive est la
suivante :
• Certification Linux Professional Institute (LPI)
• Certification Cisco CCNA
• Téléphonie sur IP avec le protocole SIP
• Téléphonie sur IP avec le protocole H323
• Mise en place de la ToIP avec l’IPX open source Asterisk (SIP, SCCP, UNISTIM)
• Mise en place de la ToIP avec le Call Manager de Cisco
• Messagerie collaborative
• Les services réseaux

GAGLO Kokou
1.1.3. Organigramme de RTN
Figure 1.1
1.2.Présentation du sujet
A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation
Network) dont est issu l’IMS. Ainsi, il
pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce
domaine.
1.3.Problématique
RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des
NGN. Ainsi, que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces
Service accueil, info,
animation scolaire
Bureau des étudiants
Service Ressource
Technique et
Documentaire
Mise en place d’une plateforme de formation IMS
Organigramme de RTN
Figure 1.1 : Organigramme de RTN
Présentation du sujet
Network) dont est issu l’IMS. Ainsi, il va de soi que les opérateurs, spécifiquement africains,
que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces
CA
DG (mme ouya)
Direction Formation
Recherche
EC2LT
Service scolarité ,
recouvrement & caisse
Départements
commissions
permanentes ou
adhoc
conseil de la vie
scolaire et des études
(DFR).
Service Recherche,
deploiement &
formation
Service comptabilité
finance
16
que les opérateurs, spécifiquement africains,
que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces entités
conseil de la vie
scolaire et des études
Service comptabilité
Service marketing,
communication, op.
commerciales

17
auront besoin que leurs ingénieurs soient formés pour une migration du réseau existant pour le
premier, que leur personnel ait le bagage nécessaire afin de décider de ce qui sera de la
réglementation de ce secteur pour le second.
C’est dans ce but que RTN a mis en place un laboratoire chargé d’effectuer des
recherches dans le domaine de l’IMS. C’est de cette dynamique que découle notre travail qui
consiste à mettre en place une plateforme de formation IMS qui permettra à l’apprenant de :
• comprendre le concept de l’IMS ;
• d’étudier toutes les entités constitutives d’une architecture IMS ;
• se familiariser avec les protocoles utilisés par la technologie IMS ;
• simuler un réseau IMS ;
• mettre en place des services et les greffer au cœur IMS ;
• d’analyser les flux générés dans un réseau IMS.
1.3.1. Objectifs
Notre travail consistera à mettre en place la plateforme de formation IMS, à
documenter toutes les étapes de la mise en place. Nous étudierons les divers
protocoles utilisés dans un réseau IMS, les interactions entre tous les composants de ce
dernier. Nous étudierons également les différents types de services supportés par
l’IMS, puis nous en implémenterons quelques uns au dessus du réseau IMS qui sera
déployé.

GAGLO Kokou
2. ETUDE DE L’IP MULTIMEDIA SUBSYSTEM
2.1.Architecture du réseau IMS
Figure 2.1 : Le modèle à quatre couche de l’a
IMS propose une approche modulaire qui permet de distinguer des niveaux de
différents. Quatre couches (ou
domaine spécifique (la figure 2.1
l’IMS) :
• la couche accès [B2] définit la manière dont l
les réseaux d’accès, on peut citer les plus classiques : GSM (Global System for Mobile
communications), UMTS (Universal Mobile Telecommunications System), CDMA
2000 (Code Division Multiple Access 2000), UMA (Unlice
xDSL (xDigital Subscriber Line), Wi
ETUDE DE L’IP MULTIMEDIA SUBSYSTEM
Architecture du réseau IMS
Le modèle à quatre couche de l’architecture IMS
IMS propose une approche modulaire qui permet de distinguer des niveaux de
Quatre couches (ou plans) peuvent être identifiées, chacune d’elles étant liée à un
maine spécifique (la figure 2.1 illustre un schéma global de l’architecture en couches
définit la manière dont l’utilisateur se connecte au réseau. Parmi
2000 (Code Division Multiple Access 2000), UMA (Unlicensed Mobile Access),
xDSL (xDigital Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide
18
rchitecture IMS
IMS propose une approche modulaire qui permet de distinguer des niveaux de traitements
peuvent être identifiées, chacune d’elles étant liée à un
illustre un schéma global de l’architecture en couches de
’utilisateur se connecte au réseau. Parmi
nsed Mobile Access),
Fi (Wireless Fidelity), WiMax (Worldwide
CHAPITRE 2

19
Interoperability for Microwave Access) et les réseaux fixes, comme Ethernet, ATM, la
fibre optique et le câble, par exemple. Cette liste non exhaustive est susceptible de
contenir n’importe quel réseau d’accès, qu’il soit filaire ou non. Remarquons que les
réseaux supportés ne s’orientent ni vers IP, ni vers les réseaux cellulaires en
particulier, mais visent une large étendue de possibilités. En regroupant différents
types de réseaux d’accès au sein de cette couche, IMS offre un niveau d’abstraction à
la manière dont l’utilisateur se connecte au réseau. Cette vision est à l’origine de l’idée
de convergence des réseaux vers un réseau unique, prônée par l’IMS. Autrement dit,
IMS est indépendant du réseau d’accès, qui n’est qu’un élément assurant la
connectivité de l’utilisateur au réseau cœur.
• la couche transport [B2] permet la connectivité de bout en bout entre les différents
interlocuteurs. Alors que la couche d’accès se contente de connecter un utilisateur au
réseau IMS, la couche transport se charge de l’acheminement des données de
l’utilisateur jusqu’à son (ou ses) correspondant(s). Cela comprend le transport de
l’information par les routeurs et le choix de la route empruntée dans le réseau. C’est le
réseau IP qui est utilisé dans cette couche.
Elle dispose en outre de deux sous-systèmes particuliers :
o NASS (Network Attachment SubSystem) pour la configuration du réseau. Il
permet de disposer dans le réseau de l’équivalent d’un serveur DHCP, afin
d’attribuer des paramètres réseau (au minimum une adresse IP et un masque de
sous réseau) à l’utilisateur, et d’un client, pour les authentifications de
l’utilisateur, réalisées sur son profil.
o RACS (Ressource Admission Control SubSystem) pour le contrôle
d’admission. Il permet d’allouer les ressources sollicitées par les applications
en effectuant, à la demande, des réservations.
• la couche contrôle [B2] assure la gestion et le contrôle du réseau. Elle est en charge
de tous les messages de signalisation dans le réseau, permettant d’ouvrir, de maintenir,
de modifier et de terminer une session entre des utilisateurs. C’est la partie intelligente
du modèle, qui offre toutes les fonctionnalités de gestion des utilisateurs et constitue le
véritable socle de l’IMS. La couche de contrôle est constituée de différentes entités

20
logiques que nous allons détailler dans les paragraphes suivants. Toutes ces entités
sont indispensables pour le fonctionnement d’un réseau IMS. Elles sont des entités
logiques, ce qui signifie que, malgré leur distinction fonctionnelle, rien n’empêche de
les implémenter (toutes ou certaines) au sein d’un même équipement.
• la couche application [B2] consiste en la fourniture des services, qu’ils soient audio,
vidéo ou textuels. Cette couche implémente tous les services que l’on peut proposer
aux utilisateurs. Elle est la partie la plus ouverte du modèle, puisque le réseau IMS ne
spécifie pas les services eux-mêmes, mais offre une plate-forme de déploiement
unifiée, simple, rapide, productive et sécurisée pour la mise en place de nouveaux
services. Sa description est assez sommaire, mais elle est susceptible d’être enrichie à
l’infini, selon les nouveaux services que l’on souhaite apporter et toutes les
propositions amenées par des développeurs. On peut, notamment, mentionner les
applications classiques de présence, de messagerie instantanée et de push-to-talk.
Nous verrons plus loin les différentes catégories de services que l’IMS permet de
distinguer.
Chaque couche est indépendante, de sorte qu’il est possible, par exemple, d’ajouter librement
de nouveaux services dans la couche applicative, sans tenir compte du réseau d’accès que les
utilisateurs ont employé, ni du terminal qu’ils ont utilisé. Cela dit, il est souhaitable que les
serveurs d’applications adaptent leur réponse en fonction de ces critères : par exemple, une
page Web ne doit pas contenir les mêmes informations ni être formatée de la même manière
selon qu’elle est destinée à être visualisée sur un ordinateur portable ou sur un téléphone
portable.
2.2.Description des entités IMS et leurs fonctionnalités
Cette section décrit les entités IMS et leurs fonctionnalités. Ces entités sont les suivantes :
• CSCF (décliné en P-CSCF, I-CSCF et S-CSCF)
• HSS et SLF
• MRF (réparti en MRFC et MRFP)
• BGCF

GAGLO Kokou
• MGW, MGCF et SGW
• TrGW et IMS-ALG
• Serveur d’applications (SIP, IM
2.2.1. la gestion de session et le routage (CSCF)
Il y a quatre (4) types de
CSCF), Serving-CSCF (S-CSCF), Interrogating
CSCF). Chaque CSCF a des tâches spéciales qui sont décrites
que le P-CSCF, S-CSCF et I-
de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En
outre, toutes les fonctions sont en mesure d
chargement hors ligne. Il ya quelques fonctions communes que P
mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur
(par exemple, lorsque S-CSCF détecte une session pendante ou P
notification indiquant que le porteur des médias est perdu) et sont en mesure de vérifier que le
contenu de la requête SIP ou la réponse est conforme à la politique de l'exploitant et
d'abonnement de l'utilisateur (par exemple le contenu de la Session Description Protocol
(SDP) de charge utile contient les types de médias ou de codecs, qui sont autorisés pour un
utilisateur).
MGW, MGCF et SGW
Serveur d’applications (SIP, IM-SSF et OSA-SCS)
on de session et le routage (CSCF)
Il y a quatre (4) types de Call Session Control Functions (CSCF)
CSCF), Interrogating-CSCF (I-CSCF) et Emergency
Chaque CSCF a des tâches spéciales qui sont décrites plus loin dans le document
-CSCF ont en commun c’est qu’ils jouent tous un rôle au cours
outre, toutes les fonctions sont en mesure d'envoyer des données de charge à une fonction de
chargement hors ligne. Il ya quelques fonctions communes que P-CSCF et S
SCF détecte une session pendante ou P
utilisateur (par exemple le contenu de la Session Description Protocol
Figure 2.2 : Les serveurs CSCF
21
(CSCF) : Proxy-CSCF (P-
CSCF) et Emergency-CSCF (E-
lus loin dans le document. Ce
CSCF ont en commun c’est qu’ils jouent tous un rôle au cours
'envoyer des données de charge à une fonction de
CSCF et S-CSCF sont en
-CSCF reçoit une
utilisateur (par exemple le contenu de la Session Description Protocol

22
2.2.1.1. Proxy Call Session Control Function (P-CSCF)
Le serveur P-CSCF constitue le point d’entrée dans le réseau IMS pour tout ce qui concerne la
signalisation d’une session d’un utilisateur. Il est situé dans le réseau auquel le terminal se
connecte, même si ce réseau n’est pas celui de l’opérateur auquel l’utilisateur est abonné. Dès
qu’une requête de signalisation est envoyée depuis un terminal, elle est réceptionnée par un
P-CSCF. Ce dernier est chargé de prendre en charge les requêtes d’un utilisateur et de les
rediriger vers les serveurs concernés (c’est-à-dire les serveurs appartenant à l’opérateur auquel
l’utilisateur a souscrit un service). De même, après avoir envoyé la requête de l’utilisateur au
serveur concerné, c’est le P-CSCF qui relaie la réponse obtenue vers le terminal. Le P-CSCF
est donc un intermédiaire imposé entre le terminal et les autres serveurs.
Dans la pratique, lorsqu’un terminal est connecté au réseau IMS, il initie une étape
d’activation de contexte PDP lui permettant de négocier les paramètres avec lesquels ses
services vont être lancés. Cette étape est indispensable pour pouvoir ensuite émettre et
recevoir des requêtes SIP. Lors de cette étape, le terminal découvre l’adresse du serveur
P-CSCF. Celui-ci sert à aiguiller chacune des requêtes émises par le terminal. Autrement dit,
le terminal s’adresse au P-CSCF pour lui formuler ses requêtes, et c’est le P-CSCF qui est
chargé de les mener à bien. Le P-CSCF est déterminé et attribué pour toute une session, d’une
connexion à la déconnexion d’un utilisateur. Par contre, il peut changer lors de la session
suivante de l’utilisateur. Le serveur P-CSCF n’est pas nécessairement la propriété de
l’opérateur auquel le client a souscrit un service. Au contraire, et c’est tout son intérêt, il peut
être un intermédiaire entre le terminal client IMS et les serveurs de l’opérateur de l’utilisateur.
Considérons un utilisateur qui se trouve physiquement dans une région où son opérateur ne
dispose d’aucune infrastructure pour permettre sa connexion, par exemple à l’étranger. Dans
ce cas, et pour peu que l’opérateur de l’utilisateur ait un contrat avec l’opérateur qui gère cette
région, l’utilisateur peut quand même se connecter en utilisant l’infrastructure du réseau
visité, matérialisé par le P-CSCF de l’opérateur de la région. Le terminal est dans ce cas «
visiteur » dans le P-CSCF qu’il sollicite. Outre sa nécessité physique, le P-CSCF facilite les
facturations entre opérateurs. Bien sûr, le P-CSCF peut aussi être celui de l’opérateur auquel
l’utilisateur à souscrit un abonnement. Ainsi, dans tous les cas, le terminal possède un
interlocuteur virtuel privilégié, auquel il délègue le soin d’aiguiller ses demandes. De cette
manière, le terminal n’a qu’une vision minimale des serveurs du réseau IMS, et c’est au
serveur P-CSCF que revient la charge de localiser et contacter les autres entités. Le réseau de

23
signalisation est de la sorte protégé par le P-CSCF, qui agit comme un garde-barrière. Il peut
même avoir les fonctionnalités suivantes :
• Contrôle de syntaxe des requêtes SIP.
• Contrôle d’intégrité des données.
• Contrôle d’admission en refusant des appels lorsque le réseau est trop chargé, afin de
ne pas dégrader la qualité des communications existantes.
À ce titre, le rôle du P-CSCF est comparable à celui que joue le proxy SIP dans l’architecture
SIP. Le P-CSCF doit également permettre l’aboutissement des appels d’urgence. De plus, il
est aussi responsable de la gestion de la qualité de service pour l’utilisateur. Outre sa
fonctionnalité d’intermédiaire dans l’acheminement des méthodes SIP entre le terminal de
l’utilisateur et le serveur approprié, le P-CSCF offre des fonctionnalités de
compression/décompression des messages SIP, afin de réduire le temps d’établissement d’une
connexion. Le terminal IMS a la possibilité de compresser ses données, ce qui permet de les
transmettre plus rapidement au P-CSCF qui les décompresse avant de les transmettre aux
entités sollicitées. C’est d’autant plus utile que les réseaux radio (utilisés le plus souvent dans
la couche d’accès) ont généralement une bande passante réduite. L’objectif de la compression
n’est pas vraiment de ne pas gaspiller la bande passante, mais plutôt sa conséquence
immédiate, qui est d’accélérer la transmission du message.
2.2.1.2. Interrogating Call Session Control Function (I-CSCF)
L’I-CSCF est le point de contact dans le réseau de l’opérateur pour toutes les connections
destinées à un utilisateur du même réseau. Les fonctions assignées au I-CSCF sont au nombre
de trois (3) :
• obtenir le nom de l’entité suivante (soit un S-CSCF soit un serveur d'application) chez
le HSS (Home Subscriver Server) ;
• attribution d'une S-CSCF en fonction des possibilités reçues de l'HSS. Cette
attribution de S-CSCF aura lieu quand un utilisateur est en train de s’enregistrer sur le
réseau ou un utilisateur reçoit une requête SIP alors qu'il est déconnecté du réseau,

24
mais il a souscrit à des services liés à un état non enregistrés (exemple messagerie
vocale) ;
• routage des demandes entrantes vers un S-CSCF attribué ou le serveur d'applications.
2.2.1.3. Serving Call Session Control Function (S-CSCF)
Le S-CSCF est le point focal de l’IMS puisqu’il est responsable du processus
d'enregistrement, de la prise de décisions de routage et du maintien des sessions et du
stockage du profil de service (s). Quand un utilisateur cherche à s’enregistrer, la requête
d’enregistrement est envoiyée au S-CSCF qui télécharge les informations d’authentification
au niveau du HSS. Sur la base des données d'authentification il génère un défi pour l'UE.
Après réception et vérification de la réponse le S-CSCF accepte l’enregistrement et
commence la supervision de l’état de l’enregistrement. Après cela, l’utilisateur est prêt à
initier ou à recevoir les services IMS. En outre, le S-CSCF télécharge les profils de services
auprès du HSS lors du processus d’enregistrement de l’utilisateur. Un profil de service est un
ensemble d'informations spécifiques à l'utilisateur qui est stocké de manière permanente
dans le HSS. Le S-CSCF télécharge le profil de service associé à une identité d’utilisateur
public lorsque cette dernière est connectée à l’IMS. Le S-CSCF utilise ces informations du
profil de service pour décider quel serveur d’application contacter lorsque l’utilisateur envoie
ou reçoit une requête SIP d’un autre utilisateur. Le profil de service contient également des
instructions concernant la politique que le S-CSCF doit appliquer (par exemple l’utilisateur
est autorisé à utiliser les services audio et ne l’est pas pour les services vidéo). Le S-CSCF est
responsable des décisions de routage puisqu'il reçoit tous les flux et transactions. Quand il
reçoit une requête initiée par un UE via le P-CSCF, il doit décider si les serveurs
d'applications sont mis en contact avant envoi de la demande plus loin. S’il y a une possible
interaction entre les serveurs d’applications le S-CSCF soit continue une session dans l’IMS
soit renvoie les requêtes à d'autres domaines (CS ou un autre réseau IP). Lorsque l’UE utilise
un numéro MSISDN (Mobile Station ISDN) pour un appel, le S-CSCF convertit le numéro
MSISDN en un SIP URI (SIP Universal Ressource Identifer) avant d’envoyer la requête
puisque l’IMS ne route pas les requêtes basées sur les numéros MSISDN. Parallèlement,
puisque le S-CSCF connait l’adresse IP de l’UE (lors de l’enregistrement), il envoie les
requêtes qui lui sont destinées via le P-CSCF qui s’occupe de la compression SIP et de la
sécurité.

25
Figure 2.3 : Les S-CSCF dans le réseau IMS
2.2.1.4. Emergency Call Session Control Function (E-CSCF)
E-CSCF est une fonctionnalité dédiée pour traiter les demandes d'urgence telles que les
sessions IMS vers la police, les pompiers et les ambulanciers. La tâche principale de l’E-
CSCF est de sélectionner un centre d'urgence également connu sous le nom d'un point de
sécurité publique (Public Safety Answering Point) où l’appel d'urgence sera adressé.
Typiquement, un critère de sélection est l'emplacement de l’utilisateur appelant et le type
possible d'urgence (police, garde-côtes). Une fois le centre d’urgence approprié sélectionné
l’E-CSCF y envoie la demande.
2.2.2. HSS (Home Subscriber Server) : la base de données
Le serveur HSS (Home Subscriber Server) est une entité centralisée qui stocke une base de
données contenant l’ensemble des profils des utilisateurs. Il comporte, entre autres et pour
chaque utilisateur, les informations suivantes :
• localisation des terminaux des utilisateurs abonnés ;
• identité complète des utilisateurs susceptibles d’accéder au réseau IMS ;
• paramètres permettant leur authentification et les informations d’autorisation
d’accès ;

26
• ensemble des services auxquels ils ont souscrits ;
• préférences de services (on peut imaginer toutes sortes de préférences, par exemple la
redirection vers la messagerie d’un utilisateur en fonction de l’heure) ;
• serveur S-CSCF, qui traite les demandes de l’utilisateur (attribué dynamiquement lors
de la connexion de l’utilisateur).
Toutes les données relatives à un même compte utilisateur doivent être stockées sur un même
HSS. Néanmoins, lorsque le nombre d’utilisateurs est important, il est possible de les repartir
au sein de plusieurs HSS. Dans ce cas, il est nécessaire de mettre en place une entité
complémentaire, appelée SLF (Subscription Locator Function), qui a pour rôle de déterminer
le HSS contenant les données relatives à un utilisateur. Les serveurs HSS et SLF
communiquent avec les autres entités du réseau au moyen du protocole Diameter. Le HSS
contient également les fonctionnalités des sous-ensembles de HLR (Home Location Register)
et d’AUC (Authentification Center) requises par un domaine de commutation de paquets
(Packet-Switched , PS) et par un domaine de commutation de circuits(Circuit-Switched , CS).
La structure de l'HSS est illustrée à la figure 2.4.
Figure 2.4 : Structure du HSS
La fonction HLR est nécessaire pour fournir un appui aux entités du domaine PS, comme
SGSN et GGSN. Il permet aux utilisateurs d’accéder aux services du domaine de
commutation de paquets. De la même façon le HLR fournit un soutien pour les entités de
domaine CS, comme les serveurs MSC. Ceci donne l’accès aux services du domaine de
commutation de circuits et prend en charge l'itinérance dans un domaine GSM/UMTS (Global
System for Mobile Communications, UMTS). L’AUC stocke les clés secrètes de chaque
abonné mobile, clés qui sont utilisées pour le chiffrement et l’authentification des mobiles. Le
SLF est utilisé comme un mécanisme de résolution qui permet au I-CSCF, au S-CSCF et au
AS de trouver l’adresse du HSS qui contient les informations à propos d’un utilisateur
lorsqu’il y a plusieurs HSS dans le réseau.

27
2.2.3. MRF (Multimedia Resource Function)
L’entité MRF (Multimedia Resource Function) permet d’établir un pont de conférence entre
les utilisateurs d’un réseau IMS. Son rôle est de gérer la signalisation vers tous les utilisateurs
d’une conférence, en offrant des facilités d’exploitation, comme la sélection des types de flux
— par exemple, si sa bande passante est faible, il est possible de demander uniquement le flux
audio sur son poste, tandis que d’autres utilisateurs disposeront de la vidéo — et la conversion
des formats de codecs — il est possible d’utiliser des codecs différents pour chaque
utilisateur, le MRF adaptant chaque flux aux exigences de chacun. Le MRF a un
fonctionnement semblable à celui de l’entité MCU (Multipoint Control Unit) consacré à
H.323, si ce n’est qu’il manipule une signalisation SIP.
Comme ce dernier, le MRF se décompose en deux entités logiques :
• MRFC (Multimedia Resource Function Controller) : pour la partie signalisation, et
plus précisément la négociation des paramètres sollicités par chaque utilisateur pour la
mise en oeuvre de la conférence ;
• MRFP (Multimedia Resource Function Processor) : pour la partie traitement des flux
de données, c’est-à-dire l’application des demandes formulées par l’utilisateur dans
les flux.
2.2.4. BGCF (Breakout Gateway Control Function)
BGCF (Breakout Gateway Control Function) est un serveur qui communique en utilisant le
protocole SIP. Il sert à préciser le routage des appels initiés par des terminaux IMS vers des
terminaux fonctionnant en mode commutation de circuits (réseaux filaires traditionnels ou
réseau GSM, par exemple).
En considérant qu’un terminal IMS cherche à joindre un correspondant dans le réseau RTC,
deux cas peuvent se produire, selon la compatibilité de l’appareil :
• si l’appareil qui se connecte est compatible avec le réseau du correspondant qu’il
cherche à joindre, le BGCF se charge de mettre en relation les deux entités.

GAGLO Kokou
• sinon, comme l’appareil n’est pas compatible avec le réseau du
cherche à joindre, le BGCF indique des passerelles spécifiques (de type MGCF,
présentées plus loin) responsables d’effectuer la liaison et auxquelles le BGCF relaie
toute la signalisation qu’il reçoit.
2.2.5. IMS-MGW, MGCF et SGW
Avec l’IMS, il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut
bien évidemment le réseau commuté RTC. Pour ce faire, les trois en
2.5 sont introduites. Il s’agit de l’IMS
Ces trois entités se répartissent sur deux plans : un plan de données (couche transport) et un
plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles.
Figure 2.5
2.2.5.1. La passerelle de flux multimédia IMS
GateWay)
Cette entité assure le transport des flux de données d’un réseau IP vers un réseau RTC, en
effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec
sinon, comme l’appareil n’est pas compatible avec le réseau du correspondant qu’il
toute la signalisation qu’il reçoit.
MGW, MGCF et SGW
il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut
bien évidemment le réseau commuté RTC. Pour ce faire, les trois entités illustrées à la figure
sont introduites. Il s’agit de l’IMS-MGW, du MGCF et du SGW.
ités se répartissent sur deux plans : un plan de données (couche transport) et un
Figure 2.5 : Interfonctionnement avec le RTC
La passerelle de flux multimédia IMS-MGW (IMS
GateWay)
effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec
28
correspondant qu’il
il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut
tités illustrées à la figure
ités se répartissent sur deux plans : un plan de données (couche transport) et un
MGW (IMS-Media
effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec le

29
transcodage correspondant (d’un flux RTP vers un flux TDM). C’est donc une passerelle de
flux de données multimédias qui convertit les flux de données multimédias codés en RTP
(dans le réseau IP) en flux de données multimédias codés en TDM (dans le réseau RTC). Elle
se situe sur la couche transport.
Généralement, cette passerelle possède des fonctionnalités complémentaires de traitement du
média, comme la suppression d’écho.
2.2.5.2. Le contrôleur de passerelle MGCF (Media Gateway
Control Function)
Cette entité, qui agit au niveau de la signalisation, assure le passage du mode paquet (IP) au
mode circuit (RTC) en ouvrant, maintenant et fermant des connexions entre les réseaux IP et
RTC et en assurant la conversion des protocoles de signalisation propres à ses réseaux.
Le serveur doit donc convertir un message SIP qui provient du réseau IP en un message ISUP
dans le réseau RTC. Le message ISUP correspondant sera remis à l’entité SGW, présentée
plus loin.
Le MGCF détermine le transcodage des flux de données et contrôle la passerelle de flux
multimédias IMS-MGW. La communication entre le serveur MGCF et le serveur IMS-MGW
se fait au moyen du protocole de signalisation MEGACO/H.248.
Le serveur MGCF doit également informer le serveur S-CSCF des messages de signalisation
qu’il génère pour que ce dernier connaisse les communications et opérations en cours.
2.2.5.3. La passerelle de signalisation SGW (Signaling GateWay)
Comme la précédente, cette entité concerne la partie signalisation. Sa fonction est de
transporter, un message de signalisation ISUP d’un transport SS7 vers SIGTRAN.
Le serveur SGW joue le rôle de passerelle pour la signalisation ISUP. Il est en contact avec
l’entité MGCF qui se charge de remplacer la signalisation ISUP en signalisation SIP.

GAGLO Kokou
2.2.6. TrGW et IMS
Le système IMS doit considérer à la fois un réseau IPv6,
IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS
compatibilité avec IPv4 et met en
communications entre des stations qui communiquent ave
communiquent avec IPv6. De cette manière, le réseau IMS se charge d’effectuer la transition
entre les deux protocoles de manière transparente.
Pour cela, les deux entités illustrées à la figure 2.
GateWay) et IMS-ALG (IMS-
Figure
Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est,
capable de comprendre le message qui lui parvient. L’idée co
entité intermédiaire entre ces deux stations afin d’effectuer la conversion du
les versions 4 et 6.
Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de
données et signalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle
TrGW, qui effectue la translation d’adresses sur les flux de données, et
IMS-ALG, qui effectue la translation d’adresses au niveau de la signalisati
TrGW et IMS-ALG
Le système IMS doit considérer à la fois un réseau IPv6, inévitablement attendu, et un
IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS
compatibilité avec IPv4 et met en œuvre des entités spécialement dédiées aux
communications entre des stations qui communiquent avec IPv4 et des stations qui
entre les deux protocoles de manière transparente.
Pour cela, les deux entités illustrées à la figure 2.6 sont introduites : TrGW (T
-Application Layer Gateway).
Figure 2.6 : Les serveurs IMS-ALG et TrGW
Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est,
capable de comprendre le message qui lui parvient. L’idée consiste à mettre en
entité intermédiaire entre ces deux stations afin d’effectuer la conversion du
ignalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle
TrGW, qui effectue la translation d’adresses sur les flux de données, et
ALG, qui effectue la translation d’adresses au niveau de la signalisati
30
inévitablement attendu, et un réseau
IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS assure la
des entités spécialement dédiées aux
c IPv4 et des stations qui
sont introduites : TrGW (Transition
Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est, à priori, pas
nsiste à mettre en place une
entité intermédiaire entre ces deux stations afin d’effectuer la conversion du protocole IP entre
ignalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle
TrGW, qui effectue la translation d’adresses sur les flux de données, et la passerelle
ALG, qui effectue la translation d’adresses au niveau de la signalisation. Autrement dit,

31
la passerelle TrGW agit sur les messages de données encapsulés par RTP (et les retours
RTCP), tandis que la passerelle IMS-ALG agit sur les messages de signalisation SDP et SIP.
2.2.7. Les serveurs d’application
L'architecture de service consiste en un ensemble de serveurs d'application interagissant avec
le réseau IMS (i.e. S-CSCF) à travers l'interface ISC (IP Multimedia Service Control)
supportée par le protocole SIP.
Les serveurs d'application sont :
• Les serveurs d'application SIP qui exécutent des services (e.g., Push To Talk,
Présence, Conférence, Instant messaging, etc.) et qui peuvent influencer le
déroulement de la session à la demande du service ;
• Le point de commutation au service IMS (IM-SSF, IP Multimedia Service Switching
Function) qui est un type particulier de serveur d'application qui termine la
signalisation SIP sur l'interface ISC d'une part et qui joue le rôle de SSP CAMEL
d'autre part (i.e., il dispose des modèles d'appel O-IM-BCSM et T-IM-BCSM, des
points de détection CAMEL et du protocole CAP) pour interagir avec les plates-
formes de service CAMEL appelées CSE (CAMEL Service Environment) ;
• La passerelle OSA (OSA SCS, OSA Service Capability Server) qui est un type
particulier de serveur d'application qui termine la signalisation SIP sur l'interface ISC
et qui interagit avec des serveurs d'application OSA en utilisant l'API OSA ;
• Un type spécialisé de serveur d'application SIP appelé gestionnaire d'interaction de
service (SCIM, Service Capability Interaction Manager) qui permet la gestion des
interactions entre serveurs d'application SIP.
2.3.Les principaux protocoles et leurs interfaces
2.3.1. Les principaux protocoles
Les trois principaux protocoles utilisés dans l’IMS sont les suivants :

GAGLO Kokou
SIP est le protocole fédérateur de l’architec
aux différents composants de communiquer entre eux de manière homogène.
Diameter, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,
Authorization, Accounting). Il est
notamment lors de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont
transférés d’une base de données vers les serveurs de traitement (nous décrivons plus loin ces
entités). Il fonctionne en mode client/serveur, donc sous la forme de requêtes et de réponses.
COPS (Common Open Policy Service) est un protocole flexible permettant la mise en
de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont
sous formes de règles dans des entités appelées PEP (Policy Enforcement
notamment à permettre aux opérateurs de garantir une qualité de
IMS.
2.3.2. Les interfaces
Figure 2.7 : Les interfaces dans l’arc
Le tableau 2.1 (voir annexe)
quelques unes d’entre-elles.
est le protocole fédérateur de l’architecture IMS. Il est en quelque sorte la glue
, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,
Authorization, Accounting). Il est employé pour la sécurisation des communications,
de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont
base de données vers les serveurs de traitement (nous décrivons plus loin ces
nne en mode client/serveur, donc sous la forme de requêtes et de réponses.
(Common Open Policy Service) est un protocole flexible permettant la mise en
de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont
sous formes de règles dans des entités appelées PEP (Policy Enforcement
notamment à permettre aux opérateurs de garantir une qualité de service dans une architecture
Les interfaces
Figure 2.7 : Les interfaces dans l’architecture IMS
résume les interfaces IMS. Les paragraphes suivant détaillent
32
ture IMS. Il est en quelque sorte la glue qui permet
, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,
employé pour la sécurisation des communications,
de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont
base de données vers les serveurs de traitement (nous décrivons plus loin ces
nne en mode client/serveur, donc sous la forme de requêtes et de réponses.
(Common Open Policy Service) est un protocole flexible permettant la mise en place
de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont appliquées
sous formes de règles dans des entités appelées PEP (Policy Enforcement Point). COPS sert
service dans une architecture
résume les interfaces IMS. Les paragraphes suivant détaillent

33
2.3.2.1. Interface Gm
L’interface Gm connecte l’UE (User Equipment) à l’IMS. Il est utilisé pour transporter tous
les messages de signalisation entre l’UE et l’IMS. Les procédures de l’interface Gm peuvent
être divisées en trois (3) catégories principales : l’enregistrement, le contrôle de session et les
transactions [B3] :
• au cours la procédure d’enregistrement l’UE utilise l’interface Gm pour envoyer une
requête d’enregistrement au P-CSCF en indiquant s’il supporte ou non des
mécanismes de sécurité. Durant la procédure d’enregistrement l’UE échange les
paramètres nécessaires pour l’authentification avec le réseau, récupère les identités
implicites de l’utilisateur connecté, négocie les paramètres de sécurité SA (Security
Associations) et démarre une compression SIP possible.
• le contrôle de session contient les mécanismes pour les sessions initiées par le
terminal source et celle initiée par le terminal destination. Dans le cas des sessions
initiées par le terminal source, l’interface Gm est utilisée pour envoyer les requêtes de
l’UE au P-CSCF. Dans le cas des sessions initiées par le terminal destination, elle est
pour envoyer les requêtes du P-CSCF à l’UE.
• Les procédures de transaction sont utilisées pour envoyer les requêtes (à l’instar de
MESSAGE) et pour recevoir les réponses (exemple : 200 OK).
2.3.2.2. Interface Mw
L’interface Gm relie l’UE à l’IMS (le P-CSCF précisément). Il faudra après une interface
basée sur SIP entre les différentes entités CSCF. Cette interface est appelée le Mw. Les
procédures de l’interface Mw peuvent être divisées en trois (3) catégories principales :
l’enregistrement, le contrôle de session et les transactions [B3] :
• Au cours de la procédure d’enregistrement, le P-CSCF utilise l’interface Mw pour
envoyer les requêtes venant de l’UE à l’I-CSCF. L’I-CSCF utilise à son tour
l’interface Mw pour envoyer la requête au S-CSCF. La réponse du S-CSCF est
également retournée par l’interface Mw.

34
• La procédure de contrôle de session contient les mécanismes pour les sessions initiées
par le terminal source et celle initiée par le terminal destination. Dans le cas des
sessions initiées par le terminal source l’interface Mw est utilisée pour envoyer les
requêtes du P-CSCF vers le S-CSCF et du S-CSCF vers l’I-CSCF. Dans le cas des
sessions initiées par le terminal destination l’interface Mw est utilisée pour envoyer les
requêtes de l’I-CSCF vers le S-CSCF et du S-CSCF vers le P-CSCF.
• Les procédures de transaction sont utilisées pour envoyer les requêtes (à l’instar de
MESSAGE) et pour recevoir les réponses (exemple : 200 OK).
2.3.2.3. Interface ISC (IMS Service Control)
Dans l’architecture IMS, les serveurs d’application sont des entités qui hébergent et exécutent
les services comme la présence, le chat et autres. C’est pourquoi il faut une interface pour
envoyer et recevoir les messages SIP entre le S-CSCF et le serveur d’application. Cette
interface est l’ISC basé sur le protocole SIP. Ses procédures peuvent être divisées en deux (2)
catégories principales : celles qui routent les requêtes SIP initiales vers l’AS (Application
Server) et celle qui gèrent les requêtes initiées par l’AS :
• Après le succès de l’enregistrement dans le réseau, le S-CSCF télécharge le profil de
l’utilisateur du HSS. Une fois que le S-CSCF reçoit une requête SIP, il l’analyse puis
décide vers quel AS envoyer la requête. L’AS traite la requête ou l’envoie à un autre
AS.
• L’AS peut initier une requête à base des actions (triggers) internes ou externe. Par
exemple l’initiation de publication d’information de présence d’un certain AS vers le
serveur de présence.
2.3.2.4. Interface Cx
Les données concernant les utilisateurs et les services sont permanemment sauvegardées dans
le HSS. Ces données centralisées sont utilisées par l’I-CSCF et le S-CSCF lorsque les
utilisateurs s’enregistrent ou reçoivent des sessions. Pour ce faire, il existe une interface entre
l’HSS et les CSCF. Cette interface est appelée le Cx et est basée sur le protocole Diameter.

35
Ces procédures peuvent être divisées en trois catégories : la localisation, la gestion des
données des utilisateurs et l’authentification des utilisateurs. Le tableau 2.2 résume les
commandes Cx disponibles.
2.3.2.5. Interface Sh
Un AS (SIP AS ou OSA SCS) a besoin de données (relatives à une identité particulière de
l’abonné ou relatives à l’identité public d’un service) ou a besoin de savoir à quel S-CSCF
envoyer une requête SIP. Ces genres d’informations sont stockés dans le HSS. C’est pourquoi
il faut une interface entre le HSS et l’AS. Cette interface est la Sh et est basée sur Diameter.
Ces procédures sont divisées en deux (2) catégories : gestion des données et
souscription/notification. Le tableau 2.3 résume les commandes Sh disponibles. Le HSS a une
liste d’AS qui sont autorisés à obtenir ou sauvegarder des données.
2.3.2.5.1. La localisation
Quand l’I-CSCF reçoit une requête SIP REGISTER du P-CSCF via l’interface Mw, la
commande UAR (User-Authorization-Request) est invoquée. A la réception de la commande
UAR, le HSS répond par une commande UAA (User-Authorization-Answer) qui contient le
nom du S-CSCF ou les S-CSCF disponibles selon le statut courant de l’utilisateur. Les S-
CSCF disponibles sont envoyés si c’est la première fois que l’utilisateur se connecte et n’a
pas de S-CSCF associé dans la base HSS. Après cela, l’I-CSCF renvoie une requête SIP
REGISTER au S-CSCF renvoyé ou sélectionné.
2.3.2.5.2. La gestion des données des utilisateurs
Durant la procédure d’enregistrement, les données concernant l’utilisateur et les services
auxquels il a souscrit seront téléchargées depuis le HSS par le S-CSCF. Cependant il est
possible que ces données changent pendant que le S-CSCF sert toujours l’utilisateur. Pour
mettre à jour ces données au niveau du S-CSCF, le HSS initie une commande PPR (Push-
Profile-Request). La mise à jour est effectuée immédiatement.

36
2.3.2.5.3. L’authentification des utilisateurs
L’authentification des utilisateurs IMS est basée sur un secret partagé préconfiguré. Le secret
partagé et les séquences de nombre sont stockés dans l’ISIM (IP Multimedia Service Identity
Module) ou l’USIM (UMTS Subscriber Identity Module) dans l’UE et dans le HSS dans le
réseau. Parce que le S-CSCF s’occupe de l’authentification de l’utilisateur, il existe un besoin
de transférer des données de sécurité par l’interface Cx. Lorsque le S-CSCF a besoin
d’authentifier un abonné, il envoie une commande MAR (Multimedia-Auth-Request) au HSS.
Le HSS répond par une commande MAA (Multimedia-Auth-Answer). La réponse contient
entre autre l’information d’authentification. Elle inclut un ou plusieurs vecteurs selon
l’algorithme utilisé (exemple Digest-AKAv1-MD5), l’information d’authentification (le
challenge RAND d’authentification et la valeur AUTN prise), l’information d’autorisation
(expected response ou XRES), la clé d’intégrité et la clé de confidentialité
2.3.2.5.4. Gestion des données
La gestion des données donne la possibilité de récupérer des données depuis le HSS. Ces
données peuvent contenir des données relatives au service (transparent ou non transparent),
des informations d’enregistrement, des identités publiques, des filtres, le nom du S-CSCF qui
s’occupe de l’utilisateur, des adresses des entités qui s’occupent de la facturation et même des
informations de localisation provenant de domaines paquets ou circuits. L’AS utilise la
commande UDR (User-Data-Request) pour demander des données et le HSS répond par la
commande UDA (User-Data-Answer).
2.3.2.5.5. Souscription/Notification
Ces procédures de souscription/notification permettent à l’AS d’avoir des notifications quand
une donnée particulière d’un utilisateur spécifique a été mise à jour dans le HSS. L’AS envoie
la commande SNR (Subscribe-Notifications-Request) pour recevoir les notifications et le HSS
répond par la commande SNA (Subscribe-Notifications-Answer).

37
2.4.Les identités IMS
Le réseau IMS reprend la notion d’identités publique et privée, qui est propre aux réseaux à
commutation de circuits des télécoms. L’identité publique d’un utilisateur désigne un URI
(SIP ou de type téléphonique) affecté publiquement à l’utilisateur et utilisé par les
correspondants de ce dernier pour le désigner, et donc le joindre. Dans la terminologie
télécoms, ce concept est l’équivalent du MSISDN (Mobile Subscriber ISDN Number) [B2].
Par exemple, si un utilisateur dispose d’une adresse professionnelle et d’une adresse privée, il
dispose de deux identités publiques correspondant à chacune de ses adresses.
De plus, même si l’utilisateur ne dispose que d’une adresse privée, celle-ci peut se présenter à
la fois sous la forme d’un URI SIP et d’un URI téléphonique. La première forme (au format
sip:identifiant@operateur) est adaptée au protocole SIP qu’exploite l’IMS et est donc
préférable de manière générale. La seconde (au format tel:+221776814199) est indispensable
pour être joignable à partir de terminaux non-IMS, qui ne disposent que de chiffres pour
joindre leurs correspondants et ne sont joignables que par un numéro d’appel.
L’identité privée d’un utilisateur désigne un identifiant au format NAI (Network Access
Identifier) qui est de type identifiant@operateur. Elle est affectée secrètement à l’utilisateur et
est utilisée par l’opérateur pour désigner ce dernier. Dans la terminologie télécoms, ce concept
est l’équivalent de l’IMSI (International Mobile Subscriber Identifier).
Par exemple, si un utilisateur dispose de plusieurs identités publiques, il peut toutes les gérer à
partir d’un compte unique (d’une identité privée) et donc d’un terminal unique, lequel recevra
les appels destinés à l’utilisateur, et ce quelle que soit l’identité publique avec laquelle les
appels sont adressés. L’identité privée est avant tout utile pour permettre l’identification et
l’authentification de l’abonné par l’opérateur.
De la même manière qu’une identité privée peut être liée à plusieurs identités publiques, une
identité publique peut être liée à plusieurs identités privées. Par exemple, considérons un
utilisateur qui dispose de deux terminaux IMS, le premier étant professionnel, le second privé,
et de deux identités publiques, là aussi, une professionnelle et l’autre privée. Chacun des
terminaux de cet utilisateur sera configuré avec une identité privée. Il peut décider de ne
recevoir, sur le premier terminal, que les appels professionnels (c’est-à-dire liés à son profil

38
public professionnel), tandis que, sur le second terminal, il décidera de recevoir tous les
appels (c’est-à-dire à la fois ceux liés à son compte professionnel et ceux liés à son compte
personnel).
Ainsi certaines identités privées sont-elles liées à plusieurs identités publiques, et certaines
identités publiques à plusieurs identités privées.
2.5. Enregistrement d’un terminal dans le réseau
L’enregistrement d’un utilisateur dans le réseau est la première action réalisée par un
terminal, dès sa mise en route. Elle est indispensable puisqu’elle permet à la fois d’appeler et
d’être joignable par ses correspondants.
La méthode associée à cette fonctionnalité est REGISTER, du protocole de signalisation SIP.
La figure 2.8 illustre les étapes temporelles liées au scénario d’enregistrement.

39
Figure 2.8 : Processus d’enregistrement d’un terminal
2.6.La fourniture de services dans l’IMS
L’IMS a une architecture qui se base sur le protocole SIP pour offrir des services et
applications IP dans le réseau paquet. L'IMS fournit les éléments nécessaires à l'invocation
des services: c'est le «service provisionning» qui se base sur deux notions essentielles:
les profils utilisateurs
le(s) serveur(s) d'application (AS)

GAGLO Kokou
2.6.1. Le profil utilisateur
Lorsqu'un utilisateur souscrit à un abonnement IMS chez un opérateur, l'opérateur lui assigne
un profil utilisateur. Ce profil utilisateur contient au moins une
service. Il est à noter qu'un abonnement IMS peut concerner plusieurs profils de services ce
qui permet d'avoir des traitements selon les identités publiques par exemple.
2.6.2. Le profil de service
Un profil de service est un ens
utilisateur particulier.
Figure
Ces informations sont transférées du HSS vers le S
opérations qui sont le SAA et PPR
Diameter au format XML. Il est constitué de trois parties.
Le profil utilisateur
un profil utilisateur. Ce profil utilisateur contient au moins une identité privée et un profil de
Le profil de service
Un profil de service est un ensemble d'informations stocké dans le HSS et qui concerne un
Figure 2.9 : Structure d’un profil utilisateur
Ces informations sont transférées du HSS vers le S-CSCF qui sert l'utilisateur à travers deux
et PPR.
Le profil de service est transmis sous la forme d'une AVP
est constitué de trois parties.
40
identité privée et un profil de
emble d'informations stocké dans le HSS et qui concerne un
CSCF qui sert l'utilisateur à travers deux
Le profil de service est transmis sous la forme d'une AVP

GAGLO Kokou
2.6.2.1. L'identification publique
Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de
service. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque
identité publique contient une information d'interdiction qui lorsqu'elle est positionnée
indique au S-CSCF d'interdire l'utilisation de cette identité publique dans une com
IMS autre que l'enregistrement ou le réenregistrement.
2.6.2.2. La politique media
Cette information est transportée dans l'autorisation de service du réseau cœur (Core
Network). Elle contient un entier qui indique le profil media auquel l'abonné a sous
S-CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils
d'abonnés au sein de leur réseau IMS. Le S
statique qui fait la correspondance entre l'entier et le profil media.
pas standardisée et est fonction de l'opérateur.
2.6.2.3. Le déclenchement des services
L'information sur le déclenchement des services se présente sous la forme d'une IFC (Initial
Filter Criteria). Une IFC décrit quand et comment une
particulier.
L'identification publique
vice. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque
CSCF d'interdire l'utilisation de cette identité publique dans une com
IMS autre que l'enregistrement ou le réenregistrement.
La politique media
Network). Elle contient un entier qui indique le profil media auquel l'abonné a sous
CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils
d'abonnés au sein de leur réseau IMS. Le S-CSCF a besoin alors d'une basse de données
statique qui fait la correspondance entre l'entier et le profil media. La valeur de l'entier n'est
pas standardisée et est fonction de l'opérateur.
Le déclenchement des services
Filter Criteria). Une IFC décrit quand et comment une requête est transmise vers un AS
Figure 2.10 : Structure d'un IFC
41
vice. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque
CSCF d'interdire l'utilisation de cette identité publique dans une communication
Network). Elle contient un entier qui indique le profil media auquel l'abonné a souscrit dans le
CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils
CSCF a besoin alors d'une basse de données
La valeur de l'entier n'est
requête est transmise vers un AS

42
Le premier champ d'une IFC c'est sa priorité. Le champ priorité définit comment cette IFC
sera évaluée par rapport aux autres IFC appartenant au même profil de service. Le S-CSCF
choisit en premier l'IFC avec la plus grande priorité (plus le champ priorité est moins grand
plus l'IFC est prioritaire).
Après les IFCs, on trouve au plus un « Trigger Point ». Un trigger point est une expression qui
détermine si une requête SIP doit être transmise à un AS spécifique. Il est constitué d'un
ensemble de filtres appelés « Service Point Trigger » (SPT).
Le SPT nous permet d'accéder à différentes informations de la requête SIP :
• la valeur de la Requête URI
• la méthode de la requête (ex : INVITE, MESSAGE)
• la présence ou l'absence d'un en-tête SIP particulier
• le type de session (requête initiée par un utilisateur servi, destinée à un utilisateur
enregistré ou à un utilisateur non enregistré)
• la description de la session (contenu SDP)
Les SPTs peuvent être liées par des expressions logiques (AND, OR, NOT). S'il n'y a aucun
Trigger Point alors toute requête est transmise automatiquement à l'AS.
Après les « Trigger Point » (constitués de SPT), on trouve l'URL de l'AS qui recevra la
requête si les conditions des SPT sont respectées. On trouve aussi un champ qui décrit ce qu'il
faut faire (continuer ou annuler le traitement) au cas où l'AS ne peut pas être contacté.
Chapitre 6 : Déploiement
des services

43
3. LES SERVICES IMS
3.1. Présence
La présence est faite essentiellement de deux choses : elle implique de mettre à la disposition
des autres mon statut et que le leur aussi me soit disponible.
Figure 3.1 : Aperçu de la présence
3.1.1. Le service de présence dans l’IMS
L’architecture du service de présence (basée sur celle d’OMA : Open Mobile Alliance)
présente les blocs suivants :
• « Presence Server » : un serveur d’application IMS qui gère les informations de
présence chargées par les différentes sources de présence et répond aux réponses de
souscription.
• « Resource List Server » : un serveur d’application IMS qui accepte et gère les
souscriptions aux listes de présence.
CHAPITRE 3

44
• « XML Document Management Servers » : des serveurs d’application qui sauvegarde
les données relatives au service de présence. Quatre différents AS sont définit :
o Presence XDMS : un serveur qui contient les règles pour les informations de
souscription et les règles pour les informations de publication.
o RLS XDMS : un serveur qui contient la liste des contacts d’un utilisateur.
o Presence Content XDMS : un serveur qui gère les fichiers média pour le
service de présence.
o Shared XDMS : un serveur qui peut être réutilisé par différents serveurs
d’application.
• « Content Server » : une entité qui est capable de gérer les types d’objet MIME pour
la présence en permettant à la source de présence ou au serveur de présence de stocker
des objets de type MIME.
• « Presence source » : une entité qui fournit les informations de présence au service de
présence. La source de présence peut être localisée au niveau du terminal de
l’utilisateur ou dans une entité du réseau.
• « Presence watcher » : une entité qui demande les informations de présence à propos
des ressources.
• « Watcher agent » : une entité qui contrôle l’utilisation des « Presence Watchers »
dans le domaine.
• « Watcher Information Subscriber » : une entité qui demande les informations à
propos des statuts de présence auprès du service de présence
La figure 3.2 présente l’architecture de la présence avec un terminal comme source de
présence.

45
Figure 3.2 : Architecture de la présence
3.1.2. Publication des informations de présence
Pour publier ou mettre à jour des informations, la source de présence charge les informations
en utilisant la méthode SIP PUBLISH au niveau du serveur de présence.
Figure 3.3 : Publication de présence

46
3.1.3. Souscription au service de présence
Pour obtenir des informations à propos des autres utilisateurs, le watcher (Alice) souscrit au
service de présence en envoyant une requête SIP SUBSCRIBE dans laquelle il peut être
spécifié un utilisateur particulier ou une liste d’utilisateur donnée (exemple :
sip :friends@example.com qui contient les utilisateurs Bob et Sarah). Dans le dernier cas, la
requête sera redirigée vers le RLS qui va autoriser la souscription d’Alice ensuite souscrire
Alice aux informations de Bob et Sarah de façon individuelle.
Figure 3.4 :Souscription aux informations de présence

47
3.2.Gestion de groupe
La gestion de groupe est un service qui permet aux utilisateurs de stocker des données
spécifiques à un service dans le réseau du fournisseur. Ces données peuvent être créées,
modifiées et supprimer à tout moment par l’utilisateur. Plusieurs services comme la présence,
le PoC (Push to Talk over Cellular), ont besoin de ce support pour l’accès et la manipulation
de certaines données dont ils ont besoin. Comme exemples de ces données on peut citer la
liste des utilisateurs qui sont des potentiels « notifiers », liste qui peut permettre à un autre
utilisateur de souscrire aux informations de présence de ce groupe d’utilisateurs ; le document
contenant les règles d’accès d’un utilisateur spécifique à une ressource ; les données de
configuration pour les services IMS supplémentaires à l’instar du renvoie d’appel vers un
numéro spécifique lorsque l’utilisateur est injoignable.
Les données sont sauvegardées dans le réseau et sont accessibles, manipulables par les
utilisateurs autorisés.
OMA a adopté le terme XDM (XML Document Management) comme synonyme du terme
gestion de groupe. Les services XDM spécifient les documents qui peuvent être partagés par
de multiples services.
Le XCAP (XML Configuration Access Protocol) défini par l’IETF (Internet Engineering
Task Force) a été choisi par OMA et 3GPP (Third Generation Partnership Project) comme le
protocole pour transporter, accéder, lire et manipuler les documents XML qui contiennent les
données.
3.2.1. XML Configuration Access Protocol
Dans l’Extensible Markup Language (XML) Configuration Access Protocol (XCAP) un
utilisateur est capable de charger des informations sur le serveur XCAP qui met ces dernières
à la disposition des serveurs d’application qui les utilisent pour satisfaire la demande d’autres
utilisateurs. Avec XCAP, l’utilisateur est également autorisé à manipuler, ajouter et effacer
ces données. Un exemple de donnée que l’utilisateur peut charger est sa liste de ressources
pour la présence. XCAP utilise le HTTP (HyperText Transfert Protocol) pour charger et lire
les informations générées par les utilisateurs. Ces informations sont représentées à base du
XML.

48
Il existe quatre (4) opérations héritées du HTTP pour créer (HTTP PUT), chercher (HTTP
GET), modifier (HTTP PUT) et effacer (HTTP DELETE).
Figure 3.5 : Les opérations XCAP
3.2.2. La liste de ressources
Les spécifications SIP à propos du mécanisme notification des événements permet à un
utilisateur de demander des notifications sur l’état d’une ressource lorsqu’il change. Sans
aucun mécanisme cela entrainerait que l’abonné génère des requêtes SIP SUBSCRIBE pour
chaque ressource. Pour contrôler les congestions et gérer la bande passante, il n’est pas bon
d’avoir des terminaux générant de multiples requêtes SUBSCRIBE, une pour chaque
ressource. Pour résoudre ce problème la RFC4662 décrit une extension de notification
d’événements qui donne la possibilité aux utilisateurs de souscrire à une liste de ressources
avec une seule requête SUBSCRIBE. Cette liste est identifiée par un URI et contient zéro ou
plusieurs URI pointant vers des ressources atomiques ou d’autres listes. Dans un système de
présence ces ressources sont les statuts de présences (presentities en anglais). L’entité qui
envoie la requête SUBSCRIBE pour la liste est le RLS (Resource List Server). Le RLS peut
générer des souscriptions individuelles pour chaque ressource de la liste. Cette souscription
peut ou ne pas être des requêtes SIP SUSCRIBE. La figure 3.6 montre la solution.

49
Figure 3.6 : Exemple de flux de souscription avec RLS
Un client envoyant la requête SUBSCRIBE pour une liste inclut un en-tête Supported avec un
tag d’option avec la valeur ‘eventlist’. Si cette option tag n’est pas incluse et l’URI dans la
requête représente une liste alors le RLS retourne une erreur ‘421 Extension Required’. Si la
souscription est acceptée le RLS génère une requête NOTIFY contenant les informations sur
l’état de la liste. La requête NOTIFY contient l’en-tête Require avec une option tag avec la
valeur ‘evntlist’. Il contient aussi un corps de type MIME ‘multipart/related’ qui en interne
transporte une MIME ‘application/rlmi+xml’ qui contient les meta-informations de la liste de
ressource.
Comme exemple, Alice utilise deux terminaux, un à la maison et un au bureau. Elle crée sa
liste de ressource avec son terminal à la maison et ajoute Bob et Sarah comme ses contacts.
La requête XCAP suivante est créée pour envoyer la liste de ressource (contacts) sur le
serveur :
PUT /resource-lists/users/sip:alice@example.com/friends HTTP/1.1
Content-Type:application/resource-lists+xml
Host: xcap.example.com
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
<entry uri="sip:bob@example.com">
<display-name>Bob</display-name>
</entry>
<entry uri="sip:sarah@example.com">

50
<display-name>Sarah</display-name>
</entry>
</list>
</resource-lists>
Alice une fois arrivée au bureau décide d’ajouter John à ses contacts. Elle le fait en utilisant
son terminal au bureau et modifie la liste qu’elle a créée plus tôt à la maison. La figure 3.7
résume l’exemple.
Figure 3.8 : Exemple de liste de ressources
3.3.Push to Talk Over Cellular
Le service Push to Talk Over Cellular permet à un utilisateur de passer des appels d’un
utilisateur à un autre utilisateur ou d’un utilisateur à un groupe d’utilisateurs. L’idée est
simple. L’appelant sélectionne un correspondant ou un groupe qu’il veut joindre, il appuie sur
la touche dédié au PoC et commence à parler. La session établie est temps réelle. Les
sessions Push to Talk sont des communications unidirectionnelles : quand une personne parle
les autres écoutent. Le tour de parole est demandé en appuyant la touche PoC dédiée et est
obtenu selon la règle du premier venu, premier servi. Les appels Push to Talk sont assez
souvent établis sans que les correspondants ne décrochent et utilisent le haut parleur du
téléphone de l’appelé. Un utilisateur peut éventuellement choisir de recevoir un appel Push to
Talk à condition qu’il ait accepté l’invitation. La conservation peut aussi être écoutée à travers
les écouteurs du téléphone si besoin est.

51
Le service Push to Talk est basé sur du multi ou unicasting. Le client envoie le paquet du
trafic au serveur d’application Push to Talk qui, dans le cas d’un multicasting, duplique le
trafic pour tous les correspondants (voir figure 3.9). Une session de control PoC et les autres
signalisations sont basées sur SIP et le trafic voix est transporté par RTP/RTCP (Real-Time
Transport Protocol/Real-Time Transport Control Protocol).
Le service PoC utilise mieux les ressources radio et les ressources cellulaires que les services
basés sur les circuits. Il fournit une meilleure couverture puisqu’il utilise celle fournie par les
réseaux GSM/WCDMA/CDMA. Les paragraphes qui suivent décrivent le PoC définit par le
standard OMA PoC Release 1.
Figure 3.9 : Push to Talk Over Cellular
3.3.1. Architecture du PoC

Mise en place d’une plateforme de formation IMS

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Mise en place d’une plateforme de formation IMS

Semelhante a Mise en place d’une plateforme de formation IMS (20)

Mais de Kokou Gaglo

Mais de Kokou Gaglo (11)

Mise en place d’une plateforme de formation IMS