WO2012076796A1

WO2012076796A1 - Service management in a network

Info

Publication number: WO2012076796A1
Application number: PCT/FR2011/052866
Authority: WO
Inventors: Songbo Song; Hassnaa Moustafa
Original assignee: France Telecom
Priority date: 2010-12-10
Filing date: 2011-12-05
Publication date: 2012-06-14
Also published as: FR2968874A1

Abstract

The invention relates to a context management server customizing an offer of digital contents for a user of an audio-visual broadcasting system through a communication network as a function of a context. The system comprises a user interface module, a module for broadcasting digital contents and a module for controlling the broadcasting module. The server comprises communication modules arranged so as to receive the context information. The invention also relates to a user interface module, a module for broadcasting digital contents, a module for controlling broadcasting module, a system for audio-visual broadcasting to a user device, comprising the aforesaid three modules, a method of customizing an offer of digital contents, a computer program implementing said method, and a support storing said computer program.

Description

SERVICE MANAGEMENT IN A NETWORK

The invention relates to a communication network of Internet type, or IP for 'Internet Protocol', and more particularly a management of services offered in such a network in a personalized manner.

This type of network offers various functions such as, for example, telephone services (VoIP for 'Voice over IP'), video telephony (V2oIP for 'Voice and Video Internet Protocol') or video broadcasting. (IPTV for Internet Protocol Tele Vision ').

The functions offered to the users allow them more and more autonomy and more and more choices. This is notably the case of 'nTS' services (for 'network time shifting' in English) which enable a user to watch a television program that is out of step with his broadcast schedule, or services of the type 'nTS'. nPVR '(for' Network Personal Video Recorder 'in English) which allow to record at the network level digital content for a user.

In IPTV (or IPTV) systems, digital television services are provided to users using the Internet protocol (IP) protocol over a broadband connection. IP telephony services can be combined with IP telephony and data services.

Consideration of the context could allow customization of IPTV services tailored to each user (in a differentiated manner), and adapted to the user's environment (device and network). The article "Personalized TV Service through Employing Context-Awareness in IPTV / IMS Architecture", published at the FMN 2010 conference, of S. SONG et al, concerns in particular processes and a system relying on the SIP protocol. In this article, it is proposed in particular to extend the IPTV / IMS architecture to include consideration of the context and to allow customized IPTV services as part of an IMS architecture. A possible architecture according to this article comprises four parts: a Context-Aware Server (CAS), Context Aware User Equipment (CAUE) , service domain modules and a network domain module.

The CAS is centrally located in the operator's core network to enable personalized services for the user, whether at home or on the road (eg at the hotel). The CAS consists of four modules:

i) Context-Aware Management Module (CAM). This module gathers the context information obtained from the user, an application server and the network, and derives context information of higher level by context inference.

ii) a context database module (CDB). The module stores context information collected and obtained by inference, and provides a query interface to a service trigger module (ST).

iii) a service trip module (ST). This module offers two functions: customization of established services, based on various context information, and discovery and configuration of personalized services for users according to the different contexts. The ST communicates dynamically with the CBD module to observe the context information prior to triggering the services, and communicates with a privacy protection module (PP) to verify whether the services can use the context information or whether There are privacy constraints.

iv) a Privacy Protection Module (PP). This module performs checks to determine what data can be used by checking whether ready-to-activate services have permission to access the required context information or a subset, based on different levels of privacy protection. .

The CAUE includes a Client Context Acquisition (CCA) module and a Local Service Management (LSM) module. The CCA module discovers the context sources in the local sphere and collects the raw context information (user context and device context information) and then sends it to the CAM module located in the CAS server. The LSM module controls and manages the execution of local services by tracking the CCA module and dynamically comparing the context with its stored rules, so as to activate a corresponding service in a personalized way.

The service domain modules located at the application server level include a Service Context Acquisition (SCA) module which collects service context information and transmits it to the CAM module. and a Media Delivery Context Acquisition (MDCA) module that observes the content delivery and dynamically acquires network context information during the service delivery and sends it to the network. CAM module.

In the network domain, a Network Context Acquisition (NCA) module collects bandwidth information from the resource and admission control subsystem (RACS). Resource and Admission Control Sub-System) prior to the establishment of each service session and sends the acquired information to the CAM. This context-aware system has been introduced in an IPTV architecture based on IMS to allow this IPTV architecture to take into account the context and provide new personalized services. In this IMS-based, context-aware IPTV system, the IMS core is responsible for controlling the signaling and context-aware context information transfer of the user equipment from the service domain module. and the network domain module to the server taking into account the context, which facilitates the deployment of such CAS through the control plane (in English "control plane") to transfer the signaling. However, this IMS-based solution relies on the SIP protocol, which limits its application by excluding non-SIP applications and requires the deployment of an IMS architecture. The SIP protocol is not yet very widely deployed and the solutions proposed in this article are not always usable. In addition, the solutions proposed in this article for an IPTV service in an IMS architecture are not directly transferable to other "dedicated IPTV System" architectures, such as an NGN IPTV architecture. Indeed, the integration of the CAS in an IMS architecture is simply because the CAS server is considered as a service with respect to the IMS core network. The S-CSCF server is intended to communicate with an application server via a SIP interface. For an IPTV service on an NGN type architecture, such a server is not provided. It is not possible to directly translate this CAS integration into dedicated IPTV System architectures.

