WO2011064492A1 - Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip - Google Patents

Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip Download PDF

Info

Publication number
WO2011064492A1
WO2011064492A1 PCT/FR2010/052476 FR2010052476W WO2011064492A1 WO 2011064492 A1 WO2011064492 A1 WO 2011064492A1 FR 2010052476 W FR2010052476 W FR 2010052476W WO 2011064492 A1 WO2011064492 A1 WO 2011064492A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
hss
servers
cscf
primary
Prior art date
Application number
PCT/FR2010/052476
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
France Telecom
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 filed Critical France Telecom
Priority to US13/511,737 priority Critical patent/US9021300B2/en
Priority to EP10805447.9A priority patent/EP2504982B1/fr
Publication of WO2011064492A1 publication Critical patent/WO2011064492A1/fr

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/10—Architectures or entities
    • H04L65/1045—Proxies, e.g. for session initiation protocol [SIP]
    • 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/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Definitions

  • IP Internet Protocol
  • VoIP Voice over IP
  • Presence Presence
  • IP Internet Protocol
  • the present invention relates to the consistency of customer information recorded in such a network, and therefore the coherence in the processing by the network of the conversational data relating to these customers.
  • the client devices to which such resources are accessible may for example be a fixed or mobile terminal, or a home or residential gateway ("Residential Gateway” in English), or a network operator gateway ("Voice Gateway”).
  • a DSLAM-SIP DSLAM-SIP
  • DSLAM-SIP DSLAM-SIP
  • SIP protocol initials of the words “Session Initiation Protocol” meaning “Session Initiation Protocol”
  • signaling messages
  • the SIP protocol has been defined by the IETF in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • the SIP protocol also allows for event notification procedures and the sending of information outside the context of a session. It is widely used for instant messaging service orders. Thus, in a SIP environment, there are different types of communications such as session establishment requests and queries exchanged outside any dialog.
  • IMS IP Multimedia Subsystem
  • IMS IP Multimedia Subsystem
  • 3GPP 3rd Generation Partnership Project
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • This architecture which uses the SIP protocol, enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the network for transporting multimedia streams.
  • network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • IMS currently provides access to telephony services, videophone , presence and instant messaging, which she also manages the interaction.
  • the user's terminal When a user wishes to benefit from the services offered by an IP network such as those described above, he sends signaling messages to the network that may include various types of requests.
  • the user's terminal must register on the network. When the network is unable to link this record to a previous record (for example, due to a network failure, or following a termination of the terminal for a duration longer than a predetermined value), the record is considered to be a initial registration. After an initial registration, the user's terminal must periodically send the network a request to confirm that it wishes to maintain its registration.
  • the IP networks as described above comprise one or more servers, generally called “S-CSCF” (initials of the words “Serving-CalI Server Control Function” meaning “Control Function of the Server d 'Service Calls'), able (among other functions) to manage the registration procedure of devices connected to the network.
  • S-CSCF server-CalI Server Control Function
  • these networks comprise one or more servers, generally called “l-CSCF” (initials of the English words “Interrogating- Call Server Control Function” meaning “Query Call Server Control Function”) which, at the moment the registration of a client device, query a server called “HSS” (initials of the words “Home Subscriber Server” meaning “Nominal Subscriber Server”) to be able to select an S-CSCF server having the characteristics that are mandatory (and, if necessary, optional) required to achieve the level of service underwritten by this customer.
  • each client device can, after an S-CSCF server has been so assigned, send a subscription request to certain services for the current connection.
  • It can be an event notification service: for example, when the user of a terminal has a mailbox on the network, this terminal can subscribe to a message deposit notification, it that is to say, he can ask to be informed whenever a message has been recorded on this voicemail box; the end of the user may also request to be notified of its registration status; it can also subscribe to a presence notification service, which allows it to receive information published by another user it has designated, and so on.
  • the terminal After the initial subscription request, the terminal must periodically send the network a request to renew its subscription.
  • the S-CSCF servers contribute to the implementation of these various services by managing the routing of the signaling, on the one hand, between each client device and the servers of the network specialized in the implementation customer service, and to other customers managed by the same network or a network
  • the servers of type l-CSCF or of type S-CSCF exchange information with one or more server (s) HSS type mentioned above.
  • the HSS servers each contain a client database, and are therefore the equivalent in IP networks of "HLR” servers (initials of the words “Home Location Register” meaning “Nominal Location Register”) used in GSM networks. .
  • HLR Home Location Register
  • Each HSS server contains the "profile" of a number of network clients, this profile including their registration status, authentication and location data, and subscribed services.
  • HSS servers therefore play a vital role in the operation of such a network, and the accuracy of the dynamic information they contain is essential for the proper functioning of the network. This is why it is generally planned to associate with each "normal"("primary") HSS an "emergency"("secondary”) HSS intended to replace the primary HSS in the event that the latter breaks down. But such a provision entails, as realized by the authors of the present invention, a real danger as to the coherence in the processing by the network of information relating to customers.
  • the present invention thus relates, according to a first aspect adapted to a first network architecture, to a method of switching from a primary HSS server to a backup HSS server in an IP network, said network comprising a plurality of CSCF servers (respectively, application servers), in which, following detection of a loss of connection between one of said CSCF servers (respectively, application servers) and a primary HSS server to which it is normally connected, this server CSCF (respectively , application server) connects to a backup HSS server.
  • the method is remarkable in that it also comprises the following steps:
  • said broadcast device sends, at least to the other CSCF servers (respectively, application servers) normally connected to said primary HSS, a predetermined failure message containing the reference of said primary HSS server, and
  • said other CSCF servers connect to said backup HSS server.
  • said CSCF server can accommodate either an S-CSCF function, or a function l-CSCF, or both.
  • all the CSCF servers (respectively, application servers) connected to the same primary HSS server switch to the same backup HSS server, so that the accuracy of the information stored on the HSS server (HSS primary in normal operation, or backup HSS due to a loss of connectivity of at least one of the CSCF servers or application servers) is guaranteed at all times.
  • said broadcasting device comprises said backup HSS server.
  • said broadcasting device comprises an SLF server.
  • IP networks comprising several HSS servers also include, in a conventional manner, an SLF server.
  • said broadcasting device comprises said server CSCF (respectively, application server) having detected a loss of connection.
  • the broadcast of the alert is directly provided by the server CSCF (respectively, application server) which has detected the loss of connection.
  • the present invention also relates, according to a second aspect adapted to a second network architecture, a method of failover of a primary HSS server on a backup HSS server in an IP network, said network comprising a plurality of CSCF servers (respectively, application servers) and a plurality of SLF servers providing a proxy function between said CSCF servers (respectively, application servers) on the one hand, and said primary and backup HSS servers on the other hand, wherein, following the detection of a loss of connection between one of said SLF servers and a primary HSS server to which it is normally connected, this SLF server connects to a HSS backup server.
  • the method is remarkable in that it also comprises the following steps:
  • said broadcast device sends, at least to the other SLF servers normally connected to said primary HSS, a predetermined failure message containing the reference of said primary HSS server, and
  • said broadcasting device comprises said backup HSS server.
  • said broadcasting device comprises said SLF server having detected a loss of connection. Thanks to these provisions, the broadcast of the alert is directly provided by the SLF server which detected the loss of connection.
  • the invention relates to various devices.
  • a broadcasting device for switching a primary HSS server on a backup HSS server in an IP network, said network comprising a plurality of CSCF servers (respectively, application servers).
  • Said device comprises means for, when detecting a connection loss between one of said CSCF servers (respectively, application servers) and a primary HSS server to which it is normally connected, and the connection of this server CSCF (respectively, application server) to a backup HSS server:
  • said broadcasting device comprises said backup HSS server.
  • said broadcasting device comprises an SLF server.
  • said broadcasting device comprises said server CSCF (respectively, application server) having detected a loss of connection.
  • the invention also relates, secondly, to a broadcast device for failover of a primary HSS server on a backup HSS server in an IP network, said network comprising a plurality of CSCF servers (respectively, application servers) and a plurality of SLF servers providing a proxy function between said CSCF servers (respectively, application servers) on the one hand, and said primary and backup HSS servers on the other hand.
  • Said device comprises means for detecting a loss of connection between one of said SLF servers and a primary HSS server to which it is normally connected, and connecting this SLF server to a backup HSS server:
  • said broadcasting device comprises said backup HSS server.
  • said broadcasting device comprises said SLF server having detected a loss of connection.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of any of the failover methods of a primary HSS on a backup HSS succinctly set forth above, when it is run on a computer.
  • the advantages offered by this computer program are essentially the same as those offered by said methods.
  • FIG. 1 schematically represents a general network for the provision of multimedia services capable of implementing the invention
  • FIG. 2 represents the loss of connection between a CSCF server and the primary HSS server to which it is normally connected, according to a first network architecture
  • FIG. 3 represents a first embodiment of the invention
  • FIG. 4 represents a second embodiment of the invention
  • FIG. 5 represents the loss of connection between a CSCF server and the primary HSS server to which it is normally connected, according to a second network architecture.
  • the system illustrated in Figure 1 is based on an IMS type network architecture, as briefly presented above.
  • the multimedia services offered by such a system may include telephony, video telephony, content-sharing, presence, instant messaging, or television services. These services are available to the UE user (for "User Equipmenf") on a network 20 comprising an IP transport infrastructure and servers through which the terminal 10 can exchange multimedia streams and services.
  • session control signals in accordance with the SIP protocol, in particular with another UE terminal 11, the terminals 10 and 11 having previously registered with the network 20.
  • the terminal 10, 11 is a fixed or mobile terminal, or a home or enterprise gateway, having SIP signaling means and may include means for restitution of audiovisual content.
  • this multimedia service delivery system relies on a network that conforms to the IMS architecture defined in the 3QPP, and which comprises:
  • this device manages in particular the procedure for registering the devices connected to the network 20; in fact, for such a device to benefit from the services provided by this network, this device must, with some exceptions (in the case of certain emergency calls), register with the server l / S-CSCF 22; the l / S-CSCF server 22 also manages the routing of the signaling between the terminal 10 and the voicemail servers VM 25, PS 26 presence and TAS telephony 27, as well as the routing towards other terminals managed by the same IMS network (as for example the terminal 11) and the routing of the signaling between this IMS network 20 and other networks (not shown);
  • P-CSCF server 21 • one (or more) P-CSCF server (initials of the words "Proxy-Call Server Control Function” meaning "Control Function of the Proxy Call Server”); the P-CSCF server 21
  • the SIP contact point of the terminal 10 (respectively, 11) in the IMS network is the SIP contact point of the terminal 10 (respectively, 11) in the IMS network; thus, all the SIP signaling exchanged between the terminal 10 (respectively, 11) and the call server l / S-CSCF 22 passes through this server P-CSCF 21 (respectively, 28); • one or more database servers, of the HSS (for "Home Subscriber Server") type; an HSS server, designated H in Figure 1, contains the user profile of the terminal 10 in terms of authentication data, location and subscribed services; Optionally, a server of the SLF type (for "Subscriber Location Function"); an SLF server, designated F in FIG.
  • this SLF server F is interrogated by the functions I-CSCF and S-CSCF to find the address of the HSS H server hosting the data concerning the user of the terminal 10; the HSS servers and the SLF F server communicate with each other by means of the "DIAMETEP" protocol. (see IETF RFC 3588), which provides authentication, authorization and accounting functions;
  • One (or more) VM 25 voicemail server (s); the server VM 25 manages the subscription of the terminal 10 to the events of posting / viewing of the messages of the user of this terminal, and notifies the terminal 10 during the occurrence of these events;
  • the server PS 26 manages the subscription of the terminal 10 to the presence events that the user of this terminal wishes to monitor, and notifies the terminal at the occurrence of these events;
  • TAS 27 telephony server manages the telephone services to which the user of the terminal 10 has subscribed with his operator, such as the presentation of the number or the call forwarding.
  • the VM 25 voicemail servers, the PS presence servers 26 and the TAS telephony servers 27 are examples of so-called “application servers” (AS).
  • AS application servers
  • the HSS H database server is contacted:
  • the S-CSCF function during the initial registration of the terminal 10 in order to download the data relating to the services subscribed by this user, in particular the detection points which will enable the l / S-CSCF server to determine which message of signaling it must route to which application server AS (such as VM 25, PS 26 or TAS 27);
  • FIG. 2 The technical problem addressed by the present invention is illustrated in FIG. 2 as part of an exemplary network architecture.
  • FIG. 2 represents, schematically, two CSCF servers C1 and C2 each hosting, indifferently, an S-CSCF function, l-CSCF or both.
  • These CSCF servers C1 and C2 are both connected to a primary HSS server H, for which there is provided a HSS server of relief ⁇ '.
  • the CSCF servers C1 and C2 are both connected to an SLF server F.
  • the CSCF C2 switches to the HSS server H '. But if the connection between the HSS H and the CSCF server C1 then continues to work, the latter does not switch to the HSS server H '.
  • the data subsequently recorded on the servers H and H ' will therefore become inconsistent, so that the processing of the services rendered to the customers can deteriorate sharply (incoming calls sent on voice mail despite the availability of the recipient of the calls, and so on) .
  • FIG. 3 illustrates a first embodiment of the method according to the invention. The steps of this method are essentially as follows.
  • step E1 the CSCF server C2 finds that H is unreachable.
  • step E2 the server C2 informs the backup HSS server H 'by means of a DIAMETER message, preferably other than one of those used to monitor the DWR link ("Device-Watchdog-Request"), that H is unreachable, this DIAMETER message can be either a new message or a new AVP ("Attribute-Value Fact") in an existing DIAMETER message.
  • step E3 the server H 'informs all the CSCF servers connected to it (here, C1) that the server H is unreachable, in broadcasting a new DIAMETER message (or an existing message with a new AVP).
  • step E4 on receiving this message, the CSCFs (here, C1) having the same primary HSS H switch to the backup HSS H '.
  • FIG. 4 illustrates a second embodiment of the method according to the invention. The steps of this method are essentially as follows.
  • step E1 the CSCF server C2 finds that H is unreachable.
  • step E2 the server C2 informs the SLF server F by means of a DIAMETER message, preferably other than one of those used for the supervision of the DWR link, that H is unreachable; this DIAMETER message can be either a new message or a new AVP in an existing DIAMETER message.
  • step E3 the SLF server F broadcasts a new DIAMETER message (or an existing message with a new AVP), containing the information that H is unreachable to the set of CSCFs.
  • this diffusion is only intended for CSCFs having exactly H in primary HSS and H 'in HSS as backup; in fact, the SLF server having the knowledge of the primary HSS / HSS backup profiles, it is possible for it to make a targeted distribution.
  • step E4 on receiving this message, the CSCFs (here, C1) having the same primary HSS H switch to the backup HSS H '.
  • step E1 the CSCF server C2 finds that H is unreachable.
  • step E2 the server C2 informs all other CSCF servers of the IMS network that it has just switched to a backup HSS, specifying the reference (H) of the primary HSS and ( ⁇ ') of the backup HSS; this information can be broadcast either in a new specific request or in a new SIP header within an existing request, such as "NOTIFY".
  • step E3 upon receipt of this message, the CSCFs (here,
  • this broadcast is only addressed to CSCFs having exactly H as the primary HSS, so as to avoid a generalized broadcast on all the other CSCF servers of the IMS network.
  • the implementation of this variant assumes that each CSCF server is configured to know which other CSCF servers have the same primary HSS server as itself; However, such a solution is impractical because it involves frequent configuration changes during network refittings.
  • This figure 5 corresponds to a network architecture in which several SLF servers (here F1 and F2) operate in load sharing, and provide a proxy server function between the CSCF servers and the HSS servers. uses such a structure, it must be ensured that the SLF servers share with each other the information relating to the possible switching of one of them (here, F1) on the backup HSS server H ', so that the other SLF (here, F2) then also switches to the server H '.
  • F1 and F2 the information relating to the possible switching of one of them
  • step E1 the SLF server F1 finds that H is unreachable.
  • the server F1 informs the other SLF servers (here, F2) of the IMS network with which it is in load sharing that it has just switched to the backup HSS H '; this information can be broadcast in a DIAMETER message, preferably other than one of those used to monitor the DWR link; this DIAMETER message can be either a new message or a new AVP in an existing DIAMETER message.
  • step E3 on receiving this message, these other SLF servers (here, F2) switch from the primary HSS server H to the backup HSS H '.
  • step E1 the SLF server F1 finds that H is unreachable.
  • step E2 the server F1 informs the backup HSS server H 'by means of a DIAMETER message, preferably other than one of those used for the supervision of the DWR link, that H is unreachable; this DIAMETER message can be either a new message or a new AVP in an existing DIAMETER message.
  • step E3 the server H 'informs all of the SLF servers connected to it (here, F2) that the server H is unreachable, by broadcasting a new message DIAMETER (or an existing message with a new AVP).
  • step E4 upon receipt of this message, the SLF servers (here, F2) having the same primary HSS H switch to the backup HSS H '.
  • the implementation of the invention within the nodes of the telecommunications network can be realized by means of software components and / or materials.
  • the software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system can be used to execute a computer program comprising instructions for implementing the method of switching a primary HSS on a backup HSS according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for performing the steps of a method of switching a primary HSS on a backup HSS according to the invention, when it is run on a computer.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • 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 another desirable form.
  • 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 means magnetic recording, for example a diskette ("floppy disc” in English) or a hard disk.
  • 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 computer program according to the invention can in particular be downloaded to 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 switching method of a primary HSS on a backup HSS according to the invention. 'invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) (C1, C2), dans lequel, suite à la détection d'une perte de connexion entre l'un desdits serveurs CSCF (respectivement, serveurs d'applications) (C2) et un serveur HSS primaire (H) auquel il est normalement connecté, ce serveur CSCF (respectivement, serveur d'applications) (C2) se connecte à un serveur HSS de secours (H'). Ce procédé comprend également les étapes suivantes : a) un dispositif de diffusion prédéterminé est informé de ladite perte de connexion avec ledit serveur HSS (H); b) ledit dispositif de diffusion envoie, au moins aux autres serveurs CSCF (respectivement, serveurs d'applications) (C1) normalement connectés audit HSS primaire (H)1 un message de panne prédéterminé contenant la référence dudit serveur HSS primaire (H); et c) lesdits autres serveurs CSCF (respectivement, serveurs d'applications) C1 se connectent audit serveur HSS de secours (H').

Description

PROCEDE DE BASCULEMENT D'UN HSS PRIMAIRE
SUR UN HSS DE SECOURS DANS UN RESEAU IP
La présente invention concerne les réseaux IP {"Internet Protocol"), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, tels que "Voix sur IP" (VoIP), "Partage de Contenu", "Présence", ou "Messagerie Instantanée".
Plus particulièrement, la présente invention concerne la cohérence des informations-clients enregistrées dans un tel réseau, et donc la cohérence dans le traitement par le réseau des données conversationnelles relatives à ces clients.
Les dispositifs clients à qui de telles ressources sont accessibles peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique ou située dans une entreprise (" Residential Gateway en anglais), ou encore une passerelle d'opérateur réseau (" Voice Gateway" en anglais) telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais "Digital Subscriber Une Access Multiplexer" signifiant "multiplexeur d'accès de lignes d'abonnés numériques" ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques).
Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais "Session Initiation Protocol" signifiant "Protocole d'Initiation de Session"), utilisent des messages dits "de signalisation", qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF dans le document RFC 3261. Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP permet également des procédures de notification d'événements et l'envoi d'informations en dehors du contexte d'une session. Il est largement utilisé pour des commandes de services de messagerie instantanée. Ainsi, dans un environnement SIP, il existe différents types de communications telles que des requêtes d'établissement de sessions et des requêtes échangées hors de tout dialogue.
L'invention convient bien en particulier aux infrastructures de type IMS ("IP Multimedia Subsystem"). L'IMS a été défini par les organismes de normalisation 3GPP ("3rd Génération Partnership Project) et TISPAN (" Télécommunications and Internet Converged Services and Protocols for Advanced Networking"). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture, qui utilise le protocole SIP, permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en oeuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, présence et messagerie instantanée, dont elle gère aussi l'interaction.
Lorsqu'un utilisateur souhaite bénéficier des services offerts par un réseau IP tel que ceux décrits ci-dessus, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes. Tout d'abord, le terminal de l'utilisateur doit s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du terminal pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le terminal de l'utilisateur doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement.
Pour pouvoir donc enregistrer les clients, les réseaux IP tels que décrits ci-dessus comprennent un ou plusieurs serveurs, généralement appelés "S-CSCF" (initiales des mots anglais "Serving-CalI Server Control Function" signifiant "Fonction de Contrôle du Serveur d'Appels de Service"), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.
En outre, ces réseaux comprennent un ou plusieurs serveurs, généralement appelés "l-CSCF" (initiales des mots anglais "Interrogating- Call Server Control Function" signifiant "Fonction de Contrôle du Serveur d'Appels d'Interrogation") qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur appelé "HSS" (initiales des mots anglais "Home Subscriber Server" signifiant "Serveur d'Abonné Nominal") pour pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par ce client.
En effet, chaque dispositif-client peut, après qu'un serveur S-CSCF lui ait été ainsi attribué, envoyer une requête de souscription à certains services pour la connexion en cours. Il peut s'agir d'un service de notification d'événement : par exemple, lorsque l'utilisateur d'un terminal dispose d'une boîte vocale sur le réseau, ce terminal peut souscrire à une notification de dépôt de message, c'est-à-dire qu'il peut demander à être informé chaque fois qu'un message a été enregistré sur cette boîte vocafe ; le terminai de l'utilisateur peut, de même, demander à être notifié de son état d'enregistrement ; il peut également souscrire à un service de notification de présence, qui lui permet de recevoir des informations publiées par un autre utilisateur qu'il a désigné, et ainsi de suite. Après la requête de souscription initiale, le terminal doit envoyer périodiquement au réseau une requête pour renouveler sa souscription.
Les serveurs S-CSCF, mentionnés ci-dessus, contribuent à la mise en œuvre de ces divers services en gérant le routage de la signalisation, d'une part, entre chaque dispositif-client et les serveurs du réseau spécialisés dans la mise en œuvre de tel ou tel service souscrit par le client, et d'autre part en direction d'autres clients gérés par le même réseau ou par un réseau qui lui est relié.
Pour pouvoir acheminer ces diverses requêtes au sein du réseau, les serveurs de type l-CSCF ou de type S-CSCF (d'ailleurs souvent combinés en un même serveur, dénoté l/S-CSCF) échangent des informations avec un ou plusieurs serveur(s) de type HSS mentionné ci- dessus. Les serveurs HSS contiennent chacun une base de données- clients, et sont donc l'équivalent dans les réseaux IP des serveurs "HLR" (initiales des mots anglais "Home Location Register" signifiant "Registre de Localisation Nominal") utilisés dans les réseaux GSM. Chaque serveur HSS contient le "profil" d'un certain nombre de clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits.
Les serveurs HSS jouent donc un rôle capital dans le fonctionnement d'un tel réseau, et l'exactitude des informations dynamiques qu'ils contiennent est essentielle pour le bon fonctionnement du réseau. C'est pourquoi il est généralement prévu d'associer à chaque HSS "normal" ("primaire") un HSS "de secours" ("secondaire") destiné à remplacer le HSS primaire au cas où ce dernier tombe en panne. Mais une telle disposition entraîne, comme s'en sont rendu compte les auteurs de la présente invention, un réel danger quant à la cohérence dans le traitement par le réseau des informations relatives aux clients.
Voici un exemple élémentaire d'incohérence causée par le basculement sur un HSS de secours dans un réseau comprenant plusieurs serveurs (ou fonctions) l-CSCF et plusieurs serveurs (ou fonctions) S-CSCF. On notera que dans un tel réseau les appels entrants à partir du Réseau Public Téléphonique Commuté (RPTC) (en anglais, "Public Switched Téléphone Network" ou PSTN) sont habituellement distribués de manière équitable sur l'ensemble des serveurs l-CSCF ; ceux-ci interrogent alors le serveur HSS pour déterminer vers que) serveur S-CSCF il faut router chaque appel entrant.
Supposons à présent que la connexion entre un certain serveur I- CSCF (appelons-le "serveur C2", hébergeant aussi un serveur S-CSCF) et le serveur HSS primaire tombe en panne, de sorte que ce serveur C2 bascule sur le serveur HSS de secours. Le serveur HSS de secours est alors informé par le serveur C2 à chaque fois qu'un client s'enregistre subséquemment sur le réseau via le serveur C2. Si à présent un appel entrant à destination de l'un de ces clients nouvellement enregistré sur le HSS de secours est confié au serveur C2, l'appel sera traité correctement puisque le serveur C2 interrogera le HSS de secours pour déterminer quel est le S-CSCF en charge de ce client. En revanche, si un appel pour ce même client est confié à un serveur (appelons-le "serveur C1 ", hébergeant également un serveur S-CSCF) autre que le serveur C2, et qui n'a, quant à lui, pas perdu sa connectivité avec le serveur HSS primaire, alors l'interrogation de ce serveur HSS primaire par le serveur C1 aboutira à la conclusion erronée que le client concerné n'est pas enregistré, de sorte que l'appel sera routé vers la boîte vocale du client au lieu de lui être transmis directement. Comme expliqué en détail ci-dessous, ce problème affectant les serveurs CSCF affecte également les serveurs dits "serveurs d'applications" ("application servers" ou AS en anglais), tels que les serveurs de messagerie vocale, les serveurs de présence et les serveurs de téléphonie, car ces serveurs AS doivent consulter un serveur HSS lors du dépôt ou de la récupération de données de services.
Or, dans les réseaux IP selon l'état de l'art, les incohérences mentionnées ci-dessus ne disparaissent que lors d'un redémarrage global du réseau, car les problèmes posés par le basculement sur un serveur HSS de secours ne sont pas pris en compte.
La présente invention concerne donc, selon un premier aspect adapté à une première architecture de réseau, un procédé de basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications), dans lequel, suite à la détection d'une perte de connexion entre l'un desdits serveurs CSCF (respectivement, serveurs d'applications) et un serveur HSS primaire auquel il est normalement connecté, ce serveur CSCF (respectivement, serveur d'applications) se connecte à un serveur HSS de secours. Ledit procédé est remarquable en ce qu'il comprend également les étapes suivantes :
a) un dispositif de diffusion prédéterminé est informé de ladite perte de connexion avec ledit serveur HSS,
b) ledit dispositif de diffusion envoie, au moins aux autres serveurs CSCF (respectivement, serveurs d'applications) normalement connectés audit HSS primaire, un message de panne prédéterminé contenant la référence dudit serveur HSS primaire, et
c) lesdits autres serveurs CSCF (respectivement, serveurs d'applications) se connectent audit serveur HSS de secours. On notera que ledit serveur CSCF peut héberger indifféremment une fonction S-CSCF, ou une fonction l-CSCF, ou encore les deux.
Grâce à ces dispositions, tous les serveurs CSCF (respectivement, serveurs d'applications) reliés à un même serveur HSS primaire basculent sur un même serveur HSS de secours, de sorte que l'exactitude des informations enregistrées sur le serveur HSS (HSS primaire en fonctionnement normal, ou HSS de secours suite à une perte de connectivité de l'un au moins des serveurs CSCF ou serveurs d'applications) est garantie en permanence.
Selon des caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur HSS de secours.
Grâce à ces dispositions, c'est le serveur HSS de secours lui- même qui, avantageusement, alerte les serveurs CSCF (respectivement, serveurs d'applications) concernés.
Selon d'autres caractéristiques particulières, ledit dispositif de diffusion comprend un serveur SLF.
Grâce à ces dispositions, la diffusion de l'alerte est avantageusement assurée par un serveur SLF (initiales des mots anglais "Subscriber Location Function" signifiant "Fonction de Localisation d'Abonné"). En effet, les réseaux IP comprenant plusieurs serveurs HSS comprennent également, de manière classique, un serveur SLF.
Selon encore d'autres caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur CSCF (respectivement, serveur d'applications) ayant détecté une perte de connexion.
Grâce à ces dispositions, la diffusion de l'alerte est directement assurée par le serveur CSCF (respectivement, serveur d'applications) qui a détecté la perte de connexion.
La présente invention concerne également, selon un deuxième aspect adapté à une deuxième architecture de réseau, un procédé de basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) et une pluralité de serveurs SLF assurant une fonction de mandataire entre lesdits serveurs CSCF (respectivement, serveurs d'applications) d'une part, et lesdits serveurs HSS primaire et de secours d'autre part, dans lequel, suite à la détection d'une perte de connexion entre l'un desdits serveurs SLF et un serveur HSS primaire auquel il est normalement connecté, ce serveur SLF se connecte à un serveur HSS de secours. Ledit procédé est remarquable en ce qu'il comprend également les étapes suivantes :
a) un dispositif de diffusion prédéterminé est informé de ladite perte de connexion avec ledit serveur HSS,
b) ledit dispositif de diffusion envoie, au moins aux autres serveurs SLF normalement connectés audit HSS primaire, un message de panne prédéterminé contenant la référence dudit serveur HSS primaire, et
c) lesdits autres serveurs SLF se connectent audit serveur HSS de secours.
Grâce à ces dispositions, tous les serveurs SLF reliés à un même serveur HSS primaire basculent sur un même serveur HSS de secours, de sorte que l'exactitude des informations enregistrées sur le serveur HSS (HSS primaire en fonctionnement normal, ou HSS de secours suite à une perte de connectivité de l'un au moins des serveurs SLF) est garantie en permanence.
Selon des caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur HSS de secours.
Grâce à ces dispositions, c'est le serveur HSS de secours lui- même qui, avantageusement, alerte les SLF concernés.
Selon d'autres caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur SLF ayant détecté une perte de connexion. Grâce à ces dispositions, la diffusion de l'alerte est directement assurée par le serveur SLF qui a détecté la perte de connexion.
Corrélativement, l'invention concerne divers dispositifs.
Elfe concerne ainsi, premièrement, un dispositif de diffusion pour le basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications). Ledit dispositif comprend des moyens pour, lors de la détection d'une perte de connexion entre l'un desdits serveurs CSCF (respectivement, serveurs d'applications) et un serveur HSS primaire auquel il est normalement connecté, et de la connexion de ce serveur CSCF (respectivement, serveur d'applications) à un serveur HSS de secours :
a) recevoir l'information de ladite perte de connexion avec ledit serveur HSS, et
b) envoyer, au moins aux autres serveurs CSCF (respectivement, serveurs d'applications) normalement connectés audit HSS primaire, un message de panne prédéterminé contenant la référence dudit serveur HSS primaire.
Selon des caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur HSS de secours.
Selon d'autres caractéristiques particulières, ledit dispositif de diffusion comprend un serveur SLF.
Selon encore d'autres caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur CSCF (respectivement, serveur d'applications) ayant détecté une perte de connexion.
L'invention concerne aussi, deuxièmement, un dispositif de diffusion pour le basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) et une pluralité de serveurs SLF assurant une fonction de mandataire entre lesdits serveurs CSCF (respectivement, serveurs d'applications) d'une part, et lesdits serveurs HSS primaire et de secours d'autre part. Ledit dispositif comprend des moyens pour, lors de la détection d'une perte de connexion entre l'un desdits serveurs SLF et un serveur HSS primaire auquel il est normalement connecté, et de ia connexion de ce serveur SLF à un serveur HSS de secours :
a) recevoir l'information de ladite perte de connexion avec ledit serveur HSS, et
b) envoyer, au moins aux autres serveurs SLF normalement connectés audit HSS primaire, un message de panne prédéterminé contenant la référence dudit serveur HSS primaire.
Selon des caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur HSS de secours.
Selon d'autres caractéristiques particulières, ledit dispositif de diffusion comprend ledit serveur SLF ayant détecté une perte de connexion.
Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.
On notera qu'il est possible de réaliser les dispositifs succinctement décrits ci-dessus dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de basculement d'un HSS primaire sur un HSS de secours succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur. Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se' réfère aux figures qui l'accompagnent, dans lesquelles :
- la figure 1 représente schématiquement un réseau général pour la fourniture de services multimédia apte à mettre en œuvre l'invention,
- la figure 2 représente la perte de connexion entre un serveur CSCF et le serveur HSS primaire auquel il est normalement connecté, selon une première architecture de réseau,
- la figure 3 représente un premier mode de réalisation de l'invention,
- la figure 4 représente un deuxième mode de réalisation de l'invention, et
- la figure 5 représente la perte de connexion entre un serveur CSCF et le serveur HSS primaire auquel il est normalement connecté, selon une deuxième architecture de réseau.
Le système illustré sur la figure 1 est fondé sur une architecture de réseau de type IMS, tel que présenté succinctement ci-dessus. Les services multimédia offerts par un tel système peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu {"content-sharing" en anglais), de présence, de messagerie instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un terminal UE (pour "User Equipmenf en anglais) 10 sur un réseau 20 comprenant une infrastructure de transport IP et des serveurs à travers lesquels le terminal 10 peut échanger des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, notamment avec un autre terminal UE 11 , les terminaux 10 et 11 s'étant au préalable enregistrés auprès du réseau 20. Le terminal 10, 11 est un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel.
Comme le montre la figure 1 , ce système de fourniture de services multimédia s'appuie sur un réseau 20 conforme à l'architecture IMS définie au 3QPP, et qui comprend :
• une infrastructure de transport IP (non représentée) ;
• un ou plusieurs serveurs d'appel l/S-CSCF (pour la combinaison d'une fonction " Interrogating-Call Server Control Function" et d'une fonction "Serving-Call Server Control Function" dans le même serveur) ; un serveur d'appel l/S-CSCF, désigné par 22 sur la figure 1 , gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 20 ; en effet, pour qu'un tel dispositif puisse bénéficier des services fournis par ce réseau, ce dispositif doit, sauf exceptions (cas de certains appels d'urgence), s'enregistrer auprès du serveur l/S-CSCF 22 ; le serveur l/S-CSCF 22 gère également le routage de la signalisation entre le terminal 10 et les serveurs de messagerie vocale VM 25, de présence PS 26 et de téléphonie TAS 27, ainsi que le routage en direction d'autres terminaux gérés par le même réseau IMS (comme par exemple le terminal 11) et le routage de la signalisation entre ce réseau IMS 20 et d'autres réseaux (non- représentés) ;
• un (ou plusieurs) serveur(s) P-CSCF (initiales des mots anglais "Proxy-Call Server Control Function" signifiant "Fonction de Contrôle du Serveur d'Appels Mandataire") ; le serveur P-CSCF 21
(respectivement, 28) est le point de contact SIP du terminal 10 (respectivement, 11) dans le réseau IMS ; ainsi, toute la signalisation SIP échangée entre le terminal 10 (respectivement, 11) et le serveur d'appel l/S-CSCF 22 passe par ce serveur P-CSCF 21 (respectivement, 28) ; • un ou plusieurs serveurs de base de données, de type HSS (pour "Home Subscriber Server") ; un serveur HSS, désigné par H sur la figure 1 , contient le profil de l'utilisateur du terminal 10 en termes de données d'authentification, de localisation et de services souscrits ; · optionnellement, un serveur de type SLF (pour "Subscriber Location Function") ; un serveur SLF, désigné par F sur la figure 1 , est utilisé dans les réseaux IP comprenant plusieurs serveurs HSS ; plus précisément, ce serveur SLF F est interrogé par les fonctions I- CSCF et S-CSCF pour trouver l'adresse du serveur HSS H hébergeant les données concernant l'utilisateur du terminal 10 ; les serveurs HSS et le serveur SLF F communiquent entre eux au moyen du protocole "DIAMETEP." (cf. document RFC 3588 de l'IETF), qui assure des fonctions d'authentification, d'autorisation et de comptabilité ;
· un (ou plusieurs) serveur(s) de messagerie vocale VM 25 ; le serveur VM 25 gère la souscription du terminal 10 aux événements de dépôt/consultation des messages de l'utilisateur de ce terminal, et notifie le terminal 10 lors de l'occurrence de ces événements ;
• un (ou plusieurs) serveur(s) de présence PS 26 ; le serveur PS 26 gère la souscription du terminal 10 aux événements de présence que l'utilisateur de ce terminal souhaite surveiller, et notifie le terminal lors de l'occurrence de ces événements ; et
• un (ou plusieurs) serveur(s) de téléphonie TAS 27 ; un serveur TAS gère (es services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou (e renvoi d'appel.
Les serveurs de messagerie vocale VM 25, les serveurs de présence PS 26 et les serveurs de téléphonie TAS 27 sont des exemples de ce que l'on appelle des "serveurs d'applications" {"application servers" ou AS en anglais). Le serveur de base de données HSS H est notamment contacté :
• par la fonction l-CSCF lors de l'enregistrement du terminal 10 afin d'allouer un serveur S-CSCF à l'utilisateur de ce terminal ou de retrouver le serveur S-CSCF déjà alloué à cet utilisateur ;
• par la fonction S-CSCF lors de l'enregistrement initial du terminal 10 afin de télécharger les données concernant ies services' souscrits par cet utilisateur, dont notamment les points de détection qui permettront au serveur l/S-CSCF de déterminer quel message de signalisation il doit acheminer vers quel serveur d'application AS (comme par exemple le VM 25, le PS 26 ou le TAS 27) ;
• par la fonction S-CSCF lors des enregistrements de l'utilisateur du terminal 10, afin d'informer le serveur HSS H de l'installation ou de la prolongation d'un enregistrement de cet utilisateur sur le serveur l/S- CSCF ;
• par la fonction S-CSCF, afin de récupérer les informations nécessaires à l'authentification de la signalisation émise par l'utilisateur du terminal 10 ;
• par la fonction l-CSCF lors de la réception d'un appel, afin de récupérer les coordonnées du serveur l/S-CSCF en charge de l'abonné destinataire de cet appel ; et
• par des serveurs d'application AS lors du dépôt ou de la récupération de données de services.
Le problème technique visé par la présente invention est illustré sur la figure 2 dans le cadre d'une architecture de réseau donnée à titre d'exemple.
La figure 2 représente, schématiquement, deux serveurs CSCF C1 et C2 hébergeant chacun, indifféremment, une fonction S-CSCF, l-CSCF ou les deux. Ces serveurs CSCF C1 et C2 sont tous deux connectés à un serveur HSS primaire H, pour lequel il est prévu un serveur HSS de secours Η'. Enfin, les serveurs CSCF C1 et C2 sont tous deux connectés à un serveur SLF F.
Si, par exemple, la connexion entre le serveur HSS H et le CSCF C2 tombe en panne, le CSCF C2 bascule sur le serveur HSS H'. Mais si la connexion entre le HSS H et le serveur CSCF C1 continue alors à fonctionner, ce dernier ne bascule pas sur le serveur HSS H'. Les données enregistrées subséquemment sur les serveurs H et H' vont donc devenir incohérentes, de sorte que le traitement des services rendus aux clients peut se dégrader fortement (appels entrants envoyés sur boîte vocale malgré la disponibilité du destinataire des appels, et ainsi de suite).
Le problème affectant les serveurs CSCF affecte évidemment les serveurs d'application AS de la même façon, et par conséquent tous les exemples ci-dessus et les modes de réalisation ci-dessous décrits, pour fixer les idées, en référence à des serveurs CSCF s'appliquent tout aussi bien aux serveurs AS.
On va maintenant illustrer le fonctionnement et les avantages de la présente invention au moyen de divers modes de réalisation.
La figure 3 illustre un premier mode de réalisation du procédé selon l'invention. Les étapes de ce procédé sont essentiellement les suivantes.
A l'étape E1, le serveur CSCF C2 constate que H est injoignable.
A l'étape E2, le serveur C2 informe le serveur HSS de secours H' au moyen d'un message DIAMETER, de préférence autre que l'un de ceux servant à la supervision du lien DWR {"Device-Watchdog-Request), que H est injoignable ; ce message DIAMETER peut être soit un nouveau message, soit un nouvel AVP ("Attribute-Value Fait") dans un message DIAMETER existant.
A l'étape E3, le serveur H' informe l'ensemble des serveurs CSCF qui lui sont raccordés (ici, C1) que le serveur H est Injoignable, en diffusant un nouveau message DIAMETER (ou un message existant avec un nouvel AVP).
Enfin, à l'étape E4, sur réception de ce message, les CSCF (ici, C1) ayant le même HSS primaire H basculent sur le HSS de secours H'.
La figure 4 illustre un deuxième mode de réalisation du procédé selon l'invention. Les étapes de ce procédé sont essentiellement les suivantes.
A l'étape E1, le serveur CSCF C2 constate que H est Injoignable.
A l'étape E2, le serveur C2 informe le serveur SLF F au moyen d'un message DIAMETER, de préférence autre que l'un de ceux servant à la supervision du lien DWR, que H est injoignable ; ce message DIAMETER peut être soit un nouveau message, soit un nouvel AVP dans un message DIAMETER existant.
A l'étape E3, le serveur SLF F diffuse un nouveau message DIAMETER (ou un message existant avec un nouvel AVP), contenant l'information selon laquelle H est injoignable vers l'ensemble des CSCF. En variante, cette diffusion ne s'adresse qu'aux CSCF ayant exactement H en HSS primaire et H' en HSS de secours ; en effet, le serveur SLF ayant la connaissance des profils HSS primaire/HSS de secours, il lui est possible de faire une diffusion ciblée.
Enfin, à l'étape E4, sur réception de ce message, les CSCF (ici, C1) ayant le même HSS primaire H basculent sur le HSS de secours H'.
On va décrire à présent un troisième mode de réalisation (non représenté sur les figures) du procédé selon l'invention. Les étapes de ce procédé qui, pour la transmission de l'instruction de basculement, utilise le protocole SIP et les interfaces "Mw" (interfaces SIP entre les serveurs I- CSCF, P-CSCF et S-CSCF), sont essentiellement les suivantes.
A l'étape E1, le serveur CSCF C2 constate que H est injoignable.
A l'étape E2, le serveur C2 informe tous les autres serveurs CSCF du réseau IMS qu'il vient de basculer sur un HSS de secours, en précisant la référence (H) du HSS primaire et (Η') du HSS de secours ; cette information peut être diffusée soit dans une nouvelle requête spécifique, soit dans un nouveau header SIP à l'intérieur d'une requête existante, telle que "NOTIFY".
Enfin, à l'étape E3, sur réception de ce message, les CSCF (ici,
C1) ayant le même HSS primaire H basculent sur le HSS de secours H'.
En variante, cette diffusion ne s'adresse qu'aux CSCF ayant exactement H comme HSS primaire, de manière à éviter une diffusion généralisée sur tous les autres serveurs CSCF du réseau IMS. Mais la mise en œuvre de cette variante suppose toutefois que chaque serveur CSCF est configuré de manière à savoir quels autres serveurs CSCF ont le même serveur HSS primaire que lui ; or une telle solution est peu pratique car qu'elle implique des modifications de configuration fréquentes lors de réaménagements du réseau.
On notera que l'invention n'est pas nécessairement mise en œuvre dans une architecture de réseau du type représenté sur les figures 2, 3 et
4. En effet, l'invention peut être mise en œuvre dans d'autres structures, par exemple celle représentée sur la figure 5.
Cette figure 5 correspond à une architecture de réseau dans laquelle plusieurs serveurs SLF (ici F1 et F2) fonctionnent en partage de charge, et assurent une fonction de mandataire {"proxy server) entre les serveurs CSCF et les serveurs HSS. Si l'on utilise une telle structure, il faut veiller à ce que les serveurs SLF partagent entre eux les informations relatives au basculement éventuel de l'un d'entre eux (ici, F1) sur le serveur HSS de secours H', de manière à ce que l'autre SLF (ici, F2) bascule alors lui aussi sur le serveur H'.
On va décrire à présent un quatrième mode de réalisation du procédé selon l'invention, adapté à l'architecture représentée sur la figure
5. Les étapes de ce procédé sont essentiellement les suivantes.
A l'étape E1 , le serveur SLF F1 constate que H est injoignable. A l'étape E2, le serveur F1 informe les autres serveurs SLF (ici, F2) du réseau IMS avec qui il est en partage de charge qu'il vient de basculer sur le HSS de secours H' ; cette information peut être diffusée dans un message DIAMETER, de préférence autre que l'un de ceux servant à la supervision du lien DWR ; ce message DIAMETER peut être soit un nouveau message, soit un nouvel AVP dans un message DIAMETER existant.
Enfin, à l'étape E3, sur réception de ce message, ces autres serveurs SLF (ici, F2) basculent du serveur HSS primaire H sur le HSS de secours H'.
On va décrire, enfin, un cinquième mode de réalisation du procédé selon l'invention, lui aussi adapté à l'architecture représentée sur la figure 5. Les étapes de ce procédé sont essentiellement les suivantes.
A l'étape E1 , le serveur SLF F1 constate que H est injoignable. A l'étape E2, le serveur F1 informe le serveur HSS de secours H' au moyen d'un message DIAMETER, de préférence autre que l'un de ceux servant à la supervision du lien DWR, que H est injoignable ; ce message DIAMETER peut être soit un nouveau message, soit un nouvel AVP dans un message DIAMETER existant.
A l'étape E3, le serveur H' informe l'ensemble des serveurs SLF qui lui sont raccordés (ici, F2) que le serveur H est injoignable, en diffusant un nouveau message DIAMETER (ou un message existant avec un nouvel AVP).
Enfin, à l'étape E4, sur réception de ce message, les serveurs SLF (ici, F2) ayant le même HSS primaire H basculent sur le HSS de secours H'.
La mise en œuvre de l'invention au sein des nœuds du réseau de télécommunications (plus précisément, les serveurs de type HSS, CSCF, SLF et AS dans les modes de réalisation décrits ci-dessus) peut être réalisée au moyen de composants logiciels et/ou matériels. Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de basculement d'un HSS primaire sur un HSS de secours selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de basculement d'un HSS primaire sur un HSS de secours selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.
Ce programme peut utiliser n'importe quel langage de programmation, et se présenter 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 disc" en anglais) 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 d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, 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é de basculement d'un HSS primaire sur un HSS de secours selon l'invention.

Claims

R E V E N D I C A T I O N S
1. Procédé de basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) (C1, C2), dans lequel, suite à la détection d'une perte de connexion entre l'un desdits serveurs CSCF (respectivement, serveurs d'applications) (C2) et un serveur HSS primaire (H) auquel il est normalement connecté, ce serveur CSCF (respectivement, serveur d'applications) (C2) se connecte à un serveur HSS de secours (H'), caractérisé en ce qu'il comprend également les étapes suivantes :
a) un dispositif de diffusion prédéterminé est informé de ladite perte de connexion avec ledit serveur HSS (H),
b) ledit dispositif de diffusion envoie, au moins aux autres serveurs CSCF (respectivement, serveurs d'applications) (C1) normalement connectés audit HSS primaire (H), un message de panne prédéterminé contenant la référence dudit serveur HSS primaire (H), et
c) lesdits autres serveurs CSCF (respectivement, serveurs d'applications) (C1) se connectent audit serveur HSS de secours (Η').
2. Procédé de basculement selon la revendication 1 , caractérisé en ce que ledit dispositif de diffusion comprend ledit serveur HSS de secours (Η').
3. Procédé de basculement selon la revendication 1 , caractérisé en ce que ledit dispositif de diffusion comprend un serveur SLF (" Subscriber Location Function") (F).
4. Procédé de basculement selon la revendication 1, caractérisé en ce que ledit dispositif de diffusion comprend ledit serveur CSCF (respectivement, serveur d'applications) (C2) ayant détecté une perte de connexion.
5. Procédé de basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) (C1, C2) et une pluralité de serveurs SLF (F1, F2) assurant une fonction de mandataire entre lesdits serveurs CSCF (respectivement, serveurs d'applications) d'une part, et lesdits serveurs HSS primaire et de secours d'autre part, dans lequel, suite à la détection d'une perte de connexion entre l'un desdits serveurs SLF (F1) et un serveur HSS primaire (H) auquel il est normalement connecté, ce serveur SLF (F1) se connecte à un serveur HSS de secours (H'), caractérisé en ce qu'il comprend également les étapes suivantes :
a) un dispositif de diffusion prédéterminé est informé de ladite perte de connexion avec ledit serveur HSS (H),
b) ledit dispositif de diffusion envoie, au moins aux autres serveurs SLF (F2) normalement connectés audit HSS primaire (H), un message de panne prédéterminé contenant la référence dudit serveur HSS primaire (H), et
c) lesdits autres serveurs SLF (F2) se connectent audit serveur HSS de secours (H').
6. Procédé de basculement selon la revendication 5, caractérisé en ce que ledit dispositif de diffusion comprend ledit serveur HSS de secours (H').
7. Procédé de basculement selon la revendication 5, caractérisé en ce que ledit dispositif de diffusion comprend ledit serveur SLF (F1) ayant détecté une perte de connexion.
8. Dispositif de diffusion pour te basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) (C1, C2), ledit dispositif comprenant des moyens pour, lors de la détection d'une perte de connexion entre l'un desdits serveurs CSCF (respectivement, serveurs d'applications) (C2) et un serveur HSS primaire (H) auquel il est normalement connecté, et de la connexion de ce serveur CSCF (respectivement, serveur d'applications) (C2) à un serveur HSS de secours (H') :
a) recevoir l'information de ladite perte de connexion avec ledit serveur HSS (H), et
b) envoyer, au moins aux autres serveurs CSCF (respectivement, serveurs d'applications) (C1) normalement connectés audit HSS primaire (H), un message de panne prédéterminé contenant la référence dudit serveur HSS primaire (H).
9. Dispositif de diffusion selon la revendication 8, caractérisé en ce qu'il comprend ledit serveur HSS de secours (Η').
10. Dispositif de diffusion selon la revendication 8, caractérisé en ce qu'il comprend un serveur SLF (F).
11. Dispositif de diffusion selon la revendication 8, caractérisé en ce qu'il comprend ledit serveur CSCF (respectivement, serveur d'applications) (C2) ayant détecté une perte de connexion.
12. Dispositif de diffusion pour le basculement d'un serveur HSS primaire sur un serveur HSS de secours dans un réseau IP, ledit réseau comprenant une pluralité de serveurs CSCF (respectivement, serveurs d'applications) (C1 , C2) et une pluralité de serveurs SLF (F1, F2) assurant une fonction de mandataire entre lesdits serveurs CSCF (respectivement, serveurs d'applications) d'une part, et lesdits serveurs HSS primaire et de secours d'autre part, ledit dispositif comprenant des moyens pour, lors de la détection d'une perte de connexion entre l'un desdits serveurs SLF (F1) et un serveur HSS primaire (H) auquel il est normalement connecté, et de la connexion de ce serveur SLF (F1) à un serveur HSS de secours (Η') : a) recevoir l'information de ladite perte de connexion avec ledit serveur HSS (H), et
b) envoyer, au moins aux autres serveurs SLF (F2) normalement connectés audit HSS primaire (H), un message de panne prédéterminé contenant la référence dudit serveur HSS primaire (H).
13. Dispositif de diffusion selon la revendication 12, caractérisé en ce qu'il comprend ledit serveur HSS de secours (Η').
14. Dispositif de diffusion selon la revendication 12, caractérisé en ce qu'il comprend ledit serveur. SLF (F1) ayant détecté une perte de connexion.
15. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de basculement d'un HSS primaire sur un HSS de secours selon l'une quelconque des revendications 1 à 7.
16. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de basculement d'un HSS primaire sur un HSS de secours selon l'une quelconque des revendications 1 à 7, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2010/052476 2009-11-27 2010-11-22 Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip WO2011064492A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/511,737 US9021300B2 (en) 2009-11-27 2010-11-22 Method of changing over from a primary HSS to a backup HSS in an IP network
EP10805447.9A EP2504982B1 (fr) 2009-11-27 2010-11-22 Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0958456 2009-11-27
FR0958456 2009-11-27

