4.2.1 The Managed Model

The managed model deals with content services delivered over an end-to-end managed network. The end user can access content that is made available by the operator. The operator plays the “Content Aggregation” and “Content Delivery” roles:

• Content Provider: provides content and associated metadata to be delivered via the managed operator network. It provides the bundled content to the IPTV service provider through the Content Provider Interface (CPI). A content provider normally retains the rights to the audiovisual content (movies, documentaries, TV programs…etc.). It can be a production company, or a distributor/vendor.
• IPTV Service Provider: is a content aggregator that prepares the content provided by the content provider for delivery by providing additional metadata, content encryption, advertising etc. The Service Provider Interface (SPI) links the IPTV Service Provider to the Service Platform Provider.
• Service Platform Provider: provides the means to control the access to the service prior to delivery to the end user. The Service Platform Provider (SPP) might offer a set of enablers to enrich the IPTV services, such as handling charging information generation. The Transport and Control Interface (TCI) links the Service Platform Provider to the Network Provider
• Network Provider: provides transport resources for delivery of authorized content to the consumer domain. It also provides the communications between the consumer domain and the Service Platform Provider. The User to Network Interface (UNI) links the Network Provider to the consumer domain.

In a typical Managed model, a stakeholder, such as a Telecom Operator, plays the IPTV Service Provider, Service Platform Provider and Network Provider roles, so that high quality services can be guaranteed to the end user.

4.2.2 Unmanaged Model

The Unmanaged Model has the same set of technical roles as that of the managed model (See Figure 4-3), but the roles are typically played by different stakeholders. Note that providing services of equivalent quality to those offered by the managed model cannot be easily guaranteed owing to the inherent lack of quality of service guarantees in Internet delivery.

In an Unmanaged Model the relationship between the Service Platform Provider and the Network Provider is not necessarily defined. The role of the Service Platform Provider could be played by an Internet portal.

The Internet Access Interface (IAI) in the Unmanaged Model replaces the TCI in the managed model.

5.2.1 Network Provider Functional Entities

The following is a brief description of the functional entities depicted in Figure 5-2:

• Service Access Authentication: This functional entity is responsible for service access protection and authentication of users. The user is identified and authenticated by means of some pre-established credentials (such as user name and password or GBA authentication).
• Authentication and Session Management (Managed Network Model only): This functional entity is responsible for the authentication of the user for service access protection, as well as session management for the purpose of coordinating and managing (service accessibility) users’ activities and for charging purposes. To this end, the session management ensures that a user request for a service is routed to the appropriate Application Server. This entity has access to the Subscription Profile.
• Authentication Proxy (Managed Network Model only): This functional entity establishes a secure communications channel between a network provider’s security domain and the ITF. The Authentication Proxy terminates all signalling and control traffic destined to functions within the control of the network provider, and eliminates the need for separate security associations with individual network elements hosting these functions.
• GBA Single Sign-on: This functional entity allows Single Sign-on based on the Generic Bootstrapping Architecture. It is used in managed networks, but can also be used in unmanaged networks when a UICC-based IMS authentication is available in the home network.
• IPTV Service Provider Discovery: provides information necessary for the ITF to select IPTV Service Providers, in both the managed and unmanaged models
• IPTV Service Discovery: provides information about IPTV services offered by an IPTV service provider, in both the managed and unmanaged models
• IPTV Control: This is the main control point for the IPTV solution. It controls the delivery of IPTV services to authorized users. In that regard, it inter-works with the Authentication and Session Management functional entity, which routes incoming/outgoing requests from the IPTV Control to the appropriate destination. This entity has access to the IPTV User and Subscription Profiles. The IPTV Control generates charging related information.
• IPTV Metadata Control: This functional entity performs aggregation of the metadata coming from content providers or third party sources. The IPTV Metadata Control offers basic metadata related to services such as service description, the whole program guide, details related to each event (e.g. description of the film, actors, etc.), program listings and their schedule, personalized Content Guide (CG). This functional entity enables the user to search, discover and initiate immediate viewing or scheduled viewing of future programs and stored content.
• IPTV Applications: These include IPTV related services or application logic such as CoD, Push CoD, Content Download, Network PVR, and Messaging as well as Web push/pull service. The function provides end users with IPTV applications using the Declarative Application Environment (DAE). The function provides Web Server functionality to allow an authorized user to access some IPTV services (e.g., to remotely schedule a recording on a PVR by using a non-OITF enabled device which has a browser.).
• Provider Specific Applications: This function interacts with the Application Gateway in the consumer domain in order to download generic applications. Provider specific applications run on the AG execution environment. The download can be via push or pull mechanisms. For IPTV, this function can provide end users with provider-specific applications that run in the Procedural Application Environment (PAE) which can manipulate media streams and the Content Guide.
• Person-to-Person Communication Enablers (Managed Network Model only): These include interface to various communication services, such as multimedia telephony, presence, chat, messaging, caller ID notification, etc., for service blending with IPTV related services.
• IPTV Service Profile: This functional entity holds the IPTV User Profile that is associated with the user’s IPTV subscription with an IPTV Service Provider. The IPTV User Profile is consulted by the IPTV Service Provider when the user requests an IPTV service. The IPTV User Profile can be updated by the IPTV Service Provider as well as by an authorized end-user, if allowed by the IPTV Service Provider.
• User Database: The central database of Subscription profiles, managed by the Service Platform Provider. The nature of this may vary between managed and unmanaged systems, and would typically includes data that is not IPTV service specific such as authentication information, communication related information, etc.
• The Content Delivery Network (CDN): This is a fundamental functionality in an IPTV CoD solution. For CoD, it allows the optimization of the network use through a distribution of the media servers in the physical network, and the optimization of the storage resources through a popularity-based distribution of the content on the media servers. This results in having popular content massively distributed on media servers at the edge of the network (as close as possible to the customer) while less popular content are distributed on a reduced number of media servers. For scheduled content, it enables the support of enhanced services like Personal Channel (PCh) and Network Personal Recording (nPVR).
• Multicast Content Delivery Function: This entity is responsible for delivery of content and generic data to the OITF by means of multicast, using multicast streams and the multicast data channel respectively. In the content streaming case, this is the so-called head end. In the data case it is the source of the multicast data channel.
• Fast Channel Change/Retransmission Server: The functional entity that delivers ancillary data for multicast streams when triggered by the OITF, in the context of FCC/RET service
• Network Attachment: This functional entity includes the functions associated with provisioning of IP addresses, network level user authentication and access network configuration. For the unmanaged model, this function is provided by the user’s access network provider.
• Transport Processing Function: This functional entity includes the functions needed to support real-time multicast and unicast streams, optimizing network usage in the physical network, and enforcing related traffic policies coming from Resource and Admission Control.
• Resource and Admission Control (Managed Network Model only): In a managed network, Resource and Admission Control provides policy control and resource reservation for the required transport resources, for both unicast and multicast delivery. In this capacity, it interacts with the authentication and session management functional entity and the Transport processing function.
• Charging: This functional entity includes the charging mechanisms at the platform level available to all the IPTV Service Providers, for all the users managed by the Service Platform Provider. The charging subsystem collects network and platform related events that can be later used for billing and statistical analysis purposes. The IPTV service providers are free to build their own billing systems that could be based on common charging but also be completely independent (e.g. based on the CSP and CAS). The IPTV service provider’s billing mechanisms are out of the scope of this specification.
• CSP-T Server: This functional entity handles service protection and content protection for the CSP-T client in the OITF. It is used to enable the key management necessary to implement service protection and content protection.
• CSP-G Server: This functional entity handles service protection and content protection for the Content and Service Protection Gateway (CSPG) in the residential network. The solution for service and content protection is specific to the IPTV service provider. Therefore, network reference points are not specified by this specification and interfaces are defined by the IPTV Service Provider.
• Remote Management: In a managed network, this entity provides the server-side functionalities to remotely manage the residential network devices, for both provisioning and assurance purposes: the functions provided relates to configuration management (including firmware upgrade), fault management (including troubleshooting and diagnostics), and performance monitoring.
• Key Management Function: Entity responsible for storing and providing Service, Program, Content Keys and ECM attached information.
• Content on Demand Encryption Management Function: Back office Content on Demand function in charge of encrypting Content on Demand.
• Notification Services: This is the server that generates notifications for end-users in a form that corresponds to the IPTV end-user preference. The forms currently supported are short message services (SMS), multi media messaging (MMS), and IMS instant messaging. Note that these notifications are not related to the DAE-based notifications on UNIS-6.
• Emergency Services: This is the node that generates emergency messages destined for IPTV end users. This node is not owned by the platform service provider. Platform service providers just interfaces with it based on applicable standards which are typically regional and local in nature.
• Messaging AS: This is the server that supports the generation and delivery of IMS instant messaging to IMS end users. This is a part of the person-to-person communication enabler but has been extracted here for clarity.
• Other Delivery Networks: This entity represents existing mobile networks used to deliver MMS and SMS messages to end users.
• Audience Research Collector: This entity enables the Service Provider to collect and retrieve Audience Research data by exploiting the Transport Processing Function to intercept requests from users. How the Transport Processing Function supports this is out of scope of this specification. It also enables the Service Provider to retrieve and collect the Audience Research data from functional entities such as the IPTV Control, Cluster Controller, IPTV Application, etc., as well as other functional entities that receive service status information through the (SIP/RTSP) signalling path
• Audience Research Agency: This functional entity collects audience research data from different Service Providers, under the explicit consent of the users. It is usually managed by an external certified authority, which collects audience data across networks, platforms, types of services and service providers. It can use the collected Audience Research data for consultation purposes, or statistical analysis, data profiling etc. The behaviour of Audience Research Agency is out of scope of this specification.
• Content Management Function: This offline entity handles content lifecycle (ingest, encoding, encryption, distribution) and content aggregation into commercial offers for On-Demand Content.
• Scheduling Function: This offline entity handles content lifecycle (ingest, encoding, encryption, distribution) and content aggregation into commercial offers for Scheduled Content.
• Scheduled Content Encryption Function: Back office Scheduled Content function in charge of encrypting the Scheduled Content.
• Recording Function: This function handles the recording of Scheduled Content for later use for catch-up and start-over.

5.2.1.1 Content Delivery Network

The following section describes the internal functional entities and reference points in the CDN functional entity.

The following is a brief description of the functional entities that make up the CDN, as depicted in Figure 5-3.

The Content Delivery Network contains three sub-functions:

• Content Delivery Network Controller (CDNC): This functional entity performs cluster The term Cluster corresponds to a logical association of one or more "Content Delivery Functions" which share some resources (such as location, storage capacity etc.). selection in the CDN, based on the request issued by the IPTV Control functional entity. Many instances of a CDN controller may coexist in the same CDN. They may interact for the purpose of selecting the right cluster.
• Cluster Controller (CC): This functional entity manages a set of Content Delivery Functions (a cluster of CDFs).
  • It terminates IPTV service session setup
  • It handles content delivery session setup
  • It proxies all message exchanges between CDFs and the ITF.
  • It maintains the state of the media servers (Content Delivery Functions)
• Content Delivery Function (CDF): This functional entity is responsible for media processing, delivery and distribution, under the control of the Cluster Controller.

The following reference points depicted in Figure 5-3 are internal to the CDN:

• NPI-10;
• NPI-25;
• NPI-26;

5.2.2 Mapping between HLA and IPTV Domains (informative)

5.2.3 Reference Points Description

5.3.1 Residential Network Functional Entities

The following is a more detailed description of the various functional entities identified above.

For ease of understanding of the detailed functional description of the residential network, this specification uses a stepwise build up of the residential network functional entities comprising of the following steps:

• OITF and WAN Gateway (WG)
• OITF, WG and IG
• OITF, WG, IG and the optional functional entities AG and CSPG

Note that this build-up of functions does not imply that these combinations of functions are the only deployment options possible. Each of OITF, IG, AG, CSPG and WAN Gateway functional entities may be deployed as separate physical devices in the residential network or in combinations or may not be deployed at all in the case of the optional entities AG and CSPG as described in section 5.3.4.

5.3.1.1 Open IPTV Terminal Functional Entity (OITF)

The OITF functional entity shown in Figure 5-5 includes the following functions:

User Profile Management: Manages subscription information associated with a specific User, e.g., viewing preferences. The user profile management functions include the ability to create, fetch, modify, delete, replace user profiles.

Stream Session Management and Control: Initiates and terminates content delivery sessions. Manages content delivery sessions, including trick play control of unicast streams and multicast stream control. It applies to both the unmanaged and the managed models.

Stream Transmitter/Receiver: Receives streamed content from the network and includes stream buffering in the case of progressive download. It also transmits real-time audio and video in the case of multimedia telephony. The function applies to both the managed and unmanaged models, although different technologies might be chosen for each case.

Codecs: A/V codecs for all streamed and downloaded content. It includes decoding, scaling and rendering functions.

CSP: Client side key management for the terminal centric approach to service protection and content protection. Enforces content usage rules in the client. It applies to both the managed and the unmanaged models. See CSP Gateway functional entity for the alternative gateway centric approach to service and content protection.

Content Download: Reception of content downloaded to the client in non-real time. Content download might be unicast or multicast. For multicast, the MDTF is used. Local storage is required for content download. It applies to both the managed and the unmanaged models. This function is optional.

MDTF (Multicast Data Terminating Function): This function receives generic data sent over multicast. Content types that can be distributed to MDTF include Content Guide data, static DAE content, video content, interactivity information, notifications, software releases and patches.

Decrypt: Removes any encryption applied to the content, under the control of the CSP function. This function is not used for unencrypted content. It applies to both the managed and the unmanaged models.

Declarative Application Environment (DAE): A declarative language based environment (browser) based on CEA-2014 [Ref-3] for presentation of user interface and including scripting support for interaction with network server-side applications and access to the APIs of the other OITF functions.

The specification of the DAE declarative language environment including the APIs available to the downloaded applications is within the scope of the Forum.

The DAE can also query, internally to the OITF, the Metadata-based Content Guide Client in order to extract any data it may contain.

The downloaded applications that run in the DAE are considered to be Service Provider specific and therefore will not be defined by the Forum’s specifications.

Metadata-based Content Guide Client: Client for metadata-based content guides. The user interface including the presentation of metadata-based content guide is OITF vendor dependent and is out of scope of this specification. This function may also make the metadata available to Residential Network devices via the DLNA Functions function. It applies to both the managed and the unmanaged models.

Remote Management Client: provides the client-side functions to remotely manage the OITF, for both provisioning and assurance purposes. The functions provided relate to configuration management (including firmware upgrade) and fault management (including troubleshooting and diagnostics). When realized as standard TR-069 client, it uses the UNI-RMS interface (providing also performance monitoring); otherwise, remote management is supported as a DAE application which uses the UNIS-6 interface.

IPTV Service Discovery: Function for discovering IPTV Service Providers and related services. It applies to both the unmanaged and the managed models. Note that different aspects of DVB SD&S [Ref-4] may apply to the different models.

Integral Storage System: Storage for content download and PVR based functions. This function is optional but will be required if Content Download is supported.

DLNA Functions: Implements DLNA DMS [Ref-2] functions to expose and distribute content in a DLNA compliant manner through the residential network. The DLNA Functions function may also offer a DLNA DMP [Ref-3] function to locate and select content available from other DMS in the residential network. The selected content can be streamed across the residential network and rendered by the OITF. The DLNA Functions may also support the DLNA RUI Source capability (+RUISRC+) to provide remote UI content to the DLNA RUI Pull controller capability (+RUIPL+), which can be used to support an ITF Remote Control Function (IRCF). This function is optional.

OITF embedded application: This optional function provides embedded applications for IPTV services, e.g. local PVR, using the standardized interfaces which are defined as UNI and HNI-IGI. The user interaction with this function is OITF vendor specific

Performance Monitor Client: Client for providing feedback on service quality – for example, pixilation, frame loss, packet loss and delay (the exact information to be provided is to be specified other specifications). It applies to both the managed and the unmanaged models.

Device Management: This function acts as a UPnP Device Management Client [Ref-42] for remote management operations such as configuration management (including triggering of a software upgrade) and fault management (including troubleshooting and diagnostics).

The WAN Gateway functional entity shown in Figure 5-5 contains the following functions:

LAN/WAN Gateway: Supports the physical termination of the access network (e.g. xDSL, GPON etc.) and the layer 2, layer 3 and higher services (such as NAT, IGMP proxy-routing) required to support IPTV and other services terminated in the residential network that share the WAN connection.

Attachment: Attachment function is responsible for the attachment of the residential network to the Network Provider.

RMS3: Depending on the provider model, the WAN Gateway may be remotely monitored and configured by the access service provider. The RMS function supports the interface to the remote manager (i.e. TR 069 CWMP remote management protocol [Ref-1], plus TR 098 device data model [Ref-33] with possible extensions.)

QoS: The QoS function provides classification, marking, re-marking, policing, and queuing of Ethernet and IP traffic that goes between the WAN and LAN interfaces. Marking and re-marking of Ethernet priority and Diffserv code points (DSCP) [Ref-6] is supported. Classification can occur through a variety of characteristics of IP traffic, including Ethernet priority, DSCP, origination and destination IP address, and application protocol.

IGMP Support: Provides the functions for IGMP Proxy and IGMP Snooping. The IGMP Proxy allows multiple in-home devices in the residential network to be able to join the same multicast stream. IGMP Snooping is the process of listening to IGMP traffic to allow, when present, the switch to "listen in" on the IGMP conversation between hosts and routers by processing the layer 3 IGMP packets sent in a multicast network to avoid flooding (see section 5.3.3.1).

UN/MC Conv: The WAN Gateway may have this function to avoid some problems due to the low efficiency and unreliability of multicast on wireless networks. This function is not specified in the Release 2 Solution [Ref-45].

UPnP Control Point: The UPnP Control Point [Ref-28] interacts with the UPnP Device Management Client [Ref-42] in the OITF for remote management operations.

5.3.1.2 OITF and IG

In a device that implements both the OITF and IG, the use of the HNI-IGI interface is optional.

The IG functional entity depicted in Figure 5-6 includes the following additional functions:

IMS Gateway (IG)

Authentication/Session Management Client/Server: Responsible for subscriber authentication and any session management required for managed networks (e.g., managed IPTV services and person-to-person communication services). The authentication performed by this function is (re-)used for Content and Service Protection (CSP) purposes.

The Authentication/Session Management client/server interacts with the network servers through the UNIS-8 interface. This function includes the implicit connectivity admission control (CAC) request for the WAN side. No explicit CAC function is required on the LAN side.

IG-OITF Server: The IG-OITF server exposes authentication and session management client/server functionalities to the OITF for managed IPTV services and blended person-to-person communication application support (e.g., caller id display, messaging etc.) via HTTP and/or other protocols as required. If required, the interaction between the IG-OITF Server and the OITF may result in a UI on the OITF display or the delivery of execution script(s) to the DAE function on the OITF.

RMS2: Client application for remote management functions in a managed environment. It provides a standard interface for provisioning and assurance tasks on managed devices with the IG function (i.e. TR 069 CWMP remote management protocol [Ref-1], plus TR 104 [Ref-29] IMS data model with possible extensions). It includes functions for configuration management, firmware upgrade, troubleshooting/diagnostics, performance management and monitoring of IMS/SIP services.

Network Discovery: Network discovery function is responsible for the discovery of and attachment to an IMS service provider.

DLNA Content Transformation Device (DLNA CTD): This optional function provides media transformation, e.g. transcoding for remote access. The DLNA Content Transformation Device implements the DLNA Media Interoperability Unit (MUI) device class or DLNA devices which implement the DLNA virtual device functionality with content transformation function.

5.3.1.3 OITF, IG, AG and CSPG

A residential network with the addition of the optional Application Gateway and the optional CSP Gateway functional entities is depicted in Figure 5-7. This represents a residential network with all the residential network functional entities. The AG and CSPG are independent optional functional entities that may be required in a specific residential network configuration. The following additional functions are identified.

Application Gateway (AG)

Procedural Application Environment (PAE): A local procedural language execution environment based on Java Connected Device Configuration (CDC) [Ref-34] for IPTV Service Provider specific downloaded applications. If required, these applications can present a UI via the CEA-2014 [Ref-2] based Remote UI function on the OITF’s DAE. When the PAE is deployed in a device with local graphics rendering (e.g., combined with an OITF), these applications also can also directly access that local graphics system.

The definition of the full capabilities of the PAE is within the scope of the Forum’s specifications. The specification of the Service Provider specific applications that are downloaded and executed in the environment are outside of the scope of the Forum’s specifications.

