Cours - 108

Université Sultan Moulay Slimane
Ecole Nationale des Sciences Appliquées

de Khouribga
Nouvelles Générations des Réseaux

Next Generation Network
NGN
Filière : Génie Réseaux & Télécommunications

Département : Génie Réseaux & Télécommunications
Semestre : 5
Pr. O. IBRIHICH
Année universitaire 2018-2019
Ecole Nationale des Sciences Appliquées,Bd Béni Amir, BP 77, Khouribga - Maroc
Tel +2125 23 49 23 35 /+2126 18 53 43 72, Fax : +212 05 23 49 23 39,
http://www.ensa.uh1.ac.ma/ensak/
Objectifs du cours
— Présenter les nouvelles générations de réseaux dites
NGN orientées services et non plus infrastructures ré-
seaux en traitant l’ensemble des composantes formant
l’édifice NGN ;
— Présenter le concept de l’architecture IMS que ce soit
d’un point de vue global que d’un point de vue fonction-
nel en définissant les éléments principaux de l’architec-
ture IMS.
2
Liste des abréviations
3GPP 3rd Generation Partnership Project

AN Access Network
ATIS Alliance for Telecommunications Industry Solutions
ATM Asynchronous Transfer Mode
CCSA China Communications Standards Association
DSLAM DSL Access Multiplexer
DSL Digital Subscriber Line
EDGE Enhanced Data Rates for GSM Evolution
ETSI European Telecommunications Standards Institute
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
IAD Integrated Access Device
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IMS IP Multimedia Subsystem
IP Internet Protocol
ITU-T International Telecommunication Union Telecommunication Standardization Sector
IVR Interactive Voice Response
MGCP Media Gateway Control Protocol
MGW Media Gateway
MSAN Multi Service Access Node
NAT Network Address Translation
NGN-GSI Next Generation Networks Global Standards Initiative
3
Liste des abréviations 4
NGN Next Generation Network

PSTN Public Switched Telephone Network
RFC Request For Comment
RNIS Réseau Numérique à Intégration de Services
RTC Réseau Téléphonique Commuté
SBC Session Border Controller
SCP Service Control Point
SGW Signalling Gateway
SIP Session Initiation Protocol
SLAs Service Level Agreements
TDM Time Division Multiplexing
TISPAN Telecoms & Internet converged Services & Protocols for Advanced Networks
TTA Telecommunications Technology Association
TTC Telecommunication Technology Committee
UMTS Universal Mobile Telecommunications System
VoIP Voice over IP
W-CDMA Wideband Code Division Multiple Access
WAP Wireless Application Protocol
WLAN Wireless Local Area Network
WiFi Wireless Fidelity
WiMAX Worldwide Interoperability for Microwave Access
Table des matières
Objectifs du cours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Liste des abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapitre 1: Convergence et NGN : points essentiels . . . . . . . . . . . . . . . . . . . . . 13
1.1 Préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.1 Problématique des réseaux d’aujourd’hui . . . . . . . . . . . . . . . . . . . . 13
1.1.2 Pourquoi le NGN ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1.3 Travaux de standardisation pour les NGN . . . . . . . . . . . . . . . . . . . 15
1.2 Vision générale sur les NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Les services offerts par NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.3 Les exigences de tourner vers NGN . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.4 Caractéristiques du réseau NGN . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.5 Avantages des NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3 Classification des réseaux NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.1 Types des NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.2 Les Classes des réseaux NGN . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Architecture des réseaux NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4.1 Architecture NGN téléphonie . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.4.2 Entités fonctionnelles du cœur de réseau . . . . . . . . . . . . . . . . . . . . 29
1.5 Evolution des réseaux de télécommunication . . . . . . . . . . . . . . . . . . . . . . 30
1.6 Evolution de la couche accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6.1 Les réseaux d’accès fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5
Table des matières 6
1.6.2 Les technologies d’accès fixe sans fil/radio . . . . . . . . . . . . . . . . . . . 34
Chapitre 2: Téléphonie sur IP et migration NGN du cœur de réseau

fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1 Description d’un réseau téléphonique traditionnel . . . . . . . . . . . . . . . . . . . 38

2.1.1 Architecture d’un réseau RTC . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.1.2 Avantages RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.1.3 Inconvénients de commutation de circuit . . . . . . . . . . . . . . . . . . . . 40
2.1.4 Le PABX (Private Automatic Branch eXchange) . . . . . . . . . . . . . . . . 40
2.2 Typologie des scénarios de migration . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.2.1 Scénario 1 : Mise en place de solutions NGN au niveau des liens de transit . 43
2.2.2 Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur de classe 4 45
2.2.3 Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5 . . . . . . . . 45
2.2.4 Scénario 4 : Mise en place de solutions tout IP en overlay . . . . . . . . . . . 46
2.3 NGN Téléphonie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.1 Architecture NGN Téléphonie . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.2 Services dans le RTC versus Services dans le NGN Téléphonie . . . . . . . . 48
2.4 La téléphonie sur IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.1 Principe de la téléphonie sur IP . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.2 La téléphonie sur réseaux sans fil . . . . . . . . . . . . . . . . . . . . . . . . 56
2.4.3 La téléphonie sur WiMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.5 La qualité de service et ToIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.5.1 Les protocoles de contrôle d’appel . . . . . . . . . . . . . . . . . . . . . . . . 66
2.5.2 Les protocoles de commande de Media Gateway . . . . . . . . . . . . . . . . 79
2.6 La pratique de la téléphonie sur IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.6.1 Le modèle de téléphonie tout-IP . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.6.2 Téléphoner gratuitement d’un PC vers un téléphone fixe . . . . . . . . . . . 87
2.6.3 Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.6.4 Windows Live Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.6.5 Yahoo ! Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.6.6 Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.6.7 Google Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.6.8 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Chapitre 3: Les familles de protocoles d’un réseau NGN . . . . . . . . . . . . . . . . 93
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.2 Protocole H.248/Megaco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.2.1 H.248/Megaco dans les IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.2.2 Modèle de connexion H.248/Megaco . . . . . . . . . . . . . . . . . . . . . . . 95
3.2.3 Format des messages H.248/Megaco . . . . . . . . . . . . . . . . . . . . . . . 98
3.3 Le protocole COPS (Common Open Policy Service) . . . . . . . . . . . . . . . . . . 99
3.3.1 Format des messages COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.3.2 Classes des objets du message . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.3.3 Messages du protocole COPS . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.3.4 Classes de qualité de service . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4 Le protocole DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.4.1 Les responsabilités de Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.4.2 Entités DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.4.3 Transactions DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.4.4 Format du message DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . 111
Chapitre 4: Concepts et Architecture IMS (IP Multimedia Subsys-

tem) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.2 Accès multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
4.3 Collaboration mondiale des organismes de normalisation . . . . . . . . . . . . . . . 126
4.3.1 L’approche 3GPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.3.2 L’approche TISPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.3.3 L’approche OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.4 Evolution des réseaux mobiles vers l’IMS . . . . . . . . . . . . . . . . . . . . . . . . 130
4.5 Concepts IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.6 Pourquoi IMS ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.6.1 Notions de réseau visité et de roaming . . . . . . . . . . . . . . . . . . . . . 133
4.7 Architecture d’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.7.1 Architecture fonctionnelle en couche d’IMS . . . . . . . . . . . . . . . . . . . 134
4.7.2 Principaux composants de l’architecture IMS . . . . . . . . . . . . . . . . . . 136
4.8 Gestion des identités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.8.1 Public User Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

4.8.2 Private User Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.8.3 Relations entre Public et Private User Identity . . . . . . . . . . . . . . . . 148
4.9 Carte USIM et ISIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.9.1 SIM (Subscriber Identify Module) . . . . . . . . . . . . . . . . . . . . . . . . 149
4.9.2 USIM (Universal Subscriber Identity Module) . . . . . . . . . . . . . . . . . 150
4.9.3 ISIM (IMS Subscriber Identity Module) . . . . . . . . . . . . . . . . . . . . 150
4.10 Protocoles utilisés dans l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.10.1 Les extensions du protocole SIP dans l’IMS . . . . . . . . . . . . . . . . . . 151
4.10.2 Les commandes DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.11 Procédure générale pour obtenir le service IMS . . . . . . . . . . . . . . . . . . . . . 153
4.11.1 Enregistrement basé sur ISIM/USIM . . . . . . . . . . . . . . . . . . . . . . 154
4.11.2 Interfaces vers la base des abonnés . . . . . . . . . . . . . . . . . . . . . . . 156
4.12 Sécurité dans l’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4.12.1 Défis de sécurité en IMS et attaques potentielles . . . . . . . . . . . . . . . . 159
4.12.2 Quelques notions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.12.3 Mécanisme de sécurité en IMS . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.13 Technologies pour le développement de services télécom dans IMS . . . . . . . . . . 165
4.13.1 JAIN SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.13.2 JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.13.3 Les SIP Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.13.4 Implémentations existantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.13.5 Voice XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.13.6 Call Control XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.13.7 State Chart XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.13.8 Technologies de développement alternatives . . . . . . . . . . . . . . . . . . 172
Références. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Table des figures
1.1 Réseau multi-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.2 Architecture d’un réseau NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Types de NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4 Architecture simplifiée des NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Architecture en couche des NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.6 Evolution des réseaux de télécommunication . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Architecture d’un réseau RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.2 Le PABX au coeur des services d’entreprise . . . . . . . . . . . . . . . . . . . . . . 41
2.3 Du PABX à l’IPBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4 Architecture d’une solution NGN pour le trafic de transit international . . . . . . . 44
2.5 Architecture d’une solution NGN pour le trafic de transit national . . . . . . . . . . 44
2.6 Architecture d’une solution NGN de classe 4 . . . . . . . . . . . . . . . . . . . . . . 45
2.7 Architecture d’un réseau NGN de classe 5 . . . . . . . . . . . . . . . . . . . . . . . 46
2.8 Architecture overlay VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.9 Exemple d’architecture NGN Téléphonie . . . . . . . . . . . . . . . . . . . . . . . . 48
2.10 Services dans le RTC vis-à-vis Services dans le NGN Téléphonie . . . . . . . . . . . 49
2.11 La technique de transfert de paquets . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.12 Un flot de paquets téléphoniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.13 Équipements à traverser par une communication téléphonique sur IP . . . . . . . . 53
2.14 Temps de transfert d’un paquet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.15 Voix sur IP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.16 Réseau WiMax 802.16e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.17 Format de la trame WiMax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.18 Réémission avec TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.19 Le contrôle de session par RTP et RTCP. . . . . . . . . . . . . . . . . . . . . . . . . 62
2.20 En-tête RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.21 Architecture de H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.22 Format générique d’un message SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.23 Rôle fédérateur du protocole MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . 79
9
Table des figures 10
2.24 L’architecture MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

2.25 Mise en relation de deux endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.26 Format d’un message MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.27 Le modèle de téléphonie tout-IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.28 Le modèle de téléphonie IP/RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.29 Téléphones Skype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.30 Fenêtre principale de WLM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.31 Modèle Yahoo ! Messenger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.32 Le modèle décentralisé de Jabber . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.33 Modèle Google Talk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.34 Procédure de call-back . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.1 Les tâches principales de H.248/Megaco . . . . . . . . . . . . . . . . . . . . . . . . 94

3.2 Architecture du système COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.3 Format du message COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.4 Message COPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5 Représentation schématique des échanges COPS . . . . . . . . . . . . . . . . . . . . 103
3.6 Le protocole DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.7 Les nœuds DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.8 Transactions DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.9 Format du message DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.10 Message DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.11 Commande de base DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.12 Commandes diameter de l’interface Cx . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.13 Format d’un AVP DIAMETER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.14 DIAMETER dans NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.15 Messages DIAMETER sur les interfaces Cx et Dx . . . . . . . . . . . . . . . . . . . 119
3.16 Les valeurs définies pour les attributs des AVP . . . . . . . . . . . . . . . . . . . . . 119
3.17 DIAMETER sur l’interface Sh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.18 Messages DIAMETER sur l’interface Sh . . . . . . . . . . . . . . . . . . . . . . . . 120
3.19 Enregistrement d’un abonné IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.20 Architecture des systèmes de facturation . . . . . . . . . . . . . . . . . . . . . . . . 123
4.1 IMS connectant à plusieurs réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.2 Accès multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.3 Organisations de normalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.4 Core IMS dans 3GPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

4.5 L’approche TISPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.6 L’approche OMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
4.7 Evolution des réseaux mobiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.8 Historique d’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.9 Architecture IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.10 Composants d’IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.11 SLF (Subscription Locator Function) . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.12 Structure des informations des tables du HSS . . . . . . . . . . . . . . . . . . . . . 138
4.13 Call Session Control Function (CSCF) . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.14 Proxy CSCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.15 L’Interrogating CSCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.16 Le Serving CSCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.17 Identités IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.18 Relation des identités des utilisateurs privés et publics dans 3GPP R5 . . . . . . . . 148
4.19 Relation des identités des utilisateurs privés et publics dans 3GPP R6 . . . . . . . . 148
4.20 SIM, USIM et ISIM dans la carte UICC des terminaux IMS 3GPP . . . . . . . . . . 149
4.21 Procédure générale pour obtenir le service IMS . . . . . . . . . . . . . . . . . . . . . 154
4.22 Enregistrement d’un terminal IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
4.23 Les étapes d’enregistrement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.24 Appel entre réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.25 Exemple de communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4.26 Menaces potentielles dans IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.27 Attack fin de session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.28 Attack Vol de média . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.29 Différentes zones de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.30 Sécurité de l’accès NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.31 Sécurité de la communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.32 Architecture de JAIN SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.33 Architecture de JSLEE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.34 Architecture de SIP Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.35 Exemple de SIP Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.36 JAIN SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.37 Mobicents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.38 SailFin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.39 Cipango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

4.40 Exemple d’un programme XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.41 Exemple d’un programme CCXML . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.42 Chart XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.43 Adhearsion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.44 Echarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.45 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Chapitre
1
Convergence et NGN : points essen-
tiels
1.1 Préliminaire
1.1.1 Problématique des réseaux d’aujourd’hui
— Il existe différents réseaux (fixe, mobile, sansfil,...), standardisés par différentes organisations
(ITU-T, GSM-ETSI, 3GPP, IEEE,...).
— Tous ces réseaux ont été développés avec des intentions et des objectifs indépendants les uns
par rapport aux autres.
— Il n’y a aucun concept commun entre eux qui permettrait un point de facturation commun,
l’utilisation d’une adresse IP unique, la fourniture de services communs (VoIP, vidéoconfé-
rence, messagerie instantanée, jeux multi-joueurs,...), l’utilisation d’une identification com-
mune comme le numéro de téléphone ou l’identité de l’utilisateur, indépendamment de la
technologie utilisée et du lieu d’accès, tout en garantissant une qualité de service.
— Infrastructures séparées pour voix, données et vidéo ;
— Difficulté pour intégrer les applications ;
— Le réseau voix n’a pas été con¸u pour traiter les flux intégrés de données, voix et vidéo.
a) Limitations des architectures actuelles
— Le réseau GSM/GPRS pour les communications avec les téléphones mobiles,
— Les réseaux de données (ATM, IP) pour le transport de données inter et intra-
entreprises,
13
Chapitre 1 Convergence et NGN : points essentiels 14
Figure 1.1: Réseau multi-service
— Le réseau câblé pour la diffusion TV,
— Le réseau RTC/RNIS pour les communications téléphoniques "fixes",
— Le réseau Internet sur IP.
b) Inconvénients
— Incompatibilité des réseaux existants avec les nouveaux services (le réseau RTC n’a pas
été con¸u pour supporter des longues connexions internet),
— La capacité de transmission est utilisée et redistribuée de manière inefficace,
— Les coûts d’opération augmentent, Investissements multiples,
— Existence de protocoles et d’architectures propriétaires.
Aujourd’hui seul un service sur mesure pourrait être proposé grâce aux accès à hauts débits
déjà plus ou moins en place (xDSL, câble, UMTS).
c) Solutions
— Offrir un mode d’acheminement des données indépendant, d’une part, du type de tech-
nologies réseaux sous-jacentes (Ethernet, Fibre optique, WiFi, WiMAX, Satellite,
3G/2G, etc.) et, d’autre part, du type de données véhiculées (audio, vidéo, données),
— Réaliser, à travers la nouvelle solution, le support de multiples services (téléphonie,

télévision, services Internet) au sein d’une unique infrastructure tirant parti de l’hété-
rogénéité des technologies d’accès.
1.1.2 Pourquoi le NGN ?
Pour les opérateurs, l’accès et le transport ne sont plus assez lucratifs et, pour rester compétitif,
il leur faudra donc offrir aux usagers toute une gamme de services utiles, faciles à utiliser et
rémunérateurs. Par conséquent, les NGN seront axés sur les services, et fourniront tous les moyens
nécessaires pour en offrir de nouveaux et adapter les existants pour augmenter les recettes. En fait,
on pourra choisir les NGN grâce à :
— La Souplesse pour l’élaboration et l’offre de services,
— La Réduction de coût prévisibles du fait du partage de l’infrastructure et des systèmes,
— La Simplification de l’exploitation et de la maintenance, d’où une diminution des dépenses

d’exploitation
— L’utilisation d’interfaces ouvertes entraîne : Un Déploiement rapide des services et applica-

tions, De nouveaux services(tiers).
1.1.3 Travaux de standardisation pour les NGN
Plusieurs organismes de standardisation interviennent dans la normalisation des NGN :
— 3GPP (3rd Generation Partnership Project ),
— IETF (Internet Engineering Task Force ),
— ETSI (European Telecommunications Standards Institute),
— ITU-T(International Telecommunication Union Telecommunication Standardization Sector),
— ATIS (Alliance for Telecommunications Industry Solutions),
— IEEE (Institute of Electrical and Electronics Engineers),
— TISPAN (Telecoms & Internet converged Services & Protocols for Advanced Networks),
Ainsi qu’une force commune de travail entre :
— TTA (Telecommunications Technology Association) en Corée,
— CCSA (China Communications Standards Association ) en Chine,
— TTC (Telecommunication Technology Committee) en Japon.
a) IETF
— Organisme international, ouvert à tout individu, formé par des concepteurs de réseaux,
des opérateurs, des vendeurs et des institutions de recherche qui travaillent ensemble
pour définir des standards pour les protocoles Internet tel que TCP/IP.
— Produit la plupart des nouveaux standards d’Internet.
— Organisé en des groupes de travail (Working Group).
— Standards exprimés sous forme de RFC (Request For Comment).
b) 3GPP
— Créé en 1998 suite à une convention de coopération entre des organismes de standardisa-
tion régionaux en Télécommunications tels que l’ETSI (Europe), ARIB /TTC (Japon),
CCSA (Chine), ATIS (Amérique du Nord) et TTA (Corée du Sud).
— Vise à produire des spécifications techniques pour les réseaux mobiles de 3ème généra-
tion (3G) basés sur la norme 2G GSM, 3G UMTS.
— Ne produit pas des standards.
— Produit des spécifications techniques (TS) et des rapports techniques (TR) qui, une
fois approuvés, sont délivrés aux organismes partenaires pour produire les standards
nécessaires.
— 3GPP Release 5 contient la spécification de la première version du NGN multimédia

(IMS).
c) TISPAN
— Groupe de travail au sein de l’ETSI.

— Standardisation des réseaux de prochaine génération (NGN) et de leur interfonctionne-

ment avec les réseaux et services téléphoniques existants.
— Production des spécifications pour la distribution des services de téléphonie, de voix sur
IP et plus largement des services multimédia dans le contexte NGN.
d) ITU-T
— Chargée de la réglementation et de la planification des télécommunications dans le

monde.
— établit les normes de ce secteur.
— Diffuse toutes les informations techniques nécessaires pour permettre l’exploitation des
services mondiaux de télécommunications.
— A lancé l’initiative NGN-GSI qui :
— Se concentre sur l’élaboration de normes détaillées nécessaires pour le déploiement NGN

pour donner aux fournisseurs de services les moyens d’offrir l’éventail des services at-
tendus dans les réseaux NGN.
— Harmonise, en collaboration avec d’autres organismes, différentes approches de l’archi-

tecture NGN dans le monde entier.
e) IEEE
— Organisation à but non lucratif.
— Constituée d’ingénieurs électriciens, d’informaticiens, de professionnels du domaine des

télécommunications, etc.
— A pour but de promouvoir la connaissance dans le domaine de l’ingénierie électrique (

électricité et électronique).
— Joue un rôle important dans le développement des technologies d’accès sans fil
(Wifi,Wimax, etc..).
f) OMA
— Crée en 2002 pour répondre à la prolifération de forums professionnels traitant chacun

de quelques protocoles applicatifs pour les mobiles (forum WAP en charge de la nor-
malisation des protocoles de navigation web et forum Wireless Village en charge de la
détection de présence et de la messagerie instantanée).
— Organisme de standardisation qui développe des standards ouverts pour l’industrie des
téléphones mobiles.
— Son Objectif est de fournir des services multimédias et interopérables pour les mobiles.
1.2 Vision générale sur les NGN
1.2.1 Définition
Définition 1
L’ETSI (European Telecommunications Standards Institute) par exemple, définit le NGN
comme étant "un concept pour définir et déployer les réseaux, qui du fait de leur sépara-
tion formelle en différentes couches et plans et de l’utilisation d’interfaces ouvertes, offrent aux
fournisseurs de services ainsi qu’aux opérateurs une plateforme évolutive pour créer, déployer
et gérer des services multimédias innovants".
Définition 2
Les NGN sont définis comme un réseau de transport en mode paquet permettant la convergence
des réseaux Voix/données et Fixe/Mobile ; ces réseaux permettront de fournir des services
multimédia accessibles depuis différents réseaux d’accès.
Définition 3
Les NGN sont basés sur une évolution progressive vers le "tout IP" et sont modélisés en couches
indépendantes dialoguant via des interfaces ouvertes et normalisées. Afin d’offrir aux fournis-
seurs de services ainsi qu’aux opérateurs une plateforme évolutive pour créer, déployer et gérer
des services multimédias innovants, ainsi les services doivent être évolutifs et accessibles indé-
pendamment des réseaux d’accès.
Figure 1.2: Architecture d’un réseau NGN
1.2.2 Les services offerts par NGN
Les NGN offrent les capacités, en termes de protocole, de gestion, et d’infrastructure, de déployer
et de créer de nouveaux services multimédia en mode paquet sur les réseaux. La grande des services
est due aux variétés offertes par les réseaux NGN en termes de :
— Support multimédia (données, texte, audio, visuel).
— Mode de communication, Unicast (communication point à point), Multicast (Communication

point-multipoint), Broadcast (diffusion).
— Portabilité sur des terminaux,
— Mobilité (services disponibles tout le temps et partout).
Parmi ces services fournis aussi nous citons :
— La voix sur IP,
— La diffusion de contenus multimédia,
— La messagerie unifiée,
— Le stockage de données,
— La messagerie instantanée,
— Les services associés à la localisation.
1.2.3 Les exigences de tourner vers NGN
Depuis quelques années, les laboratoires des constructeurs et les organismes de standardisation se
penchent sur une nouvelle architecture réseau les Next Generation Networks (NGN) pour répondre
aux exigences suivantes
— Les réseaux de télécommunications sont spécialisés et structurés avant tout pour la téléphonie
fixe.
— Le développement de nouveaux services, évolution des usages du réseau d’accès fixe et l’ar-
rivée du haut débit.
— La migration des réseaux mobiles vers les données.
— Difficulté à gérer des technologies multiples (ATM, TDM, IP) Seul un vrai système intégré
peut maîtriser toutes ces technologies reposant sur la voix ou le monde des données.
— Prévision d’une progression lente du trafic voix et au contraire une progression exponentielle
du volume de données => baisse de la rentabilité des opérateurs.
1.2.4 Caractéristiques du réseau NGN
Des impératifs ont été clairement identifiés par les organismes œuvrant pour les réseaux NGN
(3GPP, ITU-T, ETSI,...) :
— Un cœur de réseau unique et mutualisé pour tous les types de réseaux d’accès et de services,
— Une architecture de cœur de réseau en deux couches : Transport et Services,
— Une évolution du transfert des données vers le mode paquet,
— Des interfaces ouvertes et standardisées entre chaque couche afin de réaliser l’indépendance
des services vis-à-vis du réseau,
— Un découplage entre la fourniture de service et la fourniture de réseau.
— Le support de technologies d’accès multiples,
— Le support de la convergence des réseaux voix/données et fixe/mobile,
— Le support de terminaux multiples (modulaires, multimode, multimédia et adaptatifs).
La principale caractéristique d’un réseau de nouvelle génération est son fondement sur IP qui offre
un mode de transfert homogène de bout en bout, indépendant d’une part, des réseaux sous-jacents
et, d’autre part, du type de données applicatives véhiculées.
1.2.5 Avantages des NGN
Cette nouvelle topologie offre les avantages suivants :
— Grâce au NGN, l’opérateur dispose d’un réseau multiservice permettant d’interfacer n’im-
porte quel type d’accès (Boucle locale, PABX, Commutateur d’accès téléphonique, accès
ADSL, accès mobile GSM ou UMTS, téléphone IP, etc.).
— L’opérateur n’aura plus à terme qu’à exploiter un seul réseau multiservice.
— Elle utilise le transport comme l’IP ou l’ATM ignorant les limites des réseaux TDM (Time
Division Multiplexing) à 64 kbit/s. En effet le TDM perd son efficacité dès lors que l’on sou-
haite introduire des services asymétriques, sporadiques ou à débit binaire variable. C’est une
topologie ouverte qui peut transporter aussi bien les services téléphoniques que les services
de multimédia (vidéo, données temps réel).
— Elle dissocie la partie support du réseau de la partie contrôle, leur permettant d’évoluer sépa-
rément et brisant la structure de communication monolithique. En effet, la couche transport
peut être modifiée sans impact sur les couches contrôle et application.
— Elle utilise des interfaces ouvertes entre tous les éléments, permettant à l’opérateur d’acheter
les meilleurs produits pour chaque partie de son réseau.
1.3 Classification des réseaux NGN
1.3.1 Types des NGN
Les NGN peuvent être divisé en deux :
— Un NGN téléphonie qui est l’évolution des réseaux traditionnels pour le transport de la voix.
D’un point de vue de l’utilisateur, il y a peu d’évolution par rapport aux services offerts
aujourd’hui.
— Un NGN Multimédia, qui est une architecture offrant les services multimédia (message-
rie vocale/vidéo, conférence audio/vidéo, tonalité ou sonnerie de retour (Ring-back tone)
voix/vidéo) puisque l’usager a un terminal IP multimédia.
1.3.2 Les Classes des réseaux NGN
Il existe trois types de réseau NGN :
— NGN class 4,
— NGN class 5,
— NGN multimédia.
Les NGN de Class 4 et Class 5 sont des architectures de réseau offrant uniquement les services de
téléphonie. Il s’agit donc de NGN téléphonie. Le Class 4 NGN permet :
Figure 1.3: Types de NGN
— Le remplacement des centres de transit téléphoniques (Class 4 Switch).
— La croissance du trafic téléphonique en transit.
Le Class 5 NGN permet :
— Le remplacement des centres téléphoniques d’accès (Class 5 Switch).
— La croissance du trafic téléphonique à l’accès.
— La voix sur DSL/ Voix sur le câble.
Le NGN Multimédia est comme son nom indique, offre les services multimédia (messagerie vo-
cale/vidéo, conférence audio/vidéo, Ring-back tone voix/vidéo). Cette solution est plus intéres-
sante puisqu’elle permet à l’opérateur d’innover ses services. Au regard des réponses de l’ensemble
des acteurs, s’accorde globalement que le NGN est un système offrant des services multimédia en
s’appuyant sur un réseau caractérisé par plusieurs éléments :
— Un cœur de réseau unique pour les différents types de Services et d’accès.
— Une architecture de réseau en 4 couches : Accès, Contrôle, Transport et Services.

