Final 150827004742 Lva1 App6891

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
Ministère de l’Enseignement Supérieur et de laRecherche Scientifique
Université des Sciences et de la Technologie Houari Boumediene
U!1.D9-/ ~J 19lD ii...A..DL.:;1

4;J9-l9-iLiJ19 ,a9-LJ:L..l.l
USTHB
Faculté d’Electronique et Informatique
Département de Télécommunications
Mémoire de MASTER
Domaine : Sciences et Technologie
Filière : Télécommunications
Spécialité : Télécommunication. Réseau et Multimédia
THEME
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP

OVER LTE, DIMENSIONNEMENT ET MESURE DE LA
QoS
Encadré par : Mme MERAZKA Fatiha

M. HAKIMI Fouad
Présenté par : NAOUI Khaled

BENAHMED Sidali
Devant le jury composé de :
Président : M. AMROUCHE Abderrahmane

Examinateur : M. DERRAS Mohamed
Promoteur : Mme. MERAZKA Fatiha
Co-promoteur : M. HAKIMI Fouad
Promotion : 2014-2015
Remerciements
Nous remercions ALLAH le tout puissant et miséricordieux, pour nous avoir donné le
courage, la force ainsi que la capacité de pouvoir mener jusqu’au bout ce modeste travail.
Nous adressons nos sincères remerciements à notre promotrice Mme Merazka Fatiha,
Professeur à l'USTHB, pour ses nombreux conseils, son aide précieuse et sa compréhension
durant l'élaboration de ce projet.
Nous tenons à exprimer notre profonde gratitude à notre encadreur M. HAKIMI Fouad
au sein d’Algérie Télécom qui a accepté de nous accompagner durant ce stage. Nous le
remercions pour sa patience à notre égard et sa disponibilité durant toute cette période.
Nos remerciements s’adressent aussi à tout le personnel d’Algérie Télécom pour leur
accueil.
Nous tenons à remercier les membres du jury: le président de jury M. AMROUCHE

ainsi que l’examinateur, M. DERRAS, pour avoir bien voulu nous faire l’honneur d’être
membre de notre jury. Nous ferons l’honneur d’apprécier et de prendre connaissance de toutes
éventuelles critiques et corrections de leur part.
Enfin, nous remercions toute personne qui a contribué de près ou de loin à l’élaboration
de ce travail.
SOMMAIRE
Introduction général……………....................................................................................... 1
Chapitre I : Généralités
I. Introduction………………………………………….…………………………….. 2
II. Les différentes technologies de la téléphonie mobile …………..……………….... 2
II.1. La première génération des téléphones mobiles (1G) ……………………….. 2
II.2. La deuxième génération des téléphones mobiles (2G)….........….....……..….. 3
II.1.1. Le sous-système radio BSS……………………………………………. 3

II.1.2. Le sous-système d’acheminement NSS………………………….……. 3
II.1.3. Le sous-système d’exploitation et de maintenance « OSS »………...... 4
II.3. Le réseau GPRS (2.5G) ………………………………………………………. 4
II.4. La troisième génération des téléphones mobiles 3G UMTS)…………………. 5
II.4.1. Architecture du réseau UMTS …............................................................ 6
II.4.2. L’entité d'un réseau UMTS…………………………………………… 6
II.4.3. Le débit de l'UMTS…………………………………………………….. 7
II.5. La quatrième génération des téléphones mobiles 4G (LTE)………………….. 7
II.5.1. Performances du LTE ………………….………………….…….…… 8
II.5.2. Caractéristiques et entités du réseau EPS …………………………… 9
II.5.3. Architecture du réseau EPS ………………………………………….. 10
II.5.3.1. Entité eNodeB ……………………………………………… 11
II.5.3.2. Entité MME (Mobility Management Entity)……………… 12
II.5.3.3. Entité Serving GW (Serving Gateway)…………………… 13
II.5.3.4. Entité PDN GW (Packet Data Network Gateway)…........... 14
II.5.3 .5. Entité HSS (Home Subscriber Server) ….............................. 15
II.5.3.6. Entité PCRF (Policy & Charging Rules Function)………… 15

III. Les procédures d’attachement et détachement au réseau EPS …………………… 15
III.1. Attachement de l’UE au réseau EPS …………………………………………. 15
III.2. Détachement de l’UE au réseau EPS ………………………………………… 16
IV. Conclusion………………..……….……...……….………………..……..…......... 16
Chapitre II : La voix sur LTE
I. Introduction…..……..…………….………………......……………..………............. 17
II. CSFB (Circuit Switched FallBack) …................................................................... 17
III. VoLGA (Voice Over LTE via Generic Access)..………………………….……….. 19
IV. VoLTE (voice over LTE) via IP Multimedia Subsystem…………………………… 20
IV.1. L’architecture IMS…………………………………………………………. 21
IV.1.1. La couche accès ……………………………………………………. 21
IV.1.2. La couche de transport ……………………………………………… 21
IV.1.3. La couche de contrôle …………………………………………….. 22
IV.1.4.La couche application ……………………………………………….. 25
V. Le modèle protocolaire ……………………………………………………………. 26
V.1. La notion de ‘Bearer’ et QCI …………………………………………………… 26
V.2. Etablissement de dedicated bearer pour les services IMS ………………….. 27
VI. Protocoles mise en œuvre en VoLTE …………………………………………….. 28
VI.1. Le protocole DIAMETER …………………………………………………. 28
IV.1.1. Les messages DIAMETER ………………………………………….. 29
VI.2. Le protocole SIP …………………………………………………………….. 30
VI.2. 3 Les requêtes ………………………………………………………..... 30
VI.2.4 Les réponses …………………………………………………………. 32
VI.2.5 Les en-têtes ……………………………………………………………. 33

VI.3. Le protocole SDP…………………………………………………………… 34
VI.4. Les protocole RTP et RTCP………………………………………………… 35
VI.4.1. Le protocole RTP…………………………………………………... 35
VI.4.2. Le protocole RTCP……………………………………………….... 35
VI.5. Le protocole MEGACO…………………………………………………… 35
VI.6. Codage des signaux …………………………………………………………. 36
VII. L’établissement d’une communication dans le réseau IMS……………………… 36
VII.1. Enregistrement d’un terminal dans le réseau IMS…………………………. 36
VII.1.2. Première étape d’enregistrement…………………………………. 37
VII.1.1. Deuxième étape d’enregistrement ……………………………….. 38
VII.2. Mise en relation de deux utilisateurs VoLTE ……………………………. 39
VIII. Conclusion ………………………………………………………….……….…… 41
Chapitre III : Réalisation pratique
I. Introduction …………………………………………...……………………….…..…. 42
II. Open Source IMS core………..…...…………………………………………………. 42
II.1. Architecture et conception de banc d’essai …………………………………... . 43
III. Métriques de performance d’IMS …………………………………………………... 44
III.1. Demande d’enregistrement……………………………………………………. 45
III.1.1. Délai d’enregistrement (RRD) ……………………………………… 45
III.2. Etablissement d’une session audio, vidéo…………………………………… 46
III.2.1. Délai d’établissement d’une session audio(SRD) ………..………… 48

III.2.2. Délai du flux RTP…………….…………….…………….…..……… 48
III.2.3. Gigue du flux RTP …………….…………….…………...…………... 48
III.2.4. Bande passante du flux RTP(BW) …………….…………………… 48
IV. Mesure de la bande passante des différents codecs ……………………………… 48

IV.1. Débits des codecs audio …………………………………………………… 50
IV.2. bande passante des codecs vidéo ………………………………………….. 50
V. La gigue des différents codecs …………………………………………………….. 51
V.1. la gigue des codecs audio ……………………………………………………. 51
V.1. la gigue des codecs vidéo…………………………………………………….. 52
VI. Mean Opinion Score (MOS)………………………………………………………. 53
VII. Etablissement d’une session data……………………………………….………. 54
VII.1. Délai d’établissement d’une session data…………………….…………... 54
VIII. Les services supplémentaires ……………………………………………………... 55
VIII.1. Le service de présence …………………………………………………….. 55
VIII.1.1. le processus de présence …………………………………………. 55
VIII.2. Le service IPTV …………………………………………………………… 55
VIII.2.1. le processus de service IPTV ……………………………………. 57
IX. appel vers l’extérieur………………………………………………………………. 59
X. Conclusion …………………………………………………………………………… 61
Conclusion général………………………………………………………………………. 62
Annexe
Bibliographie
List des Figures
Figure 1.1 : Architecture du réseau GSM.……………………………………………...... 3
Figure 1.2 : Architecture du réseau GPRS.……………………………………………..... 5
Figure 1.3 : Architecture du réseau UMTS ……………………………………………….. 6
Figure 1.4 : Architecture de réseau EPS…………………………………………………. 10
Figure 1.5 : Architecture E-UTRAN……………………………………………………... 11
Figure 2.1 : La solution CSFB (Circuit Switched Fallback)……………………………... 17
Figure 2.2: La solution voLGA (Voice Over LTE via Generic Access)………………… 19
Figure 2.3 : La solution voLTE (voice over LTE)……………………………………….. 20
Figure 2.4 : L’architecture de réseau IMS……………………………………….............. 21
Figure 2.5 : Le modèle protocolaire…………………………………………………….... 26
Figure 2.6 : Création d’un dedicated bearer pour la VoLTE…………………………….. 28
Figure 2.7 : Processus d’enregistrement d’un terminal avec l’IMS……………………… 37
Figure 2.8 : Mise en communication de deux terminaux………………………………… 39
Figure 3.1 : Architecture d’OpenIMSCore………………………………………………. 42
Figure 3.2 : Architecture de banc d’essai………………………………………………… 44
Figure 3.3 : les messages SIP mise en jeu pendant le processus d’enregistrement……… 45
Figure 3.4 : Procédure d’enregistrement capturé avec SIPWorkbench………………….. 46
Figure 3.5 : exemple d’un appel vocal..………………………………………………….. 47
Figure 3.6 : les messages SIP mise en jeu pendant et à la fin d’une session vocale……... 47
Figure 3.7 : la bande passante de codec G.711 (PCMA)………………………………… 49
Figure 3.8 : la bande passante de codec GSM…………………………………………… 49
Figure 3.9: la bande passante de codecAMR (G.722.2) « 12.65 Kbps »………………… 50
Figure 3.10 : la bande passante de codec H.264………………………………………..... 50
Figure 3.11 : La gigue mesurée pour un codec G.711 (PCMA)………………………..... 51

Figure 3.12 : La gigue mesurée pour un codec GSM…………………………………..... 52
Figure 3.13: La gigue mesurée pour un codec AMR (12.65 kbps)………………………. 52
Figure 3.14 : La gigue mesurée pour un codec h.264……………………………………. 53
Figure 3.15 : les messages SIP mise en jeu pendant l’envoi d’un message……………… 54
Figure 3.16 : les messages SIP publie pendant le processus de présence………………... 55
Figure 3.17 : Procédure de présence capturée avec SIPWorkbench……………………... 56
Figure 3.18 : exemple de présence entre deux clients……………………………………. 56
Figure 3.19: Architecture de services d’IPTV…………………………………………… 57
Figure 3.20 : les messages SIP échangé pendant le processus IPTV…………………….. 58
Figure 3.21 : fonctionnement d’IPTV capturée avec SIPWorkbench……………………. 58
Figure 3.22 : test de fonctionnement d’IPTV…………………………………………...... 59
Figure 3.23 : fichier de configuration de S-CSCF……………………………………….. 60
Figure 3.24 : appel d’un client IMS vers un client non IMS……………………………... 60
List des Tableaux
Tableau 2.1 : les différents types des bearers et QCI…………………………………….. 27
Tableau 2.2 : Les types de réponses……………………………………………………... 32
Tableau 2.3 : Le protocole SDP………………………………………………………….. 34
Tableau 3.1 : Mean opinion score (MOS)……………………………………………….. 53

Introduction
Générale
Introduction générale
Introduction générale
Les réseaux mobiles et sans fil ont connu un essor sans précédent ces dernières années. Il s’agit
d’une part du déploiement de plusieurs générations successives de réseaux de télécommunications
essentiellement dédiés à la téléphonie (deuxiéme génération), puis plus orientés vers le
multimédia ( troisiéme génération). La quatriéme génération de réseaux sans fil apporte une
véritable augmentation du débit et permet l’interopérabilité avec les autres réseaux.
Le service téléphonique est rempli à partir de deux fonctions de base : le transport de la voix et le
traitement de la signalisation téléphonique. Cette dernière n’est pas supportée par le réseau 4G
appelé EPS (Evolved Packet System) car ce réseau utilise uniquement la commutation de paquet.
Le terme Voix sur LTE ou VoLTE (Voice over LTE) est le terme consacré pour désigner le
transport de la voix assuré par le réseau EPS, dans le cadre de la fourniture du service téléphonique.
La Voix sur LTE est mise en œuvre par l’association du réseau EPS pour le transport des paquets IP
( contenant la voix ou la signalisation téléphonique ), et du réseau IMS (IP Multimedia Sub-system)
pour le traitement de la signalisation téléphonique.
Ce mémoire est divisé en trois chapitres :
Le premier chapitre présente les différentes normes et générations de téléphonie mobile. On

commencera tout d’abord par l’ancienne génération la plus répondue dans le monde la 2G (GSM),
ensuite on passera à la 2.5G (GPRS), après on présentera les réseaux 3G (UMTS) et 4G (LTE).
Le deuxième chapitre sera concentré sur l’étude des solutions qui offrent le service téléphonique sur
les réseaux de quatrième génération et principalement la solution VoLTE via l’IMS.
Le dernier chapitre sera consacré à la mise en place d’une solution IMS pour la VoLTE basée sur
une plateforme IMS open source, avec d’autres services comme IPTV, Présence, puis on effectuera
des tests sur la qualité de service QoS.
Enfin une conclusion générale termine ce mémoire ainsi que des recommandations pour illustrer les
perspectives de notre travail.
1
CHAPITRE I
Chapitre 1 : Généralité sur les réseaux mobiles
I.Introduction :
Durant les années passées les réseaux mobiles ont connu une évolution technologique remarquable,
cette évolution peut décrit par la succession de plusieurs générations (1G, 2G, 3G, 4G et
prochainement la 5G), en apportant un débit exceptionnel et qui ne cesse d’augmenter, une bande
passante de plus en plus large avec une augmentation identique à celle de nombre d’utilisateur
pouvant être supportés.
Les réseaux de la 1ère génération (1G) arrivent au début d’années 80. Ces systèmes ont cependant
été abandonnés quelques années après laissant la place à la seconde génération qui a été lancée en
1991, elle est encore active de nos jours.. Le principal standard utilisant la 2G est GSM. A la
différence de la 1G qu’elle était base sur des technologies analogique offrant que la communication
téléphonique vocale, la seconde génération utilise des technologies numériques très avancées par
rapport au celle de première permet d’accéder à divers services, comme l’utilisation du WAP
permettant d’accéder à Internet, tant dit que l’arrivée de la 3ème génération a permis un haut débit
pour l’accès à l’internet et le transfert de données.
En ce qui concerne la nouvelle génération 4G (LTE), qui a été déployée dans plusieurs pays à
travers le monde, elle permet la transmission des paquets à très haut débit, faible latence et permet
aussi d’exploité de nouveaux services.
II. Les différentes technologies de la téléphonie mobile :
Cette partie décrira brièvement les différentes technologies de réseau mobile, il est intéressant de
rappeler l'évolution de ces technologies ainsi que leur fonctionnement.
II.1. La première génération des téléphones mobiles (1G)
La première génération des téléphones mobiles est apparue dans le début des années 80 en
offrant un service médiocre et très couteux de communication mobile. La 1G avait
beaucoup de défauts, comme l’incompatibilité avec d’autre réseau existant, une transmission
analogique non sécurisée.
2
II.2. La deuxième génération des téléphones mobiles (2G) :
Le GSM est apparu dans les années 90. Il s'agit de la norme 2G. Son principe, est de passer
des appels téléphoniques, s'appuyant sur les transmissions numériques permettant une sécurisation
des données (avec cryptage), il a connu un succès et a permis de réponde au besoin de la
téléphoner en tout lieu avec la possibilité d'émettre des mini messages (SMS). Ainsi qu’il autorise
le roaming entre les pays exploitant le réseau GSM.
................... - OTA
._CJ ........ Aux data interne
SMSC •••••••• Ondes radio

