an overview of iptv standards development-lvz

IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009 315

An Overview of IPTV Standards DevelopmentJulien Maisonneuve, Muriel Deschanel, Juergen Heiles, Wei Li, Hong Liu, Randy Sharpe, and Yiyan Wu

Abstract—In the last few years, IPTV has emerged as oneof the major distribution and access techniques for broadbandmultimedia services. It is one of the primary growth areas for thetelecommunications industry. However, existing IPTV systemsare generally based on proprietary implementations that do notprovide interoperability. Recently, many international standardbodies have published, or are developing, a series of IPTV relatedstandards.. This paper is an overview of the most significant recentand upcoming IPTV standards.

Index Terms—Broadcast, IPTV, multicast, networks.

I. INTRODUCTION

TELEVISION distribution is one of the largest technology

infrastructures deployed after telephone and electric

power networks. Digital technologies have completely trans-

formed the telephone system creating a much more versatile

and dynamic telecommunications infrastructure and services.

The television distribution is now undergoing a similar digital

revolution. Internet Protocol Television, or IPTV, is one of the

promising techniques which takes a step further by merging

telecommunications and digital television delivery services,

unleashing new, more personal options to consumers, and

fulfilling the promises of a real home broadband multimedia

experience.

By early 2009, there should be more than 25 million IPTV

users in the world. Now it is a good time to take a step back and

look at what has been achieved, what is missing and what the

future might be holding.

The motivation for this IPTV special edition also resides in

the completion of a number of standardization activities that

have taken several years to achieve. It is interesting to take a

look at what standards have to offer, and how they might change

the landscape of IPTV in the years to come.

Manuscript received January 28, 2009; revised February 17, 2009. First pub-lished May 05, 2009; current version published May 22, 2009.

J. Maisonneuve is with the Alcatel-Lucent, 75008 Paris, France (e-mail:[email protected]).

M. Deschanel is with the Microsoft Corporation, Paris, France (e-mail:[email protected]).

J. Heiles is with the Nokia Siemens Networks, 80241 Munich, Germany(e-mail: [email protected]).

W. Li, H. Liu, and Y. Wu are with the Communications Research CentreCanada, Ottawa, ON K2H 8S2 Canada (e-mail: [email protected]; [email protected];[email protected]).

R. Sharpe is with the Alcatel-Lucent, Plano, TX 75075 USA (e-mail: [email protected]).

Color versions of one or more of the figures in this paper are available onlineat http://ieeexplore.ieee.org.

Digital Object Identifier 10.1109/TBC.2009.2020451

TABLE ICOMPARISONS BETWEEN TERRESTRIAL BROADCASTING TV AND IPTV

A. An Opening Market

IPTV has been a significant driver for telecom investments for

the last few years. The bandwidth requirements of video trans-

mission make it one of, if not the most, demanding mass-market

telecommunication applications to date. Transmission of a Stan-

dard Definition (SD) video stream takes several Mbit/s, while

High Definition (HD) reaches into the tens Mbit/s. This is far

more than what is required for voice transmission (typically 32

to 64 Kbit/s), or even to browse the internet.

As a result, IPTV has been the best motivation for operators

to deploy higher-speed DSL (no longer 256–784 Kbit/s but up to

28 Mbit/s), and to consider deploying optical fiber beyond cen-

tral offices to curb cabinets (FTTC), buildings or even homes

(FTTH). These capacity upgrades also bring much higher In-

ternet communication speed and enable new services such as

video telephony or file sharing, but it is not certain that in isola-

tion they would have been a sufficient motivation for operators

to invest in massive new infrastructures, or indeed for customers

to pay premium subscriptions. IPTV has been the catalyst for a

technology leap.

Because the basic technology—IP—is the same for the In-

ternet connection and IPTV, it enables a more fluid mix of ser-

vices that can share the available bandwidth more consistently.

B. Differences Between TV, IPTV and WebTV

The advantages and challenges of IPTV reside in the differ-

ences between existing terrestrial broadcasting TV, cable TV

and satellite TV [25]. IPTV differentiates from traditional ter-

restrial broadcasting TV in many ways. Table I lists some major

differences between these two services.

Comparing with existing cable TV and satellite TV, IPTV

distinguishes itself with full interactivity, high personalization

and flexibility as shown in Table II.

IPTV is not TV that is broadcasted over the Internet. There

are actually wide spread confusions between Internet TV and

IPTV. Table III illustrates a comparison between the two.

0018-9316/$25.00 © 2009 IEEE

Authorized licensed use limited to: Imperial College London. Downloaded on June 07,2010 at 19:38:59 UTC from IEEE Xplore. Restrictions apply.

316 IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

TABLE IICOMPARISONS BETWEEN CABLE TV, SATELLITE TV AND IPTV

TABLE IIICOMPARISONS BETWEEN INTERNET TV AND IPTV

C. IPTV and Standards

Interestingly, because IPTV is deployed within private IP

networks and it does not consume rare and shared resources

(such as radio spectrum), there has been no immediate need to

standardize systems and architectures. Indeed, one operator can

choose to deploy several IPTV systems on the same network

without major ill effects (if you exclude overall cost, the need

for a dedicated set top box and distribution network bandwidth

occupied by several systems operating in parallel).

This low level of constraint and the lack of a readily available

and comprehensive IPTV standard lead to a flurry of proprietary

implementations that now constitute the base of all IPTV sys-

tems in operation over the world. However, those systems are

still based on a number of key standards that had already reached

prevalence at design time.

Digital Video is not a new standardization subject, it has been

seen as a key development sector for more than 20 years. In

that space, some groups and organizations have gained almost

universal recognition. The first one is probably MPEG (Motion

Picture Expert Group) for its video coding (MPEG-2, MPEG-4)

and transmission protocols (MPEG TS).

Because of the unavoidable role of IP, the second one would

certainly be IETF (Internet Engineering Task Force) for its de-

livery and control protocols (RTP/RTCP, RTSP, SDP, SIP, etc.).

Fig. 1. Structure of IPTV systems.

Many other organizations have worked on IPTV specifica-

tions, but none has yet gained the industry-wide recognition and

there are no deployed systems based on those standards at this

time. Before we start standards review, it is important to obtain

a generic picture that will help to outline the differences and

common points between the proposed standard architectures.

D. Structure of IPTV Systems

By definition, IPTV is about sending video streams from

a source (a streaming device where the content is distributed

from) to a terminal. Video traffic can be divided in two cate-

gories: broadcast and video on demand. The former generally

requires the use of IP multicast to reduce the network band-

width required to carry the video streams by sharing it between

users. The latter generally uses plain Unicast (point to point)

delivery, but may be accelerated by interposing Content De-

livery Networks.

To get access to video content (either content on demand or

broadcast), a terminal needs to be aware of its existence and how

to access it: this is the role of the service guide.

The following diagram (Fig. 1) gives a very high level archi-

tecture of an IPTV system.

While the interface to the access network is generally

common, there are significant variations on how the other

components (e.g. control subsystem, Service Guide, etc.) are

structured and behave. In a setting where even subtle variations

on protocols or data formats can be a barrier to interoperability,

these differences created several families of systems, and

corresponding standards have been developed.

II. IPTV STANDARDIZATION ACTIVITIES

A. IPTV Standard Development at DVB Project

Traditionally, Digital Video Broadcasting (DVB) services are

delivered over broadcasting networks, i.e. a one-to-many uni-di-

rectional architecture. The advent of high-speed bi-directional

consumer broadband networks means that there is an increasing

demand to offer DVB services over IP (Internet Protocol) net-

works. The delivery of TV services using bi-directional IP over

a broadband network presents a particular set of challenges, es-

