[go: up one dir, main page]

EP3053321A1 - Technique de restauration d'un service dans un réseau - Google Patents

Technique de restauration d'un service dans un réseau

Info

Publication number
EP3053321A1
EP3053321A1 EP14796195.7A EP14796195A EP3053321A1 EP 3053321 A1 EP3053321 A1 EP 3053321A1 EP 14796195 A EP14796195 A EP 14796195A EP 3053321 A1 EP3053321 A1 EP 3053321A1
Authority
EP
European Patent Office
Prior art keywords
server
user
interrogation
service request
registration server
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.)
Withdrawn
Application number
EP14796195.7A
Other languages
German (de)
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
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
Orange 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 Orange SA filed Critical Orange SA
Publication of EP3053321A1 publication Critical patent/EP3053321A1/fr
Withdrawn 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
    • 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]

Definitions

  • the invention is in the field of Internet Protocol (IP) type communication networks, and more particularly relates to a technique for restoring a service for a user in an IP Multimedia System (IMS) network.
  • IP Internet Protocol
  • IMS IP Multimedia System
  • An IMS network architecture as defined by the 3rd Generation Partnership Project (3GPP) standardization group enables the establishment and control of multimedia sessions between two user equipments as well as the reservation of resources for the multimedia streams at the network level. transport. With this architecture, network operators can conveniently control the quality of service offered.
  • the IMS architecture currently offers telephony, video telephony, Presence and Instant Messaging services and also manages the interaction of these services. It typically implements Session Initiation Protocol (SIP), as defined by the Internet Engineering Task Force (IETF) in RFC 3261 as a session management protocol, which enables the establishment, modification, or and terminating multimedia sessions in a network using the IP protocol.
  • SIP Session Initiation Protocol
  • IETF Internet Engineering Task Force
  • Such an IMS network architecture comprises in particular:
  • Each subscriber server contains the "profile" of a number of user devices of the network, this profile including their registration status, authentication and location data, and subscribed services;
  • S-CSCF Server-Call Server Control Function
  • Interrogating-Call Server Control Function I-CSCF
  • I-CSCF Interrogating-Call Server Control Function
  • proxy servers also called “proxy” servers
  • P-CSCF Proxy-Call Server Control Function
  • IMS Restoration Procedures a IMS network when a nominal registration server is unreachable (eg, network failure, or failure of the registration server itself).
  • two restoration procedures are described, the first involved when registering a user equipment on the IMS network (TS 23.380, ⁇ 4.2.2), and the second when the end of a session with a device. user (TS 23.380, ⁇ 4.3.3).
  • Both of these procedures provide for sending an ability request message by an I-CSCF interrogation server to an HSS subscriber server, so that the I-CSCF interrogation server can select a registration server S- Replacement CSCF.
  • Capabilities are defined in Chapter 6.7 of 3GPP TS 29.228 Technical Specification. This ensures service continuity in the transparent IMS network for the user.
  • a disadvantage of the service restoration procedures as specified in the TS 23.380 specification document is that when processing a service request for a user, a transfer of the service request is systematically made to the nominal registration server. .
  • the nominal registration server remains unreachable waiting for a response from the latter and retransmissions of the service request to the nominal registration server are particularly consumer in terms of network resources, then network capacity is reduced, in particular due to the unavailability of the nominal registration server.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention relates to a method of processing in a communication network a service request relating to a user, said method comprising the following steps implemented by an interrogation server during an optimization phase: a / reception from a user equipment of said service request relating to a user;
  • dl determining a replacement registration server from the received capabilities, and transferring the service request to the determined alternative registration server; in which, during a detection phase, during which the recording server is deemed reachable, said nominal recording server being associated with said user, and said method further comprises, prior to the step of receiving capacitors, the following steps : bl / receiving an identifier of a nominal registration server in response to the interrogation of step b1;
  • the detection phase implements the steps provided for in the restoration procedures described in TS 23.380.
  • the processing method thus provides for an optimization phase, triggered when the nominal registration server is deemed unreachable. Thanks to the processing method, the service request relating to the user is only transferred once to a recording server during the optimization phase. It is thus possible to avoid waiting times and retransmissions following the transfer of the service request to an unreachable registration server.
  • the service restoration procedures as defined in the TS 23.380 technical specification, are only implemented following a finding of unavailability of the nominal registration server after a first transfer of the service request to that server. nominal registration.
  • a single transfer of the service request during the optimization phase saves network resources and optimizes the processing of service requests relating to a user in the event of unavailability of a nominal registration server. Traffic within the network is also reduced. The continuity of service is thus reinforced, which contributes to improving the quality of service perceived by the user.
  • the processing method further comprises a step of determining that the nominal registration server is deemed unreachable, implemented by the interrogation server.
  • the step of determining that the nominal recording server is deemed unreachable can trigger the optimization phase.
  • Service Restore management is local to each network polling server. It is possible to implement service restoration strategies specific to each interrogation server of the network, depending for example on the number of transfer failures triggering the optimization phase.
  • the processing method comprises a step of determining that the nominal registration server is deemed unreachable, implemented by the subscriber server.
  • the initiation of the optimization phase by the subscriber server allows centralized management of the service restoration.
  • the subscriber server may maintain information relating to the unavailability of a registration server for each registration server of the network.
  • the subscriber server When the subscriber server is polled by a polling server to obtain a identifying a nominal registration server associated with a user, the subscriber server directly returns capabilities in response to this query when it has identified the registration server as unreachable or unavailable.
  • a second interrogation of the subscriber server by the query server to obtain capabilities and a possible new failure to transfer the service request are avoided, which has the effect of reducing network traffic.
  • the number of polls of the subscriber server is independent of the number of interrogation servers of the network.
  • the unreachable state of the nominal registration server is determined from at least one counter associated with said nominal registration server, updated during the detection phase during a transfer failure to the nominal recording server.
  • a counter makes it possible to have direct information as to the number of transfer failures for a given registration server. Associated with an unreachable state of a recording server, it makes it possible to define different strategies for triggering the optimization phase. This last phase is for example triggered according to the number of failed transfer of the service request. An operator may, for example, decide to define a low transfer failure number before triggering the optimization phase for interrogation servers requiring the best continuity of service, and raised for environments that tolerate service interruptions. It is thus possible for the operator to offer different levels of quality of service to a user.
  • the management for this trigger value counter of the optimization phase is simple. Indeed, there is only one counter to be updated per known registration server of an interrogation server.
  • the unreachable state of the nominal registration server is determined from a plurality of counters respectively associated with a plurality of types of service request.
  • Specialized counters by service request type allow fine management of service restoration strategies in an IMS network.
  • An operator may, for example, choose to privilege a continuity of service for requests relating to the registration (eg UAR requests, User Authorization Request) of a user equipment on the IMS network, and to adopt a different service restoration policy for example, Location Information Request (LIR) requests.
  • LIR Location Information Request
  • the invention relates to an interrogation server, arranged to process a service request relating to a user, comprising: a first send / receive module, arranged to receive from a user equipment said service request relating to a user and transfer it to a recording server;
  • a second sending / receiving module arranged to interrogate a subscriber server, in order to obtain in return an identifier of a registration server associated with the user or of capacities that a registration server must to be able to provide authorized services for a user;
  • a selection module arranged to determine a replacement recording server from received capacities
  • control module arranged to control an interrogation of a subscriber server, so that during a first phase, to obtain an identifier of a nominal registration server associated with the user, to command a transfer to the subscriber server; nominal registration server and following a failed transfer of the service request to said nominal registration server, obtain capabilities; and also arranged for, in a second phase, control when the nominal registration server is deemed unreachable, a single transfer of the service request for a user to a recording server.
  • the interrogation server further comprises a calculation module, arranged to update at least one counter relating to an unreachable state of a recording server.
  • the invention relates to a subscriber server arranged to process a service request relating to a user comprising:
  • a send / receive module arranged to answer a query from an interrogation server, in particular to provide it with an identifier of a nominal registration server associated with the user or to provide the same with the capabilities that a registration server must have in order to provide the authorized services for a user;
  • a control module arranged to control during an optimization phase where the nominal registration server is deemed unreachable, providing capabilities directly in response to an identifier request of said nominal registration server.
  • the subscriber server further comprises a calculation module, arranged to update at least one counter relating to an unreachable state of a registration server.
  • the invention proposes a system for processing a service request in a communication network, said system comprising:
  • an interrogation server according to the second aspect; a calculation module, arranged to update at least one counter relating to an unreachable state of a recording server;
  • a subscriber server comprising:
  • a sending / receiving module arranged to answer a query from an interrogation server, in particular to provide it with an identifier of a registration server associated with the user or to provide the latter with
  • control module of the subscriber server is furthermore arranged to control during an optimization phase where the nominal registration server is deemed unreachable, a supply of capabilities directly in response to a request for subscribers. identifier of said nominal registration server.
  • the invention relates to a program for an interrogation server, comprising program code instructions for controlling the execution of the steps of the method described above, when said program is executed by said server and support of recordable by an interrogation server on which a program for an interrogation server is stored.
  • the invention also relates to a program for a subscriber server, comprising program code instructions intended to control the execution of the steps of the method described above, when said program is executed by said server and a support recordable by a subscriber server on which a program is registered a subscriber server.
  • FIG. 1 represents a system for processing a service request relating to a user in a communication network
  • FIG. 2 represents an interrogation server implementing a method of processing a service request according to a particular embodiment
  • FIG. 3 represents a subscriber server according to a particular embodiment
  • FIGS. 4a and 4b represent steps of a method of processing a service request relating to a user according to two particular embodiments.
  • FIG. 1 represents a system 2 for processing a service request in a communication network 1.
  • the multimedia services offered by this network 1 may comprise services of telephony, video telephony, content sharing, Presence, instant messaging, or television.
  • the system 2 makes it possible to transfer a request for registration of a user equipment ⁇ User Equipment, or UE in English) on the network 1 to a server registration, and to benefit from the services offered by this network.
  • the user equipment 10 is for example a fixed or mobile terminal, or a home or enterprise gateway.
  • the system 2 comprises an interrogation server 20, a subscriber server 30 and a calculation module (not shown) for determining whether a recording server is unreachable.
  • the calculation module is for example according to a first embodiment described later integrated in the interrogation server 20 or according to a second embodiment also described later integrated in the subscriber server 30.
  • the subscriber 30 and interrogation servers 20 also communicate together.
  • the interrogation server 20 also communicates with recording servers 40-41.
  • Figure 1 is shown in a simplified manner to facilitate understanding. However, there is no limitation as to the number of subscriber servers, recording servers, interrogation servers belonging to the communication network. Similarly there is no limitation as to the number of user equipment.
  • the interrogation server 20 is an I-CSCF server
  • the recording servers 40-41 are S-CSCF servers
  • the subscriber server. 30 is an HSS server, some of these different servers can be gathered within the same entity, if any.
  • the SIP signaling protocol is used for exchanges with the user equipment 10, as well as between the interrogation and registration 40-41 servers.
  • the exchanges between the subscriber server 30 on the one hand and the interrogation and registration servers 40-41 on the other hand are supported by the Diameter protocol.
  • FIGS. 4a and 4b show a method of processing a service request relating to a user. They are based on two phases: a first PI detection phase and a second P2 optimization phase.
  • PI detection phase in the case of a failed transfer of the service request for a user to a nominal registration server 40, the service restoration procedures as defined in the TS 23.380 technical specification are implemented. Then on detection that the recording server is unreachable the second P2 optimization phase is triggered.
  • FIG. 4a describes the steps of the method of processing a service request relating to a user according to a first embodiment.
  • the detection that the nominal registration server 40 is unreachable is implemented in the IMS communication network 1 by the interrogation server 20.
  • the interrogation server 20 receives a service request M1 relating to a user from a user equipment 10.
  • the service request M1 is for example a SIP REGISTER request to register with a server recording.
  • the interrogation server 20 interrogates in a step E2 the subscriber server 30 in order to obtain an identifier of the nominal registration server 40 having the characteristics required to reach the level of service subscribed by the user.
  • This interrogation is more particularly carried out by sending a M2 (User-Authorization-Request) UAR message according to the Diameter protocol as defined in RFC 4740 and in accordance with specifications 3GPP TS 24.229 and TS 29.228.
  • the interrogation server 20 receives from the subscriber server 30 in response to the request UAR M2, a UAA message (for User-Authorization-Answer) M3 indicating an identifier Id s .
  • CSCF1 of the nominal registration server 40 with which the user is registered.
  • This identifier is for example a uniform resource identifier (Uniform Resource Identifier or URI) as defined by RFC 3986.
  • a step E4 the interrogation server 20 checks with a CPT counter whether a threshold SI conditioning the transition to a second phase P2, called “optimization phase” has been reached.
  • the threshold SI is defined by the operator of the communication network.
  • the achievement of this threshold S1 terminates a first phase PI, called “detection phase”, after which the nominal registration server 40 is deemed unreachable.
  • the second phase P2 is then triggered.
  • the interrogation server 20 transfers during a step E5 the request SIP REGISTER (message M4) to the nominal registration server 40 identified in the step E3.
  • step E6 an absence of response to the SIP REGISTER request is noted by the interrogation server 20.
  • the SIP protocol provides a mechanism for retransmission of messages, after which after several unanswered sending attempts, the absence of response is considered to be identical to a 408 Request Timeout response code, indicating that no response from the nominal registration server 40 was received in the allotted time for processing the message.
  • the lack of response from the nominal registration server 40 results, for example, from a failure of the latter, from disturbed network traffic, or from any other cause that makes it impossible to join it or does not allow the latter to reply. to a received request.
  • a new UAR M5 message including a capacity request is sent to the subscriber server 30.
  • the capacity request is built in entering the User-Authorization-type field of the UAR M5 message with the value REGISTRA TION_AND_CAPABILITIES.
  • the interrogation server 20 increments the counter CPT associated with the recording server 40 in a step E8.
  • the counter CPT is incremented with each transmission of a request UAR comprising a request for capacities during the detection phase.
  • a counter is associated with each recording server.
  • the interrogation server 20 receives a response from the subscriber server 30 in the form of a UAA M6 message including the requested capabilities.
  • the interrogation server 20 determines, during a step E10, from the received capacities, a new recording server 41 capable of rendering the service required by the user equipment 10.
  • This determined recording server 41 called As a replacement registration server, it thus replaces the nominal registration server 40 at which an attempt to transfer a SIP REGISTER request has previously failed.
  • the interrogation server 20 transfers the SIP request REGISTER M7 to the registration server 41 determined in the step E10.
  • Steps El to El i are re-implemented each time a service request for a user is received, as long as the detection phase has not ended. That is, as long as the counter associated with the recording server 40, incremented in step E8, does not exceed the threshold S1.
  • the nominal registration server 40 is deemed unreachable and the second optimization phase P2 is triggered.
  • This second phase P2 differs from the first phase PI by the absence of steps E5 and E6. Only steps E1 to E4 and E7 to E1 are implemented for the processing of a service request relating to a user.
  • the interrogation server 20 verifies by means of the counter CPT associated with the nominal registration server 40 if the threshold SI conditioning the transition to the second optimization phase P2 has been reached.
  • the achievement of this threshold S1 terminates the first phase of detection PI, after which the nominal registration server 40 is deemed unreachable.
  • the transfer of the service request relating to a user to the nominal registration server 40 is then inhibited during the optimization phase.
  • the steps E7 to El i are then implemented as described above in connection with the first phase PI, in order to transfer the service request relating to a user to the replacement registration server 41.
  • a single transfer of the request service is thus achieved during the second phase P2.
  • the method advantageously avoids waiting and retransmissions (in step E5) generated by a lack of response from the nominal recording server 40. This allows in particular to optimize the use of network resources.
  • the interrogation server 20 continues during the second phase P2 to increment the counter CPT associated with the nominal registration server 40 during a step E8.
  • This step makes it possible during this second phase P2 to define, for example, a second threshold S2 associated with the nominal registration server 40 which, when it is exceeded, makes it possible to return to a nominal processing of the service request.
  • This second threshold makes it possible, for example, to detect that a certain number of UAR requests comprising a capacity request have been sent. It is then likely that the nominal registration server 40 is again in operation for example if a failure had occurred.
  • this second phase P2, El to E4 and E7 to El i are again implemented at each reception of a service request relating to a user until reaching for example the second threshold S2 allowing a return to a nominal processing of the service requests relating to a user or intervention of the network operator to replace the nominal registration server, which terminates the second phase P2.
  • the polling server (20) transfers the service request relating to the user to the nominal registration server (40).
  • the counter CPT is reset, thus allowing a return to a nominal treatment of the service requests.
  • a new attempt to transfer the service request relating to the user to this server is, for example, performed when a new threshold value S n is reached.
  • FIG. 4b describes the steps of the method of processing a service request relating to a user according to a second embodiment.
  • the detection that the nominal registration server 40 is unreachable is implemented in the IMS communication network 1 by the subscriber server 30.
  • the counter associated with the nominal registration server 40 is no longer managed by the interrogation server 20 but by the subscriber server 30.
  • the subscriber server 30, more specifically the subscriber module calculation then implements a step E8b, similar to step E8.
  • the counter associated with the nominal registration server 40 is then incremented by the subscriber server 30 upon receipt of a UAR message M5 comprising a request for capabilities.
  • the determination that the nominal recording server 40 is deemed unreachable, allowing the triggering of the second phase P2 is performed by the subscriber server 30 during a step E4b, similar to the step E4.
  • the interrogation server 20 implements the steps E1 and E2 previously described in relation to the first embodiment and transmits a nominal request UAR M2.
  • the subscriber server 30 responds directly in the second phase P2 with a UAA message comprising capabilities, received by the interrogation server 20 in the step E9.
  • the subscriber server 30 thus responds as if it had received from the interrogation server 20 a request UAR comprising a request for capabilities.
  • the interrogation server 20 is thus arranged to receive capacity information without having previously requested it. It is emphasized here that, since the steps E3 to E7 described previously in relation with FIG.
  • step E7 UAR (step E7) and UAA (step E3) between the interrogation server 20 and the subscriber server 30.
  • the sending of a SIP-REGISTER request to the nominal registration server 40 is also avoided (step E5 ). This makes it possible in particular to optimize the use of the resources of the network, by lightening more particularly the traffic of signaling messages due to the redundancy of the UAR and UAA messages.
  • Steps E10 and E1 are then implemented in accordance with what has been previously described in connection with FIG. 4a.
  • the management of the counter to determine that a recording server is unreachable is centralized at the subscriber server 30, and is therefore also easier to implement.
  • This second embodiment makes it possible in particular for the subscriber server 30 to respond to an interrogation server for a service request relating to the user without the interrogation server explicitly having to request capabilities.
  • This second embodiment also makes it possible to benefit from the advantages of implementing the processing method to an interrogation server receiving a service request relating to the user and having, for example, little traffic, because of the in account during the step E8b of updating the counter of the UAR messages received from the other interrogation servers.
  • a counter associated with a particular type of request (UAR or LIR in the embodiments described above)
  • a global counter incremented indifferently at the time of transmission a request UAR or an LIR request each comprising a request for capacities when the counter is managed by the interrogation server 20 as described above in the first embodiment, or when receiving these requests without request explicit capabilities when the counter is managed by the subscriber server 30 as previously described in the second embodiment. Taking into account all the requests giving rise to the issuance of a UAR or LIR message makes it possible in particular to trigger the P2 optimization phase more quickly.
  • a threshold is associated with each counter defined by type of request. This makes it possible to adopt more refined service restoration strategies, for example with several threshold values depending on the incoming traffic or time slots.
  • the network operator may for example choose to implement the second phase P2 faster for time slots with high network traffic.
  • FIG. 2 represents an interrogation server 20 arranged to process a service request relating to a user. It includes:
  • a first send / receive module 200 arranged to receive a service request relating to a user and transfer it to a recording server;
  • a second sending / receiving module 202 arranged for interrogating a subscriber server, in order to obtain in return an identifier of a registration server associated with the user or of capacities that a registration server must have to be able to provide authorized services for a user;
  • a selection module 204 arranged to determine a replacement recording server from received capacities
  • control module 206 arranged to control an interrogation of the subscriber server.
  • control module 206 is arranged to interrogate the subscriber server in order to obtain an identifier of a nominal registration server associated with the user and following a failed transfer of the service request. to the identified nominal registration server, to poll the subscriber server for capabilities.
  • control module 206 is arranged to control a single transfer of the service request for a user to a recording server.
  • the interrogation server 20 further comprises a calculation module 208, arranged to update at least one counter relating to an unreachable state of a recording server.
  • the calculation module 208 determines that the nominal recording server is deemed unreachable and triggers the second phase P2.
  • FIG. 3 represents a subscriber server 30 arranged to process a service request relating to a user. It includes:
  • a send / receive module 300 arranged to answer a query from an interrogation server, in particular to provide it with an identifier of a registration server associated with the user or to provide the user with capabilities that a registration server must have in order to provide the authorized services for a user;
  • control module 302 arranged to control the response to the interrogation server.
  • the subscriber server 30 further comprises a calculation module 304, arranged to update at least one counter relating to an unreachable state of a recording server.
  • control module 302 is arranged to control a supply of capacity directly in response to a request for a server identifier. nominal registration, corresponding to the record server deemed unreachable.
  • module may correspond in this document to both a software component, a hardware component or a set of hardware and / or software components, capable of implementing a function or a set of functions, as described above for the module concerned.
  • a software component corresponds to one or more computer programs, one or more subroutines of a program, or more generally to any element of a program or software.
  • Such a software component is stored in memory and then loaded and executed by a data processor of a physical entity and is able to access the hardware resources of this physical entity (memories, recording media, communication buses, electronic cards of a physical entity). input / output, user interfaces, etc.).
  • a material component corresponds to any element of a material set (or hardware). It may be a programmable hardware component or not, with or without an integrated processor for running software. This is for example an integrated circuit, a smart card, an electronic card for executing a firmware, etc.
  • the modules 200, 202, 204, 206, and 208 are arranged to implement the previously described treatment method.
  • These are preferably software modules comprising software instructions for executing the steps of the previously described processing method, implemented by an interrogation server.
  • the invention therefore also relates to:
  • a program for an interrogation server comprising program code instructions intended to control the execution of the steps of the previously described processing method, when said program is executed by said interrogation server;
  • modules 300, 302, and 304 are arranged to implement the previously described treatment method. These are preferably software modules comprising software instructions for executing the steps of the previously described processing method, implemented by a subscriber server.
  • the invention therefore also relates to:
  • a program for a subscriber server comprising program code instructions intended to control the execution of the steps of the previously described processing method, when said program is executed by said subscriber server;
  • a recording medium readable by a subscriber server on which the program for a subscriber server is recorded.
  • the software modules can be stored in or transmitted by a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.