............
Edlanoesde
SolS
.................
...-,
.....
BSC
AUC
VLR
Figure 1.1 : Architecture du réseau GSM [1].
D’après l’architecture du réseau GSM (Figure 1.1), on distingue trois sous-systèmes :
II.1.1 Le sous-système radio BSS :
BSS ou (base station sub-system), c’est un sous-système de l’architecture GSM qui assure les
transmissions radioélectriques et gère la ressource radio. Le BSS comprend les BTS qui sont des
émetteurs-récepteurs ayant un minimum d’intelligence et les BSC qui contrôlent un ensemble de
BTS et permettent une première concentration des circuits [1].
II.1.2 Le sous-système d’acheminement NSS :
Son rôle est d’assurer les fonctions de commutations et de routage. C’est donc lui qui permet
l’accès au réseau public RTCP ou RNIS. En plus des fonctions indispensables de commutation, on
y retrouve les fonctions de gestion de la mobilité, de la sécurité et de la confidentialité qui sont
implantées dans la norme GSM [1].
3
Il se compose de plusieurs équipements, en citant quelques-uns :
- MSC : sont des commutateurs qui assurant l’interconnexion entre le réseau mobile et le réseau
fixe public. Le MSC gère l’établissement des communications, la transmission des messages
courts et l’exécution le processus de handover lorsqu’il y a changement de cellules.
- HLR : est une base de données de localisation et de caractéristiques des abonnés
- VLR : Le VLR a pour mission d’enregistrer des informations dynamiques relatives aux abonnés
de passage dans le réseau
- AUC : est un centre d’authentification AUC (Authentification Center) mémorise pour chaque
abonné une clé secrète utilisée pour authentifier les demandes de services et pour chiffrer
(crypter) les communications.
II.1.3 Le sous-système d’exploitation et de maintenance « OSS » :
OSS (Operation Sub-System) permet à l’opérateur de contrôlé son réseau. La mise en place d’un
réseau GSM (en mode circuit) va permettre à un opérateur de proposer des services de type « Voix»
à ses clients en donnant accès à la mobilité tout en conservant un interfaçage avec le réseau fixe
RTC existant [1].
II.3. Le réseau GPRS (2.5G) :
Le réseau GPRS vient ajouter un certain nombre de « modules » sur le réseau GSM sans changer le
réseau existant. Ainsi sont but est de conservés l’ensemble des modules de l’architecture GSM
(Figure 1.2), nous verrons par ailleurs que certains modules GSM seront utilisés pour le
fonctionnement du réseau GPRS [2].
La mise en place d’un réseau GPRS va permettre à un opérateur de proposer des nouveaux services
de type "Data" à ses clients.
4
••••••• ~ PLMN
i._
GPRS~
Figure 1.2 : Architecture du réseau GPRS.
Un réseau GPRS est un réseau IP. Qui est constitué les entités suivantes :
- Le nœud de service (SGSN) : Le SGSN (Serving GPRS Support Node) joue un rôle de
routeur, il gère les terminaux GPRS présents dans une zone donnée. Le SGSN est le «
contrôleur » des terminaux GPRS présents dans sa zone de surveillance.
- Le nœud de passerelle (GGSN) : Le GGSN (Gateway GPRS Support Node) est un routeur qui
relié le réseau GPRS à un ou plusieurs réseaux de données (Internet, Intranet, autre réseau
GPRS...).
- Le module BG pour la sécurité : le BG (Border Gateway) permet de connecter les réseaux

GPRS via un réseau fédérateur et qui assurent les fonctions de sécurité pour la connexion entre
ces réseaux [2].
II.4. La troisième génération des téléphones mobiles 3G (UMTS) :
La 3G a été lancée pour permettre des applications haut débits sur le mobile (la visiophonie,
vidéo streaming...etc), et améliorer la QoS du Multimédia.
L’idée été d’ajouter des amplificateurs avant chaque antennes, il amplifie le signal pour que
celui-ci puisse être reçu par une autre antenne, en changeant les techniques de modulation.
Pour cela il a fallu améliorer les terminaux (Smartphone, Tablette...) permettant un usage plus
confortable de la connexion haut débit.
5
II.4.1. Architecture du réseau UMTS :
Le réseau cœur de I'UMTS s'appuie sur les éléments de base du réseau GSM et GPRS. Il est en
charge de la commutation et du routage des communications (voix et données) vers les réseaux
externes.
Le réseau cœur se décompose en deux parties : le domaine circuit dans un premier temps et le
domaine paquet.
•••••• /~p
I... LMN~
GPRS
~/""'
Internet~
/_----
ISDN ~
PSDN )
Figure 1.3 : Architecture du réseau UMTS [3].
II.4.2. L’entité d'un réseau UMTS:
La mise en place du réseau UMTS (Figure 1.3) abords des nouveaux éléments sur le réseau sont:
- Le NodeB : Le NodeB est une antenne. Reparties géographiquement sur l'ensemble du

territoire, le NodeB est l’équivalent du BTS au réseau GSM. Ils gèrent la couche physique de
l'interface radio. Il régit le codage du canal, l'entrelacement, l'adaptation du débit et l'étalement.
Ils communiquent directement avec le mobile sous l'interface dénommée Uu.
6
- Le RNC (Radio Network Controller) : Le RNC est un contrôleur de NodeB. il est l'équivalent
du BCS dans le réseau GSM, qui ce charge pour :
 contrôlé et géré les ressources radio en utilisant le protocole RRC (Radio Ressource
Control) pour définir procédures et communication entre mobiles et le réseau.
 Le contrôle de charge et de congestion des différents NodeB.
 Le contrôle d'admission et d'allocation des codes pour les nouveaux liens radio [3].
II.4.3. Le débit de l'UMTS :
L’UMTS permet théoriquement des débits de transfert de 1,920 Mbps, mais les débits offerts par
les opérateurs dépassent rarement 384 Kbps. Néanmoins, cette vitesse est nettement supérieure
au débit de base GSM qui est de 9,6 kbps.
II.4.4. Le mode de transmission dans le réseau UMTS :
Ce réseau repose sur deux modes :
 Le mode circuit
Le domaine circuit permettra de gérer les services temps réels dédiés aux conversations
téléphoniques (téléphonie, vidéoconférence, visiophonie). Ces applications nécessitent un temps
de transfert rapide.
 Le mode paquets :
Le domaine paquet permettra de gérer les services non temps réels. II s'agit principalement de la
navigation sur Internet, l’utilisation des e-mails. Ces applications sont moins sensibles au temps de
transfert, c'est la raison pour laquelle les données transiteront en mode paquet [3].
II.5. La quatrième génération des téléphones mobiles 4G (LTE) :
La LTE (Long Term Evolution) est un projet mené par l'organisme de standardisation 3GPP visant
à rédiger les normes techniques de la future quatrième génération en téléphonie mobile. Elle permet
le transfert de données à très haut débit, avec une portée plus importante, un nombre d’appels par
cellule supérieur (zone dans laquelle un émetteur de téléphonie mobile peut entrer en relation avec
des terminaux) et une latence plus faible. En théorie, elle permet d’atteindre des débits de l’ordre de
50 Mbps en lien ascendant et de 100 Mbps en lien descendant, à partager entre les utilisateurs
mobiles d'une même cellule.
7
Pour les opérateurs, la LTE implique de modifier le cœur du réseau et les émetteurs radio. Il faut
également développer des terminaux mobiles adaptés. En termes de vocabulaire, le futur réseau
s’appelle EPS (Evolved Packet System). Il est constitué d’un nouveau réseau d’accès appelé LTE
(Long Term Evolution) et d’un nouveau réseau cœur appelé SAE (System Architecture Evolution)
ou EPC (Evolved Packet Core) [4].
II.5.1 Performances du LTE :
- Débit sur l’interface radio : L ’interface radio E-UTRAN doit pouvoir supporter un débit
maximum descendant instantané (du réseau au terminal) de 100 Mbps en considérant une
allocation de bande de fréquence de 20 MHz pour le sens descendant et un débit maximum
montant instantané (du terminal au réseau) de 50 Mbps en considérant aussi une allocation de
bande de fréquence de 20 MHz. Les technologies utilisées sont OFDMA (Orthogonal
Frequency Division Multiple Access) pour le sens descendant et SC-FDMA (Single Carrier
Frequency Division Multiple Access) pour le sens montant. Cela correspond à une efficacité du
spectre de 5 bit/s/Hz pour le sens descendant et 2,5 bit/s/Hz pour le sens montant.
- Connexion permanente : Principe des accès haut débit où la connectivité est permanente pour
l’accès à Internet. Même si la connexion est permanente au niveau du réseau, il est nécessaire
pour le terminal de passer de l’état IDLE à l’état ACTIF lorsqu’il s’agira d’envoyer ou recevoir
du trafic. Ce changement d’état s’opère en moins de 100 ms. Le réseau pourra recevoir le trafic
de tout terminal rattaché puisque ce dernier dispose d’une adresse IP, mettre en mémoire ce
trafic, réaliser l’opération de paging afin de localiser le terminal et lui demander de réserver des
ressources afin de pouvoir lui relayer son trafic.
- Délai pour la transmission de données : Moins de 5 ms entre l’UE et l’Access Gateway, ceci
dans une situation de non-charge où un seul terminal est ACTIF sur l’interface radio. La valeur
moyenne du délai devrait avoisiner les 25 ms en situation de charge moyenne de l’interface
radio. Ceci permet de supporter les services temps réel IP nativement, comme la voix sur IP et
le streaming sur IP.
- Mobilité : Assurée à des vitesses comprises entre 120 et 350 km/h. Le handover pourra
s’effectuer (la LTE ne permet que le hard handover et non pas le soft handover) dans des
conditions où l’usager se déplace à grande vitesse.
- Coexistence et Interfonctionnement avec la 3G : Le handover entre E-UTRAN (LTE) et

UTRAN (3G) doit être réalisé en moins de 300 ms pour les services temps-réel et 500 ms pour
les services non temps-réel. Il est clair qu’au début du déploiement de la LTE peu de zones
8
seront couvertes. Il s’agira pour l’opérateur de s’assurer que le handover entre LTE et la 2G/3G
est toujours possible. Le handover pourra aussi s’effectuer entre LTE et les réseaux CDMA-
2000. Les opérateurs CDMA évolueront aussi vers la LTE qui devient le vrai standard de
communication mobile de 4ème génération.
- Flexibilité dans l’usage de la bande : Comme indiqué précédemment E-UTRAN doit pouvoir
opérer dans des allocations de bande de fréquence de différentes tailles incluant 1.4 , 5, 10, 15 et
20MHz.
- Support du multicast : Notamment pour les applications multimédia telles que la télévision en
broadcast.
- Couverture de cellule importante dans les zones urbaines et rurales : Comme la LTE pourra
opérer sur des bandes de fréquences diverses et notamment basses comme celle des 700 MHz il
sera possible de considérer des cellules qui pourront couvrir un large diamètre [4].
II.5.2 Caractéristiques et entités du réseau EPS :
L’EPS (Evolved packet System) représente l’ensemble du réseau à savoir LTE et SAE. Il a les
caractéristiques suivantes :
- Il possède une architecture plate et simplifiée comparée à celle hiérarchique 2G/3G puisque la
fonction de contrôleur d’antenne disparaît. La seule entité présente dans l’accès est l’eNodeB
qui peut être assimilé à un NodeB + RNC dans le cas de réseau 3G.
- Il s’agit d’une architecture uniquement paquet comparée à l’architecture 2G/3G circuit et

paquet.
- Il permet une connectivité permanente tout-IP comparée à des contextes PDP temporaires ou
permanents en 2G/3G dans le domaine paquet
- Son interface radio est totalement partagée entre tous les usagers en mode ACTIF comparée à
des ressources dédiées et partagées dans l’architecture 2G/3G. Les appels voix et visiophonie
requièrent des ressources dédiées en 3G.
- Il permet des handover vers les réseaux 2G/3G et CDMA/CDMA2000 afin d’assurer des
communications sans couture en environnement hétérogène [5].
9
Les grandes fonctions assurées par l’EPS sont les:
• Fonctions de contrôle d’accès réseau :
Elles permettent d’authentifier l’usager lorsque ce dernier s’attache au réseau, met à jour sa tracking
area, et demande des ressources pour ses communications. Elles permettent aussi de réaliser la
taxation de l’usager en fonction de l’usage des ressources et en fonction des flux de service émis et
reçus. Elles permettent enfin de sécuriser les flux de signalisation et les flux média des usagers en
les encryptant entre l’UE et l’eNodeB.
- Fonctions de gestion de la mobilité : Elle permet à l’UE de s’attacher, de se détacher et de

mettre à jour sa tracking area.
- Fonctions de gestion de session : Elle permet d’établir des defaults bearers et des dedicated
bearers afin que l’UE dispose de connectivités IP pour ses communications.
- Fonctions de routage de paquet et de transfert : Elle permet d’acheminer les paquets de l’UE
au PDN GW ainsi que du PDN GW à l’UE.
- Fonctions de gestion de ressource radio : Elle permet l’établissement et la libération de RAB

(Radio Access Bearer) entre l’UE et le Serving GW à chaque fois quel’UE souhaite devenir
actif pour communiquer [6].
II.5 .3. Architecture du réseau EPS :
Figure 1.4: Architecture de réseau EPS [6].
10
Le réseau EPS consiste en les entités suivantes :
II.5.3.1. Entité eNodeB :
Figure 1.5 : Architecture E-UTRAN [7].
L’eNodeB est responsable de la transmission et de la réception radio avec l’UE. A la différence de

