Domaine IP multimédia

Architecture, fonctionnalités
et procédures essentielles de l’IMS

par Sandrine LATASTE

Architecte de réseaux innovants
France Telecom Recherche & Développement

1. Pourquoi l’IP multimédia ....................................................................... TE 7 512 - 2

2. Architecture IMS ...................................................................................... — 3
2.1 Principes d’architecture............................................................................... — 3
2.2 Architecture IMS .......................................................................................... — 3
2.3 Souscriptions IMS et identification de l’utilisateur ................................... — 5
3. Procédures réseau dans l’IMS (en Rel-5/Rel-6) ................................. — 6
3.1 Vue générale des procédures ..................................................................... — 6
3.2 Support du roaming dans l’IMS ................................................................. — 7
3.3 Découverte du point d’entrée dans l’IMS .................................................. — 7
3.4 Enregistrement dans l’IMS.......................................................................... — 7
3.5 Établissement de session multimédia ....................................................... — 10
3.6 Modification de session multimédia .......................................................... — 13
3.7 Relâche de session multimédia .................................................................. — 16
3.8 Fin d’enregistrement ................................................................................... — 18
3.9 Gestion de la QoS dans l’IMS ..................................................................... — 19
4. Sécurité dans l’IMS .................................................................................. — 22
4.1 Authentification............................................................................................ — 22
4.2 Tunnel IPSec entre terminal et P-CSCF...................................................... — 23
4.3 Passerelles de sécurité ................................................................................ — 23
4.4 Fonction I-CSCF(THIG)................................................................................. — 23
5. Conclusion ................................................................................................. — 23

e domaine IP multimédia fait l’objet d’une standardisation internationale au

L sein de l’organisme 3GPP. Cet organisme est aussi à l’origine du standard
du réseau mobile de troisième génération (UMTS).
Le domaine IP multimédia est conçu pour rendre des services de type IP mul-
timédia en réutilisant les services déjà existants au sein d’Internet (sans
11 - 2008

nécessairement développer des applications spécifiques au 3GPP). L’idée

générale est de fournir un réseau support pour permettre le développement de
services de manière indépendante du réseau et aussi pour permettre la créa-
tion et l’implémentation rapide de services utilisant les capacités de l’IMS. Il
doit être noté que les opérateurs de télécommunications, les fournisseurs de
contenu multimédia, les sociétés informatiques ou les fournisseurs d’accès
TE 7 512

Internet sont candidats au développement de services IMS.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 1
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

Glossaire Glossaire (suite)

2G/3G 2nd Generation/3rd Generation P-CSCF Proxy-CSCF

3GPP 3rd Generation Partnership Project PDF Policy Decision Function
ADSL Asymmetric Digital Subscriber Line PDP Policy Decision Point

AS Application Server PEF Policy Enforcement Function

ATM Asynchronous Transfer Mode PEP Policy Enforcement Point

COPS Common Open Policy Service PLMN Public Land Mobile Network Application
Server
CN Core Network
PS Packet Switched
CS Circuit Switched
PSTN Public Switched Telephone Network
CSCF Call Session Control Function
QoS Quality of Service
DHCP Dynamic Host Configuration Protocol
Rel-5/Rel-6 Release 5/Release 6
DNS Domain Name System
RAN Radio Access Network
FQDN Fully Qualified Domain Name
RFC Request For Comments
GERAN GPRS EDGE Radio Access Network
RSVP ReSerVation Protocol
GGSN Gateway GPRS Support Node
SAE System Architecture Evolution
GPRS General Packet Radio Service SBLP Service-Based Local Policy
HSS Home Subscriber Server S-CSCF Serving-CSCF
I-CSCF Interrogating-CSCF SDP Session Description Protocol
IETF Internet Engineering Task Force SGSN Serving GPRS Support Node
IMS IP Multimedia Subsystem SIP Session Initiation Protocol
I-WLAN Intelligent Wireless Local Area SLF Subscription Locator Function
Networking
STM Synchronous Transfer Mode
IMSI International Mobile Subscriber Identifier
UE User Equipment
IP Internet Protocol
UMTS Universal Mobile Telecommunications
ISIM IP Subscriber Identity Module System
LDP Label Distribution Protocol URI Uniform Resource Identifier
MMSC MultiMedia Session Continuity URL Universal Resource Locator

NGN Next Generation Network USIM Universal Subscriber Identity Module

PCRF Policy Control and Charging Rules UTRAN Universal Terrestrial Radio Access
Function Network

1. Pourquoi l’IP multimédia ?
Le domaine IP multimédia peut être considéré comme un réseau
permettant la fourniture de services IP multimédia à un utilisateur
qui y accède depuis un réseau sous-jacent. Ce réseau offre à l’utili-
sateur une connectivité IP, initialement l’UMTS avec la release 5,
puis le I-WLAN en release 6 et l’ADSL en release 7.
Avant la construction de l’architecture IMS, le réseau support
(par exemple, le GPRS) permet d’accéder à des services exécutés
sur des plates-formes de services directement connectées à ce
réseau. Les services ainsi supportés utilisent le mode client/ser-
veur et ne permettent pas une interaction simple des services
entre eux.
L’IMS permet au contraire d’offrir des services interpersonnels
en combinant la voix et les services de données. Il rend aussi pos-
sible la combinaison de plusieurs services pour rendre un service
plus sophistiqué (par exemple, en combinant le service de pré-
sence avec un service de renvoi d’appel). De plus, il permet de
simplifier le terminal de l’utilisateur en implémentant une pile SIP.
Cette pile rend alors divers services basés sur les fonctionnalités
de ce protocole (service de messagerie, service de présence, etc.)
au lieu d’implémenter localement une application dédiée à chaque
service (client de messagerie, client de présence).
Pour un opérateur de réseaux, l’IMS permet aussi d’homogé-
néiser des fonctions réseau utiles à l’ensemble des services, telles
que le système de facturation, la gestion des utilisateurs dans les
bases de données, le système de sécurité, la gestion de la qualité
de service, etc.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 2 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA
2. Architecture IMS
L’architecture IMS repose sur certains principes énoncés dans
les spécifications techniques du 3GPP dès la première release
(Rel-5 finalisée en mars 2003). Cette architecture évolue et s’enri-
chit de nouvelles fonctionnalités (Rel-6 finalisée en mars 2005 et
Rel-7 en juin 2007).
2.1 Principes d’architecture
Les principes d’architecture suivants ont guidé la conception de
l’architecture IMS dès sa première version en release 5.
1. Séparation entre les fonctions réseau et les fonctions radio
d’accès : l’objectif est de permettre un accès au réseau via différents
types d’accès et ce même si la technologie d’accès radio évolue.
2. Indépendance de la technologie d’accès : l’architecture IMS est
prévue dès le départ pour être utilisée depuis des accès mobiles
ou fixes (xDSL, Cable, Wireless-LAN). L’interface avec le réseau
sous-jacent pour la connectivité IP se fait à un point de référence
stable (par exemple, le GGSN pour l’UMTS qui cache la micromo-
bilité du terminal). En réalité, faute de temps, la release 5 ne définit
que l’accès à l’IMS depuis une connectivité de type GPRS alors
que l’accès depuis I-WLAN est introduite en release 6, et l’accès
fixe de type xDSL ou Cable apparaît seulement en release 7.
3. Principe d’allocation des ressources : l’IMS est construit de façon
que les ressources mises en œuvre dans le réseau d’un opérateur
soient contrôlées par des éléments de réseau de cet opérateur.
4. Support du roaming (possibilité, pour un usager de téléphone
mobile, de pouvoir appeler et être appelé via différents types de
réseaux mobiles) entre mobile 2G et 3G.
5. Support d’une large gamme de terminaux.
6. Support de mécanismes permettant le développement rapide de
services par les opérateurs et fournisseurs tiers.
7. Support des contraintes réglementaires : en particulier les inter-
ceptions légales et la portabilité du numéro.
8. Support des protocoles du monde Internet : dans la mesure du
possible, l’IMS doit utiliser les protocoles existants ou des évolu-
tions de protocoles issus du monde Internet pour rendre les
services multimédia.
9. Séparation des plans de transport et de signalisation (principe
du NGN) : cela de façon à rendre modulable pour l’opérateur le
dimensionnement du réseau lors de sa création et pour ses évolu-
tions futures.
10. Indépendance de la couche transport : l’IMS doit pouvoir être
utilisé quel que soit la couche de transport en usage dans le
réseau de l’opérateur (par exemple, STM, ATM, IP).
2.2 Architecture IMS
La solution complète pour le support d’applications IP multimé-
dia comporte les terminaux, le réseau d’accès (en release 5 l’accès
radio de type GERAN ou UTRAN), le cœur de réseau GPRS évolué
et le nouveau domaine IP multimédia (IMS est introduit à partir de
la release 5).
2.2.1 Architecture générale de la release 5
à la release 7
La figure 1 illustre l’architecture IMS en release 6 depuis un
accès UMTS (UTRAN + cœur de réseau GPRS) :
– l’architecture initiale en release 5 étant identique à ceci près
que le CRF ne fait pas encore partie de l’architecture et que la fonc-
tion PDF est alors intégrée dans le P-CSCF ;
– l’architecture en release 7 étant identique à ceci près que la
fonction CRF intègre désormais la fonction PDF pour former le
PCRF (la nouvelle interface Gx utilisant le protocole Diameter en
remplacement de COPS utilisé en release 6).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
est strictement interdite. – © Editions T.I.
Cette architecture contient les entités logiques et leurs interfaces
standardisées, ce qui n’empêche pas les industriels de regrouper
physiquement des entités logiques sur un même équipement phy-
sique dans leurs solutions IMS (par exemple, regroupement de
CSCF).
2.2.2 Entités et interfaces
Les entités définies dans cette architecture (figure 1) ne sont pas
rappelées ici, mais tout ou partie de ces entités seront notamment
évoquées lors de l’exécution des procédures dans l’IMS (voir § 3),
telles que l’enregistrement de l’utilisateur dans le domaine IP mul-
timédia, l’établissement d’une session dans l’IMS, etc.
Ces entités peuvent se répartir en quatre groupes :
– les entités représentées en violet assurent le contrôle de
session dans l’IMS ;
– les entités représentées en vert permettent l’exécution des ser-
vices multimédia dans différents types de plates-formes de
services ;
– les entités représentées en jaune permettent l’interaction avec
le domaine circuit pour le passage d’un appel, par exemple depuis
le domaine IP multimédia vers un mobile 2G ou le réseau de télé-
phonie fixe classique (PSTN) ;
– les entités représentées en bleu permettent l’interaction entre
réseaux utilisant des versions IP différentes (IPv4 et IPv6).
Le tableau 1 illustre les interfaces qui lient les entités entre elles
et le protocole utilisé sur chacune d’elle (cf. figure 1).
2.2.3 Lien en standardisation entre IETF et 3GPP
En cohérence avec le principe d’architecture 8, l’architecture IMS
du 3GPP utilise les protocoles spécifiés à l’IETF (Internet Enginee-
ring Task Force) sur ses interfaces, notamment SIP et Diameter
largement présents. Certaines adaptations des protocoles IETF
sont nécessaires dans les spécifications du 3GPP et il s’ensuit une
étroite collaboration entre les deux organismes de standardisation
(cf. tableau 2).
2.2.3.1 Protocoles amendés pour les besoins du 3GPP
SIP et Diameter tels qu’ils sont mis en œuvre au 3GPP néces-
sitent des modifications par rapport aux spécifications techniques
de l’IETF.
■ SIP
Le protocole SIP au cœur des procédures IMS est spécifié au
3GPP (dans le TS 24.229) par différence de celui défini à l’IETF
[RFC 3261 et nombreux autres RFC) (cf. Normes en tableau 2)].
• Différences sur la définition des entités
• Le terminal de l’utilisateur est au départ un SIP User Agent
standardisé à l’IETF auquel le 3GPP a ajouté des comportements
spécifiques tels que la réservation obligatoire des ressources avant
l’établissement de session.
• Les CSCF sont des proxies SIP auxquels le 3GPP a ajouté des
fonctionnalités, par exemple :
– les CSCF sont capables d’émettre des tickets de facturation,
– le P-CSCF et S-CSCF sont capables d’initialiser la fin d’une ses-
sion multimédia,
– le P-CSCF et S-CSCF peuvent autoriser l’usage des ressources
(média, codec) en fonction de la politique locale de l’opérateur
(P-CSCF et S-CSCF) et la souscription de l’abonné (S-CSCF seule-
ment),
– le P-CSCF est impliqué dans la gestion de la qualité de service.
• Le S-CSCF est un serveur d’enregistrement SIP qui, de plus,
interagit avec le HSS pour authentifier l’utilisateur lors de l’enre-
gistrement.
TE 7 512 – 3
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

