Ims

3me Anne du cycle ingnieur
Brique RMOB
Trimestre 2
Encadrant M. Philippe MARTINS
Etude des procdures

denregistrement et dtablissement de session
en IMS
Avril 2006
Par
MROUEH Lina et LABAKY Elie
Enregistrement et tablissement de session en IMS
Sommaire
Sommaire ................................................................................................................................... 2
Table des Figures ....................................................................................................................... 2
Remerciement............................................................................................................................. 3
Rsum ....................................................................................................................................... 4
Introduction ................................................................................................................................ 5
1. Prsentation de larchitecture IMS......................................................................................... 6
1.1. Larchitecture fonctionnelle de lIMS............................................................................. 6
1.2. Gestion des identits en IMS........................................................................................... 9
1.2.1. Public User Identity.................................................................................................. 9
1.2. Private User Identity.................................................................................................... 9
1.2.3. Relations entre Public et Private User Identity ...................................................... 10
1.3. Les cartes USIM et ISIM .............................................................................................. 10
1.3.1. USIM (Universal Subscriber Identity Module)...................................................... 11
1.3.2. ISIM (IMS Subscriber Identity Module)................................................................ 11
1.4. Type de Signalisations en IMS...................................................................................... 11
2. Procdure denregistrement dans IMS REGISTER........................................................ 12
2.1. Prambule...................................................................................................................... 12
2.2. Procdure denregistrement........................................................................................... 13
2.2.1. Dcouverte du P-CSCF .......................................................................................... 14
2.2.2. LEnregistrement IMS (avec un ISIM) .................................................................. 14
2.2.3. Enregistrement avec un USIM ............................................................................... 17
2.2.4. Les Messages SIP................................................................................................... 18
2.2.5. Les Messages Diameter.......................................................................................... 22
2.2.6. Souscription ltat denregistrement du terminal reg Event State ................. 23
3. Procdure dtablissement de session en IMS INVITE.................................................. 24
3.1. Etape 1 : Invite et Session Progress .............................................................................. 24
3.2. Etape 2: Prack Request.................................................................................................. 32
3.4. Etape 3: Alerter lappel ............................................................................................... 33
Conclusion................................................................................................................................ 34
Glossaire................................................................................................................................... 35
Rfrences ................................................................................................................................ 37
MROUEH Lina & LABAKY Elie
Page 2
15/04/2006
Table des Figures

Figure 1.1.a : Architecture fonctionnelle IMS. .......................................................................... 6
Figure 1.2.3.a : Relation entre lidentit prive et publiques en IMS 3GPP R5. ..................... 10
Figure 1.2.3.b : Relation entre lidentit prive et publiques en IMS 3GPP R6. ..................... 10
Figure 2.1.a : Procdure gnrale pour obtenir le service IMS................................................ 13
Figure 2.2.2.a : Procdure denregistrement. ........................................................................... 15
Figure 2.2.6.a : Souscription ltat denregistrement (Suite de la procdure
denregistrement). .................................................................................................................... 24
Figure 3.1.a : Invite + Session Progress ................................................................................... 25
Figure 3.2.a : Suite de la procdure dtablissement de session. ............................................. 32
Figure 3.4.a : Suite de la procdure dtablissement de session. ............................................. 34
Page 3
15/04/2006
Remerciement
On tient remercier de tout cur Monsieur Philippe Martins pour son encadrement et
de nous avoir donn loccasion de travailler sur un sujet novateur comme lIMS.
Page 4
15/04/2006
Rsum
Ce projet consiste faire ltude de la procdure denregistrement et dtablissement

de session dans les rseaux IMS.
Dans la premire partie on prsentera en gros larchitecture fonctionnelle de lIMS
ainsi que la gestion des identits et le types de cartes puces utilis. Puis on prsentera le type
de signalisation dans lIMS. Ces informations forment les prs requis pour les parties
suivantes.
Dans la deuxime et la troisime partie on expliquera en dtail respectivement la
procdure denregistrement et la procdure dtablissement de session.
Page 5
15/04/2006
Introduction
A nos jours les pratiques technologiques sont en train dvoluer, tel que lInternet
mobile, la tlphonie mobile, le multimdia Les oprateurs estiment lmergence des
nouveaux services multimdia quil faut fournir indpendamment du temps, du lieu et des
mthodes daccs travers des quipements mobiles. En ralit, ni le rseau RTC, ni
lInternet ne correspondent aux besoins futurs. On entend beaucoup aujourdhui de la
tlphonie sur IP et de la vido sur IP souvent dans les accs xDSL ; donc on se dirige vers
une convergence des rseaux des tlcommunications. Or cette convergence ncessite un
nouveau rseau qui est le NGN (Next Generation Network) quon peut appeler New
Generation Network comme il nest plus Next .
On envisage utiliser un mme plan de transport pour offrir la fois les services
rseaux de donnes et les services tlcoms comme la vido et la voix. Ceci ncessite le
dploiement dun rseau de transport commun donnant tous les types de QoS, ainsi que le
dveloppement dune architecture de service commune et un plan contrle.
De son cot lIMS sera le plan contrle de cette nouvelle infrastructure NGN o lIP
sera le plan transport. LIMS est une architecture softswitch avec une couche service trs
volue ce qui permet de raliser des services tlcoms traditionnels et des nouveaux services
multimdia. Avec larchitecture softswitch on a procd la rupture du lien troit entre le
plan transport (Matrice de commutation) et le plan de contrle des commutateurs (Unit de
contrle). Dans IMS, le plan contrle sera bas SIP avec un plan transport unifier IP.
Loriginalit dIMS est le faite dtre transparent aux rseaux daccs qui peuvent tre des
rseaux mobile (GSM, UMTS) ou fixe (RTC, xDSL) et ceci travers une couche
transport unique IP. Donc lIMS sera le mme rseau dinfrastructure pour les rseaux fixe et
mobile et il assurerait une double convergence fixe/Mobile, circuit/paquet. Actuellement
lIMS est normalis par le 3GPP comme une nouvelle volution des rseaux mobiles.
La rvolution majeure introduite par lIMS dans le monde des tlcommunications est
le passage du mode Visited Service Control au Home Service Control . Ce nouveau
paradigme permet un terminal de rester attacher au mme rseau nominal quelque soit le
rseau visit et tous les services de lutilisateur seront effectu et contrl par le rseau
nominal sans aucun chargement de profil dans le rseau visit. Or dans lancienne approche
on devait tlcharger le profil de lutilisateur du rseau nominal au rseau visit ainsi que des
marques CAMEL par exemple pour que la plateforme de service du rseau nominal puisse
manipuler les switch du rseau visit afin doffrir le mme service lutilisateur dans le
rseau visit.
Page 6
15/04/2006
1. Prsentation de larchitecture IMS

1.1. Larchitecture fonctionnelle de lIMS
Dans cette partie, on va faire une description synthtique des diffrents composants de
larchitecture IMS :
Figure 1.1.a : Architecture fonctionnelle IMS.
HSS : Home Subscriber Server

Le HSS est lquivalent du HLR de GSM.
Elle contient toutes les informations ncessaires un utilisateur pour ouvrir une
session multimdia :
des informations sur la localisation de lutilisateur.
le profil de lutilisateur cest dire lensemble des services auxquels
lutilisateur est abonn.
Ladresse du S-CSCF allou lutilisateur.
Des informations de scurits.
Le SLF est une base de donnes contenant pour chaque utilisateur le HSS
correspondant dans le cas ou le rseau contient plusieurs HSS.
C-CSCF: Call/Session Control Function

Le C-CSCF est un serveur SIP qui traite la signalisation SIP en IMS. Il existe 3 types
de C-CSCF :
P-CSCF: Proxy CSCF

Le P-CSCF est le premier point de contact usagers avec IMS : Toute la signalisation
SIP du UE et vers le UE passe via le P-SCSF. Le P-CSCF est allou lutilisateur dans la
phase de registration et ne change pas durant toute la dure de registration. Le P-CSCF peut
tre localis dans le home network, comme dans le visited network.
Page 7
15/04/2006
Les diffrentes fonctionnalits :

Scurit :
Il maintient des associations de scurit IPsec entre lui et lquipement
terminal.
Authentification de lutilisateur.
Il maintient un cache local pour la localisation du S-SCSF associ lutilisateur.
La compression / dcompression des messages SIP.
Le P-CSCF inclut les fonctionnalits du Policy Decision Function (PDF). Le PDF gre
les exigences QoS pour les services et authorise lallocation des ressources.
La gnration de CDRs (Call Detailed Record) taxation.
I-CSCF : Interrogating CSCF
LI-CSCF est localis dans le home network.
Fait une premire autorisation pour laccs au rseau IMS.
Pour une requte SIP, il contacte le HSS pour identifier le S-CSCF correspondant et
renvoie les messages de cette session ce S-CSCF (Protocole Diameter sur linterface
I-CSCF HSS).
Peut incluse une fonctionnalit de masquage de larchitecture du rseau de loprateur
par rapport au rseau visit.
S-CSCF : Serving CSCF