The invention aims to improve the situation.

According to a first embodiment, the invention relates to a context management server for personalizing an offer of digital content (such as films or television, in the form of video on demand) for a user of a computer. audiovisual broadcasting system through a communication network according to a context. Context is information that takes into account the circumstances in which the content is delivered. The context can thus relate to the load (for example as a percentage of available bandwidth) or the available bit rate of the network or networks involved in the provision of digital content as well as the nature of this (s) network (s) (in particular the technology under -Fixed used, such as GSM, GPRS, 3G, EDGE, ADSL, cable, Ethernet over twisted pair, fiber optic, satellite, Bluetooth, infrared, etc.), the number of routers to cross to reach the device of the user , the type of device used by the user to perceive the digital content (MP3 player, smart phone, personal assistant, laptop, desktop computer, server, television, radio, etc.), time, place (for example the country, the city, the precise address or the room in which the user is), the date, the language to use, the user's age, sex, socio-professional category, weight, height , his marital status, his eating habits his artistic tastes, his consumption habits, the existence of potential children, or the activity the user (lunch, nap, sport, travel by car, plane, train, etc.). The server is for example a physical server (electronic equipment) or a software server loadable on a physical server. The system includes a user interface module, a digital content broadcast module, and a broadcast module control module. These three modules are, for example, software modules executed by a microprocessor, or electronic modules (wired electronics, microcontrollers with a memory loading adapted software, etc.). The context management server includes:

a first communication module, arranged to receive from the user interface module first context information relating to at least one device of said user and / or the user;

a second communication module arranged to receive from the digital content broadcasting module second network context information for an established session of the user; and,

a third communication module, arranged to receive from the control module third context information relating to the network during an initialization of a session of the user.

The three modules of the group are, for example, software modules executed by a microprocessor, or electronic modules (wired electronics, microcontroller with a memory loading adapted software, etc.). The context according to the first embodiment is determined from the context information (first context information and / or second context information and / or third context information) received by one of the communication modules. According to one possible embodiment, the three communication modules are one and the same module (for example a CAM module).

This advantageously makes it possible to offer context-aware digital content in a setting other than a SIP architecture, as SIP architectures are not currently widespread. Indeed, with the development of IPTV NGN services, cooperation between network operators and service providers becomes crucial. NGN IPTV architecture allows interoperability between multiple operators. Not to be tied to an IMS architecture that is based on the SIP protocol increases the possibilities for coexistence of different IPTV systems belonging to different network operators and service providers. This improves the compatibility of IPTV services. This first aspect of the invention thus makes it possible to propose solutions that extend existing IPTV architectures of the NGN type by integrating the taking into account of the context.

In this type of architecture, service interworking is not expected. For example, a presence service interworking only with UE by via a user interface module. The implementation of the known solution for the IMS architecture has the disadvantage of providing a central role for the user interface module to communicate the context information. Such a solution is not optimal and may cause load problems at the user interface module.

According to a second embodiment relating to a particular implementation of the first embodiment, the first communication module is arranged to receive fourth context information relating to the service, issued by a service discovery module of the system and relayed by the user interface module. This is advantageous because it enriches the context information and further target the content provided.

According to a third embodiment relating to a particular implementation of the first or second embodiment, the server comprises a service triggering module for proposing a personalized digital content offer according to the context, and the third module is also arranged to transmit said offer to the control module. This is advantageous because it allows not only to adapt the content provided, but also to offer the user specific content.

According to a fourth embodiment relating to a particular implementation of the first, second or third embodiment, the server comprises a service triggering module for customizing a program guide according to the context and the first communication module is also arranged to transmit said personalized program guide to the user interface module. This improves the personalization of the content. This service trigger module differs in particular from the ST module of the CAS server according to the article by Song et al., In that it makes it possible to customize a program guide (EPG) according to contextual information to provide it to a user. user equipment via a user interface module.

A fifth embodiment of the invention relates to a user interface module for audio-visual broadcasting system, the user interface module comprising a first communication module arranged to relay to a context management server according to the first embodiment of the context information relating to a device of a user and / or a user. The module according to the fifth embodiment is for example a software module executed by a microprocessor, or an electronic module (wired electronics, microcontroller with a memory loading a suitable software, etc.). The fifth embodiment makes it possible to share context information, for example to adapt a content or to propose particular contents.

