FR3011423A1 - Technique de restauration d'un service dans un reseau - Google Patents

Abstract

L'invention concerne un procédé de traitement dans un réseau de communication d'une requête de service relative à un utilisateur, dans lequel pendant une première phase dite « phase de détection », un serveur d'interrogation interroge un serveur d'abonnées afin d'obtenir un identifiant d'un serveur d'enregistrement nominal auprès duquel il transfère la requête de service, et suite à un échec du transfert, interroge le serveur d'abonnées afin d'obtenir des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour l'utilisateur ; et dans lequel une fois le serveur d'enregistrement nominal réputé injoignable, une deuxième phase dite « phase d'optimisation » est déclenchée, au cours de laquelle est réalisé un unique transfert de la requête de service relative à un utilisateur vers des serveurs d'enregistrement.

Description

L'invention se situe dans le domaine des réseaux de communication de type IP (Internet Protocol), et concerne plus particulièrement une technique de restauration d'un service pour un utilisateur dans un réseau de type IMS (IP Multimedia System).

Une architecture de réseau IMS telle que définie par le groupe de normalisation 3GPP (pour 3rd Generation Partnership Project) permet l'établissement et le contrôle de sessions multimédia entre deux équipements utilisateur ainsi que la réservation de ressources pour les flux multimédias au niveau du réseau de transport. Grâce à cette architecture, les opérateurs de réseaux peuvent commodément contrôler la qualité de service offerte. L'architecture IMS permet actuellement d'offrir des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée et gère également l'interaction de ces services. Elle met généralement en oeuvre le protocole SIP (pour Session Initiation Protocol), tel que défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261 en tant que protocole de gestion de sessions, lequel permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Une telle architecture de réseau IMS comprend notamment : - un ou plusieurs serveurs d'abonnés, ou serveurs HSS (pour Home Subscriber Server), contenant chacun une base de données utilisateurs. Chaque serveur d'abonnés contient le « profil » d'un certain nombre d'équipements utilisateur du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits ; - un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (pour Serving-Call Server Control Function) permettant notamment de gérer la procédure d'enregistrement des équipements utilisateur connectés au réseau ; - un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (pour Interrogating-Call Server Control Function), permettant d'interroger un serveur d'abonnés au moment de l'enregistrement d'un équipement utilisateur, afin de d'obtenir un identifiant d'un serveur d'enregistrement disposant des caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateu, un tel serveur est appelé par la suite « serveur d'enregistrement nominal » ; - un ou plusieurs serveurs mandataires (aussi appelés serveurs « proxy »), désignés par « P-CSCF » (pour Proxy-Call Server Control Function), servant d'entité de raccordement entre le coeur de réseau IMS et le réseau d'accès utilisé par les équipements utilisateur, aptes à retransmettre tous les messages de signalisation entre les équipements utilisateur d'une part et les serveurs SCSCF ou I-CSCF d'autre part. Afin d'assurer une continuité de service dans un réseau IMS, le groupe de normalisation 3GPP a défini dans un document de spécifications techniques TS 23.380 version 11.1.0, intitulé « IMS Restoration Procedures », des procédures relatives à la restauration de service au sein d'un réseau IMS lorsqu'un serveur d'enregistrement nominal est injoignable (e.g., panne réseau, ou panne du serveur d'enregistrement lui-même). Deux procédures de restauration sont en particulier décrites, la première intervenant lors de l'enregistrement d'un équipement utilisateur sur le réseau IMS (TS 23.380, §4.2.2), et la seconde lors de la fin d'une session avec un équipement utilisateur (TS 23.380, §4.3.3). Ces deux procédures prévoient un envoi d'un message de demande de capacités par un serveur d'interrogation I-CSCF à un serveur d'abonnés HSS, afin que le serveur d'interrogation I-CSCF puisse sélectionner un serveur d'enregistrement S-CSCF de remplacement. Ces « capacités » sont définies dans le Chapitre 6.7 des spécifications techniques 3GPP TS 29.228. Ceci permet d'assurer une continuité de service dans le réseau IMS transparente pour l'utilisateur. Un inconvénient des procédures de restauration de service telles que spécifiées dans le document de spécification TS 23.380, est que lors du traitement d'une requête de service relative à un utilisateur, un transfert de cette dernière est systématiquement effectué vers le serveur d'enregistrement nominal. Dans le cas où le serveur d'enregistrement nominal reste injoignable l'attente d'une réponse de la part de ce dernier et les retransmissions de la requête de service vers ce serveur d'enregistrement nominal sont particulièrement consommateur en terme de ressources réseaux, alors même que les capacités du réseau sont réduites du fait notamment de l'indisponibilité du serveur d'enregistrement nominal. Il existe donc un besoin d'améliorer le traitement d'une requête de service relative à un utilisateur lors d'une restauration de service dans un réseau IMS. Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. Selon un premier aspect l'invention concerne un procédé de traitement dans un réseau de communication d'une requête de service relative à un utilisateur, ledit procédé comprenant les étapes suivantes mises en oeuvre par un serveur d'interrogation pendant une phase d'optimisation : a/ réception en provenance d'un équipement utilisateur de ladite requête de service relative à un utilisateur ; b/ interrogation du serveur d'abonnés afin d'obtenir une information permettant de traiter la requête de service ; c/ réception depuis un serveur d'abonnés de capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour ledit utilisateur ; d/ détermination d'un serveur d'enregistrement de remplacement à partir des capacités reçues, et transfert de la requête de service vers le serveur d'enregistrement de remplacement déterminé ; dans lequel, pendant une phase de détection, au cours de laquelle le serveur d'enregistrement est réputé joignable, ledit serveur d'enregistrement nominal étant associé audit utilisateur, et ledit procédé comprend en outre préalablement à l'étape c/ de réception de capacités les étapes suivantes : bl/ réception d'un identifiant d'un serveur d'enregistrement nominal en réponse à l'interrogation de l'étape b/ ; b2/ transfert de la requête de service vers le serveur d'enregistrement nominal ; et suite à un échec de ce transfert vers le serveur d'enregistrement nominal : b3/ interrogation du serveur d'abonnés afin d'obtenir lesdites capacités ; et le serveur d'enregistrement nominal étant réputé injoignable à l'issue de la phase de détection, déclenchement de la phase d'optimisation au cours de laquelle le transfert de l'étape d/ est l'unique transfert de la requête de service réalisé vers des serveurs d'enregistrement. La phase de détection met en oeuvre les étapes prévues dans les procédures de restauration décrites dans la spécification technique TS 23.380. Le procédé de traitement prévoit ainsi une phase d'optimisation, déclenchée lorsque le serveur d'enregistrement nominal est réputé injoignable. Grâce au procédé de traitement, la requête de service relative à l'utilisateur n'est transférée qu'une fois vers un serveur d'enregistrement pendant la phase d'optimisation. Il est ainsi possible d'éviter les temps d'attente et les retransmissions faisant suite au transfert de la requête de service vers un serveur d'enregistrement injoignable. Les procédures de restauration de service, telles que définies dans la spécification technique TS 23.380, ne sont mises en oeuvre que suite à un constat d'indisponibilité du serveur d'enregistrement nominal après un premier transfert de la requête de service vers ce serveur d'enregistrement nominal Un unique transfert de la requête de service pendant la phase d'optimisation permet d'économiser les ressources réseau et d'optimiser le traitement des requêtes de service relatives à un utilisateur en cas d'indisponibilité d'un serveur d'enregistrement nominal Le trafic au sein du réseau est également réduit. La continuité de service est ainsi renforcée, ce qui contribue à améliorer la qualité de service perçue par l'utilisateur. Selon une caractéristique particulière, le procédé de traitement comprend en outre une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en oeuvre par le serveur d'interrogation. L'étape de détermination que le serveur d'enregistrement nominal est réputé injoignable permet de déclencher la phase d'optimisation. La gestion de la restauration de service est locale à chaque serveur d'interrogation du réseau. Il est possible de mettre en oeuvre des stratégies de restauration de service propres à chaque serveur d'interrogation du réseau, en fonction par exemple du nombre d'échecs de transfert déclenchant la phase d'optimisation. Selon une autre caractéristique particulière, le procédé de traitement comprend une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en oeuvre par le serveur d'abonnés. Le déclenchement de la phase d'optimisation par le serveur d'abonnés permet une gestion centralisée de la restauration de service. Le serveur d'abonnés peut maintenir une information relative à l'indisponibilité d'un serveur d'enregistrement pour chaque serveur d'enregistrement du réseau. Lorsque le serveur d'abonnés est interrogé par un serveur d'interrogation afin d'obtenir un identifiant d'un serveur d'enregistrement nominal associé à un utilisateur, le serveur d'abonnés renvoie directement des capacités en réponse à cette interrogation lorsqu'il a identifié le serveur d'enregistrement comme étant injoignable ou indisponible. Une deuxième interrogation du serveur d'abonnés par le serveur d'interrogation afin d'obtenir des capacités ainsi qu'un éventuel nouvel échec de transfert de la requête de service sont ainsi évités, ce qui a pour effet de diminuer le trafic réseau. Il est également à noter que s'agissant d'une gestion centralisée, le nombre d'interrogation du serveur d'abonnés est indépendant du nombre de serveur d'interrogation du réseau. Selon une autre caractéristique particulière, l'état injoignable du serveur d'enregistrement nominal est déterminé à partir d'au moins un compteur associé audit serveur d'enregistrement nominal, mis à jour pendant la phase de détection lors d'un échec de transfert vers le serveur d'enregistrement nominal.