Landscapes

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

Abstract

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

Description

Technique de restauration d'un service dans un réseau
L'invention se situe dans le domaine des réseaux de communication de type IP (Internet Protocol), et concerne plus particulièrement une technique de restauration d'un service pour un utilisateur dans un réseau de type IMS (IP Multimedia System).
Une architecture de réseau IMS telle que définie par le groupe de normalisation 3GPP (pour 3rd Génération Partnership Project) permet l'établissement et le contrôle de sessions multimédia entre deux équipements utilisateur ainsi que la réservation de ressources pour les flux multimédias au niveau du réseau de transport. Grâce à cette architecture, les opérateurs de réseaux peuvent commodément contrôler la qualité de service offerte. L'architecture IMS permet actuellement d'offrir des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée et gère également l'interaction de ces services. Elle met généralement en œuvre le protocole SIP (pour Session Initiation Protocol), tel que défini par l'IETF (Internet Engineering Task Force) dans le document RFC 3261 en tant que protocole de gestion de sessions, lequel permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP.
Une telle architecture de réseau IMS comprend notamment :
- un ou plusieurs serveurs d'abonnés, ou serveurs HSS (pour Home Subscriber Server), contenant chacun une base de données utilisateurs. Chaque serveur d'abonnés contient le « profil » d'un certain nombre d'équipements utilisateur du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits ;
- un ou plusieurs serveurs d'enregistrement, appelés « S-CSCF » (pour Serving-Call Server Control Function) permettant notamment de gérer la procédure d'enregistrement des équipements utilisateur connectés au réseau ;
- un ou plusieurs serveurs d'interrogation, appelés « I-CSCF » (pour Interrogating-Call Server Control Function), permettant d'interroger un serveur d'abonnés au moment de l'enregistrement d'un équipement utilisateur, afin de d'obtenir un identifiant d'un serveur d'enregistrement disposant des caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateu, un tel serveur est appelé par la suite « serveur d'enregistrement nominal » ;
- un ou plusieurs serveurs mandataires (aussi appelés serveurs « proxy »), désignés par « P-CSCF » (pour Proxy-Call Server Control Function), servant d'entité de raccordement entre le cœur de réseau IMS et le réseau d'accès utilisé par les équipements utilisateur, aptes à retransmettre tous les messages de signalisation entre les équipements utilisateur d'une part et les serveurs S- CSCF ou I-CSCF d'autre part.
Afin d'assurer une continuité de service dans un réseau IMS, le groupe de normalisation 3GPP a défini dans un document de spécifications techniques TS 23.380 version 11.1.0, intitulé « IMS Restoration Procédures », des procédures relatives à la restauration de service au sein d'un réseau IMS lorsqu'un serveur d'enregistrement nominal est injoignable (e.g., panne réseau, ou panne du serveur d'enregistrement lui-même). Deux procédures de restauration sont en particulier décrites, la première intervenant lors de l'enregistrement d'un équipement utilisateur sur le réseau IMS (TS 23.380, §4.2.2), et la seconde lors de la fin d'une session avec un équipement utilisateur (TS 23.380, §4.3.3). Ces deux procédures prévoient un envoi d'un message de demande de capacités par un serveur d'interrogation I-CSCF à un serveur d'abonnés HSS, afin que le serveur d'interrogation I-CSCF puisse sélectionner un serveur d'enregistrement S-CSCF de remplacement. Ces « capacités » sont définies dans le Chapitre 6.7 des spécifications techniques 3GPP TS 29.228. Ceci permet d'assurer une continuité de service dans le réseau IMS transparente pour l'utilisateur.
Un inconvénient des procédures de restauration de service telles que spécifiées dans le document de spécification TS 23.380, est que lors du traitement d'une requête de service relative à un utilisateur, un transfert de cette dernière est systématiquement effectué vers le serveur d'enregistrement nominal. Dans le cas où le serveur d'enregistrement nominal reste injoignable l'attente d'une réponse de la part de ce dernier et les retransmissions de la requête de service vers ce serveur d'enregistrement nominal sont particulièrement consommateur en terme de ressources réseaux, alors même que les capacités du réseau sont réduites du fait notamment de l'indisponibilité du serveur d'enregistrement nominal. Il existe donc un besoin d'améliorer le traitement d'une requête de service relative à un utilisateur lors d'une restauration de service dans un réseau IMS.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect l'invention concerne un procédé de traitement dans un réseau de communication d'une requête de service relative à un utilisateur, ledit procédé comprenant les étapes suivantes mises en œuvre par un serveur d'interrogation pendant une phase d'optimisation : a/ réception en provenance d'un équipement utilisateur de ladite requête de service relative à un utilisateur ;
b/ interrogation du serveur d'abonnés afin d'obtenir une information permettant de traiter la requête de service ;
cl réception depuis un serveur d'abonnés de capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour ledit utilisateur ;
dl détermination d'un serveur d'enregistrement de remplacement à partir des capacités reçues, et transfert de la requête de service vers le serveur d'enregistrement de remplacement déterminé ; dans lequel, pendant une phase de détection, au cours de laquelle le serveur d'enregistrement est réputé joignable, ledit serveur d'enregistrement nominal étant associé audit utilisateur, et ledit procédé comprend en outre préalablement à l'étape cl de réception de capacités les étapes suivantes : bl/ réception d'un identifiant d'un serveur d'enregistrement nominal en réponse à l'interrogation de l'étape bl ;
b2/ transfert de la requête de service vers le serveur d'enregistrement nominal ;
et suite à un échec de ce transfert vers le serveur d'enregistrement nominal :
b3/ interrogation du serveur d'abonnés afin d'obtenir lesdites capacités ;
et le serveur d'enregistrement nominal étant réputé injoignable à l'issue de la phase de détection, déclenchement de la phase d'optimisation au cours de laquelle le transfert de l'étape d/ est l'unique transfert de la requête de service réalisé vers des serveurs d'enregistrement.
La phase de détection met en œuvre les étapes prévues dans les procédures de restauration décrites dans la spécification technique TS 23.380. Le procédé de traitement prévoit ainsi une phase d'optimisation, déclenchée lorsque le serveur d'enregistrement nominal est réputé injoignable. Grâce au procédé de traitement, la requête de service relative à l'utilisateur n'est transférée qu'une fois vers un serveur d'enregistrement pendant la phase d'optimisation. Il est ainsi possible d'éviter les temps d'attente et les retransmissions faisant suite au transfert de la requête de service vers un serveur d'enregistrement injoignable. Les procédures de restauration de service, telles que définies dans la spécification technique TS 23.380, ne sont mises en œuvre que suite à un constat d'indisponibilité du serveur d'enregistrement nominal après un premier transfert de la requête de service vers ce serveur d'enregistrement nominal. Un unique transfert de la requête de service pendant la phase d'optimisation permet d'économiser les ressources réseau et d'optimiser le traitement des requêtes de service relatives à un utilisateur en cas d'indisponibilité d'un serveur d'enregistrement nominal. Le trafic au sein du réseau est également réduit. La continuité de service est ainsi renforcée, ce qui contribue à améliorer la qualité de service perçue par l'utilisateur.
Selon une caractéristique particulière, le procédé de traitement comprend en outre une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en œuvre par le serveur d'interrogation.
L'étape de détermination que le serveur d'enregistrement nominal est réputé injoignable permet de déclencher la phase d'optimisation. La gestion de la restauration de service est locale à chaque serveur d'interrogation du réseau. Il est possible de mettre en œuvre des stratégies de restauration de service propres à chaque serveur d'interrogation du réseau, en fonction par exemple du nombre d'échecs de transfert déclenchant la phase d'optimisation.
Selon une autre caractéristique particulière, le procédé de traitement comprend une étape de détermination que le serveur d'enregistrement nominal est réputé injoignable, mise en œuvre par le serveur d'abonnés.
Le déclenchement de la phase d'optimisation par le serveur d'abonnés permet une gestion centralisée de la restauration de service. Le serveur d'abonnés peut maintenir une information relative à l'indisponibilité d'un serveur d'enregistrement pour chaque serveur d'enregistrement du réseau. Lorsque le serveur d'abonnés est interrogé par un serveur d'interrogation afin d'obtenir un identifiant d'un serveur d'enregistrement nominal associé à un utilisateur, le serveur d'abonnés renvoie directement des capacités en réponse à cette interrogation lorsqu'il a identifié le serveur d'enregistrement comme étant injoignable ou indisponible. Une deuxième interrogation du serveur d'abonnés par le serveur d'interrogation afin d'obtenir des capacités ainsi qu'un éventuel nouvel échec de transfert de la requête de service sont ainsi évités, ce qui a pour effet de diminuer le trafic réseau. Il est également à noter que s'agissant d'une gestion centralisée, le nombre d'interrogation du serveur d'abonnés est indépendant du nombre de serveur d'interrogation du réseau.
Selon une autre caractéristique particulière, l'état injoignable du serveur d'enregistrement nominal est déterminé à partir d'au moins un compteur associé audit serveur d'enregistrement nominal, mis à jour pendant la phase de détection lors d'un échec de transfert vers le serveur d'enregistrement nominal.
La mise en œuvre d'un compteur permet d'avoir une information directe quant au nombre d'échec de transfert pour un serveur d'enregistrement donné. Associé à un état injoignable d'un serveur d'enregistrement, elle permet de définir différentes stratégies quant au déclenchement de la phase d'optimisation. Cette dernière phase est par exemple déclenchée en fonction du nombre d'échec de transfert de la requête de service. Un opérateur pourra par exemple décider de définir un nombre d'échec de transfert faible avant déclenchement de la phase d'optimisation pour des serveurs d'interrogation nécessitant la meilleure continuité de service, et élevé pour des environnements tolérants des interruptions de services. Il est ainsi possible à l'opérateur de proposer différents niveaux de qualité de service à un utilisateur.
Le compteur étant par ailleurs associé à un serveur d'enregistrement indépendamment du type de requête de service, la gestion pour ce compteur de valeurs de déclenchement de la phase d'optimisation est simple. Il n'existe en effet qu'un compteur à mettre à jour par serveur d'enregistrement connu d'un serveur d'interrogation.
Selon une autre caractéristique particulière, l'état injoignable du serveur d'enregistrement nominal est déterminé à partir d'une pluralité de compteurs respectivement associés à une pluralité de types de requête de service.
Des compteurs spécialisés par type de requête de service permettent une gestion fine des stratégies de restauration de service dans un réseau IMS. Un opérateur peut par exemple choisir de privilégier une continuité de service pour les requêtes relatives à l'enregistrement (e.g. requêtes UAR, User Authorization Request) d'un équipement utilisateur sur le réseau IMS, et adopter une politique de restauration de service différente pour par exemple des requêtes LIR {Location Info Request) dîtes de localisation.
Selon un deuxième aspect, l'invention concerne un serveur d'interrogation, agencé pour traiter une requête de service relative à un utilisateur, comprenant : - un premier module d'envoi/réception, agencé pour recevoir en provenance d'un équipement utilisateur ladite requête de service relative à un utilisateur et la transférer vers un serveur d'enregistrement ;
- un second module d'envoi/réception, agencé pour interroger un serveur d'abonnés, afin d'obtenir en retour un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ;
- un module de sélection, agencé pour déterminer un serveur d'enregistrement de remplacement à partir de capacités reçues ;
- un module de commande, agencé pour commander une interrogation d'un serveur d'abonnés, afin de lors d'une première phase, obtenir un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur, commander un transfert vers le serveur d'enregistrement nominal et suite à un échec de transfert de la requête de service vers ledit serveur d'enregistrement nominal, obtenir des capacités ; et également agencé pour, lors d'une deuxième phase, commander lorsque le serveur d'enregistrement nominal est réputé injoignable, un unique transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement.
Selon une caractéristique particulière, le serveur d'interrogation comprend en outre un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement.
Les avantages énoncés pour le procédé de traitement selon l'une quelconque des caractéristiques du premier aspect sont directement transposables au serveur d'interrogation selon le deuxième aspect.
Selon un troisième aspect, l'invention concerne un serveur d'abonnés agencé pour traiter une requête de service relative à un utilisateur comprenant :
- un module d'envoi/réception, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ;
- un module de commande, agencé pour commander lors d'une phase d'optimisation où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur d'enregistrement nominal.
Selon une caractéristique particulière, le serveur d' abonnés comprend en outre un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d' enregistrement.
Selon un quatrième aspect, l'invention propose un système de traitement d'une requête de service dans un réseau de communication, ledit système comprenant :
- un serveur d'interrogation selon le deuxième aspect ; - un module de calcul, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement ; et
- un serveur d'abonnés comprenant :
- un module d'envoi/réception, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ;
- un module de commande, agencé pour commander la réponse au serveur d'interrogation. Selon une caractéristique particulière, le module de commande du serveur d' abonnés est en outre agencé pour commander lors d'une phase d'optimisation où le serveur d'enregistrement nominal est réputé injoignable, une fourniture de capacités directement en réponse à une demande d'identifiant dudit serveur d'enregistrement nominal.
Selon un cinquième aspect, l'invention concerne un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré un programme pour un serveur d'interrogation.
Selon un sixième aspect, l'invention concerne également un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé précédemment décrit, lorsque ledit programme est exécuté par ledit serveur et un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré un programme un serveur d'abonnés.
L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers, en référence aux dessins annexés sur lesquels :
- la figure 1 représente un système de traitement d'une requête de service relative à un utilisateur dans un réseau de communication;
- la figure 2 représente un serveur d'interrogation mettant en œuvre un procédé de traitement d'une requête de service selon un mode particulier de réalisation ;
- le figure 3 représente un serveur d'abonnés selon un mode particulier de réalisation ;
- les figures 4a et 4b représentent des étapes d'un procédé de traitement d'une requête de service relative à un utilisateur selon deux modes particuliers de réalisation.
La figure 1 représente un système 2 de traitement d'une requête de service dans un réseau de communication 1. Les services multimédia offerts par ce réseau 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu, de Présence, de Messagerie Instantanée, ou de télévision. Le système 2 permet de transférer une demande d'enregistrement d'un équipement utilisateur {User Equipment, ou UE en anglais) 10 sur le réseau 1 vers un serveur d'enregistrement, et de bénéficier des services offerts par ce réseau. L'équipement utilisateur 10 est par exemple un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise. Le système 2 comprend un serveur d'interrogation 20, un serveur d'abonnés 30 et un module de calcul (non représenté) permettant de déterminer si un serveur d'enregistrement est injoignable. Le module de calcul est par exemple selon un premier mode de réalisation décrit ultérieurement intégré au serveur d'interrogation 20 ou selon un deuxième mode de réalisation également décrit ultérieurement intégré au serveur d'abonnés 30. Les serveurs d'abonnés 30 et d'interrogation 20 communiquent par ailleurs ensemble. Le serveur d'interrogation 20 communique également avec des serveurs d'enregistrement 40-41.
Il est par ailleurs à noter que la figure 1 est représentée de manière simplifiée afin de faciliter la compréhension. Il n'existe cependant pas de limitation quant au nombre de serveurs d'abonnés, de serveurs d'enregistrement, de serveurs d'interrogation appartenant au réseau de communication. De même il n'existe pas de limitation quant au nombre d'équipement utilisateur.
Dans le cas particulier où le réseau de communication 1 présente une architecture de type IMS, le serveur d'interrogation 20 est un serveur I-CSCF, les serveurs d'enregistrement 40-41 sont des serveurs S-CSCF et le serveur d'abonnés 30 est un serveur HSS, certains de ces différents serveurs pouvant être rassemblés au sein d'une même entité, le cas échéant. Dans le cas d'une telle architecture IMS, le protocole de signalisation SIP est utilisé pour les échanges avec l'équipement utilisateur 10, ainsi qu'entre les serveurs d'interrogation 20 et d'enregistrement 40-41. Les échanges entre le serveur d'abonnés 30 d'une part et les serveurs d'interrogation 20 et d'enregistrement 40-41 d'autre part, sont quant à eux supportés par le protocole Diameter.
Les modes de réalisation décrits par la suite en relation avec les figures 4a et 4b présentent un procédé de traitement d'une requête de service relative à un utilisateur. Ils reposent sur deux phases : une première phase de détection PI et une deuxième phase d'optimisation P2. Pendant la phase de détection PI, dans le cas d'un échec de transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement nominal 40, les procédures de restauration de service telles que définies dans la spécification technique TS 23.380 sont mises en œuvre. Puis sur détection que le serveur d'enregistrement est injoignable la deuxième phase d'optimisation P2 est déclenchée.
La figure 4a décrit les étapes du procédé de traitement d'une requête de service relative à un utilisateur selon un premier mode de réalisation.
Dans ce premier mode de réalisation, la détection que le serveur d'enregistrement nominal 40 est injoignable est mise en œuvre dans le réseau de communication IMS 1 par le serveur d'interrogation 20.
Dans une étape El, le serveur d'interrogation 20 reçoit une requête de service Ml relative à un utilisateur en provenance d'un équipement utilisateur 10. La requête de service Ml est par exemple une requête SIP REGISTER d'enregistrement auprès d'un serveur d'enregistrement. Le serveur d'interrogation 20 interroge dans une étape E2 le serveur d'abonnés 30 afin d'obtenir un identifiant du serveur d'enregistrement nominal 40 possédant les caractéristiques requises pour atteindre le niveau de service souscrit par l'utilisateur. Cette interrogation est plus particulièrement réalisée par l'envoi d'un message UAR (pour User-Authorization-Request) M2 selon le protocole Diameter tel que défini dans la RFC 4740 et conformément aux spécifications 3GPP TS 24.229 et TS 29.228.
Lors d'une étape E3, le serveur d'interrogation 20 reçoit du serveur d'abonnés 30 en réponse à la requête UAR M2, un message UAA (pour User-Authorization-Answer) M3 lui indiquant un identifiant Ids.CSCF1 du serveur d'enregistrement nominal 40 auprès duquel l'utilisateur est enregistré. Cet identifiant est par exemple un identifiant uniforme de ressource (Uniform Resource Identifier ou URI en anglais) tel que défini par la RFC 3986.
Dans une étape E4, le serveur d'interrogation 20 vérifie à l'aide d'un compteur CPT si un seuil SI conditionnant le passage à une deuxième phase P2, dite « phase d'optimisation », a été atteint. Le seuil SI est défini par l'opérateur du réseau de communication. L'atteinte de ce seuil SI met fin à une première phase PI, dite « phase de détection », à l'issue de laquelle le serveur d'enregistrement nominal 40 est réputé injoignable. La deuxième phase P2 est alors déclenchée. Lorsque la deuxième phase P2 n'est pas déclenchée, le serveur d'interrogation 20 transfère lors d'une étape E5 la requête SIP REGISTER (message M4) vers le serveur d'enregistrement nominal 40 identifié à l'étape E3.
A l'étape E6, une absence de réponse à la requête SIP REGISTER est constatée par le serveur d'interrogation 20. Le protocole SIP prévoit un mécanisme de réémission de messages, à l'issue duquel après plusieurs tentatives d'envoi sans réponse, l'absence de réponse est considérée comme étant identique à un code de réponse 408 Request Timeout, indiquant qu'aucune réponse du serveur d'enregistrement nominal 40 n'a été reçue dans le temps imparti pour le traitement du message. L'absence de réponse du serveur d'enregistrement nominal 40 résulte par exemple d'une panne de ce dernier, d'un trafic réseau perturbé, ou de toute autre cause ne permettant pas de le joindre ou ne permettant pas à ce dernier de répondre à une requête reçue.
Dans une étape E7, conformément aux procédures de restauration du service IMS telles que définies dans les spécifications techniques 3GPP TS 23.380, un nouveau message UAR M5 comportant une demande de capacités est envoyé au serveur d'abonnés 30. La demande de capacités est construite en renseignant le champ User-Authorization-type du message UAR M5 par la valeur REGISTRA TION_AND_CAPABILITIES.
Le serveur d'interrogation 20 incrémente ensuite le compteur CPT associé au serveur d'enregistrement 40 dans une étape E8. Le compteur CPT est incrémenté à chaque émission d'une requête UAR comportant une demande de capacités pendant la phase de détection. Dans le mode de réalisation décrit, un compteur est associé à chaque serveur d'enregistrement. Dans une étape E9, le serveur d'interrogation 20 reçoit une réponse du serveur d'abonnés 30 sous la forme d'un message UAA M6 comprenant les capacités demandées.
Le serveur d'interrogation 20 détermine ensuite lors d'une étape E10, à partir des capacités reçues, un nouveau serveur d'enregistrement 41 capable de rendre le service requis par l'équipement utilisateur 10. Ce serveur d'enregistrement 41 déterminé, appelé serveur d'enregistrement de remplacement, se substitue ainsi au serveur d'enregistrement nominal 40 auprès duquel une tentative de transfert d'une requête SIP REGISTER a précédemment échoué.
Dans une étape El i, le serveur d'interrogation 20 transfère la requête SIP REGISTER M7 au serveur d'enregistrement 41 déterminé à l'étape E10.
Les étapes El à El i sont de nouveau mises en œuvre à chaque fois qu'une requête de service relative à un utilisateur est reçue, tant que la phase de détection n'a pas pris fin. C'est-à-dire tant que le compteur associé au serveur d'enregistrement 40, incrémenté à l'étape E8, ne dépasse pas le seuil SI.
Lorsque le seuil SI est atteint, le serveur d'enregistrement nominal 40 est réputé injoignable et la deuxième phase d'optimisation P2 est déclenchée. Cette deuxième phase P2 diffère de la première phase PI par l'absence des étapes E5 et E6. Seules les étapes El à E4 et E7 à El 1 sont mises en œuvre pour le traitement d'une requête de service relative à un utilisateur.
Au cours de cette deuxième phase P2, le serveur d'interrogation 20 vérifie à l'aide du compteur CPT associé au serveur d'enregistrement nominal 40 si le seuil SI conditionnant le passage à la deuxième phase d'optimisation P2 a été atteint. L'atteinte de ce seuil SI met fin à la première phase de détection PI, à l'issue de laquelle le serveur d'enregistrement nominal 40 est réputé injoignable. Le transfert de la requête de service relative à un utilisateur vers le serveur d'enregistrement nominal 40 est alors inhibé pendant la phase d'optimisation.
Les étapes E7 à El i sont ensuite mises en œuvre telles que décrites précédemment en relation avec la première phase PI, afin de transférer la requête de service relative à un utilisateur vers le serveur d'enregistrement de remplacement 41. Un unique transfert de la requête de service est ainsi réalisé au cours de la deuxième phase P2. Le procédé permet avantageusement d'éviter l'attente et les retransmissions (lors de l'étape E5) générées par une absence de réponse du serveur d'enregistrement nominal 40. Ceci permet notamment d'optimiser l'utilisation des ressources du réseau.
Dans un mode de réalisation particulier, le serveur d'interrogation 20 continue pendant la deuxième phase P2 d'incrémenter le compteur CPT associé au serveur d'enregistrement nominal 40 lors d'une étape E8. Cette étape permet lors de cette deuxième phase P2 de définir par exemple un second seuil S2 associé au serveur d'enregistrement nominal 40 qui lorsqu'il est dépassé permet de revenir à un traitement nominal de la requête de service. Ce second seuil permet de détecter par exemple qu'un certain nombre de requêtes UAR comportant une demande de capacités a été envoyé. Il est alors probable que le serveur d'enregistrement nominal 40 soit de nouveau en fonctionnement par exemple si une panne était survenue.
Les étapes de cette deuxième phase P2, El à E4 et E7 à El i, sont de nouveau mises en œuvre à chaque réception d'une requête de service relative à un utilisateur jusqu'à l'atteinte par exemple du second seuil S2 permettant un retour à un traitement nominal des requêtes de service relatives à un utilisateur ou une intervention de l'opérateur du réseau pour remplacer le serveur d'enregistrement nominal, ce qui met fin à la deuxième phase P2.
Dans un autre mode réalisation, à l'atteinte du second seuil S2, le serveur d'interrogation (20) transfère la requête de service relative à l'utilisateur vers le serveur d'enregistrement nominal (40). Dans le cas où ce dernier est de nouveau joignable, le compteur CPT est remis à zéro, permettant ainsi un retour à un traitement nominal des requêtes de service. Lorsque le serveur d'enregistrement nominal (40) reste injoignable, une nouvelle tentative de transfert de la requête de service relative à l'utilisateur vers ce serveur est par exemple réalisée à l'atteint d'une nouvelle valeur de seuil Sn fonction du seuil S2. A titre d'exemple non limitatif, une tentative de transfert est réalisée pour chaque valeur de seuil Sn = 2" X S 2 .
La figure 4b décrit les étapes du procédé de traitement d'une requête de service relative à un utilisateur selon un deuxième mode de réalisation.
Dans ce deuxième mode de réalisation, la détection que le serveur d'enregistrement nominal 40 est injoignable est mise en œuvre dans le réseau de communication IMS 1 par le serveur d'abonnés 30.
Dans ce deuxième mode de réalisation, le compteur associé au serveur d'enregistrement nominal 40 n'est plus géré par le serveur d'interrogation 20 mais par le serveur d'abonnés 30. Le serveur d'abonnés 30, plus précisément le module de calcul, met alors en œuvre une étape E8b, similaire à l'étape E8. Le compteur associé au serveur d'enregistrement nominal 40 est alors incrémenté par le serveur d'abonnés 30 à chaque réception d'un message UAR M5 comprenant une demande de capacités. De même, la détermination que le serveur d'enregistrement nominal 40 est réputé injoignable, permettant le déclenchement de la deuxième phase P2 est effectuée par le serveur d'abonnés 30 lors d'une étape E4b, similaire à l'étape E4. Dans ce deuxième mode de réalisation, lors de la deuxième phase P2, le serveur d'interrogation 20 met en œuvre les étapes El et E2 précédemment décrites en relation avec le premier mode de réalisation et transmet une requête UAR nominale M2. Sur réception de cette requête UAR nominale, le serveur d'abonnés 30 répond directement dans la deuxième phase P2 avec un message UAA comprenant des capacités, reçu par le serveur d'interrogation 20 dans l'étape E9. Le serveur d'abonnés 30 répond ainsi comme s'il avait reçu du serveur d'interrogation 20 une requête UAR comportant une demande de capacités. Dans ce deuxième mode de réalisation, le serveur d'interrogation 20 est ainsi agencé pour recevoir des informations de capacités sans les avoir demandées précédemment On souligne ici que, les étapes E3 à E7 décrites précédemment en relation avec la figure 4a n'étant pas mises en œuvre dans ce deuxième mode de réalisation lors de la deuxième phase P2, le procédé de traitement permet d'éviter les échanges de messages UAR (étape E7) et UAA (étape E3) entre le serveur d'interrogation 20 et le serveur d'abonnés 30. L'envoi d'une requête SIP- REGISTER vers le serveur d'enregistrement nominal 40 est également évité (étape E5). Ceci permet notamment d'optimiser l'utilisation des ressources du réseau, en allégeant plus particulièrement le trafic de messages de signalisation dû à la redondance des messages UAR et UAA.
Les étapes E10 et El i sont ensuite mises en œuvre conformément à ce qui a été décrit précédemment en relation avec la figure 4a.
La gestion du compteur permettant de déterminer qu'un serveur d'enregistrement est injoignable est centralisée au niveau du serveur d'abonnés 30, et est de ce fait également plus facile à mettre en œuvre. Ce deuxième mode de réalisation permet en particulier au serveur d' abonnés 30 de répondre à un serveur d'interrogation pour une requête de service relative à l'utilisateur sans que le serveur d'interrogation ait explicitement à demander des capacités.
Ce deuxième mode de réalisation permet également de faire bénéficier des avantages de la mise en œuvre du procédé de traitement à un serveur d'interrogation recevant une requête de service relative à l'utilisateur et présentant par exemple peu de trafic, du fait de la prise en compte lors de l'étape E8b de mise à jour du compteur des messages UAR reçus depuis les autres serveurs d'interrogation.
Les précédents modes de réalisation ont été décrits pour le traitement d'une requête de service SIP REGISTER. Il n'existe cependant pas de limitations quant aux types de requête de service traités. Le procédé s'applique également par exemple à une requête de service SIP INVITE. Dans ce dernier cas, le procédé de traitement mis en œuvre est équivalent à celui mis en œuvre pour traiter une requête SIP REGISTER, seuls les types de messages échangés entre le serveur d'interrogation 20 et le serveur d'abonnés 30 diffèrent. Au lieu des messages UAR et UAA, les serveurs s'échangent respectivement des messages LIR (pour Location Info Request) et LIA (pour Location Info Answer). Un compteur pour les interrogations du serveur d'abonnés est alors incrémenté dans le premier mode, lors de l'étape E8 à chaque émission d'une requête LIR comportant une demande de capacités, ou dans le deuxième mode lors de l'étape E8b à chaque réception d'une requête LIR.
Dans un autre mode de réalisation, au lieu d'un compteur associé à un type de requête particulier (UAR ou LIR dans les modes de réalisation décrits précédemment), il peut être avantageux d'utiliser un compteur global incrémenté indifféremment lors de l'émission d'une requête UAR ou d'une requête LIR comprenant chacune une demande de capacités lorsque le compteur est géré par le serveur d'interrogation 20 tel que décrit précédemment dans le premier mode de réalisation, ou lors de la réception de ces requêtes sans demande explicite de capacités lorsque le compteur est géré par le serveur d'abonnés 30 tel que décrit précédemment dans le deuxième mode de réalisation. La prise en compte de l'ensemble des requêtes donnant lieu à l'émission d'un message UAR ou LIR permet notamment de déclencher plus rapidement la phase d'optimisation P2.
De même, dans un autre mode de réalisation, plusieurs seuils sont utilisés pour le déclenchement de la deuxième phase P2. Un seuil est par exemple associé à chaque compteur défini par type de requête. Ceci permet d'adopter des stratégies de restauration de service plus fines, avec par exemple plusieurs valeurs de seuils en fonction du trafic entrant ou encore de tranches horaires. L'opérateur de réseau peut par exemple choisir de mettre en œuvre la deuxième phase P2 plus rapidement pour des tranches horaires présentant un trafic réseau élevé.
La figure 2 représente un serveur d'interrogation 20 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment :
- un premier module d'envoi/réception 200, agencé pour recevoir une requête de service relative à un utilisateur et la transférer vers un serveur d'enregistrement ;
- un second module d'envoi/réception 202, agencé pour interroger un serveur d'abonnés, afin d'obtenir en retour un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ;
- un module de sélection 204, agencé pour déterminer un serveur d'enregistrement de remplacement à partir de capacités reçues ;
- un module de commande 206, agencé pour commander une interrogation du serveur d'abonnés.
Dans une première phase, le module de commande 206 est agencé pour interroger le serveur d'abonnés afin d'obtenir un identifiant d'un serveur d'enregistrement nominal associé à l'utilisateur et suite à un échec de transfert de la requête de service vers le serveur d'enregistrement nominal identifié, pour interroger le serveur d'abonnés afin d'obtenir des capacités. Dans une deuxième phase, déclenchée lorsque le serveur d'enregistrement nominal est réputé injoignable, le module de commande 206 est agencé pour commander un unique transfert de la requête de service relative à un utilisateur vers un serveur d'enregistrement.
Dans le premier mode de réalisation, le serveur d'interrogation 20 comprend en outre un module de calcul 208, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement. Le module de calcul 208 détermine que le serveur d'enregistrement nominal est réputé injoignable et déclenche la deuxième phase P2.
La figure 3 représente un serveur d'abonnés 30 agencé pour traiter une requête de service relative à un utilisateur. Il comprend notamment :
- un module d'envoi/réception 300, agencé pour répondre à une interrogation d'un serveur d'interrogation, notamment pour fournir à celui-ci un identifiant d'un serveur d'enregistrement associé à l'utilisateur ou pour fournir à celui-ci des capacités qu'un serveur d'enregistrement doit posséder pour pouvoir fournir les services autorisés pour un utilisateur ;
- un module de commande 302, agencé pour commander la réponse au serveur d'interrogation.
Dans le deuxième mode de réalisation, le serveur d'abonnés 30 comprend en outre un module de calcul 304, agencé pour mettre à jour au moins un compteur relatif à un état injoignable d'un serveur d'enregistrement.
Dans la deuxième phase, déclenchée sur détection par le module de calcul 304 que le serveur d'enregistrement nominal est réputé injoignable, le module de commande 302 est agencé pour commander une fourniture de capacités directement en réponse à une demande d'identifiant de serveur d'enregistrement nominal, correspondant au serveur d'enregistrement réputé injoignable.
L'invention est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et/ou logiciels, apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit précédemment pour le module concerné.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel. Un tel composant logiciel est stocké en mémoire puis chargé et exécuté par un processeur de données d'une entité physique et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware). Il peut s'agir d'un composant matériel programmable ou non, avec ou sans processeur intégré pour l'exécution de logiciel. Il s'agit par exemple d'un circuit intégré, d'une carte à puce, d'une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Dans un mode de réalisation particulier, les modules 200, 202, 204, 206, et 208 sont agencés pour mettre en œuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de traitement précédemment décrit, mises en œuvre par un serveur d'interrogation. L'invention concerne donc aussi :
- un programme pour un serveur d'interrogation, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d'interrogation ;
- un support d'enregistrement lisible par un serveur d'interrogation sur lequel est enregistré le programme pour un serveur d'interrogation. De même, les modules 300, 302, et 304 sont agencés pour mettre en œuvre le procédé de traitement précédemment décrit. Il s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé de traitement précédemment décrit, mises en œuvre par un serveur d'abonnés. L'invention concerne donc aussi :
- un programme pour un serveur d'abonnés, comprenant des instructions de code de programme destinées à commander l'exécution des étapes du procédé de traitement précédemment décrit, lorsque ledit programme est exécuté par ledit serveur d' abonnés ;
- un support d'enregistrement lisible par un serveur d'abonnés sur lequel est enregistré le programme pour un serveur d'abonnés.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.