l’UTRAN 3G où sont présentes les entités NodeB et RNC, l’architecture E-UTRAN ne présente
que des eNodeB. Les fonctions supportées par le RNC ont été réparties entre l’eNodeB et les entités
du réseau cœur MME/SGW. L’eNodeB dispose d’une interface S1 avec le réseau cœur. L’interface
S1 consiste en S1-C (S1-Contrôle) entre l’eNodeB et le MME et S1-U (S1-Usager) entre l’eNodeB
et le SGW.
Une nouvelle interface X2 a été définie entre eNodeBs adjacents. Son rôle est de minimiser la perte
de paquets lors de la mobilité de l’usager en mode ACTIF (handover). Lorsque l’usager se déplace
en mode ACTIF d’un eNodeB à un autre eNodeB, de nouvelles ressources sont allouées sur le
nouvel eNodeB pour l’UE ; or le réseau continu à transférer les paquets entrants vers l’ancien
eNodeB tant que le nouvel eNodeB n’a pas informé le réseau qu’il s’agit de lui relayer les paquets
entrants pour cet UE. Pendant ce temps l’ancien eNodeB relaie les paquets entrants sur l’interface
X2 au nouvel eNodeB qui les remet à l’UE. La figure 1.5 décrit l’architecture E-UTRAN avec ses
eNodeB et les interfaces X2 (entre les eNodeB) et S1 (entre eNodeB et entités du réseau coeur
MME/Serving GW) [7].
11
II.5.3.2. Entité MME (Mobility Management Entity) :
Les fonctions de l’entité MME incluent:
- Signalisation EMM et ESM avec l’UE : Les terminaux LTE disposent des protocoles EMM
(EPS Mobility Management) et ESM (EPS Session Management) qui leur permettent de gérer
leur mobilité (attachement, détachement, mise à jour de localisation) et leur session
(établissement/libération de session de données) respectivement. Ces protocoles sont échangés
entre l’UE et le MME
- Authentification : Le MME est responsable de l’authentification des UEs à partir des

informations recueillies du HSS.
- Joignabilité de l’UE dans l’état ECM-IDLE (incluant paging) : C’est l’entité MME qui est
responsable du paging lorsque l’UE est dans l’état IDLE et que des paquets à destination de
l’UE sont reçus et mis en mémoire par le Serving GW.
- Gestion de la liste de Tracking Area : L’UE est informé des zones de localisation prises en
charge par le MME, appelées Tracking Area. L’UE met à jour sa localisation lorsqu’il se
retrouve dans une Tracking Area qui n’est pas prise en charge par son MME.
- Sélection du Serving GW et du PDN GW : C’est au MME de sélectionner le Serving GW et

le PDN GW qui serviront à mettre en oeuvre le Default Bearer au moment du rattachement de
l’UE au réseau.
- Sélection de MME lors du handover avec changement de MME : Lorsque l’usager est dans
l’état ACTIF et qu’il se déplace d’une zone prise en charge par un MME à une autre zone qui
est sous le contrôle d’un autre MME, alors il est nécessaire que le handover implique l’ancien et
le nouveau MME.
- Sélection du SGSN lors du handover avec les réseaux d’accès 2G et 3G : Si l’usager se

déplace d’une zone LTE à une zone 2G/3G, c’est le MME qui sélectionnera le SGSN qui sera
impliqué dans la mise en place du default bearer.
- Roaming avec interaction avec le HSS nominal : Lorsque l’usager se rattache au réseau, le
MME s’interface au HSS nominal afin de mettre à jour la localisation du mobile et obtenir le
profil de l’usager.
12
- Fonctions de gestion du bearer incluant l’établissement de dedicated bearer : C’est au

MME d’établir pour le compte de l’usager les defaults bearer et dedicated bearer nécessaires
pour la prise en charge de ses communications.
- Interception légale du trafic de signalisation : L’entité MME reçoit toute la signalisation

émise par l’UE et peut l’archiver à des fins de traçabilité [6].
II.5.3.3. Entité SGW (Serving Gateway):
Les fonctions de l’entité Serving GW incluent :
- Point d’ancrage pour le handover inter-eNodeB : Lors d’un handover inter-eNode, le trafic
de l’usager qui s’échangeait entre l’ancien eNodeB et le Serving GW doit désormais être relayé
du nouvel eNodeB au Serving GW.
- Point d’ancrage pour le handover LTE et les réseaux 2G/3G : Il relaie les paquets entre les
systèmes 2G/3G et le PDN-GW. Lors d’une mobilité entre LTE et Les réseaux 2G/3G paquet, le
SGSN du réseau 2G/3G s’interface avec le Serving GW pour la continuité du service de
données.
- Interception légale : Le SGW est sur le chemin de signalisation pour l’établissement/ la

libération de bearer et sur le chemin du média (paquets de données échangés par l’UE). Il est
donc un point stratégique pour l’interception légale des flux média et contrôle.
- Routage des paquets et relai des paquets : Le SGW route les paquets sortant au PGW
approprié et relaie les paquets entrants à l’eNodeB servant l’UE.
- Comptabilité par usager pour la taxation inter-opérateurs : Le SGW comptabilise le

nombre d’octets envoyés et reçus permettant l’échange de tickets de taxation inter-opérateurs
pour les reversements.
- Marquage des paquets dans les sens montant et descendant : Par exemple positionnant le
DiffServ Code Point sur la base du QCI (QoS Class Identifier) du bearer EPS associé. Cela
permet d’associer des priorités aux flux de données au sens DiffServ [6].
13
II.5.3.4. Entité PDN GW (Packet Data Network Gateway):
Les fonctions de l’entité PDN GW incluent :
- Interface vers les réseaux externes : (Internet et intranet). Le PDN GW est l’entité qui termine
le réseau mobile EPS et assure l’interface aux réseaux externes IPv4 ou IPv6.
- Allocation de l’adresse IP de l’UE : Le PDN GW assigne à l’UE son adresse IP dès

l’attachement de l’UE lorsque le réseau établit un defaut bearer permanent à l’UE. Le PDN GW
peut allouer une adresse IPv4 ou IPv6.
- Interception légale : Le PDN GW est sur le chemin de signalisation pour l’établissement/ la

libération de bearer et sur le chemin du média (paquets de données échangés par l’UE). Il est
donc un point stratégique pour l’interception légale des flux média et contrôle.
- Marquage des paquets dans les sens montant et descendant : Par exemple positionnant le
DiffServ Code Point sur la base du QCI (QoS Class Identifier) du bearer EPS associé. Cela
permet d’associer des priorités aux flux de données au sens DiffServ.
- Taxation des flux de service montants et descendants :(Par exemple sur la base des règles de
taxation fournies par le PCRF) ou sur la base de l’inspection de paquets définie par des
politiques locales) [5].
II.5.3 .5. Entité HSS (Home Subscriber Server) :
Avec la technologie LTE, le HLR est réutilisé et renommé Home Subscriber Server (HSS). Le HSS
est un HLR évolué et contient l’information de souscription pour les réseaux GSM, GPRS, 3G, LTE
et IMS.
A la différence de la 2G et de la 3G où l’interface vers le HLR est supportée par le protocole MAP

(protocole du monde SS7), l’interface S6 s’appuie sur le protocole DIAMETER (protocole du
monde IP).
Le HSS est une base de données qui est utilisée simultanément par les réseaux 2G, 3G, LTE/SAE et
IMS appartenant au même opérateur. Il supporte donc les protocoles MAP (2G, 3G) et DIAMETER
(LTE/SAE, IMS) [6].
14
II.5.3.6. Entité PCRF (Policy & Charging Rules Function):
L’entité PCRF réalise deux fonctions :
- Elle fournit au PDN-GW les règles de taxation lorsqu’un default bearer ou un dedicated bearer
est activé ou modifié pour l’usager. Ces règles de taxation permettent au PDNGW de
différencier les flux de données de service et de les taxer de façon appropriée.
- Elle permet de demander au PDN GW d’établir, de modifier et de libérer des dedicated bearer
sur la base de QoS souhaitée par l’usager. Par exemple, Si l’usager demande l’établissement
d’une session IMS, un message SIP sera envoyé au P-CSCF qui dialoguera avec le PCRF pour
lui indiquer la QoS requise par l’usager pour cette session.
Le PCRF dialogue alors avec le PDN-GW pour créer le dedicated bearer correspondant [5].
III.Les procédures d’attachement et détachement du réseau EPS :
III.1. Attachement de l’UE au réseau EPS :
1- L ’UE initie la procédure d'attachement au réseau EPS par l'envoi d'un message ATTACH
REQUEST à l’entité MME de rattachement. Si cette requête est acceptée par le réseau, un
message ATTACH ACCEPT est retourné à l’UE.
2- Si le message ATTACH ACCEPT contient un nouveau GUTI alloué par le MME, l’UE doit
utiliser ce GUTI (Globally Unique Temporary Identity) comme nouvelle identité temporaire et
le stocker sur sa carte SIM en remplacement de l'ancien. Par ailleurs l’UE émet un message
ATTACH COMPLETE au MME.
3- Si aucune identité GUTI n’est présente dans le message ATTACH ACCEPT, l’UE doit
continuer à utiliser son ancien GUTI sans retourner de message ATTACH COMPLETE.
4- Si la demande ATTACH REQUEST est refusée par le réseau EPS, un message ATTACH
REJECT est retourné à l’UE [6].
15
III.2. Détachement de l’UE du réseau EPS :
1- La procédure de détachement du réseau EPS est initiée par l’UE à travers un message DETACH
REQUEST. Lorsque le MME de rattachement reçoit ce message, il ne retourne pas de réponse
car l’UE est déjà hors tension.
2- Lors d'un problème réseau, le MME de rattachement initie une procédure de détachement en
envoyant un message DETACH REQUEST à l’UE qui doit l’accepter en retournant une réponse
DETACH ACCEPT [6].
IV. Conclusion :
Dans ce chapitre introductif, nous avons présenté d’une façon générale l'évolution de
communications mobiles à travers toutes ses générations, De la voix analogique en premier
génération à la deuxième génération numérique, le but était rehausser l'expérience de la voix d'un
utilisateur, en améliorant la qualité de la communication. La 2.5G (GPRS) la communication data
devient possible sur le réseau GSM mais limitée par son faible débit. Avec l’arrivé de la 3G le but a
changé, on s’intéresse essentiellement aux applications data en assurant des communications haut
débit. De plus la mobilité totale (roaming) est devenue un objectif à poursuivre.
Cependant, l’évolution au cours de la dernière décennie est incomparable à l’explosion du besoin en

bande passante déclenché notamment par la généralisation des abonnements data mobiles et
notamment avec un usage du vidéo streaming pour mobile. L’introduction de la 4G a donc été
anticipé par les opérateurs afin de mieux contrôler cette évolution des usagés dans un monde mobile
tout IP.
16
CHAPITRE II
Chapitre 2 : La voix sur LTE
I. Introduction :
Les appels vocaux continuent à représenter une part essentielle du modèle économique des
opérateurs mobiles. En effet, plus de 60 % de leur chiffre d’affaires provient du trafic vocal et SMS
c’est pourquoi ils ont besoin d’une solution stable et normalisée pour fournir ces services et
protéger cette part de leur chiffre d’affaires.
La LTE est un système IP complet conçu exclusivement pour l’acheminement des données, alors
que les opérateurs ont eu recours aux réseaux 2G/3G via les fonctions CS Fallback et VoLGA pour
l’acheminement des communications vocales.
La technologie VoLTE (voice over LTE) représente l’étape suivante logique pour la prise en charge
des appels vocaux sur IP de bout en bout. Cette technologie VoLTE a été lancée en 2012 par des
opérateurs innovants sud-coréens et cette année, des opérateurs du monde entier vont multiplier les
tests en laboratoire et sur le terrain pour proposer une expérience nouvelle en matière de
communication vocale.
II. CSFB (Circuit SwitchedFallBack) :
Cette première solution consiste tout simplement à continuer d’utiliser le réseau 2G/3G pour le
service téléphonique et à réserver le réseau 4G pour le service de transmission de données. Avec ce
principe, le terminal mobile est connecté soit au réseau actuel GSM/UMTS soit au réseau LTE
selon l’application qu’il utilise. Un échange de signalisation entre d’une part le cœur de réseau NSS
(Network Sub System) et d’autre part le cœur de réseau EPC (Evolved PacketCore) du réseau 4G est
alors nécessaire afin que le mobile puisse basculer vers le réseau 2G/3G lorsqu’étant connecté au
réseau LTE, il reçoit ou désire émettre un appel téléphonique. S’il souhaite conserver ses
communications données en cours, il est également nécessaire de basculer le mode PS établi avec le
réseau 4G vers le mode PS sur le réseau 2G/3G (Figure 2.1)[8].
Figure 2.1 : La solution CSFB (Circuit SwitchedFallback) [8].
17
Cette solution offre l’avantage de se baser sur des technologies existantes et éprouvées mais
présente cependant plusieurs inconvénients:
- le temps de bascule entre les réseaux 4G et 2G/3G est significatif (de l’ordre de quelques
secondes en moyenne) ce qui, en terme d’expérience utilisateur, n’est guère satisfaisant et l’on
voit mal les premiers utilisateurs de LTE, probablement assez technophiles et dotés de
smartphones les plus récents, accepter une telle régression.
- les transferts de données sont également perturbés durant la bascule ce qui, à l’heure des
téléphones multitâches avec de nombreuses applications s’exécutant en tâche de fond, devra
s’effectuer le plus rapidement possible afin de limiter l’impact en terme d’usage
- ce modèle s’intègre mal avec des perspectives de développements de nouveaux services en

isolant la voix sur des anciennes technologies sans possibilité d’évolution. Il serait ainsi
impossible par exemple, de proposer des services combinant voix et données en tirant profit du
débit 4G (conférence, collaboration, jeux …).
Il s’agit là des principaux défauts du CSFB qui souffre en outre d’autres insuffisances (mauvaise
intégration avec de potentielles femtocells LTE, mauvaise occupation de la bande radio …).
En résumé, le CSFB offre l’avantage de permettre une réutilisation complète de l’infrastructure

existante (réseau, services, systèmes de facturation…) en ne nécessitant que quelques mises à jour
mineures. Cependant il s’agit là d’une solution permettant plus de prolonger la vie du réseau 2G/3G
existant que de tirer profit de l’introduction de la 4G, ce qui risque de réduire fortement l’intérêt de
déployer cette nouvelle technologie [8].
Un mécanisme assez similaire consiste à se connecter à la fois aux réseaux 2G/3G et 4G, mais de
façon simultanée afin d’éviter la phase de bascule radio. Cette approche, connue sous le nom de
SVLTE (Simultaneous Voice and LTE), a également le mérite de ne pas nécessiter de modifications
dans le réseau mais conduit à une plus grande complexité du téléphone ainsi qu’une consommation
énergétique accrue. Des terminaux utilisant ce système sont déjà disponibles en CDMA/LTE (pas
encore en GSM/UMTS/LTE).
18
III. VoLGA (Voice Over LTE via Generic Access):
Cette seconde solution permet également de réutiliser l’infrastructure voix existante mais de
manière un peu plus évoluée. Elle consiste à connecter le réseau EPS au cœur de réseau NSS qui
fournit le service téléphonique 2G/3G par l’intermédiaire d’une passerelle VANC (VoLGA Access
Network Controller). La signalisation 2G/3G de la téléphonie est ainsi réutilisée mais est
transportée sur le réseau de données 4G en étant encapsulée au sein de paquets IP. Le réseau EPS
joue alors le rôle de réseau d’accès au même titre que le BSS (Base Station Sub-system) du réseau
2G ou l’UTRAN (UMTS TRAnsport Network) du réseau 3G [9].
Figure 2.2 : La solution VoLGA (Voice Over LTE via Generic Access) [9].
Cette solution présente l’avantage de n’apporter aucune modification tant au niveau du réseau EPS
que du cœur de réseau NSS (Figure 2.2). Par contre, le mobile doit intégrer des adaptations pour le
transport, sur le réseau 4G, de la signalisation NAS (Non Access Stratum) échangée entre le
mobile et le réseau NSS.
Comme le CSFB, VoLGA permet de réutiliser l’infrastructure existante, ce qui assure un