La mise en oeuvre d'un compteur permet d'avoir une information directe quant au nombre d'échec de transfert pour un serveur d'enregistrement donné. Associé à un état injoignable d'un serveur d'enregistrement, elle permet de définir différentes stratégies quant au déclenchement de la phase d'optimisation. Cette dernière phase est par exemple déclenchée en fonction du nombre d'échec de transfert de la requête de service. Un opérateur pourra par exemple décider de définir un nombre d'échec de transfert faible avant déclenchement de la phase d'optimisation pour des serveurs d'interrogation nécessitant la meilleure continuité de service, et élevé pour des environnements tolérants des interruptions de services. Il est ainsi possible à l'opérateur de proposer différents niveaux de qualité de service à un utilisateur. Le compteur étant par ailleurs associé à un serveur d'enregistrement indépendamment du type de requête de service, la gestion pour ce compteur de valeurs de déclenchement de la phase d'optimisation est simple. Il n'existe en effet qu'un compteur à mettre à jour par serveur d'enregistrement connu d'un serveur d'interrogation. Selon une autre caractéristique particulière, l'état injoignable du serveur d'enregistrement nominal est déterminé à partir d'une pluralité de compteurs respectivement associés à une pluralité de types de requête de service. Des compteurs spécialisés par type de requête de service permettent une gestion fine des stratégies de restauration de service dans un réseau IMS. Un opérateur peut par exemple choisir de privilégier une continuité de service pour les requêtes relatives à l'enregistrement (e.g. requêtes UAR, User Authorization Request) d'un équipement utilisateur sur le réseau IMS, et adopter une politique de restauration de service différente pour par exemple des requêtes LIR (Location Info Request) dîtes de localisation. Selon un deuxième aspect, l'invention concerne un serveur d'interrogation, agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un premier module d'envoi/réception, agencé pour recevoir en provenance d'un équipement utilisateur ladite requête de service relative à un utilisateur et la transférer vers un serveur d'enregistrement ; - un second module d'envoi/réception, agencé pour interroger un serveur d'abonnés, afin d'obtenir en retour un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de sélection, agencé pour déterminer un serveur d'enregistrement de remplacement à partir de capacités reçues ; - un module de commande, agencé pour commander une interrogation d'un serveur d'abonnés, afin de lors d'une première phase, obtenir un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur, commander un transfert vers le serveur d'enregistrement nominal et suite à un échec de transfert de la requête de service vers ledit serveur d'enregistrement nominal, obtenir des capacités ; et également agencé pour, lors d'une deuxième phase, commander lorsque le serveur d'enregistrement nominal est réputé injoignable, un unique transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement. Selon une caractéristique particulière, le serveur d'interrogation comprend en outre un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement. Les avantages énoncés pour le procédé de traitement selon l'une quelconque des caractéristiques du premier aspect sont directement transposables au serveur d'interrogation selon le deuxième aspect.