The PAE is a multipurpose execution environment capable of supporting many IPTV-specific and general services. These capabilities include support of the following service provider specific applications:

• Media Control: Enables the Service Provider to locally intercept the media stream (media, control, CSP) for the purpose of adding or inserting content generated or stored in the AG into that media stream. The operation of Media Control shall be under the control of Applications running in the PAE via defined APIs.

  Note that for protected content, this is only possible when the AG and the CSPG are combined in the same device and that the Release 2 Solution [Ref-45] does not define the routing of media content (for the purposes of media control) via an AG which is not also a CSPG

• CG: Client with the following functions:
  • Discovery and description of available services and content.
  • At least one of:
    • Presentation of an CG on the OITF via the DAE
    • Passing all or some subset of the metadata to the “Metadata CG client” on the OITF, depending on the policy of either the Service Platform Provider or the IPTV Service Provider.

      Note that this is not addressed in the Release 2 specifications.

    • When present, this application terminates the UNIS-7 interface in addition to the CG application client in the OITF, which also directly handles the UNIS-7 interface.
• IPTV Service Discovery: Client with the following functions:
  • Discovery of available service providers.
  • Discovery and description of available services and content.
• Fully blended communication services: Possibly requiring additional hardware to support advanced applications such as video telephony. The HNI-AGI interface allow applications in the AG implementing advanced communication services to access the Authorization and Session Management functions in the IG.
• RUI Server: This function enables applications running in the PAE to serve declarative language applications running on the DAE in the OITF.
• Proprietary or non-standard content download protocols: Implementation of proprietary, non-standard or other service provider-specific protocols in a PAE application.

RMS1: Client application for remote management functions in a managed environment. It provides a standard interface for provisioning and assurance tasks on managed devices with the AG function (i.e. TR 069 CWMP remote management protocol [Ref-1], plus TR 135 [Ref-30]/TR 140 [Ref-31] IPTV/storage data model with possible extensions). It includes functions for configuration management, firmware upgrade, troubleshooting/diagnostics, performance management and monitoring of streaming services.

CSP Gateway (CSPG)

The CSP Gateway is required when a gateway centric approach to service and content protection is deployed as an alternative to the Marlin based CSP functions of the OITF. A secure authenticated channel is used between the CSPG and the OITF.

5.3.2 Handling QoS in the Residential Network

The QoS function in the WAN gateway is responsible for the QoS marking (e.g., DSCP, Ethernet priority) into and out of the residential network. All nodes in the residential network are responsible for marking the appropriate priority of originating traffic.

5.3.3 Multicast Handling in modem gateway router

Modem gateway router includes transport related functionality such as LAN handling, IP multicast support, etc. IPTV services require additional functionality to be supported in order to ensure efficiency in the home LAN environment.

5.3.4 Deployment Options

This section describes the allowable deployment options in the residential network, and the services supported by each deployment option.

Each of the OITF, IG, AG and WG functional entities may be deployed as separate physical devices in the residential network, or in combinations as described in this section.

5.3.4.2 Deployment Examples

5.3.4.2.1 OITF STB

This deployment supports the consumption of unmanaged services using a legacy TV. The following devices are deployed.

• A WAN Gateway: This is a standard modem/router, providing access to an unmanaged network via an ISP.
• OITF STB: A set top box implementing the OITF and connecting to a legacy TV via, for example, HDMI or SCART.
• Legacy TV: A television without OITF or DLNA capabilities.

Optionally, the OITF STB may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the residential network.

5.3.4.2.2 OITF TV

This deployment supports unmanaged services without the need for an additional set top box. The following devices are deployed.

• A WAN Gateway: This is a standard modem/router, providing access to an unmanaged network via an ISP.
• OITF TV: A television including an OITF.

Optionally, the OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network.

5.3.4.2.3 Combined IG–WAN Gateway with OITF TV

This deployment supports both managed and unmanaged services, with DAE applications. The following devices are deployed:

• Combined IG and WAN Gateway: A single physical device including an IG and modem/router functionality.
• OITF TV: This is an OITF TV, as described in this document.

Optionally, the OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network.

5.3.4.2.4 Combined IG–WAN Gateway with multiple OITF TVs

This deployment supports both managed and unmanaged services, with DAE applications. The following devices are deployed:

• Combined IG and WAN Gateway: A single physical device including an IG and modem/router functionality.
• OITF TVs: These are OITF TVs, as described in this document.

Optionally, either OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network.

Note that one or both OITFs may be deployed in an STB connected to a legacy TV, as shown below, instead of being embedded in a TV.

5.3.4.2.5 Combined IG–OITF STB and Multiple OITFs

This deployment supports both managed and unmanaged services, with DAE applications, presented on an OITF TV and a legacy TV. The following devices are deployed:

• A WAN Gateway.
• Combined IG and OITF STB: A set top box including IG and OITF functionality that exposes HNI-IGI to other OITFs in the residential network. It connects to the legacy TV using some non-OIPF specified mechanism, such as HDMI or SCART.
• OITF TV: This is a TV containing an OITF.

Optionally, the OITF TV and IG-OITF STB may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network.

5.3.4.2.6 Combined IG–OITF TV

This deployment supports both managed and unmanaged services, with DAE applications, presented on an OITF TV. The following devices are deployed:

• A WAN Gateway.
• Combined IG and OITF TV: A TV including both IG and OITF functionality.

Optionally, the IG-OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network.

Note that the IG inside the TV may be used by external OITFs to access managed services.

5.3.4.2.7 Multiple IG–OITF STBs

This deployment supports both managed and unmanaged services, with DAE applications, presented on multiple legacy TVs. The following devices are deployed:

• A WAN Gateway.
• Two combined IG-OITF STBs: STBs including both IG and OITF functionality.

Only one IG can be active in the residential network at any one time. This limitation may be relaxed in a future specification.

Optionally, each IG-OITF TV may act as a DMS to make OIPF-defined services available to DLNA devices. They may also act as a DMP to access content from other DLNA devices on the home network.

5.3.4.2.8 Combined IG–AG–OITF STB and OITF TV

This deployment supports both managed and unmanaged services, with DAE and PAE applications, presented on an OITF TV and a legacy TV. The following devices are deployed:

• A WAN Gateway.
• Combined IG, AG and OITF STB: A set top box including IG, AG and OITF functionality, that exposes the HNI-INI-AG interface to other OITFs in the residential network. It connects to the legacy TV using some non-OIPF specified mechanism, such as HDMI or SCART.
• OITF TV: This is a TV containing an OITF.

Optionally, the combined IG-AG-OITF STB or the OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. They may also act as a DLNA DMP to access content from other DLNA devices on the home network.

5.3.4.2.9 Combined AG–IG with multiple OITFs

This deployment supports both managed and unmanaged services, with DAE and PAE applications, presented on an OITF TV and a legacy TV. The following devices are deployed:

• A WAN Gateway.
• Combined AG-IG device: A device including both IG and AG functionality, that exposes the HNI-INI-AG interface to OITFs in the residential network.
• OITF STB: A set top box containing an OITF. It connects to the legacy TV using some non-OIPF specified mechanism, such as HDMI or SCART.
• OITF TV: A TV containing an OITF.

Optionally, the OITF STB or the OITF TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. They may also act as a DLNA DMP to access content from other DLNA devices on the home network.

5.3.4.2.10 AG–IG, OITF–IG, Multiple OITFs

This deployment supports managed and unmanaged services, and DAE and PAE applications. The following devices are deployed:

• A WAN Gateway.
• Combined AG-IG device: A device including both IG and AG functionality, that exposes the HNI-INI-AG interface to OITFs in the residential network.
• OITF STB: A set top box containing an OITF. It connects to the legacy TV using some non-OIPF specified mechanism, such as HDMI or SCART.
• IG-OITF STB: A set top box containing both an IG and an OITF.
• OITF TV: A TV containing an OITF.

In this deployment, there are multiple IGs. Only one IG can be active in the residential network at any point in time. The ISIM application must always be in the AG-IG in this case.

Note: The applicability of Remote Access to this deployment has not been studied.

5.3.4.2.11 Combined OITF–AG TV and IG–WAN Gateway

This deployment supports managed and unmanaged services, and DAE and PAE applications. The following devices are deployed:

• Combined IG-WAN Gateway: A single physical device including an IG and WAN Gateway functionality.
• Combined AG-OITF TV: A TV including both an OITF and an AG.

Optionally, the OITF-AG TV may act as a DLNA DMS to make OIPF-defined services available to DLNA devices. It may also act as a DLNA DMP to access content from other DLNA devices on the home network

5.3.5 Residential Network Reference Points

• HNI-INI: This is a group of reference points directly connected to the OITF to provide application layer protocols common to both managed and unmanaged models. If an AG function is deployed, the AG may terminate HNI-INI in addition to the OITF as described in section 5.3.1.3. The HNI-INI consists of the following UNI reference points.
  • UNIP-1 (to “User Profile Management”)
  • UNIP-2 (to “Person-to Person-Communication Enablers User Profile management”)
  • UNIS-13 (to “Stream Session Management and Control”)
  • UNIS-11 (to “Stream Session Management and Control”)
  • UNIS-CSP-T (to “CSP”)
  • UNIS-6 (to “DAE”)
  • UNIS-7 (to “Metadata based Content Guide client”)
  • UNIT-17 (to “Stream transmitter/receiver”)
  • UNIS-14 (to “Stream Session Management and Control”)
  • UNIS-15 (to “Service Discovery”)
  • UNIT-18 (to “Performance Monitor Client”)
• HNI-INI-AG: This interface is a group of reference points between the OITF and AG which supports the adaptation of the IPTV services to the OITF. Where applicable, this interface uses the same protocols as HNI-INI, as follows: the UNIS-6 reference point always applies between the OITF and AG. The following reference points may apply when the AG includes A/V media storage - UNIS-11, UNIT-17 and UNIT-18. Use of the remaining reference points from HNI-INI between an OITF and an AG is not defined in the Release 2 Solution [Ref-45]. Additionally, the HNI-INI-AG interface includes the device discovery mechanisms.
• HNI-IGI: This interface is between the OITF and IG and provides, to the OITF, access to IG functions for the adaptation to IPTV services on managed networks. The HNI-IGI includes device discovery mechanisms.
• HNI-AGI: This interface is between the IG and AG and provides. To the AG, access to IG functions for the adaptation to IPTV services in managed networks. The HNI-AGI includes device discovery mechanisms.
• HNI-AMNI: This interface is between the IG and the network and includes the reference points that are required in addition to the HNI-INI reference points, to deliver managed services.
• HNI-CSP: This interface is between the OITF and the CSPG and allows the OITF to access CSPG functions for the conversion from a content and service protection solution to a secure authenticated channel between the CSPG and the OITF.
• HNI-AGC: This interface allows access to encryption keys.
• HNI-DM: This is the interface between the WAN Gateway and the OITF to support remote management of the OITF in the home. This reference point uses the UPnP DM protocol [Ref-42].

  Note: The mapping between UNI-RMS and HNI-DM will be based on [Ref-43].

5.4.1 RAC functional description and deployment options

The RAC functional entities are:

• A-RACF (Access Resource Admission Control Function): performs admission control and derives the traffic policies that are installed in the RCEF.
• SPDF (Service-based Policy Decision Function): provides a single point of contact for the Authentication and Session Management FE to receive resource reservation requests and acts as a final Policy Decision Point for Service-Based Policy control.

The Transport Processing Functions involved in processing unicast and multicast flows are:

• BTF (Basic Transport Function): sends and receives IGMP and PIM messages; and replicates multicast flows;
• RCEF (Resource Control Enforcement Function): enforces traffic policies and builds and forwards admission control requests to the A-RACF;

To maximize performance a distributed architecture is possible; in particular, depending on operator policy, the A-RACF may be located in any Transport Processing Function node. All Transport Processing Function Nodes have the following deployment options:

• BTF only; in this case policies are not enforced at the Transport Node;
• BTF + RCEF; in this case a centralized resource and admission control approach is used;
• BTF + RCEF + A-RACF; in this case a distributed resource and admission control approach is used;

The interfaces between the functional entities are:

• RCEF – A-RACF: based on the same protocol as used between the Authentication and Session Management and the Resource and Admission Control Function, i.e. Diameter [Ref-27]. The RCEF - BTF interface can be considered an internal Transport Processing Functions interface.
• A-RACF – A-RACF: Inter A-RACF interface when multiple A-RACFs are present. One A-RACF could delegate the control of a resource to another A-RACF through this interface.

A more detailed description of the RAC behaviour, with examples of specific deployment scenarios, is provided in Appendix E.

6.2.1 IPTV Service Discovery and IPTV Service Access Procedures for Unmanaged Networks

This section describes the IPTV Service Discovery and Service Access procedures for unmanaged networks. As described in section 5.3, the minimum set of functional entities needed to access unmanaged IPTV services are the OITF and the WAN Gateway; thus, the IPTV Service Discovery and Service Access procedures for unmanaged network are shown hereafter considering only these entities.

6.2.1.1 High Level Procedure

The IPTV Service Discovery and IPTV Service Access procedures for an unmanaged network comprise a number of steps, as shown in Figure 6-2:

1.	Determination of the IPTV Service Provider Discovery entry point
2.	IPTV Service Provider Discovery
3.	IPTV Service Discovery
4.	IPTV Service Access (e.g. Access to the Content Guide – via metadata or web page)

These steps are described in detail below.

0.	Attachment to the network, where the OITF obtains connectivity to the unmanaged network through the WAN Gateway
1.	Determination of an IPTV Service Provider Discovery entry point. This is an internal process in the OITF.
2.	The OITF initiates the IPTV Service Provider Discovery using this entry point. In this step, the IPTV Service Provider Discovery functional entity provides the list of IPTV Service Providers and information that is used in the next step (e.g. IPTV Service Provider name, IP address, protocols to be used)
3.	The OITF initiates the IPTV Service Discovery. In this phase the OITF selects an IPTV Service Provider and obtains the list of IPTV services available from that specific IPTV Service Provider
4.	The OITF can select and access an IPTV service, e.g. access the Content Guide.

6.2.1.3 IPTV Service Provider Discovery

The OITF requests the information on the available IPTV service providers from the IPTV Service Provider Discovery functional entity via HTTP(S).

6.2.1.4 IPTV Service Discovery

The Service Discovery Record can be delivered via HTTP(S) as XML data (DVB-IP SD&S Record) or as a Web Page.

6.2.1.5 IPTV Service Access

The following figure shows the call flow for obtaining the Content Guide, which is an example of IPTV service access.

6.2.2 IPTV Service Discovery and IPTV Service Access Procedures for the Managed Model

This section describes the IPTV Service Discovery and Service Access procedures for managed networks. As described in section 5.3, the minimum set of functional entities needed to access the managed IPTV services are the OITF, the IG and the WAN Gateway; moreover, the AG can be introduced as an optional functional entity in some deployment options.

The IPTV Service Discovery and Service Access procedures are shown hereafter, starting from a high-level procedure description and then detailing two cases based on two different deployment options. Section 6.2.2.2 shows the case where just the IG is deployed, while section 6.2.2.3 describes the case where the AG is also deployed together with the IG.

Although the flows depicted in this section explicitly show the HNI-IGI based communication between the OITF and IG, it must be noted that in the case where a device implements both the OITF and IG, this type of communication may not be required.

6.2.2.1 High Level Procedure

The managed network Service Provider Discovery comprises a number of steps as shown in Figure 6-6:

0.	Attachment to the Service Platform provider (SPP)
1.	Discovery of the IG. The OITF is turned on and obtains the entry point for the IPTV Service Provider Discovery from the IG. The determination of the IPTV Service Provider Discovery entry points can be achieved in a number of ways e.g. pre-configuration of the IG or using a specific event package, the service provider discovery request can be forwarded to the appropriate Service Provider Discovery FE.
2.	Registration with the SPP (IMS Registration)
3.	GBA bootstrapping procedure
4a.	IPTV Service Provider Discovery: The OITF initiates the IPTV Service Provider Discovery. The Service Provider Discovery FE provides the list of IPTV Service Providers and information used for the next step (e.g. IPTV Service Providers’ name, IP address, protocols to be used).
4b.	IPTV Service Discovery: The OITF initiates the IPTV Service Discovery. In this step, the OITF selects an IPTV Service Provider and obtains from the Service Discovery FE the list of services available from that specific IPTV Service Provider.
5.	The OITF can select and access an IPTV service, e.g., access the Content Guide, via metadata or a web page.

In the case where there is a 1-to-1 relationship between the Service Platform Provider and the IPTV Service Provider, the Service Provider Discovery phase will return a single record; therefore, in such a deployment, the subscriber would not select the service provider and the initial response to Service Provider discovery could return the address of the Service Discovery functional entity.

6.2.2.2 IPTV Service Discovery and Service Access for Residential networks with an IG

6.2.2.2.1 High Level Step 4a – IPTV Service Provider Discovery

The call flow in Figure 6-7 shows the case where the OITF requests, via the IG and the ASM, information about the available IPTV Service Providers from the Service Provider Discovery FE

Assumptions for this signal flow are that:

• The IG is registered with the SPP.
• The SPP has configured the IG.
• The IG knows the service URI of the IPTV Service Provider Discovery FE. This FE’s service URI as well as the protocol to use to access it may be well known within the SPP domain.

In signals 2-7 the IG obtains a list of IPTV Service Providers available via the SPP. The result of this phase (step 10) is the retrieval of the list of IPTV Service Providers and related information (e.g. the IPTV Service Providers’ name, IPTV SPs SD Service-URI (address of IPTV Service Discovery entity), protocol to be used for Service Discovery).

It is recommended that a well known Public Service Identifier (PSI) is assigned for the IPTV Service Provider Discovery functional entity. This well known PSI, which is a SIP URI, simplifies the remote configuration of IGs and allows IMS routing to be fully exploited.

The User Database is configured with the originating filter criteria necessary to route the SIP SUBSCRIBE messages from authorized users to the correct FE. In order to ensure that unauthorized users do not get access to the Service Provider Discovery FE, the PSI should not be configured in the DNS of the Service Platform Provider.

HTTP can optionally be used in this signal flow.

6.2.2.2.2 High Level Step 4b – IPTV Service Discovery

This procedure can be performed via the use of HTTP (case 1), or IGMP/multicast (case 2), depending on the “protocol to be used for Service Discovery” info obtained in High Level step 4a (see Figure 6-7).

IPTV Service Discovery – Case 1 – Using HTTP

The IPTV Service Discovery address is obtained in the high level step 4a shown in Figure 6-6.

In the flow shown in Figure 6-8, the OITF receives the address from where it can obtain the Content Guide as well the protocol to be used (via multicast or unicast).

The Service Discovery Record can be delivered to the OITF as XML data (for the metadata client) or a Web Page (for the DAE).

IPTV Service Discovery – Case 2 – Using IGMP multicast

The IPTV Service Discovery multicast address is obtained in the high level step 4a shown in Figure 6-6.

In the flow shown in Figure 6-9, the OITF joins the appropriate address using IGMP to obtain the IPTV service discovery information as XML data (for the metadata client).

6.2.2.2.3 High Level Step 5 – IPTV Service Access - Obtaining the Content Guide

Three possible flows are shown in Figure 6-10:

• Metadata based Content Guide delivered via multicast.
• Metadata based Content Guide delivered via unicast.
• Content Guide delivered via unicast in data formats supported by the DAE (e.g., HTML Web Page).

6.2.2.3 IPTV Service Discovery and Service Access for Residential Networks with an IG and an AG

6.2.2.3.1 High Level Step 4a – IPTV Service Provider Discovery

The call flow in Figure 6-11 is very similar to the IG-only case. The only difference is that the AG intercepts the data, generates a web page and sends its address (URL) to the OITF for retrieval.

The assumptions for this signal flow are that:

• The IG is registered with the SPP.
• The SPP has configured the AG+IG.
• The AG+IG knows the Service-URI of the IPTV Service Provider Discovery FE. This FE’s service-URI as well as the protocol to use to access it may be well known within the SPP domain.

In signals 2-7, the AG+IG obtains a list of IPTV Service Providers available at the SPP and converts this information into a suitable format, among those supported by the DAE. This conversion can be required, for example, to change the look & feel of the page listing the Service Providers.

Note that Service Provider Discovery info can be delivered as XML data (for the metadata client) or data formats supported by the DAE (e.g., HTML web page).

Analogous to the case where only the IG is deployed, it is recommended that a well known Public Service Identifier (PSI) is assigned for the IPTV Service Provider Discovery functional entity. This well known PSI, which is a SIP URI, simplifies the remote configuration of IGs, and allows IMS routing to be fully exploited.