According to a sixth embodiment, a module according to the fifth embodiment comprises means for registering the user with said server prior to activating the first communication module for said user.

According to a seventh embodiment, the first communication module of a module according to the fifth or sixth embodiment is also arranged to relay service context information received from a service discovery module of the system. .

According to an eighth embodiment, a module according to the fifth, sixth or seventh embodiment comprises a second communication module, arranged to relay to the user's device a program guide received from the management server of context.

The module according to the fifth, sixth, seventh and eighth embodiments can be advantageously implemented within the framework of the ETSI TISPAN standard, for example within the framework of the current version of this standard, namely ETSI TS 182 028, 2008. , "Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); NGN Integrated IPTV Subsystem Architecture". This module is then for example a module type CFIA (Customer Facing English IPTV Application). This module may advantageously include means for authentication and authorization of the user.

A ninth embodiment relates to a digital content broadcasting module for audio-visual broadcasting system. The broadcast module comprises means for acquiring context information relating to the network for an established session of a user and means arranged for transmitting context information received by the acquisition means to a context management server. according to the first embodiment. In the context of the ETSI / TISPAN standard, the module is for example of the MF type (of the English Media Function), and the acquisition means is for example MDCA type. This ninth embodiment makes it possible to share contextual information in order, for example, to adapt a content or to propose particular contents.

A tenth embodiment relates to a broadcast module control module for audio-visual broadcasting system. The control module comprises transmission means arranged to relay context information relating to the network during an initialization of a session to a context management server according to the first embodiment. As part of the ETSI / TISPAN standard, the module is for example IPTV-C type (English IPTV Control Function). This tenth embodiment makes it possible to share context information, for example to adapt a content or to propose particular contents.

An eleventh embodiment relates to an audio-visual broadcast system to a user device, comprising a user interface module according to the fifth mode of embodiment, a digital content broadcasting module according to the ninth embodiment and a broadcast module control module according to the tenth embodiment.

A twelfth embodiment relates to a method of customizing a digital content offering for a user of an audio-visual broadcasting system through a communication network according to a context. The method comprises sending context information of a user interface module according to the fifth embodiment, a digital content broadcasting module according to the ninth embodiment and a module control module. according to the tenth embodiment to a server according to the first embodiment, via the communication network. According to one aspect of the invention, the management method establishes three non-SIP interfaces of type using the hypertext transfer protocol http, which has the advantage of being easy to implement. The use of HTTP as a signaling protocol to convey context information and to control context-aware services is advantageous because it makes it easy to extend services to third-party services, such as, for example, services. WEB TV or social networking applications (such as Skype or Facebook), and generally NGN applications.

According to one aspect of the invention, the management method comprises receiving, by the context management server, via at least one of the three non-SIP interfaces, context information relating to a user device and or to a recipient user of the digital content, network context information for an established session of the user, and network context information upon initialization of a user's session .

Advantageously, the management method further comprises receiving context information relating to the digital content delivery service.

The combination of the four contexts is advantageous because it allows the sending of digital content better targeted. A given context may be composed of several elements, for example user context information may include the user's age, size, gender and weight. The context information relating to a user device and / or a user is intended to be transmitted via the non-SIP interface between the context-aware context management server (designated by the acronym CAS, for Context-Aware Server) and the user interface module. This allows the provision of advanced TV services, adapting the content to the context of the user and its environment, which simplifies the compatibility of the different IPTV systems and allows a better cooperation between the various operators of networks and services. This also allows a better quality of service (QoS). In the context of an NGN IPTV architecture, context information relating to the device is typically transmitted from a device (such as a Set Top Box) to the interface module. CFIA user to be transferred to the context management server. Context information relating to the user is typically sent from a User Profile Server Function (UPSF) profile management module of the content management entity to the CFIA module (of the same entity). content management), which sends it to the context management server. Context information relating to the digital content delivery service may be transmitted from a content management entity's SD & S module (Service Discovery and Selection) to the CFIA module (from the same content management entity) , which sends it to the context management server. The network context information can be transmitted from the MF and CFIA modules to the context management server. The proposed non-SIP interfaces thus advantageously make it possible to exchange relevant contextual information and thus to provide more appropriate digital content.

According to one aspect of the invention, the implementation of the method involves a service triggering module of the context management server, the method comprising an exchange between a database storing contexts and the service triggering module in order to discover the services available. This can be based in particular on a context of the digital content delivery service obtained from an SD & S module in the ETSI / TISPAN framework.

According to one aspect of the invention, the method comprises sending, by a service triggering module to a context collection device, a request to set up or personalize a digital content service. .

According to one aspect of the invention, the method comprises sending, to a context collecting device, personalized digital content according to the context present in the database.

