WO2011144846A1 - Technique d'acces a un service par un utilisateur - Google Patents

Technique d'acces a un service par un utilisateur Download PDF

Info

Publication number
WO2011144846A1
WO2011144846A1 PCT/FR2011/051072 FR2011051072W WO2011144846A1 WO 2011144846 A1 WO2011144846 A1 WO 2011144846A1 FR 2011051072 W FR2011051072 W FR 2011051072W WO 2011144846 A1 WO2011144846 A1 WO 2011144846A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
service
access
authentication
access request
Prior art date
Application number
PCT/FR2011/051072
Other languages
English (en)
Inventor
Jean-Baptiste Hennequin
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 WO2011144846A1 publication Critical patent/WO2011144846A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/102—Gateways
    • H04L65/1033—Signalling gateways
    • H04L65/1036—Signalling gateways at the edge
    • 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/1069—Session establishment or de-establishment

Definitions

  • the invention is in the field of telecommunications and more particularly in the implementation of services in a type of communication network 3P ("Internet Protocol").
  • 3P Internet Protocol
  • the invention finds a particularly advantageous application in the field of IP-based communication networks for 'dissemination of audiovisual data, especially when access to a content delivery service established according to the procedures set in the area of I' IMS ("B? Multimedia Subsystem") by the 3rd Generation Partnership Project (3GPP) and TISPAN ("Telecommunications and Internet Converged Services and Protocols for Advanced Networking").
  • 3GPP 3rd Generation Partnership Project
  • TISPAN Time Division Multiple Access Plus
  • the IMS is a network architecture that allows establishment and control of a multimedia session as well as resource reservation at the level of the media flow transport network. This network architecture notably allows the implementation of an interaction between services.
  • the technical specifications TS 182 027 and TS 183 063 defined by the TISPAN group describe the IPTV architectures on an IMS architecture and mechanisms enabling a user's terminal to access a content broadcasting service.
  • a user To access a service, a user must first register with the IMS core network. Then, the user subscribes to an SDF server, for "Service Discovery Function", implementing the service, such as the content distribution service, and in return obtains a list of at least one selection server. SSF service, for "Service Selection Function”. The user then transmits an access request to the SSF service selection server.
  • SDF server for "Service Discovery Function”
  • SSF service for "Service Selection Function”.
  • PBTSI TS 183 063 In order to offer a personalized service according to the user, it is proposed in the technical specification of PBTSI TS 183 063 to implement a user authentication function.
  • This authentication function can be implemented by the SSF service selection server itself or by an authentication authentication proxy entity "Authentication Proxy" located at the end of the exchanges between the user and the service selection server. . The user must thus authenticate prior to the processing of his access request by the SSF service selection server.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the subject of the invention is a method of access to a service by a user, said access being effected by means of a device for accessing a network of communication, said method comprising the following steps implemented by the access device:
  • the access method originates from a problem identified for the implementation of an IPTV type service. It is also applicable to other services, requiring a joint implementation of IMS services and services accessible by the HTTP signaling protocol.
  • the access device to the communication network is thus responsible for guaranteeing the public identity in the request for access to the service selection server. This consists of modifying the service access request to add the information relating to the identification of the public identity associated with the user. It is easy to integrate such a function in the network access device and the upgrade can be performed by downloading a new software version. Specifically, the header of the access request is modified to indicate that the public identity indicated in the request is authenticated.
  • Such a network access device is for example a residential gateway. It allows access to a communication network to a set of user terminals located in a home network.
  • the access method takes advantage of the preferred location of the network access device and the functions it implements.
  • the network access device implements a SIP agent function, for "Session Initiation Protocol", in charge of relaying the signaling SP, and a proxy function or "proxy” "For the HTTP signaling protocol, for” HyperText Transfer Protocol ", in charge of relaying the signaling conforming to this protocol originating from or destined for the user's terminal.
  • the network access device can thus easily obtain the information relating to the authentication. He can obtain it for example at the end of the recording phase in the successful network. Specifically, this is the MS recording phase. It can also obtain it on receipt of a notification sent by an SDF server during a service discovery phase.
  • the access method is also compatible with embodiments in which the device? access also implements a function of managing the public identity of the user of a terminal.
  • the terminal identifies itself in the local network with a local identity specific to it, the access device being in charge of making the change to the public identity of the user of the terminal.
  • IPTV service it is thus possible thanks to this public identity guaranteed to implement the customization of the service by simplifying access for the user.
  • the access method further comprises a step of obtaining at least one identifier of the service selection server during a service discovery by the user and a verification step that the request for service access is to a service selection server identified by the identifier obtained, said verification step being implemented prior to the step of modifying the access request.
  • the identifiers of the service selection servers are obtained following a discovery of the service or when changes to the accessible services or access rights to the service. It is then possible to implement an access control to an authorized service selection server. If the service selection server does not match one of the authorized servers for the service, the access request is blocked. Otherwise, it is transmitted, after modification, to the service selection server.
  • the access method further comprises a step of obtaining at least one identifier of the service selection server during a service discovery by the user and in which the modification step the access request is implemented if the access request is to a service selection server identified by an identifier obtained.
  • the modification of the access request is implemented only for an authorized service selection server. This simplifies the processing implemented by the access device.
  • the invention relates to a device for accessing a communication network, arranged to allow at least one user to access a service, comprising:
  • Such a device can be integrated in a gateway for access to a communication network.
  • the invention relates to a gateway for access to a communication network, arranged to allow at least one user to access a service, comprising a first module, arranged to relay messages relating to the application session. , and a second module, arranged to relay messages relating to a signaling protocol, in which:
  • the first module is further arranged to obtain information relating to an authentication of a public identity associated with the user, said authentication having been implemented during a registration of the user in said network;
  • the second module is furthermore arranged to receive an access request from said user to a service selection server associated with said service, to modify said access request by adding the information relating to authentication obtained in association with the service; public identity and to forward the modified access request to the service selection server
  • the invention relates to a system for accessing a communication network, comprising a network access device according to the second aspect.
  • the invention also relates to a computer program comprising instructions for implementing the access method according to the first aspect, implemented by an access device, when this program is executed by a user. processor.
  • FIG. 1 represents a device for accessing a communication network in its environment according to a particular embodiment of the invention
  • FIG. 2 represents a simplified diagram of the steps of the method of access to a service according to a first particular embodiment of the invention
  • FIG. 3 represents a device for accessing a communication network according to a particular embodiment of the invention.
  • a device 10 for accessing a communication network in its environment will be described with reference to FIG. 1 according to a first particular embodiment. More precisely, it is placed later in the case where this access device to the communication network is a residential gateway. It is also part of the implementation of an IPTV audiovisual data broadcasting service.
  • the gateway 10 allows access to the communication network to user terminals 20, 22 of a local, home or private network.
  • the user terminals 20, 22 are also known under the name "STB" for "Set Top Box”. They have functions to initialize and manage .IPTV services on a. IMS type architecture. As such, these terminals are identified as the applicants or users in their exchanges with the gateway 10.
  • the IPTV terminal is identified by a local identity in the local network, Id-loc .
  • Id-loc a local identity in the local network
  • the gateway 10 for "Home GateWay”, also called “residential gateway” or “Box”, separates the local network from the communication network of the operator. It provides user terminals with connectivity D? to the communication network.
  • the gateway 10 comprises two functions or logical entities 12, 14:
  • a first entity 12 implementing a SIP agent function or "B2BUA SIP", for "Back to Back SIP User Agent”.
  • This first entity 12 supports SIP signaling and the processing of the corresponding sessions. It thus has a relay function for the SP signaling.
  • the first entity or SIP 12 entity entity is thus in charge of managing two SP dialogs transparently, one with a PTV terminal on the local network and a second with an SP service platform in the communication network;
  • This second entity 14 proxy for the HTTP signaling protocol.
  • This second entity 14 supports HTTP signaling from or to the user terminal 20, 22.
  • the "HTTP proxy" function is in charge of relaying the HTTP signaling protocol compliant messages from the users terminals of the local network to the user terminal. the communication network and vice versa.
  • the first SP dialog with the PTV terminal is done on the basis of a local Id-loc identity and the second SP dialogue with the platform. in the communication network is performed on the basis of a default public identity of the gateway 10.
  • This functionality of the gateway 10, and more precisely the proxy entity SP 12, is more precisely described in the specification.
  • the public identity IMPU of the gateway 10, for "P Multimedia Public Identity" corresponds to the default public identity to be used in the absence of selection of a public identity by the user.
  • the gateway 10 can be configured with a list of public identities of the users of the PTV terminal. The user of the latter selects a public identity, denoted Id-pub thereafter, in this list, as described in the ETSI TS specification. 185 003, paragraph 7.2. A given public identity is associated with a private identity IMPI, for "IP Multimedia Private Identity".
  • the SIP proxy entity 12 of the gateway 10 communicates with an IMS core network 30 and an application server 32 contributing to the implementation of an IPTV service.
  • the core IMS network 30 includes a set of CSCF proxy servers in charge of routing SIP signaling messages between users or between a user and the service platforms.
  • the application server 32 corresponds to a service discovery server SDF or "Service Discovery Function".
  • SDF Service Discovery Function
  • a dialog with the latter allows the user to obtain attachment information, and more specifically a list of SSF service selection servers.
  • SSF service selection servers One of them is shown in Figure 1 as 34.
  • Such a service selection server 34 as described in the specifications of ETSI TS 182 027 and TS 182 063, notably provides the user with metadata including a program guide, a service guide, service plans , descriptions of the media, ...
  • the method of accessing the IPTV service will now be described in relation to FIG. 2, the method comprising a recording phase with the IMS core network 30, followed by a phase of discovery of the IPTV service and then a phase access to one of the service selection servers 34 for the IPTV service.
  • the description is carried out using IPTV IMS mechanisms as described by ETSI TISPAN specifications.
  • the user terminal 20 transmits a message M1 to the gateway 10.
  • This is a SIP REGISTER registration request containing the local identity Id-loc of the IPTV terminal 20.
  • the registration request message M1 is received in a step E1 by the proxy entity 12 SE? of the gateway 10.
  • the proxy entity 12 SP then transmits an M2 message to the IMS core network 30.
  • This is a SIP REGISTER registration request comprising the public identity IMPU of the gateway 10 or a public identity selected by the user of the IPTV terminal 20 in the list of public identities stored in the gateway 10.
  • the registration request also includes the private identity IMPI associated with the public identity IMPU. This public identity Id-pub provided by the gateway 10 is subsequently called current public identity.
  • the messages M2, M3, M4 exchanged between the gateway 10 and the IMS core network 30 correspond to the exchanges aimed at authenticating the user identified by the current private and public identities. More specifically, the message M3 transmitted by the IMS core network 30 to the gateway 10 corresponds to a SIP message 401 Unauthorized. The gateway 10 responds with an M4 SIP REGISTER message comprising the public identity Id-pub, the private identity PI and an authentication datum. The content of this authentication data is not detailed here more precisely, these exchanges being carried out in accordance with the standard mechanisms implemented in an IMS type network. If the authentication data is correct, the user is registered with the IMS core network 30. The IMS heart network 30 then transmits to the gateway 10 an M5 message SU? 200-OK.
  • the corresponding user the public identity Id-pub current and using the IPTV terminal 20 identified by the local identity Id-loc is registered and therefore authenticated to the core IMS network 30.
  • the registration phase with the HVIS core network 30 is then complete.
  • a service discovery phase with the service discovery server 32 is implemented.
  • the D? TV terminal 20 transmits a subscription request M7 message to the IPTV service to the gateway 10, more specifically to the SIP proxy entity 12. Is this an SE message? SUBSCRIBE, including local identity Id-loc.
  • the proxy entity SJP 12 modifies the local identity Id-loc by the current public identity Id-pub and then in turn transmits a message M8 subscription request to the heart network IMS 30. It is also a message SB? SUBSCRIBE, including the current public id-pub identity.
  • This subscription request message M8 is relayed to the application server 32 in the form of an M9 message.
  • the application server 32 verifies that the user associated with the current public identity Id-pub is authorized to access the service and if this is the case, transmits an M10 agreement message to the core network 3MS 30 in response to the message M9 of subscription request. This is a 200-OK SIP message.
  • This M10 agreement message is relayed by the IMS core network 30 in the form of a Mi I message to the gateway 10, more precisely to the SIP 12 proxy entity.
  • the SD proxy entity? 12 then transmits an M12 agreement message to the terminal IPTV 20. It is also an SD message? 200-OK.
  • the application server 32 then generates a notification message M13, comprising information for access to the IPTV service and transmits it to the IMS core network 30.
  • This notification message M13 comprises in particular at least one address in the communication network of a network.
  • SSF service selection server such as server 34. This is a SJP NOTIFY message.
  • the heart network S 30 relays the notification message to the gateway 10 in the form of a notification message M14 comprising the information for access to the D TV service described above in connection with the notification message M13.
  • the proxy entity SD? 12 receives the notification message M14 and transmits it in the form of an M15 notification message to the IPTV terminal 20. Still in this step E2, the proxy entity SU? 12 extract from the notification message M 14 the information for access to the IPTV service. This extracted information is then transmitted to the proxy entity 14 for the HTTP signaling protocol of the gateway 10, for example in the form of an NI message using an API programming interface, for "Application Programming Interface" .
  • Such an NI message also includes the local identity Id-loc of the IPTV terminal 20 and the current public identity Id-pub of the registered user and using the IPTV terminal 20.
  • H is therefore an authenticated public identity. No restriction is attached to the form in which the proxy entity SP 12 transmits this information to the proxy entity 14 for the HTTP signaling protocol.
  • the extracted information and the associations between the identities can also be transmitted in a succession of unit messages.
  • the proxy entity 14 for the HTTP signaling protocol receives this message NI and then records in a table, referenced 110 in FIG. 3, the association between the local identity Id-loc and the public identity Id-pub authenticated by the IMS core network 30 for this user and the list of service selection server addresses.
  • a record in table 110 of this association means that this user is authenticated to the IMS 30 core network. In other words, it is information relating to authentication of the associated public identity Id-pub. to the user, this authentication having been implemented during the registration of the user with the heart network IMS 30.
  • the proxy entity 14 for the HTTP signaling protocol acknowledges by an acknowledgment message N2 the receipt of the message NI.
  • the IPTV terminal 20 Upon receipt of the notification message M 15, the IPTV terminal 20 transmits to the gateway 10, more specifically to the proxy entity SB? 12, an M16 SIP 200-O acknowledgment message. This acknowledgment message M16 is then transmitted to the IMS core network 30 with the current public identity and then to the application server 32 in the form of a message Ml 8.
  • the discovery phase of the IPTV service by the user of the IPTV terminal 20 is then complete.
  • the access phase to a service selection server 34 is then implemented.
  • the IPTV terminal 20 transmits to the gateway 10, more precisely to the proxy entity 14 for the HTTP signaling protocol, a PI message conforming to the HTTP signaling protocol.
  • This PI message corresponds to a request to access the SSF service selection server 34 identified by its @SSF address in the communication network for the user of the IPTV terminal 20, identified by its local identity Id-loc.
  • This PI message is received in a first substep F21 of a step F2 by the proxy entity 14 for the HTTP signaling protocol. Still in this step F2, more precisely in a second substep F22, the proxy entity 14 for the HTTP signaling protocol checks using the records of the table 110, in particular the list of addresses extracted from the -message. M14, if the user of the terminal ffTV 20 has the right to access this service selection server 34. The control is based firstly on local identity Id-loc of the user requesting access and d on the other hand on the address in the communication network of the service selection server 34 contained in the message PI.
  • the SIP proxy entity 12 is able to perform access control to service selection servers authorized by the application server 32 This brings additional security when accessing the service.
  • the PI message is blocked by the proxy entity 14 for the HTTP signaling protocol.
  • the user of the IPTV terminal 20 is notified of the rejection.
  • the proxy entity 14 for the HTTP signaling protocol obtains from the record of the table 110 associated with this local identity Id-loc and for this address @ Service selection server SSF, the public identity Id-pub authenticated by the IMS core network 30.
  • the proxy entity 14 for the HTTP signaling protocol then enriches the header of the message.
  • PI access request in the form of an "X-3GPP-Asserted Identity" header including the public identity Id-pub authenticated and thus guaranteed, to obtain a P2 access request message.
  • Such a header is defined in the specification ETSI TS 124 109.
  • the insert enrichment of a public identity guaranteed by the user is thus deported from a Proxy authentication proxy entity to the gateway 10, and more precisely to the proxy entity 14 for the HTTP signaling protocol. This avoids a new authentication procedure of the user for access to the service selection server 34, This simplifies access to the service for the user.
  • the information is provided to the proxy entity 14 for the HTTP signaling protocol only after the user has been registered and therefore authenticated in the IMS 30 core network. This allows an implicit authentication of the user. by benefiting from the security of the procedures defined for the IMS 30 core network.
  • privileged of the gateway 10 which is cut off from the exchanges of the IPTV terminal with both the IMS core network and the SSF service selection servers.
  • This embodiment also allows the IPTV terminal 20 to use its local identity. Id-loc in its exchanges with the gateway 10, the association between the local identity Id-loc and public identity Id-pub being memorized only by the gateway 10. The IPTV terminal 20. thus remains generic and usable by any user. ⁇
  • the modification of the header is performed only for a service selection server address registered in the table in association with the local identity Id-loc.
  • messages conforming to the HTTP signaling protocol but intended for other servers are not modified.
  • the message P2 comprising the guaranteed public identity is transmitted to the latter in a fifth substep F25 of the step F2.
  • the message P2 corresponds to a message received from an authenticating proxy entity.
  • the method is thus transparent to the service selection server 34.
  • the service selection server 34 can then implement a customization of the TPTV service for the guaranteed user, as described in ETSI specification TS 183 0063, section 6.3. .1. As non-limitative examples, it may be to apply a parental control to the program guide, to adapt the program guide according to a profile of the user, to adapt the service plans in Terminal capacity function, user subscription rights ...
  • This personalization of the service is implemented during a step G1 and a response message P3 to the access request is transmitted by the service selection server 24 to the gateway 10.
  • the response message P3 comprises a personalized response based on the guaranteed public identity received in the message P2.
  • the response message P3 is received by the gateway 10, in particular by the proxy entity 14 for the HTTP signaling protocol, and is transmitted in the form of a response message P4 to the IPTV terminal 20.
  • the gateway 10 implements a function of guaranteeing the public identity of the users of the IPTV terminals, making it possible to offer a personalized service.
  • SDF service discovery server 32 may transmit an SJP NOTIFY notification message including an updated list of SSF service selection servers. This corresponds for example to the case where the user has access to a new bouquet of services. In this case, this message corresponds to a message M13 as described above. Steps E2 and F1 are again implemented in order to update the corresponding record in the table. When a new user of the terminal 20 registers with the IMS core network 30, the message exchanges M1 to M15 are performed as described above. In step F1 and upon receipt of the NI message, the proxy entity 14 for the HTTP signaling protocol then updates the corresponding record in the: 110 array using the new public identity. and the new list of service selection servers.
  • the gateway 10 is not in charge of managing a list of public identities of the users.
  • the IPTV terminal 20 then stores itself the public identity Id-pub of the user.
  • the agent entity SB? 12 does not implement a B2BUA Back-to-Back User Agent function but only a "SIP proxy" function.
  • the exchanges described above in connection with FIG. 2 are directly transferable to this second embodiment, the terminal identifying itself in the local network with the public identity of the user.
  • the NI message comprises the current public identity Id-pub of the registered user and using the IPTV terminal 20 and the list of SSF service selection servers.
  • the proxy entity 14 for the HTTP signaling protocol then records in the table 110 the public identity Id-pub authenticated by the IMS core network 30 for this user and the list of addresses of the servers. service selection.
  • the service selection server access request PI message 34 transmitted by the terminal 20 then comprises an "X-3GPP-Intended-Identity" header, as described in ETSI specification TS 183 063, clause 6.1.1.1, containing the public identity Id-pub.
  • the proxy entity 14 for the HTTP signaling protocol modifies the header of the message PI as described in connection with the first embodiment to obtain a message P2 comprising a header. "X-3GPP-Asserted Identity".
  • the modification consists in substituting the header "X-3GPP-Intented-identity" by an "X-3GPP-Asserted Identity” header in the message PI to obtain the message P2.
  • the proxy entity 14 for the HTTP signaling protocol does not perform a check according to the address @SSF of the service selection server 34.
  • the SIP 12 proxy entity does not transmit in the NI message the list of service selection server addresses to the proxy entity 14 for the HTTP signaling protocol and the latter enriches it.
  • the message PI as described above in relation to the fourth substep F24 of the step F2 regardless of the destination address contained in the HTTP access request. In this case, all messages conforming to the HTTP signaling protocol transmitted by this user are enriched.
  • the description of the method has been made for particular embodiments, in which the header of the access request is modified to add the information relating to P authentication of the public identity. No restriction is attached to the form in which the gateway 12 transmits this information.
  • the method is easily transposable to other modes of modifying the access request.
  • a device 100 for accessing a communication network will now be described in relation to FIG. 3.
  • Such a device is notably designed to allow at least one user to access a service.
  • Such a device comprises:
  • a module 102 arranged to relay the signaling conforming to the SIP protocol, in particular during a user registration phase in the network, a service discovery phase;
  • a module 104 arranged to relay the compliant signaling.
  • the HTTP signaling protocol in particular for receiving a request from a user for access to a service selection server associated with said service and for transmitting the modified access request to the service selection server;
  • a modification module 106 of said access request by adding information relating to an authentication obtained
  • the table 110 memorizing a public identity in association with the information relating to the authentication of the user.
  • the obtaining module 108 is further arranged to control a recording in the table 110 of the information relating to an authentication of a public identity associated with the user.
  • the relay module 104 of the signaling conforming to the HTTP signaling protocol is furthermore arranged to control the module 106 for modifying the header of the access request.
  • the access device comprises the two entities as described above.
  • the SIP proxy entity 12 is arranged to relay messages relating to the SIP protocol and the proxy entity 14 for the HTTP signaling protocol is arranged to relay messages relating to the HTTP signaling protocol.
  • the entity 12 then comprises the modules 102 signaling relays SU 5 and 108 obtaining.
  • the entity 14 then comprises the relay modules 104 of the HTTP signaling, 106 of the processing of an access request and the table 110..
  • the access control device can. be integrated in a gateway to the communication network.
  • the modules 102, 104, 106, 108 of the access device to a communication network are arranged, to implement those of the steps of the method of access to a previously described service performed by the access device.
  • These are preferably software modules comprising software instructions for executing those of the steps of the method of access to a previously described service, implemented by an access device.
  • the invention therefore also relates to:
  • a program for an access device comprising program instructions intended to control the execution of those of the steps of the method of access to a previously described service which are executed by said device, when said program is executed by a processor of this one ;
  • the software modules can be stored in or transmitted by a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as an electrical signal, optical or radio, or a telecommunications network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne un procédé d'accès à un service par un utilisateur. L'accès s'effectue par l'intermédiaire d'un dispositif d'accès (10, 100) à un réseau de communication (30). Le procédé comprend les étapes suivantes mises en œuvre par le dispositif d'accès : - obtention d'une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau; - réception d'une demande d'accès dudit utilisateur à un serveur (34) de sélection de service associé audit service : - modification de ladite demande d'accès par ajout de l'information relative à une authentification obtenue; - transmission de la demande d'accès modifiée au serveur de sélection de service.

