Version 0.

IPTV green book

Introduction to the work being done.
This document lists all ITU-T Recommendations relevant for IPTV. They have been grouped and
assigned to different chapters. Each chapter starts with the list of relevant recommendations
followed by their summaries.
Extended summaries have been drafted for a number of Recommendations and inserted after
extracted summaries. If, in the table of contents below, a recommendation appears with its identifier
and complete title, this means that an extended summary has been drafted and is inserted there.
Propositions to draft missing extended summaries are welcome. Feedback would be appreciated on:
• Missing recommendations
• Structure of table of contents
• Existing extended summaries
Propositions and feedback are to be sent to Simão Campos ([email protected]).

Contents
1 Abbreviations .................................................................................................................................. 2
2 Introduction (from FG to SGs) ......................................................................................................... 3
3 Overview of IP content delivery (could base on one of the current technical papers?)................. 3
4 Architecture , requirements and use cases ..................................................................................... 3
4.1 Y.1901: Requirements for the support of IPTV services ......................................................... 3
4.2 Y.1910: IPTV functional architecture ....................................................................................... 6
4.3 Y.1991: Terms and definitions for IPTV ................................................................................. 14
4.4 Y-series Suppl. 5: Supplement 5 to Y-series Recommendations ITU-T Y.1900-series,
Supplement on IPTV service use cases.............................................................................................. 15
4.5 Other Recommendations ...................................................................................................... 18
5 IPTV Security (X-series) .................................................................................................................. 20
6 IPTV Terminal Devices ................................................................................................................... 21
6.1 H.720: Overview of IPTV terminal devices and end systems ................................................ 21
6.2 H.721: IPTV Terminal Device: Basic model ............................................................................ 23
6.3 J.702: Enablement of current terminal devices for the support of IPTV services ................. 25
6.4 J.703: IPTV Client Control Interface Definition ...................................................................... 27
6.5 J.705: IPTV client provisioning, activation, configuration and management Interface
Definition ........................................................................................................................................... 30
7 IPTV Middleware ........................................................................................................................... 31
8 IPTV Application Event Handling (with big emphasis on AM) ....................................................... 32

Green book on IPTV Page 1 / 64

 Version 0.5

8.1 H.740: Application event handling for IPTV services............................................................. 32

8.2 H.741.0: IPTV application event handling: Overall aspects of audience measurement for
IPTV services ...................................................................................................................................... 34
8.3 H.741.1: IPTV application event handling: Audience measurement operations for IPTV
services .............................................................................................................................................. 37
8.4 H.741.2: IPTV application event handling: Data structures of audience measurement for
IPTV services ...................................................................................................................................... 42
8.5 H.741.3: IPTV application event handling: Audience measurement for IPTV distributed
content services ................................................................................................................................ 44
8.6 H.741.4: IPTV application event handling: Transport mechanisms for audience
measurement .................................................................................................................................... 46
8.7 Other Recommendations ...................................................................................................... 47
9 IPTV Metadata ............................................................................................................................... 48
9.1 H.750: High-level specification of metadata for IPTV services.............................................. 48
9.2 H.751: common specification with IEC TC 100 on metadata for rights interoperability (or for
“security”).......................................................................................................................................... 50
10 IPTV Multimedia Application Frameworks ................................................................................ 51
10.1 H.760: Overview of Multimedia Application Frameworks for IPTV ...................................... 51
10.2 H.761 : Nested Context Language (NCL) and Ginga-NCL for IPTV services ........................... 56
10.3 Other Recommendations ...................................................................................................... 59
11 IPTV Service Discovery up to consumption ............................................................................... 59
11.1 H.770: Mechanisms for service discovery and selection for IPTV services ........................... 60
11.2 Other Recommendations ...................................................................................................... 63
12 Application of IPTV Technology................................................................................................. 63

1 Abbreviations
IPTV Internet Protocol Television
SADS Service and Application Discovery and Selection
SCP Service and Content Protection
TTS Time-stamped Transport Stream

Green book on IPTV Page 2 / 64

 Version 0.5

2 Introduction (from FG to SGs)

3 Overview of IP content delivery (could base on one of the current

technical papers?)

4 Architecture , requirements and use cases

The Y-Series Recommendations cover IPTV architecture, requirements and use cases. Quality related
aspects are covered in the G-Series, while some other related aspects are found in the H-, J- and Q-
Series:
– Y.1901 (01/2009): Requirements for the support of IPTV services
– Y.1902: Framework for multicast based IPTV content delivery
– Y.1910 (09/2008): IPTV functional architecture
– Y.1911: IPTV services and nomadism: scenarios and functional architecture for unicast delivery
– Y.1920: Guidelines for the use of traffic management mechanisms in support of IPTV services
– Y.1991 (03/2010): Terms and definitions for IPTV
– Y-series Suppl. 5 (05/2008): Supplement 5 to Y-series Recommendations ITU-T Y.1900-series,
Supplement on IPTV service use cases
– Y.Suppl.16: Guidelines on deployment of IP multicast for IPTV content delivery
– Y.Suppl.20: Scenarios and use cases of mobile IPTV
– G.1080: Quality of experience requirements for IPTV services
– G.1081: Performance monitoring points for IPTV
– G.1082: Measurement-based methods for improving the robustness of IPTV performance
– H.622.1: Architecture and functional requirements for home network supporting IPTV services
– J.700: IPTV Framework for Secondary Distribution
– Q.3040: Signalling and control plane architecture for IPTV
– H.701: Content delivery error recovery for IPTV services. Note: Should this be security or
quality related section? Should we have a separate quality related section, split from the
Architecture one?
The following Recommendation provide specification for content delivery within the context of
[DocSys?] systems:
– J.704: Functional requirements of the service provider interface for television primary and
secondary distribution and associated interactive services

4.1 Y.1901: Requirements for the support of IPTV services

Extracted summary
Recommendation ITU-T Y.1901 specifies the high level requirements to support IPTV services. These
include IPTV requirements for service offering, network aspects, QoS and QoE, service and content
protection, end system, middleware and content.
Extended summary

Green book on IPTV Page 3 / 64

 Version 0.5

For each issue requirements are listed in three sections, first the requirements which are to be
strictly followed and from which no deviation is permitted, second the requirements which are
recommended but which are not absolutely required and third optional requirements.
Requirements are listed for different issues and features of the IPTV architecture, namely:
• General aspects (e.g. multiple content resolutions and multiple content aspects ratios or
two-way communication between the end-user and the service provider)
o Service offering (e.g. ability to support interactive services, communications services,
and information services or ability for the service provider to prevent the sending of
bulk unsolicited content to end-users)
o Accounting and charging (e.g. ability for the service provider to authenticate,
authorize and charge the subscriber or capabilities for transferring settlement
information between service providers)
o Service consumption (e.g. mechanisms so that the end-user can filter unwanted
contents or ability for the end-user to turn on and off the audio, the subtitles,
captioning, etc.)
o Miscellaneous (e.g. means to present the ITF with the time of day reference or
mechanisms for the service provider to operate, administer, maintain, and provision
IPTV devices
• QoS and performance aspects (e.g. framework that identifies the components and
measurement points for quality of service measurement or capabilities for management of
capacity on service and network elements)
o Quality of experience (e.g. mechanisms for supporting appropriate resiliency in the
service provider infrastructure to maintain high QoE or means to provide channel
changing times with sufficient QoE)
o Traffic management (e.g. traffic management mechanisms for the differential
treatment of IPTV traffic or mechanism for assigning IPTV traffic priorities)
• Security aspects including service and content protection
o General IPTV security (e.g. content protection or service and content protection of
end-user shared content)
o Service and content protection (e.g. association of content with protection and
content management metadata to permit the expression of its rights of usage or
protection of content transferred over multicast and/or over unicast streams)
o Service security (e.g. authorization and authentication of end-user or rights
management independent of specific content formats or specifications)
o Network security (e.g. provision of security measures to block illegal or unwanted
traffic or protection against attacks on multicast capabilities)
o IPTV terminal device security (e.g. means to authenticate IPTV terminal devices or
physical tampering resistance for IPTV terminal devices)
o Subscriber security (e.g. user privacy protection or support to allow a subscriber to
set an access control mechanism (e.g., a password) in order to restrict access to
content and/or services)
• Network related aspects (e.g. ability of both multicasting and unicasting transmission
schemes or content delivery in several yet optional versions to be selected according to the
capabilities of the IPTV terminal device)
o Network (e.g. mechanism to appropriately distinguish different forms of traffic or
mechanism for NAT traversal)
o Multicast distribution (e.g. multicast means of communication to all end-users or
mechanisms that allow IPTV services to be distributed to specific groups of end-
users.)

Green book on IPTV Page 4 / 64

 Version 0.5

o Mobility aspects (e.g. mechanisms for exchanging subscriber-related information

between the visited network and the home IPTV service provider or mechanisms for
discovering and selecting IPTV services provided by the home IPTV service provider
for roaming users)
o Interworking between IPTV and PSTN/ISDN (e.g. network facilities for processing
PSTN/ISDN incoming/outgoing calls or voice encoding/decoding capabilities, as per
PSTN/ISDN incoming/outgoing calls.)
• End systems and interoperability aspects
o End-user aspects on IPTV services (e.g. end-user ability to choose and select one
subtitle or closed caption flow from several or mechanism for end-users to make the
content they produced/created available to other end-users). Requirements are also
listed for end-user aspects on linear TV, on linear TV with trick mode, on time-shift
TV, on VoD, on push VoD, on PVR service and on service information
o IPTV terminal device (e.g. decoding of at least one video and one audio format or
system start-up and initialization function). Requirements are further listed for
interfaces, provisioning, PVR control, security and authentication functions, SCP
functions, end-user interaction functions, terminal management, system resource
management functions, Internet access functions and aspects related to ITF.
o Remote management (e.g. ability for the service provider to retrieve device
information such as manufacturer name, software version, firmware version and
supported profiles or ability for the service provider to retrieve statistical information
of usage)
o Home network (e.g. IP filtering functions in the DNGF in order to prevent selected
local multicast traffic on the home network side from appearing on the network side
or mechanisms for transport of time of day to the home network)
• Middleware, application and content aspects
o General (e.g. ability to search for available content or capability of receiving and
processing content metadata available from content providers)
o Middleware (e.g. terminal device start-up and initialization function or support for
play, pause and stop functions)
o Metadata (e.g. description of accessibility features, including language or extensible
content description). Requirements are further detailed for metadata structure,
metadata for service navigation, metadata for package service, metadata
provisioning and metadata delivery.
o Content.
Content delivery (e.g. mechanisms for content downloading or both a pull
and a push method of content delivery)
Video (e.g. wide range of temporal sampling standards, bit-rates and picture
resolutions or accurate lip-synchronisation)
Audio (e.g. audio depth equivalent to existing broadcasts or mechanisms for
single (mono), dual (stereo) and multichannel (at least 5.1 surround sound)
audio transmission)
Content replay (e.g. playback of recorded content in the same way as typical
DVD players or mechanisms to assist in locating random access points in the
media stream)
Content provisioning and management (e.g. mechanism for the service
provider to ingest and store VoD content or transfer interface between
content provider and service provider independent of content formats)
o Service navigation (e.g. content selection through an electronic content guide or
service selection through an electronic service guide)

Green book on IPTV Page 5 / 64

 Version 0.5

o Service/content discovery and selection (e.g. capabilities for service discovery or

capabilities for the end-user to select the content to be delivered)
o Returned data (e.g. acquisition of demographic data from the IPTV terminal device)
• Public interest
o Accessibility (e.g. mechanisms to support subtitles and captions or ability to select
and receive two (related) video sources simultaneously)
o Emergency telecommunications and regulatory information services (e.g. emergency
alert service, where required, by regulation or law of the country or routing of
emergency telecommunications from the end-user to appropriate emergency
response service)
o Provider selection and number portability (e.g. support a mechanism for end-users
to select IPTV network providers, IPTV service providers, and IPTV content providers
according to their preferences or number portability capabilities)
Appendix I is about “Public interest cross-reference”. Cross-references to individual requirements in
the main body are given for "Public interest" requirements.

4.2 Y.1910: IPTV functional architecture

Extracted summary
Recommendation ITU-T Y.1910 describes the IPTV functional architecture intended to support IPTV
services based on the IPTV service requirements and definitions. Starting from a basic description of
IPTV roles and services, a high level IPTV functional model is outlined. This model is then developed
into a set of functional architectures which support NGN and non-NGN transport networks, as well as
operation modes with or without IMS.
Extended summary

End user Network provider Service provider Content provider

Y.1910(08)_F6-1

Figure 6-1 from Y.1910 – IPTV domains

Figure 6-1 shows the main domains that are involved in the provision of an IPTV service.
This Recommendation identifies three IPTV architecture approaches that enable service providers to
deliver IPTV services:
1) "Non-NGN IPTV functional architecture" (non-NGN IPTV): The non-NGN IPTV architecture is based
on existing network components and protocols/interfaces.
2) "NGN-based non-IMS IPTV functional architecture" (NGN non-IMS IPTV): The NGN non-IMS IPTV
architecture utilizes components of the NGN framework reference architecture as identified in

Green book on IPTV Page 6 / 64

 Version 0.5

[ITU-T Y.2012] to support the provision of IPTV services, in conjunction with other NGN
services if required.
3) "NGN IMS-based IPTV functional architecture" (NGN-IMS IPTV): The NGN IMS-based IPTV
architecture utilizes components of the NGN architecture including the IMS component to
support the provision of IPTV services in conjunction with other IMS services if required.
Architectural differences between the three IPTV functional architectures are outlined, in particular
for service control functions.

End-user functions Application functions Management Content provider

functions functions
IPTV terminal
functions Application profile Application
Transaction management
protocol IPTV application functional block
Application functional block
functions
client functions Content Content
Metadata Content and metadata
preparation and metadata
functions sources
SCP client
SCP functions
functions Control Content
Service control
management
functional block
Service control functions Content delivery functions

Content distribution
and location
control functions
Content delivery Delivery protocols
Content delivery Content delivery
client functions
and storage management
functions functional block
Control client IPTV service
control functional Service user
functional block Multicast
block profile functional Content and
delivery
block control
control
End-user device
protocol
management
functional block
Home network Network functions
functions
Authentication and
configuration protocol Authentication and
Resource control Transport
IP allocation
functional block management
functional block
functional block

Delivery network
gateway Access network Edge Core transport Transport
functional block functions functions functions functions

Y.1910(08)_F9-1

Figure 9-1 from Y.1910 – IPTV architectural overview

Figure 9-1 provides an overview of the IPTV functional architecture.
The highest level in the IPTV functional overview is the level of functional groups as follows:
• End-user functions: to perform mediation between the end user and the IPTV infrastructure
• Application functions to enable the end-user functions to select and purchase or rent a
content item
• Service control functions (SCF): to request and release network and service resources
required to support the IPTV services
• Content delivery functions (CDF): to receive content from the application functions, store,
process and deliver it to the end-user functions using the capabilities of the network
functions, under control of the service control functions
• Network functions: to provide IP layer connectivity between the IPTV service components
and the end-user functions
• Management functions: to perform overall system management (i.e., operations,
administration, maintenance and provisioning (OAM&P)).

Green book on IPTV Page 7 / 64

 Version 0.5

• Content provider functions: to provide (i.e., sell, rent or give free usage permission) content
or content assets
Each functional group is further decomposed in smaller functional groups or functional blocks as
illustrated on figure 9-1 from Y.1910.
The end-user functions are comprised of
• IPTV terminal functions: to collect control commands from the end user, to interact with the
application functions to obtain service information (e.g., EPG), content licenses and keys for
decryption, to interact with the service control and content delivery functions to receive the
IPTV services and also provide the capability for content reception, decryption and decoding.
o Application client functions: to exchange information with the IPTV application
functions to support IPTV services and other interactive applications
o Service and content protection (SCP) client functions: to provide service protection
and content protection, to verify the usage rights and decrypt and optionally
watermark the content
o Content delivery client functions: to receive and control the delivery of the content
from the content delivery and storage functions (CD&SF)
o Control client functional block: to initiate service requests to the IPTV service control
functional block in order to prepare for the connection to the content delivery
functions
• Home network functions
o Delivery network gateway functional block: to provides IP connectivity between the
external network (i.e., external to the home network) and the IPTV terminal device,
to manage IP connectivity, to obtain IP addresses and configurations for the home
network functions and IPTV terminal devices
The application functions are comprised of:
• IPTV application functions: to enable the IPTV terminal functions to select and purchase
content
• Application profile functional block: to include end-user settings (capabilities of IPTV terminal
devices), global settings (e.g. language preference), linear TV settings, list of subscribed linear
TV service packages, VoD settings (e.g. parental control level), personal video recorder (PVR)
, information related to actions taken by the user while accessing services
• Content preparation functions: to control the preparation and aggregation of the contents,
metadata and EPG data, as received from the content provider functions
• Service and content protection (SCP) functions: to control access to services and protect
services using methods such as encryption, to control access to contents and to protect
them using methods such as encryption
The service control functions are comprised of:
• IPTV service control functional block: to handle service initiation, modification and
termination requests, perform service access control, establish and maintain the network
and system resources required to support the IPTV services requested by the IPTV terminal
functions.
• Service user profile functional block: to store end-user service profile (i.e., IPTV services
subscribed to), subscriber-related data (e.g., who pays the incurred charges), end-user
location data, end-user presence status (e.g., online/offline), to perform basic data
management and maintenance functions
Content delivery functions (CDF). They are used to perform cache and storage functionalities and
deliver the content according to the request from the end-user functions. They are comprised of:

Green book on IPTV Page 8 / 64

 Version 0.5