déploiement rapide ainsi qu’une transparence complète du réseau vis-à-vis des services
téléphoniques. De plus, VoLGA ne souffre pas des défauts majeurs de CSFB en assurant un accès
simultané aux services voix 2G/3G et données LTE. Au niveau du réseau, VoLGA ne nécessite que
le déploiement de quelques nouveaux éléments (VANC principalement). Le terminal, en revanche,
devra également intégrer cette nouvelle technologie afin d’être en mesure d’encapsuler la téléphonie
2G/3G dans des paquets IP.
19
Le support de VoLGA dans le terminal constitue le principal obstacle à son adoption car cela
nécessite un support fort des fournisseurs de mobiles pour une technologie de transition qui n’a pas
vocation à être utilisée sur le long-terme. Ce point est de plus gênant par le fait qu’il s’agit d’une
technologie non adoptée par le 3GPP, l’organisme qui est en charge des spécifications GSM et
LTE. Par ailleurs, VoLGA, comme CSFB, ne permet pas de véritables services de convergence car
les réseaux gérant la voix et les données restent séparés [9].
IV. VoLTE (voice over LTE)via IP Multimedia Subsystem :
VoLTE, ou Voix sur LTE, qui est présentée comme la solution cible à long terme est celle de la
mise en œuvre de l’IMS (IP Multimedia Subsystem), qui est le réseau multimédia IP spécifié par le
3GPP. Ce réseau, extérieur au réseau 4G, permet de supporter tous types de services et différentes
réseaux d’accès (Figure 2.3) [10].
Figure 2.3 : La solution voLTE (voice over LTE) [10].
Le réseau IMS est basé sur l’emploi du protocole de signalisation SIP (Session Initiation Protocol)
qui permet l’enregistrement du mobile au service téléphonique et l’établissement d’une session, et
du protocole SDP (Session Description Protocol), associé au protocole SIP, qui supporte la
négociation du média (voix, vidéo, données). La seconde fonction assurée par l’architecture IMS
concerne le traitement du flux média pour les fonctions indisponibles dans le réseau 4G comme la
conférence, la génération des annonces et les passerelles vers les réseaux téléphoniques fixes PSTN
(Public Switched Telephone Network) et les réseaux de mobiles PLMN (Public Land Mobile
Network) [11].
20
IV.1. L’architecture IMS
IMS propose une approche modulaire qui permet de distinguer des niveaux de traitements
différents (Figure 2.4).
Figure 2.4 : L’architecture de réseau IMS [12].
Quatre couches peuvent être identifiées, chacune d’elles étant liée à un domaine spécifique.
IV.1.1. La couche accès :
Elle définit la manière dont l’utilisateur se connecte au réseau. Parmi les réseaux d’accès, on peut
citer : E-UTRAN (Evolved Universal Terrestrial Radio Access Network), GSM (Global System for
Mobile communications), UMTS (Universal Mobile Telecommunications System), CDMA2000,
xDSL, Wi-Fi, WiMax, Ethernet, ATM, la fibre optique...etc
IV.1.2. La couche de transport :
La couche de transport est une couche générique IP. Elle est formée d’un maillage de commutateurs
et de routeurs qui assurent, dans le réseau IP, le routage des données multimédias.
21
IV.1.3. La couche de contrôle :
Elle 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 la véritable base de l’IMS [13].
La couche de contrôle est constituée de différents blocs, qui sont les suivantes :
IV.1.3. 1. Bloc de contrôle des sessions :
Le contrôle d'appel initié par un terminal IMS doit être pris en charge dans le réseau nominal
(réseau auquel l’usager a souscrit à ses services IMS) car l'usager correspondant peut souscrire à un
grand nombre de services et certains d'entre eux peuvent ne pas être disponibles ou peuvent
fonctionner différemment dans un réseau visité, notamment suite à des problèmes d’interaction de
service. Cela a induit la définition d’entités suivantes :
 P-CSCF : Le Proxy-CSCF (P-CSCF) est le premier point de contact dans le domaine IMS. Son
adresse est découverte par le terminal lors de l'activation d'un contexte PDP pour l'échange de
messages de signalisation SIP.
Le P-CSCF se comporte comme un Proxy Server SIP lorsqu'il relaye les messages SIP vers le
destinataire approprié et comme un User Agent SIP lorsqu'il termine l'appel.
Les fonctions réalisées par l'entité P-CSCF comprennent :
- L'acheminement de la méthode SIP REGISTER émise par le terminal à l'entité I-CSCF à

partir du nom du domaine nominal.
- L'acheminement des méthodes SIP émises par le terminal au S-CSCF dont le nom a été
obtenu dans la réponse à la procédure d'enregistrement.
- Le routage des méthodes SIP ou réponses SIP au terminal.
- La génération de CDRs (Call Detailed Record).
- La compression / décompression des messages SIP.
 I-CSCF : L'Interrogating-CSCF (I-CSCF) est le point de contact au sein d'un réseau d'opérateur
pour toutes les sessions destinées à un utilisateur de cet opérateur. Il peut exister plusieurs
ICSCF au sein d'un réseau.
Les fonctions réalisées par l'entité I-CSCF comprennent :
22
- L'assignation d'un S-CSCF à un utilisateur s'enregistrant.

- L'acheminement des méthodes SIP reçues depuis un autre réseau, au S-CSCF.
- L'obtention de l'adresse du S-CSCF auprès du HSS.
 S-CSCF : Le Serving-CSCF (S-CSCF) prend en charge le contrôle de la session. Il maintient un

état de session afin de pouvoir invoquer des services. Dans un réseau d'opérateur, différents
SCSCF peuvent présenter des fonctionnalités différentes.
Les fonctions réalisées par le S-CSCF pendant une session comprennent :
- L'émulation de la fonction REGISTRAR puisqu'il accepte les méthodes SIP

d'enregistrement et met à jour le HSS.
- L'émulation de la fonction Proxy server puisqu'il accepte les méthodes SIP et les achemine.
- L'émulation de la fonction User Agent puisqu'il peut terminer des méthodes SIP par exemple
lorsqu'il exécute des services complémentaires.
- L'interaction avec des serveurs d'application après avoir analysé les critères de
déclenchement des services correspondants.
- La génération de CDRs
 L’E-CSCF : L’entité E-CSCF effectue le traitement des appels d’urgence transmis par l’entité
P-CSCF et le routage de la requête vers le centre d’urgence le plus proche de l’UE.
IV.1.3.2. Bloc de l’interconnexion avec les autres réseaux :
L’interconnexion entre le domaine IMS et les autres réseaux est assuré a travers les entités suivants:
 Le BGCF : L’entité BGCF détermine le saut suivant pour l’acheminement du message SIP.
Elle doit choisir l’entité MGCF responsable de l’interfonctionnement avec les réseaux PSTN ou
PLMN. Si l’entité d’interconnexion est située dans un réseau tiers, elle transmet le message SIP
à une autre entité BGCF située dans ce réseau tiers.
23
 Le MGCF : L’entité MGCF assure l’établissement, le maintien et la libération des connexions

dans l’entité MGW. Une connexion représente une association entre une terminaison en entrée
(l’interface avec les réseaux tiers PSTN et PLMN) et une terminaison en sortie (l’interface avec
le réseau IP) et inversement.
 L'IMS-MGW : L’entité MGW effectue la conversion de protocoles relatifs aux flux

multimédias entre les deux terminaisons. Elle contient les traitements effectués sur les flux
médias, comme le transcodage (modification du type de codec entre les deux terminaisons),
l’annulation d’écho, l’émission des tonalités et des annonces.
 Le TrGW et IMS-ALG: La passerelle TrGW effectue la translation d’adresses sur les flux de
données, et la passerelle IMS-ALG, qui effectue la translation d’adresses au niveau de la
signalisation [13].
IV.1.3.3.Bloc des bases de données :
Le bloc des bases de données constitue des deux entités suivantes :
 Le HSS : L’entité HSS est une base de données assurant le stockage des données propres à
chaque utilisateur. Les principales données stockées comprennent les identités des utilisateurs,
les paramètres d’accès et les règles d’invocation des serveurs d’applications par l’entité S-
CSCF.
 Le SLF : L’entité SLF (Subscription Locator Functional) permet aux entités CSCF de trouver
l’adresse de l’entité HSS affectée à un UE, lorsque plusieurs entités HSS sont déployées.

IV.1.3. 4. Bloc de traitement du média :
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.
Le MRF (Multimedia Resource Function) 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 œuvre de
la conférence.
24
• 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.
IV.1.4.La couche application :
Elle 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.
IV.1.4.1. Les serveurs d’applications :
Les serveurs d’applications ou AS (Application Server) sont des entités SIP fournissant différent
types de services aux utilisateurs. Ils sont connectés au serveur S-CSCF, qui joue l’intermédiaire
entre l’utilisateur et les services.
On distingue trois grandes familles de serveurs d’applications, qui sont
 SIP AS (SIP Application Server):Ces serveurs permettent l’exécution des services nativement
implémentés pour fonctionner avec SIP. Les services les plus classiques (service de présence,
push-to-talk, messagerie instantanée, etc.) sont généralement implémentés au sein de ces
serveurs.
 IM-SSF (IP Multimedia-Service Switching Function): Pour permettre la mobilité de l’abonné

tout en lui garantissant la fourniture de ses services même s’il se trouve dans une infrastructure
qui n’appartient pas à son opérateur de services (on parle de roaming pour désigner la
connexion d’un utilisateur à un réseau qui n’est pas celui de son opérateur), il est nécessaire
d’avoir une passerelle, appelée IM-SSF, afin de connecter l’abonné au serveur d’applications de
son opérateur.
 La passerelle OSA (OSA SCS, OSA Service Capability Server) qui est un type particulier de
serveur d'application qui termine la signalisation SIP, et qui interagit avec des serveurs
d'application OSA en utilisant l'API OSA [12].
25
V. Le modèle protocolaire :
Pour qu’une communication soit établi entre un client LTE et un serveur d’application situe au
réseau IMS les paquets émis doivent suivi la pile protocolaire représentés dans la Figure 2.5 :
Figure 2.5 : Le modèle protocolaire [14].
Ce modèle est base sur 3 couches :
 La première couche, la couche physique elle définit les protocoles de mode d’accès LTE.
 La deuxième couche représente la couche de transport ou le fameux protocole IP était utilisé

pour transporter les données de bout en bout.
 La troisième couche, la couche d’application ou se trouve plusieurs protocoles tels que le

protocole de signalisation SIP, flux multimédia RTP/RTCP, Codecs (AMR, H264…etc.) [14].
V.1. La notion de ‘Bearer’ et QCI :
Un des avantages d'utiliser le réseau IMS combiné avec le LTE, est la capacité d'établir des tunnels
virtuelles appelé “EPS bearer” fournir une qualité service (QoS). Il définit comment les données
sont traitées quand ce transporté à travers le réseau.
Lorsque l’usager se rattache au réseau EPC, ce dernier lui crée un défaut bearer qui représente une
connectivité permanente (maintenue tant que l’usager est rattaché au réseau) mais sans débit
garanti.
26
Lorsque l’usager souhaitera établir un appel qui requiert une certaine qualité de service telle que
l’appel voix ou visiophonie, le réseau pourra établir pour la durée de l’appel un dedicated bearer qui
supporte la qualité de service exigée par le flux de service et surtout qui dispose d’un débit garanti
afin d’émuler le mode circuit.
3GPP définissent des class QCI (QoS Class of Identifier) pour chaque type de media, ces QCI varie
de 1 à 9, et deux types des ‘bearer’, le GBR (Guaranteed Bit Rate) et le non-GBR, selon
l’importance de l’application exécuté (Tableau 2.1) [15].
QCI Type de bearer priorité Latence (ms) Packetloss Exemple

1 2 100 10-2 Appel VoLTE
2 4 150 Appel visiophoné
GBR 10-3
3 3 50 Jeu online
4 5 300 Vidéo streaming
5 1 100 IMS signalisations
10-6
Vidéo, email, chat, ftp
6 6 300
…etc.
Non-GBR Voix, vidéo, jeu
7 7 100 10-3
interactive
8 8
300 10-6 Internet
9 9
Tableau 2.1 : les différents types des bearers et QCI [15]
V.2. Etablissement de dedicated bearer pour les services IMS :
L’établissement, la modification et la libération de session dans l’IMS implique un échange de

messages SIP/SDP de bout en bout. Pendant l’échange, le terminal négocie un ensemble
de caractéristiques média (e.g., les codecs). Le P-CSCF à travers son PCRF (Policy & Charging
Rules Function) autorise les flux IP des composants média choisis par le terminal en réalisant une
translation des paramètres de la description SDP en des paramètres de QoS IP. Ces paramètres de
QoS IP sont ensuite passés par le PCRF au PCEF à l’aide protocole DIAMETER.
Lorsque le terminal IMS émet une requête SIP INVITE au P-CSCF, ce dernier émet une requête Rx
AAR au PCRF. Le PCRF la traduit en une requête Gx RAR et l’achemine au PCEF. Cette requête
indique au PCEF la description des flux à autoriser (flux RTP/RTCP entre l’appelant et appelé) et la
QoS du dedicated bearer qui doit accommoder ces flux. Ce dedicated bearer est établi entre l’UE
VoLTE et le PDN GW (Figure 2.6)[16].
27
Figure 2.6. Création d’un dedicated bearer pour la VoLTE[16].
VI. Protocoles principales mise en œuvre en VoLTE :
VI.1. Le protocole DIAMETER :
Le protocole DIAMETER successeur du protocole RADIUS est un protocole AAA (Authentication,

Authorization, Accounting). Il permet aux opérateurs d’authentifier des utilisateurs, de leur
autoriser certains services et de collecter des informations sur l’utilisation des ressources. Il s’agit
du protocole le plus à même de satisfaire les nouveaux besoins suscités par la mobilité.
DIAMETER est un protocole en particulier utilisé par le 3GPP pour ses architectures LTE (Long
Term Evolution) et IMS (IP Multimedia Subsystem). Il permet entre autres l’authentification,
l’autorisation et la taxation online et offline des clients LTE et IMS [17].
VI.1.1.Les messages DIAMETER :
Les messages DIAMETER sont échangés entre, d’une part, les entités CSCF du réseau IMS et,
d’autre part, soit l’entité HSS lors de l’enregistrement de l’entité UA ou du routage de la requête
SIP, soit l’entité PCRF pour le contrôle du média [18].
28
VI.1.1.1. Les messages liés à l’enregistrement et au routage :
 La requête UAR et la réponse UAA (User-Authorization-Request/Answer) : sont utilisées