Description

Technique d'accès à un service par un utilisateur
L'invention se situe dans le domaine des télécommunications et plus particulièrement dans la mise en œuvre de services dans un réseau de communication de type 3P (« Internet Protocol »).
L'invention trouve une application particulièrement avantageuse dans le domaine des réseaux de communication de type IP permettant ' la diffusion de données audiovisuelles, notamment lors d'un accès à un service de diffusion de contenu établi suivant les mécanismes définis dans le domaine de I'IMS (« B? Multimedia Subsystem ») par les organismes de normalisation 3GPP (« 3rd Génération Partnership Project ») et TISPAN (« Télécommunications and Internet converged Services and Protocols for Advanced Networking »).
L'IMS est une architecture de Téseau qui permet un établissement et un contrôle d'une session multimédia ainsi qu'une réservation des ressources au niveau du réseau de transport des flux médias. Cette architecture de réseau permet notamment la mise en œuvre d'une interaction entre des services.
Plus précisément, les spécifications techniques TS 182 027 et TS 183 063 définies par le groupe TISPAN décrivent les architectures IPTV sur une architecture IMS et des mécanismes permettant à un terminal d'un utilisateur d'accéder à un service de diffusion de contenus.
Pour accéder à un service, un utilisateur doit au préalable s'enregistrer auprès du réseau cœur IMS. Puis, l'utilisateur souscrit auprès d'un serveur SDF, pour « Service Discovery Function », mettant en œuvre le service, tel que le service de diffusion de contenus, et obtient en retour une liste d'au moins un serveur de sélection de service SSF, pour « Service Sélection Function ». L'utilisateur transmet ensuite une demande d'accès au serveur de sélection de service SSF.
Afin d'offrir un service personnalisé en fonction de l'utilisateur, il est proposé dans la spécification technique de PBTSI TS 183 063 de mettre en œuvre une fonction d'authentification de l'utilisateur. Cette fonction d'authentification peut être mise en œuvre par le serveur de sélection de service SSF lui-même ou bien par une entité mandataire d'authentification « Authentication Proxy » située en coupure des échanges entre l'utilisateur et le serveur de sélection de service. L'utilisateur doit ainsi s'authentifier préalablement au traitement de sa demande d'accès par le serveur de sélection de service SSF.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
Selon un premier aspect, l'invention a pour objet un procédé d'accès à un service par un utilisateur, ledit accès s'effectuant par l'intermédiaire d'un dispositif d'accès à un réseau de communication, ledit procédé comprenant les étapes suivantes mises en œuvre par le dispositif d'accès :
- obtention d'une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- réception d'une demande d'accès dudit utilisateur à un serveur de sélection de service associé audit service :
- modification de ladite demande d'accès par ajout de l'information, relative à F authentification obtenue en association avec ladite identité publique ;
- transmission de la demande d'accès modifiée au serveur de sélection de service.
Le procédé d'accès tire son origine d'un problème identifié pour la mise en œuvre d'un service de type IPTV. Il est également applicable à d'autres services, nécessitant une mise en œuvre conjointe de services IMS et de services accessibles par le protocole de signalisation HTTP.
Le dispositif d'accès au réseau de communication est ainsi en charge de garantir l'identité publique dans la demande d'accès au serveur de sélection de service. Ceci consiste à modifier la demande d'accès au service pour y ajouter l'information relative à P uthentification de l'identité publique associée à l'utilisateur. H est aisé d'intégrer une telle fonction dans le dispositif d'accès au réseau et la mise à niveau peut être réalisée par téléchargement d'une nouvelle version logicielle. Plus précisément, l'entête de la demande d'accès est modifiée pour y indiquer que l'identité publique indiquée dans la demande est authentifiée.
Un tel dispositif d'accès au réseau est par exemple une passerelle résidentielle. Il permet l'accès à un Téseau de communication à un ensemble de terminaux utilisateurs situés dans un réseau domestique.
Le procédé d'accès tire parti de l'emplacement privilégié du dispositif d'accès au réseau et des fonctions qu'il met en œuvre. En effet, dans un mode particulier de réalisation, le dispositif d'accès au réseau met en œuvre une fonction d'agent SIP, pour « Session Initiation Protocol », en charge du relais de la signalisation SP, et une fonction mandataire ou « proxy » pour le protocole de signalisation HTTP, pour « HyperText Transfer Protocol », en charge du relais de la signalisation conforme à ce protocole en provenance ou à destination du terminal de l'utilisateur.
Le dispositif d'accès au réseau peut ainsi obtenir aisément l'information relative à l'authentification. Il peut l'obtenir par exemple en fin de phase d'enregistrement dans le réseau réussie. Plus précisément, il s'agit de la phase d'enregistrement MS. Il peut également l'obtenir sur réception d'une notification émise par un serveur SDF lors d'une phase de découverte du service.
Ainsi, il n'est pas nécessaire de dérouler une nouvelle authentification de l'utilisateur du terminal pour accéder à un service accessible par le protocole de signalisation HTTP. Ceci présente de nombreux avantages, tels que l'absence de déploiement dans le réseau de l'opérateur d'une nouvelle entité d'authentification et la simplification des échanges avec l'utilisateur.
Le procédé d'accès est en outre compatible avec des modes de réalisation dans lesquels le dispositif d?accès met également en œuvre une fonction de gestion de l'identité publique de l'utilisateur d'un terminal. Dans ce cas, le terminal s'identifie dans le réseau local avec une identité locale propre à celui-ci, le dispositif d'accès étant en charge d'effectuer la modification vers l'identité publique de l'utilisateur du terminal.
Pour le service IPTV, il est ainsi possible grâce à cette identité publique garantie de mettre en œuvre la personnalisation du service en simplifiant l'accès pour l'utilisateur.
Selon une caractéristique particulière, le procédé d'accès comprend en outre une étape d'obtention d'au moins un identifiant du serveur de sélection de service lors d'une découverte du service par l'utilisateur et une étape de vérification que la demande d'accès est à destination d'un serveur de sélection de service identifié par l'identifiant obtenu, ladite étape de vérification étant mise en œuvre préalablement à l'étape de modification de la demande d'accès.
Les identifiants des serveurs de sélection de service sont obtenus suite à une découverte du service ou bien lors de modifications des services accessibles ou des droits d'accès au service. Ή est alors possible de mettre en œuvre un contrôle d'accès à un serveur de sélection de service autorisé. Si le serveur de sélection de service ne correspond pas à un des serveurs autorisés pour le service, la demande d'accès est bloquée. Sinon, elle est transmise, après modification, au serveur de sélection de service.
Selon une autre caractéristique particulière, le procédé d'accès comprend en outre une étape d'obtention d'au moins un identifiant du serveur de sélection de service lors d'une découverte du service par l'utilisateur et dans lequel l'étape de modification de la demande d'accès est mise en œuvre si la demande d'accès est à destination d'un serveur de sélection de service identifié par un identifiant obtenu.
La modification de la demande d'accès est mise en œuvre uniquement pour un serveur de sélection de service autorisé. Ceci simplifie le traitement mis en œuvre par le dispositif d'accès.
Selon un deuxième aspect, l'invention concerne un dispositif d'accès à un réseau de communication, agencé pour permettre à au moins un utilisateur d'accéder à un service, comprenant :
- des moyens d'obtention d'une information relative à une authentifîcation d'une identité publique associée à l'utilisateur, ladite authentifîcation ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- des moyens de réception d'une demande d'accès dudit utilisateur à un serveur de sélection de service associé audit service : - des moyens de modification de ladite demande d'accès par ajout de l'information relative à une authentification obtenue en association avec l'identité publique ;
- des moyens de transmission de la demande d'accès modifiée au serveur de sélection de service.
Un tel dispositif peut être intégré dans une passerelle d'accès à un réseau de communication.
Selon un troisième aspect, l'invention concerne une passerelle d'accès à un réseau de communication, agencé pour permettre à au moins un utilisateur d'accéder à un service, comprenant un premier module, agencé pour relayer des messages relatifs à la session applicative, et un deuxième module, agencé pour relayer des messages relatifs à un protocole de signalisation, dans laquelle :
- le premier module est en outre agencé pour obtenir une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- le deuxième module est en outre agencé pour recevoir une demande d'accès dudit utilisateur à un serveur de sélection de service associé audit service, pour modifier ladite demande d'accès par ajout de l'information relative à F authentification obtenue en association avec l'identité publique et pour transmettre la demande d'accès modifiée au serveur de sélection de service
Selon un quatrième aspect, l'invention concerne un système d'accès à un réseau de communication, comprenant un dispositif d'accès au réseau selon le deuxième aspect.
Selon un cinquième aspect, l'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'accès selon le premier aspect, mises en œuvre par un dispositif d'accès, lorsque ce programme est exécuté par un processeur.
L'invention sera mieux comprise à l'aide de la description suivante de modes de réalisation particuliers du procédé de l'invention, en référence aux dessins annexés sur lesquels :
la figure 1 représente un dispositif d'accès à un réseau de communication dans son environnement selon un mode particulier de réalisation de l'invention ; la figure 2 représente un schéma simplifié des étapes du procédé d'accès à un service selon un premier mode particulier de réalisation de l'invention ;
la figure 3 représente un dispositif d'accès à un réseau de communication selon un mode particulier de réalisation de l'invention.
Un dispositif 10 d'accès à un réseau de communication dans son environnement va être décrit en relation avec la figure 1 selon un premier mode particulier de réalisation. Plus précisément, on se place par la suite dans le cas où ce dispositif d'accès au réseau de communication est une passerelle résidentielle. On se place également dans le cadre de la mise en œuvre d'un service de diffusion de données audiovisuelles IPTV. La passerelle 10 permet l'accès au réseau de communication à des terminaux utilisateurs 20, 22 d'un réseau local, domestique ou privé. Les terminaux utilisateurs 20, 22 sont également connus sous la dénomination « STB », pour « Set Top Box ». Ils disposent de fonctions permettant l'initialisation et la gestion des services .IPTV sur une. architecture de type IMS. A ce titre, ces terminaux sont identifiés comme étant les demandeurs ou utilisateurs lors de leurs échanges avec la.passerelle 10. Plus précisément, on considère par la suite que le terminal IPTV est identifié par une identité locale dans le réseau local, Id-loc. Ceci permet de banaliser l'utilisation d'un même terminal IPTV par une pluralité d'utilisateurs, l'association entre l'utilisateur et le terminal étant mise en œuvre par la passerelle. A titre d'exemple illustratif, on peut choisir en tant qu'identité locale Γ adresse MAC, pour « Media Access Control », du terminal PTV.
La passerelle 10 ou HGW, pour « Home GateWay », également appelée « passerelle résidentielle » ou « Box », sépare le réseau local du réseau de communication de l'opérateur. Elle fournit aux terminaux utilisateurs la connectivité D? au réseau de communication. La passerelle 10 comprend deux fonctions ou entités logiques 12, 14 :
- une première entité 12 mettant en œuvre une fonction d'agent SIP ou « B2BUA SIP », pour « Back to Back User Agent SIP ». Cette première entité 12 prend en charge la signalisation SIP et le traitement des sessions correspondantes. Elle a ainsi une fonction de relais pour la signalisation SP. La première entité ou entité mandataire SIP 12 est ainsi en charge de gérer de manière transparente deux dialogues SP, un premier avec un terminal PTV sur le réseau local et un deuxième avec une plateforme de service SP dans le réseau de communication ;
- une deuxième entité 14 mandataire pour le protocole de signalisation HTTP. Cette deuxième entité 14 prend en charge la signalisation HTTP en provenance ou à destination du terminal utilisateur 20, 22. La fonction « HTTP proxy » est en charge du relais des messages conformes au protocole de signalisation HTTP en provenance des terminaux utilisateurs du réseau local vers le réseau de communication et réciproquement.
Ainsi, dans le cas décrit ici où le terminal PTV est partagé par une pluralité d'utilisateurs, le premier dialogue SP avec le terminal PTV s'effectue sur la base d'une identité locale Id-loc et le deuxième dialogue SP avec la plateforme de service dans le réseau de communication s'effectue sur la base d'une identité publique par défaut de la passerelle 10. Cette fonctionnalité de la passerelle 10, et plus précisément de l'entité mandataire SP 12, est plus précisément décrite dans la spécification de l'ETSI TS 185 003, paragraphe 7.3.1. L'identité publique IMPU de la passerelle 10, pour « P Multimedia Public Identity », correspond à l'identité publique par défaut à utiliser en l'absence de sélection d'une identité publique par l'utilisateur.
Par ailleurs, la passerelle 10 peut être configurée avec une liste d'identités publiques des utilisateurs du tenninal PTV. L'utilisateur de ce dernier sélectionne une identité publique, notée Id-pub par la suite, dans cette liste, conformément à ce qui est décrit dans la spécification ETSI TS 185 003, paragraphe 7.2. A une identité publique donnée est associée une identité privée IMPI, pour « IP Multimedia Private Identity ».
L'entité mandataire 12 SIP de la passerelle 10 communique avec un réseau cœur IMS 30 et un serveur applicatif 32 contribuant à la mise en œuvre d'un service IPTV. Le réseau cœur IMS 30 comprend notamment un ensemble de serveurs mandataires CSCF en charge de l'acheminement des messages de signalisation SIP entre utilisateurs ou entre un utilisateur et les plateformes de services.
Plus précisément, le serveur applicatif 32 correspond à un serveur de découverte de service SDF ou « Service Discovery Function ». Un dialogue avec ce dernier permet à l'utilisateur d'obtenir des informations d'attachement, et plus précisément une liste de serveurs de sélection de service SSF. Un d'entre eux est présenté sur la figure 1 sous la référence 34.
Un tel serveur de sélection de service 34, tel que décrit dans les spécifications de l'ETSI TS 182 027 et TS 182 063, fournit notamment à l'utilisateur des métadonnées comprenant un guide des programmes, un guide de service, des plans de services, des descriptions des médias, ...
Le procédé d'accès au service IPTV va maintenant être décrit en relation avec la figure 2, le procédé comprenant une phase d'enregistrement auprès du réseau cœur IMS 30, suivie d'une phase de découverte du service IPTV, puis d'une phase d'accès à un des serveurs de sélection de service 34 pour le service IPTV. La description est réalisée en utilisant les mécanismes IPTV IMS tels que décrits par les spécifications de l 'ETSI TISPAN.
En référence à la figure .2, le terminal utilisateur 20 transmet un message Ml à la passerelle 10. Il s'agit d'une demande d'enregistrement SIP REGISTER contenant l'identité locale Id-loc du terminal IPTV 20.
Le message de demande d'enregistrement Ml est reçu dans une étape El par l'entité mandataire 12 SE? de la passerelle 10. L'entité mandataire 12 SP transmet alors un message M2 à destination du réseau cœur IMS 30. H s'agit d'une demande d'enregistrement SIP REGISTER comprenant l'identité publique IMPU de la passerelle 10 ou bien une identité publique sélectionnée par l'utilisateur du terminal IPTV 20 dans la liste des identités publiques mémorisées dans la passerelle 10. La demande d'enregistrement comprend également l'identité privée IMPI associée à l'identité publique IMPU. Cette identité publique Id-pub fournie par la passerelle 10 est appelée par la suite identité publique courante.
Les messages M2, M3, M4 échangés entre la passerelle 10 et le réseau cœur IMS 30 correspondent aux échanges visant à authentifier l'utilisateur identifié par les identités privée et publique courantes. Plus précisément, le message M3 transmis par le réseau cœur IMS 30 à la passerelle 10 correspond à un message SIP 401 Unauthorized. La passerelle 10 répond avec un message M4 SIP REGISTER comprenant l'identité publique Id-pub, l'identité privée PI et une donnée d'authentification. Le contenu de cette donnée d'authentification n'est pas détaillé ici plus précisément, ces échanges s' effectuant conformément aux mécanismes standards mis en œuvre dans un réseau de type IMS. Si la donnée d'authentification est correcte, l'utilisateur est enregistré auprès du réseau cœur IMS 30. Le réseau cœur IMS 30 transmet alors à la passerelle 10 un message M5 SU? 200-OK. La passerelle 10, plus précisément l'entité mandataire 12 SU?, transmet alors un message M6 SJP 200-OK au terminal IPTV 20. A l'issue de cette phase d'enregistrement," l'utilisateur correspondant, à l'identité publique courante Id-pub et utilisant le terminal IPTV 20 identifié par l'identité locale Id-loc est enregistré et donc authentifié auprès du réseau cœur IMS 30. La phase d'enregistrement auprès du réseau cœur HVIS 30 est alors terminée.
Pour accéder à un service, plus précisément dans le mode de réalisation décrit ici au service IPTV, une phase de découverte du service auprès du serveur de découverte de service 32 est mise en œuvre. Le terminal D?TV 20 transmet un message M7 de demande de souscription au service IPTV à la passerelle 10, plus précisément à l'entité mandataire 12 SIP. H s'agit d'un message SE? SUBSCRIBE, comprenant l'identité locale Id-loc.
L'entité mandataire 12 SJP modifie l'identité locale Id-loc par l'identité publique courante Id-pub puis transmet à son tour un message M8 de demande de souscription au réseau cœur IMS 30. H s'agit également d'un message SB? SUBSCRIBE, comprenant l'identité publique courante Id-pub.
Ce message M8 de demande de souscription est relayé auprès du serveur applicatif 32 sous la forme d'un message M9. Le serveur applicatif 32 vérifie que l'utilisateur associé à l'identité publique courante Id-pub est bien autorisé à accéder au service et si tel est le cas transmet un message d'accord M10 au réseau cœur 3MS 30 en réponse au message M9 de demande de souscription. H s'agit d'un message SIP 200-OK. Ce message d'accord M10 est relayé par le réseau cœur IMS 30 sous la forme d'un message Mi l à destination de la passerelle 10, plus précisément de l'entité mandataire SIP 12.
. L'entité mandataire SD? 12 transmet alors un message d'accord M12 à destination du terminal IPTV 20. Il s'agit également d'un message SD? 200-OK.
Le serveur applicatif 32 génère alors un message de notification M13, comprenant des informations pour l'accès au service IPTV et le transmet au réseau cœur IMS 30. Ce message de notification M13 comprend notamment au moins une adresse dans le réseau de communication d'un serveur de sélection de service SSF, tel que le serveur 34. Il s'agit d'un message SJP NOTIFY.
Le réseau cœur S 30 relaie le message de notification vers la passerelle 10 sous la forme d'un message de notification M14 comprenant les informations pour l'accès au service D?TV décrites précédemment en relation avec le message de notification M13.
Dans une étape E2, l'entité mandataire SD? 12 reçoit le message de notification M14 et le transmet sous la forme d'un message de notification M15 à destination du terminal IPTV 20. Toujours dans cette étape E2, l'entité mandataire SU? 12 extrait du message de notification M 14 les informations pour l'accès au service IPTV. Ces informations extraites sont alors transmises à l'entité mandataire 14 pour le protocole de signalisation HTTP de là passerelle 10 par exemple sous la forme d'un message NI à l'aide d'une interface de programmation API, pour « Application Programming Interface ». Un tel message NI comprend également l'identité locale Id-loc du terminal IPTV 20 et l'identité publique courante Id-pub de l'utilisateur enregistré et utilisant le terminal IPTV 20. Pour rappel, l'utilisateur enregistré a été authentifié par le réseau cœur S 30 sous cette identité publique, H s'agit donc d'une identité publique authentifiée. Aucune restriction n'est attachée à la forme sous laquelle l'entité mandataire SP 12 transmet ces informations à l'entité mandataire 14 pour le protocole de signalisation HTTP. Les informations extraites et les associations entre les identités peuvent également être transmises en une succession de messages unitaires.
Dans une étape Fl, l'entité mandataire 14 pour le protocole de signalisation HTTP reçoit ce message NI et enregistre alors dans un tableau, référencé 110 sur la figure 3, l'association entre l'identité locale Id-loc et l'identité publique Id-pub authentifiée par le réseau cœur IMS 30 pour cet utilisateur et la liste d'adresses de serveurs de sélection de service. Un enregistrement dans le tableau 110 de cette association signifie que cet utilisateur est bien authentifié auprès du réseau cœur IMS 30. En d'autres termes, il s'agit d'une information relative à F authentification de l'identité publique Id-pub associée à l'utilisateur, cette authentification ayant été mise en œuvre lors de l'enregistrement de l'utilisateur auprès du réseau cœur IMS 30.
Puis, l'entité mandataire 14 pour le protocole de signalisation HTTP acquitte par un message d'acquittement N2 la réception du message NI.
Ces différents échanges sont répétés lorsqu'un utilisateur d'un autre terminal IPTV 22 souscrit au service IPTV et conduisent ainsi à un nouvel enregistrement dans le tableau 110 associant les identités locale et publique et la liste des adresses de serveurs de sélection de service pour l'utilisateur de cet autre terminal 22.
Sur réception du message M 15 de notification, le terminal IPTV 20 transmet à la passerelle 10, plus précisément à l'entité mandataire SB? 12, un message M16 d'acquittement SIP 200-O . Ce message d'acquittement M16 est alors transmis au réseau cœur IMS 30 avec l'identité publique courante puis au serveur applicatif 32 sous la forme d'un message Ml 8.
La phase de découverte du service IPTV par l'utilisateur du terminal IPTV 20 est alors terminée.
La phase d'accès auprès d'un serveur de sélection de service 34 est alors mise en œuvre.
Le terminal IPTV 20 transmet à la passerelle 10, plus précisément à l'entité mandataire 14 pour le protocole de signalisation HTTP, un message PI conforme au protocole de signalisation HTTP. Ce message PI correspond à une demande d'accès au serveur de sélection de service SSF 34 identifié par son adresse @SSF dans le réseau de communication pour l'utilisateur du terminal IPTV 20, identifié par son identité locale Id-loc.
Ce message PI est reçu dans une première sous-étape F21 d'une étape F2 par l'entité mandataire 14 pour le protocole de signalisation HTTP. Toujours dans cette étape F2, plus précisément dans une deuxième sous-étape F22, l'entité mandataire 14 pour le protocole de signalisation HTTP contrôle à l'aide des enregistrements du tableau 110, notamment la liste des adresses extraites du -message .de notification M14, si l'utilisateur du terminal ffTV 20 a bien le droit d'accéder à ce serveur de sélection de service 34. Le contrôle se base d'une part sur ridentité locale Id-loc de l'utilisateur requérant l'accès et d'autre part sur l'adresse dans le réseau de communication du serveur de sélection de service 34 contenue dans le message PI .
Grâce à cette collaboration entre l'entité mandataire SIP 12 et l'entité mandataire 14 pour le protocole de signalisation HTTP, cette dernière est en mesure d'effectuer un contrôle d'accès à des serveurs de sélection de service autorisés par le serveur applicatif 32. Ceci apporte une sécurisation supplémentaire lors de l'accès au service.
Si l'utilisateur du terminal IPTV 20 n'a pas le droit d'accéder au serveur de sélection de service 34, alors le message PI est bloqué par l'entité mandataire 14 pour le protocole de signalisation HTTP. Dans une variante de réalisation, l'utilisateur du terminal IPTV 20 est notifié du rejet.
Toujours dans cette étape F2, plus précisément dans une troisième sous-étape F23, l'entité mandataire 14 pour le protocole de signalisation HTTP obtient à partir de l'enregistrement du tableau 110 associé à cette identité locale Id-loc et pour cette adresse @SSF de serveur de sélection de service, l'identité publique Id-pub authentifiée par le réseau cœur IMS 30. Dans une quatrième sous-étape F24, l'entité mandataire 14 pour le protocole de signalisation HTTP enrichit alors l'entête du message de demande d'accès PI sous la forme d'un entête « X-3GPP-Asserted Identity » comprenant l'identité publique Id-pub authentifiée et ainsi garantie, pour obtenir un message de demande d'accès P2. Un tel entête est défini dans la spécification ETSI TS 124 109.
L'enrichissement par insertion d'une identité publique garantie de l'utilisateur est ainsi déporté d'une entité mandataire d'authentification Proxy vers la passerelle 10, et plus précisément l'entité mandataire 14 pour le protocole de signalisation HTTP. On évite ainsi une nouvelle procédure d'authentification de l'utilisateur pour un accès au serveur de sélection de service 34, Ceci simplifie l'accès au service pour l'utilisateur.
On note que les informations ne sont fournies à l'entité mandataire 14 pour le protocole de signalisation HTTP qu'une fois l'utilisateur enregistré et donc authentifié dans le réseau cœur IMS 30. Ceci permet d'effectuer une authentification implicite de l'utilisateur en bénéficiant de la sécurité des procédures définies pour le réseau cœur IMS 30. On tire ainsi parti de l'emplacement privilégié de la passerelle 10, qui se trouve en coupure des échanges du terminal IPTV aussi bien avec le réseau cœur IMS qu'avec les serveurs de sélection de service SSF.
Ce mode de réalisation permet également au terminal IPTV 20 d'utiliser son identité : locale . Id-loc dans ses échanges avec la passerelle 10, l'association entre l'identité locale Id-loc et Fidentité publique Id-pub étant mémorisée uniquement par la passerelle 10. Le terminal IPTV 20. reste ainsi générique et utilisable par tout utilisateur. ·
De plus, la modification de l'entête est effectuée uniquement pour une adresse de serveur de sélection dé service enregistrée dans le tableau en association avec l'identité locale Id-loc. Ainsi des messages conformes au protocole de signalisation HTTP mais à destination d'autres serveurs ne sont pas modifiés.
Lorsque l'utilisateur du terminal 20 a le droit d'accéder au serveur de sélection de service 34, alors le message P2 comprenant l'identité publique garantie est transmis à ce dernier dans une cinquième sous-étape F25 de l'étape F2. Pour le serveur de sélection de service 34, le message P2 correspond à un message reçu en provenance d'une entité mandataire d'authentifïcation. Le procédé est ainsi transparent pour le serveur de sélection de service 34. Le serveur de sélection de service 34 peut alors mettre en œuvre une personnalisation du service TPTV pour l'utilisateur garanti, tel que décrit dans la spécification ETSI TS 183 0063, paragraphe 6.3.1. A titre d'exemples non limitatifs, il peut s'agir d'appliquer un contrôle parental au guide des programmes, d'adapter le guide des programmes en fonction d'un profil de l'utilisateur, d'adapter les plans de service en fonction de capacités du terminal, des droits d'abonnement de l'utilisateur...
Cette personnalisation du service est mise en œuvre lors d'une étape Gl et un message de réponse P3 à la demande d'accès est transmis par le serveur de sélection de service 24 à destination de la passerelle 10. Le message de réponse P3 comprend une réponse personnalisée en fonction de l'identité publique garantie reçue dans le message P2.
Le message de réponse P3 est reçu par la passerelle 10, notamment par l'entité mandataire 14 pour le protocole de signalisation HTTP, et est transmis sous la forme d'un message de réponse P4 au terminal IPTV 20.
Ainsi, la passerelle 10 met en place une fonction de garantie de l'identité publique des utilisateurs des terminaux IPTV, permettant d'offrir un service personnalisé.
Si nécessaire, le serveur de découverte de service SDF 32 peut transmettre un message de notification SJP NOTIFY comprenant une liste mise à jour des serveurs de sélection de service SSF. Ceci correspond par exemple au cas où l'utilisateur a accès à un nouveau bouquet de services. Dans ce cas, ce message correspond à un message M13 tel que décrit précédemment. Les étapes E2 et Fl sont de nouveau mises en œuvre afin de mettre à jour l'enregistrement correspondant dans le tableau. Lorsqu'un nouvel utilisateur du terminal 20 s'enregistre auprès du réseau cœur IMS 30, les échanges de message Ml à M15 s'effectuent tel que décrit précédemment. Lors de l'étape Fl et sur réception du message NI, l'entité mandataire 14 pour le protocole de signalisation HTTP met alors à jour l'enregistrement correspondant dans le :tableau 110 à l'aide de la nouvelle identité publique. et de la nouvelle liste de serveurs de sélection de service.
Dans un deuxième mode de réalisation, la passerelle 10 n'est pas en charge de la gestion d'une liste d'identités publiques des utilisateurs. Dans ce cas, le terminal IPTV 20 mémorise alors lui-même l'identité publique Id-pub de l'utilisateur. En. conséquence, l'entité mandataire SB? 12 ne met pas en œuvre de fonction de « Back-to-Back User Agent » B2BUA mais uniquement une fonction de « Proxy SIP ». Les échanges décrits précédemment en relation avec la figure 2 sont directement transposables à ce deuxième mode de réalisation, le terminal s'identifiant dans le réseau local avec l'identité publique de l'utilisateur. Dans ce cas, le message NI comprend l'identité publique courante Id-pub de l'utilisateur enregistré et utilisant le terminal IPTV 20 et la liste des serveurs de sélection de service SSF. Lors de l'étape Fl, l'entité mandataire 14 pour le protocole de signalisation HTTP enregistre alors dans le tableau 110 l'identité publique Id-pub authentifiée par le réseau cœur IMS 30 pour cet utilisateur et la liste d'adresses de serveurs de sélection de service. Le message PI de demande d'accès au serveur de sélection de service 34 transmis par le terminal 20 comprend alors un entête « X-3GPP-Intended-Identity », tel que décrit dans la spécification ETSI TS 183 063, paragraphe 6.1.1.1, contenant l'identité publique Id-pub. Lors de la quatrième sous-étape F23 de l'étape F2, l'entité mandataire 14 pour le protocole de signalisation HTTP modifie l'entête du message PI comme décrit en relation avec le premier mode de réalisation pour obtenir un message P2 comprenant un entête « X-3GPP-Asserted Identity ». Plus précisément, la modification consiste à substituer l'entête « X-3GPP-Intented-identity » par un entête « X-3GPP-Assered Identity » dans le message PI pour obtenir le message P2. Les avantages indiqués précédemment en relation avec le premier mode de réalisation, notamment d'éviter une nouvelle authentifïcation de l'utilisateur, sont également obtenus.
Dans une variante à ces deux modes de réalisation, lors de la deuxième sous-étape F22 de l'étape F2, l'entité mandataire 14 pour le protocole de signalisation HTTP n'effectue pas de contrôle en fonction de l'adresse @SSF du serveur de sélection de service 34. Les avantages indiqués précédemment en relation avec les autres étapes des deux modes de réalisation, notamment d'éviter une nouvelle authentifïcation de l'utilisateur, sont également obtenus.
Dans une autre variante à ces deux modes de réalisation, l'entité mandataire SIP 12 ne transmet pas dans le message NI la liste des adresses de serveurs de sélection de service à l'entité mandataire 14 pour le protocole de signalisation HTTP et cette dernière enrichit le message PI tel que décrit précédemment en relation avec la quatrième sous-étape F24 de l'étape F2 quelle que soit l'adresse de destination contenue dans la demande d'accès HTTP. Dans ce cas, tous les messages conformes au protocole de signalisation HTTP transmis par cet utilisateur sont enrichis. Les avantages indiqués précédemment en relation avec les autres étapes des deux modes de réalisation, notamment d'éviter une nouvelle authentification de l'utilisateur, sont également obtenus.
La description du procédé a été effectuée pour des modes de réalisation particuliers, dans lesquels l'entête de la demande d'accès est modifiée pour y ajouter l' information relative à P authentification de l'identité publique. Aucune restriction n'est attachée à la forme sous laquelle la passerelle,12 transmet cette information. Le procédé est aisément transposable à d'autres modes de modification de la demande d'accès.
Un dispositif 100 d'accès à un réseau de communication va maintenant être décrit en relation avec la figure 3. Un tel dispositif est notamment agencé pour permettre à au moins un utilisateur d' accéder à un service.
Un tel dispositif comprend :
- un module 102 agencé pour relayer la signalisation conforme au protocole SIP, notamment lors d'une phase d'enregistrement de l'utilisateur dans le réseau, d'une phase de découverte du service ;
- un module d'obtention 108 d'une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- un module 104 agencé pour relayer la signalisation conforme . au protocole de signalisation HTTP, notamment pour recevoir une demande d'accès d'un utilisateur à un serveur de sélection de service associé audit service et pour transmettre la demande d'accès modifiée au serveur de sélection de service ;
- un module de modification 106 de ladite demande d'accès par ajout de l'information relative à une authentification obtenue ;
- le tableau 110 mémorisant une identité publique en association avec l'information relative à P authentification de Putilisateur.
Le module 108 d'obtention est en outre agencé pour commander un enregistrement dans le tableau 110 de l'information relative à une authentification d'une identité publique associée à l'utilisateur.
Le module 104 relais de la signalisation conforme au protocole de signalisation HTTP est en outre agencé pour commander le module 106 de modification de l'entête de la demande d'accès.
Dans un mode de réalisation particulier, le dispositif d'accès comprend les deux entités telles que décrites précédemment. L'entité mandataire SIP 12 est agencée pour relayer des messages relatifs au protocole SIP et l'entité mandataire 14 pour le protocole de signalisation HTTP est agencée pour relayer des messages relatifs au protocole de signalisation HTTP. L'entité 12 comprend alors les modules 102 relais de signalisation SU5 et 108 d'obtention.
L'entité 14 comprend alors les modules 104. relais de la signalisation HTTP, 106 de traitement d'une demande d'accès et le tableau 110. ..·
Le dispositif de contrôle d'accès peut. être intégré dans une passerelle d'accès au réseau de communication.
Les modules 102, 104, 106, 108 du dispositif d'accès à un réseau de communication sont agencés, pour mettre en œuvre celles des étapes du procédé d'accès à un service précédemment décrit exécutées par le dispositif d'accès. H s'agit de préférence de modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé d'accès à un service précédemment décrit, mises en œuvre par un dispositif d'accès. L'invention concerne donc aussi :
- un programme pour dispositif d'accès, comprenant des instructions de programme destinées à commander l'exécution de celles des étapes du procédé d'accès à un service précédemment décrit qui sont exécutées par ledit dispositif, lorsque ledit programme est exécuté par un processeur de celui-ci ;
- un support d'enregistrement lisible par un dispositif d'accès sur lequel est enregistré le programme pour dispositif d'accès.
Les modules logiciels peuvent être stockés dans ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal électrique, optique ou radio, ou un réseau de télécommunication.
La description a été faite pour un accès au service D?TV. Elle est aisément transposable à d'autres services, nécessitant une mise en œuvre conjointe de services HVIS et de services accessibles par le protocole de signalisation HTTP.