The User Database is configured with the originating filter criteria necessary to route the SIP SUBSCRIBE messages from authorized users to the correct FE. In order to ensure that unauthorized users do not get access to the Service Provider Discovery FE, the PSI is should not be configured in the DNS of the Service Platform Provider.

HTTP can be optionally be used in this signal flow.

6.2.2.3.2 High Level Step 4b – IPTV Service Discovery

This procedure can be performed via the use of the IMS either HTTP, or IGMP/multicast, depending on the “protocol to be used for Service Discovery” information obtained in step 4a of the high level procedures (see Figure 6-7). For the sake of simplicity, no call flows are shown here as the other cases are very similar to those described in section 6.2.2.2.2.

6.2.2.3.3 High Level Step 5 – IPTV Service Access

Figure 6-12 shows XML data for creating the Content Guide (CG) being retrieved using HTTP.

6.2.3 Consolidated service discovery of managed and unmanaged services

For an OITF connected to a managed network, the OITF may present a consolidated view of the services discovered from the managed network, and also whatever is available from the default service discovery mechanisms for unmanaged network based SPs. At this point, if the user is allowed to enter preferences regarding the first screen, this will be seen when the OITF is powered on the next time.

6.3.1 Unmanaged Networks

For unmanaged networks, the solution should use HTTP Digest Authentication [RFC 2617] [Ref-16] in order to identify and authorize users for IPTV service access. The HTTP Digest Authentication scheme improves the HTTP Basic Authentication method by transmitting cryptographic hashes of passwords and other relevant data instead of transferring passwords from clients to servers as clear text. Figure 6-13 depicts the call flow for HTTP Digest Authentication between the relevant functional entities.

The following is a description of the various messages:

6.3.2 Managed Networks

In the managed network case, user identification and authentication is based on either the 3GPP IMS Authentication and Key Agreement (AKA) or on SIP Digest [Ref-18].

User authentication occurs during IMS Registration, which occurs either when:

1. The IG is powered up, or
2. The end user explicitly logs on for personalized services

6.3.2.1 IMS AKA

To support IMS AKA, a UICC with an ISIM or USIM application must be integrated into the IMS Gateway (IG). From the IMS point of view, the IG thereby takes the role of an IMS Subscriber. The UICC stores a long-term secret key K which is shared between the ISIM or USIM application and a User Database belonging to the network operator that provides the ISIM or the USIM. The following figure shows the high-level message flows for user identification and authentication based on the IMS AKA procedure:

The following is a description of the message flows shown in Figure 6-14:

1.	OITF to IG: Registration Request The OITF sends a request for registration to the IMS Gateway (IG), when needed (case b. The end user explicitly logs on for personalized services)
2.	IG to ASM: SIP REGISTER This request contains the domain name of the Service Platform Provider (SPP) network as read from the ISIM (referred to as the Home Network Domain Name in the ISIM), the private and public IMS identities <IMPI> and <IMPU> of the IG, as well as IG's IP address (obtained prior to IMS AKA). Besides the IP address, all these data are read from the ISIM.
3.	ASM to User Database: DIAMETER MULTIMEDIA AUTH REQUEST (MAR) ASM requests authentication data from the User Database with respect to the IMS subscriber (IG) identified by <IMPI>.
4.	User Database to ASM: DIAMETER MULTIMEDIA AUTH ANSWER (MAA) The User Database sends an Authentication Vectors (AV) to the ASM containing the following data: random challenge RAND, answer XRES expected by the IG in step 6, network authentication token AUTN, integrity key IK, and ciphering key CK. The authentication token AUTN contains a message authentication code (MAC) enabling the IG to authenticate the SPP network (see step 5).
5.	ASM to IG: SIP 401 Unauthorized At this point in time, the ASM denies the IG authentication. Instead, it sends a SIP Unauthorized message with a WWW-Authenticate header to the IG. This header contains RAND and AUTN. After reception of this message, the IG verifies the message authentication code contained in AUTN thereby authenticating its SPP network.
6.	IG to ASM: SIP REGISTER ISIM computes the value RES on input of its version of the secret key K stored on the UICC of the IG. The IG sends a new SIP REGISTER request to the ASM, this time with RES as response to the challenge the ASM initiated in step 5.
7.	ASM to IG: SIP 200 OK If RES = XRES (successful case), ASM considers the IG as authenticated, and binds <IMPU> to the IP address <IP address>.
8.	IG to OITF: Registration Response The IG informs the OITF about the result of the registration procedure. (when step 1 is needed) In case of success, the ISIM of the IG is able, based on its knowledge of the secret key K and the authentication token AUTN, to calculate the same values of the integrity key IK and the ciphering key CK as those that the ASM received in step 4 from the User Database. The IG and the ASM use IK and CK to establish IPSec Security Associations for protecting SIP signalling messages over the IG – ASM reference point.

6.3.3 Usage for GBA in the Unmanaged Model

In case where IMS-based authentication capability is supported and available in the home, the GBA Single Sign-on procedure can be used when accessing IPTV Application Servers that trust these IMS-based user credentials for service access. The unmanaged model shall use the same mechanism deployed in the managed model with regard to the usage of GBA. This applies in both the residential network and the SPP network.

6.4.1 Unicast Session Setup (managed model)

Figure 6-15 shows a high level call flow for a unicast session setup based on the above descriptions. The unicast session setup procedure includes the following three call flows:

• Service Session setup.
• Secure Channel setup for the Content Delivery Session (optional).
• Content Delivery and Control.

Each of the above call flows will be described in separate sub-sections.

6.4.1.1 Service Session Setup Description

The Service Session establishment in the managed network model involves the OITF, the IG, the IPTV Control, the CDNC, the “Authentication and Session Management (ASM)” and the “Resource and Admission Control (RAC)” functional entities.

The following is a description of the interactions in the call flow shown in Figure 6-16:

1.	The sequence is triggered by an action from the user. The user requests content from the CoD catalogue, or selects some content stored in an nPVR, which results in a unicast session.
	The OITF acquires all the necessary information about the selected content that allows it to make an SDP offer. The SDP offer must include the IP address and port of the OITF, which is the destination address of the stream for the selected content.
2.	The OITF sends an HTTP session setup request to the IG. The request includes the selected content id and the corresponding SDP offer.
3.	The IG sends a Service session setup request (SIP INVITE) to the ASM in the IMS core network.
	The ASM uses the services of the “Resource and Admission Control” functional entity to perform resource reservation.
4.	The ASM forwards the request to the IPTV Control functional entity.
	The IPTV Control authorizes the request based on the IPTV User Profile. The IPTV Control selects the appropriate CDN Controller. Optionally, the IPTV Control interacts with another functional entity that performs that task.
5.	The IPTV Control forwards the request to the ASM for routing to the selected CDN Controller.
6.	The ASM routes the request to the target Content Delivery Network Controller. The CDN Controller locates the appropriate Cluster Controller that can service the request.
7.	The Content Delivery Network Controller forwards the Service session setup request to the chosen Cluster Controller
	The Cluster Controller analyses the Service session setup request in order to choose the appropriate Content Delivery Function (CDF) based on its status, options and load (e.g. number of outgoing streams). Please refer to Annex C for more information about CDNC/CC/CDF selection.
	The Cluster Controller then sets up the content delivery session (RTSP session) for the requested content, and establishes a binding between the service session and the corresponding content delivery session.
8-11.	The content delivery session identification is returned, through the Service session setup response, back to the ASM.
	The “Authentication and Session Management” FE instructs the “Resource and Admission Control” FE to commit the reserved resources.
12.	The ASM forwards the Service session setup response to the IG
13.	The IG sends an HTTP response to the OITF that includes the content delivery session identifier (RTSP session ID), and all relevant information to allow the OITF and the user to start viewing.

6.4.1.2 Securing Content Delivery Session Signalling (optional)

As shown in the HLA in Figure 5-2, a secure channel can be optionally established between the OITF and the Cluster Controller prior to any exchange of signalling messages. In particular, this allows the Cluster Controller and the OITF to mutually authenticate each other. This is particularly critical in environments where direct communication without such a secure authenticated channel is not desirable because of potential security risks.

Note that the secure channel can be torn down when there is no signalling to be exchanged between the OITF and the Cluster Controller. Thus, the secure channel can be set up on demand.

Figure 6-17 depicts the actual call flow over such a secure tunnel.

The steps in this call flow are as follows.

1.	The OITF establishes a TLS channel with the selected CC to serve the user. Server authentication is performed by the OITF in this step.
2.	The OITF starts streaming control to start viewing the selected content.
	The CC needs to authenticate the OITF before it proxies the message to the CDF.
3.	Once mutual authentication is successfully completed, the CC proxies the start stream control message to the CDF.
4-5.	The successful response from the Content Delivery functional entity is proxied all the way to the OITF.
6.	Following that, the media streaming starts.

6.4.1.3 Content Delivery

After the service and content delivery sessions are setup, as explained in section 6-16, the OITF uses the content delivery session ID to stream and control the content received from the CDF. A logical binding exists between the service session and the content delivery session. The binding is maintained by the CC, as well as the IPTV Control FE.

The steps in this call flow depicted in Figure 6-18 are as follows.

• Stream Control requests generated by the OITF are targeted to the CC. The CC proxies those requests to the appropriate Content Delivery Function.
• The Content Delivery Function streams the media directly to the OITF.

6.4.2 Unicast Session Modification (managed model)

There are a number of use cases that can lead to the need for session modification. Examples include the need to receive a second stream for “picture-in-picture”, or simply to view a second channel in a side-by-side window with the original stream. These features depend on the capabilities of the rendering device. The implication of the above is that there can potentially be a 1:N relationship between a service session and the content delivery session.

Session modification can be initiated from the OITF or from the network side. The subsequent call flows show examples of both cases.

It is also important to note that modifying an existing session to include an additional stream is one option, while creating a new unicast session to carry that additional stream is another. Operator policies as well as client design can play a role here.

6.4.2.1 OITF-initiated session modification call flow

Figure 6-19 shows a typical call flow for the modification of an existing unicast session to add a new stream. Terminal capabilities must support such a feature in the first place.

It is assumed, that a Service Session and its associated Content Delivery Session(s) have been established prior to any modifications.

Below is a brief description of the steps that occur in this process:

1.	The sequence is triggered by an action from the user. The user requests something from the CoD catalogue or selects some content stored in an nPVR. The user can optionally select a new Service Session to be setup for viewing that content or he can reuse an existing Service Session.
	The OITF acquires all the necessary information about the selected content that allows it to make to make an SDP offer. The SDP offer must include the IP address and port of the OITF, which is the destination address of the stream.
2.	The OITF sends an HTTP session modify request to the IG. The request includes the selected content id, the corresponding SDP offer, and the service session id to be used for that session.
3.	The IG sends a Service Modify request (SIP Re-INVITE) to the ASM in the IMS core network.
	The ASM uses the services of the “Resource and Admission Control” functional entity to perform resource reservation.
4.	The ASM forwards the request to the IPTV Control functional entity.
	The IPTV Control FE authorizes the request based on the IPTV User Profile. The IPTV Control FE selects the appropriate CDN controller. Optionally the IPTV Control FE interacts with another functional entity that performs that task.
5.	The IPTV Control FE forwards the request to the ASM for routing to the selected CDN Controller.
6.	The ASM routes the request to the target Content Delivery Network Controller. The CDN Controller locates the appropriate CC that can service the request.
7.	The Content Delivery Network Controller forwards the Service modify request to the chosen Cluster Controller.
	The Cluster Controller analyses the Service modify request in order to choose the appropriate Content Delivery Function based on its status, options and load (e.g. number of outgoing streams). Please refer to Appendix C more information about CDNC/CC/CDF selection.
	The Cluster Controller then sets up the content delivery session (RTSP session) for the requested content, and establishes a binding between the Service Session and the corresponding Content Delivery Session.
8-11.	The Content Delivery Session identification is returned through the Service modify response, back to the ASM.
	The “Authentication and Session Management” instructs the “Resource and Admission Control” to commit the reserved resources.
12.	The ASM forwards the Service modify response to the IG.
13.	The IG sends an HTTP response to the OITF that includes the Content Delivery Session identifier (RTSP session ID), and all relevant information to allow the OITF and the user to start viewing.

6.4.2.2 Server Initiated Unicast Session

Figure 6-20 shows a typical call flow for a new unicast session generated from the network towards a registered user. Below is a brief description of the steps that occur in this process.

The sequence is triggered by an action from a network server. For example, the server may have learnt somehow that a user is registered and decided to send an advertisement to the target user. (Note that the use of an advertising server in Figure 6-20 is purely for use in illustrating a network-initiated session modification, and is not intended to show how advertising will work.)

1.	The advertising server (or any other network server) sends a Service session setup request to the Authentication and Session Management functional entity.
2.	The Authentication and Session Management functional entity, based on the Subscription profile, forwards the request to the IPTV Control for further processing.
3.	The IPTV Control has the option, based on operator policy, to either initiate a completely new session for the user or modify an existing unicast session for that user. The IPTV Control functional entity is always in the signalling path and retains state information for all ongoing unicast sessions. In this example, the IPTV Control functional entity decides to initiate a new unicast session for the target user. Hence, it initiates a Service session setup request to the ASM.
4-5.	The Authentication and Session Management functional entity performs admission control for the new session. This step is optional for the managed model.
6.	The ASM forwards the Service session setup request to the IG.
	The IG performs the necessary RUI procedures to notify the OITF of an incoming session.
7.	The OITF sends an HTTP POST to the IG to indicate its acceptance of the incoming session.
8.	The IG sends a Service session setup response back to the ASM.
9-10.	The ASM commits the reserved resources for the new session. This step is optional for a managed network.
11-13.	The Service session setup response is forwarded all the way to the network server that initiated the session.
14-17.	The network acknowledges the receipt of the response. This gets forwarded all the way to the IG.
18.	The IG sends an HTTP response to the OITF.

6.4.3 Session Teardown (managed model)

Figure 6-21 shows a typical call flow for a unicast session tear down.

It is assumed that a Service Session and one or more associated Content Delivery sessions are ongoing before teardown can occur.

The following is a brief description of the steps that occur in this process:

The sequence is triggered by an action from the user, which results in the OITF requesting the termination of an ongoing unicast session which may or may not have an ongoing live stream.

6.4.4 Unicast Session Management (unmanaged model)

Unicast session management for media streaming in an unmanaged network model differs from the managed network in that no resource management is performed in the network. This means there is no interactive management of the session – a new content delivery session is created for each unicast stream. This requires setup at the ITF and the content delivery function, but not in the network itself.

6.4.4.2 Purchase of content from Service Providers over unmanaged networks

The call flow in Figure 6-22 shows the steps used to purchase service or content from an IPTV Service Provider accessed over an unmanaged network.

The following is a brief description of the steps involved in the process.

1.	Shows the OITF sending a HTTP GET or POST request to the IPTV Application, to acquire an XHTML page which contains the list of content. [Note: Signal 1 could be substituted by the request to the Metadata Control FE for XML based metadata, to be used by the Metadata-based CG client in the OITF for presentation of a Content Guide to the user].
2-3.	Involves the IPTV Application retrieving the IPTV User Profile from the IPTV Service Profile functional entity, to customize the HTML page according to the user’s profile. These steps are optional.
4.	Carries a response back to the OITF including the XHTML page which contains the list of content. [Note: Signal 4 could be substituted by the response carrying XML metadata from the Metadata Control FE, to be used by the Metadata-based CG client on OITF for presentation of a Content Guide to the user].
5.	Shows the OITF sending a HTTP GET or POST request to the IPTV Application, to request the purchase of a specific service or content which the user has selected.
6-7.	Shows the IPTV Application retrieving the IPTV User Profile from the IPTV Service Profile function to process the purchase request based on data in the user’s profile. These steps are optional.
8.	Carries a response back to the OITF including the XHTML page which contains the result of the purchase request. The actual processing of the purchase request is done before this step, but the exact method is not defined (and is specific to the service provider). This page could also include links for the content acquisition, or an automatic redirection to the content acquisition function.

6.4.4.3 Unmanaged content delivery management

The call flow in Figure 6-23 shows the steps used to manage a unicast session in the case of an unmanaged network.

The following is a brief description of the steps involved in a unicast content delivery session.

1.	Shows the OITF sending a setup request to the Cluster Controller, to initiate a content delivery session, using a previously acquired SDP.
	Note: The SDP describing the requested media could be acquired from the content guide or using an RTSP DESCRIBE [Ref-19]. The exact method is left to the detailed protocol specifications.
2-3.	Involves the Cluster Controller and the Content Delivery functions setting up the necessary resources for content delivery.
4.	Carries a response back to the OITF. If the request is successful, a session identifier will be returned by the Cluster Controller. Alternatively, the response may redirect the OITF to another Cluster Controller, for example for load balancing reasons. The exact mechanism for achieving this is left to the detailed protocol specifications. In this case, the OITF would repeat the process from signal 1 to re-issue the request to the specified Cluster Controller.
5.	Requests the Cluster Controller function to start streaming the content to the OITF.
6-7.	Sets up the start the streaming of the content from the Content Delivery function.
8.	Returns the status to the OITF.
9.	Represents the content being streaming from the Content Delivery functional entity to the OITF.
10.	Occurs at some later time, when the OITF no longer wishes to receive the stream.
11-12.	Completes the teardown process and signal 13 returns the result to the OITF.

Note: The detailed specifications shall consider methods to prevent DOS attacks on Cluster Controllers, and to prevent session ID hijacking.

6.6.1 Scheduled Content session set-up

Scheduled content session set-up procedures should be established at ITF power up, after successful authentication and identification and content guide retrieval.

Figure 6-25 shows a call flow for the scheduled content session set-up.

The following is a brief description of the steps in the flow:

Appendix E gives a more detailed description of the Transport Processing Functions and the relation with Resource and Admission Control for an xDSL access network.

6.6.2 Scheduled Content service session teardown procedure

Figure 6-26 shows a typical call flow for tearing down a scheduled content session. The following is a brief description of the steps in the flow. The call flow assumes that a pre-condition for clearing a channel has occurred, such as the ITF being powered off, or the user switching to a CoD service, etc.

6.6.3 A typical call flow for scheduled content service set-up where FCC/RET service is operational (Enhanced managed model)

Figure 6-27 shows a call flow for the scheduled content session set-up where FCC and RET service are deployed.

The following is a brief description of the steps in the flow:

6.7.1 PPV Session Set-up procedure

The following is a description of the interactions in the flow shown in Figure 6-29:

6.8.1 Scheduled Content Time Shift

The call flows below in Figure 6-30 and Figure 6-31 depict the sequence of messages that are exchanged when an end-user, watching a scheduled content item, for which time shift is available, uses trick play modes, which causes a switch to the unicast mode associated with the time-shifted content.

The following is a brief description of the steps in Figure 6-30:

The remaining steps are shown in Figure 6-31.

6.8.2 User-initiated switch from time-shifted to regular Scheduled Content

The call flows in Figure 6-32 and Figure 6-33 depict the sequence that occurs when an end-user watching a time shifted scheduled content item reverts back to the regular (i.e., not time-shifted) scheduled content.

The following is a brief description of the steps:

6.8.3 End of Stream in a Scheduled Content Time Shift

The call flows shown in Figure 6-34 and Figure 6-35 depict the sequence that occurs when an end-user watching a time shifted scheduled content reaches the end of the stream. In this case, the OITF automatically reverts to the regular schedule content service without user intervention.

There are two options for detecting the end of the stream. A CDF may support sending an RTSP ANNOUNCE message reflecting the end of the stream. Optionally, an OITF detecting the starvation of the content buffer over a minimum time of 2 to 3 seconds may treat such an event as the end of the stream. The following is a brief description of the steps:

It is assumed that the user is watching a time shifted scheduled content item.

If the CDF does not support the sending of the RTSP ANNOUNCE message, the OITF can interpret the content buffer starvation as an implicit indication for the end of the stream.

The remaining steps in Figure 6-35 showing the actual switch from time-shifted scheduled content to regular scheduled content are identical to the steps shown in section 6.8.2 and will not be repeated.

6.9.1 Forced Play Out controlled by the OITF (managed model)

The Forced Play Out control can be applied when a user attempts trick play operations while watching either scheduled or CoD content.

Figure 6-36 depicts the sequence of messages that are exchanged to restrict the user’s capabilities for trick play. For example, when a user attempts to fast forward while watching CoD content, the operation is forbidden by the OITF.

Note that the policy can be retrieved through a DAE application, or by other means (e.g., CSP).

The following is a brief description of the steps in the message flow:

Note 1: For Forced Play Out control applied when a user attempts trick play operation while watching scheduled content, the above signalling flow can be applied with the following modifications:

1. The INVITE message will instead be a RE-INVITE or UPDATE message.
2. The resource reservation and commit steps will instead convert the reserved resources from multicast to unicast.

Note 2: Policies sent to the OITF may need to be secured and handled by a trusted entity within the OITF. Under the current OITF definition, this would fall to the CSP functions, and so a CSP-based solution may be desirable.

6.9.2 Forced Play Out controlled by the Cluster Controller (managed model)

The call flow in Figure 6-37 depicts the sequence of messages that are exchanged when a user make trick play operation while watching a scheduled content item with time shift is available or a CoD content item, the fast forward is forbidden by the CC. The following is a brief description of the steps:

The following is a brief description of the steps in the message flow:

Note: For Forced Play Out control applied when a user attempts trick play operation while watching scheduled content, the above signalling flow can be applied with the following modifications:

1. The INVITE message will instead be a RE-INVITE or UPDATE message.
2. The resource reservation and commit steps will instead convert the reserved resources from multicast to unicast.

6.9.3 Integration with OITF functions

In some cases, in addition to controlling which users may access certain content and services, detailed control is required over the play out by a user of a service or content. This is required, for example, when a Service or Content Provider does not want a user to skip over a warning, announcement or advertisement.

As shown in the call flows below, the IPTV Application determines when service/content play-out control must be exercised, and when certain actions are to be disabled. The call flows in this section show how play out control is executed on the OITF. Depending on implementation choices made by the Service/Content Provider, this can be done in different ways.

6.9.3.1 Use of DAE and CSP for enforcement of OITF-enforced playout control

Figure 6-38 illustrates the processes involved when play out control over streamed or progressive download content is implemented at the client-side. In this case, the play out logic, such as stringing together content and advertisements, is under the control of the IPTV Application and executed in the OITF by a downloaded DAE application. Note that the “player” shown in this call flow is the internal media player function within the OITF. It includes the stream receiver, decryption and codecs shown in the model of the OITF from Figure 5-5, and also the internal media player logic of the OITF.

1.	Using the browser, the user chooses an IPTV Application and selects a service or content item, as shown in section 6.2.
2.	Using the browser, the IPTV Application triggers the OITF to acquire rights (and keys) for the service/content.
3.	Using the browser, the IPTV Application triggers the OITF to acquire the content item from the Transport Processing Function and render it. Steps 3a, b, c and d are part of this process
3a.	In the case of protected content, the Player function inside the OITF will need the keys to access the content item. These keys are acquired from the CSP-T or CSP-G function and will not be released unless the user has the rights to access the content.
3b.	During the rendering of the content, the User may (via a DAE application) request the Player to fast-forward or pause the content. These requests are available in the DAE [OIPF_DAE2]. This method can be used for both protected and non-protected content.
3c.	The IPTV application can use the DAE A/V playback API [OIPF_DAE2] to implement the play-out-policy and instruct the native player to override the user requests and enforce normal play-out. These calls may be handled locally by the DAE application or forwarded to the IPTV Application on the server side.
3d.	The Player adapts its content requests accordingly.

6.9.3.2 Use of DAE, CSP and CC for network-enforced playout control

Figure 6-39 illustrates the processes involved when play out control over streamed content is implemented at the server-side.

1.	Using the browser, the user chooses an IPTV Application and selects a service or a content item.
2.	Using the browser, the IPTV Application triggers the OITF to acquire rights (and keys) for the Service/Content.
3.	Using the browser, the IPTV Application triggers the OITF to acquire the content item from the Transport Processing Function and render it. Steps 3a, b, c and d are part of this process
3a.	The Player function inside the OITF will need the keys to access the content item. These keys are acquired from the CSP-T or CSP-G function and will not be released unless the user has the rights to access the content.
3b.	During the rendering of the content item, the User may (via a DAE application) request the Cluster Controller to fast-forward or pause the Content. This method can be used for both protected and non-protected content.
3c.	The Cluster Controller receives play-out control information from the IPTV Application.
3d.	Depending on the Play-out policy, the Cluster Controller will honour the user playout requests and instruct the Transport Processing Function to execute them.

6.10.1 Overview

The PVR is a service that permits the IPTV User with appropriate rights to record content available through this offering.

PVR services can be categorized according the type of storage, the involved roles (service provider controlled, user controlled) and the user and service interaction model. The following definitions apply:

• Local Storage: the recorded content is stored within the consumer domain or ITF (OITF, IG, AG, WG)
• Network Storage: the recorded content is stored in the IPTV service provider domain (Service Provider Network Equipment)
• Immediate Recording: the user decides to record a scheduled content immediately. The scheduled content must be multicast at that moment.
• Scheduled Recording: the user decides ahead of time to record a scheduled content.
• User Controlled recording: no Service Provider intervention or permission is involved to record content, apart from content protection.
• Network controlled recording: the content is recorded under Service Provider control

6.10.2 Local PVR

6.10.2.1 Locally Managed Local PVR recording based on a timer

Figure 6-40 shows the simple case of a scheduled local PVR recording triggered by a timer in the OITF. Note that recording and play back of the recording may be policed by the CSP function in the OITF.

First, the user sets up a scheduled content recording, shown in the upper portion of the figure.

The user selects an item of content from the EPG, and requests that it is recorded.

The OITF sets up an internal timer based on the start time of the content item. Typically, the timer will be set to trigger shortly before the scheduled start time of the content item, in case it starts early. Similarly, the recording will usually be set to finish some time after the scheduled end time of the programme.

Note that advanced functions such as the automatic recording of a complete series, or recording based on a recommendation service, are possible, but are not detailed here. The OITF may also attempt to resolve conflicts at this stage, for example if overlapping recordings are scheduled but the OITF can only make one recording at a time. In any case, the outcome of the set up stage is that one or more timer events are set up within the OITF.

At a later time, the OITF performs the recording, shown in the second part of the figure.

The OITF’s internal timer triggers at the appropriate time.
1.	The OITF performs any procedures that are necessary before broadcast session set up. Which procedures are necessary depends on the state of the OITF at the time of the trigger. If it is powered down, all procedures including network attachment, IG discovery, user registration and IPTV service discovery must be performed. If the OITF is already active and the user to make the recording is signed in, no action is necessary. Note that conflicts may also occur at this stage, for example if the user is already using a service and there is insufficient bandwidth available to receive the additional service to be recorded. Resolution of any conflicts is assumed to be managed by the OITF.
2.	The scheduled content session is set up as described in section 6.6.1.
3.	The OITF uses IGMP to join the multicast delivery channel of the scheduled content service.
4.	The service is received by the OITF via a multicast stream.
5.	The OITF records the received stream to local storage.
At some later time, the internal timer in the OITF triggers again to indicate that the recording should stop.
6.	The OITF stops recording.
7.	The OITF uses IGMP to stop multicast delivery.
8.	The scheduled content session is torn down as described in section 6.6.2.

6.10.2.2 Locally Managed Local PVR Accurate Recording based on In-Band Signalling

Some existing digital and analogue television systems enable accurate recording, meaning that the start and end of the recording are aligned with programme play out, and recordings take place correctly even when a programme is delayed or extended without warning. The call flow below shows how this can be achieved using in band signalling in the form of EIT (Event Information Tables), as defined in ETSI EN 300 468 [Ref-40].

Note that the use of EIT in scheduled content services, and the processing of these tables by the OITF, is optional in the Open IPTV Forum specifications [Ref-45].

Note that recording, and play back of the recording, may be policed by the CSP function in the OITF.

First, the user sets up a scheduled content recording. This is done as in the basic case shown in section 6.10.2.1, except that in addition to setting up the timer, the OITF also stores an identifier for the content. In the case of the EIT-based scheme shown here, the identifier is a combination of the “DVB triplet” of <original network ID, transport stream ID, service ID>, and the event ID – together these form a unique identifier for the programme.

At a later time, the OITF performs the recording.

The OITF’s internal timer triggers at the appropriate time. This should be some time in advance of the expected start time of the programme, in case the programme runs early, or the OITF’s internal clock is not accurate.
1.	The OITF performs any procedures that are necessary before scheduled content session set up. This is as described in section 6.10.2.1.
2.	The scheduled content session is set up as described in section 6.6.1.
3.	The OITF uses IGMP to join the multicast delivery channel of the scheduled content service.
4.	The service is received by the OITF via a multicast stream.
Instead of starting the recording immediately, the OITF instead monitors the EIT contained in the stream. These can be used to signal the moment that a content item actually starts and ends using the “running status” flag. Note that this is dependent on the service or content provider accurately provisioning the EIT.
5.	When the running status flag indicates that the content item of interest is starting, the OITF records the received stream to local storage.
Instead of setting a timer to trigger the end of the recording, the OITF instead continues to monitor the EIT.
6.	When the running status flag indicates the end of the content item, the OITF stops recording.
7.	The OITF uses IGMP to stop multicast delivery.
8.	The scheduled content session is torn down as described in section 6.6.2.

6.10.2.3 Local request for Service Provider controlled Local PVR Recording

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed on Local Storage, under the control of the IPTV Service Provider.

It is also possible to achieve this procedure through a DAE application interacting with an IPTV Application directly, but this is not described in this subsection.

Figure 6-42 shows a call flow for a local PVR recording session.

The following is a brief description of the steps in the flow:

The user, based on information provided by the EPG, orders the recording of an available scheduled content item scheduled for future multicast delivery. Note: Immediate recording is analogous to scheduled recording with the timer set to 0.
1.	The OITF makes a request to the IG to capture the particular Scheduled content item selected by the user. During this step, the OITF gives appropriate parameters to the IG to identify the Request Type as “SetUpRecordingOrder”, the BCService Id, the ProgramId, and relevant timing information as ProgramStartTime, ProgramEndTime, ProgramDuration, etc. The OITF also indicates the TargetUserID. The TargetUserID identifies the User on behalf of whom the request is made. The request shall include also the storage recording mode (local) and if it is a Scheduled Recording (“SR” as used in this example, and not an immediate recording request, “IR”). Note: The Request Type can be of several types: set up a recording order, cancel a recording order, delete a recorded content, edit a recording order, and view a recording order.
2.	The IG transforms the HTTP POST request from step 1 into a SIP MESSAGE request with appropriate parameters defined by step 1, and sends it to the IPTV Control via the ASM in the IMS core network. The IPTV Control receives the request, acting as a Terminating SIP UA.
3.	The IPTV Control queries the IPTV Service Profile FE to retrieve the IPTV Service and User Profiles, to fetch the user related PVR settings.
4.	The IPTV Service Profile FE returns the IPTV User Profile to the IPTV Control.
5.	The IPTV Control verifies that the user is subscribed to the service. The IPTV Control verifies that there is no active Capture Order for the same Program. The IPTV-Control verifies that the user is allowed to set up a Scheduled Recording order in the Local mode. When the local mode is initiated, the IPTV Control verifies the recording capabilities of the target local PVR and its settings (spare limits in time and volume).
6.	Then, the IPTV Control confirms the Capture Request to the IG via the ASM.
7.	The IG transforms the SIP 200 OK into HTTP 200 OK and sends it to OITF.
8.	The IPTV Control sends a SIP MESSAGE to the IG via the ASM with BC Service Id, the Program Id, and relevant timing information as ProgramStartTime, ProgramEndTime, ProgramDuration, etc.
9.	A HTTP 200 OK in sent to the OITF in response to the HTTP Pending IG Request.
10.	A new HTTP Pending IG request is sent by the OITF with a SIP 200 OK response in the HTTP message body. The IG sends the SIP 200 OK, in response to the received SIP MESSAGE, to the IPTV Control via the ASM.
11.	Upon reception of the confirmation response, the IPTV Control updates the IPTV User Profile status for PVR to “Order Captured”, meaning that the order is pending execution.
12.	The IPTV Service Profile FE updates the PVR Status Flag to “Order_Captured” together with related info: Program and BCServiceId.
13.	The OITF starts a counting down timer up to the expected time the program is scheduled to start. At the start time of the scheduled program, the OITF sets up a scheduled content session.
14.	The OITF joins the multicast channel.
15.	The OITF starts recording when it receives the IP flow.
16.	When the program is over, the OITF stops the recording.
17.	When the recording finishes, the OITF leaves the channel and tears down the scheduled content session. Within this tear down process, the OITF reports back to the IPTV Control the result of the recording, together with the “spare_limit_in_volume” and “spare_limit_in_time” values for the specific user (the UserID is also provided).
18.	The IPTV Control updates the metadata records specific for PVR.
19.	The IPTV Control updates the IPTV User Profile PVR Status Flag to “ProgramRecorded”, together related info: Program ID and BCId.
At this point, since the content is stored in the OITF, no further interaction is necessary between the OITF and other network entities to either access or play the recorded content Note that if the OITF is using a DAE application to talk to the IPTV Application, then steps 8 through 9 can be replaced by a HTTP 200 OK sent in response to a HTTP Pending IG request from the OITF.

6.10.2.4 Remote request for Service Provider controlled Local PVR Recording

Remote requests for recording allow an authorized user to perform PVR requests from an OITF different than the one used for recording.

Figure 6-43 shows a call flow for a remote request for a local PVR recording session.

The following is a brief description of the steps in the flow:

The user, based on information provided by the EPG, orders, on OITF 2, the recording of an available scheduled content program scheduled for future multicast delivery.
1.	The OITF makes a request to the IG to capture the particular scheduled content item selected by the user. During this step, the OITF gives appropriate parameters to the IG to identify the Request Type as “SetUpRecordingOrder”, the BCService Id, the ProgramId, and relevant timing information such as ProgramStartTime, ProgramEndTime, ProgramDuration, etc. The OITF also indicates the TargetUserID. The TargetUserID identifies the User on behalf of whom the request is made, in this case User 2. The request shall include also the storage recording mode (local) and if it is a Scheduled Recording (“SR”, as in this example, and not an immediate recording request, “IR”).
2.	The IG transforms the HTTP POST request from step 1 into a SIP MESSAGE with appropriate parameters defined by step 1, and sends it to the IPTV Control via the ASM in the IMS core network. The IPTV Control receives the request, acting as Terminating SIP UA.
3.	The IPTV-Control queries the IPTV Service Profile FE to retrieve the IPTV User Profile of User 2, to obtain the user-related PVR settings.
4.	The IPTV Service Profile FE returns the IPTV User Profile to the IPTV Control.
5.	The IPTV Control verifies that User 2 is subscribed to the service. The IPTV Control verifies that there is no active Capture Order for the same Program. The IPTV Control verifies that the user is allowed to set up a Scheduled Recording order in the Local mode. When the local mode is initiated, the IPTV Control verifies the recording capabilities of the target local PVR and its settings (spare limits in time and volume). The IPTV Control verifies that User 1 can record on behalf of User 2.
6.	Then, the IPTV Control confirms the Capture Request to the IG via the ASM.
7.	The IG transforms the SIP 200 OK into an HTTP 200 OK and sends it to the OITF.
8.	The IPTV Control sends a SIP MESSAGE to the same or another IG via the ASM, with the TargetUserID, BC Service Id, the Program Id, and relevant timing information such as ProgramStartTime, ProgramEndTime, ProgramDuration, etc . This message includes the storage requirements to be checked by OITF 2.
9.	A HTTP 200 OK in sent in response to the HTTP Pending IG request.
10.	A new HTTP Pending IG is sent by OITF 2 with a SIP 200 OK response in the HTTP message body.
11.	The IG sends the SIP 200 OK to the IPTV Control via the ASM
12.	Upon reception of a confirmation response, the IPTV Control updates the IPTV User Profile status of User 2 for PVR to “Order Captured”, meaning that the order is pending execution.
13.	The IPTV Service Profile FE updates PVR Status Flag to “Order_Captured” together with related info: Program and BCServiceId.
14.	OITF 2 starts a counting down timer up to the expected time the program is scheduled to start. At the start of the time of the scheduled program, OITF 2 sets up a scheduled content session.
15.	OITF2 joins the multicast channel.
16.	OITF 2 starts recording when it receives the IP flow.
17.	When the program is over, OITF 2 stops the recording.
18.	When the recording finishes, OITF 2 leaves the channel and tears down the scheduled content session. Within this tear down procedure, OITF 2 reports back to the IPTV Control the result of the recording, together the “spare_limit_in_volume” and “spare_limit_in_time” values for the specific user (the UserID is also provided).
19.	The IPTV Control updates the metadata records specific for the PVR.
20.	The IPTV Service Profile FE updates the PVR Status Flag to “ProgramRecorded”, together with the related info: Program ID and BCId.
Note that if the OITF is using a DAE application to talk to the IPTV Application, then steps 8 through 9 can be replaced by a HTTP 200 OK sent in response to a HTTP Pending IG request from the OITF.

6.10.2.5 Remote request from a non-OITF device for Local PVR Recording (managed model)

Remote request for Local PVR recording allows an authorized user to perform local PVR requests from a non-OITF enabled device using a web browser.

Figure 6-44 shows a call flow for remote local PVR recording session using a web browser.

The following is a brief description of the steps in the flow:

0.	As part of the user’s subscription to the remote L-PVR recording service, the service provider performs a binding between user’s IPTV user identity (IMS IPTV IMPU), and the valid user’s credentials depending of the user’s device. These credentials could be username and password, as utilized by HTTP DIGEST (see section 6.3), or IMSI, as utilized by EAP AKA and SIM AKA when devices support USIM or SIM cards, respectively. The IPTV Application supports an instance of a Web portal for non-OITF enabled devices. As part of the remote L-PVR recording service, and through the non-OITF Web portal in the IPTV Application functional entity, the service provider grants access to the user’s IPTV EPG service according to the user’s IPTV Service Profile. Thus, the user, based on information provided by the EPG, orders the recording on its OITF of an available program scheduled for future multicast delivery.
1.	The device, using a web browser, makes a request to the IPTV Application to capture the particular scheduled content item selected by the user. During this step, the device provides the appropriate parameters to the IPTV Application to identify the Request Type as “SetUpRecordingOrder”, the BCService ID, the ProgramID, and relevant timing information as ProgramStartTime, ProgramEndTime, ProgramDuration, TargetUserID, etc.
2.	A specific functional entity in the Service Provider domain or, optionally, the IPTV Application authenticates the user request based on DIGEST or EAP SIM, or EAP AKA, depending of the type of device used.
3.	A specific functional entity in the Service Provider domain or, optionally, the IPTV Application obtains the user’s IPTV IMS user identity based on the valid identities used on the specific device (user/password, IMSI).
4.	The IPTV Application, on behalf of the IPTV User, requests the IPTV Control to capture the record request. The IPTV Application gives some appropriate parameters to the IPTV Control to identify the request, and, in addition, the IPTV IMS User Id.
5.	The IPTV Control queries the IPTV Service Profile FE to retrieve the IPTV User Profile, to fetch the user related PVR settings.
6.	The IPTV Service Profile FE returns the profile to the IPTV Control.
7.	The IPTV Control verifies that the user is subscribed to the service. The IPTV Control verifies that there is no active Capture Order for the same program. The IPTV Control verifies that the user is allowed to set up a Scheduled Recording order in Local mode. When local mode is initiated, the IPTV Control verifies the recording capabilities of the target local PVR and its settings (spare limits in time and volume). Then, the IPTV Control confirms the Capture Request to the IPTV Application.
8.	The IPTV Application confirms the Capture Request to the user.
9.	The IPTV Application sends the result of the Record Request to the Device.
10.	The IPTV Control sends a SIP MESSAGE to the same or another IG via the ASM with TargetUserID, BC Service Id, the Program Id, and relevant timing information as ProgramStartTime, ProgramEndTime, ProgramDuration, etc. This message includes the storage requirements to be checked by the OITF.
11.	An HTTP 200 OK containing the SIP MESSAGE in the HTTP body is sent to the Target OITF in response to the HTTP Pending IG request.
12.	A new HTTP Pending IG request is sent by the Target OITF with a SIP 200 OK response to the received SIP MESSAGE in the HTTP body. The Target OITF sends a response to the IG, to confirm or reject the record request.
13.	The IG sends the SIP 200 OK with the Record Response to the IPTV Control via the ASM.
14.	Upon reception of a confirmation response, the IPTV Control updates the IPTV User Profile status of User 2 for PVR to “Order Captured”, meaning that the order is pending execution.
15.	The IPTV Service Profile FE updates the PVR Status Flag to “Order_Captured” together with related info: Program and BCServiceId.
16.	The Target OITF starts a counting down timer up to the expected time the program is scheduled to start. At the start of the time of the scheduled program, the Target OITF initiates a scheduled content session.
17.	The Target OITF joins the multicast channel.
18.	The Target OITF starts recording when it receives the IP flow.
19.	When the program is over, the Target OITF stops the recording.
20.	When the recording finishes, the Target OITF leaves the channel and tears down the multicast session. Within this tear down, the Target OITF reports back to the IPTV Control the result of the recording, together the “spare_limit_in_volume” and “spare_limit_in_time” values for the specific user (the UserID is also provided).
21.	The IPTV Control updates the metadata records specific for the PVR.
22.	The IPTV Service Profile FE updates the PVR Status Flag to “ProgramRecorded”, together with the related info: Program ID and BCId.