1.4 Architecture des réseaux NGN
1.4.1 Architecture NGN téléphonie
a) Modèle d’architecture en couche
Les réseaux NGN reposent sur une architecture en couches indépendantes (accès, transport,
contrôle, services) communiquant via des interfaces ouvertes et normalisées. Les services
doivent être évolutifs et accessibles indépendamment du réseau d’accès utilisé. Le NGN est
Figure 1.4: Architecture simplifiée des NGN
constitué :
— Un réseau de base de commutation de paquets pour le transport des données ;
— Des passerelles de média (MG=Media Gateway) servant d’interfaces avec le RTC, les
abonnées et les fournisseurs de services Internet.
— Des serveurs d’appels (softswitches) pour les fonctions de commande d’appel et de

service ;
— D’un système de gestion de réseau pour la fourniture de services, la garantie de services

et la facturation des services sur les NGN.
— D’un plan services et applications qui héberge les logiques de service, exécute les services
en contrôle l’exécution.
Figure 1.5: Architecture en couche des NGN
i) Couche accès
— Formée par l’ensemble des réseaux d’accès existants : accès fixe (xDSL, PSTN, ...),
accès mobile (GSM, UMTS,EDGE, ..) et accès sans fil (WLAN, Bluetooth, ..).
— Permet de connecter et gérer
— les accès des équipements utilisateurs au réseau NGN selon la technologie d’accès.
— Offre les fonctions et les équipements nécessaires à la conversion du format des

données avant leur transmission (circuit vers paquet ou paquet vers circuit).
ii) Couche Transport
— Assure le transport des flux média (voix ou données) et des informations de contrôle
et de gestion (signalisation) dans le cœur de réseau IP.
— Offre un réseau de transport commun et tout IP à tous les types de trafic (conver-
gence voix/données) et à toutes les technologies d’accès (convergence fixe/mobile).
— Fonction principale : routage + transport des paquets IP
— commutation de paquet.
— Assure : Haute fiabilité, QoS garantie, Large capacité
iii) Couche Contrôle (cœur du réseau NGN)
— Gère l’ensemble des fonctions de contrôle des services en général, et de contrôle

d’appel en particulier pour le service voix.
— Permet d’établir, de maintenir et de libérer des sessions multimédias dans le réseau

cœur IP.
— Assure l’allocation de ressources dans le réseau transport et la résolution des

adresses.
— pilotage de la couche transport.
— Contrôle l’accès aux services NGN (profils d’abonnés, accès aux plateformes de
service ).
— Equipement principale : contrôleur d’appel ou Softswitch ou bien aussi MGC (Media

Gateway Controller) : Permet de contrôler le fonctionnement des passerelles de
signalisation (SGW) et des passerelles de médias (MGW).
— Permet d’allouer les ressources nécessaires à l’établissement des appels ou des ses-
sions multimédias sur le réseau de transport (réseau cœur IP).
— Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP,
communication avec les serveurs d’application pour la fourniture des services.
— Assure l’accès aux différentes plateformes et capacités de service de la couche ser-

vice.
— Assure l’authentification des abonnés et la facturation des communications.
iv) Couche service
— Regroupe les plates-formes d’exécution de services et de diffusion de contenus.
— Offre des services à valeur ajoutée.

— Communique avec la couche contrôle via des interfaces ouvertes et normalisées.
b) Les composants au niveau de chaque couche
i) Couche accès
- Terminaux IP : peuvent être des téléphones IP, des PBX (Private Branch Exchange)
IP ou des "software phone". Ils sont basés sur les protocoles SIP ou H.323 pour la
signalisation. Ils n’ont pas besoin de convertir leur format de données car la voix à
transmettre est déjà numérisée au niveau du terminal IP.
- Integrated Access Device (IAD) : un équipement qui permet de transmettre des flux
de différentes nature : voix, vidéo, données sur un support unique, souvent une ligne de
type xDSL. Sous forme de boîtier, il permet de connecter des téléphones analogiques
mais aussi les ordinateurs. Les IAD sont aujourd’hui proposés par les fournisseurs d’ac-
cès Internet pour fournir les offres de "triple play" avec leurs box.
- Le Multi Service Access Node (MSAN) : constitue une évolution de DSLAM. Un
MSAN est une interface capable de prendre en charge des milliers de clients large bande
sur une seule interface réseau. Un MSAN permet aux opérateurs de fournir des services
de téléphonie classiques RTC, téléphonie VoIP et des services hauts débit, via une
plate-forme intégrée installée dans un centrale locale.
- DSLAM : DSL Access Multiplexer équipement fournissant l’accès DSL.
- Access Network (AN) : un réseau d’accès permet de relier les équipements des utili-
sateurs aux passerelles d’accès (MGW).
Il renferme toutes les fonctions relatives à la technologie d’accès (W-CDMA,
xDSL,WLAN, ...).
- Téléphone SIP ou téléphone H.323 : téléphone multimédia implémentant le protocole
SIP ou H.323.
- Session Border Controller (SBC) :
* Localisé à la borne administrative du réseau cœur IP pour renforcer la politique de
gestion des sessions multimédia.
- Assure les fonctions suivantes :
* Interfonctionnement et interopérabilité des protocoles entre les différents réseaux d’ac-

cès.
* Sécurité
* Gestion des SLAs (Service Level Agreements).
* Contrôle du "overload" ou surcharge de traffic.
* NetworkAddress Translation (serveur NAT).
* Gestion de QoS.
* Comptabilisation des appels.
ii) Couche Transport
— Media Gateway (MGW) :
— Se situe généralement entre un réseau à commutation de circuits (RTC) et un réseau

de commutation de paquet (Internet).
— Convertit les flux de données du mode circuit (TDM) en des flux de données en
mode paquet (IP, ATM, etc.) pour qu’ils puissent être traités par le réseau NGN.
— Signalling Gateway (SGW) : permet d’adapter la signalisation au protocole de

transport utilisé (adaptation TDM/IP).
iii) Couche service
— OSS (Operation Support System) : intègre un système de facturation, un système

de commande et de gestion réseau.
— Serveurs d’applications (AS) : forment la plateforme de création et d’exécution des

services NGN. Un serveur d’application peut héberger un ou plusieurs services.
Un service peut être composé de plusieurs services élémentaires qui impliquent
différents serveurs applicatifs.
— Serveur de média (MS) : traite les flux médias pour plusieurs services comme les
conférences multimédias, l’IVR (Interactive Voice Response), etc.
— Service Control Point (SCP) : élément clé dans les réseaux intelligents qui sauve-
garde la logique du service et les données des abonnés. Le SCP est mis à jour quand
un nouveau service est installé.
— Serveur Vidéo : permet de planifier, gérer et offrir des vidéos conférences aux utili-
sateurs NGN.
1.4.2 Entités fonctionnelles du cœur de réseau
a) Le Media Gateway (MG)
Le Media Gateway est situé au niveau du transport des flux média entre le réseau en mode
paquet et les réseaux RTC, ou entre les réseaux d’accès et le coeur de réseau NGN. Il a pour
rôle :
— La mise en paquets et le codage du flux média re¸u du RTC et vice-versa (conversion du

trafic TDM/IP).
— La transmission des flux média re¸us, suivant les instructions du Media Gateway.
— La gestion de la disponibilité de la couche physique ainsi que la détection de fautes.
b) La Signalling Gateway (SG)
La fonction SG converti la signalisation échangée entre le réseau externe interconnecté et le

réseau NGN, mais sans l’interpréter (ce rôle étant dévolu au Media Gateway). Finalement,
elle assure l’adaptation de la signalisation au protocole de transport utilisé.
c) Le SoftSwitch ou MGC
Dans un réseau NGN, c’est le MGC qui possède "l’intelligence". Il gère :
— L’échange des messages de signalisation transmise de part et d’autre avec les passerelles
de signalisation, et l’interprétation de cette signalisation.
— Le traitement des appels : dialogue avec les terminaux H.323, SIP voire MGCP, com-
munication avec les serveurs d’application pour la fourniture des services.
— Le choix du MG de sortie selon l’adresse du destinataire, le type d’appel, la charge du

réseau, etc.
— La réservation des ressources dans le MG et le contrôle des connexions internes au MG

(commande des Media Gateways).
Le Soft Switch peut être implanté sur un serveur ou installé sur un commutateur tradition-
nel TDM ou un équipement différent comme un Media Gateway. Dans ce cas, on parlera
d’architecture distribuée.
d) Le Multi Service Access Node (MSAN)
Les MSAN constituent une évolution des DSLAM. Un MSAN est un équipement existe dans
la plupart des architectures NGN, un point d’entrée vers les réseaux d’accès des opérateurs.
La selle différence avec DSLAM, c’est que le châssis ne peut supporter que des cartes des
services de type xDSL, un MSAN supporte des cartes RNIS, Ethernet,... Ce qui permet de
déployer toutes les technologies d’accès sur le réseau.
1.5 Evolution des réseaux de télécommunication
• Passé : la technologie de commutation par paquets était largement mise en oeuvre dans la
plupart des réseaux, non seulement dans les réseaux centraux comme ceux qui étaient utilisés dans
un passé lointain, mais également dans les réseaux d’accès. Cette évolution a été rendue possible
essentiellement par l’adoption du protocole IP prenant en charge la technologie xDSL et par les
efforts remarquables qui ont été déployés pour "connecter le monde". Toutefois, plusieurs services
de transmission de données utilisaient toujours un accès en mode circuits, notamment le modem.
• Présent : le mode de transmission par paquets est le principal mode assuré par les réseaux de
télécommunication, qu’il s’agisse de la téléphonie ou de la transmission de données, y compris les
communications avec des mobiles. Bénéficiant de la technologie d’accès à large bande, l’infrastruc-
ture en mode paquets concerne un grand nombre de services multimédias, y compris la téléphonie.
Cela étant, les réseaux à commutation de circuits occupent toujours une place importante pour les
services de téléphonie, même si certains de ces services commencent à être assurés par des réseaux
à commutation de paquets.
• Futur : il est prévu que la technologie de commutation de paquets soit utilisée par tous les
types de réseaux, tels que les réseaux d’accès et les réseaux centraux. Cette technologie prendra
en charge non seulement le multimédia, mais également les services de téléphonie sur les réseaux
fixe et mobile, en association avec la technologie large bande.
Figure 1.6: Evolution des réseaux de télécommunication
1.6 Evolution de la couche accès
La multiplication et les évolutions des réseaux d’accès sont identifiées par une très grande majo-
rité des acteurs interrogés dans le cadre de cette étude comme un élément déclencheur majeur
- et un moteur essentiel - de l’évolution des réseaux vers les NGN.
Les réseaux d’accès assurent l’interface entre :
• Un cœur de réseau caractérisé par sa convergence (fixe-mobile, multi-service) et sa capacité à
s’adapter au niveau des logiciels.
• Et des terminaux caractérisés par leur diversité pour s’adapter à des contraintes différentes
selon les services utilisés et les besoins des utilisateurs.
• Les réseaux d’accès sont caractérisés par :
- la multiplicité des standards

- l’évolution rapide des technologies et des performances
- Augmentation de la bande passante à prix égal ;
- Augmentation de la portée des systèmes (radio, fixe) ;
1.6.1 Les réseaux d’accès fixes
Le réseau téléphonique commuté (RTC)

• Le réseau d’accès téléphonique comme le réseau de transport longue distance associé restent
aujourd’hui des réseaux dédiés basés sur la commutation de circuits (TDM). Ils possèdent de
nombreuses interconnexions afin de gérer les communications internationales, fixe vers mobile ou
encore d’un opérateur à un autre pour une même communication.
• Ce type d’offre a amené les opérateurs alternatifs présents sur les deux types de marché (voix et
données) à développer des réseaux convergents de type paquets, afin d’optimiser leur infrastruc-
ture.
Les technologies xDSL
• Les technologies xDSL permettent d’utiliser les paires de cuivre du réseau public de téléphonie
afin d’offrir des services de données à haut débit. Différents types de technologies xDSL, offrant
des débits symétriques ou non, ont été développés ou sont en cours de spécification afin d’offrir
l’adéquation entre les technologies utilisées et les services souhaités, ainsi qu’une augmentation des
débits utilisables. Une contrainte forte de l’xDSL est la distance à parcourir sur la paire de cuivre
entre le terminal du client et le DSLAM de l’opérateur.
• Pour les offres d’interconnexion ADSL, l’interface du réseau de collecte xDSL vers le coeur de
réseau s’appuie sur des flux IP, eux-mêmes en général véhiculés sur des technologies de transport
ATM. Cette technologie permet donc une interconnexion simple et rapide pour les services de
données. Mais la voix sur ADSL est un service qui a aussi vocation à se développer. La technolo-
gie permet en effet de transporter en mode paquet jusqu’à 16 communications sur un lien DSL.
Un opérateur alternatif peut ainsi proposer une installation destinée à un groupe d’utilisateurs
(PME/PMI) pour leur téléphonie complète et leur accès Internet haut débit.
Les réseaux de données IP et Ethernet
• Les réseaux de données se composent traditionnellement d’un réseau local (LAN) sur lequel
sont rattachés les équipements terminaux ou postes clients, de commutateurs ou routeurs, et d’un
réseau distant (WAN) composé de liaisons de données qui interconnectent les différents sites. Le
protocole de transport de données maintenant le plus largement utilisé est IP.
• Ethernet est la technologie LAN la plus commune, qui utilise historiquement des câbles coaxiaux
ou des paires torsadées pour des débits de transmission jusqu’à 10 Mbit/s, et plus récemment 100
Mbit/s (Fast Ethernet).
• Un réseau Ethernet est con¸u pour transporter des flux IP natif. Par ailleurs, ses évolutions vers le
très haut débit et un support physique optique permettent maintenant d’utiliser Ethernet comme
technologie d’accès, voire de transport longue distance. Ces deux aspects en font une technologie
particulièrement pertinente dans le cadre des NGN.
Les liaisons par fibre optique
La fibre optique, incontournable de manière générale dans les réseaux de transport à très haut
débit, est un support de boucle locale "neutre", aussi bien adapté au transport de services voix
(TDM) que données (IP), et permettant un très haut débit. Elle est donc pertinente dans le cadre
de l’évolution vers les NGN.
L’accès par câble - HFC
• Le câble est le réseau large bande le plus déployé en Europe de l’Ouest. L’offre de nouveaux
services a contraint les opérateurs de câble à un effort important de mise à niveau de leurs réseaux,
généralisant l’architecture de transport mixte de type HFC (Hybrid Fibre Coax) et activant une
voie de retour bande étroite. L’architecture HFC a été reconnue comme l’une des plus fiables, tant
techniquement qu’économiquement, car elle combine les avantages de la large bande passante de la
fibre optique (utilisée au plus près de l’abonné) et les coûts faibles de la technologie câble coaxial
(utilisée pour la desserte terminale).
• Malgré sa couverture limitée, l’accès câble, de par ses possibilités techniques de transmission de
services haut débit en complément de la diffusion TV, représente un réel potentiel de services NGN
(et donc de nouveaux acteurs).

Les courants porteurs en ligne (CPL)
• La technologie CPL (Courant Porteurs en Ligne) ou PLC en anglais (PowerLine Communication)
connaît un regain d’intérêt en Europe dans le cadre d’un accès à la boucle locale d’abonné dans
des zones non desservies par d’autres techniques par exemple.
• La première génération des spécifications du PLC autorisera des débits de transmission de don-
nées dans les bâtiments de l’ordre de 5 à 10 Mbit/s, ce qui permet aisément d’envisager des
applications comme le streaming audio ou multimédia et la voix sur IP. La technologie CPL pour-
rait donc éventuellement jouer un rôle dans la diffusion de contenus multimédia de proximité (ex. :
video streaming) ou l’ADSL à l’intérieur des bâtiments.
1.6.2 Les technologies d’accès fixe sans fil/radio
Ce sont par essence des technologies convergentes voix-donnée (technologie de transport "neutre"
ou orienté données) et/ou fixe mobile (nomadisme), qui joueront donc un rôle clé dans l’émergence
des réseaux et services NGN.
La boucle locale radio (BLR)
La BLR est une technologie sans-fil large bande qui autorise la fourniture de services voix et don-
nées fixes à haut débit. Le réseau BLR se contente d’encapsuler les données dans des trames et
ainsi ne limite aucunement les types de services pouvant être offerts. La technologie utilisée pour
la transmission est le LMDS (Local Multipoint Distribution Services) qui a initialement été déve-
loppé pour la diffusion de programmes télévisuels. Aujourd’hui, les services utilisant la technologie
«LMDS» prévus selon les déclarations des opérateurs BLR couvrent une large gamme de services
de communication, à savoir :
- L’accès à Internet haut débit,
- Les liaisons louées,
- La téléphonie de base,
- Les réseaux privés virtuels (VPN) et l’interconnexion de LAN,
- Le transfert de fichier en temps réel, le video streaming

L’accès satellite
• Deux grands types de satellites peuvent être distingués : les satellites de diffusion, dits tradition-
nels, et les satellites multimédia de nouvelle génération. Les satellites multimédia sont généralement
bidirectionnels, c’est-à-dire permettant une voie de retour (qui peut aussi être terrestre). L’objectif
de ces satellites large bande est de diffuser un contenu spécifique à un utilisateur (configuration
"unicast"), ou à un groupe d’utilisateurs (configuration "multicast").
• Trois grandes familles de service peuvent être aussi envisagées : les services "multicast" basés
sur la diffusion point-à-multipoint, les services à la demande basés sur une diffusion point-à-point,
et les services d’accès à Internet bidirectionnel. Cette nouvelle génération de satellites multimédia
pourrait à moyen ou long terme relancer les programmes de fourniture de services de communica-
tions par satellite, qui ont jusqu’ici été pour la plupart des échecs de par leur coût et l’étroitesse
du marché visé, mais plutôt avec une approche de services "fixes".
Les réseaux locaux sans fil (WLAN)
• Les technologies WLAN permettent d’établir des réseaux locaux IP sans fil, entre des ordinateurs
et périphériques. Le marché visé pour la technologie WLAN est en tout premier lieu le marché
professionnel. Les services offerts aux clients sont les mêmes que ceux pour les accès fixes en mode
IP : email, accès à un Intranet d’entreprise, accès à Internet, téléchargement de fichiers. . . L’appli-
cation initiale était plutôt orientée vers des réseaux privés d’entreprise, mais certains opérateurs
déploient des réseaux WLAN publics (plusieurs projets en Asie, et plus récemment en Europe).
• Les WLAN, comme les systèmes cellulaires, utilisent des stations de base pour communiquer
avec des ordinateurs portables. A la différence de la BLR, les réseaux WLAN permettent de gérer
la mobilité des utilisateurs au niveau IP. Les débits de transmission de données sont par ailleurs
très supérieurs à ceux des réseaux cellulaires, présentés plus loin.
L’accès sans fil Bluetooth
• Contrairement aux technologies WLAN ou BLR qui s’appuient sur une architecture centralisée,
Bluetooth ne nécessite pas de point d’accès puisque les connexions peuvent être directement effec-
tuées entre les appareils.
• Initialement, l’utilisation de Bluetooth est prévue pour des connexions de très courte portée
(dialogue entre périphériques – concept de "réseau personnel" -, ou desserte de l’ordre de quelques
mètres).
• Bluetooth pourrait évoluer pour être utilisé comme réseau d’accès afin d’offrir des services si-
milaires à ceux du WLAN. On citera notamment le constructeur Ericsson, grand promoteur de
Bluetooth, qui commence à proposer aux opérateurs une offre d’accès allant dans ce sens, s’ap-
puyant sur des bornes de service Bluetooth utilisées en complément des accès réseaux mobiles
(GSM/GPRS, UMTS) afin de desservir des sites d’entreprises.
Téléphonie sans fil : le DECT
Le DECT (Digital Enhanced Cordless Telecommunications) est une norme européenne d’accès ra-
dio cellulaire numérique « sans fil » dont la première version a été publiée par l’ETSI en 1992, qui
s’appuie sur un mode d’accès TDMA (Time Division Multiple Access) / FDD (Frequency Division
Duplex). Il bénéficie de procédures de sécurité (authentification, chiffrement) importantes. Depuis
1995, la norme DECT a en effet été constamment étendue pour supporter :
- des services multimédia. Les systèmes DECT ont été enrichis d’un DECT Multimedia Access
Profile (DMAP) incluant le GAP (profil d’accès des terminaux pour la voix) et le DPRS (pour les
données).
- Le WAP (Wireless Access Protocol). Le DECT a en effet été intégré comme réseau d’accès pos-
sible dans les spécifications du protocole WAP.
- L’interopérabilité avec les réseaux mobiles 3G. L’évolution des services de données du DECT
vers le haut débit est une des raisons pour lesquelles le DECT fait partie des normes de réseaux
d’accès regroupés au sein de la famille IMT-2000 pour les services mobiles de nouvelle génération.
Radiocommunications : le GSM et le GPRS
• Le GSM (Global System for Mobile communications) est une norme européenne de système de
radiocommunications numérique. Le système GSM avait initialement vocation à la fourniture de
services voix dans un environnement mobile. L’architecture de réseau repose donc sur un ensemble
d’équipements spécifiques aux réseaux mobiles, mais le GSM ayant été spécifié dans l’optique d’un
raccordement avec les réseaux RTC ou RNIS, la commutation de trafic s’effectue en mode circuit
TDM à 64 kbit/s dans le cœur de réseau.

• Le GPRS (General Packet radio Service), spécifié par l’ETSI en 1991, est un nouveau service
mobile de transmission de données en mode paquet utilisant la technologie d’accès radio GSM.
• La mise en œuvre du GPRS, qui est récente ou imminente dans la plupart des réseaux GSM
européens, sera pour les opérateurs mobiles une étape clé qui leur permettra de mettre en oeuvre
des architectures de coeur de réseau (transport IP) et des services de transmission de données en
mode paquet à haut débit que l’on peut qualifier de « pré-UMTS » ou « pré-NGN ».
Les réseaux 3G UMTS
• "Universal Mobile Telecommunications System" (UMTS) désigne la norme cellulaire numérique
de troisième génération retenue en Europe. Le système mobile de troisième génération UMTS est
le premier système global entièrement normalisé (du moins dans sa deuxième phase) avec une ar-
chitecture de réseau et de services NGN : une évolution vers le "tout IP", des services multimédia
à très haut débit en mobilité étendue, un transport unifié et une séparation du réseau en couches
dialoguant via des interfaces normalisées, ainsi qu’une interopérabilité avec des réseaux d’accès
multiples.
• L’utilisation massive du transport ATM dans le sous-système radio UMTS fait que, en fonction
de leur existant, les opérateurs UMTS s’orienteront vraisemblablement pour leur coeur de réseau
soit vers un transport convergent voix/données en ATM, soit vers un transport de la voix sur TDM
(réutilisation du backbone GSM) et de la donnée sur IP (réutilisation du backbone GPRS).
Chapitre
2
Téléphonie sur IP et migration
NGN du cœur de réseau fixe
2.1 Description d’un réseau téléphonique traditionnel
Le réseau téléphonique utilise la commutation de circuits d’où son nom RTC en anglais PSTN.
La commutation de circuits, ou la transmission TDM est caractérisée par l’établissement d’une
liaison entre deux extrémités du réseau pendant la durée de la communication, en assurant le
transfert de l’information. Le principal inconvénient de cette méthode est qu’elle gaspille de la
bande passante puisque la ligne ne peut pas être utilisée pendant cette communication. Dans la
téléphonie traditionnel, les commutateurs sont reliés par des circuits et attacher aux clients par des
lignes d’abonnés. Selon la terminologie des opérateurs, le réseau RTC est découpé en différentes
zones.
2.1.1 Architecture d’un réseau RTC
a) Zone Locale (ZL)
Dans la zone locale, les clients sont raccordés à un étage d’abonné (local ou distant). Les
étages d’abonnés établissent les connexions entre les lignes d’abonnés et leur CCA de ratta-
chement.
b) Zone à Autonomie d’Acheminement (ZAA)
ZAA est une zone géographique constituée par des ZL, équipé par des CCA. Ils gèrent
l’acheminement du trafic entre ZL et entre CCA.
38
Chapitre 2 Téléphonie sur IP et migration NGN du cœur de réseau fixe 39
Figure 2.1: Architecture d’un réseau RTC
c) Zones de Transit (ZT)
Il y a plusieurs zones de transit, national ou international :
• Zones Transit Secondaire (ZTS) est délimitée par le CTS qui gère les CCA situés dans
la zone. Les CTS assurent uniquement le brassage des circuits, lorsqu’un CCA ne peut pas
atteindre le CCA du destinataire.
• Zone de Transit Principale (ZTP) regroupe des ZTS et inclut un CTP qui gère les
CTS. Cette zone assure la commutation des longue distance.
• Zone de Transit Internationale (ZTI) CTP sont reliés à un CTI permettant de traiter
le trafic de l’international, TT dispose de deux centres de transit internationaux.
2.1.2 Avantages RTC
a) Bande passante garantie

• Communications avec des performances prédictibles
• No (best-effort)
b) Simple abstraction
• Communication fiable des canaux entre entités.

• Pas de désordonnées ou de pertes de paquets.
c) Forwarding simple
• Forwarding sur la base de time slot ou fréquences
• Pas d’inspection d’en-tête de paquet
d) Faible overhead par paquet

• En-tête dans chaque paquet.
2.1.3 Inconvénients de commutation de circuit
Bande passante perdue

• Trafic en rafale entraine une connexion inactive pendant une période OFF (silencieuse).
• TDM : slot transmis même s’il n’y a pas de données à envoyer.
• Pas de gains tangibles comme le multiplexage statistique.
Connexions bloquées
• Refus de connexion lorsque les ressources disponible sont insuffisante.
Délai d’établissement de connexion
• Pas de communications jusqu’à ce que la connexion est établie.
Etat du réseau
• Obligation d’enregistrement des informations liées à une connexion.
2.1.4 Le PABX (Private Automatic Branch eXchange)
Un autocommutateur privé de téléphonie, PABX (Private Automatic Branch eXchange) est l’in-
terface entre le service de téléphonie de l’entreprise et le réseau téléphonique (public ou privé). Sa
fonction essentielle consiste à mettre, temporairement, en relation deux usagers (commutation de
circuits). Cette relation peut être interne à l’établissement ou établie à travers le réseau télépho-
nique public (RTC ou RNIS) ou privé.
Ces principales fonctions :

- Il gère les appels en interne et vers l’extérieur et distribue les appels entrants.
- Il gère une boîte vocale (si correspondant absent) et traite la voix et les données comme la télé-
copie.
- Il gère les terminaux téléphoniques (postes analogiques ou numériques) ainsi que diverses fonc-
tionnalités de messagerie, de numérotation, etc.
Un IPBX est un élément qui rassemble en un seul ensemble cohérent toutes les fonctionnalités
Figure 2.2: Le PABX au coeur des services d’entreprise
d’un système de téléphonie IP.
Figure 2.3: Du PABX à l’IPBX

PABX et transmission de données