pecially when integrated with a range of other IP services.

DVB projects’ task, in response to calls from the industry, is

to help define and develop appropriate standards for the delivery

of DVB services over such networks, and to provide a means of


MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT 317

integrating them with other broadband services, whilst main-

taining maximum interoperability with existing DVB broadcast

standards.

DVB was one of the pioneer organizations to start standard-

ization work on the delivery of TV services over IP networks.

The DVB TM-IPI (Technical Module-Internet Protocol Infra-

structure) working group was set up back in 2000. Eight years

later, DVB released the fourth revision of the “Transport of

MPEG 2 TS Based DVB Services over IP Based Networks”;

specification, also referred to as the DVB-IPTV 1.4 handbook,

and soon to be published by ETSI as TS102 034 v1.4.1 [1].

DVB is led by commercial requirements which have evolved

over time as services have been introduced and deployed. This

has led to continuing updates of DVB-IPTV specifications.

The goal of the DVB-IPTV handbook is to specify technolo-

gies on the interface between an IP network and a Home Net-

work End Device (HNED), for example a Set-Top Box, en-

abling deployment of TV services over IP-based networks and

mass production of IPTV receivers by Consumer Electronics

manufacturers. The technologies specified, implemented in a

DVB-IPTV HNED, should allow a consumer to buy such a re-

ceiver in off-the-shelf, connect it to a broadband network, and

be able to choose and consume DVB services available over the

IP network. The specification covers several types of IPTV ser-

vices, such as Live Media Broadcast (i.e. TV or radio services),

Content on Demand, and content download services.

The following key functionalities are specified by the DVB-

IPTV handbook:

• The delivery of DVB MPEG-2 TS based services over

bi-directional IP networks for Live Media Broadcast ser-

vices (i.e. TV or radio services) and Content on Demand

(CoD) services. The transport part of the specification

covers the encapsulation of MPEG-2 TS services for

streaming delivery over IP and the protocols to be used to

access such services. Quality of Service is covered, based

on Differentiated Services (DiffServ).

• The delivery of Content Download Services (CDSs).

CDSs provide the download of content items to a local

storage of the HNED via a broadband IP connection.

CDSs can be used to provide IPTV services in areas where

a broadband connection suitable for streaming services is

not available or prone to errors, for simultaneous delivery

of multiple content items to HNEDs or for reduced cost

offers as the bandwidth consumption may be limited

compared to streaming services. Two types of services are

supported: push download services where the distribution

decision is taken by the service provider (without explicit

request from the user) and pull download services where

the download is requested by the user.

• The Service Discovery and Selection (SD&S) mechanism

for DVB based A/V services over bi-directional IP net-

works. The service discovery information, its data format

and the protocols to use for carriage of this information

are defined. Both push and pull models of delivery are

supported. Binarization encoding of SD&S information is

specified and can optionally be used if required. Support

for advanced codecs, logical channel numbering and sig-

naling regional DVB-IPTV services is provided.

• The use of command and control application-level protocol

RTSP to control CoD services and optionally to join mul-

ticast services.

• The assignment of an IP Address to a Home Network End

Device (HNED) to get onto the network. The specification

is based on DHCP and is restricted to the scenarios where

an HNED has a single interface onto the home network

and there is a single Delivery Network Gateway (DNG)

per home network segment.

• The File Upload System Stub (FUSS) which is mandatory

and allows the system software of an HNED to be updated

on a power-cycle or reboot. The sending of the system soft-

ware will be handled by the mechanisms in the optional

Remote Management and Firmware Update System for

DVB-IPTV Services (RMS-FUS) specification, ETSI TS

102 824 [2].

• Discovery of Broadband Content Guides (including third

party). The Broadband Content Guide is a content guide

that is delivered over an always-on bi-directional IP net-

work and is provided as a separate specification, ETSI TS

102 539 [3].

• An optional protocol for Application Layer FEC

(AL-FEC) protection of streaming media for DVB-IPTV

services carried over RTP transport. This AL-FEC pro-

tocol is a layered protocol with a base layer and zero or

more optional enhancement layer(s). The base layer is a

simple packet-based interleaved parity code based on a

subset of SMPTE 2022-1[4]. The base layer shall be used

wherever AL-FEC is used. The enhancement layer is a

Raptor code, as defined in ETSI TS 126 346 [5] and ETSI

TS 102 472 [6] and may optionally be used to provide

further packet loss protection.

• An optional retransmission mechanism (RET) to provide

for protection against packet loss of DVB-IPTV services

carried over RTP transport. It specifies the mechanism to

provide immediate feedback (FB) towards the network

using RTCP and how to retransmit the missing packets.

Packet loss repair can be achieved using the optional AL-FEC

solution, the optional retransmission solution or a combination

of both solutions.

The DVB-IPTV handbook specifies technologies on the in-

terface to the HNED and only the minimum necessary for in-

teroperability. The implementation of the HNED is left to the

CE (Consumer Electronic) manufacturers. The same applies for

the implementation of networking and service provider systems,

as long as their implementations meet the requirements on the

standardized HNED interface.

Fig. 2 defines a reference model of the home network and

some key interfaces. The key interface for standardization in the

DVB-IPTV handbook is the “IP Infrastructure-1” (IPI-1) inter-

face. The advanced home network functionality is not covered

in the current DVB-IPTV handbook and will be defined in a sep-

arate specification.

Fig. 3 is a logical diagram of the high-level protocols on the

IPI-1 interface, specified in the DVB-IPTV 1.4 handbook for en-

abling DVB services over IP-based networks and the associated

delivery and network support services. The organization of this

protocol stack is based on the hierarchical structure frequently



Fig. 2. Home network reference model.

Fig. 3. Diagram of the protocol stack for DVB-IPTV services.

applied in equipment design, i.e. service offering and applica-

tions, middleware and functions, IP protocols and transport, and

PHY/MAC/link layers. This follows the ISO/OSI layering con-

vention in general terms.

The top layer of this stack signifies the service offering in-

tended by the Service Provider. This consists of programs, infor-

mation about programs, multicast- and/or unicast IP addresses;

i.e. the essential items needed to enable a DVB service over an

IP network.

The IP protocol and transport layer attempts to identify which

protocols and transports are required and map the usage of those

protocols and transports to the functions of the layers above.

Operators require the flexibility to deploy IPTV services

according to their market requirements and business models,

taking into account the access network capabilities such as

limited bit rate. As an example, they may initially deploy only

one type of IPTV service (e.g. only live TV or only Content

Download), or they may want to mix a DVB-IPTV compliant

IPTV service with a proprietary IPTV service (e.g. a DVB

compliant live TV service, and a proprietary Video on Demand

portal). The DVB-IPTV handbook does not define subsets and

it became evident that a small set of service oriented profiles

were required to facilitate and maximize the stepwise deploy-

ment of IPTV services. This is essential for lower-cost and

differentiated services that do not require full implementation

of the DVB-IPTV handbook.

ETSI TS102 826 [7] defines four service oriented profiles:

• A basic profile to accommodate existing IPTV deploy-

ments of live TV services. This is the first step to achieve

a basic degree of DVB-IPTV compliance.

• Live Media Broadcast profile to build live IPTV services

carried over multicast transport and using SD&S for dis-

covery with legacy SI/PSI metadata support.

• Content on Demand profile to build On-Demand IPTV ser-

vices carried over unicast transport, RTSP connection, and

requiring BCG (Broadcast Content Guide) discovery with

TV-Anytime metadata support.

• Content Download profile to build services of content

available for download either in push or pull modes.

The structure used to define a profile is presented in more

details in Fig. 4.

DVB has also defined IPTV profiles for its interactive mid-