entre les entités I-CSCF et HSS lors des deux phases d’enregistrement de l’entité UA (user
agent). A la réception d’une requête REGISTER, l’entité I-CSCF interroge l’entité HSS afin de
récupérer la liste des entités S-CSCF qu’il est possible d’attribuer à l’entité UA et l’adresse IP
de l’entité S-CSCF attribuée à l’entité UA
 La requête MAR et la réponse MAA (Multimedia-Auth-Request/Answer) : sont utilisées

entre les entités S-CSCF et HSS lors de la première phase d’enregistrement. A la réception de la
requête REGISTER, l’entité S-CSCF fournit son adresse IP et récupère les données
d’authentification de l’entité UA.
 La requête SAR et la réponse SAA (Server-Assignment-Request/Answer) : sont utilisées

entre les entités S-CSCF et HSS lors de la seconde phase d’enregistrement.
A la réception de la requête REGISTER, l’entité S-CSCF s’enregistre auprès de l’entité HSS et
télécharge le profil de l’entité UA
 La requête RTR et la réponse RTA (Registration-Termination-Request/Answer) : sont

utilisées entre les entités HSS et S-CSCF lorsque l’entité HSS déclenche le désenregistrement
de l’entité UA.
 La requête LIR et la réponse LIA (Location-Info-Request/Answer) : sont utilisées entre les

entités I-CSCF et HSS pour le routage de la requête INVITE. Lors d’un appel entrant, à la
réception de la requête INVITE, l’entité I-CSCF récupère l’identité de l’entité S-CSCF attribuée
à l’entité UA de destination.
 La requête PPR et la réponse PPA (Push-Profile-Request/Answer) : sont utilisées entre les

entités HSS et S-CSCF. Elles permettent à l’entité HSS de notifier une modification du profil de
l’entité UA [18].
29
VI.1.1.2.Les messages liés au contrôle du média :
Les messages liés au contrôle du média sont échangés entre les entités P-CSCF et PCRF lors de
l’établissement d’une session.
- La requête AAR (Authorization-Authentication-Request) : est utilisée par l’entité P-CSCF

pour transmettre à l’entité PCRF les caractéristiques du média négocié dans le message SDP
- La réponse AAA (Authorization-Authentication-Answer) : de l’entité PCRF acquitte la

requête. Si les codecs du média sont autorisés,
- La requête STR (Session-Termination-Request) : est utilisée par l’entité P-CSCF pour

informer l’entité PCRF de la terminaison de la session SIP.
- La réponse STA (Session-Termination-Answer) : de l’entité PCRF acquitte la requête. A la

réception de cette requête, l’entité PCRF libère les ressources immobilisées dans le réseau EPS.
- La requête ASR (Abort-Session-Request) : est utilisée par l’entité PCRF pour informer l’entité
P-CSCF que les ressources réservées par le réseau EPS ne sont plus disponibles.
- La réponse ASA (Abort-Session-Answer) : acquitte la requête. A la réception de cette requête,

l’entité P-CSCF termine la session SIP en envoyant une requête BYE à chaque entité UA
participant à la session.
VI.2. Le protocole SIP :
Le protocole SIP est un protocole de commande qui peut établir, modifier et terminer des sessions
multimédias.
Le protocole SIP est basé sur un couple requête/réponse de type HTTP (Hypertext Transfer
Protocol). Chaque transaction consiste en une requête, qui fait appel à une méthode particulière et
en une ou plusieurs réponses [19].
VI.2. 3. Les requêtes :
La requête débute par une ligne contenant la méthode, une identité URI et la version du protocole.
Elle contient ensuite des en-têtes.
30
 La méthode REGISTER : La méthode REGISTER est utilisée par une entité UA (user agent)
afin de notifier l’entité REGISTRAR de la correspondance entre l’adresse IP de l’entité UA et
son identité URI. Cette correspondance est nécessaire pour les appels entrants.
 La méthode INVITE : La méthode INVITE est utilisée par une entité UAS pour établir un
dialogue ou une session. Les réponses définitives, positives ou négatives, doivent être validées
par la requête ACK. La requête INVITE peut contenir un corps de message décrivant le média
que l’entité UAC souhaite établir
 La méthode ACK : La méthode ACK est utilisée pour acquitter une réponse définitive (2xx,
3xx, 4xx, 5xx, 6xx) à la requête INVITE. La requête ACK peut contenir un corps de message
décrivant le média dans le cas où cette description n’est pas fournie dans la requête INVITE.
 La méthode BYE : La méthode BYE est utilisée pour terminer une session établie. Une session
est considérée comme établie lorsque la réponse 2xx est reçue à la suite de la requête INVITE.
 La méthode CANCEL : La méthode CANCEL est utilisée pour terminer une session qui n’a
pas abouti. Elle est générée lorsqu’une réponse provisoire 1xx a été reçue, mais pas de réponse
définitive.
 La méthode PRACK : La méthode PRACK est utilisée pour acquitter la réception d’une
réponse provisoire (1xx), à l’exception de la réponse 100 Trying.
 La méthode SUBSCRIBE : La méthode SUBSCRIBE est utilisée lorsqu’une entité UA veut

souscrire à un service lui permettant de recevoir des notifications d’événements.
 La méthode NOTIFY : La méthode NOTIFY permet à une entité de notifier l’occurrence d’un
événement.
 La méthode REFER : La méthode REFER permet de transférer un média établi entre deux
entités UA (par exemple entre Alice et Bob). La requête REFER est envoyée par Alice transféré
vers Carol pour reprendre la communication.
 La méthode MESSAGE : La méthode MESSAGE est utilisée pour transmettre de petits

messages, contenus dans un corps de message, entre deux entités UA.
31
VI.2.4. Les réponses :
Quelle que soit la méthode utilisée dans une requête, le récepteur final doit y apporter au moins une
réponse en retour, ne serait-ce qu’une réponse temporaire pour informer l’émetteur que sa requête
est prise en compte et en train d’être traitée et qu’elle sera suivie d’une réponse finale dès que
possible.
La réponse débute par une ligne contenant la version du protocole, suivie par un code du type de
réponse et d’une description textuelle du code.
Les différents types de réponses sont explicités au tableau (Tableau 2.2) :
Typede réponse Désignation
1xx Réponse provisoire
2xx Réponse définitive et positive
3xx Réponse définitive de redirection
4xx Réponse définitive et négative, erreur due au client
5xx Réponse définitive et négative, erreur due au réseau
6xx Réponse définitive et négative, erreur globale
Tableau 2.2 : Les types de réponses [19].
Parmi les réponses :
 La réponse 100 TRYING : La réponse 100 Trying est générée par l’entité PROXY SERVER
pour avertir l’émetteur de la requête que le message SIP a été reçu.
 La réponse 180 RINGING : La réponse 180 Ringing est utilisée par l’appelé pour indiquer à
l’appelant que la requête INVITE a été reçue et que l’appelé est averti d’un appel entrant par
une sonnerie.
 La réponse 200 OK : La réponse 200 OK a deux utilisations. Lorsqu’il s’agit d’une réponse à
une requête INVITE, elle contient le corps du message décrivant le média mis en place par
l’entité UAS. Pour les autres requêtes, la réponse acquitte la réception de la requête.
32
 401 UNAUTHORIZED : indique que la requête requiert une authentification de l’entité UA.
Elle est utilisée par l’entité REGISTRAR à la réception d’une requête REGISTER. La réponse
inclut l’en-tête WWW-Authenticate qui contient un défi à partir duquel l’entité UA calcule les
données d’authentification.
 503 SERVICE UNAVAILABLE : Le service n’est pas disponible en ce moment, peut-être par
surcharge du serveur, maintenance ou dysfonctionnement.
 600 BUSY EVERYWHERE : L’appelé a été joint, mais il est occupé sur tous les postes et ne
peut prendre la communication.
VI.2.5. Les en-têtes :
 L’en-tête Via : est utilisée pour enregistrer l’itinéraire de la requête et permettre ainsi
l’acheminement de la réponse.
 L’en-tête From : indique la source de la requête. L’entité UAC ajoute le paramètre tag qui
participe à l’identification du dialogue.
 L’en-tête To : indique le destinataire de la requête. Les réponses générées par l’entité UAS
contiennent cet en-tête avec l’ajout d’un paramètre tag.
 L’en-tête Call-ID :est une partie de l’identification du dialogue entre deux entités UA.
L’en-tête Call-ID doit être unique pour un appel.
 L’en-tête Contact : est utilisé pour transmettre l’adresse IP de l’émetteur de la requête ou

de la réponse. Cette adresse est mise en cache pour le routage des requêtes subséquentes dans un
dialogue.
 L’en-tête Route : est utilisé pour fournir des informations de routage des requêtes. Deux
modes de routage sont définis, le routage strict et le routage lâche.
 L’en-tête Record-Route : est utilisé pour forcer le routage à travers une entité PROXY
SERVER pour toutes les requêtes subséquentes entre deux entités UA.
33
 L’en-tête WWW-Authenticate : est utilisé dans la réponse 401 Unauthorized. Il

contient un défi d’authentification (paramètre nonce) de l’entité UAC par l’entité
REGISTRAR [19].
VI. 3. Le protocole SDP :
Le protocole SDP (Session Description Protocol) fournit une description du flux média pour lequel
l’établissement de la session est mis en œuvre par le protocole SIP. Le message SDP constitue le
corps de message attaché au message SIP. Il apparaît généralement dans la requête INVITE et dans
la réponse 200 OK. Les paramètres qui caractérisent le flux média sont les suivantes (Tableau 2.3) :
- le type de média (audio, vidéo, données) ;

- le protocole de transport (par exemple RTP) ;
- le format du média (par exemple le type de codec pour la voix et la vidéo) ;
- l’adresse IP à laquelle le média doit être transmis ;
- le numéro du port de destination.
Le message SDP est un ensemble de lignes de format <type>=<valeur>. Le champ <type> contient
un caractère ; le contenu du champ <valeur> dépend du type.
Champ <type> Description
v Version du protocole. Le contenu du champ <valeur>est <0>
o Identifiant de l’origine et de la session
s Nom de la session. Le contenu du champ <valeur> est <->
c Information sur la connexion
t Temps d’activité de la session. Le contenu du champ<valeur> est <00>
m Description du média
a Attribut complémentaire du média
Tableau 2.3 : Le protocole SDP [19].
34
VI.4. Les protocoles RTP et RTCP :
VI.4.1 Le protocoles RTP :
Le but de RTP et de fournir un moyen uniforme de transmettre sur IP des données soumises à des
contraintes de temps réel (audio, vidéo, etc.). Le protocole RTP permet :
- d'identifier le type de l'information transportée.

- d'ajouter des marqueurs temporels permettant d’indiquer l’instant d’émission du paquet.
L’application destinataire peut alors synchroniser les flux et mesurer les délais et la gigue.
- d’inclure des numéros de séquence à l'information transportée afin de détecter l’occurrence
de paquets perdus et de délivrer les paquets en séquence à l’application destinataire [20].
VI.4.1 Le protocoles RTCP :
C’est un protocole de contrôle des flux RTP, permettant de véhiculer des informations basiques sur
les participants d'une session, et sur la qualité de service.
Il existe cinq types différents de paquets RTCP pour chaque type d'information :
- SR (Sender Report) contient des statistiques de transmission et de réception pour les

participants qui sont des émetteurs actifs.
- RR (Receiver Report) contient des statistiques de réception pour les participants qui ne sont
pas des émetteurs actifs mais récepteurs d’une session [20].
- SDES (Source Description) décrit la source : nom, email, tél, etc.
- BYE permet à une station d’indiquer la fin de sa participation à une session.
- APP est un paquet de signalisation spécifique à une application.
VI.5. Le protocole MEGACO :
MEGACO s’appelle H.248 à l’ITU-T et est donc défini conjointement par l’IETF et l’ITU-T. Le
protocole MEGACO permet à ces deux entités MGCF et MGW de s’échanger des transactions.
Chaque transaction s’exprime par l’envoi d’une transaction Request par l’une des entités et l’envoi
d’une transaction Reply par l’autre entité. Une transaction Request consiste en une suite de
commandes alors qu’une transaction Reply contient une suite de réponses correspondantes [21].
35
VI.6. Codage des signaux :
Il est essentiel compte tenu du nombre important de normes de codage de signaux audio ou vidéo
d’inclure un mécanisme à RTP afin de permettre au destinataire de connaître le codage utilisé et
ainsi pouvoir décoder correctement, parmi les type codecs spécifié par 3GPP (3GPP TS 26.093)
pour la VoLTE, le codec HD VOICE ou AMR WB (Adaptive Multi Rate Wide Band) avec un
débit moyenne de 12.65 Kb/s [19].
VII. L’établissement d’une communication :
Pour mettre deux utilisateurs en communication dans le réseau IMS, le protocole SIP sera
indispensable pour l’établissement, la gestion et la terminaison des sessions
Nous allons voir comment les messages SIP sont envoyés dans deux cas d’application classique :
- l’enregistrement d’un terminal dans le réseau ;

- la mise en relation de deux utilisateurs.
VII.1. Enregistrement d’un terminal :
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 REGISTRER, du protocole de signalisation SIP.

Nous allons détailler le processus mis en œuvre avec SIP, qui diffère avec l’IMS du fait de son
architecture particulière.
36
Figure 2.7.Processus d’enregistrement d’un terminal avec l’IMS [13].
On observe globalement deux étapes SIP dans ce scénario (Figure 2.7) , correspondant à la succession de
deux requêtes et de leurs réponses.
VII.1.1. Première étape d’enregistrement :
1- Le terminal IMS envoi sa requête d’enregistrement au serveur P-CSCF.
2- Le P-CSCF localise le serveur I-CSCF à l’aide de DNS. et lui transmet la requête de l’utilisateur.
3- L’I-CSCF reçoit la requête, puis demande au HSS d’authentifier l’utilisateur (requête UAR).
4- La base HSS répond par la réponse UAA et propose l’ensemble des S-CSCF disponibles
5- L’I-CSCF choisit l’un d’entre eux, et il lui relaie la requête d’enregistrement de l’utilisateur.
6- Le S-CSCF contacte alors la base HSS pour l’informer qu’il a été désigné pour prendre en charge
la session de l’utilisateur (requête MAR).
37
7- Il reçoit en retour une réponse MAA qui confirme l’enregistrement du S-SCSF affecté à
l’utilisateur et lui transmettre les vecteurs d’authentification de ce dernier qui permettent de générer
le challenge.
8- Lorsque le S-CSCF les reçoit, il répond au serveur I-CSCF par un message SIP
401UNAUTHORIZED, contenant le challenge .Ce message de réponse est relayé conformément au
modèle SIP client/serveur, c’est-à-dire de proche en proche, en passant par tous les émetteurs de
requêtes : le I-CSCF d’abord, le P-CSCF ensuite et le terminal client enfin [10].
VI.1.2. Deuxième étape d’enregistrement
1-Lorsque le client reçoit le message de réponse 401, il détecte le challenge qui s’y trouve et
prépare automatiquement une réponse adaptée.
2- Cette réponse est générée dans une nouvelle requête d’enregistrement REGISTER. Elle est
envoyée en suivant le même processus d’acheminement que le premier message de requête.
3- Quand la requête atteint le serveur I-CSCF il effectue la même requête (UAR) auprès de la base
HSS. La base HSS dans ce cas lui fournis dans sa réponse (message UAA) en lui fournissant
l’adresse du serveur S-CSCF en charge de la session courante.
4- À réception de la requête, le serveur S-CSCF vérifie l’authentification de l’utilisateur, en