Le débat en cours depuis quelques années sur les rôles respectifs des PABX et des LAN (réseaux
locaux) dans la communication d’entreprise est aujourd’hui clos, les deux réseaux étant consi-
dérés comme complémentaires. Le PABX est parfaitement adapté au transport de la voix (64
Kbit/s/ligne), mais il peut également transporter des données à faible débit (jusqu’à 256 Kbit/s
par ligne en interne). Le réseau local est adapté au transfert de données haut débit (10 Mbit/s pour
un réseau Ethernet) mais pas à celui de la voix, du fait de contraintes temporelles trop strictes, sauf
exception. Le tableau suivant récapitule les caractéristiques comparées des PABX et des réseaux
locaux.
TABLE 2.1 : Comparaison des PABX et des réseaux locaux
Rôle du MSAN dans une architecture NGN

Les MSAN constituent une évolution naturelle des DSLAMs. Un MSAN est un équipement qui
constitue, dans la plupart des architectures de type NGN, un point d’entrée unique vers les réseaux
d’accès des opérateurs. A la différence d’un DSLAM, dont le chassis ne peut supporter que des
cartes permettant de proposer des services de type xDSL, un MSAN peut supporter des cartes
RNIS, Ethernet, FTTx, ou encore X25. De ce fait, au sein d’un seul et même chassis, l’opérateur
peut déployer toutes les technologies d’accès envisageables sur son réseau. Le rôle de media gateway
décrit ci-avant peut, dans certains cas, être " embarqué " au sein de ce MSAN, et disparaître en
tant que noeud de réseau dédié.
2.2 Typologie des scénarios de migration
La mise en place d’architectures NGN peut se faire avec une plus ou moins grande ampleur,
selon que l’utilisation des technologies NGN s’approche ou non au plus près de l’utilisateur final.
Le choix de déploiement à retenir conditionne en grande partie les bénéfices à attendre de la mise
en place d’un réseau NGN du point de vue de l’économie de coût. Quatre grands scénarios peuvent
ainsi être dégagés :
• Scénario 1 : Mise en place de solutions NGN en transit
• Scénario 2 : Mise en place de solutions NGN jusqu’au commutateur de classe 4
• Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5
• Scénario 4 : Mise en place de solutions tout IP en overlay
2.2.1 Scénario 1 : Mise en place de solutions NGN au niveau des liens
de transit
Dans ce scénario, l’opérateur utilise des technologies NGN pour son coeur de réseau, mais dès
que l’on s’approche des commutateurs de classe 4, le trafic continue à être supporté par le réseau
traditionnel. Cette démarche est mise en place par un grand nombre d’opérateurs mondiaux,
précisément sur ces fonctions de transit que ce soit au niveau régional, national ou international.
Il s’agit de la première étape de la migration d’un réseau traditionnel vers un réseau NGN pour
nombre d’entre eux.
Exemple 1 : Migration du trafic téléphonique international sur IP (Figure 2.4)
Pour un opérateur souhaitant déployer une solution VoIP pour son trafic international il suffit
d’implémenter :
• un softswitch qui centralisera le contrôle des appels, le routage du trafic et la gestion des aspects
de signalisation. Ce softswitch remplacera le (ou les) commutateur(s) de transit international TDM
existant(s).
• des passerelles media dans les PoP (Points de Présence) situés dans les pays où l’opérateur veut
s’interconnecter au réseau national TDM.
Figure 2.4: Architecture d’une solution NGN pour le trafic de transit international
Exemple 2 : Migration du trafic téléphonique de transit au niveau national (Figure 2.5) Au

niveau national, l’approche est similaire sauf que ce sont les commutateurs de classe 3 et de niveau
hiérarchiques supérieurs qui seront remplacés par un ou plusieurs softswitch et passerelles media.
Evidemment les commutateurs TDM de classe 4 et 5 sont conservés et assurent la livraison des
communications téléphoniques TDM de manière tout à fait classique aux abonnés.
Figure 2.5: Architecture d’une solution NGN pour le trafic de transit national
2.2.2 Scénario 2 : Mise en place de solutions NGN jusqu’au commu-
tateur de classe 4
D’un point de vue architectural, il s’agit de la même solution que pour le scénario précédent à un
niveau différent du réseau plus proche de l’abonné. En effet un commutateur de classe 4 ne diffère
d’un commutateur de classe 3 ou de niveau hiérarchique supérieur uniquement par sa capacité de
traitement de données. Il n’intègre aucune intelligence réseau. Du coup, pour le réseau NGN, la
différence se traduira uniquement par la nature des capacités supportés par les media gateways et
softswitchs.
Figure 2.6: Architecture d’une solution NGN de classe 4
2.2.3 Scénario 3 : Mise en place de solutions NGN jusqu’au classe 5
Les commutateurs de classe 5 constituent le point de raccordement avec l’abonné pour la four-
niture des services voix basiques. Les opérateurs historiques possèdent plusieurs milliers de ces
commutateurs et de part leur position stratégique dans leur réseau ont été peu enclins jusqu’à
présent à les remplacer par une solution NGN. Toutefois, compte tenu de la forte progression de la
pénétration des services haut débit et du déclin de la demande en services de téléphonie tradition-
nelle, les opérateurs considèrent de plus en plus l’opportunité de faire converger leur infrastructure
d’accès vers une plate-forme IP commune.
Dans le cadre d’une migration de classe 5, l’opérateur réalise une migration complète, et tout le
trafic transitant dans le réseau sera supporté par une architecture NGN. Cette approche permet la
fourniture de bout en bout de services VoIP à condition que l’utilisateur final utilise un équipement
IP. De loin la plus complexe, cette étape est aujourd’hui assez peu répandue. Seuls quelques opé-
rateurs régionaux aux Etats Unis ainsi que SK Télécom en Corée du Sud ont à ce jour commencé
le déploiement de technologies NGN jusqu’à ce stade.
Figure 2.7: Architecture d’un réseau NGN de classe 5
2.2.4 Scénario 4 : Mise en place de solutions tout IP en overlay
Dans ce cas, l’opérateur déploie une architecture entièrement basée sur IP, qui n’a pas besoin
de se connecter au réseau de commutation existant, ceci en parallèle du réseau traditionnel, qui
continue à vivre sa vie indépendamment. Ce type de solution est particulièrement adapté aux
opérateurs historiques qui sont confrontés à une forte chute des revenus de téléphonie classique
et qui, pour protéger leur base de clientèle, doivent lancer des solutions innovantes basés sur des
technologies alternatives (DSL, FTTH, câble, ...).
Figure 2.8: Architecture overlay VoIP
2.3 NGN Téléphonie
Comme déjà définit précédemment, le NGN téléphonie est une architecture de réseau NGN
offrant uniquement les services de téléphonie (voix,...).
2.3.1 Architecture NGN Téléphonie
La figure 2.2 montre un exemple d’architecture NGN Téléphonie. Les équipements existants
(exemple : commutateur d’accès téléphonique ou BTS/BSC du réseau GSM) sont reliés à une
couche de transport IP ou ATM par le biais de Media Gateways (couche transport). L’établissement
des canaux de communication IP ou ATM entre les Media Gateways est la responsabilité du MGC
appartenant à la couche contrôle. Le MGC est un serveur d’appel qui contient l’intelligence liée
au contrôle de l’appel et pour ce faire possède un modèle d’appel complet. Le MGC identifie les
usagers, détermine le niveau de service pour chaque usager et l’acheminement de trafic. Par ailleurs,
il fournit toutes les informations permettant la taxation des appels et la mesure des performances du
réseau. Aussi, le MGC s’interface aux serveurs d’applications. Dans l’architecture NGN Téléphonie,
le protocole de contrôle tel que MGCP ou MEGACO ne fait que décrire les interactions entre le
MGC et le MG. Si un MGC doit contrôler un MG qui est sous la responsabilité d’un autre MGC,
il est nécessaire que les MGCs s’échangent de la signalisation. Une fois la connexion établie, le
MG convertira les signaux audio transportés dans les circuits de parole (terminaison circuit) en
paquets IP qui seront transportés dans le réseau IP (terminaison IP) ou en cellules ATM dans le
cas d’un transport ATM.
Figure 2.9: Exemple d’architecture NGN Téléphonie
2.3.2 Services dans le RTC versus Services dans le NGN Téléphonie
Dans le contexte du Réseau Téléphonique Commuté, le commutateur réalise deux fonctions

essentielles :
— La commutation de la voix (Media).
— Le contrôle de l’appel (établissement / libération d’appel).
— Les services à valeur ajoutée sont mis en oeuvre par le réseau intelligent à travers les entités
SCP (Service Control Point) / SRP (Specialized Resource Point).
— Les services complémentaires sont mis en oeuvre directement par le commutateur d’accès
(Class 5 Switch).
Dans le monde NGN, la commutation de la voix est réalisée par le MG entre le réseau téléphonique
commuté et le réseau de transport du NGN. Dans le réseau de transport, ce sont les commutateurs
ATM / Routeurs IP qui assurent le transport de la voix paquétisée jusqu’au MG de sortie qui
commute la parole reconvertie, sur un circuit de parole sortant. Le contrôle de l’appel (établissement
/ libération d’appel) est pris en charge par le MGC. Un MGC Class 4 émule le point sémaphore
d’un Class 4 Switch. Un MGC Class 5 émule le point sémaphore d’un Class 5 Switch. Les services
à valeur ajoutée sont pris en charge par le SCP légataire du réseau intelligent ou par un serveur
d’application SIP et par un serveur de media (appelé Multimedia Resource Function) qui fonctionne
en voix sur IP (il émet des annonces vocales et collecte l’information de l’usager sur des canaux
RTP/UDP/IP).
Figure 2.10: Services dans le RTC vis-à-vis Services dans le NGN Téléphonie
2.4 La téléphonie sur IP
2.4.1 Principe de la téléphonie sur IP
Le principe de base de cette transmission consiste :

1. La voix à transmettre est échantillonnée et numérisée par un convertisseur analogique numérique.
2. Le signal numérique obtenu est comprimé et encodé grâce à des algorithmes de compression
spécifiques .
3. Le signal est découpé en paquets.
4. Les paquets sont transmis à travers le réseau Internet.
- À la réception, les paquets sont ré-assemblés, le signal de données ainsi obtenu est décomprimé
puis convertis en signal analogique sonore.
1. La téléphonie par circuit et par paquets

Dans la communication à transfert de paquets, toutes les informations à transporter sont
découpées en paquets pour être acheminées d’une extrémité à une autre du réseau. Cette
technique est illustrée à la figure 2.11. Dans la parole téléphonique, l’information est regrou-
Figure 2.11: La technique de transfert de paquets
pée pour être placée dans un paquet, comme illustré à la figure 2.12. Le combiné téléphonique
produit des octets, provenant de la numérisation de la parole, c’est-à-dire le passage d’un
signal analogique à un signal sous forme de 0 et de 1, qui remplissent petit à petit le paquet.
Dès que celui-ci est plein, il est émis vers le destinataire. Une fois le paquet arrivé à la sta-
tion terminale, le processus inverse s’effectue, restituant les éléments binaires régulièrement
à partir du paquet pour reconstituer la parole téléphonique.
Le réseau de transfert est lui-même composé de nœuds, appelés nœuds de transfert, reliés
entre eux par des lignes de communication, sur lesquelles sont émis les éléments binaires
constituant les paquets. Le travail d’un nœud de transfert consiste à recevoir des paquets et
à déterminer vers quel noeud suivant ces derniers doivent être acheminés.
Le paquet forme donc l’entité de base, transférée de nœud en nœud jusqu’à atteindre le récep-
teur. Ce paquet est regroupé avec d’autres paquets pour reconstituer l’information transmise.
L’action consistant à remplir un paquet avec des éléments binaires en général regroupés par
Figure 2.12: Un flot de paquets téléphoniques
octet s’appelle la mise en paquet, ou encore la paquétisation, et l’action inverse, consistant

à retrouver un flot d’octets à partir d’un paquet, la dépaquétisation.
Le déroulement d’une communication téléphonique sur IP parcourt les cinq grandes étapes
suivantes :
• Mise en place la communication. Une signalisation démarre la session. Le premier
élément à considérer est la localisation du récepteur (User Location). Elle s’effectue par une
conversion de l’adresse du destinataire (adresse IP ou adresse téléphonique classique) en une
adresse IP d’une machine qui puisse joindre le destinataire (qui peut être le destinataire
lui-même). Le récepteur peut être un combiné téléphonique classique sur un réseau d’opé-
rateur télécoms ou une station de travail (lorsque la communication s’effectue d’un combiné
téléphonique vers un PC). Le protocole DHCP (Dynamic Host Configuration Protocol) et
les passerelles spécialisées (gatekeeper) sont employés à cette fin.
• Établissement de la communication. Cela passe par une acceptation du terminal des-
tinataire, que ce dernier soit un téléphone, une boîte vocale ou un serveur Web. Plusieurs
protocoles de signalisation sont utilisés pour cela, en particulier le protocole SIP (Session
Initiation Protocol) de l’IETF. Comme son nom l’indique, SIP est utilisé pour initialiser la
session. Une requête SIP contient un ensemble d’en-têtes, qui décrivent l’appel, suivis du
corps du message, qui contient la description de la demande de session. SIP est un protocole
client-serveur, qui utilise la syntaxe et la sémantique de HTTP. Le serveur gère la demande
et fournit une réponse au client. Trois types de serveurs gèrent différents éléments : un ser-
veur d’enregistrement (Registration Server), un serveur relais (Proxy Server) et un serveur
de redirection (Redirect Server). Ces serveurs travaillent à trouver la route : le serveur proxy
détermine le prochain serveur (Next-Hop Server), qui, à son tour, trouve le suivant, et ainsi
de suite. Des champs supplémentaires de l’en-tête gèrent des options, comme le transfert
d’appel ou la gestion des conférences téléphoniques.
• Transport de l’information téléphonique. Le protocole RTP (Real-time Transport
Protocol) prend le relais pour transporter l’information téléphonique proprement dite. Son
rôle est d’organiser les paquets à l’entrée du réseau et de les contrôler à la sortie de façon à
reformer le flot avec ses caractéristiques de départ (vérification du synchronisme, des pertes,
etc.). C’est un protocole de niveau transport, qui essaye de corriger les défauts apportés par
le réseau.
•Changement de réseau. Un autre lieu de transit important de la ToIP est constitué par
les passerelles, qui permettent de passer d’un réseau à transfert de paquets à un réseau à
commutation de circuits, en prenant en charge les problèmes d’adressage, de signalisation
et de transcodage que cela pose. Ces passerelles ne cessent de se multiplier entre FAI et
opérateurs télécoms.
• Arrivée au destinataire. De nouveau, le protocole SIP envoie une requête à la passe-
relle pour déterminer si elle est capable de réaliser la liaison circuit de façon à atteindre le
destinataire. En théorie, chaque passerelle peut appeler n’importe quel numéro de téléphone.
Cependant, pour réduire les coûts, mieux vaut choisir une passerelle locale, qui garantit que
la partie du transport sur le réseau téléphonique classique est le moins cher possible.
2. Temps de transfert d’un paquet ToIP

Le temps de transfert d’un flux de parole téléphonique est constitué de la somme des cinq
temps suivants (voir figure 2.14) :
TTransfert = TNumérisation + TRemplissage + TPropagation + TTransmission + TTraitement nœud
Figure 2.13: Équipements à traverser par une communication téléphonique sur IP
Figure 2.14: Temps de transfert d’un paquet
• Temps de numérisation de la voix : la parole téléphonique est un signal analogique

impossible à coder sur un ordinateur. Il faut la numériser en données numériques (un
ensemble de 1 et de 0) à l’aide d’un codec (codeur/décodeur), dont nous expliquerons plus
loin le fonctionnement. Le temps de numérisation est généralement négligeable, mais le
codec va déterminer la vitesse à laquelle les données seront émises.
• Temps de remplissage des paquets : les données envoyées sont assemblées en paquets.
Ces paquets comportent des en-têtes (avec entre autre l’adresse du récepteur pour router
le paquet et l’adresse de l’émetteur pour recevoir une réponse), qui sont placés une fois le
paquet constitué. Plus il y a de données dans le paquet, moins il y a d’entêtes, et donc de

consommation de bande passante. En revanche, plus l’attente avant d’envoyer le paquet
est longue, plus l’interactivité de la communication est compromise. Il est donc nécessaire
d’avoir suffisamment de données pour remplir le paquet avec une certaine taille avant de
l’envoyer dans le réseau. On peut définir le temps de remplissage comme le temps mis par le
codec pour remplir un paquet de taille fixée (cette taille ne prend pas en compte les en-têtes
qui sont ajoutés automatiquement et indépendamment du codec).
• Temps de propagation : un signal binaire envoyé d’un endroit arrive à un autre endroit
après un certain temps, qui dépend de la distance à parcourir. Le temps de propagation peut
donc être défini comme le rapport de la distance à parcourir entre l’émetteur et le récepteur
sur la vitesse de propagation du signal. On prend généralement une vitesse de propagation
d’un signal de 200 000 km/s.
• Temps de transmission : des données arrivent d’un point à un autre selon un temps
qui dépend de la quantité de données émise et du débit auquel fonctionnent les liens entre
l’émetteur et le récepteur. On peut donc définir le temps de transmission comme le rapport
de la quantité de données à envoyer sur le débit du lien considéré.
• Temps de traitement par les nœuds intermédiaires : pour aller de l’émetteur au
récepteur, les flux de données parcourent un ensemble de routeurs intermédiaires qui les
aiguillent jusqu’à leur source. Chacun de ces nœuds ajoute un délai supplémentaire, qui
constitue le temps de traitement des noeuds intermédiaires. Ce temps est généralement de
l’ordre de la milliseconde pour chaque nœud.
3. Problématique de transmission de la voix sur IP

La voix sur IP adresse deux types d’applications : celles qui, comme la téléphonie, mettent
en jeu une interaction humaine, laquelle implique un temps de transit très court, et celles qui
transportent des paroles unidirectionnelles, qui n’exigent pas de temps réel. Cette dernière
catégorie rassemble essentiellement des transferts de fichiers contenant de la parole. Dans ce
livre, nous nous intéressons uniquement à la parole téléphonique.
La téléphonie transportée par paquets, et plus particulièrement par paquet IP, permet d’in-
tégrer dans un même réseau les services de données et la téléphonie. Les entreprises sont
de plus en plus nombreuses à intégrer leur environnement téléphonique dans leur réseau à
transfert de paquets. Les avantages de cette intégration sont, bien sûr, la baisse des frais de
communication, mais aussi la simplification de la maintenance de leurs réseaux, qui passent
de deux (téléphonie et données) à un seul (données).
La difficulté de la téléphonie par paquets réside dans la très forte contrainte temporelle due à
l’interaction entre individus. Le temps de latence doit être inférieur à 300 ms si l’on veut gar-
der une interaction humaine acceptable. Si l’on souhaite une bonne qualité de la conversation,
la latence ne doit pas dépasser 150 ms.
Définition de la téléphonie sur IP

La téléphonie sur IP est un service de téléphonie fourni sur un réseau de télécommuni-
cation ouvert au public ou privé utilisant principalement le protocole IP.
Deux approches de la voix sur IP doivent être distinguées (figure 2.15).

La première, à l’instar d’ATM et du Frame Relay consiste à transporter la voix traditionnelle
Figure 2.15: Voix sur IP.
sur un réseau IP, appelée voix sur IP (VoIP, Voice over IP), elle est limitée aux infrastructures
de transport de la voix sous forme de paquets, contournant ainsi le réseau téléphonique

commuté. La seconde utilise le protocole IP de bout en bout, les téléphones (IP phone) sont
directement connectés à un LAN IP, c’est la téléphonie sur IP (ToIP, Telephony over IP).
la ToIP modifie les équipements terminaux (ex. IP Phones) alors que la VoIP ne concerne
que les PABX et leur adaptation au réseau IP par des passerelles.
4. Principe de fonctionnement de la téléphonie sur IP

Un terminal A souhaite appeler un terminal B dans un réseau ToIP :
• A envoie une requête au Gatekeeper (G) en composant le numéro de B.
• Le Gatekeeper (G) assure la translation entre le numéro de téléphone de B et son adresse
IP et envoie une requête IP sur le réseau pour vérifier la disponibilité de B :
- Si B est disponible, alors G met en relation A et B en fournissant à A l’adresse IP de B.
- Si B n’est pas sur le même LAN que A, alors G route l’appel vers la Gateway (GW)
pour localiser B.
• Une fois l’appel terminé, G met à jour ses tables pour la disponibilité des terminaux A et
B.
2.4.2 La téléphonie sur réseaux sans fil
Plus qu’une évolution technologique, la ToIP est aujourd’hui une application réseau incontour-
nable, dont l’atout majeur est incontestablement le prix.
Si les communications téléphoniques sont généralement facturées à la durée et à la distance, les
communications sur Internet sont le plus souvent forfaitaires, sans limitation de distance ni de
temps. Toutes les applications dont les flux transitent sur le réseau Internet sont incluses dans le
prix. Encore faut-il trouver les applications susceptibles de séduire les utilisateurs. La ToIP est
précisément l’une des possibilités.
Si la ToIP a pour principale vocation d’offrir une solution de rechange à moindre coût à la télépho-
nie sur circuit classique, le sans-fil offre bien d’autres avantages. Les réseaux sans fil permettent
aux utilisateurs de s’abstraire des contraintes de câblage sur les derniers mètres de raccordement
jusqu’à leur poste. La zone de couverture devient étendue, ce qui procure une souplesse d’utilisation
accrue. Le gain se traduit également par une facilité de déploiement et d’extensibilité du réseau,
ce dernier devenant ambiant. C’est donc presque naturellement que la ToIP a donné naissance à
la téléphonie sur réseaux sans fil, ou ToWLAN (Telephony over Wireless LAN).
Cette nouvelle application ne va toutefois pas sans contraintes. Il s’agit principalement d’assurer
la portabilité en sans-fil des éléments essentiels au déploiement de la voix.
Contraintes de la ToIP sans fil
La technologie de ToIP sans fil a pour objectif de permettre aux utilisateurs de téléphoner direc-
tement en IP, donc à un coût extrêmement bas et depuis de nombreux points sans avoir besoin
d’une connexion physique. Elle représente un pas supplémentaire vers la convergence des flux au-
dio, vidéo et données sur un médium unique.
La problématique de la ToIP sur WLAN est évidemment semblable à celle de la téléphonie sur
réseau terrestre, si ce n’est qu’il s’y ajoute la difficulté de réaliser la traversée de l’interface air
dans un laps de temps suffisamment court pour satisfaire à la contrainte temps réel. Il s’agit d’une
vraie difficulté dans la mesure où les équipements raccordés au point d’accès Wi-Fi sont a priori
indépendants les uns des autres. De plus, les environnements Wi-Fi offrent un débit particulière-
ment fluctuant, et il est quasiment impossible de connaître le débit disponible à l’instant suivant.
Les terminaux de ToIP sur Wi-Fi assurent les fonctions de codec, de paquétisation et d’encapsu-
lation dans la trame Ethernet pour transiter sur le réseau Wi-Fi.
2.4.3 La téléphonie sur WiMax
L’initiative WiMax est née du désir de développer des liaisons hertziennes concurrentes des tech-
niques xDSL terrestres. Après de longues années d’hésitation, son vrai démarrage a été favorisé
par l’arrivée de la norme IEEE 802.16.
Les différences entre les normes 802.16 et 802.11 sont nombreuses. La couverture est beaucoup
plus importante pour les premières, puisqu’elle peut dépasser 10 km, contre quelques dizaines à
quelques centaines de mètres pour les secondes. La technologie 802.16 est moins sensible aux ef-
fets multitrajet et pénètre mieux à l’intérieur des bâtiments. Elle est de plus mieux conçue pour
assurer le passage à l’échelle, ou scalabilité, sur de grandes surfaces, c’est-à-dire sur des cellules de
plusieurs kilomètres carrés au lieu de plusieurs centaines de mètres carrés.
Classes de services WiMax pour la ToIP
Figure 2.16: Réseau WiMax 802.16e
Le réseau WiMax est doté de quatre classes de services pour la téléphonie, et le réseau WiMax-
Mobile de cinq.
Les quatre classes de WiMax sont les suivantes :
• UGS (Unsolicited Grant Service), dévolu à la téléphonie grâce à une forte garantie de la qualité
de service.
• rtPS (Real-time Packet Service), qui correspond à des applications ayant de fortes contraintes
temporelles, mais avec des débits qui peuvent être variables.
• nrtPS (Non-real-time Packet Service), qui correspond à des applications sans contraintes tem-
porelles mais avec des contraintes de débit.
• BE (best-effort), qui ne possède aucune garantie.

Un mécanisme dit de Request-Grant a été défini par le groupe IEEE 802.16 pour gérer la trans-
mission montante. Les stations doivent en tout premier lieu être capables d’envoyer une demande
de bande passante dans la trame en cours avant de pouvoir transmettre dans la trame suivante
dans un slot réservé.
L’accès au support physique de WiMax est de type TDMA (Time Division Multiple Access). Il
permet l’émission de trames successives, elles-mêmes découpées en tranches, comme l’illustre la
figure 2.17.
Figure 2.17: Format de la trame WiMax
2.5 La qualité de service et ToIP
D’une manière générale, on retient trois facteurs pour déterminer la qualité de service d’une
application de téléphonie :
• Qualité de la transmission de la voix. C’est la partie technique qui prend en compte le
signal de départ et qui essaie de le retranscrire au mieux au niveau du récepteur.
• Efficacité de la conversation. C’est l’interactivité plus ou moins grande entre les deux indi-
vidus en train de converser.
• Intelligibilité de la communication. C’est la façon dont s’expriment les individus en com-