6.10.3 Network PVR

6.10.3.3 OITF-initiated nPVR Recording – Synchronous Method

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed on Network Storage, under the control of the IPTV Service Provider.

Figure 6-45 shows a call flow for the synchronous method of setting up an nPVR recording session.

The following is a brief description of the steps in the flow:

0.	The user, based on information provided by the EPG, orders the recording of an available Program scheduled for multicast delivery in the future.
Note: Immediate recording is analogous to scheduled recording, with the timer set to 0.
1.	The OITF makes a request to the IG to capture the particular Scheduled Content item selected by the user. During this step, the OITF gives appropriate parameters to the IG to identify the Request Type as “SetUpRecordingOrder”, the BCService Id, the ProgramId, and relevant timing information such as ProgramStartTime, ProgramEndTime, ProgramDuration, etc. The request shall include also the storage recording mode (“network”, in this example) and if it is a Scheduled Recording (“SR”, in this example, and not an immediate recording request, “IR”).
Note: The Request Type can be of several types: set up recording order, cancel a recording order, delete a recorded content, edit a recording order, and view a recording order.
2.	The IG transforms the HTTP POST request from step 1 into a SIP MESSAGE request with appropriate parameters defined by step 1 and sends it to the ASM in the IMS core network.
3.	The IPTV Control receives the request, acting as Terminating SIP UA.
4-5.	The IPTV Control queries the IPTV Service Profile FE to retrieve the IPTV User Profile, to obtain the user related PVR settings.
6.	The IPTV Control verifies that the user is subscribed to the service. The IPTV Control verifies that there is no active Capture Order for the same Program for this user. The IPTV Control verifies that the new item to be recorded does not exceed the user’s storage quota. The IPTV Control verifies that the signalled Storage mode is according the User settings. Optionally, based on Service Provider determined criteria, the IPTV Control could override the PVR Storage mode signalled by the OITF.
7.	The IPTV Control confirms the Capture Request to the OITF via the ASM and the IG, and starts timing management procedures, that would include a timer that counts down to the expected time the program is scheduled to start.
8.	The IPTV Control updates the IPTV User Profile status for PVR to “Order Captured”, meaning that a recording order is pending execution.
9.	The IPTV Service Profile FE updates PVR Status Flag to “Order_Captured”.
10.	The IPTV Control answers back to the user with a 200 OK response.
11.	At the start of the time of the scheduled program (or when the timer to order the recording of a Program on a channel expires), the IPTV Control issues an Order_Record_Request, of type “Start”, to the selected Content Delivery Network Function. The request includes the appropriate parameters such as BCServiceID, Program ID, etc.
Note: Upon reception of more than one request for the same network PVR recording session (BCSeviceID, Program ID), the IPTV Control, based on local policy, may issue only one Order_Record_Request of type “Start”. In this case, the CRID will be updated for each of the requestor’s service profile and metadata.
12.	The CDNC assigns the CC function that will handle the INVITE for nPVR.
13.	The CDN selects a CDF with PVR capabilities.
14.	The CC sends an RTSP ANNOUNCE to deliver relevant transport parameters: IP Multicast for the channel.
15.	The CDF answers back with an RTSP 200 OK.
16.	The set up of the RTSP session is performed and an RTSP Session ID is established.
17.	The CDF joins the Multicast Channel.
18.	The CDF answers back with a RTSP 200 OK.
19.	The CDF sends an order record command against the RTSP Session Id.
20.	The CDF with PVR Recording capabilities starts the recording.
21.	The confirmation of the recording is sent back, including the Content Reference Identifier (CRID) associated with the content being recorded.
22-23.	The message, including the CRID, is sent back to the CDNC and then to the IPTV Control, via the ASM.
24.	The IPTV Control updates the metadata records specific for PVR. One parameter is the new Content Reference Identifier assigned to the new content. A CoD session establishment to start streaming the content could optionally be possible at this point.
25.	The Metadata Control acknowledges with a 200 OK.
26.	The IPTV Control updates the IPTV User Profile in IPTV Service Profile FE.
27.	The PVR Status in the IPTV User Profile is set to “Order_Recording”.
28.	The IPTV Service Profile FE acknowledges with a 200 OK.
29.	When the recording finishes, and before the CDF leaves the channel, the CDF reports back to the IPTV Control the result of the recording (it includes some minimum information like CRID and result code).
30.	The RTSP ANNOUNCE is sent to the CC.
31.	The CC updates the information before sending it to the CDNC in a SIP UPDATE message.
32.	The SIP UPDATE message is progressed to the IPTV Control FE, which uses the Session ID to verify the pending ACK for the recording order.
33.	The IPTV Control acknowledges the UPDATE message.
34-35.	The acknowledgement is sent to the CDNC, and then onto the CC.
36.	The CC sends an acknowledgement of the RTSP ANNOUNCE to the CDF.
37.	The SIP session is terminated.
38.	The SIP BYE is progressed to the CC.
39.	In the CC, the RTSP session is torn down.
40.	The CDF leaves the channel.
41.	The IPTV Control updates the metadata records specific for PVR.
42.	The IPTV User Profile FE updates the PVR Status Flag to “ProgramRecorded” together with the related info: Program ID and BCId.
43.	The PVR Status in the IPTV User Profile is set to: “Order_Recorded”
At this point, in order to play the recorded content, a Content-on-Demand session set-up needs to be initiated by the OITF.

6.10.3.4 OITF-initiated nPVR Recording – Asynchronous method

Based on the EPG, the user decides to set-up the recording of a program (immediate or scheduled). The recording is performed in the CDN, under the control of the IPTV Service Provider.

Figure 6-46 shows a call flow for the asynchronous method of setting up a local nPVR recording session.

The following is a brief description of the steps in the flow:

0.	The user, based on information provided by the EPG, orders the recording of an available Program scheduled for future multicast delivery.
Note: Immediate recording is analogous to scheduled recording, with the timer set to 0.
1.	The OITF makes a request to the IG to capture the particular Scheduled Content item selected by the user. During this step, the OITF provides appropriate parameters to the IG to identify the Request Type as “SetUpRecordingOrder”, the BCService Id, the ProgramId, and relevant timing information such as ProgramStartTime, ProgramEndTime, ProgramDuration, etc. The OITF also indicates the TargetUserID. The TargetUserID identifies the User on behalf of whom the request is initiated. The request shall also include the storage recording mode (“Network”) and if it is a Scheduled Recording (“SR”, and not an immediate recording request, “IR”).
Note: The Request Type can be of several types: set up recording order, cancel a recording order, delete a recorded content, edit a recording order, and view a recording order.
2.	The IG transforms the HTTP POST request from step 1 into a SIP MESSAGE with appropriate parameters defined by step 1 and sends it to the ASM in the IMS core network.
3.	The IPTV Control receives the request, acting as Terminating SIP UA.
4-5.	The IPTV Control queries the IPTV Service Profile FE to retrieve the IPTV Service and User Profiles, and to obtain the user-related PVR settings.
6a.	The IPTV Control verifies that the user is subscribed to the service. The IPTV Control verifies that there is no active Capture Order for the same Program. The IPTV Control verifies that the user is allowed to set up a Scheduled Recording order in the “Network” mode and has enough storage space in the quota allocated to his subscription.
6b.	The IPTV Control creates a context for the order and registers relevant information to keep track of the order status.
Note: Whether the IPTV Control sets a timer at this stage or immediately forwards the recoding order to the CDN with appropriate information is left to the IPTV Solution specifications.
7.	The IPTV Control sends a SIP MESSAGE to the ASM with the BC Service Id, the Program Id, and relevant timing information such as the ProgramStartTime, ProgramEndTime, ProgramDuration, etc.
8.	The SIP MESSAGE is progressed to the CDNC, and then to the appropriate CC.
9-11a.	The CC confirms the recording order with a SIP 200 OK.
11b.	The IPTV Control updates the context of the order and registers the order status information.
12.	Upon reception of confirmation response, the IPTV Control updates the IPTV User Profile status for PVR to “Order Captured”, meaning that the order is pending execution.
13-14.	The IPTV User Profiles updates PVR Status Flag to “Order_Captured” together the related info, Program and BCServiceId, and confirms that update to the IPTV Control.
15-16.	The IPTV Control confirms the Capture Request to the OITF via the ASM and the IG.
The Recording Process between the CC and the CDF is the same as in the synchronous method (see steps 14 to 39 regarding RTSP and IGMP in section 6.10.3.3).
17a-g.	When the recording starts, the CC informs the IPTV Control of that event using a SIP MESSAGE. The IPTV Control acknowledges the message with a 200 OK.
18-23.	When the recording is completed, the CC sends a SIP MESSAGE to the IPTV Control. The IPTV Control acknowledges with a SIP 200 OK, after updating the context of the order and registering the order status information.
24.	The IPTV Control updates the metadata records specific for PVR.
25.	The IPTV User Profile FE updates the PVR Status Flag to “ProgramRecorded” together related info: Program ID and BCId.
26.	When the user profile is updated, a notification is sent to the OITF.

6.11.1 Bookmarking a CoD item

6.11.1.1 IMS-based approach

6.11.1.1.1 Bookmarking Creation and Storage

The call flow in Figure 6-47 depicts the IMS-based sequence for creating a bookmark for a CoD item and storing it in the user’s IPTV service profile for later retrieval.

The following is a brief description of the steps:

1.	The OITF has established a CoD session. At some point in time, the user decides he wants to create a bookmark. If the OITF does not have the current play out position, it sends an RTSP GET-PARAMETER request to the CC, which sends an RTSP GET-PARAMETER request to the CDF to request the current play out position.
2.	The CDF returns the response to the RTSP GET-PARAMETER request in an RTSP 200 OK to the CC, which returns the 200 OK to the OITF.
3.	The OITF issues an HTTP POST request to the IG that includes the SIP INFO message.
4.	The IG sends to the ASM a SIP INFO Message that includes the info-event CoD-Bookmark package as well as the CoD content id.
5.	The ASM proxies the SIP INFO Message to the IPTV Control FE.
6.	The IPTV Control FE issues a Bookmark store request to the IPTV Application handling bookmarks. The request includes the info-event CoD-Bookmark package and the content id
7.	The IPTV Application issues an XCAP request, on behalf of the user, to update the service profile with the CoD-Bookmark data
8.	The IPTV Service Profile returns the response to the IPTV Application.
9.	The IPTV Application returns its own response to the IPTV Control FE.
10.	The IPTV Control FE returns a SIP 200 OK to the ASM.
11.	The ASM proxies the SIP 200 OK to the IG.
12.	The IG returns to the OITF a 200 HTTP OK that includes the SIP response

6.11.1.1.2 Bookmarking retrieval

The call flow in Figure 6-48 depicts the IMS-based sequence for retrieving a CoD bookmark that is stored in the user’s IPTV service profile.

The following is a brief description of the steps:

1.	The OITF issues an XCAP GET request to the IPTV Service Profile to request the bookmark.
2.	The bookmark is returned in an HTTP 200 OK response.

6.11.1.1.3 Content-related Bookmark Retrieval

Content-related retrieval allows a user to retrieve all the bookmarks previously set against the content item the user had chosen for viewing. For example, the user watches a show, and sets bookmarks on some terrific scenes so that they may be reviewed later. Some time later, when the user wants to review the show, the user requests the content for viewing. At the same time, all the bookmarks for that content item are transferred from the network to the OITF, and the user can watch from any of the bookmarked points.

1.	The ITF sends an INVITE to the IPTV Control via the ASM to set up a CoD session. The ASM uses the services of the “Resource and Admission Control” functional entity to perform resource reservation.
2.	The IPTV Control sends an XCAP GET to retrieve the user’s service profile.
3.	The IPTV Service Profile returns 200 OK to the IPTV Control with the user’s service profile, and the IPTV Control FE uses the user’s service profile data to check the service rights for the requested service.
4.	The IPTV Control validates the request, selects the appropriate CDNC for the requested content, and sends the INVITE to the CDNC via the ASM. The CDNC then selects the CC and sends the INVITE to the CC, which selects the CDF and sends the RTSP SETUP to the CDF.
5.	The CDF returns an RTSP 200 OK to CC, which returns a SIP 2OO OK to CDNC, which returns the 200 OK to the IPTV Control via the ASM.
6.	The IPTV Control sends an XCAP GET to retrieve the bookmark list from the IPTV Service Profile, with the user ID and content identifier.
7.	The IPTV Service Profile returns the 200 OK with the bookmark list to the IPTV Control. Each bookmark in the list should contain at least the content ID and the time reference.
Note: The messages in step 6 and 7 may be embedded in the messages for steps 2 and 3.
8.	The IPTV Control returns the 200 OK to the ITF via the ASM, with the Bookmark list. The ASM instructs the “Resource and Admission Control” FE to commit the reserved resources.
9.	The ITF displays the bookmark list to the user, and the user selects the bookmark from which she wishes to start viewing the content.

6.11.1.2 DAE-based approach for bookmarking CoD

6.11.1.2.1 Bookmarking Creation and Storage

The call flow in Figure 6-50 depicts the DAE-based sequence for creating a bookmark for a CoD item and storing it in the user’s IPTV service profile for later retrieval.

The following is a brief description of the steps:

1.	The OITF has established a CoD session. At some point in time the user decides he wants to create a bookmark. If the OITF does not have the current play out position, it sends an RTSP GET-PARAMETER request to the CC, which sends an RTSP GET-PARAMETER request to the CDF to request the current playout position.
2.	The CDF returns the response to the RTSP GET-PARAMETER request in an RTSP 200 OK to the CC, which returns the 200 OK to the OITF.
3.	The OITF issues an HTTP POST to the IPTV Application for storing the Cod-Bookmark. The request includes the content id.
4.	The IPTV Application issues an XCAP request, on behalf of the user, to update the IPTV Service Profile with the CoD Bookmark data.
5.	The IPTV Service Profile returns the response to the IPTV Application.
6.	The IPTV Application returns an HTTP 200 OK response to the OITF.

6.11.1.2.2 Bookmarking Retrieval

The call flow in Figure 6-51 depicts the DAE-based sequence for retrieving a CoD bookmark that is stored in the user’s IPTV service profile. The following is a brief description of the steps:

1.	The OITF issues an HTTP GET request to the IPTV Application to fetch the requested information.
2.	The IPTV Application issues an XCAP GET request to the IPTV Service Profile to request the bookmark information.
3.	The bookmark information is returned in an HTTP 200 OK response.
4.	The IPTV Application returns an HTTP 200 OK that includes the bookmark information.

6.11.2 Bookmarking a Scheduled Content item

6.11.2.1 IMS-based approach

6.11.2.1.1 Bookmarking Creation and Storage

The call flow in Figure 6-52 shows the IMS-based procedure for bookmarking a scheduled content item, and storing the bookmark in the user’s IPTV service profile for later retrieval.

The following is a brief description of the steps:

1.	The OITF has established a scheduled content session. At some point in time, the user decides he wants to create a bookmark. The OITF issues an HTTP POST request to the IG that includes the SIP INFO message.
2.	The IG sends to the ASM a SIP INFO Message that includes the info-event TV-bookmark package. If the bookmark refers to a locally stored content, the request includes the PVR field; otherwise this field is not included.
3.	The ASM proxies the SIP INFO Message to the IPTV Control FE.
4.	The IPTV Control FE issues a bookmark request to the IPTV Application handling bookmarks. The request includes the TV-Bookmark and the PVR field (if included in the request).
5.	If the PVR field is absent, the IPTV application verifies that the selected scheduled content is available for bookmarking. This verification is bypassed if the PVR field is present.
6.	The IPTV Application issues an XCAP request, on behalf of the user, to update the IPTV Service Profile with the TV-Bookmark data, if a bookmark is available for storage
7.	The IPTV Service Profile returns the response to the IPTV application.
8.	The IPTV Application returns its own response to the IPTV Control FE.
9.	The IPTV Control FE returns a SIP 200 OK to the ASM.
10.	The ASM proxies the SIP 200 OK to the IG.
11.	The IG returns an HTTP 200 OK that includes the SIP response.

6.11.2.3 DAE approach

6.11.2.3.1 Bookmarking Creation and Storage

The call flow in Figure 6-53 shows the sequence for creating a DAE-based bookmark for Scheduled Content and storing it in the user’s IPTV service profile for later retrieval.

The following is a brief description of the steps:

1.	The OITF has established a scheduled content session. At some point in time, the user decides he wants to create a bookmark. The OITF issues an HTTP POST to the IPTV Application for storing the TV-Bookmark. If the bookmark refers to a locally stored content, the request includes the PVR field; otherwise this field is not included.
2.	If the PVR field is absent, the IPTV application verifies that selected Scheduled Content item is available for bookmarking. This verification is bypassed if the PVR field is present.
3.	The IPTV application issues an XCAP request, on behalf of the user, to update the IPTV Service Profile with the TV-Bookmark data if a bookmark is available for storage
4.	The IPTV Service Profile returns the response to the IPTV application.
5.	The IPTV Application returns an HTTP 200 OK to the OITF

6.11.2.3.2 Bookmarking Retrieval

This procedure is identical to that in section 6.11.1.2.2.

6.11.2.4 Network initiated Bookmarking (managed model)

This procedure is performed when, for example, the IPTV Control FE needs to acquire the offset for the purpose of session transfer or session replication (see section 6.17.3.2). Note that other applications may need this procedure as well.

Figure 6-54 shows how the OITF can use the IMS network to return the requested information.

The following is a brief description of the steps in the call flow:

1.	The IPTV Control FE sends a SIP INFO message to the IG (via the ASM which is not shown for simplicity) requesting the OITF to send to it the missing information.
2.	The IG sends an HTTP 200 OK response to the OITF that includes the SIP INFO.
3.	The OITF issues to the IG an HTTP POST that includes the SIP 200 OK response with the requested data.
4.	The IG returns a SIP 200 OK response to the IPTV Control FE. The IPTV Control FE may scale back a bit the returned position to cater for some time lost.
5.	The IPTV Control FE then issues a Bookmark request to the IPTV Application responsible for bookmarks.
6.	The IPTV Application issues an XCAP PUT request to the IPTV Service Profile.
7.	The IPTV Service Profile returns a 200 OK to the IPTV Application.
8.	The IPTV Application returns a response to the IPTV Control.

Note that steps 5 to 8 are needed in case the OITF did not receive the bookmark during the session initiation procedure and has to retrieve it.

6.12.1 What is on the TV?

“What is on the TV” is a feature that allows users with proper authorization to be informed of the content being watched at an OITF. The description below shows how the OITF reports to the network the content that is being watched.

There are several modes for this feature, all of which are under the control of service provider, and which are negotiated during the scheduled content session setup, and thereafter. Changes to any of the negotiated modes can occur at any point in time during the lifetime of a scheduled content session using normal session modification procedures. The various modes for the feature shall be aligned with the IETF RFC [Ref-47]. The modes of operation are:

• The OITF can be ordered to report at all times the content being displayed after channel zapping
• An OITF that continuously reports the content that is being displayed after channel zapping can be ordered to stop such reporting at any time.
• An OITF that is ordered to stop reporting the content being displayed can be ordered to resume reporting immediately and until such time when it is ordered to stop reporting

All of the above modes are under the control of the service provider.

6.12.1.1 Negotiated content reporting at session initialization

The call flow in Figure 6-55 depicts the normal sequence that occurs when a scheduled content session setup is augmented with the support for this feature, in which the OITF is ordered to report the content currently being displayed.

The following is a brief description of the steps:

1.	The OITF sends an HTTP POST request to the IG to set up the scheduled content session. The OITF and IPTV Control FE must support the info-event package for content reporting.
2.	The IG sends a SIP INVITE to the ASM. The INVITE includes the headers received by the IG.
3.	The ASM performs initial resource reservation with the RAC.
4.	Following that, the ASM proxies the INVITE to the IPTV Control FE.
5.	The IPTV Control FE validates the INVITE per the normal procedure associated with the scheduled content. The IPTV Control FE then returns a 200 OK to the ASM. The 200 OK must include the rec-info header. If the IPTV Control FE does not want any reporting by the OITF it shall set the value of rec-info to that effect. If the IPTV Control FE wants the OITF to report content information, it shall set the value of rec-info to that effect. In this call sequence, the value is set such that the OITF is ordered to report the content. The 200 OK may include the send-info header.
6.	The ASM performs final resource modification with the RAC.
7.	The ASM proxies the 200 OK to the IG.
8.	The IG sends an HTTP 200 OK to the OITF.
9-10.	The IG sends an ACK to the ASM, which proxies it to the IPTV Control FE.
11.	The OITF issues an IGMP JOIN to the access node to view the selected content item.
12.	The OITF issues an HTTP POST to the IG to report the content being watched.
13.	The IG sends a SIP INFO message to the ASM. The SIP INFO includes the info-event for content reporting.
14.	The ASM proxies the SIP INFO to the IPTV Control FE.
15.	The IPTV Control FE responds to the ASM with a 200 OK.
16.	The ASM proxies the 200 OK to the IG.
17.	The IG sends an HTTP 200 OK to the OITF.
18.	The OITF performs channel zapping.
19.	Following channel zapping, it is assumed that the OITF remains tuned to a scheduled content item for a minimum configurable time.
20.	After that time has elapsed, the OITF issues an HTTP POST to the IG to report the content being displayed.
The remaining steps are identical to the previous reporting and will not be described again.

6.12.1.2 Mid-Session negotiation for content reporting

The call flow in Figure 6-56 depicts the sequence that occurs in mid-session when a service provider orders an OITF to stop or resume content reporting depending on the OITF mode. There are no limits on how frequently such an order can be sent. The triggers for such an order can be many. Examples include a service request from an authorized member in the household for the information when it is not available, manual intervention by the service provider, etc.

The following is a brief description of the steps:

1.	It is assumed that the OITF is displaying content, and the OITF is reporting the content being displayed. The OITF sends an HTTP PENDING request so that it can receive any information destined to it.
2.	At some point in time, a trigger requests the IPTV Control FE to order the OITF to stop reporting the watched content. The IPTV Control FE sends a SIP UPDATE to the ASM. The UPDATE includes the rec-info header set to indicate “no content reporting”.
3.	The ASM proxies the SIP UPDATE to the IG.
4.	The IG sends an HTTP 200 OK to the OITF to report the request.
5.	The OITF sends an HTTP PENDING request to the IG.
6.	The IG sends back a 200 OK to the ASM in response to the SIP UPDATE.
7.	The ASM proxies the 200 OK to the IPTV Control FE.
8.	Later, the user performs channel zapping, and the OITF displays a new content item.
9.	Channel zapping is stopped for the minimum configurable time but the content displayed is not reported.
At some later point in time, the IPTV Control FE receives a new trigger to order the OITF to report the displayed content.
10-15.	The OITF issues an HTTP POST to the IG to report the content being displayed. Steps 10-15 are identical to steps 2-7.
Immediately upon receipt of the new order, the OITF reports the content being watched in steps 16-21, which are identical to steps 20-25 described in section 6-55.

6.12.1.3 Publishing and Subscribing to Content being watched by an OITF

There are two means by which content being streamed to an OITF can be published:

• The end user can have an application on the OITF that can publish to a Presence server what the user is currently watching. This is under user control.
• The IPTV Control FE can perform the same task. It is aware of the content being streamed and can publish the data to a Presence server on behalf of the user. This is under the control of the service provider.

Clearly, the information in the Presence server can be updated by either approach simultaneously.

End users with appropriate authorization can subscribe to receive this information. The service provider performs the necessary verification to ensure that only authorized users can have access to this information. The service provider also guarantees that the information is accurate. This feature is essential for parental control purposes.

6.12.1.3.1 Publishing watched content at an OITF by the Service Provider

The call flow in Figure 6-57 depicts the sequence for publishing watched content, by the service provider.

The following is a brief description of the steps:

1.	The IPTV Control FE has information related to content being watched by a user at OITF1, and sends a SIP PUBLISH to the ASM on behalf of the user.
2.	The ASM forwards the PUBLISH to the Presence server.
3-4.	The Presence server returns a 200 OK to the ASM, which forwards it to the IPTV Control FE.

6.12.1.3.2 Publishing watched content at an OITF by the End User

The call flow in Figure 6-58 shows the sequence of messages for publishing watched content by the end user.

The following is a brief description of the steps:

1.	The OITF issues an HTTP POST to the IG. The request includes the SIP PUBLISH.
2.	The IG forwards a SIP PUBLISH to the ASM.
3.	The ASM forwards the SIP PUBLISH to the IPTV Control FE or directly to the Presence server.
4.	The IPTV Control FE forwards the SIP PUBLISH to the Presence server via the ASM.
5.	The Presence server responds with a SIP 200 OK to the IPTV Control FE via the ASM.
6-7.	The IPTV Control FE forwards the SIP 200 OK to the ASM, which forwards it to the IG.
8.	The IG sends an HTTP 200 OK, which includes the SIP 200 OK, to the OITF.

6.12.1.3.3 Subscribing to receive information on content watched at an OITF

The call flow in Figure 6-59 shows the sequence of messages for subscribing to receive information on content streamed at an OITF.

The following is a brief description of the steps:

1.	The OITF issues an HTTP POST to the IG. The request includes the SIP SUBSCRIBE.
2.	The IG forwards the SIP SUBSCRIBE to the ASM.
3.	The ASM forwards the SIP SUBSCRIBE to the IPTV Control FE. Before the IPTV Control FE forwards the SUBSCRIBE message to the Presence server, it can perform the following optional step: The IPTV Control FE can pull the latest watched channel information from the OITF and publish it. It does so if it believes that the information has changed since the last time it was published. The IPTV Control FE can also choose to temporarily request that the OITF retry subscribing later while the IPTV Control performs that task.
4.	The IPTV Control FE forwards the SIP SUBSCRIBE to the Presence server via the ASM
5-7.	The Presence server responds with a SIP 200 OK to the IPTV Control FE via the ASM, which, in turn, forwards the 200 OK to the IG via the ASM.
8.	The IG sends an HTTP 200 OK that includes the SIP 200 OK to the OITF.
9.	The OITF sends an HTTP POST pending request in anticipation of the reception of a NOTIFY.
10.	The Presence server sends a NOTIFY including the required information to the IPTV Control FE via the ASM.
11-12.	The IPTV Control FE forwards the NOITFY to the ASM, which forwards it to the IG.
13.	The IG sends an HTTP 200 OK that includes the SIP NOITFY to the OITF
14.	The OITF issues an HTTP POST that includes the SIP 200 OK response to the IG.
15-16.	The IG forwards the 200 OK to the ASM, which passes it on to the IPTV Control FE.
17.	The IPTV Control FE forwards the 200 OK to the Presence server.

6.12.2 Parental Authorization for CoD

An example of parental control within the context of CoD services, and using communication services, refers to the ability of the IPTV solution to seek, in real-time, parental authorization when an end user engages with the IPTV system for CoD selection and if the IPTV User Profile of that end user indicates such a need.

Section 6.12.2.1 provides an example for a call flow to illustrate the roles played by different entities involved in parental control within the context of a CoD service.

6.12.2.1 Browser-Based Portal CoD Application

This use case is about an end user engaging with the IPTV system for the purpose of selecting a CoD and for whom parental control has been activated in the IPTV Service Profile FE.

The call flow for this use case is shown in Figure 6-60. The following is a brief description of the steps:

1.	The end user, through the GUI and the OITF, browses the CoD application and makes his choice regarding a CoD.
The CoD application verifies with the IPTV Service Profile FE if parental authorization is required, and determines that it is needed in this case.
2.	The CoD application returns an HTTP response to the OITF to inform the user that parental authorization is currently being sought, before the selected content can be made available for viewing.
3.	The CoD application sends a request to the IPTV Control FE to request parental authorization for the subject end-user. The CoD application includes all information needed in that regard.
The IPTV Control FE can use various means to obtain the required authorization. For example, IMS communication services, such as SIP messaging, or SMS can be used to obtain such an authorization. Other means can also be envisaged such as e-mail.
4.	Once the CoD application receives such an authorization, it can send a SIP MESSAGE to the end-user to indicate that parental authorization is granted.
Following that, a normal unicast CoD session is established for the desired content.

6.12.3 Parental Control for Scheduled Content (managed model)

This section describes, at a high-level, the procedure for parental control of scheduled content by which a parent can remotely turn off access to a scheduled content program. It can be used, for example, when a parent (away from home, say) becomes aware that there might be violent pictures from a major accident shown in the news. The parent checks what the children are watching on TV, and, if it is that news program, can temporarily block access to that content.

Figure 6-61 shows a high-level procedure for allowing a parent to temporarily block access to a scheduled content item.

The following is a description of the interactions in the flow:

6.12.3.1 Detailed Signal Flow for Parental Control of Scheduled Content

Figure 6-62 shows a detailed signal flow for the procedures that allow a parent to temporarily block access to scheduled content.

The following is a description of the interactions between the entities:

1.	A parent retrieves information on the program watched by the child. The method for doing this is described in section 6.12.1.
2.	The parent initiates a request to block access to the program temporarily. This is done by ITF2 sending a SIP MESSAGE to the IPTV Control. The MESSAGE carries some parameters including the following: the command for the type of Parental Control requested, e.g., channel change, session termination, etc. the parent identity. the child identity.
3.	The SIP MESSAGE is routed to the IPTV control via the ASM.
4.	The IPTV Control validates the message, and sends a SIP MESSAGE, including parameters such as the command for the type of Parental Control requested, the parent identity, etc., to ITF1 to block the content. In the example flow shown, the command for the type of parental control requested is to change the channel. (Other types of parental control, such as session teardown, are also possible, but not shown.).
5.	The MESSAGE is routed to ITF1 via the ASM.
6-7.	In the example shown, the parent’s request is to change the channel. ITF1 sends an IGMP Leave to leave the channel and a subsequent IGMP Join to join the new channel.
8-11.	The ITF1 responds with a 200 OK, which is routed back via the ASM to ITF2.
Note: Any subsequent steps are left to the service provider.

6.13.1 IPTV User Profile Retrieval - Unmanaged Model

This use case includes an end user fetching his IPTV User Profile, updating it and then uploading it. The call flow for this use case is shown in Figure 6-63.

The following is a brief description of the steps:

6.14.1 Terminal-centric Content and Service Protection

In the terminal-centric approach, the CSP function in the OITF and the CSP-T Server functional entity on the Provider Network exchange messages related to service and content protection over the UNIS-CSP-T reference point.

6.14.2 Gateway-centric Content and Service Protection

In the gateway-centric approach, the CSP Gateway (CSPG) functional entity inside the Residential Network and the CSP-G Server functional entity on the Provider Network exchange messages related to service and content protection over the UNIS-CSP-G reference point. The HNI-CSP reference point between CSPG and OITF(s) allows the OITF to access CSPG functions for the conversion from a content and service protection scheme to a secure authentication channel between the CSPG and the OITF. The HNI AGC reference point provides the connection between the CSPG and the Application Gateway (AG).

The CSPG and OITF functional entities are can be implemented in the same device. In this case the CA/DRM system used for content delivery will be terminated directly at the terminal device. Also, the OITF-CSPG communication is a device-internal interface that does not need to conform to the HNI-CSP interface. This is conceptually equivalent to the implementation of any chosen CAS or DRM solution in the device hosting the OITF.

6.14.3 Resource Access Entitlement

Users register with an IPTV Service Provider for subscription to an IPTV Service or to request content rental. Therefore, content and service protection servers (CSP-T and CSP-G Server) need to check with the IPTV Service Provider or against data provided beforehand by the IPTV Service Provider whether a given (set of) OITF(s) or CSP Gateway(s) is (are) entitled to get access to such resources. Content and service protection servers need to do so before they can supply OITFs and CGs with the corresponding resource access data (e.g., licenses, service encryption keys, content encryption keys).

The aforementioned data that the IPTV Service Provider sends to the content and service protection server so that it is able to decide whether or not to supply a (set of) OITF(s) or CG(s) with resource access data is referred to as entitlement information. For example, entitlement information may consist of an identifier for a User, an identifier of an IPTV service, a validity period, and an item such as “grant” or “deny”.

In the high-level architecture (see Figure 5-2), the IPTV Service Profile and/or the IPTV Applications functional entities are responsible for sending entitlement information to the content and service protection servers. In the terminal-centric approach, entitlement information is transferred to the CSP-T Server over the reference point NPI-CSPT1 and/or NPI CSPT1a. In the gateway-centric approach, entitlement information is transferred to the proprietary CSP-G Server over the reference point NPI-CSG1 and/or NPI-CSPG1a. The CSP specification defines which functional entity (IPTV Service Profile or IPTV Applications) is actually responsible for supplying content and service protection servers with entitlement information.

There are two different models of how the transfer of entitlement information from the IPTV Service Provider to the content and service protection server is initiated: in the push model, the IPTV Service Provider sends entitlement information to the content and service protection server without being requested by the latter, while in the pull model, the content and service protection server asks the IPTV Service Provider for entitlement information. The following sub-sections show message flows for both models, both for the terminal-centric and the gateway-centric approaches.

6.14.3.1 Terminal-Centric Approach

6.14.3.1.1 Pull Model

Figure 6-64 shows a high-level message flow for the pull of entitlement information in the terminal-centric approach.

A brief description of the steps is as follows:

1.	The User subscribes to an IPTV service or rents a content item.
2.	The IPTV Service Provider (IPTV Service Profile / IPTV Applications) stores the result and related data for the subscription or rental transaction executed in step 1.
3.	The OITF sends a license acquisition request to the CSP-T Server.
4.	To process the request received in step 3, the CSP-T Server asks the IPTV Service Provider for entitlement information, i.e., it pulls the entitlement information from the IPTV Service Provider.
5.	The IPTV Service Provider supplies the CSP-T Server with the requested entitlement information.
6.	In accordance to the entitlement information received in step 5, the CSP-T Server sends a license response message to the OITF.

6.14.3.1.2 Push Model

The CSP specification [OIPF_CSP2] describes the push of entitlement information in the terminal-centric approach.

6.14.3.2 Gateway-Centric Approach

6.14.3.2.1 Push Model

Figure 6-65 shows a high-level message flow for the push of entitlement information in the gateway-centric approach.

A brief description of the steps is as follows:

1.	The User subscribes to an IPTV service or rents a content item.
2.	The IPTV Service Provider (IPTV Service Profile / IPTV Applications) stores the result and related data for the subscription or rental transaction executed in step 1.
3.	The IPTV Service Provider sends entitlement information (e.g., that OITF X has successfully subscribed to a particular IPTV service) to the CSP G Server, i.e., it pushes the entitlement information to the CSP-G Server.
4.	The OITF requests access to a protected resource. In the CSPG-CI+ case, this request takes place within the OITF. In the CSPG-DTCP case, this request is submitted to the CSPG.
5.	Based on the entitlement information received by CSP G Server the proprietary solution made of CSPG and CSP-G Server functional entities decides on whether to grant or deny the request initiated by the OITF in step 4. The details of this step are out of scope of OIPF specifications.

6.14.3.2.2 Pull Model

The CSP specification [OIPF_CSP2] describes the pull of entitlement information in the gateway-centric approach.

6.15.1 User Notification Service Framework

User notification allows a user to request a notification be sent to him for specific events, such as a broadcast reminder for the start of a scheduled content. This section defines the necessary framework to support this feature. The framework can be applied against any event. The actual events themselves are outside the scope of this specification.

The notification sent to a user can be in the form of a text message on a mobile phone, an email, or an IMS instant message.

The user configures the preferred method for delivering a notification to him, as well as the information required for the selected delivery method.

The list of services available with user notification is:

• Setting a notification service request
• Deleting a pending notification service request.
• Requesting a list of all pending notification service requests.
• Modifying a pending notification service request, which is a combination of a delete operation and setting up a new request.

Two procedures shall be defined for user notification services, an IMS procedure and a DAE procedure.

It is important to note that user notification service is independent from instant messaging service, even though both use the same underlying SIP MESSAGE. Hence, the user notification service is not tied to a user’s subscription to the instant messaging application, and/or the activation of the instant messaging application by the end user in case of subscription.

6.15.1.1 IMS procedure for User Notification Services

6.15.1.1.1 Setting up a Notification Service request

The call flow in Figure 6-66 depicts the sequence for setting up a notification service request.

The following is a brief description of the steps:

1.	Upon user triggering, the OITF issues an HTTP POST to the IG that includes a SIP MESSAGE requesting the setting up of a notification service for a selected event
2.	The IG sends a SIP MESSAGE to the ASM
3.	The ASM forwards the SIP MESSAGE to the IPTV Control FE.
4.	The IPTV Control FE performs user authorization, then forwards the request to the IPTV Application responsible for handling the request.
5.	If needed, the IPTV Application validates the content of the request with the IPTV Metadata Control
6.	The IPTV Metadata Control returns the response to the IPTV Application.
7.	The IPTV Application then forwards the response back to the IPTV Control FE. For a successful request, the IPTV Application includes a notification request identity that is carried all the way to the OITF. The notification request identity shall be carried in all subsequent operations that want to reference the request.
8.	The IPTV Control FE generates a SIP 200 OK response (that includes the notification request identity) or any other appropriate response back to the ASM
9.	The ASM forwards the response to the IG
10.	The IG sends an HTTP 200 OK to the OITF that includes the SIP response to the SIP MESSAGE

6.15.1.1.2 Deletion of a Pending Notification Service request

The call flow in Figure 6-67 depicts the sequence for deleting a pending notification service request.

The following is a brief description of the steps:

1.	Upon user triggering, the OITF issues an HTTP POST to the IG that includes a SIP MESSAGE requesting the deletion of a pending notification service request
2.	The IG sends a SIP MESSAGE to the ASM. The SIP MESSAGE includes the identity of the notification service request to be deleted.
3.	The ASM forwards the SIP MESSAGE to the IPTV Control FE.
4.	The IPTV Control FE performs user authorization, then forwards the request to the IPTV Application responsible for handling the request
5.	The IPTV Application deletes the pending notification service request, then forwards the response back to the IPTV Control FE
6.	The IPTV Control FE returns a SIP 200 OK response to the ASM
7.	The ASM forwards the response to the IG
8.	The IG sends an HTTP 200 OK to the OITF that includes the SIP 200 OK response.

6.15.1.2 DAE procedure for User Notification Services

The call flow in Figure 6-68 depicts the generic sequence for all DAE-based operations for the user notification services.

The following is a brief description of the steps in the call flow

1.	Due to user triggering, the OITF issues an HTTP POST to the IPTV Application. The request includes all the necessary information pertinent to the requested operation.
2.	If applicable, the IPTV Application validates the content of the request with the IPTV Metadata Control
3.	The IPTV Metadata Control returns the response to the IPTV Application.
4.	The IPTV Application then forwards the response back to the OITF in an HTTP 200 OK. If the requested operation is for setting up a notification service request, the response includes a notification request identity.

6.15.1.3 Generation and Delivery of Notifications

Requested notifications to be delivered to an end user can occur via a text message to a mobile, an IMS instant message, or an email.

The following section depicts some examples for generating and delivering notifications

6.15.1.3.1 Notification to an OITF using IMS IM

The call flow in Figure 6-69 depicts the sequence for delivering a text notification to an OITF using IMS instant messaging.

The following is a brief description of the steps in the call flow:

1.	When the IPTV Application is ready to deliver a notification to an end user, it generates an HTTP request to the Notification Services functional entity. The HTTP request includes the requested notification.
2.	The Notification Services functional entity generates a SIP MESSAGE for the intended user and delivers it to the IMS AS.
3.	The IMS AS sends a SIP MESSAGE to the ASM
4.	The ASM delivers the SIP MESSAGE to the IG
5a.	The IG returns an HTTP 200 OK response to the OITF that includes the SIP MESSAGE. (It is assumed that the OITF had an HTTP pending request).
5b.	The OITF generates an HTTP POST message that includes the SIP 200 OK response to the received SIP MESSAGE.
6.	The IG forwards the SIP 200 OK to the ASM.
7-8.	The ASM forwards the SIP 200 OK to the Notification Services functional entity.
9.	The Notification Services functional entity returns an HTTP 200 OK response to the IPTV Application. The HTTP 200 OK response includes the SIP response to the SIP MESSAGE.

6.15.1.3.2 Notification to a mobile phone

The call flow in Figure 6 70 depicts the sequence for delivering a text (i.e., SMS) notification to a mobile phone. The following is a brief description of the steps in the call flow