Selon un troisième aspect, l'invention concerne un serveur d'abonnés agencé pour traiter une requête de service relative à un utilisateur comprenant : - un module d'envoi/réception, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de commande, agencé pour commander lors d'une phase d'optimisation où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur d'enregistrement nominal. Selon une caractéristique particulière, le serveur d' abonnés comprend en outre un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d' enregistrement. Selon un quatrième aspect, l'invention propose un système de traitement d'une requête de service dans un réseau de communication, ledit système comprenant : - un serveur d'interrogation selon le deuxième aspect ; - un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement ; et - un serveur d'abonnés comprenant : - un module d'envoi/réception, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de commande, agencé pour commander la réponse au serveur d'interrogation. Selon une caractéristique particulière, le module de commande du serveur d'abonnés est en outre agencé pour commander lors d'une phase d'optimisation où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur d'enregistrement nominal. Selon un cinquième aspect, l'invention concerne un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré un programme pour un serveur d'interrogation. Selon un sixième aspect, l'invention concerne également un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré un programme un serveur d'abonnés. L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels : - la figure 1 représente un système de traitement d'une requête de service relative à un utilisateur dans un réseau de communication; - la figure 2 représente un serveur d'interrogation mettant en oeuvre un procédé de traitement d'une requête de service selon un mode particulier de réalisation ; - le figure 3 représente un serveur d'abonnés selon un mode particulier de réalisation ; - les figures 4a et 4b représentent des étapes d'un procédé de traitement d'une requête de service relative à un utilisateur selon deux modes particuliers de réalisation.

