WO2012072920A1 - Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims - Google Patents

Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims Download PDF

Info

Publication number
WO2012072920A1
WO2012072920A1 PCT/FR2011/052759 FR2011052759W WO2012072920A1 WO 2012072920 A1 WO2012072920 A1 WO 2012072920A1 FR 2011052759 W FR2011052759 W FR 2011052759W WO 2012072920 A1 WO2012072920 A1 WO 2012072920A1
Authority
WO
WIPO (PCT)
Prior art keywords
subscription
terminal
service
queue
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/FR2011/052759
Other languages
English (en)
Inventor
Bertrand Bouvet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
France Telecom SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom SA filed Critical France Telecom SA
Publication of WO2012072920A1 publication Critical patent/WO2012072920A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1073—Registration or de-registration

Definitions

  • the invention is in the field of IMS (IP Multimedia Subsystem) type telecommunication networks as defined by the 3GPP (Third Generation Partnership Project).
  • IMS IP Multimedia Subsystem
  • 3GPP Third Generation Partnership Project
  • One of the goals of the IMS is to allow a user to access different services regardless of their type of IP connectivity.
  • IMS networks initially designed for mobile networks, tend to develop on fixed access networks such as ADSL (Asymmetric Digital Subscriber Line) or FTTH (fiber to the home), or cable networks in particular.
  • ADSL Asymmetric Digital Subscriber Line
  • FTTH fiber to the home
  • the IMS architectures for fixed networks have been deployed for the marketing of so-called "Multiplay" offers allowing a user to access various services of the IMS network, and in particular to access services to the Internet, to voice IP (VoIP) and Internet TV (IPTV) via a home gateway.
  • VoIP voice IP
  • IPTV Internet TV
  • telecommunications operators offer terminals complementary to fixed telephones, these additional terminals being equipped with voice over IP (VoIP) software using the same public identifier IMPU as that of the home gateway and a private identifier.
  • VoIP voice over IP
  • IMPI may or may not be the same as the home gateway.
  • a terminal To register at the heart of the IMS network, a terminal (called the User Agent in the document RFC3261) sends, to a server S-CSCF (Serving Call State Control Function) responsible for the records, a registration request including the two identifiers IMPU and IMPI supra.
  • S-CSCF Serving Call State Control Function
  • IMS services In addition to the SIP registration required to establish a multimedia session, some IMS services require the terminals to subscribe to certain services, for example to a presence service or to a message deposit notification service called "Message Waiting Indicator”. MWI).
  • the subscription by the terminal to each of these services uses the SIP message (SUBSCRIBE).
  • this message includes event identifiers associated with the services.
  • the subscription mechanism is specified at the IETF level in RFC3265 and the different event information must be declared to the Internet Assigned Numbers Authority.
  • Terminals wishing to subscribe to at least one service must therefore send a SIP SUBSCRIBE message to an entity, usually an application server, hosting the service, this application server AS being called Notifier in RFC3265.
  • an application server mention may be made, for example, of message waiting notification application servers Message Waiting Indicator and presence application servers.
  • Figure 1 describes an architecture implementing a service subscription mechanism in an IMS network.
  • the HGW home gateway provides voice over IP service from a TEL home phone, which in this example is a DECT compliant phone.
  • the home gateway HGW receives in its VoIP configuration file its VoIP subscription parameters and in particular its public entity IMPU.
  • the home gateway HGW connects via an access network RA, for example of the ADSL type, through a first DSLAM type network equipment, which is itself connected to an RC collection network, for example to ATM or Giga Ethernet type which allows it to reach a RO operator network through a first RI router.
  • RA access network
  • a first DSLAM type network equipment which is itself connected to an RC collection network, for example to ATM or Giga Ethernet type which allows it to reach a RO operator network through a first RI router.
  • the RO operator network of the back bone IP type, makes it possible to reach the entry point of the IMS network via a second router R2.
  • the entry point of an IMS network is a so-called "edge" entity, referenced EB in FIG. 1, which may be constituted by:
  • border entity will refer to any of these three devices.
  • the IMS network comprises in particular the functional entities P-CSCF, I-CSCF, S-CSCF, SLF, HSS, and DNS ENUM known to those skilled in the art.
  • the IMS network is interconnected with an AS application server offering a message deposit notification service.
  • an AS application server offering a message deposit notification service.
  • two terminals namely two mobile VoIP terminals SPl and SP2 are connected to the home gateway HGW by a wireless connection WIFI and use the same public identity IMPU as the HGW gateway.
  • Each of the SIP terminals (HGW gateway, voice over IP terminals SP1, SP2) requests a subscription to the services provided by the application server AS, which requires managing the subscription contexts associated with the services, within:
  • a SIP SUBSCRIBE message sent by a terminal includes information from the VoIP configuration file transmitted to the terminal; and especially :
  • URI Uniform Resource Identifier
  • dynamic information obtained by the network including the IP address, the port number, the UDP or TCP transport protocol of the entry point EB of the IMS network;
  • the first SUBSCRIBE subscription message sent by a terminal to subscribe to a service is called the initial subscription message.
  • This subscription message is routed to the IMS core network either directly at the P-CSCF or through the EB boundary entity and, if all conditions are met, this message is routed by the S-CSCF to the application server concerned.
  • the application server concerned responds to the subscription message by a message type 200 OK containing the value of the subscription period (Expires parameters).
  • the application server then immediately transmits to the terminal a NOTIFY notification message providing the status of the information related to the services associated with the event information; this NOTIFY message is acknowledged by the terminal by a message of type 200 OK.
  • the terminal After the initial subscription the terminal must renew the subscription to the services before the expired value expires. This renewal is carried out according to the same principle as the initial subscription, namely by the sequence of messages SUBSCRIBE, 200 OK, NOTIFY, 200 OK.
  • Subsequent messages retain the same SIP dialog identifiers as the initial subscription message and increment a CSeq field from 1 to each new submission.
  • the application server AS transmits, on its own initiative, a SIP NOTIFY message containing the event intended for the terminal, this SIP message being acknowledged by the terminal by the sending of a message 200 OK.
  • the terminal can send to the application server AS a SUBSCRIBE SIP message containing the Expires field set to 0, which responds to this message by sending a message 200 OK, then sends the terminal a NOTIFY notification message containing the end of subscription to the service, this notification message being also acknowledged by the terminal by sending a 200 OK message.
  • an application server AS can notify the terminal that a service is no longer available by sending a notification message SIP NOTIFY containing the end of the subscription to the service, the terminal acknowledging this message by sending a 200 OK message.
  • the duration of the Expires, setting the duration of subscription to the services is variable. It varies in particular according to the service and the load of equipment.
  • the duration of the Expires can be set to 24 hours and the terminal re-subscribes approximately every 23 hours 50 minutes.
  • a SUBSCRIBE dialogue context is created in each of the devices described with reference to FIG. 1 (HGW gateway, EB edge entity, S-CSCF server and AS application server).
  • a SUBSCRIBE dialogue context is created in each of the devices described with reference to FIG. 1 (terminal concerned, EB edge entity, S-CSCF server and server D AS application).
  • terminal concerned EB edge entity, S-CSCF server and server D AS application.
  • the contexts are kept end-to-end in each of the entities and self-destruct automatically when the expires time expires.
  • the terminal SP1, SP 2 or the HGW gateway is re-registered in SIP core network, after a shutdown without unregistration to the previous service, it re-subscribes to the service but using a new SIP SUBSCRIBE dialog .
  • the different equipment traversed (edge entity, S-CSCF server and AS application server) will consume new memory resources to store this new dialogue.
  • some home gateways implement monitoring mechanisms to restart the SIP voice over IP stack under certain conditions, for example during a loss of ADSL synchronization or in the absence of a response from a VoIP equipment without taking the time to unsubscribe to the service or to de-register at the core of the IMS network.
  • the subscription mechanism presented above poses problems of memory sizing at the nodes traversed in the network for memorizing the SIP dialogs, this problem being all the more critical as the duration of service subscription expires. is important.
  • the invention aims at a subscription management method in an IMS network that does not have the disadvantages of those of the state of the art.
  • the invention relates to a method for managing subscription to a service in an IMS network, these methods comprising:
  • the invention relates to a subscription management device for a service in an IMS network, this device comprising:
  • the invention proposes to manage the subscription to different SIP services by using several subscription queues.
  • the method according to the invention must be implemented in each of the entities traversed and managing the subscription dialogues (EB edge entity, S-CSCF server and AS application server).
  • the fact of managing several subscription queues makes it possible to optimize the memory resources of the various equipment traversed by applying policies adapted to each queue.
  • the discriminant parameter chosen to select the subscription queue is chosen from:
  • a public identity range IMPU to which the public identity of the terminal belongs.
  • the parameter "q" defined by the document RFC3261 of the IETF standard makes it possible to give a priority to a terminal, between 0 and 1, for the function known to those skilled in the art under the name of "forking" when an incoming call to the IMPU is presented to the S-CSCF server.
  • the specific size associated with each of the queues corresponds to the number of subscription dialog contexts that can be stored in the queue.
  • each of these contexts is of the order of 30 KO (kilobytes).
  • each of the subscription queues is further associated with an expires value of expiration of the service.
  • an expires value of expiration of the service For example, we will choose a value of Expired significant, of the order of 24 hours for the subscription queues assigned to the home gateways and a value of expiration of a few hours for the secondary terminals of voice over IP SP1 and SP2 so in case of loss of WIFI connectivity or malfunction of the non-priority terminal, the memory resources are released much more quickly at the network equipment level.
  • the subscription policy associated with a subscription queue is chosen from:
  • POLA a first policy for which there is no control as to the number of dialogs that can be recorded in the queue
  • POLB second policy
  • POLC third policy
  • the invention also relates to an edge entity, an S-CSCF server and an application server comprising a subscription management device as mentioned above.
  • the invention also aims at a subscription message to a service sent by a terminal in an IMS network, this message comprising a selection criterion, for a network identity, a subscription queue among a plurality of subscription queues associated with a public identity of the terminal transmitting the message for this service.
  • the various steps of the filtering method are determined by computer program instructions.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented by a computer, this program comprising instructions adapted to the implementation of the steps of the method of management of subscriptions to a service as mentioned above.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention also relates to a computer-readable information medium, comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 already described represents an edge entity EB, an S-CSCF server and an application server AS in accordance with a particular embodiment of the invention
  • FIG. 2 represents the hardware architecture of these entities in a particular embodiment of the invention.
  • FIG. 3 represents in flowchart form the main steps of a subscription management method for a service according to a particular embodiment of the invention.
  • FIG. 2 there is shown the hardware architecture of a subscription management device 10 to a service according to one embodiment of the invention.
  • this device 10 has the hardware architecture of a computer. It comprises in particular a processor 11, a random access memory of the RAM type 12, a ROM type ROM 13, communication means 14 and a rewritable non-volatile memory 15.
  • ROM ROM 13 is a recording medium according to the invention. This recording medium is readable by the processor 11 and it stores a PG computer program including instructions for implementing the subscription management method whose main steps are represented in flow chart form in FIG. 3.
  • This subscription device 10 is incorporated in each of the entities traversed by the subscription messages and manages the SUBSCRIBE dialogs namely, by the EB border entity, by the S-CSCF server and by the application server AS.
  • reference 100 denotes any of these entities.
  • This method comprises, a preliminary step E5 creation of subscription queues Fl, F2 and F3, and a default subscription queue FD, in each of the entities EB, S-CSCF and AS.
  • the subscription queues are stored in the rewritable non-volatile memory 15 of the device 10.
  • an entity 100 receives, during a step E10, a SUBSCRIBE SIP subscription message sent by a terminal SP1, SP2 or by the gateway HGW, all these equipments having the same public identity IMPU.
  • the device 10 determines whether the syntax of the SUBSCRIBE subscription message received in step E10 is correct.
  • step E20 the entity 100 returns a SIP return code according to the specifications defined in the document RFC3265.
  • the result of the E15 test is positive and this test is followed by an E25 test in which the entity 100 determines whether it is an EB border entity, an S-CSCF server or a AS application server.
  • the test E25 is followed by an authentication step E30 of the terminal issuing the subscription message.
  • step E35 it is determined whether the subscription message received in step E10 is an initial subscription message.
  • this test E35 is followed by a step E40 during which the entity 100 identifies whether the subscription message includes a discriminating parameter enabling it to select one of the subscription queues F1, F2, F3 created at the first time. step E5 for the requested service.
  • the result of the test E40 is negative and the default subscription queue FD is allocated, for the requested service, to the terminal sending the subscription message during a step E45.
  • the entity 100 determines the subscription queue Fl, F2 or F3 on the basis of this parameter during a step E50.
  • step E55 the entity 100 determines which subscription policy is associated with the previously determined queue (file Fl, F2, F3 or default file FD). If the subscription policy is the first policy (POLA), the result of the test E55 is followed by a step E70 of creating a SIP dialogue context associated with the subscription message received in step E10.
  • POLA the first policy
  • the device 10 determines, during a step E60 if the maximum number of subscription dialogs for this queue has been reached.
  • the subscription message received in step E10 is rejected during a step E65 and the device 10 sends for example a code of return 403 Forbidden to the terminal.
  • POLC third policy
  • step E60 is followed by step E70 of creating dialogue context.
  • the dialog context creation step E70 consists of registering a subscription SIP dialogue, for the terminal sending the SUBSCRIBE message received in step E10 and for the service requested by this message.
  • the step E70 is followed by a step E75 during which the entity 100 determines whether it is constituted by an S-CSCF server, by an application server AS or by an edge entity EB.
  • test E75 is followed by a step E80 during which the device 10 relays the SUBSCRIBE subscription message received in step E10 to the downstream node .
  • test E75 is followed by a step E85 during which the server AS sends a return code 200 OK to the terminal if the service is operational, this message including the value of d expires associated with the queue chosen in step E45 or E50.
  • the application server AS instantly notifies the sending terminal of the SUBSCRIBE message of the state of the service.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Ce procédé de gestion d'une souscription à un service dans un réseau IMS comporte : - une étape (E5) 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; - une étape (E10) de réception d'un message de souscription audit service émis par un terminal ayant cette identité publique; et -une étape (E70) d'attribution d'une desdites files de souscription audit terminal pour ledit service sur la base d'un paramètre discriminant compris dans un champ dudit message de souscription.