1.	When the IPTV Application is ready to deliver a notification to an end user, it generates an HTTP message that includes the desired notification to the Notification Services functional entity.
2.	The Notification Services functional entity generates a text message, based on short message peer-to-peer (SMPP) protocol [Ref-41], to the user mobile. The message goes to the Other Delivery Network entity (e.g., SMS centre) associated with the end-user.
3.	The Other Delivery Network entity (e.g., SMS centre) delivers the message to the user’s mobile.
4.	The Notification Services functional entity returns an HTTP 200 OK response to the IPTV Application.
Note that the notification may in certain cases require the mobile cellular device to make a selection based on the incoming notification and return its selection, via an SMS, to the IPTV Application.

6.15.2 Emergency notification

Emergency notification is a type of notification about critical events, which the network initiates and sends to the OITF. Emergency notifications are discovered and obtained without user intervention.

Figure 6-71 shows the call flow for retrieving emergency notification.

The following is a brief description of the steps in the flow:

6.15.3 Network Generated Notifications associated with a Scheduled Content Service

Network generated notifications can be provided by the network to the user about events related to a scheduled content service, i.e. the notification service should only be consumed together with the related scheduled content service. To allow the independent purchase of such notifications, the notification service is described as a separate service from the related scheduled content. In this case, an extension to the scheduled content service mechanism, through the inclusion of a “Network Generated Notification” indicator, is used to identify such a notification service.

A network-generated notification message is a multimedia message consisting of text, picture and/or audio-video clips. Multicast delivery is used for delivering such network-generated notifications to multiple users at the same time.

To access to the scheduled content as well as the related notification service in one procedure, the scheduled content session initialization procedure defined in section 6.6.1 is extended, as shown in Figure 6-72.

The following is a brief description of the steps:

6.16.1 OITF-centric Personalised Channel

The following is a brief description of the steps:

6.16.2 Network-centric Personalised Channel (PCh)

Figure 6-74 shows a high level procedure for a network-centric Personalised Channel service. The procedure includes the following three sub-procedures:

Network-centric PCh Configuration procedure: The user configures the PCh as described in section 6.16.2.1.

Network-centric PCh Service set-up procedure: The user initiates the PCh service session when he/she wants to watch the Personalised Channel. The detailed procedure is described in section 6.16.2.2 or in section 6.16.2.3 based on the deployment chosen.

Network-centric PCh Service teardown procedure: The PCh service teardown procedure may be triggered by the user’s action, at the end of the PCh service or when it is needed. The procedure in section 6.4.3 or 6.6.2 shall be reused.

6.16.2.1 Network-centric PCh Configuration

Figure 6-75 below depicts the call flow for configuration of the Personalised Channel, where the IPTV Application generates, at the user’s request, the personalised content guide based on the user profile and content metadata.

The user can update the personalised content guide with his preferences as well.

The following is a brief description of the steps:

1.	The ITF sends an HTTP GET, with the user id, to the IPTV Application to request the configuration of the PCh.
2.	The IPTV Application sends an XCAP GET to the IPTV Service Profile with the user id, which responds with a 200 OK including the user’s IPTV service profile.
3.	The IPTV Application checks the user’s rights for the PCh service, and interacts with the IPTV Metadata Control to generate a personalised content guide based on user preference, etc., and creates related information, e.g. PCh id.
4.	The IPTV Application sends a 200 OK to the ITF with the PCh content guide containing related information e.g., PCh id, selected content IDs and related time schedule.
5.	The ITF sends an HTTP POST to the IPTV Application to update the PCh content guide. The IPTV Application may store the PCh information in the IPTV Service Profile.
6.	The IPTV Application sends HTTP 200 OK back to the ITF
7.	If supported by the OITF, the DAE may be used to set up any necessary local PVR.

6.16.2.2 Network-centric procedure for PCh service set-up (multicast/unicast)

Figure 6-76 shows the high-level call flows for PCh service setup.

The following is a brief description of the steps:

1.	The user selects the PCh channel from the content guide.
2a-b.	Depending on the content guide information, the ITF requests the related PCh service, and establishes either a scheduled content session (Step 2a) or a CoD session (Step 2b). Shortly before it is time for the next item in the PCh playlist to be streamed, as indicated by the PCh information, several alternatives are possible depending on the type of content item that is being streamed and what is next: If the item being streamed is scheduled content and the next item in the PCh playlist is also a scheduled content item, and if the IPTV Application has determined that there is no overlapping in time between these content items, the IPTV Application modifies the existing scheduled content session (if appropriate) for the new content item; If the item being streamed is scheduled content and the next item in the PCh playlist is also a scheduled content item, and if there is an overlapping in time with the previous item, step 3 onwards is followed. If the item being streamed is a scheduled content item, and the next item in the PCh schedule is a CoD item, and if there is no overlapping in time, then the scheduled content session is torn down after its completion and a new session is created for the CoD item If the item being streamed is scheduled content and the next item in the PCh playlist is a CoD item, and if there is an overlapping in time with the previous item, then the CoD item shall be delayed until the scheduled content is completed. If the item being streamed is a CoD item and the next item in the PCh playlist is a scheduled content item, and if the IPTV Application has determined that there is no overlapping in time between these content items, the IPTV application tears down the old session and a new session is established for the scheduled content If the item being streamed is a CoD item and the next item in the PCh playlist is a scheduled content item, and if the IPTV Application has determined that there is an overlapping in time with the previous content item, then step 3 onwards is followed If the item current being watched is a CoD item and the next item in the PCh schedule is also a CoD item, and if the IPTV Application has determined that there is no overlapping in time with the previous content, then the CoD session is modified to switch to the next content item. If the item current being watched is a CoD item and the next item in the PCh schedule is also a CoD item, and if the IPTV Application has determined that there is an overlap in time, then the next CoD is delayed until the first CoD content is completed.
3.	The IPTV Application has detected that there is an the overlap between the content item that is currently being streamed and the next item in the PCh playlist. It selects, based on user choice or SP policy or ITF capabilities the location of the PVR (Local PVR or nPVR) for recording the overlapped content items.
4.	The IPTV Application triggers the initiation of the appropriate PVR procedure based on the selected mode of recording (Local PVR or nPVR).
5.	The OITF may play out the LPVR content, if it has been locally recorded.

6.16.2.3 Network-centric procedure for PCh service setup (unicast only)

Figure 6-77 depicts the call flow for PCh service setup, where a single unicast session between the ITF and the network is established for multiple items provided by the network, regardless of the content types (scheduled content item or content-on-demand content item).

This call flow shows a specific deployment where a Service Provider’s CDN is used for unicast delivery of both CoD as well as scheduled content.

The following is a brief description of the steps:

1.	The ITF sends the unicast session setup request (SIP INVITE), containing the PCh id and the unicast SDP, to the IPTV Control via the ASM.
2-3.	The IPTV Control validates the request and retrieves the related PCh information (e.g. list of content to be played with the time schedule of each item) from the IPTV Application.
4-5.	The IPTV Control sends the unicast session setup request (SIP INVITE), containing the content ID (e.g. BC Channel ID or COD content ID) to be played, to the CC via the ASM and the CDNC.
6.	The CC sets up the content delivery session (using RTSP SETUP) towards the CDF.
7.	For scheduled content, which is not stored in the CDF, the CDF will need to join the multicast channel and perform the multicast-to-unicast conversion.
8.	Following that, the CDF returns an RTSP 200 OK to the CC.
9-11.	The session setup response (SIP 200 OK) is sent from the CC to the ITF via the CDNC, IPTV Control and ASM.
12.	The content is delivered from the CDF to the ITF through a unicast delivery channel.
13.	When the PCh information indicates that it is time for the next item to be streamed, and it has been determined that there is no overlap with the ongoing content item currently being streamed, the IPTV Application initiates a unicast session modification procedure, via the ASM, CDNC and CC, to indicate to the CDF to switch to the new content using the next Content ID (e.g., BC Channel ID or CoD Content ID).
14.	When the PCh information indicates that it is time for the next item in the content play list to be streamed, and the IPTV Application detects an overlap between the current content, which is still being streamed to the OITF, and the new one that is about to start, the IPTV Application decides on the location of the PVR (Local PVR or nPVR) to be used for recording the overlapped contents.
15.	The IPTV Applications triggers the initiation of the procedure to start an nPVR or a Local PVR, based on the user’s choice, or SP policy, or ITF capability, in accordance with section 6.10.
16.	The unicast session may be modified if the reserved resource is not sufficient for the upcoming PCh item, e.g. due to a higher bandwidth requirement. In this case, the CC-initiated session modification procedure is applied.

6.17.1 Push Mode

6.17.1.1 High Level Push Procedure for Session Transfer and Session Replication

Figure 6-78 shows the high level procedure employed in the push mode for session transfer and replication.

The following is brief description of the steps in the call flow:

1.	It is assumed that the OITF1 is receiving streaming content over an established CoD session. At some point in time, the user on OITF1 decides that he wants to transfer or replicate the current CoD session to (or on) another device (another OITF for example).
2.	In this step, a dynamic device discovery procedure is performed to identify the potential list of devices, one of which will be the target device for a session transfer or replication. This procedure is specified by 3GPP in [Ref-37].
3.	In this example, OITF2 has been selected as the target device, and a request is sent to OITF2 to request it to initiate a session transfer or to replicate a session.
4.	If OITF2 accepts the incoming request, it initiates a new session with the network to transfer or replicate the session on OITF1.
5.	The request in step 4 is sent to the IG. If the request is for a session transfer, the IG verifies if the target and the original devices are located within the same household and behind the same IG. If so, the IG performs the necessary procedure to avoid multiple QoS reservation.
6.	The IPTV Control FE optionally bookmarks the ongoing session, if no bookmark has been performed by the original device, so that viewing the content from the target device can start from the point in time where the session transfer or replication was initiated.
7.	The new session from OITF2 is successfully established.
8.	In the session transfer case, once the new session is successfully transferred, the IPTV Control FE tears down the old session.

6.17.1.2 Push Procedure for Session Transfer and Session Replication

The call flows in Figure 6-79 and Figure 6-80 depict a more detailed procedure for session transfer/replication.

The following is a brief description of the steps in the call flow:

1.	The user has established a CoD session on OITF1, and decides to transfer or replicate the session to another device. The user selects the push option on OITF1. In order to select a target device, the 3GPP procedure for dynamic discovery of devices is performed to allow the user to discover all devices registered to all users that are under the same subscription.
2.	Once a device is selected by the end user, OITF1 issues an HTTP POST to the IG for a session transfer or replication. The request includes the identity of the session to be transferred (Session Transfer Identifier – STI), the identity of the target device the session is transferred to, and an indicator to show if session transfer or replication is requested. OITF1 may include the offset as well in the request. Additional pertinent parameters are also included in the request.
3.	The IG then issues a SIP REFER request to the target device via the ASM and the IPTV Control FE. The REFER request includes the STI, the content identifier, the target device identity and other pertinent parameters. The position being viewed on the device may be included in the body of the SIP REFER.
4.	OITF1 issues an HTTP POST pending request in anticipation of the response.
5.	The IPTV Control FE proxies the SIP REFER back to the IG associated with the target device.
6.	The IG sends an HTTP 200 OK to OITF2 that includes the SIP REFER. (It is assumed that a HTTP pending request has previously been issued by OITF2 in anticipation of any unsolicited response from the network)
7.	The OITF2 accepts the incoming request and issues an HTTP POST request to the IG that includes a SIP 202 ACCEPTED response in the POST body.
8.	The IG forwards the SIP 202 ACCEPTED to the ASM and the IPTV Control FE
9.	The IPTV Control FE forwards the SIP 202 ACCEPTED to the IG associated with OITF1.
10.	The IG sends an HTTP 200 OK to OITF1 that includes the SIP 202 ACCEPTED response in the HTTP response body.
11.	OITF1 issues an HTTP POST pending request.
12.	OITF2 now starts the transfer procedure: OITF2 issues an HTTP POST request to the IG. The IG includes the STI for the session to be transferred, the CoD content identifier, and an indication of whether this is a session transfer or a session replication request in addition to other pertinent parameters. (Note that this step can occur right after step 7)
If the request is for a session transfer, the IG verifies if the original and the target OITF belong to the same household and are behind the same IG. If that is the case, then the IG executes the procedure defined in section 6.17.3.1 prior to executing the next step in this procedure. If the request is for a session replication, the IG does not perform any additional procedure, and moves onto the next step in this procedure.
In this call flow it is assumed that the two OITFs do not belong to the same household, even though one IG is only shown in the figure for simplicity.
13.	The IG then issues a SIP INVITE to the ASM. The INVITE request includes the STI, the CoD content identifier and other relevant parameters as obtained from step 12. The ASM performs resource reservation based on the requested bandwidth.
14.	The ASM forwards the INVITE to the IPTV Control FE.
15.	The IPTV Control FE optionally performs bookmarking for the original session, using the procedure defined in section 6.17.3.2, if the original device, OITF1, did not perform one. The IPTV Control FE is involved in the bookmarking procedure and as such it is aware if OITF1 bookmarked the session.
Steps 16-21 are performed in case the request is for session transfer. In these steps, the IPTV Control FE instructs the original device, OITF1 to put the media on hold, if OITF1 did not already undertake that step. Note that if both devices involved in a session transfer are behind the same IG, the IG instructs the OITF to put the media on hold as per the procedure described in section 6.17.3.1 and this procedure is not performed,
16.	The IPTV Control FE sends a SIP re-INVITE to the original device, OITF1, to put the media on hold. If OITF1 has already put the media on hold, step 21 onwards is executed.
17.	Upon receipt of the re-INVITE to put the media on hold, OITF sends an RTSP PAUSE to the CC prior to putting the media on hold.
18.	The CC in turn issues an RTSP PAUSE to the CDF
19.	The CDF returns a 200 OK to the CC
20.	The CC returns a 200 OK to OITF1.

21.	OITF1 returns a 200 OK SIP response to the IPTV Control FE.
For steps 22-32, if the request is for session transfer and the same CDF (used by OITF1) will be used for OITF2, then the IPTV Control FE can initiate a SIP UPDATE or re-INVITE towards the remote target, otherwise a new SIP session will be established, in which case the old SIP and RTSP session shall be torn down by the IPTV Control FE (tearing down the old SIP and RTSP session is not shown for brevity)
If the request is for session replication, then a new SIP (RTSP) session shall be established and the old SIP (RTSP) session shall be maintained
22.	The IPTV Control FE starts a new SIP session by sending a SIP INVITE to the selected CDNC via the ASM
23-32.	Steps 23-32 are identical to the CoD session procedure and will not be described again for brevity. The only exception is step 29. This step is executed only if this is a session transfer case.
33.	Following the successful establishment of the new session in OITF2, OITF2 issues an HTTP POST to the IG in step 33 to notify OITF1 that the session has been successfully transferred or replicated.
34.	The IG sends a SIP NOTIFY to the IPTV Control FE via the ASM.
35.	The IPTV Control FE forwards the SIP NOTIFY to the IG of the original device, OITF1.
36.	The IG sends an HTTP 200 OK response that includes the SIP NOTIFY
37.	OITF1 issues an HTTP POST to the IG that includes the SIP 200 OK response to the incoming SIP NOTIFY
38.	The IG sends the 200 OK to the IPTV Control FE via the ASM
39.	The IPTV Control FE forwards the 200 OK to the IG for OITF2.
40.	The IG sends an HTTP 200 OK response to OITF 2 that includes the SIP 200 OK response
41.	Following that, OITF2 retrieves the bookmark associated with the content as per the procedure defined in section 6.11 if not received in step 31
42.	OITF2 now issues an RTSP PLAY to the CC for viewing the content starting at the desired position.
43.	CC proxies the RTSP PLAY to the appropriate CDF.
44.	The CDF responds with a 200 OK to the CC
45.	The CC responds to OITF2 with a 200 OK

At this point, OITF2 receives the same content.

6.17.1.3 Procedure for dynamic device discovery and device awareness

Figure 6-81 depicts the procedure for dynamic discovery of devices belonging to the same IPTV subscription.

The following is a brief description of the steps in the call flow:

1.	OITF2 issues an HTTP POST to the IG. The HTTP POST includes the SIP SUBSCRIBE to the Registration event package, and is destined to the IPTV Control FE.
2.	The IG forwards the SIP SUBSCRIBE to the ASM.
3.	The ASM forwards the SIP SUBSCIBE to the IPTV Control FE
4.	The IPTV Control FE returns a SIP 200 OK to the ASM.
5.	The ASM forwards the SIP 200 OK to the IG.
6.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP 200 OK response.
7.	OITI2 issues an HTTP Pending IG request
8.	The IPTV control generates a SIP NOTIFY that includes all registered devices belonging to all users under the same IPTV subscription as that of the originator of the procedure. The IPTV Control FE sends the SIP NOTIFY to the ASM.
9.	The ASM forwards the SIP NOTIFY to the IG.
10.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP NOTIFY
11.	OITF2 issues an HTTP POST to the IG that includes the SIP 200 OK response to the incoming SIP NOTIFY.
12.	The IG forwards the SIP 200 OK to the ASM
13.	AMS forwards the SIP 200 OK to the IPTV Control FE

6.17.2 Pull Mode

6.17.2.1 High level pull procedure for session transfer or replication

Figure 6-82 shows the high level procedure employed in the pull mode for both session transfer and replication.

The following is brief description of the steps in the call flow:

1.	It is assumed that the OITF1 is receiving streaming content over an established CoD session. At some point in time, the user on OITF1 decides he wants to transfer or replicate the current CoD session to (or on) another device, OITF2, in this example.c
2.	The user registers at the target device, OITF2. Following that, the dynamic active session discovery procedure is performed to identify active sessions that can be transferred or replicated on OITF2. This procedure is specified by 3GPP [Ref-37].
3.	The target device, OITF2, initiates a new session with the IG to transfer or replicate the chosen session.
4.	The IG verifies if the target and the original devices are located within the same household and behind the same IG. If so, the IG performs the necessary procedure to avoid multiple QoS reservation.
5.	The IPTV Control FE optionally bookmarks the ongoing session, if no bookmark has been performed by the original device, so that viewing the content from the target device can start from the point in time where the session transfer started.
6.	The new session is successfully established both for replication or session transfer.
7.	In the session transfer case, once the new session has been successfully transferred, the IPTV Control FE tears down the old session.

6.17.2.2 Pull Procedure for Session Transfer and Session Replication

The call flows in Figure 6-83 and Figure 6-84 depict a more detailed procedure for session transfer/replication for the pull method.

The following is a brief description of the steps in the call flow:

1.	The user has established a CoD session on OITF1, and decides to transfer or replicate the session to another device, OITF2. The user selects the pull option.
2.	The user registers on OITF2, and then starts the pull procedure. Subsequently, the 3GPP procedure for dynamic discovery of active sessions on other devices where the user, or other users under the same IPTV subscription, are registered and active in a session, is performed to allow the user to select a session.
3.	Once a session is selected by the user, OITF2 issues an HTTP POST to the IG for a session transfer or replication. The request includes the identity of the session to be transferred (Session Transfer Identifier – STI) and an indicator to show if session transfer or replication is requested. Additional pertinent parameters are also included in the request.
If the request is for a session transfer, the IG verifies if the original and the target OITF belong to the same household and are behind the same IG. If that is the case, then the IG executes the procedure defined in section 6.17.3.1 prior to executing the next step in this procedure. If the request is for session replication, the IG does not perform any procedure, and moves to the next step in this procedure.
In the call flow in Figure 6-83, it is assumed that the two OITFs do not belong to the same household, even though only one IG is only shown in the figure for simplicity.
4.	OITF1 issues an HTTP pending request
5.	The IG then issues a SIP INVITE to the ASM. The INVITE request includes the STI, the CoD content identifier and other relevant parameters received in step 3. The ASM performs resource reservation based on the requested bandwidth
6.	The ASM forwards the INVITE to the IPTV Control FE
7.	The IPTV Control FE optionally bookmarks the original content, based on the procedure defined in section 6.17.3.2, if the original device, OITF1, did not perform one.
Steps 8-13 are performed in case the request is for session transfer. In these steps, the IPTV Control FE instructs the original device, OITF1, to put the media on hold, if OITF1 has not already undertaken that step. Note that if both devices involved in a session transfer are behind the same IG, the IG instructs the OITF to put the media on hold as described in section 6.17.3.1 and this procedure is not performed,
8.	The IPTV Control FE sends a SIP Re-INVITE to the original device, OITF1, to put the media on hold. If OITF1 has already put the media on hold, steps 13 onwards are executed.
9.	Upon receipt of the Re-INVITE to put the media on hold, OITF1 sends an RTSP PAUSE to the CC prior to putting the media on hold.
10.	The CC in turn issues an RTSP PAUSE to the CDF
11.	The CDF returns a RTSP 200 OK to the CC
12.	The CC returns a SIP 200 OK to OITF1.
13.	OITF1 returns SIP 200 OK response to the IPTV Control FE.
For steps 14-26, if the request is for session transfer and the same CDF (used by OITF1) is to be used for OITF2, then the IPTV Control FE can initiate a SIP UPDATE or re-INVITE towards the remote end; otherwise a new SIP session will be established, in which case the old SIP and RTSP session shall be torn down by the IPTV Control FE (tearing down the old SIP and RTSP session is not shown for brevity)
If the request is for session replication, then a new SIP (RTSP) session shall be established and the old SIP (RTSP) session shall be maintained.
14.	The IPTV Control FE starts a new SIP session by sending a SIP INVITE to the selected CDNC via the ASM.
15-26.	Steps 15-26 are identical to the normal CoD session establishment procedure and will not be described again for brevity. The only exception is step 23. This step is executed only if this is a session transfer case. The remaining steps are shown in Figure 6-84.
27.	OITF2 retrieves the bookmark associated with the content as per the procedure defined in section 6.11 if not received in step 21.
28.	OITF2 now issues an RTSP PLAY to the CC for viewing the content starting at the desired position.
29.	The CC proxies the RTSP PLAY to the appropriate CDF.
30.	The CDF responds with a 200 OK to the CC
31.	The CC responds to OITF2 with a SIP 200 OK