La figure 1 représente un système 2 de traitement d'une requête de service dans un réseau de communication 1. Les services multimédia offerts par ce réseau 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu, de Présence, de Messagerie Instantanée, ou de télévision. Le système 2 permet de transférer une demande d'enregistrement d'un équipement utilisateur (User Equipment, ou UE en anglais) 10 sur le réseau 1 vers un serveur d'enregistrement, et de bénéficier des services offerts par ce réseau. L'équipement utilisateur 10 est par exemple un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise. Le système 2 comprend un serveur d'interrogation 20, un serveur d'abonnés 30 et un module de calcul (non représenté) permettant de déterminer si un serveur d'enregistrement est injoignable. Le module de calcul est par exemple selon un premier mode de réalisation décrit ultérieurement intégré au serveur d'interrogation 20 ou selon un deuxième mode de réalisation également décrit ultérieurement intégré au serveur d'abonnés 30. Les serveurs d'abonnés 30 et d'interrogation 20 communiquent par ailleurs ensemble. Le serveur d'interrogation 20 communique également avec des serveurs d'enregistrement 40-41. Il est par ailleurs à noter que la figure 1 est représentée de manière simplifiée afin de faciliter la compréhension. Il n'existe cependant pas de limitation quant au nombre de serveurs d'abonnés, de serveurs d'enregistrement, de serveurs d'interrogation appartenant au réseau de communication. De même il n'existe pas de limitation quant au nombre d'équipement utilisateur. Dans le cas particulier où le réseau de communication 1 présente une architecture de type IMS, le serveur d'interrogation 20 est un serveur I-CSCF, les serveurs d'enregistrement 40-41 sont des serveurs S-CSCF et le serveur d'abonnés 30 est un serveur HSS, certains de ces différents serveurs pouvant être rassemblés au sein d'une même entité, le cas échéant. Dans le cas d'une telle architecture IMS, le protocole de signalisation SIP est utilisé pour les échanges avec l'équipement utilisateur 10, ainsi qu'entre les serveurs d'interrogation 20 et d'enregistrement 40-41. Les échanges entre le serveur d'abonnés 30 d'une part et les serveurs d'interrogation 20 et d'enregistrement 40-41 d'autre part, sont quant à eux supportés par le protocole Diameter. Les modes de réalisation décrits par la suite en relation avec les figures 4a et 4b présentent un procédé de traitement d'une requête de service relative à un utilisateur. Ils reposent sur deux phases : une première phase de détection Pl et une deuxième phase d'optimisation P2. Pendant la phase de détection Pl, dans le cas d'un échec de transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement nominal 40, les procédures de restauration de service telles que définies dans la spécification technique TS 23.380 sont mises en oeuvre. Puis sur détection que le serveur d'enregistrement est injoignable la deuxième phase d'optimisation P2 est déclenchée. La figure 4a décrit les étapes du procédé de traitement d'une requête de service relative à un utilisateur selon un premier mode de réalisation. Dans ce premier mode de réalisation, la détection que le serveur d'enregistrement nominal 40 est injoignable est mise en oeuvre dans le réseau de communication IMS 1 par le serveur d'interrogation 20. Dans une étape El, le serveur d'interrogation 20 reçoit une requête de service M1 relative à un utilisateur en provenance d'un équipement utilisateur 10. La requête de service M1 est par exemple une requête SIP REGISTER d'enregistrement auprès d'un serveur d'enregistrement.

Le serveur d'interrogation 20 interroge dans une étape E2 le serveur d'abonnés 30 afin d'obtenir un identifiant du serveur d'enregistrement nominal 40 possédant les caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateur. Cette interrogation est plus particulièrement réalisée par l'envoi d'un message UAR (pour User-Authorization-Request) M2 selon le protocole Diameter tel que défini dans la RFC 4740 et conformément aux spécifications 3GPP TS 24.229 et TS 29.228. Lors d'une étape E3, le serveur d'interrogation 20 reçoit du serveur d'abonnés 30 en réponse à la requête UAR M2, un message UAA (pour User-Authorization-Answer) M3 lui indiquant un identifiant Ids cscH du serveur d'enregistrement nominal 40 auprès duquel l'utilisateur est enregistré. Cet identifiant est par exemple un identifiant uniforme de ressource (Uniform Resource Identifier ou URI en anglais) tel que défini par la RFC 3986. Dans une étape E4, le serveur d'interrogation 20 vérifie à l'aide d'un compteur CPT si un seuil S1 conditionnant le passage à une deuxième phase P2, dite « phase d'optimisation », a été atteint. Le seuil Si est défini par l'opérateur du réseau de communication. L'atteinte de ce seuil Si met fin à une première phase Pl, dite « phase de détection », à l'issue de laquelle le serveur d'enregistrement nominal 40 est réputé injoignable. La deuxième phase P2 est alors déclenchée. Lorsque la deuxième phase P2 n'est pas déclenchée, le serveur d'interrogation 20 transfere lors d'une étape E5 la requête SIP REGISTER (message M4) vers le serveur d'enregistrement nominal 40 identifié à l'étape E3. A l'étape E6, une absence de réponse à la requête SIP REGISTER est constatée par le serveur d'interrogation 20. Le protocole SIP prévoit un mécanisme de réémission de messages, à l'issue duquel après plusieurs tentatives d'envoi sans réponse, l'absence de réponse est considérée comme étant identique à un code de réponse 408 Request Timeout, indiquant qu'aucune réponse du serveur d'enregistrement nominal 40 n'a été reçue dans le temps imparti pour le traitement du message. L'absence de réponse du serveur d'enregistrement nominal 40 résulte par exemple d'une panne de ce dernier, d'un trafic réseau perturbé, ou de toute autre cause ne permettant pas de le joindre ou ne permettant pas à ce dernier de répondre à une requête reçue.

