WO2014170582A1 - Procede de restauration de service dans un reseau ims - Google Patents

Procede de restauration de service dans un reseau ims Download PDF

Info

Publication number
WO2014170582A1
WO2014170582A1 PCT/FR2014/050859 FR2014050859W WO2014170582A1 WO 2014170582 A1 WO2014170582 A1 WO 2014170582A1 FR 2014050859 W FR2014050859 W FR 2014050859W WO 2014170582 A1 WO2014170582 A1 WO 2014170582A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
cscf
user
cscf server
hss
Prior art date
Application number
PCT/FR2014/050859
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2014170582A1 publication Critical patent/WO2014170582A1/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
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
    • 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/1046—Call controllers; Call servers
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/30—Profiles
    • H04L67/306—User profiles
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]

Definitions

  • the present invention relates to communication networks of IP ("Internet Protocol") type, and in particular those of IP networks that are able to implement advanced session control protocols.
  • IP networks include the transmission of conversational data, in the context of services such as "VoIP” (VoIP), "Content Sharing", or "Instant Messaging”.
  • the present invention relates to the routing of a service request, for example a VoIP call, to a client device belonging to an IMS network (initials of the words "IP Multimedia Subsystem” meaning “Multimedia subsystem on IP ").
  • a client device (“User Equipment” in English) is said to "belong” to the network of a given operator when the user of this client device has a account with this operator, regardless of the access network used by the client device to connect to the network of the operator.
  • client devices may for example be a fixed or mobile terminal, or a residential gateway (English) or located in a company, or a network operator gateway (“Voice Gateway” in English) such as a DSLAM-SIP (DSLAM) are the initials of the words “Digital Subscriber Line Access Multiplexer” meaning “Digital Subscriber Line Access Multiplexer", it is a device that collects DSL data traffic that passes through on a number of telephone lines).
  • DSLAM-SIP DSLAM-SIP
  • the SIP protocol has been defined by the Internet Engineering Task Force (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 was then extended in particular in RFC 3265. This extension allows event notification procedures.
  • IETF Internet Engineering Task Force
  • the SIP protocol is used in particular in the IMS-type infrastructures, mentioned above.
  • the IMS has been defined by the 3GPP standardization body ("3 rd Generation Partnership Project") and TISPAN ("Telecommunications and Internet Converged Services and Protocols for Advanced Networking"). It is a network architecture introduced by 3GPP for mobile networks, then taken over by TISPAN for fixed networks. This architecture 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. Through this architecture, 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 services such as telephony, video telephony, and instant messaging, which it also manages.
  • IM Instant Messaging
  • chat a name derived from the English word “chat” meaning “chatter”
  • chat a name derived from the English word “chat” meaning “chatter”
  • textual and file this which allows an interactive dialogue between two users connected to the same network (such as the Internet).
  • the client device of the user must, with exceptions (such as certain emergency calls), register on the network.
  • exceptions such as certain emergency calls
  • the network is unable to link this record to a previous record (for example due to a network failure, or following a client-device shutdown for a duration longer than a predetermined value)
  • the record is considered being an initial recording.
  • the user's client device must periodically send the network a request to confirm that it wishes to maintain its registration.
  • the networks In order to be able to register the client devices, the networks
  • IMSs include one or more registration servers, referred to as "S-CSCFs" (initials of the English words “Serving-Call Server Control Function” meaning “Server Call Session Control Function”), suitable (among other functions) manage the registration procedure of devices connected to the network.
  • S-CSCFs initials of the English words "Serving-Call Server Control Function” meaning “Server Call Session Control Function”
  • suitable (among other functions) manage the registration procedure of devices connected to the network.
  • these networks include one or more servers, called “l-CSCF” servers (initials of the English words “Interrogating- Call Server Control Function” meaning “Interrogating Call Session Control Function”) - moreover often combined physically with the servers of type S-CSCF to constitute servers denoted “l / S-CSCF” - which, at the time of the registration of a device-client, interrogate a server called “HSS” (initials of the English words " Home Subscriber Server “means” Subscriber Subscriber Server ”) so that you can select an S-CSCF server with the capabilities required to provide all services authorized for the user-device user.
  • HSS home Subscriber Server
  • HSS servers are the equivalent in IP networks of "HLR” servers (initials of the words “Home Location Register” meaning “Link Location Registry”) used in GSM networks.
  • HSS server can access a client database defined in 3GPP TS 23.008 specification (see in particular Section 3): this client data concerns, for example, for each user of the IMS network, the state of registration of the associated client device, as well as authentication and location data.
  • client database defined in 3GPP TS 23.008 specification (see in particular Section 3): this client data concerns, for example, for each user of the IMS network, the state of registration of the associated client device, as well as authentication and location data.
  • such a database whether or not it obeys specification TS 23.008) will be referred to as "user profile”.
  • each user can use a number of services during the current connection. For example, these services may be offered automatically to all users of the IMS network. It can also be services to which this user has subscribed to the network operator, and which are automatically made available. Finally, they may be services that the user can use after issuing an appropriate request (SIP SUBSCRIBE).
  • These services include audiovisual applications as mentioned above. It can also be a subscription to the state of a resource, in which case event notifications (SIP NOTIFY) are sent to the client device as soon as the state of the resource changes; for example, when the user of a client device has a mailbox on the network, he can be informed each time a message has been recorded on this mailbox; a user can, likewise, ask to be notified of the registration status of his own client device.
  • SIP NOTIFY event notifications
  • 3GPP defined in the TS 23.380 specification a procedure to restore the IMS service in the event of an S-CSCF server failure.
  • this specification proposes in Section 4.3.3 the selection by an l-CSCF server of a new S-CSCF server for the processing of incoming calls, so that a user whose nominal S-CSCF server is has failed to be aware of the failure and calls for it continue to be issued (the notion of "nominal" S-CSCF server is defined in Section 3.2.2 of TS 23.008 mentioned above). -above).
  • the network includes multiple I-CSCF servers
  • these l-CSCF servers are in mutual competition over the restore procedures. This problem is illustrated below by an example, with reference to FIG.
  • a service request (No. 1) targeting a certain user of an IMS network is received by an I-CSCF server (No. 1) of this network.
  • this l-CSCF server No. 1 initiates a so-called "first location procedure"("LIRDiameter” message) to the HSS server in charge of said user, to know the identity of the nominal S-CSCF server (N ° 1) assigned to this user.
  • the HSS server responds to the l-CSCF server No. 1 ("LIA Diameter" message) by providing an identifier of the nominal S-CSCF server; it is for example an S-CSCF server called "S3".
  • the l-CSCF server No. 1 attempts to join the S-CSCF server S3 to transmit the request No. 1, but the attempt fails; this may be due to a failure of the S-CSCF server S3, or failure of the connection between the server-CSCF No. 1 and r is the S-CSCF S3 dreamer.
  • the l-CSCF server No. 1 therefore initiates a restoration procedure in accordance with the aforementioned TS 23.380 specification. To do this, the l-CSCF server No. 1 initiates a "second location procedure", in which the l-CSCF server No. 1 sends a "capacity request" (second message "Diameter LIR") to the server HSS, to find out what capabilities an S-CSCF server must have in order to provide all the services authorized for that user.
  • a "capacity request" second message "Diameter LIR”
  • the server HSS responds to the server l-CSCF No.
  • the l-CSCF server No. 1 selects a new S-CSCF server (S-CSCF No. 2) having the capabilities required to provide all the services authorized for this user; for example, assume that the selected S-CSCF server has the identifier "S2".
  • the l-CSCF server No. 1 then sends the request No. 1 to this server S-CSCF No. 2 (ie, S2).
  • a new service request (No. 2), targeting the same user as the service request No. 1, is received by an I-CSCF server (No. 2) of the IMS network; it will be noted that this l-CSCF server No. 2 may possibly be identical to the l-CSCF server No. 1.
  • the I- CSCF server # 2 initiates a "first" procedure loca l ization (message "Diameter ITA") to the HSS in charge of said user for the identity of the nominal S-CSCF (No. 1) server associated with this user.
  • step E10 analogous to step E3 above, the HSS server responds to the l-CSCF server No. 2 ("LIA Diameter" message) by providing an identifier of the nominal S-CSCF server, i.e. S3.
  • the HSS server responds to the l-CSCF server No. 2 ("LIA Diameter" message) by providing an identifier of the nominal S-CSCF server, i.e. S3.
  • step E1 analogous to step E4 above, the l-CSCF server No. 2 attempts to join the S-CSCF server S3 to send him the request No. 2, and the attempt fails.
  • the S-CSCF server No. 2 updates the HSS server with its own reference (ie, S2) ("SAR Diameter" message), since, following the step E7 above, above, this S-CSCF server S2 considers that it is henceforth the nominal S-CSCF server for said user.
  • the HSS server confirms this update ("Diameter SAA" message).
  • step E13 similar to step E5 above, the server I-
  • CSCF # 2 sends a capability request (second "Diameter LIR” message) to the HSS server, to find out what capabilities an S-CSCF server must have in order to provide all the authorized services for that user.
  • the server HSS responds to the server l-CSCF No. 2 (second message "Diameter LIA") indicating which are said capabilities.
  • the I-CSCF server No. 2 selects a new S-CSCF server (No. 3) having the capabilities required to be able to provide all the authorized services. for this user; it is for example an S-CSCF server called "S4".
  • S-CSCF server an S-CSCF server
  • the server S-CSCF No. 3 selected by the server l-CSCF No. 2 may, where appropriate, be identical to the server S-CSCF No. 2, but may also to be distinct from it.
  • the l-CSCF server No. 2 then sends the request No. 2 to this server S-CSCF No. 3 (i.e., S4).
  • step E16 analogous to step E12 above, the S-CSCF server No. 3 then updates the HSS server with its own reference (ie, S4) ("SAR Diameter" message), since following the previous step E15, this S-CSCF server S4 considers that it is henceforth the nominal S-CSCF server for said user.
  • the HSS server confirms this update ("Diameter SAA" message).
  • the present invention thus relates to a service restoration method in an IMS network, comprising the following steps:
  • a service request for a user of said IMS network is received by an I-CSCF server of this IMS network,
  • said l-CSCF server sends to the HSS server of the IMS network in charge of said user a request to know the identity of the nominal S-CSCF server associated with said user,
  • the HSS server selects a new S-CSCF server capable of providing all the authorized services for the user, and provides the l-CSCF server with an identifier of the new S-CSCF server, and d) the l-CSCF server. takes into account said identifier of the new S-CSCF server, and forward the service request to this new S-CSCF server.
  • the method is notable in that the HSS server records the assignment to the user of the new S-CSCF server.
  • the invention can be indicated to any l-CSCF server that has received a service request targeting a certain user, not only (in a conventional manner) the identity of the nominal S-CSCF server for that user. user, but also, following a failure of this nominal S-CSCF server, the identity of a single S-CSCF server to process the service requests for this user, instead of the S-CSCF server failed. This avoids contradictory reselections according to the state of the art, and the loss of calls that result.
  • said method further comprises, between said steps b) and c), the following steps:
  • said HSS server responds to said l-CSCF server by providing an identifier of said nominal S-CSCF server,
  • the l-CSCF server attempts to join this nominal S-CSCF server, but the attempt fails, and
  • the l-CSCF server sends the HSS server a request for capabilities to know what capabilities an S-CSCF server must have in order to provide all the authorized services for said user.
  • the HSS server in order to record the assignment to the user of said new S-CSCF server, registers an identifier of this new S-CSCF server in a dedicated piece of information of the user's profile.
  • the HSS server may advantageously read said information element, and respond to the second l-CSCF server by providing an identifier of said (single) assigned S-CSCF server to the user.
  • the invention relates to an HSS server of an IMS network, comprising means for:
  • Said HSS server is remarkable in that it also has means for recording the assignment to the user of the new S-CSCF server.
  • said HSS server can access an equivalence table whose each element is a pair of S-CSCF servers of said IMS network such that the second (respectively, first) S-CSCF server of this pair has at least all the capabilities of the first (respectively, second) S-CSCF server of this couple.
  • the HSS server can conveniently:
  • 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 service restoration methods succinctly set forth above, when run on a computer.
  • FIG. 1, described above schematically illustrates the successive steps of a conventional method of service restoration in the event of failure of an S-CSCF server
  • FIG. 2 schematically represents, by way of example, a system for providing multimedia services capable of implementing the invention
  • FIG. 3 schematically illustrates the successive steps of a service restoration method in case of failure of an S-CSCF server, according to one embodiment of the invention.
  • the system illustrated in FIG. 2 implements an IMS 1 type network architecture, as briefly presented above.
  • the Multimedia services offered by this IMS network 1 may include telephony services, video telephony, content-sharing ("content-sharing"), Presence, Instant Messaging, or television. These services are available to the user of a device-client ("User Equipment” or UE in English) 10 belonging to the network 1, which allows the UE 10 to exchange multimedia streams and signaling signals. session control according to the SIP protocol, for example with a UE 1 1.
  • This UE 10 may be a fixed or mobile terminal, or a home or enterprise gateway, having SIP signaling means and may include means for rendering audiovisual content.
  • this IMS network 1 comprises, in addition to an IP transport infrastructure (not shown):
  • the S-CSCF server 27 manages in particular the procedure for registering the devices connected to the network 1; the S-CSCF server 27 also manages the routing of the signaling between the UE 10 and the voicemail servers VM 25, Instant Messaging IM 26, and telephony TAS 29;
  • the l-CSCF server 22 notably manages the routing towards other client devices managed by the same IMS network 1 and the routing of the signaling between this IMS network 1 and other networks;
  • At least one P-CSCF server (initials of the English words "Proxy-Call Server Control Function” meaning "Proxy Call Session Control Function”);
  • the P-CSCF server 21 serves as a connection entity between the network 1 and the access network used by the UE 10;
  • the P-CSCF server 28 serves as a connection entity between the network 1 on the one hand, and the UE 1 1 or an access network used by the UE 11 on the other hand; all SIP signaling exchanged between the EU 10 (respectively 1 1) and the S-CSCF server 27 passes through the P-CSCF server 21 (respectively 28);
  • At least one database server, of the HSS type contains the profile of the user of the UE 10 in terms of authentication data, location and subscribed services;
  • At least one VM-25 voice mail server (“message-summary"); the server VM 25 manages an eventual subscription of the UE 10 to the message depot / consultation events for the user of the UE 10, and notifies the client device 10 at the occurrence of these events. ;
  • At least one TAS 29 telephony server the TAS server manages any telephone services to which the user of the UE 10 has subscribed with the network operator 1, such as the presentation of the number or call forwarding.
  • Instant IM 26, and TAS telephony 29 are examples of so-called AS (initials of the English words "Application Servers” meaning “Application Servers”).
  • S-CSCF 27 verifies that this service complies with the subscription of this user to the operator of the network 1, and f) in the event of compliance, S-CSCF 27 forward the request to an appropriate EU 10 contact address; for example, if the UE 10 is a VoIP telephone, and if the required service is a telephone call to the telephone number of the user of the UE 10, said contact address is usually an IP address associated with said number phone.
  • FIG. 3 illustrates an embodiment of this method according to the invention.
  • the steps ⁇ to E'5 are similar to the steps E1 to E5 described above with reference to FIG.
  • step E'6 unlike the state of the art, it is the HSS server that selects the new S-CSCF server to assign the user to replace the failed S-CSCF server.
  • the HSS server operates an equivalence table according to the invention to which it has access.
  • the equivalence table can be constructed as follows.
  • the first column of this table represents a list of S-CSCF servers.
  • a second column indicates, on the same line as a given S-CSCF server of the first column, an "equivalent" S-CSCF server, that is to say an S-CSCF server having at least the capacities of said server S-CSCF given, and who can replace this server S-CSCF given in case of failure.
  • the equivalence table further comprises a third column containing an index referencing each pair S-CSCF / S-CSCF-equivalent.
  • the contents of the equivalence table are known, not only of the HSS server, but also of all the I-CSCF servers of the IMS network.
  • the equivalence table does not include this third column.
  • the contents of the equivalence table are known to the HSS server, but are not shared with the l-CSCF servers.
  • S4 has S1 (index 6), but that meanwhile S1 has no equivalent since S4 S4 lacks the capacity C 3 to regain the overall capacity of S1.
  • it is the S-CSCF server S3 that had been nominally associated with the user.
  • the HSS server can therefore select the S-CSCF server S1 (index 3), or the S-CSCF server S2 (index 4), or the S-CSCF server S4 (index 5) instead of the S-CSCF server S3.
  • the HSS server selects the S-CSCF server S1.
  • the HSS server updates the user's profile accordingly, for example by entering an identifier of the S-CSCF server S1 in an "S-CSCF-Restoration-Info" field, as defined in the TS 29.229 specification. 3GPP; more precisely, this "S-CSCF-Restoration-Info" field will, for the implementation of the present invention, include a dedicated piece of information, in which the HSS server will write said identifier.
  • the HSS server can advantageously select (for example) the S-CSCF server S2 for this other user, in order to perform load sharing to all the S-CSCF servers equivalent to S3.
  • the HSS responds to the server l-CSCF No. 1 (second message "Diameter LIA") by providing an identifier of the new server S-CSCF (ie, S1) assigned to the user. More specifically, in the context of the first variant mentioned above, the HSS server searches for the S-CSCF server S3 in the equivalence table, finds therein the information of equivalence with S1, reads the corresponding index (at know, "3") and sends this index "3" to the server l-CSCF No. 1 to indict the selection of the server S-CSCF S1. In the context of the second variant mentioned above, the server HSS sends to the server l-CSCF No.
  • an identifier of said server S-CSCF (ie, S1) that the HSS server selected; the advantage of this second variant lies in the fact that it is not necessary to share the equivalence table with the l-CSCF servers, resulting in savings in terms of storage and operating costs compared to in the first variant.
  • CSCF # 1 receives this identifier from the HSS server and takes it into account.
  • the server l-CSCF No. 1 therefore follows the service request No. 1 to the server S1 as server S-CSCFN ° 2.
  • a new service request (No. 2) for the same user as the service request (No. 1) is received by a second I-CSCF server (No. 2) of the IMS network (this second I-CSCF server (No. 2) may or may not be different from the first server l-CSCF (No. 1)).
  • the l-CSCF server No. 2 contains a "first" location procedure ("LIR Diameter” message) to the HSS server.
  • a step ⁇ similar to the step E10 described above with reference to FIG. 1, the server HSS responds to the server l-CSCF No. 2 by supplying it with an identifier of the new server S-CSCF assigned to the user (ie, S1).
  • the l-CSCF server No. 2 receives this identifier from the HSS server and takes it into account. It therefore follows the request No. 2 to the S-CSCF server S1, that is to say to the same server S-CSCF that the one to which the server l-CSCF No. 1 has forwarded the request No. 1.
  • the S-CSCF server No. 2 updates the HSS server with its own reference (ie, S1 ) (message "Diameter SAR"), so that the S-CSCF server No. 2 is now the nominal S-CSCF server in charge of said user.
  • the HSS server confirms this update ("Diameter SAA" message).
  • the implementation of the invention within nodes of an IMS network, in particular within HSS servers, can be achieved by means of software and / or hardware components.
  • 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 service restoration method 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 service restoration method according to the invention, when it is executed 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 an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, such as a hard disk, or a USB key. (“USB flash drive" in English).
  • 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 service restoration method according to the invention.

Landscapes

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

Abstract

La présente invention concerne un procédé de restauration de service dans un réseau IMS, comprenant les étapes suivantes : une requête de service (N° 1) visant un utilisateur dudit réseau IMS (1) est reçue (E'1) par un serveur I-CSCF (N° 1) de ce réseau IMS (1); ledit serveur I-CSCF (N° 1) envoie (E'2) au serveur HSS du réseau IMS (1) en charge dudit utilisateur une requête visant à connaître l'identité du serveur S-CSCF (N° 1) nominal associé audit utilisateur; le serveur HSS sélectionne (E'6) un nouveau serveur S-CSCF (N° 2) apte à fournir l'ensemble des services autorisés pour l'utilisateur, enregistre l'assignation à l'utilisateur dudit nouveau serveur S-CSCF (N° 2), et fournit au serveur I- CSCF (N° 1) un identifiant du nouveau serveur S-CSCF (N° 2) assigné à l'utilisateur; le serveur I-CSCF (N° 1) prend en compte (E'7) ledit identifiant du nouveau serveur S-CSCF (N° 2), et fait suivre la requête de service (N° 1) vers ce nouveau serveur S-CSCF (N° 2).

Description

PROCEDE DE RESTAURATION DE SERVICE DANS UN RESEAU IMS
La présente invention concerne les réseaux de communications de type 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 notamment la transmission de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ».
Plus particulièrement, la présente invention concerne le routage d'une requête de service, par exemple un appel de VoIP, vers un dispositif-client appartenant à un réseau IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »).
On notera à cet égard que, dans le cadre de la présente invention, un dispositif-client (« User Equipment » en anglais) est dit « appartenir » au réseau d'un opérateur donné lorsque l'utilisateur de ce dispositif-client possède un compte auprès de cet opérateur, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter au réseau de l'opérateur. Ces dispositifs-clients peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, 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 Line 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 {Internet Engineering Task Force) 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 a ensuite été étendu notamment dans le document RFC 3265. Cette extension permet des procédures de notification d'événements.
Le protocole SIP est utilisé en particulier dans les infrastructures de type IMS, mentionné ci-dessus. L'IMS a été défini par l'organisme 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 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 œuvre 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 tels que la téléphonie, la visiophonie, et la Messagerie Instantanée, dont elle gère aussi l'interaction. On rappelle par exemple que la Messagerie Instantanée (« Instant Messaging », ou IM, en anglais), également appelée « tchat » (appellation dérivée du mot anglais « chat » signifiant « bavardage »), permet l'échange quasi-instantané de messages textuels et de fichiers, ce qui permet un dialogue interactif entre deux utilisateurs connectés au même réseau (tel qu'Internet).
Lorsqu'un utilisateur souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes.
Tout d'abord, le dispositif-client de l'utilisateur doit, sauf exceptions (telles que certains appels d'urgence), 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 dispositif-client 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 dispositif-client 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 dispositifs-clients, les réseaux
IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés serveurs « S-CSCF » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), 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, appelés serveurs « l-CSCF » (initiales des mots anglais « Interrogating- Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») — d'ailleurs souvent combinés physiquement avec les serveurs de type S-CSCF pour constituer des serveurs dénotés « l/S-CSCF »— 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é de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les capacités requises pour pouvoir fournir tous les services autorisés pour l'utilisateur du dispositif-client. Ces « capacités » sont définies de manière précise dans le Chapitre 6.7 de la spécification TS 29.228 du 3GPP (cf. notamment la Table 6.7).
Les serveurs HSS sont l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS peut accéder à une base de données-clients, définie dans la spécification TS 23.008 du 3GPP (cf. notamment la Section 3) : ces données-client concernent par exemple, pour chaque utilisateur du réseau IMS, l'état d'enregistrement du dispositif-client associé, ainsi que des données d'authentification et de localisation. Dans le cadre de la présente invention, une telle base de données (qu'elle obéisse ou non à la spécification TS 23.008) sera désignée par « profil de l'utilisateur ».
Après qu'un serveur S-CSCF lui a été ainsi attribué, chaque utilisateur peut faire usage d'un certain nombre de services pendant la connexion en cours. Il peut par exemple s'agir de services offerts automatiquement à tous les utilisateurs du réseau IMS. Il peut aussi s'agir de services auxquels cet utilisateur a souscrit auprès de l'opérateur du réseau, et qui sont mis automatiquement à sa disposition. Enfin, il peut s'agir de services dont l'utilisateur peut faire usage après avoir émis une requête appropriée (SIP SUBSCRIBE).
Ces services comprennent des applications audiovisuelles telles que mentionnées ci-dessus. Il peut s'agir également d'une souscription à l'état d'une ressource, auquel cas des notifications d'événement (SIP NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; par exemple, lorsque l'utilisateur d'un dispositif-client dispose d'une boîte vocale sur le réseau, il pourra être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; un utilisateur peut, de même, demander à être notifié de l'état d'enregistrement de son propre dispositif-client.
Le 3GPP a défini dans la spécification TS 23.380 une procédure de restauration du service IMS en cas de panne d'un serveur S-CSCF. En particulier, cette spécification propose dans sa Section 4.3.3 la sélection par un serveur l-CSCF d'un nouveau serveur S-CSCF pour le traitement des appels arrivés, de telle sorte qu'un utilisateur dont le serveur S-CSCF nominal est tombé en panne ne s'aperçoive pas de la panne et que les appels qui lui sont destinés continuent à lui être délivrés (la notion de serveur S-CSCF « nominal » est définie dans la Section 3.2.2 de la spécification TS 23.008 mentionnée ci-dessus).
Or les auteurs de la présente invention ont réalisé que, si cette procédure de restauration est adéquate dans le cas d'un réseau IMS comprenant un serveur l-CSCF unique et apte à sélectionner toujours le même serveur S-CSCF de remplacement, elle est inadéquate dans le cas d'un réseau IMS usuel, lequel comprend, soit plusieurs serveurs l-CSCF (cas le plus fréquent, pour des raisons de capacité du réseau), soit un unique serveur l-CSCF (du type « proxy stateless ») pouvant a priori sélectionner des serveurs S-CSCF de remplacement différents d'une requête de service à l'autre.
Par exemple, lorsque le réseau comprend plusieurs serveurs I- CSCF, ces serveurs l-CSCF se trouvent en concurrence mutuelle sur les procédures de restauration. Ce problème est illustré ci-dessous par un exemple, en référence à la figure 1.
Lors d'une étape E1 , une requête de service (N ° 1 ) visant un certain utilisateur d'un réseau IMS est reçue par un serveur l-CSCF (N ° 1 ) de ce réseau.
Lors d'une étape E2, ce serveur l-CSCF N ° 1 initie une procédure dite « première procédure de localisation » (message « Diameter LIR ») vers le serveur HSS en charge dudit utilisateur, pour connaître l'identité du serveur S-CSCF (N ° 1 ) nominal assigné à cet utilisateur.
Lors d'une étape E3, le serveur HSS répond au serveur l-CSCF N ° 1 (message « Diameter LIA ») en fournissant un identifiant du serveur S- CSCF nominal ; il s'agit par exemple d'un serveur S-CSCF appelé « S3 ».
Cette « première » procédure de localisation, mise en œuvre aux étapes E2 et E3, est décrite dans la spécification TS 29.228 (mentionnée ci-dessus) au Chapitre 6.1 .4 (cf. notamment la Table 6.1 .4.1 ). Dans les échanges « Diameter » entre un serveur l-CSCF et un serveur HSS, l'utilisateur est identifié au moyen de son IMPU (initiales des mots anglais « IP Multimedia PUblic identity » signifiant « Identité Publique pour IP Multimédia »).
Lors d'une étape E4, le serveur l-CSCF N ° 1 tente de joindre le serveur S-CSCF S3 pour lui transmettre la requête N ° 1 , mais la tentative échoue ; cela peut être dû à une panne du serveur S-CSCF S3, ou à une panne du lien entre le serveur l-CSCF N ° 1 et le serveur S-CSCF S3.
Lors d'une étape E5, le serveur l-CSCF N ° 1 initie donc une procédure de restauration conformément à la spécification TS 23.380 mentionnée ci-dessus. Pour ce faire, le serveur l-CSCF N ° 1 initie une « deuxième procédure de localisation », dans laquelle le serveur l-CSCF N ° 1 envoie une « requête de capacités » (deuxième message « Diameter LIR ») au serveur HSS, afin de savoir quelles capacités un serveur S- CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur.
Lors d'une étape E6, le serveur HSS répond au serveur l-CSCF N °
1 (deuxième message « Diameter LIA ») en indiquant quelles sont lesdites capacités.
Lors d'une étape E7, le serveur l-CSCF N ° 1 sélectbnne un nouveau serveur S-CSCF (S-CSCF N ° 2) ayant les capacités requises pour fournir l'ensemble des services autorisés pour cet utilisateur ; supposons par exemple que le serveur S-CSCF sélectionné porte l'identifiant « S2 ». Le serveur l-CSCF N ° 1 fait ensuite suivre la requête N ° 1 vers ce serveur S-CSCF N ° 2 (i.e., S2).
Lors d'une étape E8, une nouvelle requête de service (N ° 2), visant le même utilisateur que la requête de service N ° 1 , est reçue par un serveur l-CSCF (N ° 2) du réseau IMS ; on notera que ce serveur l-CSCF N ° 2 peut éventuellement être identique au serveur l-CSCF N ° 1 .
Lors d'une étape E9, analogue à l'étape E2 ci-dessus, le serveur I- CSCF N° 2 initie une « première » procédure de localisation (message « Diameter LIR ») vers le serveur HSS en charge dudit utilisateur pour connaître l'identité du serveur S-CSCF (N ° 1 ) nominal associé à cet utilisateur.
Lors d'une étape E10, analogue à l'étape E3 ci-dessus, le serveur HSS répond au serveur l-CSCF N ° 2 (message « Diameter LIA ») en fournissant un identifiant du serveur S-CSCF nominal, i.e. S3.
Lors d'une étape E1 1 , analogue à l'étape E4 ci-dessus, le serveur l-CSCF N ° 2 tente de joindre le serveur S-CSCF S3 pur lui transmettre la requête N ° 2, et la tentative échoue.
Parallèlement, lors d'une étape E12, le serveur S-CSCF N ° 2 met à jour le serveur HSS avec sa propre référence (i.e., S2) (message « Diameter SAR »), puisque, suite à l'étape E7 ci-dessus, ce serveur S- CSCF S2 considère qu'il est dorénavant le serveur S-CSCF nominal pour ledit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »).
Lors d'une étape E13, analogue à l'étape E5 ci-dessus, le serveur I-
CSCF N ° 2 envoie une requête de capacités (deuxième message « Diameter LIR ») au serveur HSS, afin de savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur. Lors d'une étape E14, analogue à l'étape E6 ci-dessus, le serveur HSS répond au serveur l-CSCF N ° 2 (deuxième message « Diameter LIA ») en indiquant quelles sont lesdites capacités.
Lors d'une étape E15, analogue à l'étape E7 ci-dessus, le serveur I- CSCF N ° 2 sélectionne un nouveau serveur S-CSCF (N ° 3) ayant les capacités requises pour pouvoir fournir l'ensemble des services autorisés pour cet utilisateur ; il s'agit par exemple d'un serveur S-CSCF appelé « S4 ». En effet, selon l'état de l'art, le serveur S-CSCF N ° 3 sélectionné par le serveur l-CSCF N ° 2 peut, le cas échéant, été identique au serveur S-CSCF N ° 2, mais peut aussi bien en être distinct. Le serveur l-CSCF N ° 2 fait ensuite suivre la requête N ° 2 vers ce serveur S-CSCF N ° 3 (i.e., S4).
Lors d'une étape E16, analogue à l'étape E12 ci-dessus, le serveur S-CSCF N ° 3 met alors à jour le serveur HSS avec sa propre référence (i.e., S4) (message « Diameter SAR »), puisque, suite à l'étape E15 précédente, ce serveur S-CSCF S4 considère qu'il est dorénavant le serveur S-CSCF nominal pour ledit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »).
Mais, lors d'une étape E17, les appels initiés sur le serveur S-CSCF N ° 2 (i.e., S2) sont cassés lorsque le serveur HSS informe ce dernier qu'un nouveau serveur S-CSCF (i.e., S4) est désormais nominalement en charge de l'utilisateur. En effet, dans un réseau IMS, il ne peut y avoir du point de vue du serveur HSS qu'un seul serveur S-CSCF nominal assigné à un utilisateur donné. Cet utilisateur risque donc de voir certains de ses appels en arrivée libérés, ce qui peut être très fâcheux, notamment si le trafic à son intention est important (par exemple si ledit utilisateur est une entreprise et son dispositif-client est un PABX).
On constate le même problème dans un procédé divulgué par la demande EP 1988662. Ce procédé débute par des étapes analogues aux étapes E1 et E2 ci-dessus, mais ensuite c'est le serveur HSS lui-même qui détecte que le serveur S-CCF nominal est en panne. Le serveur HSS choisit alors un nouveau serveur S-CSCF (appelons-le « S5 »), et fournit un identifiant de ce nouveau serveur S-CSCF S5 au serveur l-CSCF, qui fait ensuite suivre la requête vers ce serveur S-CSCF S5. Parallèlement, selon ce procédé, le serveur HSS notifie l'utilisateur, via le serveur S- CSCF S5, qu'il doit se réenregistrer sur le réseau. Or, lorsque l'utilisateur se réenregistre, il lui est naturellement assigné un nouveau serveur S- CSCF nominal (appelons-le « S6 »), mais rien dans le procédé selon EP 1988662 ne vient garantir que ce serveur S-CSCF nominal S6 sera le même que le serveur S-CSCF S5 ! L'utilisateur risque donc de voir certains de ses appels en arrivée libérés, comme dans l'exemple ci- dessus.
La présente invention concerne donc un procédé de restauration de service dans un réseau IMS, comprenant les étapes suivantes :
a) une requête de service visant un utilisateur dudit réseau IMS est reçue par un serveur l-CSCF de ce réseau IMS,
b) ledit serveur l-CSCF envoie au serveur HSS du réseau IMS en charge dudit utilisateur une requête visant à connaître l'identité du serveur S-CSCF nominal associé audit utilisateur,
c) le serveur HSS sélectionne un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur, et fournit au serveur l-CSCF un identifiant du nouveau serveur S-CSCF, et d) le serveur l-CSCF prend en compte ledit identifiant du nouveau serveur S-CSCF, et fait suivre la requête de service vers ce nouveau serveur S-CSCF.
Ledit procédé est remarquable en ce que le serveur HSS enregistre l'assignation à l'utilisateur du nouveau serveur S-CSCF.
Grâce à l'invention, on peut indiquer à tout serveur l-CSCF ayant reçu une requête de service visant un certain utilisateur, non seulement (de manière classique) l'identité du serveur S-CSCF nominal pour cet utilisateur, mais aussi, suite à une panne de ce serveur S-CSCF nominal, l'identité d'un unique serveur S-CSCF pour traiter les requêtes de service concernant cet utilisateur, à la place du serveur S-CSCF en panne. On évite ainsi les resélections contradictoires selon l'état de l'art, et les pertes d'appels qui en résultent.
Ledit serveur HSS peut être informé de diverses manières du fait que ledit serveur S-CSCF nominal de l'utilisateur est en panne ou est injoignable. Selon des caractéristiques particulières, ledit procédé comprend en outre, entre lesdites étapes b) et c), les étapes suivantes :
- ledit serveur HSS répond audit serveur l-CSCF en fournissant un identifiant dudit serveur S-CSCF nominal,
- le serveur l-CSCF tente de joindre ce serveur S-CSCF nominal, mais la tentative échoue, et
- le serveur l-CSCF envoie au serveur HSS une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur.
Selon d'autres caractéristiques particulières, pour enregistrer l'assignation à l'utilisateur dudit nouveau serveur S-CSCF, le serveur HSS inscrit un identifiant de ce nouveau serveur S-CSCF dans un élément d'information dédié du profil de l'utilisateur.
Grâce à ces dispositions, si une autre requête de service visant le même utilisateur est ensuite reçue par un deuxième serveur l-CSCF (différent ou non du premier serveur l-CSCF susmentionné), et que ledit deuxième serveur l-CSCF interroge le serveur HSS pour connaître l'identité du serveur S-CSCF nominal associé à cet utilisateur, le serveur HSS pourra avantageusement lire ledit élément d'information, et répondre au deuxième serveur l-CSCF en lui fournissant un identifiant dudit (unique) serveur S-CSCF assigné à l'utilisateur. Corrélativement, l'invention concerne un serveur HSS d'un réseau IMS, comprenant des moyens pour :
- recevoir, de la part d'un serveur l-CSCF, une requête visant à connaître l'identité du serveur S-CSCF nominal associé à un utilisateur, dont ledit serveur HSS a la charge, dudit réseau IMS,
- répondre audit serveur l-CSCF en fournissant un identifiant dudit serveur S-CSCF nominal,
- recevoir, de la part du serveur l-CSCF, une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur,
- sélectionner un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur, et
- fournir au serveur l-CSCF un identifiant dudit nouveau serveur S- CSCF.
Ledit serveur HSS est remarquable en ce qu'il possède en outre des moyens pour enregistrer l'assignation à l'utilisateur du nouveau serveur S- CSCF.
Les avantages offerts par ce serveur HSS sont essentiellement les mêmes que ceux offerts par le procédé corrélatif succinctement exposé ci- dessus.
Selon des caractéristiques particulières, ledit serveur HSS peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau IMS tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple.
Grâce à ces dispositions, le serveur HSS peut commodément :
- sélectionner un nouveau serveur S-CSCF apte à fournir l'ensemble des services autorisés pour l'utilisateur, et - fournir au serveur l-CSCF un identifiant d'un nouveau serveur S- CSCF assigné à l'utilisateur, sous la forme d'un index pointant vers un élément de ladite table d'équivalences.
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 restauration de service 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 ledit procédé.
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 dessins qui l'accompagnent, dans lesquels :
- la figure 1 , décrite ci-dessus, illustre schématiquement les étapes successives d'un procédé classique de restauration de service en cas de panne d'un serveur S-CSCF,
- la figure 2 représente schématiquement, à titre d'exemple, un système pour la fourniture de services multimédia apte à mettre en œuvre l'invention, et
- la figure 3 illustre schématiquement les étapes successives d'un procédé de restauration de service en cas de panne d'un serveur S- CSCF, selon un mode de réalisation de l'invention.
Le système illustré sur la figure 2 met en œuvre une architecture de réseau de type IMS 1 , tel que présenté succinctement ci-dessus. Les services multimédia offerts par ce réseau IMS 1 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 dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1 , qui permet à l'UE 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, par exemple avec un UE 1 1 .
Cet UE 10 peut être 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 2, ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) :
• au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre l'UE 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 ;
• au moins un serveur l-CSCF ; le serveur l-CSCF 22 gère notamment le routage en direction d'autres dispositifs-clients gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux ;
• au moins un serveur P-CSCF (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Mandataire ») ; le serveur P-CSCF 21 sert d'entité de raccordement entre le réseau 1 et le réseau d'accès utilisé par l'UE 10 ; le serveur P-CSCF 28 sert d'entité de raccordement entre le réseau 1 d'une part, et l'UE 1 1 ou un réseau d'accès utilisé par l'UE 1 1 d'autre part ; toute la signalisation SIP échangée entre l'UE 10 (respectivement 1 1 ) et le serveur S-CSCF 27 passe par le serveur P- CSCF 21 (respectivement 28) ;
• au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur de l'UE 10 en termes de données d'authentification, de localisation et de services souscrits ;
• au moins un serveur VM 25 de messagerie vocale (« message- summary » en anglais) ; le serveur VM 25 gère une éventuelle souscription de l'UE 10 aux événements de dépôt/consultation des messages à l'intention de l'utilisateur de l'UE 10, et notifie le dispositif-client 10 lors de l'occurrence de ces événements ;
• au moins un serveur de Messagerie Instantanée IM 26 (mentionné ci-dessus) ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres utilisateurs de ce service ; et
• au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les éventuels services téléphoniques auxquels l'utilisateur de l'UE 10 a souscrits auprès de l'opérateur du réseau 1 , tels que la présentation du numéro ou le renvoi d'appel.
Les serveurs de messagerie vocale VM 25, de Messagerie
Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de ce que l'on appelle des AS (initiales des mots anglais « Application Servers » signifiant « Serveurs d'Applications »).
Selon la norme TS 24.229 du 3GPP (cf. notamment, dans la version 1 1 .5.0 de cette norme, la clause 5.4.3.3, items 3C and 3D, ainsi que l'Annexe I), lorsque le S-CSCF 27 reçoit du serveur l-CSCF 22 une requête de service visant l'utilisateur qui a préalablement enregistré l'UE 10 :
e) le S-CSCF 27 vérifie que ce service est conforme à la souscription de cet utilisateur auprès de l'opérateur du réseau 1 , et f) en cas de conformité, le S-CSCF 27 fait suivre la requête vers une adresse de contact adéquate de l'UE 10 ; par exemple, si l'UE 10 est un téléphone de VoIP, et si le service requis est un appel téléphonique vers le numéro de téléphone de l'utilisateur de l'UE 10, ladite adresse de contact est habituellement une adresse IP associée audit numéro de téléphone.
Afin, notamment, de remédier aux problèmes exposés ci-dessus en référence à la figure 1 , l'invention propose un nouveau procédé de restauration de service pour la gestion des requêtes en arrivée. La figure 3 illustre un mode de réalisation de ce procédé selon l'invention.
Les étapes ΕΊ à E'5 sont analogues aux étapes E1 à E5 décrites ci-dessus en référence à la figure 1 .
Lors d'une étape E'6, contrairement à l'état de l'art, c'est le serveur HSS qui sélectionne le nouveau serveur S-CSCF à assigner à l'utilisateur pour remplacer le serveur S-CSCF nominal en panne.
Pour ce faire, le serveur HSS exploite une table d'équivalences selon l'invention, à laquelle il a accès.
Cette table contient des équivalences en termes de « capacités » Cb où i = 1,2, telles que mentionnées ci-dessus, de l'ensemble des serveurs S-CSCF ou d'une partie d'entre eux (en fait, la spécification TS 29.228 distingue des capacités obligatoires et des capacités optionnelles, mais la présente invention ne vise que les capacités obligatoires).
La table d'équivalences peut être construite de la manière suivante. La première colonne de cette table représente une liste de serveurs S- CSCF. Une deuxième colonne indique, sur la même ligne qu'un serveur S-CSCF donné de la première colonne, un serveur S-CSCF « équivalent », c'est-à-dire un serveur S-CSCF possédant au moins les capacités dudit serveur S-CSCF donné, et qui donc pourra remplacer ce serveur S-CSCF donné en cas de panne. Selon une première variante, la table d'équivalences comprend en outre une troisième colonne contenant un index référençant chaque couple S-CSCF/S-CSCF-équivalent. Dans cette première variante, le contenu de la table d'équivalences est connu, non seulement du serveur HSS, mais aussi de l'ensemble des serveurs l-CSCF du réseau IMS.
Selon une deuxième variante, la table d'équivalences ne comprend pas cette troisième colonne. Dans cette deuxième variante, le contenu de la table d'équivalences est connu du serveur HSS, mais n'est pas partagé avec les serveurs l-CSCF.
Prenons par exemple un ensemble de quatre serveurs S-CSCF ayant les capacités suivantes :
51 [Cl t C2, C3],
52 [Cl t C2 l C3
53 [C , et
54 [C , C2].
Si l'on choisit par exemple la première variante mentionnée ci-dessus, la table d'équivalences se présente alors ainsi :
Figure imgf000018_0001
On voit par exemple que S4 possède un équivalent en S1 (index 6), mais que S1 quant à lui ne possède pas d'équivalent en S4 puisqu'il manque à S4 la capacité C3 pour retrouver l'ensemble des capacités de S1 . Dans l'exemple de réalisation considéré, c'est le serveur S-CSCF S3 qui avait été nominalement associé à l'utilisateur. Le serveur HSS peut donc sélectionner le serveur S-CSCF S1 (index 3), ou le serveur S-CSCF S2 (index 4), ou encore le serveur S-CSCF S4 (index 5) en remplacement du serveur S-CSCF S3.
Supposons que le serveur HSS sélectionne le serveur S-CSCF S1 . Le serveur HSS met alors à jour le profil de l'utilisateur en conséquence, par exemple en inscrivant un identifiant du serveur S-CSCF S1 dans un champ « S-CSCF-Restoration-Info », tel que défini dans la spécification TS 29.229 du 3GPP ; plus précisément, ce champ « S-CSCF-Restoration- Info » devra, pour la mise en œuvre de la présente invention, comporter un élément d'information dédié, dans lequel le serveur HSS inscrira ledit identifiant.
On notera au passage que si, ultérieurement, le serveur HSS reçoit une requête de capacités concernant un autre utilisateur auquel était également associé le serveur S-CSCF S3 en tant que serveur S-CSCF nominal, le serveur HSS pourra avantageusement sélectionner (par exemple) le serveur S-CSCF S2 pour cet autre utilisateur, cela afin de réaliser un partage de charge vers l'ensemble des serveurs S-CSCF équivalents à S3.
Le HSS répond alors au serveur l-CSCF N ° 1 (deuxième message « Diameter LIA ») en lui fournissant un identifiant du nouveau serveur S- CSCF (i.e., S1 ) assigné à l'utilisateur. Plus précisément, dans le cadre de la première variante mentionnée ci-dessus, le serveur HSS recherche le serveur S-CSCF S3 dans la table d'équivalences, y trouve l'information d'équivalence avec S1 , lit l'index correspondant (à savoir, « 3 ») et envoie cet index « 3 » au serveur l-CSCF N ° 1 pour lui indquer la sélection du serveur S-CSCF S1 . Dans le cadre de la deuxième variante mentionnée ci-dessus, le serveur HSS envoie au serveur l-CSCF N ° 1 , sous une autre forme que ledit index, un identifiant dudit serveur S-CSCF (i.e., S1 ) que le serveur HSS a sélectionné ; l'avantage de cette deuxième variante réside dans le fait qu'il n'est pas nécessaire de partager la table d'équivalences avec les serveurs l-CSCF, d'où une économie en termes de stockage et de coûts d'exploitation par rapport à la première variante.
Lors d'une étape E7, contrairement à l'état de l'art, le serveur I-
CSCF N ° 1 reçoit cet identifiant de la part du serveur HSS et le prend en compte. Le serveur l-CSCF N ° 1 fait donc suivre la requête de service N ° 1 vers le serveur S1 en tant que serveur S-CSCFN ° 2.
Lors d'une étape E'8, analogue à l'étape E8 décrite ci-dessus en référence à la figure 1 , une nouvelle requête de service (N ° 2) visant le même utilisateur que la requête de service (N ° 1 ) est reçue par un deuxième serveur l-CSCF (N ° 2) du réseau IMS (ce deuxième serveur I- CSCF (N ° 2) pouvant être différent ou non du premiff serveur l-CSCF (N ° 1 )).
Lors d'une étape E'9, analogue à l'étape E9 décrite ci-dessus en référence à la figure 1 , le serveur l-CSCF N ° 2 intie une « première » procédure de localisation (message « Diameter LIR ») vers le serveur HSS.
Lors d'une étape ΕΊ 0, analogue à l'étape E10 décrite ci-dessus en référence à la figure 1 , le serveur HSS répond au serveur l-CSCF N ° 2 en lui fournissant un identifiant du nouveau serveur S-CSCF assigné à l'utilisateur (i.e., S1 ).
Lors d'une étape ΕΊ 1 , le serveur l-CSCF N ° 2 reçot cet identifiant de la part du serveur HSS et le prend en compte. Il fait donc suivre la requête N ° 2 vers le serveur S-CSCF S1 , c'est-à-die vers le même serveur S-CSCF que celui à qui le serveur l-CSCF N ° 1 a fait suivre la requête N ° 1 .
Parallèlement, lors d'une étape ΕΊ 2, analogue à l'étape E12 décrite ci-dessus en référence à la figure 1 , le serveur S-CSCF N ° 2 met alors à jour le serveur HSS avec sa propre référence (i.e., S1 ) (message « Diameter SAR »), de sorte que le serveur S-CSCF N ° 2 est désormais le serveur S-CSCF nominal en charge dudit utilisateur. Le serveur HSS confirme cette mise à jour (message « Diameter SAA »).
On voit donc que, grâce à l'invention, les risques de sélection de serveurs S-CSCF de restauration multiples sont évités ; les libérations précoces ou les pertes d'appels sont donc également évitées.
La mise en œuvre de l'invention au sein de nœuds d'un réseau IMS, notamment au sein de serveurs HSS, 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 restauration de service 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 restauration de service 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, inamovible, ou partiellement ou totalement amovible, 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 comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
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 restauration de service selon l'invention.

Claims

REVENDICATIONS
1. Procédé de restauration de service dans un réseau IMS, comprenant les étapes suivantes :
a) une requête de service (N° 1) visant un utilisateur dudit réseau IMS (1) est reçue (ΕΊ) par un serveur l-CSCF (N° 1) de ce réseau IMS (1),
b) ledit serveur l-CSCF (N° 1) envoie (E'2) au serveur HSS du réseau IMS (1) en charge dudit utilisateur une requête visant à connaître l'identité du serveur S-CSCF (N° 1) nominal associé audit utilisateur,
c) le serveur HSS sélectionne (E'6) un nouveau serveur S-CSCF (N° 2) apte à fournir l'ensemble des services autoirsés pour l'utilisateur, et fournit au serveur l-CSCF (N° 1)un identifiant dudit nouveau serveur S-CSCF (N° 2), et
d) le serveur l-CSCF (N° 1) prend en compte (E7) èdit identifiant du nouveau serveur S-CSCF (N° 2), et fait suivre la requête de service (N° 1) vers ce nouveau serveur S-CSCF (N° %, caractérisé en ce que le serveur HSS enregistre l'assignation à l'utilisateur du nouveau serveur S-CSCF (N° 2).
2. Procédé de restauration de service selon la revendication 1, caractérisé en ce qu'il comprend en outre, entre lesdites étapes b) et c), les étapes suivantes :
- ledit serveur HSS répond (E'3) audit serveur l-CSCF (N° 1) en fournissant un identifiant dudit serveur S-CSCF (N° 1) nominal,
- le serveur l-CSCF (N° 1) tente (E'4) de joindre serveur S-CSCF nominal (N° 1), mais la tentative échoue, et
- le serveur l-CSCF (N° 1) envoie (E'5) au serveur HSS une requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur.
3. Procédé de restauration de service selon la revendication 1 ou la revendication 2, caractérisé en ce que, pour enregistrer l'assignation à l'utilisateur dudit nouveau serveur S-CSCF (N ° 2), le serveur HSS inscrit un identifiant de ce nouveau serveur S-CSCF (N ° 2) dans un élément d'information dédié du profil de l'utilisateur.
4. Serveur HSS d'un réseau IMS, comprenant des moyens pour :
- recevoir, de la part d'un serveur l-CSCF (N ° 1 ), une requête visant à connaître l'identité du serveur S-CSCF (N ° 1 ) norrinal associé à un utilisateur, dont ledit serveur HSS a la charge, dudit réseau IMS (1 ),
- répondre audit serveur l-CSCF (N ° 1 ) en fournissait un identifiant dudit serveur S-CSCF (N ° 1 ) nominal,
- recevoir, de la part du serveur l-CSCF (N ° 1 ), ure requête de capacités visant à savoir quelles capacités un serveur S-CSCF doit posséder pour pouvoir fournir l'ensemble des services autorisés pour ledit utilisateur,
- sélectionner un nouveau serveur S-CSCF (N ° 2) apte à fournir l'ensemble des services autorisés pour l'utilisateur, et
- fournir au serveur l-CSCF (N ° 1 ) un identifiant dudit nouveau serveur S-CSCF (N ° 2),
caractérisé en ce qu'il possède en outre des moyens pour enregistrer l'assignation à l'utilisateur du nouveau serveur S-CSCF (N ° 2).
5. Serveur HSS selon la revendication 4, caractérisé en ce qu'il peut accéder à une table d'équivalences dont chaque élément est un couple de serveurs S-CSCF dudit réseau IMS (1 ) tels que le deuxième (respectivement, premier) serveur S-CSCF de ce couple possède au moins toutes les capacités du premier (respectivement, deuxième) serveur S-CSCF de ce couple.
6. 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 restauration de service selon l'une quelconque des revendications 1 à 3.
7. 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 restauration de service selon l'une quelconque des revendications 1 à 3, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2014/050859 2013-04-16 2014-04-10 Procede de restauration de service dans un reseau ims WO2014170582A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1353436 2013-04-16
FR1353436A FR3004612A1 (fr) 2013-04-16 2013-04-16 Procede de restauration de service dans un reseau ims

Publications (1)

Publication Number Publication Date
WO2014170582A1 true WO2014170582A1 (fr) 2014-10-23

Family

ID=48782394

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/050859 WO2014170582A1 (fr) 2013-04-16 2014-04-10 Procede de restauration de service dans un reseau ims

Country Status (2)

Country Link
FR (1) FR3004612A1 (fr)
WO (1) WO2014170582A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109995765A (zh) * 2019-03-11 2019-07-09 河北远东通信系统工程有限公司 一种ims网络agcf双归属注册方法

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1988662A1 (fr) 2006-02-20 2008-11-05 Huawei Technologies Co., Ltd. Procédé et système de mise en oeuvre de service d'appel

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1988662A1 (fr) 2006-02-20 2008-11-05 Huawei Technologies Co., Ltd. Procédé et système de mise en oeuvre de service d'appel

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Organization of subscriber data (Release 11)", 3GPP STANDARD; 3GPP TS 23.008, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. CT WG4, no. V11.6.0, 21 December 2012 (2012-12-21), pages 1 - 109, XP050691427 *
"3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Study on IMS Restoration Procedures (Release 9)", 3GPP STANDARD; 3GPP TR 23.820, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V9.0.0, 1 September 2009 (2009-09-01), pages 1 - 43, XP050363853 *
"RFC 3261", IETF
"Telecommunications and Internet Converged Services and Protocols for Advanced Networking", 3GPP

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109995765A (zh) * 2019-03-11 2019-07-09 河北远东通信系统工程有限公司 一种ims网络agcf双归属注册方法

Also Published As

Publication number Publication date
FR3004612A1 (fr) 2014-10-17

Similar Documents

Publication Publication Date Title
EP2772035B1 (fr) Procede de gestion d'une communication destinee a un utilisateur et serveur d'application
EP2504982B1 (fr) Procede de basculement d'un hss primaire sur un hss de secours dans un reseau ip
EP3085065A1 (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
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP2926524B1 (fr) Routage d'une requête de service visant un abonné ims
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d'un appelé
FR3011423A1 (fr) Technique de restauration d'un service dans un reseau
WO2020128258A1 (fr) Procédé de basculement d'une communication de tcp sur udp
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
WO2013079865A1 (fr) ENREGISTREMENT D'UN DISPOSITIF AUPRES D'UN COEUR DE RESEAU VoIP
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2017220883A1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3583757B1 (fr) Procédé de changement de réseau mobile
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
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
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

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14722695

Country of ref document: EP

Kind code of ref document: A1