Les fonctions ralises par le S-CSCF pendant une session comprennent :
Le S-CSCF est toujours localis dans le home network.
SIP Registrar : Il maintient lassociation entre ladresse IP du terminal et le SIP
adresse de lutilisateur (Public User Identity).
Tlcharger le profil de lutilisateur de HSS :
A travers les filter criteria , le S-CSCF envoi les requtes SIP satisfaisant
ces critres vers des serveurs dapplications correspondant au service demand.
De cette faon il fourni des services de type rseau intelligent (Signalisation
dintelligence).
Authentification, enregistrement.
Service de translation : Consultation du DNS pour traduire le TEL-URI en SIP-URI.
Il obtient ladresse de lI-CSCF dans le rseau destinataire lors de ltablissement de
session.
Serveurs dapplications (AS)

Il y a 3 types de serveur qui agissent comme un serveur SIP du point de vue du rseau IMS.
Serveur SIP dapplication qui effectue des services IP multimdia bas SIP.
OSA-SCS (Open Service Access Service Capability Server): Cest une gateway
OSA qui implmente lAPI Parlay. Elle permet des serveurs dapplication tiers
daccder au rseau IMS dune faon scuris pour fournir des services aux
utilisateurs.
Page 8
15/04/2006
IMS-SSF (IP Multimedia Service Switching Function) : permet de rutiliser les

services CAMEL dvelopper pour les technologies GSM et GPRS. Donc une
gsmSCF peut contrler une session IMS grce ce serveur.
MRF : Media Ressource Function

Le MRF est divis en deux nuds :
Signaling plane node : MRFC (Media Ressource Function Controller)
SIP user Agent : La MRFC interprte la signalisation SIP reu via SCSCF
Media Plane node : MRFP (Media Ressource Function Processor). La MRFP
offre les ressources du plan usager qui sont demands et commands par la
MRFC et ralise les fonctions suivantes :
Mixage des flux Media provenant du UE
Traitement du flux mdia (ex : transcodage audio, analyse du mdia).
Source de flux mdia (pour les annonces multimdia).
BGCF: Breakout Gateway Control Function
Serveur SIP qui possde des fonctionnalits de routage lorsquil sagit dune session
initi par un terminal IMS et destin un utilisateur dans un rseau commut circuit
(cas de PSTN, PLMN).
Prsente deux fonctionnalits essentielles :
Choisir le rseau appropri pour sinterfacer avec le domaine CS.
Ou choisir un Gateway (MGCF) si le passage vers le CS a eu lieu dans le
mme rseau que le BGCF.
PSTN/CS Gateway
Les PSTN gateways constituent une interface vers les rseaux commuts circuit. Cette
interface prsente plusieurs entits fonctionnelles suivant larchitecture Softswitch :
SGW : Signalling Gateway
Cest la fonction de transcodage de signalisation, qui permet grce SIGTRAN de
transporter la signalisation SS7 sur IP, et davoir une interface NNI de signalisation
avec les rseaux commutation de circuits.
Effectue des conversions dans les protocoles de couche bas (Transport)
transport : Remplace la couche de transport MTP de SS7 par SCTP (Stream
Control Transmission Protocol) sur IP.
Conversion dISUP/MTP en ISUP/SCTP/IP.
MGCF/ Media Gateway Control Function
Elle permet de contrler les MGW, et elle sinterface avec la SGW grce SIGTAN
pour lchange de la signalisation.
passerelle qui permet la communication entre IMS et les usagers dans le
domaine de commutation de circuits CS.
Conversion de lISDN User Part (ISUP) ou le Bearer Independent Call Control
(BICC) en protocole SIP.
MGW Meadi Gateway
Interface pour le plan de donnes entre le rseau IMS/IP et les rseaux PSTN
commutation de circuit. (Transport de la voix).
Page 9
15/04/2006
Dun ct, elle est capable denvoyer et de recevoir flux IMS sur le
protocole RTP Real-Time Protocol.
Dun autre ct, utilise le PCM (Pulse Code Modulation) pour coder la
voix et la transmettre sur des times slots au rseau CS.
Fonction de transcodage quand le terminal IMS ne supporte pas le codesc
utilis par le CS. Par ex, Terminal IMS utilise AMR, tandis que le terminal
PSTN utilise G711.
1.2. Gestion des identits en IMS

Comme dans tout type de rseau, il est impratif de pouvoir identifier les utilisateurs
dune faon unique de telle manire quils soient joignables de nimporte quel rseau. Dans
IMS il y a un nouveau concept didentification par rapport ce qui ce faisait dans les rseaux
mobile tout en restant compatible avec. Cette identification peut paratre un peu trange et
compliqu mais elle fourni plus de flexibilit pour raliser des nouveaux services. (La
technique didentification est prise de SIP)
1.2.1. Public User Identity
Cest une adresse publique qui permet didentifier un utilisateur. Loprateur attribut
une ou plusieurs adresse publique pour chaque utilisateur IMS. Cest la grande nouveaut, ce
qui permet lutilisateur de sparer son identit personnel, familiale et daffaire pour gnrer
des services diffrents. Lidentit publique de lutilisateur est lquivalent du MSISDN en
GSM, donc cest une adresse de contacte qui permet de joindre un abonn, elle sert router
les messages SIP. La Public User Identity peut tre sous deux formats :

SIP URI : sous la forme sip : premier.dernier@oprateur.com . Il est aussi
possible dinclure un numro de tlphone dans une SIP URI qui sera sous le format :
sip : +1-961-007-007@oprateur.com ; user=phone .

TEL URL : permet de reprsenter un numro de tlphone dans un format
international tel : +1-961-007-007 . Il est impossible de senregistrer avec un TEL
URL, il faut toujours une SIP URI pour se faire. Mais le TEL URL est utilis pour faire
des appels entre le monde RTC et le monde IMS. Or en RTC les tlphones sont
identifis par des numros et ne peuvent composer que des numros. Donc loprateur
IMS doit allouer chaque utilisateur au moins une SIP URI et un TEL URL.
1.2. Private User Identity

On affecte une identit prive pour chaque utilisateur. Cette identit joue le mme rle
que lIMSI en GSM, elle permet dauthentifier labonn et pour lenregistrement. Elle prend
le
format
dun
Network
Access
Identifier
qui
est
la
suivante :
username@oprateur.com . La Private User Identity est stocke dans la carte puce.
1.2.3. Relations entre Public et Private User Identity

Dans le cas GSM/UMTS, la carte puce stocke lidentit prive et au moins une
identit publique. Le HSS contient pour chaque utilisateur son identit prive et la collection
Page 10
15/04/2006
didentit publiques qui lui est attribu. Notons que dans le cas ou lutilisateur utilise une
carte GSM/UMTS qui ne contient pas ces informations, le terminal est capable de les
construire travers lIMSI (Voire la procdure denregistrement par USIM). La relation entre
lutilisateur IMS et ces identits dans la Release 5 est montr par la figure suivante :
Figure 1.2.3.a : Relation entre lidentit prive et publiques en IMS 3GPP R5.
Dans lIMS 3GPP Release 6, un abonn peut avoir plusieurs identits prives. Dans le
cas de lUMTS seulement une identit prive peut tre contenu dans la carte puce mais
lutilisateur peu avoir plusieurs cartes contenant chacune une identit prive diffrente. Il est
encore possible dutiliser simultanment la mme identit publique avec plusieurs identits
prives (deux cartes insres dans deux terminaux diffrents).
Figure 1.2.3.b : Relation entre lidentit prive et publiques en IMS 3GPP R6.
1.3. Les cartes USIM et ISIM

Dans chaque terminal, il y a une carte puce appele UICC (Universal Integrated
Circuit Card). LUICC est utilis pour stocker des informations telles que ltat
denregistrement, clefs dauthentifications, message et un carnet dadresses. LUICC contient
plusieurs applications logiques qui peuvent tre : la SIM, lUSIM et lISIM.
1.3.1. USIM (Universal Subscriber Identity Module)
Elle est utilise pour laccs au rseau UMTS en mode circuit ou paquet. Elle contient
les paramtres suivants :

IMSI : comme en GSM elle permet didentifier lutilisateur et lauthentifier. La
Private user Identity est lquivalent lIMSI mais en IMS.
Page 11
15/04/2006

MSISDN : contient une ou plusieurs numros de tlphone pour lutilisateur.
La Public User Identity est lquivalent au MSISDN mais en IMS.

CK (Ciphering Key) et IK (Integrity Key) : se sont les clefs de chiffrement et
dintgrit utiliss pour la scurit de linformation sur linterface radio.

Long term secret : secret utilis pour authentifier lutilisateur et pour gnrer
les clefs de chiffrement et dintgrit utilis entre le terminal et le rseau.