Claims

REVENDICATIONS
1. Procédé d'accès à un service par un utilisateur, ledit accès s' effectuant par l'intermédiaire d'un dispositif d'accès (10, 100) à un réseau de communication (30), ledit procédé comprenant lés étapes suivantes mises en œuvre par le dispositif d'accès : ..
- obtention (E2, Fl) d'une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- réception (F21) d'une demande d'accès dudit utilisateur à un serveur (34) de sélection de service associé audit service :
- modification (F24) de ladite demande d'accès par ajout de l'information relative à P authentification obtenue en association avec ladite identité publique ;
- transmission (F25) de la demande d'accès modifiée au serveur de sélection de service.
2. Procédé d'accès selon la revendication 1, comprenant en outre une étape d'obtention (E2) d'au moins un identifiant du serveur de sélection de service lors d'une découverte du service par l'utilisateur et une étape de vérification (F22) que la demande d'accès est à destination d'un serveur de sélection de service identifié par l'identifiant obtenu, ladite étape de vérification étant mise en œuvre préalablement à l'étape de modification de la demande d'accès.
3. Procédé d'accès selon la revendication 1, comprenant en outre une étape d'obtention (E2) d'au moins un identifiant du serveur de sélection de service lors d'une découverte du service par l'utilisateur et dans lequel l'étape de modification de la demande d'accès est mise en œuvre si la demande d'accès est à destination d'un serveur de sélection de service identifié par un identifiant obtenu.
4. Dispositif d'accès à un réseau de communication, agencé pour permettre à au moins un utilisateur d'accéder à un service, comprenant :
- des moyens d'obtention (108) d'une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentification ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- des moyens de réception (104) d'une demande d'accès dudit utilisateur à un serveur de sélection de service associé audit service :
- des moyens de modification (106) de ladite demande d'accès par ajout de l'information relative à une authentification obtenue en association avec l'identité publique ; - des moyens de transmission (104) de la demande d'accès modifiée au serveur de sélection de service.
5. Passerelle d'accès à un réseau de communication, agencé pour permettre à au moins un utilisateur d'accéder à un . service, comprenant un premier module, agencé pour relayer des messages relatifs à la. session applicative, et un deuxième module, agencé pour relayer des messages relatifs à un protocole de signalisation, dans laquelle :
- le premier module est en outre agencé pour obtenir une information relative à une authentification d'une identité publique associée à l'utilisateur, ladite authentifîcation ayant été mise en œuvre lors d'un enregistrement de l'utilisateur dans ledit réseau ;
- le deuxième module est en outre agencé pour recevoir une demande d'accès dudit utilisateur à un serveur de sélection de service associé audit service, pour modifier ladite demande d'accès, par ajout de l'information relative à Y authentification obtenue en association avec l'identité publique et pour transmettre la demande d'accès modifiée au serveur de sélection de service.
6. Système d'accès à un réseau de communication, comprenant un dispositif d'accès au réseau selon la revendication 4.
7. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'accès selon la revendication 1, mises en œuvre par un dispositif d'accès, lorsque ce programme est exécuté par un processeur.
PCT/FR2011/051072 2010-05-20 2011-05-13 Technique d'acces a un service par un utilisateur WO2011144846A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1053914 2010-05-20
FR1053914 2010-05-20