Figure 1 – Architecture IMS en release 6

Tableau 1 – Liste des entités et interfaces

Entité Interface Protocole Entité Interface Protocole
Cx Interface entre CSCF et HSS Diameter Mg Interface entre MGCF et CSCF SIP
Dh Interface entre AS Diameter
Mi Interface entre CSCF et BGCF SIP
(SIP-AS ou OSA-CSCF) et SLF
Dx Interface entre CSCF et SLF Diameter Mj Interface entre BGCF et MGCF SIP
Gi Interface entre GPRS et réseau IP externe IP Mm Interface entre CSCF et autres réseaux IP SIP
Interface entre GPRS et le réseau IMS multimédia
en particulier
Gm Interface entre UE et P-CSCF SIP Mp Interface entre MRFC et MRFP H.248
Go Interface entre PDF et GGSN (Rel-5/Rel-6) COPS Mr Interface entre CSCF et MRFC SIP
Gq Interface entre PDF et P-CSCF (Rel-6) Diameter Mw Interface entre CSCF et CSCF SIP
Gx Interface entre CRF et GGSN (Rel-6) Diameter
Mx Interface entre CSCF/BGCF et IMS-ALG SIP
Interface entre PCRF et GGSN (Rel-7)
ISC Interface entre S-CSCF et AS SIP Rx Interface entre CRF et P-CSCF (Rel-6) Diameter
(serveur d’application) Interface entre PCRF et P-CSCF (Rel-7)
Sh Interface entre AS (SIP-AS Diameter
Ix Interface entre IMS-ALG et TrGW
ou OSA-CSCF) et HSS
Mb Point d’accès vers les réseaux IP v6 IP Si Interface entre IM-SSF et HSS CAP
Ut Interface entre UE et AS XCAP
Mn Interface entre MGCF et IM-MGW H.248
(serveur d’application)

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 4 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

• Différences sur la définition des en-têtes SIP ■ Diameter

• Le 3GPP a besoin d’en-têtes spécifiques qui initialement
n’étaient pas définis à l’IETF mais qui ont donné lieu à des RFC [en
particulier le RFC 3455 (cf. tableau 2)] pour répondre aux besoins
du 3GPP :
– l’en-tête « P-Associated-URI » indique la liste des identités
publiques qui font partie du même ensemble d’enregistrement
pour l’enregistrement implicite,
– l’en-tête « P-Visited-Network-ID » indique le réseau dans lequel
se trouve le P-CSCF afin de vérifier les droits de l’utilisateur pour le
roaming dans l’IMS lors de l’enregistrement,
– l’en-tête « P-Access-Network-Info » indique le type de
connectivité IP utilisé par le terminal pour accéder aux services
IMS, soit le GERAN, l’UTRAN, l’ADSL, le Wifi, etc.,
– les en-têtes « P-Charging-Function-Addresses » et
« P-Charging-Vector » servent à la facturation des services IMS.
• Le 3GPP rend obligatoire l’usage de certains en-têtes dont
l’usage est optionnel au 3GPP :
– le réseau IMS (P-CSCF) certifie l’identité publique de l’utilisa-
teur en insérant obligatoirement l’en-tête « P-Asserted-Identity ».
Le protocole Diameter est utilisé au 3GPP pour gérer les interac-
tions entre les CSCF et les bases de données HSS et SLF. Il est en
fait spécifié (TS 29.228, TS 29.229) par delta par rapport au proto-
cole défini à l’IETF (RFC 3588) avec des codes spécifiques alloués
par l’IETF pour le 3GPP (RFC 3589) (cf. tableau 2).
2.2.3.2 Protocoles inchangés pour les besoins du 3GPP
L’architecture IMS intègre aussi des interfaces avec des entités
externes telles que des serveurs DHCP et DNS définis à l’IETF et
dont l’usage au 3GPP est conforme à l’IETF (et dont l’utilisation sera
vue lors des procédures IMS, par exemple la découverte du P-CSCF).
2.3 Souscription IMS et identification
de l’utilisateur
L’utilisateur qui souhaite accéder à des services IMS fait l’objet
d’une souscription :
– souscription aux services IMS ;

Tableau 2 – Normes (1)

3GPP http://www.3gpp.org IETF http://www.ietf.org (suite)

3GPP TS 23.002 Network architecture IETF RFC 3262 Reliability of Provisional Responses in SIP
3GPP TS 23.008 Organization of subscriber data IETF RFC 3263 Session Initiation Protocol (SIP) :
Locating SIP Servers
3GPP TS 23.060 General Packet Radio Service (GPRS) ; Service IETF RFC 3264 An Offer/Answer Model with the Session Descrip-
description tion Protocol (SDP)
3GPP TS 23.207 End-to-end Quality of Service (QoS) concept IETF RFC 3265 Session Initiation Protocol (SIP) – Specific Event
and architecture Notification
3GPP TS 23.221 Architectural requirements IETF RFC 3311 The Session Initiation Protocol (SIP) UPDATE
Method
3GPP TS 23.228 IP multimedia sub-system IETF RFC 3312 Integration of resources management and SIP
3GPP TS 23.401 General Packet Radio Service (GPRS) enhance-
ments for Evolved Universal Terrestrial Radio IETF RFC 3313 Private SIP Extensions for Media Authorization
Access Network (E-UTRAN) access
3GPP TR 23.893 Feasibility study on multimedia session IETF RFC 3319 DHCPv6 Options for SIP Servers
continuity
3GPP TS 24.228 Signalling flows for the IP multimedia call IETF RFC 3323 A Privacy Mechanism for the Session
control based on SIP and SDP Initiation Protocol (SIP)
3GPP TS 24.229 IP Multimedia Call Control Protocol based on IETF RFC 3325 Private Extensions to the Session Initiation
SIP and SDP Protocol (SIP) for Network Asserted Identity
within Trusted Networks
3GPP TS 29.208 End-to-end Quality of Service (QoS) signalling IETF RFC 3327 Session Initiation Protocol Extension Header Field
flows for Registering Non-Adjacent Contacts
3GPP TS 29.228 IP Multimedia (IM) Subsystem Cx and Dx
interfaces ; Signalling flows and message IETF RFC 3329 Security Mechanism Agreement for SIP
content
3GPP TS 29.229 Cx and Dx interfaces based IETF RFC 3455 Private Header (P-Header) Extensions to the Ses-
on the Diameter protocol ; Protocol détails sion Initiation Protocol (SIP) for the 3rd-Genera-
tion Partnership Project (3GPP)
3GPP TS 33.203 Access security for IP-based services IETF RFC 3486 Compressing the Session Initiation Protocol (SIP)
IETF RFC 3524 Mapping of media streams to Resource reserva-
IETF http://www.ietf.org
tion flows
IETF RFC 2131 DHCP IETF RFC 3588 Diameter Base Protocol
IETF RFC 2782 A DNS RR for specifying the location of services IETF RFC 3589 Diameter command codes for 3gpp release 5
(DNS SRV)
IETF RFC 2916 E.164 number and DNS IETF RFC 3680 A Session Initiation Protocol (SIP) Event Package
for Registrations
IETF RFC 3261 SIP : Session Initiation Protocol IETF RFC 4566 SDP : Session Description Protocol
(1) TS : Technical Specification ; RFC : Request For Comments

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 5
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

Public User Service

Identity-1 Profile -1
Private User
Identity -1

IMS Public User

Subscription Identity-2
Service
Private User Profile -2
Identity -2
Public User
Identity-3

Figure 2 – Souscription IMS