A thirteenth embodiment relates to a computer program comprising instructions for implementing the method according to the twelfth embodiment and / or its variants, when this program is executed by a processor.

A fourteenth embodiment relates to a computer-readable non-transitory storage medium on which is stored the computer program according to the thirteenth embodiment (for example a CD, a DVD, a flash memory, a ROM, a portable hard disk, Blu-ray disc, etc.).

The device used by the user to view the content typically belongs to (or is typically under the control of) the user wishing to obtain the digital content, and may for example be a mobile phone, a smart phone, a personal assistant (such as PDA), a laptop, a tablet, a Set Top Box, or a digital TV. Other aspects, objects and advantages of the invention will appear on reading the description of one of its embodiments.

The invention will also be better understood with the aid of the drawings, in which:

FIG. 1 illustrates an extended IPTV architecture according to one embodiment of the invention;

FIG. 2 illustrates various protocols and interfaces used in the context of one embodiment of the invention;

FIG. 3 illustrates a contextual service initialization procedure according to one embodiment of the invention;

FIG. 4 illustrates an exchange of messages in the context of the dynamic transmission of user context information and / or device according to one embodiment of the invention;

FIG. 5 illustrates an exchange of messages as part of the dynamic transmission of service context information according to one embodiment of the invention; FIG. 6 illustrates an exchange of messages in connection with the transmission of network context information during a session initialization according to an embodiment of the invention;

FIG. 7 illustrates an exchange of messages as part of the dynamic transmission of network context information according to one embodiment of the invention; Figure 8 illustrates a notification by a service trigger module of the existence of a new personalized service; and

Figure 9 illustrates a communication between an ST module and an FM module to trigger the provision of personalized content.

According to one embodiment of the invention, a context-aware system (such as the one proposed in the aforementioned article by S. SONG) is integrated with an NGN IPTV architecture, forming an audio-visual broadcasting system and one defines extensions to existing protocols to allow communication between the context-aware system and the entity implementing the NGN IPTV architecture, the communication allowing the transfer and processing of different context information concerning the user, devices, networks, or digital content. This makes it possible to personalize TV services in terms of content solicitation, content selection and content adaptation.

The NGN IPTV architecture used may be the one defined by ETSI / TISPAN, and may include the following functions: - Discovery and selection of services (SD & S for "Service Discovery and Selection"). The SD & S function provides the service attachment and service selection information (for example a list of available services that a user can browse and select, the services corresponding to the digital content offering). SD & S module is also used to designate the module implementing the SD & S function;

- A user interface module for the IPTV application (CFIA for "Customer Facing IPTV Application"). The CFIA function is in charge of the interface with the user and makes it possible in particular to provision the IPTV service and to implement an authentication and authorization function verifying the access rights of the user according to the profile. user stored in a UPSF module. There is also a CFIA module for designating the module implementing the CFIA function;

- The user profile server function (UPSF). We also speak of UPSF module to designate the module implementing the UPSF function. The UPSF module is responsible for hosting a set of user-related information and user security information (including access control information for authentication and authorization);

the IPTV control function, implemented by a control module of an IPTV-C broadcast module. The IPTV-C module provides the functions of selecting and managing an MF broadcast function;

the broadcast function MF, responsible for controlling and supplying media streams to the user equipment (UE), which may be for example a mobile phone or a set top box, of which one user can use to view digital content.

The application services, for example the VoD video on demand service or the "Live" real-time television service, are Media Delivery Functions that are integrated in the MF module.

FIG. 1 represents an extension of an IPTV NGN architecture by integration of a context-aware server (CAS), also called a context management server, to customize IPTV services.

The UPSF module can be used to store static user context information, such as the age or gender of the user, the services to which they subscribe, and their preferences.

According to one embodiment, an SCA module is integrated in the SD & S module and is arranged to acquire service context information using a service guide. Electronic Service Guide (ESG) received by the SD & S from a content provider, including a description of the content and media.

A media delivery context acquisition module MDCA can be integrated into the MF module to dynamically acquire network status information during a session. The MF module may employ the Real Time Transport Control Protocol (RTCP), described in the IETF RFC 3550 document, to control the provision of content by dynamically gathering network context information statistics for one or more session sessions. current media, eg information about packet loss, jitter, or round-trip delay, information reflecting the network context. An NCA network context acquisition module may also be integrated within a RACS resource and admission control subsystem to collect context information during session initialization (such as bandwidth). Finally, it is possible to set up a CCA client context acquisition module and a LSM local service management module within the UE user equipment (smart phone, etc.).

After each acquisition of context information (related for example to the user, the device, the network and the services offered), a management module taking into account the context (CAM) of the context management server CAS deduces information collected higher level context information, which can be stored in a CDB context database. An ST service trigger module can communicate continuously with the CBD module to track the evolution of the context information, whereby the ST can discover a need to customize established services or configure new services. . In this respect, the ST module can obtain context information stored from the context database CDB and use it when triggering a corresponding service. Before triggering the service, the ST module can communicate with a PP module to check whether the corresponding service can completely use the existing context information. If there is no privacy constraint, the ST module can enable the custom services. In particular, two techniques for activating personalized services can be envisaged.