• Content distribution and location control functions: to include at least interactions with the
IPTV service control functional block, control of content distribution from the content
preparation functions to the content delivery and storage functions
• Content delivery and storage functions: to store and cache content, process it under the
control of content preparation functions and distribute it among instances of content
delivery and storage functions based on the policy of content distribution and location
control functions
Network functions. They are shared across all services delivered by IP to end-user functions, they
provide the IP layer connectivity to support IPTV services. They are comprised of:
• Authentication and IP allocation functional block: for authentication of the delivery network
gateway functional block which connects to the network functions, as well as allocation of IP
addresses to the delivery network gateway functional block and optionally to the IPTV
terminal functions
• Resource control functional block: to provide control of the resources which have been
allocated for the delivery of the IPTV services through the access network, edge and core
transport functions.
• Transport functions: to provide IP layer connectivity between the content delivery functions
and the end-user functions
o Access network functions: to aggregate and forward IPTV traffic sent by the end-user
functions into the edge of the core network, to forward IPTV traffic from the edge of
the core network towards the end-user functions.
o Edge functions: to forward IPTV traffic aggregated by the access network functions
towards the core network, and also to forward the IPTV traffic from the core
network to the access network functions.
o Core transport functions: to forward IPTV traffic throughout the core network.
Management functions. They are used to handle overall system status monitoring and configuration.
They include functional blocks for application management, content delivery management, service
control management, end-user device management and transport management.
Content provider functions. They are used to provide the content and associated metadata to
content preparation functions. They include:
• Content and metadata sources: to include content protection rights sources, content sources
and metadata sources for the IPTV services.
Differences in functional blocks for the three IPTV architecture approaches are shown on the
following table:
Functional block Non-NGN IPTV NGN non-IMS IPTV NGN IMS IPTV
architecture architecture architecture
Control client Control client Control client Session client
functional block functional block functional block functional block
IPTV service control IPTV service control IPTV service control Core IMS functions
functional block functional block functional block
Network functions Network functions NGN transport stratum NGN transport stratum
functions functions
Authentication and IP Authentication and IP Transport control Transport control
allocation functional allocation functional functions including functions including
block block network attachment network attachment
control functions control functions

Green book on IPTV Page 9 / 64

 Version 0.5

(NACF) and resource (NACF) and resource

Resource control Resource control
and admission control and admission control
functional block functional block
functions (RACF) functions (RACF)

Interworking between these various architectures can be achieved by means of interworking

functions or interworking gateways in between two different IPTV architectures.
Another form of interworking is the third party application interworking in which a third party
application gateway functional block added to the application functions functional block provides a
controlled interface to enable outside third party application functions to utilize the IPTV-related
capabilities and resources.

The three IPTV architectures are further detailed as illustrated on the following figure for NGN non-
IMS IPTV architecture:
End-user functions Application functions

IPTV terminal IPTV application functions

E0 A4
functions Application profile
SADS functional block A5
Application functional block
client functions E1 M1
IPTV application functional block A3 Content preparation functions
SADS client
functional block A6 C3
A1 A2 SCP functions
IPTV application E2
client functional C2 C1
block NGN service stratum functions Content delivery functions
Service support functions Content distribution and location control functions
SCP client S1
functions Location control functional block Distribution control functional block

Control client E3
D1
functional block Content delivery and storage functions
Content delivery Content delivery control functional block
Service control functions
client functions
Error recovery Service user profile Cache/storage functional block Distribution functional block
E4 functional block
client functional
block Error recovery functional block Content processing functional block
IPTV service control
Unicast content functional block
E6 Unicast delivery functional block Multicast delivery functional block
delivery client
functional block

Multicast content E5 NGN transport stratum functions

delivery client
functional block Control functions
H1 Network attachment control functions (NACF) Resource and admission control functions (RACF)
Home network T1 R1
functions
Access network functions Edge functions Core transport functions Transport
E7 functions
Multicast transport functions
Multicast control point functional block
H2 Multicast replication functional block
Delivery network
gateway
functional block H3
Unicast transport functions

Y.1910(08)_F11-2

Figure 11-1 from Y.1910 – Reference points of NGN non-IMS IPTV architecture

Reference points are identified for the three IPTV architectures, as illustrated on the previous figure
for the non-NGN IPTV architecture:
Reference points with characteristics common to all three IPTV architectures:
• A2 used by the IPTV applications functional block to request service parameters from
CD&LCF.
• A3 used to transmit the metadata stored in content preparation functions to the IPTV
application functional block
• A4 used by the SADS functional block to retrieve application profiles
• A5 used by the IPTV application functional block to retrieve application profiles

Green book on IPTV Page 10 / 64

 Version 0.5

• A6 used for transferring keys related to service and content protection information from SCP
functions to the IPTV application functional block
• C1 used to facilitate content preparation functions to configure policies such as content
distribution rules, selection criteria, etc., in the CD&LCF
• C2 used to transfer content from content preparation functions to CD&SF
• C3 used by the SCP functions to acquire the content rights or licenses from the content
preparation functions
• E0 used by the ITF to discover and select IPTV services and applications
• E1 reference point used by the ITF to support service and application configuration
• E2 used for delivering security information (e.g., rights object or keys) from SCP functions to
SCP client functions
• E4 used to exchange messages for requesting and delivering error recovery information, for
example FEC repair data or retransmission data
• E5 used to exchange messages for joining multicast channels, e.g., IGMP messages
• E6 used to exchange content control messages, e.g., video recording commands
• E7 used to deliver control messages and content streams
• D1 used by the CD&LCF to get status information from the CD&SF, such as load status, the
contents catalogue on each CD&SF, etc.
• H2 provides multicast-based IP connectivity between the delivery network gateway
functional block and access network functions in order to deliver control messages and
content streams
• H3 provides unicast-based IP connectivity between the delivery network gateway functional
block and access network functions in order to deliver control messages and content streams
• M1 used by SCP functions to get security-related information from the application profile
functional block
• Mc used to pass information to allow for the dynamic computation, establishment and
maintenance of multicast trees
• Md used by the CD&SF to deliver content streams in multicast mode
• Ud used by the CD&SF to deliver content streams in unicast mode
Reference points with characteristics specific to non-NGN IPTV architecture:
• A1 used for forwarding service signalling information between the IPTV service control
functional block and the IPTV application functional block and for forwarding signalling
information between the IPTV application functional block and other functions, such as the
ITF, CD&LCF
• E3 used to exchange session signalling information, e.g., session establishment, modification
and termination
• H1 used to perform authentication, and obtain necessary network parameters, e.g., IP
address, etc., when the ITF within end-user functions attaches to the network
• R1 used by the resource control functional block to control network resources within the
transport functions
• S1 used to forward the service signalling messages, e.g., service requests, content resource
requests, between the ITF/IPTV application functions and the CD&LCF
• S2 used by the IPTV service control functional block to access service user profiles
• S3 used by the IPTV service control functional block for requesting control of network
resources
• S4 used by the IPTV service control functional block to get information from the
authentication and IP allocation functional block such as the ITF location
• S5 used to exchange messages for session management, e.g., session establishment,
modification, or termination

Green book on IPTV Page 11 / 64

 Version 0.5

• T1 used for management of network configuration parameters as well as authentication of

data
Reference points with characteristics specific to NGN non-IMS IPTV architecture:
• A1, E3, S1, S2, S5 same as in the non-NGN architecture
• H1 used to perform authentication, and get necessary network parameters, e.g., IP address,
when the ITF within the end-user functions attaches to the network
• R1 between RACF and the transport functions. It corresponds to the Rw reference point in
[ITU-T Y.2111]
• S3 between the IPTV service control functional block and RACF. It corresponds to the Rs
reference point in [ITU-T Y.2111].
• S4 between the IPTV service control functional block and NACF. It corresponds to the S-TC1
reference point in [ITU-T Y.2014].
• T1 between NACF and the access network functions. It corresponds to the TC-T1 reference
point in [ITU-T Y.2014].
Reference Points specific to NGN IMS IPTV Architecture:
• H1, R1, T1 same as in the NGN non-IMS architecture
• A0 used for exchanging service and application discovery information towards the ITF
• A1 used for forwarding service signalling information between the core IMS and IPTV
application functional block and for forwarding signalling information between the IPTV
application functional block and other functions, such as the ITF, CD&LCF. It corresponds to
the ISC reference point defined in [ITU-T Y.2021].
• E3 used by the session client functional block to initiate a service request to the IPTV
application functions via the core IMS functions, to identify and prepare for the connection
to the content delivery functions, e.g., request for suitable content delivery and storage
functions in a VoD case, and request for network parameters in a linear TV case, etc.
• S1 used to forward the service signalling messages, e.g., service requests, content resource
requests, between the ITF/IPTV application functions and CD&LCF
• S2 used by core IMS functions to store and get service user profiles. The profile includes end-
user information, e.g., end-user identity, security information, etc., as well as a service profile
specific to an IPTV application. It corresponds to the Cx reference point defined in [ITU-T
Y.2021]
• S3 used by the core IMS functions to request RACF for the control of transport resources. It
corresponds to the Rs reference point as defined in [ITU-T Y.2111]
• S4 used by core IMS functions to interact with NACF in order to retrieve information related
to the IP connectivity access information (e.g., physical location of the ITF). It corresponds to
the S-TC1 reference point as defined in [ITU-T Y.2012].
• S5 used to exchange messages for session management, e.g., session establishment,
modification or termination
Annex A is about “Relationship between IPTV and NGN architectures”. It provides a functional
mapping between NGN-based IPTV and NGN functional architectures.
Appendix I is about “Procedural flows relating to IPTV services”. These procedural flows are intended
as illustrative examples of interactions between functional blocks and functions.
There are two main approaches to timing of the allocation resources:
• Tightly coupled: The delivery and network resources are allocated and released at the
request of the application during the transactional phase of the service.

Green book on IPTV Page 12 / 64

 Version 0.5

• Loosely coupled: The delivery and network resources are allocated in response to the
establishment of the streaming protocol session and released when this streaming protocol
session is terminated.
High level procedural flows are provided for loosely coupled content-on-demand, tightly coupled
content-on-demand, loosely coupled linear TV, tightly coupled linear TV, initialization of IPTV
application access, file-based content distribution and stream-based content distribution.
Here is a figure to illustrate the procedural flow for loosely coupled content-on-demand:

IPTV Application Content delivery and

Network functions
TF functions service control functions
Connect

Transaction protocol
OK
Select

Browser and select

Establish authority
OK
OK (Service URL)

Consume (Service URL)

Get current ITF location (Note)
Location (Note)
Consume: Set-up

Allocate CD&SF
capabilities
Request network resources

Allocate network
resources

Stream control protocol

OK
OK
Play
OK
Play

Can be triggered by abnormal

Content flow termination or timeout of
streaming session
Close

Release CD&SF
capabilities
Release network resources
Consume: Close

Release network
resources
OK
OK
Disconnect
OK
Y.1910(08)_FI-1

NOTE – Optional procedure.

Figure I.1 from Y.1910 – High level procedural flows for loosely coupled content-on-
demand
Procedural flows for IPTV services based on NGN non-IMS IPTV architectures are also provided.

Green book on IPTV Page 13 / 64

 Version 0.5

There are two ways in which the IPTV control and the content delivery functions interoperate:
• Proxy: One approach is for IPTV service control functional block to proxy all
requests between the ITF and the content functions.
• Redirect: The other approach is for the IPTV service control functional block to
request the allocation of delivery and network resources and then redirect the ITF to
communicate directly with the actual content storage and delivery functions that have
been allocated.
Procedural flows are provided for content on-demand with loose coupling and redirect, content on-
demand with loose coupling and proxy, content on-demand with tight coupling and redirect, content
on-demand with tight coupling and proxy and local programme adaptation for NGN-based linear
IPTV.
Procedural flows for IPTV services based on NGN IMS IPTV architecture are provided for VoD service
and Linear TV service.
Procedural flows for IPTV interconnection between two NGN networks are also provided.
Appendix II lists “Potential protocols that could be used on IPTV reference points”.
Appendix III deals with “IPTV physical network hierarchy”. It involves between content providers and
IPTV terminal devices:
• Super head end (SHE) network node(s) with the broadest content scope: The SHE sources
content to an entire IPTV network.
• Video hub office (VHO) network node(s) with a local/regional content scope: The VHO sources
region dependent off-air content (e.g., local programming) and houses local off-line storage of
content.
• Video serving office (VSO) network node(s) that connect end users (via access systems) to the
IPTV network
Appendix IV is about “Overlay networking function for IPTV services and multicast”.
Appendix V deals with “Adaptation of the IPTV architecture for HFC networks”.
Appendix VI is about “Nomadism for IPTV services”. Roaming in this appendix means nomadism of
the terminal device.
This appendix describes:
• Interconnection with the visited network
• Interconnection with the visited network without service control functions
• Interconnection with third party service providers

4.3 Y.1991: Terms and definitions for IPTV

Extracted summary
Recommendation ITU-T Y.1991 contains terms and definitions and a framework relevant to providing
a general understanding of IPTV. The primary purpose of this Recommendation is to provide a
context for the use of certain terms and definitions to avoid misunderstandings in IPTV and IPTV-
related activities.
Extended summary
Recommendation ITU-T Y.1991 collected terms and their definitions from other ITU-T
Recommendations.

Green book on IPTV Page 14 / 64

 Version 0.5

49 terms (with their definitions) related to requirements to support IPTV services are mainly defined
in ITU-T Y.1901 (accessibility feature, acquisition, aspect ratio, audio description, captions, channel,
etc) with just a few (7) defined in ITU-T Y-Sup.5 (application provider, content aggregator), ITU-T
M.60 (broadcast), ITU-T Q.1706 (mobility), ITU-T M.1400 (service provider), ITU-T M.3050.1
(subscriber) and ITU-T Q.1741.3 (subscription).
Among the 9 terms (with their definitions) related to IPTV architecture, 5 are defined in ITU-T Y.1910
(content provider, delivery, distribution, end-user, network provider), 3 in ITU-T Y.2012 (functional
architecture, functional entity, reference point) and one in ITU-T Y.101 (application).
Among the 7 terms (with their definitions) related to performance, QoE, QoS and traffic
management, 5 are defined in ITU-T G.1080 (channel zapping, clean audio, group of pictures, triple
play service, VoD trick modes), one in ITU-T G.1081 (platform) and one in ITU-T P.10 Amd.2 (quality
of experience (QoE)).
82 terms (with their definitions) related to metadata, terminal devices and home network are taken
from ITU-T H.761 (author, authoring tool, event, hybrid application, hybrid declarative application,
hybrid imperative application, media object, profile, stream, etc.), ITU-T J.200 (declarative
application, element, execution engine, markup language, plug-in, presentation engine, etc.), ITU-T
H.720 (distributed PVR, IPTV network, service navigation, etc.), H.721 (electronic content guide,
portal), ITU-H.701 (forward error correction), ITU-T H.622 (home network), ITU-T H.750 (metadata
fragment, metadata schema), ITU-T H.770 (service platform, set-top box, etc.).
8 terms (with their definitions) related to secondary distribution are mainly from ITU-T J.700
(enhanced broadcasting, hybrid CPE) and ITU-T J.701 (resource abstraction/middleware interface,
service components) and one from ITU-T M.2301 (provisioning).
40 terms (with their definitions) related to IPTV security aspects are extracted from ITU-T X.800
(access control, authentication, authorization, availability, key, key management, scrambling, threat,
etc.) and ITU-T X.1191 (content export, content protection, content tracing, entitlements, etc.).

4.4 Y-series Suppl. 5: Supplement 5 to Y-series Recommendations ITU-T

Y.1900-series, Supplement on IPTV service use cases
Extracted summary
Y-series Suppl. 5: This IPTV service use cases supplement provides a list of IPTV use cases that are
informative illustrations of how IPTV services can be designed, deployed and operated. From the
end-user's perspective, use cases have been categorized by distributed content services, interactive
services, communication services, etc.
Extended summary
This informative supplement describes IPTV use cases with all steps necessary to operate them.
As an example, next figure shows how the use case of linear TV with trick mode is illustrated.

Green book on IPTV Page 15 / 64

 Version 0.5

Figure 6-3 from Y-series Suppl.5. – Use case of linear TV with trick mode
Use cases are first detailed for the following “distributed content services”:
• Broadcast services
o Linear TV (including audio only, audio + video + data)
o Linear TV with trick mode
o Pay per view (PPV)
o Electronic program guide (EPG)
o Personal broadcast service
o Hybrid: Online and off-air TV delivery
o Linear TV with multi-view service
• On-demand services
o Video on demand (VoD)
o Near VoD (NVoD), video service where a program is broadcasted multiple times at
short time offsets (typically 10-20 minutes)
o Reserved delivery service (e.g. video delivery cannot be immediately carried out in
VoD, following the end-user request, but will be triggered at a later stage by some
wake-up mechanisms)
o On-demand with multi-view service (various camera angles in addition to the one
station view provided by the video on-demand service)
o Music on demand (MoD)
• Advertising services
o Traditional advertising service (Advertising content is inserted into the video stream
prior to the video being incorporated by the IPTV acquisition system and delivered to
the end-user)
o Targeted advertising (Targeted advertisements are defined according to the end-
user's preferences, usage history, personal characteristics and usage environments
and according to advertisers who want to ensure their commercials are only seen in
areas where their products or services are available)
o On-demand advertising (the end-user navigates a business advertising directory
information created and delivered by the service provider and selects an
advertisement)

Green book on IPTV Page 16 / 64

 Version 0.5

