Pfa Ims
Pfa Ims
Pfa Ims
Un IMS, pour IP Multimedia Subsystem en anglais ou sous-systme IP multimdia en franais, renvoie une architecture rseau standardise conue pour permettre aux oprateurs de tlphonie de dlivrer des services multimdia, la fois par le biais de rseaux fixe et mobile. Il peut s'agir de services de transfert de voix, de messagerie instantane, de jeux interactifs, de partage de contenus... L'IMS repose sur une volution du protocole UMTS (3G version 5) conue pour supporter une surcouche rseau indpendante du type d'accs (UMTS, WLAN, GPRS, DSL, etc.). L'architecture est galement compatible avec des rseaux plus anciens par le biais de passerelles, notamment GSM. Bas sur le protocole IP (Internet Protocol), elle assure la connexion entre les diffrentes infrastructures rseau en prsence, et contrle les sessions et appels, voix et multimdia. Dans cette optique, l'IMS gre la fois les flux voix et donnes.
Sparant le contrle des transactions de la gestion de leur transmission, l'IMS permet de grer des changes point point en prsentant toutes les garanties ncessaires l'acheminement de services multimdia. Pour ce faire, il utilise notamment le protocole SIP (Session Initiation Protocole). Historiquement, le SIP a t labor par l'IETF, consortium de standardisation des protocoles lis Internet, dans le cadre du projet de spcifications techniques de l'UMTS. Dans ses dernires volutions, le SIP supporte nanmoins les rseaux fixes. Cette rflexion s'inscrit dans la vision d'une convergence des services de tlphonie fixe et mobile. Derrire ce concept, et celui d'IMS : l'ide de fournir aux utilisateur un numro de tlphone unique, avec la clef un routage transparent des appels entre ligne fixe et mobile.
NGN. Pour un oprateur tabli, limportant est de dfinir les conditions de migration de leur rseau tlphonique commut actuel vers le NGN.
3. Architecture NGN
La topologie du rseau NGN sarticule autour de 6 couches : - Couche Terminal: Elle contient lensemble des terminaux permettant lutilisateur dtablir et recevoir des appels. - Couche Accs: Elle relie les usagers au rseau et regroupe leur trafic. Elle contient les lments de rseau existant chez loprateur laccs tels que les commutateurs tlphoniques daccs, les PABX, les boucles locales, les BTS / BSC, Les NodeB / RNC, etc. - Couche Transport: Elle transporte le trafic destination. La couche transport utilise la technologie IP (Internet Protocol) ou ATM (Asynchronous Transfer Mode). Loffre NGN des constructeurs sappuie aujourdhui sur une couche de transport bas sur ATM directement ou IP. - Couche Adaptation: Elle conditionne le trafic pour son transport sur le rseau. Par exemple, le trafic vocal est conditionn en cellules ATM ou en paquets IP. Cette couche contient des passerelles (MGW, Media Gateway) permettant linterfonctionnement entre la couche daccs et la couche de transport. - Couche Contrle: Elle assure lintelligence dappel. Cette couche dcide quel service un usager va recevoir. Elle contrle aussi dautres lments de rseau des couches infrieures, leur indiquant quel traitement faire subir au trafic. Elle contient des contrleurs dappels appels Media Gateway Controllers (MGC) puisquils pilotent les MGWs de la couche dadaptation. - Couche Application: Elle fournit des services valeur ajoute par le biais de serveurs dapplications. Seul le MGC peut sinterfacer avec ces serveurs pour invoquer des services. - La Gestion est transversale lensemble des couches. Chaque couche possde sa propre gestion. Ainsi les lments dune couche donne sont vendus avec le systme de gestion qui permet loprateur de superviser, grer et exploiter ces lments.
Cette nouvelle topologie offre les avantages suivants : -Grce au NGN, loprateur dispose dun rseau multiservice permettant dinterfacer nimporte quel type daccs (Boucle locale, PABX, Commutateur daccs tlphonique, accs ADSL, accs mobile GSM ou UMTS, tlphone IP, etc.) -Loprateur naura plus terme qu exploiter un seul rseau multiservice. - Elle utilise le transport comme lIP ou l ATM ignorant les limites des rseaux TDM 64 kbit/s. En effet le TDM perd son efficacit ds lors que lon souhaite introduire des services asymtriques, sporadiques ou dbit binaire variable. - Cest une topologie ouverte qui peut transporter aussi bien les services tlphoniques que les services de multimdia (vido, donnes temps rel). - Elle dissocie la partie support du rseau de la partie contrle, leur permettant dvoluer sparment et brisant la structure de communication monolithique. En effet, la couche transport peut tre modifie sans impact sur les couches contrle et application. - Elle utilise des interfaces ouvertes entre tous les lments, permettant loprateur dacheter les meilleurs produits pour chaque partie de son rseau.
Dans larchitecture NGN Tlphonie, le protocole de contrle tel que MGCP ou MEGACO ne fait que dcrire les interactions entre le MGC et le MGW. Si un MGC doit contrler un MGW qui est sous la responsabilit dun autre MGC, il est ncessaire que les MGCs schangent de la signalisation. Deux protocoles de signalisation peuvent tre utiliss : SIP-T (Session Initiation Protocol for Telephones) et BICC (Bearer Independent Call Control). SIP-T est une proposition de lIETF alors que BICC est spcifi par lITU-T. La figure 5 montre linterface de contrle qui est mise en uvre par le protocole MGCP ou MEGACO/H.248, et linterface de signalisation ralise par le protocole SIP-T ou BICC. Une fois la connexion tablie, le MGW convertira les signaux audio transports dans les circuits de parole (terminaison circuit) en paquets IP qui seront transports dans le rseau IP (terminaison IP) ou en cellules ATM dans le cas dun transport ATM.
5. NGN Multimdia
NGN Multimdia aussi appel IMS (IP Multimedia Subsystem) introduit une nouvelle entit fonctionnelle dans le rseau, appele CSCF (Call State Control Function). Elle joue le rle de Proxy Server SIP, et ses principales fonctions sont : La localisation des usagers en traduisant l'adresse SIP de destination en une adresse IP. Le routage des messages SIP pour l'tablissement, la modification et la libration de sessions multimdias. Le maintien des informations d'tat de la session afin de pouvoir invoquer les services souscrits par les usagers, afin de contrler la session pendant sa dure de vie, et pour la facturation de la session.
Dcembre 2005 - Publication de la premire dition de la norme ETSI sur IMS, centralise sur l'accs fixe haut dbit en DSL, la 3G et le GPRS en IPv4 (50 normes, dont certaines finaliser). Il reste encore traiter du transit, de l'encapsulation ISUP, des appels d'urgence, des interceptions lgales; etc. 2006 - TISPAN travaille avec le DSL Forum, l'UIT-T, le 3GPP, l'IETF, le DVB Forum et les groupes OMA/Parlay spcialiss dans le Rseau Intelligent. 2007 - Sortie prvue de la version 2 de la norme IMS de l'ETSI avec IP/TV, VoD, QoS, accs entreprise","content delivery", etc. 2009 - Sortie annonce de la version 3 relative la mobilit gnralise et la convergence. 2.3 - UIT-T Dbut 2006, la Commission d'tudes 11 de l'UIT-T recevra les travaux de l'ETSI/TISPAN en vue de leur incorporation dans les normes du NGN.
pour transmettre des messages lectroniques (E-mails). SIP sappuie sur un modle transactionnel client/serveur comme HTTP. Ladressage utilise le concept dURL SIP (Uniform Resource Locator) qui ressemble une adresse E-mail. Chaque participant dans un rseau SIP est donc adressable par une URL SIP. Par ailleurs, les requtes SIP sont acquittes par des rponses identifies par un code numrique. Dailleurs, la plupart des codes de rponses SIP ont t emprunts au protocole HTTP. Par exemple, lorsque le destinataire nest pas localis, un code de rponse 404 Not Found est retourn. Une requte SIP est constitue de headers comme une commande SMTP. Enfin SIP comme SMTP est un protocole textuel. SIP a t tendu afin de supporter de nombreux services tels que la prsence, la messagerie instantane (similaire au service SMS dans les rseaux mobiles), le transfert dappel, la confrence, les services complmentaires de tlphonie, etc. SIP a t retenu par le 3GPP pour larchitecture IMS (IP Multimedia Subsystem) comme protocole pour le contrle de session et le contrle de service. Il remplacera terme les protocoles ISUP (utilis pour le contrle dappel dans le Rseau Tlphonique Commut) et INAP (utilis pour le contrle de service dans larchitecture Rseau Intelligent) Le protocole SIP nest quun protocole de signalisation. Une fois la session tablie, les participants de la session schangent directement leur trafic audio/vido travers le protocole RTP (Real-Time Transport Protocol). Par ailleurs, SIP nest pas un protocole de rservation de ressource, il ne peut donc pas assurer la QoS. Il sagit dun protocole de contrle dappel et non de contrle du mdia. SIP nest pas non plus un protocole de transfert de fichier tel que HTTP, utilis afin de transporter de grands volumes de donnes. Il a t conu pour transmettre des messages de signalisation courts afin dtablir, maintenir et librer des sessions multimdia. Des messages courts non relatifs un appel peuvent nanmoins tre transports par SIP la manire des SMS.
requtes SIP, traduit l'adresse SIP de destination en une ou plusieurs adresses rseau et les retourne au client. Contrairement au Proxy server, le Redirect server n'achemine pas de requtes SIP. Dans le cas dun renvoi dappel, le Proxy server a la capacit de traduire le numro de lappel dans le message SIP reu, en un numro de renvoi dappel et
d'acheminer lappel cette nouvelle destination, et ce, de faon transparente pour le client origine ; pour le mme service, le Redirect server retourne le nouveau numro (numro de renvoi) au client origine qui se charge dtablir un appel vers cette nouvelle destination. Lagent utilisateur (UA, User Agent) : Il sagit dune application sur un quipement de lusager qui met et reoit des requtes SIP. Il se matrialise par un logiciel install sur un PC, sur un tlphone IP ou sur une station mobile UMTS (UE, User Equipment). Lenregistreur (Registrar) ; Il sagit dun serveur qui accepte les requtes SIP REGISTER. SIP dispose de la fonction denregistrement dutilisateurs. Lutilisateur indique par un message REGISTER mis au Registrar, ladresse o il est joignable (e.g., adresse IP). Le Registrar met alors jour une base de donne de localisation. Lenregistreur est une fonction associe un Proxy server ou un Redirect server. Un utilisateur peut senregistrer sur diffrents UAs SIP ; dans ce cas, lappel lui sera dlivr sur lensemble de ces UAs.
Lorsquun UA ayant mis la mthode SIP INVITE reoit une rponse finale linvitation (i.e., 200 OK), il confirme la rception de cette rponse par une mthode ACK. Une rponse telle que busy ou answer est considre comme finale alors quune rponse telle que ringing signifiant que lappel est alert, est une rponse provisoire. La mthode BYE permet la libration dune session pralablement tablie. Elle correspond au message RELEASE des protocoles ISUP et Q.931. Un message BYE peut tre mis par lappelant ou lappel. La mthode REGISTER est utilise par un UA afin dindiquer au Registrar la correspondance entre son adresse SIP et son adresse de contact (e.g., adresse IP). La mthode CANCEL est utilise pour demander l abandon d un appel en cours mais na aucun effet sur un appel dj accept. En effet, seule la mthode BYE peut terminer un appel tabli. La mthode OPTIONS est utilise afin dinterroger les capacits et ltat dun User agent ou dun serveur. La rponse contient ses capacits (e.g., type de mdia tant support, mthodes supportes, langue supporte) ou le fait que l'UA soit indisponible.
b- Rponses SIP
Aprs avoir reu et interprt une requte SIP, le destinataire de cette requte retourne une rponse SIP. Il existe six classes de rponses :
Classe 1xx : Information, la requte a t reue, et est en cours de traitement. Classe 2xx : Succs, la requte a t reue, comprise et accepte. Classe 3xx : Redirection, lappel requiert dautres traitements avant de pouvoir dterminer sil peut tre ralis. Classe 4xx : Erreur requte client, la requte ne peut pas tre interprte ou servie par le serveur. La requte doit tre modifie avant dtre renvoye. Classe 5xx : Erreur serveur, le serveur choue dans le traitement dune requte apparemment valide. Classe 6xx : Echec global, la requte ne peut tre traite par aucun serveur.
dynamiquement par DHCP. La fonction Registrar met alors jour une base de donnes de localisation. A partir de cet instant, le User Agent peut recevoir des appels puisqu'il est localis. Si un usager SIP veut renvoyer ses appels de son domaine courant un autre domaine (e.g., du domaine orange.com au domaine francetelecom.com), il lui suffit dindiquer la fonction Registrar de orange.com son adresse SIP dans le domaine francetelecom.com. Quand un message INVITE doit tre dlivr par le proxy serveur du domaine orange.com sip:mary.taylor@orange.com, la base de donnes mise jour par la fonction Registrar indique au Proxy Server que le message doit tre relay sip:mary.taylor@francetelecom.com. Alors le Proxy server effectue une recherche par le DNS de ladresse IP du Proxy server du domaine francetelecom.com afin de lui relayer le message SIP acheminer la destination approprie (sip:mary.taylor@francetelecom.com). Dans un rseau IMS (IP Multimedia Subsystem), le Proxy Server correspond une entit CSCF (Call State Control Function), alors que la base de donnes de localisation est reprsente par l'entit HSS (Home Subscriber Server). Le HSS dans lIMS pour les mobiles est un HLR contenant par ailleurs le profil de l'usager pour les services IMS souscrits.
Par ailleurs, la requte SIP INVITE contient une syntaxe SDP (Session Description Protocol). Cette structure consiste en plusieurs lignes qui dcrivent les caractristiques du mdia que lappelant Mary requiert pour lappel. Mary Taylor indique que la description SDP utilisation la version 0 du protocole, qu'il s'agit d'une session tlphonique (m=audio), que la voix paqutise doit lui tre dlivre l'adresse de transport (port UDP = 45450, adresse IP = 192.23.34.45) avec le protocole RTP et en utilisant un format d'encodage dfini dans le RFC AVP (Audio Video Profile) et pouvant tre G.711 -law ou G.728.
11
INVITE sip:mark.rich@francetelecom.com SIP/2.0 Via : SIP/2.0/UDP station1.francetelecom.com:5060 Max-Forwards : 20 To : Mark Rich <sip:mark.rich@francetelecom.com> From : Mary Taylor <sip:mary.taylor@francetelecom.com> CallId: 23456789@station1.francetelecom.com CSeq: 1 INVITE Contact: mary.taylor@192.190.132.20 Content-Type: application/sdp Content-Length:162
La rponse 180 RINGING est retourne par le destinataire lUA de l appelant. Lorsque l'appel accepte la session, la rponse 200 OK est mise par son UA et achemine lUA de l appelant.
12
SIP/2.0 200 OK Via: SIP/2.0/UDP ps1.francetelecom.com:5060 Via : SIP/2.0/UDP station1.francetelecom.com:5060 Max-Forwards : 20 To : Mark Rich <sip:mark.rich@francetelecom.com> From : Mary Taylor <sip:mary.taylor@francetelecom.com> CallId: 23456789@station1.francetelecom.com CSeq: 1 INVITE Contact: mark.rich@192.190.132.27 Content-Type: application/sdp Content-Length:162
LUA de l appelant retourne une mthode ACK au destinataire, relaye par l'entit Proxy Server. L'entit Proxy Server participe l'acheminement de la signalisation entre UAs alors que les UAs tablissent directement des canaux RTP pour le transport de la voix ou de la vido paqutise sans implication du Proxy Server dans ce transport. Lorsque Mary raccroche, son UA envoie une requte BYE pour terminer la session. Cette requte est remise au Proxy Server qui l'achemine lUA de Mark. Ce dernier retourne la rponse 200 OK.
BYE sip:mark.rich@francetelecom.com SIP/2.0 Via : SIP/2.0/UDP station1.francetelecom.com:5060 Max-Forwards : 20 To : Mark Rich <sip:mark.rich@francetelecom.com> From : Mary Taylor <sip:mary.taylor@francetelecom.com> CallId: 23456789@station1.francetelecom.com CSeq: 2 BYE
SIP/2.0 200 OK Via : SIP/2.0/UDP ps1.francetelecom.com:5060 Via : SIP/2.0/UDP station1.francetelecom.com:5060 Max-Forwards : 20 To : Mark Rich <sip:mark.rich@francetelecom.com> From : Mary Taylor <sip:mary.taylor@francetelecom.com> CallId: 23456789@station1.francetelecom.com
13
CSeq: 2 BYE
Ce Gateway a deux fonctions : Traduction de la signalisation ISUP (ISDN User Part) en signalisation SIP et inversement Conversion des signaux audio en paquets RTP et inversement ; en effet ce Gateway tablit des canaux logiques RTP avec le terminal SIP et tablit des circuits de parole avec un Class 5 ou Class 4 switch. Le Class5 Switch reprsente un commutateur tlphonique laccs alors que le Class 4 Switch est un commutateur tlphonique de transit. Dans lexemple considr la figure 3, un terminal reli au RTC appelle un UA SIP. Le Class 5 Switch auquel est rattach lappelant, met un message ISUP IAM au Gateway RTC/SIP. Ce message contient le numro du destinataire, lidentificateur de circuit choisi par le Class 5 Switch pour lappel (CIC, Circuit Identification Code) ainsi que des informations indiquant la nature de lappel (parole, fax, donnes, etc.). Le Gateway RTC/SIP traduit ce message en une requte SIP INVITE qui contient une adresse de destination SIP dont le champ user est un numro de tlphone. Il passe le message au SIP Proxy server qui obtient ladresse IP du destinataire partir de ladresse SIP par interrogation dune base de donnes ou dun serveur de localisation. Le message INVITE est relay lUA SIP. Paralllement, le Proxy server notifie au Gateway la rception de la requte INVITE par la rponse 100 Trying. Le terminal SIP retourne au Proxy server une rponse 180 Ringing pour informer l appelant de lalerte de lappel, message relay par le Proxy server au Gateway. Le Gateway traduit cette rponse en un message ISUP ACM (Address Complete Message) renvoy au Class 5 Switch. Ce message est traduit par le Class 5 Switch en un message Alerting si le terminal appelant est un terminal RNIS ou en un signal Ringing Tone dans le cas dun terminal analogique. Lorsque lappel dcroche, une rponse 200 OK est retourne au Proxy server qui la relaye au Gateway. Le Gateway acquitte la rception de cette rponse par une requte ACK achemine par le Proxy Server au destinataire. Paralllement, le Gateway gnre un message ISUP ANM (Answer Message) mis au Class 5 Switch. Cet change de signalisation a permis ltablissement de canaux RTP entre le terminal SIP et le Gateway et la mise en place dun circuit de parole entre le Gateway et le Class 5 Switch.
15
Pendant la phase de transfert dinformation, le Gateway convertit les signaux audio reus sur le circuit de parole en paquets RTP envoys sur les canaux RTP et inversement.
16
multimdia et collecte des informations utilisateur. Il sagit de lvolution de lentit SRP (Specialized Resource Point) dans le monde multimdia. Le serveur dappel SIP (Proxy server) joue le rle de point depuis lequel un service peut tre invoqu. Il dispose du profil de service de labonn qui lui indique les services souscrits par labonn et sous quelle condition invoquer ces services. Il correspond au SSP de larchitecture Rseau Intelligent.
17
Les capacits non fonctionnelles : haute disponibilit, partage de charge, tolrance aux fautes. Ces caractristiques sont similaires celles exiges pour un SCP dans larchitecture Rseau Intelligent.
Les fonctions de ressources mdia telles que les fonctions de dtection de tonalit, de synthse vocale, de reconnaissance vocale, de traduction de mdia, etc. Cest la fonction MRFP (Multimedia Resource Function Processor).
Les fonctions de contrle du mdia qui fournissent aux applications les moyens de
contrler les ressources mdia tels que, jouer un message, collecter un vote, enregistrer un message, etc, et ce, travers le protocole SIP. C est la fonction MRFC (Multimedia Resource Function Controller).
L'architecture distribue du serveur de mdia SIP /serveur dapplication spare les applications voix / vido du contrle des mdias, ce qui permet aux oprateurs de rduire les cots des ressources rseau et d'hberger moindre frais les applications clients. Le serveur de mdia IP supporte le protocole de contrle SIP. En plus du serveur de mdia IP et du serveur dapplication, les entits suivantes peuvent tre considres :
Browser VoiceXML : Ce composant intgr dans le serveur de mdia IP fournit un exemple denvironnement dexcution dapplications vocales. Les applications dveloppes selon les spcifications VoiceXML peuvent tre interprtes et excutes par le browser VoiceXML. Ce browser ne fait quinterprter et dterminer les tapes atomiques du call flow. Cest le serveur de mdia IP qui interagit avec lusager.
18
Serveur ASR : Ce composant fournit le service Automatic Speech Recognition (ASR). Le flux audio de lusager est transport sur RTP du Media Gateway ou du tlphone IP de lusager au serveur ASR. Le Browser VoiceXML contacte le serveur ASR lorsqu une reconnaissance de parole est ncessaire. Serveur TTS : Ce composant fournit le service Text-To-Speech (TTS). Une chaine de caractre est mise ce composant et est convertie en une annonce vocale qui peut tre mise l usager sous forme de flux RTP. Le browser VoiceXML contacte le serveur TTS lorsqu un texte doit tre traduit en un message vocal et dlivr lusager. Serveur WEB : Ce composant est un serveur standard HTTP. Il est utilis afin dhberger le Contenu vocal. Ce contenu consiste en des scripts VoiceXML, des annonces vocales/vido, des messages daccueil, et des grammaires de reconnaissance de la parole. Les scripts VoiceXML dfinissent la logique dapplication. Des messages daccueil assistent lusager dans sa navigation dans une application. Les grammaires contiennent les mots permis ou les phrases qu un usager peut prononcer lorsque l application lui demande d entrer des informations.
reconnaissance de la parole est un composant de la plupart des services lusager tels que messagerie vocale (voicemail), la messagerie unifie, les jeux interactifs, et les portails vocaux. Gnration dinformation de taxation : Une taxation prcise et juste est une exigence pour les oprateurs de service afin doffrir des services voix et donnes forte valeur ajoute. Le serveur de mdia SIP gnre des informations de taxation.
19
Interactive Voice Response (IVR) : Le serveur de mdia SIP doit supporter la dtection des tonalits DTMF envoyes dans la bande ainsi que les digits reus via SIP INFO. Enregistrement : Le serveur de mdia SIP a des capacits d enregistrement et de restitution (playback). De nombreuses applications telles que la messagerie vocale, la messagerie unifie, le push-to-talk et
la confrence utilisent cette fonction, i.e., enregistrement de lappel afin quil soit restitu ultrieurement. Le serveur de mdia SIP utilise des serveurs de stockage existants chez loprateur de service. Text-To-Speech : La technologie text-to-speech est troitement associe la fonctionnalit IVR. Le text-to-speech est utilis dans des applications telles que la messagerie unifie afin de lire des E-mail ou des fax travers le tlphone. La traduction peut tre ralise en plusieurs langues. Gestion du multiparties : Le serveur de mdia SIP doit tre capable de fournir tous les mcanismes de contrle des appels plusieurs participants Cette fonctionnalit est utilise dans de nombreuses applications tels que confrence ou le push to talk. Transcodage : Le transcodage permet de convertir un schma dencodage numrique en un autre. Dans le cas d une confrence ou les participants ne disposent pas d un mme codec commun, le serveur de mdia SIP assurera alors les traductions de mdia ncessaires. Interfaces standard ouvertes : Le serveur de mdia SIP doit pouvoir tre contrl travers le protocole SIP et doit pouvoir excuter des scripts VoiceXML.
20
Le service sonnerie diffrentie permet de modifier la sonnerie du poste appel en fonction de l'identit de l'appelant. Ce service basique est typiquement un service qu'il faut dployer sur le poste. Le service filtrage d'appel est une variante du service prcdent dans laquelle l'identit de l'appel sert dterminer si l'appel doit tre accept, renvoy ou refus. Le service annuaire montre l'intrt d'une connexion directe du terminal avec un annuaire d'entreprise : il permet l'utilisateur de consulter un annuaire LDAP depuis le tlphone, de slectionner un numro parmi les rsultats et de lancer un appel vers ce numro.
lauthentification, lautorisation et la taxation online et offline des clients LTE et IMS. Le paragraphe 1 introduit le protocole de base DIAMETER et dcrit les diffrentes applications DIAMETER dfinies par le monde des tlcommunications notamment pour ses architectures LTE et IMS. Le paragraphe 2 prsente les diffrents types de nud DIAMETER, i.e., client, agent et serveur. Le paragraphe 3 dcrit le format des messages DIAMETER et des AVPs (Attribute Value Pair) qui sont les paramtres des messages DIAMETER.
4.2.1 Le protocole DIAMETER est ses applications dans le monde des tlcommunications
Le protocole DIAMETER a t conu comme une version amliore du protocole RADIUS. Un des objectifs tait de maximiser la compatibilit et faciliter la migration de RADIUS DIAMETER. Par exemple, un message DIAMETER comme un message RADIUS transporte un ensemble de paires <attribut, valeur>. DIAMETER est dfini travers un protocole de base et un ensemble dapplications. Cette conception
21
permet une extension du protocole de base pour de nouvelles applications. Le protocole de base fournit des mcanismes pour un transport fiable, la livraison des messages et le traitement des erreurs. Le protocole de base doit tre utilis conjointement avec une application DIAMETER. Chaque application sappuie sur les services du protocole de base. DIAMETER est en particulier utilis dans le monde des tlcommunications par les architectures LTE et IMS. La LTE (Long Term Evolution of 3G) est un projet men par l'organisme de standardisation 3GPP visant rdiger les normes techniques de la future quatrime gnration en tlphonie mobile. Elle permet le transfert de donnes trs haut dbit, avec une porte plus importante et une latence plus faible. En terme de vocabulaire, le futur rseau de quatrime gnration sappelle EPS (Evolved Packet System). Il est constitu dun nouveau rseau daccs appel LTE (Long Term Evolution) et dun nouveau rseau coeur appel SAE (System Architecture Evolution). LEPS (Evolved packet System) a les caractristiques suivantes : Il possde une architecture plate et simplifie compare celle hirarchique 2G/3G puisque la fonction de contrleur dantenne disparat. La seule entit prsente dans laccs LTE est leNodeB qui peut tre assimil un nodeB avec des fonctions du RNC. Il sagit dune architecture uniquement paquet compare larchitecture 2G/3G circuit et paquet. Il permet une connectivit permanente tout-IP (appele default bearer) compare des contextes PDP temporaires ou permanents en 2G/3G dans le domaine paquet Son interface radio est totalement partage entre tous les usagers en mode ACTIF compare des ressources ddies et partages dans larchitecture 2G/3G. Les appels voix et visiophonie requirent des ressources ddies en 3G. Il permet des handover vers les rseaux 2G/3G et CDMA/CDMA2000 afin dassurer des communications sans couture en environnement htrogne.
L'IMS (IP Multimedia Subsytem) normalis par lorganisme 3GPP est une architecture de rseau et de service qui permet le contrle de sessions multimdia sur un rseau IP. Elle supporte des sessions temps rels (voix, vidotlphonie, confrence, IPTV), pseudo temps rel (tchat, push to talk) et non temps rel (SMS). Un seul cur de rseau (IP + IMS) supportant des services multimdia (Services IMS) servira des usagers sur diffrents accs large bande (xDSL, LTE, 3G+, Cble, FTTH, etc). LIMS intgre de plus le concept de convergence des services multimdia. LIMS normalise dj un ensemble de capacits de service telles que la prsence, le
22
messaging, la confrence, les hosted enterprise services, lIPTV, les multimedia telephony services qui correspondent aux services complmentaires de la tlphonie, la voice call continuity, etc.
3GPP dfinit pour LTE et IMS un nombre d applications bases sur le protocole DIAMETER qui supportent les interfaces suivantes : S6 (LTE) : S6 est une interface entre lentit de gestion de la mobilit LTE appele MME (Mobility Management Entity) et la base de donnes globale LTE appele HSS (Home Subscriber Server) S13 (LTE) : S13 est linterface entre lentit MME et lentit EIR (Equipment Identity Register) dans la LTE Gx (LTE) : Gx est linterface permettant lentit de commutation de paquet dans la LTE appele PDN-GW (Packet Data Network Gateway) dobtenir des rgles de taxation auprs de lentit PCRF (Policy and Charging Rules Function) et ainsi taxer lusager sur la base des flux de services et non pas sur le volume. Gy (LTE) : Gy est linterface de taxation online entre le PDN-GW et lOCS (Online Charging System) Gz (LTE) : Gz est linterface de taxation offline entre le PDN-GW et lOffline Charging System S9 (LTE) : S9 est linterface entre le PCRF du rseau visit et le PCRF du rseau nominal dans le cas o la taxation est prise en charge par le rseau visit. Rx (LTE) : Rx est linterface permettant lIMS de demander au rseau LTE (entit PCRF) de rserver des ressources laccs pour garantir la qualit de service des sessions IMS. Cx (IMS) : Cx est linterface entre les entit de contrle de session IMS appeles I-CSCF et S-CSCF (Interrogating et Serving Call State Control Function) et la base de donnes IMS appele HSS afin dauthentifier, dautoriser et de localiser lusager IMS. Dx (IMS) : Dx est linterface entre lI-CSCF ou le S-CSCF et lentit SLF (Subscription Locator Function) afin de localiser le HSS de lusager. Sh (IMS) : Sh est linterface entre lApplication Server (AS) SIP et le HSS afin que lAS obtienne les donnes de service permettant lexcution du service par lAS. Dh (IMS) : Dh est linterface entre lAS et le SLF afin de localiser le HSS de lusager.
23
Rf (IMS) : Rf est linterface entre les entits IMS et lentit CCF (Charge Collection Fuction) pour la taxation offline. Ro (IMS) : Ro est linterface entre les entits IMS et lentit Online Charging System (OCS).
Lapplication DIAMETER SIP spcifie dans le RFC 4740 dfinit une application DIAMETER qui peut tre utilise par un serveur SIP afin dauthentifier les usagers et les autoriser utiliser diffrentes ressources SIP. Lapplication DIAMETER SIP a une spcification proche de celle de linterface Cx en terme de fonctions, mais elle a t conue afin dtre suffisamment gnrique et ainsi tre utilise par dautres scnarii de dploiement SIP en dehors de lIMS. LApplication DIAMETER Credit Control spcifie dans le RFC 4006 est utilise pour la taxation temps rel (online charging) dun grand nombre de services. Elle est similaire linterface Ro DIAMETER dfinie dans lIMS.
exemple dagent de traduction est lentit IWF de larchitecture LTE qui traduit DIAMETER en MAP. A la figure 1, le chemin de la requte et de la rponse est 1, 4, 5 et 6 dans le cas du traitement uniquement par des agents relai/proxy. Le chamin devient 1, 2, 3, 4, 5, et 6 si lagent de redirection est aussi impliqu.
25
r(eserved) - Les bits r sont rservs pour usager futur. Ils sont positionns 0 et ignors par le rcepteur. command-code (4 octets) est utilis pour communiquer la commande associe au message. Chaque message DIAMETER doit contenir un code de commande afin que le rcepteur sache identifier laction raliser pour chaque message Application-ID (4 octets) identifie l application spcifique laquelle appartient le
message, tel que Mobile IP, Accounting, etc. Hop-by-hop identifier transporte un identificateur utilis afin dassocier la requte et la rponse sur ce saut (hop). Lmetteur de la rponse doit sassurer que la valeur de cet identificateur est la mme que celle prsente dans la requte correspondante. End-to-end identifier est utilis afin de dtecter des messages dupliqus. Lidentificateur dans la rponse doit tre identique celui de la requte correspondante. Lidentification doit tre unique pour au moins 4 minutes. Cet identificateur ainsi que lAVP Origin-Host (dcrit plus tard) sont utiliss ensemble afin de dtecter des duplications de message. Une requte duplique ne doit pas conduire lenvoi de deux rponses.
A titre dexemple, considrons linterface Cx entre lI-CSCF ou le S-CSCF et le HSS dans larchitecture IMS. Cette interface permet : Lautorisation denregistrement pour lusager (I-CSCF HSS) La demande des vecteurs dauthentification pour lusager (S-CSCF HSS) La notification dtat denregistrement (register / de-register) (S-CSCF HSS)
26
Lannulation denregistrement initie par le rseau (HSS S-CSCF) La demande de localisation de lusager (I-CSCF HSS) La mise jour du profil de lusager (HSS S-CSCF).
Tous les messages DIAMETER dfinis par cette interface ont leur champ Application-ID positionn la valeur 16777216. Les messages UAR et UAA (Command-Code 300) appartiennent la transaction dautorisation. Le message UAR mis par lentit I-CSCF est acquitt par une rponse UAA qui contient les informations denregistrement de lusager (si celui-ci est dj enregistr) ou la dcision sur la permission de traitement de lenregistrement (rejeter ou accepter). Le message MAR est utilis afin dobtenir les vecteurs dauthentification pour un usager donn auprs du HSS. La rponse MAA contient un ou plusieurs vecteurs dauthentification Gnrs pour lusager. Les messages MAR et MAA ont leur champ Command-Code Positionn la valeur 303. Le message SAR est mis par le S-CSCF lentit HSS afin de mettre jour dans le profil de lusager son S-CSCF courant. Lentit HSS rpond par le message SAA en indiquant le nouvel tat denregistrement de lusager ainsi que son profil de service. Les messages SAR et SAA ont pour Command-Code la valeur 301. Lannulation denregistrement de lusager par le rseau est ralise laide du message RTR mis par le HSS. Le S-CSCF lacquitte par une rponse RTA. Le Command-Code de RTR et RTA a pour valeur 304. Le message LIR est mis par lentit I-CSCF au HSS afin de localiser le S-CSCF courant de lusager. Lentit HSS rpond par un message LIA contenant le nom du S-CSCF ou une valeur dtat indiquant que lusager nest pas connu dans ce HSS ou nest pas actuellement enregistr. Les messages LIR et LIA ont pour Command-Code la valeur 302. Enfin, le message PPR est utilis par le HSS afin de mettre jour un profil dusager dans le S-CSCF. Ce message est acquitt par le S-CSCF par une rponse PPA. Le Command-Code de PPR et PPA est gal 305.
27
AVP est l'objet le plus important dans le protocole DIAMETER ; il est utilis pour fournir toutes les donnes. Certains AVPs sont ncessaires DIAMETER lui-mme pour fonctionner, alors que d'autres fournissent des donnes lies aux applications exploitant DIAMETER. Les AVPs contenant l'information spcifique une application peuvent tre arbitrairement ajouts aux messages DIAMETER, ds lors que les AVPs ncessaires sont prsents et que ceux qui doivent tre ajouts ne sont pas explicitement interdits par les rgles du protocole. Les AVPs transportent les informations dauthentification, dautorisation, de scurit, de comptabilit ainsi que des informations de configuration. Le format de len-tte de l AVP est donn la figure 4. Il contient les champs suivants : AVP-Code (4 octets): identifie l AVP de manire unique. Les 256 premiers numros sont rservs pour la compatibilit avec RADIUS. Les suivants sont utiliss par le protocole de base et ses extensions (numros devant tre allous par l IANA). Fanions (5 bits): V bit, connu comme Vendor-Specific bit, indique si le champ optionnel Vendor-ID est prsent dans len-tte de l AVP. Quand positionn, le code AVP appartient lespace dadressage des codes de ce constructeur. M bit: Le bit M signifie Mandatory bit. Il indique si le support de cet AVP est obligatoire. Ainsi si un AVP dont le bit M est gal 0 indique que cet AVP est informationnel, et par consquent qu il peut tre ignor. 28
P bit: Le bit P signifie Protected . Il indique la ncessit d un encryptage pour une scurit de bout en bout. Le protocole de base DIAMETER spcifie quels AVPs doivent tre protgs.En pratique ce bit est positionn la valeur 0. Les bits rrrrr sont rservs et positionns la valeur 0. Vendor-ID (4 octets) identifie le constructeur lorigine de cet AVP propritaire. La prsence de ce champ est prcise par le bit V du champ Fanion (Flags) Data : Longueur variable.
Parmi les AVPs dfinis par le protocole de base DIAMETER figurent : Origin-Host AVP: Cet attribut est ajout par le client qui gnre le message DIAMETER et ne peut pas tre modifier par les agents DIAMETER. Il doit tre prsent dans tous les messages DIAMETER. Origin-Realm AVP: Cet AVP contient le Realm (Nom de domaine) de lmetteur du message DIAMETER et doit tre prsent dans tous les messages DIAMETER. Les agents Relai ne doivent pas modifier cet AVP. Destination-Host AVP: Cet AVP qui peut tre prsent dans un message DIAMETER mis par un client est utilis afin de router un message au serveur identifi par cet AVP. Labsence de cet AVP dans un message DIAMETER aura pour consquence lenvoi du message nimporte quel serveur DIAMETER supportant lapplication et appartenant au domaine spcifi par DestinationRealm AVP. Destination-Realm AVP: Cet AVP contient le Realm auquel doit tre rout le message DIAMETER. Lorsquil est prsent, cet AVP permet de raliser des dcisions de routage.
29
5. Exigence de lIMS :
Un ensemble de besoins ont t dfini lors de la conception de lIMS : Connectivit IP : Le client doit disposer de la connectivit IP pour accder aux services IMS. Par ailleurs, le protocole IPv6 est requis. La raison fondamentale qui justifie l'usage d'Ipv6 est l'insuffisance d'adresse Ipv4 pour permettre chaque mobile (si lon considre lapplication de lIMS aux rseaux mobiles) de disposer d'une adresse IP avec un mode "accs permanent". Des solutions comme la traduction dadresse rseau (NAT, Network Address Translation) ne peuvent tre que temporaires. De nouveaux services comme laccs permanent, le tlchargement systmatique, lauto-configuration, les applications en temps rel (tlphonie), la scurit, etc. dpasseront bientt les possibilits de la technologie NAT. Avec IPv6, les champs d'adresse ont une longueur de 16 octets la diffrence des adresses Ipv4 sur 4 octets. LIPv6 fournit donc un espace dadressage largi permettant dattribuer une adresse unique chaque quipement Internet mobile (une ncessit pour les quipements toujours connects ), LIPv6 permet de configurer automatiquement ladresse IP de la machine hte sans avoir recours au protocole de configuration dynamique de la machine hte DHCP, Dynamic Host Configuration Protocol)], ce qui est intressant pour les quipements mobiles). LIPv6 gre la scurit de bout en bout. Le rseau mobile peut tre considr comme un rseau ferm dont linterfonctionnement avec le rseau antcdent IPv4 peut tre assur la priphrie du rseau (avec des routeurs passerelles excutant des empilages IP doubles avec des tunnels IPv6-IPv4, etc.). Indpendance par rapport laccs : LIMS a t conu pour tre indpendant de laccs afin que les services IMS puissent tre fournis partir de nimporte quel type daccs connect un rseau IP (e.g., GPRS, UMTS, WLAN, xDSL, cble, etc). Garantie Qos des services multimdia : Sur Internet, le type de QoS fourni est best effort. Cela ne sera 30
pas le cas avec lIMS. Les rseaux daccs et de transport de lIMS fournissent la QoS de bout-en-bout. A travers lIMS, le terminal ngocie ses capacits et exprime ses exigences de QoS durant la phase dtablissement de la session avec le protocole SIP. En parallle le terminal rserve les ressources ncessaires dans le rseau daccs en utilisant un protocole de rseau de ressources (e.g., RSVP, SM/GTP1, etc). Contrle de politique : Le contrle de politique IP signifie la capacit dautoriser et de contrler lusage du trafic au niveau mdia dans lIMS sur la base des paramtres de la signalisation SIP change lors de ltablissement de la session. Cela requiert des interactions entre le rseau daccs et lIMS laide du protocole COPS (Common Open Policy Service). Communications scurises : LIMS fournit des mcanismes de scurit similaires ceux mis en place dans les rseaux GSM et GPRS. Par exemple, lIMS sassure que lusager a t authentifi avant de pouvoir utiliser ses services. Taxation : LIMS fournit diffrents modles de taxation : off-line (postpay) et on-line (prpay). Support du roaming : Lusager peut accder ses services IMS depuis nimporte quel rseau IMS visit. La mobilit de l usager (nomadisme) et de ses services sont pris en compte. Inferfonctionnement avec dautre rseaux : LIMS ne sera pas dploy partout au mme moment. Il est donc ncessaire de prvoir des passerelles entre les rseaux RTC/GSM et le rseau IMS. Ces passerelles de mdia (media gateways) sont contrles par des softswitchs. LIMS identifie aussi un signaling gateway permettant de dlivrer la signalisation ISUP du RTC/GSM au softswitch sur SIGTRAN. Contrle de service : LIMS fournit tous les lments permettant de connatre les services souscrits par labonn et de les invoquer pour toute session sortante ou entrante. Dveloppement de service : LIMS fournit les APIs permettant le dveloppement de services multimdia. Parmi les APIs dj considres figurent la prsence, la messagerie instantane, le push to talk, la confrence et le chat .
6. Architecture IMS :
L introduction de l IMS (IP Multimedia Subsystem) dans les rseaux fixe et mobile reprsente un changement fondamental dans les rseaux de tlcommunication de type voix. Les nouvelles capacits des rseaux et des terminaux, le mariage entre l Internet et la voix, le contenu et la mobilit donnent naissance des nouveaux modles de rseaux et surtout offrent un formidable potentiel pour dvelopper de nouveaux services. Dans cet objectif, l IMS est conu pour offrir aux utilisateurs la possibilit d tablir des sessions multimdia en utilisant tout accs haut dbit et une commutation de paquets IP. LIMS fournit un rseau IP multi-service, multi-accs, scuris et fiable Multi-services : tout type de services dlivrs par un rseau cur supportant diffrents 31
niveaux de QoS pourront tre offerts lusager, Multi-accs: Tout rseau daccs large bande, fixe et mobile pourra sinterfacer lIMS LIMS nest pas un unique rseau, mais diffrents rseaux qui interoprent grce des accords de roaming IMS fixe-fixe, fixe-mobile, mobile-mobiles LIMS est un enabler pour les fournisseurs de service afin d offrir : Des services de communication non temps-reel, pseudo temps-rel et temps rel suivant une configuration client-server ou entre entits paires La mobilit des services / Mobilit de l usager (Nomadisme) Plusieurs sessions et services simultanment sur la mme connexion rseau
32
Control Function). Par ailleurs, ce mme MGC termine la signalisation ISUP du ct RTC/GSM qu'il convertit en signalisation SIP qui est dlivre au domaine IMS.
Le maintien des informations d'tat de la session afin de pouvoir invoquer les services souscrits par les usagers, afin de contrler la session pendant sa dure de vie, et pour la facturation de la session. La fonction de contrle est assure par le CSCF (Call Session Control Function) qui se dcompose en trois parties: P-CSCF (Proxy CSCF), I-CSCF (Interrogating CSCF) et S-CSCF (Serving CSCF). Sur le plan conceptuel, linfrastructure IMS est une suite de fonctions logiques dont il appartient aux quipementiers de les mettre en uvre par le biais dun ou plusieurs serveurs ddis. La fonction centrale est assure par le contrleur de sessions (ou CSCF). Elle se subdivise en trois sous-fonctions de base : serveur proxy (P-CSCF), fonction d'interrogation (I-CSCF) et fonction de service (S-CSCF). Proxy-CSCF (P-CSCF): Proxy-CSCF (P-CSCF): Le proxy-CSCF est le premier point de contact du terminal dans le rseau IMS visit. Il possde deux fonctions principales : il diffuse les messages de signalisation (registration et tablissement de session) de et vers le S-CSCF, et contrle les appels durgences locaux et lallocation des ressources durant ltablissement de la session. Le P-CSCF se comporte comme un Proxy server SIP lorsquil relaye les messages SIP vers le destinataire appropri, et comme User Agent SIP lorsquil termine lappel. Interrogating CSCF (I-CSCF): Cest le premier point de contact du terminal IMS dans le rseau nominal; Il interroge le HSS pour trouver la localisation du S-CSCF durant ltablissement de la communication, et il intgre les fonctions de pare-feu pour assurer les exigences de scurit et de confidentialit, il effectue aussi des oprations de facturations et de partage de charge entre les S-CSCF. 1.1 Policy Decision Function PDF Dans lobjectif dassurer la mise en uvre de politiques de provisionning, de routage ou de QoS, la release 5 des spcifications 3GPPP a prvu lutilisation dune plate forme de distribution de politiques conforme COPS. Dans ce contexte, la fonction PDF est une entit fonctionnelle dont le rle est dassurer la distribution des politiques de services locale (Service Based Local Policy : SBLP). A cet effet, la release 5 a intgr cette fonction dans le P-CSCF, tandis que pour la release 6 lentit PDF est prise en charge par un bloc fonctionnel indpendant du P-CSCF. 1.2 Passerelles et Contrle de passerelles : Media Gateway Control Function: Media Gateway Control Function: MGCF Le rseau IMS doit permettre ses utilisateurs dtablir des appels avec le RTCP, pour cela lIMS doit inter fonctionner avec le rseau RTCP qui fonctionne en mode TDM. De ce fait, des passerelles sont requises pour convertir des flux RTP en flux TDM. Cette conversion est assure par des passerelles : IMS-MGW (IP Mulimedia Subsystem Media Gateway) et T-SGW (Trunking Signaling Gateway Function).
34
Le contrle de ces passerelles est assur par la MGCF qui assure les fonctions suivantes : Conversion du protocole ISUP provenant du RTCP en protocole SIP. Contrle les parties de lappel qui maintient le contrle de connexion pour les canaux media. Communique et dialogue avec la CSCF. Slectionne le CSCF en fonction du routing number pour les appels entrants. IP Multimedia Subsystem Media Gateway: IMS-MGW : Cette passerelle est contrle par le MGCF via le protocole MEGACO/.H248 et assure deux fonctions: elle achemine sur le rseau IP le trafic de parole quil reoit du rseau tlphonique commutation de circuit, ce trafic est transport sur RTP/UDP/IP ; et supporte gnralement la fonction dannulation dcho. Trunking Signalling Gateway: T-SGW: La signalisation ISUP est change entre le commutateur tlphonique et le T-SGW et par suite change entre le T-SGW et le MGCF sur SIGTRAN. La T-SGW assure la conversion du transport pour lacheminement de la signalisation ISUP entre le RTCP et le MGCF. Breakout Gateway Control Function: BGCF Breakout Gateway Control Function: BGCF :: La fonction de contrle de passerelles de drivation (BGCF) choisit le rseau de destination pour lequel le rseau PSTN doit se connecter; choisit MGCF local ou la BGCF homologue et fournit la scurit par l'autorisation des rseaux homologues. 1.3 Media Ressource Function: MRF La fonction de ressources multimdia MRF est responsable de ltablissement des confrences multimdias et du contrle de support lors des sessions multiparties. Elle se dcompose en deux parties : MRFC et MRFP. Media Resource Function Controller: MRFC: La fonction MRFC (MRF Controller) assure le traitement de la signalisation manant du P-SCSF par le biais dune interface de communication de type SIP. Media Resource Function Processor: MRFP Media Resource Function Processor: MRFP Cest au niveau de la fonction MRFP que sopre le traitement des flux RTP. En effet, cette fonction dite MRF Processor permet le traitement de mdia travers le transport RTP/UDP/IP.
35
Figure 11 : Architecture de service IMS (AS, Application Server) excute des services (e.g. Push To Talk, Prsence, Prepaid, Instant messaging, etc.) et peut influencer le droulement de la session la demande du service (voir annexes). Le serveur dapplication correspond lentit SCF (Service Control Function) du Rseau Intelligent. (MRF Multimdia Ressource Function) met en oeuvre lentit fonctionnelle. Il tablit des confrences multimdias, joue des annonces vocales ou multimdia et collecte des informations utilisateur. Il sagit de lvolution de lentit SRF (Specialized Resource Function) du Rseau Intelligent dans le monde multimdia. 2.1 Le serveur dapplication SIP_AS : Le serveur d'application de SIP (AS) est le serveur indigne d'application dans l'IMS. De nouveaux services exclusivement dvelopps pour l'IMS sont susceptibles d'tre excuts par des serveurs d'application SIP. La figure 4 montre la relation entre les serveurs d'application de SIP et le reste du rseau. Quand un serveur (AS) est situ dans le rseau nominal, il peut sur option mettre en application une interface daccs au HSS appele Sh, le protocole utilis y est utilis est le Diameter .
2.2 Le serveur dapplication OSA-SCS : OSA-SCS (Open Service Access Service Capability Server) fournit la fonctionnalit de passage pour excuter des services d'OSA (accs ouvert des services) dans l'IMS. La figure 5 montre l'OSA-SCS dans le contexte de l'IMS. L'OSA-SCS fournit une interface, externe l'IMS, vers le framework du serveur d'application d'OSA. L'OSA-SCS AS fournit galement l'interface ISC vers le S-CSCF bas sur le SIP et peut employer l'interface Sh facultative vers le HSS .
Figure 13 : le serveur OSA-SCS 2.3 Le serveur dapplication IMS-SSF : Le troisime type de serveurs d'application est la fonction de commutation de service multimdia IP (IMS-SSF)*3+. Ce serveur d'application fournit un passage aux rseaux de service qui mettent en application les services CAMEL *4+, qui sont largement dploys dans des rseaux de GSM. L'IMS-SSF agit en tant quinterface entre les services de SIP et de CAMEL, permettant ainsi des services CAMEL d'tre adopts par l'IMS.
Figure 14 : le serveur IM-SSF La figure montre le fonctionnement de l'IMS-SSF dans un contexte IMS. LIMS-SSF connecte le S-CSCF par l'intermdiaire de l'interface ISC, en utilisant le SIP comme protocole dchange. L'IMS-SSF connecte galement le HSS avec une interface nomm Si. Le protocole relatif 37
l'interface Si est MAP (Mobile Application Part)*5+, un protocole non IMS existant utilis dans des rseaux de GSM. En dehors de l'IMS l'IMS-SSF connecte le gsmSCF (GSM Service Control Function), qui fait partie de l'environnement de service de CAMEL (CSE). Le protocole relatif cette interface est CAP (CAMEL Application Part) qui est aussi un protocole non IMS.
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. SLF : Subscriber Location Function correspondant dans le cas ou le rseau contient plusieurs HSS.
1. Enregistrement dun client mobile depuis un accs 3G ou 4G avec une carte USIM intgrant un module ISIM (IMS SIM Module) : La rfrence une souscription IMS est dfinie par un compte usager. La souscription IMS peut tre utilise depuis n importe quel quipement appel UE (User Equipment) , pour des communications fixes ou mobiles. Un usager doit avoir au moins une identit prive et au moins une identit publique. L identit prive IMS (IMSI Private User Identity, IMPI) est une donne usager permanente dans le HSS (Home Subscriber Server). Le format de l IMPI est de type username@realm de Network Address Identifier (NAI) tel que spcifi dans le RFC IETF 4282. L IMSI peut tre inclus dans la partie username si souhait par l oprateur; le format de la partie realm tant alors : ims.mnc[MNC].mcc[MCC].3gppnetwork.org Si l IMSI suivant est utilis, 2080123456555 o MCC = 208, MNC = 01, et MSIN = 43567656, alors IMPI = 2080123456555@ims.mnc01.mcc208.3gppnetwork.org
38
autre IMPI possible: JohnCook_private@orange.fr La Private User Identity n est pas une URI SIP. La rfrence une souscription IMS est dfinie par un compte usager. La souscription IMS peut tre utilise depuis n importe quel quipement appel UE (User Equipment) , pour des communications fixes ou mobiles. Un usager doit avoir au moins une identit prive et au moins une identit publique. L identit prive IMS (IMSI Private User Identity, IMPI) est une donne usager permanente dans le HSS (Home Subscriber Server). Le format de l IMPI est de type username@realm de Network Address Identifier (NAI) tel que spcifi dans le RFC IETF 4282. L IMSI peut tre inclus dans la partie username si souhait par l oprateur; le format de la partie realm tant alors : ims.mnc[MNC].mcc[MCC].3gppnetwork.org Si l IMSI suivant est utilis, 2080123456555 o MCC = 208, MNC = 01, et MSIN =43567656, alors IMPI = 2080123456555@ims.mnc01.mcc208.3gppnetwork.org autre IMPI possible: JohnCook_private@orange.fr La Private User Identity n est pas une URI SIP.
2. Enregistrement dun client mobile depuis un accs 3G ou 4G avec une carte USIM sans module ISIM (IMS SIM Module): Un usager mobile peut senregistrer lIMS avec sa carte USIM sans que celle-ci possde de module ISIM. Une adresse prive temporaire et une adresse publique temporaire sont alors gnres pour lenregistrement IMS et ont le format : username@realm. L IMSI doit tre inclus dans la partie username; le format de la partie realm est : ims.mnc[MNC].mcc[MCC].3gppnetwork.org Ex : IMSI = 2080143567656, o MCC = 208, MNC = 01, et MSIN = 43567656. L identit prive est alors : 2080143567656@ims.mnc01.mcc208.3gppnetwork.org L identit publique temporaire est identique une adresse prive temporaire mais prfixe par sip: car il s agit d une URI SIP. Dans notre exemple sa valeur est : sip : 2080143567656@ims.mnc01.mcc208.3gppnetwork.org Lorsqu un terminal IMS disposant d une USIM sans ISIM doit construire le nom de domaine de son rseau nominal qui est inclus dans le Request-URI de la requte SIP REGISTER, le terminal supprime la partie user de l identit publique temporaire. L URI du nom de domaine du rseau nominal est : sip: ims.mnc01.mcc208.3gppnetwork.org Dans ce cas particulier, lorsque l usager s enregistre, l authentification sera base sur l AKA 3G et non pas l AKA IMS. L authentification IMS pour les clients mobiles est base sur une cl partage K qui est
39
uniquement prsente dans le HSS et dans l application ISIM de la carte USIM sur l UE. Comme le HSS ne communique jamais directement avec l UE, le S-CSCF ralise les procdures d authentification. Le vecteur d authentification (AV, Authentication Vector) est tlcharg par le S-CSCF partir du HSS pendant l enregistrement. La procdure dauthentification est similaire celle mise en uvre dans les rseaux mobiles 3G sur la base du protocole AKA (Authentication and Key Agreement). La partie authentication de AKA permet de vrifier l identit de l usager alors que la partie Key Agreement permet de gnrer des cls qui sont ensuite utilises pour le chiffrement du trafic de signalisation SIP entre lUE et le P-CSCF et pour la protection de l intgrit de la signalisation SIP toujours entre lUE et le P-CSCF. Dans le cas dun usager ne disposant pas de module ISIM, lauthentification sappuiera sur lAKA 3G et la cl K prsents sur lUSIM. Si lauthentification russit pendant la phase denregistrement lusager obtient du rseau son identit ou ses identits publiques IMS (prsents dans le header P-Associated-URI de la rponse SIP 200 OK) . Une fois la procdure d enregistrement finalise, le terminal IMS dispose donc d un ensemble d identits publiques d usager pour par exemple tablir des sessions IMS.
3. Enregistrement dun client fixe sans USIM et ISIM : Dans ce cas prcis, le nom dutilisateur et le mot de passe utiliss par le modem (e.g., modem ADSL) pour lauthentification sur laccs large bande fixe peuvent tre rutiliss pour lauthentificaiton lIMS. L authentification d accs HTTP avec la mthode Digest est la forme la plus simple d authentification dans le protocole SIP et concerne ce scnario. Le mcanisme fait partie de la spcification SIP (RFC 3261) et doit tre implant obligatoirement dans les clients et serveurs SIP. Il s agit d une adaptation du mme mcanisme utilis pour l authentification au service Web. Le mcanisme requiert un nom d utilisateur et un mot de passe. Le nom d utilisateur est considr comme la Private User Identity. L authentification est toujours mutuelle. Le transport est assur par TLS (Transport Layer Security). L authentification d accs HTTP avec la mthode Digest est donc utilise pour accder l IMS travers des rseaux d accs non dfinis par 3GPP. Nous avons montr que si l accs est 3GPP (e.g., 3G, 3G+, LTE/4G), l usager dispose d une USIM avec ou sans module ISIM. Alors le mcanisme d authentification est l authentification d accs HTTP avec la mthode Digest en utilisant AKA appel simplement HTTP Digest AKA.
40
4. Le HSS retourne les informations d autorisation de l'usager et les capacits obligatoires et optionnelles du S-CSCF slectionner (Rponse UAA : User Authorization Answer). ces informations serviront d'entres sa fonction de slection d'un S-CSCF. 5. L I-CSCF vrifie si l usager est autoris s'enregistrer partir du rseau visit et dans le cas positif, lI-CSCF relaye la mthode SIP REGISTER au S-CSCF identifi. L'entit S- CSCF a plus de fonctionnalits que les P-CSCF et I-CSCF. L'oprateur peut disposer de plusieurs S-CSCFs avec des capacit diffrentes et slectionner celui appropri pour rendre le service demand. 6. L entit S-CSCF demande des informations d authentification de l usager au HSS (MAR : Multimedia authentication request) 7. Le HSS retourne les informations dauthentification par une rponse MAA (Multimedia Authentication Answer) au S-CSCF. 8.9. 10. Lentit S-CSCF retourne lusager une rponse ngative denregistrement contenant dune part une valeur random (RAND) utiliser par son module ISIM pour calculer un rsultat dauthentification usager et dautre part un rsultat dauthentification rseau (AUTN) permet au rseau IMS de sauthentifier auprs de lusager. Notons que lauthentification IMS est mutuelle. 11. L usager renvoie une demande d enregistrement au P-CSCF. Cette deuxime demande denregistrement contient un rsultat dauthentification usager (RES). 12. Le P-CSCF route le message REGISTER un S-CSCF du domaine nominal de l usager. 13. et 14. Idem 3 et 4. 15. Le message REGISTER est rout de l I-CSCF au S-CSCF. 16. L'entit S-CSCF aprs avoir vrifi les informations d authentification de l usager, met une requte SAR (Server Assignment Request) au HSS afin que ce dernier mette jour le profil de l'usager avec le nom du S-SCSF qui le sert. 17. Le HSS retourne une rponse SAA (Server Assignment Answer) l'entit S-CSCF, contenant le profil de l'usager. Ce profil consiste en les informations de souscription par l'usager des services. Le S-CSCF doit par ailleurs stocker le nom / l'adresse du PCSCF courant de l'usager afin de lui dlivrer directement des demandes d'tablissement de session entrantes concernant cet usager. 18. Le S-CSCF invoque des services ventuels tels que le service de Prsence. 19., 20. et 21. Une rponse 200 OK est retourne par le S-CSCF l'entit I-CSCF qui le relaye au P-CSCF qui le dlivre UE. L IMS est bas sur plusieurs relations de scurit. Deux d entre elles influencent la signalisation SIP : authentification entre l usager et le rseau , et L association de
42
scurit (SA, Security Association) entre l UE et le P-CSCF . Les procdures d authentification et d tablissement de SA dans l IMS sont directement lies aux procdures d enregistrement SIP.
chiffre. IK La cl d intgrit. Cette cl sert la protection de lintgrit de la signalisation SIP change entre lUE et le P-CSCF. Au del du P-CSCF, lintgrit de la signalisation SIP nest pas protge.
Pour obtenir les vecteurs dauthentification, le S-CSCF met la requte DIAMETER Multimedia-Auth Request (MAR) au HSS. Cette requte contient : < Diameter Header: 303, REQ, PXY, 16777216 > L AVP Session-Id (263), positionn scscf1.orange.fr; 1123347722;122 LAVP Vendor-Specific-Application-Id AVP (260) indiquant le Vendor-ID (i.e.,10415), et de manire optionnelle Authentication-Application-Id (16777216) et AccountingApplication-Id. LAVP Auth-Session-State AVP (277) indiquant quaucun tat nest maintenu (i.e., No_State_Maintained). L AVP Public-Identity (600), indiquant la public user identity qui est enregistre, i.e., l URI contenue dans le header To de la requte REGISTER: sip:JohnCook@orange.fr; L AVP User-Name AVP (1) positionn la valeur de la private identity de John Cook, i.e., JohnCook_private@orange.fr ;
44
L AVP Server-Name (602) positionn la valeur de l URI SIP du S-CSCF ralisant la commande MAR, i.e. sip:scscf1.orange.fr; L AVP SIP-Number-Auth-Items (607) positionn la valeur 5, indiquant que le SCSCF souhaite tlcharger 5 vecteurs d authentification conscutifs pour cet usager, L AVP SIP-Auth-Data-Item (612), incluant le schma d authentification SIP SIPAuthenticationScheme L AVP Origin-Host (264) positionn l adresse du S-CSCF, i.e. scscf1.orange.fr; L AVP Origin-Realm (296) positionn au nom de domaine du rseau de l oprateur dans lequel est prsent le S-CSCF, i.e., orange.fr , L AVP Destination-Realm (283) correspondant au nom de domaine du HSS, i.e. orange.fr, L AVP Destination-Host (293) positionn l adresse du HSS, i.e., hss1@orange.fr, qui sera pr-configure au niveau du S-CSCF si le rseau nominal ne possde qu un seul HSS. Aprs avoir reu la commande MAR, le HSS vrifie d abord si le S-CSCF est autoris tlcharger des donnes d authentification relatives Mary Taylor. Comme le S-CSCF est autoris, le HSS retourne une rponse DIAMETER Multimedia-Auth Answer (MAA) au SCSCF, contenant : < Diameter Header: 303, PXY, 16777216 > L AVP Session-Id (263), positionn scscf1.orange.fr; 1123347722;122 LAVP Vendor-Specific-Application-Id AVP (260) indiquant le Vendor-ID (i.e.,10415), et de manire optionnelle Authentication-Application-Id (16777216) et AccountingApplication-Id. LAVP Auth-Session-State AVP (277) indiquant quaucun tat nest maintenu (i.e., No_State_Maintained). L AVP Origin-Host (264) positionn l adresse du HSS, i.e., hss1.orange.fr; L AVP Origin-Realm (296) positionn au nom de domaine du rseau de l oprateur dans lequel est prsent le HSS, i.e., orange.fr , L AVP Public-Identity (608) positionn la mme valeur que celle reue dans la commande MAR, i.e., public user identity, sip:JohnCook@orange.fr L AVP User-Name (1) positionn l identit prive de John Cook : JohnCook_private@orange.fr L AVP SIP-Number-Auth-Items (607) positionn la valeur 5, indiquant que le HSS a retourn 5 vecteurs d authentification S-CSCF; L AVP SIP-Auth-Data-Item (612), incluant 5 fois les AVPs suivants (un par vecteur d authentification) : L AVP SIP-Item-Number (613) positionn la valeur 1 pour le premier vecteur
45
d authentification (et incrmente de 1 pour les 4 autres vecteurs d authentification), cette squence indiquant l ordre dans lequel utiliser les vecteurs L AVP SIP-Authentication-Scheme AVP (608) positionn la valeur DigestAKAv1-MD5 L AVP SIP-Authenticate (609) incluant : La valeur random (RAND); Le jeton d authentification rseau (AUTN); L AVP SIP-Authorization (610) incluant le rsultat attendu (XRES); L AVP Confidentiality-Key (625) incluant la cl de confidentialit (CK); L AVP Integrity-Key (626) incluant la cl d intgrit (IK); L AVP Result-Code (268) positionn DIAMETER SUCCESS (2001), indiquant que la requte a t excute avec succs. Sur la base des donnes dans le quintupl d authentification, le S-CSCF retourne une rponse 401 Unauthorized contenant le header WWW-Authenticate et renseigne ce header de la manire suivant comme montr la figure ci-dessus : dans le champs nonce , sont prsents les paramtres RAND et AUTN qui taient prsents dans l AVP SIP-Authenticate de la rponse DIAMETER MAA. Ces deux valeurs ont une longueur de 32 bits et 64 bits respectivement. dans le champ algorithm la valeur prsente est AKAv1-MD5 comme prsent dans l AVP SIPAuthentication-Scheme dans la rponse MAA et qui identifie le mcanisme 3GPP AKA; dans les champs ik et ck sont prsents les cls d intgrit et de chiffrement respectivement comme prsentes dans les AVPs Confidentiality-Key et Integrity-Key de la rponse MAA. Ces deux champs ne font pas partie de la dfinition l origine du header WWWAuthenticate header, comme dfini dans le RFC 3261. Aprs avoir reu la rponse SIP 401 (Unauthorized), le P-CSCF doit supprimer en les mmorisant les champs ik et ck du header WWW-Authenticate header, avant de relayer cette rponse l UE.
46
A partir du paramtre AUTN reu, l application ISIM sur l UE de John Cook dcouvre qu il s agit bien du rseau nominal de John Cook qui a envoy la rponse 401 (Unauthorized). Il peut driver de l AUTN que le SQN (sequence number) est valide. Les paramtres RAND et AUTN reus ainsi que la cl K permettent l ISIM de gnrer RES, CK et IK et les passe l UE. L UE renvoie une seconde requte SIP REGISTER qui inclut un header Authorization incluant entre autres les champs suivants : le champ username qui inclut l identit prive de John Cook, le champ nonce qui est retourn avec la mme valeur que celle reue dans le header WWW-Authenticate de la rponse SIP 401 (Unauthorized); le champ response qui inclut le challenge d authentification RES driv partir de K et de RAND par l application ISIM. L ISIM calcule aussi les cls CK et IK qui sont par ailleurs connues par le P-CSCF (ce dernier les a reu du S-CSCF dans le message 9). Sur la base de ces cl et d autres informations, l UE et le P-CSCF tablissent des SAs (Secure Associations) IPSec, utilises par l UE pour envoyer la seconde requte REGISTER. REGISTER sip:orange.fr SIP/2.0 Authorization: Digest username= "JohnCook_private@orange.fr", realm= "orange.fr", nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAv1-MD5, uri="sip:orange.fr", response="6629fae49393a05397450978507c4ef1"
47
Lorsque le S-CSCF reoit le message REGISTER (Message 15), il compare le champ response avec le paramtre XRES deu vecteur dauthentification correspondant. Si les valeurs de ces deux informations sont gales, alors lauthentification de lUE a russi. Le but de la formation IMS Avanc dEFORT est de prsenter en dtail les procdures denregistrement, dtablissement de session, dinvocation de services et de taxation IMS. Les protocoles SIP et DIAMETER impliqus dans ces procdures sont dcrits dans le contexte IMS et leur usage prsent laide de traces.
Si on prend la mthode INVITE du protocole SIP et on analyse le format du message entre les diffrents serveurs jusqu' le destinataire.
48
49
50
51
Points Faibles de lIMS : Le nombre de profils d'usagers et d'applications dfinir laisse sceptiques les dcideurs. La voix sera-t-elle encore longtemps le service majeur dans les dix ans venir ? Le passage en IPv6 reprsente un cot important pour un bnfice qui ne semble pas vident. Il faut parvenir crer des applications qui ne ncessitent pas des manipulations complexes sur les claviers des terminaux. Il faut s'assurer de la scurit des interactions entre quipements de signalisation et de l'inviolabilit de celles-ci. L'IMS, rsultant de la conjonction d'un grand nombre d'lments intgrer, suscite des inquitudes quant aux cots et la fiabilit globale. Il faudrait disposer de plus grandes certitudes sur la croissance du trafic tlphonique vocal. La centralisation des fonctions de transit sur une dizaine ou une vingtaine de commutateurs par logiciel en IP fragiliserait le rseau. L'adaptation de l'IMS l'accs fixe est coteuse. La proportion d'abonns qui est concerne par les nouvelles applications technologiques ne peut pas tre value avec prcision. L'abonn est-il prt abandonner le forfait pour la tarification au service utilis ?
52
CONCLUSION
SIP a t prfr H.323, jug plus lourd et plus cher. La fin des messages indsirables et une plus grande scurit sont attendues par tous les utilisateurs professionnels et rsidentiels. L'IMS suppose un bon interfonctionnement de plusieurs familles de protocoles de signalisation d'origine diverse. Comment rpondront les utilisateurs ce nouveau dploiement de technologies ? Il a fallu neuf ans pour que le public fasse un usage fabuleux des SMS ! L'architecture IMS provoquera-t-elle la chute et la fin de l'Internet ?
Une suite de paradoxes peut tre releve en conclusion ce bref rsum. L'IMS vient du monde des mobiles, mais les rseaux fixes ont besoin de l'IMS.
L'IMS pourrait permettre de mieux grer les rseaux mobiles, compte tenu de la pnurie en ressources en dbits dans les cellules (le dbit disponible y est divis par le nombre d'utilisateurs actifs). On ne connat pas en effet les possibilits relles des techniques annonces (HSDPA et HSUPA). L'Europe, la diffrence des Etats-Unis, dispose en radio de techniques "circuits" et de techniques "paquets".
La ncessit du renouvellement des parcs de commutateurs dans les rseaux pose un problme d'investissements et de gestion de la scurit aux exploitants. L'IMS constituet-il la rponse leurs besoins ? L'IMS arrivera-t-il temps ?
53