Domaine IP multimédia

Transcription

1 Domaine IP multimédia Architecte, fonctionnalités et procédes essentielles de l IMS par Sandrine LATASTE Architecte de réseaux innovants France Telecom Recherche & Développement 1. Poquoi l IP multimédia... TE Architecte IMS Principes d architecte Architecte IMS Souscriptions IMS et identification de l utilisate Procédes réseau dans l IMS (en Rel-5/Rel-6) Vue générale des procédes Support du roaming dans l IMS Découverte du point d entrée dans l IMS Enregistrement dans l IMS Établissement de session multimédia Modification de session multimédia Relâche de session multimédia Fin d enregistrement Gestion de la QoS dans l IMS Sécité dans l IMS Authentification Tunnel IPSec entre terminal et P-CSCF Passerelles de sécité Fonction I-CSCF(THIG) Conclusion L e domaine IP multimédia fait l objet d une standardisation internationale au sein de l organisme 3GPP. Cet organisme est aussi à l origine du standard du réseau mobile de troisième génération (UMTS). Le domaine IP multimédia est conçu po rendre des services de type IP multimédia en réutilisant les services déjà existants au sein d Internet (sans nécessairement développer des applications spécifiques au 3GPP). L idée générale est de fonir un réseau support po permettre le développement de services de manière indépendante du réseau et aussi po permettre la création et l implémentation rapide de services utilisant les capacités de l IMS. Il doit être noté que les opérates de télécommunications, les fonisses de contenu multimédia, les sociétés informatiques ou les fonisses d accès Internet sont candidats au développement de services IMS. est strictement interdite. Editions T.I. TE

2 DOMAINE IP MULTIMÉDIA 2G/3G 3GPP ADSL AS ATM COPS CN CS CSCF DHCP DNS FQDN GERAN GGSN GPRS HSS I-CSCF IETF IMS I-WLAN IMSI IP ISIM LDP MMSC NGN PCRF Glossaire 2 nd Generation/3 rd Generation 3 rd Generation Partnership Project Asymmetric Digital Subscriber Line Application Server Asynchronous Transfer Mode Common Open Policy Service Core Network Circuit Switched Call Session Control Function Dynamic Host Configation Protocol Domain Name System Fully Qualified Domain Name GPRS EDGE Radio Access Network Gateway GPRS Support Node General Packet Radio Service Home Subscriber Server Interrogating-CSCF Internet Engineering Task Force IP Multimedia Subsystem Intelligent Wireless Local Area Networking International Mobile Subscriber Identifier Internet Protocol IP Subscriber Identity Module Label Distribution Protocol MultiMedia Session Continuity Next Generation Network Policy Control and Charging Rules Function P-CSCF PDF PDP PEF PEP PLMN Glossaire (suite) Proxy-CSCF Policy Decision Function Policy Decision Point Policy Enforcement Function Policy Enforcement Point Public Land Mobile Network Application Server PS Packet Switched PSTN Public Switched Telephone Network QoS Quality of Service Rel-5/Rel-6 Release 5/Release 6 RAN Radio Access Network RFC Request For Comments RSVP ReSerVation Protocol SAE System Architecte Evolution SBLP Service-Based Local Policy S-CSCF Serving-CSCF SDP Session Description Protocol SGSN Serving GPRS Support Node SIP Session Initiation Protocol SLF Subscription Locator Function STM Synchronous Transfer Mode UE User Equipment UMTS Universal Mobile Telecommunications System URI Uniform Resoce Identifier URL Universal Resoce Locator USIM Universal Subscriber Identity Module UTRAN Universal Terrestrial Radio Access Network 1. Poquoi l IP multimédia? Le domaine IP multimédia peut être considéré comme un réseau permettant la fonite de services IP multimédia à un utilisate qui y accède depuis un réseau sous-jacent. Ce réseau offre à l utilisate une connectivité IP, initialement l UMTS avec la release 5, puis le I-WLAN en release 6 et l ADSL en release 7. Avant la construction de l architecte IMS, le réseau support (par exemple, le GPRS) permet d accéder à des services exécutés s des plates-formes de services directement connectées à ce réseau. Les services ainsi supportés utilisent le mode client/serve et ne permettent pas une interaction simple des services entre eux. L IMS permet au contraire d offrir des services interpersonnels en combinant la voix et les services de données. Il rend aussi possible la combinaison de plusies services po rendre un service plus sophistiqué (par exemple, en combinant le service de présence avec un service de renvoi d appel). De plus, il permet de simplifier le terminal de l utilisate en implémentant une pile SIP. Cette pile rend alors divers services basés s les fonctionnalités de ce protocole (service de messagerie, service de présence, etc.) au lieu d implémenter localement une application dédiée à chaque service (client de messagerie, client de présence). Po un opérate de réseaux, l IMS permet aussi d homogénéiser des fonctions réseau utiles à l ensemble des services, telles que le système de factation, la gestion des utilisates dans les bases de données, le système de sécité, la gestion de la qualité de service, etc. TE est strictement interdite. Editions T.I. Dossier délivré po

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

4 DOMAINE IP MULTIMÉDIA Fige 1 Architecte IMS en release 6 Tableau 1 Liste des entités et interfaces Entité Interface Protocole Entité Interface Protocole Cx Interface entre CSCF et HSS Diameter Mg Interface entre MGCF et CSCF SIP Dh Interface entre AS Diameter (SIP-AS ou OSA-CSCF) et SLF Mi Interface entre CSCF et BGCF SIP Dx Interface entre CSCF et SLF Diameter Mj Interface entre BGCF et MGCF SIP Gi Interface entre GPRS et réseau IP externe IP Mm Interface entre CSCF et autres réseaux IP SIP Interface entre GPRS et le réseau IMS en particulier multimédia Gm Interface entre UE et P-CSCF SIP Mp Interface entre MRFC et MRFP H.248 Go Interface entre PDF et GGSN (Rel-5/Rel-6) COPS Mr Interface entre CSCF et MRFC SIP Gq Interface entre PDF et P-CSCF (Rel-6) Diameter Mw Interface entre CSCF et CSCF SIP Gx Interface entre CRF et GGSN (Rel-6) Diameter Interface entre PCRF et GGSN (Rel-7) Mx Interface entre CSCF/BGCF et IMS-ALG SIP ISC Interface entre S-CSCF et AS (serve d application) SIP Rx Interface entre CRF et P-CSCF (Rel-6) Interface entre PCRF et P-CSCF (Rel-7) Diameter Sh Interface entre AS (SIP-AS Diameter Ix Interface entre IMS-ALG et TrGW ou OSA-CSCF) et HSS Mb Point d accès vers les réseaux IP v6 IP Si Interface entre IM-SSF et HSS CAP Mn Interface entre MGCF et IM-MGW H.248 Ut Interface entre UE et AS (serve d application) XCAP TE est strictement interdite. Editions T.I. Dossier délivré po