dleware specifications, DVB-MHP and GEM.

IPTV continues to be a very active and evolving activity in

DVB with many stakeholders involved both in the technical and

commercial groups. Future releases of the specification will see

many new and exciting features including a solution for fast

channel change which gives great improvement on zapping time

between TV services. Many research works have been done in

this area [32]–[35].

However, the distribution of audiovisual content is evolving

quickly and DVB needs to prepare the next steps. Work has now

been organized around two tracks. Track 1 covers delivery of



Fig. 4. Relationship between profile, module, option and extension.

DVB services over managed IP networks and Track 2 covers

delivery over the Open Internet.

The technical work on DVB-IPTV so far has been part of

Track 1 which will continue to evolve and will include in the

future more flexible stream composition to enhance IPTV ser-

vices, more straightforward interfaces to n-Play solutions (e.g.

telecommunication, mobile, etc.), and also support for hybrid

DVB broadcast and DVB-IPTV services. The recently started

Track 2 will cover the distribution of commercial content over

the Open Internet. DVB will endeavor to continue collaboration

with other standards development organizations through formal

liaisons as it is recognized that co-operation is essential to the

success of DVB solutions for IPTV in particular in the area of

n-Play.

B. ETSI TISPAN

ETSI TISPAN (European Telecommunications Standards

Institute Telecommunications and Internet converged Services

and Protocols for Advanced Networking) was chartered in

2004 to standardize Fixed NGN, working alongside 3GPP

which concentrated on mobile NGN. TISPAN NGN R1 was

completed in 2005 and focused on networking and VOIP

aspects. After more than two years of hard work, TISPAN has

published NGN R2 in June 2008. There are two variants of

IPTV in TISPAN R2 (and also in R3), differing in how they use

the IMS (IP Multimedia Subsystem, originated in the mobile

world of 3GPP) components.

TISPAN is open to all ETSI members and associate mem-

bers. Members usually are European companies, while associate

members can come from other countries (typically from Asia or

America). A number of non-European companies participate as

full members through European subsidiaries. TISPAN member-

ship is mainly composed of telecom vendors and operators.

TISPAN and IPTV: In TISPAN, IPTV is not the primary focus

of activities. To some extent IPTV can be seen as an applica-

tion (a Service, among others such as voice services) that is pro-

vided over a network and benefits from an existing ecosystem.

IPTV is thus reusing the properties of TISPAN NGN, such as

QoS, user and service profiles, authentication (with variants),

charging, etc.

NGN R1 did not address IPTV, but it was quickly recognized

that IPTV became a key application for NGN networks. IPTV

had higher bandwidth requirements than most existing applica-

tions (such as voice) and potential for rapid mass-market de-

ployment (more than videoconferencing). As a result, a number

of participants started to develop requirements for IPTV in late

2005 [8]. Two philosophies were developed on how those re-

quirements should be fulfilled: one was to adapt existing IETF

protocols to an NGN environment, the other to reuse the IMS

machinery for providing IPTV services. Because of the way

those two specifications were developed, they do not share many

components and can be described separately.

Dedicated IPTV: This IPTV variant [9] was designed as an

adaptation for NGN of the principles used in many existing

IPTV systems and mainly DVB-IP (as shown in Fig. 5). It is

based on proven IETF protocols (HTTP, RTSP, IGMP) used in

a straightforward way. Authentication needs to be supported

within the dedicated IPTV subsystem, but it otherwise makes

use of the NGN elements used to store user profiles (UPSF) and

control network characteristics and QoS (NASS and RACS). In

addition, it can make use of NGN charging. It supports 3 types of

IPTV services with trick play (pause, rewind, forward): Broad-

cast, Content on demand, and NPVR (network personal video

recorder).

The interaction between the User Equipment and the network

conforms to the DVB-IP 1.3 specification ([1], as outlined in

[12]) and uses HTTP and RTSP to control sessions. IGMP is

used to access multicast channels from the terminal. Bandwidth

reservation is performed on the RACS through the Gq’ interface,

just as other TISPAN applications.

IMS-Based IPTV: This IPTV variant [14] was designed to

take advantage of the benefits of the 3GPP IMS, originally de-

veloped to support IP multimedia communications in mobile

networks (as shown in Fig. 6). It relies on the use of the core IMS

and manages most interactions through the SIP (session initia-

tion protocol [13]) protocol. As a result, it benefits from the pop-

ular IMS features: implicit authentication, roaming across IMS



Fig. 5. TISPAN dedicated IPTV architecture.

Fig. 6. TISPAN IMS-based IPTV architecture.

networks, and natural interfacing to NGN components (UPSF,

NASS, RACS, charging). It supports 3 types of IPTV services

with trick play (pause, rewind, forward): Broadcast, Content on

demand, and NPVR (network personal video recorder).

Handling of Content on Demand session is very close to the

natural IMS model where session establishment and media con-

trol are joined: SIP/SDP interaction yields a bandwidth-allo-

cated session to the Media Delivery Function. Media control

(pause, rewind, forward, etc.) is then performed using a direct

RTSP connection to the Media Server.

Broadcast sessions are treated differently since they require

separation in two conceptual steps, one to reserve bandwidth

and another to gain access to multicast channels. To improve

performance, channel switching does not go through the IMS

core unless session parameters (bandwidth or charging) change.

As a result a third step is introduced to inform the IPTV appli-

cation of which channel a user settles upon.

The startup procedure begins with IMS registration of the user

equipment, and is followed by a service discovery procedure.

The latter can take two forms: one is to use SIP to get the dis-

covery data, and the other uses HTTP to get to the DVB Service

Discovery and selection mechanism. The User Equipment can

also get access to DVB BCG or OMA BCAST ESG.

The specification makes ample use of SIP extensions (such as

subscribe and notify) to provide additional services. The speci-

fication is following the same principles as the ones of the Open

IPTV Forum, but differs in a few aspects, making interoper-

ability unlikely without some alignment work.

Perspectives on TISPAN R3: In Release 3, the two families of

specifications will support new features described in [9]: IPTV

presence, access to third party content, P2P distribution, inter-

face with a Content Distribution Network, Forward Error Cor-

rection, NPVR command from another terminal and more fea-

tures that are added progressively. The R3 dedicated IPTV spec-

ification is [11] and the IMS-based IPTV specification is [15].

Assessment: After a few years of work, ETSI TISPAN

comes up with two reasonably complete IPTV specifications:

one based on IMS and the other based on DVB-IP 1.3. They

innovate in their degree of integration in the telecom network,



and borrow very significant elements from other existing spec-

ifications (mainly DVB-IP).

There are only a limited number of common components be-

tween these two specifications, less than what was achievable

when looking at the diagrams of ATIS IIF and ITU-T FG IPTV.

The specifications’ level of maturity has prompted other

organizations (such as MSF (MultiService Forum)) to reuse

the specifications for interoperability testing. There is a near

feature parity between the two, and their success will thus be

tested in the market, according to their respective merits and

performances.

C. ATIS IIF

The Alliance for Telecommunications Industry Solutions

(ATIS) is a leading standards development and technical

planning organization committed to rapidly developing and

promoting technical and operations standards for the com-

munications and related information technologies industry

worldwide using a pragmatic, flexible and open approach.

Participants from more than 300 communications companies

are active in ATIS’ 22 industry committees, Incubator Solutions