According to a first technique, described later in connection with FIG. 8, the module ST customizes an electronic program guide ("personalized EPG") as a kind of content customization (or service recommendation) corresponding to the current user context and notifies the user of the existence of a new personalized service by sending it (ie sending to his UE) the personalized electronic program guide. The ST module uses an HTTP NOTIFY message to notify the user. According to one embodiment, it is proposed to use a new HTTP NOTIFY message extending the conventional HTTP POST message by encapsulating the notification information. of service, as illustrated below:

POST HTTP / 1.1

HOST CAS / NOTIFY

LOCATION: EU

Content-type: text / xml

Content-Length: (...)

<? xml version = "l .0" encoding = "UTF-8"?>

<context xmlns = "urn: ietf: params: xml: ns: context"

xmlns: rpid = "urn: ietf: params: xml: ns: pidf: rpid">

<pird: content_typex / content_type>

</ service>

</ Notify>

According to a second technique, described later in connection with FIG. 9, the module

ST offers a custom digital content offering and sends the IPTV-C module an HTTP NOTIFY message encapsulating the service information to trigger a service (eg content adaptation according to the user context) as shown below:

POST HTTP / 1.1

HOST CAS / NOTIFY

LOCATION: IPTV-C

Content-type: text / xml

Content-Length: (...)

<? xml version = "l .0" encoding = "UTF-8"?>

<context xmlns = "urn: ietf: params: xml: ns: context"

xmlns: rpid = "urn: ietf: params: xml: ns: pidf: rpid">

<rpid: bandwidthx / bandwidth>

<rpid: devicexdevice>

</ service>

</ Notify>

In order to implement the content adaptation, the IPTV-C module selects the appropriate FM module and forwards it the service information, and the latter modifies the content according to the received context information.

In FIG. 1, in a step 1, context information relating to the user and the user device is transmitted. In a step 2, context information relating to the service is transmitted. In a step 3, context information relating to the network is transmitted. In a step 4, top-level context information, called context, is determined from the context information received by inference and the context is stored in the database CDB. Steps 1-4 are re-implemented when changes are detected. In a step 5, the ST communicates with the database CDB for get the context and discover the services. In a step 6, the ST communicates with the PP module to check if there are privacy protection constraints. In a step 7, the ST module can offer a personalized digital content offer according to the context and send a request to the IPTV-C control module to configure the services or to customize the services. Also in this step 7, the ST module can customize a program guide based on the context and forward this customized program guide to the CFIA module. In a step 8, a suitable content is sent to the user equipment UE.

FIG. 2 represents various protocols and interfaces used in an IPTV architecture based on NGN and taking into account the context according to one embodiment of the invention.

The protocols used across the interfaces Tr, Ss ', Ss, Gq', Xd, Sa, Sh are described in the ETSI / TISPAN standard. According to this standard, the IPTV-C control module communicates with the UE user equipment directly or via the CFIA user interface module. The IPTV-C control module controls the MF module. The interfaces Tr, Ss, Ss', Sh, Gq 'are used to transfer context information, and three new interfaces Ca, Ce, Ca' used by the CFIA, IPTV-C and MF modules for communicating with the server are defined. CAS to also transfer context information. The protocol used in these three new interfaces is the HTTP protocol. These new interfaces make it possible to integrate the context management service in a simple way in IPTV NGN architecture.

The CAS server communicates with the CFIA module via the interface Ca, in particular for:

receiving context information relating to at least one device of said user and / or the user and context information relating to the service, transmitted by a service discovery module of the system and relayed by the module CFIA, and

- send a personalized program guide according to the context.

The CAS server communicates with the MF module through the interface Ca ', in particular to receive context information relating to the network for an established session of the user.

The CAS server communicates with the IPTV-C module via the Ce interface, in particular for:

receive context information relating to the network during an initialization of a session of the user, and

- offer a digital content offer tailored to the context.

The communication procedures implemented as part of the IPTV NGN architecture and taking into account the context management service include contextual service registration, and transmission of context information between the end user, the network, the content servers and / or service domains, and the CAS server.

The service context registration procedure completes the traditional IPTV service initialization and authentication procedure to transfer the acquired static context information. After authentication, the CFIA module records the IPTV user equipment

UE to the CAS server using the Ca interface using a new HTTP message

REGISTER completing the classic HTTP POST message by encapsulating the user's registration information as shown below:

POST / HTTP / 1.1 users

Host: CAS / REGISTER

Content-Type: application / xml

Content-Length: (...)

<? xml version = "l .0" encoding = "UTF-8"?>