o Advertising message logging (a tool used to record information about advertising

messages, such as message text, channel, click time, etc.)
• Time-shifting and place-shifting services (IPTV content access and control (pause, rewind,
fast forward, etc.) without time limitations with two approaches: end-user-based time-
shifting service and network-based time-shifting service. Two approaches also for subscriber-
based place-shifting and network-based place-shifting)
• Supplementary content (e.g. Sub-titles and captions, audio description, Sign language
interpretation, alternative audio track for comments, etc.)
IPTV use cases are also provided for the following “interactive services” with a generic flow diagram:
• Information services (news, weather and traffic forecasts, and advertisements)
• Commercial services (to purchase goods and use financial services, such as banking, stocks,
shopping, ticketing, auctions, etc.)
• Entertainment services (games, karaoke, lottery, blog, and photo albums, etc.)
• Learning services (educational content, e.g., languages, financial skill, etc., to remote
students. Teachers and students can communicate in real and/or non-real time through
video, audio, pictures and text, etc.)
• Medical services (remote diagnosis, remote consultation, remote medical examination,
medical education, etc., in real time and/or non-real time through video, audio, pictures and
text, etc.)
• Monitoring services (health monitoring, location surveillance, etc.)
• Portal services (branded aggregation of products and services designed to satisfy a large
majority of end-users' needs, such as VoD, shopping, banking, communication,
entertainment and other interactive services with a portal menu). This use case is illustrated
by a flow diagram.
• Interactive advertising (icon shown during an advertisement to connect to a website to get
additional information on the product or "click-to-call" button to initiate a free call to
purchase the product)
For communication services, a number of well-known services are listed without detailed use cases:
messaging, telephony (i.e., VoIP), video telephony, multi-party conference calls, videoconference.
Among public interest services the following services are identified:
• Support for end-users with disabilities. It is not a stand-alone service but a feature added to
IPTV services. It is about sub-titling (language translation of the dialogue), captioning,
(transcript of sound effects and dialogue), visual sign language translation, audio description.
• Emergency communications (insertion of emergency alert notification (EAN) message in IPTV
services with all pertinent details for presentation in a way easily and quickly understandable
by the population: multiple languages in some cases, multimedia for illiterate or
hearing/visually impaired individuals)
• Community-related communications
o From public authority (announcements, bus routes, weather reports and
government services related information)
o To public authority (fire warning, medical alert and illegal house intrusion event, etc.)
o Between user groups (end-user contents, warnings)
Hosting services to allow organizations and end-users to store information, images, video, or any
content on the IPTV platforms are briefly described without any flow diagram.
Presence services allow information about end-user's location to be made available to applications
and services. The following use cases are identified:

Green book on IPTV Page 17 / 64

 Version 0.5

• Basic presence service (End-users are notified when one of their friends connects to the IPTV
service)
• Channel-based presence service (to discover buddies watching the same channel now)
• Targeted advertising based on presence service (presence information and user information
are used for targeted advertisement)
Session mobility service (Transfer of multimedia session seamlessly between different devices based
on user preferences) is detailed with a flow diagram.
A number of payment methods for accessing IPTV services are listed, namely: free, subscription, Pay
per view (PPV) or pay per use (PPU), à la carte (The end-user can purchase only the channel(s) he or
she wants to receive), cash-back point (credit acquired by using or purchasing IPTV services with real
money to be used for future payment instead of real money), package (combination of channels,
content, applications organized by the service provider).

4.5 Other Recommendations

Recommendation ITU-T Y.1902 describes a framework for multicast-based IPTV content delivery
based upon different content delivery functional models and their associated requirements. The
content delivery functional models are defined according to different methods of multicast-based
IPTV content delivery in terms of IPTV functional architecture described in Recommendation ITU-T
Y.1910. Requirements for multicast capabilities specified in this Recommendation are based on the
requirements provided in Recommendation ITU-T Y.1901.
Recommendation ITU-T Y.1911 describes scenarios and functional architecture aspects related to the
support of IPTV services in conjunction with nomadism. Recommendation ITU-T Y.1911 addresses
IPTV services supported via the use of unicast delivery.
Recommendation ITU-T Y.1920 describes a set of traffic management mechanisms which are aimed
to facilitate the efficient support of IPTV services over the network infrastructure and provides
guidelines on the use of the traffic management mechanisms in various IPTV services such as VoD
and Live TV.
Supplement 16 to ITU-T Y-series Recommendations describes the technical guidelines for the
deployment of IP multicast technologies for IPTV content delivery. The deployment guidelines
identify the technical issues and considerations regarding the capabilities of IP multicast from the
perspective of supporting the IPTV services.
Supplement 20 to ITU-T Y-series Recommendations provides mobile IPTV use cases as informative
illustrations of how mobile IPTV services can be designed, deployed and operated. The use cases are
described with sample scenarios and operational procedures of mobile IPTV services. In addition, the
use cases detail functional procedures to illustrate how the service scenarios can be supported with
IPTV architectural functions. Finally, the use cases have been categorized in terms of service aspects
and capability aspects.
Recommendation ITU-T G.1080 defines user requirements for quality of experience (QoE) for
Internet protocol television (IPTV) services. The QoE requirements are defined from an end user
perspective and are agnostic to network deployment architectures and transport protocols. The QoE
requirements are specified as end-to-end and information is provided on how they influence
network transport and application layer behaviour. QoE requirements for video, audio, text,
graphics, control functions and meta-data are provided. Compression coding schemes addressed in
this Recommendation are examples, and detailed numeric values as performance targets, e.g., bit
rate, packet loss rate, are also examples. The readers may appropriately choose or replace these
parameter values in order to be consistent with the requirements of each IPTV service context to
which they are intended to be applied.

Green book on IPTV Page 18 / 64

 Version 0.5

Recommendation ITU-T G.1081: Successful deployment of IPTV services requires performance

parameters to be monitored at a number of different points in the complete end-to-end chain,
including the customer premises, key aggregation points and at interconnect points between
disparate and service provider network domains. Recommendation ITU-T G.1081 defines five
monitoring points where such performance measurements can be made.
Recommendation ITU-T G.1082 provides a framework for improving the robustness of IPTV
performance based on the results of real-time measurements. The primary application of this
framework is to control the media and network resources based on the measurement information
and according to policy rules to support high quality of experience of IPTV services. For IPTV services,
service providers and network providers may have separate monitoring systems. Measurement
information is provided by the monitoring system. This Recommendation first describes the possible
measurement information used in different monitoring domains and the information exchanged
between providers. It then gives guidance on how to take these factors into account to adjust media
and network resources in order to maintain the quality of experience for IPTV services.
Recommendation ITU-T H.622.1 describes an architecture for home networks supporting IPTV
services and its functional requirements. In this Recommendation, home networks and IPTV-related
entities are defined, and interfaces between these entities are identified. Functions needed for the
home network to support IPTV services are described. Requirements for these functions are also
described in this Recommendation.
Recommendation ITU-T J.700: The telecommunications industry today is pursuing development of a
new generation of television services, typically called IPTV, built upon IP networking technology to
deliver integrated triple-play voice, data and video services across a converged network
infrastructure. The cable industry has a long history of successfully delivering video services over
hybrid fibre/coax (HFC) networks while adding support for data and voice through the DOCSIS and
IPCablecom architectures. Recommendation ITU-T J.700 describes the use of the IPTV mechanism,
and is intended to support IPTV services over existing cable-based secondary distribution networks
and/or other networks to enhance the existing television distribution services. This revised
Recommendation provides a clearer relationship of the IPTV architecture between this
Recommendation and Recommendation ITU-T Y.1910, and the relationship to the service provider
interface is newly described. In addition, the latest access network technologies for secondary
distribution such as radio frequency over glass (RFoG), wavelength-multiplexed video transport over
optical fibre, and hybrid use of HFC and optical fibre, are mentioned. This revision is also intended to
provide a number of editorial corrections.
Recommendation ITU-T Q.3040 describes the overall signalling architecture for IPTV control plane. It
identifies the functions, functional blocks, physical entities, interfaces, and protocols that will model
the control plane for IPTV.
Recommendation ITU-T J.704: To encourage the successive growth of television broadcasting
services, it is important to enable third-party operators to provide services by making the best use of
television distribution facilities and functionalities. Recommendation ITU-T J.704 defines functional
requirements of the service provider's interface for television primary and secondary distribution and
associated interactive services for integrated broadband cable and primary distribution television
networks. This Recommendation provides interfaces and functionalities to enable third-party service
providers to offer television and associated interactive services including RF-based linear TV, video
on demand (VoD), cable telephony, and enhanced broadcast services.
Recommendation ITU-T H.701 provides content delivery error recovery (CDER) mechanisms for IPTV
services. It details the error recovery functions in the IPTV architecture and specifies detailed CDER
mechanisms. It also provides guidelines on the applicability of the CDER mechanisms to different
IPTV services and network conditions.

Green book on IPTV Page 19 / 64

 Version 0.5

5 IPTV Security (X-series)

The security framework for IPTV security is found in the X-Series Recommendations:
– X.1191: Functional requirements and architecture for IPTV security aspects
– X.1192: Functional requirements and mechanisms for the secure transcodable scheme of IPTV
– X.1193: Key management framework for secure internet protocol television (IPTV) services
– X.1194: Algorithm selection scheme for service and content protection (SCP) descrambling
– X.1195: Service and content protection (SCP) interoperability scheme
– X.1196: Framework for the downloadable service and content protection system in the mobile
Internet Protocol Television (IPTV) environment
– X.1197: Guidelines on criteria for selecting cryptographic algorithms for IPTV service and
content protection
– X.1198: Virtual machine-based security platform for renewable IPTV service and content
protection

Recommendation ITU-T X.1191 addresses the functional requirements, architecture, and

mechanisms dealing with the security aspects of IPTV content, services, networks, terminal devices,
and subscribers (end users).

Recommendation ITU-T X.1192 deals with the functional requirements, architecture, and
mechanisms that pertain to the security of transcoding protected IPTV content. Generic security of
IPTV content is not discussed in this Recommendation.

Recommendation ITU-T X.1193 describes the requirements and architecture for key management,
including key hierarchy, for unicast and multicast IPTV services in the IPTV context. It also specifies
key management for downloadable service and content protection (SCP), if deployed. This
Recommendation does not include any other key management architecture or mechanisms
described in Recommendation ITU-T X.1191.

Recommendation ITU-T X.1194 develops an algorithm selection standard for descrambling in various
terminal devices. This Recommendation provides the general service and content
protection (SCP) architecture, security requirements and algorithm selection scheme (ASS). In
particular, the algorithm selection scheme consists of the SCP control client function, ASS
descrambler/demuxer control function and descrambler authentication function.

Recommendation ITU-T X.1195 develops a complete set of requirements for interoperable service
and content protection (SCP) to support interoperability between multiple SCP mechanisms. This
includes interoperable SCP scenarios, interoperable SCP architecture and interoperable SCP process.

Recommendation ITU-T X.1196 provides a framework for the downloadable service and content
protection (SCP) scheme in the mobile Internet Protocol television (IPTV) environment. It also
describes functional architecture and requirements for the downloadable service and content
protection (SCP) scheme for roaming in the mobile IPTV environment.

Recommendation ITU-T X.1197 provides guidelines on the criteria for selecting cryptographic
algorithms for IPTV service and content protection (SCP). It also provides a list of cryptographic
algorithms to provide confidentiality, data origin authentication and integrity for IPTV SCP services.

Green book on IPTV Page 20 / 64

 Version 0.5

Recommendation ITU-T X.1198 specifies a virtual machine-based security platform for the renewable
service and content protection (SCP) system. The virtual machine supports an abstract function of
hardware devices. This Recommendation defines a common interface and functional logic in the
Internet protocol television (IPTV) terminal device and includes the data structure of SCP client and
system components for a terminal device such as an embedded SCP, media client and control client.

6 IPTV Terminal Devices

IPTV Terminal devices are mostly specified in the H-series, while some aspects are also described in
the J-series:
– H.720 (10/2008): Overview of IPTV terminal devices and end systems
– H.721 (03/2009): IPTV Terminal Device: Basic model
– H.721 (2009) Amd.1 (07/2010): IPTV Terminal Device: Basic model: New Appendix II on
terminal device implementation example.
– J.702 (10/2008): Enablement of current terminal devices for the support of IPTV services
– J.703 (03/2010): IPTV Client Control Interface Definition
– J.705 (01/2011): IPTV client provisioning, activation, configuration and management Interface
Definition

6.1 H.720: Overview of IPTV terminal devices and end systems

Extracted summary
Recommendation ITU-T H.720 gives an overview of the architecture and functional components of an
Internet Protocol television (IPTV) terminal device and provides a high-level description of the
functionality necessary to support IPTV services. This Recommendation provides the definitions of
terminal device and end system, the location of terminal devices and end systems within the overall
architecture of IPTV, examples of IPTV services, an abstract description of the terminal device
architecture, and descriptions of other Recommendations that discuss IPTV terminal devices.
Extended summary
Recommendation ITU-T H.720 identifies basic IPTV services, namely:
• Distributed content service with service navigation (to discover, select and consume) , linear
TV and Content on Demand
• Interactive services including information services, learning services and entertainment
services
• Public interest services including Emergency alert system, closed captions, subtitles, audio
description and sign language interpretation
Advanced services that a full-fledged IPTV terminal device might be able to render are also listed:
• Linear TV with trick mode
• Personal video recorder (PVR) services (Client PVR, Network PVR and Distributed PVR)
• Advertising services (Targeted advertising, on-demand advertising)
• Audience measurement information
• Interactive services requiring high security (Commerce services, medical services and
personal IPTV broadcast)

Green book on IPTV Page 21 / 64

 Version 0.5

The key features of IPTV terminal devices are described: network attachment, service provider
discovery, service discovery, service attachment, service navigation, security, privacy, quality and
performance monitoring.
Based on the IPTV functional architecture framework defined in Y.1910, H.720 sepcifies the
functional architecture of IPTV terminal devices as shown on the following figure:

Figure 7-1 from H.720 – Functional architecture block diagram of IPTV terminal device
A brief explanation of each component/functional entity is provided with references to other
Recommendations for more details.
H.720 identifies also possible terminal device interfaces as shown on the next figure.

Green book on IPTV Page 22 / 64

 Version 0.5

Figure 8-1 from H.720 – Examples of IPTV terminal device interfaces

H.720 describes also an overview of the IPTV terminal software architecture as shown on the
following figure:

Figure 9-1 from H.720 – IPTV terminal software architecture – Overview

Appendix I lists a number of ITU-T Recommendations which should be developed based on this
Recommendation: “IPTV terminal devices for basic services” (published as H.721), “IPTV terminal
device full-fledged model” and “IPTV terminal device mobile model”.

6.2 H.721: IPTV Terminal Device: Basic model

Extracted summary

Green book on IPTV Page 23 / 64

 Version 0.5

Recommendation ITU-T H.721 describes and specifies the functionalities of the IPTV terminal devices
for the IPTV basic services defined in Recommendation ITU-T H.720. This Recommendation is
targeted at IPTV terminal devices capable of receiving linear TV service and video-on-demand
services, with additional data content (such as text) using a managed content delivery network. The
service definition takes into consideration conditions on content delivery such as QoS. The expected
types of IPTV terminal devices are set-top boxes and digital TV sets with embedded IPTV capabilities.
Amendment 1 introduces new Appendix II, which describes implementation examples that support
ITU-T H.721 terminal device specifications.
Extended summary
Using the same structure as Recommendation H.720, H.721 provides a list of applicable
specifications for each basic IPTV service defined in H.720, namely:
• Linear TV: video (MPEG-2, H.264), audio (MPEG-2 AAC, MPEG-1 Layer II), captioning (ARIB
Captioning, ATSC Closed Captioning, EBU Teletext Subtitles, DVB Subtitling), Multiplex format
(MPEG-2 TS, TTS), streaming (RTP)
• Content-on-demand : video (MPEG-2, H.264), audio (MPEG-2 AAC, MPEG-1 Layer II, MPEG-4
HE AAC v1, Dolby AC-3), captioning (ARIB Captioning, ATSC Closed Captioning), Multiplex
format (MPEG-2 TS, TTS), streaming (RTP, RTSP)
• Service navigation and content selection using remote controller, EPG, ECG or portal service
• Interactive services: same presentation and control functionalities as for Linear and content-
on-demand services
• Public interest services: Closed caption, subtitles, audio description and sign language
interpretation may be provided alongside with all of the above-mentioned basic services
with accessibility
Applicable Recommendations are listed for the following features of the basic IPTV terminal device:
• Terminal device attachment and initialization. Applicable protocols are : IP, ICMP, IPv6,
ICMPv6, DHCP, DNS
• Service provider discovery and service attachment : Multiplex format (MPEG-2 TS, TTS),
streaming (RTP, RTSP), Multicast (IGMPv2, MLDv2), Unicast (HTTP)
• Security: Secure Communication (SSL/TLS), Encryption Algorithm (AES, CSA)
• Quality of Service: error correction (H.701), clock synchronization and jitter removal
(solutions described in appendix I)
Media control functional block is required to support playback, stopping and pausing, fast-forwarding
and rewinding of VoD contents either using specialized contents or usual contents. It can optionally
support the skip forward and skip backward functionalities, chapter playback functionality for VoD
contents.
For video, the following resolutions are required to be supported:
• ITU-T H.262: 1920x1080i MP@HL, 1440x1080i MP@HL, 1280x720p MP@HL and 720, 544,
480x480i MP@ML
• ITU-T H.264: 1920x1080i [email protected], 1440x1080i [email protected], 1280x720p
[email protected], 720x480i [email protected]/3.1/3.2, 720x576i (the format used in
Europe)
Temporary and permanent data to be stored in the storage functional block are listed.
The Recommendation describes as well the operation of the service protection and content
protection functional blocks.
For IPTV application client functions a reference is made to H.760.

Green book on IPTV Page 24 / 64

 Version 0.5

For SADS client functions a reference is made to H.770.

Physical interfaces are listed but only reset button and remote controller interfaces are
recommended to be supported by the basic model, other interfaces are optional.
Appendix I provides an overview of the “Clock synchronization and jitter removal” issue and specifies
a solution for “Time-stamped TS (TTS) clock reconstruction”.
Appendix II provides implementation examples of ITU-T H.721 terminal device (TD) specifications
supporting linear TV, video on-demand, and interactive services.

Figure II.1 from H.721 – Implementation example of the IPTV terminal functions
It shows in more details how terminal functions communicate with each other above the applicable
delivery protocols listed in the main body.

6.3 J.702: Enablement of current terminal devices for the support of IPTV
services
Extracted summary

Green book on IPTV Page 25 / 64

 Version 0.5

