etude et mise en place de la solution voip over lte, dimensionnement et mesure de la qos

U!1.D9-/ ~J 19lD ii...A..DL.:;14;J9-l9-iLiJ19 ,a9-LJ:L..l.lUSTHB

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

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

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

ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESURE DE LA

QoS

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 3.1 : Mean opinion score (MOS)……………………………………………….. 53

Tableau 2.3 : Le protocole SDP………………………………………………………….. 34

Introduction

Générale

IInnttrroodduuccttiioonn ggéénnéérraallee

Introduction générale

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

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 :

acer

Line

CCHHAAPPIITTRREE II

CChhaappiittrree 11 :: GGéénnéérraalliittéé ssuurr lleess rréésseeaauuxx mmoobbiilleess

2

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.

VLR

AUC

.................

........ Aux data interne

•••••••• Ondes radio

EdlanoesdeSolS

...-,.....

BSC

._CJSMSC

................... - OTA............


3

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.

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

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 :


4

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

La mise en place d’un réseau GPRS va permettre à un opérateur de proposer des nouveaux services

de type "Data" à ses clients.

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

~••••••• i._ PLMN

GPRS~


5

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.

Figure 1.2 : Architecture du réseau GPRS.

/_---ISDN ~PSDN )

~/""'

Internet~

•••••• /~p ~I... LMNGPRS


6

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.

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

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

Figure 1.3 : Architecture du réseau UMTS [3].

La mise en place du réseau UMTS (Figure 1.3) abords des nouveaux éléments sur le réseau sont:


7

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


8

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


9

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.

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

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


10

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


11

Le réseau EPS consiste en les entités suivantes :

II.5.3.1. Entité eNodeB :

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

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.


12

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.


13

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


14

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


15

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


16

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.

CCHHAAPPIITTRREE IIII

CChhaappiittrree 22 :: LLaa vvooiixx ssuurr LLTTEE

17

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

Figure 2.1 : La solution CSFB (Circuit SwitchedFallback) [8].

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


18

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


19

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

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.

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.


20

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

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

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


21

IV.1. L’architecture IMS

IMS propose une approche modulaire qui permet de distinguer des niveaux de traitements

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.

Figure 2.4 : L’architecture de réseau IMS [12].

différents (Figure 2.4).


22

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 :


23

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


24

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.


25

• 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].


26

V. Le modèle protocolaire :

Pour qu’une communication soit établi entre un client LTE et un serveur d’application situe au

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.

Figure 2.5 : Le modèle protocolaire [14].

réseau IMS les paquets émis doivent suivi la pile protocolaire représentés dans la Figure 2.5 :


27

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.

QCI Type de bearer priorité Latence (ms) Packetloss Exemple

1

GBR

2 100 10-2

Appel VoLTE

2 4 150 10

-3 Appel visiophoné

3 3 50 Jeu online

4 5 300

10-6

Vidéo streaming

5

Non-GBR

1 100 IMS signalisations

6 6 300 Vidéo, email, chat, ftp

…etc.

7 7 100 10-3 Voix, vidéo, jeu

interactive

8 8 300 10

-6 Internet

9 9

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

Tableau 2.1 : les différents types des bearers et QCI [15]

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

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


28

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

Figure 2.6. Création d’un dedicated bearer pour la VoLTE[16].


29

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


30

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.


31

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.


32

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.

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

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.

Tableau 2.2 : Les types de réponses [19].

Les différents types de réponses sont explicités au tableau (Tableau 2.2) :


33

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.


34

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

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

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


35

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


36

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.


37

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

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.


38

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


39

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.

Figure 2.8.Mise en communication de deux terminaux

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


40

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


41

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.

CCHHAAPPIITTRREE IIIIII

CChhaappiittrree 33 :: RRééaalliissaattiioonn PPrraattiiqquuee

42

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:

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

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.


43

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


44

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.

Figure 3.2 : Architecture de banc d’essai

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)


45

III.1. Demande 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

Figure 3.3 : les messages SIP mise en jeu pendant le processus 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.


46

III.2. Etablissement d’une session audio, vidéo :

Figure 3.4 : Procédure d’enregistrement capturé avec SIPWorkbench

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