Programs, and other activities (http://www.atis.org).

The ATIS Board of Directors approved the formation of the

IPTV Interoperability Forum (IIF) in July 2005. More than

50 ATIS member companies are actively engaged in ATIS’

IPTV standardization efforts through the ATIS IIF, including

Verizon, Qwest, AT&T, BT, Alcatel-Lucent, Nokia Siemens

Networks, Nortel, Cisco, Motorola, Intel, Microsoft and Sun

Microsystems, among others. The IPTV IIF is an open forum

and all companies meeting the ATIS membership requirements

are eligible to become IIF participating companies.

IIF Mission/Scope: The IIF enables the interoperability, in-

terconnection, and implementation of IPTV systems/services by

developing ATIS standards and facilitating related technical ac-

tivities. This forum place an emphasis on North American and

ATIS Member Company needs in coordination with other re-

gional and international standards development organizations.

The scope of the work in the IIF includes the following areas:

1) Coordinate standards activities that relate to IPTV tech-

nologies. This includes providing a liaison function

between the various Standard Development Organizations

(SDOs), forums, and other ATIS committees/forums that

are each working on important components for multi-

media, but may not have visibility to other aspects of the

application.

2) Develop self-consistent ATIS standards, such as interoper-

ability requirements, specifications, guidelines, and tech-

nical reports.

3) Provide a venue for interoperability activities.

4) Provide a venue for the development of standards and

other documents for IPTV systems/services deployed over

a managed IP and/or NGN infrastructure.

IIF Committee Structure: The IIF is composed of five

committees:

• Architecture

• IPTV Security Solutions

• Quality of Service Metrics

• IIF Testing and Interoperability

• Metadata and Transaction Delivery

The Architecture Committee develops IPTV architecture re-

quirements, specifications, protocols, and other documents re-

quired to enable deployment of a standardized, interoperable,

and access-agnostic IPTV service.

The IPTV Security Solutions Committee develops security

standards with emphasis on a security requirements framework

and an integrated toolkit of security functions that can be uti-

lized for an interoperable solution for enabling IPTV services.

The Quality of Service Metrics Committee develops stan-

dards that define metrics, models, and approaches for measure-

ment and reporting of quality of service (QoS) and quality of

experience (QoE) for IPTV services.

The Testing and Interoperability Committee develops the

necessary test scripting and test planning for the interoperability

of ATIS IIF standards and addresses IPTV interoperability is-

sues, providing recommended courses of action for mitigation

of the identified issues.

The Metadata and Transaction Delivery Committee develops

standards that define metadata elements, the representation of

metadata elements, and the content of application-level trans-

actions where the MTD Committee is the primary developer of

metadata standards in support of all ATIS IIF Committees.

Accomplishments: Since its establishment, the ATIS IIF has

produced a number of key requirements and framework doc-

uments to serve as the foundation for further development of

IPTV specifications and standards. The following summarizes

key activities and deliverables to date:

• IPTV DRM Interoperability Requirements (ATIS-

0800001.v002)—This ATIS standard defines the require-

ments for the interoperability of systems and components

in the IPTV DRM/security environment.

• IPTV Architecture Requirements (ATIS-0800002)—The

ATIS IIF delivered the industry’s first set of IPTV archi-

tecture requirements that define, in broad terms, the scope

of IPTV services and the high level requirements that will

guide the development of architecture specifications over

time. This architecture document focuses on services that

may comprise IPTV; the functions necessary for content

providers to deliver content to service providers; the func-

tions required by service providers and network providers

to offer IPTV; and the home networking functions neces-

sary for the consumer to receive IPTV services.

• IPTV Architecture Roadmap (ATIS-0800003)—The IPTV

Architecture Roadmap defines the phases in which IPTV

architecture standards will be developed. The document

calls for the release of specifications in three phases. The

first phase includes specifications for network/service at-

tachment; service discovery; basic navigation through ser-

vices; and regulatory compliance, including Emergency

Alert Services (EAS), Closed Caption and Parental Advi-

sory. A second phase of specifications will address video

on-demand (VOD) and pay-per-view (PPV) transaction-

based services. Phase three will address interactive TV,

multiplayer games, network PVR, and in-home peer-to-

peer interaction.

• Framework for QoS Metrics and Measurements Sup-

porting IPTV Services (ATIS-0800004)—The framework



serves as a basis for definitions of Quality of Service

(QoS)/Quality of Experience (QoE) related to different

segments of the network, different service instances or

invocations, network architectures/technologies utilized,

and modes of service. The document offers an overview

and concepts related to the following: measurement model

and measurement points; quality layers, protocol stack

view, and use cases; types, characteristics, and definitions

of metrics; a QoS/QoE model; measurement practices

and methodologies; time and frequency synchronization

requirements for ensuring QoS/QoE, and enabling metrics

measurement.

• IPTV Packet Loss Issue Report (ATIS-0800005)—The re-

port reviews factors that may cause packet loss in IPTV

transmissions and addresses solutions to mitigate packet

loss.

• IIF Default Scrambling Algorithm (ATIS-0800006)—This

document specifies a default scrambling/descrambling al-

gorithm for MPEG-2 Transport Stream and scrambling al-

gorithm signaling. Use of the specification provides net-

work operators with a maximum choice of IPTV receiving

device platforms.

• IPTV High Level Architecture (ATIS-0800007)—This

document provides a high level architectural framework for

end-to-end systems’ implementation and the supporting

network design. This serves as reference architecture for

the IPTV functional specifications being defined in sepa-

rate IIF specification. The IIF IPTV functional architecture

is based on an NGN framework allowing either core-IMS

based service control or a dedicated IPTV service con-

trol, with an emphasis on commonality of functions and

interfaces.

• QoS Metrics for Linear Broadcast IPTV (ATIS-

0800008)—This document provides a consensus view

of the meanings of QoS metrics for linear broadcast IPTV,

including video, audio, and the synchronization between

audio and video. It also identifies measurement points, ap-

plicable measurements and measurement methodologies.

• Remote Management of Devices in the Consumer Do-

main for IPTV Service (ATIS-0800009)—This document

addresses the remote management of devices in the con-

sumer domain, focusing initially on the Delivery Network

Gateway (DNG) and IPTV Terminal Function (ITF) de-

vices. Additionally it addresses device attachment to the

transport network; software image download; provisioning

of parameters; status monitoring; remote diagnostics; fault

recovery; and security management.

• Emergency Alert Provisioning Specifications (ATIS-

0800010)—The Emergency Alert System (EAS) for IPTV

addressed in this document broadens the delivery of EAS

messages from a few linear channels to the complete IPTV

experience, spanning the full range of activities from

live and recorded TV viewing, through games, internet

streaming and sourced content, and even including IPTV

client menu activities. The goal is to deliver important

emergency alerts to any person using the IPTV service,

independent of activity.

• QoS Metrics and Measurements for Public Services (ATIS-

0800011)—This document defines a base set of Quality of

Service metrics for regulatory services, including Emer-

gency Alert Systems, Closed Captioning and Content Ad-

visories, and V-Chip Technology.

• IPTV Emergency Alert System (EAS) Metadata Re-

quirements (ATIS-0800012)—Building upon the system

requirements given in ATIS-0800010, this document de-

fines an XML schema used for delivery of emergency alert

signaling and information to the IPTV service provider’s

EAS Ingestion System (EIS), and for delivery of alert

information and signaling to the IPTV terminal function

on the consumer premises. In addition, the document

specifies the methods used to authenticate EAS data and

audio files.

• Secure Download Interoperability Specification- (ATIS

-0800014)—This document specifies the IPTV Security

Solution/Authentication (ISS/A), which is used to authen-

ticate downloads and messages to IPTV receiving devices.

• Network Attachment and Initialization of Devices and

Client Discovery of IPTV Services (ATIS-0800017)—This

specification seeks to provide an overall end-to-end, high

level description of the process for attaching a device to

the network and service provider and readying the device

for service provision.

• IPTV Linear/Broadcast Service (ATIS-0800018)—This