SMS : Dans ce champ on va stocker les messages courts (reu et envoy avec
leur tat).

SMS parameters : paramtres de configuration du service SMS (exemple :
adresse du SMS centre).

MMS user connectivity parameters : contient les paramtres de configuration
du service MMS (exemple : adresse du MMS server et du MMS gateway).

MMS user preferences : contient les prfrences de lutilisateur sur le service
MMS comme le drapeau de rapport dexpdition.
1.3.2. ISIM (IMS Subscriber Identity Module)
Elle contient les paramtres utiliss pour lidentification et lauthentification de
lutilisateur ainsi que la configuration du terminal IMS. ISIM peut co-exister simultanment
avec une USIM ou une SIM. Les paramtres essentiels contenus dans une ISIM sont :

Private User Identity

Public User Identity

Home Network Domain URI : SIP URI du rseau nominal de lutilisateur qui
est unique dans la carte.

Long-term secret : secret utilis pour authentifier lutilisateur et pour gnrer
les clefs de chiffrement et dintgrit utilis entre le terminal et le rseau. Les messages
SIP envoys entre le terminal et le P-CSCF sont chiffrs et protgs par la clef
dintgrit.
1.4. Type de Signalisations en IMS

Dans tout type de rseau il y a toujours quatre types de signalisations ; dans IMS la
signalisation est raliser essentiellement par SIP :

Signalisation denregistrement : cest la signalisation par la quelle un terminal
senregistre dans le rseau. Elle contient les procdures de tlchargement du profile et
la gestion de la localisation. Cette signalisation est effectue par la procdure
denregistrement SIP (SIP REGISTER).

Signalisation dappel : cest la signalisation par la quelle on tablit une
association de bout en bout entre les points dextrmit dsirant communiquer, cest
caractris par lchange de rfrence. Ceci est ralis en IMS grce la procdure
dtablissement de session (SIP INVITE).

Signalisation de connexion : cest laffectation dun service support un appel.
De proche en proche on va rserver des ressources dans le rseau selon la QoS requise
pour le service. Au niveau SIP cette signalisation est effectue grce aux enttes SDP
qui permettent de dcrire le trafic et le ressources requis. Au niveau transport on utilise
les mcanismes RSVP, DiffServ, MPLS pour faire la qualit de service dans le rseau
IP.

Signalisation dintelligence : cest la signalisation qui nous permet de faire un
traitement substitutif par rapport au traitement dappel normal. Dune faon similaire
Page 12
15/04/2006
aux rseaux intelligent de type RI (INAP) ou CAMEL, les services sont excuter par
lquivalant aux plateformes de service qui sont des serveurs dapplications (AS). Un
autre type de signalisation SIP est utilis sur linterface ISC entre les AS et les S-CSCF.
Comme SIP ne dcrit pas le flux mdia on utilise en plus le protocole SDP (Session
Description Protocol). SDP est transport dans le cur des messages SIP et il dcrit les
sessions multimdia en termes de codeur audio, vido, informations de session (bande
requise, type de flux) et adressage multicastCes informations seront exploites pour faire
la rservation de ressource dans le plan transport.
Certaines interfaces internes du rseau IMS utilisent la signalisation Diameter et
nom pas SIP. Cest une application standardis par le 3gpp qui permet dinterfacer diffrentes
entit du rseau IMS. Les changes Diameter sont toujours du type un message requte et une
rponse associ. Les informations changes dans ces messages sont mis dans des attributs
appels AVP (Attribute Value Pairs). Chaque interface Diameter a ces AVPs et ces
commandes.
2. Procdure denregistrement dans IMS REGISTER

2.1. Prambule
Dans cette partie, on va expliquer le droulement de la procdure denregistrement en
IMS. Cest une procdure daccs au rseau IMS qui permet un terminal de se dclarer
joignable de point de vue service IMS. Comme tout autre procdure daccs (Mise jour de
localisation GSM, attachement GPRS), le terminal sera authentifi par le rseau IMS et son
profil sera charg dans le S-CSCF nominal qui est une sorte de central de rattachement ou un
MSC/VLR qui est allou lutilisateur quelque soit sa localisation dans le monde. Le S-CSCF
contient ladresse du Proxy P-CSCF o le terminal est rattach (quivalent un BSC pour
caricaturier).
Il faut garder lesprit que le rseau IMS est en dessus de tous types de rseaux qui
peuvent servir lattachement du terminal au systme IMS (GSM, GPRS, UMTS, WiMax,
xDSL, RTC). De plus toutes les procdures denregistrement, authentification et
chargement de profiles qui se font au niveau IMS sont indpendantes des procdures dans les
rseaux daccs. La localisation gographique du terminal nest plus importante car il sera
toujours rattach son rseau nominal travers le Proxy du rseau visit.
Afin dexpliquer la procdure, on va prendre lhypothse que le terminal est un
terminal UMTS qui est dans son rseau nominal et que lutilisateur sattache au service IMS
de son oprateur. Donc au pralable le mobile dj tablit un contrat daccs au service IMS
de son oprateur UMTS. (Cest la mme procdure si lutilisateur est dans un rseau visit).
La procdure denregistrement se fait en plusieurs tapes :
1. Attachement au rseau UMTS.
2. Activation dun Contexte PDP, avec obtention dune adresse IPv6 et dun APN qui
donne une connexion vers le rseau IMS travers une connectivit IPv6.
3. Dcouvert du P-CSCF.
4. Enregistrement IMS.
5. Souscription ltat denregistrement du mobile reg Event State .
Page 13
15/04/2006
Concernant lobtention dune adresse IP, aprs que le mobile soit attach au rseau
UMTS, il demande louverture dun PDP contexte au SGSN demandant laccs un APN
(Access Point Name) particulier et la connectivit un rseau IPv6. LAPN dsigne la
connexion vers un rseau IMS. En fonction de cet APN et le type de connectivit le SGSN
choisi le GGSN appropri et ouvre avec lui la suite du PDP contexte. Le GGSN va fournir au
mobile un prfixe dadresse IPv6 de 64bits (au lieu dune adresse complte) et lenvoie dans
la rponse louverture du PDP contexte. Le SGSN transmet dune faon transparente le
prfixe IPv6 au terminal qui lui va choisir alatoirement un suffixe IPv6 de 64bits, pour
former en tout, une adresse IPv6 de 128bits. Notons que si lIP CAN nest pas du type
GPRS/UMTS, le terminal obtiendra une adresse IPv6 en utilisant probablement un protocole
tel que le DHCPv6.
Figure 2.1.a : Procdure gnrale pour obtenir le service IMS.
2.2. Procdure denregistrement

La procdure denregistrement est constitue de plusieurs tapes. Tout dabord le
terminal doit obtenir ladresse IP du P-CSCF cette procdure sappel P-CSCF Discovery. Puis
la procdure denregistrement au niveau IMS dans la quelle plusieurs fonctionnalit seront
satisfaites.
2.2.1. Dcouverte du P-CSCF
Il y a deux faons pour obtenir ladresse IP de P-CSCF :
Intgr (Integrated) dans la procdure daccs lIP CAN : Donc lors de
ltablissement du PDP contexte le terminal obtiendra non seulement une adresse IPv6
et un APN mais aussi ladresse du P-CSCF.
La stand-alone, dans la quelle la dcouverte du P-CSCF se fait grce lutilisation du
DHCPv6 et du DNS.
Une fois un P-CSCF est allou un utilisateur il le sera toujours jusqu' la prochaine
dcouverte de P-CSCF. Et le terminal IMS na pas sinquit si ladresse du P-CSCF
chang car elle est fixe.
Page 14
15/04/2006
2.2.2. LEnregistrement IMS (avec un ISIM)

Aprs avoir obtenu ladresse du P-CSCF, le terminal envoie une requte SIP
REGISTER. Cette procdure permet lutilisateur dassocier son URI publique une URI qui
contient ladresse IP ou le host name de la machine o lutilisateur est logu. En effet, lURI
publique ne permet pas la localisation de lutilisateur car elle nest pas routable, do la
ncessit de lassocier une adresse routable tel quune adresse IP.
On distingue deux faons pour faire lenregistrement IMS. La diffrence rside dans la
mthode dauthentification qui est appliqu. Or pour authentifier les utilisateurs le terminal
devra tre quip par un UICC, qui peut inclure une application ISIM, USIM ou les deux.
Figure 2.2.2.a : Procdure denregistrement.
La procdure denregistrement trs similaire dans les deux cas mme si quelque dtail sont
diffrents. On prendra dans un premier temps lenregistrement utilisant une carte ISIM.
La procdure denregistrement permet de raliser les fonctionnalits suivantes :
Effectuer lassociation entre une Public User Identity et une adresse IP de contacte.
Le rseau nominal authentifie lutilisateur.
Lutilisateur authentifie son rseau nominal.
Page 15
15/04/2006
Le rseau nominal IMS autorise lenregistrement de lutilisateur et lutilisation des