Dans une étape E7, conformément aux procédures de restauration du service IMS telles que définies dans les spécifications techniques 3GPP TS 23.380, un nouveau message UAR M5 comportant une demande de capacités est envoyé au serveur d'abonnés 30. La demande de capacités est construite en renseignant le champ User-Authorization-type du message UAR M5 par la valeur REGISTRATION AND_CAPABILITIES.

Le serveur d'interrogation 20 incrémente ensuite le compteur CPT associé au serveur d'enregistrement 40 dans une étape E8. Le compteur CPT est incrémenté à chaque émission d'une requête UAR comportant une demande de capacités pendant la phase de détection. Dans le mode de réalisation décrit, un compteur est associé à chaque serveur d'enregistrement. Dans une étape E9, le serveur d'interrogation 20 reçoit une réponse du serveur d'abonnés 30 sous la forme d'un message UAA M6 comprenant les capacités demandées. Le serveur d'interrogation 20 détermine ensuite lors d'une étape E10, à partir des capacités reçues, un nouveau serveur d'enregistrement 41 capable de rendre le service requis par l'équipement utilisateur 10. Ce serveur d'enregistrement 41 déterminé, appelé serveur d'enregistrement de remplacement, se substitue ainsi au serveur d'enregistrement nominal 40 auprès duquel une tentative de transfert d'une requête SIP REGISTER a précédemment échoué. Dans une étape Ell, le serveur d'interrogation 20 transfere la requête SIP REGISTER M7 au serveur d'enregistrement 41 déterminé à l'étape E10. Les étapes El à El 1 sont de nouveau mises en oeuvre à chaque fois qu'une requête de service relative à un utilisateur est reçue, tant que la phase de détection n'a pas pris fin. C'est-à-dire tant que le compteur associé au serveur d'enregistrement 40, incrémenté à l'étape E8, ne dépasse pas le seuil Sl.

Lorsque le seuil S1 est atteint, le serveur d'enregistrement nominal 40 est réputé injoignable et la deuxième phase d'optimisation P2 est déclenchée. Cette deuxième phase P2 diffère de la première phase Pl par l'absence des étapes E5 et E6. Seules les étapes El à E4 et E7 à El l sont mises en oeuvre pour le traitement d'une requête de service relative à un utilisateur. Au cours de cette deuxième phase P2, le serveur d'interrogation 20 vérifie à l'aide du compteur CPT associé au serveur d'enregistrement nominal 40 si le seuil Si conditionnant le passage à la deuxième phase d'optimisation P2 a été atteint. L'atteinte de ce seuil S1 met fin à la première phase de détection Pl, à l'issue de laquelle le serveur d'enregistrement nominal 40 est réputé injoignable. Le transfert de la requête de service relative à un utilisateur vers le serveur d'enregistrement nominal 40 est alors inhibé pendant la phase d'optimisation.

Les étapes E7 à El 1 sont ensuite mises en oeuvre telles que décrites précédemment en relation avec la première phase Pl, afin de transférer la requête de service relative à un utilisateur vers le serveur d'enregistrement de remplacement 41. Un unique transfert de la requête de service est ainsi réalisé au cours de la deuxième phase P2. Le procédé permet avantageusement d'éviter l'attente et les retransmissions (lors de l'étape E5) générées par une absence de réponse du serveur d'enregistrement nominal 40. Ceci permet notamment d'optimiser l'utilisation des ressources du réseau. Dans un mode de réalisation particulier, le serveur d'interrogation 20 continue pendant la deuxième phase P2 d'incrémenter le compteur CPT associé au serveur d'enregistrement nominal 40 lors d'une étape E8. Cette étape permet lors de cette deuxième phase P2 de définir par exemple un second seuil S2 associé au serveur d'enregistrement nominal 40 qui lorsqu'il est dépassé permet de revenir à un traitement nominal de la requête de service. Ce second seuil permet de détecter par exemple qu'un certain nombre de requêtes UAR comportant une demande de capacités a été envoyé. Il est alors probable que le serveur d'enregistrement nominal 40 soit de nouveau en fonctionnement par exemple si une panne était survenue.

