WO2015181505A1 - Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal - Google Patents

Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal Download PDF

Info

Publication number
WO2015181505A1
WO2015181505A1 PCT/FR2015/051409 FR2015051409W WO2015181505A1 WO 2015181505 A1 WO2015181505 A1 WO 2015181505A1 FR 2015051409 W FR2015051409 W FR 2015051409W WO 2015181505 A1 WO2015181505 A1 WO 2015181505A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
entity
client device
access network
type
Prior art date
Application number
PCT/FR2015/051409
Other languages
English (en)
Inventor
José DOREE
Jean-Claude Le Rouzic
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2015181505A1 publication Critical patent/WO2015181505A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/02—Processing of mobility data, e.g. registration information at HLR [Home Location Register] or VLR [Visitor Location Register]; Transfer of mobility data, e.g. between HLR, VLR or external networks
    • H04W8/08—Mobility data transfer
    • H04W8/12—Mobility data transfer between location registers or mobility servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information

Definitions

  • the present invention relates to communication networks of IP ("Internet Protocol") type, and in particular those of IP networks that are able to implement advanced session control protocols.
  • IP networks allow the transmission of conversational data, in the context of services such as "Voice over IP” (VoIP), "Content Sharing", or "Instant Messaging”.
  • the present invention relates to the means set up in an IP network to enable entities of this network, such as core network servers, to dynamically update information concerning the type of network. access to which is connected a given client device ("User Equipment" in English).
  • client device User Equipment
  • the "type" of a network represents the technology and architecture implemented in this network.
  • the "client device” concerned by the invention may for example be a mobile terminal. It can also be a fixed terminal, or a home gateway ("Residential Gateway" in English) or located in an enterprise, having access to at least two IP networks; this fixed terminal may for example be a personal computer having access, on the one hand, to the 3G mobile network by means of a "3G key” insertable in the computer, and on the other hand to a fixed network ADSL via a gateway domesticated. It will generally be assumed that the user of this client device has an account with the operator of the IP network, irrespective of the access network used by the client device to connect to this IP network.
  • IP network communication services can identify physical or virtual resources using character strings such as a "URI” (initials of the English words "Uniform Resource Identifier”).
  • URI instants of the English words "Uniform Resource Identifier”
  • the syntax of URIs is defined in RFC 3986 of the 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.
  • SIP-URI resource identifier
  • tel-URI resource identifiers
  • a SIP-URI is of the form “user @ host” (for example, alice @ domain1), where the "host” part identifies the domain of the operator responsible for the identity represented by the "user” part.
  • tel: phone_number for example, tel: +33123456789
  • phone_context "
  • tel: 0623456789; phone-context + 33
  • URI any type of physical or virtual application resource identifier accessible on an IP network.
  • SIP protocol initials of the words “Session Initiation Protocol” meaning “Session Initiation Protocol”
  • signaling messages
  • the SIP protocol has been defined by the Internet Engineering Task Force (IETF) in RFC 3261. This protocol allows the establishment, modification and termination of multimedia sessions in a network using the IP protocol.
  • the SIP protocol has been extended in particular in RFC 3265. This extension defines event notification procedures.
  • IMS infrastructure type IMS
  • IMS IP Multimedia Subsystem
  • 3GPP standardization body Third Generation Partnership Project
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • 3GPP Third Generation Partnership Project
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • 3GPP Third Generation Partnership Project
  • TISPAN Telecommunications and Internet Converged Services and Protocols for Advanced Networking
  • This architecture enables the dynamic establishment and control of multimedia sessions between two clients as well as the reservation of resources at the level of the network for transporting multimedia streams.
  • 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.
  • the client device of the user must, with exceptions (such as certain emergency calls), register on the network.
  • exceptions such as certain emergency calls
  • the network is unable to link this record to a previous record (for example due to a network failure, or following a terminal shutdown for a duration greater than a value predetermined)
  • the recording is considered to be an initial recording.
  • the user's client device must periodically send the network a request to confirm that it wishes to maintain its registration.
  • the networks In order to be able to register the client devices, the networks
  • IMSs include one or more registration servers, called “S-CSCFs" (Initials of the English words “Serving-Call Server Control Function” meaning “Server Call Session Control Function”), suitable (among other functions) to manage the registration procedure for devices connected to the network.
  • S-CSCFs Initials of the English words “Serving-Call Server Control Function” meaning “Server Call Session Control Function”
  • the IMS networks furthermore comprise one or more interrogation servers, called “l-CSCF” (initials of the words “Interrogating-Call Server Control Function” meaning “Interrogating-Call Session Control Function”) - moreover often physically combined with the S-CSCF recording servers to form call servers denoted "l / S-CSCF” - which, at the time of registration of a client device, query a data server of subscriber called “HSS” (initials of the words “Home Subscriber Server” meaning “Subscriber Subscriber Server”), in order to select an S-CSCF server with the characteristics that are obligatorily (and, if necessary, optionally) required to reach the level of service subscribed by the user.
  • HSS data server of subscriber
  • HSS Home Subscriber Server
  • Subscriber Subscriber Server Subscriber Subscriber Server
  • 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 “Link Location Registry”) used in the networks.
  • GSM Global System for Mobile communications
  • Each HSS server contains the "profile” of a number of client devices in the network, this profile including their registration status, authentication and location data, and subscribed services. Indeed, each user can, after an S-CSCF server has been so assigned, send a subscription request to certain services valid for the current connection.
  • the general principle is that a client device can subscribe to a particular service using an appropriate request (SUBSCRIBE).
  • event notifications are sent to the client device as soon as the state of the resource changes; for example, when the user of a terminal has a mailbox on the network, this terminal can subscribe to a message deposit notification, that is to say it can ask to be informed each time a message has been recorded on this mailbox the user's terminal can likewise request to be notified of its own registration status, and so on.
  • the initial subscription requests are issued either automatically just after the terminal has been started or an application installed on this terminal, or following a user action on the terminal interface.
  • the client device For each subscription, the client device must first issue an initial request, and then periodically a request to renew its subscription (we speak of "refreshment" of the subscription).
  • the network For each subscription (whether an initial subscription or a refresh), the network indicates to the client device the refresh period desired by the network operator for this subscription.
  • the maximum refresh period associated with the subscription to a particular "event-package" offered by the network is defined by reference to the document that defines that particular service; for example, concerning the subscription to the message deposit notification, the document RFC 3842 recommends (see "event-package message summary ”) a refreshment period ranging from a few hours to a few days.
  • the IMS networks furthermore comprise one or more servers called "P-CSCF” (initials of the English words "Proxy-Call Server Control Function” meaning “Proxy Call Session Control Function”).
  • P-CSCF Internet Services Controller
  • IP-CAN IP Connectivity Access Network
  • RAT Radio Access Technology
  • LTE Long Term Evolution
  • network operators are faced with the problem of being able to offer a user services that depend on the type of access network on which the user is is located. Indeed, some services can only work if the speed they require is available for access; however this rate varies considerably according to the RAT implemented by the access network.
  • Some services for example video sharing ("video sharing" in English) of the RCS ("Rich Communication Services") package, can operate in LTE technology, can work with degraded quality in 3G technology, and are downright non-functional in 2G technology.
  • some applications may only be available on the basis of sufficient throughput.
  • the access network type information may also be used to adjust an operating parameter, such as whether or not to transmit a High Definition audio or video stream.
  • Another motivation to know the type of access a subscriber is on is related to taxation. Indeed, an operator could apply preferential rates for the same service when it becomes aware that the service will be degraded (for example because the service is not intended to be used on this or that type of radio coverage) or simply to encourage the use of an access network that offloads the global radio network.
  • the 3GPP TS 24.229 standard provides that a SIP header called "P-Access-Network-Information" (or PANI) is used to convey information about the type of access network used by 3GPP. a given client device. It is intended to disseminate this information when establishing a session, but not during an established session, or outside of the session. Consequently, according to the state of the art, it is not possible for IMS core network entities such as an S-CSCF server or an application server to know the type of access network used. by a given client device at any time.
  • PANI P-Access-Network-Information
  • CDRs Charging Data Records
  • a CDR is, in the terminology 3GPP, a formatted collection of information about a taxable telecommunication event (such as placing a phone call, or browsing the Internet from a mobile phone); an operator issues CDRs to prepare the bills of its subscribers, and relies primarily on CDRs issued by AS or S-CSCF servers.
  • the present invention therefore relates to a notification method in an IP network, said method being related to a given client device connected to an access network to an IP core network, and comprising the following steps:
  • an entity of an IP network issues a subscription request to the access network type change events by this client device, addressed to a public identity of the user of the client device,
  • connection entity between said IP core network and said access network, in charge of said client device, receives said subscription request, and informs the subscribing network entity of the type of access network to which the device -client is currently connected, and
  • connection entity if said connection entity receives information indicating another type of access network to which the client device has subsequently connected, the connection entity transmits this information to the subscribing network entity.
  • the invention proposes to create a new type of subscription enabling any entity of an IP network that has subscribed to the notifications according to the invention, to be informed of any change, by a certain client device, of a network. access involving a change of "type of access network" within the meaning of the invention.
  • this subscriber network entity can dynamically modify the characteristics recorded concerning this client-device (such as a mobile terminal or gateway), so as to take the appropriate measures.
  • These measures may consist, for example, in avoiding routing incoming calls to a client device that is not under a radio coverage for rendering a service associated with this call (with, possibly, release of the call), or else to enrich the CDRs generated by the different network devices having subscribed to the notifications according to the invention, by indicating in these CDR changes in the type of access of the client device.
  • the subscription requests (initial or refresh) issued by the subscribing network entity are addressed to a public identity of the user of the client device (for example, its tel-URI).
  • the subscriber network entity will not have the means to know the URI of the connection entity in charge of the client device; the fact of addressing the subscription request to the public identity associated with the client device makes it possible to advantageously rely on the conventional routing mechanisms in the IP networks to send the request to this connection entity;
  • a change of access network by the client device will involve a change of connection entity to the core network; in this case, according to the standards in force, the old connecting entity will be notified because the client-device concerned is no longer responsible, and, consequently, the former connection entity will send an end-of-subscription notification to the subscribing network entity; the subscriber network entity will therefore issue, at the address of said public identity, a new subscription request, which will be automatically transferred to the new connection entity.
  • said method further comprises a step during which said connecting entity in charge of said client device transmits, to a network policy command entity, a network type change notification request. access relating to said client device; furthermore, during said step c), said information received by the connection entity and mentioning another type of access network to which the client device subsequently connected, is provided by said network policy control entity .
  • connection entity can itself be informed of said access network changes, on the basis of mechanisms already existing in a number of current IP networks.
  • the invention relates to various devices.
  • connection entity between an IP core network and an access network to said IP network, having means for:
  • connection entity receives information mentioning another type of access network to which the client-device has subsequently connected, transmit this information to the subscriber network entity.
  • connection entity is remarkable in that it also has means for:
  • the invention also relates, secondly, to an entity of an IP network.
  • Said network entity is remarkable in that it has means for:
  • connection entity receiving, from said connection entity, a notification message informing it of another type of access network to which the client device subsequently connected.
  • This subscriber network entity may in particular be a core network server, such as a registration server or an application server, or another client device, such as a terminal or a gateway.
  • a core network server such as a registration server or an application server
  • another client device such as a terminal or a gateway.
  • the invention also relates to a computer program downloadable from a communication network and / or stored on a computer readable medium and / or executable by a microprocessor.
  • This computer program is notable in that it includes instructions for performing the steps of the notification method succinctly set forth above, when executed on a computer.
  • the multimedia services offered by this IMS network 1 may include telephony services, video telephony, content-sharing ("content-sharing" in English), presence, instant messaging, or television. These services are available to the user of a user device ("User Equipment” or "UE") 10 belonging to the network 1, which enables the client device 10 to exchange data. multimedia streams and session control signals conforming to the SIP protocol, for example with the client device (not shown) of a user belonging to a SIP network (not shown) connected to the network 1.
  • UE User Equipment
  • the client device 10 may be a fixed or mobile terminal, or a home or enterprise gateway, with SIP signaling means and may include means for restitution of audiovisual content.
  • this IMS network 1 comprises, in addition to an IP transport infrastructure (not shown):
  • the S-CSCF server 27 manages in particular the procedure for registering the devices connected to the network 1; the S-CSCF server 27 also manages the routing of the signaling between the client device 10 and the voicemail servers VM 25, instant messaging 26, and telephony TAS 29;
  • the l-CSCF server 22 notably manages the routing towards other terminals managed by the same IMS network 1 and the routing of the signaling between this IMS network 1 and other networks (not shown);
  • the P-CSCF server 21 serves as a connection entity between the IMS core network and the access network used by the client device 10;
  • At least one database server, of the HSS type contains the profile of the user of the client device 10 in terms of authentication data, location and subscribed services;
  • At least one VM-25 voice mail server (“message-summary"); the server VM 25 manages the subscription of the client device 10 to the events of deposit / consultation of the messages to the client device 10, and notifies the client device 10 at the occurrence of these events;
  • At least one TAS 29 telephony server the TAS server manages the telephone services to which the user of the terminal 10 has subscribed with his operator, such as the presentation of the number or call forwarding.
  • the VM 25 voicemail servers, IM 26 instant messaging servers, and TAS 29 telephony servers are examples of Application Servers (AS).
  • Some services such as those of the VM server 25 and the IM instant messaging server 26, rely on the subscription of the terminal 10 to predetermined events, as explained above.
  • PCC Policy and Charging Control
  • PCRF Policy Control and Charging Rules Function
  • PCEF operator policy
  • the entity PCRF is able to determine the charging method for a given service flow; it has access to the user's subscription data in order to be able to adapt the use of the transport resources made by this service, as well as the charging of the service, according to the profile of the user.
  • the PCEF selects a PCC rule for each data packet of said flow by examining the service data contained in that packet.
  • the dashed lines represent the actual path followed by the SIP signals (between the UE 10 and the PCEF entity 31, then between the PCEF entity 31 and the P-CSCF server 21).
  • the hatched line (between the UE 10 and the P-CSCF 21 server) represents the "logical" path of the SIP signaling.
  • the PCRF entity 30 is connected to the PCEF entity 31 and the P-CSCF server 21.
  • PCRF entity exploited by the present invention in the specific context of the IMS networks are fulfilled, in the context of any type of IP network, by an entity called "network policy control entity", whose PCRF entity represents a particular case.
  • Each entity of the IP network wishing to exploit the radio access type change information, which will be called for example "Access_modification”, for a certain client device must subscribe according to the invention to the connection entity (P-CSCF server in an IMS network) in charge of this client device.
  • the subscription request is sent by this network entity, preferably just after the network registration of the client device.
  • IP-CAN IP-CAN
  • the subscriber node is an application server (AS) hosting a service type "service 1".
  • AS application server
  • the AS receives a copy of a REGISTER registration request sent by a client device.
  • This copy may for example be sent to the AS by the S-CSCF server in charge of the client device concerned, in accordance with paragraph 5.4.1 .7 of TS 24.229 mentioned above.
  • the AS is configured to react to the reception of said registration request by subscribing to the P-CSCF server, during a step E1, to the type change event. access network by this client device.
  • the AS issues the following request:
  • SUBSCRIBE indicates that it is a SIP ("method") subscription message.
  • the destination IP resource of this SIP message (generally called "Request-URI"), which is indicated after the word "SUBSCRIBE” as well as in the "To” field, is here: sip: impu_observed_user @ operator. ims. com,
  • IP Multimedia PUblic identity or IMPU in English
  • the AS has in fact read this IMPU by consulting the REGISTER request received at step E0.
  • This request SUBSCRIBE issued by the AS is, in a manner known per se, received (on the basis of the recipient IMPU) by the S-CSCF server in charge of the client device concerned, and transferred to the P-CSCF server in charge. of this client device.
  • the P-CSCF server accepts the subscription:
  • the P-CSCF server informs the AS, in the NOTIFY notification (NOTIFY) of the subscription finalization, of the type of access network type currently used by the client device .
  • the access network type information is conveyed within a dedicated header, which we will call "Access-Event": NOTIFY sip: AS_servicel @ operator. ims. com SIP / 2.0
  • RAT-TYPE HSPA_EVOLUTION
  • Access-Event indicates the contact address (represented by "AoC" of the client device; indeed, when a client device changes access network, it changes at the same time contact address; the type of access network to which the client device targeted by the subscription is connected is therefore associated with a certain contact address of this client device.
  • step E4 the AS confirms the good reception of the message NOTIFY: SIP / 2.0 200 OK
  • the P-CSCF server sends (on an interface called "Rx") - if it has not already done so - a request for notification to the PCRF entity of the IMS network.
  • the P-CSCF server may advantageously, for example, apply the procedure indicated in sections 4.4.6.4 and 5.3.13 of the standard TS 29.214, as well as that in section B.1 a of 3GPP TS 29.213: the request for notification takes the form of an "AA-Request" (AAR) order valuing an "Attribute-Value Pair” (AVP) field called " Specific-Action "with the value" IP-CAN_CHANGE ".
  • AAR AA-Request
  • AVP Attribute-Value Pair
  • the server P-CSCF Following receipt by the P-CSCF server, during a step E6, from a PCRF entity, of an access network type change information concerning the client device, the server P- CSCF, during a step E7, informs the AS:
  • this notification indicates, in the "Access-Event” header, the new contact address ("AoC") of the client-device concerned by the subscription.
  • the subscription refresh requests sent by the AS will also be addressed to the IMPU of the user of the client device, and will therefore be transferred in the same way by the S-CSCF server to the client. P-CSCF server. The latter will therefore continue to send to the AS, if necessary, access network change notifications by the client device.
  • a change of access network by the client device may possibly be accompanied by a change of IP address of this client device.
  • the client device must issue a new registration request, and then the embodiment described above will be resumed from step E0.
  • the subscribing network entity is an S-CSCF server instead of an AS.
  • This second embodiment is similar to the first mode described above, except that there is obviously no step E0.
  • the subscriber network entity is a second client device, distinct from the client device whose "access network changes" are “monitored".
  • this second client device will generally not receive a copy of the registration requests sent by the "monitored” client device.
  • the subscription requests issued by this second client device may be triggered by various other mechanisms (for example, device-client).
  • the access network type information has been conveyed in the Access-Event header of the NOTIFY message sent to the subscribers. But other formats are obviously possible to convey this information. Thus, according to a second variant, this information can be conveyed in the message body ("body xml" in English) of the NOTIFY message.
  • the present invention can be implemented within the nodes of an IP network, for example connection entities or core network servers, by means of software and / or hardware components.
  • 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 may be used to execute a computer program comprising instructions for implementing any of the notification methods of the invention.
  • the invention also relates to a downloadable computer program from a communication network comprising instructions for performing the steps of a notification method according to the invention, when it is executed on a computer.
  • This computer program may be stored on a computer readable medium and may be executable by a microprocessor.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any another desirable form.
  • the invention also relates to an information carrier, irremovable, or partially or completely removable, readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, such as a hard disk, or a USB key. (“USB flash drive" in English).
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the computer program according to the invention can in particular be downloaded to an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in carrying out any of the notification methods of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de notification dans un réseau IP, 5 ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès audit réseau IP, et comprenant les étapes suivantes : une entité d'un réseau IP émet une requête de souscription aux évènements de changement de type de réseau d'accès par ce dispositif-client, adressée à une identité publique de l'utilisateur du dispositif-client; l'entité de 10 raccordement entre ledit cœur de réseau IP et ledit réseau d'accès, en charge dudit dispositif-client, reçoit ladite requête de souscription, et informe l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté; si ladite entité de raccordement reçoit une information mentionnant un autre type de réseau 15 d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet cette information à l'entité réseau souscriptrice. Application aux réseaux IMS.

Description

PROCEDE POUR INFORMER UNE ENTITE D'UN RESEAU IP DU TYPE DE RESEAU D'ACCES UTILISE PAR UN TERMINAL
La présente invention concerne les réseaux de communications de type IP (« Internet Protocol »), et notamment ceux parmi les réseaux IP qui sont aptes à mettre en œuvre des protocoles de contrôle de session évolués. Les réseaux IP permettent la diffusion de données conversationnelles, dans le cadre de services tels que « Voix sur IP » (VoIP), « Partage de Contenu », ou « Messagerie Instantanée ».
Plus particulièrement, la présente invention concerne les moyens mis en place dans un réseau IP pour permettre à des entités de ce réseau, telles que des serveurs de cœur de réseau, de mettre à jour de façon dynamique des informations concernant le type de réseau d'accès auquel est connecté un dispositif-client (« User Equipment » en anglais) donné. Au sens de l'invention, le « type » d'un réseau représente la technologie et l'architecture mises en œuvre dans ce réseau.
Le « dispositif-client » concerné par l'invention peut par exemple être un terminal mobile. Il peut également s'agir d'un terminal fixe, ou d'une passerelle domestique (« Residential Gateway » en anglais) ou située dans une entreprise, ayant accès à au moins deux réseaux IP ; ce terminal fixe peut par exemple être un ordinateur personnel ayant accès, d'une part, au réseau mobile 3G au moyen d'une « clé 3G » insérable dans l'ordinateur, et d'autre part à un réseau fixe ADSL via une passerelle domestique. On supposera en général que l'utilisateur de ce dispositif- client possède un compte auprès de l'opérateur du réseau IP, et ce, quel que soit le réseau d'accès utilisé par le dispositif-client pour se connecter à ce réseau IP.
Des exemples de serveurs de cœur de réseau aptes à mettre en œuvre la présente invention seront fournis plus bas. Les services de communication sur réseau IP peuvent identifier des ressources physiques ou virtuelles au moyen de chaînes de caractères telles qu'une « URI » (initiales des mots anglais « Uniform Resource Identifier » signifiant « Identifiant Uniforme de Ressource »). La syntaxe des URIs est définie dans le document RFC 3986 de l'IETF ; 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.
En particulier, dans les réseaux mettant en œuvre le protocole SIP, on distingue deux types d'identifiants de ressource : ceux de la forme « SIP-URI » telle que définie dans la RFC 3261 , ou ceux de la forme « tel- URI » telle que définie dans la RFC 3966. Une SIP-URI est de la forme « user@host » (par exemple, alice@domaine1 ), où la partie « host » identifie le domaine de l'opérateur responsable de l'identité représentée par la partie « user ». Une tel-URI est de la forme « tel:numéro_de_téléphone » (par exemple, tel :+33123456789) en référence aux numéros de téléphone publics internationaux, ou de la forme « tel:numéro_de_téléphone;phone-context=... » (par exemple, tel:0623456789;phone-context=+33) en référence aux numéros de téléphone attribués par un opérateur pour son réseau privé.
Par souci de brièveté, dans le reste de la présente description, nous appellerons « URI » tout type d'identifiant de ressource applicative physique ou virtuelle accessible sur un réseau IP.
Les protocoles de contrôle de session évolués classiques, tels que le protocole SIP (initiales des mots anglais « Session Initiation Protocol » signifiant « Protocole d'Initiation de Session »), utilisent des messages dits de « signalisation », qui sont des messages permettant à un terminal de demander une connexion avec un autre terminal, ou également des messages signalant qu'une ligne téléphonique est occupée, ou signalant que le téléphone appelé sonne, ou encore signalant que tel téléphone est connecté au réseau et peut être joint de telle ou telle manière. Le protocole SIP a été défini par l'IETF {Internet Engineering Task Force) dans le document RFC 3261 . Ce protocole permet l'établissement, la modification et la terminaison de sessions multimédia dans un réseau utilisant le protocole IP. Le protocole SIP a ensuite été étendu notamment dans le document RFC 3265. Cette extension définit des procédures de notification d'événements.
Le protocole SIP est utilisé en particulier 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 (« Third Génération Partnership Project ») et TISPAN (« Télécommunications and Internet Converged Services and Protocols for Advanced Networking »). C'est une architecture de réseau introduite par le 3GPP pour les réseaux mobiles, puis reprise par TISPAN pour les réseaux fixes. Cette architecture permet l'établissement dynamique et le contrôle de sessions multimédia entre deux clients ainsi que la réservation des ressources au niveau du réseau de transport des flux multimédias. Grâce à cette architecture, les opérateurs réseau peuvent commodément mettre en œuvre une politique de gestion, fournir une Qualité de Service prédéterminée, et calculer les montants à facturer aux clients. L'IMS permet actuellement d'accéder à des services de type téléphonie, visiophonie, Présence et Messagerie Instantanée, dont elle gère aussi l'interaction.
Lorsqu'un usager souhaite bénéficier des services offerts par un réseau IMS, il émet vers le réseau des messages de signalisation pouvant inclure notamment divers types de requêtes.
Tout d'abord, le dispositif-client de l'usager doit, sauf exceptions (telles que certains appels d'urgence), s'enregistrer sur le réseau. Lorsque le réseau est incapable de faire le lien entre cet enregistrement et un enregistrement précédent (par exemple suite à une panne réseau, ou suite à un arrêt du terminal pendant une durée supérieure à une valeur prédéterminée), l'enregistrement est considéré comme étant un enregistrement initial. Après un enregistrement initial, le dispositif-client de l'utilisateur doit envoyer périodiquement au réseau une requête pour confirmer qu'il souhaite maintenir son enregistrement.
Pour pouvoir donc enregistrer les dispositifs-clients, les réseaux
IMS comprennent un ou plusieurs serveurs d'enregistrement, appelés « S- CSCF » (initiales des mots anglais « Serving-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Serveuse »), aptes (entre autres fonctions) à gérer la procédure d'enregistrement des dispositifs connectés au réseau.
Les réseaux IMS comprennent en outre un ou plusieurs serveurs d'interrogation, appelés « l-CSCF » (initiales des mots anglais « Interrogating-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Interrogatrice ») — d'ailleurs souvent combinés physiquement avec les serveurs d'enregistrement S-CSCF pour constituer des serveurs d'appel dénotés « l/S-CSCF »— qui, au moment de l'enregistrement d'un dispositif-client, interrogent un serveur de données d'abonné appelé « HSS » (initiales des mots anglais « Home Subscriber Server » signifiant « Serveur d'Abonné de Rattachement »), afin de pouvoir sélectionner un serveur S-CSCF possédant les caractéristiques qui sont obligatoirement (et, le cas échéant, optionnellement) requises pour atteindre le niveau de service souscrit par l'usager. 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 de Rattachement ») utilisés dans les réseaux GSM. Chaque serveur HSS contient le « profil » d'un certain nombre de dispositifs-clients du réseau, ce profil comprenant leur état d'enregistrement, des données d'authentification et de localisation, et les services souscrits. En effet, chaque usager peut, après qu'un serveur S-CSCF lui ait été ainsi attribué, envoyer une requête de souscription à certains services valable pour la connexion en cours. Le principe général est qu'un dispositif-client peut souscrire à un service particulier à l'aide d'une requête appropriée (SUBSCRIBE). Ainsi, dans le cas d'une souscription à l'état d'une ressource, des notifications d'événement (NOTIFY) sont envoyées au dispositif-client dès lors que l'état de la ressource change ; par exemple, lorsque l'utilisateur d'un terminal dispose d'une boîte vocale sur le réseau, ce terminal peut souscrire à une notification de dépôt de message, c'est-à-dire qu'il peut demander à être informé chaque fois qu'un message a été enregistré sur cette boîte vocale ; le terminal de l'utilisateur peut, de même, demander à être notifié de son propre état d'enregistrement, et ainsi de suite.
Les requêtes de souscription initiales sont émises soit de manière automatique juste après le démarrage du terminal ou d'une application installée sur ce terminal, soit suite à une action de l'utilisateur sur l'interface du terminal. Pour chaque souscription, le dispositif-client doit émettre d'abord une requête initiale, et puis périodiquement une requête pour renouveler sa souscription (on parle de « rafraîchissement » de la souscription).
Pour chaque souscription (qu'il s'agisse d'une souscription initiale ou d'un rafraîchissement), le réseau indique au dispositif-client la période de rafraîchissement souhaitée par l'opérateur du réseau pour cette souscription. Dans le cas du document RFC 3265, la période de rafraîchissement maximale associée à la souscription à un service (« event-package » en anglais) particulier offert par le réseau est définie par renvoi au document qui définit ce service particulier ; par exemple, concernant la souscription à la notification de dépôt de message, le document RFC 3842 préconise (cf. « event-package message summary ») une période de rafraîchissement allant de quelques heures à quelques jours.
Les réseaux IMS comprennent en outre un ou plusieurs serveurs appelés « P-CSCF » (initiales des mots anglais « Proxy-Call Server Control Function » signifiant « Fonction de Commande de Session d'Appel Mandataire »). Pour chaque dispositif-client connecté à un réseau IMS, il existe un serveur P-CSCF servant d'entité de raccordement entre le cœur de réseau IMS et le réseau d'accès utilisé par ce dispositif-client ; ainsi, toute la signalisation SIP échangée entre le dispositif-client d'une part, et le serveur d'interrogation l-CSCF ou le serveur d'enregistrement S-CSCF d'autre part, passe par le serveur P-CSCF.
Les normes TS 23.203 et TS 29.212 du 3GPP prévoient de caractériser les réseaux d'accès en termes de technologie et d'architecture, à l'aide d'un identifiant appelé IP-CAN (initiales des mots anglais « IP Connectivity Access Network » signifiant « Réseau d'Accès à la Connectivité IP ») ; un certain nombre de valeurs possibles pour ΙΊΡ- CAN sont définies dans la Section 5.3.27 de la norme TS 29.212. Pour un IP-CAN donné, on peut au besoin indiquer de manière plus précise la technologie radio (« Radio Access Technology », ou RAT, en anglais) utilisée ; un certain nombre de valeurs possibles pour la RAT sont définies dans la Section 5.3.31 de la norme TS 29.212.
Avec la mise en œuvre de la norme LTE (« Long Term Evolution ») du 3GPP, les opérateurs réseau sont confrontés à la problématique consistant à pouvoir offrir à un usager des services qui dépendent du type de réseau d'accès sur lequel l'usager est situé. En effet, certains services ne peuvent fonctionner que si le débit qu'ils requièrent est disponible à l'accès ; or ce débit varie considérablement en fonction de la RAT mise en œuvre par le réseau d'accès. Certains services, comme par exemple le partage vidéo (« video sharing » en anglais) du bouquet RCS (« Rich Communication Services »), peuvent fonctionner en technologie LTE, peuvent fonctionner avec une qualité dégradée en technologie 3G, et sont carrément non-fonctionnels en technologie 2G. Outre les services, ce sont certaines applications qui pourraient n'être disponibles que sur la base d'un débit suffisant. Au sein d'un service donné, l'information du type de réseau d'accès peut également servir à ajuster un paramètre de fonctionnement, tel que la possibilité ou non d'émettre un flux audio ou vidéo en Haute Définition.
Une autre motivation à connaître le type d'accès sur lequel se trouve un abonné est liée à la taxation. En effet, un opérateur pourrait appliquer des tarifs préférentiels pour un même service dès lors qu'il a connaissance que le service sera dégradé (par exemple parce que le service n'est pas prévu pour être utilisé sur tel ou tel type de couverture radio), ou simplement pour encourager l'utilisation d'un réseau d'accès qui déleste le réseau radio global.
La norme TS 24.229 du 3GPP prévoit qu'un en-tête (« header » en anglais) SIP appelé « P-Access-Network-Information » (ou PANI) permet de véhiculer l'information du type de réseau d'accès utilisé par un dispositif-client donné. Il est prévu de diffuser cette information lors de l'établissement d'une session, mais non au cours d'une session établie, ou en-dehors de la session. En conséquence, selon l'état de l'art, il n'est pas possible pour des entités du cœur de réseau IMS telles qu'un serveur S- CSCF ou un serveur d'applications de connaître le type de réseau d'accès utilisé par un dispositif-client donné à n'importe quel instant.
Or cette information est accessible à tout instant aux serveurs P- CSCF, mais les serveurs P-CSCF ne sont pas en charge de la gestion des services, lesquels sont généralement du ressort des serveurs d'application (« Application Servers », ou AS, en anglais). Les serveurs P- CSCF ne sont pas non plus en charge de l'émission des rapports de données de taxation (« Charging Data Records », ou CDR en anglais) ; on rappelle à cet égard (cf. Wikipedia) qu'un CDR est, dans la terminologie du 3GPP, une collection formatée d'informations concernant un événement de télécommunication taxable (comme le fait de placer un appel téléphonique, ou de naviguer sur Internet à partir d'un téléphone mobile) ; un opérateur émet des CDR pour préparer les factures de ses abonnés, et il se fonde principalement pour ce faire sur les CDR émis par des AS ou par des serveurs S-CSCF.
La présente invention concerne donc un procédé de notification dans un réseau IP, ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès à un cœur de réseau IP, et comprenant les étapes suivantes :
a) une entité d'un réseau IP émet une requête de souscription aux événements de changement de type de réseau d'accès par ce dispositif-client, adressée à une identité publique de l'utilisateur du dispositif-client,
b) l'entité de raccordement entre ledit cœur de réseau IP et ledit réseau d'accès, en charge dudit dispositif-client, reçoit ladite requête de souscription, et informe l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et
c) si ladite entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet cette information à l'entité réseau souscriptrice.
Ainsi, l'invention propose de créer un nouveau type de souscription permettant à une quelconque entité d'un réseau IP ayant souscrit aux notifications selon l'invention, d'être informée de tout changement, par un certain dispositif-client, de réseau d'accès impliquant un changement de « type de réseau d'accès » au sens de l'invention.
Grâce à ces dispositions, cette entité réseau souscriptrice pourra modifier dynamiquement les caractéristiques enregistrées concernant ce dispositif-client (tel qu'un terminal mobile ou une passerelle), de manière à prendre les mesures adaptées. Ces mesures peuvent consister par exemple à éviter de router des appels arrivés vers un dispositif-client qui n'est pas sous une couverture radio permettant de rendre un service associé à cet appel (avec, éventuellement, libération de l'appel), ou bien à enrichir les CDR engendrés par les différents dispositifs réseau ayant souscrit aux notifications selon l'invention, en indiquant dans ces CDR les changements de type d'accès du dispositif-client.
On notera que, selon l'invention, les requêtes de souscription (initiale ou de rafraîchissement) émises par l'entité réseau souscriptrice sont adressées à une identité publique de l'utilisateur du dispositif-client (par exemple, sa tel-URI). Cette caractéristique présente plusieurs avantages :
• dans nombre d'applications de l'invention, l'entité réseau souscriptrice n'aura pas les moyens de connaître l'URI de l'entité de raccordement en charge du dispositif-client ; le fait d'adresser la requête de souscription à l'identité publique associée au dispositif-client permet de s'appuyer avantageusement sur les mécanismes classiques de routage dans les réseaux IP pour faire parvenir la requête à cette entité de raccordement ;
• même si l'on considère une entité réseau souscriptrice ayant les moyens de connaître l'URI de l'entité de raccordement, l'invention dispense cette entité réseau souscriptrice d'avoir à mémoriser cette URI ; cette mémorisation aurait d'ailleurs été particulièrement complexe en cas de « forking », c'est-à-dire lorsqu'un usager utilise plusieurs dispositifs- clients sous la même identité publique ;
• dans certains cas, un changement de réseau d'accès par le dispositif-client impliquera un changement d'entité de raccordement au cœur de réseau ; dans ce cas, selon les normes en vigueur, l'ancienne entité de raccordement sera notifiée du fait que le dispositif-client concerné n'est plus à sa charge, et, conséquemment, l'ancienne entité de raccordement enverra une notification de fin de souscription à l'entité réseau souscriptrice ; l'entité réseau souscriptrice émettra donc, à l'adresse de ladite identité publique, une nouvelle requête de souscription, qui sera automatiquement transférée à la nouvelle entité de raccordement.
Selon des caractéristiques particulières, ledit procédé comprend en outre une étape au cours de laquelle ladite entité de raccordement en charge dudit dispositif-client émet, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client ; de plus, lors de ladite étape c), ladite information reçue par l'entité de raccordement et mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, est fournie par ladite entité de commande de politique réseau.
Grâce à ces dispositions, l'entité de raccordement peut être elle- même informée desdits changements de réseau d'accès, sur la base de mécanismes déjà existants dans nombre de réseaux IP actuels.
Corrélativement, l'invention concerne divers dispositifs.
Elle concerne ainsi, premièrement, une entité de raccordement entre un cœur de réseau IP et un réseau d'accès audit réseau IP, possédant des moyens pour :
- recevoir, de la part d'une entité dudit réseau IP, une requête de souscription aux événements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau d'accès et dont ladite entité de raccordement a la charge,
- informer l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et
- si l'entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, transmettre cette information à l'entité réseau souscriptrice.
Ladite entité de raccordement est remarquable en ce qu'elle possède en outre des moyens pour :
- émettre, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et
- recevoir, de la part de ladite entité de commande de politique réseau, une information indiquant un type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté.
L'invention concerne aussi, deuxièmement, une entité d'un réseau IP. Ladite entité réseau est remarquable en ce qu'elle possède des moyens pour :
- émettre une requête de souscription aux événements de changement de type de réseau d'accès par un dispositif-client connecté à un réseau d'accès à un cœur de réseau IP, adressée à une identité publique de l'utilisateur du dispositif-client,
- recevoir, de la part de l'entité de raccordement entre ledit cœur de réseau IP et ledit réseau d'accès, en charge dudit dispositif-client, une information concernant le type de réseau d'accès auquel ledit dispositif- client est présentement connecté, et
- recevoir, de la part de ladite entité de raccordement, un message de notification l'informant d'un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté.
Cette entité réseau souscriptrice pourra notamment être un serveur de cœur de réseau, tel qu'un serveur d'enregistrement ou un serveur d'applications, ou un autre dispositif-client, tel qu'un terminal ou une passerelle. Les avantages offerts par ces dispositifs sont essentiellement les mêmes que ceux offerts par les procédés corrélatifs succinctement exposés ci-dessus.
On notera qu'il est possible de réaliser ces dispositifs dans le contexte d'instructions logicielles et/ou dans le contexte de circuits électroniques.
L'invention vise également un programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur. Ce programme d'ordinateur est remarquable en ce qu'il comprend des instructions pour l'exécution des étapes du procédé de notification succinctement exposé ci-dessus, lorsqu'il est exécuté sur un ordinateur.
Les avantages offerts par ce programme d'ordinateur sont essentiellement les mêmes que ceux offerts par ledit procédé.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée ci-dessous de modes de réalisation particuliers, donnés à titre d'exemples non limitatifs. La description se réfère à la figure unique qui l'accompagne, et qui représente schématiquement un système pour la fourniture de services multimédia apte à mettre en œuvre l'invention.
Bien que la présente invention concerne les réseaux IP en général, on va considérer à présent, à titre d'exemple de réalisation, une architecture de réseau de type IMS, telle que présentée succinctement ci- dessus. Cette architecture est illustrée sur la figure 1.
Les services multimédia offerts par ce réseau IMS 1 peuvent comprendre des services de téléphonie, de vidéo-téléphonie, de partage de contenu (« content-sharing » en anglais), de Présence, de Messagerie Instantanée, ou de télévision. Ces services sont à la disposition de l'utilisateur d'un dispositif-client (« User Equipment », ou UE en anglais) 10 appartenant au réseau 1 , qui permet au dispositif-client 10 d'échanger des flux multimédias et des signaux de contrôle de session conformes au protocole SIP, par exemple avec le dispositif-client (non représenté) d'un utilisateur appartenant à un réseau SIP (non représenté) relié au réseau 1 .
Le dispositif-client 10 peut être un terminal fixe ou mobile, ou une passerelle domestique ou d'entreprise, disposant de moyens de signalisation SIP et pouvant comprendre des moyens de restitution d'un contenu audiovisuel.
Comme le montre la figure 1 , ce réseau IMS 1 comprend, outre une infrastructure de transport IP (non représentée) :
• au moins un serveur S-CSCF ; le serveur S-CSCF 27 gère notamment la procédure d'enregistrement des dispositifs connectés au réseau 1 ; le serveur S-CSCF 27 gère également le routage de la signalisation entre le dispositif-client 10 et les serveurs de messagerie vocale VM 25, de Messagerie Instantanée 26, et de téléphonie TAS 29 ;
• au moins un serveur l-CSCF ; le serveur l-CSCF 22 gère notamment le routage en direction d'autres terminaux gérés par le même réseau IMS 1 et le routage de la signalisation entre ce réseau IMS 1 et d'autres réseaux (non représentés) ;
• au moins un serveur P-CSCF ; le serveur P-CSCF 21 sert d'entité de raccordement entre le cœur de réseau IMS et le réseau d'accès utilisé par le dispositif-client 10 ;
• au moins un serveur de base de données, de type HSS ; le serveur HSS 24 contient le profil de l'utilisateur du dispositif-client 10 en termes de données d'authentification, de localisation et de services souscrits ;
• au moins un serveur VM 25 de messagerie vocale (« message- summary » en anglais) ; le serveur VM 25 gère la souscription du dispositif-client 10 aux événements de dépôt/consultation des messages à l'intention du dispositif-client 10, et notifie le dispositif- client 10 lors de l'occurrence de ces événements ;
• au moins un serveur de Messagerie Instantanée IM 26 ; en cas de souscription de l'utilisateur de l'UE 10 au service de Messagerie Instantanée, cet utilisateur peut dialoguer « instantanément » en ligne avec d'autres abonnés à ce service ; et
• au moins un serveur de téléphonie TAS 29 ; le serveur TAS gère les services téléphoniques auxquels l'utilisateur du terminal 10 a souscrits auprès de son opérateur, tels que la présentation du numéro ou le renvoi d'appel.
Les serveurs de messagerie vocale VM 25, de Messagerie Instantanée IM 26, et de téléphonie TAS 29 sont des exemples de Serveurs d'Applications (AS).
Certains services, comme ceux du serveur VM 25 et du serveur de Messagerie Instantanée IM 26, s'appuient sur la souscription du terminal 10 à des événements prédéterminés, comme expliqué ci-dessus.
Pour mettre en œuvre la taxation des usagers, les réseaux IMS utilisent une architecture appelée PCC (initiales des mots anglais « Policy and Charging Control » signifiant « Commande de Politique et de Taxation »). Comme expliqué par exemple dans le tutoriel intitulé « PCC (Policy and Charging Control) pour les Services Data Mobiles » publié en 201 1 par la Société « Etudes et Formations en Télécommunications » (cf. http ://www. ef o rt . co m ) , cette architecture PCC consiste en une entité centrale appelée PCRF (initiales des mots anglais « Policy Control and Charging Rules Function » signifiant « Fonction de Commande de Politique et de Règles de Taxation »), qui fournit des règles de taxation et de « politique d'opérateur » (comme par exemple le débit maximum alloué, ou la priorité du flux selon son type) à une entité appelée PCEF (initiales des mots anglais « Policy and Charging Enforcement Function » signifiant « Fonction d'Application de Politique et de Taxation »). L'entité PCRF est apte à déterminer la méthode de taxation pour un flux de service donné ; elle a accès aux données d'abonnement de l'usager afin de pouvoir adapter l'utilisation des ressources de transport faite par ce service, ainsi que la taxation du service, en fonction du profil de l'usager. L'entité PCEF sélectionne une règle PCC pour chaque paquet de données dudit flux en examinant les données de service contenues dans ce paquet.
Sur la figure 1 , les lignes en pointillé représentent le chemin réel suivi par les signaux SIP (entre l'UE 10 et l'entité PCEF 31 , puis entre l'entité PCEF 31 et le serveur P-CSCF 21 ). La ligne hachurée (entre l'UE 10 et le serveur P-CSCF 21 ) représente le chemin « logique » de la signalisation SIP. L'entité PCRF 30 est connectée à l'entité PCEF 31 et au serveur P-CSCF 21 .
On suppose que les fonctions de l'entité PCRF exploitées par la présente invention dans le cadre spécifique des réseaux IMS sont remplies, dans le cadre d'un type quelconque de réseau IP, par une entité appelée « entité de commande de politique réseau », dont l'entité PCRF représente un cas particulier.
Chaque entité du réseau IP souhaitant exploiter l'information de changement de type d'accès radio, que l'on appellera par exemple « Access_modification », pour un certain dispositif-client doit souscrire conformément à l'invention auprès de l'entité de raccordement (serveur P- CSCF dans un réseau IMS) en charge de ce dispositif-client. La demande de souscription est émise par cette entité réseau, de préférence, juste après l'enregistrement réseau du dispositif-client.
L'entité réseau recevra alors des notifications lors de tout changement, par le dispositif-client concerné, de réseau d'accès impliquant un changement de « type de réseau » au sens de l'invention. Il peut s'agir, par exemple : - d'un changement d'IP-CAN (par exemple de IP-CAN-TYPE=3GPP- GPRS à IP-CAN-TYPE=3GPP-EPS), sans changement de RAT, ou
- d'un changement de RAT (par exemple, de RAT- TYPE=HSPA_EVOLUTION à RAT-TYPE=GERAN), sans changement d'IP-CAN, ou encore
- d'un changement à la fois d'IP-CAN et de RAT.
On va décrire à présent un premier mode de réalisation du procédé de notification selon l'invention, dans lequel le nœud souscripteur est un serveur d'applications (AS) hébergeant un service de type « service 1 ».
Lors d'une étape E0, l'AS reçoit une copie d'une requête d'enregistrement REGISTER émise par un dispositif-client. Cette copie peut par exemple être envoyée à l'AS par le serveur S-CSCF en charge du dispositif-client concerné, conformément à l'alinéa 5.4.1 .7 de la norme TS 24.229 mentionnée ci-dessus.
Dans le présent mode de réalisation, l'AS est configuré de manière à réagir à la réception de ladite requête d'enregistrement, en souscrivant auprès du serveur P-CSCF, lors d'une étape E1 , à l'événement de changement de type de réseau d'accès par ce dispositif-client. Pour ce faire, l'AS émet la requête suivante :
SUBSCRIBE sip : impu_observed_user@operator . ims . com SIP/2.0 To: <sip : impu_observed_user@operator . ims . com >
From: <sip: AS_servicel Ooperator . ims . com> ; tag=78923 Call-Id: [...]
CSeq: 1 SUBSCRIBE
Contact : AS_servicel@operator . ims . co
Event : Access_modification
Expires : [...]
Accept : application/Access_modification-notification Content-Length: 0 Comme expliqué plus haut, la mention SUBSCRIBE indique qu'il s'agit d'un message SIP (« méthode ») de souscription. On notera que, conformément à l'invention, la ressource IP destinataire de ce message SIP (appelée de manière générale « Request-URI »), qui est indiquée à la suite du mot « SUBSCRIBE » ainsi que dans le champ « To », est ici : sip : impu_observed_user@operator . ims . com,
laquelle n'est autre que l'identité publique (« IP Multimedia PUblic identity », ou IMPU en anglais) de l'utilisateur du dispositif-client ; l'AS a en effet pris connaissance de cette IMPU en consultant la requête REGISTER reçue à l'étape E0.
Cette requête SUBSCRIBE émise par l'AS est, de manière connue en soi, reçue (sur la base de l'IMPU destinataire) par le serveur S-CSCF en charge du dispositif-client concerné, et transférée au serveur P-CSCF en charge de ce dispositif-client.
Lors d'une étape E2, le serveur P-CSCF accepte la souscription :
SIP/2.0 200 OK
To : impu_observed_user@operator . ims . com; tag=123456 From: <sip: AS_servicel Ooperator . ims . com> ; tag=78923 Call-Id: [ ...]
CSeq: 1 SUBSCRIBE
Contact : [ ... ]
Event : Access_modif ication
Expires : [ ... ]
Content -Length : 0 Lors d'une étape E3, le serveur P-CSCF informe l'AS, dans la notification (message NOTIFY) de finalisation de souscription, du type de type de réseau d'accès présentement utilisé par le dispositif-client. Selon une première variante, les informations de type de réseau d'accès sont véhiculées au sein d'un en-tête (« header ») dédié, que nous appellerons « Access-Event » : NOTIFY sip : AS_servicel@operator . ims . com SIP/2.0
From: <sip : impu_observed_user@operator . ims . com> ; tag=123456 To : <sip: AS_servicel@operator . ims . com>; tag=78923
Call-Id: [ ...]
CSeq: 1 NOTIFY
Contact : [ ... ]
Event : Access_modification
Subscription-State : active
Access-Event :AoC; IP-CAN-TYPE=3GPP-GP S ;
RAT—TYPE=HSPA_EVOLUTION
Content-Length: 0
On notera que l'en-tête « Access-Event » ci-dessus indique l'adresse de contact (représentée par « AoC ») du dispositif-client ; en effet, lorsqu'un dispositif-client change de réseau d'accès, il change en même temps d'adresse de contact ; le type de réseau d'accès auquel est connecté le dispositif-client visé par la souscription est donc associé à une certaine adresse de contact de ce dispositif-client.
Lors d'une étape E4, l'AS confirme la bonne réception du message NOTIFY : SIP/2.0 200 OK
From: <sip: impu_observed_user@operator . ims . com> ; tag=123456
To : <sip : AS_ser ice1@opérâtor . ims . com> ;tag=78923 Call-Id: [ ...]
CSeq: 1 NOTIFY
Contact : [ ... ]
Lors d'une étape E5, le serveur P-CSCF émet (sur une interface appelée « Rx »)— s'il ne l'a pas déjà fait— une demande de notification à destination de l'entité PCRF du réseau IMS. Pour ce faire, le serveur P- CSCF peut avantageusement, par exemple, appliquer la procédure indiquée dans les Sections 4.4.6.4 et 5.3.13 de la norme TS 29.214, ainsi que dans la section B.1 a de la norme TS 29.213 du 3GPP : la demande de notification prend alors la forme d'une commande « AA-Request » (AAR) valorisant un champ « Attribute-Value Pair » (AVP) appelé « Specific-Action » avec la valeur « IP-CAN_CHANGE ». En conséquence, le serveur P-CSCF sera notifié par l'entité PCRF à chaque fois que le dispositif-client passe d'un réseau d'accès d'un certain type, à un réseau d'accès d'un autre type.
Suite à la réception par le serveur P-CSCF, lors d'une étape E6, de la part d'une entité PCRF, d'une information de changement de type de réseau d'accès concernant le dispositif-client, le serveur P-CSCF, lors d'une étape E7, en informe l'AS :
NOTIFY sip : AS_servicel@operator . ims . corn SIP/2.0
From: <sip : impu_observed_user@operator . ims . com >;tag=123456
To : <sip: AS_servicel@operator . ims . com>; tag=78923
Call-Id: [ ...]
CSeq: 2 NOTIFY
Contact : [ ... ]
Event : Access_modification
Subscription-State : active
Access-Event : AoC; IP—CAN—TYPE=3GPP—GPRS; RAT—TYPE=GERAN
Content-Length: 0
On notera que cette notification indique, dans l'en-tête « Access- Event », la nouvelle adresse de contact (« AoC ») du dispositif-client concerné par la souscription.
Enfin, lors d'une étape E8, l'AS confirme la bonne réception du message NOTIFY :
SIP/2.0 200 OK
From: <sip : impu_observed_user@operator . ims . com >;
tag=123456
To: <sip: AS_servicel@operator . ims . com>; tag=78923
Call-Id: [ ...] CSeq: 2 NOTIFY
Contact : [ ... ]
Dans la suite de la session, les requêtes de rafraîchissement de souscription émises par l'AS auront elles aussi pour destinataire l'IMPU de l'utilisateur du dispositif-client, et seront donc transférées de la même manière par le serveur S-CSCF au serveur P-CSCF. Ce dernier continuera donc à envoyer à l'AS, le cas échéant, des notifications de changement de réseau d'accès par le dispositif-client.
On notera qu'un changement de réseau d'accès par le dispositif- client pourra éventuellement s'accompagner d'un changement d'adresse IP de ce dispositif-client. Dans ce cas, le dispositif-client devra émettre une nouvelle requête d'enregistrement, et l'on reprendra alors le mode de réalisation décrit ci-dessus à partir de l'étape E0.
Selon un deuxième mode de réalisation de l'invention, l'entité réseau souscriptrice est un serveur S-CSCF au lieu d'un AS. Ce deuxième mode de réalisation est analogue au premier mode décrit ci-dessus, si ce n'est qu'il n'y a évidemment pas d'étape E0.
Selon un troisième mode de réalisation de l'invention, l'entité réseau souscriptrice est un second dispositif-client, distinct du dispositif- client dont on « surveille » les changements de réseau d'accès. Dans ce cas, ce second dispositif-client ne recevra généralement pas de copie des requêtes d'enregistrement émises par le dispositif-client « surveillé ». A la place, les requêtes de souscription émises par ce second dispositif-client (à l'adresse d'une identité publique de l'utilisateur du dispositif-client « surveillé ») peuvent être déclenchées par divers autres mécanismes (par exemple, dispositif-client « surveillant » un autre dispositif-client associé à la même identité publique, ou contrôle technique effectué par l'opérateur dudit cœur de réseau à l'aide d'un terminal ou d'une passerelle lui appartenant). Dans les modes de réalisation décrits ci-dessus, les informations de type de réseau d'accès ont été véhiculées dans l'en-tête Access-Event du message NOTIFY envoyé aux souscripteurs. Mais d'autres formats sont évidemment possibles pour véhiculer ces informations. Ainsi, selon une deuxième variante, ces informations peuvent être véhiculées dans le corps de message (« body xml » en anglais) du message NOTIFY.
De manière générale, la présente invention peut être mise en œuvre au sein des nœuds d'un réseau IP, par exemple des entités de raccordement ou des serveurs de cœur de réseau, 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 de l'un quelconque des procédés de notification 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 notification selon l'invention, lorsqu'il est exécuté sur un ordinateur. Ce programme d'ordinateur peut être stocké sur un support lisible par ordinateur et peut être exécutable par un microprocesseur.
Ce programme peut utiliser n'importe quel langage de programmation, et se présenter sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations, inamovible, ou partiellement ou totalement amovible, lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comprendre un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou un moyen d'enregistrement magnétique, tel qu'un disque dur, ou encore une clé USB (« USB flash drive » en anglais).
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme d'ordinateur selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
En variante, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un quelconque des procédés de notification selon l'invention.

Claims

R E V E N D I C A T I O N S
1 . Procédé de notification dans un réseau IP, ledit procédé étant relatif à un dispositif-client donné connecté à un réseau d'accès à un cœur de réseau IP, et comprenant les étapes suivantes :
a) une entité d'un réseau IP émet une requête de souscription aux événements de changement de type de réseau d'accès par ce dispositif-client, adressée à une identité publique de l'utilisateur du dispositif-client,
b) l'entité de raccordement entre ledit cœur de réseau IP et ledit réseau d'accès, en charge dudit dispositif-client, reçoit ladite requête de souscription, et informe l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et
c) si ladite entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, l'entité de raccordement transmet cette information à l'entité réseau souscriptrice.
2. Procédé de notification selon la revendication 1 , caractérisé en ce qu'il comprend en outre une étape au cours de laquelle ladite entité de raccordement en charge dudit dispositif-client émet, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et en ce que, lors de ladite étape c), ladite information reçue par l'entité de raccordement et mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, est fournie par ladite entité de commande de politique réseau.
3. Procédé de notification selon la revendication 2, caractérisé en ce que, ledit réseau IP étant un réseau IMS, ladite entité de commande de politique réseau comprend une entité PCRF.
4. Procédé de notification selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite entité réseau souscriptrice est un serveur de cœur de réseau.
5. Procédé de notification selon l'une quelconque des revendications 1 à 3, caractérisé en ce que ladite entité réseau souscriptrice comprend un terminal ou une passerelle distincts dudit dispositif-client.
6. Procédé de notification selon l'une quelconque des revendications précédentes, caractérisé en ce que, ledit réseau IP étant un réseau IMS, ledit changement de type de réseau d'accès concerne un changement de type d'IP-CAN (IP Connectivity Access Network) et/ou un changement de type de RAT (Radio Access Technology).
7. Entité de raccordement entre un cœur de réseau IP et un réseau d'accès, possédant des moyens pour :
- recevoir, de la part d'une entité dudit réseau IP, une requête de souscription aux événements de changement de type de réseau d'accès concernant un dispositif-client connecté audit réseau d'accès et dont ladite entité de raccordement a la charge,
- informer l'entité réseau souscriptrice du type de réseau d'accès auquel le dispositif-client est présentement connecté, et
- si l'entité de raccordement reçoit une information mentionnant un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté, transmettre cette information à l'entité réseau souscriptrice,
caractérisée en ce qu'elle possède en outre des moyens pour :
- émettre, à destination d'une entité de commande de politique réseau, une demande de notification de changement de type de réseau d'accès concernant ledit dispositif-client, et - recevoir, de la part de ladite entité de commande de politique réseau, une information indiquant un type de réseau d'accès auquel le dispositif- client s'est subséquemment connecté.
8. Entité de raccordement selon la revendication 7, caractérisée en ce que, ledit réseau IP étant un réseau IMS, ladite entité de raccordement comprend un serveur P-CSCF.
9. Entité d'un réseau IP, caractérisée en ce qu'elle possède des moyens pour :
- émettre une requête de souscription aux événements de changement de type de réseau d'accès par un dispositif-client connecté à un réseau d'accès à un cœur de réseau IP, adressée à une identité publique de l'utilisateur du dispositif-client,
- recevoir, de la part de l'entité de raccordement entre ledit cœur de réseau IP et ledit réseau d'accès, en charge dudit dispositif-client, une information concernant le type de réseau d'accès auquel ledit dispositif- client est présentement connecté, et
- recevoir, de la part de ladite entité de raccordement, un message de notification l'informant d'un autre type de réseau d'accès auquel le dispositif-client s'est subséquemment connecté.
10. Entité réseau selon la revendication 9, caractérisée en ce qu'elle comprend un serveur de cœur de réseau.
1 1 . Entité réseau selon la revendication 10, caractérisée en ce que ledit serveur de cœur de réseau est un serveur d'enregistrement ou un serveur d'applications.
12. Entité réseau selon la revendication 1 1 , caractérisé en ce que, ledit réseau IP étant un réseau IMS, ledit serveur d'enregistrement est un serveur S-CSCF.
13. Entité réseau selon la revendication 9, caractérisée en ce qu'elle comprend un terminal ou une passerelle distincts dudit dispositif- client.
14. 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 notification selon l'une quelconque des revendications 1 à 6.
15. Programme d'ordinateur téléchargeable depuis un réseau de communications 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 notification selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté sur un ordinateur.
PCT/FR2015/051409 2014-05-28 2015-05-28 Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal WO2015181505A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1454857 2014-05-28
FR1454857A FR3021836A1 (fr) 2014-05-28 2014-05-28 Procede pour informer une entite d' un reseau ip du type de reseau d' acces utilise par un terminal

Publications (1)

Publication Number Publication Date
WO2015181505A1 true WO2015181505A1 (fr) 2015-12-03

Family

ID=51168249

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/051409 WO2015181505A1 (fr) 2014-05-28 2015-05-28 Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal

Country Status (2)

Country Link
FR (1) FR3021836A1 (fr)
WO (1) WO2015181505A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3067552A1 (fr) * 2017-06-26 2018-12-14 Orange Procede de detection de composants media orphelins

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1435748A1 (fr) * 2002-12-30 2004-07-07 France Telecom Sa Transfert entre réseaux mobiles de technologies différentes
US20060104262A1 (en) * 2004-11-18 2006-05-18 Azaire Networks Inc. Maintaining consistent network connections while moving through wireless networks
WO2008077669A2 (fr) * 2006-12-22 2008-07-03 Nokia Corporation Changement de réseau d'accès
WO2011098920A1 (fr) * 2010-02-12 2011-08-18 Alcatel Lucent Procédé et appareil permettant de fournir à des applications des informations de présence sur un réseau d'accès
US20120020345A1 (en) * 2009-04-20 2012-01-26 Zte Corporation Method for implementing limited policy and charging control and system thereof

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1435748A1 (fr) * 2002-12-30 2004-07-07 France Telecom Sa Transfert entre réseaux mobiles de technologies différentes
US20060104262A1 (en) * 2004-11-18 2006-05-18 Azaire Networks Inc. Maintaining consistent network connections while moving through wireless networks
WO2008077669A2 (fr) * 2006-12-22 2008-07-03 Nokia Corporation Changement de réseau d'accès
US20120020345A1 (en) * 2009-04-20 2012-01-26 Zte Corporation Method for implementing limited policy and charging control and system thereof
WO2011098920A1 (fr) * 2010-02-12 2011-08-18 Alcatel Lucent Procédé et appareil permettant de fournir à des applications des informations de présence sur un réseau d'accès

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3067552A1 (fr) * 2017-06-26 2018-12-14 Orange Procede de detection de composants media orphelins
WO2019002730A1 (fr) * 2017-06-26 2019-01-03 Orange Procédé de synchronisation d'état média
US11824669B2 (en) 2017-06-26 2023-11-21 Orange Method of media state synchronization

Also Published As

Publication number Publication date
FR3021836A1 (fr) 2015-12-04

Similar Documents

Publication Publication Date Title
WO2015092278A1 (fr) Procédé de mise a jour dynamique d&#39;informations obtenues de la part d&#39;un serveur dns
WO2011064492A1 (fr) Procede de basculement d&#39;un hss primaire sur un hss de secours dans un reseau ip
EP3278532A1 (fr) Procédé de priorisation de flux médias dans un réseau de communications
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
WO2020128258A1 (fr) Procédé de basculement d&#39;une communication de tcp sur udp
WO2014083289A1 (fr) Routage d&#39;une requete de service visant un abonne ims
EP3158709A1 (fr) Procédé de sélection dynamique par un appelant parmi une pluralité de terminaux d&#39;un appelé
WO2019102117A1 (fr) Procédé de propagation d&#39;informations concernant la bande passante allouée à un usager d&#39;un réseau ip
WO2015181505A1 (fr) Procédé pour informer une entité d&#39;un réseau ip du type de réseau d&#39;accès utilisé par un terminal
EP3391615B1 (fr) Procédé de communication entre un terminal appelant et une pluralité de terminaux appelés
EP3472993B1 (fr) Procédé de détermination d&#39;un ensemble de formats de codage pour établir une communication
EP3646578B1 (fr) Procédé de synchronisation d&#39;état média
FR2969453A1 (fr) Procede de localisation et d&#39;identification d&#39;un abonne connecte a un reseau emulant le rtc/rnis
WO2014170582A1 (fr) Procede de restauration de service dans un reseau ims
EP2801178B1 (fr) Procédé dynamique de détermination d&#39;une liste de services dans un réseau sip
WO2018215719A1 (fr) Procédé de contrôle d&#39;une communication comprenant des transactions multiples
WO2018150150A1 (fr) Procédé de changement de réseau mobile
WO2012049404A1 (fr) Procede de traitement des flux de presence dans un reseau sip
WO2007148015A2 (fr) Systeme de declenchement d&#39;un comptage dans un reseau de transport a travers un reseau a architecture de type ims

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15732322

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

Country of ref document: EP

Kind code of ref document: A1