ressources IMS.
Si le P-CSCF est localis dans un rseau visit, le rseau nominal vrifie sil y a un
accord de roaming entre eux et en consquence il autorise lutilisation du P-CSCF.
Le rseau nominal informe lutilisateur des autres adresses quil lui a allou.
Le terminal IMS ngocie avec le P-CSCF les mcanismes de scurit utilis pour la
signalisation qui suit. Ils tablissent un ensemble de mcanismes de scurit pour
assurer lintgrit des messages SIP envoys.
Le terminal IMS et le P-CSCF changent leurs algorithmes de compression des enttes
SIP.
Afin de dclancher la procdure denregistrement, le terminal IMS extrait la Public User

Identity, la Private User Identity et ladresse du rseau nominale. Puis construit la requte SIP
REGISTER et lenvoie au P-CSCF. Cette requte contient les paramtres suivant :
Registration URI : SIP URI qui identifie le non de domaine du rseau nominal.
Public User Identity : URI SIP qui reprsente lidentit de lutilisateur sous
enregistrement.
Private User Identity : identit utilis uniquement pour lauthentification.
Contact address : URI SIP qui contient ladresse IPv6 du terminal IMS pour joindre
lutilisateur.
Une fois la requte denregistrement est reu par le P-CSCF il doit la relayer au I-CSCF
du rseau nominal. En gnrale le P-CSCF peut ne pas tre dans le rseau nominal de
lutilisateur. Donc il doit dterminer un point dentr au rseau nominal qui est le I-CSCF, et
ceci en faisant une requte DNS. Le P-CSCF insert dans lentte SIP un champ P-VisitedNetwork-ID qui contient lidentifiant du rseau visit et un champ Path contenant son
URI pour que le rseau nominal lui envoie les requtes SIP destines au mobil. Dans tous les
cas les requtes SIP passeront par le P-CSCF.
LI-CSCF est un serveur stateless qui ne conserve aucun contexte
denregistrement. En effet, lI-CSCF peut varier dune requte une autre due au mcanisme
de partage de charge DNS. Quand lI-CSCF reoit la requte denregistrement, il envoie une
requte Diameter (UAR) au HSS qui rpond par un (UAA). Le but de cet change est de faire
lautorisation de lutilisateur pour utiliser le rseau IMS et de voire sil y a un S-CSCF allou
lutilisateur. Dans le Message UAR (User Authorization Request) lI-CSCF envoie au HSS
le Public User Identity, le Private User Identity et lidentificateur du rseau visit. Le HSS
effectue les oprations suivantes :
Vrifie que lutilisateur dfini par sa Public User Identity est un utilisateur lgitime du
systme.
Vrifie quil y a un accord de roaming avec le rseau visit.
Fait une corrlation entre la Public User Identity et la Private User Identity pour des
raisons dauthentification.
Voit si il y a un S-CSCF allou lutilisateur ou le I-CSCF doit choisir un.
La rponse du HSS sera dans le message UAA (User Authorization Answer), qui va
contenir lURI du S-CSCF qui a t dj allou lutilisateur. Dans le cas chant (donc une
premire procdure denregistrement) le HSS envoie au I-CSCF un ensemble de capabilits
que va utiliser le I-CSCF pour choisir le S-CSCF adquat lutilisateur. Les capabilits sont
divis en deux catgories : capabilit obligatoire que le S-CSCF choisi doit au moins
accomplir, et des capabilits optionnel que le S-CSCF peut ou pas les fournir. Ces capabilits
Page 16
15/04/2006
sont identifi par des entiers dont la smantique est propritaire loprateur, linterface Cx
est interne. Le I-CSCF contient une table configurable qui chaque S-CSCF dans le rseau
elle lui associe les copabilits dont il est capable de fournir. De cette faon lI-CSCF choisi le
S-CSCF adquat pour lui renvoy la requte denregistrement.
Le S-CSCF reoit la requte denregistrement et contacte le HSS pour deux raisons : le
S-CSCF a besoin de tlcharger les vecteur dauthentification pour authentifier lutilisateur et
enregistrer son URI dans le HSS pour que les requtes suivantes concernant cet utilisateur
soient rediriger vers lui. Le S-CSCF envoie un message Diameter MAR (Multimedia
Authentication Request) sur linterface Cx, pour demander les vecteur dauthentification du
HSS et enregistre son URI dans le profile de lutilisateur. Le HSS rpond par un message
MAA (Multimedia Authentication Answer) qui contient un ou plusieurs vecteurs
dauthentification pour authentifier lutilisateur.
Le S-CSCF cre un message 401 Unauthorized qui contient un dfit dans lentte
WWW-Authenticate et lenvoie au terminal IMS. Ce message arrive au terminal IMS via
un I-CSCF et le mme P-CSCF. Le terminal dtecte que ce message contient un dfit, et
rpond par une nouvelle requte SIP REGISTER appel credentials car elle contient une
rponse un dfit. Le terminal extrait ou drive les informations dauthentification de sa carte
puce (UICC) pour crer les credentials . De la mme manire que la premire requte
REGISTER cette deuxime sera envoye au P-CSCF qui va la relayer lI-CSCF. Il est trs
probable que le I-CSCF ne soit pas le mme que le premier due au partage de charge. Donc
lI-CSCF fera la mme procdure dautorisation avec le HSS travers les messages UAR et
UAA, mais cette fois il va obtenir lURI du S-CSCF qui a t allou lutilisateur, donc la
requte arrivera au mme S-CSCF. Le S-CSCF vrifie la rponse au dfit et si cest correcte
donc lutilisateur est authentifi. Alors il informe le HSS que lutilisateur est enregistr chez
lui par un message Diameter SAR et demande le tlchargement du profile (ou du reste du
profile) de lutilisateur. Le HSS rpond par le profile demand au S-CSCF.
A ce stade l, le S-CSCF a stock ladresse URI de contacte de lutilisateur qui lui
permet de le rejoindre ainsi que la liste des Path URI qui permet de router les requtes SIP
vers lutilisateur. (Les Path URI contiennent obligatoirement lURI du P-CSCF et
optionnellement les URI des I-CSCF).
A la fin le S-CSCF envoie une rponse 200 OK lutilisateur pour lui indiquer que la
requte denregistrement est russit. Cette requte contient un entte P-Associated-URI
qui reprsente une liste dURI allou lutilisateur (qui identifient lutilisateur). En plus on
trouve un entte Service-Route qui contient une liste des URI des serveurs SIP qui seront
utilis pour router les requtes SIP envoy par le terminal, (lURI du S-CSCF allou
lutilisateur est toujours prsente dans cet entte). On note que lutilisateur sera enregistr
durent une priode indiqu dans le paramtre Expires de lentte Contact .
2.2.3. Enregistrement avec un USIM

Si on se place dans un contexte purement UMTS o le terminal na pas un ISIM mais
plutt un USIM. Dans ce cas lutilisateur nest pas capable dobtenir une Private User
Idententity, une Public User Identity et lURI du rseau nominal. Mais le mobile dispose
dune IMSI, qui est un identifiant international unique pour lutilisateur. Cet identifiant sera
exploit pour que le terminal puisse construire une Private User Idententity temporaire, une
Public User Identity temporaire et lURI du rseau nominal. Ceci va permettre lutilisateur
de construire une requte SIP REGISTER. Aprs lenregistrement lutilisateur obtiendra des
Public User Identities quil utilisera dans les requtes SIP suivante.
Page 17
15/04/2006
Private User Identity temporaire : elle est toujours du format username@realm.

LIMSI sera lusername. Supposons quon a un IMSI=2483235551234, tel que le
MCC=248, le MNC=323 et le MSIN=5551234. Donc la Parivate User Identity
temporaire sera : 2483235551234@323.248.imsi.3Gppnetwork.org . La chane
.imsi.3Gppnetwork.org est toujours fixe.
Public User Identity temporaire : Elle a le mme forma que la Parivate User Identity
temporaire, mais prcder par la chane sip : .
( sip : 2483235551234@323.248.imsi.3Gppnetwork.org ).
URI du rseau nominal : est obtenu en enlevant la parie user de la Public User Identity
donc le format : sip : 323.248.imsi.3Gppnetwork.org .
La procdure denregistrement reste toujours la mme, mais le contenu des messages sera
diffrent. Et le S-CSCF va tlcharger des vecteurs dauthentifications du HSS en ligne avec
lUSIM, et lauthentification se fait comme en UMTS avec les quintupls.
2.2.4. Les Messages SIP
1. (1) REGISTER :
REGISTER sip : home1.net SIP/2.0
Via : SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp;
Branch=z9hG4bk9h9ab
Max-Forwards: 70
P-Access-Network-Info: 3GPP-UTRAN-TDD;
Utran-cell-id-3gpp=C3559A3913B20E
From: <sip:alice@home1.net>;tag=s8732n
To: <sip:alice@home1.net>
Contact: <sip:[1080::8:800:200C:417A];comp=sigcomp>
;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username= alice_private@home1.net,
Realm= home1.net, nonce= ,
Uri= sip:home1.net, response=
Security-Client: ipsec-3gpp; alg=hmac-sha1-1-96;
Spi-c= 3929102; spi-s= 0293020;
Port-c: 3333; port-s=5059
Require: sec-agree
Proxy-Require : sec-agree
CSeq : 1 REGESTER
Supported: path
Content-Length: 0

