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

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 3

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 4

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 5

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 6

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 7

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 8

15/04/2006

Enregistrement et tablissement de session en IMS

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).
MROUEH Lina & LABAKY Elie

Page 9

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 10

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 11

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 12

15/04/2006

Enregistrement et tablissement de session en IMS

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

2.1. Prambule

REGISTER

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 .

MROUEH Lina & LABAKY Elie

Page 13

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 14

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 15

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 16

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 17

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 18

15/04/2006

Enregistrement et tablissement de session en IMS

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:
REGISTER sip : home1.net SIP/2.0 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 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= 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.

MROUEH Lina & LABAKY Elie

Page 19

15/04/2006

Enregistrement et tablissement de session en IMS

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 Via : SIP/2.0/UDP [1080::8:800:200C:417A];comp=sigcomp; Branch=z9hG4bk9h9ab From: <sip:alice@home1.net>;tag=s8732n 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; Port-c: 4444; port-s=5058 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):

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= dcd98b7102dd2f0e8b11d0f600bfb0c093, Algorithm=AKAv1-MD5,

MROUEH Lina & LABAKY Elie

Page 20

15/04/2006

Enregistrement et tablissement de session en IMS Uri= sip:home1.net, Response= 6629fae49393a0539740978507c4ef1 Security-Verify: ipsec-3gpp; ; q=0.1; alg=hmac-sha1-1-96; Spi-c= 909767; spi-s= 421909; Port-c: 4444; port-s=5058 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
REGISTER sip : home1.net SIP/2.0 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 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]:5059;comp=sigcomp> ;expires=600000 Call-ID: 23fi57lju Authorization: Digest username= alice_private@home1.net, Realm= home1.net, nonce= dcd98b7102dd2f0e8b11d0f600bfb0c093, Algorithm=AKAv1-MD5, Uri= sip:home1.net, Response= 6629fae49393a0539740978507c4ef1 Integrity-protected=yes 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: 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 .

MROUEH Lina & LABAKY Elie

Page 21

15/04/2006

Enregistrement et tablissement de session en IMS

6. (20) 200 OK
SIP/2.0 200 OK Via : SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; Branch=z9hG4bk9h9ab Path: <sip:term@pcscf1.visited1.net;lr> Service-Route: <sip:orig@scscf1.home1.net;lr> From: <sip:alice@home1.net>;tag=s8732n 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

MROUEH Lina & LABAKY Elie

Page 22

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 23

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 24

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 25

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 26

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 27

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 28

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 29

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 30

15/04/2006

Enregistrement et tablissement de session en IMS

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.
MROUEH Lina & LABAKY Elie

Page 31

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 32

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 33

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 34

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 35

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 36

15/04/2006

Enregistrement et tablissement de session en IMS

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

MROUEH Lina & LABAKY Elie

Page 37

15/04/2006

Enregistrement et tablissement de session en IMS

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.

MROUEH Lina & LABAKY Elie

Page 38

15/04/2006

Enregistrement et tablissement de session en IMS

MROUEH Lina 3me anne du cycle ingnieur Tlcom Paris mroueh@enst.fr

LABAKY Elie 3me anne du cycle ingnieur Tlcom Paris labaky@enst.fr

Avril 2006

MROUEH Lina & LABAKY Elie

Page 39

15/04/2006