Recommendation ITU-T J.702 describes an IPTV terminal device (IPTV TD) that enables a migration
path for the support of basic IPTV services, for current terminal devices used for other TV delivery
services. This Recommendation identifies architectures and functions needed for the IPTV TD to
support basic IPTV services, and is intended to meet immediate demands of current TV delivery
services to rapidly deploy basic IPTV services.
Extended summary
Starting from existing TV devices, J.702 identifies what has to added to enable them to support basic
IPTV services.
Based on requirements and recommendations identified in ITU-T Y.1901, J.702 defines the basic
services that the IPTV TD is recommended to support, namely:
• Content delivery service: Service navigation, Linear TV, Content on-demand
• Interactive services: information services, commercial services, entertainment services (e.g.,
games, karaoke, etc.), learning services, medical services, monitoring services, portal
services, etc.
• Public interest services: Accessibility features, emergency telecommunications, regulatory
information services, provider selection and number portability.
The IPTV TD is required to support national regulations, if any.
Functional requirements are listed with applicable Recommendations:
• Network attachment (ITU-T J.293 is recommended to be supported
• Service discovery (ETSI TS 102 034 (DVB-IPI) and service information (SI) of the MPEG
transport stream are recommended to be supported)
• Service navigation (recommended capability, metadata described in ITU-T H.750 is
recommended with caching and searching capabilities, parental control functionality is
recommended)
• Provisioning and management (support recommended, polling and report-back should
be supported, recommended accounting and management, software download and
upgrade capability is recommended)
• Service and content protection: TD authentication, physical tamper-resistance for TD
and secure means for performing security critical processes in TD are required, clause
6.5 of ITU-T X.1191 is recommended to be supported)
• Privacy: following items are recommended to be securely handled within the IPTV
TD: viewing history, return/interaction channel usage and audience measurement
information, history of interactive operation, personal profiles and preferences and ID
number with reference to clause 6.6 and annex A of ITU-T X.1191
• Video content: support of commonly used video formats is recommended with
optional capability for regional video and graphics output (e.g. NTSC, PAL, SECAM)
and HDMI outputs
• Audio content: support of commonly used audio formats is recommended, audio
transcoding is optional
• Diagnostics: monitoring capabilities to provide diagnostic information about
configuration and operation are recommended to be supported
• Network architecture: one of them is required to be supported: "Non-NGN IPTV
functional architecture", "NGN-based non-IMS IPTV functional architecture" and
"NGN IMS-based IPTV functional architecture"

Green book on IPTV Page 26 / 64

 Version 0.5

The IPTV terminal device functional architecture is introduced with a figure representing the
Functional architecture block diagram for IPTV terminal devices very similar to the figure above in
H.721 with the same title.
All functional blocks are described.
The IPTV TD is required to support RTSP for the delivery of unicast on-demand content or for the
support of linear TV with trick mode, and the remote control of a streaming media server.
Error recovery functional entity is recommended based on retransmission, forward error correction
(FEC), or hybrid combinations of both.
The terminal device management functional entity provides the functions "provisioning and
management" and "diagnostics".
Home Network interface is optional.
Possible interfaces are identified and described with the same figure as in H.720. For the definition of
many interfaces reference is made to ITU-T J.293.
The IPTV terminal software architecture is presented with the same figure as in H.720.
Two basic configurations are defined for the basic IPTV terminal device :
• "basic IPTV-centric terminal device configuration" (no broadcast reception, no PVR)
• "basic IPTV-centric terminal device with PVR".
Annex A defines the baseline functionality for support of basic IPTV services, and optional step-up
functions
Annex B is about content selection.
At least one of the following audio codecs is required to be supported: MPEG-1 Layer II, AC-3, MPEG-
2 AAC.
At least one of the following video codecs is required to be supported: MPEG-2, H.264/AVC.
Appendix I provides a list of codecs that might be supported by the IPTV terminal device for IPTV
content coding for content delivery services and for IPTV applications on interactive services.
Appendix II is about VBI data processing. The IPTV TD should be capable of passing through,
extracting, decoding and rendering vertical blanking interval (VBI) lines carried in an encoded content
stream and should make the VBI data available to the operating system and applications for
processing.
Appendix III presents service flow charts of interactions between applications, service
platforms and terminal middleware for software upgrade, boot-strap and initialization, service
authentication, living broadcast service, time-shift service, VoD service, log upload, status report and
configuration.
Appendix IV describes how the IPTV TD can use the service/system information to find out where on
the network to access any content that the user selects.
Appendix V is about service discovery schemes. The service provider discovery is based on a three-
layered record structure containing the network provider configuration record, the service provider
discovery record and the service discoveryrecord.
A comparison is made between ETSI TS 102 034 (DVB-IP) and Japan.

6.4 J.703: IPTV Client Control Interface Definition

Extracted summary

Green book on IPTV Page 27 / 64

 Version 0.5

Recommendation ITU-T J.703 defines the interface that enables the service client in the customer's
network to send requests for content and application transport using Internet Protocol (IP)
technology to the Internet Protocol Television (IPTV) service functions in the operator's network.
Examples of IPTV content include digital video and audio programme content, including the
metadata describing the programme content. Examples of IPTV requests include requests for
broadcast or video on demand (VoD) content, requests to manipulate VoD content delivery (pause,
play, rewind, etc.), and requests to record content for later viewing.
Extended summary
The scope of this Recommendation is the i-3 interface between service client in the customer
network and IPTV Service Functions in the operator network, shown on the figure below.

Figure 1 of J.703 – IPTV network reference points

The i-3 interface enables the service client in the customer's network to send requests for content
and application transport, using IP technology to the IPTV service functions in the operator's
network.
Examples of content and application to be requested through the i-3 interface include digital video
and audio programme content, including the metadata describing the programme content, and
applications to be presented or executed at the service client.
There are requests for broadcast or VoD content, to manipulate VoD content delivery (pause, play,
rewind, etc.), and to record content for later viewing.

Green book on IPTV Page 28 / 64

 Version 0.5

The Recommendation describes and specifies operation modes and protocols for the foolowing
issues, namely:
• Client sign-on. The operator provides information about itself and its network topology to
CPEs using a set of IP multicast flows. The first multicast flow is the system-wide flow at a
well-known IP multicast address. It contains IP names or address of the various IPTV
application functions and servers in the system and a code download list that tells the set-
tops in the system when to upgrade boot and client code. The operator assigns each CPE in a
system to a cluster (permanently joined multicast flow from CPE) and each cluster to a hub
(multicast flow for system information or service information (SI) table delivery).
DSM-CC (ISO/IEC 13818-6) UNPassThru messages are used for change notifications.
• CPE booting. The booting process is described step by step. First, the boot loader must obtain
an IP address using DHCP and check for a new code. If a new code is available, the boot
loader must obtain the new code from the service functions, then boot the new code.
Second, the boot loader must start the video applications (client code).
• System information or service information management. System information or service
information (SI) acquisition can be done on a hub-by-hub basis over the hub multicast flow.
CPEs can be placed in individual hubs and different services can be provided and provisioned
to different CPEs (and subscribers) based on hub.
• EPG acquisition and management. The EPG is acquired by the CPE, it is parsed and presented
to the end-user for selection. Then the referenced system information (SI) is used to acquire
the service as directed. ITU-T H.770 provides the method for service discovery, using EPG
data acquisition and management.
• Emergency alert service. Only relevant to deployments in the United States. Emergency alert
messages (EAMs) are sent to the appropriate group of set-top boxes using a DSM-CC
UNPassthru message on the cluster multicast flow.
• Broadcast/multicast content signalling. The IPTV client accesses broadcast/multicast content
using IGMP procedures (IETF RFC 3376). Using source specific multicast (SSM), clients specify
a source and a group (S, G) when sending a join message to request a stream. Client must
support IGMPv3.
• On-demand content signalling. The IPTV client accesses on-demand content using either
RTSP (IETF RFC 2326) or DSM-CC (ISO/IEC 13818-6) for content session setup and control. On-
demand, content catalogs can be browsed from the CPE using HTTP or HTTPS protocols, with
the on-demand catalog returning XML formatted metadata query results.
• Admission control and policy management. There are three options currently available for
admission control. First, the RSVP can be used as on path admission control for applications
that support it. Second, application-based rate limiting (as known as application admission
control) can be used to manage bandwidth within a manually provisioned partition. Third, a
feature called "multicast rate limiting" can be used to limit the multicast bandwidth used on
certain links.
Multicast rate limiting can be used in conjunction with any of the access link QoS models
below.
o Fully provisioned. The access line is sized such that all available service provider
video streams can be carried simultaneously.
o Under provisioned with application admission control in home. The next level is to
support limited oversubscription of service provider video of the access line, with
admission control done in the home.
o Under provisioned with home-to-network admission control. The next level is to
support oversubscription of service provider video on the access network, with
access line admission control done between the home and the service provider's
network.

Green book on IPTV Page 29 / 64

 Version 0.5

In each of these models, the service provider uses a diffserv marking for its video traffic so
that this traffic can receive appropriate QoS treatment.

Potential supporting protocols include IGMP/MLD [IETF RFC 3376], RTSP [IETF RFC 2326], SDP and
DSM-CC [ISO/IEC 13818-6].

Appendix I is about IPTV client bootup sequence. It shows a high level example flow diagram
illustrating fundamental steps in the IPTV client bootup sequence adapted from ATIS-0800017.

6.5 J.705: IPTV client provisioning, activation, configuration and

management Interface Definition
Extracted summary
Recommendation ITU-T J.705 describes the i-2 interface, identified in Recommendation ITU-T J.700,
that enables the service client in the customer network to interface with the operations support
systems (OSS) functions in the operator network to provision and manage the IPTV client functions in
the customer network. Examples of OSS functions include client provisioning, activation,
configuration, and management (PACM).
Extended summary
The i-2 interface and other IPTV network reference points are shown on the same figure already
included above in the presentation of Recommendation J.703.
The following types of functions are supported over the interface:
1) Configuration functions at the network level,
2) Accounting management,
3) Security management,
4) Fault management in the CPE
In particular, the following functions are supported, aligned with (ATIS-0300092):
a) Service(s) management including messaging, and management of 3rd party applications.
b) CAS/DRM control processing and client handling (complementing i-3).
c) Event accounting, e.g., pay per view.
d) Subscriber resource management,
e) Service quality and performance management, through [BBF TR-069] ACS or other probes (e.g.,
channel changes, dropped packets, MPEG); and VQE statistics.
f) CPE and RG management (remotely), including secure software download and settings,
g) Service problem management and resource trouble management
Potential supporting protocols include the following: HTTP, XML, XCAP for Web services, SIP for
configuration framework, TFTP for client configuration, TR-069, SNMP, OMA DM, DSM-CC for data
carousel; polling and report back for event accounting, DHCP used in discovery, UPnP used in
discovery.
For reporting, at least one of the following protocols is required to be supported by the CPE if it is
designed for the use with an embedded-DOCSIS cable modem.

Green book on IPTV Page 30 / 64

 Version 0.5

• SNMPv3 defined in IETF Standard 62 [IETF RFC 3411] through [IETF RFC 3418]
• SNMPv1/v2c coexistence [IETF RFC 3584]
• SNMPv2 community-based access [IETF RFC 1901]
If the CPE uses a baseband IP communication method such as Ethernet, one of the following
protocols is required to be used: HTTP version 1.1 [IETF RFC 2616], HTTP over TLS [IETF RFC 2818],
TFTP [IETF RFC 1350] or TCP [IETF RFC 793].
For event accounting, it is required to support the following (service control layer) event accounting
through the i-2 interface between a head-end controller and a CPE:
• PPV purchase information;
• CPE internal event, e.g., panic dump, system error;
• CPE internal log, e.g., keypad press history of remote control.
As a protocol for event accounting, it is required to use HTTP over TLS [IETF RFC 2818].
For secure software download. The CPE should support software download and upgrade capability
using methods such as in-band DSM-CC carousels, multicast IP, or TCP/IP.
Non-DSM-CC solution : The authentication aspects for secure software download shall follow [ATIS-
0800014] and the protocols used by a terminal device for software download shall follow [ATIS-
0800009] (which are based on [BBF TR-069] and [ETSI TS 102 824]).
DSM-CC solution: The different steps for software download are described and illustrated by flow
diagrams on : CPE component version determination, CPE component download, CPE component
validation, CPE recovery from error and CPE download monitoring.
In a cable TV network, CPE using DOCSIS software upgrade mechanisms should follow the
specification for privacy on the DOCSIS channel and authentication of the software image.
For a CPE with wireless WAN-based access (such as a hybrid set-top), the firmware upgrade protocol
shall follow [OMA DM FUMO] (Firmware Update Management Object).

7 IPTV Middleware
Currently, there are two middleware Recommendations defined for IPTV:
– H.730: Web-based terminal middleware for IPTV services
– J.701: Broadcast-centric IPTV Terminal middleware
Recommendation ITU-T H.730: Web-based terminal middleware (WBTM) defines the functional
interfaces for high-level resource management over an IPTV terminal device and describes the
structure of a web-based presentation engine, which basically supports IPTV multimedia application
frameworks in the ITU-T H.76x series of Recommendations. Web-based IPTV terminal middleware is
based on ITU-T IPTV functional architecture and ITU-T terminal devices in the H.72x series of
Recommendations. ITU-T web-based IPTV terminal middleware is necessary to support basic and
advanced interactive IPTV services for IPTV terminal devices.
This Recommendation also describes the general WBTM requirements for IPTV services and any
additional functionality for basic and advanced IPTV services. Annex A summarizes the general
requirements.
Recommendation ITU-T J.701 defines components of a broadcast-centric IPTV terminal middleware
and provides a high-level description of functionality necessary to support IPTV services. These
definitions and descriptions are intended to provide a migration path from existing terminal

Green book on IPTV Page 31 / 64

 Version 0.5

middleware for current digital broadcasting, with enhancements for IPTV support, to meet
immediate market demand to deploy IPTV services. This Recommendation also describes the
terminal middleware architecture and its relationship with the service platform. Additionally, this
Recommendation provides a table of application programming interface (API) classifications.

8 IPTV Application Event Handling (with big emphasis on AM)

IPTV application event handling is defined in the H.740-subseries. While H.740 is general in nature,
the H.740-subseries specify how to perform audience measurement in the context of IPTV services:
– H.740 (03/2010): Application event handling for IPTV services
– H.740 (2010) Amd. 1 (03/2011): Application event handling for IPTV services: New video
handling sensor event scenario in Appendix II
– H.741.0 (03/2012): IPTV application event handling: Overall aspects of audience measurement
for IPTV services
– H.741.1 (06/2012) and Amd. 1 (01/2013): IPTV application event handling: Audience
measurement operations for IPTV services
– H.741.2 (06/2012): IPTV application event handling: Data structures of audience
measurement for IPTV services
– H.741.2 (2012) Amd. 1 (11/2013): New Appendix I with XML schema on the data structures of
audience measurement for IPTV services (note: not yet published)
– H.741.3 (06/2012): IPTV application event handling: Audience measurement for IPTV
distributed content services
– H.741.4 (06/2012): IPTV application event handling: Transport mechanisms for audience
measurement
– HSTP.IPTV-AM.101 "Introduction to H.741- series – A video engagement audience
measurement standard" (note: not yet available for download).
– J.706 (01/2012): Overview of the distribution of target-specific content (Note: location to be
confirmed: architecture, application event handling or application)
– J.707 (01/2012): Messages and protocols enabling the distribution of target-specific content
within integrated broadband cable networks (note: location to be confirmed with J.706)

8.1 H.740: Application event handling for IPTV services

Extracted summary
Recommendation ITU-T H.740 provides a framework for application event handling for IPTV, such as
emergency alert and audience measurement. This Recommendation provides a basic framework for
application event model, application event description and notification, metadata model, delivery
methods and security mechanism for application event for IPTV.
Amendment 1 includes a new use case about a video handling sensor event. This event can be used
as supplemental information on audience measurement and other IPTV applications.
Extended summary
Every user interaction or every occurrence related to multimedia content in IPTV is called an event
(e.g. video play start, button press, changed in metadata). Application events are events detectable
at the application level.

Green book on IPTV Page 32 / 64

 Version 0.5