</ Registration>

</ Context>

The static context information is stored in the UPSF module. According to one embodiment of the invention, it is proposed to extend the Diameter Server-Assignment response message, defined in 3GPP TS 29.229: "Cx Interface based on Diameter - Protocol details ") which is sent by the UPSF module to the CFIA module to include the static context information by adding an attribute Attribute Value Pair (AVP) of the user's static context (" User-Static-Context "). This extended Diameter message is shown below:

<Server-Assignment-Answer> :: = <Session-Id>

{Vendor-Specific-Application-Id}

[Resuit-Code]

[Experimental-Result]

{Auth-Session-State}

{Origin-Host}

{Origin-Realm}

[User-Name]

[Supported-Features]

[User-Data]

[Charging Information]

[Associated-Identities]

[Loose-Route-Indication]

[User-Static-Context]

According to one embodiment, an HTTP POST message is used to transmit the static context information of the user, stored in the UPSF module, to the CAS server. The representation of context information in this message relies for example on the RPID format (defined in the IETF RFC4480 document), completed to include attributes context information to represent the user's static context (for example, the user's preferences, the services to which the user is subscribed and the age of the user). The HTTP POST message is shown below:

POST / HTTP / 1.1 users

Host: CAS / Context

Content-Type: application / xml

Content-Length: (...)

<? xml version = "l .0" encoding = "UTF-8"?>

<context xmlns = "urn: ietf: params: xml: ns: pidf"

xmlns: dm = "urn: ietf: params: xml: ns: pidf: data-mode1" xmlns: rpid = "urn: ietf: params: xml: ns: pidf: rpid" entity = "pres: user_public @ home net ">

<dm: person id = "1234">

<rpid: preferencexrpid: preference />

<rpid: subscriptionxrpid: subscription />

<rpid: agexrpid: age />

</ dm: person>

</ Context>

Figure 3 illustrates a message exchange during a contextual service initiation procedure according to one embodiment.

Message 1 allows a UE to send an HTTP message to the CFIA module to initialize the IPTV service. During this step, the UE performs an authentication procedure similar to a conventional IPTV service scenario. The messages 2, transmitted from the CFIA module to the CAS server, and 3, from the CAS server to the CFIA module, enable the user equipment UE to be registered with the CAS context management service on behalf of the user equipment UE using an HTTP POST message.

Message 4 corresponds to the downloading, from the UPSF profile server, of the user profile by the module CFIA after successful authentication of the user. The Diameter protocol is used to include in the profile a user's static context information by adding a static user context AVP attribute.

Message 5 allows the CFIA to send the static context information of the user to the CAS server using an HTTP POST message. When the CAS server accepts the context information, it sends a 200 OK response message 6 to the CFIA module which relays it (message 7) to the user equipment UE.

According to one embodiment, a procedure for dynamic transmission of user context information and / or device (the device designating the user equipment UE) is proposed to allow the CCA module of the user equipment UE to update, in the CAS server, the context information of user and / or device that it acquires dynamically. It is proposed to use an HTTP POST message to convey context information. The representation of the context information in the HTTP POST message follows, for example, the RPID format, by supplementing it to include context information attributes representing the user and device context, for example the user's location.

(such as: inside or outside), the location of the device, the types of networks supported, the media formats supported, the size of the screen, or the type of network. The HTTP message

POST is shown below:

POST / HTTP / 1.1 users

Host: CAS / context

Content-Type: application / xml

Content-Length: (...)

<? xntl version = "l .0" encoding = * "UTF-8"?>

<context xmins = "urn: ietf: pararas: xml: s: pidf"

xmlns: dm = "urn: ietf: pararns: xml: ns: pidf: data-mode!"

xmlns: rpid = "urn: ietf: pararas: ml: ns: pidf: rpid"

entity = "pres: user_public @ home. net">

<dm: person id = "1234">

<rpid: place-typexrpid: home / x / rpid: place-type>

<rpid: locationxrpid: salon / x / rpid: location>

<rpid: network-typexrpid: ADSL / x / rpid: network-type>

</ Dm: person>

<dm: device id = "l">

<rpid: locationxrpid: salon / x / rpid: location>

<rpid: supported_network_type> <rpid: fixxrpid: supported_network_type> <rpid: supported_media_formatxrpid: mpeg2 / xrpid: supported_media_format> <rpid: screen_sizexxrpid: screen_size>

</ dm: device>

</ Context>

FIG. 4 illustrates an exchange of messages corresponding to this dynamic transmission procedure of context information relating to a device or to a user.

The message 1 corresponds to the transmission to the CFIA module (and the dynamic update) of the context information acquired by the user equipment UE, concerning for example the context information of the user and the device. The extended HTTP POST message is used. The CFIA module relays this message (message 2) to the CAS server using the interface Ca.