specification defines the basic linear TV service oper-

ation after the initialization, configuration, and service

provider discovery documented in ATIS-0800017 and

ATIS-0800009. This specification describes a basic ac-

quisition mechanism for linear TV content channels

with options for various network resource allocation

mechanisms.

• IPTV EPG Metadata Specification (ATIS-0800020)—This

document specifies the logical data model and delivery

mechanisms for IPTV Electronic Program Guide (EPG) in-

formation to be delivered from EPG servers in the service

provider domain to EPG clients in the consumer domain.

The logical data model is specified in the form of an XML

schema. The delivery specifications include fragmentation,

encoding, encapsulation, and transport of the EPG infor-

mation, with support for both multicast push and unicast

pull transport.

• EPSNR Trial Use (ATIS-0800021)—This document de-

scribes a technique to generate an estimate of video quality

by estimating Peak Signal-to-Noise Ratio (PSNR). The Es-

timated PSNR (EPSNR) algorithm is experimental in na-

ture, and requires additional testing and validation; there-

fore, it is being published as a Trial-Use Standard in order

to facilitate evaluation by the industry.

• Consumer Domain Configuration Metadata Requirements

Specification—This document identifies requirements for

metadata associated with configuration of consumer do-

main devices - specifically the Delivery Network Gateway

(DNG) and the IPTV Terminal Function (ITF) - during net-

work attachment, initialization, configuration and remote

management. Initialization and configuration of the ITF

and DNG in a consumer domain may require metadata ex-



change between these consumer domain devices and ser-

vice provider and/or network provider systems.

• IPTV Metadata Consumer Requirements Specification—

This document will address the need to establish basic con-

sumer (subscriber and user) profile and preferences meta-

data requirements for an IPTV Consumer Metadata Spec-

ification/Standard.

• Application Level Interfaces (API) Interoperability Spec-

ification—This specification will address the need for in-

teroperable DRM Application Programming Interfaces.

• Media Protocols Specification (0800013)—This specifica-

tion will define the media protocols, including reliability

protocols, for IPTV service. Media protocols include the

protocols used for actual audio and video media delivery

over IP. Definition of the protocol stack from the IP layer

upwards is required and should include consideration of

reliability techniques applied at the IP layer and above, ex-

amples of which include quality of service marking, for-

ward error correction at the application or transport layer,

and retransmission.

• IPTV Multicast Network Service Specification—This

specification is designed to describe a simple IP multicast

service that the network provider can offer for use as a

basis for a linear/broadcast TV service. The intent is to

focus on the service requirements from the perspective

of the IPTV service provider rather than detail specific

implementation mechanisms within the network operator

domain.

• IPTV Digital Rights Management (DRM) Requirements

Update—This document will address the maintenance of

the DRM requirements document as IIF members, IPTV/

DRM stakeholders, and/or IPTV liaison partners introduce

changes based on working with the IPTV DRM specifica-

tion. The purpose of the document is to incorporate con-

sensus issues and introduce specific deliverables to supple-

ment and/or revise the DRM requirements document.

• Categorized Listing of Fault Modes for IPTV—This doc-

ument will define a standard set of fault modes that cause

the improper functioning of an IPTV component or signal.

The type of fault is a vital input to service assurance, test,

fault and performance operations and systems.

• Certificate Trust Management Hierarchy—This specifica-

tion will provide the basis of trust for Public Key Infra-

structure (PKI) operations by creating a PKI hierarchy that

satisfies trust requirements of security solutions, identi-

fying trust relationships affected by PKI hierarchies, and

establishing requirements for the generation, distribution,

and revocation of IIF PKI certificates.

• Standard Public Key Infrastructure (PKI) Certificate

Format—This document will standardize the delivery,

distribution, and validation of encrypted keys in a trusted

certificate format. The encrypted keys within a key cer-

tificate are a security component consisting of digital

signatures used to authenticate data sources and content.

• Security Robustness Rules—This specification aims to fa-

cilitate interoperability and encourage product innovation

while maintaining standardized procedures, interfaces, and

platforms with respect to secure transmission and storage

of materials.

• Distribution of Content in the Subscriber’s Authorized Ser-

vice Domain—This document will identify requirements

for interoperability of the system and components neces-

sary to share protected content in the IPTV/DRM security

environment.

The ATIS IIF documents are available in the ATIS document

Center at: https://www.atis.org/docstore/default.aspx.

D. ITU-T IPTV Focus Group and GSI

The International Telecommunications Union—Telecommu-

nication Standardization Sector (ITU-T, formerly CCITT) is a

Geneva-based United Nations (UN) organization responsible

for fostering cooperative standards for telecommunications

equipment and systems. The ITU-T mission is to ensure the

efficient and timely production of standards (referred to as

“Recommendations”) covering all fields of telecommunications

on a worldwide basis, as well as defining tariff and accounting

principles for international telecommunication services. Given

that IPTV is becoming an increasingly important service in the

market, and that more and more manufacturers and operators

are facing challenges from technical as well as regulatory

issues, ITU-T has received proposals to strengthen its work on

IPTV standardization. There is an urgent need to increase the

international effort on various issues, in particular, interoper-

ability and gap analysis of IPTV standards. Since late 2005,

ITU-T Study Group Chairmen have studied possible measures

to take care of the IPTV study within ITU-T, including coor-

dination with other Standardization Developing Organizations

(SDOs). During the TSB director’s consultation meeting on

IPTV standardization [22], the consensus had been reached to

support the TSB Director to create, according to ITU-T Rec-

ommendation A.7 [23], a focus group, the IPTV Focus Group

(FG IPTV). Focus Group is a more efficient way to allow ITU

to take the lead in coordinating and developing global standards

to enable rapid progress and to avoid market fragmentation.

The mission of FG IPTV was agreed on this TSB director’s

meeting [22] as: “The mission of IPTV FG is to coordinate and

promote the development of global IPTV standards taking into

account the existing work of the ITU study groups as well as

Standards Developing Organizations, Fora and Consortia.”

Different from Study Groups (SGs), the FG IPTV opens to

ITU member states, sector members and associates, and it also

opens to any individual from a country which is a member of

ITU who wishes to contribute to the work (this includes indi-

viduals who are also members of international, regional and

national organizations). This provides ITU-T the way of re-

sponding to market needs very quickly and of doing the job in

the most efficient, transparent and professional manner.

As a start point, the following goals of FG IPTV were

developed:

• Definition of IPTV

• Review and gap analysis of existing standards and ongoing

works

• Coordination of existing standardization activities

• Harmonization of the development of new standards



Fig. 7. FG IPTV and IPTV GSI compositions.

• Encourage interoperability with existing systems where

possible

From July 2006 until December 2007, a total of seven meet-

ings were held. As illustrated in Fig. 7, the FG IPTV separated

its tasks into six areas corresponding to six Working Groups

(WGs). Significant progresses have been made in these six

areas. Each area has produced enriched documents covering

most of the IPTV worldwide development efforts.

The FG IPTV ended in December 2007 and its documents

were transferred to the appropriate study groups via Study

Group 13. The ongoing work has been carried out under the

umbrella of a Global Standards Initiative (IPTV-GSI) via

related study groups (SGs). Fig. 7 shows the IPTV-GSI related

SGs. The IPTV-GSI focuses on speedy preparation of ITU-T

Recommendations (standards) based on the output of the Focus

Group as well as the detailed protocols necessary.

Some important achievements towards IPTV standardization

are listed below:

Definition of IPTV: The consensus was reached during the

first FG IPTV meeting on the IPTV definition [24]: “IPTV is

defined as multimedia services such as television/video /audio/

text/graphics/data delivered over IP based networks managed to