5 DOMAINE IP MULTIMÉDIA Différences s la définition des en-têtes SIP Le 3GPP a besoin d en-têtes spécifiques qui initialement n étaient pas définis à l IETF mais qui ont donné lieu à des RFC [en particulier le RFC 3455 (cf. tableau 2)] po répondre aux besoins du 3GPP : l en-tête «P-Associated-URI» indique la liste des identités publiques qui font partie du même ensemble d enregistrement po l enregistrement implicite, l en-tête «P-Visited-Network-ID» indique le réseau dans lequel se trouve le P-CSCF afin de vérifier les droits de l utilisate po le roaming dans l IMS lors de l enregistrement, l en-tête «P-Access-Network-Info» indique le type de connectivité IP utilisé par le terminal po accéder aux services IMS, soit le GERAN, l UTRAN, l ADSL, le Wifi, etc., les en-têtes «P-Charging-Function-Addresses» et «P-Charging-Vector» servent à la factation des services IMS. Le 3GPP rend obligatoire l usage de certains en-têtes dont l usage est optionnel au 3GPP : le réseau IMS (P-CSCF) certifie l identité publique de l utilisate en insérant obligatoirement l en-tête «P-Asserted-Identity». Diameter Le protocole Diameter est utilisé au 3GPP po gérer les interactions entre les CSCF et les bases de données HSS et SLF. Il est en fait spécifié (TS , TS ) par delta par rapport au protocole défini à l IETF (RFC 3588) avec des codes spécifiques alloués par l IETF po le 3GPP (RFC 3589) (cf. tableau 2) Protocoles inchangés po les besoins du 3GPP L architecte IMS intègre aussi des interfaces avec des entités externes telles que des serves DHCP et DNS définis à l IETF et dont l usage au 3GPP est conforme à l IETF (et dont l utilisation sera vue lors des procédes IMS, par exemple la découverte du P-CSCF). 2.3 Souscription IMS et identification de l utilisate L utilisate qui souhaite accéder à des services IMS fait l objet d une souscription : souscription aux services IMS ; Tableau 2 Normes (1) 3GPP IETF (suite) 3GPP TS Network architecte IETF RFC 3262 Reliability of Provisional Responses in SIP 3GPP TS Organization of subscriber data IETF RFC 3263 Session Initiation Protocol (SIP) : Locating SIP Servers 3GPP TS General Packet Radio Service (GPRS) ; Service description IETF RFC 3264 An Offer/Answer Model with the Session Description Protocol (SDP) 3GPP TS End-to-end Quality of Service (QoS) concept and architecte IETF RFC 3265 Session Initiation Protocol (SIP) Specific Event Notification 3GPP TS Architectal requirements IETF RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method 3GPP TS IP multimedia sub-system IETF RFC 3312 Integration of resoces management and SIP 3GPP TS General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio IETF RFC 3313 Private SIP Extensions for Media Authorization Access Network (E-UTRAN) access 3GPP TR Feasibility study on multimedia session IETF RFC 3319 DHCPv6 Options for SIP Servers continuity 3GPP TS Signalling flows for the IP multimedia call control based on SIP and SDP IETF RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP) 3GPP TS GPP TS GPP TS IP Multimedia Call Control Protocol based on SIP and SDP End-to-end Quality of Service (QoS) signalling flows IP Multimedia (IM) Subsystem Cx and Dx interfaces ; Signalling flows and message content Cx and Dx interfaces based on the Diameter protocol ; Protocol détails IETF RFC 3325 IETF RFC 3327 IETF RFC 3329 Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts Secity Mechanism Agreement for SIP 3GPP TS IETF RFC 3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3 rd -Generation Partnership Project (3GPP) 3GPP TS Access secity for IP-based services IETF RFC 3486 Compressing the Session Initiation Protocol (SIP) IETF IETF RFC 3524 Mapping of media streams to Resoce reservation flows IETF RFC 2131 DHCP IETF RFC 3588 Diameter Base Protocol IETF RFC 2782 A DNS RR for specifying the location of services IETF RFC 3589 Diameter command codes for 3gpp release 5 (DNS SRV) IETF RFC 2916 E.164 number and DNS IETF RFC 3680 A Session Initiation Protocol (SIP) Event Package for Registrations IETF RFC 3261 SIP : Session Initiation Protocol IETF RFC 4566 SDP : Session Description Protocol (1) TS : Technical Specification ; RFC : Request For Comments est strictement interdite. Editions T.I. TE