reprenant les vecteurs d’authentification que lui a fournis le HSS à l’étape précédente. Si les
paramètres d’authentification sont valides, l’authentification est un succès, et le serveur S-CSCF en
informe le HSS (par un message SAR).
5- Le HSS répond ensuite au S-CSCF en lui envoyant le profil complet de l’utilisateur, qui est
stocké temporairement et servira à paramétrer et personnaliser les services de ce dernier.
6- Pour terminer, le serveur S-CSCF envoie un message de réponse 200 OK.
7- Comme précédemment, le message de réponse traverse les entités qui ont acheminé la requête,
c’est-à-dire l’I-CSCF, le P-CSCF puis le terminal IMS [10].
38
VII.2. Mise en relation de deux utilisateurs VoLTE :
Une communication implique une première étape de recherche des abonnés, de vérification des
autorisations d’accès, puis de mise en relation entre les correspondants.
La méthode associée à cette dernière fonctionnalité est INVITE avec le protocole de signalisation
SIP. C’est aussi la méthode que nous allons employer, mais avec une mise en œuvre particulière,
dont un scénario est illustrée à la figure 2.8.
Nous considérons que l’appelant et l’appelé ont des opérateurs différents et sont localisés dans des
réseaux visités, c’est-à-dire qui n’appartiennent pas forcement à leur opérateur respectif. C’est le
cas le plus général.
Ce scénario de mise en relation de deux terminaux, ou UE (User Equipment), peut être découpé en
sept grandes étapes, que nous allons brièvement présenter (Figure 2.8):
Figure 2.8.Mise en communication de deux terminaux

39
1. Message d’invitation de A vers B, avec deux réponses temporaires : une réponse 100 pour
indiquer la tentative et une réponse 183 pour négocier les paramètres de la communication.
L’appelant sollicite le terminal de B et, pour cela, s’adresse au serveur I-CSCF de B, qui le localise
après une requête Diameter.
2. Pour s’assurer que l’émetteur A a bien reçu la réponse 183, celui-ci doit impérativement envoyer
un acquittement temporaire. Comme toute requête SIP, et conformément au modèle client/serveur,
une réponse est envoyée.
3. Le terminal A doit négocier les paramètres de qualité de service pour garantir sa communication
dans le réseau. Cette étape permet aux utilisateurs d’établir une communication avec une bande
passante garantie, et donc un service de qualité. Elle est nouvelle par rapport au processus habituel
d’établissement de connexion qu’utilise SIP, car la qualité de service est un élément essentiel avec
l’IMS. Le terminal B vérifie que lui aussi a réservé les ressources nécessaires à la communication
dans le réseau et valide la requête par sa réponse.
4. Dès ce moment, le terminal de B commence à sonner. Cette étape complète les réponses
temporaires à la requête d’invitation par une réponse 180, elle aussi temporaire.
5. Pour s’assurer que cette réponse est bien reçue du terminal A, ce dernier doit confirmer la
réception par une requête d’acquittement, qui attend elle-même une réponse.
6. Dès que l’utilisateur du terminal B a répondu (ou que sa messagerie s’est enclenchée), la réponse
définitive 200 est envoyée à la requête initiale d’invitation.
7. La requête d’acquittement finale valide l’initialisation de la communication, qui peut dès lors
débuter pour permettre aux terminaux de s’échanger des flux de données multimédias [13].
40
VIII. Conclusion :
Dans ce deuxième chapitre, nous avons présenté les différentes technologies qui permettant de
fournir les services de la téléphonie à travers des réseaux de quatrième génération tel que la
technologie CS Fall-Back qui repose sur des réseaux déjà existant 3G et 2G pour établir des
communications téléphoniques. Cette solution d’attente et ses extensions (SvLTE, VoLGA…)
connait plusieurs inconvénients comme la durée d’établissement d’appel, consumation d’énergie
éminent…etc.
Ensuite nous avons présenté la technologie VoLTE qui sera la solution de long terme pour la
téléphonie 4G. Par conséquent, nous avons présenté l’architecture IMS avec ses différentes entités
et protocoles mis en œuvre pour bénéficier des services liées à la téléphonie (présence, push to talk,
visiophonie…) et d’autres services autrefois exclusivement réservés à Internet (iptv, video on
demande, chat…), avec une expérience meilleure que celle offerte dans les générations précédentes.
41
CHAPITRE III
Chapitre 3 : Réalisation Pratique
I. Introduction :
Étant donné, que notre travail consiste principalement au déploiement et au provisionnement d’une
solution IMS pour la VoLTE, et pour cela nous avons choisi d’utiliser une plateforme IMS open
source « OpenIMSCore » pour analyser le fonctionnement et les performances d’un réseau IMS.
II. Open Source IMS core:
Le projet d’open source IMS (OpenIMSCore) a été lancé en 2006, développé par l’université
FOKUS (Fraunhofer Institute for Open Communication System) [22].
Cette solution a été adoptée par plusieurs opérateurs et fournisseurs de télécommunications dans le
monde comme un banc d’essais pour tester les fonctionnalités de système IMS avec l’intégration
des nouveaux services sur IP comme la télévision sur IP (IPTV). Open source IMS Core est formé
par l’ensemble des éléments de base d’une architecture IMS définie dans les réseaux de nouvelle
génération et telle qu’indiquée dans 3GPP, 3GPP2, ETSI TISPAN.
Figure 3.1 : Architecture d’OpenIMSCore
Toutes les entités de cette plateforme sont basées sur des logiciels libres. Ainsi, open source IMS
CSCFs est composé de trois éléments : le Proxy (P-CSCF), Interrogating (I-CSCF) et Serving (S-
CSCF) Call Session Control Functions. Ces trois éléments sont des extensions de SIP Express
Router (SER) qui ont été testés avec des produits commerciaux pour l’interopérabilité.
42
La base des données d’OpenIMSCore, FHoSS (FOKUS Home Subscriber Server) est basé sur
MySQL. La logique du FHoSS d’application est entièrement écrite avec Java. La composante
principale de cette base de données est l’utilisateur maître (Master) à base de MySQL, supportant
des entités de réseaux qui gèrent les communications sur IMS. Plus précisément, le FHoSS offre les
fonctions suivantes :
- stocke et gère les informations relatives au profil d’abonnés ;

- génère des données pour l’authentification et l’autorisation des utilisateurs ;
- maintenir les tables de routage sous forme de répertoires de localisation de l’abonné ;
- fournir des informations sur les points de service de l’abonné ;
- gestion de déclencheur des services;
FHoSS est configuré pour supporter plusieurs millions d’abonnés et peux servir de multiples
centaines d’utilisateurs enregistrés par seconde.
II.1. Architecture et conception de banc d’essai :
Tel que mentionné précédemment nous avons choisi OpenIMSCore comme une plate-forme libre
constitué des entités principale de l’IMS (le bloc de contrôle CSCF et la base de donnée HSS)
conformément aux normes définie par la 3gpp. Ensuite nous avons ajouté des serveurs
d’application:
- Un serveur de présence.
- Un serveur IPTV accompagné d’un serveur média.
Pour déployer ces composants, nous avons choisi d’utiliser sept machines virtuelles équipées d’un
système d’exploitation Linux (Ubuntu server 12.04), chaque module a été installé dans une machine
virtuelle séparée, chaque machine est repérée à l’aide d’un serveur DNS, au lieu d’utiliser le modèle
classique proposé par FOKUS, afin d’avoir des tests adéquats a un environnement professionnel.
Pour assurer le bon fonctionnement de ces entités séparées, et l’interconnexion entre elle, nous
étions obligés d’apporter des modifications au niveau des fichiers de configuration de chaque entité.
43
Pour tester le fonctionnement de ces services dans ce banc d’essai nous avons utilisé GNS3 comme
outil d’interconnexion entre les différentes machines, ainsi que pour visualiser le trafic dans chaque
nœud. Finalement Deux client IMS sont utiliser pour test les différents services (Figure 3.2)
Figure 3.2 : Architecture de banc d’essai
III. Métriques de performance d’IMS :
Apres l’installation et configuration (Annexe2) de toute les machines, on passe à la mise en œuvre
et le test de cette solution avec des outils d’analyse de trafic tels que WireShark et SIPWorkbench,
Il existe plusieurs procédures dans le standard IMS, dans notre analyse nous avons mis l’accent sur
trois principales procédures qui sont l’enregistrement, l’établissement d’une session et la
sollicitation des services.
44
III.1. Demande d’enregistrement :
Pour vous connecter à un système IMS, l’utilisateur final doit d’abord s’attacher au réseau: ce
processus est appelé «procédure d’enregistrement» qui est principalement basé sur l’échange de
messages de signalisation SIP.
L’UE (User Equipment) envoie une première demande d’enregistrement au proxy PCSCF à l’aide
d’un message «REGISTER». Le P-CSCF doit d’abord vérifier l’identité de l’utilisateur final en
fonction de son profil stocké dans la base de données FHoSS à l’aide des autres entités S-SCSF et I-
CSCF. Après cette vérification, l’UE envoie un second message d’enregistrement «REGISTER»
qui sera acquitté par «200 OK» (Figure 3.3 et 3.4) qui précise que la demande d’enregistrement
est réussie et que l’utilisateur peut établir une session voix, vidéo, ou données.
Figure 3.3 : les messages SIP mise en jeu pendant le processus d’enregistrement
III.1.1.Délai d’enregistrement (RRD) :
Le RRD (Registration Request Delay) dans une tentative d’enregistrement réussie, est définie
comme l’intervalle de temps entre le moment où le premier bit du «REGISTER» initial jusqu’à ce
que le dernier bit du message réponse «200 OK» reçue indiquant la tentative d’enregistrement a
réussi.
RRD = Time of Final Response - Time of REGISTER Request (3.1)
Le délai d’enregistrement (RRD) écoulé dans notre cas est : RRD =0.431 Seconde
45
Figure 3.4 : Procédure d’enregistrement capturé avec SIPWorkbench
III.2. Etablissement d’une session audio, vidéo :
Une fois l’utilisateur est enregistré au sein du réseau, il peut avoir un accès à n’importe quel service
inclus dans son abonnement avec l’opérateur. La voix est le service principal offert par l’opérateur
téléphonique. D’abord, une demande «INVITE» est envoyée par le premier client « client IMS 1 »
pour lancer un appel téléphonique avec « client IMS 2 » (Figure 3.5). Ensuite, les deux participants
négocient les paramètres de session (codecs, type de média …etc.) ainsi que la réservation de
ressources par les messages «SIP/SDP».
46
Lorsque tous les paramètres de la session sont négociés et mis en place, les deux UE échangent un
message «200 OK», puis ils échangent un message «ACK» qui indique que la création de la session
a réussi. À cet instant la session est déjà établie entre les deux clients, le trafic audio ou vidéo est
acheminé entre eux en utilisant RTP comme protocole de transport, à la fin de session les deux
clients échangent un message « BYE » confirmé avec une réponse « 200 OK »(Figure 3.6)..
Figure 3.5 : exemple d’un appel vocal
Figure 3.6 : les messages SIP mise en jeu pendant et à la fin d’une session vocale
Remarque : la seul différence entre un appel audio ou vidéo est au niveau du message SIP/SDP la
ou les deux participants négocient en plus les paramètres de l’audio et celle de la vidéo. Au niveau
RTP le flux audio et vidéo sont transmis sur deux connexions différentes.
47
III.2.1. Délai d’établissement d’une session audio(SRD)
Le SRD (Session Request Delay) d’une session réussite est défini par l’UIT-T est l’intervalle du
temps entre le moment ou l’UE envoie un message «INVITE» et le moment où il reçoit une réponse
«Ringing»
SRD = Time of Status Indicative Response - Time of INVITE (3.2)
Dans cet exemple le délai est duré : SRD=0.182 seconde
IV. Mesure de la bande passante des différents codecs :
IV.1.Bande passante du flux RTP (BW) :
La bande passante au niveau IP pour le flux RTP est égale à la somme de tous les octets, y compris
les entêtes IP (20 octets) et UDP (8 octets) de tous les paquets du flux RTP au cours de la dernière
seconde.
Pour évaluer le débit expérimentale d’un codec, nous avons choisi le logiciel Wireshark comme
outils de mesure, qui permet de visualisé la variation de débits sur des graphes en fonction de
temps, les résultats des mesures se présenter comme suit :
IV.2.Débits des codecs audio :
Dans un premier temps nous avons choisi d’évaluer la bande passante de célèbre codec G.711
(PCMA) pour le prendre comme référence.
D’après les mesures présentées dans la figure 3.7 nous avons constaté que la bande passante de
codec G.711 varie entre 90 et 100 Kbps. Par rapport au débit théorique (64Kbps).
Cette différence revient à l’addition des entêtes (Ethernet +IP + UDP + RTP = 66 octets) a la
charge outil de codecs G.711 (donnée = 80 octets).
Par un simple calcule on trouve :