– souscription au réseau paquet : une souscription est néces- sein d’une même souscription IMS en release 6 avec un partage
saire également pour accéder au réseau support sous-jacent à d’identité publique entre plusieurs identités privées. Ainsi, sur la
l’IMS, par exemple une souscription pour l’accès GPRS. figure 2, l’identité publique 2 est partagée entre l’identité privée 1
et l’identité privée 2, l’intérêt étant pour l’utilisateur de pouvoir
être contacté sur plusieurs terminaux avec la même identité
2.3.1 Souscription IMS dans les bases de données publique (fonctionnalité de « forking »).
(HSS et SLF)
La souscription IMS de l’utilisateur se traduit dans le réseau de 2.3.3 Profil de service de l’utilisateur dans l’IMS
l’opérateur par la « création » de cet utilisateur dans les bases de
données de l’IMS, c’est-à-dire dans le HSS, et dans le SLF si l’opé- Le profil de l’utilisateur fait partie de la souscription IMS
rateur dispose de plusieurs HSS dans son réseau : (cf. figure 2). Il est associé à une identité privée et à une identité
– dans le SLF, il s’agit d’associer l’utilisateur à un HSS qui stoc- publique au minimum. Les données de souscription IMS de l’utili-
kera les données de souscription IMS le concernant ; sateur seront décrites dans un autre article.
– dans le HSS, il s’agit de stocker les données de souscription
IMS, à savoir les identités de l’utilisateur et les profils d’abonné
associés.
3. Procédures réseau
2.3.2 Identification de l’utilisateur dans l’IMS
dans l’IMS (en Rel-5/Rel-6)
Sans entrer dans les détails de structure des bases de données
et le format des données, la figure 2 illustre une souscription IMS
avec les liens entre identités publiques et identités privées de l’uti- 3.1 Vue générale des procédures
lisateur et ses profils d’abonné.
La figure 3 illustre les procédures utiles pour accéder aux servi-
L’identité privée est attribuée par l’opérateur réseau et est utili- ces IMS dans l’ordre où elles doivent être exécutées pour rendre
sée à des fins d’identification de l’utilisateur du point de vue possible, par exemple, la participation du terminal/de l’utilisateur
réseau (par exemple, pour authentifier l’utilisateur lors de l’enre- dans une session (appel reçu ou appel émis).
gistrement dans le réseau IMS). Elle n’est pas utilisée par l’utilisa-
teur contrairement à l’identité publique.
L’identité publique sert à l’utilisateur pour communiquer avec
d’autres utilisateurs : c’est l’identité que ses correspondants
connaissent pour le joindre. L’utilisateur peut disposer d’une ou plu-
sieurs identités publiques pour une même identité privée, ce qui
signifie qu’il pourra recevoir des appels avec l’une ou l’autre des
identités publiques si plusieurs sont enregistrées dans l’IMS (par
exemple, une identité publique personnelle communiquée à ses
proches et une identité publique professionnelle communiquée à
ses collègues).
Exemples :
• sip:user1_public1@home1.net ou sip:jean.dupond@orange.fr sont
des exemples d’identité publique sous le format SIP URI (une partie
utilisateur et une partie réseau séparées par le signe @ à l’instar
d’une adresse mail).
• tel : +1-212-555-2222 est un exemple d’identité publique sous le
format tel URI. Ce type d’identité publique permet à l’utilisateur d’être
joint par un correspondant qui initie un appel voix depuis un réseau en
mode circuit (PSTN, mobile GSM, ce qui nécessite une conversion
pour router l’appel dans le réseau IMS jusqu’à l’utilisateur).

En release 5, l’utilisateur ne peut disposer que d’une identité