Description

Procédé et dispositif de gestion d'une souscription à un service dans un réseau IMS
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 Subsystem) tel que défini par le 3GPP (Third Génération Partnership Project).
L'un des objectifs de l'IMS est de permettre à un utilisateur d'accéder à différents services quel que soit son type de connectivité 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 type ADSL (Asymmetric Digital Subscriber Line), ou FTTH (Fiber To The Home), ou sur des réseaux câblés notamment.
Les architectures IMS pour les réseaux fixes ont en particulier été déployées pour la commercialisation d'offres dites « Multiplay » permettant à un utilisateur d'accéder à différents services du réseau IMS, et notamment à des services d'accès au réseau Internet, de voix sur IP (VoIP) et de télévision sur internet (IPTV), via une passerelle domestique.
Afin de diversifier leur offre, les 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 sur IP (VoIP) utilisant le même identifiant public IMPU que celui de la passerelle domestique et un identifiant privé IMPI pouvant être ou non le même que celui de la passerelle domestique.
Pour s'enregistrer en cœur de réseau IMS, un terminal (appelé User Agent dans le document RFC3261) envoie, à un serveur S-CSCF (Serving Call State Control Function) responsable des enregistrements, une requête d'enregistrement comportant notamment les deux identifiants IMPU et IMPI précités.
En complément de l'enregistrement SIP 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 de messages appelé « Message Waiting Indicator » (MWI).
La souscription par le terminal à chacun de ces services utilise le message SIP (SUBSCRIBE).
De façon connue, ce message comporte des identifiants d'événements (Event Packages) associés aux services. Le mécanisme de souscription est spécifié au niveau de l'IETF dans le document RFC3265 et les différentes informations d'événement doivent être déclarées à ΙΊΑΝΑ (Internet Assigned Numbers Authority).
Les terminaux qui veulent souscrire à au moins un service (appelés Subscriber dans le document RFC3265) doivent donc envoyer un message SIP SUBSCRIBE à 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 titre d'exemple de serveur d'application, on peut par exemple citer les serveurs d'application de notification de dépôt de messages Message Waiting Indicator et les serveurs d'application de présence.
La figure 1 décrit une architecture mettant en œuvre un mécanisme de souscription à un service dans un réseau IMS.
La passerelle domestique HGW offre un service de voix sur IP à partir d'un téléphone domestique TEL, constitué dans cet exemple par un téléphone conforme à la norme DECT.
La passerelle domestique HGW reçoit dans son fichier de configuration VoIP ses paramètres d'abonnement aux services VoIP et en particulier son entité publique IMPU.
La passerelle domestique HGW 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 Ethernet ce qui lui permet d'atteindre un réseau opérateur RO à travers un premier routeur RI.
Le réseau opérateur RO, de type back bone IP permet d'atteindre, au travers un deuxième routeur R2 le point d'entrée du réseau IMS.
De façon connue, le point d'entrée d'un réseau IMS est une entité dite « de bordure », référencée EB sur la figure 1, celle-ci pouvant être constituée par :
- un équipement SBC (Session Border Controller) ;
- un serveur P-CSCF ;
- un équipement remplissant à la fois les fonctions d'un équipement SBC et celles d'un serveur P-CSCF.
Dans la suite de ce document, la terminologie « entité de bordure » désignera l'un quelconque de ces trois équipements.
Le réseau IMS comporte notamment les entités fonctionnelles P-CSCF, I-CSCF, S-CSCF, SLF, HSS, et DNS ENUM connues de l'homme du métier.
Dans l'exemple décrit ici le réseau IMS est interconnecté à un serveur d'application AS offrant un service de notification de dépôt de messages. Dans l'exemple de la figure 1, deux terminaux, à savoir deux terminaux mobiles de voix sur IP (Soft Phone VoIP) SPl et SP2 sont connectés à la passerelle domestique HGW par une liaison sans fil WIFI et utilisent la même identité publique IMPU que la passerelle HGW.
Chacun des terminaux SIP (passerelle HGW, terminaux de voix sur IP SPl, SP2) demande une souscription aux services fournis par le serveur d'application AS, ce qui nécessite de gérer les contextes de souscription associés aux services, au sein :
- de chaque terminal ;
- des équipements intermédiaires (entité de bordure EB et/ou serveur S-CSCF) ; et
- du serveur d'application AS.
De façon connue, un message SIP SUBSCRIBE émis par un terminal comporte des informations provenant du fichier de configuration VoIP transmis au terminal ; et notamment :
- l'identité publique IMPU ;
- le nom de domaine du réseau IMS ;
- l'URI (« Uniform Resource Identifier ») permettant l'accès au service fourni par le serveur d'application AS ;
- des informations dynamiques obtenues par le réseau, dont l'adresse IP, le numéro de port, le protocole de transport UDP ou TCP du point d'entrée EB du réseau IMS ;
- 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 SUBSCRIBE envoyé par un terminal pour souscrire à un service est appelé message de souscription initial.
Ce message de souscription est routé vers le cœur de réseau IMS soit directement au niveau du P-CSCF, soit au travers de l'entité de bordure EB puis, si toutes les conditions sont remplies, ce message est routé par le S-CSCF vers le serveur d'application concerné.
De façon connue le 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 souscription (paramètres Expires).
Le serveur d'application émet ensuite immédiatement vers le terminal un message de notification NOTIFY fournissant l'état des informations liées aux services associés aux informations d'événement (Event Package) ; ce message NOTIFY est acquitté par le terminal par un message de type 200 OK. De façon connue, après la souscription initiale le terminal doit renouveler la souscription aux services avant que la valeur d'Expirés n'arrive à expiration. Ce renouvellement est réalisé selon le même principe que la souscription initiale, à savoir par l'enchaînement des messages SUBSCRIBE, 200 OK, NOTIFY, 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 CSeq de 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 l'événement à destination du terminal, ce message SIP étant acquitté par le terminal par l'envoi d'un message 200 OK.
De façon connue, pour dé-souscrire à un service, le terminal peut envoyer au serveur d'application AS un message SIP SUBSCRIBE contenant le champ Expires fixé à 0, 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 message de notification étant lui aussi acquitté par le terminal par l'envoi d'un message 200 OK.
De même, à tout moment, un serveur d'application AS 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 d'un message 200 OK.
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.
A titre d'exemple, pour le service MWI de notification de dépôt de message au sein d'une messagerie vocale, la durée de l'Expires peut être fixée à 24 heures et le terminal re-souscrit environ toutes les 23 heures 50 minutes.
Lorsque la passerelle domestique HGW souscrit à un service, un contexte de dialogue SUBSCRIBE est créé dans chacun des équipements décrits en référence à la figure 1 (passerelle HGW, entité de bordure EB, serveur S-CSCF et serveur d'application AS).
De façon similaire, lorsqu'un terminal SP1, SP2 souscrit à un service, un contexte de dialogue SUBSCRIBE est créé dans chacun des équipements décrits en référence à la figure 1 (terminal concerné, entité de bordure EB, serveur S-CSCF et serveur d'application AS). En fonctionnement normal, tant que le terminal ne désouscrit pas au service, les contextes sont conservés de bout en bout dans chacune des entités et s'autodétruisent automatiquement à l'expiration de la durée Expires.
Mais, si pour une raison ou pour une autre, le terminal SP1, SP 2 ou la passerelle HGW se réenregistre en cœur de réseau SIP, après un arrêt sans désouscription au service précédent, il resouscrit au service mais en utilisant un nouveau dialogue SIP SUBSCRIBE.
Par conséquent, les 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 œuvre des mécanismes de surveillance pour redémarrer la pile de voix sur IP SIP sous certaines conditions, par exemple lors d'une perte de synchronisation ADSL ou en absence de réponse d'un équipement VoIP sans prendre le temps de désouscrire au service ni de se désenregistrer au niveau du cœur de réseau IMS.
Par conséquent, le mécanisme de souscription présenté ci-dessus pose des problèmes de dimensionnement de la mémoire au niveau des nœuds traversés dans le réseau pour la mémorisation des dialogues SIP, 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
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 :
- 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
- une étape 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. Corrélativement, l'invention concerne un dispositif de gestion de souscription à un service dans un réseau IMS, ce dispositif comportant :
- 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 ;
- des moyens de réception d'un message de souscription à ce service émis par un terminal 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 à différents services SIP en utilisant plusieurs files de souscription.
Pour être efficace, le procédé selon l'invention doit être mis en œuvre dans chacune des entités traversées et gérant les dialogues de souscription (entité de bordure EB, serveur S-CSCF et serveur d'application AS).
Le fait de gérer plusieurs files de souscription permet de définir des terminaux dits "prioritaires" (tels que la passerelle domestique HGW qui offre le 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 IP SP1 et SP2).
Par ailleurs, et de façon très avantageuse, le fait de gérer plusieurs files de souscription permet d'optimiser les ressources mémoires des différents équipements 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 ;
- un type du terminal ;
- un identifiant du réseau auquel appartient ce terminal ;
- le paramètre q défini dans le document RFC3261 de l'IETF ; et
- une plage d'identités publiques IMPU à laquelle appartient l'identité publique du terminal.
On rappelle que le paramètre "q" défini par le document RFC3261 de la norme IETF permet de donner une priorité à un terminal, comprise entre 0 et 1, pour la fonction connue de l'homme du métier sous le nom de "forking" lorsqu'un appel entrant à destination de l'IMPU est présenté au serveur S-CSCF. Au sens de l'invention, la taille spécifique associée à chacune des files correspond au nombre de contextes de dialogue de souscription pouvant être mémorisés dans la file.
Typiquement, la taille de chacun de ces contextes est de l'ordre de 30 KO (kilo 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 exemple, on choisira une valeur d'Expirés importante, de l'ordre de 24 heures pour les files de souscription attribuées aux passerelles domestiques et une valeur d'expiration de quelques heures pour les terminaux secondaires de voix sur IP SP1 et SP2 de sorte qu'en cas de perte de connectivité WIFI ou de dysfonctionnement du terminal non prioritaire, les ressources mémoires soient libérées beaucoup plus rapidement au niveau des équipements du réseau.
Dans un mode de réalisation de l'invention, la politique de souscription associée à une file de souscription est choisie parmi :
- une première politique (POLA) pour laquelle il n'est pas effectué de contrôle quant au nombre de dialogues pouvant être enregistrés dans la file :
- une deuxième politique (POLB) définissant un nombre maximum de dialogues SIP dans la file, celle-ci étant gérée selon une méthode de type FIFO (first in first out) ; et
- une troisième politique (POLC) consistant à rejeter toute demande de souscription dans la file au-delà d'un nombre maximum de dialogues déjà enregistrés dans cette file.
En ce qui concerne la deuxième politique, plusieurs solutions peuvent être envisagées pour déterminer le terminal à rejeter selon la méthode FIFO. On peut choisir notamment de rejeter :
- le terminal de la file dont la souscription est la plus ancienne ; ou
- le terminal de la file générant le moins de trafic sur le réseau ; ou
- le terminal de la file dont le paramètre q dé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 comportant un dispositif de gestion de souscription tel que mentionné précédemment.
L'invention vise aussi un message de souscription à un service émis par un terminal dans un réseau IMS, ce message comportant un critère de sélection, pour une identité du réseau, d'une file de souscription parmi une pluralité de files de souscription associées à une identité publique du terminal émetteur du message pour ce service.
Dans un mode particulier de réalisation, les différentes étapes du procédé de filtrage sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre par un ordinateur, ce programme comportant des instructions adaptées à la mise en œuvre 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, tel 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 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 le programme. Par exemple, le 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 disquette (floppy dise) ou un disque dur.
D'autre part, le 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 l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la 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. Sur les figures :
- la figure 1 déjà décrite représente une entité de bordure EB, un serveur S- CSCF et un serveur d'application AS conformes à un mode particulier de réalisation de l'invention ; - la figure 2 représente l'architecture matérielle de ces entités dans un exemple particulier de réalisation de l'invention ; et
- la figure 3 représente sous forme d'organigramme les principales étapes d'un procédé de gestion de souscription à un service conforme à un mode particulier de réalisation de l'invention.
Description détaillée d'un mode de réalisation
En référence à la figure 2, on a représenté l'architecture matérielle d'un dispositif 10 de gestion 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 mémoire non volatile réinscriptible 15.
La mémoire morte de type ROM 13 constitue un support d'enregistrement conforme à l'invention. Ce support d'enregistrement est lisible par le processeur 11 et il mémorise un programme d'ordinateur PG comprenant des instructions pour mettre en œuvre le procédé de gestion de souscription dont les principales étapes sont représentées sous forme d'organigramme à la figure 3.
Ce dispositif 10 de souscription est incorporé dans chacune des entités traversées par les messages de souscription et gérant les dialogues SUBSCRIBE à 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 100 désigne l'une quelconque de ces entités.
On va maintenant décrire, en référence à la figure 3 les principales étapes E10 à E90 du procédé mis en œuvre par ces entités.
Ce procédé comporte, une étape préliminaire E5 de création de files de souscription Fl, F2 et F3, et d'une file de souscription par défaut FD, dans chacune des entités EB, S-CSCF et AS.
Dans le mode de réalisation décrit ici, les files de souscription sont mémorisées dans la mémoire non volatile réinscriptible 15 du dispositif 10.
On supposera qu'une entité 100 reçoit au cours d'une étape E10 un message de souscription SIP SUBSCRIBE émis par un terminal SP1, SP2 ou par la passerelle HGW, tous ces équipements ayant la même identité publique IMPU. Au cours d'une étape E15, le dispositif 10 détermine si la syntaxe du message de souscription SUBSCRIBE reçu à l'étape E10 est correcte.
Si tel n'est pas le cas, le résultat du test E15 est négatif et ce test est suivi par une étape E20 au cours de laquelle l'entité 100 renvoie un code de retour SIP conformément aux spécifications définies dans le document RFC3265.
Si le message de souscription SUBS est syntaxiquement correct, le résultat du test E15 est positif et ce test est suivi par un test E25 au cours duquel l'entité 100 détermine si elle est une entité de bordure EB, un serveur S-CSCF ou un serveur d'application AS.
Si l'entité 100 est un serveur S-CSCF et si le message de souscription SIP SUBSCRIBE est configuré pour être authentifié en cœur de réseau IMS, le test E25 est suivi par une étape E30 d'authentification du terminal é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.
Si l'authentification réussit, le test E30 est suivi par un test E35.
Lorsque l'entité 100 est une identité de bordure EB ou un serveur d'application AS, celle-ci ne met pas en œuvre l'é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 à l'étape E10 est un message de souscription initial.
Si tel est le 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 Fl, F2, F3 créée à l'étape E5 pour le service demandé.
Si tel n'est pas le cas, le résultat du test E40 est négatif et la file de souscription par défaut FD est attribuée, pour le service demandé, au terminal émetteur du message de souscription au cours d'une étape E45.
Au contraire, si le message de souscription SUBSCRIBE comporte un tel paramètre discriminant, l'entité 100 détermine la file de souscription Fl, F2 ou F3 sur la base de ce paramètre au cours d'une étape E50.
Au cours d'une étape E55, l'entité 100 détermine quelle politique de souscription est associée à la file déterminée précédemment (file Fl, 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 étape E70 de création d'un contexte de dialogue SIP associé au message de souscription reçu à l'étape E10.
Si la politique de la file de souscription est la deuxième politique (POLB) ou la troisième politique (POLC), le dispositif 10 détermine, au cours d'une étape E60 si le nombre maximum de dialogues de souscription pour cette file a été atteint.
Si tel est le cas, et si la politique de souscription est la troisième politique (POLC), alors le message de souscription reçu à l'étape E10 est rejeté au cours d'une étape E65 et le dispositif 10 envoie par exemple un code de retour 403 Forbidden au terminal.
Si tel n'est pas le cas, l'étape E60 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 le terminal émetteur du message SUBSCRIBE 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 l'entité 100 détermine si elle est constituée par un serveur S-CSCF, par un serveur d'application AS ou par une entité de bordure EB.
Si l'entité 100 est un serveur S-CSCF ou une entité de bordure EB, le test E75 est suivi par une étape E80 au cours de laquelle le dispositif 10 relaie le message de souscription SUBSCRIBE reçu à l'étape E10 vers le nœud aval.
Si l'entité 100 est un serveur d'application AS, le test E75 est suivi par une étape E85 au cours de laquelle le serveur AS envoie un code de retour 200 OK au terminal si le service est opérationnel, ce message comportant la valeur d'expiration Expires associée à la file choisie à l'étape E45 ou E50.
Puis, au cours d'une étape E90, le serveur d'application AS notifie instantanément le terminal émetteur du message SUBSCRIBE de l'état du service.

Claims

REVENDICATIONS
1. Procédé de gestion d'une souscription à un service dans un réseau IMS, ce procédé comportant :
- une étape (E5) de création, pour une identité publique (IMPU) donnée, d'au moins deux files de souscription (Fl, F2, F3), chacune étant associée à une taille et à une politique (POLI, POL2, POL3) de souscription ;
- une étape (E10) de réception d'un message de souscription audit service émis par un terminal (HGW, SP1, SP2) ayant ladite identité publique ; et
-une étape (E70) d'attribution d'une desdites files de souscription audit terminal pour ledit service sur la base d'un paramètre discriminant compris dans un champ dudit message de souscription.
2. Procédé de gestion selon la revendication 1, caractérisé en ce que ledit paramètre discriminant est choisi parmi :
- un identifiant du service auquel ledit terminal souhaite souscrire ;
- un jeton d'identification ;
- un type du terminal ;
- un identifiant du réseau auquel appartient ledit terminal ;
- le paramètre q défini dans le document RFC3261 de l'IETF ;
- une plage d'identités publiques (IMPU) à laquelle appartient ladite identité publique.
3. Procédé de gestion selon la revendication 1, caractérisé en ce que chaque file de souscription est en outre associée à une valeur d'expiration dudit service.
4. Procédé de gestion selon la revendication 1, caractérisé en ce qu'il comporte une étape d'attribution d'une file par défaut (FD) audit terminal si ledit message ne comporte pas ledit paramètre discriminant.
5. Procédé de gestion selon la revendication 1 caractérisé en ce que ladite politique de souscription (POLA, POLB, POLC) associée à une file de souscription est choisie parmi :
- une première politique (POLA) pour laquelle il n'est pas effectué de contrôle quant au nombre de dialogues pouvant être enregistrés dans ladite file ;
- une deuxième politique (POLB) définissant un nombre maximum de dialogues SIP dans ladite file, celle-ci étant gérée selon une méthode de type FIFO ; et - une troisième politique (POLC) consistant à rejeter toute demande de souscription dans ladite file, au-delà d'un nombre maximum de dialogues déjà enregistrés dans ladite file.
6. Procédé de gestion selon la revendication 5 caractérisé en ce que ladite deuxième politique de souscription (POLB) consiste à rejeter, selon la méthode FIFO :
- le terminal de ladite file dont la souscription est la plus ancienne ; ou
- le terminal de ladite file générant le moins de trafic sur le réseau ; ou
- le terminal de ladite file dont le paramètre q défini dans le document RFC3261 est le plus petit.
7. Dispositif (10) de gestion des souscriptions à un service dans un réseau IMS, ce dispositif comportant :
- des moyens (11, 12, 13, 14, 15) de création, pour une identité publique (IMPU) donnée, d'au moins deux files de souscription (Fl, F2, F3), chacune étant associée à une taille et à une politique (POLI, POL2, POL3) de souscription ;
- des moyens (11, 12, 13, 14, 15) de réception d'un message (SUBS) de souscription audit service émis par un terminal (HGW, SP1, SP2) ayant ladite identité publique ;
- des moyens (11, 12, 13, 14, 15) d'attribution d'une desdites files de souscription audit terminal pour ledit service sur la base d'un paramètre discriminant compris dans un champ dudit message de souscription.
8. Entité de bordure (EB) comportant un dispositif de gestion des souscriptions selon la revendication 7.
9. Serveur S-CSCF comportant un dispositif de gestion des souscriptions selon la revendication 7.
10. Serveur d'application (AS) comportant un dispositif de gestion des souscriptions selon la revendication 7.
11. Message (SUBS) de souscription à un service émis par un terminal dans un réseau IMS, caractérisé en ce qu'il comporte un critère de sélection, pour une entité (EB, S-CSCF, AS) dudit réseau, d'une file de souscription (Fl) parmi une pluralité de files de souscription (Fl, F2, F3) associées à une identité publique (IMPU) du terminal émetteur dudit message pour ledit service.
12. Programme d'ordinateur (PG) comportant des instructions pour l'exécution des étapes du procédé de gestion des souscriptions selon l'une quelconque des revendications 1 à 6 lorsque ledit programme est exécuté par un ordinateur.
13. Support d'enregistrement (13) lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PG) comprenant des instructions pour l'exécution des étapes du procédé de gestion des souscriptions selon l'une quelconque des revendications 1 à 6.
PCT/FR2011/052759 2010-11-30 2011-11-25 Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims Ceased WO2012072920A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1059900 2010-11-30
FR1059900A FR2968158A1 (fr) 2010-11-30 2010-11-30 Procede et dispositif de gestion d'une souscription a un service dans un reseau ims

Publications (1)

Publication Number Publication Date
WO2012072920A1 true WO2012072920A1 (fr) 2012-06-07

Family

ID=44147557

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/052759 Ceased WO2012072920A1 (fr) 2010-11-30 2011-11-25 Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims

Country Status (2)

Country Link
FR (1) FR2968158A1 (fr)
WO (1) WO2012072920A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2139195A1 (fr) * 2008-06-23 2009-12-30 Alcatel Lucent Procédé, appareil et système pour l'enregistrement d'un terminal doté d'un serveur d'application dans un IMS
WO2010079307A1 (fr) * 2009-01-08 2010-07-15 France Telecom Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2139195A1 (fr) * 2008-06-23 2009-12-30 Alcatel Lucent Procédé, appareil et système pour l'enregistrement d'un terminal doté d'un serveur d'application dans un IMS
WO2010079307A1 (fr) * 2009-01-08 2010-07-15 France Telecom Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ROACH A B: "RFC 3265: Session Initiation Protocol (SIP) - Specific Event Notification", NETWORK WORKING GROUP REQUEST FOR COMMENTS, XX, XX, 1 June 2002 (2002-06-01), pages 1 - 38, XP002280672 *

Also Published As

Publication number Publication date
FR2968158A1 (fr) 2012-06-01

Similar Documents

Publication Publication Date Title
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2786546A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
EP2926524A1 (fr) Routage d'une requete de service visant un abonne ims
WO2017168084A1 (fr) Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
EP3646578B1 (fr) Procédé de synchronisation d'état média
WO2019102117A1 (fr) Procédé de propagation d'informations concernant la bande passante allouée à un usager d'un réseau ip
WO2009122078A1 (fr) Partage de contenu multi supports a partir d'une communication audio-video
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP2458813B1 (fr) Procédé de détection d'une situation de nomadisme d'un terminal SIP et terminal mettant en oeuvre ce procédé
FR3021836A1 (fr) Procede pour informer une entite d' un reseau ip du type de reseau d' acces utilise par un terminal
FR2968158A1 (fr) Procede et dispositif de gestion d'une souscription a un service dans un reseau ims
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
WO2007148015A2 (fr) Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims
FR2988951A1 (fr) Procede d'enregistrement d'un serveur aupres d'une pluralite de coeurs de reseau, et serveur.
WO2013156727A1 (fr) Procede de traitement d'un message, entite et cœur de reseau
WO2011151572A1 (fr) Procede et dispositif de presentation d'un appel entrant dans un reseau ims
WO2009030869A2 (fr) Procede et dispositif pour gerer le desenregistrement d'un terminal aupres d'une entite dans un reseau de telecommunications

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11799781

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11799781

Country of ref document: EP

Kind code of ref document: A1