LURI home1.net reprsente lURI du rseau nominal vers le quelle la
requte sera rout.

Le champ Via contient ladresse IPv6 que le terminal obtenu durant
lactivation du PDP Contexte.

Le champ P-Access-Network-Info reprsente des informations concernant
le type de rseau daccs, dans notre cas cest un rseau UMTS TDD.

Lidentit publique de lutilisateur qui a mit cette requte est contenu dans le
champ From . Cette identit peut tre obtenue dune ISIM ou une USIM.
Page 18
15/04/2006

Le champ To contient aussi lidentit publique de lutilisateur qui sera
enregistr. Cette identit permet aux autres de reconnatre cet utilisateur. De mme elle
peut tre obtenue dune ISIM ou une USIM.

Le champ Contact indique ladresse IPv6 de lutilisateur. Cest une adresse
temporaire qui permet de joindre lutilisateur, comme un point de contacte. Les requtes
destines cet utilisateur seront envoy vers cette adresse. Le S-CSCF va stocker cette
information.

Le champ Authorization contient des informations dauthentifications.
Lidentit prive de lutilisateur est dans le champ username
(alice_private@home1.net). Le champ Realm contient le mon du rseau au
l'utilisateur sera authentifier. Le champ uri est similaire au Realm car cest
obtenu du mme champ de lUSIM ou lISIM.

La partie Security-Client contient lensemble des algorithmes de scurits
que le terminal sait faire.

Le champ Supported indique au rcepteur de cette requte que le terminal
supporte lentte Path .
2. (5) REGISTER:
Via : SIP/2.0/UDP icscf1.home1.net; branch=z9hg4bkea1dof,
SIP/2.0/UDP pcscf1.visited1.net; branch=z9hg4bkoh2qrz,
SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp;
Branch=z9hG4bk9h9ab
Max-Forwards: 68
;expires=600000
Call-ID: 23fi57lju
Realm= home1.net, nonce= ,
Uri= sip:home1.net, response=
Integrity-protected=no
Require: path
Supported: path
Path: <sip:term@pcscf1.visited1.net;lr>
P-Visited-Network-ID: Visited 1 Network
P-Charging-Vector: icid-value=W34h6dlg
CSeq: 1 REGISTER
Content-Length: 0

LI-CSCF neffectue aucune modification sur la requte denregistrement mais
comme le P-CSCF il va ajouter son adresse dans la partie Via .

Pour sassurer que les requtes SIP destination du terminal passent toujours
par lui, le P-CSCF ajoute son adresse dans le champ Path . Donc le S-CSCF saura o
envoyer les requtes.

Le P-CSCF ajoute le champ P-Visited-Network-ID , ce champ contient le
nom de domaine ou une autre adresse qui permet didentifier le rseau visit ou se
trouve le P-CSCF.
Page 19
15/04/2006

Le champ Require permet au rcepteur de traiter correctement lentte
Path . Si le rcepteur ne supporte pas cette adresse il gnre une erreur 420 indiquant
que le message t rout par erreur en dehors du sous systme IMS.

Le P-CSCF ajoute aussi le champ P-Charging-Vector et alimente le
paramtre icid par une valeur unique.

Le P-CSCF enlve lentte Security-Client et loption sec-agree car il
veut un entte vide.
3. (10) 401 UNAUTHORIZED

SIP/2.0 401 Unauthorized
Branch=z9hG4bk9h9ab
To: <sip:alice@home1.net>; tag=409sp3
Call-ID: 23fi57lju
WWW-Authenticate: Digest realm=home1.net,
Nonce=dcd98b7102dd2f0e8b11d0f600bfb0c093,
Algorithm=AKAv1-MD5
Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha1-1-96;
Spi-c= 909767; spi-s= 421909;
CSeq: 1 REGISTER
Content-Length: 0

Le message 401 Unauthorized reu par le P-CSCF est diffrent de celui-ci
qui est envoy au terminal par le P-CSCF. Or le message reu par le P-CSCF contient
en plus dans la partie WWW-Authenticate la clef dintgrit IK et la clef de
chiffrement CK, que le S-CSCF mis. (Notons que le message du tableau ci-dessus est
celui reu par le terminal, et le terminal drive IK et CK de son USIM comme en
UMTS).

Dans la partie WWW-Authenticate de ce message on trouve le dfit envoy
par le S-CSCF pur authentifier lutilisateur (nonce). Ce nonce est form par la
concatnation dun AKA RAND, AKA AUTH et des donnes spcifiques au serveur.

Dans le champ Security-Server on trouve le paramtre q , qui indique
quelle mcanisme de scurit utiliser en premier. Dans notre cas le 0.1 indique lIPSec.
4. (11) REGISTER (Credentials):

Branch=z9hG4bk9h9ab
Max-Forwards: 70
;expires=600000
Call-ID: 23fi57lju
Realm= home1.net,
nonce= dcd98b7102dd2f0e8b11d0f600bfb0c093,
Algorithm=AKAv1-MD5,
Page 20
15/04/2006

Uri= sip:home1.net,
Response= 6629fae49393a0539740978507c4ef1
Security-Verify: ipsec-3gpp; ; q=0.1; alg=hmac-sha1-1-96;
Spi-c= 909767; spi-s= 421909;
Require: sec-agree
Proxy-Require : sec-agree
CSeq : 2 REGESTER
Supported: path
Content-Length: 0
Ce message reprsente la rponse la requte dauthentification mise par le S-CSCF.

Le champ Athorization contient la rponse au dfit dj reu par le
terminal, dans le paramtre Response . et contient aussi lidentit prive de
lutilisateur, le Realm , le nonce , l URI et les algorithmes. Se message est
protger par IPSec dj ngoci.

Le champ Security-Verify contient laccord sur les mcanismes de scurit
comme convenu dans le Security-Server du message prcdent.
5. (15) REGISTER
Via : SIP/2.0/UDP icscf1.home1.net; branch=z9hg4bkea1dof,
SIP/2.0/UDP pcscf1.visited1.net; branch=z9hg4bkoh2qrz,
SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp;
Branch=z9hG4bk9h9ab
Max-Forwards: 68
Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>
;expires=600000
Call-ID: 23fi57lju
Realm= home1.net,
nonce= dcd98b7102dd2f0e8b11d0f600bfb0c093,
Algorithm=AKAv1-MD5,
Uri= sip:home1.net,
Response= 6629fae49393a0539740978507c4ef1
Integrity-protected=yes
Require: path
Supported: path
P-Visited-Network-ID: Visited 1 Network
P-Charging-Vector: icid-value=W34h6dlg
CSeq: 2 REGISTER
Content-Length: 0
Cest la rponse au dfit reu par le S-CSCF, il subit la mme chose que le message (5)
REGISTER en gardant le champ Authorization .
Page 21
15/04/2006
6. (20) 200 OK
SIP/2.0 200 OK
Via : SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp;
Branch=z9hG4bk9h9ab
Service-Route: <sip:orig@scscf1.home1.net;lr>
To: <sip:alice@home1.net>; tag=409sp3
Call-ID: 23fi57lju
Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp>
;expires=600000
CSeq: 2 REGISTER
Date : Wed, 04 April 2006 19:13:50 GMT
P-Associated-URI :<sip:alice-family@home1.net>
<sip:alice-business@home1.net>
<sip:+1-212-555-1234@home1.net;user=phone>
Content-Length: 0
Une fois lauthentification de lutilisateur russit, le S-CSCF envoie cette rponse au

terminal qui contient :

P-Associated-URI : qui contient une liste des URI allou lutilisateur.

Service-Route : Qui contient obligatoirement ladresse du S-CSCF allou
lutilisateur ainsi quune liste optionnelle dURI de serveurs SIP que le terminal peut
utiliser pour envoyer ses requtes.