La taille d’un paquet de donnée = (80 (donnée) + 66 (en-tête))*8 = 1168 bits
1168 bits 10 ms
La bande passante de codec G.711 = 116.8 Kbps
48
Figure 3.7 : la bande passante de codec G.711 (PCMA)
De même façon nous avons mesuré la bande passante de codec GSM (12.2 Kbps) (Figure 3.8)., le
codec le plus utilisé dans les communications mobile, nous avons trouvé que le débit de ce codec
varie entre 35 et 40 Kbps, avec ce débit le canal peut supporter plusieurs communications en
même temps par rapport au codec G.711, mais en terme de qualité le G.711 est meilleur.
Flux RTP de codec GSM
Figure 3.8 : la bande passante de codec GSM
En fin nous avons choisi de mesurer la bande passante du codec AMR (G.722.2 de débit qui varie
entre 6.6 et 23.85 Kbps) (Figure 3.9)., ce codec est recommandé par la 3gpp pour la norme VoLTE.
On constate que la bande passante de ce dernier est proche de celle du codec GSM, au tour de
35 Kbps, mais avec une qualité de communication meilleure.
49
Figure 3.9: la bande passante de codec AMR (G.722.2)12.65 Kbps
IV.2. bande passante des codecs vidéo :
Pour mesurer la bande passante des codecs vidéo nous avons choisi le codec H.264, un des codecs
les plus utilisés pour la visiophonie.
Après les mesures on nous avons constaté que la bande passante de ce codec peut atteindre
260Kbps pour une résolution (640 x 480 VGA) (Figure 3.10).
Flux RTP de codec H.264
Figure 3.10 : la bande passante de codec H.264
50
V.La gigue des différents codecs :
V.1. Gigue du flux RTP :
La gigue est la variance statistique du délai de transmission. Pour les applications téléphoniques la
gigue est la variation de délai entre l’émission et l’écoute de la voix. La présente d’une gigue élevée
cause une dégradation de la QoS. Ceci est dû aux deux facteurs qui sont principalement les paquets
perdus et le délai pour chaque paquet. RTP est utilisé comme protocole de transport pour la
téléphonie en IMS donc il faut bien surveiller cette métrique. Le calcul de la gigue est effectué selon
RFC3550 et exprimé comme suit :
J (i) =J (i - 1) + (|D (i - 1, i)|-J (i - 1))/16 (3.3)
V.2. Les codecs audio:
A partir des mesures que nous avons réalisées sur les codecs G.711 (Figure 3.11). et GSM, (Figure
3.12).on a remarqué que la variation de la gigue ne dépasse pas 15 ms, celle-ci indique que la
communication ne présente aucune coupure, car cette variation est largement inférieur à l’état
critique (100 ms).
La gigue
Figure 3.11 : La gigue mesurée pour un codec G.711 (PCMA)
51
La gigue
Figure 3.12 : La gigue mesurée pour un codec GSM
Dans le cas de codec AMR (Figure 3.13)., la valeur de la gigue mesurée ne dépasse pas 30 ms,
malgré cette augmentation de la gigue mais la communication reste audible, sans coupure.
La gigue
Figure 3.13: La gigue mesurée pour un codec AMR (12.65 kbps)
V.3. Les codecs vidéo :
Dans le cas de codec H.264 (Figure 3.14)., la valeur de la gigue mesurée ne dépasse pas 30 ms,
celle-ci signifie que la communication vidéo ne présenter pas des coupures ou des dégradations
de qualité de la vidéo.
52
Figure 3.14 : La gigue mesurée pour un codec h.264
VI. Mean Opinion Score (MOS):
Pour évaluer la qualité d’un appel, la note d’opinion moyenne (MOS) (Tableau 3.1) est un test qui
est utilisé dans les réseaux de téléphonie pour obtenir vue de l’utilisateur humain de la qualité de
l’appel.
Codec MOS Qualité
G.711 4.1 Excellents
GSM 3.5 Juste
AMR 4.14 Excellents
Tableau 3.1 : Mean opinion score (MOS)
D’après ces résultats on confirme que le codec AMR est le choix idéal pour la communication
mobile et spécialement la VoLTE.
53
V.II. Établissement d’une session data :
La messagerie instantanée (IM) se réfère à la transmission des messages entre les utilisateurs en
temps quasi réel. Ces messages sont souvent utilisés dans un mode conversationnel dont le transfert
est assez rapide pour les participants de maintenir une conversation interactive.
Pour établir une session de données entre les deux abonnées « client IMS 1 » envoie un message de
demande «MESSAGE» contenant le message instantané à envoyer. Le message est reçu par « client
IMS 2 », affiché une réponse «200 OK» est généré et envoyé au « IMS client 1 » pour indique que
le message a été bien reçu.
Figure 3.15 les messages SIP mise en jeu pendant l’envoi d’un message
VII.1. Délai d’établissement d’une session donnée :
Le délai d’une session donnée est défini par l’intervalle du temps entre le moment ou l’UE envoie la
requête «MESSAGE» et le moment de la réception du dernier bit du message réponse «200 OK»
reçue indiquant que la session a été établie (Figure 3.15).
Délai d’établissement d’une session donné par :

IMD = Time of Status Indicative Response – Time of MESSAGE (3.5)
Dans notre cas le délai d’établissement d’une session donnée durée : IMD=0.353 second
54
VIII. Les services supplémentaires :
Avec le développement rapide des réseaux télécom d’aujourd’hui et la convergence de ces deniers
de plus en plus vers la multimédia, les opérateurs de télécom devient rend en compte ces services.
La technologie IMS comme une architecture ouverte peut avoir plusieurs services supplémentaires
pour répond aux besoins de marché sans faire des changements au niveau de réseau de l’opérateur
lui-même, ce qui augmente la rentabilité et la souplesse de mise en place des nouveaux services aux
plans économique et technique.
Dans notre projet on a choisie d’ajoutés deux services supplémentaire: le service de présence et le
service d’IPTV.
VIII.1. le service de présence :
Le service de présence permet aux utilisateurs de connaître en en temps réel la disponibilité et les
statuts de leurs contacts (en ligne, hors ligne, occupé…etc.), pour mettre en place ce service sur
notre plateforme nous avons choisi d’installer le serveur SIP Kamailio, qui permet de traiter les
requêtes liées à la présence.
VIII.1.1. le processus de présence :
Afin de mettre son statut à la disposition, le client envoi la méthode SIP PUBLISH au serveur de
présence. Ce dernier traite cette requête, répond au client par une réponse positive (200 ok) puis
publie son état actuel pour indiquer à ces contacts qu’il est joignable par exemple (Figures 3.16,3.17)
Figure 3.16 les messages SIP publie pendant le processus de présence
55
Figure 3.17 : Procédure de présence capturée avec SIPWorkbench
Figure 3.18 exemple de présence entre deux clients
VIII.2. le service IPTV :
Le service IPTV basé sur l’IMS est une architecture de plateforme qui offrir les services de la
télévision sur IP contrôlés et gérés par le réseau IMS et acheminés indépendamment sur un réseau
de transport IP. Cette architecture spécifie les fonctions d’IPTV supportées par le réseau IMS et
réutilise les mécanismes prédéfinis dans celle-ci pour l’initiation et le control de service en se
basant sur le protocole SIP (Figure 3.19).
56
Figure 3.19: Architecture de services d’IPTV

VIII.2.1. le processus de service IPTV : Pour
qu’un abonné puisse regarder un programme télévisé ou une vidéo à la demande sur son
terminal, le client doit être enregistré et authentifié par le réseau IMS. Apres le client IMS (UCT
IMS Client) émet un message INVITE au serveur IPTV-AS à travers l’entité S-CSCF, ce dernier
analyse ce message et confirme bel et bien qu’il est dédié pour le service IPTV, à l’aide des
informations présentes dans l’entête de message et les critères (triggers) décrites dans la base de
données (HSS), puis il transmet la requête de l’utilisateur au serveur IPTV, ce dernier consulte le
HSS a son tour pour vérifie que l’abonné possède un accès au service IPTV, ensuit l’IPTV ouvre la
session entre le client et le serveur Media, le client et le serveur négocient les paramètres de session
(codecs, type de média …etc.) ainsi que la réservation de ressources. A partir de ce moment le
client est prêt à exploiter le serveur Media (pour le streaming par exemple) à l’aide du protocole
RTSP qui prend en charge le transport des media en temps réel (Figures 3.20, 3.21).
57
Figure 3.20 les messages SIP échangé pendant le processus IPTV
Figure 3.21 fonctionnement d’IPTV capturée avec SIPWorkbench
58
Figure 3.22: test de fonctionnement d’IPTV
IX. appel vers l’extérieur :
La communication téléphonique peut également être établie entre un mobile et un terminal connecté
au réseau téléphonique fixe PSTN (Public Switched Telephone Network) ou mobile PLMN (Public
Land Mobile Network). Le réseau IMS fournit les entités qui assurent la conversion des protocoles
pour l’interconnexion avec ces réseaux
Comme mentionné dans le chapitre 2 l’IMS offre la possibilité d’interconnecter avec des réseaux
externes grâce à l’intervention de d’autres entités (bgcf, mgcf, mgw…), cependant ces entités ne
sont pas encore fonctionnelles sur le banc de test OpenIMSCore, nous avons choisi alors d’utiliser
un serveur SIP servant comme une passerelle pour établir des appels vers les abonnées non IMS.
Sachant que le S-CSCF est l’élément qui sollicite le bloc d’interconnexion en cas d’un appel vers
l’extérieur, nous avons analysé ses fichiers configurations, et localisé la partie de script qui traite
cette fonction , puis apporté les changements nécessaire (Figure 3.23).
59
Figure 3.23 : fichier de configuration de S-CSCF
1- représente le format de l’identité SIP de l’appelé (tous les numéros commençant par ‘0’ est pris
en considération par cette fonction).
2- représente la fonction de routage vers les réseaux externes (PSTN…).
3- indique la route vers l’entité d’interconnexion.
Figure 3.24: appel d’un client IMS vers un client non IMS
60
X. Conclusion :
Ce chapitre décrit les étapes de mise en place de notre plate-forme. Pour commencer nous avons
étudié et testé la solution open source OpenIMSCore, nous avons choisi d’extraire ses entités de
contrôle CSCF ainsi que sa base de donnée HSS afin de créer notre propre réseau qui comprend ces
entités en plus des serveurs d’application et qui est défini par un nom de domaine spécifique «
usthb.dz ». Ce réseau permet aux clients enregistrés dans la base HSS d’établir des sessions de
communication (appel audio, visiophonie, chat …) entre des clients enregistrés dans la base HSS et
de bénéficier des services supplémentaires (IPTV, présence…etc.). Il est possible aussi de passer
des appels vers des réseaux externes.
Enfin, nous avons effectué quelques mesures sur des paramètres de QoS tel que le débit, le délai, et
la gigue.
61
Conclusion
Générale
Conclusion et Perspectives
Conclusion générale
Favorisée par l'explosion du trafic de données 4G LTE ainsi que par les avantages opérationnels et
économiques qui y sont associés, mais aussi par la promesse de nouveaux services compétitifs, la
technologie de voix sur LTE représente l'avenir des services vocaux, et ce, chez tous les opérateurs.
La VoLTE est une technologie qui se repose sur l’architecture IMS. Ce réseau, extérieur au réseau
4G, permet de supporter tous types de services et de réseaux d’accès. Il constitue donc pour les
opérateurs et constructeurs une solution universelle et largement supportée permettant de mutualiser
au maximum les nouvelles infrastructures.
Notre travail consiste en l’étude et la mise en place d’une solution IMS pour la VoLTE, malgré les
difficultés que nous rencontrées et l’insuffisance de documentations sur cette technologies et la
plateforme que nous avons utilisé, vue qu’elle est récente, nous avons pu avoir un aperçu sur cette
technologies et d’explorer les divers possibilités offertes par cette dernière.
Perspectives :
Durant ce travail nous n’avons pas l’occasion de combiner la plateforme IMS avec un réseau EPS
afin d’effectuer une communication VoLTE de bout en bout, en raison des limites technique que
nous avons rencontré. En effet pour que cela soit réalisable, il faut procurer des plateformes
hardware avancées qui permettent d’émuler ce réseau. Cela peut être l’objet d’autres projets à venir.
Il est intéressant d’examiner cette solution de point de vue commerciale, d’étudier et d’implémenter
les entités responsables à la taxation au sein de cette architecture.
Enfin il est possible de proposer des nouveaux services pour enrichir l’expérience de l’utilisateur
comme la conférence, la génération des annonces et les appels d’urgence.
62
List des Abbreviations
3GPP Third Generation Partnership Project

BGCF Breakout Gateway Control Function
CSFB Circuit Switched Fall Back
Diffserv Differentiated Services
E-UTRAN Evolved Universal Terrestrial Radio Access Network
EPC Evolved Packet Cor e
EPS Evolved Packet system
GUTI Globally Unique Temporary Identity
HSS Home Subscriber Server
I-CSCF Interrogating Call Session Control Function
IMS IP Multimedia Subsystem
LTE Long Term Evolution
MOS Mean Opinion Score
MSC Mobile Switching Centre
MGCF Media Gateway Control Function
MME Mobility Management Entity
MRF Media Resource Function
PDN Packet Data Network
PCRF Proxy and Charging Rules Function
P-CSCF Proxy Call Session Control Function
PS Packet Switched
QCI QoS Class Identifier
QoS Quality of Service
RRC Radio Resource Control
RTP Real Time Protocol
S-CSCF Serving Call Session Control Function
SIP Session initial protocol
SGW Serving Gateway
VoLTE Voice over LTE via IP Multimedia Subsystem
VoLGA Voice over LTE via Generic Access
UA User Agent
UAA User-Authorization-Answer
UAC User Agent Client
UAR User-Authorization-Request
UAS User Agent Server
URI Uniform Resource Identifier
XML eXtensible Markup Language
Annexe
Annexe
Annexe 1 : Les interfaces
Figure : Les interfaces dans l’architecture IMS
Interface Gm : 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
Interface Mw : 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.
Interface ISC (IMS Service Control) : cette interface est utilisée pour envoyer et recevoir les
messages SIP entre le S-CSCF et le serveur d’application.
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.
2.3.2.5. Interface Sh : Un AS a besoin de données relatives à des l’abonné ou 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.
I
Annexe
Annexe 2 : Guide d'installation OpenIMSCore : [23]
Étape 1: Pré-requis :
 ~ 100 Mo d'espace disque pour être sur le côté sécuritaire

 Gcc3 / 4, faire, JDK1.5, fourmi
 MySQL installé et démarré (ou d'autres SGBD si vous pouvez traiter avec elle)
 bison, flex
 libxml2 (> 2.6), libmysql - à la fois avec le développement
 Noyau Linux 2.6 et ipsec-tools (setKey) si vous souhaitez utiliser la sécurité IPSec
 friser et libcurl4-gnutls-dev pour l'interface a perdu de l'E-CSCF
 Facultatif : openssl si vous souhaitez activer la sécurité TLS
 lier installé et fonctionne (ou un autre serveur de nom si vous pouvez traiter avec elle)
 Navigateur sur la boîte ou qui peut se connecter à la boîte (pour le provisionnement des
utilisateurs)
Etape 1 : Installation
mkdir / opt / OpenIMSCore

cd / opt / OpenIMSCore
mkdir FHoSS
svn checkout https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk
FHoSS
ser_ims mkdir
svn checkout https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk
ser_ims
cd FHoSS
ant compile deploy
cd ..
ser_ims cd
make install-libs all
cd ..
II
Annexe
root -p mysql <FHoSS / scripts / hss_db.sql

root -p mysql <FHoSS / scripts / userdata.sql
root -p mysql <ser_ims / cfg / icscf.sql
ser_ims cp / cfg / *. cfg.

ser_ims cp / cfg / *. xml.
ser_ims cp / cfg / *. sh.
Étape 2: Obtenir le code source
 Obtenir le code du https://sourceforge.net/p/openimscore/code (vous aurez besoin d'avoir installé

Subversion).
 Le CSCF : ser_ims / trunk

 Le HSS : FHoSS / trunk
 Comment ? - Le code source est pré-configuré pour fonctionner à partir d'un chemin d'accès de
fichier standard :
Créer / opt / OpenIMSCore et y aller
 mkdir / opt / OpenIMSCore

 cd / opt / OpenIMSCore
 Créer un nouveau ser_ims d'annuaire et la caisse les CSCF il:
 ser_ims mkdir
svn checkout https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk ser_ims
Créez un nouveau répertoire FHoSS et la caisse de la HSS il:
 mkdir FHoSS
svn checkout https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FHoSS
Étape 3 : Compiler
 ser_ims
o ser_ims cd
o make install-libs all
cd ..
o Si quelque chose se brise, vous n’avez probablement pas toutes les conditions préalables.
 FHoSS
III
Annexe
o Si vous ne disposez pas d'un JDK> = 1.5, en obtenir un avant de continuer

o Assurez-vous que la version JDK que vous utilisez est> = 1.5 !!!
o # Java -version
o java version "1.5.0_07"
o Java (TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03)
o Java HotSpot (TM) VM cliente (build 1.5.0_07-b03, mode mixte)
o Do "compilation ant deploy" dans FHoSS New !!! "fourmi gen" est pas plus nécessaire !!!
o cd FHoSS
o ant compile
o ant deploy
cd ..
 Pendant que vous attendez pour la compilation pour finir, vous pouvez aller de l'avant et d'effectuer