Les étapes de cette deuxième phase P2, El à E4 et E7 à Ell, sont de nouveau mises en oeuvre à chaque réception d'une requête de service relative à un utilisateur jusqu'à l'atteinte par exemple du second seuil S2 permettant un retour à un traitement nominal des requêtes de service relatives à un utilisateur ou une intervention de l'opérateur du réseau pour remplacer le serveur d'enregistrement nominal, ce qui met fin à la deuxième phase P2. Dans un autre mode réalisation, à l'atteinte du second seuil S2, le serveur d'interrogation (20) transfere la requête de service relative à l'utilisateur vers le serveur d'enregistrement nominal (40). Dans le cas où ce dernier est de nouveau joignable, le compteur CPT est remis à zéro, permettant ainsi un retour à un traitement nominal des requêtes de service. Lorsque le serveur d'enregistrement nominal (40) reste injoignable, une nouvelle tentative de transfert de la requête de service relative à l'utilisateur vers ce serveur est par exemple réalisée à l'atteint d'une nouvelle valeur de seuil Sn fonction du seuil S2. A titre d'exemple non limitatif, une tentative de transfert est réalisée pour chaque valeur de seuil Sn = 2' x S2 . La figure 4b décrit les étapes du procédé de traitement d'une requête de service relative à un utilisateur selon un deuxième mode de réalisation. Dans ce deuxième mode de réalisation, la détection que le serveur d'enregistrement nominal 40 est injoignable est mise en oeuvre dans le réseau de communication IMS 1 par le serveur d'abonnés 30. Dans ce deuxième mode de réalisation, le compteur associé au serveur d'enregistrement nominal 40 n'est plus géré par le serveur d'interrogation 20 mais par le serveur d'abonnés 30. Le serveur d'abonnés 30, plus précisément le module de calcul, met alors en oeuvre une étape E8b, similaire à l'étape E8. Le compteur associé au serveur d'enregistrement nominal 40 est alors incrémenté par le serveur d'abonnés 30 à chaque réception d'un message UAR M5 comprenant une demande de capacités. De même, la détermination que le serveur d'enregistrement nominal 40 est réputé injoignable, permettant le déclenchement de la deuxième phase P2 est effectuée par le serveur d'abonnés 30 lors d'une étape E4b, similaire à l'étape E4. Dans ce deuxième mode de réalisation, lors de la deuxième phase P2, le serveur d'interrogation 20 met en oeuvre les étapes El et E2 précédemment décrites en relation avec le premier mode de réalisation et transmet une requête UAR nominale M2. Sur réception de cette requête UAR nominale, le serveur d'abonnés 30 répond directement dans la deuxième phase P2 avec un message UAA comprenant des capacités, reçu par le serveur d'interrogation 20 dans l'étape E9. Le serveur d'abonnés 30 répond ainsi comme s'il avait reçu du serveur d'interrogation 20 une requête UAR comportant une demande de capacités. Dans ce deuxième mode de réalisation, le serveur d'interrogation 20 est ainsi agencé pour recevoir des informations de capacités sans les avoir demandées précédemment On souligne ici que, les étapes E3 à E7 décrites précédemment en relation avec la figure 4a n'étant pas mises en oeuvre dans ce deuxième mode de réalisation lors de la deuxième phase P2, le procédé de traitement permet d'éviter les échanges de messages UAR (étape E7) et UAA (étape E3) entre le serveur d'interrogation 20 et le serveur d'abonnés 30. L'envoi d'une requête SIP- REGISTER vers le serveur d'enregistrement nominal 40 est également évité (étape E5). Ceci permet notamment d'optimiser l'utilisation des ressources du réseau, en allégeant plus particulièrement le trafic de messages de signalisation dû à la redondance des messages UAR et UAA. Les étapes El0 et El 1 sont ensuite mises en oeuvre conformément à ce qui a été décrit précédemment en relation avec la figure 4a. La gestion du compteur permettant de déterminer qu'un serveur d'enregistrement est injoignable est centralisée au niveau du serveur d'abonnés 30, et est de ce fait également plus facile à mettre en oeuvre. Ce deuxième mode de réalisation permet en particulier au serveur d'abonnés 30 de répondre à un serveur d'interrogation pour une requête de service relative à l'utilisateur sans que le serveur d'interrogation ait explicitement à demander des capacités. Ce deuxième mode de réalisation permet également de faire bénéficier des avantages de la mise en oeuvre du procédé de traitement à un serveur d'interrogation recevant une requête de service relative à l'utilisateur et présentant par exemple peu de trafic, du fait de la prise en compte lors de l'étape E8b de mise à jour du compteur des messages UAR reçus depuis les autres serveurs d'interrogation. Les précédents modes de réalisation ont été décrits pour le traitement d'une requête de service SIP REGISTER. Il n'existe cependant pas de limitations quant aux types de requête de service traités. Le procédé s'applique également par exemple à une requête de service SIP INVITE. Dans ce dernier cas, le procédé de traitement mis en oeuvre est équivalent à celui mis en oeuvre pour traiter une requête SIP REGISTER, seuls les types de messages échangés entre le serveur d'interrogation 20 et le serveur d'abonnés 30 different. Au lieu des messages UAR et UAA, les serveurs s'échangent respectivement des messages LIR (pour Location Info Request) et LIA (pour Location Info Answer). Un compteur pour les interrogations du serveur d'abonnés est alors incrémenté dans le premier mode, lors de l'étape E8 à chaque émission d'une requête LIR comportant une demande de capacités, ou dans le deuxième mode lors de l'étape E8b à chaque réception d'une requête LIR. Dans un autre mode de réalisation, au lieu d'un compteur associé à un type de requête particulier (UAR ou LIR dans les modes de réalisation décrits précédemment), il peut être avantageux d'utiliser un compteur global incrémenté indifféremment lors de l'émission d'une requête UAR ou d'une requête LIR comprenant chacune une demande de capacités lorsque le compteur est géré par le serveur d'interrogation 20 tel que décrit précédemment dans le premier mode de réalisation, ou lors de la réception de ces requêtes sans demande explicite de capacités lorsque le compteur est géré par le serveur d'abonnés 30 tel que décrit précédemment dans le deuxième mode de réalisation. La prise en compte de l'ensemble des requêtes donnant lieu à l'émission d'un message UAR ou LIR permet notamment de déclencher plus rapidement la phase d'optimisation P2.