munication.
Des facteurs externes sont également à prendre en compte dans la qualité perçue. Les principaux
facteurs externes sont les suivants :
• Bruit de ligne de la communication.
• Bruit corrélé au signal qui provient généralement du codec et essentiellement du choix de la
quantification.
• Bruit de fond provenant de l’endroit où se trouve le micro.
Il est donc très difficile d’évaluer la qualité de la voix en dehors d’une écoute d’un utilisateur,
qui est capable de prendre en compte l’ensemble des paramètres importants, d’où l’origine de la
technique MOS (Mean Opinion Score).
1- TCP et le transport de données multimédias temps réel
Le protocole TCP implémente plusieurs mécanismes de contrôle :
• Contrôle de séquence. Chaque trame est numérotée au niveau de l’émetteur. Cela permet de
reconstituer l’ordre des trames au niveau du récepteur, grâce à l’estampille séquentielle.
• Contrôle de flux. Un mécanisme de fenêtrage limite le nombre de paquets qu’il est possible
d’émettre.
• Contrôle d’erreur. Le récepteur envoie un message d’acquittement pour toutes les trames
reçues. Il peut exister des acquittements cumulatifs, permettant d’acquitter plusieurs trames en
même temps. Dans le cas où le récepteur reçoit des trames qui ne sont pas intègres, par exemple si
une erreur est détectée lors du contrôle de redondance, il ne les acquitte pas. Si certaines trames de
l’émetteur ne reçoivent pas d’acquittement passé un certain délai, appelé temporisateur de réémis-
sion, l’émetteur considère que ces trames sont perdues dans le réseau (un routeur saturé détruit
les paquets qui arrivent en surplus) ou que le récepteur ne les a pas reçues de façon correcte.
• Contrôle de congestion. Des mécanismes (appelés Slow Start et Congestion Avoidance) sont
utilisés pour augmenter progressivement le débit d’envoi des données au niveau de l’émetteur. Le
débit progresse par paliers successifs. Dès qu’un palier est atteint, le suivant est accessible, et ainsi
de suite jusqu’à atteindre la limite fixée. Dans le cas où un palier n’est pas correctement validé
parce que les acquittements des trames envoyées ne parviennent plus jusqu’à l’émetteur, le débit
est automatiquement abaissé jusqu’à son palier le plus bas. En effet, si un seuil pose problème,
il ne sert à rien d’aller au suivant, car, avec un débit plus importan t, les erreurs risquent de se
multiplier, aggravant l’état de saturation du réseau. En repartant d’un débit très faible, l’émetteur
allège la charge du réseau susceptible de le stabiliser et de réguler son état avant que l’émetteur le
sollicite. À nouveau, à partir du seuil le plus bas, la procédure d’augmentation de débit progressive
est enclenchée.
La figure 2.18 illustre ce qui ne devrait pas se produire. Alice envoie trois messages à Brigitte,
contenant respectivement les mots " bonjour ", " à ", " tous " (il s’agit bien sûr d’un cas d’école,
le découpage réel des trames se faisant à la durée et non au mot). Imaginons que seuls les mots "
bonjour " et " tous " soient reçus par Brigitte. Avec le protocole TCP, une réémission du mot " à
" va être effectuée par le terminal d’Alice, une fois le temporisateur de réémission écoulé. Comme
il s’agit d’une conversation téléphonique, le terminal de Brigitte doit diffuser les messages reçus
immédiatement (en fait un système de cache permet de réduire plus ou moins cet effet, mais sans
pallier le problème pour autant puisqu’il n’offre qu’un délai supplémentaire limité). Le protocole
Figure 2.18: Réémission avec TCP
TCP est donc bien inadapté au temps réel, puisque tous les contrôles qu’il met en place pour le
transport des paquets pénalisent ses délais de transmission.
La contrainte de fiabilité n’étant pas compatible avec la contrainte de délai imposée par la ToIP,
TCP n’est donc pas un bon candidat pour les transferts de type temps réel.
2- TCP/IP et le transport de la voix
Pour des raisons d’efficacité le protocole UDP (User Datagram Protocol) s’impose pour le transfert
des flux multimédia :
• Pas d’ouverture, ni de fermeture de session ;
• Pas d’acquittement, ni de reprise sur erreur ;
• Pas de contrôle de flux et de congestion ;
• Faible temps de latence.
Deux protocoles complémentaires ont été adjoints à UDP :
• Le premier RTP (Real Time Protocol) a essentiellement pour objet de fournir les informations
nécessaires à la correction de gigue et au respect du séquencement.
• Le second, intégré dans RTP, RTCP (Real Time Control Protocol) fournit périodiquement des
informations sur la qualité de service dans le réseau.
La figure 2.19 illustre les différents flux protocolaires.
Figure 2.19: Le contrôle de session par RTP et RTCP.

Dans une session multimédia, chaque flux est transporté par une session RTP distincte. De même,
à chaque session RTP est associé un flux de contrôle RTCP. Une session RTP est une association
de plusieurs communicants, au moins 2, une session est identifiée par le couple port/adresse. L’en-
tête RTC contient les informations d’identification, de séquencement, de type de charge utile et
d’horodatage (figure 2.20).
Figure 2.20: En-tête RTP
3- Qualité de service sur IP

L’IETF propose deux grandes catégories de services pour les contrôles réseau. Ils se déclinent en
sous-services dotés de différentes qualités de service : les services intégrés IntServ (Integrated
Services) et les services différenciés DiffServ (Differentiated Services).
Les services IntServ disposent des trois classes suivantes :
• service garanti (Guaranteed Service) ;
• service contrôlé (Controlled Load) ;
• best-effort.
Les services DiffServ disposent des trois classes suivantes :
• service garanti (Expedited Forwarding), ou service Premium ;
• service contrôlé (Assured Forwarding), ou service Olympic ;
• best-effort.
Les services intégrés sont gérés indépendamment les uns des autres, tandis que les services diffé-
renciés rassemblent plusieurs applications simultanément. La première solution est souvent choisie
pour le réseau d’accès et la seconde pour l’intérieur du réseau, lorsqu’il y a beaucoup de flots à
gérer.
a- Le service IntServ
Le service IntServ intègre deux niveaux de service avec garantie de performance. C’est un service
orienté flot, dans lequel chaque flot peut faire sa demande spécifique de qualité de service.
Pour obtenir une garantie précise, le groupe de travail IntServ a considéré que seule une réservation
de ressources était capable de fournir à coup sûr les moyens de garantir la demande.
Comme expliqué précédemment, trois sous-types de services sont définis dans IntServ : un service
avec garantie totale, un service avec garantie partielle et le service best-effort. Le premier corres-
pond aux services rigides, avec de fortes contraintes à respecter. Les deuxième et troisième sont
des services dits élastiques, qui n’ont pas de contraintes fortes.
Le service IntServ doit posséder les mécanismes suivants :
• Procédure de signalisation pour avertir les nœuds traversés. Le protocole RSVP (Resource Re-
SerVation Protocol) est supposé remplir cette tâche.
• Méthode permettant d’indiquer la demande de qualité de service de l’utilisateur dans le paquet
IP afin que les nœuds en tiennent compte.
• Contrôle de trafic pour maintenir la qualité de service.
• Mécanisme permettant de faire passer le niveau de qualité au réseau sous-jacent, s’il existe.
Le service garanti GS (Guaranteed Service) affecte une borne supérieure au délai d’acheminement.
Pour cela, un protocole de réservation tel que RSVP est nécessaire. La demande de réservation
comporte deux parties : une spécification de la qualité de service déterminée par un FlowSpec
et une spécification des paquets qui doivent être pris en compte par un filtre, le FilterSpec. En
d’autres termes, certains paquets du flot peuvent avoir une qualité de service mais pas forcément
les autres. Chaque flot possède sa qualité de service et son filtre, qui peut être fixe (fixed filter),
partagé avec d’autres sources (shared-explicit) ou encore spécifique (wildcard filter).
Le service partiellement garanti CL (Controlled Load) doit garantir une qualité de service à peu
près égale à celle offerte par un réseau peu chargé. Cette classe est essentiellement utilisée pour le
transport des services élastiques. Les temps de transit dans le réseau des flots CL sont similaires à
ceux de clients d’une classe best-effort dans un réseau très peu chargé. Pour arriver à cette fluidité
du réseau, il faut intégrer une technique de contrôle.
Le service IntServ pose le problème du passage à l’échelle, ou scalabilité, qui désigne la possibilité
de continuer à bien se comporter lorsque le nombre de flots à gérer devient très grand, comme c’est
le cas sur Internet. Le contrôle IntServ s’effectuant sur la base de flots individuels, les routeurs du
réseau IntServ doivent garder en mémoire les caractéristiques de chaque flot. Une autre difficulté
concerne le traitement des différents flots dans les nœuds IntServ : quel flot traiter avant tel autre
lorsque des milliers de flots arrivent simultanément avec des classes et des paramètres associés
distincts ?
En l’absence de solution reconnue à tous ces problèmes, la seconde grande technique de contrôle,
DiffServ, essaie de trier les flots dans un petit nombre bien défini de classes, en multiplexant les
flots de même nature dans des flots plus importants, mais toujours en nombre limité. IntServ peut
cependant s’appliquer à de petits réseaux comme les réseaux d’accès.
b- Le service DiffServ
Le principal objectif de DiffServ est de proposer un schéma général permettant de déployer de la
qualité de service dans un grand réseau IP et de réaliser ce déploiement assez rapidement.
DiffServ sépare l’architecture en deux composantes majeures : la technique de transfert et la confi-
guration des paramètres utilisés lors du transfert. Cela concerne aussi bien le traitement reçu par
les paquets lors de leur transfert dans un nœud que la gestion des files d’attente et la discipline de
service, c’est-à-dire la façon dont les clients sont servis ; les disciplines de service les plus connues
étant FIFO (First In First Out), LCFS (Last Come, First Served) et PS (Processor Sharing).
La configuration de tous les nœuds du chemin s’effectue selon un critère appelé PHB (Per-Hop
Behavior). Ces PHB déterminent les différents traitements correspondant aux flots qui ont été
différenciés dans le réseau. DiffServ définit la sémantique générale des PHB, et non les mécanismes
spécifiques permettant de les implémenter. Les PHB sont définis une fois pour toutes, tandis que
les mécanismes peuvent être modifiés et améliorés, voire être différents suivant le type de réseau
sous-jacent.
Les PHB et les mécanismes associés doivent pouvoir être facilement déployés dans les réseaux IP,
ce qui demande que chaque nœud puisse gérer les flots grâce à des mécanismes tels que l’ordon-
nancement, la mise en forme ou la perte des paquets traversant un nœud.
L’architecture d’un nœud DiffServ se termine par des files d’attente destinées à mettre en attente
les paquets avant leur émission sur la ligne de sortie déterminée par le routage. Un algorithme
de précédence est utilisé pour traiter l’ordre d’émission des paquets. L’ordonnanceur (Scheduler)
s’occupe de cette fonction. L’algorithme le plus simple revient à traiter les files suivant leur ordre
de priorité et à ne pas laisser passer les clients d’une autre file tant qu’il y a encore des clients dans
une file prioritaire.
2.5.1 Les protocoles de contrôle d’appel
La signalisation désigne la transmission d’un ensemble de signaux et d’informations de contrôle

échangés entre les intervenants d’une communication. Ces intervenants peuvent être des entités
en bout de liaison (terminaux) ou des entités intermédiaires de contrôle et de gestion des commu-
nications. Leurs échanges permettent l’initiation, la négociation, l’établissement, le maintien et la
fermeture de la connexion.
Les protocoles de contrôle d’appel permettant l’établissement, généralement à l’initiative d’un uti-
lisateur, d’une communication entre deux terminaux ou entre un terminal et un serveur ; les deux
principaux protocoles sont H.323, norme de l’UIT et SIP, standard développé à l’IETF.
i) Le protocole historique : H.323 La recommandation H.323 de l’UIT décrit les procé-

dures pour les communications audio et vidéo point à point ou multipoint sur des réseaux
en mode paquet. C’est une adaptation des procédures de vidéoconférence sur RNIS (H.320)
aux réseaux sans garantie de service.
Les six versions de H.323
Les premiers travaux sur H.323 ont débuté en mai 1995. Depuis lors, six versions standar-
disées se sont succédé, apportant leurs lots de nouveautés et d’améliorations. Le protocole
H.323 impose une compatibilité ascendante, ce qui veut dire que les fonctionnalités et mé-
thodes présentes dans les premières versions du protocole restent supportées dans toutes
celles qui suivent. Cette section présente les évolutions du protocole au cours du temps.
H.323 version 1 (mai 1996), H.323 version 2 (janvier 1998), H.323 version 3 (septembre 1999),
H.323 version 4 (novembre 2000), H.323 version 5 (juillet 2003) et la H.323 version 6 (juin
2006).
Les quatre entités d’une architecture H.323

Le protocole H.323 axe très fortement ses communications sur une typologie d’équipements.
La terminologie anglaise étant couramment employée dans les documentations françaises, il
convient de la connaître. Dans ce qui suit, les premiers termes donnés peuvent être considérés
comme les plus courants.
Une architecture H.323 est généralement composée des quatre catégories d’entités suivantes :
• Terminaux (au minimum deux). Ce sont les équipements de traitement destinés aux uti-
lisateurs, leur permettant d’émettre et de recevoir des appels. Deux terminaux doivent au
minimum être présents pour qu’une communication ait lieu.
• Gatekeeper, ou garde-barrière. C’est l’équipement permettant la localisation des uti-
lisateurs. Ces derniers peuvent s’identifier entre eux par des noms, auxquels il faut attribuer
l’adresse IP correspondante dans le réseau ou, si l’appelé n’est pas situé dans un réseau IP,
la localisation de l’entité intermédiaire à joindre pour l’appel. Outre cette fonction primor-
diale, un gatekeeper remplit tout un ensemble de fonctions complémentaires de gestion et de
contrôle des communications, certaines étant indispensables et d’autres facultatives.
• Passerelle, ou gateway. C’est l’équipement permettant à des utilisateurs du réseau IP
de joindre les utilisateurs qui sont actifs sur d’autres types de réseaux téléphoniques, RTC,
RNIS ou ATM. On peut avoir autant de passerelles différentes que nécessaire, suivant la
nature des réseaux non-IP à interconnecter.
• MCU (Multipoint Control Unit), ou unité de contrôle multipoint, parfois appe-
lée pont multipoint. C’est l’équipement permettant la gestion des conférences, c’est-à-dire
les communications multimédias mettant en jeu plus de deux interlocuteurs. Ces derniers
doivent préalablement se connecter à la MCU, sur laquelle s’établissent les demandes et né-
gociations des paramètres à utiliser lors de la conférence.
• Points de terminaison. Terminaux, gateway et MCU sont des entités auxquelles les
émetteurs peuvent s’adresser directement pour communiquer. Contrairement au gatekeeper,
qui joue un rôle intermédiaire de contrôle et de gestion, ces entités sont des points de termi-
naison des appels (aussi appelés endpoints).
• Zone et système H.323. La nomenclature H.323 définit deux notions qu’il convient de
bien connaître et différencier :
– Un système H.323 est défini comme un ensemble de deux terminaux au minimum,
d’autres éléments pouvant être ajoutés.
– Une zone H.323 est un ensemble de deux terminaux avec un gatekeeper au minimum,
d’autres éléments pouvant être ajoutés.
Autrement dit, une zone H.323 est un système H.323 associé à un gatekeeper et éventuelle-
ment, mais pas nécessairement, à des entités additionnelles, comme une MCU ou une passe-
relle. Chaque entité peut être présente en grand nombre.
Figure 2.21: Architecture de H.323
Les autres protocoles

Bien d’autres protocoles sont utilisés dans la spécification H.323. Le tableau suivant récapi-
tule les principaux protocoles présents dans H.323.
TABLE 2.2 : Principaux protocoles de H.323
La sécurité
Absence de la sécurité dans la première version du protocole, les mécanismes de sé-
curité ont été ajoutés dès la seconde avec la recommandation H.235. Le protocole H.323
supporte aussi la sécurisation des échanges multimédias via le protocole SRTP (Secure RTP).
ii) Le protocole alternatif : SIP
SIP (Session Initiation Protocol) est un protocole de contrôle qui peut établir, modifier et
terminer des sessions multimédia, aussi bien des conférences que des appels téléphoniques
sur des réseaux mode paquets. Il est sous forme de texte, tout comme http ou SMTP, et a
pour rôle d’initier des sessions de communications interactives. Ces sessions peuvent inclure
aussi bien de la voix, de la vidéo, des jeux interactifs...
Le protocole SIP a été conçu pour s’adapter à Internet, en particulier pour que le réseau sup-
porte des montées en charge du nombre d’utilisateurs. Pour cela, l’architecture SIP repose
sur plusieurs serveurs distincts, qui distribuent la charge du réseau en communiquant entre
eux, un peu à la manière des serveurs DNS sur Internet. Lorsque le nombre d’utilisateurs
croît, il suffit d’ajouter des serveurs disposant de fonctions dédiées pour collaborer avec ceux
déjà en place.
SIP (Session Initiation Protocol) a été normalisé par le groupe de travail WG MMUSIC
(Work Group Multiparty Multimedia Session Control) de l’IETF. La version 1 est sortie en
1997, et une seconde version majeure a été proposée en mars 1999 (RFC 2543). Cette der-
nière a elle-même été largement revue, complétée et corrigée en juin 2002 (RFC 3261). Des
compléments au protocole ont été définis dans les RFC 3262 à 3265.
SIP peut notamment se déployer ou s’intégrer aux protocoles suivants :
• RTP (Real-time Transport Protocol), RFC 3550, qui se charge du transport des flux temps
réel.
• RTCP (Real-time Transport Control Protocol), RFC 3550, qui fournit des informations
dynamiques sur l’état du réseau.
• RTSP (Real-Time Streaming Protocol), RFC 2326, pour contrôler la diffusion de flux mul-
timédias en temps réel.
• SDP (Session Description Protocol), RFC 2327, qui fournit la description d’une session,
c’est-à-dire les paramètres utilisés dans une communication SIP.
• SAP (Session Advertisement Protocol), RFC 2974, pour les communications multicast, qui
permet d’ajouter les spécifications d’une nouvelle session.
• MIME (Multipurpose Internet Mail Extension), RFC 2045, standard pour les descriptions
de contenus, utilisé sur Internet.
• RSVP (Resource reSerVation Protocol), RFC 2205, pour obtenir des garanties de qualité
de service et effectuer des réservations de ressources.
• HTTP (HyperText Transfer Protocol), RFC 2616, pour le traitement des pages Web sur
Internet (on peut inclure des adresses SIP directement dans des pages Web).
• MGCP (Media Gateway Control Protocol), RFC 3435, pour le contrôle des passerelles
assurant la connectivité entre un réseau IP et un réseau téléphonique.
Architecture de SIP
Contrairement à H.323, largement fondé sur une architecture physique, le protocole SIP s’ap-
puie sur une architecture purement logicielle.
L’architecture de SIP s’articule principalement autour des cinq entités suivantes :
• terminal utilisateur : Le terminal est appelé UA (User Agent), il est constitué de deux
sous-entités :(Une partie cliente, appelée UAC (User Agent Client), chargée d’émettre les
requêtes, c’est l’UAC qui initie un appel. et une autre partie serveur, appelée UAS (User
Agent Server), qui est en écoute, reçoit et traite les requêtes, c’est l’UAS qui répond à un
appel) ;
• serveur d’enregistrement : (Registrar Server) offre un moyen de localiser un correspondant
avec souplesse, tout en gérant la mobilité de l’utilisateur. Il peut en outre supporter l’au-
thentification des abonnés ;
• serveur de localisation : Le serveur de localisation (Location Server) joue un rôle complé-
mentaire par rapport au serveur d’enregistrement en permettant la localisation de l’abonné.
Ce serveur contient la base de données de l’ensemble des abonnés qu’il gère. Cette base est
renseignée par le serveur d’enregistrement. Chaque fois qu’un utilisateur s’enregistre auprès
du serveur d’enregistrement, ce dernier en informe le serveur de localisation ;
• serveur de redirection : (Redirect Server) agit comme un intermédiaire entre le terminal
client et le serveur de localisation. Il est sollicité par le terminal client pour contacter le
serveur de localisation afin de déterminer la position courante d’un utilisateur ;
• serveur proxy : (parfois appelé serveur mandataire) permet d’initier une communication à
la place de l’appelant. Il joue le rôle d’intermédiaire entre les terminaux des interlocuteurs
et agit pour le compte de ces derniers. Il remplit les différentes fonctions suivantes : loca-
liser un correspondant, réaliser éventuellement certains traitements sur les requêtes, initier,
maintenir et terminer une session vers un correspondant.

Les serveurs proxy jouent aussi un rôle collaboratif, puisque les requêtes qu’ils véhiculent
peuvent transiter d’un serveur proxy à un autre, jusqu’à atteindre le destinataire. Notons
que le serveur proxy ne fait jamais transiter de données multimédias et qu’il ne traite que
les messages SIP. On distingue deux types de serveurs proxy :
• Proxy statefull, qui maintient pendant toute la durée des sessions l’état des connexions.
• Proxy stateless, qui achemine les messages indépendamment les uns des autres, sans
sauvegarder l’état des connexions.
Les proxy stateless sont plus rapides et plus légers que les proxy statefull, mais ils ne dis-
posent pas des mêmes capacités de traitement sur les sessions.
Format des adresses SIP
Tout utilisateur SIP dispose d’un identifiant unique. Cet identifiant constitue l’adresse de
l’utilisateur permettant de le localiser. Le format d’une adresse SIP (ou URL SIP) respecte
la RFC 3986 (nommée Uniform Resource Identifier : Generic Syntax) et se présente sous la
forme suivante :
sip :identifiant[ :mot_de_passe]@serveur[ ?paramètres]
Les messages SIP

Les messages SIP sont décrits dans la RFC 822, qui définit la syntaxe à la fois des requêtes
et des réponses. On y trouve une très forte influence des autres protocoles de l’IETF, prin-
cipalement HTTP et SMTP. Le format des requêtes et réponses est en effet similaire à celui
utilisé dans le protocole HTTP, et les en-têtes s’apparentent à celles utilisées dans le proto-
cole SMTP. On y retrouve par ailleurs le concept d’URL.
Figure 2.22: Format générique d’un message SIP
La première partie est soit une ligne de requête, s’il s’agit d’une requête, soit une ligne d’état,
s’il s’agit d’une réponse. La seconde partie rassemble les en-têtes du message. Enfin, vient
le corps du message. Optionnel, celui-ci est précédé d’une balise de retour chariot et saut
de ligne CR-LF (Carriage Return-Line Feed) afin d’indiquer le début du corps du message.
Cette balise assure la séparation de l’en-tête et du corps du message, ce qui permet d’opti-
miser le temps de traitement des messages.
La séparation des champs réduit le temps de transit des messages dans le réseau. De cette
manière, les serveurs intermédiaires peuvent rapidement discerner les informations utiles,
sans avoir à manipuler les données du corps du message. La spécification du protocole limite
le nombre d’en-têtes possible, ce qui permet de borner le temps de lecture ou d’écriture des
messages.
Notion de transaction
Une communication est constituée d’une succession de transactions par le biais d’échanges
de messages, qui peuvent être soit des requêtes, soit des réponses à des requêtes. Une tran-
saction SIP peut s’entendre en première approximation selon le sens commun : un émetteur
formule une demande à un récepteur. Ce dernier étudie les conditions de la demande avant de
répondre. Éventuellement, il peut être amené à envoyer des réponses temporaires, indiquant
l’évolution du traitement de la requête.
Une transaction est donc constituée d’une requête et de sa ou ses réponses. Pour se mettre
d’accord sur la nature de l’échange, chaque intervenant est susceptible de négocier les para-
mètres de la session au moyen de nouvelles transactions.
En-têtes d’un message
Un message de requête comme un message de réponse peut contenir des en-têtes. Les en-têtes
les plus couramment utilisés dans les messages SIP sont les suivants :
• En-têtes généraux, qui peuvent être utilisés indifféremment pour des messages de requête
ou des messages de réponse.
• En-têtes de requête, exclusivement employés pour les messages de requête.
• En-têtes de réponse, exclusivement employés pour les messages de réponse.
• En-têtes d’entité, qui donnent des informations descriptives sur le corps du message.
TABLE 2.3 : Principaux champs d’en-têtes des messages SIP

Corps d’un message

Le corps d’un message SIP contient le descriptif complet des paramètres de la session concernée.
Typiquement, une description de la session à ouvrir comporte les informations suivantes :
• informations générales sur la session (nom de la session, date de la session, objet de la session,
etc.) ;
• informations sur l’émetteur du message (nom, e-mail, numéro de téléphone, etc.) ;
• informations réseau (ressources nécessaires, protocole et port utilisés pour le transport des don-
nées multimédias, etc.) ;
• liste des flux multimédias utilisés (audio, vidéo, texte) ;
• liste des codages supportés (G.711, G.729, H.216, MPEG, etc.) ;
• informations de sécurité (type de cryptage utilisé).
Ces informations sont fournies soit pour être négociées avec le correspondant, soit pour être fixées
au terme de la négociation. Elles permettent de s’accorder préalablement à l’échange sur la compa-
tibilité des terminaux. C’est l’en-tête qui précise dans quel langage sont spécifiées les informations
données dans le corps du message (avec le champ CONTENT-TYPE). Le plus couramment, ces
spécifications s’effectuent soit sous forme textuelle, en utilisant le langage HTML, soit sous forme
applicative, en utilisant le langage protocolaire SDP.
SDP (Session Description Protocol)
Son rôle est de décrire l’ensemble des paramètres constituant une session. Cela inclut la spéci-
fication des médias utilisés, des protocoles de transport, des ports, des codages, des ressources
nécessaires et des dates d’activité de la session. Avec SDP, la syntaxe des spécifications du corps
respecte le modèle suivant :
paramètre = valeur
Les paramètres peuvent appartenir à deux catégories distinctes :

• Globale : le paramètre s’applique à l’ensemble de la session (paramètre de média).
• Locale : le paramètre ne s’applique qu’à un média particulier (paramètre de média).
Le tableau suivant récapitule quelques-uns des champs possibles définis avec SDP.
TABLE 2.4 : Champs SDP les plus courants
Les réponses SIP

Les réponses sont classées en catégories, suivant leur type. Elles peuvent au besoin être complétées
par un message plus explicite. Les réponses aux requêtes SIP débutent par une ligne d’état (Status
Line), laquelle comporte les trois champs suivants :
• Version : c’est la version du protocole SIP utilisée.
• Code d’état (Status Code) : code numérique à trois chiffres spécifiant la réponse donnée à la
requête. Cet entier est codé sur trois bits.
• Raison (Reason Phrase) : message textuel expliquant brièvement le code d’état de la réponse.
Fonctionnellement parlant, il s’agit d’un élément redondant par rapport au code d’état. Le pro-
tocole offre néanmoins ainsi un niveau de clarté plus accessible, qui favorise la compréhension
des messages protocolaires par les utilisateurs comme par les programmeurs. Son utilité n’est pas
protocolaire mais informative.
TABLE 2.5 : Principaux codes d’état et raisons d’une réponse SIP

TABLE 2.5 : Principaux codes d’état et raisons d’une réponse SIP (suite)
Scénarios de communication
La succession chronologique des messages de requêtes et de réponses dans les six scénarios classiques
suivants :
1. Initialisation d’une communication directe.
2. Enregistrement d’un terminal.
3. Initialisation d’une communication avec un serveur proxy.
4. Localisation par un serveur de redirection et initialisation d’appel directe.
5. Modification dynamique d’une communication SIP.
6. Terminaison d’une communication.
2.5.2 Les protocoles de commande de Media Gateway
Les protocoles de commande de Media Gateway sont issus de la séparation entre les couches
Transport et Contrôle et permet au Softswitch ou Media Gateway Controller de gérer les passe-
relles de transport ou Media Gateway. MGCP (Media Gateway Control Protocol) de l’IETF et
H.248/MEGACO, développé conjointement par l’UIT et l’IETF, sont actuellement les protocoles
prédominants.
Le protocole historique : MGCP
Le Media Gateway Control Protocol (MGCP), protocole défini par l’IETF, a été conçu pour des
réseaux de téléphonie IP utilisant des passerelles VoIP. Il gère la communication entre les Media
Gateway et les Media Gateway Controller. Ce protocole traite la signalisation et le contrôle des
appels, d’une part, et les flux média d’autre part.
Il fonctionne au niveau applicatif et permet d’offrir une couverture plus large en fédérant toutes
les signalisations, qu’elles soient de type IP ou RTC entre autres. C’est le maître d’oeuvre de l’in-
teropérabilité entre tous les protocoles de signalisation et tous les réseaux, de quelque nature qu’ils
soient.
Architecture et fonctionnement
Figure 2.23: Rôle fédérateur du protocole MGCP
MGCP fonctionne selon une architecture centralisée permettant de faire communiquer et de contrô-
ler différentes entités appartenant à des réseaux distincts. Il se fonde sur l’hypothèse que les termi-
naux des utilisateurs peuvent être des composants de base, peu coûteux et sans aucune intelligence,
réduits à des fonctionnalités élémentaires.
MGCP fait éclater le modèle architectural proposé avec H.323 en décomposant le rôle des passerelles
et en externalisant toute leur intelligence sur une entité centrale. Pour réaliser cette distinction,
MGCP définit les entités suivantes :
• Le Call Agent, qui sert à piloter et administrer les passerelles de manière centralisée.
• Les passerelles, qui maintiennent la connectivité entre réseaux de nature différente.
Le Call Agent
Le Call Agent, également appelé contrôleur de passerelles multimédias ou encore SoftSwitch, selon
une terminologie non officielle mais courante, a pour fonction de contrôler les passerelles et de
concentrer toute l’intelligence ainsi que la prise de décision dans le réseau. Entité logique, pou-
vant être localisée n’importe où dans le réseau, le Call Agent est spécifiquement responsable de
l’établissement, de la maintenance et de la terminaison des appels établis entre des terminaux
appartenant à des réseaux de nature différente. Le rôle de la passerelle multimédia est donc réduit
Figure 2.24: L’architecture MGCP
à l’acheminement cohérent des données, ce qui implique qu’elle accomplisse les tâches suivantes :
• conversion du signal ;
• adaptation au support ;
• compression des données ;
• conversion de la signalisation ;
• multiplexage ;
• mise en paquets.
Principes d’établissement d’une communication