Le champ Expires indique la dure denregistrement du terminal.
2.2.5. Les Messages Diameter
Les messages suivants sont changs sur linterface Cx qui peut tre entre lI-CSCF et
le HSS ou le S-CSCF et le HSS. Cette interface est caractrise par lapplication Diameter qui
dfini un ensemble de commandes (requte/rponse) pour linterface Cx parmi les quelle
figures ces messages.
1. (3) UAR/ (4) UAA:
Quand lI-CSCF reoit la requte SIP REGISTER, il envoie un message UserAuthorization-Request au HSS pour les raisons suivante :
Le HSS vrifie si la Public User Identity est attribu un utilisateur lgitime du
systme et que lutilisateur ne doit pas tre bloqu (Si son crdit est termin).
Le HSS vrifie encore sil y a un accord de roaming avec le rseau visit o se
trouve le P-CSCF. Ceci est important, car il permet au rseau du P-CSCF
dchanger des informations de facturation avec le rseau nominale.
LI-CSCF a besoin de savoir sil y a un S-CSCF allou lutilisateur pour lui
renvoyer le message SIP REGISTER. Sinon lI-CSCF recevra un ensemble de
capabilit qui va lui permettre de choisir un.
Le HSS va corrler la Public User Identity avec la Private User Identity, pour
voir sils peuvent tre utiliss ensemble pour authentifier lutilisateur.
Le HSS rpond par un User-Authorization-Answer lI-CSCF qui contient un ResultAVP (Result Attribute Value Paires) pour lui indiquer sil continue la procdure
Page 22
15/04/2006
denregistrement ou pas. Si lenregistrement est autoris lUAA contiendra aussi des AVP
pour aider lI-CSCF dterminer ou choisir le S-CSCF.
2. (6) MAR/ (7) MAA:
Quand le S-CSCF reoit le message denregistrement il doit authentifier lutilisateur.
Pour cela il doit tlcharger les vecteurs dauthentification du HSS car pour une premire
fois le S-CSCF ne les pas. Le S-CSCF envoie le message Multimedia-Auth-Request au
HSS pour lui demander ces vecteurs et enregistre en mme temps son URI dans le profile
de lutilisateur pour que dautre CSCFs ou AS soit capable de savoir quelle est le SCSCF allou a cet utilisateur. Le HSS rpond par les vecteurs dans le message
Multimedia-Auth-Answer.
3. (16) SAR/ (17) SAA:
Une fois lutilisateur authentifi, le S-CSCF envoie le message Server-AssignmentRequest au HSS pour lui indiquer que lutilisateur est enregistr chez lui et pour lui
demander son profile complet (ou le reste de son profile). Le HSS rpond par un message
Server-Assignment-Answer contenant le profile demand. Le S-CSCF peut aussi envoyer
le massage SAR au HSS si lutilisateur nest plus enregistr pour garder le HSS au
courrant de ltat denregistrement de lutilisateur. Le HSS peut autoriser le S-CSCF de
garder le profile de lutilisateur et de lui rester affecter. Le HSS contrle cette possibilit.
2.2.6. Souscription ltat denregistrement du terminal reg Event State

Il est important dinformer lutilisateur sil est toujours joignable ou pas, cest un
besoin hrit du GSM, c'est--dire dtect si le service IMS est toujours disponible. La
solution pour ce problme est dutiliser une technique rseau intelligent sur vnement, o on
va souscrire le terminal IMS un service qui lui permet de savoir son tat denregistrement
(registration-state), cette information est disponible dans le S-CSCF. Ceci consiste mettre en
place une supervision dun vnement (Enregistrement/dsenregistrement) grce au message
SIP SUBSCRIBE, et pour informer loccurrence de cet vnement on utilise le NOTIFY.
Quand le terminal IMS termine son enregistrement, il envoie une requte
SUBSCRIBE adress pour la mme Public User Identity dj enregistr. Le S-CSCF reoit
cette requte et installe cette souscription. Le S-CSCF envoie une requte NOTIFY
lutilisateur qui contient la liste des Public User Identity qui lui son affect avec ltat
denregistrement de chaque une. Maintenant le terminal sait avec quelle Public User Identity
lutilisateur est enregistr. Si ltat denregistrement de lutilisateur change le S-CSCF va
linformer. De plus le P-CSCF va se souscrire son tour ltat denregistrement de
lutilisateur, de cette faon il sera inform en temps relle sur ltat denregistrement de
chaque Public User Identity.
Page 23
15/04/2006
Notons que dautre entit peuvent souscrire ltat denregistrement de lutilisateur tel
que les serveurs dapplication afin de fournir des servir divers (ex : envoy un message de
bien venue lutilisateur).
Figure 2.2.6.a : Souscription ltat denregistrement (Suite de la procdure denregistrement).
Page 24
15/04/2006
3. Procdure dtablissement de session en IMS INVITE

Dans cette partie, on va dcrire les messages changs lors de ltablissement dune
session en IMS. Pour illustrer cette procdure, on va considrer un scnario o les 2
terminaux sont en cas de roaming. On va supposer alors que lappelant
(user1_public1@home1.net) possde un abonnement franais et il est en roaming en Finland,
et lappel (+1-212-555-2222) possde un abonnement allemand et il est en roaming aux
Etats-Unis. Dans ce scnario, chacun des terminaux IMS, possde alors un rseau mre et un
rseau visit. On suppose ltablissement dune session de visiophonie entre des abonnes
UMTS.
Dans la suite, on va suivre lacheminement de lappel tape par tape.
3.1. Etape 1 : Invite et Session Progress

La figure suivante reprsente ltape 1 [Invite + Session Progress] des diffrents messages de
signalisation changs lors de ltablissement de session.
Figure 3.1.a : Invite + Session Progress
On va dtailler par la suite les champs importants des messages SIP [Invite et Session
Progress] changs lors de la premire tape.
Page 25
15/04/2006
(1) Invite : UE1 P-CSCF1

LUE1 envoie un Invite request au rseau pour tablir une session multimdia.
On va analyser les principaux champs de ce message :

- Request URI : Contient le TEL-URI Public User Identity de lappel (+ 1-212555-2222).
- Via Header :
Contient ladresse IPv6 (5555:aaa:bbb:ccc:ddd) et le numro de port (1357)
sur lequel le terminal IMS souhaite recevoir les rponses cette requte.
Indique si le terminal est capable de recevoir des enttes SIP compress
(SigComp : Compressed Signaling).
Indique le protocole de transport (UDP, TCP, SCTP) qui peut tre utilis
(soit UDP dans notre cas).
- Route :
Contient ladresse du P-CSCF : p-cscf1.visited1.net (daprs la Discovery
Procedure) et la valeur du numro de port (1357) du P-CSCF.
Contient la valeur du Service-Route Header obtenue lors de la registration,
cest dire ladresse du S-CSCF dans le rseau mre s-cscf1.home1.net.
Page 26
15/04/2006
P-Preferred Identity : Chaque utilisateur peut avoir plusieurs Public User Identity.
Pour cela, lappelant doit indiquer quelle identit (user1_public1@home1.net) il va
utiliser pour cette session.
P-Access Network Info: Ce champ indique 2 types dinformation sur laccs:
Le type de la couche daccs 2/3 utilis par le terminal IMS (UMTS,
WLAN, ), qui est dans notre cas un accs UMTS (UTRAN).
Lidentit de la cellule radio auquel le terminal est connect.
SDP content : Ces champs dcrivent la session ; Ils indiquent que cest un offre
SDP (Session Description Protocol) contenant le Bandwidth, ainsi que les
caractristiques pour chacun des codecs quil peut supporter pour cette session. Le
vido streaming peut supporter 2 codecs (H.263 soit MPEG-4) et laudio streaming
peut supporter le codec AMR.
Require : precondition indique que lappel doit rpondre par un SDP answer.
Privacy : = id si lappelant veut cacher son identit, et = none dans le cas contraire.
Security-Verify: Indique que la connexion entre le UE et le P-CSCF est chiffr,
utilisation du protocole IP-Sec.
(3) Invite : P-CSCF 1 S-CSCF 1

Ce message est utilis pour transfrer le message invite vers le next hop Destination
indiqu dans le route Header du message prcdent cest dire vers le S-CSCF 1
(scscf1.home1.net).
On retrouve dans ce message les mmes champs indiqus dans le message (1) avec les
modifications suivantes :
-
P-CSCF 1 ajoute son adresse SIP-URI (pcscf1.visted1.net) au Record- Route

Header et au Via-Header. Ce Record Route ne contient pas le paramtre comp =
sigcomp comme la requte est envoy vers une interface non compresse.
P-CSCF 1 enlve le Security-Verify Header, comme cette requte est envoye vers
le cur du rseau. Il y aura pas par la suite besoin pour des connexions IP-Sec.
P-Asserted-Identity: Le P-CSCF1 ajoute la requte le champ P-Asserted-Identity
et supprime le champ de P-Preferred-Identity header. Le P-Asserted-Identity doit
Page 27
15/04/2006
contenir une adresse SIP URI valide (user1_public1@home1.net) pour