De même, dans un autre mode de réalisation, plusieurs seuils sont utilisés pour le déclenchement de la deuxième phase P2. Un seuil est par exemple associé à chaque compteur défini par type de requête. Ceci permet d'adopter des stratégies de restauration de service plus fines, avec par exemple plusieurs valeurs de seuils en fonction du trafic entrant ou encore de tranches horaires. L'opérateur de réseau peut par exemple choisir de mettre en oeuvre la deuxième phase P2 plus rapidement pour des tranches horaires présentant un trafic réseau élevé. La figure 2 représente un serveur d'interrogation 20 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment : - un premier module d'envoi/réception 200, agencé pour recevoir une requête de service relative à un utilisateur et la transférer vers un serveur d'enregistrement ; - un second module d'envoi/réception 202, agencé pour interroger un serveur d'abonnés, afin d'obtenir en retour un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de sélection 204, agencé pour déterminer un serveur d'enregistrement de remplacement à partir de capacités reçues ; - un module de commande 206, agencé pour commander une interrogation du serveur d'abonnés. Dans une première phase, le module de commande 206 est agencé pour interroger le serveur d'abonnés afin d'obtenir un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur et suite à un échec de transfert de la requête de service vers le serveur d'enregistrement nominal identifié, pour interroger le serveur d'abonnés afin d'obtenir des capacités. Dans une deuxième phase, déclenchée lorsque le serveur d'enregistrement nominal est réputé injoignable, le module de commande 206 est agencé pour commander un unique transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement. Dans le premier mode de réalisation, le serveur d'interrogation 20 comprend en outre un module de calcul 208, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement. Le module de calcul 208 détermine que le serveur d'enregistrement nominal est réputé injoignable et déclenche la deuxième phase P2.

La figure 3 représente un serveur d'abonnés 30 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment : - un module d'envoi/réception 300, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de commande 302, agencé pour commander la réponse au serveur d' interrogation.

Dans le deuxième mode de réalisation, le serveur d'abonnés 30 comprend en outre un module de calcul 304, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement. Dans la deuxième phase, déclenchée sur détection par le module de calcul 304 que le serveur d'enregistrement nominal est réputé injoignable, le module de commande 302 est agencé pour commander une fourniture de capacités directement en réponse à une demande d'identifiant de serveur d'enregistrement nominal, correspondant au serveur d'enregistrement réputé injoignable. L'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).

De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Dans un mode de réalisation particulier, les modules 200, 202, 204, 206, et 208 sont agencés pour mettre en oeuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de traitement précédemment décrit, mises en oeuvre par un serveur d'interrogation. L'invention concerne donc aussi : - un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d'interrogation ; - un support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré le programme pour un serveur d'interrogation. De même, les modules 300, 302, et 304 sont agencés pour mettre en oeuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de traitement précédemment décrit, mises en oeuvre par un serveur d'abonnés. L'invention concerne donc aussi : - un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d'abonnés ; - un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré le programme pour un serveur d'abonnés. Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.10

Claims (15)