On appelle endpoint un équipement dit de terminaison, qui représente soit la source soit la des-
tination d’un message multimédia.
Pour mettre en relation les deux endpoints, les cinq étapes suivantes sont nécessaires :
1. Requête de création de connexion vers la première passerelle. Le Call Agent sollicite la création
d’une connexion avec un endpoint auprès de la passerelle concernée.
2. Réponse de la première passerelle. Celle-ci se charge de joindre le endpoint et lui attribue les
ressources nécessaires à la communication : une session est créée entre la passerelle et le endpoint.
En retour, la passerelle envoie au Call Agent un descriptif de la session créée. Ce descriptif contient
l’ensemble des paramètres permettant de joindre le endpoint, incluant l’adresse IP de ce dernier,
le port UDP sur lequel la communication est en attente et les codecs supportés.
3. Requête de création de connexion vers la seconde passerelle. Le Call Agent procède de la même
façon pour le second endpoint et sa passerelle : il sollicite cette dernière en lui envoyant un message
pour la création d’une connexion avec le second endpoint. En plus, et dans le même message, le
Call Agent lui fait parvenir le descriptif de session que lui a retourné la première passerelle.
4. Réponse de la seconde passerelle. La seconde passerelle joint le endpoint concerné et alloue les
ressources nécessaires à cette communication. En retour, elle transmet au Call Agent un descriptif
de session contenant les paramètres permettant de joindre le second endpoint.
5. Mise en relation des deux endpoints. Le Call Agent contacte la première passerelle et lui trans-
met le descriptif de la session retournée par la seconde passerelle. Comme une connexion existe
déjà avec le endpoint, il n’est pas nécessaire de créer une nouvelle connexion. Il suffit de modifier
celle qui existe et de la compléter. C’est donc une commande de modification qui est effectuée par
le Call Agent.
Les messages MGCP
La communication avec MGCP obéit à un modèle de type client-serveur. Un message MGCP est
soit une requête, soit une réponse à une requête. Il est constitué sous forme textuelle, ce qui simpli-
fie son usage (traitement sans compilateur, donc plus rapide, et débogage immédiat), et présente
plusieurs analogies avec le protocole SIP. Ainsi, une transaction MGCP est-elle constituée d’une
Figure 2.25: Mise en relation de deux endpoints
requête et de la réponse à cette requête, éventuellement précédée de réponses temporaires.

Dans ce message, on distingue trois parties :
• Ligne de requête ou de réponse : notifie la commande à exécuter (s’il s’agit d’une requête) ou le
résultat de la commande (s’il s’agit d’une réponse). C’est une partie indispensable.
• En-tête : spécifie la liste des paramètres du message. C’est une partie facultative.
• Corps du message : décrit les paramètres de la session à établir. C’est une partie facultative.
Figure 2.26: Format d’un message MGCP
Paramètres généraux pour les requêtes et les réponses

Les en-têtes et corps d’un message sont communs à tous les messages MGCP.
En-tête d’un message
Cette partie est, selon les messages, obligatoire, optionnelle ou interdite. Elle mentionne des attri-
buts caractérisant le message.
TABLE 2.6 : Paramètres d’en-tête d’un message MGCP

Les réponses MGCP

Comme pour SIP, les messages de réponse à une requête sont envoyés par un code de retour à trois
chiffres. Là aussi, on distingue plusieurs catégories de codes de retour, assez comparables à ceux
de SIP.
TABLE 2.7 : Principaux codes d’état des réponses MGCP

TABLE 2.7 : Principaux codes d’état des réponses MGCP (suite)

TABLE 2.7 : Principaux codes d’état des réponses MGCP (suite)
Les codes de retour numérotés de 800 à 899 et 903 à 905 inclus sont réservés pour les paquetages.
2.6 La pratique de la téléphonie sur IP
2.6.1 Le modèle de téléphonie tout-IP
L’offre gratuite (Figure 2.27) ne permet aux utilisateurs du logiciel que de communiquer entre
eux. Il s’agit d’une communication purement IP, qui sollicite exclusivement le réseau Internet. Ce
service est systématiquement proposé gratuitement dans toutes les offres. La gratuité est justifiée
puisque le coût de connexion au réseau IP est directement imputable à l’internaute, lequel s’acquitte
d’une somme le plus souvent forfaitaire pour disposer d’une connexion Internet. La communication
ne requiert donc pas de surcoût en soi.
Figure 2.27: Le modèle de téléphonie tout-IP

L’offre payante (Figure 2.28) met en relation un utilisateur utilisant un softphone avec un
utilisateur du réseau de téléphonie traditionnel. Les utilisateurs de softphone ne sont donc pas
confinés à des communications entre internautes mais encouragés à acheter des crédits leur per-
mettant d’appeler les téléphones traditionnels. Ce sont donc à la fois le réseau Internet et le réseau
téléphonique commuté qui sont utilisés dans ce mode de communication. Le service n’est plus gra-
tuit puisque le réseau RTC est généralement facturé à l’usage et non forfaitairement. Grâce à ces
crédits, les utilisateurs peuvent communiquer partout dans le monde, à des tarifs très avantageux,
une bonne partie de la communication transitant sur le réseau IP, y compris la partie qui relit
l’abonné appelant à son opérateur.
Figure 2.28: Le modèle de téléphonie IP/RTC
2.6.2 Téléphoner gratuitement d’un PC vers un téléphone fixe
Parmi les dizaines de sites qui proposent de téléphoner gratuitement d’un PC vers des téléphones
fixes sur des dizaines de destinations, citons notamment les suivants :
• Netappel (www.netappel.fr)
• VoIPBuster (www.voipbuster.com)
• VoIPStunt (www.voipstunt.com)
• VoIPCheap (www.voipcheap.com)
• VoIPDiscount (www.voipdiscount.com)
• InternetCalls (www.internetcalls.com)
• SIPDiscount (www.sipdiscount.com)
En dépit de la profusion de ces sites, ce modèle ne semble guère viable à première vue. En réalité,
derrière tous ces sites se cache une seule et même société, Finarea SA, basée à Lugano en Suisse.
La multiplicité des offres a pour unique objectif de rabattre de nouveaux clients vers cette société.
2.6.3 Skype
Skype est l’un des premiers logiciels grand public à avoir permis la jonction entre la téléphonie du
monde Internet et celle du monde RTC. C’est sans doute là la clé de son succès. Grâce à une qualité
d’écoute excellente, une facilité d’utilisation ne nécessitant généralement aucune configuration (y
compris dans les infrastructures réseau déployant des pare-feu), une mobilité accrue, une gamme de
services complémentaires et un prix incomparablement moins cher que la téléphonie traditionnelle,
Skype s’est répandu de manière virale. Skype a été lancé le 29 août 2003 à l’initiative de Niklas
Zennström, un Suédois de 36 ans, et Janus Friis, un Danois de 26 ans, tous deux experts en
technologies de peer-topeer puisqu’ils avaient fait frémir l’industrie de l’entertainment au début
des années 2000 avec le logiciel Kazaa, qu’ils avaient conçu.
Figure 2.29: Téléphones Skype
2.6.4 Windows Live Messenger
Utilisée par plusieurs millions de personnes dans le monde, la messagerie instantanée n’a pas
échappé à la déferlante de la ToIP et permet désormais à ses utilisateurs de téléphoner vers le
réseau RTC traditionnel, en plus des conversations audio et vidéo sur le réseau IP.
Avec près de 300 millions d’utilisateurs, WLM est l’un des clients de messagerie les plus utilisés
au monde. La grande nouveauté de WLM réside dans la possibilité d’appeler des utilisateurs sur
le réseau téléphonique traditionnel (fixe ou mobile). Pourvu de cette fonctionnalité, l’affrontement
avec Skype, qui, de son côté, revendique le plus grand nombre d’utilisateurs à sa solution de ToIP
logicielle, semble inévitable.
Figure 2.30: Fenêtre principale de WLM
2.6.5 Yahoo ! Messenger
Avec près de 90 millions d’adeptes dans le monde, Yahoo ! Messenger, la messagerie instantanée
de Yahoo !, est très proche de la messagerie de Microsoft.
• Les utilisateurs d’ordinateurs Mac et UNIX n’ont pas été oubliés par le logiciel proposé par
Yahoo !.
• Pour Windows, http ://fr.messenger.yahoo.com.
• Pour MacOS 8/9/X, http ://fr.messenger.yahoo.com/mac.php.
• Pour UNIX, http ://fr.messenger.yahoo.com/unix.php.
2.6.6 Jabber
Jabber est une plate-forme libre développée pour assurer l’interopérabilité des logiciels de mes-
sagerie instantanée et fédérer les réseaux de messagerie autour de normes communes. Comme la
Figure 2.31: Modèle Yahoo ! Messenger
ToIP est devenue le pendant de la messagerie instantanée, Jabber a étendu son modèle pour traiter
la gestion des flux multimédias. L’approche de Jabber en matière de messagerie instantanée et de
téléphonie se distingue de celle de ses concurrents en ce qu’elle se rapproche du courrier électro-
nique.
Jabber définit un ensemble de protocoles qui utilisent des normes communes et ouvertes laissant
libres l’implémentation et l’ergonomie des logiciels clients tout en garantissant l’interopérabilité
de leurs communications. Il ne s’agit donc pas à proprement parler d’un logiciel client, ni d’un
logiciel serveur, mais plutôt d’une plate-forme dédiée à la messagerie instantanée et conçue pour
être ouverte, rapide, facile à utiliser et à étendre pour de nouveaux services, parmi lesquels la
téléphonie sur IP.
2.6.7 Google Talk
• Pour Google, le service de téléphonie Google Talk n’est que le troisième volet de son offre
de communication pour les internautes, qui inclut aussi Google Mail, le courrier électronique, et
Google Chat, la messagerie instantanée.
• Troisième volet de la communication initiée par Google, la ToIP a été lancée le 9 août 2005. Dans
Google Talk la conversation est fluide, stable, sans coupure ni retard perceptible et globalement
Figure 2.32: Le modèle décentralisé de Jabber
d’excellente qualité.
Figure 2.33: Modèle Google Talk
2.6.8 Asterisk
Asterisk est un PBX-IP, ou IP PBX ou encore IPBX. Complet et performant, il offre une plate-
forme personnalisable et modulable pour la mise en oeuvre de services de téléphonie. Il garantit une
très large interconnexion avec plusieurs serveurs PBX, mais aussi avec des réseaux de téléphonie
non-IP.
Asterisk propose toutes les fonctionnalités d’un standard téléphonique de niveau professionnel, des
plus élémentaires aux plus complexes. Non seulement, il permet de gérer le routage des appels
au sein du réseau, mais en plus il supporte une large gamme de services, notamment les suivants
(pour la liste exhaustive, voir le site de l’éditeur, à l’adresse http ://www.asterisk.org) :
• Authentification des utilisateurs appelants.
• Serveur vocal, ou standard d’accueil téléphonique automatisé, aussi appelé IVR (Interactive
Voice Response). Cette fonction permet de demander à l’appelant le service qu’il souhaite utiliser
et d’effectuer le routage correspondant.
• Numérotation abrégée pour définir des raccourcis.
• Transfert d’appel.
• Filtrage des appels.
• Messagerie vocale (répondeur automatique).
• Notification et écoute par e-mail des messages laissés sur son répondeur (voicemail).
• Gestion des conférences.
• Double appel.
• Mise en attente.
• Journalisation des appels.
• Facturation détaillée.
• Enregistrement des appels.
Figure 2.34: Procédure de call-back

Chapitre
3
Les familles de protocoles d’un ré-
seau NGN
3.1 Introduction
La convergence des réseaux voix/données ainsi que le fait d’utiliser un réseau en mode paquet
pour transporter des flux multimédia, ayant des contraintes de "temps réel", a nécessité l’adap-
tation de la couche contrôle. En effet ces réseaux en mode paquet étaient généralement utilisés
comme réseau de transport mais n’offraient pas de services permettant la gestion des appels et
des communications multimédia. Cette évolution a conduit à l’apparition de nouveaux protocoles,
principalement concernant la gestion des flux multimédia, au sein de la couche Contrôle.
3.2 Protocole H.248/Megaco
Le groupe de travail MEGACO (MEdia GAteway COntrol) a été constitué en 1998 pour complé-
ter les travaux sur le protocole MGCP au sein de l’IETF. Depuis 1999, l’UIT et l’IETF travaillent
conjointement sur le développement du protocole MEGACO/H.248 ; c’est un standard permettant
la communication entre les Media Gateway Controller (MGC) et les Media Gateway (MG). Il est
dérivé de MGCP et possède des améliorations par rapport à celui-ci :
• Support de services multimédia et de vidéo conférence.
• Possibilité d’utiliser UDP ou TCP.
• Utilise le codage en mode texte ou binaire.
Le protocole MEGACO/H.248 a été choisi dans UMTS par le 3GPP pour le contrôle des Media
93
Chapitre 3 Les familles de protocoles d’un réseau NGN 94
Gateways. Les tâches principales de H.248/Megaco sont :

• La commande des ressources,
• La commande de la conversion des flux informationnels,
• Le traitement de signaux et d’événements signalés par les passerelles,
• Les rapports statistiques.
Figure 3.1: Les tâches principales de H.248/Megaco
3.2.1 H.248/Megaco dans les IMS
Le protocole H.248/Megaco est utilisé sur trois interfaces différentes :

• Entre le MGCF (Media Gateway Control Function) et les passerelles de médias T-MGF
(Trunking-Media Gateway Function), il joue son rôle conventionnel.
• Entre les entités du serveur de médias MRFC (Media Resource Function Controller) et MRFP
(Media Resource Function Processor), il permet de commander la génération des tonalités et an-
nonces, la mise en place de conférences et la transcription de flux provenant de codecs différents.
• Entre le contrôleur IBCF (Interconnection Border Gateway Control Function) et la passerelle
I-BGF (Interconnection Border Gateway Function), il commande l’interconnexion avec d’autres
réseaux SIP.
3.2.2 Modèle de connexion H.248/Megaco
Le modèle de connexion H.248/Megaco décrit les entités logiques localisées sur les passerelles de
médias qui sont contrôlées par le contrôleur de passerelles de médias.
• Contexte (Context) : permet l’établissement de communications entre appareils multimédias
recourant à plusieurs connexions parallèles, dont les paramètres diffèrent en fonction des flux in-
formationnels transportés.
• Terminaison (Termination) : Représente un flux entrant ou sortant de la passerelle.
• Terminaisons éphémères ou virtuelles correspondant à un flux RTP sont créées au besoin
et supprimées lorsque la communication est terminée.
• Les caractéristiques d’une terminaison (taille de la mémoire de compensation de gigue, annu-
lation d’écho, émission/réception, etc.) sont regroupées dans des descripteurs (Termination
Descriptor) qui peuvent être surveillés et modifiés par le contrôleur.
A)- Relation entre transaction, contexte et commande
• Les commandes transmises entre contrôleur et passerelles de médias sont regroupées en transac-
tions.
• Les commandes permettent de manipuler les entités logiques du modèle de connexions de
H.248/Megaco, les contextes et les terminaisons.
• Il est possible, par exemple, d’ajouter des terminaisons à un contexte, de modifier des terminai-
sons, de supprimer des terminaisons d’un contexte et d’examiner les propriétés des contextes et
des terminaisons.
B)- Liste des commandes

• Add (MGC ->MG) ajoute une terminaison à un contexte. Appliquée à la première terminai-
son, elle sert à créer le contexte.
• Substract (MGC -> MG) supprime une terminaison d’un contexte et renvoie les statistiques
relatives à cette terminaison. Appliquée à la dernière terminaison d’un contexte, elle supprime le
contexte.
• Modify (MGC -> MG) modifie les propriétés, les événements et les signaux d’une terminai-
son.
• Move (MGC -> MG) déplace une terminaison d’un contexte vers un autre.
• Audit Value (MGC -> MG) requiert que la passerelle de médias informe le contrôleur de
passerelles de l’état des terminaisons.
• Audit capabilities (MGC -> MG) requiert que la passerelle de médias informe le contrôleur
de passerelles de toutes les caractéristiques possibles pour les terminaisons.
• Notify (MG -> MGC) permet d’informer le contrôleur de passerelles de médias d’événements
qui se sont déroulés dans la passerelle concernée.
• service (MGC -> MG/ MG -> MGC) permet d’indiquer la mise hors service.
• Change (MGC -> MG/MG -> MGC) terminaisons, respectivement leur retour au service
normal. Cette commande permet également à la passerelle d’annoncer sa disponibilité à un contrô-
leur.
C)- Descripteur (Descriptor)

• Les paramètres caractérisant une commande s’appellent descripteurs.
• Ils sont formés d’un nom et d’une liste d’éléments dont certains peuvent être pourvus de valeurs :
DescriptorName=parm=value, parm=value...
TABLE 3.1 : Sommaire des descripteurs
D)- Paquetage (Package)

• Un paquetage décrit un ensemble de fonctionnalités spécifiques.
• Un contrôleur qui interroge une passerelle à l’aide de la commande Audit Capabilities va
recevoir en réponse une liste des paquetages (Packages) supportés par la passerelle.
Les paquetages de base sont :
• Tone Generator (Générateur de tonalités) : définit les paramètres pour générer des tonalités
audio.
• Tone Detection (Détection de tonalités) : définit les événements relatifs à la détection des
tonalités audio.
• Basic DTMF Generator (Génération de tonalités DTMF) définit les tonalités DTMF (Dual-
Tone Multi-Frequency) de base sous la forme de signaux.
• Basic DTMF Detection (Détection de tonalités DTMF) : définit le mode de détection des
tonalités DTMF de base.
• Call Progress Tones Generator (Générateur de tonalités de progression d’appel) : définit les
tonalités de progression d’appel de base en tant que signaux.
• Call Progress Tones Detection (Détection de tonalités de progression d’appel) : définit les
tonalités de détection de progression d’appel de base.
• Basic Continuity (Continuité de base) : définit événements et signaux pour le test de continuité,
qui comprend bouclage et fonctionnalité d’émetteur-récepteur.
• Analog Line Supervision (Supervision de ligne analogique) : définit les événements et les états
des lignes analogiques.
• Network (Réseau) : définit les propriétés des terminaisons de réseau indépendantes du type de
réseau (TDM, IP et ATM).
• RTP (RTP : Real-Time Protocol) : est utilisé pour assurer le transport en mode paquet, de
données multimédias, au moyen du protocole de transport en temps réel RTP.
• TDM Circuit (Circuit TDM) : peut être utilisé par toute terminaison qui prend en charge le
contrôle du gain et la compensation de l’écho.
• Segmentation (Segmentation) : définit les propriétés à mettre en œuvre lors de l’exécution d’une
segmentation de type H.248 dans des protocoles de transport qui n’offrent pas la segmentation.
3.2.3 Format des messages H.248/Megaco
Version du protocole (Megaco V3) : La version actuelle du protocole est 3.

• Identificateur de transaction (TransactionID : 1266) : Les commandes entre le contrôleur et
les passerelles de médias sont regroupées dans des transactions identifiées par un identificateur.
• Identificateur de contexte (Context=33554704) : Une transaction est un regroupement d’ac-
tions à appliquer à un contexte.
• Commandes (Add TerminationID = ...) : Le regroupement de plusieurs commandes dans un
seul message est une caractéristique importante de H.248.
• Descripteurs (Local Media Descriptor ...) : Les actions à effectuer sont précisées par des des-
cripteurs. Ici, le descripteur définit les caractéristiques du flux de média au moyen de SDP (Session
Description Protocol).
3.3 Le protocole COPS (Common Open Policy Service)
COPS est le protocole de signalisation développé par l’IETF pour transporter les demandes
de configuration et retourner les politiques à appliquer. Il s’agit d’un protocole flexible de type
Requête/Réponse entre un serveur de politique, ou PDP, et un client, ou PEP. Il supporte les
politiques de contrôle et permet une certaine qualité de service au niveau de l’IMS. Ce protocole
est basé sur une architecture client-serveur. Le serveur, baptisé PDP (Policy Decision Point),
transmet les règles de gestion de trafic à des clients, dénommés PEP (Policy Enforcement Point).
Les clients sont généralement des routeurs, des commutateurs ou des pare-feu chargés de leur mise
en application. Ce protocole est constitué de deux principaux éléments :
• Le PDP (Policy Decision Point) est responsable des prises de décision (comportement sur un
flux ou des paquets) pour la gestion d’un domaine. Il peut émettre un ordre de sa propre initiative
ou après avoir été sollicité par des PEP (Policy Enforcement Point). Il doit également gérer les
ressources en déterminant les règles à appliquer aux PEP. Il convertit les règles de politique dans
un format adapté (sous forme de Policy Information Base, PIB) et garanti leur acheminement aux
PEP.
• Le PEP (Policy Enforcement Point) est un équipement du réseau (routeur, passerelle, etc) où
sont mises en application les règles de politique (QoS, sécurité, mobilité, etc) définies par le PDP.
Les fonctions principales du PEP consistent d’abord à faire la correspondance entre les règles
définies dans les PIB et la configuration des équipements réseaux ; puis d’exécuter les décisions du
PDP et de l’en informer via des rapports.
Le mode d’échange de COPS est de type Client-Serveur avec un e relation de maître à esclave
("Master/Slave"). Le PDP est le maître et le PEP l’esclave. Il n’y a pas de classifi cation de
message de type requête/réponse. COPS peut fonctionner au dessus de TCP uniquement. Une
connexion persistante TCP est établie entre le PEP et PDP. La fiabilité est donc assurée par TCP.
Dans le COPS, le mode de communication est unique et direct entre le PEP et le PDP, il n’y pas
d’entités intermédiaires.
Figure 3.2: Architecture du système COPS
3.3.1 Format des messages COPS
Un message COPS comprenant un en-tête avec différents champs de contrôle, suivi des champs
objet. Chaque champ objet est composé de la même façon, en commençant par la longueur de
l’objet, la définition de l’objet, le type d’objet et enfin le contenu et les valeurs associées de l’objet.
Ils sont de longueur variable. Si la longueur totale d’un objet n’atteint pas un multiple de 4 octets
(32 bits), des bits de bourrage seront insérés.

L’entête est composé de six champs :
Figure 3.3: Format du message COPS
• Version : correspond au numéro de version du protocole (actuellement V1).
Figure 3.4: Message COPS
• Flags : flag 0x1 signifie que le message a été sollicité par un autre message COPS. Les autres
flags sont mis à 0.
• Op Code : définit le type d’opération qui est initiée par le contenu informationnel du message.
Les 10 valeurs prévues sont :
TABLE 3.2 : Codes opération d’un message COPS
• Client-type : identifie le client et détermine l’interprétation des objets encapsulés dans le corps
du message. Les valeurs 0x8000 à 0xFFFF sont utilisées pour des applications propriétaires.
• Message Length : indique la taille du message en octets, incluant l’en-tête.
• Length : indique la taille de l’objet qui suit, en octets.
• C-Num : identifie la classe de l’information contenue dans le champ Object Contents du mes-
sage.
• C-Type : identifie la sous-classe ou la version de l’information contenue dans Object Contents.
• Object Contents : transporte le contenu informationnel correspondant aux divers types de
politiques ou instances, comme la gestion de qualité, l’authentification d’accès au réseau, etc.
Messages du PEP -> PDP
• REQUEST : Demande de politique
• REPORT STATE : Résultat d’installation de politique
• DELETE REQUEST STATE : Fin d’application de politique
• CLIENT OPEN : Demande de prise en compte de Client COPS
• SYNCHRONIZE STATE COMPLETE : Fin de synchronisation
Messages du PDP -> PEP
• DECISION : Envoi de politique
• SYNCHRONIZE STATE REQUEST : Demande de synchronisation
• CLIENT ACCEPT : Prise en compte de Client COPS
Messages du PDP <-> PEP

• CLIENT CLOSE : Fin de prise en compte de Client COPS
• KEEP ALIVE : Signal d’existence.
Scénario
Les scénario de contrôle de politiques COPS dépendent du mode de contrôle de politique. Cepen-
dant, on peut illustrer les échanges de messages COPS par une décomposition en étapes décrites
dans la figure 3.5.
Figure 3.5: Représentation schématique des échanges COPS
3.3.2 Classes des objets du message
• Handle : contient une valeur unique utilisée comme référence à une requête émise par le PEP.
Elle est reprise par le PDP.
C-Type = 1 : Client Handle
• Context : spécifie le type d’événement qui a initié la requête. Les deux premiers octets
contiennent le R-Type et les deux suivants, le M-Type.
• In-Interface : identifie l’interface d’entrée et l’adresse à l’origine du message.

C-Type = 1 : l’adresse IPv4 et l’identification de l’interface sont contenues dans le champ Object
Contents
C-Type = 2 : l’adresse IPv6 et l’identification de l’interface sont contenues dans le champ Object
Contents
• Out-Interface : même usage que ci-dessus, mais pour l’interface de sortie et l’adresse.
• Reason : spécifie la raison pour laquelle un état a été effacé. Les deux premiers octets identifient
la raison, alors que les deux derniers, baptisés Reason Sub-Code, sont utilisés par le fabricant pour
préciser la raison.
• Decision : contient la décision prise par le PDP. Ce code apparaît dans les réponses.
• LPDP Decision (Local Policy Decision Point) : même description que cidessus.
• Error : est utilisé pour identifier une erreur particulière du protocole COPS. Les deux premiers
octets identifient l’erreur, alors que les deux derniers, dénommés Error Sub-Code, sont utilisés par
le client pour préciser le type d’erreur.
• Client Specific Info : contient de l’information spécifique au type de client.

C-Type = 1 Signaled ClientSI
C-Type = 2 Named ClientSI
• Keep-Alive Timer : indique le temps maximal avant lequel un message doit être envoyé,
respectivement reçu. La valeur est comprise entre 1 et 65’535 secondes.
• PEP Identification : est utilisé pour identifier un client PEP auprès du PDP distant.
C-Type = 1 chaîne ASCII identifiant le client de manière univoque.
• Report-Type : définit le type de rapport associé à un objet Handle.
• PDP-Redirect Address : A la clôture d’une session avec un C-Type = 1

1 = Success (la décision est positive pour le PEP)
2 = Failure (La décision n’a pas abouti pour le PEP)
3 = Accounting (mise à jour des informations de traçabilité)
• PEP, le PDP peut indiquer l’adresse d’un autre PDP.
C-Type = 1 Adresse IPv4 et numéro de port TCP
• Last PDP Address : A l’envoi du message Client-Open, le PEP doit indiquer l’adresse du
dernier PDP avec lequel une ouverture a abouti.
• Accounting Timer : indication du temps maximal entre deux rapports, compris entre 1 et
65’535 secondes.
• Message Integrity : champ servant à authentifier et valider un message. L’implémentation doit
supporter au minimum HMAC-MD5-96 (algorithme MD5 tronqué à 96 bits).
3.3.3 Messages du protocole COPS
• Authorisation_Request (REQ) : permet à la passerelle de demander les informations