Publications (1)

Publication Number Publication Date
WO2011144846A1 true WO2011144846A1 (fr) 2011-11-24

Family

ID=43085752

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2011/051072 WO2011144846A1 (fr) 2010-05-20 2011-05-13 Technique d'acces a un service par un utilisateur

Country Status (1)

Country Link
WO (1) WO2011144846A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103888835A (zh) * 2014-04-17 2014-06-25 江苏银河电子股份有限公司 一种智能机顶盒的安全认证方法
CN110720203A (zh) * 2017-06-01 2020-01-21 奥兰治 与应用有关的网络切片的选择

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009093942A1 (fr) * 2008-01-24 2009-07-30 Telefonaktiebolaget L M Ericsson (Publ) Procédé et dispositif pour commander une passerelle multimédia comprenant un isim
WO2010027309A1 (fr) * 2008-09-05 2010-03-11 Telefonaktiebolaget L M Ericsson (Publ) Serveur d'application, procédé de commande associé, programme et support de stockage lisible par un ordinateur

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009093942A1 (fr) * 2008-01-24 2009-07-30 Telefonaktiebolaget L M Ericsson (Publ) Procédé et dispositif pour commander une passerelle multimédia comprenant un isim
WO2010027309A1 (fr) * 2008-09-05 2010-03-11 Telefonaktiebolaget L M Ericsson (Publ) Serveur d'application, procédé de commande associé, programme et support de stockage lisible par un ordinateur

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103888835A (zh) * 2014-04-17 2014-06-25 江苏银河电子股份有限公司 一种智能机顶盒的安全认证方法
CN110720203A (zh) * 2017-06-01 2020-01-21 奥兰治 与应用有关的网络切片的选择
CN110720203B (zh) * 2017-06-01 2022-07-12 奥兰治 与应用有关的网络切片的选择