provide the required level of QoS/QoE, security, interactivity

and reliability.”

IPTV Domains: Four IPTV domains are identified including

content provider, service provider, network provider and end

user.

IPTV Architectural Approaches: Three IPTV architecture

approaches are identified that enable service providers to de-

liver IPTV services. These include: Non-NGN IPTV functional

architecture (Non-NGN IPTV), NGN-based non-IMS IPTV

functional architecture (NGN-Non-IMS IPTV) [26], [27], NGN

IMS-based IPTV functional architecture (NGN-IMS-IPTV)

[28].

IPTV Functional Architecture: Fig. 8 provides an overview

of the IPTV functional architecture. Functions and functional

blocks described in this clause are common to all architectural

approaches. Various IPTV architectural options and more de-

tailed architectural descriptions can be found in [29].

Quality of Experience (QoE) Dimensions: QoE is defined in

[30] as the overall acceptability of an application or service, as

perceived subjectively by the end-user. Quality of Service (QoS)

is defined in [31] as the collective effect of performance which

determines the degree of satisfaction of a user of the service. In

telecommunications, QoS is usually a measure of performance

of the network itself.

Fig. 9 shows factors contributing to QoE.

In upcoming IPTV-GSI events, regular ITU-T working

methods and procedures will apply by means of the work

carried out by the experts of the relevant Study Groups where

global standards will be developed.

Up to now, a total of five IPTV-GSI events have been held.

For example, SG13 (next generation networks) further details

the IPTV architectural design issues including requirements,

network control, service management, traffic classification, etc.

SG16 (multimedia terminals, systems and applications) contin-

uously completes the IPTV terminal device basic models, ser-

vice discovery and consumption mechanisms, multicast func-

tion support, broadcast-centric IPTV terminal middleware, etc.

SG12 is working towards the completion of new recommenda-

tions on IPTV QoE, performance monitoring, etc. The IPTV

GSI events see many new draft recommendations on different

aspects (Questions) in various Study Groups.

E. Open IPTV Forum

The Open IPTV Forum is a pan-industry initiative with the

objective to specify a common and open end-to-end solution for

supplying a variety of IPTV and internet multimedia services

to retail based consumer equipment in the home. The Forum,

which is open to participation from the communications,

entertainment and other relevant industries, will focus on the

development of open standards that will help streamline and

accelerate deployments of IPTV technologies, and maximize

the benefits of IPTV for consumers, network operators, content

providers, service providers, consumer electronics manufac-

turers and home and network infrastructure providers.

The Forum was founded in January 2007 by Ericsson, France

Telecom, Nokia Siemens Networks, Panasonic, Philips, Sam-



Fig. 8. IPTV architectural overview.

Fig. 9. QoE dimensions.

sung, Sony and Telecom Italia. While standardization for IPTV

was already going on at that time in several standardization

bodies, the founding members noted that a single specification

that covers all aspects of end-to-end solutions for IPTV and mul-

timedia services delivered both via Managed Networks and the

Open Internet as shown in Fig. 10 was missing. Such a specifi-

cation will ensure the interoperability between consumer equip-

ment and the service offerings, which will make it possible for

the end users to easily access their choice of content and services

offered from multiple service providers. The Forum’s plan is to

extend the specification work with a certification and logo pro-

gram in order to foster interoperability. In the mean time the

Forum membership has increased to over 60 members covering

most parts of the IPTV ecosystem.

An important objective of the Forum is to base its specifica-

tions on existing technologies and open standards as much as

possible. The intention of the Forum is not to create yet another

standardization initiative, but to define a complete delivery so-

lution by profiling existing standards and filling the gaps where

necessary. The Forum will work closely with existing standard-

ization efforts and address those areas which need enhance-

ments by actively contributing the work of the Forum. Currently

the Forum is in the process to setup liaison activities with rele-

vant standardization organizations and fora.

Fig. 10. Open IPTV forum scope.

The Forum’s directions are set by the Steering Group, sup-ported by four ad-hoc groups for working procedures, admin-istration and budget, certification and logo program and stan-dards coordination as shown in Fig. 11. Five working groupsare assigned to drive the Forum’s specification, interoperability,testing, and marketing activities. Requirements specified by theRequirements Working Group are the starting point of any spec-ification work. These requirements are defined based on usercases contributed by the Forum’s members. Based on the re-quirements a functional architecture is defined by the Architec-ture Working Group in order to provide the directions for thetechnical specifications defined by the Solution Working Group.The Solution Working Group has several Task Forces to coverspecific areas of the overall solutions like protocols, codecs,metadata, content protection and application execution environ-ments. Based on the technical specification, the Interoperability& Test Working Group will define test specifications as inputfor the planned certification & logo program. The objective ofthe Marketing Working Group is to communicate and promotethe Forum’s activities and specifications in order to obtain widerrecognition and support in the industry and from end-users.



Fig. 11. Open IPTV forum organization.

The Forum has just published its technical specification workfor Release 1. Release 1 focuses on basic IPTV services likescheduled content service, content on demand and personalvideo recording. In addition the integration with communi-cation services like chatting and messaging and interactiveapplications are in the focus. For a detailed description ofthe Release 1 services and functions see [16]. The Release 1Requirements [17] and Architecture [18] are already finalizedand publicly available. The technical specifications are ex-pected to be finalized in mid of 2008. In parallel the work onrequirements for Release 2 has already started. It will extendthe Open IPTV Forum specifications with enhanced interactivefunctions, tighter integration with communication services,new advertising features and the support of converged services,which can be accessed on various end devices connected viafixed and mobile access networks. This will allow the end userto consume and control IPTV services not only on the TV, butalso on the PC, mobile phone and PDA at home or on the move.

As an unique approach, the Forum covers IPTV and multi-media services available both via a Managed Network and theOpen Internet. A common User-Network Interface (UNI) willensure that the end user has access to a variety of services of-fered by multiple service providers both over Managed Net-works and the Open Internet. This will make the overall ser-vice offering more attractive and result in a wider availability ofend devices as they will not be dedicated to a specific serviceoffering. It is expected that Open IPTV Forum compliant enddevices will become available for the retail market, giving theend user a choice between different devices and different serviceofferings and as such stimulating the overall IPTV market. Inorder to achieve the goal of a common UNI, but still be open fordifferent business models, the Forum has defined several func-tional entities within the consumer domain as shown in Fig. 12.

The Open IPTV Forum Terminal Function (OITF) providesthe basic functionality to access IPTV services via the Open In-ternet. This includes services discovery, user profile manage-ment, metadata processing, content streaming, content and ser-vice protection, audio and video decoding, service monitoringand a declarative application environment for server based ap-plications and access to web based services. Service discovery,

Fig. 12. Open IPTV forum consumer domain architecture.

metadata, content delivery and A/V codecs will be based onthe DVB IPTV specifications, while the declarative applicationenvironment will be based on CE-HTML as defined by CEA(Consumer Electronics Association). Optionally storage func-tionality for local PVR (Personal Video Recorder) and con-tent download services and DLNA (Digital Living Network Al-liance) Digital Media Player (DMP) and Digital Media Server(DMS) functionality can be included. The latter two allow ac-cess to content from other DLNA devices (DMP functionality)and make Open IPTV Forum services available to other DLNAdevices (DMS functionality) on the residential network.

For managed network services, the IP Multimedia Subsystem(IMS) Gateway (IG) is introduced. The managed network isbased on IMS as defined by 3GPP and ETSI TISPAN. IMSprovides authentication, session management, resource and ad-mission control, billing and user management functions. TheIG contains the IMS client for authentication and session man-agement, and optionally the Universal Integrated Circuit Card(UICC) for IMS Services Identity Module (ISIM) based authen-tication. It provides session management for IPTV services likeCoD and scheduled content offerings, but also the integrationwith IMS based communication services like presence, callerID, chatting and messaging.