d’autorisation au PDP.
• Authorisation_Decision (DEC) : contient la décision du PDP d’installer une configuration.
• Authorisation_Failure (DEC) : permet au PDP d’informer la passerelle d’un échec d’auto-
risation.
• Gate Decision (DEC) : informe la passerelle du nouveau statut qui a été établi pour un
contexte.
• Report (RPT) : permet à la passerelle, suite à la réception d’un message DEC, d’informer le
PDP de la réussite ou de l’échec de mise en place de la décision.
• Delete Request State (DRQ) : permet à la passerelle d’informer le PDP que le contexte a
été désactivé et n’est plus disponible sur le client PEP, et qu’il doit aussi être supprimé dans le
PDP.
• Remove_Decision (DEC) : est utilisé par le PDP pour informer la passerelle que l’autorisation
des ressources a été révoquée pour le contexte spécifié.
3.3.4 Classes de qualité de service
Conversationnel : trafic conversationnel en temps réel comme, par exemple, un service parole
qui requiert la préservation des caractéristiques du temps réel ;
• Lecture en flux (Streaming) : trafic en temps réel dont la relation temporelle entre les
différentes entités du flux informationnel doit être préservée comme, par exemple, du streaming
vidéo ;
• Interactif : trafic de catégorie Best Effort comme, par exemple, la navigation web ;
• Trafic d’arrière-plan : trafic de catégorie Best Effort comme, par exemple, la télémétrie ou le
courrier électronique.
3.4 Le protocole DIAMETER
Diameter, décrit dans la RFC 3588 de l’IETF, l’évolution du RADIUS, est le protocole AAA
dans IMS (authentification : "authentifier l’identité du client", autorisation : "accorder des droits au
client" et Accounting : "enregistrer les données de comptabilité de l’usage du réseau par le client").
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. Les échanges Diameter sont
toujours du type un message requête et une réponse associée. Les informations échangées dans
ces messages sont mises dans des attributs appelés AVP (Attribute Value Pairs). Chaque interface
Diameter a ces AVPs et ces commandes. Ce protocole se situe au niveau de la couche transport.
Il utilise le port 3868 via le protocole TCP ou bien SCTP. Dans un domaine IMS, on utilise
Diameter entre le HSS et l’I/S_CSCF pour la gestion des autorisations des abonnés. La plupart
des informations sont stockées dans le HSS et certaines le sont dans l’équipement de l’utilisateur
(UE) pour gérer sa mobilité et sa localisation. Ce protocole est utilisé par exemple lors des échanges
entre les serveurs d’application et le serveur HSS, pour les transferts d’informations des profils des
utilisateurs. La sécurité fournie par Diameter est présente via IP Sec ou TLS.
Figure 3.6: Le protocole DIAMETER

Le protocole Diameter fournitles fonctionnalités suivantes :

• Délivre les AVPs (attribute value pairs) ;
• Possède une capacité de négociation ;
• Notifie sur les erreurs ;
• Extensible grâce à la possibilité d’ajouter des nouvelles commandes et des AVPs ;
• Permet de faire des services basiques nécessaires pour les applications comme la manipulation
des sessions des utilisateurs ou la comptabilité.
Les AVPs sont utilisés par le protocole DIAMETER pour :
• Transporter les informations d’authentification et d’autorisation ;
• Echanger des informations qui peuvent servir pour la comptabilité ;
• Envoyer les informations sur le profil des services des utilisateurs.
3.4.1 Les responsabilités de Diameter
Tel qu’il a été défini par l’IETF, Diameter peut être divisé en deux composants :
• Le protocole Diameter en lui-même (Diameter Base) : fournit les conditions de com-
munication et de format des messages, et utilise les protocoles TCP ou SCTP. Ses fonctions sont
essentiellement :
o Livraison des AVPs (Attibute-Value Pair) ;
o Négociation des capacités ;
o Notification des erreurs ;
o Gestion de session.
• Diameter Application : placée au-dessus du "Diameter Base", cette partie du protocole hérite
des facilités de communication ainsi offertes, fournit des messages spécifiques de requête/réponse
pour les services utilisés. Ses fonctions sont :
o Autorisation de l’utilisateur ;
o Assignation d’un serveur (S-CSCF) ;
o Récupération des informations de localisation ;
o Authentification multimédia ;
o Finalisation de l’enregistrement ;
o Modifications du profil de l’utilisateur.
3.4.2 Entités DIAMETER
• Un nœud DIAMETER est un hôte qui implante le protocole DIAMETER. Il joue un rôle dual
client et serveur.
• Un agent DIAMETER est un nœud DIAMETER qui fournit des services de relai, de proxy ou
de traduction.
• Un agent relai est un agent DIAMETER qui accepte des requêtes, et les relaie soit à un autre
agent, soit au nœud DIAMETER de destination à partir des informations présentes dans les re-
quêtes (e.g., Destination-Realm).
• Un agent proxy comme un agent relai route le message DIAMETER en utilisant les tables de
routage de realm.
• Agent de redirection : agit comme un entrepôt de configuration pour les autres nœuds du réseau.
A la réception d’une requête, il consulte sa base de données et renvoie l’information de redirection
demandée. Il fournit aussi une fonction de routage. A la différence des autres types d’agent (relai
et proxy) qui acheminent les messages DIAMETER, l’agent de redirection retourne un type parti-
culier de réponse à l’émetteur de la requête. La réponse contient l’information de routage afin que
l’émetteur puisse retransmettre son message directement au serveur destinataire.
Figure 3.7: Les nœuds DIAMETER

3.4.3 Transactions DIAMETER
1. Requête client-serveur : Dans un tel cas, l’adresse du serveur est connue du client. Il peut
donc directement envoyer la requête au serveur adéquat.
2. Requête client-serveur avec proxy : Le proxy permet d’acheminer la requête vers un autre
domaine DIAMETER et, le cas échéant, de modifier le contenu du message.
3. Requête client-serveur avec serveur de redirection : Un serveur de redirection sera né-
cessaire si, par exemple, plusieurs serveurs sont disponibles. Le serveur de redirection informera de
la destination adéquate par un message RedirectNotification.
4. Utilisation d’un Agent de traduction : Si DIAMETER doit opérer avec un environnement
AAA différent (p. ex. RADIUS, TACACS), les messages devront être traduits d’un environnement
à l’autre.
Figure 3.8: Transactions DIAMETER
3.4.4 Format du message DIAMETER
Un message Diameter est composé de 2 parties distinctes :

• L’en-tête du message ;
• Les données qui sont découpés en autant d’AVP voulu.
Figure 3.9: Format du message DIAMETER
i)- En-tête DIAMETER

Un message DIAMETER est constitué d’un en-tête fixe ayant une taille de 20 octets et d’un
nombre variable d’AVP.
• Version : (1 octet) Indique le numéro de version du protocole DIAMETER et doit être mis à 1.
• Message length : (3 octets) indique la longueur du message en octets.
• Command Flags : Ce champ contient 8 bits dont 4 sont réservés.
— Le bit R (Request) indique que le message est une requête (avec la valeur 1) ou une
réponse (avec la valeur 0) ;
— Le bit P (Proxiable) Il indique si le message peut être routé par un agent proxy, un agent
relai ou un agent de redirection ou s’il doit être traité localement ;
— Le bit E (Error) a toujours la valeur 0 dans une requête. Dans un message de réponse, il
indique qu’il y a une erreur dans le message de requête (avec la valeur 1) ou qu’il n’y a pas d’erreur
(avec la valeur 0) ;
— Le bit T (Potentially re-transmitted message) indique qu’un message est original (avec
la valeur 0) ou qu’il a été retransmis (avec la valeur 1) suite à une requête sans réponse ;
— Les 4 bits rrrr (Reserved) sont réservés pour un usage futur ; ils doivent être mis à 0 et
ignorés par le récepteur.
• Command Code : (3 octets) Ce champ identifie le type du message ; Chaque paire de messages
(requête et réponse) dispose d’un code de commande unique assigné par l’IANA. Par exemple
les messages " Credit Control Request " et " Credit Control Answer " utilisés dans la facturation
prépayée ont pour code de commande " 272 ".
• Application-ID : (4 octets) Le protocole DIAMETER est constitué d’un protocole de base sur
lequel sont développés plusieurs applications ou extensions. Ce champ permet d’identifier l’appli-
cation DIAMETER à laquelle appartient le message.
• Hop-by-Hop Identifier : (4 octets) Ce champ est utilisé pour associer un message de réponse
au message de requête correspondant. La valeur de ce champ change à chaque fois qu’un message
est relayé (à chaque saut).
• End-to-End Identifier : (4 octets) Ce champ est un nombre qui permet de détecter un message
DIAMETER dupliqué. Cet identifiant n’est pas modifié durant la transmission du message.
• AVP : A la suite de l’en-tête, viennent les AVP qui représentent le contenu du message, il est
l’objet le plus important dans le protocole DIAMETER ; il est utilisé pour fournir toutes les don-
nées.
Figure 3.10: Message DIAMETER
ii)- Les commandes de base diameter

Diameter définit un ensemble de commandes d’authentification, d’autorisation et de taxation of-
fline et online génériques. Il y a le groupe de commandes connexion management qui permet la
mise en relation DIAMETER entre deux peers et la supervision de cette relation. Ces commandes
ne sont pas routables puisqu’elles ne peuvent subir qu’un seul saut. Le groupe Session Operations
quant à lui permet d’établir une session DIAMETER d’authentification et d’autorisation entre un
client et un serveur. Ces commandes sont de bout en bout et routables via des agents. Les groupes
accounting (offline ou online) permettent l’envoi d’informations de taxation (offline ou online) par
un client à un serveur. Les commandes sont de bout en bout routables via des agents.
Ces différentes commandes sont présentées sur la figure ci-dessous :
Figure 3.11: Commande de base DIAMETER

A ces commandes de bases peuvent s’ajouter des commandes spécifiques aux nœuds ou applica-
tions implémentant diameter. A titre d’exemple, considérons l’interface Cx entre les entités I-CSCF
ou S-CSCF et le HSS dans l’architecture IMS. Cette interface permet l’autorisation d’enregistre-
ment pour l’usager (I-CSCF vers HSS), la demande des vecteurs d’authentification pour l’usa-
ger (S-CSCF vers HSS), la notification d’état d’enregistrement (S-CSCF vers HSS), L’annulation
d’enregistrement initiée par le réseau (HSS vers S-CSCF), La demande de localisation de l’usager
(I-CSCF vers HSS), et la mise à jour du profil de l’usager (HSS vers S-CSCF). Ces différentes
commandes sont illustrées par la figure ci-dessous :
Figure 3.12: Commandes diameter de l’interface Cx
Le tableau suivant détaille la liste des commandes qui sont définies sur l’interface de commutation
nommée Cx, qui est l’interface de communication la plus utilisée, entre la base de données HSS et
les serveurs I-CSCF et S-CSCF.
iii)- Format des AVP

Les données transportées par un message DIAMETER sont contenues dans les AVP. Un message
DIAMETER doit donc renfermer au moins un AVP. Il comporte les champs ci-après :
• AVP Code : C’est un code unique permettant d’identifier un AVP et assigné par l’IANA ;
• AVP Flags : Il est constitué de 8 bits dont 5 sont réservés :
— Le bit V (Vendor-Id) indique si le champ Vendor-Id est présent dans l’AVP (avec la
valeur 1) ou s’il est absent (avec la valeur 0).
— Le bit M (Mandatory) indique si le destinataire du message doit obligatoirement prendre

en charge cet AVP (avec la valeur 1) ou non (avec la valeur 0).
— Le bit P (Protected) indique que l’AVP doit être crypté.
— Les 5 bits RRRRR (Reserved) sont réservés et doivent être mis à 0.

• AVP Length : Indique la taille, en octets, de l’AVP.
• Vendor-Id : Le protocole DIAMETER étant extensible, un particulier peut décider d’implé-
menter un AVP spécifique à ses besoins. L’IANA lui assigne donc un identifiant qui est mis dans
le champ Vendor-Id de l’AVP.
• Data : C’est ce champ qui contient l’information transportée par l’AVP.
Figure 3.13: Format d’un AVP DIAMETER
Les valeurs des codes définis pour les AVP :

iv)- DIAMETER dans les NGN

• Clients DIAMETER : Dans les NGN, les serveurs de signalisation SIP que sont I-CSCF et S-
CSCF, ainsi que les serveurs d’applications et les serveurs chargés de la traçabilité et de la taxation
contiennent les clients DIAMETER.
• Serveurs DIAMETER : La base de données HSS-UPSF est un serveur DIAMETER. NASS
joue un rôle similaire pour les données de paramétrage des équipements du réseau d’accès physique.
• Agent de redirection : Dans un réseau contenant plusieurs HSS-UPSF, la base de données
SLF joue le rôle de serveur de redirection DIAMETER.
Figure 3.14: DIAMETER dans NGN
L’interface Cx
Considérons l’interface Cx entre l’I-CSCF ou le S-CSCF et le HSS dans l’architecture IMS. Cette
interface permet :
• L’autorisation d’enregistrement pour l’usager (I-CSCF –> HSS) ;
• La demande des vecteurs d’authentification pour l’usager (S-CSCF –> HSS) ;
• La notification d’état d’enregistrement (register / de-register) (S-CSCF –> HSS) ;
• L’annulation d’enregistrement initiée par le réseau (HSS –> S-CSCF) ;

• La demande de localisation de l’usager (I-CSCF –> HSS) ;
• La mise à jour du profil de l’usager (HSS –> S-CSCF).
Messages DIAMETER sur les interfaces Cx et Dx
Figure 3.15: Messages DIAMETER sur les interfaces Cx et Dx
Les valeurs définies pour les attributs des AVP
Figure 3.16: Les valeurs définies pour les attributs des AVP
Messages DIAMETER sur l’interface Sh
Figure 3.17: DIAMETER sur l’interface Sh
Figure 3.18: Messages DIAMETER sur l’interface Sh
Enregistrement d’un abonné IMS

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.
Pour pouvoir utiliser et bénéficier des services qu’offrent l’IMS, l’utilisateur, doit d’abord s’enre-
gistrer. Le premier pas dans l’enregistrement de l’utilisateur est la découverte du P-CSCF qui fait
office d’interface entre le réseau IMS et les périphériques finaux. Pour un usager se trouvant dans
un réseau d’accès 3G/3G+, la découverte du P-CSCF passe par l’activation d’un contexte PDP
nécessaire pour l’échange de la signalisation SIP.
Les procédures d’authentification et d’établissement dans l’IMS sont directement liées aux procé-
dures d’enregistrement SIP. Il est à noter que l’IMS permet une grande mobilité des abonnés. Ce
qui veut dire qu’un abonné peut s’enregistrer depuis son réseau nominal (Réseau de son opérateur)
ou depuis un réseau visité.
La figure ci-dessous illustre les procédures d’enregistrement d’un abonné IMS :
Figure 3.19: Enregistrement d’un abonné IMS
La procédure d’enregistrement présentée ci-haut fait intervenir à la fois le protocole SIP (pour
l’échange des messages de signalisation) et le protocole diameter (pour l’authentification de
l’abonné) dont les types de messages ont été présentés ci-haut. Les messages SIP "401 Unauthori-
zed" sont des réponses négatives d’enregistrement envoyées par le S-CSCF aux UEs. Ces réponses
contiennent d’une part une valeur random (RAND) à utiliser par l’UE pour calculer un résultat
d’authentification usager et d’autre part un résultat d’authentification réseau (AUTN) permettant
au réseau IMS de s’authentifier auprès de l’usager car l’authentification IMS est mutuelle. Grâce
à cet enregistrement :
• Le HSS est notifié de la localisation de l’UE par rapport au réseau nominal et met à jour le profil
de l’abonné correspondant ;
• L’usager, grâce aux informations d’enregistrement sera authentifié avant de pouvoir accéder aux
services IMS ;
• Le réseau nominal de l’usager sélectionne un S-CSCF approprié qui invoquera les services de
l’UE auprès de serveurs d’application, et ce, grâce au profil de l’usager retourné par le HSS au
S-CSCF sélectionné.
v)- Facturation et télécoms
• Basé sur la consommation d’unités de coût donné
• 2 modes :
• Mode Offline
– Utilisateurs d’offres postpayées (abonnements) ;
– Evènement ou durée ;
– Peu d’influence de Système de Facturation sur le Service rendu.

• Mode Online
– Utilisateur d’offres prépayées (cartes) ;
– Evènement ou durée ;
– Facturation immédiate ou avec réservation d’unités.

Les types de facturation IMS
• La facturation peut être :
– Évènementielle (accès à une ressource) ;
– Session (durée d’accès à une ressource).

• Pour la facturation online, nécessité de réserver des unités
– Ne pas donner accès à une ressource sans crédit.

• Usage de Diameter :
– Plus grande flexibilité de facturation, nécessaire dans des usages nouveaux MAIS plus
grande complexité.
Architecture des systèmes de facturation
Les interfaces Rf et Ro permettent de collecter les données relatives à la facturation différée (Rf
–> offline), respectivement à la taxation en ligne (Ro –> online).
Figure 3.20: Architecture des systèmes de facturation

Chapitre
4
Concepts et Architecture IMS (IP
Multimedia Subsystem)
4.1 Introduction
L’IMS a été conçu à l’origine pour les réseaux mobiles, mais avec l’ajout des travaux de TISPAN
dans la version 7, les réseaux fixes sont également supportés. On appelle cela la convergence
Fixe/Mobile, qui est devenue une des tendances-clés de l’industrie des télécoms en 2005.
L’IMS est une partie structurée de l’architecture des réseaux de nouvelle génération (NGN) qui
permet l’introduction progressive des applications voix et données multimédia dans les réseaux fixes
et mobiles. L’IMS inter-fonctionne avec tous types de réseaux (fixe, mobile ou sans fil), incluant les
fonctions de commutations de paquets, comme le GPRS, l’UMTS, CDMA 2000, WLAN, WiMAX,
DSL, le câble... Les systèmes plus anciens de commutation de circuit (POTS, GSM) sont aussi
supportés grâce à des passerelles (Gateways). Des interfaces ouvertes entre les couches de contrôle
et de service permettent de mélanger les appels/sessions de différents réseaux d’accès. L’IMS
utilise les technologies cellulaires pour fournir un accès en tout lieu, et les technologies Internet
pour fournir les services.
L’architecture IMS est constituée par un ensemble d’équipements et de protocoles dont les fonctions
et les rôles se complètent. Les interfaces sur les différentes liaisons internes et externes à cette
architecture font également l’objet des spécifications évolutives. Le principe de l’IMS consiste,
d’une part à séparer nettement la couche transport de la couche des services et d’autre part à
utiliser la couche transport pour des fonctions de contrôle et de signalisation afin d’assurer la
qualité de service souhaitée pour l’application désirée. L’IMS a pour ambition de constituer une
124
Chapitre 4 Concepts et Architecture IMS (IP Multimedia Subsystem) 125
plate-forme unique pour toute une gamme de services et d’être en mesure d’offrir de nouvelles
applications en un temps minimum. IMS vise, à faire du réseau une sorte de couche middleware
entre les applications et l’accès. Les applications sont soit SIP, soit non SIP, elles passent alors par
une passerelle avant la connexion au contrôleur de sessions.
Figure 4.1: IMS connectant à plusieurs réseaux
4.2 Accès multiple
Bien que conçu comme une évolution du GSM en réseau de paquets, IMS est maintenant devenu
un système de contrôle central indépendant des moyens d’accès au réseau. Les interfaces vers
trois principaux réseaux d’accès ont été définies dans les normes et sont décrites ici : UMTS 3G,
WLAN et DSL à large bande. Les travaux en cours sur les normes continuent de définir d’autres
moyens d’accès, tels que le câble, le Metro Ethernet et le WiMAX. La conception modulaire
du projet de partenariat de troisième génération (3GPP) définissait le système IMS comme un
sous-système, placé au-dessus du réseau d’accès UMTS. Quand IMS a été adopté par fil réseaux,
TISPAN (services et protocoles Internet et télécommunications pour réseaux avancés) définit, en
termes plus génériques, le système IMS principal partagé par tous les réseaux d’accès. Ils ont
également défini les installations spécifiques à l’accès nécessaires pour l’accès filaire (par exemple,
le processus de rattachement au réseau). La figure suivante illustre le modèle à trois couches IMS
avec tous les réseaux interconnectés. Ceux-ci incluent les différents CAN IP à travers lesquels
le terminal IMS peut accéder. Également inclus est l’accès au niveau de l’application via des
passerelles Web Services ou OSA (Open Service Architecture), qui peuvent également initier des
sessions dans IMS. De plus, la figure 4.2 montre la connectivité à d’autres réseaux IP et aux CSN.
Figure 4.2: Accès multiple
4.3 Collaboration mondiale des organismes de normalisa-
tion
Dans le cas d’IMS, les organisations existantes sont mobilisées pour compléter les efforts du 3GPP
plutôt que de le dupliquer. Le 3GPP coopère étroitement avec l’IETF (Internet Engineering Task
Forcer) sur l’extension des protocoles Internet, en particulier des extensions de SIP et Diameter.
Autres organisations développent des extensions de l’architecture IMS, par exemple, OMA (Open
Mobile Alliance) définit des normes d’interfonctionnement de services, telles que PoC (Push-to-
Talk over Cellular). En plus, TISPAN (ETSI) produit notamment des interfaces filaires à intégrer
au 3GPP.
La figure suivate décrit les différents organismes de normalisation qui collaborent au cahier des
charges d’IMS. En Amérique du Nord, le groupe 3GPP2 fusionne le WCDMA nord-américain
(Large bande CDMA) avec le 3GPP dirigé par GSM et l’ATIS (Alliance for Telecommunications
Solutions industrielles) contribue à l’interfonctionnement des réseaux filaires dans ce pays.
Figure 4.3: Organisations de normalisation
4.3.1 L’approche 3GPP
IMS a été conçu comme le sous-système permettant la fourniture de services multimédias au

Mobile 3G, il était basé sur l’accès au téléphone mobile. Il s’agissait principalement de la connec-
tivité sur paquet, avec gestion de l’ID utilisateur et de la localisation et possibilité d’itinérance.
L’architecture est axé sur la capacité à se déplacer et à rendre les données utilisateur accessibles
aux applications - d’où la définition du contrôleur de session (CSCF) et du HSS.
La force de cette architecture réside dans sa nature distribuée inhérente et dans les données cen-
trales. Ces attributs le rendent facilement évolutif et bien adapté aux réseaux mondiaux.
La figure 4.4 présente les principaux éléments de Core IMS décrits par le 3GPP. Les éléments de
contrôle de session détaillent les rôles au sein de la fonction CSCF et la répartition en RTPC via
la fonction MGCF qui contrôle les passerelles de média. La gestion des données (HSS / SLF) est
affichée avec les liens vers l’AS.
Figure 4.4: Core IMS dans 3GPP.
4.3.2 L’approche TISPAN
TISPAN est un groupe ETSI qui a évolué à partir des normes de réseaux fixes (TIPHON) pour
définir des normes IP pour les réseaux NGN (réseaux de nouvelle génération) et la migration à
partir de réseaux de lignes fixes. Le travail TISPAN a permis de faire croire que les connexions
mobiles et fixes peuvent être convergées non seulement avec le transport commun, mais également
avec des composants centraux communs. Les terminaux filaires basés sur IP incluent non seulement
les téléphones IP, mais également les PC et les ordinateurs portables.
TISPAN n’a pas pour objectif de réinventer un autre type de système IMS, mais a adopté tout
ce qui était possible dans les spécifications 3GPP, à savoir définir le système IMS central commun
aux réseaux 3G Mobile et aux NGN définis par TISPAN.
La figure 4.5 représente la définition du Core IMS de TISPAN, avec des éléments déjà définis par
le 3GPP et approuvés par TISPAN, mais également les fonctions qui ont été ajoutés par TISPAN,
tels que AGCF (fonction de contrôle de passerelle), A-BGF (fonction de passerelle d’accès), RACF
(fonction de contrôle des ressources et de l’admission), etc.
Figure 4.5: L’approche TISPAN

4.3.3 L’approche OMA
L’OMA (Open Mobile Alliance) se concentre sur la capacité de fourniture de services plutôt que
sur l’admission et le contrôle de session. L’OMA définit les services de type IMS et les services
non-IMS. Les services non-IMS peuvent être des services Web, des services centrés sur les données,
des services en temps réel ou des services de machine à machine. L’OMA définit les facilitateurs
de service pour les deux types de services.
Comme le montre la figure 4.6, les applications peuvent accéder directement à ces outils pour un
échange d’informations en dehors du cadre du système IMS. L’environnement de service OMA gère
l’interaction entre les services IMS et les services non-IMS.
Figure 4.6: L’approche OMA
4.4 Evolution des réseaux mobiles vers l’IMS
Les systèmes de télécommunications de troisième génération ont la capacité de traiter les appli-
cations multimédias en temps réel et la large bande passante qu’elles nécessitent. Pour bénéficier
d’un retour rapide sur les investissements réalisés sur l’UMTS il faut que :
• Les opérateurs mobiles prennent une part dans la fourniture de service et contenus.
• Introduire rapidement l’architecture IMS qui assure l’accès à une plage de service très grande et
variée.
• La release 99 du 3GPP s’appuie sur une nouvelle interface radio, et une évolution des cœurs de
réseau Global System for Mobile Communications (GSM) et General Packet Radio Service (GPRS)
pour gérer les flux des domaines circuit et paquet.
• La release R4 est la première étape vers un cœur de réseau tout IP, et la release R5 finalise cette
évolution.
Figure 4.7: Evolution des réseaux mobiles
Historique d’IMS
• Défini par le 3GPP (3rd Generation Partnership Project) puis par l’ETSI et le TISPAN.
• IMS apparait dans la release 5 de 3GPP lors du passage de la 2G vers la 3G en mars 2003.
• IMS est toujours entrain d’être standardisé dans la release 11 de 3GPP.
Figure 4.8: Historique d’IMS
4.5 Concepts IMS
C’est une architecture de réseau conçue pour fournir des services IP multimédias fixes et mobiles,
basée sur un réseau cœur tout IP. Il peut s’interconnecter aux réseaux d’accès existants tels que
les réseaux mobiles (GSM,UMTS...) les réseaux WLAN et les réseaux à commutation de circuits(
RTC), en plus il supporte des sessions applicatives temps réel (voix, vidéo, conférence,...) et non-
temps réel (messagerie instantanée, présence, Push To Talk, etc.).
Définition 1
L’IMS est défini dans la spécification 3GPP Release 5 de l’UMTS, l’architecture IMS constitue
une couche logique intermédiaire entre, d’un côté, les terminaux mobiles et les réseaux
de transport orientés IP et, de l’autre, les services applicatifs télécoms gérés par des
serveurs opérés par l’opérateur ou des fournisseurs tiers.
Définition 2
D’après Wikipedia (adapté) : IMS (IP Multimedia Subsystem) est une architecture de services
multimédias pour les réseaux fixes et mobiles qui est ouverte, standardisée et tournée vers
les opérateurs. Cette architecture utilise des protocoles standards du monde Internet.
IMS est utilisé par les opérateurs télécoms au sein de réseau de nouvelle génération (NGN) qui
combinent voix et données au sein d’un même réseau par paquets pour offrir des services
multimédia de manière contrôlée.
4.6 Pourquoi IMS ?
• Architecture de réseau conçue pour fournir des services IP multimédias et mobiles.