1. REVENDICATIONS1. Procédé de traitement dans un réseau de communication (1) d'une requête de service relative à un utilisateur, ledit procédé comprenant les étapes suivantes mises en oeuvre par un serveur d'interrogation pendant une phase d'optimisation (P2) : a/ réception (El) en provenance d'un équipement utilisateur de ladite requête de service relative à un utilisateur ; b/ interrogation (E2, E7) du serveur d'abonnés (30) afin d'obtenir une information permettant de traiter la requête de service ; c/ réception (E9) depuis un serveur d'abonnés (30) de capacités qu'un serveur d'enregistrement (40-41) doit posséder pour pouvoir fournir les services autorisés pour ledit utilisateur ; d/ détermination (E10) d'un serveur d'enregistrement (41) de remplacement à partir des capacités reçues, et transfert (E11) de la requête de service vers le serveur d'enregistrement de remplacement (41) déterminé ; dans lequel, pendant une phase de détection (Pl), au cours de laquelle le serveur d'enregistrement est réputé joignable, ledit serveur d'enregistrement nominal (40) étant associé audit utilisateur, et ledit procédé comprend en outre préalablement à l'étape c/ de réception (E9) de capacités les étapes suivantes : bl/ réception (E3) d'un identifiant d'un serveur d'enregistrement nominal (40) en réponse à l'interrogation de l'étape b/ ; b2/ transfert (E5) de la requête de service vers le serveur d'enregistrement nominal (40); et suite à un échec de ce transfert vers le serveur d'enregistrement nominal (40) : b3/ interrogation (E7) du serveur d'abonnés (30) afin d'obtenir lesdites capacités ; et le serveur d'enregistrement nominal (40) étant réputé injoignable à l'issue de la phase de détection, déclenchement (E4, E4b) de la phase d'optimisation (P2) au cours de laquelle le transfert de l'étape cl/ est l'unique transfert de la requête de service réalisé vers des serveurs d' enregistrement.
2. 2. Procédé de traitement selon la revendication 1, comprenant en outre une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en oeuvre par le serveur d'interrogation (20).
3. 3. Procédé de traitement selon la revendication 1, comprenant en outre une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en oeuvre par le serveur d' abonnés (30).
4. 4. Procédé de traitement selon la revendication 1, dans lequel l'état injoignable du serveur d'enregistrement nominal (40) est déterminé à partir d'au moins un compteur associé audit serveur d'enregistrement nominal (40), mis à jour pendant la phase de détection (P1) lors d'un échec de transfert vers le serveur d'enregistrement nominal (40).
5. 5. Procédé de traitement selon la revendication 4, dans lequel l'état injoignable du serveur d'enregistrement nominal (40) est déterminé à partir d'une pluralité de compteurs respectivement associés à une pluralité de types de requête de service.
6. 6. Serveur d'interrogation (20), agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un premier module d'envoi/réception (200), agencé pour recevoir en provenance d'un équipement utilisateur ladite requête de service relative à un utilisateur et la transférer vers un serveur d'enregistrement (40-41) ; - un second module d'envoi/réception (202), agencé pour interroger un serveur d'abonnés, afin d'obtenir en retour un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de sélection (204), agencé pour déterminer un serveur d'enregistrement de remplacement à partir de capacités reçues ; - un module de commande (206), agencé pour commander une interrogation d'un serveur d'abonnés, afin de lors d'une première phase (P1), obtenir un identifiant d'un serveur d'enregistrement nominal (40) associé à l'utilisateur, commander un transfert vers le serveur d'enregistrement nominal (40) et suite à un échec de transfert de la requête de service vers ledit serveur d'enregistrement nominal (40), obtenir des capacités ; et également agencé pour, lors d'une deuxième phase (P2), commander lorsque le serveur d'enregistrement nominal est réputé injoignable, un unique transfert de la requête de service relative à un utilisateur vers un serveur d' enregistrement.
7. 7. Serveur d'interrogation (20) selon la revendication 6, comprenant en outre un module de calcul (208), agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement (40).
8. 8. Serveur d'abonnés (30) agencé pour traiter une requête de service relative à un utilisateur comprenant : - un module d'envoi/réception (300), agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveurd'enregistrement nominal associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de commande (302), agencé pour commander lors d'une phase d'optimisation (P2) où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur d'enregistrement nominal
9. 9. Serveur d'abonnés (30) selon la revendication 8, comprenant en outre un module de calcul (304), agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement (40).
10. 10. Système (2) de traitement d'une requête de service dans un réseau de communication (1), ledit système (2) comprenant : - un serveur d'interrogation (20) selon la revendication 6 ; - un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement ; et - un serveur d'abonnés (30) comprenant : - un module d'envoi/réception (300), agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ; - un module de commande (302), agencé pour commander la réponse au serveur d' interrogation. 25
11. 11. Système (2) de traitement d'une requête de service selon la revendication 10, dans lequel le module de commande (302) du serveur d'abonnés (30) est en outre agencé pour commander lors d'une phase d'optimisation (P2) où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur 30 d'enregistrement nominal (40).
12. 12. Programme pour un serveur d'interrogation (20), comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 1 à 5, lorsque ledit programme est exécuté par ledit serveur. 35
13. 13. Programme pour un serveur d'abonnés (30), comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé selon l'une des revendications 3 à 5, lorsque ledit programme est exécuté par ledit serveur.
14. 14. Support d'enregistrement lisible par un serveur d'interrogation (20) sur lequel est enregistré le programme selon la revendication 12.
15. 15. Support d'enregistrement lisible par un serveur d'abonnés (30) sur lequel est enregistré le programme selon la revendication 13.10