In case support for local applications (e.g. advanced inter-active applications, home control) is needed, the ApplicationGateway (AG) has to be used. It allows Java based applicationsto be installed from the network and run locally in the consumerdomain. The AG has the capability to control and intercept themedia stream for the purpose of inserting content generated orstored in the AG into that media stream. It can also interact withthe IG in order to access and control managed network services.

While the OITF (Open IPTV Terminal Function) uses a spe-cific Content and Service Protection (CSP) solution, it will alsobe possible to support alternative CSP solutions via the CSPGateway (CP). The CP terminates the alternative CSP scheme



and uses DLNA link protection for secure communication be-tween itself and the OITF and AG.

The Wide Area Network (WAN) gateway (WG) representsthe residential gateway including network attachment and re-mote management functionality.

The functional gateway entities can be implemented in dif-ferent physical devices. The OITF, AG and IG can be for ex-ample part of an IPTV set-top box. Networked TVs with inte-grated IPTV set-top box functionality may implement the OITFfunction only. In this case IG, AG and CP have to be provided byadditional devices (e.g. a residential gateway that already sup-ports IMS/SIP functions for Voice over IP) as needed.

With its objective to define an interoperable end-to-end so-lution both for Managed Networks and the Open Internet, theintegration of communication services and the support of webbased applications and services, the Open IPTV Forum pro-vides a unique approach to foster and widen the IPTV market.Having its work based on already existing specifications and on-going work in other standardization bodies and fora will reducethe time to market and helps to increase the acceptance of theForum’s work.

III. CONCLUSIONS

We have just reviewed the five major IPTV standard or-ganizations and the corresponding specifications that werecompleted in 2008 (some of which are still being extended in2009). It should be noted that in the meantime, another organ-ization—The Object Mobile Alliance (OMA)—has steppedforward to start a new work item on IPTV as a follow up to itswork on Mobile TV (OMA BCAST). There are not only signifi-cant overlaps among existing specifications, developments alsoseem to evolve towards more divergence within IPTV systems.

As before, the upcoming specifications share a lot of commonelements, but fall short of providing interoperability betweenthemselves because they differ in many details. There is thus astrong risk to see new standard-based technology islands emergealongside the existing proprietary islands. Because of the largenumber of alternatives, there is a fair chance that one or severalof those islands will eventually wither and die.

However, there will still be issues of interoperability betweenIPTV systems, and possibly with mobile TV systems. The pur-suit of a single IPTV standard may have failed, but there maystill be room to achieve convergence standards that will bringtogether those technology islands for the purpose of bridgingtheir functionality. This is work that the ETSI MCD TC initia-tive has started to explore.

With so many available standards, vendors and operators willneed to make hard choices, and interoperability may not be pos-sible before another generation of standards is born, or one winsover all the others. Both ways are open, and they may take lesstime than the previous round of exploratory standards. It mightbe a long and tortuous path.

The published standards dealt with basic IPTV scenarios, butthe current standard work comes closer to state-of-the-art de-velopments. In the past years, a significant amount of researchhas been done on IPTV related issues, such as channel zap-ping, QoS/QoE, admission control, and network interconnec-tivity [32]–[38]. Many articles in this Special Issue focus on

more advanced issues that researchers are exploring for the nextgeneration of IPTV systems and services.

REFERENCES

[1] Transport of MPEG-2 TS-Based DVB Services Over IP Based Net-

works., ETSI TS 102 034.[2] Remote Management and Firmware Update System for DVB IP Ser-

vices, ETSI TS 102 824.[3] Carriage of Broadband Content Guide (BCG) Information Over In-

ternet Protocol, ETSI TS 102 539.[4] Forward Error Correction for Real-Time Video/Audio Transport Over

IP Networks, SMPTE specification 2022-1(2007).[5] Universal Mobile Telecommunications System (UMTS); Multimedia

Broadcast/Multicast Service (MBMS); Protocols and codecs; (3GPP

TS 26.346 Release 6), ETSI TS 126 346.[6] Digital Video Broadcasting (DVB);IP Datacast over DVB-H: Content

Delivery Protocols, ETSI TS 102 472.[7] DVB-IPTV Profiles for TS 102 034, ETSI TS102 826.[8] TISPAN; Service Layer Requirements to integrate NGN Services and

IPTV, ETSI TS 181 016, Ver. 2.0.0.[9] TISPAN: Service Layer Requirements to integrate NGN services and

IPTV (R3), ETSI TS 181 016 Ver. 3.0.1.[10] TISPAN; IPTV Architecture; Dedicated subsystem for IPTV functions,

ETSI TS 182 028 , Ver. 2.0.0.[11] TISPAN; IPTV Architecture; Dedicated Subsystem for IPTV Functions,

ETSI TS 182 028, Ver. 3.0.0.[12] DVB Bluebook A128 (02/07) DVB-IP Phase 1.3 in the Context of ETSI

TISPAN NGN.[13] Session Initiation Protocol, IETF RFC 3261.[14] TISPAN; IPTV Architecture; IPTV Functions Supported by the IMS

Subsystem, ETSI TS 182 027, Ver. 2.0.[15] TISPAN; IPTV Architecture; IPTV Functions Supported by the IMS

Subsystem, ETSI TS 182 027, Ver. 3.0.[16] “Open IPTV Forum, Services and Functions for Release 1, Ver-

sion 1.0.,” [Online]. Available: http://www.openiptvforum.org/docs/Open_IPTV_Forum_Services_and_Functions_for_Release_1_V10.pdf

[17] “Open IPTV Forum, Service and Platform Requirements, Version1.0.,” [Online]. Available: http://www.openiptvforum.org/docs/Open_IPTV_Forum_Service_and_Platform_Requirements_V10.pdf

[18] “Open IPTV Forum, Functional Architecture, Version 1.1.,” [Online].Available: http://www.openiptvforum.org/docs/OpenIPTV-Func-tional_Architecture-V1_1-2008-01-15_APPROVED.pdf

[19] Transport of MPEG-2 TS-Based DVB Services Over IP Based Net-

works, ETSI TS 102 034.[20] Remote Management and Firmware Update System for DVB IP Ser-

vices, ETSI TS 102 824.[21] Carriage of Broadband Content Guide (BCG) Information Over In-

ternet Protocol, ETSI TS 102 539.[22] “Final Report of the TSB Director’s Consultation Meeting on IPTV

Standardization,” Geneva, Switzerland, FG IPTV-DOC-0046, Apr.4–5, 2006.

[23] “Focus Groups: Working Methods and Procedures,” ITU-T Recom-mendation A.7, Oct. 2000.

[24] “Mandate and terms of reference of FG IPTV working groups,” in First

Meeting of the FG IPTV, Geneva, Switzerland, Jul. 10–14, 2006, FGIPTV-OD-0001.

[25] “Mandate and terms of reference of FG IPTV working groups,” in IBC

2007, Amsterdam, The Netherlands, Sep. 7–11, 2007.[26] “General Overview of NGN,” ITU-T Recommendation Y.2001, Dec.

2004.[27] “Functional Requirements and Architecture of the NGN,” ITU-T Rec-

ommendation Y.2012, Aug. 2006.[28] “IMS for Next Generation Networks,” ITU-T Recommendation

Y.2021, Aug. 2006.[29] “IPTV Architecture," Qawra, Malta, FG IPTV-DOC-0181, Dec.

11–18, 2007.[30] “Appendix I to P.10/G.100: Definition of QoE,” Geneva, ITU-T