47

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.

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


48

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


49

Figure 3.7 : la bande passante de codec G.711 (PCMA)

Figure 3.8 : la bande passante de codec GSM

Flux RTP de codec GSM

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.

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.


50

Figure 3.9: la bande passante de codec AMR (G.722.2)12.65 Kbps

IV.2. bande passante des codecs vidéo :

Figure 3.10 : la bande passante de codec H.264

Flux RTP de codec H.264

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


51

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)

Figure 3.11 : La gigue mesurée pour un codec G.711 (PCMA)

La gigue

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


52

Figure 3.12 : La gigue mesurée pour un codec GSM

Figure 3.13: La gigue mesurée pour un codec AMR (12.65 kbps)

V.3. Les codecs vidéo :

La gigue

La gigue

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.

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.


53

Figure 3.14 : La gigue mesurée pour un codec h.264

VI. Mean Opinion Score (MOS):

Codec MOS Qualité

G.711 4.1 Excellents

GSM 3.5 Juste

AMR 4.14 Excellents

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.

Tableau 3.1 : 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.


54

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.

VII.1. Délai d’établissement d’une session donnée :

Figure 3.15 les messages SIP mise en jeu pendant l’envoi d’un message

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


55

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 :

Figure 3.16 les messages SIP publie pendant 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)


56

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


57

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


58

Figure 3.20 les messages SIP échangé pendant le processus IPTV

Figure 3.21 fonctionnement d’IPTV capturée avec SIPWorkbench


59

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


60

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

Figure 3.23 : fichier de configuration de S-CSCF


61

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.

Conclusion

Générale

Conclusion et Perspectives

62

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.

acer

Line

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 Core

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

AAnnnneexxee

Annexe

I

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.

Annexe

II

É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

Annexe 2 : Guide d'installation OpenIMSCore : [23]

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

https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk

https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk

Annexe

III

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

cd ..

o Si quelque chose se brise, vous n’avez probablement pas toutes les conditions préalables.

FHoSS

o ser_ims cd

o make install-libs all

https://sourceforge.net/p/openimscore/code

https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk

https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk

Annexe

IV

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.

Annexe

V

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.

Annexe

VI

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

Annexe

VII

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.

Annexe

VIII

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é

http://localhost:8080/

http://www.openimscore.org/mailto:[email protected]

http://www.openimscore.org/mailto:[email protected]

Annexe

IX

Créer une identité publique :

Créer une identité privée

Annexe

X

Création des AS au niveau du HSS :

Paramétrage du serveur AS :

Paramétrage du Trigger Point de serveur :

Annexe

XI

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

BBiibblliiooggrraapphhiiee

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.

BBiibblliiooggrraapphhiiee

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

[22] www.fokus.fraunhofer.de . juin 2015

[23] www.openimscore.org . Juin 2015

Webographie:

ملخص

لنقل الحزم IPيعتمدان كليا على البروتوكول EPCونظام نقل الحزم المطور LTEالتكنولوجيا الالسلكية التي تستعمل شبكات المحمول الجيل الرابع

لثالث (GSM) نشرت بالفعل في شبكات الجيل الثاني التقليدية التي النقالةفي حين أن خدمات الهواتف ,بمعدل تدفق مرتفع ومنخفضة الكمون

ألن هذا النوع من الشبكات ال يدعم اإلشارات الهاتفية. LTEيمكن استغاللها في شبكات ال

العديد من الحلول التقنية لحل هذه المشكلة، من بين هذه الحلول نجد GSMAو GPP3لمواجهة هذه المشكلة قدمت منظمات االتصاالت مثل

VoLTE الصوت عبر(LTE الذي يستخدم )IMS نظام( دعم الوسائط المتعددة عبرIP كمنصة إلدارة إشارات ،)SIP،دفع، وجودة ال ، التسجيل

(.G3و G2الجيل الثالث الخلوية مثل )األرضية و الخدمة، و الربط بين أنواع مختلفة الشبكات الهاتف

ل، األداء وجودة الخدمة.في هذا السياق قمنا بدراسة التقنيات المستخدمة لتنفيذ هذا الح

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.

و ا

(UMTS)