• Permettre à un terminal de rester attacher au même réseau nominal quelque soit le réseau visité
et tous les services de l’utilisateur seront effectués et contrôlés par le réseau nominal sans aucun
chargement de profil dans le réseau visité.
• Ajoute aux services déjà disponibles dans le monde Internet la mobilité de téléphonie.
• Constitue une plate forme unique pour toute une gamme de services.
• Définir des standards de façon à pouvoir définir, développer, déployer, combiner des services,
ceci de façon générique (non spécifique à un opérateur).
• Fournir un cadre permettant principalement de fournir des informations sur le service utilisé.
Ceci permettant d’appliquer la QoS adaptée au service et la facturation adéquate pour un service
donné (forfait ? Débit ? Durée ?).
4.6.1 Notions de réseau visité et de roaming
• Le terminal IMS de l’utilisateur — on parle également de UE (User Equipment) — doit pouvoir

se connecter de partout.
• Le concept de réseau visité : lorsqu’un utilisateur utilise un réseau qui n’est pas celui de
l’opérateur auquel il a souscrit un contrat de services, on dit que le réseau en question est visité.
— La connexion de l’utilisateur à un réseau visité est soumise aux accords qui lient son
opérateur à l’opérateur qui exploite le réseau visité.
• On parle de roaming pour désigner la possibilité qu’a un utilisateur de se connecter à un réseau
qui n’est pas celui de son opérateur.
— Les accords de roaming décrivent les conditions contractuelles qui lient un opérateur,
exploitant une base de données de clients, à un opérateur, exploitant un réseau d’accès avec une
couverture géographique.
4.7 Architecture d’IMS
4.7.1 Architecture fonctionnelle en couche d’IMS
Pour une gestion facilitée, IMS s’appuie sur une plateforme commune à tout service. Ainsi, on
peut segmenter le réseau coeur IMS en quatre parties distinctes :
• la couche physique (accès)
• la couche transport
• la couche de session (contrôle)
• la couche application.
Chaque couche est indépendante, de sorte qu’il est possible, par exemple, d’ajouter librement de
nouveaux services dans la couche applicative, sans tenir compte du réseau d’accès que les utili-
sateurs ont employé, ni du terminal qu’ils ont utilisé. Cela dit, il est souhaitable que les serveurs
d’applications adaptent leur réponse en fonction de ces critères : par exemple, une page Web ne
doit pas contenir les mêmes informations ni être formatée de la même manière selon qu’elle est
destinée à être visualisée sur un ordinateur portable ou sur un téléphone portable. Nous allons voir
ces différentes couches, en partant de la plus basse à la couche la plus haute :
Figure 4.9: Architecture IMS

i)- La couche physique (accès)

La couche physique est une couche d’accès à l’architecture IMS. Elle définit la manière dont l’uti-
lisateur se connecte au réseau. IMS permet un large choix de terminaux aux utilisateurs. En
effet, tous les systèmes comme les ordinateurs, les téléphones mobiles, les PDAs, les téléphones
fixes numériques, sont capables de se connecter à l’architecture IMS via le réseau. Les téléphones
traditionnels analogiques pourraient également se connecter à l’architecture IMS par le biais de
passerelles, pour ainsi obtenir une adresse IP, condition nécessaire à une connexion au réseau coeur
IMS.
En regroupant différents types de réseaux d’accès au sein de cette couche, IMS offre un niveau
d’abstraction à la manière dont l’utilisateur se connecte au réseau. Cette vision est à l’origine de
l’idée de convergence des réseaux vers un réseau unique, prônée par l’IMS. Autrement dit, IMS est
indépendant du réseau d’accès, qui n’est qu’un élément assurant la connectivité de l’utilisateur au
réseau cœur.
ii)-La couche transport
Cette couche permet la connectivité de bout en bout entre les différents interlocuteurs. Alors que
la couche d’accès se contente de connecter un utilisateur au réseau IMS, la couche transport se
charge de l’acheminement des données de l’utilisateur jusqu’à son (ou ses) correspondant(s). Cela
comprend le transport de l’information par les routeurs et le choix de la route empruntée dans le
réseau. C’est le réseau IP qui est utilisé dans cette couche. Un des principaux enjeux au niveau de
cette couche est de réaliser la convergence entre réseau à routage par paquet et réseaux à routage
par circuit ; autrement dit, entre le réseau téléphonique commuté et le réseau utilisant TCP/IP.
On pense ici aux téléphones traditionnels analogiques. C’est à ce niveau donc, qu’interviennent les
passerelles PSTN (Public Switched Telephone Network).
iii)- La couche contrôle de session (contrôle)
Cette couche 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 fonction-
nalités de gestion des utilisateurs et constitue le véritable socle de l’IMS.
iv)- La couche application

Elle consiste en la fourniture des services, qu’ils soient audio, vidéo ou textuels. Cette couche im-
plé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.
Tout service est exécuté par un serveur applicatif, en liaison avec les équipements de la couche de
session par l’intermédiaire des protocoles SIP et Diameter, assurant ainsi la sécurité des utilisa-
tions. A noter qu’un serveur peut exécuter différents services comme de la téléphonie et un service
de messagerie. L’avantage de cette flexibilité est de réduire la charge de travail au niveau de la
couche de contrôle.
4.7.2 Principaux composants de l’architecture IMS
Dans cette partie, on va faire une description synthétique des différents composants de l’ar-
chitecture IMS. Toutes ces entités constituent le socle de l’architecture IMS et, à ce titre, sont
indispensables pour le fonctionnement d’un réseau IMS.
i)- Le Home Subscriber Server (HSS)
Le HSS est la base de données des abonnés de l’IMS et des services associés (à l’instar du HLR
pour les réseaux mobiles). Les comptes utilisateurs, leurs profils, droits d’accès, et nom du S-CSCF
(Serving-Call Session Control Function) associés sont stockés dans cet équipement. Il communique
avec les CSCFs pour fournir, temporairement, une copie du profil utilisateur.
Toutes les données relatives à un même compte utilisateur doivent être stockées sur un même HSS.
Néanmoins, lorsque le nombre d’utilisateurs est important, il est possible de les repartir au sein de
plusieurs HSS. Dans ce cas, il est nécessaire de mettre en place une entité complémentaire, appelée
SLF (Subscription Locator Function), qui a pour rôle de déterminer le HSS contenant les données
relatives à un utilisateur. Les serveurs HSS et SLF communiquent avec les autres entités du réseau
au moyen du protocole Diameter.
Figure 4.10: Composants d’IMS
SLF (Subscription Locator Function) : utilisé dans les réseaux disposant de plusieurs HSS, qui a
pour rôle de déterminer le HSS contenant les données relatives à un utilisateur. Le HSS et SLF
implémentent le protocole Diameter de base et une application Diameter spécifique à IMS.
Figure 4.11: SLF (Subscription Locator Function)
Contenu de HSS
— Table SVP (SerVice Profile) : contient le profil de service qui est associé à chaque
utilisateur.
— Table IP Multimédia Private Identity (IMPI) : contient les identifiants qui repré-
sentent les adresses publiques et privées de l’utilisateur avec les informations d’authentification et
autorisation.
— Table IMS Public User identity (IMPU) : contient des informations d’enregistrement.
— Table IMS Subscription User (IMSU) : contient des informations de souscription.
— Table Charging information (Chginfo) : contient des informations de tarification.
— Table Networks : contient la localisation qui représente le réseau dans lequel l’utilisateur
est abonné. Table Roam : pour les réseaux avec lesquels des accords de roaming sont passés.
— Table as_perm_list : contient les services autorisés qui identifient les services auxquels
l’utilisateur est abonné.
— Table Application Server (APSVR) : contient l’adresse de l’AS à contacter si les

trigger points ont été conforme. Des informations sur le comportement par défaut de la session
sont données si le contact avec l’AS a échoué.
— Table Initial Filter Criteria (IFC) : qui représentent les informations de filtrage initial,
caractérisant un certain service pour l’utilisateur. Cette table fait correspondre un trigger point
(table Trigpt) qui associe un ensemble de service point trigger (table spt) à un serveur d’application.
Figure 4.12: Structure des informations des tables du HSS

ii)- CSCF : Call Session Control Function

Les CSCF sont des serveurs de contrôle de sessions, qui utilisent le protocole de signalisation SIP
pour communiquer. Ils sont les organes de traitement des références dans l’architecture IMS et
réalisent les fonctions permettant d’orienter et de contrôler une session. Concrètement, lorsqu’un
utilisateur se connecte, il peut accéder à un réseau qui n’est pas celui de l’opérateur chez qui il a
souscrit un service. Il faut donc que l’utilisateur emprunte le réseau pour assurer sa connectivité,
tout en cherchant à se relier à des entités appartenant à son opérateur, pour avoir accès aux services
de son contrat.
Figure 4.13: Call Session Control Function (CSCF)
Il existe trois types de CSCF, Proxy CSCF, Interrogating CSCF et Serving CSCF, chacun de ces
serveurs peut se trouver en nombre dans un réseau IMS, notamment pour répondre à la charge
des demandes. Nous détaillons dans les sections qui suivent le rôle de chacun de ces serveurs.
— Le Proxy CSCF
Le Proxy CSCF est toujours le premier point de contact entre un terminal et le réseau IMS. Ses
missions consistent notamment à contrôler l’accès et à établir une connexion sécurisée avec le ter-
minal. Son adresse est découverte par l’utilisateur lors d’une phase de "CSCF discovery". Il agit
comme intermédiaire entre l’abonné et l’I-CSCF.
Figure 4.14: Proxy CSCF
— L’Interrogating CSCF L’Interrogating CSCF a comme principales fonctions de déterminer

le S-CSCF auquel l’abonné peut se connecter et transmettre les messages entre le P-CSCF et le
S-CSCF, un peu comme une passerelle.
Figure 4.15: L’Interrogating CSCF
— Le Serving CSCF Le Serving CSCF est l’équipement qui a pour rôle de finaliser l’authen-
tification de l’utilisateur et lui procurer les services opérationnels. Il fournit des informations de
routage, de facturation, maintient l’état de la session en contrôlant un compteur de temps (timer),
interroge le HSS pour vérifier les droits utilisateurs vis-à-vis d’un service, etc. En résumé, le S-
CSCF est le cerveau du réseau cœur IMS. Pour arriver à ces fins, le S-CSCF assure notamment :
• La gestion des enregistrements SIP des utilisateurs, liant l’emplacement courant de l’utilisateur
(URI privé) et à son identité (URI public).
• Le contrôle de toute signalisation SIP provenant et à destination de son client.
• La sélection des serveurs d’applications.
Le serveur S-CSCF est déterminé grâce au serveur I-CSCF. Il en informe alors le P-CSCF, de
manière que ce dernier puisse ultérieurement s’adresser directement au S-CSCF. Parallèlement, le
S-CSCF enregistre dans le HSS la position de l’abonné dans le réseau et indique au HSS son adresse,
afin qu’une entité cherchant à joindre l’abonné détermine le SCSCF auquel elle doit s’adresser.
Figure 4.16: Le Serving CSCF
Une fois désigné pour servir la session d’un utilisateur, le premier rôle du S-CSCF est de récupérer
auprès de la base HSS via le protocole Diameter, l’ensemble des paramètres des profils d’utilisa-
teur pour l’enregistrer, l’authentifier et vérifier ses droits d’accès. De plus, il met à jour, dans cette
même base HSS, l’état courant des sessions dont il a la charge, pour localiser l’utilisateur dans
ses déplacements, modifier ses préférences, mais aussi avoir l’historique de ses communications
utile pour la facturation. Remarquons que le terminal de l’utilisateur lui-même ne connaît jamais
l’adresse du I-CSCF, ni celle du S-CSCF. Ces informations sont masquées et ne sont connues que
du P-CSCF qui sollicite les serveurs concernés pour le terminal. Le S-CSCF est responsable des
traitements à réaliser pour l’utilisateur. Il est de plus l’entité chargée d’effectuer le routage des
appels. En particulier, si l’adresse de destination n’est pas une adresse SIP, mais, par exemple, un
numéro de téléphone standard, le serveur S-CSCF fournit les fonctionnalités de conversion pour
joindre les passerelles téléphoniques. Enfin, le S-CSCF est chargé d’assurer l’interaction entre le
client et les serveurs d’applications en commutant ses requêtes vers les serveurs adéquats.
iii)- MRF (Media Ressource Function)
• L’entité MRF 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 de et 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 a un fonctionnement semblable à celui de l’entité MCU (Multipoint Control Unit)
consacré à H.323. Comme ce dernier, le MRF se décompose en deux entités logiques :
— MRFC (Multimedia Resource Function Controller) : pour la partie signalisation, et plus

précisément la négociation des paramètres sollicités par chaque utilisateur pour la mise en œuvre
de la conférence.
— MRFP (Multimedia Resource Function Processor) : pour la partie traitement des flux
de données, c’est-à-dire l’application des demandes formulées par l’utilisateur dans le flux.
iv)- BGCF (Breakout Gateway Control Function)
• C’est un serveur SIP qui possède des fonctionnalités de routage lorsqu’il s’agit d’une session
initié par un terminal IMS et destiné à un utilisateur dans un réseau commuté circuit.
• Présente deux fonctionnalités essentielles :
— Si l’appareil qui se connecte est compatible avec le réseau du correspondant qu’il cherche
à joindre, le BGCF se charge de mettre en relation les deux entités.
— Sinon, le BGCF indique des passerelles spécifiques (de type MGCF) responsables d’ef-
fectuer la liaison et auxquelles le BGCF relaie toute la signalisation qu’il reçoit.
v)- IMS-MGW (IMS-Media GateWay)
• Assure le transport des flux de données d’un réseau IP vers un réseau RTC.
• Effectue la liaison entre un terminal du côté IP et son correspondant du côté RTC.
• Effectue le transcodage correspondant (d’un flux RTP vers un flux TDM).
• C’est donc une passerelle de flux de données multimédias qui convertit les flux de données mul-
timédias codés en RTP (dans le réseau IP) en flux de données multimédias codés en TDM (dans
le réseau RTC).
vi)- MGCF (Media Gateway Control Function)
• Agit au niveau de la signalisation, assure le passage du mode paquet (IP) au mode circuit (RTC).
• Convertir un message SIP qui provient du réseau IP en un message ISUP dans le réseau RTC.
• Le MGCF détermine le transcodage des flux de données et contrôle la passerelle de flux multi-
médias IMS-MGW.
• La communication entre le serveur MGCF et le serveur IMS- MGW se fait au moyen du protocole
de signalisation MEGACO/H.248.
• Le serveur MGCF doit également informer le serveur S-CSCF des messages de signalisation qu’il
génère pour que ce dernier connaisse les communications et opérations en cours.
vii)- SGW (Signaling Gateway)
• Comme la précédente, cette entité concerne la partie signalisation.
• Sa fonction est de transporter, un message de signalisation ISUP d’un transport SS7 vers SIG-
TRAN.
• Le serveur SGW joue le rôle de passerelle pour la signalisation ISUP.
• Il est en contact avec l’entité MGCF qui se charge de remplacer la signalisation ISUP en signa-
lisation SIP.
ix)- Serveurs d’applications
Les ASs (Application Servers) sont des entités SIP fournissant différents 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 : SIP AS (SIP Application Server),
IM-SSF (IP Multimedia-Service Switching Function) et OSA-SCS (Open Service Access-Service
Capability Server).
— SIP AS
Les serveurs SIP AS (SIP Application Server) permettent l’exécution des services nativement im-
plémentés pour fonctionner avec SIP. Les services les plus classiques sont généralement implémentés
au sein de ces serveurs.
— IM-SSF
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, il est
nécessaire d’avoir une passerelle, appelée IM-SSF (IP Multimedia-Service Switching Function), afin
de connecter l’abonné au serveur d’applications de son opérateur. IM-SSF permet ainsi d’accéder
à des services distants en réalisant l’interface entre, d’un côté, le serveur S-CSCF communiquant
avec le protocole SIP et, de l’autre côté, des serveurs distants en communiquant avec le protocole
CAP.
— OSA-SCS
Les serveurs OSA-SCS (Open Service Access-Service Capability Server) fournissent le moyen d’in-
teragir avec les serveurs d’applications OSA. OSA a été défini par le 3GPP et l’ETSI comme
une architecture de gestion des services dans un réseau téléphonique de troisième génération. Son
objectif est de proposer une vision très abstraite du réseau, n’imposant aucune architecture et
s’adaptant facilement, quelle que soit l’architecture considérée.
Pour cela, OSA fournit une API qui facilite le développement des services. Cette API, ouverte,
librement téléchargeable et indépendante des technologies utilisées, a été nommée OSA Parlay. Le
3GPP y fait référence, de manière plus neutre, sous le nom d’API OSA. Ces applications sont
accessibles à l’IMS grâce au serveur OSA-SCS.
x)- Les interfaces
IMS décompose l’infrastructure de réseau en des fonctions distinctes avec des interfaces standardi-
sées. Chaque interface est spécifiée comme un "point de référence", qui définit à la fois le protocole
et les fonctions opérées sur chaque interface (Figure 1.5). Cette section explique comment les enti-
tés du réseau décrites précédemment sont reliées les unes aux autres ainsi que le protocole utilisé
au niveau de chaque interface.
— Point de référence Gm
Le point de référence Gm relie l’UE à l’IMS. Il est utilisé pour le transport de tous les messages
SIP de signalisation entre l’UE et l’IMS. Les procédures dans le point de référence Gm peuvent
être divisées en trois grandes catégories : l’enregistrement, la session de contrôle et les transactions.
— Point de référence Mw
Mw est un point de référence basé sur SIP entre les différents CSCF. Les procédures décrites
dans ce point de référence peuvent être divisées en trois catégories principales : l’enregistrement,
le contrôle de session et les transactions.
— Point de référence ISC

ISC (IMS Service Control) est un point de référence pour l’envoi et la réception de messages
SIP entre S-CSCF et le serveur d’application. Les procédures ISC peuvent être divisées en deux
principales catégories de routage : les demandes SIP vers un AS et les requêtes SIP initiées par
AS.
— Point de référence Cx
Les données centralisées dans HSS doivent être utilisés par l’I-CSCF et S-CSCF lorsque l’utilisateur
reçoit des sessions. Par conséquent, il doit y avoir un point de référence entre le HSS et le CSCF.
Ce point de référence est appelé Cx et le protocole choisi est le diamètre.
— Point de référence Dx
Lorsque plusieurs HSS sont déployées séparément dans un réseau, aucune des deux entités suivantes
l’I-CSCF et le S-CSCF ne sait quel HSS doit contacter. Dans ce cas, il est nécessaire de contacter
le SLF en premier. A cet effet, le point de référence Dx a été introduit et utilisé en conjonction avec
le point de référence Cx. Le protocole utilisé dans ce point de référence est basé sur le protocole
Diameter.
TABLE 4.1 : Interfaces IMS
4.8 Gestion des identités
Comme dans tout type de réseau, il est impératif de pouvoir identifier les utilisateurs d’une
façon unique et faire en sorte qu’ils soient joignables de n’importe quel réseau. Dans IMS, il y a
un nouveau concept d’identification par rapport à ce qui se faisait dans les réseaux mobile tout
en restant compatible avec. Cette identification peut paraître un peu étrange et compliqué mais
elle fournit plus de flexibilité pour réaliser des nouveaux services. La technique d’identification est
prise du protocole SIP (Session Initiation Protocol).
4.8.1 Public User Identity
PUI est une adresse publique qui permet d’identifier un utilisateur. L’opérateur attribut une
ou plusieurs adresses publiques pour chaque utilisateur IMS. De cette manière, cette nouveauté
permet à l’utilisateur de séparer son identité personnelle, familiale et d’affaire pour générer des
services différents. L’identité publique de l’utilisateur est l’équivalent du MSISDN (Mobile Station
ISDN Number) en GSM, c’est donc une adresse de contacte qui permet de joindre un abonné et à
router les messages SIP. La Public User Identity peut être sous deux formats :
— SIP URI : sous la forme "sip : premier.dernier@opérateur.com". Il est aussi possible
d’inclure un numéro de téléphone dans une SIP URI qui sera sous le format : "sip :+33-961-007-
007@opérateur.com ; user = phone".
— TEL URL : permet de représenter un numéro de téléphone dans un format international "tel :
+33-961-007-007". Il est impossible de s’enregistrer avec un TEL URL, il faut toujours une SIP
URI pour se faire. Cela dit, le TEL URL est utilisé pour faire des appels entre le monde RTC
et le monde IMS. En effet, en RTC, les téléphones sont identifiés par des numéros et ne peuvent
composer que des numéros. L’opérateur IMS doit ainsi allouer à chaque utilisateur au moins une
SIP URI et un TEL URL.
4.8.2 Private User Identity
Chaque utilisateur se voit attribuer une identité privée pour chaque utilisateur. Cette identité
joue le même rôle que l’IMSI (International Mobile Subscriber Identity) en GSM ; elle permet en
effet l’authentification et l’enregistrement de l’abonné. La PUI est en principe stockée dans la carte
à puce et prend le format d’un "Network Access Identifier" : "username@opérateur.com".
Figure 4.17: Identités IMS

4.8.3 Relations entre Public et Private User Identity
Dans le cas GSM/UMTS, la carte à puce stocke l’identité privée et au moins une identité pu-
blique. Le HSS contient pour chaque utilisateur son identité privée et la collection d’identités pu-
bliques qui lui sont attribuées. Notons que dans le cas où l’utilisateur utilise une carte GSM/UMTS
qui ne contient pas ces informations, le terminal est capable de les construire à travers l’IMSI. La
relation entre l’utilisateur IMS et ces identités dans la Release 5 est montré par la figure 4.18 :
Figure 4.18: Relation des identités des utilisateurs privés et publics dans 3GPP R5
Dans l’IMS 3GPP Release 6, un abonné peut avoir plusieurs identités privées comme illustré dans
la figure 4.19. Dans le cas de l’UMTS, une seule identité privée peut être contenu dans la carte
à puce, même si l’utilisateur peut avoir plusieurs cartes contenant chacune une identité privée
différente. Il est encore possible d’utiliser simultanément la même identité publique avec plusieurs
identités privées (deux cartes insérées dans deux terminaux différents).
Figure 4.19: Relation des identités des utilisateurs privés et publics dans 3GPP R6
4.9 Carte USIM et ISIM
Dans chaque terminal, il y a une carte à puce appelée UICC (Universal Integrated Circuit
Card). L’UICC est utilisé pour stocker des informations telles que l’état d’enregistrement, les clefs
d’authentifications, les messages et un carnet d’adresses. L’UICC contient plusieurs applications
logiques qui peuvent être : la SIM, l’USIM et l’ISIM.
Figure 4.20: SIM, USIM et ISIM dans la carte UICC des terminaux IMS 3GPP
4.9.1 SIM (Subscriber Identify Module)
• Spécifiée dans les documents 3GPP TS 11.11 et 3GPP TS 51.011 est bien connue pour son
usage massif et généralisé dans les réseaux GSM.
• Elle fournit, en particulier, des informations relatives au réseau de l’utilisateur :
— son identité,
— ses préférences,
— ses paramètres d’authentification et de cryptage,
— ainsi que des informations de stockage (typiquement la sauvegarde de SMS ou de son

carnet d’adresses).
4.9.2 USIM (Universal Subscriber Identity Module)
USIM est utilisée pour l’accès au réseau UMTS en mode circuit ou paquet. Elle contient les
paramètres suivants :
• IMSI : comme en GSM, elle permet d’identifier et authentifier l’utilisateur. La Private user Iden-
tity est l’équivalent à l’IMSI pour IMS.
• MSISDN : contient une ou plusieurs numéros de téléphone pour l’utilisateur. La Public User
Identity est l’équivalent au MSISDN pour IMS.
• CK (Ciphering Key) et IK (Integrity Key) : les clefs de chiffrement et d’intégrité utilisées pour
la sécurité de l’information sur l’interface radio.
• Long term secret : secret utilisé pour authentifier l’utilisateur et pour générer les clefs de chif-
frement et d’intégrité utilisées entre le terminal et le réseau.
• SMS : Dans ce champ sont stockés les messages courts (reçu et envoyé avec leur état).
• SMS parameters : paramètres de configuration du service SMS (exemple : adresse du SMS cen-
ter).
• MMS user connectivity parameters : contient les paramètres de configuration du service MMS
(exemple : adresse du MMS server et du MMS gateway).
• MMS user preferences : contient les préférences de l’utilisateur sur le service MMS comme le
drapeau de rapport d’expédition.
4.9.3 ISIM (IMS Subscriber Identity Module)
ISIM contient les paramètres utilisés pour l’identification et l’authentification de l’utilisateur

ainsi que la configuration du terminal IMS. ISIM peut coexister simultanément avec une USIM ou
une SIM. Les paramètres essentiels contenus dans une ISIM sont :
• Private User Identity : contient une ou plusieurs identités d’usager privées, de type NAI.
• Public User Identity : contient une ou plusieurs identités d’usager publiques, de type URI SIP
ou URL tel.
• Home Network Domain URI : SIP URI du réseau nominal de l’utilisateur qui est unique dans la
carte.
• Long-term secret : secret utilisé pour authentifier l’utilisateur et pour générer les clefs de chif-
frement et d’intégrité utilisées entre le terminal et le réseau. Les messages SIP envoyés entre le
terminal et le P-CSCF sont chiffrés et protégés par ces clefs de chiffrement et d’intégrité.
4.10 Protocoles utilisés dans l’IMS
• SIP est le protocole fédérateur de l’architecture IMS, son utilisation implique celle des proto-
coles associés :
— SDP, pour la description des sessions,
— RTP/RTCP, pour le transport en temps réel des flux de données multimédias.

• Diameter, décrit dans la RFC 3588 de l’IETF, est un protocole employé pour la sécurisation
des communications. Diameter est également présent dans IPsec et TLS.
• COPS (Common Open Policy Service) est un protocole flexible permettant aux opérateurs de
garantir une qualité de service dans une architecture IMS.
4.10.1 Les extensions du protocole SIP dans l’IMS
• IMS reprends le protocole SIP dans sa syntaxe et dans son fonctionnement.

• Il définit un ensemble d’extensions supplémentaire dans les en- têtes du protocole SIP pour
répondre à quelques besoins spécifiques.
• Ces extensions sont optionnelles pour le protocole SIP ; elles sont préfixées par la lettre P pour
indiquer qu’elles sont privées (en anglais private), suivie d’un tiret.
• Elles adoptent la même syntaxe que les en-têtes conventionnels, à savoir le format suivant :
nom_en_tête :valeur_en_tête
TABLE 4.2 : En-têtes SIP supplémentaires pour l’IMS
4.10.2 Les commandes DIAMETER
• Le protocole Diameter est utilisé dans l’IMS pour l’authentification, l’autorisation et la jour-
nalisation des activités de l’utilisateur (AAA, pour Authentication, Authorization, Accouting).
• Spécifié dans la RFC 3588 de l’IETF, il normalise un certain nombre de commandes pour per-
mettre son utilisation.
• La liste des commandes qui sont définies sur l’interface de commutation nommée Cx, qui est
l’interface de communication la plus utilisée, entre la base de données HSS et les serveurs I-CSCF
et S-CSCF.
TABLE 4.3 : Commandes sur l’interface Cx
4.11 Procédure générale pour obtenir le service IMS
La procédure d’enregistrement se fait en plusieurs étapes :

1. Attachement au réseau UMTS.
2. Activation d’un Contexte PDP, avec obtention d’une adresse IPv6 et d’un APN qui donne une
connexion vers le réseau IMS à travers une connectivité IPv6.
3. Découvert du P-CSCF.
4. Enregistrement IMS.
5. Souscription à l’état d’enregistrement du mobile "reg Event State".
Figure 4.21: Procédure générale pour obtenir le service IMS
4.11.1 Enregistrement basé sur ISIM/USIM
1. Le terminal envoie un message REGISTER au serveur P-CSCF comprenant les informations :