Claims

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1359388A FR3011423A1 (fr) 2013-09-30 2013-09-30 Technique de restauration d'un service dans un reseau
PCT/FR2014/052406 WO2015044596A1 (fr) 2013-09-30 2014-09-25 Technique de restauration d'un service dans un réseau

Publications (1)

Publication Number Publication Date
EP3053321A1 true EP3053321A1 (fr) 2016-08-10

Family

ID=49998381

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14796195.7A Withdrawn EP3053321A1 (fr) 2013-09-30 2014-09-25 Technique de restauration d'un service dans un réseau

Country Status (4)

Country Link
US (1) US20160241601A1 (fr)
EP (1) EP3053321A1 (fr)
FR (1) FR3011423A1 (fr)
WO (1) WO2015044596A1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9479499B2 (en) * 2013-03-21 2016-10-25 Tencent Technology (Shenzhen) Company Limited Method and apparatus for identity authentication via mobile capturing code
US10554694B2 (en) * 2015-07-20 2020-02-04 At&T Intellectual Property I, L.P. System and method for using software defined networking in internet protocol multimedia subsystems
DE102016221985A1 (de) * 2016-11-09 2018-05-09 Volkswagen Aktiengesellschaft Verfahren zur Datenübertragung in einem Fahrzeug-Kommunikationsnetzwerk, Fahrzeug- Kommunikationsnetzwerk, Teilnehmer und Fahrzeug
CN115665246B (zh) * 2022-09-01 2024-03-08 浪潮通信信息系统有限公司 注册请求处理方法、装置、设备及存储介质

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100382503C (zh) * 2005-06-20 2008-04-16 华为技术有限公司 一种在用户注册过程中注册异常的处理方法
CN101170553B (zh) * 2006-10-24 2011-07-20 华为技术有限公司 实现互联网协议多媒体子系统容灾的方法和装置
WO2009012814A1 (fr) * 2007-07-23 2009-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Procédé et appareil à usage dans un réseau de communications
CN102098652B (zh) * 2008-01-18 2012-12-12 华为技术有限公司 一种为用户提供业务的方法、系统和装置
US8369313B2 (en) * 2008-12-17 2013-02-05 At&T Intellectual Property I, L.P. IMS and method of multiple S-CSCF operation in support of single PUID
US8619547B2 (en) * 2010-11-10 2013-12-31 At&T Intellectual Property I, L.P. Communication system with failover communication services
US8582544B2 (en) * 2010-11-18 2013-11-12 At&T Intellectual Property I, L.P. Communication device for configuring failover communication services
US8533348B2 (en) * 2011-10-18 2013-09-10 At&T Intellectual Property I, L.P. Failover communication services
US9578068B2 (en) * 2012-09-24 2017-02-21 Telefonaktiebolaget Lm Ericsson (Publ) Methods and apparatus for processing an IMS session

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2015044596A1 *