6 DOMAINE IP MULTIMÉDIA IMS Subscription Private User Identity - 1 Private User Identity - 2 Public User Identity-1 Public User Identity-2 Public User Identity-3 Service Profile - 1 Service Profile - 2 Fige 2 Souscription IMS souscription au réseau paquet : une souscription est nécessaire également po accéder au réseau support sous-jacent à l IMS, par exemple une souscription po l accès GPRS Souscription IMS dans les bases de données (HSS et SLF) La souscription IMS de l utilisate se traduit dans le réseau de l opérate par la «création» de cet utilisate dans les bases de données de l IMS, c est-à-dire dans le HSS, et dans le SLF si l opérate dispose de plusies HSS dans son réseau : dans le SLF, il s agit d associer l utilisate à un HSS qui stockera les données de souscription IMS le concernant ; dans le HSS, il s agit de stocker les données de souscription IMS, à savoir les identités de l utilisate et les profils d abonné associés Identification de l utilisate dans l IMS Sans entrer dans les détails de structe des bases de données et le format des données, la fige 2 illustre une souscription IMS avec les liens entre identités publiques et identités privées de l utilisate et ses profils d abonné. L identité privée est attribuée par l opérate réseau et est utilisée à des fins d identification de l utilisate du point de vue réseau (par exemple, po authentifier l utilisate lors de l enregistrement dans le réseau IMS). Elle n est pas utilisée par l utilisate contrairement à l identité publique. L identité publique sert à l utilisate po communiquer avec d autres utilisates : c est l identité que ses correspondants connaissent po le joindre. L utilisate peut disposer d une ou plusies identités publiques po une même identité privée, ce qui signifie qu il pora recevoir des appels avec l une ou l autre des identités publiques si plusies sont enregistrées dans l IMS (par exemple, une identité publique personnelle communiquée à ses proches et une identité publique professionnelle communiquée à ses collègues). sein d une même souscription IMS en release 6 avec un partage d identité publique entre plusies identités privées. Ainsi, s la fige 2, l identité publique 2 est partagée entre l identité privée 1 et l identité privée 2, l intérêt étant po l utilisate de pouvoir être contacté s plusies terminaux avec la même identité publique (fonctionnalité de «forking») Profil de service de l utilisate dans l IMS Le profil de l utilisate fait partie de la souscription IMS (cf. fige 2). Il est associé à une identité privée et à une identité publique au minimum. Les données de souscription IMS de l utilisate seront décrites dans un autre article. 3. Procédes réseau dans l IMS (en Rel-5/Rel-6) 3.1 Vue générale des procédes La fige 3 illustre les procédes utiles po accéder aux services IMS dans l ordre où elles doivent être exécutées po rendre possible, par exemple, la participation du terminal/de l utilisate dans une session (appel reçu ou appel émis). Exemples : sip:user1_public1@home1.net ou sip:jean.dupond@orange.fr sont des exemples d identité publique sous le format SIP URI (une partie utilisate et une partie réseau séparées par le à l instar d une adresse mail). tel : est un exemple d identité publique sous le format tel URI. Ce type d identité publique permet à l utilisate d être joint par un correspondant qui initie un appel voix depuis un réseau en mode circuit (PSTN, mobile GSM, ce qui nécessite une conversion po router l appel dans le réseau IMS jusqu à l utilisate). En release 5, l utilisate ne peut disposer que d une identité privée (en vert s la fige 2) alors qu il peut en avoir plusies au Fige 3 Accès aux services IMS TE est strictement interdite. Editions T.I. Dossier délivré po

