WO2011055081A1 - Procede, terminal et serveur s-cscf aptes a gerer les enregistrements de l'identite publique d'un utilisateur dans un reseau ims - Google Patents

Procede, terminal et serveur s-cscf aptes a gerer les enregistrements de l'identite publique d'un utilisateur dans un reseau ims Download PDF

Info

Publication number
WO2011055081A1
WO2011055081A1 PCT/FR2010/052366 FR2010052366W WO2011055081A1 WO 2011055081 A1 WO2011055081 A1 WO 2011055081A1 FR 2010052366 W FR2010052366 W FR 2010052366W WO 2011055081 A1 WO2011055081 A1 WO 2011055081A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
record
public identity
terminal
records
Prior art date
Application number
PCT/FR2010/052366
Other languages
English (en)
Inventor
Sandrine Lataste
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2011055081A1 publication Critical patent/WO2011055081A1/fr

Links

Classifications

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

Definitions

  • Method, terminal and S-CSCF server capable of managing the records of the public identity of a user in an IMS network
  • the present invention is in the field of telecommunication networks, and more particularly in that of the management of user registration in an IMS (IP Multimedia Subsystem) network as specified by the 3GPP (3 rd Generation Partnership Project) in TS 23.228 and TS 24.229.
  • IMS IP Multimedia Subsystem
  • Figure 1 illustrates an example of a registration procedure that conforms to 3GPP specifications. It represents :
  • a User User Terminal UE
  • a GW Access Gateway or IP-Connectivity Access Network
  • P-CSCF entity in English "Proxy Call Session Control Function”
  • DNS server domain names (“Domain Name Server”
  • an I-CSCF entity English Interrogating Call Session Control Function
  • an S-CSCF entity an S-CSCF entity
  • a subscription data HSS server in English "Home Subscriber Server" of a nominal network.
  • the user terminal UE performs, in cooperation with the entity GW gateway packet network access, an attachment procedure useful to the establishment of a transmission link (in English " bearer ") and the discovery of a P-CSCF proxy, an entry point on the IMS network for the UE.
  • the user terminal UE sends, to the P-CSCF proxy discovered in step E1, a REGISTER registration request conforming to the SIP protocol. (in English "Session Initiation Protocol") to request to register a public identity of the user with a contact address of the terminal UE in the network.
  • SIP protocol in English "Session Initiation Protocol"
  • the P-CSCF proxy requests, during a step E3, the DNS server of domain names to obtain the address of the I-CSCF entity of the nominal network HN of the user.
  • the P-CSCF proxy then transmits, during a step E4, the REGISTER registration request received in step E2, to this I-CSCF entity.
  • the I-CSCF entity then queries, during a step E5, the subscriber data HSS server of the user to determine if this public identity is already registered in the network, and if so, for obtain the address of the S-CSCF server, or if it is not the case, to assign an S-CSCF server.
  • the entity I-CSCF then transmits, during a step E6, the REGISTER registration request received in step E4, to this server S-CSCF.
  • the server S-CSCF informs the subscribing server HSS data that it is designated as the registration server for the user and if necessary asks an authentication vector to challenge (or challenger) the user. This request is unprotected.
  • the server S-CSCF selects an authentication vector during a step E8 and proposes a challenge to the user by sending to the user terminal UE (step E9) a SIP message 401 Unauthorized, relayed (steps E10 and E1) until to the UE terminal by the entities I-CSCF and P-CSCF.
  • the user authenticates the S-CSCF server and generates a challenge response during a step E12. Then, the user terminal UE transmits (step E13) a registration request using the security parameters negotiated with the S-CSCF. This request is protected and routed to the S-CSCF server during steps E13 to E17 similar to the steps E2 to E6 already described.
  • the S-CSCF server authenticates the user during a step E18. During a step E19, it obtains the profile of this user by querying the subscription data server HSS and stores it.
  • the S-CSCF server returns a SIP 200 OK message for accepting the recording during a step E20, this message being relayed to the user terminal during the steps E21 and E22.
  • the user terminal UE must subscribe to the S-CSCF server to be notified of each record change.
  • This subscription is for a public identity associated with a contact address and a terminal instance if the terminal supports multiple registrations.
  • the S-CSCF server notifies the UE user terminal at each registration state change and especially after each successful registration as described in document TS 24.229 section 5.4.2.1.2. This notification covers all public identities of the user registered with the S-CSCF server.
  • FIG. 2 illustrates the main steps F1 to F12 of the registration procedure and registration state notification of the user, this procedure taking place after the steps already described with reference to FIG.
  • a first step F1 the user terminal UE requests the subscription by means of a SIP request SUBSCRIBE, this request being relayed (steps F2 and F3) to the server S-CSCF via the pre-established signaling path between them. during the recording.
  • the S-CSCF server verifies that the user is authorized therein during a step F4 and, if so, issues a subscription acceptance SIP response of type 200 OK. This response is relayed to the UE terminal during steps F5 and F6.
  • the server S-CSCF notifies the user terminal UE of all of its current records by means of a SIP request NCmFY.
  • This request is relayed to the UE in steps F8 and F9.
  • the user terminal UE responds with a SIP acceptance response of type 200 OK during a step F10, this response being relayed to the S-CSCF server during the steps Fil and F12.
  • the registration would be refused by the S-CSCF, the latter sending a rejection SIP response, for example of the 4xx, 5xx or 6xx type, to the UE. being relayed to the EU terminal by the I-CSCF and P-CSCF entities.
  • FIGS. 3A to 3C propose according to three possible implementations of the moment at which the S-CSCF server can send its rejection response, these implementations resulting from the documents TS 23.237 Section 4.2.1, TS 23.228 Section 5.2.1.
  • this rejection response can be sent: during a step E6b (FIG. 3A) upon reception of the registration request, before the challenge of the user and then relayed to the user terminal UE during steps E6c and E6d;
  • step E17b (FIG. 3B) upon reception of the registration request, after the challenge of the user, then relayed to the UE user terminal during steps
  • the object of the invention is to propose an implementation of the TS 23.237 Section 4.2.1, TS 23.228 Section 5.2.1 and TS 23.228 Section 5.2.2.3 specifications that do not have the above disadvantages.
  • the invention relates to a method for managing the records of the public identity of a user in an IMS network, this method comprising:
  • a step of implementing a record control policy comprising:
  • decision making is implicit in that it is identical to each new record.
  • the new record is systematically refused when the number of records of said public identity exceeds the maximum value.
  • the new registration is systematically accepted but gives rise to a systematic decision to terminate a registration of said public identity.
  • the invention relates to a system for managing the records of the public identity of a user in an IMS network, this system comprising:
  • the invention proposes defining a policy for managing the records of the public identity of a user in an IMS network, the latter comprising:
  • the method according to the invention can be executed by a terminal of the user able to memorize or at least obtain the recording control policy.
  • the invention also relates to a user terminal comprising: means for selecting a record of the public identity of the user of the terminal to be de-registered according to a recording control policy memorized or obtained by said terminal; and
  • the invention proposes to answer the problem of managing the records of the public identity of a user in an IMS network by offering the possibility, at the terminal, for example when the number of records for that identity exceeds or approaches a specified maximum number, to select a record to de-record.
  • the record control policy is stored in the terminal, it is not necessary that the maximum number of records allowed is the same for all users.
  • the step of selecting the record to be de-registered is performed after a step during which the terminal locally controls whether the number of records of the public identity of the The user of said terminal in said network is greater than a maximum value defined by a policy stored in said terminal.
  • this embodiment advantageously avoids any unnecessary signaling traffic.
  • this selection step is performed after receiving a message from the network.
  • This message may for example be a rejection response received consecutively to the sending of a registration request to request a new registration of the public identity in said network.
  • the invention is of significant interest because it allows the terminal to de-register another record and send a request to request the registration rejected by the network. Thus, in fine, it is not systematically the last record that is rejected, it is somehow substitute for a recording completed according to a criterion specific to the terminal.
  • the message may also be a message comprising information representative of the fact that the number of records of said public identity in said network is greater than a determined maximum value, this message being received consecutively to sending a registration request to request a new registration of said public identity in said network.
  • the network temporarily accepts a recording beyond the maximum allowed number, but requires the terminal to perform a de-registration to return, within a specified time, within the acceptable limit.
  • the detection method can be executed by an S-CSCF server; it comprises :
  • the registration control policy is under the responsibility of the S-CSCF. But, very advantageously, it is implemented only after successful registration, so that any unnecessary signaling is avoided.
  • the S-CSCF server sub-contracts at least part of this policy, for example to an application server of the IMS network.
  • an S-CSCF server comprising:
  • this procedure may include:
  • the procedure is entirely managed by the server.
  • the procedure can also be distributed between the S-CSCF server and the user terminal.
  • the procedure may include:
  • the terminal is left with the possibility of choosing the recording to be de-recorded for a determined period of time, but the network takes over at the end of this period to enforce the limit if the terminal does not react. .
  • a criterion may result in the selection:
  • the steps of the management method according to the invention are determined by instructions of computer programs.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a user terminal, this program comprising instructions adapted to the implementation of the steps of the method according to the first aspect of the invention mentioned above.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in an S-CSCF server, this program comprising instructions adapted to the implementation of the steps of the method according to the second aspect of the invention mentioned above.
  • Each of these programs 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 form what other form is desirable.
  • the invention also relates to a computer readable information medium, and including instructions of one of the computer programs as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • FIG. 1 already described illustrates a method of managing the records of a user in an IMS network
  • FIG. 2 already described represents the subscription of a user and the notification by an S-CSCF server of the state of the records of this user;
  • FIGS. 3A and 3C illustrate possible implementations of the rejection of a registration of a user in an IMS network if the authorized limit is exceeded, these implementations resulting from the specifications TS 23.228 and TS 23.237;
  • FIGS. 4A1 to 4A3 represent three methods of managing the records of a user according to a first embodiment of the invention
  • FIG. 4B represents a user terminal according to a first embodiment of the invention
  • FIG. 5A represents a method for managing the records of a user in an IMS network according to a second embodiment of the invention
  • FIG. 5B represents a user terminal according to a second embodiment of the invention.
  • FIG. 6A represents a method of managing the records of a user in an IMS network according to a third embodiment of the invention.
  • FIG. 6B represents an S-CSCF server according to a third embodiment of the invention.
  • FIGS. 7A1 and 7A2 represent two methods of managing the records of a user in an IMS network according to a fourth embodiment of the invention.
  • FIG. 7B represents a user terminal according to a fourth embodiment of the invention.
  • FIG. 7C represents an S-CSCF server according to a fourth embodiment of the invention.
  • FIG. 8 represents an exemplary implementation of a recording control policy that can be used in the invention.
  • FIG. 8 the main steps G10 to G40 of implementation of a record control policy that can be used in the invention. It will be assumed to describe this figure that a user who already has several records of his public identity in the IMS network, requests a new record. In this exemplary embodiment, during a test G10, it is determined whether the number of records of the public identity of a user is greater than a limit value defined by the operator's record management policy.
  • the result of the test G 10 is negative.
  • This test is then followed by a G20 test in which one of the current recordings determines whether there is a record without an active session. If all the sessions are active, the result of the G20 test is negative and it is decided not to proceed with the new registration (step G25).
  • the result of the G20 test is positive if there is at least one current record associated with an inactive session.
  • the G20 test is followed by a test G30 in which one of the current records associated with an inactive session is determined if there is a record for a type of 3GPP access.
  • step G35 If this is the case, the result of the G30 test is positive and it is decided to de-record the oldest record associated with an inactive session for a 3GPP access type (step G35).
  • step G40 if there is no record associated with an inactive session for a 3GPP access type, it is decided to de-record the oldest record among the records associated with an inactive session (step G40).
  • the record control policy described above can be used in each of the four embodiments which will now be detailed. This example is non-limiting and in particular the algorithm can determine to systematically end a recording without the G20 test being executed.
  • the operator defined record management policy is configured within an S-CSCF server SI. It includes a limit on the number of user records, as provided by TS 23.228 Section 5.2.2.3.
  • the record management policy further comprises a record control policy which defines the conditions under which a recording should be terminated, and if so, which criterion (s) to be taken into account in order to select the registration to which it must be terminated.
  • the record control policy is specific to the operator.
  • the server S-CSCF SI determines, during a step E6a, whether the maximum number of records authorized for the public identity of the user of a terminal UE1 has already been reached, and if so, transmits (step E6b) a reject SIP response to be transmitted (steps E6c and E6d) to the terminal UE1.
  • the user terminal UE1 reacts to this refusal by selecting during a step E6e, a record of this public identity to be de-registered, according to a recording control policy stored in a CS file of the terminal UE1.
  • This policy can take into account one or more criteria for selecting the record to de-record.
  • This criterion can for example define that the record to be de-registered is:
  • the selection criterion (s) chosen is such that an end of recording step necessarily takes place.
  • the end-of-registration policy can determine that:
  • the end of registration takes place only if there is at least one record for which no session is active, and in this case the selection criterion leads for example the end of the oldest record of the identity public of the user of a terminal for which there is no current session;
  • step E6e no specific action is to be taken in the opposite case (no end of registration action, no registration attempt after rejection). In this case, the steps from step E6e are not executed.
  • the end of recording is initiated by the terminal because of an implementation at the terminal according to the invention:
  • the user's preferences are stored locally for automatic execution to end a recording or stop the procedure after step E6d; - in agreement with the preferences of the user in manual mode: on reception of the rejection of recording, the terminal requests an interaction with the user: to choose not to follow-up or to choose a previous recording to deregister;
  • the operator's policy can be stored locally or downloaded from the S-CSCF server or an AS application server to the terminal for an automatic execution of end of recording or stop the procedure at the end of the step E6e.
  • the user terminal UE1 initiates, during a step E6f, the de-registration of the record selected in the step E6e, by a standard procedure defined in the document TS 24.229 section 5.1.1.6 and known to those skilled in the art under the term "user-initiated de-registration".
  • the user terminal UE1 again requests the initially desired record for which it had been rejected in step E6d by retransmitting, during a step E2 ', a REGISTER registration request identical or similar to that issued in step E2.
  • FIG. 4A2 differs from the example of FIG. 4A1 in that the S-CSCF server S 1 determines whether the maximum number of authorized records has already been reached, during a step E17a similar to that already described. with reference to Figure 3B, that is to say upon receipt of the registration request, after the challenge of the user.
  • FIG. 4A3 differs from the example of FIG. 4A1 in that the S-CSCF server S 1 determines whether the maximum number of authorized records has already been reached, during a step E18a similar to that already described. with reference to FIG. 3C, that is to say after step E18 of authentication of the user.
  • FIG. 4B represents an example of a hardware architecture of a user terminal UE1 according to a first embodiment of the invention.
  • This user terminal UE1 is remarkable in that it comprises:
  • a rewritable non-volatile memory 15 of the Flash type storing a CS file defining a recording control policy used to select a recording to be de-recorded upon receipt of a response representative of a refusal of a recording;
  • a ROM-type ROM 13 in which a computer program PG1 according to the invention is stored, this program comprising instructions able to execute:
  • step E6e of selecting a record to be de-registered step E6f of initiation of the de-registration of this recording by the terminal UE1;
  • step E2 'to ask for a recording again.
  • This user terminal further comprises, as in known manner, means 14 hardware and software for communication on the IMS network, and RAM RAM 12 required for the execution of the computer program PG1.
  • the record management policy defined by the operator is configured within a user terminal UE2 according to the invention, for example in a POL file stored in a rewritable non-volatile memory 15 of type Flash from this terminal.
  • the record management policy can be transmitted to the terminal UE2 by an entity of the nominal network HN, for example by an application server AS (in English "Application Server") and in particular by the SCC-AS via an OMA-device procedure management.
  • AS in English "Application Server”
  • SCC-AS via an OMA-device procedure management.
  • the record management policy can also be configured from the origin in the UE2 terminal.
  • the record management policy can also be configured within the S-CSCF server and transmitted on the occasion of each new record (in the acceptance response 200 OK issued in step E6b) or in the request NG IFY status change notification issued (at step F7) following a successful registration.
  • the S-CSCF server may also transmit an indication of the allowable limit value by using an HE (Stop Record) parameter in the body of a 200 OK XML message in response to the last record compatible with the allowable limit.
  • the terminal UE2 locally checks, during a step E0, before the step E2 of sending the initial SIP REGISTER request, if the number of authorized records for the The public identity of the user of this UE2 terminal has already been reached.
  • the EU terminal itself determines the overrun either by its own means of calculation or because it has received the prior indication mentioned above.
  • the terminal UE2 sends the SIP request REGISTER to request a record (step E2). If the maximum number of records allowed for this terminal UE2 has already been reached, the terminal UE2 implements the policy defined by the operator of the nominal network HN.
  • the terminal UE2 simply renounces this registration and the sending step E2 of the SIP REGISTER request is not performed, for example because there are active sessions. for each registered contact address or because the user does not wish to end a recording in progress.
  • the terminal UE2 selects a record to be de-registered (step E6e), initiates the de-registration of this record (step E6f), and initiates the initially desired record by issuing the request. corresponding REGISTER record (step E2).
  • the record management policy is also configured within the S-CSCF server and the procedure continues as described above with reference to FIG. 1 (steps E3 to E6a).
  • the limit value on the number of records is configured within the S-CSCF server, the record control policy being specified in the UE2 user terminal.
  • the S-CSCF server determines, in the step E6a, that the maximum number of records for the public identity of the user of the UE2 terminal, via the terminal UE2, is not reached. In which case, a 200 OK type positive response is returned (step E6b) by the S-CSCF server and routed to the UE2 terminal (steps E6c and E6d).
  • the S-CSCF server determines, during step E6a, that the maximum number of records for the public identity of the user of the terminal UE2 is already reached, especially if this public identity is registered via other terminals.
  • the S-CSCF server can send (step E6b) a rejection SIP response to be transmitted to the terminal UE2.
  • FIG. 5B represents an example of a hardware architecture of a user terminal UE2 according to this second variant embodiment of the invention.
  • This user terminal UE2 is remarkable in that it comprises:
  • a rewritable non-volatile memory 15 of the Flash type storing a POL file defining a record management policy used to select a record to be de-registered;
  • ROM-type ROM 13 in which a computer program PG2 according to the invention is stored, this program comprising instructions able to execute:
  • step E6f of initiation of the de-registration of this recording by the terminal UE2;
  • This user terminal further comprises, as in known manner, means 14 hardware and software for communication on the IMS network, and RAM RAM 12 of this terminal allows the execution of the computer program PG2.
  • the operator defined record management policy is configured within an S-CSCF type S3 server, as provided by TS 23.228 Section 5.2.2.3.
  • the server S3 does not check the number of records upon receipt of the initial SIP REGISTER registration request (step E6).
  • the S-CSCF server determines whether the maximum number of records allowed for this public identity has been exceeded, during a step E19a, only if the registration has been successful. With reference to FIG. 6A, this step E19a is performed after the authentication step E18.
  • a SIP message of type 200 OK is sent by the S-CSCF server (step E20) and relayed (steps E21 and E22) to the user terminal UE by the entities I-CSCF and P-CSCF.
  • the S-CSCF server applies the locally stored record control policy. In this example, it selects (step E25) a record to be unregistered, and initiates (step E26) the de-registration of this record by a standard procedure defined in the document TS 24.229 section 5.4.1.5 and known to those skilled in the art under the term "network-initiated de-registration".
  • the criteria used to select the registration of this public identity to be de-registered may for example designate:
  • the selection criteria chosen are such that an end of registration step necessarily takes place.
  • the record control policy may determine that:
  • the end of registration takes place only if there is at least one record for which no session is active, and in this case the selection criterion leads for example the end of the oldest record of the identity public of the user of a terminal for which there is no current session;
  • a criterion can also select a record according to the type of connectivity of the user.
  • the end of recording is initiated by the S-
  • the operator's policy is stored locally for automatic completion of registration or a decision not to act;
  • the S-CSCF may choose a record for the same public identity and the same terminal or a record for the same public identity on another user's terminal;
  • the user's preferences are stored locally for an automatic execution of the end of recording or a decision not to follow up.
  • the S-CSCF obtains the preferences of the user when downloading the subscriber profile in step E19.
  • Figure 6B shows an example hardware architecture of an S-CSCF server
  • This server S3 is remarkable in that it comprises: means 11 for selecting a record of a public identity of a user of said terminal to be de-registered according to a recording control policy stored in the server;
  • a rewritable non-volatile memory 15 of the Flash type storing a POL file defining a record management policy and a CS file defining a selection criterion used to select a record to be de-registered;
  • ROM-type ROM 13 in which a computer program PG3 according to the invention is stored, this program comprising instructions able to execute:
  • This user terminal further comprises, as in known manner, means 14 hardware and software communication on the IMS network, and RAM RAM 12 of this server allows the execution of the computer program PG3.
  • the operator defined record management policy is configured within an S4-type S-CSCF server, as provided by TS 23.228 Section 5.2.2.3.
  • step E19a in which the S-CSCF server S4 determines whether the maximum number of records allowed for the public identity of the user of the a UE4 terminal has been exceeded, only if successful registration of this terminal.
  • a SIP message type 200 OK is sent by the S-CSCF server S4 and relayed to the user terminal UE4 by the entities I-CSCF and P-CSCF.
  • the S-CSCF server S4 informs the user terminal UE4.
  • this operation consists in sending a message 200 OK to the terminal UE4 (steps E30, E31, E32), this message comprising an ALE indication (in English "Authorization Limit Exceeded") representative of the fact that the maximum number of records has been reached.
  • this indication can be supplied to the terminal UE4 by a SIP NOTIFY message when the notification of the user's record states is received, which procedure follows any successful registration. (step F7). This variant is of interest especially in the case where the S-CSCF server sends the response 200 OK before determining the authorized limit overrun.
  • the server S-CSCF S4 triggers, during a step E19b, a countdown (in English "timer") initialized to a determined time.
  • the user terminal UE4 reacts to the ALE indication received in step E32 by selecting during a step E6e, a record of this public identity to be de-registered, according to a Recording control policy according to UE4 terminal user preferences.
  • This policy takes into account at least one criteria for selecting a record.
  • This criterion can for example define that the record to be de-registered is:
  • This criterion can also select a record according to the type of connectivity of the user.
  • the end of registration before expiry of timer is initiated by the terminal due to an implementation at the terminal according to the invention.
  • the end of recording may result from an interaction with the user who selects a recording to be completed or chooses, on the contrary, not to finish any recording; in the latter case, the S-CSCF server terminates itself a record after expiration of the timer.
  • the selection criteria are such that an end of registration step necessarily takes place.
  • the S-CSCF server S4 can determine according to its operator policy whether to terminate an earlier record. If the S-CSCF server determines that the previous records should remain active (in steps E6a, E17a, or E18a as in Figures 3A, 3B, 3C), then the S-CSCF denies this new record by means of a 4xx response, 5xx or 6xx.
  • the end of recording is initiated by the terminal or the S-CSCF according to the implementation of the invention, namely: either at the level of the S-CSCF in accordance with the operator's policy, in the absence of user-defined preferences, this policy being stored locally for automatic completion of registration;
  • the user's preferences are stored locally for an automatic execution of the end of recording;
  • the terminal upon receipt of simultaneous record limit attainment, the terminal requests interaction from the user: choosing an earlier record to be completed; if the terminal does not respond, the S-CSCF terminates another registration according to the operator policy when the timer expires.
  • the user terminal UE4 initiates, during a step E6f, the de-registration of the record selected in the step E6e, by a standard procedure defined in the document TS 24.229 section 5.1.1.6 and known of the skilled person under the English expression "user-initiated de-registration".
  • the S-CSCF server S4 determines, at the expiration of the countdown triggered in step E19b if it has received a request for de-registration for the user of the terminal UE4.
  • the S-CSCF server selects a record to be unregistered (step E19c) and initiates the de-registration of this record by a standard procedure defined in the document TS 24.229 section 5.4.1.5 and known of the skilled person under the term "network-initiated de-registration" (step E19d).
  • FIG. 7B represents an example of a hardware architecture of a user terminal UE4 according to this fourth embodiment of the invention.
  • This user terminal UE4 is remarkable in that it comprises:
  • a flash memory rewritable non-volatile memory 15 storing an end of POL recording policy used to select a record to be de-recorded upon receipt of an ALE indication indicating that a maximum number of records was reached;
  • ROM-type ROM 13 in which is stored a computer program PG41 according to the invention, this program including instructions able to execute:
  • step E6e of selecting a record to be de-registered step E6f of initiation of the de-registration of this recording by the terminal UE4.
  • This user terminal further comprises, as in known manner, means 14 hardware and communication software on the IMS network, and RAM RAM 12 of this terminal UE4 allows the execution of the computer program PG41.
  • FIG. 7C represents an example of hardware architecture of an S-CSCF server S4 according to this fourth embodiment of the invention.
  • This server S4 is remarkable in that it comprises:
  • a rewritable non-volatile memory 15 of the Flash type storing a POL file defining a record management policy used to select a record to be de-registered;
  • ROM-type read-only memory 13 in which a computer program PG42 according to the invention is stored, this program comprising instructions able to execute:
  • This server further comprises, as in known manner, means 14 hardware and software communication on the IMS network, and RAM RAM 12 of this server S4 allows the execution of the computer program PG42.
  • control of the number of records is performed within an S-CSCF server.
  • this control can be subcontracted to an application server AS, and in particular to a server SCC AS (in English "Service Centralization and Continuity").
  • the selection of a record to be completed is made among the different records for the same public user identity (without specifying whether it is the same terminal or different terminals).
  • this control can be performed more finely. It is for example possible to take into account the records for the same public user identity and the same terminal. The case of selection for the same public user identity registered via several terminals is not applicable for cases where the selection is made at the terminal because the terminal is not aware of other records of the same public identity on other terminals.

Landscapes

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

Abstract

Ce procédé permet de gérer le nombre maximum d'enregistrements de l'identité publique d'un utilisateur dans un réseau IMS. Il évite de rejeter définitivement un nouvel enregistrement de cet identité publique lorsqu'un nombre maximum d'enregistrements ont été effectués en offrant la possibilité de dés-enregistrer (E6f) un enregistrement de cette identité sélectionné (E6e) selon une politique de contrôle d'enregistrement mise en œuvre par un terminal de l'utilisateur ou par un serveur du réseau.

Description

Procédé, terminal et serveur S-CSCF aptes à gérer les enregistrements de l'identité publique d'un utilisateur dans un réseau IMS
Arrière-plan de l'invention
La présente invention se situe dans le domaine des réseaux de télécommunication, et plus particulièrement dans celui de la gestion de l'enregistrement des utilisateurs dans un réseau IMS (IP Multimedia Subsystem) tel que spécifié par le 3GPP (3rd Génération Partnership Project) dans les documents TS 23.228 et TS 24.229.
Les spécifications actuelles du 3GPP relatives à I1MS, et notamment les documents TS 23.237 Section 4.2.1 et TS 23.228 Section 5.2.1 prévoient la possibilité, pour l'opérateur du réseau nominal (en anglais « Home Network »), de définir une politique limitant le nombre d'enregistrements simultanés pour une même identité publique.
Le document TS 23.228 Section 5.2.2.3 suggère que ce nombre maximum d'enregistrements simultanés soit configuré au niveau du S-CSCF (en anglais « Serving Call Session Control Function »).
La figure 1 illustre un exemple de procédure d'enregistrement conforme aux spécifications du 3GPP. Elle représente :
- d'une part : un terminal utilisateur UE (en anglais « User Equipment »), une passerelle d'accès GW (ou point de terminaison IP-CAN, en anglais « IP-Connectivity Access Network »), une entité P-CSCF (en anglais « Proxy Call Session Control Function ») et un serveur DNS de noms de domaines (en anglais « Domain Name Server ») pouvant se trouver dans un réseau visité VN (en anglais « Visited Network ») ; et
- d'autre part : une entité I-CSCF (en anglais « Interrogating Call Session Control Function »), une entité S-CSCF, et un serveur HSS de données de souscription (en anglais « Home Subscriber Server » d'un réseau nominal HN.
La fonction de chacun de ces équipements est connue de l'homme du métier. Seuls les éléments nécessaires à la compréhension de l'invention et de son contexte sont détaillés ci-après.
Au cours d'une étape El, le terminal utilisateur UE effectue, en coopération avec l'entité la passerelle GW d'accès au réseau paquet, une procédure d'attachement utile à l'établissement d'un lien de transmission (en anglais « bearer ») et à la découverte d'un proxy P-CSCF, point d'entrée sur le réseau IMS pour le terminal utilisateur UE.
Au cours d'une étape E2, le terminal utilisateur UE envoie, au proxy P-CSCF découvert à l'étape El, une requête d'enregistrement REGISTER conforme au protocole SIP (en anglais « Session Initiation Protocol ») pour demander à enregistrer une identité publique de l'utilisateur avec une adresse de contact du terminal UE dans le réseau.
Sur réception de cette requête, le proxy P-CSCF sollicite, au cours d'une étape E3, le serveur DNS de noms de domaines pour obtenir l'adresse de l'entité I-CSCF du réseau nominal HN de l'utilisateur.
Le proxy P-CSCF transmet ensuite, au cours d'une étape E4, la requête d'enregistrement REGISTER reçue à l'étape E2, à cette entité I-CSCF.
L'entité I-CSCF interroge ensuite, au cours d'une étape E5, le serveur HSS de données de souscription de l'utilisateur pour déterminer si cette identité publique est déjà enregistrée dans le réseau, et si c'est le cas, pour obtenir l'adresse du serveur S-CSCF, ou si ce n'est pas le cas, pour assigner un serveur S-CSCF.
L'entité I-CSCF transmet ensuite, au cours d'une étape E6, la requête d'enregistrement REGISTER reçue à l'étape E4, à ce serveur S-CSCF.
Au cours d'une étape E7, le serveur S-CSCF informe le serveur HSS de souscription de données qu'il est désigné comme serveur d'enregistrement pour l'utilisateur et demande si besoin un vecteur d'authentification pour défier (ou challenger) l'utilisateur. Cette requête est non protégée.
Le serveur S-CSCF sélectionne un vecteur d'authentification au cours d'une étape E8 et propose un défi à l'utilisateur en envoyant au terminal utilisateur UE (étape E9) un message SIP 401 Unauthorized, relayé (étapes E10 et Eli) jusqu'au terminal UE par les entités I-CSCF et P-CSCF.
L'utilisateur authentifie le serveur S-CSCF et génère une réponse au défi au cours d'une étape E12. Puis, le terminal utilisateur UE émet (étape E13) une requête d'enregistrement utilisant les paramètres de sécurité négociés avec le S-CSCF. Cette requête est protégée et routée jusqu'au serveur S-CSCF au cours d'étapes E13 à E17 similaires aux étapes E2 à E6 déjà décrites.
Le serveur S-CSCF authentifie l'utilisateur au cours d'une étape E18. Au cours d'une étape E19, il obtient le profil de cet utilisateur en interrogeant le serveur HSS de données de souscription et le mémorise.
Le serveur S-CSCF renvoie un message SIP 200 OK d'acceptation de l'enregistrement au cours d'une étape E20, ce message étant relayé jusqu'au terminal utilisateur au cours des étapes E21 et E22.
On notera que selon le standard 3GPP, et comme décrit dans le document TS 24.229 section 5.1.1.3, le terminal utilisateur UE souscrit obligatoirement auprès du serveur S-CSCF pour être notifié de chaque changement d'enregistrement. Cette souscription est faite pour une identité publique associée à une adresse de contact et à une instance de terminal si le terminal supporte les enregistrements multiples. Le serveur S-CSCF notifie le terminal utilisateur UE à chaque changement d'état d'enregistrement et notamment après chaque enregistrement avec succès comme décrit dans le document TS 24.229 section 5.4.2.1.2. Cette notification porte sur l'ensemble des identités publiques de l'utilisateur enregistrées auprès du serveur S-CSCF.
La figure 2 illustre les principales étapes Fl à F12 de la procédure de souscription et de notification d'état d'enregistrement de l'utilisateur, cette procédure se déroulant après les étapes déjà décrites en référence à la figure 1.
Au cours d'une première étape Fl, le terminal utilisateur UE demande la souscription au moyen d'une requête SIP SUBSCRIBE, cette requête étant relayée (étapes F2 et F3) jusqu'au serveur S-CSCF via le chemin de signalisation préétabli entre eux lors de l'enregistrement.
Le serveur S-CSCF vérifie que l'utilisateur y est autorisé au cours d'une étape F4 et, si c'est le cas, émet une réponse SIP d'acceptation de souscription de type 200 OK. Cette réponse est relayée jusqu'au terminal UE au cours des étapes F5 et F6.
Au cours d'une étape F7, le serveur S-CSCF notifie le terminal utilisateur UE de l'ensemble de ses enregistrements courants au moyen d'une requête SIP NCmFY. Cette requête est relayée jusqu'au terminal utilisateur UE au cours des étapes F8 et F9. Le terminal utilisateur UE y répond par une réponse d'acceptation SIP de type 200 OK au cours d'une étape F10, cette réponse étant relayée jusqu'au serveur S-CSCF au cours des étapes Fil et F12.
Afin de limiter le nombre d'enregistrements pour l'utilisateur du terminal UE, il est possible de mettre en place, au sein du serveur S-CSCF, une étape, de comparaison du nombre d'enregistrements de cet utilisateur avec une valeur maximum définie par la politique de l'opérateur du réseau nominal HN et configurée dans le S-CSCF. Ceci est spécifié dans le document TS 23.228 Section 5.2.2.3 qui prévoit une limite sur le nombre d'adresses de contacts (adresses IP) enregistrées par identité publique d'un utilisateur.
Dans l'hypothèse où cette valeur maximum serait déjà atteinte, l'enregistrement serait refusé par le S-CSCF, ce dernier envoyant une réponse SIP de rejet, par exemple de type 4xx, 5xx ou 6xx à destination du terminal utilisateur UE, cette réponse étant relayée jusqu'au terminal UE par les entités I-CSCF et P-CSCF.
On notera cependant que l'implémentation n'est pas spécifiée dans les documents TS 24.229 et TS 24.237. Notamment, il n'est pas précisé à quel moment le serveur S-CSCF renvoie sa réponse de rejet.
Les figures 3A à 3C proposent selon trois implémentations possibles du moment auquel le serveur S-CSCF peut envoyer sa réponse de rejet, ces implémentations découlant des documents TS 23.237 Section 4.2.1, TS 23.228 Section 5.2.1. Plus précisément, cette réponse de rejet peut être envoyée : - au cours d'une étape E6b (figure 3A) sur réception de la requête d'enregistrement, avant le défi de l'utilisateur puis relayée jusqu'au terminal utilisateur UE au cours d'étapes E6c et E6d;
- au cours d'une étape E17b (figure 3B) sur réception de la requête d'enregistrement, après le défi de l'utilisateur, puis relayée jusqu'au terminal utilisateur UE au cours d'étapes
E17c et E17d ;
- au cours d'une étape E18b (figure 3C) après l'étape E18 d'authentification puis relayée jusqu'au terminal utilisateur UE au cours d'étapes E18c et E18d. II serait aussi souhaitable que la réponse de rejet comporte la cause du rejet pour en permettre l'interprétation au niveau du terminal utilisateur UE. On peut par exemple envisager d'utiliser:
- une réponse SIP dédiée à ce type de rejet avec un nouveau code réponse, une telle extension étant prévue par le protocole SIP sous la forme de « response-code », comme spécifié dans le document IETF RFC 3261 section 27.4 ; ou
- une réponse générique contenant une clause spécifique (par exemple 403 Forbidden) complétée d'une mention par exemple « nombre d'enregistrements au-delà de la limite autorisée » dans le « reason phrase » ou dans l'entête « Error Info » du message SIP, ces champs étant prévus pour comporter des informations complémentaires sur la raison du rejet comme spécifié dans le document IETF RFC 3261 section 20.18 ; ou
- dans le corps du message SIP avec une indication spécifique, par exemple dans un corps de message XML.
Quoi qu'il en soit, cette implémentation des spécifications TS 23.237 section 4.2.1, TS 23.228 Section 5.2.1 et TS 23.228 Section 5.2.2.3 n'est pas pleinement satisfaisante car :
- elle impose un nombre maximum d'enregistrements identique pour tous les utilisateurs ;
- elle ne permet de rejeter que le dernier enregistrement alors que l'utilisateur peut souhaiter trafiquer sur ce dernier enregistrement ;
- elle impacte la satisfaction de l'utilisateur et les revenus pour l'opérateur du fait du rejet du dernier enregistrement ; et
- elle surcharge le réseau par une signalisation inutile en cas de rejet.
L'invention a pour objectif de proposer une implémentation des spécifications TS 23.237 Section 4.2.1, TS 23.228 Section 5.2.1 et TS 23.228 Section 5.2.2.3 qui ne présente pas les inconvénients ci-dessus.
Objet et résumé de l'invention Selon un premier aspect, l'invention concerne un procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS, ce procédé comportant :
- une étape pour contrôler si le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum ; et lorsque c'est le cas :
- une étape de mise en oeuvre d'une politique de contrôle d'enregistrement comportant :
- une étape au cours de laquelle on prend une décision de mettre fin ou non à un enregistrement de ladite identité publique dans le réseau ; et lorsque c'est le cas :
- une étape de sélection d'un enregistrement de l'identité publique de l'utilisateur dudit terminal à dés-enregistrer selon cette politique de contrôle d'enregistrement; et
- une étape d'initiation du dés-enregistrement de l'enregistrement sélectionné. Dans un mode de réalisation particulier, la prise de décision est implicite en ceci qu'elle est identique à chaque nouvel enregistrement. Dans un mode de réalisation particulier, le nouvel enregistrement est systématiquement refusé dès lors où le nombre d'enregistrements de ladite identité publique dépasse la valeur maximale. Dans un autre mode de réalisation de l'invention, le nouvel enregistrement est systématiquement accepté mais donne lieu à une décision systématique de mettre fin à un enregistrement de ladite identité publique.
Corrélativement, l'invention concerne un système de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS, ce système comportant :
- des moyens pour contrôler si le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum ;
- des moyens de mise en œuvre d'une politique de contrôle d'enregistrement aptes à prendre une décision de mettre fin ou non à un enregistrement de ladite identité publique dans le réseau ;
- des moyens de sélection d'un enregistrement de l'identité publique de l'utilisateur dudit terminal à dés-enregistrer selon une politique de fin d'enregistrement prédéfinie ; et
-des moyens d'initiation du dés-enregistrement de l'enregistrement sélectionné.
D'une façon générale, l'invention propose de définir une politique de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS, celle-ci comportant :
- une valeur maximum (ou limite) du nombre d'enregistrements simultanés autorisés ; et
- une politique de contrôle d'enregistrement, permettant de définir s'il y a lieu ou non de mettre fin à un enregistrement, et lorsque c'est le cas l'algorithme de décision permettant de sélectionner cet enregistrement particulier. Dans un mode particulier de réalisation, le procédé selon l'invention peut être exécuté par un terminal de l'utilisateur apte à mémoriser ou au moins obtenir la politique de contrôle d'enregistrement.
Par conséquent, l'invention concerne aussi un terminal utilisateur comportant : - des moyens de sélection d'un enregistrement de l'identité publique de l'utilisateur du terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée ou obtenue par ledit terminal ; et
- des moyens d'initiation du dés-enregistrement de l'enregistrement sélectionné.
Selon ce premier aspect, et d'une façon générale, l'invention propose de répondre à la problématique de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS en offrant la possibilité, au terminal, par exemple lorsque le nombre d'enregistrements pour cette identité dépasse ou approche un nombre maximum déterminé, de sélectionner un enregistrement à dés-enregistrer.
De façon avantageuse, la politique de contrôle des enregistrements étant mémorisée dans le terminal, il n'est pas nécessaire que le nombre maximum d'enregistrements autorisés soit le même pour tous les utilisateurs.
Dans un mode particulier de réalisation de l'invention, l'étape de sélection de l'enregistrement à dés-enregistrer est effectuée après une étape au cours de laquelle le terminal contrôle localement si le nombre d'enregistrements de l'identité publique de l'utilisateur dudit terminal dans ledit réseau est supérieur à une valeur maximum définie par une politique mémorisée dans ledit terminal.
Ce mode de réalisation évite avantageusement tout trafic de signalisation inutile. Dans un autre mode de réalisation, cette étape de sélection est effectuée après réception d'un message du réseau.
Ce message peut par exemple être une réponse de rejet reçue consécutivement à l'envoi d'une requête d'enregistrement pour demander un nouvel enregistrement de l'identité publique dans ledit réseau.
Il est vrai que dans ce cas là, la signalisation induite par l'envoi de la requête d'enregistrement dans le réseau a surchargé le réseau inutilement. Mais l'invention présente un intérêt important car elle permet au terminal de dés-enregistrer un autre enregistrement et d'envoyer une requête pour redemander l'enregistrement rejeté par le réseau. Ainsi, in fine, ce n'est pas systématiquement le dernier enregistrement qui se trouve rejeté, celui-ci venant en quelque sorte se substituer à un enregistrement terminé selon un critère propre au terminal.
Le message peut aussi être un message comportant une information représentative du fait que le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum déterminée, ce message étant reçu consécutivement à l'envoi une requête d'enregistrement pour demander un nouvel enregistrement de ladite identité publique dans ledit réseau.
Dans ces conditions, le réseau accepte temporairement un enregistrement au-delà du nombre maximum autorisé, mais impose au terminal de procéder à un dés- enregistrement afin de revenir, dans un délai déterminé, dans la limite acceptable.
Dans un mode particulier de réalisation, le procédé de détection peut être exécuté par un serveur S-CSCF ; il comporte :
- une étape de réception d'une requête pour enregistrer un nouvel enregistrement d'une identité publique d'un utilisateur d'un terminal dans le réseau ;
- une étape d'authentification de l'identité publique ; et, en cas de succès de l'authentification, une étape d'enregistrement du nouvel enregistrement ; et
- en cas de réponse positive à l'étape de contrôle du nombre d'enregistrements de l'entité publique dans le réseau:
- une étape de déclenchement d'une procédure aboutissant à
- l'étape de sélection d'un enregistrement de l'identité publique d'un utilisateur dudit terminal à dés-enregistrer selon la politique de contrôle d'enregistrement; et à
- l'étape d'initiation du dés-enregistrement de l'enregistrement sélectionné.
Dans ce mode de réalisation, la politique de contrôle d'enregistrement est sous la responsabilité du S-CSCF. Mais, de façon très avantageuse, elle n'est mise en œuvre qu'après un enregistrement réussi, de sorte qu'on évite ainsi toute signalisation inutile.
Dans ce mode de réalisation, le mot « responsabilité » est à comprendre au sens large. Il désigne en particulier :
- un mode de réalisation dans lequel l'ensemble de la politique de contrôle est mise en œuvre par le serveur S-CSCF ; et aussi :
- un mode de réalisation dans lequel le serveur S-CSCF sous-traite au moins une partie de cette politique, par exemple à un serveur d'application du réseau IMS.
Par conséquent, l'invention concerne aussi un serveur S-CSCF comportant :
- des moyens de réception d'une requête pour enregistrer un nouvel enregistrement d'une identité publique d'un utilisateur d'un terminal dans le réseau ;
- des moyens d'authentification de cette identité publique ;
- des moyens d'enregistrement du nouvel enregistrement en cas de succès de l'authentification ;
- des moyens pour contrôler, en cas de succès dudit enregistrement, si le nombre d'enregistrements de l'identité publique dans le réseau est supérieur à une valeur maximum définie selon une politique de contrôle d'enregistrement mémorisée dans le serveur S-CSCF ; et - des moyens de déclenchement d'une procédure aboutissant à :
- la sélection d'un enregistrement de l'identité publique de l'utilisateur dudit terminal à dés-enregistrer selon la politique de contrôle d'enregistrement; et à
- l'initiation du dés-enregistrement de l'enregistrement sélectionné.
Plusieurs procédures de dés-enregistrement sont envisageables.
Par exemple, cette procédure peut comporter :
- une étape de sélection d'un enregistrement de l'identité publique à dés-enregistrer en fonction de la politique de contrôle d'enregistrement mémorisée dans ledit serveur S- CSCF ; et
- une étape d'initiation du dés-enregistrement de l'enregistrement sélectionné par le serveur S-CSCF.
Dans ce premier exemple, la procédure est entièrement gérée par le serveur.
Mais la procédure peut aussi être distribuée entre le serveur S-CSCF et le terminal utilisateur. Par exemple, la procédure peut comporter :
- une étape d'envoi d'un message au terminal comportant une information représentative du fait que ladite valeur maximum a été dépassée ;
- une étape de déclenchement d'un compte à rebours ; et
- en cas de non réception d'une requête de dés-enregistrement pour l'entité publique concernée, avant l'expiration dudit compte à rebours :
- une étape de sélection d'un enregistrement de l'identité publique à dés-enregistrer selon la politique de contrôle mémorisée dans le serveur S-CSCF ; et
- une étape d'initiation du dés-enregistrement de l'enregistrement sélectionné.
Dans ce mode de réalisation, on laisse au terminal la possibilité de choisir l'enregistrement à dés-enregistrer pendant une durée déterminée, mais le réseau reprend la main à la fin de ce délai pour faire respecter la limite autorisée si le terminal ne réagit pas.
Quelque soit le mode de réalisation de l'invention, il est fondamental de constater qu'elle permet d'éviter de rejeter définitivement un nouvel enregistrement de l'identité publique d'un utilisateur, en proposant différents processus, mis en oeuvre par le terminal, par le serveur S-CSCF, ou distribué, pour dés-enregistrer un enregistrement de cette identité publique, l'enregistrement à dés-enregistrer étant sélectionné selon la politique de contrôle d'enregistrement.
Par exemple, et de façon non limitative, un critère peut entraîner la sélection :
- de l'enregistrement le plus ancien de l'identité publique de l'utilisateur d'un terminal pour lequel il n'existe pas de session en cours ; ou
- de l'enregistrement le plus ancien de cette identité publique si tous ces enregistrements portent une de session en cours ; - d'un enregistrement associé à un type d'accès déterminé.
Dans un mode particulier de réalisation, les étapes du procédé de gestion selon l'invention sont déterminées par des instructions de programmes d'ordinateurs.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un terminal utilisateur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé selon le premier aspect de l'invention mentionné ci-dessus.
Et, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un serveur S-CSCF, ce programme comportant des instructions adaptées à la mise en œuvre des étapes du procédé selon le deuxième aspect de l'invention mentionné ci-dessus.
Chacun de ces programmes peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un des programmes d'ordinateur tel que mentionné ci- dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
- la figure 1 déjà décrite illustre un procédé de gestion des enregistrements d'un utilisateur dans un réseau IMS ; - la figure 2 déjà décrite représente la souscription d'un utilisateur et la notification par un serveur S-CSCF de l'état des enregistrements de cet utilisateur ;
- les figures 3A et 3C illustrent des d'implémentations possibles du rejet d'un enregistrement d'un utilisateur dans un réseau IMS en cas de dépassement de la limite autorisée, ces implémentations découlant des spécifications TS 23.228 et TS 23.237 ;
- les figures 4A1 à 4A3 représentent trois procédés de gestion des enregistrements d'un utilisateur conforme à un premier mode de réalisation de l'invention ;
- la figure 4B représente un terminal utilisateur conforme à un premier mode de réalisation de l'invention ;
- la figure 5A représente un procédé de gestion des enregistrements d'un utilisateur dans un réseau IMS conforme à un deuxième mode de réalisation de l'invention ;
- la figure 5B représente un terminal utilisateur conforme à un deuxième mode de réalisation de l'invention ;
- la figure 6A représente un procédé de gestion des enregistrements d'un utilisateur dans un réseau IMS conforme à un troisième mode de réalisation de l'invention ;
- la figure 6B représente un serveur S-CSCF conforme à un troisième mode de réalisation de l'invention ;
- la figure 7A1 et 7A2 représentent deux procédés de gestion des enregistrements d'un utilisateur dans un réseau IMS conforme à un quatrième mode de réalisation de l'invention ;
- la figure 7B représente un terminal utilisateur conforme à un quatrième mode de réalisation de l'invention ;
- la figure 7C représente un serveur S-CSCF conforme à un quatrième mode de réalisation de l'invention ; et
- la figure 8 représente un exemple de mise en oeuvre d'une politique de contrôle d'enregistrement pouvant être utilisée dans l'invention.
Dans la description de chacune des variantes de réalisation de l'invention ci- dessous, on utilise les références Exx et Fxx pour désigner des étapes identiques aux étapes de mêmes références des figures déjà décrites.
Exemple de politique de contrôle des enregistrements pouvant être utilisée dans l'invention
De façon préliminaire, on décrit, en référence à la figure 8, les principales étapes G10 à G40 de mise en œuvre d'une politique de contrôle des enregistrements pouvant être utilisée dans l'invention. On supposera pour décrire cette figure qu'un utilisateur ayant déjà plusieurs enregistrements de son identité publique dans le réseau IMS, sollicite un nouvel enregistrement. Dans cet exemple de réalisation, on détermine, au cours d'un test G10 si le nombre d'enregistrements de l'identité publique d'un utilisateur est supérieur à une valeur limite définie par politique de gestion des enregistrements de l'opérateur.
Si tel n'est pas le cas, le résultat du test G10 est négatif et la procédure d'enregistrement du nouvel enregistrement se poursuit (étape G15).
Au contraire, si le nombre d'enregistrements de l'identité publique d'un utilisateur est supérieur à la valeur limite précitée, le résultat du test G 10 est négatif. Ce test est alors suivi un test G20 au cours duquel on détermine, parmi les enregistrements actuels, s'il existe un enregistrement sans session active. Si toutes les sessions sont actives, le résultat du test G20 est négatif et on décide de ne pas procéder au nouvel enregistrement (étape G25).
Dans l'exemple de réalisation décrit ici, le résultat du test G20 est positif s'il existe au moins un enregistrement actuel associé à une session non active. Dans ce cas le test G20 est suivi par un test G30 au cours duquel on détermine, parmi les enregistrements actuels associés à une session non active, s'il existe un enregistrement pour un type d'accès 3GPP.
Si tel est le cas, le résultat du test G30 est positif et on décide de dés-enregistrer l'enregistrement le plus ancien associé à une session non active pour un type d'accès 3GPP (étape G35).
Dans l'exemple de réalisation décrit ici, s'il n'existe pas d'enregistrement associé à une session non active pour un type d'accès 3GPP, on choisit de dés-enregistrer l'enregistrement le plus ancien parmi les enregistrements associés à une session non active (étape G40).
La politique de contrôle des enregistrements décrite ci-dessus peut être utilisée dans chacun des quatre modes de réalisation qui vont maintenant être détaillés. Cet exemple est non limitatif et notamment l'algorithme peut déterminer de mettre fin systématiquement à un enregistrement sans que le test G20 soit exécuté.
Description détaillée d'un premier mode de réalisation de l'invention
Ce premier mode de réalisation de l'invention est décrit en référence aux figures 4A1 à 4A3 et 4B.
Dans ce première mode de réalisation, la politique de gestion des enregistrements définie par l'opérateur est configurée au sein d'un serveur S-CSCF SI. Elle comprend une limite sur le nombre d'enregistrements de l'utilisateur, comme prévu par le document TS 23.228 Section 5.2.2.3. Conformément à l'invention, la politique de gestion des enregistrements comporte en outre une politique de contrôle des enregistrements qui définit les conditions dans lesquelles il convient de mettre fin à un enregistrement, et le cas échéant le ou les critères à prendre en compte pour sélectionner l'enregistrement auquel il doit être mis fin.
Dans ce premier mode de réalisation de l'invention, la politique de contrôle des enregistrements est propre à l'opérateur.
Dans l'exemple de la figure 4A1, le serveur S-CSCF SI détermine, au cours d'une étape E6a si le nombre maximum d'enregistrements autorisés pour l'identité publique de l'utilisateur d'un terminal UE1 est déjà atteint, et si c'est le cas, émet (étape E6b) une réponse SIP de rejet destinée à être transmise (étapes E6c et E6d) au terminal UE1.
Conformément à ce mode de réalisation de l'invention, le terminal utilisateur UE1 réagit à ce refus en sélectionnant au cours d'une étape E6e, un enregistrement de cette identité publique à dés-enregistrer, selon une politique de contrôle d'enregistrement mémorisée dans un fichier CS du terminal UE1. Cette politique peut prendre en compte un ou plusieurs critères de sélection de l'enregistrement à dés-enregistrer.
Ce critère peut par exemple définir que l'enregistrement à dés-enregistrer est :
- l'enregistrement le plus ancien pour lequel il n'existe pas de session en cours ; ou
- l'enregistrement le plus ancien si tous portent au moins une session en cours. Ce critère est satisfaisant pour un service Web en tâche de fond ; ou
- un enregistrement pour un type de connectivité particulier.
Dans le mode de réalisation de la figure 4A1, le(s) critère(s) de sélection choisi est tel qu'une étape de fin d'enregistrement a obligatoirement lieu. En variante de ce premier mode de réalisation, la politique de fin d'enregistrement peut déterminer que:
- la fin d'enregistrement a lieu seulement s'il existe au moins un enregistrement pour lequel aucune session n'est active, et dans ce cas le critère de sélection entraine par exemple la fin de l'enregistrement le plus ancien de l'identité publique de l'utilisateur d'un terminal pour lequel il n'existe pas de session en cours ;
- aucune action spécifique n'est à entreprendre dans le cas contraire (pas d'action de fin d'enregistrement, pas de tentative d'enregistrement après rejet). Dans ce cas, les étapes à partir de l'étape E6e ne sont pas exécutées.
Dans ce premier mode de réalisation, la fin d'enregistrement est initiée par le terminal du fait d'une implémentation au niveau du terminal selon l'invention:
- soit en accord avec les préférences de l'utilisateur en mode automatique: les préférences de l'utilisateur sont stockées localement pour une exécution automatique pour finir un enregistrement ou arrêter la procédure à l'issue de l'étape E6d ; - soit en accord avec les préférences de l'utilisateur en mode manuel: sur réception du rejet d'enregistrement, le terminal demande une interaction à l'utilisateur: choisir ne pas donner suite ou choisir un enregistrement antérieur à dés-enregistrer;
- soit en accord avec la politique de l'opérateur, notamment en l'absence de préférences utilisateur: la politique de l'opérateur peut être stockée localement ou téléchargée depuis le serveur S-CSCF ou un serveur d'application AS vers le terminal pour une exécution automatique de fin d'enregistrement ou arrêter la procédure à l'issue de l'étape E6e.
Dans le mode de réalisation de la figure 4A1, le terminal utilisateur UE1 initie, au cours d'une étape E6f, le dés-enregistrement de l'enregistrement sélectionné à l'étape E6e, par une procédure standard définie dans le document TS 24.229 section 5.1.1.6 et connue de l'homme du métier sous l'expression anglaise « user-initiated de-registration ».
Dans ce mode de réalisation, le terminal utilisateur UE1 redemande l'enregistrement initialement souhaité pour lequel il avait reçu un refus à l'étape E6d en réémettant, au cours d'une étape E2' une requête d'enregistrement REGISTER identique ou similaire à celle émise à l'étape E2.
L'exemple de la figure 4A2 diffère de l'exemple de la figure 4A1 en ce que le serveur S-CSCF SI détermine si le nombre maximum d'enregistrements autorisés est déjà atteint, au cours d'une étape E17a similaire à celle déjà décrite en référence à la figure 3B, c'est-à-dire sur réception de la requête d'enregistrement, après le défi de l'utilisateur.
L'exemple de la figure 4A3 diffère de l'exemple de la figure 4A1 en ce que le serveur S-CSCF SI détermine si le nombre maximum d'enregistrements autorisés est déjà atteint, au cours d'une étape E18a similaire à celle déjà décrite en référence à la figure 3C, c'est-à-dire après l'étape E18 d'authentification de l'utilisateur.
La figure 4B représente un exemple d'architecture matérielle d'un terminal utilisateur UE1 conforme à un premier mode de réalisation de l'invention.
Ce terminal utilisateur UE1 est remarquable en ce qu'il comporte :
- des moyens 11 de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée ou obtenue par ledit terminal ;
- une mémoire non volatile réinscriptible 15 de type Flash mémorisant un fichier CS définissant une politique de contrôle d'enregistrement utilisée pour sélectionner un enregistrement à dés-enregistrer sur réception d'une réponse représentative d'un refus d'un enregistrement ; et
- une mémoire morte 13 de type ROM conforme à l'invention, dans laquelle est mémorisé un programme d'ordinateur PG1 conforme à l'invention, ce programme comportant des instructions aptes à exécuter :
- l'étape E6e de sélection d'un enregistrement à dés-enregistrer ; - l'étape E6f d'initiation du dés-enregistrement de cet enregistrement par le terminal UE1 ; et
- l'étape E2' pour redemander un enregistrement.
Ce terminal utilisateur comporte en outre, comme de façon connue, des moyens 14 matériels et logiciels de communication sur le réseau IMS, et une mémoire vive 12 de type RAM nécessaire à l'exécution du programme d'ordinateur PG1.
Description détaillée d'un deuxième mode de réalisation de l'invention Ce deuxième mode de réalisation est décrit en référence aux figures 5A et 5B.
Dans ce deuxième mode de réalisation, la politique de gestion des enregistrements définie par l'opérateur est configurée au sein d'un terminal utilisateur UE2 conforme à l'invention, par exemple dans un fichier POL mémorisé dans une mémoire non volatile réinscriptible 15 de type Flash de ce terminal.
La politique de gestion des enregistrements peut être transmise au terminal UE2 par une entité du réseau nominal HN, par exemple par un serveur d'application AS (en anglais « Application Server ») et notamment par le SCC-AS via une procédure OMA-device management.
La politique de gestion des enregistrements peut aussi être configurée dés l'origine dans le terminal UE2.
La politique de gestion des enregistrements peut également être configurée au sein du serveur S-CSCF et transmise à l'occasion de chaque nouvel enregistrement (dans la réponse 200 OK d'acceptation émise au cours de l'étape E6b) ou dans la requête NG IFY de notification de changement d'état émise (à l'étape F7) suite à un enregistrement avec succès. Le serveur S-CSCF peut aussi transmettre une indication de la valeur limite autorisée en utilisant un paramètre HE (Halte Enregistrement) dans le corps d'un message XML de type 200 OK en réponse au dernier enregistrement compatible avec la limite autorisée.
Dans ce deuxième mode de réalisation, le terminal UE2 conforme à l'invention vérifie localement, au cours d'une étape E0, avant l'étape E2 d'émission de la requête SIP REGISTER initiale, si le nombre d'enregistrements autorisés pour l'identité publique de l'utilisateur de ce terminal UE2 est déjà atteint. Le terminal UE détermine lui-même le dépassement soit par ses propres moyens de calcul soit parce qu'il a reçu l'indication préalable mentionnée ci-dessus.
Si le nombre maximum d'enregistrements autorisés pour ce terminal UE2 n'est pas atteint, le terminal UE2 envoie la requête SIP REGISTER pour demander un enregistrement (étape E2). Si le nombre maximum d'enregistrements autorisés pour ce terminal UE2 est déjà atteint, le terminal UE2 met en œuvre la politique définie par l'opérateur du réseau nominal HN.
Dans une première variante de ce premier mode de réalisation, le terminal UE2 renonce purement et simplement à cet enregistrement et l'étape E2 d'envoi de la requête SIP REGISTER n'est pas effectuée, par exemple parce qu'il existe des sessions actives pour chaque adresse de contact enregistrée ou parce que l'utilisateur ne souhaite pas mettre fin à un enregistrement en cours.
Dans une deuxième variante de ce deuxième mode de réalisation, le terminal UE2 sélectionne un enregistrement à dés-enregistrer (étape E6e), initie le dés-enregistrement de cet enregistrement (étape E6f), et initie l'enregistrement initialement souhaité en émettant la requête d'enregistrement REGISTER correspondante (étape E2).
Dans l'exemple de réalisation décrit ici, la politique de gestion des enregistrements est aussi configurée au sein du serveur S-CSCF et la procédure se poursuit comme décrit précédemment en référence à la figure 1 (étapes E3 à E6a). En variante, seule la valeur limite sur le nombre d'enregistrements est configurée au sein du serveur S-CSCF, la politique de contrôle des enregistrements étant spécifiée dans le terminal utilisateur UE2.
Bien que le contrôle des enregistrements ait déjà été effectué par le terminal utilisateur UE2 à l'étape E0, le serveur S-CSCF détermine, à l'étape E6a, que le nombre maximum d'enregistrements pour l'identité publique de l'utilisateur du terminal UE2, via le terminal UE2, n'est pas atteint. Auquel cas, une réponse positive de type 200 OK est renvoyée (étape E6b) par le serveur S-CSCF et acheminée jusqu'au terminal UE2 (étapes E6c et E6d).
Mais il se peut que le serveur S-CSCF détermine, au cours de l'étape E6a, que le nombre maximum d'enregistrements pour l'identité publique de l'utilisateur du terminal UE2 est déjà atteint, notamment si cette identité publique est enregistrée via d'autres terminaux.
Dans ce cas, le serveur S-CSCF peut émettre (étape E6b) une réponse SIP de rejet destinée à être transmise au terminal UE2.
La figure 5B représente un exemple d'architecture matérielle d'un terminal utilisateur UE2 conforme à cette deuxième variante de réalisation de l'invention.
Ce terminal utilisateur UE2 est remarquable en ce qu'il comporte :
- des moyens 11 de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée ou obtenue par ledit terminal ; - une mémoire non volatile réinscriptible 15 de type Flash mémorisant un fichier POL définissant une politique de gestion des enregistrements utilisée pour sélectionner un enregistrement à dés-enregistrer; et
- une mémoire morte 13 de type ROM conforme à l'invention, dans laquelle est mémorisé un programme d'ordinateur PG2 conforme à l'invention, ce programme comportant des instructions aptes à exécuter :
- l'étape E0 de contrôle local du nombre d'enregistrements ;
- l'étape E6e de sélection d'un enregistrement à dés-enregistrer ;
- l'étape E6f d'initiation du dés-enregistrement de cet enregistrement par le terminal UE2 ; et
- l'étape E2 de demande d'enregistrement.
Ce terminal utilisateur comporte en outre, comme de façon connue, des moyens 14 matériels et logiciels de communication sur le réseau IMS, et une mémoire vive 12 de type RAM de ce terminal permet l'exécution du programme d'ordinateur PG2.
Description détaillée d'un troisième mode de réalisation de l'invention
Ce troisième mode de réalisation de l'invention est décrit en référence aux figures 6A et 6B.
Dans ce troisième mode de réalisation, la politique de gestion des enregistrements définie par l'opérateur est configurée au sein d'un serveur S3 de type S-CSCF, comme prévu par le document TS 23.228 Section 5.2.2.3.
Dans ce troisième mode de réalisation, le serveur S3 n'effectue pas de contrôle du nombre d'enregistrements sur réception de la requête d'enregistrement SIP REGISTER initiale (étape E6).
Dans ce troisième mode de réalisation, le serveur S-CSCF détermine si le nombre maximum d'enregistrements autorisés pour cette identité publique a été dépassée, au cours d'une étape E19a, uniquement en cas de succès de l'enregistrement. En référence à la figure 6A, cette étape E19a est effectuée après l'étape E18 d'authentification.
Si le nombre maximum d'enregistrements n'a pas été dépassé, un message SIP de type 200 OK est envoyé par le serveur S-CSCF (étape E20) et relayé (étapes E21 et E22) jusqu'au terminal utilisateur UE par les entités I-CSCF et P-CSCF.
Dans ce troisième mode de réalisation, si le nombre maximum d'enregistrements a été dépassé, le serveur S-CSCF applique la politique de contrôle des enregistrements mémorisée localement. Dans cet exemple, il sélectionne (étape E25) un enregistrement à dés-enregistrer, et initie (étape E26) le dés-enregistrement de cet enregistrement par une procédure standard définie dans le document TS 24.229 section 5.4.1.5 et connue de l'homme du métier sous l'expression anglaise « network-initiated de-registration ».
Dans ce troisième mode de réalisation de l'invention, les critères utilisés pour sélectionner l'enregistrement de cette identité publique à dés-enregistrer, peuvent par exemple désigner:
- l'enregistrement de l'utilisateur le plus ancien pour lequel il n'existe pas de session en cours ; ou
- l'enregistrement de l'utilisateur le plus ancien si tous portent au moins une session en cours.
Dans ce troisième mode de réalisation, les critères de sélection choisis sont tels qu'une étape de fin d'enregistrement a obligatoirement lieu. En variante de ce troisième mode de réalisation, la politique de contrôle des enregistrements peut déterminer que:
- la fin d'enregistrement a lieu seulement s'il existe au moins un enregistrement pour lequel aucune session n'est active, et dans ce cas le critère de sélection entraine par exemple la fin de l'enregistrement le plus ancien de l'identité publique de l'utilisateur d'un terminal pour lequel il n'existe pas de session en cours ;
- aucune action spécifique dans le cas contraire (pas d'action de fin d'enregistrement, pas de tentative d'enregistrement après rejet, c'est-à-dire que les étapes à partir de E25 ne sont pas exécutées dans ce cas).
Un critère peut également sélectionner un enregistrement selon le type de connectivité de l'utilisateur.
Dans ce troisième mode de réalisation, la fin d'enregistrement est initiée par le S-
CSCF:
soit (comme décrit ci-dessus) en accord avec la politique de l'opérateur, notamment en l'absence de préférences utilisateur: la politique de l'opérateur est stockée localement pour une exécution automatique de fin d'enregistrement ou d'une décision de ne pas donner suite; Le S-CSCF peut choisir un enregistrement pour la même identité publique et le même terminal ou un enregistrement pour la même identité publique sur un autre terminal de l'utilisateur ;
- soit en variante en accord avec les préférences de l'utilisateur en mode automatique: les préférences de l'utilisateur sont stockées localement pour une exécution automatique de fin d'enregistrement ou une décision de ne pas donner suite. Le S-CSCF obtient les préférences de l'utilisateur lors du téléchargement du profil d'abonné à l'étape E19.
La figure 6B représente un exemple d'architecture matérielle d'un serveur S-CSCF
S3 conforme à cette troisième variante de réalisation de l'invention.
Ce serveur S3 est remarquable en ce qu'il comporte : - des moyens 11 de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée dans le serveur ;
- une mémoire non volatile réinscriptible 15 de type Flash mémorisant un fichier POL définissant une politique de gestion des enregistrements et un fichier CS définissant un critère de sélection utilisé pour sélectionner un enregistrement à dés-enregistrer; et
- une mémoire morte 13 de type ROM conforme à l'invention, dans laquelle est mémorisé un programme d'ordinateur PG3 conforme à l'invention, ce programme comportant des instructions aptes à exécuter :
- l'étape E9a de contrôle du nombre d'enregistrements ;
- l'étape de sélection d'un enregistrement à dés-enregistrer ; et
- l'étape d'initiation du dés-enregistrement de cet enregistrement par le serveur S3.
Ce terminal utilisateur comporte en outre, comme de façon connue, des moyens 14 matériels et logiciels de communication sur le réseau IMS, et une mémoire vive 12 de type RAM de ce serveur permet l'exécution du programme d'ordinateur PG3.
Description détaillée d'un quatrième mode de réalisation de l'invention Ce quatrième mode de réalisation de l'invention est décrit en référence aux figures
7A1, 7A2, 7B et 7C.
Dans ce quatrième mode de réalisation, la politique de gestion des enregistrements définie par l'opérateur est configurée au sein d'un serveur S4 de type S-CSCF, comme prévu par le document TS 23.228 Section 5.2.2.3.
Elle se déroule exactement comme la troisième variante de réalisation de l'invention, jusqu'à l'étape E19a, dans laquelle le serveur S-CSCF S4 détermine si le nombre maximum d'enregistrements autorisés pour l'identité publique de l'utilisateur d'un terminal UE4 a été dépassé, uniquement en cas de succès de l'enregistrement de ce terminal.
Si le nombre maximum d'enregistrements n'est pas dépassé, un message SIP de type 200 OK est envoyé par le serveur S-CSCF S4 et relayé jusqu'au terminal utilisateur UE4 par les entités I-CSCF et P-CSCF.
Dans ce quatrième mode de réalisation, si le nombre maximum d'enregistrements a été dépassé, le serveur S-CSCF S4 informe le terminal utilisateur UE4.
Dans l'exemple de la figure 7A1, cette opération consiste à envoyer un message 200 OK au terminal UE4 (étapes E30, E31, E32), ce message comportant une indication ALE (en anglais « Authorization Limit Exceeded ») représentative du fait que le nombre maximum d'enregistrements a été atteint. Dans une autre variante de ce mode de réalisation décrit représenté à la figure 7A2, cette indication peut être fournie au terminal UE4 par un message SIP NOTIFY lors de la notification des états d'enregistrements de l'utilisateur, procédure qui suit tout enregistrement avec succès (étape F7). Cette variante présente un intérêt notamment dans le cas où le serveur S-CSCF envoie la réponse 200 OK avant d'avoir déterminé le dépassement de limite autorisée.
De retour à la figure 7A1, si le nombre maximum d'enregistrements a été dépassé, le serveur S-CSCF S4 déclenche, au cours d'une étape E19b, un compte-à-rebours (en anglais « timer ») initialisé à une durée déterminée.
Dans ce quatrième mode de réalisation de l'invention, le terminal utilisateur UE4 réagit à l'indication ALE reçue à l'étape E32 en sélectionnant au cours d'une étape E6e, un enregistrement de cette identité publique à dés-enregistrer, selon une politique de contrôle d'enregistrement conforme aux préférences de l'utilisateur du terminal UE4. Cette politique prend en compte au moins un critère de sélection d'un enregistrement.
Ce critère peut par exemple définir que l'enregistrement à dés-enregistrer est :
- l'enregistrement le plus ancien pour lequel il n'existe pas de session en cours ; ou
- l'enregistrement le plus ancien si tous portent au moins une session en cours une session en cours.
Ce critère peut également sélectionner un enregistrement selon le type de connectivité de l'utilisateur.
Dans ce quatrième mode de réalisation, la fin d'enregistrement avant expiration de temporisation est initiée par le terminal du fait d'une implémentation au niveau du terminal selon l'invention. Dans une variante de ce quatrième mode de réalisation, la fin d'enregistrement peut résulter d'une interaction avec l'utilisateur qui sélectionne un enregistrement à terminer ou choisit au contraire de ne terminer aucun enregistrement ; dans ce dernier cas, le serveur S-CSCF met fin lui-même à un enregistrement après expiration de la temporisation.
Dans l'exemple décrit ici, les critères de sélection sont tels qu'une étape de fin d'enregistrement a obligatoirement lieu. En variante de ce quatrième mode de réalisation, si le nombre maximum d'enregistrements a été dépassé, le serveur S-CSCF S4 peut déterminer selon sa politique opérateur s'il y a lieu de mettre fin à un enregistrement antérieur. Si le serveur S-CSCF détermine que les enregistrements antérieurs doivent rester actifs (en étapes E6a, E17a ou E18a comme dans les figures 3A, 3B, 3C), alors le S-CSCF refuse ce nouvel enregistrement au moyen d'une réponse 4xx, 5xx ou 6xx.
Dans ce quatrième mode de réalisation, la fin d'enregistrement est initiée par le terminal ou le S-CSCF en fonction de l'implémentation de l'invention, à savoir : soit au niveau du S-CSCF en accord avec la politique de l'opérateur, en l'absence de préférences définies par l'utilisateur, cette politique étant stockée localement pour une exécution automatique de fin d'enregistrement ;
soit au niveau du terminal en accord avec les préférences de l'utilisateur en mode automatique: les préférences de l'utilisateur sont stockées localement pour une exécution automatique de fin d'enregistrement;
soit en accord avec les préférences de l'utilisateur en mode manuel: sur réception d'atteinte de limite d'enregistrements simultanés, le terminal demande une interaction à l'utilisateur: choisir un enregistrement antérieur à terminer; si le terminal ne donne pas suite, le S-CSCF met fin à un autre enregistrement selon la politique opérateur lors de l'expiration de la temporisation.
Dans ce quatrième mode, le terminal utilisateur UE4 initie, au cours d'une étape E6f, le dés-enregistrement de l'enregistrement sélectionné à l'étape E6e, par une procédure standard définie dans le document TS 24.229 section 5.1.1.6 et connue de l'homme du métier sous l'expression anglaise « user-initiated de-registration ».
Dans ce quatrième mode de réalisation, le serveur S-CSCF S4 détermine, à l'expiration du compte à rebours déclenché à l'étape E19b s'il a reçu une requête de dés- enregistrement pour l'utilisateur du terminal UE4.
Si ce n'est pas le cas, le serveur S-CSCF sélectionne un enregistrement à dés- enregistrer (étape E19c) et initie le dés-enregistrement de cet enregistrement par une procédure standard définie dans le document TS 24.229 section 5.4.1.5 et connue de l'homme du métier sous l'expression anglaise « network-initiated de-registration » (étape E19d).
La figure 7B représente un exemple d'architecture matérielle d'un terminal utilisateur UE4 conforme à ce quatrième mode de réalisation de l'invention.
Ce terminal utilisateur UE4 est remarquable en ce qu'il comporte :
- des moyens 11 de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée ou obtenue par ledit terminal ;
- une mémoire non volatile réinscriptible 15 de type Flash mémorisant une politique de fin d'enregistrement POL utilisée pour sélectionner un enregistrement à dés-enregistrer sur réception d'une indication ALE lui indiquant qu'un nombre maximum d'enregistrements était atteint ; et
- une mémoire morte 13 de type ROM conforme à l'invention, dans laquelle est mémorisé un programme d'ordinateur PG41 conforme à l'invention, ce programme comportant des instructions aptes à exécuter :
- l'étape E6e de sélection d'un enregistrement à dés-enregistrer ; - l'étape E6f d'initiation du dés-enregistrement de cet enregistrement par le terminal UE4.
Ce terminal utilisateur comporte en outre, comme de façon connue, des moyens 14 matériels et logiciels de communication sur le réseau IMS, et une mémoire vive 12 de type RAM de ce terminal UE4 permet l'exécution du programme d'ordinateur PG41.
La figure 7C représente un exemple d'architecture matérielle d'un serveur S-CSCF S4 conforme à cette quatrième mode de réalisation de l'invention.
Ce serveur S4 est remarquable en ce qu'il comporte :
- des moyens 11 de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée dans ledit serveur ;
- un compte à rebours 16 ;
- une mémoire non volatile réinscriptible 15 de type Flash mémorisant un fichier POL définissant une politique de gestion des enregistrements utilisée pour sélectionner un enregistrement à dés-enregistrer; et
- une mémoire morte 13 de type ROM conforme à l'invention, dans laquelle est mémorisé un programme d'ordinateur PG42 conforme à l'invention, ce programme comportant des instructions aptes à exécuter :
- l'étape E9a de contrôle du nombre d'enregistrements ;
- l'étape E30 d'envoi d'un message de notification au terminal UE4 si le nombre maximum d'enregistrements à été atteint ;
- l'étape E19c de sélection d'un enregistrement à dés-enregistrer ; et d'initiation du dés-enregistrement de cet enregistrement par le serveur S4 si le compte à rebours a expiré.
Ce serveur comporte en outre, comme de façon connue, des moyens 14 matériels et logiciels de communication sur le réseau IMS, et une mémoire vive 12 de type RAM de ce serveur S4 permet l'exécution du programme d'ordinateur PG42.
Autres modes de réalisation de l'invention
Dans les premier, troisième et quatrième modes de réalisation de l'invention, le contrôle du nombre d'enregistrements est effectué au sein d'un serveur S-CSCF.
En variante, ce contrôle peut être sous-traité à un serveur d'application AS, et notamment à un serveur SCC AS (en anglais « Service Centralization and Continuity »).
Dans tous les modes de réalisation, la sélection d'un enregistrement à terminer se fait parmi les différents enregistrements pour une même identité publique d'utilisateur (sans préciser s'il s'agit du même terminal ou de terminaux différents). En variante, ce contrôle peut être effectué plus finement. Il est par exemple possible de prendre en compte les enregistrements pour une même identité publique d'utilisateur et un même terminal. Le cas de sélection pour une même identité publique d'utilisateur enregistrée via plusieurs terminaux n'est pas applicable pour les cas où la sélection est faite au niveau du terminal car le terminal n'a pas connaissance des autres enregistrements de la même identité publique sur d'autres terminaux.
Dans tous les modes de réalisation, il est supposé mais non précisé si la limite sur le nombre d'enregistrements autorisé concerne l'ensemble des utilisateurs en tant que politique de gestion des enregistrements configurée au S-CSCF. En variante, il est possible de configurer une limite par utilisateur par l'ajout d'un paramètre dédié dans son profil d'abonné IMS stocké dans le serveur de souscription HSS puis téléchargé dans le serveur S-CSCF (étape E19). Ceci est applicable pour les troisième et quatrième modes de réalisation.

Claims

REVENDICATIONS
1. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS, ce procédé comportant :
- une étape (G10, E6a, E17a, E18a, E19a) pour contrôler si le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum ; et lorsque c'est le cas :
- une étape de mise en œuvre d'une politique de contrôle d'enregistrement comportant : - une étape (G20) au cours de laquelle on prend une décision de mettre fin ou non à un enregistrement de ladite identité publique dans le réseau ; et lorsque c'est le cas :
- une étape (E6e, E19c, E25, G30) de sélection d'un enregistrement de ladite identité publique de l'utilisateur dudit terminal à dés-enregistrer selon ladite politique de contrôle d'enregistrement; et
- une étape (E6f, E19d, E26) d'initiation du dés-enregistrement de l'enregistrement sélectionné.
2. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 1, ce procédé pouvant être exécuté par un terminal utilisateur (UEl, UE2, UE4) apte à mémoriser ou obtenir ladite politique de contrôle d'enregistrement.
3. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 2, caractérisé en ce que ladite étape (E6e) de sélection est effectuée après une étape (E0) au cours de laquelle on contrôle localement si le nombre d'enregistrements de ladite identité publique de l'utilisateur dudit terminal (UE2) dans ledit réseau est supérieur à une valeur maximum définie par ladite politique de contrôle d'enregistrement mémorisée dans ledit terminal (UE2).
4. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 2, caractérisé en ce que ladite étape (E6e) de sélection est effectuée après réception (E6d, E17d, E18d, E32) d'un message du réseau.
5. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 4, caractérisé en ce que ledit message est une réponse de rejet reçue (E6d, E17d, E18d) consécutivement à l'envoi (E2) d'une requête d'enregistrement pour demander un nouvel enregistrement de ladite identité publique dans ledit réseau.
6. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 5, caractérisé en ce qu'il comporte, après ladite étape (E6f) d'initiation du dés-enregistrement, une étape (Ε2') d'envoi d'une requête pour redemander ledit nouvel enregistrement de l'identité publique dans le réseau.
7. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 4, caractérisé en ce que ledit message est un message comportant une information (ALE) représentative du fait que le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum déterminée, ce message étant reçu (E32, F9) consécutivement à l'envoi (E2) d'une requête d'enregistrement pour demander un nouvel enregistrement de ladite identité publique dans ledit réseau.
8. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 1, ce procédé pouvant être exécuté par un serveur S-CSCF (S3, S4) étant caractérisé en ce qu'il comporte :
- une étape (E6) de réception d'une requête pour enregistrer un nouvel enregistrement de l'identité publique de l'utilisateur dudit terminal (UE3, UE4) dans ledit réseau ;
- une étape (E18) d'authentification de ladite identité publique ; et, en cas de succès de ladite authentification, une étape (E20) d'acceptation dudit nouvel enregistrement ; et
- en cas de réponse positive à ladite étape (19a) de contrôle du nombre d'enregistrements de ladite identité publique dans ledit réseau:
- une étape (E25, E30) de déclenchement d'une procédure aboutissant à :
- ladite étape de sélection d'un enregistrement de ladite identité publique d'un utilisateur dudit terminal à dés-enregistrer selon ladite politique de contrôle d'enregistrement; et à
- ladite étape d'initiation du dés-enregistrement de l'enregistrement sélectionné.
9. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 8, dans lequel ladite politique de contrôle d'enregistrement est mémorisée dans ce ledit serveur S-CSCF et dans lequel lesdites étapes (E25) de sélection d'un enregistrement à dés-enregistrer et (E26) d'initiation du dés- enregistrement de l'enregistrement sélectionné sont exécutées par ledit serveur S-CSCF (S3, S4).
10. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon la revendication 8, dans lequel ladite procédure comporte :
- une étape (E30) d'envoi d'un message audit terminal (UE4) comportant une information (ALE) représentative du fait que ladite valeur maximum a été dépassée ;
- une étape (E19b) de déclenchement d'un compte à rebours ; et
- en cas de non réception d'une requête de dés-enregistrement pour ladite identité publique, avant l'expiration dudit compte à rebours :
- ladite étape (E19c) de sélection d'un enregistrement de ladite identité publique à dés- enregistrer selon ladite politique de contrôle mémorisée dans ledit serveur S-CSCF (S4) ; et
- ladite étape (E19d) d'initiation du dés-enregistrement de l'enregistrement sélectionné.
11. Procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon l'une quelconque des revendications 1 à 10, caractérisé en ce que ladite politique de contrôle d'enregistrement comporte au moins un critère pour sélectionner l'enregistrement à désélectionner, ce critère entraînant la sélection :
- de l'enregistrement le plus ancien de ladite identité publique pour lequel il n'existe pas de session en cours ; ou
- de l'enregistrement le plus ancien de ladite identité publique si tous ces enregistrements portent une de session en cours ;
- d'un enregistrement associé à un type d'accès déterminé.
12. Système de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS, ce système comportant :
- des moyens pour contrôler si le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum ;
- des moyens de mise en œuvre d'une politique de contrôle d'enregistrement aptes à prendre une décision de mettre fin ou non à un enregistrement de ladite identité publique dans le réseau ;
- des moyens de sélection d'un enregistrement de ladite identité publique de l'utilisateur dudit terminal à dés-enregistrer selon une politique de fin d'enregistrement prédéfinie ; et -des moyens d'initiation du dés-enregistrement de l'enregistrement sélectionné.
13. Terminal utilisateur (UE1, UE2, UE4) comportant :
- des moyens (11) de sélection d'un enregistrement d'une identité publique d'un utilisateur dudit terminal à dés-enregistrer selon une politique de contrôle d'enregistrement mémorisée ou obtenue par ledit terminal ; et - des moyens (11) d'initiation du dés-enregistrement de l'enregistrement sélectionné.
14. Serveur S-CSCF (S3, S4) comportant :
- des moyens (14) de réception d'une requête pour enregistrer un nouvel enregistrement d'une identité publique d'un utilisateur d'un terminal (UE3, UE4) dans un réseau ;
- des moyens (11) d'authentification de ladite identité publique ;
- des moyens (11) d'enregistrement dudit nouvel enregistrement en cas de succès de ladite authentification ;
- des moyens (11) pour contrôler, en cas de succès dudit enregistrement, si le nombre d'enregistrements de ladite identité publique dans ledit réseau est supérieur à une valeur maximum définie selon une politique de contrôle d'enregistrement mémorisée dans ledit serveur S-CSCF (S3, S4) ; - des moyens (11) de déclenchement d'une procédure aboutissant à :
- la sélection d'un enregistrement de ladite identité publique de l'utilisateur dudit terminal à dés-enregistrer selon ladite politique de contrôle d'enregistrement; et à
- l'initiation du dés-enregistrement de l'enregistrement sélectionné.
15. Programme d'ordinateur (PG1, PG2, PG3, PG41, PG42) comportant des instructions pour l'exécution des étapes du procédé de gestion des enregistrements de l'identité publique d'un utilisateur dans un réseau IMS selon l'une quelconque des revendications 1 à 11, lorsque ledit programme est exécuté par un ordinateur (UE1, UE2, UE4).
PCT/FR2010/052366 2009-11-06 2010-11-04 Procede, terminal et serveur s-cscf aptes a gerer les enregistrements de l'identite publique d'un utilisateur dans un reseau ims WO2011055081A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0957884 2009-11-06
FR0957884 2009-11-06

Publications (1)

Publication Number Publication Date
WO2011055081A1 true WO2011055081A1 (fr) 2011-05-12

Family

ID=42262022

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2010/052366 WO2011055081A1 (fr) 2009-11-06 2010-11-04 Procede, terminal et serveur s-cscf aptes a gerer les enregistrements de l'identite publique d'un utilisateur dans un reseau ims

Country Status (1)

Country Link
WO (1) WO2011055081A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050124341A1 (en) * 2003-12-05 2005-06-09 Nokia Corporation Controlling registration in a communication system
US20060153171A1 (en) * 2004-12-24 2006-07-13 Kabushiki Kaisha Toshiba IP telephone system
DE102006026929A1 (de) * 2006-06-09 2007-12-13 Siemens Ag Verfahren zur mehrfachen Registrierung eines multimodalen Kommunikationsendgerätes
EP2028826A1 (fr) * 2007-08-20 2009-02-25 Huawei Technologies Co., Ltd. Procédé, système, terminal et serveur d'inscription d'utilisateur basés sur le protocole SIP

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050124341A1 (en) * 2003-12-05 2005-06-09 Nokia Corporation Controlling registration in a communication system
US20060153171A1 (en) * 2004-12-24 2006-07-13 Kabushiki Kaisha Toshiba IP telephone system
DE102006026929A1 (de) * 2006-06-09 2007-12-13 Siemens Ag Verfahren zur mehrfachen Registrierung eines multimodalen Kommunikationsendgerätes
EP2028826A1 (fr) * 2007-08-20 2009-02-25 Huawei Technologies Co., Ltd. Procédé, système, terminal et serveur d'inscription d'utilisateur basés sur le protocole SIP

Similar Documents

Publication Publication Date Title
EP1560368A1 (fr) Procédé d'établissement d'une session multimédia entre un équipement appelant et un équipement appelé d'un réseau du type à sous domaine multimédia et système de communication mettant en oeuvre ce procédé
WO2008047037A1 (fr) Procede de routage d'un message sip en cas d'indisponibilite de noeuds intermediaires
EP2366238B1 (fr) Procede et systeme de regulation du trafic de redemarrage dans un reseau de telecommunications
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
FR3034608A1 (fr) Procede de priorisation de flux medias dans un reseau de communications
EP2386169B1 (fr) Procédé et système de regulation du trafic de redémarrage dans un réseau de télécommunications
EP2396950B1 (fr) Procede et systeme de gestion de la signalisation dans un reseau de telecommunications
EP3053321A1 (fr) Technique de restauration d'un service dans un réseau
EP2856732B1 (fr) Procédé et entité de traitement d'un message
EP2550776B1 (fr) Procede de gestion des enregistrements dans un reseau ims et serveur s-cscf mettant en oeuvre ce procede
EP2030382A1 (fr) Unite et procede de definition d'une regle de session dans un reseau
WO2014044951A1 (fr) Procedes de verification et de controle dans un cœur de reseau ip multimedia, et serveurs
WO2011055081A1 (fr) Procede, terminal et serveur s-cscf aptes a gerer les enregistrements de l'identite publique d'un utilisateur dans un reseau ims
WO2017168084A1 (fr) Procédé de transfert de réseau d'accès pour un terminal mobile en itinérance
WO2019243717A1 (fr) Procédé et dispositif de gestion d'un état de surcharge d'un cœur de réseau contrôlant un réseau d'accès mobile
EP3646578B1 (fr) Procédé de synchronisation d'état média
EP3632078B1 (fr) Procédé de contrôle d'une communication comprenant des transactions multiples
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
WO2010112759A1 (fr) Procede de mise a jour d'une session applicative en cours pour un terminal d'utilisateur d'un reseau de telecommunications
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
WO2011151572A1 (fr) Procede et dispositif de presentation d'un appel entrant dans un reseau ims
WO2012072920A1 (fr) Procédé et dispositif de gestion d'une souscription a un service dans un réseau ims
EP2801178A1 (fr) Procede dynamique de determination d'une liste de services dans un reseau sip

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

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

Country of ref document: EP

Kind code of ref document: A1