lutilisateur qui peut tre gale au P-Preferred-Identity. Une fois, cette adresse est
initialise, le P-CSCF nutilise plus ladresse indique dans le champ From.
(5) Invite: S-CSCF 1 vers I-CSCF 2
Le S-CSCF 1 attribu lUE 1 examine le P-Asserted-Identity pour identifier le
lutilisateur initiant lappel. Pour cela, il tlcharge le profil de lutilisateur. Ce profil contient
un critre important appel Filter Criteria.
Le Filter Criteria contient une collection de Triggers qui dtermine si la requte doit
passer par un ou plusieurs serveurs dapplication pour fournir des services lutilisateur.
En effet, le S-CSCF nexcute pas des services mais tlcharge pour chaque utilisateur des
filtres, qui sont une sorte de masque quil applique aux messages SIP, si le rsultat est positif
il envoie le message SIP a un serveur dapplication pour excuter un service. Cest la
signalisation dintelligence en IMS. Si non lappel sera trait normalement par le S-CSCF
comme dans notre cas.
Le S-CSCF de lUE1 est le premier nud qui soccupe de lacheminement de lappel vers le
destinataire. Le S-CSCF analyse le champ Request-URI de la requte. Il existe deux types
dURI : SIP-URI et TEL-URI.
- Cas de TEL-URI: Qui correspond soit un numro de tlphone (+1-212-5552222) appartenant soit un rseau RTC ou GSM (Comme dans notre cas ), soit
un utilisateur IMS. Dans ce cas, il sera traduit en un SIP-URL
(user2_public1@home2.net ). Pour cette translation dadresse, le S-CSCF utilise
les services du protocole ENUM-DNS, ou bien dautres bases de donnes de
translation correspondantes.
Une fois il connat lURI de lappel, le S-CSCF extrait le nom du domaine (home2.net)
(user2_public2@home2.net) et effectue des requtes DNS avec le DNS Server. Ces requtes
DNS changs permettent de :
Trouver les protocoles de transports supports par le home2.net.
Dterminer le ou les serveurs SIP (I-CSCF) dans le domaine home2.net.
Le S-CSCF 1 ajoute le TEL URI (+1-212-555-1111) correspondant au SIP URI
(user1_public1@home1.net) dans le champ P-Asserted-Identity header pour que ce TEL URI
Page 28
15/04/2006
soit connu par le rseau de destination dans le cas o la requte INVITE tait envoye vers un
MGCF. Il rajoute aussi son adresse (scscf1.home1.net) au record route et au via header.
(7-8) LIR et LIA
I-CSCF2 envoie une requte vers le HSS (contenant le public user identity :
user2_public2@home2.net de lappel) pour trouver le S-CSCF2 correspondant lutilisateur
appel. HSS rpond avec ladresse du S-CSCF2.
(9) Invite: I-CSCF 2 vers S-CSCF 2
On note ici que lI-CSCF 2 najoute pas son adresse au Record-Route header, comme il ny a
plus besoin de ladresse de lI-CSCF pour la signalisation une fois la session est tablit, mais
au via Header uniquement. LI-CSCF 2 envoie le message vers le S-CSCF 2 (Route) obtenue
dans les requtes Diamater.
(11) Invite: S-CSCF 2 vers P-CSCF 2
Page 29
15/04/2006
Le S-CSCF2 valide le profil de service de lUE 2 et fait lvaluation de son Filter Criteria .
Il connat aussi daprs la procdure de registration ladresse de lUE 2 et le next hop CSCF
pour cet UE.
- Le S-CSCF 2 cre une nouvelle Request-URI dont le contenu est une adresse IPv6
qui est celle du Header contact fourni lors de lenregistrement
(5555 :eee :fff :aaa :bbb)
- Le S-CSCF 2 ajoute son adresse au Via Record Route (scscf2.home2.net).
- Route : Contient ladresse du P-CSCF 2 (pcscf2.home2.net) stock lors de la
procdure de registration.
- P-Called-Party-ID: contient le Public User Identity de lappel et ses paramtres
(user2_public2@home2.net).
(13) Invite : P-CSCF 2 vers UE 2
Le P-CSCF 2 ajoute son adresse URI (pcscf2.visited2.net) ainsi que le numro de

port ngoci (8805) suivant les accords de scurit via header et au record route.
Il va router le message vers UE2 suivant ladresse IPv6 indiqu dans
Request_URI.
Suivant la valeur de privacy indiqu dans le message 1, le P-Asserted-Identity sera
supprim ou pas.
Si privacy = id, le P-Asserted-Identity sera supprim.
Privacy = none, le champ sera envoy vers lappel.
(15) Session Progress: UE 2 vers P-CSCF 2

LUE1 envoie une requte Invite lUE2 contenant un offer SDP indiquant ladresse IP et les
numros de port sur lesquels lUE1 veut recevoir le media stream, les codecs dsirs et
supports pour chacun de ces media streams.
Page 30
15/04/2006
De plus, le SDP offre contient le champ require initialis precondition indiquant quil faut
faire une rservation des ressources radio en avance.
Le SDP anser contient :

- Le media stream et le codec que lappel peut supporter pour cette session.
- Access Network Info : Le type daccs.
- Contact: Contient le SIP URI avec ladresse IP de lUE 2 sur laquelle le
destinataire souhaite recevoir le media streams. Il contient aussi comp=sigcomp
parameter.
- SDP: Le SDP contient lensemble des codecs supports par lUE2. La
confirmation de la QoS preconditions est ncessaire pour ltablissement de la
session avec ces medias streams. LUE2 peut accepter ltablissement de la session
avec audio stream mais sans vido.
- Le SDP contient aussi un champ a=conf : qos indiquant que le destinataire UE2
souhaite recevoir une notification une fois lUE1 a termin le processus de
rservation de ressources.
(16 20) Traitement de la Session Progress
La rponse Session Progress traverse lensemble des proxys traverss par Invite
- Au niveau de P-CSCF 2 :
P-Asserted-Identity: Le P-CSCF 2 prend la valeur du P-Called-Party-Id
(user2_public1@home2.net (de lappel)) de la requte INVITE reu
prcdemment et la met dans le champ P-Asserted-Identity de ce message.
Page 31
15/04/2006
Record-Route: P-CSCF2 rcrit le champ Record-Route header tout en

effaant le numro de port utilis pour des associations de scurit.
Au niveau de S-CSCF 2 :
P-Asserted-Identity: S-CSCF2 ajoute le TEL URI (+1-212-555-2222) de
lappel dans le champ P-Asserted-Identity.
Au niveau de S-CSCF 1 :
Le S-CSCF 1 peut supprimer le P-Asserted-Identity si le champ Privacy du
message (15) est initialis id.
Au niveau de P-CSCF 1 :
Record-Route: P-CSCF1 rcrit le champ Record-Route header et ajoute le
numro de port utilis pour des associations de scurit.
Le P-CSCF 1 envoie la rponse vers lUE1.
3.2. Etape 2: Prack Request
Figure 3.2.a : Suite de la procdure dtablissement de session.
(21 ... 25) LUE1 Traite la rponse de la Session Progress : Prack

Comme lUE1 peut supporter plusieurs codecs pour un media stream, le terminal a toujours
tendance rduire le nombre de codecs supports par un media stream un seul. Par exemple,
pour le vido stream, le nombre de codecs ngocis est deux (H.263 et MPEG-4).
LUE1 doit choisir lequel des 2 codecs va tre utilis. Ceci aura un impact direct sur la
gestion de la bande passante, Comme la rservation de ressources dpend du Bandwidth
Page 32
15/04/2006
associ au codec choisit. LUE1 choisit un codec par flux (codec vido et codec audio AMR)
et envoie une nouvelle offre SDP contenant le ou les codecs choisis. Par exemple, dans notre
cas le terminal 1 choisit le H.263 comme codec pour la vido et lAMR pour la voix. Cette
nouvelle offre SDP sera envoye dans le message PRACK.
En parallle avec lenvoi de ce message PRACK, lUE1 connat dj le BandWidth qui devra
tre allou, il commence alors la rservation des ressources radios. Cette procdure
ncessite un change de message avec les nuds radios et paquets (SGSN et GGSN si lIPCAN est un rseau GPRS ou UMTS).
La requte Prack est envoye ensuite vers le path indique par Record Route Header.
(26 ... 40) LUE2 Traite le Prack
Le message 200 Ok constitue la deuxime rponse loffre SDP de PRACK aprs celui de
linvite. Le SDP answer ne contient pas des paramtres ngocier mais plutt une
confirmation pour le codec et le media stream de cette session.
On note aussi que la rservation des ressources pour le terminal 2 commence ce stade l.
Le SDP answer indique aussi que lUE2 na pas reu encore une notification que lUE1 a
termin la procdure de rservation de ressources.
Ce message traverse les mmes proxies que le message PRACK a traverss.
Une fois, lUE1 a termin la procdure de rservation de ressources, il envoie lUE2 un
message de confirmation UPDATE contenant un nouvel offre SDP dans lequel lUE1 met
jour le champ a=curr :qos local sendrecv indiquant que la rservation de ressources a t
effectu au niveau de lUE1.
LUE2 doit rpondre avec un SDP answer afin dacquitter loffre SDP de Update.
3.4. Etape 3: Alerter lappel