Application events can be used for audience measurement, intelligent charging (only on what has
been consumed), target marketing, personalized service by user's behaviour, commerce, monitoring
of illegal copies, proof of purchase, managing of network bandwidth, or an emergency alert
notification (EAN).
The application event handling model is introduced. Application events have at least two
components: a description and a communication way.
There are two strict requirements for emergency events (no turn-off by end-user for incoming
events, no turn-off by terminal device for outgoing events). For other events, it is recommended to
enable the user to turn on or off events with privacy information.
The high level architecture illustrates the application event live cycle, as it consists in a sequence of 5
functional blocks: generation, recognition, notification, reception, consumption.
The application event description is detailed and may contain:
Recommended elements for application event metadata are identified and described as follows:
• Event message identifier (unique)
• Message type with values: "Notification", "Update", "Cancel", "Ack" or "Error”
• Identifier(s) of referenced message
• Event information: event description, event data recommended to be encoded as set of
pairs of parameters (name and value), event time and date, resource (file with additional
event information with resource description, MIME time, size and URI)
• Expiry date
• Sender information (globally unique identifier and some additional elements such as
sender's name, location and descriptive information)
• Recipient information (same structure as the sender information)
• Forward information (to identify the entity which receives the forwarded event description
message)
For emergency event, the common alerting protocol (CAP) [b-ITU-T X.1303] can be used. It is an
extensible mark-up language (XML) [b-W3C XML] based data format for exchanging public warnings
and emergencies between alerting technologies.
When application events are related to user privacy information, privacy protection laws in each
country, region and/or those described in IPTV or interactive broadcasting related Recommendations
such as [b-ITU-T X.1191] and [b-ITU-R BT.2052] need to be respected. This means end-user
permission is required.
Appendix I is about “Delivery methods”. It is recommended to encode metadata in XML, application
event record can optionally be encoded in XML and compressed.
Delivery of application event and metadata over IP can use HTTP version 1.1 [b-IETF RFC 2616] or
TFTP [b-IETF RFC 1350] over unicast, HTTP over TLS [b-IETF RFC 2818] over secured unicast, but
without limitation to them.
Appendix II deals with “Scenarios for application event handling”.
Three scenarios are described with flow diagrams:
• Emergency alert notification scenario (to notify the public about disasters such as
earthquakes, fires, typhoons, snow storms, or catastrophic flooding)
The emergency alert notification should include: kind, rate, affected area, time, instructions,
etc.
• Interactive advertisement and T-commerce notification scenario (interaction with TV content
to trigger a request to purchase background music or to get additional information)

Green book on IPTV Page 33 / 64

 Version 0.5

The event notification should include: user info, time, program info, commerce info,
advertisement info, etc.
• Audience measurement application scenario (e.g. to inform service provider whenever end-
users change channel to measure channel audience and/or to track popular programs)
Event notification should include: channel number before and after channel change, time of
change, end-user information, etc.
Amendment 1 added a fourth scenario to Appendix II.
• Video sensor devices event scenario (A video sensor is a device that generates information
such as gender and age of persons, their emotions, or their number and movements, by
processing video data captured by a camera. This can be used to refine audience
measurement or to switch off unwatched television sets to reduce electric power
consumption)

8.2 H.741.0: IPTV application event handling: Overall aspects of audience

measurement for IPTV services
Extracted summary
Recommendation ITU-T H.741.0 defines a foundational platform for audience measurement (AM) of
Internet Protocol television (IPTV) services. This Recommendation focuses on the interface between
terminal devices (TDs) and an audience measurement aggregation function.
The AM platform integrates a method for end users to report personal information, and is designed
to easily add time-shifted and interactive services, and non-terminal device measurement points.
While ITU-T H.741.0 allows the implementation of audience measurement for IPTV services, its
mechanism may be equally applicable to non-IPTV services.
The audience measurement mechanism specified here provides additional benefits when compared
to traditional audience measurement. Such benefits include, in particular, a larger audience
population sample, more detailed engagement metrics, passive data collection, and feedback for the
enhancement of services.
The design philosophy in ITU-T H.741.0 is focused on scalability, on minimizing the use of resources,
on optimizing security, on flexibility to support a variety of service provider deployments, and on a
rich set of privacy settings to meet emerging regulations and legislation.
The ITU-T H.741 sub-series of Recommendations defines a foundational platform for audience
measurement (AM) of IPTV services. They focus on the interface between terminal devices and an
audience measurement aggregation function.
Extended summary
Recommendation ITU-T H.741.0 starts with an overview.
When an end-user consumes an IPTV service, audience measurement (AM), implemented by an IPTV
application, collects data about the end-user behaviour with his/her permission including audience
presence and engagement. Measurement services may be provided in real-time or offline.
The targeted IPTV services for audience measurement include:
• Distributed content services such as linear TV, video on demand (VoD), network
personal video recorder (n-PVR), and consumer personal video recorder (c-PVR).
• Interactive services such as games, learning, commerce, and information access.
Requirements on the audience measurement architecture are listed staring with 20 strict
requirements (e.g. ability to measure selected services, events, to select users to be measured, to
ensure confidentiality and integrity of end-user data), 16 recommended (broad granularity of

Green book on IPTV Page 34 / 64

 Version 0.5

measurements, daily change of measurement configuration, recovery from storage or network

congestion) and 6 optional (ability to configure on a per user basis, a per content basis, or a
combination of both, presence detection).
End-user may optionally restrict audience measurement by configuration of measurement permits
based upon service type (e.g., linear TV, VoD, PVR), content type (e.g., children's TV, adult TV,
religious, political, etc.), event type (e.g., channel change, record, etc.), end-user type (e.g., children
under 13, adults, etc.), device type (e.g. TV, mobile phone, etc.), etc.
There are also requirements for IPTV architecture such as mechanism for discovery of multiple
audience measurement services, ability for the user to select a particular audience measurement
service.
The audience measurement architecture is illustrated by the following figure in which audience
measurement functions (AMF), potentially located in different functional blocks of the IPTV
architecture (terminal device, home network, service control, content delivery or network), measure
the end-user behaviour and deliver this information to aggregation functions.

End-user Application functions

functions
Aggregation
IPTV functions
terminal
functions
TD-AMF

Home Service control functions Content delivery

network functions
functions
SC-AMF CD-AMF
HN-AMF

N-AMF Network functions

H.741.0(12)_F01

Figure 1 from H.741.0 – Audience measurement components within IPTV architecture

This Recommendation specifies IPTV audience measurement only for terminal device audience
measurement functions (TD-AMFs).
The audience measurement lifecycle is described from service discovery, permit inputs, orders from
stakeholders (e.g. content providers, advertisers, etc.), TD-AMF configuration by aggregation
function, AMF measurement reports to aggregated reports to stakeholders.
The following figure illustrates the interfaces of the audience measurement and aggregation
functions

Green book on IPTV Page 35 / 64

 Version 0.5

Permission messages
from user or SP

Orders (order details, directives

Audience AM messages Aggregation and management)
measurement
functions Aggregated reports
functions

H.741.0(12)_F02
Discovery Client Server applications
applications

Figure 2 from H.741.0 – Information interfaces associated with the operation of AM

The configuration of terminal device audience measurement functions (TD-AMFs) may be initiated by
either the TD-AMF and/or the aggregation functions. Message sequences are used to illustrate both
cases.
Measurement reporting may be initiated also by either the TD-AMF and/or the aggregation
functions. Four types of delivery modes can be configured:
• Immediate Push Mode (only a short delay to send reports is allowed for traffic efficiency)
• Delayed Push Mode (reports are stored and sent later in a delivery window staring at a
randomized time for traffic shaping)
• Pull Mode (only on request from aggregation function)
• Delayed Push and Pull Mode (reports are stored for later delivery but reports can also be
requested at any time)
Three permission modes are possible and the permission mode to be used is discovered during the
AM discovery process:
• External permission mode: no end-user permits are used at TD-AMFs.
• Internal permission mode: permits are created at TD-AMFs and delivered to the TD-
AMF separately from the configuration messages.
• Hybrid permission mode: The TD-AMF requests permits from the IPTV SP and
receives them separately from configuration messages.

Appendix I deals with “Potential relationships between end users, audience measurement service
providers and content distribution service providers”.
As audience measurement services may be provided by IPTV service providers or independent
providers. These roles may be distributed in different ways in the real world and this appendix
identifies a number of possible configurations, namely:
• Service provider offering both content distribution and audience measurement services
• Separate audience measurement service and content distribution service providers (e.g. the
same Linear TV channel is distributed by two IPTV service providers but there is only one
audience measurement service provide by one of the service providers)
• Multiple audience measurement service providers (in this case end-users can choose the
audience measurement service they prefer)
Appendix II is about “Context of audience measurement”. It provides an example to show how AM
might fit into a larger context with stakeholders (service providers, content providers,
advertisers/agencies, programmers, and audience research companies) providing measurement
orders to a measurement management function relating to the aggregation functions to ask for

Green book on IPTV Page 36 / 64

 Version 0.5

measurements and to get aggregated reports. Interfaces are shown with other IPTV functions for
both aggregation functions and audience measurement functions.

8.3 H.741.1: IPTV application event handling: Audience measurement

operations for IPTV services
Extracted summary
Recommendation ITU-T H.741.1 specifies the operations of AM, including procedures prior to
configuration of terminals, configuration of terminals, reporting by terminals, security mechanisms,
and recovery from abnormal situations. Informative Appendices I-VII discuss discovery metadata,
implementation considerations, examples, permission levels, vendor considerations, alternative
privacy schemes, and discuss capabilities and profiles.
Amendment 1 to Recommendation ITU-T H.741.1 (integrated into this edition) includes XML schema
on audience measurement service discovery in Appendix VIII and XML schema instances for TD-AMF
configurations, reports and permits in Appendix IX.
Extended summary
The Recommendation ITU-T H.741.1 starts with the description of the preconfiguration which is the
first step in the audience measurement lifecycle, in which the terminal device discovers, selects and
connects to an IPTV service provider. The discovery of service providers and their services are
described in [b-ITU-T H.770].
The sequence of operations leading to configuration of audience measurement functions by
aggregation functions following connection to an IPTV service provider for the first time is shown on
a figure. This Recommendation describes how TD-AMFs are provided with audience measurement
configuration package not already obtained from discovery, to participate in audience measurement.
As this configuration package may change over the time, mechanisms to get updated information are
describes for all configuration modes (pull, push, pull and push), with the introduction of a package
check delay to trigger subsequent checks for availability of a new configuration package.
The next step is the effective configuration of the TD-AMF, which is the result of constraining the
received configuration package(s) with an effective end-user permit if present.
The configuration package is then described. Configuration packages are sent to TD-AMFs for
immediate use, or sent in advance with an operation start time. Components of a configuration
package are:
• Package header (depending on message delivery mode)
o Common elements: message-expiration time, version, compression algorithm,
identifier, start time, configuration package check delay
o Multicast-specific elements:
Filtering element. There are four ways to define targeted subsets of TD-AMFs
which are to process the associated configuration packages (lower and upper
thresholds in between a random number generated by the terminal device
has to be to process the configuration package, device type(s), MAC
addresses or match with end-user information, e.g. occupation= doctor,
income above 100000 USD)
Ack request (optional)
Error reporting (optional)
• Measurement requests. Measurement requests contain services to be measured,
measurement schedules, events and sample values to be measured, and measurement
report message delivery schedules. Reference is made to [ITU-T H.741.2] for corresponding
metadata elements.

Green book on IPTV Page 37 / 64

 Version 0.5

o Services to be measured: linear TV (with channel identification), VoD or cPVR

o Content classes to be filtered: e.g. genres as defined by different organizations which
may indicate children's TV, adult TV, religious and political programmes, etc.,
o Measurement schedule(s): duration of time during which measurements may occur.
Multiple measurement periods are possible within a day, or cross the boundaries of
a single day, independently for each day of the week
o Elements to be measured (events and sample values).
“Service-common" events and samples are defined for two or more specific services
in [ITU-T H.741.2].
"Service-specific" events and samples apply to one specific service. They are defined
in [ITU-T H.741.3].
Three types of measurement trigger can be used: event name, scheduled sample
time or service start (to get slowly changing information with the first IPTV service
started every N days). A list of elements to be reported is associated to each trigger.

The following figure illustrates what is meant by “measurement period” or

measurement schedule, “service period” in which an IPTV service is consumed,
“effective measurement period” in which measurement reports are generated, and
“periodicity” for sampling time.
Measurement period
Service period
Effective measurement period
Periodicity Periodicity
Sample Sample
time time
Event Event Event
Start End
time time
H.741.1(12)_F14

Figure 14 from H.741.1 – Sample values and events are measured within the
effective measurement period
Priority is associated to each generated measurement report to be used in case of
measurement storage congestion
o Filtering and summarization (to reduce measurement reporting traffic).
Duplicate sample value may either be ignored and not reported, reported as empty,
or reported normally.
Reporting a count of identified events without event details is made possible.
o Measurement report delivery schedule. Four types of delivery modes are possible:
immediate push, delayed push mode (in a schedule window), pull mode (only on
request from aggregation functions), delayed push and pull mode (schedule window
and request from aggregation functions).
o Parameters are “delivery address(es)” and “retransmit number”.
End-user privacy policies may be expressed within end-user permits. An end-user permit may contain
an expiration date, a default permission level, and a default content restriction list. The user permit
may limit the audience measurement requests included in the configuration package.
There are three possible permission modes (i.e. external permission mode, internal permission mode
and hybrid permission mode) and the TD-AMF learns of which permission mode to use from the
discovery process.
Specific measurement reporting issues are described:

Green book on IPTV Page 38 / 64

 Version 0.5

• Reporting of services which start or end outside measurement periods (e.g. a

ServiceInstanceID is generated when a service starts even if outside of measurement period)
• Reporting surrounding restricted content (measurements stop when restricted content starts
to be played and a service stop event report is generated)
• Reporting of user presence (detected presence reported only when the effective permit (if
available) grants permission)
• Reporting changes due to effective permit changes (measurements and reports shall
immediately reflect permission changes)
• Reporting of storage congestion (indication of measurements dropped due to storage
congestion and priority is to be reported within the measurement report message)
The next chapter addresses “Security, privacy and permission mechanisms”.
AM messages, if left unprotected, unverified, and unauthenticated will allow an adversary to
compromise the very intention of audience measurement.
The TD-AMF and AGF are required to authenticate each other directly. Before sending a request
message, the TD-AMF or AGF authenticates itself to the other party using transport layer security
(TLS) [IETF RFC 5246] which makes use of ITU-T X.509v3 [ITU-T X.509] digital certificates.
In order to safeguard end-user privacy, it is required that all unicast AM messages be encrypted. It is
recommended that all multicast AM messages be encrypted. The choices of cryptographic protocols
for confidentiality are indicated in the capabilities profile and in the discovery data structure.
In order to ensure that the AM messages are not modified by an attacker, every AM message has its
own expiration time. Every multicast message also has its own cryptographic digest (SHA-256) and a
digital signature (RSA-1024).
In order to ensure the authenticity of AM information, the inclusion of signatures in AM reports
provides non-repudiation.
In order to support privacy, it is recommended that the protection of end-user information and
identity, and AM message unlinkability, be supported.
Security methods and corresponding algorithms are summarized in a table for upstream and
downstream AM messages to ensure authentication, confidentiality and integrity.
The chapter “End-user permission operation modes” describes with permission flow diagrams the
three possible permission modes, namely:
• External permission mode in which an IPTV SP is responsible for obtaining user permits and is
responsible for using those permits
• Internal permission mode in which an AM SP is responsible for obtaining permits and is
responsible for using those permits. TD-AMFs support the ability to ask for an end user's
permission, and store responses. Specific measurements in the received configuration
package may be disallowed by the TD-AMF depending upon the end-user permissions.
• Hybrid permission mode in which an IPTV SP is responsible for obtaining permits and an AM
service provider is responsible for using those permit. AM end-user permissions are part of
the end-user information stored by the IPTV service provider. The IPTV SP provides the tool
to allow the end users to set their AM end-user permissions for the different services it
offers.
Abnormal situations may happen during the procedures of discovery, configuration, storing, and
reporting AM data. Some are identified here (Message high-level error, Configuration message or
configuration request response message error, Configuration request message error, Measurement
report request message error, Measurement report message error, Storage overrun, No

Green book on IPTV Page 39 / 64

 Version 0.5

measurement report message transport ack, Delayed push report missed, Content filtering error, TD-
AMF sends inappropriate but valid AM messages) and potential recovery actions are listed.
Appendix I addresses “Discovery of audience measurement services by terminal devices”.
As there are several possible operational options for the aggregation functions, there declaration is
necessary to allow the terminal devices to check at the AM service discovery time if they are able to
operate with them or not, and how best to operate.
Table I.1 from H.741.1 contains the elements to be included in [b-ITU-T H.770] for the discovery of
AM services.
Appendix II is about “Considerations on implementation”. This appendix addresses a number of
implementation issues, namely:
• “Considerations on whether to implement AM”, benefits of AM as part of IPTV architecture
in comparison to traditional methods are listed (e.g. a larger audience sample, more detailed
engagement measurements, etc.) and also the AM limitations in comparison to ideal
methods (e.g. AM does not measure all end-user engagements on end-user devices which
support IPTV services, AM is for IPTV "TV" only, etc.).
• “Considerations for end-user permission method selection”, as there are three permission
modes (internal, external, hybrid), conditions that may lead to select one mode or the other
are listed.
There are also diagrams to show where the user permits are exchanged and used.
Example of multiple permits in a household is given with different rights for father, mother,
and sons
• “Considerations on using content filtering in configuration packages”. Conditions that may
lead to configuration of content filtering being used by an AM provider are listed.
• “Considerations on using different measurement triggers” (events, time-based sampling,
service start). Different situations are described to show when each of these triggers are best
suited.
• “Considerations for using AM message acknowledgements”. AM includes an optional, flexible
and low overhead acknowledgement request mechanism (response qualifier) for the
multicast configuration message. Acknowledgments may be selectively configured on a set of
devices which act as device samples for the greater population.
• “Considerations for configuration mode selection” among pull, push and hybrid modes.
Situations for which each mode is best suited are listed.
• “Considerations regarding methods of obtaining end-user permits”. Several methods may be
available for AM and/or IPTV service providers to obtain end-user permits. To help select and
implement a method, three processes are recommended for consideration.
• “Considerations for using multicast sub-addressing mechanisms”. When using multicast
messages, AM provides four mechanisms which enable addressing subsets of TD-AMFs
(lower and upper thresholds in between a random number generated by the terminal device
has to be to process the configuration package, device type(s), MAC addresses or match with
end-user information). Conditions that may lead to any of these subset addressing are listed.
• “Considerations for requesting error message responses to multicast messages”. Error
message responses to multicast messages are configurable. Conditions that may lead to
request error messages from a reduced set of terminal devices are listed.
• “Considerations for delivery mode selection”. As there are four modes (i.e. immediate push,
delayed push, pull, delayed push and pull) considerations of the situations for which each
mode is best suited are given.
• “Considerations on using end-user information to filter measurement requests”. Multiple
end-user info qualifiers e.g., occupation="doctor" and income="over 200 000 Euros" may be

Green book on IPTV Page 40 / 64

 Version 0.5

associated to measurement requests to get audience information from a set of specific end-
users. Conditions that may lead to the use of end-user information for filtering measurement
requests are listed.
Appendix III provides “Examples of TD-AMF configurations, reports and permits”.
Examples of configuration package data structure for service-common measurements are provided
with corresponding end-user behaviours and measurement reports
Examples using end-user information for filtering measurement requests in configuration packages
are also given.
An example of UserPermit is given in which permission level 3 is granted for linear TV channels 150
and 153, on STB and TV, for all content genres except religious or health.
Appendix IV is about “Considerations of end-user permission levels”.
4 permission levels are identified as follows:
• Permission Level 0 (default): no measurement permitted
• Permission Level 1: End-user behaviours and device info, distinguishable end user, no end-
user information, e.g. Channel 5 was watched by anonymous end user #12683304 on mobile
device model "X"
• Permission Level 2: End-user behaviours and device info, distinguishable end user, and
anonymous end-user information, e.g. Channel 5 was watched by anonymous end user
#12683304, interested in gardening, on mobile device model "X"
• Permission Level 3: End-user behaviours and device info, distinguishable end user,
anonymous end-user information, and identifiable subscriber or end-user information, e.g.
Channel 5 was watched on mobile device model "X" being used by subscriber or end user
"John Smith" who is interested in gardening
Examples of reportable information are given for different services as permitted by the different
permission levels
Appendix V is about “Considerations regarding the unlinkability property”.
It is possible to correlate an anonymous end user (either in permission level 2 or permission level 1)
with other information previously or subsequently obtained about that user. To avoid such a
correlation, unlinkability property for AM report submission is recommended. Indirection of AM
reports is the basis to implement unlinkability which requires the use of additional network
bandwidth.
The unlinkability property can be achieved using privacy enhancing technologies from two broad
classes of alternatives:
• TTP (Trusted third party): Employing a trusted third party that acts as a proxy for
TD-AMFs to submit AM reports
• P2P (peer-to-peer): Collaboration among peer TD-AMFs to forward each other's AM
reports to an AGF. The P2P-based alternative is preferred over the TTP-based
alternative as it does not require any modifications to the AM architecture.
Appendix VI provides “Considerations for AM vendors”. Analysis of measurements may lead to
aggregation over device types, time, content, geography, channel, etc.
Appendix VII deals with “Audience measurement capabilities and profiles”
A table lists capabilities of TD-AMFs: transport delivery mode (unicast, multicast), cryptographic
protocols, permission mode (internal, external, hybrid), configuration mode (pull, push, pull and

Green book on IPTV Page 41 / 64

 Version 0.5

push), measurement triggers, report delivery mode (immediate push, delayed push, pull, delayed
push and pull).
Appendix VIII gives an “XML schema on the data structures for audience measurement service
discovery”.
An XML schema is provided for the AMServiceDiscovery record with all elements necessary for the
declaration of AM services.
Appendix IX provides “XML schema instances for TD-AMF configurations, reports and permits”
These are the XML schema instances for examples of TD-AMF configurations, reports and permits
defined in Appendix III. These instances are based on Appendix VIII.

8.4 H.741.2: IPTV application event handling: Data structures of audience

measurement for IPTV services
Extracted summary
Recommendation ITU-T H.741.2 specifies the data elements and structures of the payloads used in
audience measurement messages.
Amendment 1 contains a new appendix I with XML schema on the data structures of audience
measurement for IPTV services
Extended summary
Recommendation ITU-T H.741.2 specifies data structures and messages to be exchanged between
terminal device audience measurement function (TD-AMF) and aggregation functions.
It starts with the specification of basic data elements already from other sources, with identifier,
name, format and possible values: ca:civicAddr (Civic Address), xs:date (date), xs:dateTime (date and
time), etc.
Then data elements associated with a user's device, including capabilities, identification,
configuration and usage are shown in a table with element identifier, description, support/type and
notes or value domain, like this:
Element Description Support/ Notes or value domain
type (Note 3)
AMFCapability Container to list capabilities Note 1
Profile supported by the TD-AMF
implementation.
Among the end user device data elements are: “AMFCapabilityProfile” (capabilities supported by TD-
AMF), “ServiceInstanceID” (allocated by a TD-AMF to each specific service when it starts),
“TVInformation” (Information related to a TV connected to a STB), “IPTV-TVInformation”
(information related to an IPTV-capable TV), “AudioAmplifierInformation” (information related to an
audio system connected to a STB), “STBInformation”, “MobileDeviceInformation”, “PCInformation”,
“ControlDevice” (remote control, keyboard).
The following data elements for end-user information asserted by end user and service-common
elements are specified in a similar table: “PermissionLevel” (0-3), “ControlledUserInfoTypeString”
(e.g. AgeRange), “ControlledUserInfoValueString” (e.g. 20-40), “ControlledUserInfoTypeDate” (e.g.
birthday), “ControlledUserInfoValueDate” (e.g. 2012-09-24), “ControlledUserInfoTypeAddress” (e.g.
BirthLocation), “ControlledUserInfoValueAddress” (e.g. Fr 502), “GenericUserInfoType” (e.g.
interests), “GenericUserInfoValue” (e.g. gardening).

Green book on IPTV Page 42 / 64

 Version 0.5

The following data elements for end-user information generated by system and service-common
elements are specified in a similar table: “TDLocation”, “UserPresent” (presence information from
one source), “UserList” (end-user information), “ServiceProviderIdentifier”, “SubscriberID”, “Permit
BlockedInfo” (to indicate how measurement are blocked by end-user permit: permission level, device
type, channel, content class).
Service-common events which can trigger a measurement report are then specified in a similar table:
“VideoResize”, “VideoZoom”, “VideoObscure”, “AudioVolume”, “ConfigurationChange”,
“UserChange”, “UserInfoChange”, “AudioLanguageChange”, “CaptionLanguageChange” and “Display
Status”.
Service-common sample set identifiers are used to indicate what is to be reported when a sample
time occurs. Here are some of them: “UserPresent” (to indicate that the UserPresent data structure
defined above is to be reported when sampled), “TDLocation”, “DeviceInfo”, etc.
The major data structures for audience measurement, making use of data elements defined above
are specified:
• Data structure for error messages. It is used to report any error in a message and for this
reason contains: “HighLevelErrorCode”, “RootElement” (of the erroneous message) and may
contain depending on the erroneous message: “ConfigPackageError”, “ConfigRequestError”,
“ReportRequestError”, “ReportError”
• Data structure for measurement requests. It consists of a header with “Measurement
RequestID” and four logical parts:
o Services to be measured. For Linear TV measurement, a “LinearTVQualifier” is
specified in [ITU-T H.741.3] to select channels). “AllContentClassExceptList” allows to
filter measurements across services based upon content class.
o Measurement schedule. Several “MeasurementPeriod” may be defined with “DayOf
TheWeek”, “StartTime” and “EndTime”
o Measurement triggers: list of service-common or service-specific events with
“priority” for congestion management, “Periodicity “ for sampling after service start,
with service-common sample set identifiers specified above to list what is to be
reported with “priority”, “Interval” (number of days) for reporting for first service
start report every N days
o Measurement delivery with “DeliveryAddress”, “RetransmitNumber”, “Storage
CongestionPolicy” and parameters specific to delivery modes: immediate push,
delayed push (“DeliveryWindow”), pull and delayed push and pull.
A delayed push measurement reporting policy is specified to avoid network
congestion by measurement reports.
• Data structure for measurement request sets. It is defined to provide an optimization
mechanism to include default values for elements which have the same value in a number of
measurement requests, e.g. “DefaultMeasurementPeriod”, “DefaultRetransmitNumber”, etc.
• Data structure for "measurement request set filter". Measurements can be requested only
from end-users with end-user information matching “UserInfoTarget” defined in [ITU-T
H.741.4].
• Data structure for measurement report requests. It contains only a list of “Measurement
RequestID” to identify the measurement requests for which generated measurement reports
are requested.
• Data structure for AMF configuration packages. It contains the following elements: “Package
Version”, “EffectivityDateAndTime”, “UserPermitInfo” (when user permits are provided by
aggregation functions) and a number of “MeasurementRequestSet” defined above.
• Data structure for "acknowledge message". It is used to report on the reception of an AM
message with no error.