7 DOMAINE IP MULTIMÉDIA Les étapes 1 et 2 sont des étapes préalables exécutées non pas dans le réseau IMS, mais au niveau du réseau support sous-jacent à l IMS (par exemple, le réseau GPRS si l utilisate accède à l IMS avec une technologie GPRS). Les étapes suivantes correspondent réellement à des procédes exécutées dans le réseau IMS et ce sont celles-ci qui seront décrites dans le présent document. Étape 1 : le terminal initialise une procéde d enregistrement réseau, c est-à-dire qu il se connecte au réseau support et lance, par exemple, une procéde dite «GPRS Attach» (procéde souvent automatique lors de la mise sous tension du terminal), s il souhaite accéder aux services IMS depuis une connexion de type GPRS. Étape 2 : le terminal lance l activation d un lien de transmission qui servira au minimum po le transport de la signalisation qui sera échangée avec le réseau IMS. Il peut obtenir une adresse IP lors de l établissement du lien de transmission ou immédiatement après. Cette adresse lui sera utile po communiquer avec le réseau IMS dans les procédes IMS à venir (par exemple, po communiquer avec son correspondant dans une session multimédia). Étape 3 : le terminal lance une procéde de découverte du P-CSCF, qui sera son point d entrée dans le réseau IMS po toute fute procéde IMS. Étape 4 : le terminal demande à s enregistrer dans le réseau IMS, de façon que le réseau l authentifie et qu il puisse communiquer avec lui po tout échange fut (par exemple, po établir un appel multimédia). Étape 5 : le terminal (de même que le P-CSCF) s abonne auprès du S-CSCF (serve d enregistrement dans l IMS) de façon à être notifié de tout changement d état d enregistrement sachant que le terminal/l utilisate peut demander la fin de son enregistrement dans le réseau IMS mais que le réseau peut aussi mettre un terme à l enregistrement de l utilisate (par exemple, lors de la fin de la souscription aux services IMS). Étape 6 : le terminal est en mese d accéder à ses services IMS, par exemple recevoir un appel ou établir un appel vers un autre terminal/utilisate ou un serve d application. Les procédes des étapes 3 à 6 sont décrites plus spécifiquement dans les paragraphes suivants, étant entendu que le contenu de chaque message ne sera pas détaillé mais que les flux seront présentés de façon globale. Nota : le terminal utilisé po accéder aux services IMS nécessite des évolutions par rapport aux terminaux UMTS des versions précédentes, po la simple raison qu il doit intégrer une pile SIP de manière à échanger de la signalisation avec le réseau IMS. 3.2 Support du roaming dans l IMS Lorsque l utilisate accède à des services IMS depuis un réseau dans lequel il n a pas souscrit à ces services IMS (réseau visité au lieu du réseau «home») : il utilise certains équipements du réseau sous-jacent chez l opérate du réseau sous lequel il se trouve actuellement (par exemple, po un accès UMTS l utilisate est connecté via un l UTRAN et le SGSN dans le réseau visité le GGSN pouvant être dans le réseau «home» ou visité) ; il peut utiliser certaines entités dans l IMS du réseau visité ou toutes les entités du réseau IMS home (réseau auprès duquel il a souscrit ses services IMS). Dans ce dernier cas, cela signifie que l utilisate peut se trouver, par exemple, à l étranger sans qu il n y ait de différence dans l exécution des procédes du réseau IMS (cas où le point d entrée de l utilisate dans l IMS est le P-CSCF du réseau «home»). Dans les figes 4 et 5, l opérate du réseau visité est représenté par ses entités en rose tandis que l opérate du réseau «home» est représenté par ses entités en orange (po des raisons de simplicité, les figes sont dépouillées des entités d interfonctionnement et des plates-formes de services). Po garantir un contrôle des ressoces dans son réseau (cf. principe 3 au paragraphe 2.1), le P-CSCF et le point de terminaison de connectivité IP se trouvent dans le réseau du même opérate (tous les deux dans le réseau «home» ou tous les deux dans le réseau visité en fonction des accords de roaming entre opérates). Cas du roaming avec le P-CSCF dans le réseau «home» Les figes 4 et 5 illustrent le cas du roaming lorsque le point d entrée de l utilisate po l IMS ainsi que le point de terminaison de sa connectivité IP sont dans le réseau «home». Cas du roaming avec le P-CSCF dans le réseau visité Les figes 6 et 7 illustrent le cas du roaming lorsque le point d entrée de l utilisate po l IMS, ainsi que le point de terminaison de sa connectivité IP, sont dans le réseau visité. Comparaison Les différences s les flux de messages, lorsque l utilisate accède à l IMS depuis un P-CSCF dans le réseau «home», est expliqué par delta : le P-CSCF se situe dans le réseau «home» au lieu du réseau visité ; la fonction I-CSCF(THIG) n est pas utilisée alors qu elle peut l être optionnellement dans le cas du roaming IMS si l opérate du réseau «home» souhaite masquer la topologie de son réseau au réseau visité (cf. 4 Sécité dans l IMS). Les procédes dans ce document sont présentées en situation de roaming IMS, c est-à-dire avec le P-CSCF dans un réseau visité po rester le plus général possible. Dans le cas où le P-CSCF est dans le réseau «home», le routage des données et de la signalisation se fait avec une terminaison de connectivité IP dans le réseau «home», ce qui pose des problèmes de «tromboning» lorsque le terminal appelle depuis l étranger un correspondant dans le même pays. Exemple : lorsque le terminal se trouve aux États-Unis et appelle un correspondant aux États-Unis, le trafic est routé via le GGSN de la France po revenir aux États-Unis au lieu de rester aux USA (c est le phénomène de tromboning. En pratique, les opérates de télécommunications utilisent le GGSN dans le réseau par choix d implémentation. 3.3 Découverte du point d entrée dans l IMS Le P-CSCF est le point d entrée de l utilisate dans le réseau IMS. Il est découvert par le terminal au moyen de l une des procédes suivantes : soit pendant l établissement du lien de transmission po la signalisation par des méthodes spécifiques à la technologie utilisée (par exemple, attribution par le GGSN de l adresse du P-CSCF po un accès GPRS) ; soit, après, par des méthodes indépendantes de la technologie de connexion IP en utilisant des méthodes standards de l IETF telles que DHCP/DNS : le terminal contacte un serve DHCP qui attribue : directement l adresse IP du P-CSCF ou, le nom de domaine (FQDN) du P-CSCF et l adresse IP du serve DNS à contacter po retrouver l adresse IP du P-CSCF. La fige 8 illustre l utilisation de DHCP et DNS po un terminal qui a activé un lien de transmission GPRS («PDP context»). 3.4 Enregistrement dans l IMS Rôle de l enregistrement L enregistrement vise à rendre l utilisate disponible po l accès à ses services IMS, ce qui signifie que l utilisate ne peut est strictement interdite. Editions T.I. TE

8 DOMAINE IP MULTIMÉDIA Fige 4 Accès à l IMS depuis un réseau visité via un P-CSCF du réseau «home» IP en cos d utilisation. Il établit une route entre le terminal et ce S-CSCF, de sorte que chaque message échangé entre l utilisate et le réseau IMS utilisera ce chemin préétabli lors de l enregistrement. Le S-CSCF servira par la suite à contrôler l accès de l utilisate à chaque service IMS demandé (puisqu il aa téléchargé localement les données de souscription de l abonné lors de l enregistrement) si besoin en interagissant avec des serves d application connectés au S-CSCF. L enregistrement permet aussi au réseau d authentifier l utilisate et à l utilisate d authentifier le réseau puis d établir une relation sécisée entre le terminal et le P-CSCF (tunnel IPSec po le transfert de la signalisation SIP). Cela sera développé dans le paragraphe 4 «Sécité dans l IMS» Enregistrement implicite Fige 5 Accès à l IMS depuis un réseau visité via un P-CSCF du réseau «home», routage au niveau de la connectivité IP pas émettre ou recevoir d appel ni accéder à tout autre service IMS s il n est pas connu du réseau par une procéde d enregistrement. Il assigne un serve d enregistrement à l utilisate, c est-à-dire sélectionne un S-CSCF po enregistrer l utilisate dans ce S-CSCF via une correspondance entre ses identités et son adresse Il est possible d enregistrer plusies adresses publiques de l utilisate au sein d une même procéde d enregistrement. Cette fonctionnalité d enregistrement implicite est spécifique à l IMS 3GPP (non prévu po SIP IETF) po économiser la signalisation passée, en particulier, s l interface radio po un accès de type GPRS. Cela est rendu possible grâce au regroupement de plusies identités publiques au sein d un même ensemble dans la souscription IMS de l utilisate. Les identités publiques d un même ensemble d enregistrement peuvent avoir des profils de services différents mais appartiennent tous à la même identité privée de l utilisate comme illustré s la fige 9 (page 10). TE est strictement interdite. Editions T.I. Dossier délivré po

9 DOMAINE IP MULTIMÉDIA Fige 6 Accès à l IMS depuis un réseau visité via un P-CSCF du réseau visité Fige 8 Procéde de découverte du P-CSCF via DHCP/DNS po un accès GPRS Fige 7 Accès à l IMS depuis un réseau visité via un P-CSCF du réseau visité, routage au niveau de la connectivité IP Procéde d enregistrement La fige 10 illustre les messages échangés po enregistrer l utilisate : les messages en noir utilisent le protocole de signalisation SIP échangée entre le terminal et les CSCF du réseau IMS ; les messages en orange sont des requêtes/réponses DNS échangées entre le P-CSCF découvert par le terminal et un serve DNS dans le même réseau po connaître le point d entrée dans le réseau «home» de l utilisate. Le P-CSCF utilise le nom de domaine du réseau «home» indiqué par l utilisate/le terminal dans la requête REGISTER et le convertit en adresse IP qui indique le I-CSCF ; les messages en vert illustrent les interactions entre les CSCF (I-CSCF et S-CSCF) et les bases de données (SLF et HSS). Ce sont des messages utilisant le protocole Diameter. L interrogation au SLF permet d obtenir l adresse du HSS qui contient les données de l utilisate. L interrogation au HSS permet d obtenir les informations de l utilisate nécessaires à son enregistrement dans le réseau IMS et notamment les données servant à l authentification. est strictement interdite. Editions T.I. TE

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

11 DOMAINE IP MULTIMÉDIA Fige 10 Procéde d enregistrement de l utilisate est strictement interdite. Editions T.I. TE

12 DOMAINE IP MULTIMÉDIA Fige 11 Procéde d établissement de session TE est strictement interdite. Editions T.I. Dossier délivré po

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

14 DOMAINE IP MULTIMÉDIA Fige 12 Ajout de média avec ajout de ressoces Fige 13 Ajout de média avec modification des ressoces existantes TE est strictement interdite. Editions T.I. Dossier délivré po

15 DOMAINE IP MULTIMÉDIA Fige 14 Suppression de média Fige 15 Modification de session sans addition/suppression de médias est strictement interdite. Editions T.I. TE

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

17 DOMAINE IP MULTIMÉDIA Fige 16 Fin de session initiée par l utilisate Fige 17 Fin de session initiée par le P-CSCF Fin de session initialisée par le réseau Le P-CSCF ou le S-CSCF (de sa propre initiative ou s demande du HSS) peut demander la relâche de session Fin de session initiée par le P-CSCF Comme illustré en fige 17, le P-CSCF peut initialiser la fin de session s il reçoit une indication de perte de couverte radio ou si les ressoces de l utilisate sont supprimées par le réseau (SGSN, GGSN). Po terminer la session, le P-CSCF invoque la procéde de fin d autorisation des ressoces (bloc «Revoke authorization for resoces») et émet un message SIP BYE vers le terminal distant afin que les ressoces soient relâchées de son côté également Fin de session initiée par le S-CSCF (éventuellement s demande du HSS) Le S-CSCF peut initialiser la fin de session, par exemple du fait de l expiration de l enregistrement (relative à une identité publique de l utilisate et une adresse IP). Le HSS peut demander au S-CSCF d initialiser la fin de session, par exemple du fait de la fin de la souscription de l abonné IMS. est strictement interdite. Editions T.I. TE

18 DOMAINE IP MULTIMÉDIA Fige 18 Fin de session initiée par le S-CSCF La procéde de relâche de la session initiée par le S-CSCF est identique quelle que soit la raison. Comme illustré en fige 18, la relâche de la session est initiée par le S-CSCF via une requête «SIP BYE» envoyée vers l appelé puis le S-CSCF émet un «SIP BYE» vers l appelant. Le GGSN demande la relâche des ressoces de la session lors de la procéde de fin d autorisation des ressoces (bloc «Revoke authorization for resoces») si le terminal ne lui adresse pas la demande (via une requête «PDP context déactivation»). 3.8 Fin d enregistrement Au niveau de l IETF, la commande de fin d enregistrement utilise le même message SIP que la demande d enregistrement (à savoir «SIP REGISTER») mais une dée d enregistrement nulle. Au 3GPP, non seulement le terminal peut initier une fin d enregistrement mais également le réseau : le terminal demande notamment la fin d enregistrement quand l utilisate ne souhaite plus accéder à ses services. Cette procéde démarre avec l envoi d un message SIP REGISTER depuis le terminal ; la fin d enregistrement peut svenir à l initiative du réseau po différentes raisons explicitées plus loin. Cette procéde utilise le message «SIP NOTIFY» et non plus le «SIP REGISTER». Lors de la fin d enregistrement (initié par l utilisate ou le réseau) : le terminal doit mettre fin à ses sessions en cos ; le HSS supprime l adresse du S-CSCF stockée po l utilisate (il est possible de la conserver si cette option est souhaitée par l opérate) ; les CSCF et le terminal suppriment les données d enregistrement correspondant à l adresse publique et l adresse IP po lesquelles la fin d enregistrement est demandée ; le terminal et le P-CSCF suppriment l association de sécité établie entre eux pendant l enregistrement, s il ne reste plus d enregistrement actif po l utilisate Fin d enregistrement initiée par l utilisate La fige 19 illustre une fin d enregistrement demandée par l utilisate. Le S-CSCF initie la relâche des sessions actives de l utilisate (po l identité publique et associées qui sont en cos de fin d enregistrement avec la même adresse IP) si le terminal n en a pas fait la demande avant la fin d enregistrement. Les données d enregistrement sont supprimées s réception du «200 OK» au «REGISTER» Fin d enregistrement initiée par le réseau Le S-CSCF peut initier la fin d enregistrement en réaction à : une indication interne, typiquement l expiration de la dée d enregistrement ; ou une indication externe, typiquement une demande émanant du HSS, la procéde étant légèrement différente dans ce dernier cas. Dans les deux cas, le P-CSCF et le terminal sont notifiés (requête «SIP NOTIFY») de la fin d enregistrement puisqu ils y avaient préalablement souscrit lors de l enregistrement de l utilisate dans l IMS. Les données d enregistrement sont supprimées s réception du «200 OK» à «NOTIFY». Fin d enregistrement initiée par le S-CSCF La fige 20 illustre une fin d enregistrement demandée par le S-CSCF. Fin d enregistrement initiée par le HSS Plusies raisons possibles ont été spécifiées au 3GPP po initier la fin d enregistrement depuis le HSS : la fin de souscription IMS de l utilisate ; l allocation d un nouveau S-CSCF po servir l utilisate (cas d erre où le S-CSCF assigné à l utilisate n est pas joignable) ; une demande de réenregistrement de l utilisate via un autre S-CSCF. La fige 21 (page 20) illustre une fin d enregistrement demandée par le HSS quelle que soit la cause. TE est strictement interdite. Editions T.I. Dossier délivré po

19 DOMAINE IP MULTIMÉDIA UE P-CSCF DNS I-CSCF S-CSCF HSS SLF 1. REGISTER 2. DNS Query/response 3. REGISTER 4. User-Authorization-Request 5. User-Authorization-Answer 6. User-Authorization-Request 7. User-Authorization-Answer 8. REGISTER 9. Server-Assignment- Request 10. Server-Assignment- Answer OK OK OK Fige 19 Fin d enregistrement initiée par l utilisate UE P-CSCF DNS I-CSCF S-CSCF HSS SLF 1. De-registration event occs 2. NOTIFY 3. NOTIFY OK OK 6. NOTIFY OK 8. Service control 9. Server-Assignment- Request 10. Server-Assignment- Answer Fige 20 Fin d enregistrement initiée par le S-CSCF 3.9 Gestion de la QoS dans l IMS La gestion de la qualité de service consiste à attribuer de façon optimale les ressoces réseau de l opérate en ordonnant les priorités du trafic de chaque utilisate en fonction de l application utilisée. La qualité de service revêt un caractère important dès lors que le trafic réseau s intensifie (avec des débits de plus en plus élevés) et que les applications deviennent de plus en plus exigeantes (audio, vidéo, jeux interactifs qui ne se contentent pas du «best effort»). Des mécanismes de gestion de la QoS sont disponibles po l IMS po permettre : l optimisation des ressoces de l opérate préférable à un sdimensionnement du réseau ; la satisfaction de l utilisate avec une priorisation du trafic en fonction du besoin de l application. est strictement interdite. Editions T.I. TE

20 DOMAINE IP MULTIMÉDIA UE P-CSCF DNS I-CSCF S-CSCF HSS SLF 1. De-registration event occs 2. Registration- Termination-Request 3. NOTIFY 4. NOTIFY OK OK 7. NOTIFY OK 9. Service control 10. Registration- Termination-Answer Fige 21 Fin d enregistrement initiée par le HSS Fige 22 Mécaismes de QoS dans l IMS Mécanismes de QoS dans l IMS Po fonir à l utilisate une qualité de service de bout en bout, il est impératif de gérer la qualité de service dans chaque domaine et, en particulier, avec les réseaux externes. Le 3GPP introduit une fonction «Service Based Local Policy» (SBLP) optionnelle dans l IMS qui permet de contrôler l utilisation des ressoces engagées po une session ou un service. D autres moyens de contrôler la qualité de service sont envisageables seuls ou en combinaison avec SBLP, notamment des mécanismes de QoS IP classiques à la frontière entre des domaines gérés par des opérates différents : des mécanismes via une signalisation spécifique de négociation de bout en bout (par exemple RSVP, LDP) ; le marquage des paquets IP le long du flux de bout en bout (par exemple DiffServ, MPLS) ; des accords entre opérates po contractualiser la QoS aux routes frontières entre les domaines des opérates. La fige 22 illustre : la gestion de la QoS au niveau IP (blocs «IP BS manager») ; la gestion de la QoS au niveau UMTS (blocs «UMTS BS manager») avec une fonction de traduction entre les deux ; la fonction SBLP via la relation PDP/PEP (Policy Decision Point/Policy Enforcement Point). TE est strictement interdite. Editions T.I. Dossier délivré po

21 DOMAINE IP MULTIMÉDIA Fonction «Service Based Local Policy» (SBLP) dans l IMS La fonction «Service Based Local Policy» (SBLP), optionnelle, permet de contrôler l utilisation des ressoces engagées po une session ou un service IMS. En R5 et R6, cette fonction est implémentée dans le PDF au niveau IP et fonctionne s la base de décisions envoyées depuis le PDF (qui agit en tant que Policy Decision Point, PDP) vers le GGSN (po un accès GPRS, le point de terminaison de connectivité IP) qui met en œuvre ces décisions (agit en tant que Policy Enforcement Point, PEP). Le PDP et PEP sont localisés dans le réseau du même opérate avec une interface intra-opérate car il n est pas concevable po un opérate que ses ressoces soient contrôlées par une entité située chez un autre opérate. Le PDF définit po une session chaque flux IP qui la compose, un flux IP étant unidirectionnel et défini par le quintuple (adresse IP soce, port soce, adresse IP destination, port destination, protocole). Po chaque flux IP, une «porte» est créée au niveau du GGSN car les décisions du PDF seront relatives à un flux IP (ouverte ou fermete de «porte»). Le PDF prend ses décisions s la base des informations reçues du P-CSCF dans la signalisation via l interface Gq (cf. fige 22). Le PDF transforme ces informations en paramètres de QoS IP selon des règles de conversion standardisées et les transmet au GGSN via l interface Go (cf. fige 22). Le GGSN les convertit à son to en termes de paramètres de QoS UMTS de façon à établir les limites de la QoS autorisée po l utilisate et la session. Le terminal dérive de son côté les paramètres de la session (SIP/SDP) en paramètres de QoS UMTS de façon à demander des ressoces correspondant effectivement aux besoins de la session. Les différentes conversions entre paramètres de QoS sont explicitées dans le paragraphe suivant au niveau du PDF, du GGSN et du terminal Paramètres de QoS Informations de session SIP/SDP dérivées en paramètres de QoS IP au PDF Les paramètres de QoS IP sont dérivés au PDF s la base des informations de session contenues dans la signalisation SIP. Il s agit plus spécifiquement du corps de message SDP du message SIP, à savoir les lignes m, a et b du SDP : la ligne m indique le type de média par exemple audio ; les lignes a listent les attributs de média et indiquent notamment si un média est bidirectionnel ou unidirectionnel ; la ligne b indique la bande passante. L autorisation QoS IP contient notamment po chaque flux IP de la session IMS : des paramètres de bande passante maximale autorisée dans le sens entrant et dans le sens sortant (calculée s la base de l en-tête bande passante indiquée dans le SDP du message SIP s il est présent, une vale par défaut configée par l opérate sinon) ; un paramètre indiquant la classe de QoS maximale autorisée, typiquement une classe A po un média de type audio utilisant RTP/RTCP Paramètres de QoS IP dérivés en paramètres de QoS UMTS au GGSN Les paramètres de QoS IP sont dérivés au GGSN en paramètres de QoS UMTS po chaque «PDP context» de la session IMS : des paramètres de bande passante maximale autorisée dans le sens entrant et dans le sens sortant ; une classe maximale autorisée, par exemple classe de type conversationnelle po une classe de QoS IP de type A Informations de session SIP/SDP dérivées en paramètres de QoS UMTS au terminal De son côté, le terminal dérive les paramètres de la session (SIP/SDP) en paramètres de QoS UMTS de façon à demander des ressoces correspondant effectivement aux besoins de la session Procédes de QoS dans l IMS Diverses procédes de QoS sont définies afin de contrôler l usage des ressoces au moyen de la fonction SBLP. Elles reposent s l utilisation d un jeton commun entre la couche applicative et la couche transport en Rel-5/Rel-6. Le jeton est généré par le PDF. Elles sont présentées ici po le cas du GPRS mais sont applicables à tout type d accès (le GGSN étant considéré comme un point de terminaison de connectivité IP comme un autre). Les procédes servent à adapter les ressoces aux besoins applicatifs et sont invoquées notamment : lors de l établissement de session po asser que les ressoces demandées par l utilisate sont conformes à la session en cos d établissement ; lors de la modification de session afin que les ressoces nécessaires soient engagées tout en assant que des ressoces ne soient pas engagées en excès par rapport à l autorisation de QoS ; la relâche de la session po asser que les ressoces utilisées po la session soient libérées et disponibles po d autres utilisates si besoin Procéde d autorisation des ressoces (déclenchée au P-CSCF, décision du PDF vers le GGSN) Cette procéde dite «Authorize QoS resoces» consiste po le PDF à calculer une autorisation en termes de QoS IP s la base de la demande de niveau applicatif (s le contenu de la signalisation SIP). Typiquement, une demande d établissement de session est reçue au P-CSCF sous la forme d un message «SIP INVITE» contenant un corps de message SDP qui décrit la session en termes de média souhaité (par exemple un média audio). La procéde d autorisation des ressoces vise à dériver ces informations de session en paramètres d autorisation de niveau IP, par exemple caractériser un ou plusies flux de média avec une bande passante autorisée associée. Le PDF génère un jeton d autorisation qui servira à caractériser la session et qui devra être utilisé par le terminal lors de la réservation des ressoces. Le GGSN dérive l autorisation de QoS IP en paramètres de QoS UMTS Procéde de réservation des ressoces (déclenchée au terminal, demande de décision du GGSN vers le PDF) Cette procéde est initialisée par le terminal po demander des ressoces au niveau du plan usager (par exemple, une de demande d activation de «PDP context») po transporter les flux IP de la session IMS. Po ce faire, le terminal convertit les paramètres de la session (contenus dans le SDP) en paramètres de QoS de niveau transport, typiquement paramètres de QoS UMTS. Lors de cette demande de ressoces, le terminal utilise le jeton d autorisation correspondant à la session de manière que le GGSN demande une décision au PDF po ces ressoces. Le PDF lui retone l autorisation de QoS IP que le GGSN convertit en autorisation de QoS UMTS puis accepte la demande de ressoces si elle ne dépasse pas l autorisation ainsi déterminée Procéde d engagement de ressoces (déclenchée au P-CSCF, décision du PDF vers le GGSN) Cette procéde dite «Approval of QoS commit» consiste au PDF à donner l ordre au GGSN d ouvrir les «portes» po les flux IP de la session, ce qui signifie que les paquets IP po ce flux IP peuvent traverser le GGSN po joindre le réseau IMS. est strictement interdite. Editions T.I. TE

22 DOMAINE IP MULTIMÉDIA Procéde de désengagement des ressoces (déclenchée au P-CSCF, décision du PDF vers le GGSN) Cette procéde dite «Removal of QoS commit» consiste au PDF à donner l ordre au GGSN de fermer les «portes» po les flux IP de la session, ce qui signifie que les paquets IP po ce flux IP ne peuvent plus traverser le GGSN po joindre le réseau IMS. C est la procéde inverse de celle décrite précédemment Procéde de fin d autorisation des ressoces (déclenchée au P-CSCF, décision du PDF vers le GGSN) Cette procéde dite «Revoke authorization for resoces» est déclenchée notamment lors de la fin de session applicative (typiquement s réception au P-CSCF d un message SIP BYE). Le PDF envoie au GGSN une décision de fin d autorisation des ressoces. Le GGSN relâche les ressoces (typiquement le GGSN initie un message de type «Delete PDP context request») si besoin (après un délai configé par l opérate). L intérêt po l opérate est d asser que les ressoces sont libérées dans le réseau même si le terminal n en fait pas la demande lui-même. C est la procéde inverse de la procéde d autorisation des ressoces Procéde d indication de relâche de ressoces (information du GGSN vers le PDF) Cette procéde dite «Indication of PDP context release» est typiquement initialisée par le terminal lorsqu il demande une relâche des ressoces (le terminal envoie un message de type «Delete PDP context request») mais le SGSN ou le GGSN peuvent également demander la relâche des ressoces. Le GGSN remonte cette indication au PDF qui en informe le P-CSCF. Le P-CSCF peut alors initialiser la relâche de la session au niveau applicatif (à supposer que c est le dernier «PDP context» po la session IMS) typiquement en initialisant un message SIP BYE Procéde d indication de modification de ressoces (déclenchée au terminal, demande de décision du GGSN vers le PDF) Cette procéde dite «Authorization of PDP context Modification» est initialisée par le terminal lorsqu il demande une modification des ressoces (typiquement le terminal envoie un message de type «Modify PDP context request»). Le GGSN remonte cette indication au PDF lorsque les ressoces demandées dépassent l autorisation de QoS UMTS calculée au GGSN. Le GGSN demande une prise de décision au PDF, notamment le refus de la demande ou une modification de la demande de ressoces à la limite autorisée. En option au choix de l opérate, le PDF remonte l indication vers le P-CSCF Procéde d indication de ressoces à 0 kbit/s (indication du GGSN vers le PDF) Cette procéde dite «Indication of PDP context modification» est initialisée par le SGSN en cas de perte de couverte radio. Le SGSN demande la modification des ressoces à 0 kbits/s po des «PDP contexts» de type conversationnel ou de streaming. Le GGSN qui reçoit cette demande notifie le PDF qui en informe le P-CSCF. Le P-CSCF peut initialiser la relâche de la session Procéde de mise à jo d autorisation des ressoces (déclenchée au P-CSCF, décision du PDF vers le GGSN) Cette procéde dite «Update authorization» consiste po le PDF à calculer une nouvelle autorisation en termes de QoS IP s la base de la demande de niveau applicatif. Typiquement, une demande de modification de session est reçue au P-CSCF sous la forme d un message «SIP UPDATE» ou «re-invite». Le P-CSCF transmet les nouveaux paramètres de la session (SDP du message «SIP UPDATE» ou «re-invite») au PDF qui les dérive en paramètres de QoS IP. Le PDF peut rapporter cette mise à jo d autorisation au GGSN (mais attend de préférence une demande du GGSN lorsque le terminal demandera la mise à jo des ressoces). Le GGSN dérive l autorisation de QoS IP en paramètres de QoS UMTS. Le GGSN peut initialiser une demande de modification des ressoces («Update PDP context request» initié par le GGSN) si les ressoces en cos excédent la nouvelle autorisation et le terminal ne demande pas la mise à jo des ressoces («Modify PDP context request» initié par le terminal) après une temporisation. 4. Sécité dans l IMS Différents mécanismes de sécité sont prévus en Rel-5/Rel-6 po asser la sécité dans l IMS : l authentification de l utilisate et la montée du tunnel IPSec entre le terminal et le P-CSCF lors de l enregistrement dans l IMS ; l introduction de passerelles de sécité entre domaines de sécité ; la fonction I-CSCF(THIG) à la sortie du réseau «home» (entre le S-CSCF de l appelant et le I-CSCF de l appelé). 4.1 Authentification Le mécanisme utilisé po l authentification est IMS-AKA (Authentication and Key Agreement) qui repose s l utilisation d un secret partagé entre l utilisate (s l ISIM ou à défaut l USIM) et le réseau IMS (au niveau du HSS). Le HSS, toujos localisé dans le réseau «home» de l utilisate, contient un quintuple d authentification : un challenge aléatoire, RAND ; un jeton d authentification, AUTN (contenant un numéro de séquence et un identifiant MAC) ; une réponse attendue XRES ; une clé de cryptage, CK, et une clé d intégrité, IK, qui assent l intégrité et la confidentialité des messages SIP échangés entre le terminal et le P-CSCF. Dant l enregistrement, le S-CSCF transmet les paramètres RAND et AUTN au terminal qui s en sert po calculer une réponse attendue XMAC. L authentification est mutuelle entre l utilisate et le réseau (S-CSCF) : le terminal compare son XMAC avec le MAC reçu du réseau : le réseau est authentifié s ils sont identiques ; le réseau compare son XRES avec le RES calculé par le terminal : l utilisate est authentifié s ils sont identiques. Il est à noter que l authentification dans l IMS réutilise les principes d authentification de l UMTS (UMTS AKA). Aussi, certains mécanismes de l UMTS-AKA peuvent être partagés avec IMS-AKA. En particulier, tous les mécanismes de l UMTS-AKA sont réutilisés si le terminal contient une USIM (équivalent de la carte SIM po l UMTS) et non une ISIM (équivalent de la carte SIM po l IMS), à savoir : la clé d authentification K qui sert à calculer les paramètres d authentification (XMAC, RES, IK, CK) ; les algorithmes de sécité po calculer les clés de sécité ; le mécanisme de vérification du numéro de séquence qui sert à synchroniser les clés de sécité entre le terminal et le réseau. Lorsque seule l USIM est utilisée, il faut dériver les paramètres utiles à l IMS (qui seraient normalement s l ISIM) depuis l IMSI (identifiant de l utilisate po l UMTS) stocké s l USIM : l identité privée de l utilisate qui est une identité publique temporaire qui ne sert que lors de l enregistrement, les identités publiques associées peuvent en revanche être utilisées ; une identité publique de l utilisate ; le nom de domaine. Nota : un mécanisme a été introduit po asser l authentification des terminaux qui accèdent à l IMS sans USIM ni ISIM (typiquement des terminaux 2G n implémentant pas de fonction IPSec). Ce mécanisme associe l adresse IP du terminal et les identités de l utilisate (identité privée, identités publiques) au niveau du S-CSCF, ce qui permet de vérifier que les messages SIP reçus au S-CSCF ne proviennent pas d un autre utilisate. TE est strictement interdite. Editions T.I. Dossier délivré po

23 DOMAINE IP MULTIMÉDIA Fige 23 Passerelles de sécité dans l IMS 4.2 Tunnel IPSec entre terminal et P-CSCF Les messages de signalisation SIP sont protégés grâce à la montée d associations de sécité entre le terminal et le P-CSCF. Les clés utilisées po les associations de sécité sont CK et IK : l intégrité des données (qui asse que les messages SIP ne sont pas modifiés et l authentification de l émette du message) est obligatoire en Rel-5/Rel-6 et rendue grâce à IPSec ESP ; la confidentialité des données (c est-à-dire le cryptage) est obligatoire en Rel-6 seulement. 4.3 Passerelles de sécité Des passerelles de sécité (SEG po Secity gateway) sont introduites à la frontière entre deux domaines de sécité. Une protection de type IPSec ESP en mode tunnel est obligatoire entre deux passerelles de sécité (IPSec peut asser intégrité et confidentialité) tandis qu elle est optionnelle entre deux nœuds d un même domaine de sécité. Typiquement, lorsque le P-CSCF, I-CSCF et S-CSCF appartiennent au même réseau, la protection IPSec de les échanges est optionnelle. En revanche, un échange entre deux CSCF d opérates différents doit être protégé par IPSec comme l illustre la fige 23 (tunnels IPSec en rouge entre deux SEG en jaune). Il est à noter également qu un échange entre une entité de l IMS et une entité d un réseau non IMS peut être protégé par TLS (Transport Layer Secity), typiquement po l interfonctionnement en Rel-6 de SIP entre le S-CSCF dans l IMS et un proxy SIP externe dans un réseau non IMS (en vert s la fige 23). Le S-CSCF gère localement une liste de partenaires po l interfonctionnement, ce qui lui permet de décider s il peut faire confiance à ce proxy SIP. 4.4 Fonction I-CSCF(THIG) La fonction THIG est implémentée en option à l intérie du I-CSCF et a po rôle de crypter/décrypter les en-têtes SIP qui renseigneraient s la topologie du réseau «home», par exemple les en-têtes «Via», «Route», «Record-Route», «Path» qui montreraient les adresses des nœuds de réseau traversés par une requête SIP. 5. Conclusion Le domaine IP multimédia défini dans l organisme de standardisation po la téléphonie mobile de troisième génération promet la création de services de façon simple. De plus, la mise s le marché de ces services sera plus rapide grâce à une architecte indépendante des technologies du réseau de l opérate. Po le déploiement de services (prenant en considération par exemple l appel multimédia entre deux utilisates), l IMS prend en compte un grand nombre de fonctionnalités réseau telles que l identification et l authentification de l utilisate, la gestion de la qualité de service, la sécité, etc. Ces fonctionnalités sont mises en œuvre au sein des procédes réseau définies po l IMS. En particulier, l enregistrement permet à l utilisate de faire connaître sa localisation actuelle (son adresse IP attribuée dynamiquement en général) afin d accéder à ses services IMS. L établissement de session ainsi que les modifications po ajouter ou supprimer des médias par exemple sont également pris en charge dans le réseau IMS ainsi que la relâche de session et la fin d enregistrement. Le contrôle des ressoces utilisées po les services IMS est géré dynamiquement via la fonction «Service based local policy» qui fait interagir le niveau applicatif (P-CSCF de l IMS) avec le niveau transport (GGSN po le GPRS par exemple) via l entité PDF (Policy control decision en Rel-5/Rel-6). La réalisation des services repose essentiellement s le protocole SIP, protocole de signalisation de référence dans l IMS. Une coordination s avère donc nécessaire entre le 3GPP et l IETF po prendre en considération les besoins spécifiques du 3GPP (ce protocole doit être utilisable dans le contexte IMS défini au 3GPP). En effet, le réseau IMS peut mettre fin à un appel en cas de rupte de ressoces ou de fin de souscription de l utilisate. L IP multimédia permet l accès aux mêmes services de l utilisate via différents types d accès (GPRS, I-WLAN, xdsl) depuis le point de terminaison de connectivité IP de l utilisate (GGSN po le GPRS, PDG po I-WLAN). En tant que service IP, l IMS pora aussi être invoqué via de futes architectes de réseaux telles que l architecte SAE qui prévoit l utilisation d un support de transmission évolué ne tenant plus compte de la technologie d accès. La continuité des services IMS est également à considérer via des architectes de gestion de la mobilité telles que MMSC en cos de spécification, l intérêt po l utilisate étant de continuer l usage de son service même lorsqu il passe d une technologie à l autre en cos de communication (par exemple, depuis le GPRS vers I-WLAN). est strictement interdite. Editions T.I. TE