Avant que lappel soit alert, lUE2 doit vrifier si lallocation des ressources a t faite des
deux cts de la session, pour cela deux conditions essentielles doivent tre satisfaites:
LUE2 doit complter la rservation de ses ressources.
LUE2 doit recevoir une confirmation que le lUE1 a termin la rservation de ses
ressources (message UPDATE (31 35)).
Quand lappel est alert, une rponse Ringing est gnre et envoye vers le terminal de
lappelant travers le mme ensemble de proxys. Cette rponse ne contient pas de SDP,
puisque tous les paramtres ont taient dj ngocis.
Due la prsence du champ Require : 100rel, Cette rponse doit tre acquitte. Le terminal
de lappelant en recevant le Ringing va gnrer une tonalit ring-back (tonalit de retoure
dappel) sauvegarde localement, et va envoyer lappel une rponse PRACK (comme
aquittement du Ringing) sans offre SDP, ce dernier en recevant le PRACK envoie un 200 OK
(comme aquittement du PRACK).
Quand lappel accepte lappel, le terminal va envoyer un 200 OK comme acquittement pour
la requte INVITE quil reu de lappelant. En recevant le message 200 Ok, le terminal de
lappelant commence gnrer le trafic media, et il envoie en plus un ACK pour confirmer la
rception du 200 OK.
Page 33
15/04/2006
Ltablissement de la session est termin et les deux utilisateurs peuvent commencer gnrer
leurs flux audio et vido. Ces flux en gnral sont envoys de bout en bout via les routeurs de
lIPCAN.
Figure 3.4.a : Suite de la procdure dtablissement de session.
Page 34
15/04/2006
Conclusion
Dans ce projet, on a analys deux aspects fondamentaux de cette nouvelle technologie
qui tend remplacer linfrastructure de contrle dans les rseaux mobile. Lapport principal
de lIMS est le faite de pouvoir tablir des sessions multimdia avec la fourniture de
nouveaux services comme le Push to Talk, la messagerie instantane jusquaux jeux
vidoMais pour faire des services trs riche il faut que les rseaux daccs IP assurent un
dbit lev par utilisateur et une bonne ractivit. Actuellement les rseaux mobiles de
troisime gnration, telle que lUMTS, ne fournissent pas un dbit trs lev par utilisateur,
donc pour vraiment faire des services multimdia dune haute qualit il faut attendre
lmergence dune nouvelle technologie radio. En plus le rseau IP de transport qui pourra
tre lInternet doit fournir une qualit de service minimum pour vhiculer le trafic IMS. L,
on voit plusieurs problmatiques qui apparaissent au niveau accs transport et mme au
niveau de la gestion de la mobilit de lutilisateur quand il change de technologie daccs.
Page 35
15/04/2006
Glossaire
ACK
AMR
API
APN
AS
AVP
BGCF
CAMEL
C-CSCF
CDR
CDRs
CK
CS
DHCPv6
DiffServ
DNS
GPRS
GSM
gsmSCF
HLR
HSS
I-CSCF
I-CSCF
IK
IMS
IMSI
IMS-SSF
IMS-SSF
INAP
IP
IP CAN
IP-Sec
IPv6
ISDN
ISIM
ISUP
LIA
LIR
MAA
MAR
MCC
MGCF
MGW
MMS
Acknolage
Adaptative Multi Rate
Application Programming Interface
Access Point Name
Application Server
Attribute Value Pairs
Breakout Gateway Control Function
Customized Application for Mobile network Enhanced Logic
Call/Session Control Function
Call Detailed Record
Call Detailed Record
Ciphering Key
Circuit Switching
Dynamic Host Configuration Protocol version 6
Differenciated Services
Domain Name System
General Packet Radio Service
Global System for Mobile
GSM Service Control Function
Home Location Server
Home Subscriber Server
InterrogatingCSCF
InterrogatingCSCF
Integrity Key
IP Multimedia Subsystem
International Mobile Subscriber Identity
IP Multimedia Service Switching Function
IP Multimedia Service Switching Function
Intelligent Network Application Part
Internet Protocol
IP Connectivity Access Network
Internet Protocol Security
Internet Protocol version 6
Integrated Services Digital Network
IMS Subscriber Identity Module
ISDN User Part
Location Info Answer
Location Info Request
Multimedia Authentication Answer
Multimedia Authentication Request
Mobile Country Code
Media Gateway Control Function
Meadi Gateway
Multimedia Message Service
Page 36
15/04/2006

MNC
MPLS
MRF
MRF
MRFC
MRFC
MRFP
MSIN
MSISDN
MTP
NGN
OSA-SCS
OSA-SCS
PCM
P-CSCF
P-CSCF
PDF
PDF
QoS
RI
RSVP
RTC
RTP
SAA
SAR
S-CSCF
SCTP
SDP
SGW
SIP
SIP-URI
SMS
TCP
TEL-URL
UAA
UAR
UDP
UE
UICC
UMTS
USIM
UTRAN
VLR
WLAN
xDSL
Mobile Network Code

Multi Protocol Label Switching
Media Ressource Function
Media Ressource Function
Media Ressource Function Controller
Media Ressource Function Controller
Media Ressource Function Processor
Mobile Station Identity Number
Mobile Subscriber ISDN Number
Message Transfer Part
Next Generation Network
Open Service Access Service Capability Server
Open Service Access Service Capability Server
Pulse Code Modulation
Proxy-CSCF
Proxy-CSCF
Policy Decision Function
Policy Decision Function
Quality of Service
Rseau Intelligent
Ressource Reservation Protocol
Rseau Tlphonique Commut
Real-Time Protocol
Server Assignment Answer
Server Assignment Request
Serving-CSCF
Stream Control Transmission Protocol
Session Description Protocol
Signalling Gateway
Session Initiation Protocol
SIP Uniform Ressource Indentifier
Short Message Service
Transmision Control Protocol
Telphone Uniform Ressource Locator
User Authorization Answer
User Authorization Request
User Datagram Protocol
User Equipment
Universal Integrated Circuit Card
Universal Mobile Telecommunications System
Universal Subscriber Identity Module
Universal Terrestrial Radio Access Network
Visitor Location Server
Wireless Local Area Network
x Digital Subscriber Line
Page 37
15/04/2006
Rfrences
1. The IP Multimdia Subsystem, Gonzalo Camarillo et Miguel A. Garcia-Martin.

2. Nouveaux Services Vocaux dEntreprises, Cours Claude Rigault, ENST 2005.
3. RFC3261, SIP : Session Initiation Protocol, J. Rosenberg, H. Schulzrinne, G. Camarillo,
A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler, June 2002.
4. 3GPP TS 24.228 V5.13.0 June 2005, Signalling flows for the IP multimedia call control
based on Session Initiation Protocol (SIP), and Session Description Protocol (SDP), Stage 3,
Release 5.
5. 3GPP TS 29.229 V7.1.0 March 2006, Cx and Dx interfaces based on the Diameter
protocol, Protocol details, Release 7.
6. Rfrence Internet : www.tech-invite.com.
Page 38
15/04/2006
MROUEH Lina
LABAKY Elie
3me anne du cycle ingnieur

Tlcom Paris
3me anne du cycle ingnieur

Tlcom Paris
mroueh@enst.fr
labaky@enst.fr
Avril 2006
Page 39
15/04/2006

Ims

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ims

Transféré par

Droits d'auteur :

Formats disponibles

3me Anne du cycle ingnieur

Encadrant M. Philippe MARTINS

Etude des procdures

Enregistrement et tablissement de session en IMS

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Table des Figures

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Ce projet consiste faire ltude de la procdure denregistrement et dtablissement

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

1. Prsentation de larchitecture IMS

Figure 1.1.a : Architecture fonctionnelle IMS.

HSS : Home Subscriber Server

C-CSCF: Call/Session Control Function

P-CSCF: Proxy CSCF

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Les diffrentes fonctionnalits :

S-CSCF : Serving CSCF

Serveurs dapplications (AS)

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

IMS-SSF (IP Multimedia Service Switching Function) : permet de rutiliser les

MRF : Media Ressource Function

Enregistrement et tablissement de session en IMS

1.2. Gestion des identits en IMS

1.2. Private User Identity

1.2.3. Relations entre Public et Private User Identity

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

1.3. Les cartes USIM et ISIM

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

1.4. Type de Signalisations en IMS

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

2. Procdure denregistrement dans IMS REGISTER

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Figure 2.1.a : Procdure gnrale pour obtenir le service IMS.

2.2. Procdure denregistrement

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

2.2.2. LEnregistrement IMS (avec un ISIM)

Figure 2.2.2.a : Procdure denregistrement.

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Le rseau nominal IMS autorise lenregistrement de lutilisateur et lutilisation des

Afin de dclancher la procdure denregistrement, le terminal IMS extrait la Public User

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

2.2.3. Enregistrement avec un USIM

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS

Private User Identity temporaire : elle est toujours du format username@realm.

2.2.4. Les Messages SIP

MROUEH Lina & LABAKY Elie

Enregistrement et tablissement de session en IMS