Similar Documents

Publication Publication Date Title
US8443420B2 (en) System for communicating with a mobile device server
EP2025181B1 (fr) Systeme d'acces a un service de television sur ip dans un reseau a architecture ims
EP3417591B1 (fr) Procédé et serveur de sélection d'un serveur d'entrée d'un réseau de communication ims
KR101573329B1 (ko) 멀티캐스트 세션을 통해 수신한 어플리케이션에 기초한 ｉｐｔｖ 서비스 이용 방법 및 장치
US20090307736A1 (en) Method and browser for providing iptv to multiple ims users
WO2012126339A1 (fr) Procédé et système pour regarder un service dans un réseau de télévision ip
EP2920942B1 (fr) Selection de periodes de rafraichissement dans un reseau ip
EP2556646B1 (fr) Technique de contrôle d'accès a un flux de données diffusé
EP2873211B1 (fr) Procédé d'enregistrement d'au moins une adresse publique dans un réseau ims et application correspondante
WO2011144846A1 (fr) Technique d'acces a un service par un utilisateur
KR101732189B1 (ko) 홈 네트워크 디바이스에 외부 네트워크 서비스를 제공하는 방법 및 장치
EP3472993B1 (fr) Procédé de détermination d'un ensemble de formats de codage pour établir une communication
EP3050275B1 (fr) Conversion de protocole enrichie dans un réseau de télécommunications pour la fourniture de services à qualité de service améliorée
EP2504957B1 (fr) Acces a un contenu reference par un serveur de contenu
EP2801178B1 (fr) Procédé dynamique de détermination d'une liste de services dans un réseau sip
WO2014114871A1 (fr) Enregistrement d'un equipement client par l'intermediaire d'un serveur mandataire dans un reseau de communication
WO2015181505A1 (fr) Procédé pour informer une entité d'un réseau ip du type de réseau d'accès utilisé par un terminal
WO2010112738A1 (fr) Procede d'envoi d'un message de notification, serveur de sessions d'acces et systeme de communications
KR101734557B1 (ko) 홈 네트워크 디바이스에 외부 네트워크의 서비스를 제공하는 방법 및 장치
EP2904735B1 (fr) Technique de communication entre une entité cliente et un réseau de données en mode paquet
WO2021260290A1 (fr) Procedes et serveurs de gestion des services d'un terminal additionnel dans un reseau de coeur sip
EP2124410A1 (fr) Système, procédé, serveur d'application et HSS pour l'autoprovisionnement d'au moins un service dans au moins un serveur d'application d'une architecture IMS
WO2012076796A1 (fr) Gestion de service dans un reseau
FR2999047A1 (fr) Communication entre un reseau domestique et une plateforme de services externe
FR2999849A1 (fr) Procede d'acces a un contenu multi media, terminal mobile, terminal fixe et module logiciel correspondants

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

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

Country of ref document: EP

Kind code of ref document: A1