[go: up one dir, main page]

WO2012117178A1 - Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims - Google Patents

Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims Download PDF

Info

Publication number
WO2012117178A1
WO2012117178A1 PCT/FR2012/050255 FR2012050255W WO2012117178A1 WO 2012117178 A1 WO2012117178 A1 WO 2012117178A1 FR 2012050255 W FR2012050255 W FR 2012050255W WO 2012117178 A1 WO2012117178 A1 WO 2012117178A1
Authority
WO
WIPO (PCT)
Prior art keywords
public
user
identities
status
identity
Prior art date
Application number
PCT/FR2012/050255
Other languages
English (en)
Inventor
Jean-Claude Le Rouzic
José DOREE
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2012117178A1 publication Critical patent/WO2012117178A1/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/1066—Session management
    • H04L65/1073—Registration or de-registration
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4588—Network directories; Name-to-address mapping containing mobile subscriber information, e.g. home subscriber server [HSS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2101/00—Indexing scheme associated with group H04L61/00
    • H04L2101/30—Types of network names
    • H04L2101/395—Internet protocol multimedia private identity [IMPI]; Internet protocol multimedia public identity [IMPU]

Definitions

  • the present invention relates to networks of type IP ("Internet Protocol”) which are able to implement advanced session control protocols.
  • IP Internet Protocol
  • IP networks allow the broadcasting of conversational data, such as "Voice over IP”, “Content Sharing”, “Presence”, or “Instant Messaging”.
  • the communication services can identify physical or virtual resources by means of character strings, for example "URI” (initials of the English words “Uniform Resource Identifier” meaning "Uniform Resource Identifier”).
  • URI initials of the English words "Uniform Resource Identifier” meaning "Uniform Resource Identifier”
  • the syntax of URIs is defined in RFC 3986 of the Internet Engineering Task Force (IETF); the knowledge of the URI of a resource makes it possible to obtain the IP address of a device of the network of the operator managing this resource.
  • This equipment may for example be a fixed or mobile terminal, or a home or residential gateway ("Residential Gateway” in English), or a network operator gateway ("Voice Gateway” in English), which generally connects a large number of analog or ISDN lines, such as a DSLAM-SIP (DSLAM) are the initials of the words “Digital Subscriber Line Access Multiplexer” meaning “digital subscriber line access multiplexer”; a device that collects DSL data traffic that travels over a number of telephone lines).
  • DSLAM-SIP DSLAM-SIP
  • the conventional advanced session control protocols such as the H.323 and SIP protocols
  • use so-called “signaling” messages which are messages enabling a terminal to request a connection with another terminal, or also messages indicating that a telephone line is busy, or signaling that the called telephone rings, or signaling that such phone is connected to the network and can be joined in this or that way.
  • signaling When a client registered on a network using an advanced session control protocol wishes to benefit from a multimedia service offered by the network, it sends a signaling message to the network specifying its request.
  • the SIP (Initials of Session Initiation Protocol) protocol was defined by the IETF in RFC 3261 This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • Communication resources are identified by "SIP-URIs" as defined in RFC 3261 or by "tel-URIs” as defined in RFC 3966; an SIP-URI is of the form “user @ host” (for example, alice @ domain1), where the "host” part identifies the network on which the resource (for example, the user of a service offered by the network ) represented by the "user” part has an account; such a URI is of the form “tel: telephone_number” (for example, tel: +336123456789).
  • This SIP protocol is used in particular in infrastructure type IMS (initials of the words "IP Multimedia Subsystem” meaning “Multimedia Subsystem over IP”).
  • the IMS has been defined by the 3rd Generation Partnership Project (3GPP). It is a network architecture originally introduced for mobile networks and then extended to other accesses, including fixed access xDSL technology. This architecture allows the dynamic establishment and the control of multimedia sessions between two clients, as well as the reservation of resources at the level of the network for transporting multimedia streams. Through this architecture, network operators can conveniently implement a management policy, provide a predetermined Quality of Service, and calculate the amounts to be billed to customers.
  • the IMS currently provides access to telephony, videophone, Presence and Instant Messaging services, which it also manages.
  • Each user of an IMS network can be identified by means of various identities, including ⁇ (initials of the words “IP Multimedia Private Identity” meaning “Private Identity for Multimedia IP”) and IMPU (initials of the English words “IP Multimedia PUblic identity “meaning” Public Identity for IP Multimedia ").
  • the IMPI is defined in 3GPP specification TS 23.228.
  • the IMPI is an identity permanently assigned by the operator of a network to a subscription to this operator, and is used, for example, for registration, authorization of access, administration of services offered to the user, and billing (it should be noted that a user can have several IMPI within the same subscription, so it is possible to associate each IMPI with a different terminal).
  • the IMPI is in the form of an NAI (initials of the English words "Network Access Identifier” meaning "Network Access Identifier”) as defined in RFC 4282 of the I ETF.
  • a user uses his IMPU to communicate with other users.
  • the IMPU is in the form of a URI or short number, or any alias.
  • a URI or short number, or any alias.
  • An IMPU can be shared with another phone, so that these phones can both be joined with the same identity (for example, a single phone number for an entire family users).
  • identities are configured by the operator during the creation by a user of an account with this operator, and exploited during the registration of the user's terminal on the network.
  • the IMS networks include one or more servers, generally referred to as "S-CSCFs" (initials of the English words “Serving - Call Session Control Function” meaning “Session Call Control Function”), capable (among other functions) to manage the registration procedure of devices connected to the network.
  • S-CSCFs servers, generally referred to as "S-CSCFs” (initials of the English words “Serving - Call Session Control Function” meaning “Session Call Control Function”), capable (among other functions) to manage the registration procedure of devices connected to the network.
  • these networks include one or more servers, generally referred to as "l-CSCFs" (Initials of the English words “Interrogating - Call Session Control Function” meaning “Interrogating Call Session Control Function”) which, at the time of the registration of a user terminal, query a server called “HSS” (initials of the words “Home Subscriber Service” meaning “Link Subscriber Service”) to be able to select an S-CSCF server having the characteristics required to reach the level of service subscribed by this user.
  • HSS Home Subscriber Service
  • Link Subscriber Service Link Subscriber Service
  • the S-CSCF servers contribute to the implementation of these various services by managing the routing of the signaling, on the one hand, between each user terminal and the servers of the network specialized in the implementation of service provided by the user, and to other users managed by the same network or a network connected to it.
  • the servers of type l-CSCF or of type S-CSCF exchange information with one or more HSS server (s) mentioned above.
  • the HSS servers each contain a client database, and are therefore the equivalent in IP networks of "HLR” servers (initials of the words “Home Location Register” meaning “Nominal Location Register”) used in GSM networks. .
  • HLR Home Location Register
  • Each HSS server contains the profile of a number of network users, this profile including their registration status, authentication and location data, and subscribed services.
  • IMS Subscription In the process of creating a user account on an IMS network, the network operator first creates in the HSS an IMS subscription (referred to as "IMS Subscription" in the accompanying figures), which will serve as the basis for the billing. The operator then notes, with reference to this subscription, the IMPI and public IMPU private identities of the users sharing this subscription, declares their service profiles and the IFCs (initials of the initial Fiiter Criteria) corresponding to the Initial Filtering Criteria. , as well as many other user information.
  • Figures 1 and 2 taken from 3GPP specification TS 23.228, illustrate, as examples, data related to IMS subscriptions.
  • FIG. 1 illustrates the data related to the IMS subscription of a user having a unique private identity identity IMPI (denoted by "Private User Identity”) and three public identities IMPU (denoted “Public User Identity 1", “Public User Identity 2” and “Public User Identity 3”).
  • IMPI unique private identity identity
  • IMPU Public User Identity 1
  • Public User Identity 2 Public User Identity 2
  • Public User Identity 3 Two of these public identities are grouped into a 1RS (initials of the English words “Implicit Registration ID Set” meaning “Implicit Set of Identity Registration”), which is represented in Figure 1 by a dotted rectangle.
  • 1RS initials of the English words “Implicit Registration ID Set” meaning “Implicit Set of Identity Registration”
  • This notion of IRS makes it possible to use a public identity to record implicitly another one as well. For example, suppose that the "user" to be registered is an IPBX, namely a PABX (initials of the words "Private Automatic Branch”).
  • eXchange (means) Private Branch Switch ", which is used primarily to connect the telephone sets of an institution with the public telephone network) executing software, instead of independent and dedicated electronic equipment; in this case, it is convenient to only have to record one of the multiple public identities attached to ⁇ to declare the presence on the network of all the identities: the IRS contains the set of identities of ⁇ . It would be the same for the registration of a gateway offering multiple accesses.
  • a specific public identity is used when registering a 1RS.
  • This identity typically represents a user such as an IPBX or a gateway as a whole, and can not be used as such for routing purposes. This is known as "barred identity”.
  • Figure 2 illustrates, with the same conventions as Figure 1, the data related to the subscription IMS - a little more complex - a user with two private identities and six public identities grouped in three 1RS; it should be noted in particular that the public identity "Public User Identity 3" is common to both private identities.
  • the figure also shows the service profiles associated with each of the public identities.
  • the Public Identity 6 public identity will also (implicitly) ) registered, because these two public identities belong to the same 1RS (IRS3); the user will be reachable on his terminal both via his public identity 5 and via his public identity 6.
  • This set of data used during the declaration on the HSS, is then transmitted to the S-CSCF in charge of the user. Thanks to these provisions, the S-CSCF knows all the identities declared in the IMS subscription, knows which identities are registered implicitly, and can make the link between the public identities and the terminal's contact address (as defined in RFC 3261) to route incoming calls.
  • the S-CSCF knows the registration status of each public identity; according to the current standards, this status can be "registered”, “not registered”, or “unregistered” (non-registered identity, but having nevertheless benefited from an IMS service, for example the processing of a call for this public identity).
  • the declaration in the HSS of an IMS subscription is static.
  • the data of the IMS subscription can only be modified by the "Service Delivery” process of the operator (i.e. Information System, inaccessible to users).
  • the dynamic management of the IRS would make it easy to declare a mobile user on this or that site, according to its road map. , finding each time his profile service identical.
  • the IRS represents a network gateway such as a SIP Voice Gateway
  • dynamic IRS management would make it possible to declare certain accesses as unavailable, or again in service, as the gateway evolves.
  • the IRS represents a service such as the "My Business Addresses" list
  • dynamic IRS management would add or remove, for example, a mobile phone or a private landline from this list, depending on the availability of their user.
  • the present invention thus relates to a method for managing public identities in an IMS network, comprising a step during which a user sends a message to said IMS network.
  • Said method is remarkable in that said message contains at least one specific parameter whose meaning is to ask an S-CSCF server of said IMS network to specifically modify the status of at least one of the public identities of the user, and / or to send to the user a list of public identities of the user, according to, for each of these public identities, the contact address to which this public identity is attached.
  • any public identity of the IMS subscription can be added to any 1RS, or any public identity of a registered private identity can be transferred to any other registered private identity ( and therefore direct third party calls to another contact address).
  • the invention offers the user the possibility of knowing the status of any of his public identities, taking into account the the contact address (and therefore the private identity) to which this public identity is attached.
  • the notion of "status" generalises the conventional notion of registration status; thus (as illustrated in the examples below), the status of a given public identity attached to a given private identity (and thus, generally, to a given contact address) may represent its registration status, but also, for example, ongoing maintenance on that public identity, or service history, and so on. This information can advantageously be stored in a dedicated database.
  • the invention proposes a database, comprising at least one public identity of a subscriber to an IMS network in association with a private identity of said subscriber. Said database is remarkable in that it mentions the status of said public identity, said status being:
  • said S-CSCF server sends back to said user, in response to said message, a list of public identities of the user according to, for each of these public identities, the contact address to which this public identity is attached. Thanks to these provisions, the user receives confirmation that his request has been taken into account, and can verify the attachment of one or another of its public identities.
  • said S-CSCF server also provides in said response the status of each of the public identities of said list.
  • the user can also check the current status of one or another of his public identities.
  • this S-CSCF server sends, to the HSS server of said IMS network, a command representative of said modification, and
  • said HSS server takes this modification into account.
  • the HSS server can save any changes in the user's profile. It is recalled in this regard that the profile of a user is preserved in the HSS as long as the user remains subscribed to the network. Thus, when the user de-register after having obtained, in accordance with the invention, a modification of the status of at least one of his public identities, this modified profile is advantageously preserved for later use.
  • the invention relates to various devices.
  • an S-CSCF server of an IMS network in an IMS network is remarkable in that it comprises means for:
  • said S-CSCF server further comprises means for returning to said user, in response to said message, a list of public identities of the user according to, for each of these public identities, the address of contact to which this public identity is attached.
  • said S-CSCF server further comprises means for also providing in said response the status of each of the public identities of said list.
  • said S-CSCF server further comprises means for, following the modification by this S-CSCF server of the status of at least one of the public identities of the user, to send to the server HSS of said IMS network, a command representative of said modification.
  • the invention also relates, secondly, to an HSS server in an IMS network.
  • Said HSS server is remarkable in that it comprises means for receiving from an S-CSCF server of said IMS network a command representative of a modification of the status of at least one of the public identities of a subscribed user. IMS network audit, and to take into account said modification.
  • the invention also relates, thirdly, to a server of an IMS network.
  • Said server is remarkable in that it understands, or can access, a database as briefly described above.
  • the server may advantageously be an S-CSCF server or an HSS server.
  • the invention also relates, fourthly, to a device able to send a message to an IMS network.
  • Said equipment is remarkable in that it has means for including in said message a specific parameter whose meaning is to ask an S-CSCF server of said IMS network to specifically modify the status of at least one of the public identities of the user of this equipment, and / or to send to the user of this equipment a list of public identities of this user, according to, for each of these public identities, the contact address to which this public identity is attached.
  • this equipment can be a fixed or mobile terminal, a home gateway or located in a company, or a network operator gateway.
  • any of the devices briefly described above may be implemented in the context of an electronic circuit.
  • This electronic circuit may, for example, be constituted by a wired logic chip or include a microprocessor.
  • any of the devices briefly described above may be implemented in the context of software instructions.
  • the invention therefore also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is remarkable in that it includes instructions for performing the steps of any of the methods of public identity management succinctly set forth above, when executed on a computer.
  • FIG. 1, described above, represents a first example of data related to an IMS subscription
  • FIG. 2 represents a second example of data related to an IMS subscription
  • FIG. 3 represents the data resulting from a dynamic modification by the user of the data of FIG. 2, and
  • FIG. 4 illustrates, according to an embodiment of the invention, a method of recording in the HSS a dynamic modification of a status of a public identity of a user.
  • the HSS database server is interrogated in particular:
  • the data related to the IMS subscription and declared on the HSS is transmitted to the S-CSCF in charge of the user by means of the Diameter SAA commands (Server-Assignment-Answer) or PPR (Push-Profile-Request).
  • the SAA command is issued by the HSS in response to a Server-Assignment Request (SAR) issued by the S-CSCF to the HSS when a terminal is registered or when a call arrives at its destination an unregistered subscriber.
  • SAR Server-Assignment Request
  • the PPR command is issued by the HSS following a modification by an operator of the subscriber's profile (change of the IRS, the password, and so on).
  • the content of a user's IMS subscription is static.
  • the public identities of the user by means of which he will be reachable by other users of the network, are defined by the operator, and it is not possible for a user to modify them.
  • the invention introduces the possibility for a user to manage himself the identities by means of which he will be known in the network, by sending to the IMS network an appropriate message. Given the strong constraints inherent in the manipulation of public identities, it is preferable for the network operator to introduce an indicator into the user's IMS subscription to declare whether or not the user is authorized to implement the dynamic management of public identities according to the invention; this indicator will for example be configured in the HSS, then copied into the S-CSCF.
  • the invention also introduces the possibility for an S-CSCF server to associate with each public identity of a user for whom it is responsible the status of this public identity according to the contact address to which this public identity is attached. (the same public identity can be attached to one or more contact addresses).
  • the S-CSCF server according to the invention therefore has the means to update these statuses as and when their service evolution.
  • the method according to the invention is triggered by the sending of a message to the IMS network by a user of this network.
  • this message contains an identifier of the user with the IMS network, such as one of the contact addresses or one of the public identities of the user.
  • the S-CSCF takes into account the parameter represented by the contact address ( ⁇ sip: AoC1>) mentioned in the REGISTER message, preferably by sending back to the user all of his public identities. known and in use associated with this contact address, for example in SIP headers "P-Associated-URI": SIP / 2.0 200 OK
  • SIP REGISTER method is used to convey the dynamic management information of the public identities.
  • another SIP method for example a PUBLISH method, or a new dedicated specific method.
  • the S-CSCF returns all the known public identities and in use of the user associated with the contact address concerned to confirm the modification:
  • the S-CSCF does not return the public identity ⁇ sip: IMPU2 @ home. domain. com>, despite the fact that it belongs to the same 1 RS (I RS2) as the public identity ⁇ sip: IMPU3 @ home. domain. com>.
  • the S-CSCF returns all the known public identities and in use of the user associated with the contact address concerned to confirm the modification:
  • the S-CSCF has indeed taken into account the parameter "add” since the public identity IMPU2 is included in this list in relation to the contact address ⁇ sip: AoC1>; the associated status is "in use” ("active" parameter) according to the above request.
  • This status means that the configuration of this public identity IMPU2 by the network operator is complete, so that the network is ready to process, as the first service associated with this public identity, a connection of the user who owns the network.
  • this public identity transition from "active" status to "registered” status
  • ie a call which will be sent by mail
  • P-Associated-URI ⁇ sip: IMPUlghome. domain. com>: registered: Aocl
  • P-Associated-URI ⁇ tel: IMPU1>: registered: Aocl
  • P-Associated-URI ⁇ sip: IMPU2 @ home. domain. com>: active: Aocl P-Associated-URI: ⁇ sip: IMPU3 @ home. domain. com>: created
  • P-Associated-URI ⁇ sip: IMPU2 @ home. domain. com>: active: Aoc2 P-Associated-URI: ⁇ sip: IMPU3 @ home. domain. com>: created
  • P-Associated-URI ⁇ sip: IMPU5 @ home. domain. com>: maintenance
  • the invention provides a new parameter, hereinafter referred to as "pau", that the S-CSCF can insert into the "Contact" header to represent the P-Associated-URIs and their respective status:
  • the identity IMPU3 has the status of "created” (parameter “created”), which indicates that this identity was created, but is currently out of service (for example, following a move of the subscriber) .
  • the statute "Maintenance" of the IMPU5 identity indicates that an intervention on this identity is in progress; it is therefore temporarily unusable by the owner of this public identity (but the operator can possibly use it to perform line tests).
  • the invention makes it possible to modify the status of a particular public identity for all the contact addresses assigned to the user. For example, if the user wishes to use his identity IMPU3 for his two contact addresses (ie change his status from “created” to "active"), he can (assuming the management indicator allows him to this kind of manipulation) use the following message, which uses the parameters "garlic", “add” and “active” (the “garlic” parameter is preferably used instead of the " * " parameter to avoid confusion with standards in force, which provide for the use of the symbol " * " for the deregistration of all contacts):
  • the S-CSCF returns, for each of the user's contact addresses, all the known public identities and their associated status in order to confirm the modification:
  • the S-CSCF has indeed taken into account the parameters of the REGISTER message since the public identity ⁇ sip: IMPU3 @ home. domain. com> was commissioned with reference to ⁇ sip: AoC1> and ⁇ sip: AoC2> contact addresses.
  • these contact addresses correspond to a fixed telephone and a mobile phone of the user, these two phones will ring when, after their registration refresh (change from "active" to "registered”) , a correspondent enters on his own terminal the telephone number associated with IMPU3.
  • a new Diameter command is introduced on the Cx / Dx interfaces for the backup in the HSS of the configuration modifications described above.
  • This Diameter command which will be called UPR (for Update-Profile-Request), is issued by the S-CSCF to the HSS following the processing of a request for dynamic modification of public identities by a user.
  • the HSS Upon receipt of this new Diameter command, the HSS updates the subscriber's profile according to the structure transmitted in the UPR message (structure itself identical to the structure used in the PPR and SAA messages mentioned above).
  • This structure is an extension according to the present invention of the AVP (Attribute Value Pair) Diameter orders as defined in 3GPP TS 29.228.
  • the AVP includes a "User-Data" field, which is structured according to an XML model of the statuses of a public identity.
  • the HSS then acknowledges the UPR command by a command called UPA (for Update-Profile-Answer) indicating the success or failure of the profile change.
  • UPA Update-Profile-Answer
  • the receipt by the S-CSCF of a UPA indicating a successful modification causes the issuance of a success return code to the user (for example, a 200 OK response to the REGISTER request to change the status of a public identity).
  • the receipt by the S-CSCF of a UPA indicating an error in the processing of the modification of the subscriber's profile causes the transmission of a failure return code to the user (for example, a response 500 Cx "unable to comply"), to inform him that his modification was not taken into account.
  • This mechanism for recording changes in the HSS is illustrated below by way of example, with reference to FIG. 4.
  • step EO the subscriber's IMS subscription contains information on the status of each of its public identities following the registration of the subscriber.
  • step E1 the subscriber decides to modify the status of his public identity IMPU2. It sends for this via its terminal a change request to the network.
  • step E2 the S-CSCF in charge of this subscriber informs the HSS that the subscriber has requested to modify the status of the public identity IMPU2 to make it pass to the "non-registered" state (subject to that the management indicator allows the subscriber to do so, otherwise the S-CSCF sends an error code directly to the subscriber without attempting to contact the HSS).
  • step E3 the HSS updates the subscription of the subscriber according to the information received from the S-CSCF.
  • step E4 the HSS informs the S-CSCF that the UPR command has been positively taken into account.
  • step E5 the S-CSCF informs the user.
  • nodes of a telecommunications network in particular, the S-CSCF servers, the HSS servers and the user terminals
  • the implementation of the invention within, in particular, nodes of a telecommunications network can be realized by means of software components and / or materials.
  • the software components can be integrated into a typical network node management computer program. Therefore, as indicated above, the present invention also relates to a computer system.
  • This computer system conventionally comprises a central processing unit controlling signals by a memory, as well as an input unit and an output unit.
  • this computer system can be used to run a program computer comprising instructions for implementing the method of managing public identities according to the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for executing the steps of a public identity management method according to the invention, when it is executed on a network.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive ("USB flash drive"). in English) or a hard drive.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method of managing public identities according to the invention.

Landscapes

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

Abstract

L'invention concerne un procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS. Selon l'invention, ledit message contient au moins un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1, AoC2) à laquelle cette identité publique est rattachée.

Description

PROCÉDÉ DE GESTION D'IDENTITES PUBLIQUES
PAR UN UTILISATEUR D'UN RESEAU IMS
La présente invention concerne les réseaux de type IP (« Internet Protocol ») qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués.
On rappelle que les réseaux IP permettent la diffusion de données conversationnelles, tels que « Voix sur IP », « Partage de Contenu », « Présence », ou « Messagerie Instantanée ». Dans ces réseaux, les services de communication peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères, par exemple des « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URI est définie dans le document RFC 3986 de l'IETF (Internet Engineering Task Force) ; la connaissance de l'URI d'une ressource permet d'obtenir l'adresse IP d'un équipement du réseau de l'opérateur gérant cette ressource.
Ces équipements peuvent par exemple être un terminal fixe ou mobile, ou une passerelle domestique ou située dans une entreprise (« Residential Gateway » en anglais), ou encore une passerelle d'opérateur réseau (« Voice Gateway » en anglais), qui raccorde généralement un grand nombre de lignes analogiques ou RNIS, telle qu'un DSLAM-SIP (DSLAM sont les initiales des mots anglais « Digital Subscriber Line Access Multiplexer » signifiant « multiplexeur d'accès de lignes d'abonnés numériques » ; il s'agit d'un dispositif collectant le trafic de données DSL qui transite sur un certain nombre de lignes téléphoniques). Par souci de brièveté, on utilisera fréquemment ci- dessous le terme générique de « terminal d'utilisateur », ou de « terminal » tout court, pour désigner ces divers équipements. On rappelle également que les protocoles de contrôle de session évolués classiques, tels que les protocoles H.323 et SIP, utilisent des messages dits « de signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Lorsqu'un client enregistré sur un réseau utilisant un protocole de contrôle de session évolué souhaite bénéficier d'un service multimédia offert par le réseau, il émet vers le réseau un message de signalisation précisant sa requête.
Le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initialisation de Session ») a été défini par l'IETF dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Les ressources de communication y sont identifiées par des « SIP-URI », telles que définies dans la RFC 3261 , ou par des « tel-URI », telles que définies dans la RFC 3966 ; une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1 ), où la partie « host » identifie le réseau sur lequel la ressource (par exemple, l'utilisateur d'un service offert par le réseau) représentée par la partie « user » possède un compte ; une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel :+336123456789).
Ce protocole SIP est utilisé notamment dans les infrastructures de type IMS (initiales des mots anglais « IP Multimedia Subsystem » signifiant « Sous-système Multimédia sur IP »). L'IMS a été défini par l'organisme de normalisation 3GPP (« 3rd Génération Partnership Project »). C'est une architecture de réseau introduite initialement pour les réseaux mobiles, puis étendue à d'autres accès, dont les accès fixes à technologie xDSL. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients, ainsi que la réservation de ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.
Chaque utilisateur d'un réseau IMS peut y être identifié au moyen de diverses identités, dont ΠΜΡΙ (initiales des mots anglais « IP Multimedia Private Identity » signifiant « Identité Privée pour I P Multimédia ») et l'IMPU (initiales des mots anglais « IP Multimedia PUblic identity » signifiant « Identité Publique pour I P Multimédia »).
L'IMPI est défini dans la spécification TS 23.228 du 3GPP. L'IMPI est une identité affectée de manière permanente par l'opérateur d'un réseau à une souscription auprès de cet opérateur, et est utilisé, par exemple, pour l'enregistrement, l'autorisation d'accès, l'administration des services offerts à l'utilisateur, et la facturation (on notera qu'un utilisateur peut avoir plusieurs IMPI au sein de la même souscription ; on peut ainsi associer chaque IMPI à un terminal différent). L'IMPI a la forme d'un NAI (initiales des mots anglais « Network Access Identifier » signifiant « Identifiant d'Accès Réseau »), tel que défini dans le document RFC 4282 de l'I ETF.
Un utilisateur se sert de son IMPU pour communiquer avec d'autres utilisateurs. L'IMPU se présente sous la forme d'une URI ou d'un numéro court, ou encore d'un alias quelconque. Pour un IMPI donné, il peut y avoir plusieurs IMPU (souvent, une tel-URI et une SI P-URI). Un IMPU peut être partagé avec un autre téléphone, de manière à ce que ces téléphones puissent être tous les deux joints avec la même identité (par exemple, un numéro de téléphone unique pour toute une famille d'utilisateurs). Ces identités sont configurées par l'opérateur lors de la création par un utilisateur d'un compte auprès de cet opérateur, et exploitées lors de l'enregistrement du terminal de l'utilisateur sur le réseau.
Lorsque donc un utilisateur souhaite bénéficier des services offerts par un réseau IMS, son terminal doit, sauf exceptions (cas de certains appels d'urgence), s'enregistrer sur le réseau. Pour pouvoir enregistrer les utilisateurs, les réseaux IMS comprennent un ou plusieurs serveurs, généralement appelés « S-CSCF » (initiales des mots anglais « Serving - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.
En outre, ces réseaux comprennent un ou plusieurs serveurs, généralement appelés « l-CSCF » (initiales des mots anglais « Interrogating - Call Session Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») qui, au moment de l'enregistrement d'un terminal d'utilisateur, interrogent un serveur appelé « HSS » (initiales des mots anglais « Home Subscriber Service » signifiant « Service d'Abonné de Rattachement ») pour pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques requises pour atteindre le niveau de service souscrit par cet utilisateur.
Les serveurs S-CSCF, mentionnés ci-dessus, contribuent à la mise en œuvre de ces divers services en gérant le routage de la signalisation, d'une part, entre chaque terminal d'utilisateur et les serveurs du réseau spécialisés dans la mise en œuvre de tel ou tel service souscrit par l'utilisateur, et d'autre part en direction d'autres utilisateurs gérés par le même réseau ou par un réseau qui lui est relié.
Pour pouvoir acheminer ces diverses requêtes au sein du réseau, les serveurs de type l-CSCF ou de type S-CSCF (d'ailleurs souvent combinés en un même serveur, dénoté l/S-CSCF) échangent des informations avec un ou plusieurs serveur(s) de type HSS mentionné ci- dessus. Les serveurs HSS contiennent chacun une base de données- clients, et sont donc l'équivalent dans les réseaux IP des serveurs « HLR » (initiales des mots anglais « Home Location Register » signifiant « Registre de Localisation Nominal ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le profil d'un certain nombre d'utilisateurs du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits.
Dans le processus de création d'un compte d'utilisateurs sur un réseau IMS, l'opérateur du réseau crée d'abord dans le HSS une souscription IMS (notée « IMS Subscription » dans les figures annexées), qui servira de fondement à la facturation. L'opérateur note ensuite, en référence à cette souscription, les identités privées IMPI et publiques IMPU des utilisateurs partageant cette souscription, déclare leurs profils de services et les IFC (initiales des mots anglais « initial Fiiter Criteria » signifiant Critères de Filtrage Initiaux) associés, ainsi que de nombreuses autres informations relatives aux utilisateurs.
Les figures 1 et 2, tirées de la spécification 3GPP TS 23.228, illustrent, à titre d'exemples, des données liées à des souscriptions IMS.
La figure 1 illustre les données liées à la souscription IMS d'un utilisateur ayant une unique identité privée IMPI (notée « Private User Identity ») et trois identités publiques IMPU (notées « Public User Identity 1 », « Public User Identity 2 » et « Public User Identity 3 »). Deux de ces identités publiques sont regroupées dans un 1RS (initiales des mots anglais « Implicit Registration ID Set » signifiant « Ensemble Implicite d'Enregistrement d'Identités »), qui est représenté sur la figure 1 par un rectangle en pointillé. Cette notion d'IRS permet d'utiliser une identité publique pour en enregistrer aussi implicitement une autre. Par exemple, supposons que « l'utilisateur » à enregistrer soit une IPBX, à savoir un PABX (initiales des mots anglais « Private Automatic Branch eXchange » signifiant « Autocommutateur Téléphonique Privé », qui sert principalement à relier les postes téléphoniques d'un établissement avec le réseau téléphonique public) exécutant un logiciel, au lieu d'un équipement électronique indépendant et dédié ; dans ce cas, il est commode de n'avoir à enregistrer que l'une des multiples identités publiques attachées à ΙΊΡΒΧ pour déclarer la présence sur le réseau de l'ensemble des identités : l'IRS contient l'ensemble des identités de ΙΊΡΒΧ. Il en serait de même pour l'enregistrement d'une passerelle offrant plusieurs accès.
On utilise parfois une identité publique spécifique lors de l'enregistrement d'un 1RS. Cette identité représente généralement un utilisateur tel qu'un IPBX ou une passerelle dans son ensemble, et ne peut pas être utilisée en tant que telle à des fins de routage. On parle alors de « barred identity » (mots anglais signifiant « identité non utilisable »).
La figure 2 illustre, avec les mêmes conventions que la figure 1 , les données liées à la souscription IMS -- un peu plus complexe -- d'un utilisateur possédant deux identités privées et six identités publiques regroupées dans trois 1RS ; on notera en particulier que l'identité publique « Public User Identity 3 » est commune aux deux identités privées. La figure montre également les profils de services associés à chacune des identités publiques.
Si, par exemple, l'utilisateur enregistre un terminal configuré avec l'identité privée « Private User Identity 2 » et l'identité publique « Public User Identity 5 », alors l'identité publique « Public Identity 6 » sera elle aussi (implicitement) enregistrée, car ces deux identités publiques appartiennent au même 1RS (IRS3) ; l'utilisateur sera donc joignable sur son terminal à la fois via son identité publique 5 et via son identité publique 6. Cet ensemble de données, utilisé lors de la déclaration sur le HSS, est ensuite transmis au S-CSCF en charge de l'utilisateur. Grâce à ces dispositions, le S-CSCF connaît l'ensemble des identités déclarées dans la souscription IMS, sait quelles identités sont enregistrées implicitement, et peut faire le lien entre les identités publiques et l'adresse de contact du terminal (telle que définie dans la RFC 3261 ) afin d'acheminer les appels entrants. De plus, le S-CSCF connaît l'état d'enregistrement de chaque identité publique ; selon les normes actuelles, cet état peut être « registered » (identité enregistrée), « not registered » (identité non enregistrée), ou encore « unregistered » (identité non enregistrée, mais ayant néanmoins bénéficié d'un service IMS, par exemple le traitement d'un appel destiné à cette identité publique).
Selon l'état de l'art, la déclaration dans le HSS d'une souscription IMS est statique. Autrement dit, les données de la souscription IMS ne peuvent être modifiées que par le processus de « Service Livraison » de l'opérateur (i.e. le Système d'information, inaccessible aux utilisateurs).
Or, il serait fort utile de pouvoir modifier de manière dynamique certaines données de souscription : c'est notamment le cas du contenu des 1RS. Les trois exemples suivants illustrent l'utilité d'une gestion dynamique des 1RS.
Si l'IRS représente un IPBX et la souscription IMS représente le compte de souscription d'une entreprise multi-site, alors la gestion dynamique de l'IRS permettrait de déclarer aisément un utilisateur nomade sur tel ou tel site, selon son plan de route, en retrouvant à chaque fois son profil de service à l'identique.
Si l'IRS représente une passerelle réseau telle qu'une « Voice Gateway » SIP, alors la gestion dynamique de l'IRS permettrait de déclarer certains accès comme indisponibles, ou bien à nouveau en service, au fil des évolutions de cette passerelle. Si l'IRS représente un service tel que la liste « Mes adresses professionnelles », alors la gestion dynamique de l'IRS permettrait d'ajouter ou de retirer, par exemple, un téléphone mobile ou un poste fixe privé de cette liste, selon la disponibilité de leur utilisateur.
Or il n'existe pas dans l'état de l'art de possibilité de modifier dynamiquement le contenu d'un 1RS. En particulier, il n'est pas possible de désenregistrer une identité publique dans l'IRS sans désenregistrer la totalité des identités publiques contenues dans cet 1RS.
La présente invention concerne donc un procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS. Ledit procédé est remarquable en ce que ledit message contient au moins un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.
Grâce à l'invention, on peut ajouter n'importe quelle identité publique de la souscription IMS dans n'importe quel 1RS, ou transférer n'importe quelle identité publique d'une identité privée enregistrée vers n'importe quelle autre identité privée enregistrée (et donc diriger les appels de tiers vers une autre adresse de contact). On offre ainsi un maximum de flexibilité à l'utilisateur dans la gestion de sa joignabilité. Par exemple, dans le cas de la figure 2, on peut transférer dynamiquement l'IMPU « Public User Identity 1 » vers l'IRS 3 en retirant cette IMPU pour ΙΜΡΙ « Private User Identity 1 » et en l'ajoutant pour ΙΜΡΙ « Private User Identity 2 » : le résultat de cette opération est illustré sur la figure 3.
De plus, l'invention offre à l'utilisateur la possibilité de connaître le statut de l'une quelconque de ses identités publiques, compte tenu de l'adresse de contact (et donc de l'identité privée) à laquelle cette identité publique est rattachée. La notion de « statut » selon l'invention généralise la notion classique d'état d'enregistrement ; ainsi (comme illustré dans les exemples ci-dessous), le statut d'une identité publique donnée rattachée à une identité privée donnée (et donc, généralement, à une adresse de contact donnée) pourra représenter son état d'enregistrement, mais aussi, par exemple, une maintenance en cours sur cette identité publique, ou l'historique de service, et ainsi de suite. Ces informations pourront, avantageusement, être stockées dans une base de données dédiée.
C'est pourquoi l'invention propose une base de données, comprenant au moins une identité publique d'un abonné à un réseau IMS en association avec une identité privée dudit abonné. Ladite base de données est remarquable en ce qu'elle mentionne le statut de ladite identité publique, ledit statut étant :
- un paramètre (active) indiquant que cette identité publique est actuellement en service et prête à passer au statut « registered » ou « unregistered », ou
- un paramètre (created) indiquant que cette identité publique a été créée mais est actuellement hors service, ou
- un paramètre (maintenance) indiquant que cette identité publique fait actuellement l'objet d'une intervention de maintenance de la part de l'opérateur dudit réseau.
Les statuts que l'on vient de mentionner ne sont donnés qu'à titre d'exemples, et chaque opérateur de réseau pourra naturellement en définir d'autres selon ses besoins.
Selon des caractéristiques particulières, ledit serveur S-CSCF renvoie audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée. Grâce à ces dispositions, l'utilisateur reçoit confirmation que sa requête a bien été prise en compte, et peut vérifier le rattachement de telle ou telle de ses identités publiques.
Selon des caractéristiques encore plus particulières, ledit serveur S-CSCF fournit également dans ladite réponse le statut de chacune des identités publiques de ladite liste.
Grâce à ces dispositions, l'utilisateur peut également vérifier le statut actuel de telle ou telle de ses identités publiques.
Selon d'autres caractéristiques particulières, suite à la modification par ledit serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur :
- ce serveur S-CSCF émet, à destination du serveur HSS dudit réseau IMS, une commande représentative de ladite modification, et
- ledit serveur HSS prend en compte cette modification.
Grâce à ces dispositions, le serveur HSS peut enregistrer toute modification dans le profil de l'utilisateur. On rappelle à cet égard que le profil d'un utilisateur est préservé dans le HSS tant que l'utilisateur reste abonné au réseau. Ainsi, lorsque l'utilisateur se désenregistre après avoir obtenu, conformément à l'invention, une modification du statut d'au moins une de ses identités publiques, ce profil modifié est avantageusement préservé en vue d'un usage ultérieur.
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, un serveur S-CSCF d'un réseau IMS dans un réseau IMS. Ledit serveur S-CSCF est remarquable en ce qu'il comprend des moyens pour :
- enregistrer et mettre à jour le statut de chacune des identités publiques des utilisateurs dont il a la charge, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée, et - suite à la réception d'un message de la part d'un de ces utilisateurs, prendre en compte au moins un paramètre spécifique contenu dans ledit message et dont la signification est de demander audit serveur S-CSCF de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.
Selon des caractéristiques particulières, ledit serveur S-CSCF comprend en outre des moyens pour renvoyer audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.
Selon des caractéristiques encore plus particulières, ledit serveur S-CSCF comprend en outre des moyens pour fournir également dans ladite réponse le statut de chacune des identités publiques de ladite liste.
Selon d'autres caractéristiques particulières, ledit serveur S-CSCF comprend en outre des moyens pour, suite à la modification par ce serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur, émettre, à destination du serveur HSS dudit réseau IMS, une commande représentative de ladite modification.
L'invention concerne aussi, deuxièmement, un serveur HSS dans un réseau IMS. Ledit serveur HSS est remarquable en ce qu'il comprend des moyens pour recevoir de la part d'un serveur S-CSCF dudit réseau IMS une commande représentative d'une modification du statut d'au moins une des identités publiques d'un utilisateur abonné audit réseau IMS, et pour prendre en compte ladite modification.
L'invention concerne aussi, troisièmement, un serveur d'un réseau IMS. Ledit serveur est remarquable en qu'il comprend, ou peut accéder à, une base de données telle que décrite succinctement ci-dessus. Ce serveur peut, notamment, être avantageusement un serveur S-CSCF ou un serveur HSS.
L'invention concerne aussi, quatrièmement, un équipement apte à envoyer un message à un réseau IMS. Ledit équipement est remarquable en ce qu'il possède des moyens pour inclure dans ledit message un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur de cet équipement, et/ou d'envoyer à l'utilisateur de cet équipement une liste d'identités publiques de cet utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact à laquelle cette identité publique est rattachée.
Comme indiqué ci-dessus, cet équipement peut être aussi bien un terminal fixe ou mobile, qu'une passerelle domestique ou située dans une entreprise, ou encore qu'une passerelle d'opérateur réseau.
Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.
Selon des dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'un circuit électronique. Ce circuit électronique pourra, par exemple, être constitué par une puce à logique câblée ou comprendre un microprocesseur.
Selon d'autres dispositions particulières, on pourra réaliser l'un quelconque des dispositifs succinctement exposés ci-dessus dans le contexte d'instructions logicielles.
L'invention vise donc également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes de l'un quelconque des procédés de gestion d'identités publiques succinctement exposés ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par lesdits procédés.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère aux figures qui l'accompagnent, dans lesquelles :
- la figure 1 , décrite ci-dessus, représente un premier exemple de données liées à une souscription IMS,
- la figure 2, décrite ci-dessus, représente un second exemple de données liées à une souscription IMS,
- la figure 3, décrite ci-dessus, représente les données résultant d'une modification dynamique par l'utilisateur des données de la figure 2, et
- la figure 4 illustre, selon un mode de réalisation de l'invention, un procédé d'enregistrement dans le HSS d'une modification dynamique d'un statut d'une identité publique d'un utilisateur.
Dans un réseau IMS, le serveur de base de données HSS est notamment interrogé :
• par la fonction l-CSCF lors de l'enregistrement d'un terminal d'utilisateur afin d'allouer un serveur l/S-CSCF au terminal ou de retrouver le serveur l/S-CSCF qui lui a été déjà alloué ;
• par la fonction S-CSCF lors de l'enregistrement initial du terminal afin de télécharger les données concernant les services souscrits, dont notamment les points de détection qui permettront au serveur l/S-CSCF de déterminer quel message de signalisation il doit acheminer vers quel serveur d'application (tel qu'un serveur de messagerie vocale, un serveur de présence ou un serveur de téléphonie) ; • par la fonction S-CSCF lors des enregistrements du terminal, afin d'informer le serveur HSS de l'installation ou de la prolongation d'un enregistrement sur le serveur l/S-CSCF ; et
• par la fonction S-CSCF, afin de récupérer les informations nécessaires à l'authentification de la signalisation émise par le terminal.
Les données liées à la souscription IMS et déclarées sur le HSS sont transmises au S-CSCF en charge de l'utilisateur grâce aux commandes Diameter SAA (Server-Assignment-Answer) ou PPR (Push- Profile-Request). La commande SAA est émise par le HSS en réponse à une commande SAR (Server-Assignment-Request) émise par le S-CSCF vers le HSS lors de l'enregistrement d'un terminal ou lors du traitement d'un appel arrivé à destination d'un abonné non enregistré. La commande PPR est émise par le HSS suite à une modification par un opérateur du profil de l'abonné (changement de l'IRS, du mot de passe, et ainsi de suite).
Comme mentionné ci-dessus, dans l'art antérieur, le contenu de la souscription IMS d'un utilisateur est statique. Les identités publiques de l'utilisateur, au moyen desquelles il sera joignable par d'autres utilisateurs du réseau, sont définies par l'opérateur, et il n'est pas possible pour un utilisateur de les modifier.
L'invention introduit la possibilité pour un utilisateur de gérer lui- même les identités au moyen desquelles il sera connu dans le réseau, en envoyant au réseau IMS un message approprié. Compte tenu des fortes contraintes inhérentes à la manipulation d'identités publiques, il est toutefois préférable que l'opérateur du réseau introduise un indicateur dans la souscription IMS de l'utilisateur pour déclarer si l'utilisateur est autorisé ou non à mettre en œuvre la gestion dynamique des identités publiques selon l'invention ; cet indicateur sera par exemple configuré dans le HSS, puis copié dans le S-CSCF. L'invention introduit également la possibilité pour un serveur S- CSCF d'associer à chaque identité publique d'un utilisateur dont il a la charge le statut de cette identité publique en fonction de l'adresse de contact à laquelle cette identité publique est rattachée (la même identité publique pouvant être rattachée à une ou plusieurs adresse(s) de contact). Le serveur S-CSCF selon l'invention a donc les moyens de mettre à jour ces statuts au fur et à mesure de leur évolution de service.
On va maintenant illustrer le fonctionnement et les avantages de l'invention dans le cadre de divers modes de réalisation, en s'appuyant sur la figure 2, déjà décrite ci-dessus, et dans laquelle, par exemple :
• « Public User Identity 1 » est <sip:IMPU1 @home. domain. com>, et
• « Public User Identity 2 » est <tel:IMPU1 >
en association avec l'adresse de contact <sip:AoC1 > ;
• « Public User Identity 5 » est <sip:IMPU4@home. domain. com>, et · « Public User Identity 6 » est <sip:IMPU5@home. domain. com> en association avec l'adresse de contact <sip:AoC2> ; et
• « Public User Identity 3 » est <sip:IMPU2@home. domain. com>, et
• « Public User Identity 4 » est <sip:IMPU3@home. domain. com> en association avec les deux adresses de contact.
Le procédé selon l'invention est déclenché par l'envoi d'un message au réseau IMS par un utilisateur de ce réseau. De manière classique, ce message contient un identifiant de l'utilisateur auprès du réseau IMS, tel que l'une des adresses de contact ou l'une des identités publiques de l'utilisateur.
Considérons par exemple l'enregistrement initial de cet utilisateur sur le réseau IMS avec l'identité publique « IMPU1 @home.domain.com » :
REGISTER sip : home . domain . corn SIP/2.0
To: <sip : IMPUlghome . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER Contact: <sip:AoCl>; [...] ; expires=3600
Une fois l'utilisateur enregistré, le S-CSCF prend en compte le paramètre représenté par l'adresse de contact (<sip:AoC1 >) mentionnée dans le message REGISTER en renvoyant de préférence à l'utilisateur l'ensemble de ses identités publiques connues et en service associées à cette adresse de contact, par exemple dans des en-têtes SIP « P-Associated-URI » : SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: <sip : AoCl> ; [...]; expires=3600
P-Associated-URI : <sip : IMPUl@home . domain . com>
P-Associated-URI : <tel:IMPUl>
P-Associated-URI : <sip : IMPU2@home . domain . com>
P-Associated-URI : <sip : IMPU3@home . domain . com>
On va décrire à présent un mode de réalisation de l'invention dans lequel on utilise la méthode SIP REGISTER pour véhiculer les informations de gestion dynamique des identités publiques. Mais on pourrait également utiliser une autre méthode SIP que la méthode REGISTER, par exemple une méthode PUBLISH, ou une nouvelle méthode spécifique dédiée. En variante, on pourrait tout aussi bien véhiculer les informations de gestion dynamique des identités publiques selon l'invention dans un « body XML ».
Si l'utilisateur souhaite, par exemple, retirer l'identité publique IMPU2 de la liste ci-dessus, il lui suffit (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « remove » :
REGISTER sip : home . domain . corn SIP/2.0
To: <sip : IMPU1 @home . domain . com>
From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: <sip:AoCl>; [...] ; remove=<sip : IMPU2@home . domain . com> :
not_reg; expires=3600 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification :
SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: <sip:AoCl>; [...] ; expires=3600
P-Associated-URI : <sip : IMPUl@home . domain . com>
P-Associated-URI : <tel:IMPUl>
P-Associated-URI : <sip : IMPU3@home . domain . com>
On notera que, contrairement à l'état de l'art, le S-CSCF ne renvoie pas l'identité publique <sip:IMPU2@home. domain. com>, en dépit du fait qu'elle appartient au même 1 RS (I RS2) que l'identité publique <sip:IMPU3@home. domain. com>.
On constate effectivement que le S-CSCF a bien pris en compte le paramètre « remove » en relation avec l'adresse de contact <sip:AoC1 > puisque l'identité publique IMPU2 n'apparaît plus. Dorénavant, cette identité publique ayant (voir requête ci-dessus) le statut de « non enregistrée » (paramètre « not_reg ») pour <sip:AoC1 >, les appels destinés à IMPU2 seront dirigés uniquement vers l'adresse de contact <sip:AoC2>.
Supposons maintenant que l'utilisateur souhaite rajouter l'identité IMPU2 à sa liste des identités publiques associées à l'adresse de contact <sip:AoC1 >. Il lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « add » :
REGISTER sip : home . domain . corn SIP/2.0
To: <sip : IMPU1 @home . domain . com>
From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact : <sip : AoCl> ; [...] ; add=<sip : IMPU2@home . domain . com> :
active; expires=3600 De préférence, le S-CSCF renvoie l'ensemble des identités publiques connues et en service de l'utilisateur associées à l'adresse de contact concernée afin de confirmer la modification :
SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: <sip:AoCl>; [...] ; expires=3600
P-Associated-URI : <sip : IMPUl@home . domain . com>
P-Associated-URI : <tel:IMPUl>
P-Associated-URI : <sip : IMPU2@home . domain . com>
P-Associated-URI: <sip : IMPU3@home . domain . com>
On constate effectivement que le S-CSCF a bien pris en compte le paramètre « add » puisque l'identité publique IMPU2 figure bien dans cette liste en relation avec l'adresse de contact <sip:AoC1 > ; le statut associé est « en service » (paramètre « active ») conformément à la requête ci-dessus. Ce statut signifie que la configuration de cette identité publique IMPU2 par l'opérateur du réseau est terminée, de sorte que le réseau est prêt à traiter, en tant que premier service associé à cette identité publique, soit une connexion de l'utilisateur propriétaire de cette identité publique (passage du statut « active » au statut « registered »), soit un appel (qui sera renvoyé sur messagerie) à l'intention de cet utilisateur (passage du statut « active » au statut « unregistered »).
Supposons maintenant que l'utilisateur souhaite connaître la liste de ses identités publiques, ainsi que leur statut dans le S-CSCF. Il lui suffit alors (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) d'envoyer le message REGISTER suivant, utilisant le paramètre « list » :
REGISTER sip : home . domain . corn SIP/2.0
To: <sip : IMPU1 @home . domain . com>
From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: list=all; Le S-CSCF renvoie alors à l'utilisateur l'ensemble de ses identités publiques connues, ainsi que leur statut respectif, eu égard, pour chacune de ces identités publiques, à l'adresse de contact concernée :
SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact: <sip:AoCl>; [...] ; expires=2340
P-Associated-URI : <sip : IMPUlghome . domain . com> : registered: Aocl P-Associated-URI : <tel : IMPU1> : registered: Aocl
P-Associated-URI : <sip : IMPU2@home . domain . com> : active: Aocl P-Associated-URI : <sip : IMPU3@home . domain . com> : created
Contact: <sip:AoC2>; [...] ; expires=1540
P-Associated-URI : <sip : IMPU2@home . domain . com> : active: Aoc2 P-Associated-URI : <sip : IMPU3@home . domain . com> : created
P-Associated-URI : <sip : IMPU4@home . domain . com> : not_reg
P-Associated-URI : <sip : IMPU5@home . domain . com> : maintenance
En variante, l'invention propose un nouveau paramètre, désigné ci- dessous par « pau », que le S-CSCF peut insérer dans l'en-tête « Contact » pour représenter les P-Associated-URI et leur statut respectif :
SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id: diagxx
CSeq: 1 REGISTER
Contact : <sip : AoCl> ; [...] ; expires=2340 ;
pau : <sip : IMPU1 @home . domain . com> : registered;
pau: <tel : IMPU1> : registered;
pau : <sip : IMPU2 @home . domain . com> : active;
pau : <sip : IMPU3 @home . domain . com> : created
Contact : <sip : AoC2> ; [...] ; expires=1540 ;
pau : <sip : IMPU2 @home . domain . com> : active;
pau : <sip : IMPU3 @home . domain . com> : created;
pau : <sip : IMPU4@home . domain . com> : not_reg;
pau : <sip : IMPU5@home . domain . com> : maintenance
On constate effectivement que le S-CSCF a bien pris en compte le paramètre « list=all » puisque les six identités publiques de l'utilisateur figurent dans cette liste. On note en particulier que l'identité IMPU3 possède le statut de « créée » (paramètre « created »), qui indique que cette identité a été créée, mais est actuellement hors service (par exemple, suite à un déménagement de l'abonné). Le statut « maintenance » de l'identité IMPU5, quant à lui, indique qu'une intervention sur cette identité est en cours ; elle est donc temporairement inutilisable par le propriétaire de cette identité publique (mais l'opérateur peut éventuellement l'utiliser pour effectuer des tests de ligne).
L'invention s'applique naturellement aussi aux « Wilcard Public
User Identifies » (mots anglais signifiant « Identités Publiques d'Utilisateur avec Joker »), lesquelles définissent simplement un ensemble, ou une gamme, d'identités publiques possibles pour une identité privée donnée. On pourra par exemple supprimer une identité publique particulière dans cet ensemble ou cette gamme.
Enfin, on notera que l'invention permet de modifier le statut d'une identité publique particulière pour l'ensemble des adresses de contact attribuées à l'utilisateur. Par exemple, si l'utilisateur souhaite mettre en service son identité IMPU3 pour ses deux adresses de contact (i.e. modifier son statut de « created » à « active »), il pourra (dans l'hypothèse où l'indicateur de gestion lui autorise ce genre de manipulation) utiliser le message suivant, qui utilise les paramètres « ail », « add » et « active » (on utilise de préférence le paramètre « ail » au lieu du paramètre « * » afin d'éviter la confusion avec les normes en vigueur, qui prévoient l'utilisation du symbole « * » pour le désenregistrement de l'ensemble des contacts) :
REGISTER sip : home . domain . corn SIP/2.0
To: <sip : IMPU1 @home . domain . com>
From: <sip : IMPU1 @home . domain . com> ; tag=regtagxx
Call-Id : diagxx
CSeq: 1 REGISTER
Contact: ail; [...] ; add=<sip : IMPU3@home . domain . com> : active;
De préférence, le S-CSCF renvoie, pour chacune des adresses de contact de l'utilisateur, l'ensemble des identités publiques connues ainsi que leur statut associé afin de confirmer la modification :
SIP/2.0 200 OK
To: <sip : IMPU1 @home . domain . com>
From : <sip : IMPUIShome . domain . com> ; tag=regtagxx
Call-Id : diagxx
CSeq: 1 REGISTER Contact : <sip : AoCl> ; [...] ; expires=2340 ;
pau : <sip : IMPU1 @home . domain . com> : registered;
pau: <tel : IMPU1> : registered;
pau : <sip : IMPU2 @home . domain . com> : active;
pau : <sip : IMPU3 @home . domain . com> : active
Contact : <sip : AoC2> ; [...] ; expires=1540 ;
pau : <sip : IMPU2 @home . domain . com> : active;
pau : <sip : IMPU3 @home . domain . com> : active;
pau : <sip : IMPU @home . domain . com> : not_reg;
pau : <sip : IMPU5@home . domain . com> : maintenance
On constate effectivement que le S-CSCF a bien pris en compte les paramètres du message REGISTER puisque l'identité publique <sip:IMPU3@home. domain. com> a été mise en service en référence aux adresses de contact <sip:AoC1 > et <sip:AoC2>. Ainsi, par exemple, si ces adresses de contact correspondent à un téléphone fixe et à un téléphone mobile de l'utilisateur, ces deux téléphones vont sonner lorsque, postérieurement à leur rafraîchissement d'enregistrement (passage de « active » à « registered »), un correspondant saisit sur son propre terminal le numéro de téléphone associé à IMPU3.
On a décrit ci-dessus divers modes de réalisation du procédé selon l'invention de gestion dynamique de ses identités publiques par un utilisateur. La prise en compte des requêtes de l'utilisateur est du ressort du S-CSCF puisque c'est ce dernier qui a en charge la gestion de l'enregistrement des utilisateurs. Cependant, l'évolution des configurations des identités publiques de l'abonné seront perdues lorsque l'utilisateur va se désenregistrer. En effet, dans l'état actuel des normes, la structure de la souscription IMS d'un abonné résultant de la succession des requêtes de modification émises par cet abonné ne peut être transmise vers le HSS. Les normes ne proposent qu'une transmission du profil de l'abonné dans le sens HSS vers S-CSCF, et non dans le sens S-CSCF vers HSS. Aussi, les modifications relatives aux opérations de gestion successives de ses identités par l'utilisateur ne pourront jamais perdurer au-delà de l'expiration d'un enregistrement. Ce constat est particulièrement pénalisant si l'utilisateur est un administrateur en charge d'un IPPBX, mais il sera également déroutant pour un utilisateur grand-public qui ne comprendra pas pourquoi la configuration qu'il avait mise en place n'a pas été sauvegardée dans le réseau.
C'est pourquoi, selon un mode de réalisation de l'invention, on introduit une nouvelle commande Diameter sur les interfaces Cx/Dx pour la sauvegarde dans le HSS des modifications de configuration décrites ci- dessus. Cette commande Diameter, que l'on appellera UPR (pour Update-Profile-Request), est émise par le S-CSCF vers le HSS suite au traitement d'une requête de modification dynamique des identités publiques par un utilisateur.
Sur réception de cette nouvelle commande Diameter, le HSS met à jour le profil de l'abonné conformément à la structure transmise dans le message UPR (structure elle-même identique à la structure utilisée dans les messages PPR et SAA mentionnés ci-dessus). Cette structure constitue une extension selon la présente invention de l'AVP (Attribute Value Pair) des commandes Diameter tel que défini dans la norme 3GPP TS 29.228. Selon cette extension, l'AVP inclut un champ « User-Data », qui est structuré selon un modèle XML des statuts d'une identité publique.
Le HSS acquitte ensuite la commande UPR par une commande que l'on appellera UPA (pour Update-Profile-Answer) indiquant le succès ou l'échec de la modification de profil.
La réception par le S-CSCF d'un UPA indiquant une modification réussie provoque l'émission d'un code de retour de succès vers l'utilisateur (par exemple, une réponse 200 OK à la requête REGISTER de modification du statut d'une identité publique). La réception par le S- CSCF d'un UPA indiquant une erreur dans le traitement de la modification du profil de l'abonné provoque l'émission d'un code de retour d'échec vers l'utilisateur (par exemple, une réponse 500 Cx « unable to comply »), afin de l'informer que sa modification n'a pas été prise en compte. Ce mécanisme d'enregistrement des modifications dans le HSS est illustré ci-dessous par un exemple, en référence à la figure 4.
A l'étape EO, la souscription IMS de l'abonné contient les informations sur le statut de chacune de ses identités publiques suite à l'enregistrement de l'abonné.
A l'étape E1 , l'abonné décide de modifier le statut de son identité publique IMPU2. Il émet pour cela via son terminal une demande de modification à destination du réseau.
A l'étape E2, le S-CSCF en charge de cet abonné informe le HSS que l'abonné a demandé à modifier le statut de l'identité publique IMPU2 pour la faire passer dans l'état « non-enregistré » (sous réserve que l'indicateur de gestion autorise l'abonné à le faire, sinon le S-CSCF renvoie directement un code d'erreur vers l'abonné sans tenter de contacter le HSS).
A l'étape E3, le HSS met à jour la souscription de l'abonné conformément aux informations reçues du S-CSCF.
A l'étape E4, le HSS informe le S-CSCF que la commande UPR a été positivement prise en compte.
Enfin, à l'étape E5, le S-CSCF en informe l'utilisateur.
La mise en œuvre de l'invention au sein, en particulier, de nœuds d'un réseau de télécommunications (notamment, les serveurs S-CSCF, les serveurs HSS et les terminaux d'utilisateur) peut être réalisée au moyen de composants logiciels et/ou matériels.
Les composants logiciels pourront être intégrés à un programme d'ordinateur classique de gestion de nœud de réseau. C'est pourquoi, comme indiqué ci-dessus, la présente invention concerne également un système informatique. Ce système informatique comporte de manière classique une unité centrale de traitement commandant par des signaux une mémoire, ainsi qu'une unité d'entrée et une unité de sortie. De plus, ce système informatique peut être utilisé pour exécuter un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé de gestion d'identités publiques selon l'invention.
En effet, l'invention vise aussi un programme d'ordinateur téléchargeable depuis un réseau de communication comprenant des instructions pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.
Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut 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 clé USB (« USB flash drive » en anglais) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de gestion d'identités publiques selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de gestion d'identités publiques dans un réseau IMS, comprenant une étape au cours de laquelle un utilisateur envoie un message audit réseau IMS, caractérisé en ce que ledit message contient au moins un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée.
2. Procédé de gestion d'identités publiques selon la revendication 1 , caractérisé en ce que le statut d'une identité publique donnée associée à une identité privée donnée représente son état d'enregistrement et/ou l'historique du service associé et/ou une maintenance en cours sur cette identité publique.
3. Procédé de gestion d'identités publiques selon la revendication 1 ou la revendication 2, caractérisé en ce que ledit serveur S-CSCF renvoie audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée.
4. Procédé de gestion d'identités publiques selon la revendication la revendication 3, caractérisé en ce que ledit serveur S-CSCF fournit également dans ladite réponse le statut de chacune des identités publiques de ladite liste.
5. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit message prend la forme d'une méthode SIP REGISTER, et en ce que ledit paramètre est inséré dans l'en-tête « Contact ».
6. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit message prend la forme d'une méthode SIP autre que la méthode REGISTER.
7. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ledit message prend la forme d'un body XML.
8. Procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, suite à la modification par ledit serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur :
- ce serveur S-CSCF émet, à destination du serveur HSS dudit réseau IMS, une commande (Update-Profile-Request) représentative de ladite modification, et
- ledit serveur HSS prend en compte cette modification.
9. Serveur S-CSCF dans un réseau IMS, caractérisé en ce qu'il comprend des moyens pour :
- enregistrer et mettre à jour le statut de chacune des identités publiques des utilisateurs dont il a la charge, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée, et
- suite à la réception d'un message de la part d'un de ces utilisateurs, prendre en compte au moins un paramètre spécifique contenu dans ledit message et dont la signification est de demander audit serveur S-CSCF de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur, et/ou d'envoyer à l'utilisateur une liste d'identités publiques de l'utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée.
10. Serveur S-CSCF selon la revendication 9, caractérisé en ce qu'il comprend en outre des moyens pour renvoyer audit utilisateur, en réponse audit message, une liste d'identités publiques de l'utilisateur en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée.
1 1 . Serveur S-CSCF selon la revendication 10, caractérisé en ce qu'il comprend en outre des moyens pour fournir également dans ladite réponse le statut de chacune des identités publiques de ladite liste.
12. Serveur S-CSCF selon l'une quelconque des revendications 9 à 1 1 , caractérisé en ce qu'il comprend en outre des moyens pour, suite à la modification par ce serveur S-CSCF du statut d'au moins une des identités publiques de l'utilisateur, émettre, à destination du serveur HSS dudit réseau IMS, une commande (Update-Profile-Request) représentative de ladite modification.
13. Serveur HSS dans un réseau IMS, caractérisé en ce qu'il comprend des moyens pour recevoir de la part d'un serveur S-CSCF dudit réseau IMS une commande (Update-Profile-Request) représentative d'une modification du statut d'au moins une des identités publiques d'un utilisateur abonné audit réseau IMS, et pour prendre en compte ladite modification.
14. Équipement apte à envoyer un message à un réseau IMS, caractérisé en ce qu'il possède des moyens pour inclure dans ledit message un paramètre spécifique dont la signification est de demander à un serveur S-CSCF dudit réseau IMS de modifier de manière spécifique le statut d'au moins une des identités publiques de l'utilisateur de cet équipement, et/ou d'envoyer à l'utilisateur de cet équipement une liste d'identités publiques de cet utilisateur, en fonction, pour chacune de ces identités publiques, de l'adresse de contact (AoC1 , AoC2) à laquelle cette identité publique est rattachée.
15. Base de données, comprenant au moins une identité publique d'un abonné à un réseau IMS en association avec une identité privée dudit abonné, caractérisée en ce qu'elle mentionne le statut de ladite identité publique, ledit statut étant :
- un paramètre (active) indiquant que cette identité publique est actuellement en service et prête à passer au statut « registered » ou « unregistered », ou
- un paramètre (created) indiquant que cette identité publique a été créée mais est actuellement hors service, ou
- un paramètre (maintenance) indiquant que cette identité publique fait actuellement l'objet d'une intervention de maintenance de la part de l'opérateur dudit réseau.
16. Serveur d'un réseau IMS, caractérisé en qu'il comprend, ou peut accéder à, une base de données selon la revendication 15.
17. Moyen de stockage de données inamovible, ou partiellement ou totalement amovible, comportant des instructions de code de programme informatique pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 8.
18. Programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions pour l'exécution des étapes d'un procédé de gestion d'identités publiques selon l'une quelconque des revendications 1 à 8, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2012/050255 2011-02-28 2012-02-06 Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims WO2012117178A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1151609A FR2972092A1 (fr) 2011-02-28 2011-02-28 Procede de gestion d'identites publiques par un utilisateur d'un reseau ims
FR1151609 2011-02-28

Publications (1)

Publication Number Publication Date
WO2012117178A1 true WO2012117178A1 (fr) 2012-09-07

Family

ID=45811572

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/050255 WO2012117178A1 (fr) 2011-02-28 2012-02-06 Procédé de gestion d'identites publiques par un utilisateur d'un reseau ims

Country Status (2)

Country Link
FR (1) FR2972092A1 (fr)
WO (1) WO2012117178A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009068113A1 (fr) * 2007-11-30 2009-06-04 Telefonaktiebolaget Lm Ericsson (Publ) Stockage de données de réseau
WO2009155987A1 (fr) * 2008-06-27 2009-12-30 Telefonaktiebolaget Lm Ericsson (Publ) Enregistrement d’identités et d’adresses de contact d’utilisateurs individuels dans un réseau ims

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009068113A1 (fr) * 2007-11-30 2009-06-04 Telefonaktiebolaget Lm Ericsson (Publ) Stockage de données de réseau
WO2009155987A1 (fr) * 2008-06-27 2009-12-30 Telefonaktiebolaget Lm Ericsson (Publ) Enregistrement d’identités et d’adresses de contact d’utilisateurs individuels dans un réseau ims

Also Published As

Publication number Publication date
FR2972092A1 (fr) 2012-08-31

Similar Documents

Publication Publication Date Title
EP2504982B1 (fr) Procede de basculement d&#39;un hss primaire sur un hss de secours dans un reseau ip
EP2080339A1 (fr) Procede de routage d&#39;un message sip en cas d&#39;indisponibilite de noeuds intermediaires
WO2015092278A1 (fr) Procédé de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP3158709B1 (fr) Sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
EP2926524A1 (fr) Routage d&#39;une requete de service visant un abonne ims
FR3011423A1 (fr) Technique de restauration d&#39;un service dans un reseau
EP3646554B1 (fr) Procédé de traitement d&#39;une requête et serveur d&#39;un coeur de réseau ip multimédia
FR3090252A1 (fr) Procédé de basculement d’une communication de TCP sur UDP
EP3472993B1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
WO2012117178A1 (fr) Procédé de gestion d&#39;identites publiques par un utilisateur d&#39;un reseau ims
EP3583757B1 (fr) Procédé de changement de réseau mobile
FR2969453A1 (fr) Procede de localisation et d&#39;identification d&#39;un abonne connecte a un reseau emulant le rtc/rnis
EP3815397B1 (fr) Procédé de détermination d&#39;une localisation géographique d&#39;un point d&#39;accès d&#39;un réseau d&#39;accès local sans fil
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
FR2985135A1 (fr) Procede de propagation des associations entre adresses de contact et identites privees dans un reseau ip.
FR2987207A1 (fr) Procede d&#39;enregistrement d&#39;un serveur d&#39;application et serveur d&#39;application
WO2012049404A1 (fr) Procede de traitement des flux de presence 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: 12707872

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

Country of ref document: EP

Kind code of ref document: A1