The message 3 allows the CAS to send a Context-Aware OK context confirmation message to the CFIA module, which relays it (message 4) to the UE, to confirm to the latter the actual update, which is similar to a 200 OK message as part of the HTTP protocol.

Messages 1 to 4 are repeated when the UE discovers new context information. The procedure for dynamic transmission of service context information is similar to the procedure of dynamic transmission of the user context information to the CAS server as well as the procedure of dynamic update of service information when the message

HTTP POST is used. The representation of the context information in the HTTP POST message follows the RPID format, completed to include context information attributes representing the service context (for example, the start and end time of the service, the type of digital content, or the type of coded). The HTTP POST message including the attributes representing the service context is shown below:

POST / HTTP / 1.1 users

Host: CAS / Context

Content-Type: application / xml

Content-Length: (...)

<? xml version = "1.0" encoding = "UTF-8"^'?>

<context xralns = "urn: ietf rparams: xml: ns: pidf"

xmlns: dm = "urn: ietf: pararas: xml: ns: pidf: data-mode1" xralns: rpid = "urn: ietf: parans: xml: ns: pidf: rpid" entity = "near: SDandS @ home net ">

<dm: content>

<rpid: content-typex / rpid: content-type>

<rpid: starttimex / rpid: starttime>

<rpid: endtimex / rpid: endtime>

<rpid: codeex / rpid: codeo

</ dm content>

</ context>

FIG. 5 illustrates the exchange of messages corresponding to this procedure of dynamic transmission of service context information.

Message 1 corresponds to the transmission to the CFIA module (and the dynamic update) of the context information acquired by the SCA by extracting the service context information from the ESG received from the SD & S module. The CFIA module relays it to the CAS server (message 2) using the Ca interface. The HTTP POST message is used. The representation of the context information in the HTTP POST message follows the RPID format.

Message 3 corresponds to the sending by the CAS server of a CA-OK message (Context-Aware OK) to the CFIA module. This message is relayed to the SD & S module (message 4). This message is similar to a 200 OK message in the HTTP protocol.

Messages 1 to 4 are repeated when the SD & S module receives new information

The procedure for transmitting network context information during the session initialization takes place, according to one embodiment, by completing the resource reservation process according to the state of the art. In the state of the art, the IPTV-C module receiving the service request sends a Diameter protocol AA-Request message to the RACS subsystem to reserve a resource. Depending on the resources available, the RACS decides whether or not to reserve a resource for the service. An AA-answer message is sent by the RACS to the IPTV-C module to inform it of the result of the resource reservation request (success or failure). The process is completed to also send bandwidth information to the IPTV-C module, integrating an NCA module into the RACS and generating by this NCA module an AAA Answer context message (CAA-Answer) extending the AA-Answer message by adding an AVP attribute of QoS information (quality of service, English quality of service) that may for example include bandwidth information. An example of such a message is shown below:

CAA-Answer message

<CAA-Answer> :: =

<Session-Id>

{Auth-Application-ID}

{Origin-Host}

{Origin-Realm}

[Resuit-Code]

[Experimental-Result]

[Error-Message]

[Error-Reporting-Host]

[QoS-Info]

QoS-Inf ormation AVP Format

QoS-Information :: = <AVP Header: 1016>

[Traffic-Descriptor]

Figure 6 illustrates the message exchange corresponding to this network context information transmission procedure.

Message 1 corresponds to a conventional initialization request sent by the user wishing to start obtaining the service towards the IPTV-C module, and relies on a message of the Real Time Streaming Protocol (RTSP) type.

Message 2 corresponds to the resource reservation request, in which the IPTV-C module receiving message 1 contacts the RACS using the AA-Request message of the Diameter protocol.

Message 3 corresponds to the response to the resource reservation request, in which a CAA-Answer message of the modified Diameter protocol, containing resource information (bandwidth), is sent by the NCA module of the RACS to the IPTV-C module. . The message 4 corresponds to the transmission of network context information during an initialization of a session (in this case, bandwidth information) by the IPTV-C module to the CAS server by means of the interface Ce , using an HTTP POST message.

According to one embodiment, a procedure allows an MDCA module to dynamically transmit to CAS a network context information related to the current session. A message

HTTP POST is used, the representation of network context information according to the format

RPID modified to include context information attributes representing the network context

(eg jitter, packet loss and delays). Such a message including attributes representing a network context is shown below:

POST / HTTP / 1.1 users

Host: CAS / context

Content-Type: application / xml

Content-Length: (...)

<? xml version = "l .0" encoding = "UTF-8"?>

<context dm = "urn: ietf: params: xml: ns: pidf"

xmlns: dm = "urn: ietf: params: xml: ns: pidf: data-model" xmlns: rpid = "urn: ietf: params: xml: ns: pidf: rpid" entity = "IPTV-C @ home net ">

<dm: net ork id = "1234">