Public User Identity, Private User Identity.
2. P-CSCF détermine, sur la base du Home Network Domain Name, le point d’accès au réseau
d’origine. Il complète le message REGISTER avec les coordonnées du réseau visité, puis l’envoie
au serveur I-CSCF correspondant.
3-4. I-CSCF transmet la demande au HSS qui contrôle si l’usager n’est pas déjà enregistré et
s’il est autorisé à être enregistré dans le réseau visité.
5. HSS/UPSF livre, dans sa réponse, soit l’adresse du serveur S-CSCF à utiliser, soit les S-CSCF
capabilities permettant à I-CSCF de déterminer un S-CSCF adéquat.
6. I-CSCF transmet maintenant les indications d’enregistrement au serveur S-CSCF choisi.
7. Par l’envoi du message MAR (Media Authorization Request), S-CSCF requiert de la part du
serveur HSS, les données d’authentification de l’usager. Dans le même message, S-CSCF transmet
ses coordonnées pour qu’elles soient enregistrées, afin que toute nouvelle requête d’enregistrement
de cet usager soit faite auprès du même serveur S-CSCF.
8. HSS enregistre l’URI du serveur S-CSCF et transmet, dans le message MAA (Media Autho-
rization Answer), un ou plusieurs vecteurs d’authentification de l’usager.
9-11. S-CSCF insère, dans le message de réponse au terminal 401 Unauthorized, un défi (Chal-
lenge) auquel le terminal devra livrer une réponse valide.
12-13. Dans un nouveau message REGISTER, le terminal livre la réponse au défi reçu (Cre-
dentials). Le calcul est effectué à partir du Long-term Secret enregistré dans la carte à puce du
terminal.
14-15. I-CSCF doit contrôler les droits d’accès avant d’acheminer la requête plus loin. Pour des
raisons de répartition de charge dans le réseau NGN, le serveur I- CSCF peut être différent que
lors de l’envoi du premier message REGISTER.
16. Le message REGISTER contenant la réponse au défi est acheminé vers le serveur S-CSCF.
17-19. Après avoir contrôlé que la réponse au défi soit correcte, S-CSCF enregistre l’usager,
puis en informe HSS/USPF et charge le profil de l’usager depuis la base de données HSS. Ce profil
renferme, entre autres, les informations de routage et les critères de filtrage initial permettant
d’acheminer les futures requêtes SIP vers les serveurs d’applications auprès desquels l’usager aurait
contracté des abonnements. S-CSCF initie, le cas échéant, les procédures correspondantes pour la
commande des applications. Dès à présent, le serveur S-CSCF connaît le profil et l’URI de contact
de l’usager et peut acheminer les futurs appels entrants.
20. P-CSCF confirme l’acceptation de la requête d’enregistrement par un message 200 OK qui
contient la liste des URI utilisables par l’usager et celle des serveurs qui lui sont attribués.
21. I-CSCF achemine le message REGISTER, puis efface les informations relatives à cette
transaction.
22. A la réception du message REGISTER, le serveur P-CSCF va mettre en place une association
IPsec avec le terminal de l’usager. Ainsi, toute nouvelle transaction entre le terminal et l’entrée
dans le réseau sera protégée.
4.11.2 Interfaces vers la base des abonnés
• L’authentification et l’autorisation se font en lien étroit avec la base des abonnés (briques SLF
et HSS).
• Utilisation du protocole Diameter sur les interfaces Cx et Dx.
• Différentes opérations :
— Vérifier l’autorisation d’accès
— Récupérer le profil de l’utilisateur
— Authentifier l’utilisateur
— Associer un lien sécurisé à un abonné

Enregistrement d’un terminal IMS
Figure 4.22: Enregistrement d’un terminal IMS

Les étapes d’enregistrement d’un terminal IMS
Figure 4.23: Les étapes d’enregistrement
Exemple d’un appel entre deux réseaux
Figure 4.24: Appel entre réseau
Exemple de communication
1. L’appel vocal vient d’Alice et est tout d’abord traité par son réseau IMS, X. C’est le P-CSCF qui
reçoit la signalisation d’Alice. Il extrait la demande d’Alice et vérifie son origine et sa conformité.
2. Le P-CSCF transmet l’appel au S-CSCF d’Alice, situé dans le réseau mère X.
3. Le S-CSCF traite sa requête, exécute le contrôle du service qui peut inclure des interactions
avec le serveur d’applications et détermine le point d’entrée de l’opérateur de la maison d’Alice en
se basant sur l’identité d’Alice incluse dans la demande SIP INVITE.
4. Le S-CSCF transmet l’appel à l’I-CSCF du réseau Y.

5. L’I-CSCF interroge le HSS du réseau Y pour déterminer le S-CSCF et lui transmet la demande
d’appel.
6. Le S-CSCF du réseau Y prend en charge le traitement de la session, interroge le serveur d’ap-
plications pour les services de terminaison.
7. Le S-CSCF transmet l’appel au P-CSCF du réseau Y assigné pour Bob via le réseau Z (UMTS
/ GPRS) et une négociation peut être entamée entre les deux UE pour ouvrir la communication.
Figure 4.25: Exemple de communication
4.12 Sécurité dans l’IMS
Sans doute, la convergence des réseaux voix et données est une grande réussite pour maintenir
une plateforme de communication unique pour tous. Cela dit, le plus grand défi est de maintenir
un niveau adéquat de sécurité assurant l’intégrité et la confidentialité des données ainsi que la
disponibilité des services.
L’IMS est en particulier vulnérable aux différents attaques "peer-to-peer" vu l’utilisation du pro-
tocole SIP pour la signalisation qui est une architecture ouverte.
Les menaces dans l’IMS comprennent également des attaques par inondations, qui rendent les
ressources réseau occupées. Les serveurs d’applications IMS, qui fournissent des services à valeur
ajoutée, sont également des cibles précieuses pour les intrus. En raison de la nature " textbased
" de SIP, les ASs sont vulnérables aux attaques de type usurpation (spoofing) et falsification de
message. Enfin, les intrus peuvent lancer un déni de service (DoS) contre des applications installées
sur l’AS.
4.12.1 Défis de sécurité en IMS et attaques potentielles
Les problèmes de sécurité face à IMS sont des menaces venant de différents protocoles par
exemple, les attaques visant la signalisation SIP, les attaques RTP des médias, et les attaques du
domaine IP.
La Recommandation UIT-T X.805 peut être utilisé pour augmenter les spécifications de sécurité
et donc fournir une sécurité globale de bout-en-bout au niveau du réseau IMS en incluant le plan
de contrôle, le plan de gestion, ainsi que les plans de l’utilisateur final. La Recommandation UIT-T
X.805 définit huit mesures de sécurité pour se protéger contre les différentes menaces :
Contrôle d’accès ; Authentification ; Non-répudiation ; Confidentialité des données ; Sécurité de la
communication ; Intégrité des données et la disponibilité. Le tableau suivant fournit ces dimensions
Figure 4.26: Menaces potentielles dans IMS

de sécurité avec les principales menaces, relatives au réseau IMS, qui les atteignent.
TABLE 4.4 : Les dimensions de sécurité avec les principales menaces
Les menaces de sécurité IMS sont classées en trois catégories. Tout d’abord, les attaques com-
munes aux applications sur le réseau Internet telles que les attaques par rejeu, le déni de service,
l’usurpation (spoofing), le reniflage (sniffing) et autres attaques par interception. Il y a ensuite des
attaques spécifiques à la nature du protocole SIP (à la couche application). De par la structure de
ses messages, SIP est vulnérable à certaines attaques telles que de fausses inscriptions ou termi-
naisons de sessions. Les principales menaces sont :
Usurpation (Spoofing) : attaque contre l’authentification
Le nœud malveillant se présente dans le réseau et intercepte le trafic, ce qui permet aux attaquants
d’altérer les messages.
Déni de service (DoS) : attaque contre la disponibilité
Des signaux radio et des inondations par les demandes d’authentification au P-CSCF et d’autres
dispositifs. Par exemple, lors d’une attaque d’inondations REGISTER, l’attaquant envoie de nom-
breuses demandes REGISTER au P-CSCF avec des adresses sources fausses ou falsifiées (SIP URI).
Dans le cas des inondations REGISTER distribués, l’attaquant génère de multiples demandes RE-
GISTER avec différentes adresses source usurpées et truquées pour submerger les ressources IMS.
Il provoque ainsi la chute des ressources IMS et les utilisateurs légitimes ne peuvent pas obtenir
des services.
Phishing : attaque contre l’authentification, la confidentialité et l’intégrité
Les attaquants peuvent usurper les identifiants utilisateur dans leurs connexions avec le serveur
SIP pour voler des informations ou effectuer des actions malveillantes. Par exemple, l’attaquant
peut enregistrer son proxy SIP, avec un nom semblable à un organisme de la victime, sur le site
web proxy SIP de localisation. Lors du lancement d’une session SIP, la victime sera en réalité en
contact avec l’attaquant du serveur SIP (au lieu de son serveur SIP légitime). L’attaquant sera
alors en mesure d’obtenir des informations sur les victimes. Par ailleurs, l’attaquant peut usurper
l’identité d’une entité SIP, par exemple l’identité de l’organisation de confiance et appeler la vic-
time pour lui demander des informations afin de commettre acte un malveillant.
Fin de session : attaque contre la disponibilité du service en cours
Un attaquant pourrait utiliser la requête BYE pour mettre fin à une session. Le pirate prétend
utiliser UE2 et envoie un faux message BYE du P-CSCF au UE1. UE1 arrête ainsi d’envoyer le flux
RTP immédiatement, tandis qu’UE2 continue à envoyer des paquets RTP à UE1. Pour lancer ce
genre d’attaque, l’attaquant a besoin de connaitre tous les paramètres de session. Ces informations
peuvent être obtenues en sniffant le réseau ou en effectuant une attaque man-in the-middle pour
insérer une requête BYE dans la session comme illustré en figure.
Figure 4.27: Attack fin de session
Attaque CANCEL : attaque contre la disponibilité du service en cours

Cette attaque met fin à une demande en attente. L’attaquant pourrait utiliser la méthode CAN-
CEL pour annuler une demande INVITE générée par un utilisateur légitime. Avant que la réponse
finale soit générée pour une demande INVITE, l’attaquant envoie un " faux " message CANCEL
au P-CSCF tout en laissant croire qu’il provient d’un utilisateur légitime. Le noyau IMS accuse la
réception du message CANCEL et cesse le traitement de la demande INVITE.
Attaque Re-INVITE : attaque contre la disponibilité du service en cours
La requête INVITE établit une session ou un dialogue entre deux utilisateurs (UE). L’objectif du
message re-INVITE est de modifier les informations de la session actuelle, par exemple, en chan-
geant les adresses ou les ports, l’ajout d’un flux de support, ou la suppression d’un flux de support.
Par conséquent, l’attaquant pourrait lancer une attaque DoS en envoyant un message re-INVITE
forgé pour modifier la session.
Deviner le mot de passe : attaque contre l’authentification
Ressemble à l’attaque de détournement de session avec l’objectif d’obtenir des informations sur la
session de l’utilisateur. Même si un intrus n’est pas capable de briser le processus d’authentification
IMS, cette attaque pourrait être lancée pour une mauvaise utilisation des comptes d’utilisateurs
légitimes. L’intrus lance cette attaque en envoyant de nombreuses demandes REGISTER au P-
CSCF et reçoit des messages " 401- unauthorized " de réseau IMS. Si l’attaque réussie, l’attaquant
obtient une réponse " 200 OK ".
Voice trapping : attaque contre la confidentialité
Comme le trafic de voix sur IP est envoyé sur le réseau IP sans aucun chiffrement, l’espionnage
des paquets est ainsi possible, en particulier dans les réseaux sans fil, où il est plus facile de piéger
les données (par rapport au réseau téléphonique traditionnel qui est point à point, non diffusé).
Vol de medias : attaque contre non-répudiation
Dans un environnement de raccordement fixe, une fois la session est établie entre deux terminaux,
les flux de médias peuvent être échangés directement entre les deux terminaux (sans passer par
les CSCFs). Dans un fonctionnement normal, lorsqu’un terminal envoie ou reçoit une requête SIP
BYE, il va libérer les médias actifs. Mais si on modifie les deux terminaux de tel sorte que quand
ils reçoivent une requête SIP BYE ils ne libèrent pas les canaux médias. De cette façon, lorsqu’un
des deux terminaux envoie la requête SIP BYE aux CSCF, CSCF pense que la session terminée et
va arrêter la comptabilité. Les deux terminaux peuvent donc continuer la communication, et ainsi
voler des ressources médias. Un exemple est illustré en Figure :
Figure 4.28: Attack Vol de média
4.12.2 Quelques notions
La zone de confiance
La zone de confiance est celle dans laquelle les systèmes et ressources du NGN sont hébergés et
sous le contrôle de l’opérateur. Aucun contact n’est possible avec les équipements de l’usager ou
ceux d’un autre réseau. Cette zone est protégée par diverses mesures, par exemple :
• Sécurisation physique des éléments du réseau,
• Durcissement des systèmes visant à réduire les vulnérabilités et à diminuer les risques opération-
nels,
• Mise en œuvre d’une signalisation et d’une gestion sûres,
• Séparation des réseaux virtuels privés entre zone de confiance et zone vulnérable.
La zone de confiance vulnérable
Dans la zone de confiance vulnérable, les équipements sont exploités par l’opérateur du NGN et
sont contrôlés soit par l’opérateur lui-même, soit par l’usager. Leur rôle principal est de protéger les
systèmes et ressources du NGN situés dans la zone de confiance. En plus des mesures de protection
appliquées à la zone de confiance, l’utilisation de firewalls et de passerelles de filtrage ainsi que la
mise en place de fonctionnalités de type fusible sont prévues.
La zone vulnérable
La zone vulnérable regroupe les systèmes et les ressources situées chez les usagers et chez les opéra-
teurs partenaires, qui sont aussi des concurrents. Il s’agit d’infrastructures qui ne sont ni exploitées,
ni hébergées par l’opérateur en propre.
Figure 4.29: Différentes zones de sécurité
Sécurité de l’accès NGN

Pour les équipements mobiles (téléphones cellulaires, équipements terminaux mobiles embarqués),
le système de transmission est protégé par cryptage. La protection des flux de médias est inhérente
à l’application.
Figure 4.30: Sécurité de l’accès NGN
4.12.3 Mécanisme de sécurité en IMS
La sécurité IMS est divisée en sécurité des accès et sécurité du réseau :

• La sécurité des accès comprend l’authentification mutuelle des utilisateurs et du réseau, ainsi
que la protection du trafic entre le terminal et le réseau IMS (P-CSCF).

• La sécurité du réseau traite de la protection du trafic entre les nœuds du réseau, qui peuvent
d’ailleurs appartenir au même opérateur ou à différents opérateurs.
• Authentification.
Le mécanisme de base utilisé pour l’authentification dans IMS est IMS-AKA (Authentication and
Key Agreement). Celui-ci repose sur l’utilisation d’un secret partagé entre l’utilisateur (sur l’ISIM
ou à défaut l’USIM) et le réseau IMS (au niveau du HSS).
Confidentialité et intégrité des données
Confidentialité et intégrité des données assurées aussi bien au niveau de l’accès d’usager que de
l’interconnexion entre réseaux.
Figure 4.31: Sécurité de la communication
4.13 Technologies pour le développement de services télé-
com dans IMS
4.13.1 JAIN SIP
• Java APIs for Intelligent Networks–Session Initiation Protocol.

• Interface Java standard pour les stacks protocolaires SIP.
• Ensemble d’interfaces permettant de développer rapidement de nouveaux produits/services de

télécoms de la prochaine génération indépendamment du matériel utilisé.
• Spécifié dans la JSR-000032.
Architecture
• Listening point : Interfaçage de la stack en Java.
• SIP Provider : Gestion des transactions client et serveur, réponse stateless protocolaires.
• SIP Listener : Traitement des requêtes et des réponses en fonction de l’application.
Objectifs
• Portabilité des services (Write Once, Run anywhere)
• Abstraction des réseaux pour les applications : (Any network)
• réseaux paquets (IP), réseaux circuits (PSTN) et réseaux sans fils
• Accès réseau sécurisé : ouverture contrôlée et sécurisée des capacités du réseaux aux applications
Java
Vision de JAIN
• Faire évoluer le domaine des télécommunications qui repose sur une architecture de boites ma-
térielles et logicielles propriétaires vers une architecture ouverte où les services peuvent être rapi-
dement créés et déployés, peu importe la plateforme et le réseau.
Figure 4.32: Architecture de JAIN SIP

4.13.2 JSLEE
• Java APIs for Intelligent Networks–Service Logic Exection Environment Interface.

• JSLEE est un environnement d’exécution d’applications évènementielles.
• Conçu pour assurer une grande rapidité d’exécution, des retards faibles et une haute disponibilité.
• Spécifié dans la JSR 22.
Architecture
• RA : Réception des évènements (messages SIP, évènement de facturation...).
• Event Router : distribution de l’évènement vers différents SBB enregistrés.
• SBB : brique fonctionnelle élémentaire.
Figure 4.33: Architecture de JSLEE
4.13.3 Les SIP Servlets
• Les SIP Servlets sont des composants Java gérés par un conteneur de SIP Servlets permettant
de traiter de la signalisation SIP.
• Conçu comme une extension du modèle des servlets HTTP.
• Spécifié dans la JSR 116 (v 1.0) et la JSR 289 (v 1.1, non finalisée).
• API pour programmer des servlets SIP.
Figure 4.34: Architecture de SIP Servlets
A noter
• Les SIP servlets sont différentes des servlets HTTP par leur capacité à émettre des requêtes.
• Proximité des modèles des servlets HTTP et SIP–>faciliter le développement d’applications
convergents web-SIP.
Exemple de SIP Servlet
Figure 4.35: Exemple de SIP Servlet
4.13.4 Implémentations existantes
Stack JAIN par le NIST

• Implémentation de référence de JAIN-SIP.
• Amélioration récente dans le cadre des travaux du projet Mobicents sur la haute disponibilité.
Figure 4.36: JAIN SIP
Mobicents
• Initialement, implémentation open source des JSLEE basée sur Jboss.
• Depuis, implémente aussi les SIP Servlets (v 1.1) en s’appuyant sur Tomcat.
• Support de protocoles multiples par l’utilisation des ressources adaptors.
Figure 4.37: Mobicents
Sailfin
• Sous-projet de Glassfish de Sun, lancé en Mai 2007.
• Conteneur de SIP Servlets contribué par Ericsson.
• Implémente les SIP Servlets v1.1 et les HTTP servlets uniquement–>appel à d’autres mécanismes
pour l’interconnexion avec d’autres protocoles.
Figure 4.38: SailFin
Cipango • Pendant Open Source du produit Nexpresso de Nexcom.

• Implémentation des SIP Servlets 1.1 basée sur Jesy6.
• Réécriture de la stack SIP–>Non-basé sur JAIN SIP.
Figure 4.39: Cipango
4.13.5 Voice XML
• Langage de développement d’application vocale.

• Basé sur XML.
• Comparable au HTML pour le web Services vocaux relativement statiques.
• Abstraction des interactions bas niveau par le navigateur VXML.
• Une page VXML comprends différents états. Le résultat du parcours est remonté au serveur.
• Une page représente un dialogue, qui se parcours par le biais de formulaires (entrée libre) ou
menus.
Figure 4.40: Exemple d’un programme XML

4.13.6 Call Control XML
• Contrôle plus dynamique de l’appel téléphonique qu’en VXML.

• Basé sur XML.
• Évènementiel.
• Possibilité de contrôle d’appel multi-partie.
• Possibilité d’effectuer des appels sortants à partir du script.
Architecture de CCXML
Une application CCXML comprend plusieurs documents, et manipule 4 types d’objets :
• Session : instance d’exécution d’une application.
• Connection : connexion téléphonique, associée à une session.
• Conference : ressource destinée à mixer les médias venus de plusieurs sources.
• Dialog : similaire à VXML.
Figure 4.41: Exemple d’un programme CCXML

4.13.7 State Chart XML
• Modèle qui abstrait le VXML et le SCXML.
Figure 4.42: Chart XML
4.13.8 Technologies de développement alternatives
Adhearsion
• Framework de développement d’application télécom.
• Basé sur l’utilisation de Ruby on Rails.
Figure 4.43: Adhearsion
Echarts
• Langage de programmation de machine à état pour des systèmes évènementiels.
• Basé sur les statecharts UML, similaire à SCXML.
Figure 4.44: Echarts
Scripts Asterisk
• Langage spécifique à l’utilisation du PBX Open Source.
Figure 4.45: Asterisk

Bibliographie
[1] Régulation des Technologies de l’Information et de la Communication, COOPEDIA, 30 mai
2012.
[2] Guy Pujolle, "Les réseaux", Groupe Eyrolles, Edition 2014, 8ème édition, 1 février 2014,
SBN13 : 978-2-212-13852-8.
[3] J. Horrocks, "NGN and Convergence Models, Myths, and Muddle", Forum de prévisibilité
de l’OCDE, 3 octobre 2006.
[4] Etude technique, économique et réglementaire de l’évolution vers les réseaux de nouvelle
génération (NGN, Next Generation Networks), Arcome, Septembre 2006.
[5] QUESTION 19-1/2 : Stratégie de passage des réseaux existants aux réseaux de la prochaine
génération (NGN) pour les pays en développement, 4e PÉRIODE D’ÉTUDES (2006-2010),
UIT.
[6] Réseaux IP de prochaine génération NGN - IMS – TISPAN, Antoine Delley, Oct 03, 2013.
[7] Architectures et services des nouvelles Générations des Réseaux, Pr. S. EL KAFHALI & Pr.
S. MOUNIR, ENSA de Khouribga, 2017-2018.
[8] Claude Servin, " RÉSEAUX & TÉLÉCOMS",

c Dunod, Paris, 2003, 2006 , ISBN : 2 10
049148 2.
[9] Guy Pujolle, "Les réseaux",

c Groupe Eyrolles, Edition 2014, 8ème édition, I février 201 4,
SBN13 : 978-2-212-13852-8.
[10] Laurent Ouakil et Guy Pujolle , " Téléphonie sur IP ",

c Groupe Eyrolles, juin 2008, 2ème
édition , ISBN : 978-2-212-12359-3.
[11] Pierre Ledru ," Téléphonie sur IP, TolP : vers la convergence des réseaux dédiés, voix-vidéo-
données ", ENI : DPTOIP, novembre 2011, ISBN : 978- 2-7460-7004-2.
174
Références 175
[12] Bruns Xavier, Salque Franck, " La ToIP : qui fait quoi, pour qui et comment ? " , 2004-2005.
[13] Jean-Pierre Lagasse, " Téléphonie sur IP en entreprise : Evolution ou révolution dans le
transport de la voix et accès à de nouvelles applications " , Mai 2006.
[14] The 3G IP Multimedia Subsystem (IMS) : Merging the Internet and the Cellular Worlds
Gonzalo Camarillo, Miguel-Angel García-Martín (John Wiley & Sons, 2006, ISBN : 0-470-
01818-6).
[15] The FOKUS Open IMS Core - A Global IMS Reference Implementation Peter Weik Dragos
Vingarzan, Thomas Magedanz.
[16] IP Multimedia Subsystem (IMS) Handbook Syed A. Ahson, Mohammad Ilyas (CRC Press
Taylor & Francis Group, 2009, ISBN-13 : 978-1-4200-6459-9).
[17] The IMS : IP Multimedia Concepts and Services Miikka Poikselkä, Georg Mayer, Hisham
Khartabil, Aki Niemi (John Wiley & Sons, ISBN : 0-470-01906-9).
[18] T. Ozcelebi, I. Radovanovic, J. Lukkien, Real-Time Resource Availability Signalling in IMS-

Based Networks, in : Wireless Communications, Networking and Mobile Computing, 2007.
[19] H. Oumina, D. Ranc, Towards a Real Time Charging Framework for Complex Applications in
3GPP IP Multimedia System (IMS) Environment, in : Next Generation Mobile Applications,
Services and Technologies, 2007.
[20] Réseaux IP de prochaine génération NGN - IMS - TISPAN, Antoine Delley, Oct 03, 2013.

Cours - 108

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours - 108

Uploaded by

Copyright:

Available Formats

Université Sultan Moulay Slimane

Ecole Nationale des Sciences Appliquées

Nouvelles Générations des Réseaux

Filière : Génie Réseaux & Télécommunications

Année universitaire 2018-2019

— Présenter les nouvelles générations de réseaux dites

NGN orientées services et non plus infrastructures ré-

seaux en traitant l’ensemble des composantes formant

— Présenter le concept de l’architecture IMS que ce soit

d’un point de vue global que d’un point de vue fonction-

nel en définissant les éléments principaux de l’architec-

3GPP 3rd Generation Partnership Project

NGN Next Generation Network

Liste des abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Table des matières . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Table des figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Chapitre 1: Convergence et NGN : points essentiels . . . . . . . . . . . . . . . . . . . . . 13

1.6.2 Les technologies d’accès fixe sans fil/radio . . . . . . . . . . . . . . . . . . . 34

Chapitre 2: Téléphonie sur IP et migration NGN du cœur de réseau

2.1 Description d’un réseau téléphonique traditionnel . . . . . . . . . . . . . . . . . . . 38

Chapitre 3: Les familles de protocoles d’un réseau NGN . . . . . . . . . . . . . . . . 93

Chapitre 4: Concepts et Architecture IMS (IP Multimedia Subsys-

4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

4.8.1 Public User Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

1.1 Réseau multi-service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.1 Architecture d’un réseau RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.24 L’architecture MGCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.1 Les tâches principales de H.248/Megaco . . . . . . . . . . . . . . . . . . . . . . . . 94

4.1 IMS connectant à plusieurs réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

4.4 Core IMS dans 3GPP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

4.39 Cipango . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

1.1.1 Problématique des réseaux d’aujourd’hui

— Infrastructures séparées pour voix, données et vidéo ;

— Difficulté pour intégrer les applications ;

a) Limitations des architectures actuelles

— Le réseau GSM/GPRS pour les communications avec les téléphones mobiles,

Figure 1.1: Réseau multi-service

— Le réseau câblé pour la diffusion TV,

— Le réseau RTC/RNIS pour les communications téléphoniques "fixes",

— Le réseau Internet sur IP.

— La capacité de transmission est utilisée et redistribuée de manière inefficace,

— Les coûts d’opération augmentent, Investissements multiples,

— Existence de protocoles et d’architectures propriétaires.

— Réaliser, à travers la nouvelle solution, le support de multiples services (téléphonie,

1.1.2 Pourquoi le NGN ?

— La Souplesse pour l’élaboration et l’offre de services,

— La Réduction de coût prévisibles du fait du partage de l’infrastructure et des systèmes,

— La Simplification de l’exploitation et de la maintenance, d’où une diminution des dépenses

— L’utilisation d’interfaces ouvertes entraîne : Un Déploiement rapide des services et applica-

1.1.3 Travaux de standardisation pour les NGN

Plusieurs organismes de standardisation interviennent dans la normalisation des NGN :

— 3GPP (3rd Generation Partnership Project ),

— IETF (Internet Engineering Task Force ),

— ETSI (European Telecommunications Standards Institute),

— ITU-T(International Telecommunication Union Telecommunication Standardization Sector),

— ATIS (Alliance for Telecommunications Industry Solutions),

— IEEE (Institute of Electrical and Electronics Engineers),

Ainsi qu’une force commune de travail entre :

— TTA (Telecommunications Technology Association) en Corée,

— CCSA (China Communications Standards Association ) en Chine,

— TTC (Telecommunication Technology Committee) en Japon.

— Produit la plupart des nouveaux standards d’Internet.

— Organisé en des groupes de travail (Working Group).