Brevet FR2968158A1 — publié le 20120601

Arrière-plan de l'invention L'invention se situe dans le domaine des réseaux de télécommunication de type IMS (IP Multimedia Subsvstem)tel que défini pærke3GPp(Thind Genenation Partnæship L'un des objectifs de /%M5 est de permettre à un utilisateur d'accéder à différents services quel que soit son type de connec±iv/Lé IP. Les réseaux IMS, initialement conçus pour les réseaux mobiles, tendent à se développer sur des réseaux d'accès fixes de b/pa ADSL (AsymmeLric Digital Subscriber 10 Line), ou F1-TH (FiberTo The Home), ou sur des réseaux cabrés notamment. Les architectures I[4S pour !es réseaux fixes ont en particulier été déployées pour !a commercialisation d'offres dites « Mu!Up!uy» permettant à un utilisateur d'accéder à différents services du réseau IMS, et notamment à des services d'accès au réseau Inb8rnet, de voix sur IP (VoIP) et de télévision sur internet (IPTV), via une 15 passerelle domestique. Afin de diversifier leur offre, !es opérateurs de télécommunication proposent des terminaux complémentaires aux téléphones fixes, ces terminaux complémentaires étant équipés d'un logiciel de voix surIP (VoIP) utilisant le même identifiant public IMPU que celui de !a passerelle domestique et un identifiant privé IMPI pouvant être ou non le 20 même que celui de la passerelle domestique. Pour s'enregistrer en coeur de réseau IMS, un terminal (appelé User Agent dans !edocument RFC3361)envoie, à unserveur 5'CSCF(Sen/ing Cali StateConton/ Funciiun) responsable des enregistrements, une requête d'enregistrement comportant notamment !esdeux identifiants lMPUæLIMPIprécités. 25 En complément de l'enregistrement 5IP nécessaire pour établir une session multimédia, certains services IMS nécessitent que les terminaux souscrivent à certains services, par exemple à un service de présence ou à un service de notification de dépôt demessages appelé « Message VVa!tingIndicato/» (MVVI). La souscription par le terminal à chacun de ces services utilise le message SIP 30 (SUBSCRIBE). De façon connue, ce message comporte des identifiantsd'évènennents (Event asseeiés aux service-7 35 7 Les terminaux qui veulent souscrire à au moins un service /aooelésGubscrber dans ka document RF[3265> doivent donc envoyer un message SJP SUBSCRI8E à destination d'une entité, généralement un serveur d'application, hébergeant le service, ce serveur d'application AS étant appelé Notifier dans le document RFC3265. A btna d'exemple de serveur d'application, un peut par exemple citer les serveurs d'application de notification de dépôt de messages Message Waiting Indicator et !csserveurs d'application de présence. La figure 1 décrit une architecture mettant en ceuvre un mécanisme de souscr/ptionà un service dans un réseau IMS. La passerelle domestique HGVV offre un sen//ce de voix sur IP à partir d'un téléphone domestique TEL, constitué dans cet exemple par un téléphone conforme à la norme DEL 1. La passerelle domestique HGVV reçoit dans son fichier de configuration VoIP ses paramètres d'abonnement aux sen/icesVnIP et en particulier son entité publique IMPU. La passerelle domestique HGVV se connecte via un réseau d'accès RA, par exemple de type ADSL, au travers d'un premier équipement réseau de type DSLAM, celui-ci étant lui-même connecté à un réseau de collecte RC, par exemple de type ATM ou Giga Etharnet ce qui lui permet d'atteindre un réseau opérateur RO à travers un premier routeur R1. Le réseau opérateur RO, de type back bone IP permet d'atteindre, au travers undeuxième voubcurR2!cpoint d'entrée duréseau IMS. De façon connue, !æ point d'entrée d'un réseau IMS est une entité dite « de bordure », référencée E8 sur la figure 1, celle-ci pouvant être constituée par : - un équipennenLSBC /Session Bondcr[ontvo!!eh ; -unserveur P'[SCF; - un équipement remplissant à !a fois !es fonctions d'un équipement SBC et celles d'un serveur P-CSCF. Dans !a suite de ce document, !a terminologie ^enbté de bordure » désignera l'un quelconque de ces trois équipements. Le réseau lMS comporte notamment !zsenti~és fomc±/onneUesP-[SCF, I-CSCF, S-CSCF,SLF,,r4 DNS ENUMconnues del'homme dumétier. ' Dan ! - `!e lit''-rit ~chL id le ! -eau IMS esL !nteoonne[té à un serveur d']pp/itaUonASoJoniunsen, ~ed~/ ' -Jr ~U/ Danpexcmo!udu b [ium~ ]. 1cox~an~inaox. asavo/ - I! ' . !P) 5P! c! Sp2 sont co,ruc!c~ j 1 i ~ n~ussog~~. HGVV par une liaison sans h! NDFI et utilisent la même identité publique IMPU que la passerelle HGW. Chacun des terminaux SIP (passerelle HGN, terminaux de voix sur IP SPI, 5P2\ demande une souscription aux services fournis par !e serveur d'application AS, ce qui nécessite de gérer les contextes de souscription associés auxservices, au sein : - dechaqueùermina/ ; - des équipements intermédiaires (entité de bordure EBet/ou serveurS-05CF) ; et - du serveur d'application AS. 10 De façon connue un message EJPSU8S[RIBE émis par un terminal comporte des informations provenant du fichier de configuration VoIP transmis au terminal ; et notamment : -!'ident/té publique IMPU; -!enonndedomaine duréseau IM5; 15 - !1URI (« Uni(orm Resource Identifier ») permettant !'accès au service fourni par le serveur d'application AS ; - des informations dynamiques obtenues par !e réseau, dont l'adresse IP, le numéro de port, !e protocole de transport UDP ou TCPdu point d'entrée EB du réseau IMS; 20 -des informations statiques fournies par le matériel du terminal ; et - des informations dynamiques gérées localement par le terminal. Le premier message de souscription SUBSCRI8Eenvoyé par un hernninal pour souscrire à un service est appelé message de souscription initial. [e message de souscription est routé vers !e coeur de réseau IMS soit 25 directement au niveau du P-[5[F, soit au travers de l'entité de bordure E8 puis, si toutes !es conditions son[ remplies, ce message est routé par !e S+C5[F vers !e serveur d'application concerné. De façon connue !e serveur d'application concerné répond au message de souscription par un message de type 200 OK contenant la valeur de la durée de 30 souscription (paramètres Expires), Le serveur d'application émet ensuite immédiatement vers le terminal un message de not/ficnL/on NCTITY fournissant l'état cies information- liààà aux services (E\ )t 7ockagc) ; OB 0 agc NOT3FY 28t termina. doiL /uw ~'Lx,i/~~ n'arrive à cà~~/uü~.1. [2 35 4 renouvellement est réalisé selon le même principe que la souscription initiale, à savoir par !'enchainemnt des messages SUBSCRIBE, 200 OK, NODFY, 200 OK. On parle alors de souscription subséquente. Les messages subséquents conservent les mêmes identifiants de dialogue SIP ~ que le message de souscription initiale et incrémentent un champ C5eqde 1 à chaque nouvel envoi. Lorsqu'un évènement doit être notifié au terminal, le serveur d'application AS émet, de sa propre initiative, un message SIP NOTIFY contenant !'évènement à destination du terminal, ce message SIPétant acquitté par le terminal par l'envoi d'un 10 message 200 0K. De façon connue, pour dé-souscrire à un service, le terminal peut envoyer au serveur d'application AS un message SIP 5UBSCRIBE contenant !e champ Expires fixé à O, celui-ci répondant à ce message par l'envoi d'un message 200 OK, puis envoie au terminal un message de notification NOTIFY contenant la fin d'abonnement au service, ce 15 message de notification étant lui aussi acquitté par le terminal parl'envoi d'un message 200 0K. De même, à tout moment, un serveur d'application AG peut notifier au terminal qu'un service n'est plus disponible en envoyant un message de notification SIP NOTIFY contenant la fin de l'abonnement au service, le terminal acquittant ce message par l'envoi 20 d'un message 200 0K. La durée de l'Expires, fixant la durée de souscription aux services est variable. Elle varie notamment en fonction du service et de la charge d'équipement. Atitre d'exemp/e, pour /e service MWI de notification de dépôt de message au sein d'une messagerie vocale, !a durée de /'Expires peut être fixée à 24 heures et le 25 berminal re-souscrit environ toutes !es 23 heures 50 minutes. Lorsque !a passerelle domestique HGYV souscrit à un service, un contexte de dialogue SUBS[Rl8E est créé dans chacun des équipements décrits en référence à la figure 1 (passerelle HGVV, entité de bordure E8, serveur S-CSCF et serveur d'application AS). 30 De façon similaire, lorsqu'un terminal SPI, SPZ souscrit à un service, un conhexbe de dialogue SUBSCRIBE est créé dans chacun des équipements décrits en réfLu~nce à !æ figure 1 (terminal concerné, entité de bordure EB, serveur S-CSCF et ermina~ ne detsousc//L nus n/ 35 les c 5 Mais, si pour une raison ou pour une autre, le terminal SPI, 5P Z ou la passerelle HGVV se réenregistre en coeur de réseau 6JP\ après un arrêt sans désouscriphon au service précédent, il vesouschtau service mais en utilisant un nouveau dialogue SIPSU8S[RIBE. 5 Par conséquent, !es différents équipements traversés (entité de bordure, serveur S-CSCF et serveur d'application AS) vont consommer de nouvelles ressources mémoire pour stocker ce nouveau dialogue. En particulier, certaines passerelles domestiques, mettent en oeuvre des mécanismes de surveillance pour redémarrer /o pile de voix sur IP SIP sous certaines 10 conditions, par exemple /ors d'une perte de synchronisation ADSL ou en absence de réponse d'un équipement VnIPsans prendre le temps de désouscrire au service ni de se désenregistrerau niveau du coeur de réseau IMS. Par conséquent, !e mécanisme de souscription présenté ci-dessus pose des problèmes de dinnensionnennentde !a mémoire au niveau des noeuds traversés dans !e 15 réseau pour !a mémorisation des dialogues 5IP, ce problème étant d'autant plus critique que la durée Expires de souscription au service est importante. Objet et résumé de l'invention 20 D'une façon générale, l'invention vise un procédé de gestion des souscriptions dans un réseau IMS qui ne présente pas les inconvénients de ceux de l'état de la technique. Plus précisément, et selon un premier aspect, l'invention concerne un procédé de gestion de souscription à un service dans un réseau IMS, ces procédés comportant : 25 -une étape de création, pour une identité publique donnée, d'au moins deux files de souscription, chacune de ces files étant associée à une taille et à une politique de souscription ; - une étape de réception d'un message de souscription à ce service émis par un terminal ayant cette identité publique ; et 30 'une étape d'attribution d'une de ces files de souscription au herminel pour ce service sur la base d'un paramètre discriminant compris dans un champ de ce message de souscription. [~nà/abvc , l'invention concerne gcst'on desoysc/i!}hon à 6 -des moyens de création, pour une identité publique donnée, d'au moins deux files de souscription, chacune étant associée à une taille et à une politique de souscription ; - desmoyensde réception d'un message de souscription à ce service émis par 5 un tenninal ayant cette identité publique ; et - des moyens d'attribution d'une de ces files de souscription au terminal pour ce service sur la base d'un paramètre discriminant compris dans un champ de ce message de souscription. Ainsi, d'une façon générale, l'invention propose de gérer la souscription à 10 différents services SIP en utilisant plusieurs files de souscription. Pour être efficace, /e procédé selon l'invention doit être mis en oeuvre dans chacune des entités traversées et gérant les dialogues de souscription (entité de bordure EB, serveur S-[SCFet serveur d'application AS). Le fait de gérer plusieurs files de souscription permet de définir des terminaux 15 dits "prioritaires" (tels que /a passerelle domestique HGVV qui offre /e service principal de téléphonie) et de s'affranchir des aléas dus à des terminaux dits "secondaires" (tels que les terminaux de voix sur IPSPI et SP2). Par ailleurs, et de façon très avantageuse, !e fuit de gérer plusieurs files de souscription permet d'optimiser les ressources mémoires des différents équipements 20 traversés en appliquant des politiques adaptées à chaque file. Dans un mode particulier de réalisation de l'invention, le paramètre discriminant choisi pour sélectionner la file de souscription est choisi parmi : - un identifiant du service auquel le terminal souhaite souscrire ; -un jeton d'identification ; 25 - un type du terminal ; - un identifiant du réseau auquel appartient ce terminal ; - !e paramètre qdéfini dans /e doCumentRFC3251 deyIETF; et -un2 plage d'identités publiques IMPU à laquelle appartient l'identité publique du terminal. 30 Un rappelle que/eparamètre "q"défini par!edocument RFC3Z6l de la norme IETF permet de donner une priorité à un terminal, comprise entre Oet 1, pour la fonction connue de l'homme du rr,:Itler sous Pam de "forking" lorsqu'un appel enle ent' deshna!ion d~ [IMPUesi presunL ou sovmrS~CSCF [inva/i/uo' !a ia!!!e c .iOo~ ~ ' ' chocuo npÜ 35 7 Typiquement, la taille de chacun de ces contextes est de l'ordre de 30 !0(Nlo octets). Dans un mode préféré de réalisation de l'invention, chacune des files de souscription est en outre associée à une valeur Expires d'expiration du service. Par 5 exemple, on choisira unevaleur d'Expires importante, de l'ordre de 24 heures pour les fi/es de souscription attribuées aux passerelles domestiques et une valeur d'expiration de quelques heures pour les terminaux secondaires de voix sur IPSPI et SP2 de sorte qu'en cas de perte de connec±iv!téVVIFI nu de dysfonctionnement du termina/ non prioritaire, !es ressources mémoires soient libérées beaucoup plus rapidement au niveau des 10 équipements du réseau. Dans un mode de réalisation de l'invention, !a politique de souscription associée à une file de souscription est choisie parmi : -une première politique (POLA) pour laquelle i/ n'est pas effectué de contrôle quant au nombre de dialogues pouvant être enregistrés dans la file : 15 -unedeuxième politique (POLB)définissant un nombre maximum de dialogues SIP dans !a file, celle-ci étant gérée se/on une méthode de type FIFO (first in fiotout) ; et 'une troisième politique (POL[) consistant à rejeter toute demande de souscription dans k: file au-delà d'un nombre maximum de dialogues déjà enregistrés 20 dans cette file. En ce qui concerne !a deuxième politique, plusieurs solutions peuvent être envisagées pour déterminer /e ternninal à rejeter selon !a méthode FIF(}. On peut choisir notamment de rejeter : -/oterminal dæ!afile dont !asouscription esL!aplus ancienne ; ou 25 - !e barminal de !a file générant }e moins de trafic sur le réseau ; ou ' le terminal de !a file dont !e paramètre qdéfini dans le document RFC3261 est le plus petit. L'invention vise également une entité de bordure, un serveur S-CSCF et un serveur d'application ci.)n1portJnt un dispositif de gestion de souscription tel que 30 mentionné précédemment. L'invention vise aussi un message de nnnscripLion à un service émis par on terminal dans un IMS, cL , (-je Ld,i' in ci e de sélection, p r soi~Uon p~nx~ ure ;!uo[iùdch/asdco .kzn /u Dans xo uo~. / §hx o.^ snntdeLeno'x.`us ùo y^ü 35 A En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en oeuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en oeuvre des étapes du procédé de gestion des souscriptions à un service tel que mentionné ci-dessus. ~ Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, hal que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un ordinateur, et 10 comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker !e programme. Par exemple, !2 support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une 15 disquette (f!oppydisc)ouundisque dur. D'autre part, !e support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon !'invention peut être en particu!ierté!échapgé sur un réseau de type Internet. 70 Alternativement, !e support d'informations peut être un circuit intégré dans lequel !e programme est incorporé, !c circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Brève description des dessins 25 D'autres caractéristiques et avantages de la présente invention ressortiront de ka description faite ci-dessous en référence aux dessins qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Star les figures : -/æ figure 1 déjà décrite représente une entité de bordure EB, un serveur S-30 CSCF et un serveur d'application AS conformas à un mode particulier de réalisation de l'invention ; re 2 r 'àchitecture matérielle de ces entités un exemple ~nleGm mHUuo /pn 35 , !~ U~ qcsUo: dc >o.~~c'!!~iion ~ un sa~ cuub/n~ à un n1oc,: r~~!~~Uun~~yxwen! 9 Description détaillée d'un mode de réalisation En référence à ta figure 2, on a représenté l'architecture matérielle d'un ~ dispositif 1Udegestion des souscriptions à un service conforme à un mode de réalisation de l'invention. Dans le mode de réalisation décrit ici, ce dispositif 10 a l'architecture matérielle d'un ordinateur. Il comporte notamment un processeur 11, une mémoire vive de type RAM 12, une mémoire morte de type ROM 13, des moyens de communication 14 et une 10 mémoire non volatile réinscriptible 15. La mémoire mode de type ROM 13 constitue un support d'enregistrement conh}rrneà l'invention. Os support d'enregistrement est lisible par /e processeur 11 et il mémorise un programme d'ordinateur PG comprenant des instructions pour mettre en oeuvre !e procédé de gestion de souscription dont !es principales étapes sont 15 représentées sous forme d'organigramme à la figure 3. [e dispositif 10 de souscription est incorporé dans chacune des entités traversées par !es messages de souscription et gérant les dialogues SU8SCRIBE à savoir, par l'entité de bordure EB, par le serveur S-CSCF et par le serveur d'application AS. Dans cette description, la référence 10 désigne l'une quelconque de ces entités. 20 On va maintenant décrire, en réfénenceà la figure 3 les principales étapes E10 à E90 du procédé mis en oeuvre par ces entités. [e procédé comporte, une étape préliminaire ES de création de files de souscription F1, F2 et F3, et d'une file de souscription par défaut FD, dans chacune des entités EB, S-CSCFet AS. 25 Dans !e mode de réalisation décrit ici, les files de souscription sont mémorisées dans la mémoire non volatile réinscriptibie 15 du dispositif 10. 0n supposera qu'une entité 100 reçoit au cours d'une étape E10 un message de souscription 5IP 5UBSCRIBEémis par un terminal SPI, 5P2 Du par la passerelle t-iGW, tous ces équipements ayant la même identité publique IMPU. 30 Aucours d'une étape E15, le dispositif 10 détermine si la syntaxe du message de souscription SUBSCRI8E reçu à !'étape EIO est correcte. Si te/ n'est pas !e cas, /e rés t du test E15 cs~ n`gatif et co test est suivi par um ~ E20 au (-clips de l'entité cOn[cxn~.nev\cuxsu~cKications ni ~ ~u Drnect ce test est un iesi L25 ~. cours duquel AeLbLu 10 35 10 détermine si elle est une entité de bordure E8, un serveur S-CSCF ou un serveur d'application AS. Si l'entité 10 est un serveur 6-CSCF et si !a message de souscription SJP SUBSCRlBEest cnnMgunë pour être authentifié en coeur de réseau IMS, le test E25 est ~ suivi par une étape E30 d'authentification du Lerminal émetteur du message de souscription. Si cette authentification échoue, le résultat du test E30 est négatif et ce test est suivi par une étape E20 d'envoi d'un code de retour SIP selon le mécanisme décrit dans le document RFC3265. 10 Si l'authentification réussit, le test E30 est suivi par un test E35. Lorsque !'entité 100 est une identité de bordure EB ou un serveur d'application A6, celle-ci ne met pas en oeuvre !'étape d'authentification et le test E25 est suivi par ce test E35. Au cours du test E35, il est déterminé si le message de souscription reçu à 15 !'étape E10 estun message de souscription initial. Si tel est !e cas, ce test E35 est suivi par une étape E40 au cours de laquelle l'entité 100 identifie si le message de souscription comporte un paramètre discriminant lui permettant de sélectionner une des files de souscription F1, F2, F3 créée à l'étape E5 pour le service demandé. 70 Si hel n'est pas !e cas, !e résultat du test E40 est négatif et la file de souscription par défaut FD est attribuée, pour !e service demandé, au terminal émetteur du message de souscription au cours d'une étape E45. Au contraire, si !e message de souscription SUB5CRI8E comporte un hel paramètre discriminant, l'entité 100 détermine la file de souscription F1, F2 ou F3 sur la 25 base de ce paramètre au cours d'une étape E50. Au cours d'une étape E55, l'entité 1Odétermine quelle politique de souscription est associée à la file déterminée précédemment (file F1, F2, F3 ou file par défaut FD). Si la politique de souscription est la première politique (POLA), le résultat du test E55 est suivi par une c'topo E-70 de création d'un contexte de dialogue SIP associé au 30 message de souscription reçu à l'étape Elil Si la politique de la file de souscription est la deuxième politique (POLB) ou la troisièr-, eeiiTique (POLC), ri 100 Tit'_tei ruine au cours d'uni. '- le nOxxxc/noxmmn) x/sc/i;L!o// tir e trie et atteint. 35 (POLcii, Troisième politique aucours d'une 11 étape E65 et !e dispositif 100 envoie par exemple un code de retour 403 Forbidden au terminal. Si tel n'est pas le cas, l'étape B@ est suivie par l'étape E70 de création de contexte de dialogue. ~ L'étape E70 de création de contexte de dialogue consiste à enregistrer un dialogue SIP de souscription, pour /e terminal émetteur du message 5UBS[RIBE reçu à l'étape E10 et pour le service demandé par ce message. L'étape E70 est suivie par une étape E75 au cours de laquelle !'entité 100 détermine si æ!ie est constituée par un serveur S-C3CF, par un serveur d'application AS 10 ou par une entité de bordure EB. Si l'entité 100 est un serveur S'CSCFou une entité de bordure EB, le test E75 est suivi par une étape E80 au cours de laquelle le dispositif 100 relaie le message de souscription 5UB5CRIBE reçuà !'étape E10 vers le noeud aval. Si l'entité 100 est un serveur d'application AS, /e test E75 est suivi par une ` 15 étape E85 au cours de laquelle /e serveur AS envoie un code de retour 200 OK au termina! Si le service est opérationnel, ce message comportant la valeur d'expiration Expires associée à !a file choisie à !'étape E45 ou E50. Puis, au cours d'une étape E90, !e serveur d'application AS notifie instantanément le terminal émetteur du message SUBSCRIBE de l'état du service.