<rpid: net ork_state>

<packet_loss> </ packet_loss>

</ net ork_state>

</ dm: net ork>

</ Context>

Figure 7 illustrates a message exchange corresponding to this procedure that allows an MDCA module of an FM module to dynamically transmit to the CAS server network context information related to the current session. The message 1 corresponds to the extraction of the network context information related to the current session by an MDCA module, relying on a Real-time Transport Protocol (RTP) and RTCP reports / statistics during the session. Classes.

Message 2 corresponds to the transmission of context information by an MDCA module to the CAS server, by means of an HTTP POST message by means of the interface Ca '. The representation of the context information in the HTTP POST message follows the RPID format.

Figure 8 illustrates a notification by a service trigger module of the existence of a new custom service. The ST module can notify a user of the existence of the new service by sending it a custom EPG directly as content customization corresponding to the user's current context. The message 1 (HTTP GET message sent by user equipment) corresponds to a request from the user of a personalized program guide transmitted to the CFIA module. The latter relays the message (message 2) to the CAS server. The CAS server, more precisely the ST module of the CAS server, transmits a message 3 by means of the interface Ca to the CFIA module which relays it (message 4) to the user equipment. Messages 3 and 4 are HTTP Notify messages extending conventional HTTP POST messages by encapsulating service information. They contain the custom EPG generated by the ST module according to the context information stored in the CBD.

Figure 9 illustrates a communication between an ST module and an FM module to trigger the provision of personalized content. The ST module sends to the IPTV-C module an HTTP message NOTIFY (message 1) encapsulating the service information to trigger a service (eg adaptation of content according to the user context). In order to complete the content adaptation, the IPTV-C module selects the appropriate FM module and sends it the service information (message 2). The MF module can thus take into account this information during the adaptation of content.

The embodiments described above as examples are not limiting in nature.

The described embodiments allow easy deployment by relying on existing architectures (for example those that are standardized by ETSI / TISPAN) that can be supplemented by relying on protocols standardized by the IETF.

This allows advanced customization of IPTV services based on rich context information that can be related to the daily lives of users (user preferences, location, proximity of relevant devices, available networks and their proximity, service context, etc.).

This is particularly advantageous for mobile users and in particular for nomadic access to IPTV services in a personalized way, since there is no fixed association between a user identifier and a terminal. Indeed, the system is able to distinguish each user in a personalized way taking into account the equipment of this one and the characteristics of the network, whatever the equipment used to access the services and the place of the access (home , displacement, etc.).

Claims

A context management server for customizing an offer of digital content for a user of an audio-visual broadcast system over a context-based communication network, the system comprising a user interface module, a digital content broadcast module, and a broadcast module control module, the server comprising:

a third communication module, arranged to receive from the control module third context information relating to the network during an initialization of a session of the user,

the context for customizing the digital content offering being determined from the context information received by at least one of the communication modules.

The context management server according to claim 1, wherein the first communication module is arranged to receive fourth context information relating to the service, issued by a service discovery module of the system and relayed by the interface module. user.

3. Server according to claim 1, comprising a service triggering module for proposing a personalized digital content offer according to the context and wherein the third module is also arranged to transmit said offer to the control module.

The server of claim 1, comprising a service trigger module for customizing a program guide according to the context and wherein the first communication module is also arranged to transmit said personalized program guide to the user interface module.

A user interface module for an audio-visual broadcasting system, the user interface module comprising a first communication module arranged to relay to a Context management server according to claim 1, context information relating to a device of a user and / or a user.

6. Module according to claim 5, comprising means for registering the user with said server prior to the activation of the first communication module for said user.

The module of claim 5, wherein the first communication module is also arranged to relay service context information received from a service discovery module of the system.

8. Module according to claim 5, comprising a second communication module, arranged to relay to the device of the user a program guide received from the context management server.

9. Digital content broadcasting module for audio-visual broadcasting system, the broadcast module comprising network context information acquisition means for an established session of a user and means arranged to transmit information. context received by the acquisition means to a context management server according to claim 1.

10. Broadcast module control module for audio-visual broadcasting system, the control module comprising transmission means arranged to relay context information relating to the network during an initialization of a session to a management server. context according to claim 1.

An audio-visual broadcast system to a user device, comprising a user interface module according to claim 5, a digital content broadcasting module according to claim 9 and a broadcast module control module according to claim 10.

A method of customizing a digital content offering for a user of an audio-visual broadcast system over a context-based communication network, the method comprising sending context information by a a user interface module according to claim 5, by a digital content broadcasting module according to claim 9 and a broadcast module control module according to claim 10 to a server according to claim 1 via the communication network.

13. Computer program comprising instructions for implementing the method according to claim 12, when this program is executed by a processor.

14. Non-transitory computer-readable storage medium on which the computer program according to claim 13 is stored.