Also Published As

Publication number Publication date
US20160241601A1 (en) 2016-08-18
WO2015044596A1 (fr) 2015-04-02
FR3011423A1 (fr) 2015-04-03

Similar Documents

Publication Publication Date Title
US8661077B2 (en) Methods, systems and computer readable media for providing a failover measure using watcher information (WINFO) architecture
US9413618B2 (en) Method, system and devices for managing user provisioning of a service in an IMS network
WO2010112741A1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
EP3639541B1 (fr) Configuration d'un terminal dans un réseau ims avec une stratégie de resélection d'un type réseau
WO2013001230A1 (fr) D'obtention par un terminal d'une information relative a un acces a un service
EP2366238B1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
WO2015044596A1 (fr) Technique de restauration d'un service dans un réseau
FR3015838A1 (fr) Procede 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
EP2386169B1 (fr) Procédé et système de regulation du trafic de redémarrage dans un réseau de télécommunications
FR3034608A1 (fr) Procede de priorisation de flux medias dans un reseau de communications
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2353278B1 (fr) Procede de gestion d'un utilisateur dans un reseau de telecommunications, et dispositif associe
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
WO2016116689A1 (fr) Procédé de gestion de signalisation de présence d'un terminal dans un réseau de communication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2015079153A1 (fr) Technique de restauration d'un service dans un réseau
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
FR3001351A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160426

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190506

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20211103