Following that, OITF2 receives the same content as that received on OITF1.

6.17.2.3 Procedure for dynamic device discovery and active sessions awareness

Figure 6-85 depicts the procedure for dynamic discovery of devices belonging to the same IPTV subscription and the active IPTV sessions on these devices.

The following is a brief description of the steps in the call flow:

1.	OITF2 issues an HTTP POST to the IG. The HTTP POST includes a SIP SUBSCRIBE to the Registration event package, and is destined to the IPTV Control FE.
2.	The IG forwards the SIP SUBSCRIBE to the ASM.
3.	The ASM forwards the SIP SUBSCIBE to the IPTV Control FE
4.	The IPTV Control FE returns a SIP 200 OK to the ASM.
5.	The ASM forwards the SIP 200 OK to the IG.
6.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP 200 OK response.
7.	OITI2 issues an HTTP pending request
8.	The IPTV control generates a SIP NOTIFY that includes all registered devices belonging to all users under the same IPTV subscription as that of the originator of the procedure. The IPTV Control FE sends the SIP NOTIFY to the ASM.
9.	The ASM forwards the SIP NOTIFY to the IG.
10.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP NOTIFY
11.	OITF2 issues an HTTP POST to the IG that includes the SIP 200 OK response to the incoming SIP NOTIFY.
12.	The IG forwards the SIP 200 OK to the ASM
13.	The ASM forwards the SIP 200 OK to the IPTV Control FE
14.	OITF2 issues an HTTP POST to the IG. The HTTP POST includes the SIP SUBSCRIBE to the dialog event package [Ref-38], and is destined to the IPTV Control FE.
15.	The IG forwards the SIP SUBSCRIBE to the ASM.
16.	The ASM forwards the SIP SUBSCIBE to the IPTV Control FE
17.	The IPTV Control FE returns a SIP 200 OK to the ASM.
18.	The ASM forwards the SIP 200 OK to the IG.
19.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP 200 OK response.
20.	OITI2 issues an HTTP pending request
21.	The IPTV Control generates a SIP NOTIFY that includes all active IPTV sessions active on all devices of users belonging to the same IPTV subscription as that of the originator of the procedure. The IPTV Control FE sends the SIP NOTIFY to the ASM. OITF2 shall be able to correlate the information received here in conjunction with the information received in step 8 to identify the session and the device.
22.	The ASM forwards the SIP NOTIFY to the IG.
23.	The IG returns an HTTP 200 OK to OITF2 that includes the SIP NOTIFY
24.	OITF2 issues an HTTP POST to the IG that includes the SIP 200 OK response to the incoming SIP NOTIFY.
25.	The IG forwards the SIP 200 OK to the ASM
26.	The ASM forwards the SIP 200 OK to the IPTV Control FE

6.17.3 Procedures common to both push and pull modes

6.17.3.1 Procedure at the IG to avoid double QoS reservation

This procedure is invoked by the IG if it detects that the original and target device involved in a session transfer are in the same household, behind the same IG.

Below is a brief description of the steps in the call flow:

1.	It is assumed that OITF2, the target device in a session transfer, is behind the same IG as OITF1, the original device. OITF2 issues an HTTP POST request to initiate session transfer. The request includes the STI, and other pertinent parameters. The IG verifies if the STI included in the request matches an existing session whose state is maintained in the IG. If the verification outcome is positive, then both devices are behind the same IG and the remaining steps are executed. Otherwise the rest of the steps are skipped.
2.	OITF1 issues an HTTP pending request
3.	The IG returns an HTTP 200 OK response to OITF1 that includes, in the HTTP body, a SIP re-INVITE request from the IG to OITF1 to put the media on hold.
4.	OITF1 issues an RTSP PAUSE to the CC.
5.	The CC issues an RTSP PAUSE to the CDF.
6.	The CDF returns an RTSP 200 OK.
7.	The CC returns a SIP 200 OK to OITF1
8.	OITF1 issues an HTTP Pending request that includes, in the HTTP message body, the SIP 200 OK response to the re-INVITE from step 3.
9.	The IG returns an HTTP 200 OK response that includes the ACK in the HTTP message body.
10.	The IG sends a SIP UPDATE to the ASM to release the QoS resources for OITF1.
11.	The ASM forwards the SIP UPDATE to the IPTV Control FE.
12.	The IPTV Control FE returns a SIP 200 OK to the ASM.
13.	The ASM returns a SIP 200 OK to the IG.

6.18.1 Content on Demand

The following diagram shows the flows for CoD content preparation over the reference points identified in sections Not found:s5-2-1 and Not found:s5-2-3. These flows allow the key to be generated by the CoD Encryption Function or by the Key Management Function.

6.18.2 Scheduled Content

6.18.2.1 Unicast Scheduled Content, with periodic time based key rotation

On a regular basis the Scheduled Content Encryption Function requests keys or provides keys to the Key Management Function for each scheduled content service.

When the key is generated by Scheduled Content Encryption Function this function is in charge of the key rotation.

When the key is generated by the Key Management Function, the Scheduled Content Encryption Function may still be in charge of the schedule and key rotation.

When the Key Management Function manages the schedule for key changes for scheduled content services, it maintains a list of keys associated with time.

The Key Management Function centralizes all the information required to generate the DRM specific signaling, e.g. to be included in a DASH MPD and/or within an asset. This information is returned to the Scheduled Content Encryption Function that inserts the actual signaling.

6.18.2.2 Unicast Scheduled Content, with event based key rotation

The Scheduling Function provides a schedule of events to the Scheduled Content Encryption Function.

The Scheduled Content Encryption Function requests keys or provides keys to the Key Management Function for each event.

The Key Management Function maintains the relationship between events and keys.

The Key Management Function centralizes all the information required to generate the DRM specific signaling, e.g. to be included in a DASH MPD and/or within an asset. This information is returned to the Scheduled Content Encryption Function that inserts the actual signaling.

6.18.3 Start-over/Pause and Catch-up

6.19.1 Generic signalling flow

The following diagram shows the generic signalling flow using the entities identified above under the assumption that a download of the CSP software needs to be initiated.

* For service access and user authentication the functionalities described in section 6.3.2 can also be used for non-IMS based services.

6.19.2 Procedural Steps

This section describes the procedural steps for provisioning the remote download of CSP software. It uses the Reference Points identified in the upper part of this chapter and the items to be fulfilled by the corresponding Functional Entities. The description follows the order of the steps shown in the signalling flow diagram in Figure 6-91.

Step 1: Request for service access and user authentication

Involved Functional Entities: OITF, Service Access Authentication, IPTV Service Profile

Involved Reference Points: UNIS-14

The Service Access Authentication Function is contacted by the OITF for gaining access to the managed IPTV service offered by a service provider. This approach happens via Reference Point UNIS-14. Upon reception of the access request, the Service Access Authentication Function checks the validity of the access request and creates via the Reference Point an entry in the User Profile of the IPTV Service Profile that access to the IPTV service is granted.

Step 2: Preparation for CSP SW download

Involved Functional Entities: IPTV Service Profile, IPTV Applications, OITF

Involved Reference Points: NPI-17, UNIS-6

The IPTV Service Profile checks in the User Profile the actual version of the CSP SW to be used. Afterwards it triggers the download of the new CSP SW via the IPTV Applications Entity using the Remote Management API of the OITF as specified in section 7.11 of [OIPF_DAE2].

Step 3: Download of the new CSP SW

Involved Functional Entities: OITF, Remote Management

Involved Reference Points: UNI-RMS

The Remote Management Entity provides the server-side functionalities to manage the download of the new CSP SW in collaboration with the OITF. This includes the authentication of the device that is selected for a CSP SW download, followed by a secure download of the CSP SW.

The details of the download are under the responsibility of the IPTV Service Provider and are no subject to standardization. The delivery mechanism follows the guidelines described in clause 6.6 of [DVB_FUS].

Step 4: Finalization and registration of new CSP SW

Involved Functional Entities: OITF, IPTV Applications, IPTV Service Profile

Involved Reference Points: UNIS-6, NPI-17

The OITF informs the IPTV Applications Entity about the successful finalization of the download of the new CSP SW via the Reference Point UNIS-6. The IPTV Applications Entity takes care of registering the new CSP SW in the User Profile of the IPV Service Profile Entity using Reference Point NPI-17.

7.2.1 Outgoing Messaging

Figure 7-2 shows an example of outgoing messaging communication service, followed by a brief description of the flow.

7.2.2 Incoming Messaging

Figure 7-3 shows an example of incoming messaging communication service, followed by a brief description of the flow.

7.3.1 Chat session setup

Figure 7-4 shows an example of a chatting session set-up (i.e. communication context set-up), followed by a brief description of the flow. In this case the chatting template is generated and presented to the user directly by the OITF. The chatting template could be also generated by the IG, with a procedure including initial steps analogous to the ones presented in section 7.4.2.1.

7.3.2 Chat outgoing message

Figure 7-5 shows an example of chat outgoing message, followed by a brief description of the flow.

7.3.3 Chat incoming message

Figure 7-6 shows an example of a chat incoming message, followed by a brief description of the flow.

7.3.4 Chat session teardown

When the user wants to end the chat session, he performs the needed actions on the OITF (e.g. pushing a button). This causes:

• the In-session Notification tear down;
• a terminating message to be sent to the IG;
• the tear down of the chat session between the IG and the IM Enabler, through standard IM session-mode and IMS tear-down procedures.

7.4.1 General Description of Presence in IPTV

IPTV services may be combined with Presence service capability. The mechanisms used in order to combine IPTV services with the Presence service capabilities may also be used for other purposes such as:

• Gathering channel statistics and user behaviour information.
• Supporting session continuity between different terminals

The ITF must be able to collect and send Presence information related to:

• the end user (e.g. status of the end user);
• the IPTV service activated (e.g. Scheduled Content, CoD, PVR);
• the IPTV program watched (e.g. channel currently accessed, program currently watched, content currently accessed);
• other information the ITF can manage (e.g. in case of a hybrid ITF - IPTV and DTT capable - channel/program accessed/watched on DTT; in case of a combined deployment – unmanaged and managed models are both enabled – channel/program accessed via an unmanaged network).

It is the user's decision (through the use of privacy preferences) as to which specific IPTV attributes to include in the Presence information that is made available to other users.

Figure 7-7 and Figure 7-8 show two examples of the use of the Presence service with IPTV.

Figure 7-7 shows the mechanism proposed in order to allow an ITF to communicate Presence information.

The IPTV Control can forward and aggregate the Presence information collected towards other entities (e.g. external Presence Server, other specific application server) based on internal policies/rules.

The ITF may also collect and send the IPTV Presence information to the P2P Communication Enabler (Presence Enabler) directly, as shown in Figure 7-8.

7.4.2 Presence Session Management Procedures

The Communication Service Presence allows multiple users of an ITF to communicate their presence information inside an IPTV Service network. A user (A) can subscribe to the presence information of other users (B,C ...) so that when one of these users changes his Presence status user (A) will receive a notification of this change.

The OMA (Open Mobile Alliance) has specified an enabler for Presence allowing the management of the collection and the controlled dissemination of presence information over a SIP/IP network. The enabler is based on the IETF SIP protocol (RFC 3261) [Ref-21] with SIMPLE and 3GPP extensions. The procedure described in this section is aligned with the procedures specified in OMA “Presence SIMPLE Specification” (OMA-ERP-Presence_SIMPLE-V1_0_1-20061128-A) [Ref-24]

7.4.2.1 Presence session set-up – Presence template produced by the IG

The following is a brief description of the steps in the flow:

1.	A user logged on to an OITF wants to subscribe to the presence events associated with another user or a group of users. The OITF sends an HTTP GET message that allows it to fetch a template form to be filled up by the user.
2.	The IG-OITF Server intercepts the request and returns an HTML form document to be filled out by the end user in a 200 OK message.
3.	The OITF sends an HTTP POST message including the completed template form to the IG-OITF Server.
4.	The IG-OITF Server intercepts the message and invokes the appropriate operation in the Auth/Session Mgmt. function in the IG.
5.	The Auth/Session Mgmt. function in the IG creates a SIP SUBSCRIBE message with the appropriate information and sends it to the Authentication and Session Management FE in the user’s home network.
6.	A SIP SUBSCRIBE message is forwarded to the Presence Enabler function.
7.	A 200 OK is received as a response from the Presence Enabler function.
8.	A 200 OK is forwarded to the Auth/Session Mgmt. function in the IG.
9.	The Auth/Session Mgmt. function in the IG sends the operation result to the IG-OITF Server.
10.	The IG-OITF Server sends a 200 OK to the OITF as a response to the HTTP POST operation, which contains the result page (which will be updated when a presence event is received) and an ECMA Notification Script that is run by the client in order to set-up an In-Session Notification Procedure.
11.	The OITF sets up an In-Session Notification Procedure (XML HTTP request or Persistent TCP Connection Mode) with the IG-OITF Server. The IG-OITF Server will then be able to send a notification message to update the OITF UI page dynamically without the need to reload the XHTML-page.
12-13.	The Auth/Session Mgmt. function in the IG receives a NOTIFY message that includes the Presence status from Presence Enabler function via Authentication and Session Mgmt. function.
14.	The Auth/Session Mgmt. function in the IG invokes the In-session notification function in the IG-OITF Server.
15.	The Auth/Session Mgmt. function in the IG sends 200 OK message to Authentication and Session Mgmt. function in responds to the SIP NOTIFY.
16.	A 200 OK is forwarded to Presence Enabler function.
17.	The IG-OITF Server performs the necessary in-session notification operation (CEA 2014) [Ref-3] for the OITF to display the presence information to the end-user. All NOTIFY messages, for this subscription, are delivered within the In Session Notification session, established in step 9.
18.	Finally the IG-OITF Server sends back to the IG Auth/Session Mgmt. function the operation result.

7.4.2.2 Presence Privacy Management

The Communication Service Presence allows a user at an ITF to manage the privacy settings of the user’s presence information. The user can do so by configuring the presence authorization rules on the Presence enabler which is used to proactively or reactively authorize the incoming presence subscription requests from other users. For reactive authorization, the user subscribes to changes in the watcher information. That way when a subscription request comes in from a potential watcher, the presence enabler notifies the user who can then proceed to accept or deny the subscription.

Figure 7-10 provides an example of a signalling flow for presence privacy management using reactive authorization.

The following is a brief description of the steps in the flow:

1.	A user (A) logged on to an OITF decides to start his presence service application. The OITF sends an HTTP POST message to subscribe to the watcher information event associated with himself.
2.	The IG-OITF Server intercepts the message and invokes the appropriate operation in the Auth/Session Mgmt. function in the IG.
3.	The Auth/Session Mgmt. function in the IG creates a SIP SUBSCRIBE message with the appropriate information and sends it to the Authentication and Session Management FE in the user’s home network.
4.	A SIP SUBSCRIBE message is forwarded to the Presence Enabler function.
5.	A 200 OK is received as a response from the Presence Enabler function.
6.	A 200 OK is forwarded to the Auth/Session Mgmt. function in the IG.
7.	The Auth/Session Mgmt. function in the IG sends the operation result to the IG-OITF Server.
8.	The IG-OITF Server sends a 200 OK to the OITF as a response to the HTTP POST operation, which contains the result page (which will be updated when a watcher information event is received) and an ECMA Notification Script that is run by the client in order to set-up an In-Session Notification Procedure.
9.	The OITF sets up an In-Session Notification Procedure (XML HTTP Request or Persistent TCP Connection Mode) with the IG-OITF Server. The IG-OITF Server will then be able to send a notification message to update the OITF UI page dynamically without the need to reload the XHTML-page.
10.	Upon reception of a presence information request from another user (B), and based on presence privacy rules stored in presence enabler profile, the presence enabler may decide to send a SIP NOTIFY message with “pending” presence authorization status.
11.	A SIP NOTIFY message is forwarded to the Auth/Session Mgmt. function in the IG.
12.	The Auth/Session Mgmt. function in the IG invokes third party notification in the IG-OITF Server.
13.	The IG-OITF Server performs the necessary in-session notification operation (CEA 2014) [Ref-3] for the OITF to display the presence information to the end-user. All NOTIFY messages, for this subscription, are delivered within the In Session Notification session, established in step 9.
14.	The IG-OITF Server sends back to the IG Auth/Session Mgmt. function the operation result.
15.	The Auth/Session Mgmt. function in the IG sends 200 OK message to the Authentication and Session Mgmt. function in response to the SIP NOTIFY.
16.	A 200 OK is forwarded to Presence enabler FE.
17.	Upon reception of presence authorization request (step 13), the OITF sends an HTTP GET request to the Presence enabler profile.
18.	The Presence enabler profile returns the presence privacy profile to the OITF in a 200 OK.
19.	Upon selection by the user (A) of the presence authorization option, e.g. allow, the OITF sends an HTTP PUT request to update the Presence enabler profile.
20.	The Presence enabler profile acknowledges the HTTP request in a 200 OK.

At this point the Presence enabler can send user A’s presence information to user B.

7.4.3 Scheduled Content and fast update rate events case

When channel switching during a Scheduled Content service, users will likely be able to zap between a set of channels within the same “bouquet” (e.g. channel with the same bandwidth requirements) without further signalling related to the Service Setup Session (from ITF to IPTV Control). In this case, sending presence information each time the user changes channel may lead to a heavy load on the network (e.g. in case of zapping). In order to reduce and control possible overload caused by frequent channel hopping, it shall be possible to define some mechanisms that is able to limit the number of publications of channel change. In particular, two instances of mechanisms can be foreseen:

• Client side – configurable delay: the ITF client should not inform the IPTV Control about several consecutive channel changes within the delay period. When the user stops zapping, information about the watched channel should be sent to the IPTV Solution. The delay time that is used may be configurable.
• Server side – rate control: The IPTV Solution should control the rate of information sent by ITF client so it can decrease the frequency of publication of change channel.

Figure 7-11 and Figure 7-12 provide examples of a signalling flow for channel switching, for the case of Client side and Server side load control, respectively.

7.4.3.1 Scheduled Content channel switching; Client Side load control

0.	The ITF leaves a multicast channel and joins another multicast channel with the same QoS requirements. A delay may be applied. If the user switches channel again during this delay time, the flow is restarted at step 0. (see a.) (see a.) ...
1.	The ITF sends information about which channel that is being watched.
2.	The Authentication and Session Management FE routes the information to the IPTV Control.
3.	IPTV Control responds to the Inform channel change request.
4.	The Authentication and Session Management routes the response to the ITF.

7.4.3.2 Scheduled Content channel switching; Server Side load control

0.	The ITF leaves a multicast channel and joins another multicast channel.
1.	The ITF sends information about which channel is being watched.
2.	The Authentication and Session Management FE routes the information to the IPTV Control.
3.	IPTV Control checks the rate notification from the ITF and responds to the Inform channel change request; also sent in the response is an info (rate of publication) to decrease the frequency of sending the change channel information.
4.	The Authentication and Session Management FE routes the response to the OITF which updates its own rate of publication.