Publications (1)

Publication Number Publication Date
WO2011064492A1 true WO2011064492A1 (fr) 2011-06-03

Family

ID=42289704

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/052476 WO2011064492A1 (fr) 2009-11-27 2010-11-22 Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip

Country Status (3)

Country Link
US (1) US9021300B2 (fr)
EP (1) EP2504982B1 (fr)
WO (1) WO2011064492A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095739A (zh) * 2021-10-18 2022-02-25 海南车智易通信息技术有限公司 一种视频直播系统

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015007310A1 (fr) * 2013-07-16 2015-01-22 Nokia Solutions And Networks Oy Ré-enregistrement dans le cas d'une panne d'un serveur d'abonnés domestique
US10127116B2 (en) 2015-07-28 2018-11-13 At&T Intellectual Property I, L.P. Recovery of subscriber data in mobile communication networks
CN110198383B (zh) * 2018-02-27 2022-06-07 北京京东尚科信息技术有限公司 地址检测方法、系统、设备和存储介质
CN112714430B (zh) * 2019-10-24 2023-08-15 中国移动通信集团山东有限公司 一种异常处理方法、装置、存储介质和服务器
CN112714442B (zh) * 2019-10-24 2023-04-18 中国移动通信集团山东有限公司 一种异常处理方法、装置、存储介质和服务器
CN112235150B (zh) * 2020-12-16 2021-03-02 北京宇信科技集团股份有限公司 主备机自动接管方法和系统
CN114928832B (zh) * 2022-05-16 2023-07-21 中国联合网络通信集团有限公司 故障业务处理方法、装置、电子设备及计算机可读介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008046266A1 (fr) * 2006-10-18 2008-04-24 Zte Corporation Sous-système multimédia ip pour sélectionner automatiquement un serveur d'abonné local
WO2008046270A1 (fr) * 2006-10-18 2008-04-24 Zte Corporation Procédé de sélection automatique de serveur d'abonné local dans un sous-système multimédia ip
US20080227451A1 (en) * 2007-03-16 2008-09-18 Keiji Fukui Home subscriber server configuration method and system
WO2009080095A1 (fr) * 2007-12-19 2009-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil destinés à être utilisés dans un réseau de communication

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030167418A1 (en) * 2000-12-29 2003-09-04 Min Zhu Fault-tolerant server for collaborative computing
US20030126199A1 (en) * 2002-01-02 2003-07-03 Kadri Seemab Aslam Peer-to-peer namespace directory and discovery
US7583591B2 (en) * 2002-12-08 2009-09-01 Intel Corporation Facilitating communications with clustered servers
US20050060411A1 (en) * 2003-09-16 2005-03-17 Stephane Coulombe System and method for adaptation of peer-to-peer multimedia sessions
US7844745B1 (en) * 2004-08-19 2010-11-30 Nortel Networks Limited Alternate home subscriber server (HSS) node to receive a request if a first HSS node cannot handle said request
US7464303B2 (en) * 2005-06-09 2008-12-09 International Business Machines Corporation Autonomically adjusting configuration parameters for a server when a different server fails
US7557689B2 (en) * 2006-11-20 2009-07-07 Solana Networks Inc. Alerting method, apparatus, server, and system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008046266A1 (fr) * 2006-10-18 2008-04-24 Zte Corporation Sous-système multimédia ip pour sélectionner automatiquement un serveur d'abonné local
WO2008046270A1 (fr) * 2006-10-18 2008-04-24 Zte Corporation Procédé de sélection automatique de serveur d'abonné local dans un sous-système multimédia ip
US20080227451A1 (en) * 2007-03-16 2008-09-18 Keiji Fukui Home subscriber server configuration method and system
WO2009080095A1 (fr) * 2007-12-19 2009-07-02 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil destinés à être utilisés dans un réseau de communication

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114095739A (zh) * 2021-10-18 2022-02-25 海南车智易通信息技术有限公司 一种视频直播系统
CN114095739B (zh) * 2021-10-18 2023-08-01 海南车智易通信息技术有限公司 一种视频直播系统

Also Published As

Publication number Publication date
EP2504982B1 (fr) 2016-04-13
US20120290871A1 (en) 2012-11-15
US9021300B2 (en) 2015-04-28
EP2504982A1 (fr) 2012-10-03

Similar Documents

Publication Publication Date Title
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP3085065B1 (fr) Procédé de mise a jour dynamique d'informations obtenues de la part d'un serveur dns
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3646578B1 (fr) Procédé de synchronisation d'état média
WO2012085429A2 (fr) Procédé de localisation et d'identification d'un abonné connecté à un réseau émulant le rtc/rnis
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2015181505A1 (fr) Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal
WO2018150150A1 (fr) Procédé de changement de réseau mobile
WO2011117513A1 (fr) Procedes et dispositifs de contrôle de passerelles media
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
WO2012117178A1 (fr) Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims
WO2007148015A2 (fr) Systeme de declenchement d'un comptage dans un reseau de transport a travers un reseau a architecture de type ims
EP2073494A1 (fr) Procédé de signalisation de session de communications

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: 10805447

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 13511737

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2010805447

Country of ref document: EP