Green book on IPTV Page 43 / 64

 Version 0.5

• Data structure for configuration package requests. It is used to ask for an AMF configuration
package or to check if the current or future configuration package at the TD AMF is still valid.
• Data structure for "configuration package request response". It specifies the data structure
of the response to the message containing the just above data structure. It contains the
following elements: “ConfigurationPackageCheckDelay” (delay between checks for
configuration update), “ImmediateMeasurementDirective” with “Code” (0= no AM, 1=no
change, 2=new configuration package) and optional “AMFConfigPackage”, “Future
MeasurementDirective” with “Code” and optional “AMFConfigPackage”.
• Data structure for user permits. It may contain “ExpirationDate”, “DefaultExpirationDate”,
“DefaultAllContentClassExceptList” (content classes not to be measured), “AnonUserID”
(anonymous end-user ID, to be used when permission level is below 3), “UserId” and for each
“PermissionLevel” a set of “UserPermission” each for specific IPTV services identified for
example by “ChannelQualifier” consumed by indicated “TerminalDeviceType”.
• Data structure for measurement reports with service-common events and/or samples. The
data structure consists of common elements: “MeasurementRequestID” and “Measurement
ReportTriggerTime” and elements specific to measurement triggers (usually a change) and to
what can be requested to be reported: “DisplayStatus”, “AudioFocus”, “CaptionLanguage
Change”, “AudioLanguageChange”, “AudioVolume”, “ConfigurationChange” (device
configuration), “VideoObscure”, “VideoZoom”, “VideoResize”, “EventCount”, “Device
Information”, “UserBiographicInformation”, “TDLocation”, “UserList”, “UserPresent”,
“GenericUserInfo”, “UserInfoChange”and “PermitBlockedInfo”. Some data elements have
already been defined earlier.
• Data structure for audience measurement report package. This data structure is defined to
group a number of audience measurement reports. It starts with a header which may
contain: “SubscriberID”, “TerminalDeviceID”, “StorageCongestionImpactedService”
(identification of service with dropped measurement reports due to storage congestion),
“ServiceStopDropped” (identification of service with dropped service stop due to storage
congestion). A set of measurement reports (as defined just above) may follow this header.

8.5 H.741.3: IPTV application event handling: Audience measurement for

IPTV distributed content services
Extracted summary
Recommendation ITU-T H.741.3 specifies audience measurement for IPTV distributed content
services and, in particular, linear TV services. It describes specific configuration for linear TV and
metadata and data structures used in the payload of AM messages. The informative appendices
discuss specific implementation considerations for linear TV-specific implementation considerations,
provide examples and describe capabilities and profiles.
Extended summary
This Recommendation specifies configuration, reporting and data structures for linear TV events and
samples.
Linear TV aspects with an impact on the audience measurement configuration are described:
• Channels. Either all channels or a list of channels to be measured may be configured.
Alternatively, an "all channel except" list may be configured.
• Summarization and filtering. Configuration of a channel change filter time between channel
change events can be used to filter out unneeded reports.
• Service navigation method. The reporting of which method was used to change channel may
be configured.

Green book on IPTV Page 44 / 64

 Version 0.5

• Control device. The reporting of which device was used to change channel may be
configured.
Data elements specific to Linear TV, to be inserted in the data structures specified in ITU-T H.741.2
are listed:
• ServiceIdentifier, defined in [ITU-T H.770]
• ChannelChangeFilter (minimum time in milliseconds between subsequent channel start and
channel stop events to generate reports about these events)
• ControlDevice (device type used to navigate to a channel)
• StartNavMethod (method used to navigate to a channel)
• StopNavMethod (method used to navigate away from a channel)
• ViewMode (e.g. full screen, Picture-in-Picture , mosaic, etc.)
Specific Linear TV events are specified: LinearChannelStart and LinearChannelStop
Specific Linear TV elements which can be reported: ChannelPlaying
"LinearTVQualifier", the data element to be inserted in the "measurement request" data structure to
identify what Linear TV services are to be measured, is defined in this recommendation. It indicates if
navigation method (“NavMethod”), control device (“ControlDevice “), view mode (“ViewMode”),
obscuration (“Obscuration”) are to be reported. Other elements are “ChannelQualifier” (to identify
channels to be measured) and “ChannelChangeFilter” defined above.
Specific Linear TV data elements to be inserted in measurement request set data structure are
specified: “DefaultNavMethod”, “DefaultControlDevice”, “DefaultViewMode”, “DefaultObscuration”,
“DefaultChannelQualifier”, “DefaultChannel
ChangeFilter”.
Specific Linear TV data elements to be inserted in measurement report data structure are specified:
• ChannelStart with “ControlDevice”, “StartNavMethod”, “PreviousServiceInstanceID”,
“ServiceInstanceID”, “ServiceIdentifier”, “ViewMode”, “Obscuration”
• ChannelStop “ControlDevice”, “StopNavMethod”, “ServiceInstanceID”
• ChannelPlaying with “ServiceIdentifier”, “ServiceInstanceID”
Appendix I provides some “Implementation considerations” and in particular:
• Considerations regarding the enabling of control device reporting. Conditions that may lead
to this reporting option being enabled are listed.
• Considerations regarding the enabling of navigation method reporting. Conditions that may
lead to this reporting option being enabled are listed.
• Considerations for specifying channels to be measured. Three methods for specifying
channels to be measured: specification by inclusion, specification by exclusion, or
measurement of all channels (default).
• Considerations for using channel change filtering and how to choose the value. If reporting of
transitional channels to a final channel is not desired, then it is recommended that channel
change filtering be used.
Appendix II gives “Examples of configuration and reporting of the terminal device audience
measurement function”.
An example of an AMF configuration package is given with the following characteristics:
• For all channels except Channels 50, 53, 58 and 60. Do not measure religious content.
o Measurement reports for channel start and channel stop events when the time
following an event without either subsequent event occurring is greater than
two seconds

Green book on IPTV Page 45 / 64

 Version 0.5

o Measurement all the time.

o Report batches of events within 60 seconds of any event
• For Channels 50, 53, 58 and 60. Do not measure religious content.
o Time sampling every five minutes. Ignore the sample if its value is the same as the
previous sample's value
o Reporting: upon demand by aggregation functions
An example of end-user behaviours (watching different Linear TV channels) is illustrated on a figure
with time indication for generated measurement reports when an AMF is configured with the
previous configuration package. Several examples of measurement report packages are given.
Another example of configuration package is given to get reports related to Picture-in-Picture (PIP)
operations, including swapping the sub-picture and main picture, and resizing and moving the sub-
picture. An example of end-user behaviour with PIP operation is illustrated and some examples of
measurement report packages about PIP operation are provided.
Appendix III is about “Audience measurement capability profiles”. Capabilities of the terminal device
audience measurement function are listed:
• Measurement Triggers (events and/or time sampling)
• Operational Management (Channels to be measured, Channel change filtering, Navigation
method reporting, Control device reporting)
These capabilities are included in the capability data structure defined in [ITU-T H.741.2].

8.6 H.741.4: IPTV application event handling: Transport mechanisms for

audience measurement
Extracted summary
Recommendation ITU-T H.741.4 specifies the data elements and structures of the transport delivery-
dependent XML and binary headers, used in audience measurement messages. Appendix I provides
an analysis of AM to understand its transport protocol requirements.
Extended summary
The following table shows how messages containing data structures defined in Recommendation
ITU-T H.741.2 can be delivered in unicast mode and/or in multicast mode.

Table 1 from H.741.4 – Delivery mechanisms for each data structure