privée (en vert sur la figure 2) alors qu’il peut en avoir plusieurs au Figure 3 – Accès aux services IMS

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 6 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA
Les étapes 1 et 2 sont des étapes préalables exécutées non pas
dans le réseau IMS, mais au niveau du réseau support sous-jacent
à l’IMS (par exemple, le réseau GPRS si l’utilisateur accède à l’IMS
avec une technologie GPRS).
Les étapes suivantes correspondent réellement à des procédures
exécutées dans le réseau IMS et ce sont celles-ci qui seront
décrites dans le présent document.
Étape 1 : le terminal initialise une procédure d’enregistrement
réseau, c’est-à-dire qu’il se connecte au réseau support et lance,
par exemple, une procédure dite « GPRS Attach » (procédure sou-
vent automatique lors de la mise sous tension du terminal), s’il
souhaite accéder aux services IMS depuis une connexion de type
GPRS.
Étape 2 : le terminal lance l’activation d’un lien de transmission
qui servira au minimum pour le transport de la signalisation qui sera
échangée avec le réseau IMS. Il peut obtenir une adresse IP lors de
l’établissement du lien de transmission ou immédiatement après.
Cette adresse lui sera utile pour communiquer avec le réseau IMS
dans les procédures IMS à venir (par exemple, pour communiquer
avec son correspondant dans une session multimédia).
Étape 3 : le terminal lance une procédure de découverte du
P-CSCF, qui sera son point d’entrée dans le réseau IMS pour toute
future procédure IMS.
Étape 4 : le terminal demande à s’enregistrer dans le réseau
IMS, de façon que le réseau l’authentifie et qu’il puisse
communiquer avec lui pour tout échange futur (par exemple, pour
établir un appel multimédia).
Étape 5 : le terminal (de même que le P-CSCF) s’abonne auprès
du S-CSCF (serveur d’enregistrement dans l’IMS) de façon à être
notifié de tout changement d’état d’enregistrement sachant que le
terminal/l’utilisateur peut demander la fin de son enregistrement
dans le réseau IMS mais que le réseau peut aussi mettre un terme
à l’enregistrement de l’utilisateur (par exemple, lors de la fin de la
souscription aux services IMS).
Étape 6 : le terminal est en mesure d’accéder à ses services IMS,
par exemple recevoir un appel ou établir un appel vers un autre
terminal/utilisateur ou un serveur d’application.
Les procédures des étapes 3 à 6 sont décrites plus spécifi-
quement dans les paragraphes suivants, étant entendu que le
contenu de chaque message ne sera pas détaillé mais que les flux
seront présentés de façon globale.
Nota : le terminal utilisé pour accéder aux services IMS nécessite des évolutions par
rapport aux terminaux UMTS des versions précédentes, pour la simple raison qu’il doit
intégrer une pile SIP de manière à échanger de la signalisation avec le réseau IMS.
3.2 Support du roaming dans l’IMS
Lorsque l’utilisateur accède à des services IMS depuis un réseau
dans lequel il n’a pas souscrit à ces services IMS (réseau visité au
lieu du réseau « home ») :
– il utilise certains équipements du réseau sous-jacent chez
l’opérateur du réseau sous lequel il se trouve actuellement (par
exemple, pour un accès UMTS l’utilisateur est connecté via un
l’UTRAN et le SGSN dans le réseau visité le GGSN pouvant être
dans le réseau « home » ou visité) ;
– il peut utiliser certaines entités dans l’IMS du réseau visité ou
toutes les entités du réseau IMS home (réseau auprès duquel il a
souscrit ses services IMS). Dans ce dernier cas, cela signifie que
l’utilisateur peut se trouver, par exemple, à l’étranger sans qu’il n’y
ait de différence dans l’exécution des procédures du réseau IMS
(cas où le point d’entrée de l’utilisateur dans l’IMS est le P-CSCF
du réseau « home »).
Dans les figures 4 et 5, l’opérateur du réseau visité est repré-
senté par ses entités en rose tandis que l’opérateur du réseau
« home » est représenté par ses entités en orange (pour des
raisons de simplicité, les figures sont dépouillées des entités
d’interfonctionnement et des plates-formes de services).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
est strictement interdite. – © Editions T.I.
Pour garantir un contrôle des ressources dans son réseau (cf.
principe 3 au paragraphe 2.1), le P-CSCF et le point de terminaison
de connectivité IP se trouvent dans le réseau du même opérateur
(tous les deux dans le réseau « home » ou tous les deux dans le
réseau visité en fonction des accords de roaming entre opérateurs).
■ Cas du roaming avec le P-CSCF dans le réseau « home »
Les figures 4 et 5 illustrent le cas du roaming lorsque le point
d’entrée de l’utilisateur pour l’IMS ainsi que le point de termi-
naison de sa connectivité IP sont dans le réseau « home ».
■ Cas du roaming avec le P-CSCF dans le réseau visité
Les figures 6 et 7 illustrent le cas du roaming lorsque le point
d’entrée de l’utilisateur pour l’IMS, ainsi que le point de termi-
naison de sa connectivité IP, sont dans le réseau visité.
■ Comparaison
Les différences sur les flux de messages, lorsque l’utilisateur
accède à l’IMS depuis un P-CSCF dans le réseau « home », est
expliqué par delta :
– le P-CSCF se situe dans le réseau « home » au lieu du réseau
visité ;
– la fonction I-CSCF(THIG) n’est pas utilisée alors qu’elle peut
l’être optionnellement dans le cas du roaming IMS si l’opérateur
du réseau « home » souhaite masquer la topologie de son réseau
au réseau visité (cf. § 4 Sécurité dans l’IMS).
Les procédures dans ce document sont présentées en situation
de roaming IMS, c’est-à-dire avec le P-CSCF dans un réseau visité
pour rester le plus général possible.
Dans le cas où le P-CSCF est dans le réseau « home », le routage
des données et de la signalisation se fait avec une terminaison de
connectivité IP dans le réseau « home », ce qui pose des pro-
blèmes de « tromboning » lorsque le terminal appelle depuis
l’étranger un correspondant dans le même pays.
Exemple : lorsque le terminal se trouve aux États-Unis et appelle
un correspondant aux États-Unis, le trafic est routé via le GGSN de la
France pour revenir aux États-Unis au lieu de rester aux USA (c’est le
phénomène de tromboning.
En pratique, les opérateurs de télécommunications utilisent le
GGSN dans leur réseau par choix d’implémentation.
3.3 Découverte du point d’entrée
dans l’IMS
Le P-CSCF est le point d’entrée de l’utilisateur dans le réseau
IMS. Il est découvert par le terminal au moyen de l’une des procé-
dures suivantes :
– soit pendant l’établissement du lien de transmission pour la
signalisation par des méthodes spécifiques à la technologie utili-
sée (par exemple, attribution par le GGSN de l’adresse du P-CSCF
pour un accès GPRS) ;
– soit, après, par des méthodes indépendantes de la technologie
de connexion IP en utilisant des méthodes standards de l’IETF telles
que DHCP/DNS : le terminal contacte un serveur DHCP qui attribue :
• directement l’adresse IP du P-CSCF ou,
• le nom de domaine (FQDN) du P-CSCF et l’adresse IP du
serveur DNS à contacter pour retrouver l’adresse IP du P-CSCF.
La figure 8 illustre l’utilisation de DHCP et DNS pour un terminal
qui a activé un lien de transmission GPRS (« PDP context »).
3.4 Enregistrement dans l’IMS
3.4.1 Rôle de l’enregistrement
L’enregistrement vise à rendre l’utilisateur disponible pour
l’accès à ses services IMS, ce qui signifie que l’utilisateur ne peut
TE 7 512 – 7
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________
Figure 4 – Accès à l’IMS depuis un réseau visité via un P-CSCF du réseau « home »
Figure 5 – Accès à l’IMS depuis un réseau visité via un P-CSCF
du réseau « home », routage au niveau de la connectivité IP
pas émettre ou recevoir d’appel ni accéder à tout autre service IMS
s’il n’est pas connu du réseau par une procédure d’enregistrement.
Il assigne un serveur d’enregistrement à l’utilisateur, c’est-à-dire
sélectionne un S-CSCF pour enregistrer l’utilisateur dans ce
S-CSCF via une correspondance entre ses identités et son adresse
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
TE 7 512 – 8 est strictement interdite. – © Editions T.I.
IP en cours d’utilisation. Il établit une route entre le terminal et ce
S-CSCF, de sorte que chaque message échangé entre l’utilisateur
et le réseau IMS utilisera ce chemin préétabli lors de l’enregis-
trement. Le S-CSCF servira par la suite à contrôler l’accès de l’utili-
sateur à chaque service IMS demandé (puisqu’il aura téléchargé
localement les données de souscription de l’abonné lors de l’enre-
gistrement) si besoin en interagissant avec des serveurs d’applica-
tion connectés au S-CSCF.
L’enregistrement permet aussi au réseau d’authentifier l’utilisa-
teur et à l’utilisateur d’authentifier le réseau puis d’établir une rela-
tion sécurisée entre le terminal et le P-CSCF (tunnel IPSec pour le
transfert de la signalisation SIP). Cela sera développé dans le
paragraphe 4 « Sécurité dans l’IMS ».
3.4.2 Enregistrement implicite
Il est possible d’enregistrer plusieurs adresses publiques de l’uti-
lisateur au sein d’une même procédure d’enregistrement. Cette
fonctionnalité d’enregistrement implicite est spécifique à l’IMS
3GPP (non prévu pour SIP IETF) pour économiser la signalisation
passée, en particulier, sur l’interface radio pour un accès de type
GPRS. Cela est rendu possible grâce au regroupement de plusieurs
identités publiques au sein d’un même ensemble dans la souscrip-
tion IMS de l’utilisateur. Les identités publiques d’un même
ensemble d’enregistrement peuvent avoir des profils de services
différents mais appartiennent tous à la même identité privée de
l’utilisateur comme illustré sur la figure 9 (page 10).
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

Figure 6 – Accès à l’IMS depuis un réseau visité via un P-CSCF du réseau visité

Figure 8 – Procédure de découverte du P-CSCF via DHCP/DNS

pour un accès GPRS

– les messages en orange sont des requêtes/réponses DNS

Figure 7 – Accès à l’IMS depuis un réseau visité via un P-CSCF
du réseau visité, routage au niveau de la connectivité IP
3.4.3 Procédure d’enregistrement
La figure 10 illustre les messages échangés pour enregistrer
l’utilisateur :
– les messages en noir utilisent le protocole de signalisation SIP
échangée entre le terminal et les CSCF du réseau IMS ;
échangées entre le P-CSCF découvert par le terminal et un serveur
DNS dans le même réseau pour connaître le point d’entrée dans le
réseau « home » de l’utilisateur. Le P-CSCF utilise le nom de
domaine du réseau « home » indiqué par l’utilisateur/le terminal
dans la requête REGISTER et le convertit en adresse IP qui indique
le I-CSCF ;
– les messages en vert illustrent les interactions entre les CSCF
(I-CSCF et S-CSCF) et les bases de données (SLF et HSS). Ce sont
des messages utilisant le protocole Diameter. L’interrogation au
SLF permet d’obtenir l’adresse du HSS qui contient les données de
l’utilisateur. L’interrogation au HSS permet d’obtenir les informa-
tions de l’utilisateur nécessaires à son enregistrement dans le
réseau IMS et notamment les données servant à l’authentification.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 9
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________
Figure 9 – Souscription IMS et enregistrement implicite d’identités publiques de l’utilisateur
Seul le cas d’enregistrement avec succès est présenté ici et non
les cas d’échec, par exemple un échec d’authentification menant à
l’échec de l’enregistrement.
Ces flux de messages permettent de voir que l’enregistrement
comprend plusieurs phases.
Étapes 1 à 17 : l’utilisateur demande à s’enregistrer en émettant
la requête SIP REGISTER prévue à cet effet. Cette requête est « non
protégée » : à ce stade il n’existe pas encore d’association de sécu-
rité IPSec entre le terminal et le P-CSCF (cf. § 4 « Sécurité dans
l’IMS ») puisque l’utilisateur n’est pas encore authentifié. Cette
phase permet au I-CSCF (étape 8) de sélectionner un S-CSCF qui
sera le serveur de contrôle de session pour les futurs services IMS
que demandera l’utilisateur. Le I-CSCF interroge la base de
données utilisateur pour l’assister dans son choix pour s’assurer
que le S-CSCF contient les capacités de rendre les services sous-
crits par l’utilisateur. Le S-CSCF (étape 13) interroge le HSS pour
obtenir un vecteur d’authentification (quintuplet) qui lui permettra
d’authentifier l’utilisateur avec le mécanisme d’authentification dit
IMS AKA (cf. § 4 « Sécurité dans l’IMS »).
Nota : le HSS stocke l’adresse du S-CSCF choisi pour l’utilisateur, ce qui permettra par
la suite (lors de l’utilisation des services IMS) de pouvoir router les requêtes à destination
de l’utilisateur depuis le point d’entrée dans son réseau « home » : le I-CSCF interrogera
le HSS qui lui donnera l’adresse du S-CSCF à contacter.
Étapes 18 à 32 : l’utilisateur génère une réponse au défi envoyé
par le S-CSCF (cf. § 4 « Sécurité dans l’IMS ») : le S-CSCF authenti-
fie l’utilisateur quand la réponse reçue correspond à la réponse
attendue (étape 27). Le S-CSCF stocke le profil d’abonné de l’utili-
sateur obtenu après interrogation du HSS. En fonction du profil
d’abonné, il peut interagir avec des serveurs d’application pour les
informer de l’enregistrement de l’utilisateur et leur permettre de
s’abonner éventuellement à l’événement d’enregistrement s’ils ont
besoin de connaître l’état d’enregistrement de l’utilisateur pour
l’exécution des services IMS. Le S-CSCF accepte la demande
d’enregistrement et associe les identités de l’utilisateur avec
l’adresse IP du terminal et stocke le « chemin de signalisation »
(en-tête SIP « Service-Route ») qui lui permettra de faire suivre
toute future requête destinée à cet utilisateur. En cas de roaming,
si le réseau « home » souhaite masquer la topologie de son réseau
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
TE 7 512 – 10 est strictement interdite. – © Editions T.I.
(cf. § 4 « Sécurité dans l’IMS »), le chemin de signalisation
contiendra l’adresse du I-CSCF(THIG). Le P-CSCF monte le tunnel
IPSec visant à protéger la signalisation SIP qui sera échangée avec
le terminal jusqu’à la fin de l’enregistrement.
Étapes 33 à 49 : le terminal (étapes 33 à 41) et le P-CSCF (étapes
42 à 49) s’abonnent auprès du S-CSCF pour s’informer de tout
changement d’état d’enregistrement de l’utilisateur. La requête SIP
SUBSCRIBE leur permet de s’abonner à l’événement d’enregistre-
ment et la requête SIP NOTIFY permet au S-CSCF de leur envoyer
le nouvel état d’enregistrement de l’utilisateur.
3.5 Établissement de session multimédia
Parmi les services offerts par l’IMS, la session multimédia appa-
raît comme le service de base qui permet de mettre en
communication deux terminaux pour échanger un ou plusieurs
flux de média (par exemple, une session mettant en jeu un média
audio et un média de type application).
Des serveurs d’application peuvent être contactés lors de l’éta-
blissement de la session (étape « Service control » sur la figure 11,
page 12). Il est également possible d’établir une session multimé-
dia entre un terminal et un serveur d’application via le réseau IMS.
Ces deux aspects ne sont pas décrits ici et seront traités dans un
autre article dédié aux services IMS.
3.5.1 Établissement d’un appel basé
sur le protocole SIP défini à l’IETF
Sans entrer dans les détails du protocole SIP, l’établissement
d’une session est réalisé grâce à l’échange de 3 messages entre 2
terminaux (directement ou de façon plus réaliste au travers d’un
réseau via des proxies SIP qui font suivre les messages) :
– « INVITE » par le terminal initialisant la session pour contacter
un correspondant (message de l’appelant vers appelé) ;
– « 200 OK » envoyé par le terminal distant pour accepter de par-
ticiper à cette session (message de l’appelé vers appelant) ;
– « ACK » pour attester de l’établissement de la session
(message de l’appelant vers appelé).
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

Figure 10 – Procédure d’enregistrement de l’utilisateur

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 11
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

Figure 11 – Procédure d’établissement de session

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 12 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA
3.5.2 Établissement d’un appel dans l’IMS défini
au 3GPP
Comme en atteste la figure 11, l’établissement d’une session
dans le réseau IMS est beaucoup plus complexe.
Au 3GPP, contrairement à l’IETF, les ressources doivent être réser-
vées par chaque terminal utilisant un accès de type GPRS avant que
l’appelé puisse accepter la session. Cela rend obligatoire le support
des préconditions de qualité de service et le support de réponses
provisoires fiables. L’usage des préconditions est une extension
obligatoire au 3GPP mais standardisée à l’IETF (RFC 3312).
Concrètement, le terminal appelant indique qu’il supporte le méca-
nisme de réponse provisoire fiable (en-tête Supported : 100 rel dans
le message « SIP INVITE ») et impose au terminal distant de sup-
porter les préconditions (Require : precondition).
L’établissement de session avec préconditions induit des mes-
sages supplémentaires pour l’établissement de la session (par rap-
port au SIP IETF) :
– une réponse provisoire envoyée de l’appelant vers l’appelé
(par exemple « 183 Session progress » et non directement le
« 200 OK » pour accepter la session), qui induit un accusé de
réception de cette réponse provisoire (« PRACK » envoyé de
l’appelant vers l’appelé) et la réponse correspondante (« 200 OK »
au « PRACK » envoyée par l’appelé vers l’appelant) ;
– une requête « UPDATE » qui permet à l’appelant de faire savoir
à l’appelé que les ressources pour la session sont disponibles de
son côté ;
– une réponse « 200 OK » à « UPDATE » qui annonce à l’appe-
lant la réservation des ressources pour la session du côté de
l’appelé.
Il existe également des spécificités de traitement de l’établis-
sement de session dans l’IMS telles que :
– le routage de la signalisation pour l’établissement d’appel fait
depuis l’appelant jusqu’à son S-CSCF sur la base de l’en-tête
« Service-Route » sauvegardé pendant l’enregistrement. Ensuite, le
S-CSCF côté appelant analyse la destination de l’appel et contacte
le point d’entrée dans le réseau « home » de l’appelé (I-CSCF). Le
I-CSCF interroge le HSS pour obtenir l’adresse du S-CSCF servant
l’appelé puis route l’appel vers ce S-CSCF. Le S-CSCF côté appelé
retrouve le chemin de signalisation jusqu’à l’appelé sur la base de
l’en-tête « Service-Route » stocké lors de l’enregistrement de
l’appelé dans l’IMS ;
– le fait que le P-CSCF et le S-CSCF sauvegardent les informa-
tions liées à la session, de façon à pouvoir initialiser une fin de
session si besoin, par exemple pour terminer la session applicative
si les ressources sont relâchées côté appelant ou appelé en cas de
perte de couverture radio ;
– la possibilité pour le P-CSCF de demander un regroupement de
plusieurs médias de même nature sur un même lien de transmis-
sion (par exemple, grouper la voix et la vidéo sur un même « PDP
context » conversationnel) ;
– la possibilité pour un opérateur de réseau IMS de configurer
au P-CSCF et S-CSCF une politique locale d’utilisation des médias.
L’établissement de session est rejeté si la description de la session
n’est pas conforme à la politique locale implémentée au P-CSCF
puis après au S-CSCF, par exemple certains codecs (codeur/déco-
deur) ne sont pas autorisés pour certains types de médias ;
– le contrôle des droits de l’utilisateur au S-CSCF : le S-CSCF
rejette la demande d’établissement de session si la souscription de
l’utilisateur ne l’autorise pas (par exemple, certains médias non
autorisés). Cela est rendu possible grâce au stockage du profil de
service téléchargé depuis le HSS vers le S-CSCF lors de l’enregis-
trement de l’utilisateur pour cette adresse publique ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
est strictement interdite. – © Editions T.I.
– les interactions avec les plates-formes de services ; le S-CSCF
interagit avec les AS en fonction du profil de l’abonné pour lequel
on définit des filtres : si la requête SIP reçue au S-CSCF correspond
au filtre défini dans le profil d’abonné, le S-CSCF contacte l’AS
correspondant. Cet aspect sera développé dans un prochain article
relatif aux services IMS ;
– la négociation des médias et codec pour la session est globa-
lement conforme à la négociation définie à l’IETF via le modèle
SDP offer/answer du RFC 3264. Le 3GPP introduit les spécificités
suivantes :
• la négociation des médias se fait en deux temps avec l’usage
des préconditions de QoS (« INVITE »/« 183 Session progress »
avant réservation des ressources puis « UPDATE »/« 200 OK to
UPDATE » après réservation des ressources) ;
• lors de la négociation des médias et codec après réservation
des ressources, l’appelé doit choisir un seul codec pour chaque
média parmi la liste proposée par l’appelant contrairement à l’IETF
(au lieu de la liste des codecs qu’il supporte pour chaque média) ;
• le 3GPP impose le support de codecs obligatoires (AMR en
audio, ITU H.263 pour la vidéo) dans les terminaux mais cela
n’empêche pas les terminaux de s’entendre sur un autre codec
lors de la négociation.
3.6 Modification de session multimédia
L’appelant ou l’appelé peut demander une modification de la
session en cours à tout moment. La demande de modification de
session est exprimée par le terminal via le message « SIP
UPDATE » ou un message de type « re-INVITE » qui contient une
nouvelle description pour la session en cours (corps de message
SDP avec des valeurs d’en-têtes différents de ceux exprimés lors
de l’établissement de session).
Une modification de session consiste par exemple :
– à ajouter ou supprimer un ou plusieurs médias ;
– à changer de codec sur un ou plusieurs médias ;
– à changer de numéro de port pour un ou plusieurs flux de
médias ;
– à changer la bande passante pour un ou plusieurs médias.
De la même manière qu’à l’établissement de session, le P-CSCF
et S-CSCF examinent les paramètres de la session et rejettent la
requête si certains ne sont pas autorisés (politique locale et/ou
souscription de l’utilisateur). L’usage des préconditions de QoS est
optionnel lors de la modification de session alors qu’il est obliga-
toire lors de l’établissement de session (pour un accès de type
GPRS).
La modification de session induit l’exécution de la procédure
d’autorisation des ressources dans tous les cas (et d’autres procé-
dures selon le type de modification) lorsque l’opérateur implé-
mente la fonction SBLP. L’intérêt de la fonction SBLP est d’adapter
les ressources de la session à la modification demandée (de façon
notamment à ajouter des ressources si besoin et à en supprimer
quand elles sont en excès). Lors de cette procédure (bloc « Update
QoS Authorization »), le PDF (en Rel-5/Rel-6) n’envoie pas de jeton
d’autorisation au terminal. Puisque le jeton identifie la session, le
terminal doit réutiliser le même jeton lors de la modification de
session. Le principe de fonctionnement de la fonction SBLP ainsi
que les procédures de QoS associées sont plus amplement
détaillées au paragraphe 3.9.4 « Procédures de QoS dans l’IMS ».
La modification de session est présentée dans les figures 12,
13, 14, 15 pour un accès de type GPRS.
TE 7 512 – 13
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

Figure 12 – Ajout de média avec ajout de ressources

Figure 13 – Ajout de média avec modification des ressources existantes

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 14 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

Figure 14 – Suppression de média

Figure 15 – Modification de session sans addition/suppression de médias

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 15
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________
3.6.1 Ajout de médias
Lorsque la modification de la session consiste à ajouter au
moins un média, cela peut nécessiter l’ajout de nouvelles res-
sources (activation de nouveau « PDP context ») ou la modification
des ressources existantes pour la session (modification de « PDP
context » existant). Le P-CSCF prend la décision de grouper ou non
des médias sur un même lien de transmission selon la politique
locale de l’opérateur. Le terminal est libre d’activer de nouvelles
ressources ou de modifier les ressources existantes si le P-CSCF
n’indique pas de préférence.
3.6.1.1 Ajout de média avec ajout de ressources
La figure 12 illustre une modification de session pour laquelle le
terminal demande l’ajout de ressources. Les procédures de QoS
mises en jeu dans la modification de session dans ce cas sont les
suivantes :
– le bloc « Update Authorization » représente la procédure de
mise à jour d’autorisation des ressources : le PDF calcule la nouvelle
QoS IP autorisée à partir de la nouvelle description de la session ;
– le bloc « Approval of QoS commit » représente la procédure
d’engagement de ressources pour rendre possible le passage des
flux de données au niveau du GGSN pour le(s) nouveau(x)
média(s) ;
– le bloc « PDP context activation for data » représente la procé-
dure de réservation des ressources : il s’agit de monter le(s) lien(s)
de transmission pour le(s) nouveau(x) média(s) afin d’adapter les
ressources de la session aux nouveaux besoins de l’utilisateur,
cette demande de ressources du terminal étant soumise à autori-
sation du GGSN.
3.6.1.2 Ajout de média avec modification des ressources
existantes
Dans ce cas illustré en figure 13, la modification de session est
équivalente au cas précédent à ceci près que les ressources exis-
tantes sont modifiées pour intégrer le nouveau média dans un lien
de transmission déjà actif (alors qu’un lien de transmission dédié
au nouveau média était créé dans le cas précédent).
Les procédures de QoS mises en jeu dans la modification de
session dans ce cas sont les suivantes :
– le bloc « Update Authorization » représente la procédure de
mise à jour d’autorisation des ressources ;
– le bloc « Approval of QoS commit » représente la procédure
d’engagement de ressources pour rendre possible le passage des
flux de données au niveau du GGSN ;
– le bloc « PDP context modification for data » représente la pro-
cédure de modification des ressources pour adapter les ressources
de la session aux nouveaux besoins de l’utilisateur (par exemple,
augmenter la bande passante pour intégrer le nouveau média
dans un « PDP context » existant). Cela déclenche la procédure
« Authorization of “PDP context” modification » lorsque la
demande de ressources dépasse les ressources autorisées ; le
GGSN demande une prise de décision au PDF et le GGSN révise
l’autorisation de ressources correspondant à la nouvelle descrip-
tion de session (par exemple revoit à la baisse la QoS UMTS
demandée par le terminal).
3.6.2 Suppression de médias
La figure 14 illustre une modification de session consistant à
supprimer au moins un média. Le terminal devrait demander la
suppression des ressources transportant ce média (soit une
demande de « “PDP context” deactivation » si le média supprimé
pour la session est seul dans ce « PDP context » ou une demande
de modification de « PDP context » si d’autres médias sont encore
présents dans le « PDP context »).
Les procédures de QoS mises en jeu dans la modification de
session dans ce cas sont les suivantes :
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
TE 7 512 – 16 est strictement interdite. – © Editions T.I.
– le bloc « Update Authorization » représente la procédure de
mise à jour d’autorisation des ressources ;
– le bloc « Removal of QoS commit » représente la procédure de
désengagement de ressources : pour bloquer le passage des flux
de données au niveau du GGSN et lancer une temporisation au
GGSN. Durant ce délai, si le terminal n’a pas demandé la suppres-
sion/modification des ressources en accord avec la nouvelle
description de session (pas d’indication reçue au PDF), cela
déclenche la procédure de fin d’autorisation des ressources pour
supprimer le « PDF context » correspondant.
3.6.3 Modification de session
sans addition/suppression de médias
La figure 15 illustre une modification de session qui ne change
pas le nombre de médias mais seulement leurs caractéristiques
(par exemple, changement de codec, modification de bande
passante, changement de numéro de port pour les flux médias). Si
nécessaire, le terminal demande la modification des ressources
transportant ce média (par exemple, pour augmenter la bande
passante utilisée).
Les procédures de QoS mises en jeu dans la modification de
session dans ce cas sont les suivantes :
– le bloc « Update Authorization » représente la procédure de
mise à jour d’autorisation des ressources ;
– le bloc « PDP context modification for data » représente la procé-
dure de modification des ressources pour adapter les ressources de
la session aux nouveaux besoins de l’utilisateur (par exemple, aug-
menter la bande passante d’un média déjà présent dans un « PDP
context » existant). Cela déclenche la procédure « Authorization of
“PDP context” modification » lorsque la demande de ressources
dépasse les ressources autorisées ; le GGSN demande une prise de
décision au PDF et le GGSN révise l’autorisation de ressources cor-
respondant à la nouvelle description de session (par exemple, revoit
à la baisse la QoS UMTS demandée par le terminal).
3.7 Relâche de session multimédia
Du point de vue de la signalisation SIP, une fin de session est
réalisée au moyen d’une requête « SIP BYE » (et de sa réponse
« 200 OK »).
Contrairement à l’IETF, le 3GPP prévoit que non seulement l’uti-
lisateur mais aussi le réseau soient capables de relâcher une
session multimédia. Aussi, le P-CSCF et S-CSCF stockent les infor-
mations relatives à la session lors de l’établissement de session en
les liant à l’adresse IP actuellement utilisée par le terminal.
Les deux cas sont montrés ci-après avec des flux simplifiés,
l’intérêt étant de montrer l’entité qui initialise la relâche de la
session. Les figures 16, 17, 18 illustrent également les interac-
tions avec la QoS, la relâche de session devant être accompagnée
de la relâche des ressources impliquées dans la session. La récep-
tion de la requête SIP BYE au niveau du P-CSCF déclenche la fin
d’autorisation des ressources pour la session. Cela est représenté
par le bloc « Revoke authorization for resources » (cf. aussi § 3.9.4
«Procédure de QoS dans l’IMS »).
3.7.1 Fin de session initialisée par l’utilisateur
La figure 16 illustre un exemple de relâche de session initialisée
par l’appelant, le cas où la session est relâchée par l’appelé est
identique.
En parallèle de la relâche de la session, le terminal devrait relâ-
cher les ressources de la session (« Delete “PDP context”
request »). S’il ne le fait pas, le GGSN, passé un certain délai
configuré par l’opérateur, l’initie lui-même au sein de la procédure
de fin d’autorisation des ressources (bloc « Revoke authorization
for resources »).
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

Figure 16 – Fin de session initiée par l’utilisateur

Figure 17 – Fin de session initiée par le P-CSCF

3.7.2 Fin de session initialisée par le réseau
Le P-CSCF ou le S-CSCF (de sa propre initiative ou sur demande
du HSS) peut demander la relâche de session.
3.7.2.1 Fin de session initiée par le P-CSCF
Comme illustré en figure 17, le P-CSCF peut initialiser la fin de
session s’il reçoit une indication de perte de couverture radio ou si
les ressources de l’utilisateur sont supprimées par le réseau
(SGSN, GGSN). Pour terminer la session, le P-CSCF invoque la
procédure de fin d’autorisation des ressources (bloc « Revoke
authorization for resources ») et émet un message SIP BYE vers le
terminal distant afin que les ressources soient relâchées de son
côté également.
3.7.2.2 Fin de session initiée par le S-CSCF
(éventuellement sur demande du HSS)
Le S-CSCF peut initialiser la fin de session, par exemple du fait
de l’expiration de l’enregistrement (relative à une identité publique
de l’utilisateur et une adresse IP).
Le HSS peut demander au S-CSCF d’initialiser la fin de session,
par exemple du fait de la fin de la souscription de l’abonné IMS.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 17
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________
Figure 18 – Fin de session initiée par le S-CSCF
La procédure de relâche de la session initiée par le S-CSCF est
identique quelle que soit la raison. Comme illustré en figure 18, la
relâche de la session est initiée par le S-CSCF via une requête
« SIP BYE » envoyée vers l’appelé puis le S-CSCF émet un « SIP
BYE » vers l’appelant.
Le GGSN demande la relâche des ressources de la session lors
de la procédure de fin d’autorisation des ressources (bloc « Revoke
authorization for resources ») si le terminal ne lui adresse pas la
demande (via une requête « “PDP context” déactivation »).
3.8 Fin d’enregistrement
Au niveau de l’IETF, la commande de fin d’enregistrement utilise
le même message SIP que la demande d’enregistrement (à savoir
« SIP REGISTER ») mais une durée d’enregistrement nulle.
Au 3GPP, non seulement le terminal peut initier une fin d’enre-
gistrement mais également le réseau :
– le terminal demande notamment la fin d’enregistrement quand
l’utilisateur ne souhaite plus accéder à ses services. Cette procé-
dure démarre avec l’envoi d’un message SIP REGISTER depuis le
terminal ;
– la fin d’enregistrement peut survenir à l’initiative du réseau
pour différentes raisons explicitées plus loin. Cette procédure uti-
lise le message « SIP NOTIFY » et non plus le «SIP REGISTER ».
Lors de la fin d’enregistrement (initié par l’utilisateur ou le
réseau) :
– le terminal doit mettre fin à ses sessions en cours ;
– le HSS supprime l’adresse du S-CSCF stockée pour l’utilisateur
(il est possible de la conserver si cette option est souhaitée par
l’opérateur) ;
– les CSCF et le terminal suppriment les données d’enregistre-
ment correspondant à l’adresse publique et l’adresse IP pour
lesquelles la fin d’enregistrement est demandée ;
– le terminal et le P-CSCF suppriment l’association de sécurité
établie entre eux pendant l’enregistrement, s’il ne reste plus
d’enregistrement actif pour l’utilisateur.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
TE 7 512 – 18 est strictement interdite. – © Editions T.I.
3.8.1 Fin d’enregistrement initiée par l’utilisateur
La figure 19 illustre une fin d’enregistrement demandée par
l’utilisateur. Le S-CSCF initie la relâche des sessions actives de
l’utilisateur (pour l’identité publique et associées qui sont en cours
de fin d’enregistrement avec la même adresse IP) si le terminal
n’en a pas fait la demande avant la fin d’enregistrement.
Les données d’enregistrement sont supprimées sur réception du
« 200 OK » au « REGISTER ».
3.8.2 Fin d’enregistrement initiée par le réseau
Le S-CSCF peut initier la fin d’enregistrement en réaction à :
– une indication interne, typiquement l’expiration de la durée
d’enregistrement ;
– ou une indication externe, typiquement une demande émanant
du HSS, la procédure étant légèrement différente dans ce dernier
cas.
Dans les deux cas, le P-CSCF et le terminal sont notifiés (requête
« SIP NOTIFY ») de la fin d’enregistrement puisqu’ils y avaient
préalablement souscrit lors de l’enregistrement de l’utilisateur
dans l’IMS. Les données d’enregistrement sont supprimées sur
réception du « 200 OK » à « NOTIFY ».
■ Fin d’enregistrement initiée par le S-CSCF
La figure 20 illustre une fin d’enregistrement demandée par le
S-CSCF.
■ Fin d’enregistrement initiée par le HSS
Plusieurs raisons possibles ont été spécifiées au 3GPP pour ini-
tier la fin d’enregistrement depuis le HSS :
– la fin de souscription IMS de l’utilisateur ;
– l’allocation d’un nouveau S-CSCF pour servir l’utilisateur (cas
d’erreur où le S-CSCF assigné à l’utilisateur n’est pas joignable) ;
– une demande de réenregistrement de l’utilisateur via un autre
S-CSCF.
La figure 21 (page 20) illustre une fin d’enregistrement deman-
dée par le HSS quelle que soit la cause.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA

UE P-CSCF DNS I-CSCF S-CSCF HSS SLF

1. REGISTER

2. DNS Query/response

3. REGISTER

4. User-Authorization-Request

5. User-Authorization-Answer

6. User-Authorization-Request

7. User-Authorization-Answer

8. REGISTER
9. Server-Assignment-
Request

10. Server-Assignment-
Answer

11. 200 OK

12. 200 OK

13. 200 OK

Figure 19 – Fin d’enregistrement initiée par l’utilisateur

UE P-CSCF DNS I-CSCF S-CSCF HSS SLF

1. De-registration event occurs

2. NOTIFY

3. NOTIFY

4. 200 OK

5. 200 OK

6. NOTIFY

7. 200 OK

8. Service control

9. Server-Assignment-
Request

10. Server-Assignment-
Answer

Figure 20 – Fin d’enregistrement initiée par le S-CSCF

3.9 Gestion de la QoS dans l’IMS geantes (audio, vidéo, jeux interactifs qui ne se contentent pas du
« best effort »).
La gestion de la qualité de service consiste à attribuer de façon Des mécanismes de gestion de la QoS sont disponibles pour
optimale les ressources réseau de l’opérateur en ordonnant les l’IMS pour permettre :
priorités du trafic de chaque utilisateur en fonction de l’application – l’optimisation des ressources de l’opérateur préférable à un
utilisée. La qualité de service revêt un caractère important dès lors surdimensionnement du réseau ;
que le trafic réseau s’intensifie (avec des débits de plus en plus – la satisfaction de l’utilisateur avec une priorisation du trafic en
élevés) et que les applications deviennent de plus en plus exi- fonction du besoin de l’application.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

est strictement interdite. – © Editions T.I. TE 7 512 – 19
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________

UE P-CSCF DNS I-CSCF S-CSCF HSS SLF

1. De-registration event occurs

2. R egistration-
Term ination-Request

3. NO TIFY

4. NO TIFY

5. 200 O K

6. 200 OK

7. NO TIFY

8. 200 OK

9. Service control

10. Registration-
Term ination-Answ er

Figure 21 – Fin d’enregistrement initiée par le HSS

Figure 22 – Mécaismes de QoS dans l’IMS

3.9.1 Mécanismes de QoS dans l’IMS
Pour fournir à l’utilisateur une qualité de service de bout en
bout, il est impératif de gérer la qualité de service dans chaque
domaine et, en particulier, avec les réseaux externes.
Le 3GPP introduit une fonction « Service Based Local Policy »
(SBLP) optionnelle dans l’IMS qui permet de contrôler l’utilisation
des ressources engagées pour une session ou un service.
D’autres moyens de contrôler la qualité de service sont envi-
sageables seuls ou en combinaison avec SBLP, notamment des
mécanismes de QoS IP classiques à la frontière entre des
domaines gérés par des opérateurs différents :
– des mécanismes via une signalisation spécifique de négocia-
tion de bout en bout (par exemple RSVP, LDP) ;
– le marquage des paquets IP le long du flux de bout en bout
(par exemple DiffServ, MPLS) ;
– des accords entre opérateurs pour contractualiser la QoS aux
routeurs frontières entre les domaines des opérateurs.
La figure 22 illustre :
– la gestion de la QoS au niveau IP (blocs « IP BS manager ») ;
– la gestion de la QoS au niveau UMTS (blocs « UMTS BS
manager ») avec une fonction de traduction entre les deux ;
– la fonction SBLP via la relation PDP/PEP (Policy Decision
Point/Policy Enforcement Point).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie

TE 7 512 – 20 est strictement interdite. – © Editions T.I.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA
3.9.2 Fonction « Service Based Local Policy »
(SBLP) dans l’IMS
La fonction « Service Based Local Policy » (SBLP), optionnelle,
permet de contrôler l’utilisation des ressources engagées pour une
session ou un service IMS. En R5 et R6, cette fonction est implé-
mentée dans le PDF au niveau IP et fonctionne sur la base de déci-
sions envoyées depuis le PDF (qui agit en tant que Policy Decision
Point, PDP) vers le GGSN (pour un accès GPRS, le point de termi-
naison de connectivité IP) qui met en œuvre ces décisions (agit en
tant que Policy Enforcement Point, PEP). Le PDP et PEP sont locali-
sés dans le réseau du même opérateur avec une interface
intra-opérateur car il n’est pas concevable pour un opérateur que
ses ressources soient contrôlées par une entité située chez un
autre opérateur.
Le PDF définit pour une session chaque flux IP qui la compose,
un flux IP étant unidirectionnel et défini par le quintuple (adresse
IP source, port source, adresse IP destination, port destination,
protocole). Pour chaque flux IP, une « porte » est créée au niveau
du GGSN car les décisions du PDF seront relatives à un flux IP
(ouverture ou fermeture de « porte »).
Le PDF prend ses décisions sur la base des informations reçues
du P-CSCF dans la signalisation via l’interface Gq (cf. figure 22). Le
PDF transforme ces informations en paramètres de QoS IP selon
des règles de conversion standardisées et les transmet au GGSN
via l’interface Go (cf. figure 22). Le GGSN les convertit à son tour
en termes de paramètres de QoS UMTS de façon à établir les
limites de la QoS autorisée pour l’utilisateur et la session. Le termi-
nal dérive de son côté les paramètres de la session (SIP/SDP) en
paramètres de QoS UMTS de façon à demander des ressources
correspondant effectivement aux besoins de la session. Les diffé-
rentes conversions entre paramètres de QoS sont explicitées dans
le paragraphe 3.9.3 suivant au niveau du PDF, du GGSN et du
terminal.
3.9.3 Paramètres de QoS
3.9.3.1 Informations de session SIP/SDP dérivées
en paramètres de QoS IP au PDF
Les paramètres de QoS IP sont dérivés au PDF sur la base des
informations de session contenues dans la signalisation SIP. Il
s’agit plus spécifiquement du corps de message SDP du message
SIP, à savoir les lignes m, a et b du SDP :
– la ligne m indique le type de média par exemple audio ;
– les lignes a listent les attributs de média et indiquent notam-
ment si un média est bidirectionnel ou unidirectionnel ;
– la ligne b indique la bande passante.
L’autorisation QoS IP contient notamment pour chaque flux IP
de la session IMS :
– des paramètres de bande passante maximale autorisée dans le
sens entrant et dans le sens sortant (calculée sur la base de
l’en-tête bande passante indiquée dans le SDP du message SIP s’il
est présent, une valeur par défaut configurée par l’opérateur
sinon) ;
– un paramètre indiquant la classe de QoS maximale autorisée,
typiquement une classe A pour un média de type audio utilisant
RTP/RTCP.
3.9.3.2 Paramètres de QoS IP dérivés en paramètres
de QoS UMTS au GGSN
Les paramètres de QoS IP sont dérivés au GGSN en paramètres
de QoS UMTS pour chaque « PDP context » de la session IMS :
– des paramètres de bande passante maximale autorisée dans le
sens entrant et dans le sens sortant ;
– une classe maximale autorisée, par exemple classe de type
conversationnelle pour une classe de QoS IP de type A.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
est strictement interdite. – © Editions T.I.
3.9.3.3 Informations de session SIP/SDP dérivées
en paramètres de QoS UMTS au terminal
De son côté, le terminal dérive les paramètres de la session
(SIP/SDP) en paramètres de QoS UMTS de façon à demander des
ressources correspondant effectivement aux besoins de la session.
3.9.4 Procédures de QoS dans l’IMS
Diverses procédures de QoS sont définies afin de contrôler
l’usage des ressources au moyen de la fonction SBLP. Elles
reposent sur l’utilisation d’un jeton commun entre la couche appli-
cative et la couche transport en Rel-5/Rel-6. Le jeton est généré par
le PDF. Elles sont présentées ici pour le cas du GPRS mais sont
applicables à tout type d’accès (le GGSN étant considéré comme
un point de terminaison de connectivité IP comme un autre).
Les procédures servent à adapter les ressources aux besoins
applicatifs et sont invoquées notamment :
– lors de l’établissement de session pour assurer que les
ressources demandées par l’utilisateur sont conformes à la session
en cours d’établissement ;
– lors de la modification de session afin que les ressources néces-
saires soient engagées tout en assurant que des ressources ne
soient pas engagées en excès par rapport à l’autorisation de QoS ;
– la relâche de la session pour assurer que les ressources utili-
sées pour la session soient libérées et disponibles pour d’autres
utilisateurs si besoin.
3.9.4.1 Procédure d’autorisation des ressources
(déclenchée au P-CSCF, décision du PDF
vers le GGSN)
Cette procédure dite « Authorize QoS resources » consiste pour
le PDF à calculer une autorisation en termes de QoS IP sur la base
de la demande de niveau applicatif (sur le contenu de la signalisa-
tion SIP). Typiquement, une demande d’établissement de session
est reçue au P-CSCF sous la forme d’un message « SIP INVITE »
contenant un corps de message SDP qui décrit la session en
termes de média souhaité (par exemple un média audio). La pro-
cédure d’autorisation des ressources vise à dériver ces informa-
tions de session en paramètres d’autorisation de niveau IP, par
exemple caractériser un ou plusieurs flux de média avec une
bande passante autorisée associée. Le PDF génère un jeton d’auto-
risation qui servira à caractériser la session et qui devra être utilisé
par le terminal lors de la réservation des ressources. Le GGSN
dérive l’autorisation de QoS IP en paramètres de QoS UMTS.
3.9.4.2 Procédure de réservation des ressources
(déclenchée au terminal, demande de décision
du GGSN vers le PDF)
Cette procédure est initialisée par le terminal pour demander
des ressources au niveau du plan usager (par exemple, une de
demande d’activation de « PDP context ») pour transporter les flux
IP de la session IMS. Pour ce faire, le terminal convertit les para-
mètres de la session (contenus dans le SDP) en paramètres de
QoS de niveau transport, typiquement paramètres de QoS UMTS.
Lors de cette demande de ressources, le terminal utilise le jeton
d’autorisation correspondant à la session de manière que le GGSN
demande une décision au PDF pour ces ressources. Le PDF lui
retourne l’autorisation de QoS IP que le GGSN convertit en autori-
sation de QoS UMTS puis accepte la demande de ressources si
elle ne dépasse pas l’autorisation ainsi déterminée.
3.9.4.3 Procédure d’engagement de ressources
(déclenchée au P-CSCF, décision du PDF
vers le GGSN)
Cette procédure dite « Approval of QoS commit » consiste au
PDF à donner l’ordre au GGSN d’ouvrir les « portes » pour les flux
IP de la session, ce qui signifie que les paquets IP pour ce flux IP
peuvent traverser le GGSN pour joindre le réseau IMS.
TE 7 512 – 21
DOMAINE IP MULTIMÉDIA ___________________________________________________________________________________________________________
3.9.4.4 Procédure de désengagement des ressources
(déclenchée au P-CSCF, décision du PDF
vers le GGSN)
Cette procédure dite « Removal of QoS commit » consiste au
PDF à donner l’ordre au GGSN de fermer les « portes » pour les
flux IP de la session, ce qui signifie que les paquets IP pour ce flux
IP ne peuvent plus traverser le GGSN pour joindre le réseau IMS.
C’est la procédure inverse de celle décrite précédemment.
3.9.4.5 Procédure de fin d’autorisation des ressources
(déclenchée au P-CSCF, décision du PDF
vers le GGSN)
Cette procédure dite « Revoke authorization for resources » est
déclenchée notamment lors de la fin de session applicative (typi-
quement sur réception au P-CSCF d’un message SIP BYE). Le PDF
envoie au GGSN une décision de fin d’autorisation des ressources.
Le GGSN relâche les ressources (typiquement le GGSN initie un
message de type « Delete PDP context request ») si besoin (après
un délai configuré par l’opérateur). L’intérêt pour l’opérateur est
d’assurer que les ressources sont libérées dans le réseau même si
le terminal n’en fait pas la demande lui-même. C’est la procédure
inverse de la procédure d’autorisation des ressources.
3.9.4.6 Procédure d’indication de relâche de ressources
(information du GGSN vers le PDF)
Cette procédure dite « Indication of “PDP context” release » est
typiquement initialisée par le terminal lorsqu’il demande une
relâche des ressources (le terminal envoie un message de type
« Delete “PDP context” request ») mais le SGSN ou le GGSN
peuvent également demander la relâche des ressources. Le GGSN
remonte cette indication au PDF qui en informe le P-CSCF. Le
P-CSCF peut alors initialiser la relâche de la session au niveau
applicatif (à supposer que c’est le dernier « PDP context » pour la
session IMS) typiquement en initialisant un message SIP BYE.
3.9.4.7 Procédure d’indication de modification
de ressources (déclenchée au terminal, demande
de décision du GGSN vers le PDF)
Cette procédure dite « Authorization of “PDP context”
Modification » est initialisée par le terminal lorsqu’il demande une
modification des ressources (typiquement le terminal envoie un
message de type « Modify “PDP context” request »). Le GGSN
remonte cette indication au PDF lorsque les ressources demandées
dépassent l’autorisation de QoS UMTS calculée au GGSN. Le
GGSN demande une prise de décision au PDF, notamment le refus
de la demande ou une modification de la demande de ressources
à la limite autorisée. En option au choix de l’opérateur, le PDF
remonte l’indication vers le P-CSCF.
3.9.4.8 Procédure d’indication de ressources à 0 kbit/s
(indication du GGSN vers le PDF)
Cette procédure dite « Indication of “PDP context” modification »
est initialisée par le SGSN en cas de perte de couverture radio. Le
SGSN demande la modification des ressources à 0 kbits/s pour des
« PDP contexts » de type conversationnel ou de streaming. Le
GGSN qui reçoit cette demande notifie le PDF qui en informe le
P-CSCF. Le P-CSCF peut initialiser la relâche de la session.
3.9.4.9 Procédure de mise à jour d’autorisation
des ressources (déclenchée au P-CSCF, décision
du PDF vers le GGSN)
Cette procédure dite « Update authorization » consiste pour le PDF
à calculer une nouvelle autorisation en termes de QoS IP sur la base
de la demande de niveau applicatif. Typiquement, une demande de
modification de session est reçue au P-CSCF sous la forme d’un mes-
sage « SIP UPDATE » ou « re-INVITE ». Le P-CSCF transmet les nou-
veaux paramètres de la session (SDP du message « SIP UPDATE »
ou « re-INVITE ») au PDF qui les dérive en paramètres de QoS IP.
Le PDF peut rapporter cette mise à jour d’autorisation au GGSN
(mais attend de préférence une demande du GGSN lorsque le ter-
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
TE 7 512 – 22 est strictement interdite. – © Editions T.I.
minal demandera la mise à jour des ressources). Le GGSN dérive
l’autorisation de QoS IP en paramètres de QoS UMTS. Le GGSN
peut initialiser une demande de modification des ressources
(« Update “PDP context” request » initié par le GGSN) si les res-
sources en cours excédent la nouvelle autorisation et le terminal ne
demande pas la mise à jour des ressources (« Modify “PDP context”
request » initié par le terminal) après une temporisation.
4. Sécurité dans l’IMS
Différents mécanismes de sécurité sont prévus en Rel-5/Rel-6
pour assurer la sécurité dans l’IMS :
– l’authentification de l’utilisateur et la montée du tunnel IPSec
entre le terminal et le P-CSCF lors de l’enregistrement dans l’IMS ;
– l’introduction de passerelles de sécurité entre domaines de
sécurité ;
– la fonction I-CSCF(THIG) à la sortie du réseau « home » (entre
le S-CSCF de l’appelant et le I-CSCF de l’appelé).
4.1 Authentification
Le mécanisme utilisé pour l’authentification est IMS-AKA
(Authentication and Key Agreement) qui 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). Le HSS, toujours
localisé dans le réseau « home » de l’utilisateur, contient un quin-
tuple d’authentification :
– un challenge aléatoire, RAND ;
– un jeton d’authentification, AUTN (contenant un numéro de
séquence et un identifiant MAC) ;
– une réponse attendue XRES ;
– une clé de cryptage, CK, et une clé d’intégrité, IK, qui assurent
l’intégrité et la confidentialité des messages SIP échangés entre le
terminal et le P-CSCF.
Durant l’enregistrement, le S-CSCF transmet les paramètres
RAND et AUTN au terminal qui s’en sert pour calculer une réponse
attendue XMAC. L’authentification est mutuelle entre l’utilisateur
et le réseau (S-CSCF) :
– le terminal compare son XMAC avec le MAC reçu du réseau :
le réseau est authentifié s’ils sont identiques ;
– le réseau compare son XRES avec le RES calculé par le
terminal : l’utilisateur est authentifié s’ils sont identiques.
Il est à noter que l’authentification dans l’IMS réutilise les principes
d’authentification de l’UMTS (UMTS AKA). Aussi, certains mécanis-
mes de l’UMTS-AKA peuvent être partagés avec IMS-AKA. En par-
ticulier, tous les mécanismes de l’UMTS-AKA sont réutilisés si le
terminal contient une USIM (équivalent de la carte SIM pour l’UMTS)
et non une ISIM (équivalent de la carte SIM pour l’IMS), à savoir :
– la clé d’authentification K qui sert à calculer les paramètres
d’authentification (XMAC, RES, IK, CK) ;
– les algorithmes de sécurité pour calculer les clés de sécurité ;
– le mécanisme de vérification du numéro de séquence qui sert
à synchroniser les clés de sécurité entre le terminal et le réseau.
Lorsque seule l’USIM est utilisée, il faut dériver les paramètres
utiles à l’IMS (qui seraient normalement sur l’ISIM) depuis l’IMSI
(identifiant de l’utilisateur pour l’UMTS) stocké sur l’USIM :
– l’identité privée de l’utilisateur qui est une identité publique
temporaire qui ne sert que lors de l’enregistrement, les identités
publiques associées peuvent en revanche être utilisées ;
– une identité publique de l’utilisateur ;
– le nom de domaine.
Nota : un mécanisme a été introduit pour assurer l’authentification des terminaux qui
accèdent à l’IMS sans USIM ni ISIM (typiquement des terminaux 2G n’implémentant pas
de fonction IPSec). Ce mécanisme associe l’adresse IP du terminal et les identités de l’uti-
lisateur (identité privée, identités publiques) au niveau du S-CSCF, ce qui permet de
vérifier que les messages SIP reçus au S-CSCF ne proviennent pas d’un autre utilisateur.
____________________________________________________________________________________________________________ DOMAINE IP MULTIMÉDIA
Figure 23 – Passerelles de sécurité dans l’IMS
4.2 Tunnel IPSec entre terminal
et P-CSCF
Les messages de signalisation SIP sont protégés grâce à la mon-
tée d’associations de sécurité entre le terminal et le P-CSCF. Les
clés utilisées pour les associations de sécurité sont CK et IK :
– l’intégrité des données (qui assure que les messages SIP ne
sont pas modifiés et l’authentification de l’émetteur du message)
est obligatoire en Rel-5/Rel-6 et rendue grâce à IPSec ESP ;
– la confidentialité des données (c’est-à-dire le cryptage) est obli-
gatoire en Rel-6 seulement.
4.3 Passerelles de sécurité
Des passerelles de sécurité (SEG pour Security gateway) sont
introduites à la frontière entre deux domaines de sécurité. Une
protection de type IPSec ESP en mode tunnel est obligatoire entre
deux passerelles de sécurité (IPSec peut assurer intégrité et
confidentialité) tandis qu’elle est optionnelle entre deux nœuds
d’un même domaine de sécurité.
Typiquement, lorsque le P-CSCF, I-CSCF et S-CSCF appartien-
nent au même réseau, la protection IPSec de leurs échanges est
optionnelle. En revanche, un échange entre deux CSCF d’opéra-
teurs différents doit être protégé par IPSec comme l’illustre la
figure 23 (tunnels IPSec en rouge entre deux SEG en jaune).
Il est à noter également qu’un échange entre une entité de l’IMS
et une entité d’un réseau non IMS peut être protégé par TLS
(Transport Layer Security), typiquement pour l’interfonctionne-
ment en Rel-6 de SIP entre le S-CSCF dans l’IMS et un proxy SIP
externe dans un réseau non IMS (en vert sur la figure 23). Le
S-CSCF gère localement une liste de partenaires pour l’interfonc-
tionnement, ce qui lui permet de décider s’il peut faire confiance à
ce proxy SIP.
4.4 Fonction I-CSCF(THIG)
La fonction THIG est implémentée en option à l’intérieur du
I-CSCF et a pour rôle de crypter/décrypter les en-têtes SIP qui
renseigneraient sur la topologie du réseau « home », par exemple
les en-têtes « Via », « Route », « Record-Route », « Path » qui mon-
treraient les adresses des nœuds de réseau traversés par une
requête SIP.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie
est strictement interdite. – © Editions T.I.
5. Conclusion
Le domaine IP multimédia défini dans l’organisme de standardi-
sation pour la téléphonie mobile de troisième génération promet la
création de services de façon simple. De plus, la mise sur le mar-
ché de ces services sera plus rapide grâce à une architecture indé-
pendante des technologies du réseau de l’opérateur.
Pour le déploiement de services (prenant en considération par
exemple l’appel multimédia entre deux utilisateurs), l’IMS prend
en compte un grand nombre de fonctionnalités réseau telles que
l’identification et l’authentification de l’utilisateur, la gestion de la
qualité de service, la sécurité, etc. Ces fonctionnalités sont mises
en œuvre au sein des procédures réseau définies pour l’IMS. En
particulier, l’enregistrement permet à l’utilisateur de faire connaître
sa localisation actuelle (son adresse IP attribuée dynamiquement
en général) afin d’accéder à ses services IMS. L’établissement de
session ainsi que les modifications pour ajouter ou supprimer des
médias par exemple sont également pris en charge dans le réseau
IMS ainsi que la relâche de session et la fin d’enregistrement. Le
contrôle des ressources utilisées pour les services IMS est géré
dynamiquement via la fonction « Service based local policy » qui
fait interagir le niveau applicatif (P-CSCF de l’IMS) avec le niveau
transport (GGSN pour le GPRS par exemple) via l’entité PDF
(Policy control decision en Rel-5/Rel-6).
La réalisation des services repose essentiellement sur le proto-
cole SIP, protocole de signalisation de référence dans l’IMS. Une
coordination s’avère donc nécessaire entre le 3GPP et l’IETF pour
prendre en considération les besoins spécifiques du 3GPP (ce pro-
tocole doit être utilisable dans le contexte IMS défini au 3GPP). En
effet, le réseau IMS peut mettre fin à un appel en cas de rupture de
ressources ou de fin de souscription de l’utilisateur.
L’IP multimédia permet l’accès aux mêmes services de l’utilisa-
teur via différents types d’accès (GPRS, I-WLAN, xDSL) depuis le
point de terminaison de connectivité IP de l’utilisateur (GGSN pour
le GPRS, PDG pour I-WLAN). En tant que service IP, l’IMS pourra
aussi être invoqué via de futures architectures de réseaux telles
que l’architecture SAE qui prévoit l’utilisation d’un support de
transmission évolué ne tenant plus compte de la technologie
d’accès. La continuité des services IMS est également à considérer
via des architectures de gestion de la mobilité telles que MMSC en
cours de spécification, l’intérêt pour l’utilisateur étant de continuer
l’usage de son service même lorsqu’il passe d’une technologie à
l’autre en cours de communication (par exemple, depuis le GPRS
vers I-WLAN).
TE 7 512 – 23