P.10/G.100, Jan. 16–25, 2007.[31] “Telephone Network and ISDN Quality of Service, Network Manage-

ment and Traffic Engineering: Terms and Definitions Related to Qualityof Service and Network Performance Including Dependability,” ITU-TRecommendation E.800, Aug. 1994.

[32] W. Sun, K. Lin, and Y. Guan, “Performance analysis of a finite durationmultichannel delivery method in IPTV,” IEEE Trans. Broadcasting,vol. 54, no. 3, Sep. 2008.



[33] H. Joo, H. Song, D.-B. Lee, and I. Lee, “An effective IPTV channelcontrol algorithm considering channel zapping time and network uti-lization,” IEEE Trans. Broadcasting, vol. 54, no. 2, pp. 208–216, Jun.2008.

[34] M. Rezaei, M. M. Hannuksela, and M. Gabbouj, “Tune-in time reduc-tion in video streaming over DVB-H,” IEEE Trans. Broadcasting, vol.53, no. 1, Part 2, pp. 228–320, Mar. 2007.

[35] D. lee, H. Joo, and H. Song, “An effective channel control algorithm forintegrated IPTV services over DOCSIS CATV networks,” IEEE Trans.

Broadcasting, vol. 53, no. 4, pp. 789–796, Dec. 2007.[36] U. Jennehag, T. Zhang, and S. Pettersson, “Improving transmission ef-

ficiency in H.264 based IPTV systems,” IEEE Trans. Broadcasting, vol.53, no. 1, Part 1, pp. 69–78, Mar. 2007.

[37] A. Davy, D. Botvich, and B. Jennings, “Revenue optimized IPTV ad-mission control using empirical effective bandwidth estimation,” IEEE

Trans. Broadcasting, vol. 54, no. 3, Part 2, pp. 599–611, Sep. 2008.[38] I. Diama and T. Ahmed, “A cross-layer interworking of DVB-T and

WLAN for Mobile IPTV service delivery,” IEEE Trans. Broadcasting,vol. 53, no. 1, Part 2, pp. 382–390, Mar. 2007.

Julien Maisonneuve holds a Ph.D. in computersystems from University of Paris. After workingfor INRIA, he joined Alcatel’s research laboratoriesand led successful projects in fault tolerance andreliability. He represented Alcatel in bodies suchas the IETF and the OMG where he long servedas a board and architecture board member. Morerecently he was a chairman in the architecture groupof the ITU-T IPTV Focus Group and TISPANliaison officer for DVB. He currently is Standard-ization Manager for applications and platforms in

Alcatel-Lucent, representing the company in different standardization bodiesand trade organizations.

Muriel Deschanel Prior to joining Microsoft, Murielworked for TandbergTV and NDS where she wasinvolved in various stages of product developmentfor Digital TV solutions ranging from design engi-neering to project management.

Overall, she has been working on Digital TV for15 years and on IPTV since 2002. Muriel Deschanelgraduated as an electronic engineer from the FrenchGrande Ecole “ENSERG” Grenoble’s National Insti-tute of Electronics and Radio-Electricity; she com-bined her engineering degree with an advanced re-

search degree in data processing.

Juergen Heiles studied electrical engineering at theUniversity of Applied Sciences Rhineland-Palati-nate, Koblenz, Germany and the University ofTennessee, Knoxville, United States.

After graduating he joint Siemens AG, Mu-nich in 1986 to work on satellite communication,SDH/Sonet, Optical Networks and Carrier Ethernet.During that time he was actively involved in thestandardization of SDH, OTN, GMPLS and CarrierEthernet at ETSI, ITU-T, IETF, Optical Internet-working Forum and Metro Ethernet Forum. Since

2005 he is involved in IPTV related standardization activities for Siemens andlater on Nokia Siemens Networks. Currently he leads the common Mobile TVand IPTV standardization activities of Nokia and Nokia Siemens Networks andactively participates in the DVB Project’s IPTV activities and the Open IPTVForum.

Mr. Heiles is representing Nokia Siemens Networks in the Steering Group ofthe Open IPTV Forum and leads the standards coordination ad-hoc group of theForum which is responsible for the interaction with standardization bodies andother fora. He was a co-chair of the ITU IPTV Focus Group QoS and Perfor-mance Aspects working group.

Wei Li is currently a Research Scientist with theCommunications Research Centre (CRC) Canada.He received the B.E. degree from Shandong Uni-versity (China) in 1985, the M.S. degree from theUniversity of Science and Technology of China(China) in 1988, and the Ph.D. degree from theInstutut National des Sciences Appliqués de Rennes(France) in 1996, all in electrical engineering. InOctober 2001, He joined the CRC where his majorfocus is broadband multimedia systems and digitaltelevision broadcasting.

He was with Motorola Canada Software Centre, Montreal, Canada, from Jan-uary 2000 to September 2001, where he conducted R&D in wireless commu-nication networks. From May 1998 to December 1999, he was with EmuliveImaging in Montreal, Canada. Prior to that, he had worked as a researcher atSherbrooke University, Canada from 1997 to 1998.

Dr. Li published more than 40 technical papers. He served as session chairsfor the IEEE International Symposium on Broadband Multimedia Systems andBroadcasting 2006 and 2007. He also served as reviewer for many renownedinternational journals and conferences in the area of broadcasting, multimediacommunication and multimedia processing. He was the IPTV tutorial lecturerin the 56th IEEE Broadcast Symposium and IBC2007, and the BTS IPTV rep-resentative at the ITU-T.

Hong Liu is a research engineer at CommunicationsResearch Centre Canada, Ottawa, Canada. He re-ceived the B.Sc. degree from Nanchang University,Nanchang, China in 1993 and the M.Sc. degree fromUniversity of Ottawa, Ottawa, Canada in 2001. From1993 to 1998, he worked as a lecturer in ElectricalEngineering department of East China Jiao TongUniversity, Nanchang, China. From 2000 to 2001, heworked in Nortel Networks at Ottawa as a softwareengineer and Manitoba Telecom Services Inc at Win-nipeg as a network planner. He has been involved

in the ITU-T IPTV standardization as a representative of the IEEE BTS since2006. His research interests include video processing and communication,network communication, error control coding and DTV system.

Randy Sharpe is a lead technologist with Al-catel-Lucent’s Fixed Access Division ChiefTechnology Officer (CTO) organization in Raleigh,North Carolina. He received a B.S. in electricalengineering from the University of Michigan in1978 and an M.S. in electrical engineering from theMassachusetts Institute of Technology in 1979. Priorto his tenure at Alcatel-Lucent, he developed digitalvideo transmission systems at Bell Labs, and wasa founder and system architect at BroadBand Tech-nologies. He joined Alcatel in 2001, specializing in

broadband access network topics. His current work focus is on IPTV aspectsof broadband access networks. He co-chairs the ATIS IPTV InteroperabilityForum Architecture Committee and is involved in other standards activities.

Yiyan Wu (S’85-M’90-SM’95-F’01) is a PrincipleResearch Scientist of Communications ResearchCentre Canada. His research interests includebroadband multimedia communications, digitalbroadcasting, and communication systems engi-neering. He is an IEEE Fellow, an adjunct professorof Carleton University, Ottawa, Canada. Dr. Wu is amember of the IEEE Broadcast Technology SocietyAdministrative Committee, and a member of theATSC Board of Directors, representing IEEE. He isthe Editor-in-Chief of the IEEE TRANSACTIONS ON

BROADCASTING. Dr. Wu has more than 200 publications and received manytechnical awards and patents for his contribution to the research and develop-ment of digital broadcasting and broadband multimedia communications.


an overview of iptv standards development-lvz

Documents