Data structure Unicast Multicast
Configuration package request X
Configuration package request response X X
Configuration package X X
Measurement report request X X
Measurement report package X
Ack X
Error X
Messages are created to insert the data structures defined in ITU-T H.741.2 with the following
header for delivery over unicast and multicast are: message identifier (“MessageID”), message type
identifier (“MessageType”), message expiration time (“ExpirationTime “) and AM protocol version
numbers (“ProtocolVersionMajorID”, “ProtocolVersionMinorID” and “Compression” of XML payload.

Green book on IPTV Page 46 / 64

 Version 0.5

For multicast delivery additional data elements are necessary: message integrity check (“Digest “)
and signature (“Signature “) for authentication, element to request or not acknowledge or error
responses (“ResponseQualifier”), sub-addressing elements to target a sub-set of TD-AMFs (“Terminal
DeviceTarget”, “TerminalDeviceTypeTarget”, “UserInfoTarget.
Then message data structures used to delivery various data structures defined in ITU-T H.741.2 are
specified:
• Data structure for the configuration request message (Header elements and “ConfigPackage
Request” defined in [ITU-T H.741.2])
• Data structure for the unicast configuration request response message (Header elements
and “ConfigPackageRequestResponse” defined in [ITU-T H.741.2])
• Data structure for the multicast configuration request response message (Header elements,
additional multicast header elements, “ConfigPackageRequestResponse” defined in
[ITU-T H.741.2])
• Data structure for the unicast configuration package message (Header elements and
“ImmediateAndFutureConfiguration” defined as “ConfigPackageRequestResponse” in
[ITU-T H.741.2])
• Data structure for the multicast configuration package message (Header elements, additional
multicast header elements and “ImmediateAndFutureConfiguration” defined as “Config
PackageRequestResponse” in [ITU-T H.741.2])
• Data structure for the unicast measurement report request message (Header elements and
“MeasurementReportRequest” as defined in [ITU-T H.741.2])
• Data structure for the multicast measurement report request message (Header elements,
additional multicast header elements and “MeasurementReportRequest” as defined in [ITU-T
H.741.2])
• Data structure for the measurement report package message (Header elements and “AM
ReportPackage” as defined in [ITU-T H.741.2])
• Data structure for the configuration package ack message (Header elements and “Ack” as
defined in [ITU-T H.741.2])
• Data structure for the error message (Header elements and “Error” as defined in [ITU-T
H.741.2])
Appendix I addresses “Transport protocol considerations for audience measurement”.
It describes whether unicast and/or multicast protocols can be used for each message type. It
provides relative message size range estimates of each message with dependencies which increase
size.
It describes also the need for reliability for each message type and the impact when messages are
not delivered (e.g. gap in measurements or wrong measurements.
Concerning AM message QoS needs, AM traffic may be marked as bulk class or equivalent.
Concerning AM message integrity needs, as integrity check is provided at the message level, integrity
check at the transport level is not required.
Concerning AM message encryption needs, since AM messages include support for encryption,
encryption at the transport level is not required.

8.7 Other Recommendations

HSTP.IPTV-AM.101 "Introduction to H.741- series – A video engagement audience measurement
standard" (note: not yet available for download).

Green book on IPTV Page 47 / 64

 Version 0.5

Recommendation ITU-T J.706: Target-specific content distribution is a mechanism for distributing

content addressed to specific target users according to a set of distribution policies and specific
interactive feedback from the platform to content providers/Ad providers. This Recommendation
defines the overall architecture of the target-specific content distribution system on the platform and
seeks to describe the relationship between Recommendation ITU-T J.707 and other relevant
Recommendations.
Recommendation ITU-T J.707 defines the messages and protocols used to realize target-specific
content distribution for integrated broadband cable networks. Target-specific content distribution is
the mechanism for content distribution addressed to specific target users. This Recommendation
defines message format and delivery protocols between content providers/Ad providers and the
platform.

9 IPTV Metadata
Metadata for IPTV services are defined in the H.750 sub-series and currently comprose two
Recommendations:
– H.750 (10/2008): High-level specification of metadata for IPTV services
– H.751 (03/2013): common specification with IEC TC 100 on metadata for rights interoperability
(or for “security”).

9.1 H.750: High-level specification of metadata for IPTV services

Extracted summary
Recommendation ITU-T H.750 gives the high-level specification of the metadata for IPTV services,
with its elements and delivery protocols. IPTV metadata, the information on services and content
processed by the service and content delivery infrastructure, provides a descriptive and structural
framework for managing IPTV services. The types of metadata for IPTV are service and content
metadata, user metadata, metadata for content provisioning and management, metadata
aggregation management, and rights and security related metadata. Aspects of discovery, delivery
and transport, representation and management of metadata are covered in this Recommendation.
Extended summary:
Recommendation ITU-T H.750 provides an overview of IPTV metadata, listing existing metadata
standards specified by other SDO’s to be the basis for metadata Recommendations to be developed
by ITU-T in the IPTV area.

Figure 8-1 – IPTV metadata service overview (H.750 Figure 6-1)

Green book on IPTV Page 48 / 64

 Version 0.5

It is suggested to ITU-T experts that “Existing and mature metadata standards, such as [ISO/IEC
15938-5] or [ETSI TS 102 822-3-1], shall be adopted or integrated to avoid reinvention of new
metadata standards.”
The main sources of metadata specification are TV-Anytime for content metadata and DVB for
service provider/service metadata and delivery protocols.
The Recommendation identifies sets of metadata for service provider, service (or channel), content,
content collection, quality monitoring, content segmentation, delivery modes, content adaptation,
usage restrictions and rules, user profile or preference, audience measurement, device and network
description, user interface representation, content provisioning,
Elements are listed for each metadata set with references to standards where the reader can find
definition and specification. For example, “title” is an element listed in the content metadata set with
references to ETSI TS 102 822-3-1, ETSI TS 102 471, UPnP CDS2 and IETF RFC 4287 where such an
element is specified.
Metadata standards use the MPEG-7 Description Definition Language (DDL) (see ISO/IEC 15938-5) to
describe metadata structure as well as the XML encoding of metadata.
The Recommendation addresses also all issues related to the use of metadata, namely: identity
management (content, content provider, service, service provider, user, device), discovery, delivery
mode (pull or push, unicast or multicast, query/response), transport (fragmentation, container,
compression), updating (change notification, versioning), security and integrity. In the same spirit,
standards from other SDOs relevant to these issues are listed.
For example, on “delivery mode” issue, you can read that delivery methods can be implemented on a
SIP-based service platform, or a web service-based service-oriented architecture (SOA) framework. In
addition to this, references to standards are provided: ETSI TS 102 539 ( push and pull modes of
content description delivery for container-based and query/response-based protocols), ETSI TS 102
822-6-1 (unicast query/response delivery using the simple object access protocol (SOAP) over HTTP),
ETSI TS 102 472 ( metadata transport containers carrying ESG metadata instances delivered in FLUTE
dynamic file delivery carousel sessions).
After this IPTV metadata overview, a number of Recommendations have been approved on different
metadata aspects:
• Service provider and service metadata: H.770 (Mechanisms for service discovery and
selection for IPTV services)
• Transport of service provider and service metadata: H.770 (Mechanisms for service discovery
and selection for IPTV services)
• Audience measurement metadata: H.741.2 ( IPTV application event handling: Data structures
of audience measurement for IPTV services), H.741.3 (IPTV application event handling:
Audience measurement for IPTV distributed content services)
• Transport of audience measurement metadata: H.741.4 (IPTV application event handling:
Transport mechanisms for audience measurement)
• Rights metadata: H.751 (common specification with IEC TC 100 on metadata for rights
interoperability (or for “security”)).
• Content and content collection metadata: ETSI TS 102 822-3-1 V1.8.1 (2012-12) Broadcast
and On-line Services: Search, select, and rightful use of content on personal storage systems
("TV-Anytime"); Part 3: Metadata Sub-part 1: Phase 1 - Metadata schemas

Green book on IPTV Page 49 / 64

 Version 0.5

9.2 H.751: common specification with IEC TC 100 on metadata for rights
interoperability (or for “security”).
Extracted summary
Recommendation ITU-T H.751 defines the common semantics and core elements of rights
information interoperability (RII) for Internet Protocol television (IPTV) systems and/or equipment
that allow multimedia content to be legally used across different platforms.
The rights information includes rights- and security-related metadata that is described in
Recommendation ITU-T H.750.
This Recommendation describes rights-related information such as content ID, permission issuer ID
and permission receiver ID, which are used to bridge between rights-related metadata. It should be
noted, however, that rights management and content protection technology are beyond the scope of
this Recommendation.
This Recommendation is technically aligned with the specification in IEC 62698, Multimedia home
server systems – Rights information interoperability for IPTV.
Extended summary
This Recommendation gives a high-level metadata description for rights information interoperability
(RII). RII metadata provides descriptive and contextual classification for representing rights
information using the permission framework.
RII is concerned with finding the greatest common denominators in rights expressions that include
the minimum required components when trying to implement the mutual use of rights information.
In other words, RII is about conveying rights information in units of groups of context expressions
called permissions.
RII is not defined from a technical perspective, but rather on the basis of permission information that
rights holders actually employ in the field. RII does not provide a method of encoding context
expressions for permissions and the encoding method should make use of existing standardized
technology.
Permissions can encode "what” (content ID), “from whom” (rights-holder ID or issuer ID) and “to
whom" (receiver ID or user ID/device ID) and "under what conditions" (permission limits) using
context expressions.
The permission classification identifies the following classes:
• Disclosure (for a specified player or an unspecified group of players)
• Usage purpose ("commercial", "public", "non-profit", "promotion", "education" and "other")
• Charging ("free of charge", "pay per use", "subscription", and "coupon")
• Sponsor ("No sponsor", "Advertisement model without force viewing", "Advertisement
model with force viewing", etc.)
• Territory (region code, country code (ISO 3166-1) and postal code)
• Usage class with the following required elements:
o Transmission ( "broadcast", "streaming", "download" and "physical media")
o Storage ("fixation" for content permitted to be stored in conformant devices)
o Reuse (enable or disable secondary usage, move, copy, export, share, edit, modify
and super distribution)
o Redistribution ( enable or disable)
o Compilation (true if play-list enable, false if play-list disable and other)

Green book on IPTV Page 50 / 64

 Version 0.5

Permission limits are further defined (quality, lifetime, permission management system,
simultaneous outputs or exports).
Elements required for data management and export (Encryption flag, copy count, move count,
transcode count and type, maximum and minimum transcode rate, expiration date, etc.) are also
identified.
It makes reference mainly to IEC 62227 ( Multimedia home server systems – Digital rights permission
code subdivisions), which specifies permission classification for signalling and carrying disclosure
information, usage purpose information, charge model information, usage class information,
territory information, sponsor information, playback condition, print condition, execution condition,
etc.
Appendix I is about “Security-related issues”
Appendix II is about “Syntax (encoding)”. It shows the typical 23 use-cases scenarios that are
described in [b-IEC 62636].
Appendix III provides a “Background to rights information interoperability”.
Appendix IV specifies “Two basic technologies for enabling RII”.
Appendix V title is “Rights information metadata elements corresponding to existing SCP systems”.

10 IPTV Multimedia Application Frameworks

The IPTV multimedia application frameworks found in the H.760 sub-series of Recommendations
provide a toolbox set of imperative and declarative environments that can be used to provide rich,
interactive IPTV services:
– H.760 (03/2009): Overview of Multimedia Application Frameworks for IPTV
– H.761 (04/2009) V2 (06/2011) : Nested Context Language (NCL) and Ginga-NCL for IPTV
services
– H.762: Lightweight interactive multimedia environment (LIME) for IPTV services
– H.763.1: Cascading style sheets for IPTV services
– H.764: IPTV service enhanced script language
In addition to the Recommendations in the H.760 sub-series, the following documents should be
considered:
– HSTP-MCTB: Technical paper on media coding toolbox for IPTV

10.1 H.760: Overview of Multimedia Application Frameworks for IPTV

Extracted summary
Recommendation ITU-T H.760 identifies and describes the relevant standards of multimedia
application frameworks for interoperability and harmonization in IPTV services. It gives an overview
of standards for declarative application frameworks as well as standards for procedural application
frameworks. For declarative application frameworks, standards to be used for IPTV are described
(such as HTML, CSS, DOM, ECMAScript, SVG, BML, MHEG-5 and Ginga-NCL), while procedural
application frameworks are represented by GEM-based frameworks. It also contains descriptions of
ISO/IEC International Standards for application frameworks, namely M3M, BIFS and LASeR.
Recommendation ITU-T H.760 also has an annex on common usage of web-related technologies.
Extended summary

Green book on IPTV Page 51 / 64

 Version 0.5

First, Recommendation ITU-T H.760 describes standards for declarative application frameworks. A
declarative application platform is a framework on which applications written by a markup language
(e.g., HTML) with or without script language (e.g., ECMAScript) can run.
Standards for declarative application frameworks include (order without preference):
1. Binary format for Scene (BIFS) [ISO/IEC 14496-11]. It is the scene description language
standardized by ISO as a part of the MPEG-4 family of standards. It allows the representation
of dynamic and interactive presentations, comprising two and three dimensional (2D & 3D)
graphics, images, text and audiovisual material. This representation includes the description
of the spatial and temporal organization of the different scene components as well as user-
interaction and animations.

Figure 5-1 from H.760 – MPEG-4 BIFS scene description

Note: S & N Sound: Synthetic and Natural Sound, FBA: Face and Body Animation

2. Binary Markup Language (BML) (see [ARIB STD-B24] and [ITU-T J.201]). It is a declarative
application specification for multimedia broadcasting in Japan. BML consists of XHTML 1.0,
CSS 1 and CSS 2, Document Object Model (DOM) 1 and DOM 2, and ECMA-262. It includes
also additional functionalities for receivers with digital storage and for terrestrial digital
broadcasting including mobile reception. It is based on the functionalities of MHEG and in
particular on the following minimum set of MHEG classes: Application, Scene, Link and
Action.

3. CEA-2014. It is a web-based protocol and framework for remote user interface (UI) on UPnP
home network and over Internet. It is based on existing web rendering technologies for
consumer electronics (CE) browser with Worldwide Web Consortium (W3C) tags, XHTML 1,
ECMA-262, CSS TV profile and DOM 2.

4. Cascading style sheet (CSS). It is a style sheet language specified by W3C that is used to
describe the presentation (e.g., fonts, colours and spacing) of a document written in a
markup language. CSS does not constitute by itself a multimedia framework. CSS is human
readable and writable.
W3C CSS TV Profile specifies subsets of W3C CSS2, e.g., colour specifications tailored to TV
devices. Annex A shows different profiles including CSS.

Green book on IPTV Page 52 / 64

 Version 0.5

5. Document object model (DOM). W3C DOM 2.0 defines a platform- and language-neutral
interface that allows programs and scripts to dynamically access and update the content and
structure of documents. The Core also contains specialized interfaces dedicated to XML.
DOM does not constitute by itself multimedia framework. Annex A shows different profiles
including DOM.

6. Digital video broadcasting hypertext markup language (DVB-HTML) is a standard for allowing
digital televisions to access Internet content. Among other things, MHP 1.1 specifies the
Internet access profile, in which applications can control the basic operations of Open
Internet resident clients (web browser, e-mail and news client).

7. ECMAScript [ISO/IEC 16262]. It is a scripting programming language that is used on the web
and is often referred to as JavaScript or JScript, after the two earlier implementations of the
specification.
ECMAScript is an object-oriented programming language for performing computations and
manipulating computational objects within a host environment. The host environment
provides a means to attach scripting code to events such as change of focus, page and image
loading, unloading, error and abort, selection, form submission, and mouse actions.
ECMAScript does not constitute by itself a multimedia framework. Annex A shows different
profiles including ECMAScript.

8. Hypertext markup language (HTML). It is the predominant markup language for web pages. It
provides a means to describe the structure of text-based information in a document – by
denoting certain text as links, headings, paragraphs, lists, and so on – and to supplement that
text with interactive forms, embedded images, and other objects.
XHTML is an XML-based specification where HTML is an SGML-based specification. W3C
intended XHTML 1.0 to be identical to HTML 4.01 except where limitations of XML over the
more complex SGML required workarounds. The differences between an HTML 4.01 and
XHTML 1.0 document – in each of the corresponding document type definitions – are largely
syntactic.
Dynamic HTML allows a scripting language to change variables in a page's definition
language, which in turn affects the look and function of otherwise "static" HTML page
content, after the page has been fully loaded and during the viewing process.

9. Lightweight application scene representation (LASeR) and simple aggregation format. MPEG-
4 Part 20 [ISO/IEC 14496-20] is a specification designed for representing and delivering rich-
media services to resource-constrained devices such as mobile phones. It defines two binary
formats: lightweight application scene representation (LASeR), a binary format for encoding
2D scenes, including vector graphics, and timed modifications of the scene; and simple
aggregation format (SAF), a binary format for aggregating in a single stream LASeR content
with audio/video streams.
To achieve reactivity, the SAF specification defines the concept of cache unit which allows
sending in advance sub-content which will be used later on in the presentation.

10. MHEG-5 (see [ITU-T T.170], [ITU-T T.172], [ITU-T T.175], [b-ETSI ES 202 184]) represents an
application as a set of scenes that contain objects with spatio-temporal relationships, event-
action associations, navigation, and user interaction capabilities.
Audiovisual content may consist of graphics, bitmaps, text, and streams (based on the
multiplex of audio and video components). Interaction can be performed via graphic
elements like buttons, sliders, text entry boxes, and hypertext selections.

Green book on IPTV Page 53 / 64

 Version 0.5

Events can be generated by users, expiration of timers, playback of streams, and other
conditions.

11. Nested context language (NCL) is an XML application language allowing an author to
declaratively describe the spatio-temporal behaviour of a multimedia presentation, associate
hyperlinks (viewer interaction) with media objects, define alternatives for content and for
content presentation (adaptation), and describe the layout of the presentation on multiple
exhibition devices.
NCL is part of the data coding specifications of the Terrestrial Brazilian Digital TV System.
An NCL document (NCL application specification) only defines how media objects are
structured and related, in time and space. As a glue language, it does not restrict or prescribe
the media-object content types.
NCL also treats an HTML document as one of its possible media objects.
NCL also includes support for media objects that contain imperative code, extending the
language basic model, adding decision-making features. NCL allows imperative objects with
java code or Lua code.
Lua is the scripting language of NCL. Lua combines simple procedural syntax with powerful
data description constructs based on associative arrays and extensible semantics. Lua is
dynamically typed, runs by interpreting byte-code for a register-based virtual machine.

12. Scalable vector graphics (SVG) [W3C SVG 1.1] is a language for describing two-dimensional
graphics and graphical applications in XML. SVG allows for three types of graphic objects:
vector graphic shapes (e.g., paths consisting of straight lines and curves), images and text.
SVG drawings can be interactive and dynamic. Animations can be defined and triggered
either declaratively (i.e. by embedding SVG animation elements in SVG content) or via
scripting.
SVG Basic and SVG Tiny are targeted to resource-limited devices and are part of the 3GPP
platform for third generation mobile phones.

13. Worldwide TV markup language (WTVML) ) [ETSI TS 102 322] is a content format for the
delivery of interactive TV applications using Internet servers.
A WTVML interactive television technology platform comprises a micro-browser, a markup
language, and a significant collection of associated software tools and services. The micro-
browser and markup language are both based upon the Open Mobile Alliance WML 1.3
specification.
The format combines explicit pixel-perfect control required for TV user interfaces, and the
dynamic layout and Internet compatibility requirements necessary for e-business and
dynamic content.
The format assumes a rich event model and contains explicit state and variable management,
allowing the creation of sophisticated user interface effects without the use of scripting.
Within an architecture consisting of a micro-browser and a gateway, the gateway processes
the raw WTVML and generates compiled byte-code to be passed to the user agent to
execute.
Standards for procedural application frameworks are based on Globally Executable MHP (GEM) [ETSI
TS 102 819] as shown on the next figure. It is a formally standardized Java-based platform for
interactive content and applications.

Green book on IPTV Page 54 / 64

 Version 0.5

ARIB-AE
Service Information
Conditional Access
Data Carousel
Application Signaling

GEM MHP
ACAP JavaTV Service Information
Optional ACAP-X Havi Conditional Access
DaviC
others

MHP Object Carousel

MHP Application signaling

OCAP
Service Information
Conditional Access
Monitor Application
Unbound Applications
Security Extensions

Figure 6-1 from H.760 – GEM based Standards for multimedia application frameworks
GEM has been adopted by ETSI, ITU, CableLabs, ARIB, ACAP and the Blu-ray Disc Association.
Advanced Common Application Platform (ACAP) is primarily based on GEM and digital television
application software environment (DASE) and includes additional functionality from OCAP. There are
two categories of applications: procedural (ACAP-J) (i.e. Java TV Xlet) and declarative (ACAP-X) (i.e.
XHTML, style rules, scripts).
Open Cable Application Platform OCAP [ANSI/SCTE 90-1] is the set of specifications for the
interactive multimedia services of digital CATV. OCAP 1.0 is based on MHP 1.0.2, and includes the
extensions for the cable system in the United States.
Multimedia Home Platform MHP [ETSI TS 102 812] is a set of specifications for multimedia
broadcasting. Version 1.0 series covers the execution engine (EE) environment and version 1.1 series
covers the presentation engine (PE) environment in addition to version 1.0. The MHP 1.0
specification employs Java technology for an EE environment.

Among other related standards is “MPEG multimedia middleware” (M3W). M3W [ISO/IEC 23004.x]
provides two sets of APIs: multimedia platform APIs (handling front-end, decoder, post-processing of
A/V, security management (key, signature, license and certificate) and Support platform APIs.

Green book on IPTV Page 55 / 64

 Version 0.5

Applications
Applications
M3W
API
Middleware
Middleware

Platform
Support
M3W
API
Multimedia
Platform M3W
API
Computing Platform
Computing Platform

Figure 7-1 from H.760 – The structure of M3W

Annex A is about “Common usage”. For a typical IPTV framework based on web-related technologies,
a particular combination of these technologies defines a "profile":
1 BML profile: XHTML 1.0, CSS 1, CSS 2, DOM 1, DOM 2, ISO/IEC-16262 (ECMAScript).
2 CEA-2014: XHTML 1, CSS TV profile, DOM 2, ISO/IEC-16262 (ECMAScript).
3 DVB-HTML profile: XHTML 1.0, CSS 2, DOM 2, ISO/IEC-16262 (ECMAScript).
4 SVG profiles
• SVG 1.1: CSS 2, DOM 1, DOM 2, ISO/IEC-16262 (ECMAScript);
• SVG Tiny: CSS 2, uDOM, ECMA ISO/IEC-16262 (ECMAScript).

10.2 H.761 : Nested Context Language (NCL) and Ginga-NCL for IPTV
services
Extracted summary
Recommendation ITU-T H.761 gives the specification of the nested context language (NCL) and of an
NCL presentation engine called Ginga-NCL to provide interoperability and harmonization among IPTV
multimedia application frameworks.
NCL is a glue language that holds media objects together in multimedia presentations, no matter
which object types they are. As an example, NCL treats an HTML document as one of its possible
media objects. In this way, NCL does not substitute, but embed, XHTML-based documents. The same
reasoning applies to other media content and multimedia content objects, and also to objects with
content coded in any computer language. Ginga-NCL is an NCL presentation engine built as a
component of a DTV middleware. A very special NCL object type defined in Ginga-NCL is NCLua, an
imperative media-object with Lua code.
This Recommendation includes an electronic attachment containing NCL 3.0 module schemas used in
the Enhanced DTV profile.
Extended summary
Nested Context Language (NCL) is an XML-based, glue language that holds media objects together in
multimedia presentations, no matter which object types they are. As an example, NCL treats an
HTML document as one of its possible media objects. In this way, NCL does not substitute, but
embed, HTML-based documents. The same reasoning applies to other media content and
multimedia content objects, and also to objects with content coded in any computer language.
Ginga-NCL is an NCL presentation environment built as a component of an IPTV middleware.
Some of NCL’s highlights are: the language flexibility; its reuse facility; multi-device support (n-
screen); presentation and content adaptability; API for building and modifying applications on-the-fly

Green book on IPTV Page 56 / 64

 Version 0.5

(live editing); and, mainly, its intrinsic ability for easily defining spatiotemporal synchronization
among media assets (including viewer interactions).

Figure 10-1. Example of an NCL Multi-device application

NCL applications have a strict separation between its content and its structure. NCL does not define
itself any media content. Instead, it defines the glue that holds media objects together in multimedia
presentations. An NCL document (NCL application specification) only defines how media objects are
structured and related, in time and space. As a glue language, NCL does not restrict or prescribe the
content types of its media objects. Which media objects are supported depend on the media players
that are coupled to the NCL Presentation Environment. One of these players is the main video and
main audio decoder/player, usually implemented using hardware resources in an IPTV receiver.
Therefore, the main video and the main audio of a service are treated like all other media objects
that may be related using NCL.
Ginga-NCL implementations are required to support HTML-based media objects. Which HTML profile
is supported is an implementation choice, and, therefore, it will depend on which HTML browser will
act as a media player integrated to the NCL presentation engine.
Another media object that is required in a Ginga-NCL implementation is the declarative NCL media
object, that is, a media object containing an NCL application. Therefore, NCL applications can be
embedded in NCL parent applications, likewise HTML-based applications can be.
To extend the NCL declarative language basic model adding decision-making features that deserves
the imperative paradigm, NCLua objects are part of the Ginga-NCL specification. Lua is a powerful,
fast, lightweight, embeddable scripting language and was defined as the standard scripting language
of NCL. NCLua media objects carry Lua code following the standardized NCLua API.
Ginga architecture is depicted in Figure 3.1. Ginga Common Core (Ginga-CC) is composed of media
players, of procedures to obtain contents that can be delivered via diverse networks accessed by a
receiver (hybrid scenarios are therefore supported), and of the conceptual display graphical model
defined by the receiver platform. Ginga Common Core is also responsible for gathering metadata
information and providing this information to NCL applications; for providing an API to communicate
with DRM system; for managing context information (like user profiles and receiver profiles); and for
supporting software version management (update) of Ginga’s components.

Green book on IPTV Page 57 / 64

 Version 0.5

Figure 10-2: Ginga architecture

Media player components serve application needs for decoding and presenting content types such as
PNG, JPEG, MPEG and other formats, including those for content which contains declarative or
imperative code, like HTML, Lua, etc. A generic media player API establishes the necessary
communication between media player components and the Ginga-NCL subsystem. Thanks to this
API, Ginga-NCL and the Ginga-CC are strongly coupled but independent subsystems. Ginga-CC may
be substituted by other third part implementations, allowing Ginga-NCL to be integrated in other
middleware specifications, extending their functionalities with NCL facilities. Players that do not
follow the generic API are required to use the services provided by Adapters.
The core of Ginga-NCL subsystem is the NCL Player. This component is in charge of receiving and
controlling multimedia applications written in NCL. Applications are delivered to the NCL Player via
the Ginga Common Core.
In Ginga-NCL, a declarative application can be generated or modified on the fly, using NCL editing
commands. The NCL Player deals with NCL applications collected inside a data structure known as
private base. A Private Base Manager component is in charge of receiving NCL editing commands and
maintaining the NCL documents being presented.
Ginga-NCL Presentation Engine supports multiple presentation devices through its Layout Manager
module. This component is responsible for mapping all presentation regions defined in an NCL
application to multiple canvases on receiver’s displaying devices.
In particular, Ginga-NCL provides declarative support to IPTV specific services, such as VOD,
datacasting, etc. Thus, a VoD service may, for example, play an NCL application besides the main
audiovisual stream. Moreover, an IPTV service itself can be an NCL application.
Ginga has an open-source reference implementation that can be downloaded from
http://git.ginga.org.br. Several commercial releases are derived from this reference implementation.
At http://testsuite.gingancl.org.br, Ginga developers and testers can find a comprehensive
specification [HSTP-CONF.H761] of testing procedures for the ITU-T H.761 Ginga-NCL presentation
environment. This helps manufacturers verify the compliance of their products and give confidence
that a proper interoperability level can be achieved.
For testing NCL applications, open-source NCL Players are available for Windows, Linux and MAC
platforms (http://www.gingancl.org.br/en/ferramentas). There are also several tools to help authors

Green book on IPTV Page 58 / 64

 Version 0.5

to design NCL applications. For example, one can find NCL Composer and NCL Eclipse at
http://www.ncl.org.br/en/autoria, which are two open-source authoring tools available in the official
site of the NCL language.

10.3 Other Recommendations

Recommendation ITU-T H.762 describes the high-level functionalities of the lightweight interactive
multimedia environment (LIME) for IPTV. LIME supports functionalities in IPTV terminal devices to
provide interactivity and a variety of content such as audio, video, graphics and text. Expected
services include additional data such as text to enrich television programmes, and two-way portal
pages.
This Recommendation describes the profile called "LIME-HTML" of W3C Recommendation XHTML
1.0, the profile called "LIME-CSS" of cascading style sheets 1 (CSS1), and a part of CSS2, the profile of
document object model (DOM) called "LIME-DOM", and a script language called "LIME-Script" that is
a subset of ECMAScript but has functional extensions required for IPTV services. It describes the use
of IP-based protocols for transport of LIME and IPTV-related services.
This revision includes the addition of explanatory text and definitions to enhance readability and
improve the understanding of the extended functions. Specifically, the change of the string "BML" to
"LIME" and the addition of explanations of the browser pseudo-object methods were considered.
These changes do not modify any accepted functions nor introduce any new functionality.
Recommendation ITU-T H.763.1 describes cascading style sheets (CSS) for IPTV. The CSS profile
presented in this Recommendation provides the means for describing the presentation style of
documents relative to IPTV terminal devices. This profile is based on CSS 1, a part of CSS 2 and a
number of extended properties required for IPTV services. CSS is human readable and writable, and
expresses style in common desktop publishing terminology.
Recommendation ITU-T H.764 describes an object-oriented programming language called "Internet
protocol television services enhanced script language (IPTV SESL)", which is based on LIME Script of
Recommendation ITU-T H.762, and includes enhanced functionalities. The language is used in IPTV
services for performing computations and manipulating computational objects within an IPTV
terminal device environment. There are two primary implementations of this Recommendation, the
"Core script profile" and the "Extended script profile". The core script profile is conformant with the
LIME-Script of Recommendation ITU-T H.762 and is used for the objects for client-side computation.
The extended script profile is necessary for the functional extensions required for IPTV services.

11 IPTV Service Discovery up to consumption

The H.770 series provide specifications for service discovery and selection for IPTV services:
– H.770 (08/2009): Mechanisms for service discovery and selection for IPTV services
– H.770 (2009) Amd.1 (11/2009): Mechanisms for service discovery and selection for IPTV
services: Updated Appendix I with multiple service platforms and Appendix II with
requirements in other standard organizations
– H.770 (2009) Amd.2 (09/2010): Mechanisms for service discovery and selection for IPTV
services: Support of service discovery using Broadband Forum TR-069
– H.771: SIP-based IPTV Service Discovery

Green book on IPTV Page 59 / 64

 Version 0.5

11.1 H.770: Mechanisms for service discovery and selection for IPTV
services
Extracted summary
Recommendation ITU-T H.770 describes the mechanisms for service provider discovery, service
discovery and selection for IPTV services. The mechanisms enable IPTV terminal devices to provide
the end-users with effective ways for consuming IPTV services. The expected types of IPTV services
using service discovery information include linear TV and video-on-demand, etc. This
Recommendation identifies service discovery metadata elements and attributes providing
information concerning service providers and contents/services, and its delivery protocols covering
both unicast and multicast transport mechanisms.
Amendment 1 (11/2009) adds descriptive texts concerning service provider discovery to Appendix I
and corrects errors identified in Appendix II.
Amendment 2 (09/2010) to Recommendation ITU-T H.770 adds new Appendix V on information for
service discovery using Broadband Forum TR 069 and introduces changes in the main body of the
Recommendation concerning its use.
Extended summary
Recommendation H.770 describes the data structures (used to describe service providers and their
services) and their delivery protocols to allow a user to discover them and at the end to consume a
service or a content.

Linear TV Channel

Linear TV
discovery
Service record Guide for
provider specific
Content guide TV channels
discovery
record discovery
record
Guide for
Entry Package VoD
point discovery contents
data record
Contents
Service
Service from other Guide for
provider service provider other services
discovery record
record Other services
discovery Other services
record

Scope of this Recommendation

Figure 5-2 from H.770 – From entry point data to service/content acquisition

Each IPTV architecture has its own way to make the starting entry point(s) available to the
IPTV terminal device.
The first step is to discover the service providers. All information about a service provider is stored in
a “service provider discovery record”. It may include:
• Record type = Service provider information (Mandatory)

Green book on IPTV Page 60 / 64

 Version 0.5

• Record version (M)

• Service provider identifier (M)
• Individual service provider information version (M)
• Service provider logo URI
• Service provider name
• Service provider description
• Web portal URL
• Service offer summary (one per offering)
o Push address (IP multicast address, port and source)
o Pull URL
o Web portal URL
o Offer type (Linear TV, package, content guide, service from another service provider,
other services
o Segment identifier and version (one or more segments containing a "detailed service
offer")
Service provider information is encoded in XML and can optionally be compressed.
A single organization may play various roles: network provider, service platform, SCP provider,
service provider.
The recommended transport mechanisms for the delivery of service provider discovery record are as
follows: HTTP version 1.1 [IETF RFC 2616], HTTP over TLS [IETF RFC 2818], IGMP version 2 [IETF RFC
2236], IGMP version 3 [IETF RFC 3376], MLD version 2 [IETF RFC 3810], FLUTE [ETSI TS 102 472] and
DVBSTP [ETSI TS 102 034].
From the “service provider information record”, the terminal device knows the type of services
(Linear TV, content guide, package) offered by each service provider available through the network
provider and where to get detailed information about each service and in particular how to access
them. Detailed information about a service is stored in a “service discovery record” specific to each
service type. A Linear TV discovery record may include:
• Record type = Linear TV discovery record (Mandatory)
• Record version (M)
• Service provider identifier (M)
• Metadata server URL
• Portal URL
• Purchase information URL
• Linear TV service (one or more)
o Service identifier (M)
o Original network Id
o Transport stream Id
o Service Id
o Max bit rate
o Service location (one or more)
IP multicast address, port and source, FEC base layer multicast address, FEC
enhancement layer multicast address, maximum packet number in blocks,
maximum FEC block duration, FEC specific information
Unicast URL
o Audio coding
o Video coding
o Service availability (list of 'cells' (regions) with which the service is associated)
Country code

Green book on IPTV Page 61 / 64

 Version 0.5

Availability (true or false)

Region code (one or more strings for geographical regions in the country)
o Streaming type (RTP or direct UDP)
o Multiplex mode (MPEG-2 TS or Time-stamped MPEG-2 TS)
For linear TV discovery without SI in MPEG-2 TS, the following 'additional linear TV discovery
elements/attributes' should be used:
o Type of service (coded as per the relevant SI standards: linear TV service, digital
radio sound service, mosaic service, data broadcast service, etc.)
o Priority SI source (in case SI is also present): XML, SI, SI+XML
o Service name (for display)
o Service description
o Content guide discovery record identifier(s)
o Preferred content guide discovery record location(s)
o Service genre(s): sports, football/soccer
o Announcement stream
o Secondary service Id
o Mosaic information
The “package discovery record” provides a means for a collection of services to be marketed as, or
grouped into, a single entity. It includes: record type (=package discovery record) (M), record version
(M), service provider identifier (M), package identifier (M), displayable (true or false), package name,
package description, preferred content guide discovery record identifier, preferred content guide
discovery record location, package reference(s) (identifiers of packages included in the current
package), individual service(s) (list of services forming the package), package availability (see “service
availability” above).
The “content guide discovery record” provides a means to discover the locations of guides listing
contents available, either live (e.g., through a linear TV offering) or via content on demand. It
includes: record type (=content guide discovery record) (M), record version (M), service provider
identifier (M), content guide discovery record identifier (M), content guide name, content guide
provider name, content guide description, content guide locator(s) (push mode, HTTP pull mode,
W3C SOAP pull mode, etc.), content guide logo URI, content guide type (guide for live programs,
content on demand, both, or some other form of content), target service provider identifier (to
identify the service provider whose content is described by this content guide).
A service provider can reference individual services or a complete offering provided by another
service provider and describe this in a "service from other service providers" with the following
elements: record type (=service from other service providers record) (M), record version, service
provider identifier (M), referenced service provider identifier, service identifier(s).
A variety of other services (e.g., SMS, email, e-newspaper) may be offered by a service provider and
the “other services discovery record” is used to describe them with the following elements: record
type (=SMS, email, chat, e-newspaper, etc.) (M), record version, service provider identifier (M),
service name, service identifier (M), service description, service locator (URI or IP addresses).
Additional specific elements might be needed for each individual service type.
All records are encoded in XML and can optionally be compressed.
The recommended transport mechanisms for the delivery of all types of discovery record are the
same as those listed above for the “service provider discovery record”.

Green book on IPTV Page 62 / 64

 Version 0.5

Annex A specifies “Service discovery profiles”. The different solutions recommended for delivery
protocols for the push mode lead to the definition of two profiles: profile A with DVBSTP and profile
B with FLUTE.
Appendix I introduces the issue of “Multiple service platforms”. It provides configuration examples
in which service providers offer services through several network providers and service platforms.
Illustration is also provided for service mobility.
Appendix II addresses “Requirements in other standards organizations”. It shows all the elements
defined in the main body (e.g. record type, service provider name) and their status in DVB, ATIS and
ITU-T (Unknown, Optional, Mandatory, Conditional).
Appendix III is about “The usage of TS with service discovery information”. Service information (SI)
consists of information tables defined by each standard DVB-SI ([ETSI EN 300 468]), ARIB-SI ([b-ARIB
B10]) and ATSC-PSIP ([b-ATSC A/65]).
Two solutions are possible as follows:
• TS-Full SI [ETSI TS 102 034]: A transport stream with embedded service information (SI) as
defined by broadcasting standards organizations (e.g. ARIB, ATSC and DVB), just as in
retransmission of broadcast channel captured from satellite or terrestrial broadcast. SI tables
and their descriptors are different for each standards development organization.
• TS-Optional SI [ETSI TS 102 034]: A transport stream with MPEG PSI (PAT and PMT tables) as
defined by ISO/IEC; all other MPEG-2 and other tables are optional.
Appendix IV describes “Alternative methods for entry point handling”. Alternative methods for
delivery and handling of entry data are as follows [b-ATIS-0800017] [b ETSI TS 183 063]:
• Preconfigured methods.
• DHCP-based methods,
• Download methods (also known as pull mode)
• TR-069 protocol-based method
• DNS service records (SRV)-based method.
Appendix V describes “Service discovery using TR-069”. This appendix describes how to use TR-069 to
discover service providers and services. Service provider information and service information are as
specified in the main body.
An extension to TR-135 (Data Model for a TR-069 Enabled STB) for service provider and service
discovery is specified.

11.2 Other Recommendations

Recommendation ITU-T H.771 describes the process for IPTV service provider discovery and service
discovery based on SIP [IETF RFC 3261]. The processes enable IPTV terminal device to acquire
information about available IPTV service providers and IPTV services.

12 Application of IPTV Technology

In addition to linear TV services, IPTV can be seen as a platform for rich, interactive services that
open opportunities for service providers and users. The following application cases for IPTV are
highlighted:

Green book on IPTV Page 63 / 64

 Version 0.5

– H.780: Digital signage: Service requirements and IPTV-based architecture

– H.810: Interoperability design guidelines for personal health systems

Recommendation ITU-T H.780 describes a general framework for digital signage (DS) services based
on IPTV architecture from the viewpoint of technical and service aspects. First, DS domains, a generic
DS architecture and the classification of DS services are introduced. As technical IPTV specifications
are close to those of DS, a brief comparison between the two services is provided (e.g., structure of a
functional group and detailed media processing). Subsequently, high-level requirements concerning
DS services are described. In addition, this Recommendation contains content delivery methods and
details of functionalities of both server- and client-side applications for DS services.
Recommendation ITU-T H.810: not yet available

Green book on IPTV Page 64 / 64