l'étape 4.
Etape 4: Configuration de l'environnement :
 Note :
o Tous les exemples de montage configurés pour fonctionner uniquement sur la boucle locale
et le domaine par défaut configurée comme "open-ims.test".
o Les droits d'accès MySQL ne sont fixés que pour l'accès local
o Nous vous recommandons d'essayer d'abord comme cela et puis faites vos modifications:
 Remplacez 127.0.0.1 si nécessaire avec votre adresse IP
 Remplacez le domaine par default avec le votre
 Changer les mots de passe de base de données
Pour cette opération, le ser_ims / cfg / configurator.sh pourrait vous aider.
IV
Annexe
 DNS
o Un fichier de zone DNS de l'échantillon peut être trouvée dans ser_ims / cfg / open-ims.dnszone
o Copiez-le dans votre répertoire de configuration de liaison
o Modifier named.conf et insérez le fichier il (serait bien d'ajouter également des entrées DNS inverses)
o Redémarrez le serveur de nom
o Test que les noms peuvent être résolus (Ne pas oublier /etc/resolv.conf pointant vers votre nouveau
serveur DNS !)
 MySQL
o Exécutez le SQL décharges (la racine de mysql -p -h localhost <dump.sql):
o mysql root -p -h localhost <ser_ims / cfg / icscf.sql

o mysql root -p -h localhost <FHoSS / scripts / hss_db.sql
o mysql root -p -h localhost <FHoSS / scripts / userdata.sql
o Vérifiez si les bases sont là et accessible
Étape 5 : Configurer le noyau IMS :
 A présent, vous devriez avoir MySQL et DNS de travail
 CSCF
o Copiez les fichiers suivants dans / opt / OpenIMSCore ou un autre emplacement confortable pour
vous :
pcscf.cfg, pcscf.sh, icscf.cfg, icscf.xml, icscf.sh, scscf.cfg, scscf.xml, scscf.sh,
o ser_ims cp / cfg / *. cfg.
o ser_ims cp / cfg / *. xml.
o ser_ims cp / cfg / *. Sh.
V
Annexe
 FHoSS
o analysé les fichiers de configuration dans FHoSS / deploy /

o Modifier ces fichiers à vos propres préférences (ne pas oublier de mettre à jour le fichier de zone DNS
en conséquence et redémarrer le serveur de nom)
Étape 6: Lancer les composants :
 CSCF
o Lancer pcscf.sh, icscf.sh et scscf.sh
VI
Annexe
o Tout cela doit fonctionner en parallèle.

o Par défaut, vous devriez voir périodiquement log des messages avec le contenu de la tenue des
registres et avec les liens ouverts de diamètre
 FHoSS
o Lancer FHoSS / deploy / startup.sh
o Si l'étape précédente échoue, vérifiez que vous avez la variable d'environnement JAVA_HOME
correctement exportés et / ou modifier le script que vous venez essayer de démarrer.
VII
Annexe
o Vérifiez l'interface Web sur http : // hss.votredomaine: 8080 /
o Vérifiez si les pairs de diamètre se connectent les uns aux autres. Vous pouvez le voir dans la console
de FHoSS ou dans celui de I / S-CSCF
Étape 7 : Configurez abonnés :
 FHoSS
o Par défaut, FHoSS vient approvisionner avec un couple d'utilisateurs de l’échantillon :
 [email protected]
 [email protected]
 Créer un autre abonné
VIII
Annexe
 Créer une identité publique :
 Créer une identité privée
IX
Annexe
 Création des AS au niveau du HSS :
 Paramétrage du serveur AS :
 Paramétrage du Trigger Point de serveur :
X
Annexe
 Paramétrage de l’Initial Filter Criteria de serveur :
Étape 8 : Test :
 Ceci est la dernière étape. Vous devriez avoir tout installé et configuré.
 Assurer que toutes les entités sont en cours d’exécution.
 Utilisez Wireshark pour voir ce qui se passe :
o Surveiller les ports 4060, 5060 et 6060 pour le trafic SIP
o Surveiller les ports 3868, 3869 et 3870 pour le trafic DIAMETER
XI
Bibliographie
Bibliographie :
[1] Oancea,C.D. GSM infrastructure used for data transmission. Advanced Topics in Electrical
Engineering (ATEE), 2011 7th IEEE International Symposium
[2] Ni, S. GPRS network planning on the existing GSM system, Global Telecommunications
Conference, 2000. GLOBECOM '00. IEEE
[3] Mason, P.C.; Cullen, J.M.; Lobley, N.C. UMTS architectures, Mobile Communications
Towards the Next Millenium and Beyond, IEEE Colloquium
[4] LTE et les Réseaux 4G. Yannick Bouguen Eric - Hardouin François - Xavier Wolff. Edition
EYROLLES 2012
[5] 3GPP TS 23.002 V8.5.0, Network architecture (Release 8), Juin 2009.
[6] 3GPP TR 24.801 V8.1.0, 3GPP System Architecture Evolution (SAE); CT WG1 aspects
(Release 8), Décembre 2008.
[7] Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol
(S1AP) (Release 9). 3GPP, TS 36.413 V9.1.0.
[8] Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2 (Release 9). 3GPP, TS
24.229 V9.3.1, December 2009.
[9] Voice over LTE via Generic Access; Stage 2 Specification; Phase 1. VoLGA Forum
[10] La voix sur LTE (réseau 4G et architecture IMS). André Pérez. Edition Lavoisier 2013
[11] VOICE OVER LTE. Miikka Poikselka - Harri Holma - Jukka Hongisto - Juha Kallio and
AnttiToskala. Edition Wiley 2012
[12] Paisal, V., Seamless voice over LTE, 4th IEEE International Conference on Internet
Multimedia Services Architecture and Application(IMSAA), 2010.
Bibliographie
[13] Téléphonie sur IP 2éme Edition. Laurent Ouakil - Guy Pujolle. Edition EYROLLES 2012
[14] Cardoso, F.A.C.M.; Figueiredo, F.A.P.; Vilela, R.; Miranda, J.P. A case study on protocol
stack integration for 3GPP LTE evolved node B Communications (LATINCOM), 2014 IEEE Latin-
America Conference.
[15] Yao Liu; Gang Lu; Wei Zhang; Fengling Cai. The QoS class mapping in WLAN and 3GPP
LTE interworking network Computer Science and Network Technology (ICCSNT), 2013 3rd
International Conference on
[16] Jaewook Shin; Kwangryul Jung; Aesoon Park. Design of Session and Bearer Control Signaling
in 3GPP LTE System Vehicular Technology Conference, 2008. VTC 2008-Fall. IEEE 68th
[17] 3GPP TS 29.229, Cx and Dx interfaces based on the Diameter protocol; Protocol details, Sept
2007.
[18] RFC 3588, P. Calhoun et al., Diameter Base Protocol, Sept 2003.
[19] IP Multimedia Call Control Protocol Based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); Stage 3 (Release 9).3GPP, TS 24.229 V9.3.1, December 2009.
[20] R. Stewart, Ed. Stream Control Transmission Protocol – RFC No. 4960. Internet RFC,
September 2007.
[21] ITU-T Rec. H.248v3, Gateway Control Protocol, August 2005.
Webographie:
[22] www.fokus.fraunhofer.de . juin 2015
[23] www.openimscore.org . Juin 2015

‫ملخص‬
‫ لنقل الحزم‬IP ‫ يعتمدان كليا على البروتوكول‬EPC ‫ ونظام نقل الحزم المطور‬LTE ‫شبكات المحمول الجيل الرابع التي تستعمل التكنولوجيا الالسلكية‬
‫( و الثالث‬GSM) ‫ في حين أن خدمات الهواتف النقالة التقليدية التي نشرت بالفعل في شبكات الجيل الثاني‬,‫بمعدل تدفق مرتفع ومنخفضة الكمون‬
.‫ ألن هذا النوع من الشبكات ال يدعم اإلشارات الهاتفية‬LTE ‫( ال يمكن استغاللها في شبكات‬UMTS)
‫ من بين هذه الحلول نجد‬،‫ العديد من الحلول التقنية لحل هذه المشكلة‬GSMA‫ و‬3GPP ‫لمواجهة هذه المشكلة قدمت منظمات االتصاالت مثل‬
‫ وجودة‬،‫ الدفع‬،‫ التسجيل‬،SIP ‫ كمنصة إلدارة إشارات‬،)IP ‫ (نظام دعم الوسائط المتعددة عبر‬IMS ‫) الذي يستخدم‬LTE ‫ (الصوت عبر‬VoLTE
.)3G ‫و‬2G ‫ و الربط بين أنواع مختلفة الشبكات الهاتف األرضية و الخلوية مثل (الجيل الثالث‬،‫الخدمة‬
.‫ األداء وجودة الخدمة‬،‫في هذا السياق قمنا بدراسة التقنيات المستخدمة لتنفيذ هذا الحل‬
Résumé
Les réseaux mobiles de quatrième génération qui déploient la technologie d'accès radio LTE sont des réseaux
mobiles reposent sur des réseaux cœur tout IP appelé EPC (evolved packet core) qui permet de transmettre des
paquets a haut débits avec faible latences, alors que les services de la téléphonie mobile habituelles qui sont déjà
déployés en 2G (GSM) et 3G (UMTS) ne peut pas être exploités aussitôt dans les réseaux LTE car ce type des
réseaux ne traitent pas la signalisation téléphonique.
Face à ce problème les organisations de télécommunication tel que la 3GPP (3rd generation Partner ship) et
GSMA (GSM association)proposent pas mal de solution pour résoudre le problème de signalisation téléphonique
sur les systèmes 4G LTE , parmi ces solution, la VoLTE (voice over LTE) qui utilise la IMS (internet protocole
multimédia subsysteme) comme plateforme pour gère la signalisation SIP, tarification, l’authentification, QoS
(qualité de service), ainsi que le basculement entre les différent types des réseaux existent tel que les réseau fixe
(RTC)ou a commutation des cellules (2G et 3G).
Dans ce contexte nous allons étudier les techniques utilisées pour l’implémentation de cette solution, ainsi ses
performances et qualité de service.
Abstract
The mobile networks of fourth generation that deploythe LTE radio access technology are mobile networks based
ona full IP core networks named EPC (evolved packet core) that allows to transmit packets with high debitrateand
low latencies, while the traditionalmobile telephony services that are already deployed on 2G (GSM) and 3G
(UMTS) is not able to be exploited immediately in the LTE networks because this type of networks doesn't support
the telephonic signalization.
Facing this problem the organizations of telecommunication as the 3GPP (3rd generation Partnership) and
GSMA (GSM association) propose a lot of solution to resolve this problem on the 4G LTE systems, among this
solution, the VoLTE (voice over LTE) that uses the IMS (internet protocol multimedia subsystem) as Platform to
manage the SIP signalization, Authentication, payment, QoS (quality of service), and also the interconnecting
between the different types of the networks exists as the PLMN network or other cells network like (2G and 3G).
In this context we are study the methods used to implement this solution, its performances and quality of service.
Mots clés :VoLTE, LTE, 4G, IMS, SIP, QoS, VoIP.

Final 150827004742 Lva1 App6891

Transféré par

Droits d'auteur :

Formats disponibles

Final 150827004742 Lva1 App6891

Transféré par

Informations du document

Description originale:

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

Final 150827004742 Lva1 App6891

Transféré par

Droits d'auteur :

Formats disponibles

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

Ministère de l’Enseignement Supérieur et de laRecherche Scientifique

Université des Sciences et de la Technologie Houari Boumediene

U!1.D9-/ ~J 19lD ii...A..DL.:;1

ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP

Encadré par : Mme MERAZKA Fatiha

Présenté par : NAOUI Khaled

Devant le jury composé de :

Président : M. AMROUCHE Abderrahmane

Nous tenons à remercier les membres du jury: le président de jury M. AMROUCHE

II. Les différentes technologies de la téléphonie mobile …………..……………….... 2

II.1. La première génération des téléphones mobiles (1G) ……………………….. 2

II.2. La deuxième génération des téléphones mobiles (2G)….........….....……..….. 3

II.1.1. Le sous-système radio BSS……………………………………………. 3

II.1.3. Le sous-système d’exploitation et de maintenance « OSS »………...... 4

II.3. Le réseau GPRS (2.5G) ………………………………………………………. 4

II.4. La troisième génération des téléphones mobiles 3G UMTS)…………………. 5

II.4.1. Architecture du réseau UMTS …............................................................ 6

II.4.2. L’entité d'un réseau UMTS…………………………………………… 6

II.4.3. Le débit de l'UMTS…………………………………………………….. 7

II.5. La quatrième génération des téléphones mobiles 4G (LTE)………………….. 7

II.5.1. Performances du LTE ………………….………………….…….…… 8

II.5.2. Caractéristiques et entités du réseau EPS …………………………… 9

II.5.3. Architecture du réseau EPS ………………………………………….. 10

II.5.3.1. Entité eNodeB ……………………………………………… 11

II.5.3.2. Entité MME (Mobility Management Entity)……………… 12

II.5.3.3. Entité Serving GW (Serving Gateway)…………………… 13

II.5.3.4. Entité PDN GW (Packet Data Network Gateway)…........... 14

II.5.3 .5. Entité HSS (Home Subscriber Server) ….............................. 15

II.5.3.6. Entité PCRF (Policy & Charging Rules Function)………… 15

III.1. Attachement de l’UE au réseau EPS …………………………………………. 15

III.2. Détachement de l’UE au réseau EPS ………………………………………… 16

Chapitre II : La voix sur LTE

II. CSFB (Circuit Switched FallBack) …................................................................... 17

III. VoLGA (Voice Over LTE via Generic Access)..………………………….……….. 19

IV. VoLTE (voice over LTE) via IP Multimedia Subsystem…………………………… 20

IV.1. L’architecture IMS…………………………………………………………. 21

IV.1.1. La couche accès ……………………………………………………. 21

IV.1.2. La couche de transport ……………………………………………… 21

IV.1.3. La couche de contrôle …………………………………………….. 22

IV.1.4.La couche application ……………………………………………….. 25

V. Le modèle protocolaire ……………………………………………………………. 26

V.1. La notion de ‘Bearer’ et QCI …………………………………………………… 26

V.2. Etablissement de dedicated bearer pour les services IMS ………………….. 27

VI. Protocoles mise en œuvre en VoLTE …………………………………………….. 28

VI.1. Le protocole DIAMETER …………………………………………………. 28

IV.1.1. Les messages DIAMETER ………………………………………….. 29

VI.2. Le protocole SIP …………………………………………………………….. 30

VI.2. 3 Les requêtes ………………………………………………………..... 30

VI.2.4 Les réponses …………………………………………………………. 32

VI.2.5 Les en-têtes ……………………………………………………………. 33

VI.4. Les protocole RTP et RTCP………………………………………………… 35

VI.4.1. Le protocole RTP…………………………………………………... 35

VI.4.2. Le protocole RTCP……………………………………………….... 35

VI.5. Le protocole MEGACO…………………………………………………… 35

VI.6. Codage des signaux …………………………………………………………. 36

VII. L’établissement d’une communication dans le réseau IMS……………………… 36

VII.1. Enregistrement d’un terminal dans le réseau IMS…………………………. 36