See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224440185

An overview of IPTV standards development

Article  in  IEEE Transactions on Broadcasting · July 2009

DOI: 10.1109/TBC.2009.2020451 · Source: IEEE Xplore

CITATIONS READS
78 2,154

7 authors, including:

Julien Maisonneuve Muriel Deschanel

Nokia Microsoft
13 PUBLICATIONS   103 CITATIONS    1 PUBLICATION   78 CITATIONS   

SEE PROFILE SEE PROFILE

Randy Sharpe Yiyan Wu

Alcatel Lucent Communications Research Centre Canada
9 PUBLICATIONS   218 CITATIONS    249 PUBLICATIONS   4,881 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Converge of Broadband Wireless and Broadcasting View project

ATSC 3.0 Standardization View project

All content following this page was uploaded by Yiyan Wu on 30 May 2014.

The user has requested enhancement of the downloaded file.

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

An Overview of IPTV Standards Development

Julien Maisonneuve, Muriel Deschanel, Juergen Heiles, Wei Li, Hong Liu, Randy Sharpe, and Yiyan Wu

Abstract—In the last few years, IPTV has emerged as one TABLE I
of the major distribution and access techniques for broadband COMPARISONS BETWEEN TERRESTRIAL BROADCASTING TV AND IPTV
multimedia services. It is one of the primary growth areas for the
telecommunications industry. However, existing IPTV systems
are generally based on proprietary implementations that do not
provide interoperability. Recently, many international standard
bodies have published, or are developing, a series of IPTV related
standards.. This paper is an overview of the most significant recent
and upcoming IPTV standards.
Index Terms—Broadcast, IPTV, multicast, networks.

I. INTRODUCTION A. An Opening Market

IPTV has been a significant driver for telecom investments for
ELEVISION distribution is one of the largest technology
T infrastructures deployed after telephone and electric
power networks. Digital technologies have completely trans-
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-
formed the telephone system creating a much more versatile
dard Definition (SD) video stream takes several Mbit/s, while
and dynamic telecommunications infrastructure and services.
High Definition (HD) reaches into the tens Mbit/s. This is far
The television distribution is now undergoing a similar digital
more than what is required for voice transmission (typically 32
revolution. Internet Protocol Television, or IPTV, is one of the
to 64 Kbit/s), or even to browse the internet.
promising techniques which takes a step further by merging
As a result, IPTV has been the best motivation for operators
telecommunications and digital television delivery services,
to deploy higher-speed DSL (no longer 256–784 Kbit/s but up to
unleashing new, more personal options to consumers, and
28 Mbit/s), and to consider deploying optical fiber beyond cen-
fulfilling the promises of a real home broadband multimedia
tral offices to curb cabinets (FTTC), buildings or even homes
experience.
(FTTH). These capacity upgrades also bring much higher In-
By early 2009, there should be more than 25 million IPTV
ternet communication speed and enable new services such as
users in the world. Now it is a good time to take a step back and
video telephony or file sharing, but it is not certain that in isola-
look at what has been achieved, what is missing and what the
tion they would have been a sufficient motivation for operators
future might be holding.
to invest in massive new infrastructures, or indeed for customers
The motivation for this IPTV special edition also resides in
to pay premium subscriptions. IPTV has been the catalyst for a
the completion of a number of standardization activities that
technology leap.
have taken several years to achieve. It is interesting to take a
Because the basic technology—IP—is the same for the In-
look at what standards have to offer, and how they might change
ternet connection and IPTV, it enables a more fluid mix of ser-
the landscape of IPTV in the years to come.
vices that can share the available bandwidth more consistently.

B. Differences Between TV, IPTV and WebTV

Manuscript received January 28, 2009; revised February 17, 2009. First pub-
lished May 05, 2009; current version published May 22, 2009. The advantages and challenges of IPTV reside in the differ-
J. Maisonneuve is with the Alcatel-Lucent, 75008 Paris, France (e-mail: ences between existing terrestrial broadcasting TV, cable TV
Julien.Maisonneuve@Alcatel-Lucent.com).
M. Deschanel is with the Microsoft Corporation, Paris, France (e-mail: and satellite TV [25]. IPTV differentiates from traditional ter-
MurielD@Microsoft.com). restrial broadcasting TV in many ways. Table I lists some major
J. Heiles is with the Nokia Siemens Networks, 80241 Munich, Germany
(e-mail: juergen.heiles@nsn.com).
differences between these two services.
W. Li, H. Liu, and Y. Wu are with the Communications Research Centre Comparing with existing cable TV and satellite TV, IPTV
Canada, Ottawa, ON K2H 8S2 Canada (e-mail: wli@crc.ca; hliu@crc.ca; distinguishes itself with full interactivity, high personalization
ywu@crc.ca).
R. Sharpe is with the Alcatel-Lucent, Plano, TX 75075 USA (e-mail: Randy. and flexibility as shown in Table II.
Sharpe@Alcatel-Lucent.com). IPTV is not TV that is broadcasted over the Internet. There
Color versions of one or more of the figures in this paper are available online
at http://ieeexplore.ieee.org. are actually wide spread confusions between Internet TV and
Digital Object Identifier 10.1109/TBC.2009.2020451 IPTV. Table III illustrates a comparison between the two.

0018-9316/$25.00 © 2009 IEEE

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
316 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

TABLE II
COMPARISONS BETWEEN CABLE TV, SATELLITE TV AND IPTV

Fig. 1. Structure of IPTV systems.

Many other organizations have worked on IPTV specifica-

TABLE III
COMPARISONS BETWEEN INTERNET TV AND IPTV 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
C. IPTV and Standards to access it: this is the role of the service guide.
Interestingly, because IPTV is deployed within private IP The following diagram (Fig. 1) gives a very high level archi-
networks and it does not consume rare and shared resources tecture of an IPTV system.
(such as radio spectrum), there has been no immediate need to While the interface to the access network is generally
standardize systems and architectures. Indeed, one operator can common, there are significant variations on how the other
choose to deploy several IPTV systems on the same network components (e.g. control subsystem, Service Guide, etc.) are
without major ill effects (if you exclude overall cost, the need structured and behave. In a setting where even subtle variations
for a dedicated set top box and distribution network bandwidth on protocols or data formats can be a barrier to interoperability,
occupied by several systems operating in parallel). these differences created several families of systems, and
This low level of constraint and the lack of a readily available corresponding standards have been developed.
and comprehensive IPTV standard lead to a flurry of proprietary
implementations that now constitute the base of all IPTV sys- II. IPTV STANDARDIZATION ACTIVITIES
tems in operation over the world. However, those systems are
A. IPTV Standard Development at DVB Project
still based on a number of key standards that had already reached
prevalence at design time. Traditionally, Digital Video Broadcasting (DVB) services are
Digital Video is not a new standardization subject, it has been delivered over broadcasting networks, i.e. a one-to-many uni-di-
rectional architecture. The advent of high-speed bi-directional
seen as a key development sector for more than 20 years. In
consumer broadband networks means that there is an increasing
that space, some groups and organizations have gained almost
demand to offer DVB services over IP (Internet Protocol) net-
universal recognition. The first one is probably MPEG (Motion works. The delivery of TV services using bi-directional IP over
Picture Expert Group) for its video coding (MPEG-2, MPEG-4) a broadband network presents a particular set of challenges, es-
and transmission protocols (MPEG TS). pecially when integrated with a range of other IP services.
Because of the unavoidable role of IP, the second one would DVB projects’ task, in response to calls from the industry, is
certainly be IETF (Internet Engineering Task Force) for its de- to help define and develop appropriate standards for the delivery
livery and control protocols (RTP/RTCP, RTSP, SDP, SIP, etc.). of DVB services over such networks, and to provide a means of

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 317

integrating them with other broadband services, whilst main- • The use of command and control application-level protocol
taining maximum interoperability with existing DVB broadcast RTSP to control CoD services and optionally to join mul-
standards. ticast services.
DVB was one of the pioneer organizations to start standard- • The assignment of an IP Address to a Home Network End
ization work on the delivery of TV services over IP networks. Device (HNED) to get onto the network. The specification
The DVB TM-IPI (Technical Module-Internet Protocol Infra- is based on DHCP and is restricted to the scenarios where
structure) working group was set up back in 2000. Eight years an HNED has a single interface onto the home network
later, DVB released the fourth revision of the “Transport of and there is a single Delivery Network Gateway (DNG)
MPEG 2 TS Based DVB Services over IP Based Networks”; per home network segment.
specification, also referred to as the DVB-IPTV 1.4 handbook, • The File Upload System Stub (FUSS) which is mandatory
and soon to be published by ETSI as TS102 034 v1.4.1 [1]. and allows the system software of an HNED to be updated
DVB is led by commercial requirements which have evolved on a power-cycle or reboot. The sending of the system soft-
over time as services have been introduced and deployed. This ware will be handled by the mechanisms in the optional
has led to continuing updates of DVB-IPTV specifications. Remote Management and Firmware Update System for
The goal of the DVB-IPTV handbook is to specify technolo- DVB-IPTV Services (RMS-FUS) specification, ETSI TS
gies on the interface between an IP network and a Home Net- 102 824 [2].
work End Device (HNED), for example a Set-Top Box, en- • Discovery of Broadband Content Guides (including third
abling deployment of TV services over IP-based networks and party). The Broadband Content Guide is a content guide
mass production of IPTV receivers by Consumer Electronics that is delivered over an always-on bi-directional IP net-
manufacturers. The technologies specified, implemented in a work and is provided as a separate specification, ETSI TS
DVB-IPTV HNED, should allow a consumer to buy such a re- 102 539 [3].
ceiver in off-the-shelf, connect it to a broadband network, and • An optional protocol for Application Layer FEC
be able to choose and consume DVB services available over the (AL-FEC) protection of streaming media for DVB-IPTV
IP network. The specification covers several types of IPTV ser- services carried over RTP transport. This AL-FEC pro-
vices, such as Live Media Broadcast (i.e. TV or radio services), tocol is a layered protocol with a base layer and zero or
Content on Demand, and content download services. more optional enhancement layer(s). The base layer is a
The following key functionalities are specified by the DVB- simple packet-based interleaved parity code based on a
IPTV handbook: subset of SMPTE 2022-1[4]. The base layer shall be used
• The delivery of DVB MPEG-2 TS based services over wherever AL-FEC is used. The enhancement layer is a
bi-directional IP networks for Live Media Broadcast ser- Raptor code, as defined in ETSI TS 126 346 [5] and ETSI
vices (i.e. TV or radio services) and Content on Demand TS 102 472 [6] and may optionally be used to provide
(CoD) services. The transport part of the specification further packet loss protection.
covers the encapsulation of MPEG-2 TS services for • An optional retransmission mechanism (RET) to provide
streaming delivery over IP and the protocols to be used to for protection against packet loss of DVB-IPTV services
access such services. Quality of Service is covered, based carried over RTP transport. It specifies the mechanism to
on Differentiated Services (DiffServ). provide immediate feedback (FB) towards the network
• The delivery of Content Download Services (CDSs). using RTCP and how to retransmit the missing packets.
CDSs provide the download of content items to a local Packet loss repair can be achieved using the optional AL-FEC
storage of the HNED via a broadband IP connection. solution, the optional retransmission solution or a combination
CDSs can be used to provide IPTV services in areas where of both solutions.
a broadband connection suitable for streaming services is The DVB-IPTV handbook specifies technologies on the in-
not available or prone to errors, for simultaneous delivery terface to the HNED and only the minimum necessary for in-
of multiple content items to HNEDs or for reduced cost teroperability. The implementation of the HNED is left to the
offers as the bandwidth consumption may be limited CE (Consumer Electronic) manufacturers. The same applies for
compared to streaming services. Two types of services are the implementation of networking and service provider systems,
supported: push download services where the distribution as long as their implementations meet the requirements on the
decision is taken by the service provider (without explicit standardized HNED interface.
request from the user) and pull download services where Fig. 2 defines a reference model of the home network and
the download is requested by the user. some key interfaces. The key interface for standardization in the
• The Service Discovery and Selection (SD&S) mechanism DVB-IPTV handbook is the “IP Infrastructure-1” (IPI-1) inter-
for DVB based A/V services over bi-directional IP net- face. The advanced home network functionality is not covered
works. The service discovery information, its data format in the current DVB-IPTV handbook and will be defined in a sep-
and the protocols to use for carriage of this information arate specification.
are defined. Both push and pull models of delivery are Fig. 3 is a logical diagram of the high-level protocols on the
supported. Binarization encoding of SD&S information is IPI-1 interface, specified in the DVB-IPTV 1.4 handbook for en-
specified and can optionally be used if required. Support abling DVB services over IP-based networks and the associated
for advanced codecs, logical channel numbering and sig- delivery and network support services. The organization of this
naling regional DVB-IPTV services is provided. protocol stack is based on the hierarchical structure frequently

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
318 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

Fig. 2. Home network reference model.

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
Fig. 3. Diagram of the protocol stack for DVB-IPTV services. TV-Anytime metadata support.
• Content Download profile to build services of content
available for download either in push or pull modes.
applied in equipment design, i.e. service offering and applica- The structure used to define a profile is presented in more
tions, middleware and functions, IP protocols and transport, and details in Fig. 4.
PHY/MAC/link layers. This follows the ISO/OSI layering con- DVB has also defined IPTV profiles for its interactive mid-
vention in general terms. dleware specifications, DVB-MHP and GEM.
The top layer of this stack signifies the service offering in- IPTV continues to be a very active and evolving activity in
tended by the Service Provider. This consists of programs, infor- DVB with many stakeholders involved both in the technical and
mation about programs, multicast- and/or unicast IP addresses; commercial groups. Future releases of the specification will see
i.e. the essential items needed to enable a DVB service over an many new and exciting features including a solution for fast
IP network. channel change which gives great improvement on zapping time
The IP protocol and transport layer attempts to identify which between TV services. Many research works have been done in
protocols and transports are required and map the usage of those this area [32]–[35].
protocols and transports to the functions of the layers above. However, the distribution of audiovisual content is evolving
Operators require the flexibility to deploy IPTV services quickly and DVB needs to prepare the next steps. Work has now
according to their market requirements and business models, been organized around two tracks. Track 1 covers delivery of

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 319

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

DVB services over managed IP networks and Track 2 covers QoS, user and service profiles, authentication (with variants),
delivery over the Open Internet. charging, etc.
The technical work on DVB-IPTV so far has been part of NGN R1 did not address IPTV, but it was quickly recognized
Track 1 which will continue to evolve and will include in the that IPTV became a key application for NGN networks. IPTV
future more flexible stream composition to enhance IPTV ser- had higher bandwidth requirements than most existing applica-
vices, more straightforward interfaces to n-Play solutions (e.g. tions (such as voice) and potential for rapid mass-market de-
telecommunication, mobile, etc.), and also support for hybrid ployment (more than videoconferencing). As a result, a number
DVB broadcast and DVB-IPTV services. The recently started of participants started to develop requirements for IPTV in late
Track 2 will cover the distribution of commercial content over 2005 [8]. Two philosophies were developed on how those re-
the Open Internet. DVB will endeavor to continue collaboration quirements should be fulfilled: one was to adapt existing IETF
with other standards development organizations through formal protocols to an NGN environment, the other to reuse the IMS
liaisons as it is recognized that co-operation is essential to the machinery for providing IPTV services. Because of the way
success of DVB solutions for IPTV in particular in the area of those two specifications were developed, they do not share many
n-Play. components and can be described separately.
Dedicated IPTV: This IPTV variant [9] was designed as an
B. ETSI TISPAN adaptation for NGN of the principles used in many existing
IPTV systems and mainly DVB-IP (as shown in Fig. 5). It is
ETSI TISPAN (European Telecommunications Standards based on proven IETF protocols (HTTP, RTSP, IGMP) used in
Institute Telecommunications and Internet converged Services a straightforward way. Authentication needs to be supported
and Protocols for Advanced Networking) was chartered in within the dedicated IPTV subsystem, but it otherwise makes
2004 to standardize Fixed NGN, working alongside 3GPP use of the NGN elements used to store user profiles (UPSF) and
which concentrated on mobile NGN. TISPAN NGN R1 was control network characteristics and QoS (NASS and RACS). In
completed in 2005 and focused on networking and VOIP addition, it can make use of NGN charging. It supports 3 types of
aspects. After more than two years of hard work, TISPAN has IPTV services with trick play (pause, rewind, forward): Broad-
published NGN R2 in June 2008. There are two variants of cast, Content on demand, and NPVR (network personal video
IPTV in TISPAN R2 (and also in R3), differing in how they use recorder).
the IMS (IP Multimedia Subsystem, originated in the mobile The interaction between the User Equipment and the network
world of 3GPP) components. conforms to the DVB-IP 1.3 specification ([1], as outlined in
TISPAN is open to all ETSI members and associate mem- [12]) and uses HTTP and RTSP to control sessions. IGMP is
bers. Members usually are European companies, while associate used to access multicast channels from the terminal. Bandwidth
members can come from other countries (typically from Asia or reservation is performed on the RACS through the Gq’ interface,
America). A number of non-European companies participate as just as other TISPAN applications.
full members through European subsidiaries. TISPAN member- IMS-Based IPTV: This IPTV variant [14] was designed to
ship is mainly composed of telecom vendors and operators. take advantage of the benefits of the 3GPP IMS, originally de-
TISPAN and IPTV: In TISPAN, IPTV is not the primary focus veloped to support IP multimedia communications in mobile
of activities. To some extent IPTV can be seen as an applica- networks (as shown in Fig. 6). It relies on the use of the core IMS
tion (a Service, among others such as voice services) that is pro- and manages most interactions through the SIP (session initia-
vided over a network and benefits from an existing ecosystem. tion protocol [13]) protocol. As a result, it benefits from the pop-
IPTV is thus reusing the properties of TISPAN NGN, such as ular IMS features: implicit authentication, roaming across IMS

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
320 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

Fig. 5. TISPAN dedicated IPTV architecture.

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
Fig. 6. TISPAN IMS-based IPTV architecture. 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
networks, and natural interfacing to NGN components (UPSF, specifications will support new features described in [9]: IPTV
NASS, RACS, charging). It supports 3 types of IPTV services presence, access to third party content, P2P distribution, inter-
with trick play (pause, rewind, forward): Broadcast, Content on face with a Content Distribution Network, Forward Error Cor-
demand, and NPVR (network personal video recorder). rection, NPVR command from another terminal and more fea-
Handling of Content on Demand session is very close to the tures that are added progressively. The R3 dedicated IPTV spec-
natural IMS model where session establishment and media con- ification is [11] and the IMS-based IPTV specification is [15].
trol are joined: SIP/SDP interaction yields a bandwidth-allo- Assessment: After a few years of work, ETSI TISPAN
cated session to the Media Delivery Function. Media control comes up with two reasonably complete IPTV specifications:
(pause, rewind, forward, etc.) is then performed using a direct one based on IMS and the other based on DVB-IP 1.3. They
RTSP connection to the Media Server. innovate in their degree of integration in the telecom network,

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 321

and borrow very significant elements from other existing spec- • Metadata and Transaction Delivery
ifications (mainly DVB-IP). The Architecture Committee develops IPTV architecture re-
There are only a limited number of common components be- quirements, specifications, protocols, and other documents re-
tween these two specifications, less than what was achievable quired to enable deployment of a standardized, interoperable,
when looking at the diagrams of ATIS IIF and ITU-T FG IPTV. and access-agnostic IPTV service.
The specifications’ level of maturity has prompted other The IPTV Security Solutions Committee develops security
organizations (such as MSF (MultiService Forum)) to reuse standards with emphasis on a security requirements framework
the specifications for interoperability testing. There is a near and an integrated toolkit of security functions that can be uti-
feature parity between the two, and their success will thus be lized for an interoperable solution for enabling IPTV services.
tested in the market, according to their respective merits and The Quality of Service Metrics Committee develops stan-
performances. dards that define metrics, models, and approaches for measure-
ment and reporting of quality of service (QoS) and quality of
C. ATIS IIF experience (QoE) for IPTV services.
The Alliance for Telecommunications Industry Solutions The Testing and Interoperability Committee develops the
(ATIS) is a leading standards development and technical necessary test scripting and test planning for the interoperability
planning organization committed to rapidly developing and of ATIS IIF standards and addresses IPTV interoperability is-
promoting technical and operations standards for the com- sues, providing recommended courses of action for mitigation
munications and related information technologies industry of the identified issues.
worldwide using a pragmatic, flexible and open approach. The Metadata and Transaction Delivery Committee develops
Participants from more than 300 communications companies standards that define metadata elements, the representation of
are active in ATIS’ 22 industry committees, Incubator Solutions metadata elements, and the content of application-level trans-
Programs, and other activities (http://www.atis.org). actions where the MTD Committee is the primary developer of
The ATIS Board of Directors approved the formation of the metadata standards in support of all ATIS IIF Committees.
IPTV Interoperability Forum (IIF) in July 2005. More than Accomplishments: Since its establishment, the ATIS IIF has
50 ATIS member companies are actively engaged in ATIS’ produced a number of key requirements and framework doc-
IPTV standardization efforts through the ATIS IIF, including uments to serve as the foundation for further development of
Verizon, Qwest, AT&T, BT, Alcatel-Lucent, Nokia Siemens IPTV specifications and standards. The following summarizes
Networks, Nortel, Cisco, Motorola, Intel, Microsoft and Sun key activities and deliverables to date:
Microsystems, among others. The IPTV IIF is an open forum • IPTV DRM Interoperability Requirements (ATIS-
and all companies meeting the ATIS membership requirements 0800001.v002)—This ATIS standard defines the require-
are eligible to become IIF participating companies. ments for the interoperability of systems and components
IIF Mission/Scope: The IIF enables the interoperability, in- in the IPTV DRM/security environment.
terconnection, and implementation of IPTV systems/services by • IPTV Architecture Requirements (ATIS-0800002)—The
developing ATIS standards and facilitating related technical ac- ATIS IIF delivered the industry’s first set of IPTV archi-
tivities. This forum place an emphasis on North American and tecture requirements that define, in broad terms, the scope
ATIS Member Company needs in coordination with other re- of IPTV services and the high level requirements that will
gional and international standards development organizations. guide the development of architecture specifications over
The scope of the work in the IIF includes the following areas: time. This architecture document focuses on services that
1) Coordinate standards activities that relate to IPTV tech- may comprise IPTV; the functions necessary for content
nologies. This includes providing a liaison function providers to deliver content to service providers; the func-
between the various Standard Development Organizations tions required by service providers and network providers
(SDOs), forums, and other ATIS committees/forums that to offer IPTV; and the home networking functions neces-
are each working on important components for multi- sary for the consumer to receive IPTV services.
media, but may not have visibility to other aspects of the • IPTV Architecture Roadmap (ATIS-0800003)—The IPTV
application. Architecture Roadmap defines the phases in which IPTV
2) Develop self-consistent ATIS standards, such as interoper- architecture standards will be developed. The document
ability requirements, specifications, guidelines, and tech- calls for the release of specifications in three phases. The
nical reports. first phase includes specifications for network/service at-
3) Provide a venue for interoperability activities. tachment; service discovery; basic navigation through ser-
4) Provide a venue for the development of standards and vices; and regulatory compliance, including Emergency
other documents for IPTV systems/services deployed over Alert Services (EAS), Closed Caption and Parental Advi-
a managed IP and/or NGN infrastructure. sory. A second phase of specifications will address video
IIF Committee Structure: The IIF is composed of five on-demand (VOD) and pay-per-view (PPV) transaction-
committees: based services. Phase three will address interactive TV,
• Architecture multiplayer games, network PVR, and in-home peer-to-
• IPTV Security Solutions peer interaction.
• Quality of Service Metrics • Framework for QoS Metrics and Measurements Sup-
• IIF Testing and Interoperability porting IPTV Services (ATIS-0800004)—The framework

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
322 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

serves as a basis for definitions of Quality of Service • QoS Metrics and Measurements for Public Services (ATIS-
(QoS)/Quality of Experience (QoE) related to different 0800011)—This document defines a base set of Quality of
segments of the network, different service instances or Service metrics for regulatory services, including Emer-
invocations, network architectures/technologies utilized, gency Alert Systems, Closed Captioning and Content Ad-
and modes of service. The document offers an overview visories, and V-Chip Technology.
and concepts related to the following: measurement model • IPTV Emergency Alert System (EAS) Metadata Re-
and measurement points; quality layers, protocol stack quirements (ATIS-0800012)—Building upon the system
view, and use cases; types, characteristics, and definitions requirements given in ATIS-0800010, this document de-
of metrics; a QoS/QoE model; measurement practices fines an XML schema used for delivery of emergency alert
and methodologies; time and frequency synchronization signaling and information to the IPTV service provider’s
requirements for ensuring QoS/QoE, and enabling metrics EAS Ingestion System (EIS), and for delivery of alert
measurement. information and signaling to the IPTV terminal function
• IPTV Packet Loss Issue Report (ATIS-0800005)—The re- on the consumer premises. In addition, the document
port reviews factors that may cause packet loss in IPTV specifies the methods used to authenticate EAS data and
transmissions and addresses solutions to mitigate packet audio files.
loss. • Secure Download Interoperability Specification- (ATIS
• IIF Default Scrambling Algorithm (ATIS-0800006)—This -0800014)—This document specifies the IPTV Security
document specifies a default scrambling/descrambling al- Solution/Authentication (ISS/A), which is used to authen-
gorithm for MPEG-2 Transport Stream and scrambling al- ticate downloads and messages to IPTV receiving devices.
gorithm signaling. Use of the specification provides net- • Network Attachment and Initialization of Devices and
work operators with a maximum choice of IPTV receiving Client Discovery of IPTV Services (ATIS-0800017)—This
device platforms. specification seeks to provide an overall end-to-end, high
• IPTV High Level Architecture (ATIS-0800007)—This level description of the process for attaching a device to
document provides a high level architectural framework for the network and service provider and readying the device
end-to-end systems’ implementation and the supporting for service provision.
network design. This serves as reference architecture for • IPTV Linear/Broadcast Service (ATIS-0800018)—This
the IPTV functional specifications being defined in sepa- specification defines the basic linear TV service oper-
rate IIF specification. The IIF IPTV functional architecture ation after the initialization, configuration, and service
is based on an NGN framework allowing either core-IMS provider discovery documented in ATIS-0800017 and
based service control or a dedicated IPTV service con- ATIS-0800009. This specification describes a basic ac-
trol, with an emphasis on commonality of functions and quisition mechanism for linear TV content channels
interfaces. with options for various network resource allocation
mechanisms.
• QoS Metrics for Linear Broadcast IPTV (ATIS-
• IPTV EPG Metadata Specification (ATIS-0800020)—This
0800008)—This document provides a consensus view
document specifies the logical data model and delivery
of the meanings of QoS metrics for linear broadcast IPTV,
mechanisms for IPTV Electronic Program Guide (EPG) in-
including video, audio, and the synchronization between
formation to be delivered from EPG servers in the service
audio and video. It also identifies measurement points, ap-
provider domain to EPG clients in the consumer domain.
plicable measurements and measurement methodologies.
The logical data model is specified in the form of an XML
• Remote Management of Devices in the Consumer Do-
schema. The delivery specifications include fragmentation,
main for IPTV Service (ATIS-0800009)—This document encoding, encapsulation, and transport of the EPG infor-
addresses the remote management of devices in the con- mation, with support for both multicast push and unicast
sumer domain, focusing initially on the Delivery Network pull transport.
Gateway (DNG) and IPTV Terminal Function (ITF) de- • EPSNR Trial Use (ATIS-0800021)—This document de-
vices. Additionally it addresses device attachment to the scribes a technique to generate an estimate of video quality
transport network; software image download; provisioning by estimating Peak Signal-to-Noise Ratio (PSNR). The Es-
of parameters; status monitoring; remote diagnostics; fault timated PSNR (EPSNR) algorithm is experimental in na-
recovery; and security management. ture, and requires additional testing and validation; there-
• Emergency Alert Provisioning Specifications (ATIS- fore, it is being published as a Trial-Use Standard in order
0800010)—The Emergency Alert System (EAS) for IPTV to facilitate evaluation by the industry.
addressed in this document broadens the delivery of EAS • Consumer Domain Configuration Metadata Requirements
messages from a few linear channels to the complete IPTV Specification—This document identifies requirements for
experience, spanning the full range of activities from metadata associated with configuration of consumer do-
live and recorded TV viewing, through games, internet main devices - specifically the Delivery Network Gateway
streaming and sourced content, and even including IPTV (DNG) and the IPTV Terminal Function (ITF) - during net-
client menu activities. The goal is to deliver important work attachment, initialization, configuration and remote
emergency alerts to any person using the IPTV service, management. Initialization and configuration of the ITF
independent of activity. and DNG in a consumer domain may require metadata ex-

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 323

change between these consumer domain devices and ser- platforms with respect to secure transmission and storage
vice provider and/or network provider systems. of materials.
• IPTV Metadata Consumer Requirements Specification— • Distribution of Content in the Subscriber’s Authorized Ser-
This document will address the need to establish basic con- vice Domain—This document will identify requirements
sumer (subscriber and user) profile and preferences meta- for interoperability of the system and components neces-
data requirements for an IPTV Consumer Metadata Spec- sary to share protected content in the IPTV/DRM security
ification/Standard. environment.
• Application Level Interfaces (API) Interoperability Spec- The ATIS IIF documents are available in the ATIS document
ification—This specification will address the need for in- Center at: https://www.atis.org/docstore/default.aspx.
teroperable DRM Application Programming Interfaces.
• Media Protocols Specification (0800013)—This specifica- D. ITU-T IPTV Focus Group and GSI
tion will define the media protocols, including reliability The International Telecommunications Union—Telecommu-
protocols, for IPTV service. Media protocols include the nication Standardization Sector (ITU-T, formerly CCITT) is a
protocols used for actual audio and video media delivery Geneva-based United Nations (UN) organization responsible
over IP. Definition of the protocol stack from the IP layer for fostering cooperative standards for telecommunications
upwards is required and should include consideration of equipment and systems. The ITU-T mission is to ensure the
reliability techniques applied at the IP layer and above, ex- efficient and timely production of standards (referred to as
amples of which include quality of service marking, for- “Recommendations”) covering all fields of telecommunications
ward error correction at the application or transport layer, on a worldwide basis, as well as defining tariff and accounting
and retransmission. principles for international telecommunication services. Given
• IPTV Multicast Network Service Specification—This that IPTV is becoming an increasingly important service in the
specification is designed to describe a simple IP multicast market, and that more and more manufacturers and operators
service that the network provider can offer for use as a are facing challenges from technical as well as regulatory
basis for a linear/broadcast TV service. The intent is to issues, ITU-T has received proposals to strengthen its work on
focus on the service requirements from the perspective IPTV standardization. There is an urgent need to increase the
of the IPTV service provider rather than detail specific international effort on various issues, in particular, interoper-
implementation mechanisms within the network operator ability and gap analysis of IPTV standards. Since late 2005,
domain. ITU-T Study Group Chairmen have studied possible measures
• IPTV Digital Rights Management (DRM) Requirements to take care of the IPTV study within ITU-T, including coor-
Update—This document will address the maintenance of dination with other Standardization Developing Organizations
the DRM requirements document as IIF members, IPTV/ (SDOs). During the TSB director’s consultation meeting on
DRM stakeholders, and/or IPTV liaison partners introduce IPTV standardization [22], the consensus had been reached to
changes based on working with the IPTV DRM specifica- support the TSB Director to create, according to ITU-T Rec-
tion. The purpose of the document is to incorporate con- ommendation A.7 [23], a focus group, the IPTV Focus Group
sensus issues and introduce specific deliverables to supple- (FG IPTV). Focus Group is a more efficient way to allow ITU
ment and/or revise the DRM requirements document. to take the lead in coordinating and developing global standards
• Categorized Listing of Fault Modes for IPTV—This doc- to enable rapid progress and to avoid market fragmentation.
ument will define a standard set of fault modes that cause The mission of FG IPTV was agreed on this TSB director’s
the improper functioning of an IPTV component or signal. meeting [22] as: “The mission of IPTV FG is to coordinate and
The type of fault is a vital input to service assurance, test, promote the development of global IPTV standards taking into
fault and performance operations and systems. account the existing work of the ITU study groups as well as
• Certificate Trust Management Hierarchy—This specifica- Standards Developing Organizations, Fora and Consortia.”
tion will provide the basis of trust for Public Key Infra- Different from Study Groups (SGs), the FG IPTV opens to
structure (PKI) operations by creating a PKI hierarchy that ITU member states, sector members and associates, and it also
satisfies trust requirements of security solutions, identi- opens to any individual from a country which is a member of
fying trust relationships affected by PKI hierarchies, and ITU who wishes to contribute to the work (this includes indi-
establishing requirements for the generation, distribution, viduals who are also members of international, regional and
and revocation of IIF PKI certificates. national organizations). This provides ITU-T the way of re-
• Standard Public Key Infrastructure (PKI) Certificate sponding to market needs very quickly and of doing the job in
Format—This document will standardize the delivery, the most efficient, transparent and professional manner.
distribution, and validation of encrypted keys in a trusted As a start point, the following goals of FG IPTV were
certificate format. The encrypted keys within a key cer- developed:
tificate are a security component consisting of digital • Definition of IPTV
signatures used to authenticate data sources and content. • Review and gap analysis of existing standards and ongoing
• Security Robustness Rules—This specification aims to fa- works
cilitate interoperability and encourage product innovation • Coordination of existing standardization activities
while maintaining standardized procedures, interfaces, and • Harmonization of the development of new standards

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
324 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

Fig. 7. FG IPTV and IPTV GSI compositions.

• Encourage interoperability with existing systems where Quality of Experience (QoE) Dimensions: QoE is defined in
possible [30] as the overall acceptability of an application or service, as
From July 2006 until December 2007, a total of seven meet- perceived subjectively by the end-user. Quality of Service (QoS)
ings were held. As illustrated in Fig. 7, the FG IPTV separated is defined in [31] as the collective effect of performance which
its tasks into six areas corresponding to six Working Groups determines the degree of satisfaction of a user of the service. In
(WGs). Significant progresses have been made in these six telecommunications, QoS is usually a measure of performance
areas. Each area has produced enriched documents covering of the network itself.
most of the IPTV worldwide development efforts. Fig. 9 shows factors contributing to QoE.
The FG IPTV ended in December 2007 and its documents In upcoming IPTV-GSI events, regular ITU-T working
were transferred to the appropriate study groups via Study methods and procedures will apply by means of the work
Group 13. The ongoing work has been carried out under the carried out by the experts of the relevant Study Groups where
umbrella of a Global Standards Initiative (IPTV-GSI) via global standards will be developed.
related study groups (SGs). Fig. 7 shows the IPTV-GSI related Up to now, a total of five IPTV-GSI events have been held.
SGs. The IPTV-GSI focuses on speedy preparation of ITU-T For example, SG13 (next generation networks) further details
Recommendations (standards) based on the output of the Focus the IPTV architectural design issues including requirements,
Group as well as the detailed protocols necessary. network control, service management, traffic classification, etc.
Some important achievements towards IPTV standardization SG16 (multimedia terminals, systems and applications) contin-
are listed below: uously completes the IPTV terminal device basic models, ser-
Definition of IPTV: The consensus was reached during the vice discovery and consumption mechanisms, multicast func-
first FG IPTV meeting on the IPTV definition [24]: “IPTV is tion support, broadcast-centric IPTV terminal middleware, etc.
defined as multimedia services such as television/video /audio/ SG12 is working towards the completion of new recommenda-
text/graphics/data delivered over IP based networks managed to tions on IPTV QoE, performance monitoring, etc. The IPTV
provide the required level of QoS/QoE, security, interactivity GSI events see many new draft recommendations on different
and reliability.” aspects (Questions) in various Study Groups.
IPTV Domains: Four IPTV domains are identified including
content provider, service provider, network provider and end E. Open IPTV Forum
user. The Open IPTV Forum is a pan-industry initiative with the
IPTV Architectural Approaches: Three IPTV architecture objective to specify a common and open end-to-end solution for
approaches are identified that enable service providers to de- supplying a variety of IPTV and internet multimedia services
liver IPTV services. These include: Non-NGN IPTV functional to retail based consumer equipment in the home. The Forum,
architecture (Non-NGN IPTV), NGN-based non-IMS IPTV which is open to participation from the communications,
functional architecture (NGN-Non-IMS IPTV) [26], [27], NGN entertainment and other relevant industries, will focus on the
IMS-based IPTV functional architecture (NGN-IMS-IPTV) development of open standards that will help streamline and
[28]. accelerate deployments of IPTV technologies, and maximize
IPTV Functional Architecture: Fig. 8 provides an overview the benefits of IPTV for consumers, network operators, content
of the IPTV functional architecture. Functions and functional providers, service providers, consumer electronics manufac-
blocks described in this clause are common to all architectural turers and home and network infrastructure providers.
approaches. Various IPTV architectural options and more de- The Forum was founded in January 2007 by Ericsson, France
tailed architectural descriptions can be found in [29]. Telecom, Nokia Siemens Networks, Panasonic, Philips, Sam-

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 325

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 Fig. 10. Open IPTV forum scope.
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 The Forum’s directions are set by the Steering Group, sup-
Open Internet as shown in Fig. 10 was missing. Such a specifi- ported by four ad-hoc groups for working procedures, admin-
cation will ensure the interoperability between consumer equip- istration and budget, certification and logo program and stan-
dards coordination as shown in Fig. 11. Five working groups
ment and the service offerings, which will make it possible for
are assigned to drive the Forum’s specification, interoperability,
the end users to easily access their choice of content and services
testing, and marketing activities. Requirements specified by the
offered from multiple service providers. The Forum’s plan is to
Requirements Working Group are the starting point of any spec-
extend the specification work with a certification and logo pro-
ification work. These requirements are defined based on user
gram in order to foster interoperability. In the mean time the cases contributed by the Forum’s members. Based on the re-
Forum membership has increased to over 60 members covering quirements a functional architecture is defined by the Architec-
most parts of the IPTV ecosystem. ture Working Group in order to provide the directions for the
An important objective of the Forum is to base its specifica- technical specifications defined by the Solution Working Group.
tions on existing technologies and open standards as much as The Solution Working Group has several Task Forces to cover
possible. The intention of the Forum is not to create yet another specific areas of the overall solutions like protocols, codecs,
standardization initiative, but to define a complete delivery so- metadata, content protection and application execution environ-
lution by profiling existing standards and filling the gaps where ments. Based on the technical specification, the Interoperability
necessary. The Forum will work closely with existing standard- & Test Working Group will define test specifications as input
ization efforts and address those areas which need enhance- for the planned certification & logo program. The objective of
ments by actively contributing the work of the Forum. Currently the Marketing Working Group is to communicate and promote
the Forum is in the process to setup liaison activities with rele- the Forum’s activities and specifications in order to obtain wider
vant standardization organizations and fora. recognition and support in the industry and from end-users.

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
326 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

Fig. 11. Open IPTV forum organization.

The Forum has just published its technical specification work

for Release 1. Release 1 focuses on basic IPTV services like
scheduled content service, content on demand and personal Fig. 12. Open IPTV forum consumer domain architecture.
video recording. In addition the integration with communi-
cation services like chatting and messaging and interactive
applications are in the focus. For a detailed description of metadata, content delivery and A/V codecs will be based on
the Release 1 services and functions see [16]. The Release 1 the DVB IPTV specifications, while the declarative application
Requirements [17] and Architecture [18] are already finalized environment will be based on CE-HTML as defined by CEA
and publicly available. The technical specifications are ex- (Consumer Electronics Association). Optionally storage func-
pected to be finalized in mid of 2008. In parallel the work on tionality for local PVR (Personal Video Recorder) and con-
requirements for Release 2 has already started. It will extend tent download services and DLNA (Digital Living Network Al-
the Open IPTV Forum specifications with enhanced interactive liance) Digital Media Player (DMP) and Digital Media Server
functions, tighter integration with communication services, (DMS) functionality can be included. The latter two allow ac-
new advertising features and the support of converged services, cess to content from other DLNA devices (DMP functionality)
which can be accessed on various end devices connected via and make Open IPTV Forum services available to other DLNA
fixed and mobile access networks. This will allow the end user devices (DMS functionality) on the residential network.
to consume and control IPTV services not only on the TV, but For managed network services, the IP Multimedia Subsystem
also on the PC, mobile phone and PDA at home or on the move. (IMS) Gateway (IG) is introduced. The managed network is
As an unique approach, the Forum covers IPTV and multi- based on IMS as defined by 3GPP and ETSI TISPAN. IMS
media services available both via a Managed Network and the provides authentication, session management, resource and ad-
Open Internet. A common User-Network Interface (UNI) will mission control, billing and user management functions. The
ensure that the end user has access to a variety of services of- IG contains the IMS client for authentication and session man-
fered by multiple service providers both over Managed Net- agement, and optionally the Universal Integrated Circuit Card
works and the Open Internet. This will make the overall ser- (UICC) for IMS Services Identity Module (ISIM) based authen-
vice offering more attractive and result in a wider availability of tication. It provides session management for IPTV services like
end devices as they will not be dedicated to a specific service CoD and scheduled content offerings, but also the integration
offering. It is expected that Open IPTV Forum compliant end with IMS based communication services like presence, caller
devices will become available for the retail market, giving the ID, chatting and messaging.
end user a choice between different devices and different service In case support for local applications (e.g. advanced inter-
offerings and as such stimulating the overall IPTV market. In active applications, home control) is needed, the Application
order to achieve the goal of a common UNI, but still be open for Gateway (AG) has to be used. It allows Java based applications
different business models, the Forum has defined several func- to be installed from the network and run locally in the consumer
tional entities within the consumer domain as shown in Fig. 12. domain. The AG has the capability to control and intercept the
The Open IPTV Forum Terminal Function (OITF) provides media stream for the purpose of inserting content generated or
the basic functionality to access IPTV services via the Open In- stored in the AG into that media stream. It can also interact with
ternet. This includes services discovery, user profile manage- the IG in order to access and control managed network services.
ment, metadata processing, content streaming, content and ser- While the OITF (Open IPTV Terminal Function) uses a spe-
vice protection, audio and video decoding, service monitoring cific Content and Service Protection (CSP) solution, it will also
and a declarative application environment for server based ap- be possible to support alternative CSP solutions via the CSP
plications and access to web based services. Service discovery, Gateway (CP). The CP terminates the alternative CSP scheme

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
MAISONNEUVE et al.: AN OVERVIEW OF IPTV STANDARDS DEVELOPMENT www.DownloadPaper.ir 327

and uses DLNA link protection for secure communication be- more advanced issues that researchers are exploring for the next
tween itself and the OITF and AG. generation of IPTV systems and services.
The Wide Area Network (WAN) gateway (WG) represents
the residential gateway including network attachment and re- REFERENCES
mote management functionality. [1] Transport of MPEG-2 TS-Based DVB Services Over IP Based Net-
The functional gateway entities can be implemented in dif- works., ETSI TS 102 034.
[2] Remote Management and Firmware Update System for DVB IP Ser-
ferent physical devices. The OITF, AG and IG can be for ex- vices, ETSI TS 102 824.
ample part of an IPTV set-top box. Networked TVs with inte- [3] Carriage of Broadband Content Guide (BCG) Information Over In-
grated IPTV set-top box functionality may implement the OITF ternet Protocol, ETSI TS 102 539.
function only. In this case IG, AG and CP have to be provided by [4] Forward Error Correction for Real-Time Video/Audio Transport Over
IP Networks, SMPTE specification 2022-1(2007).
additional devices (e.g. a residential gateway that already sup- [5] Universal Mobile Telecommunications System (UMTS); Multimedia
ports IMS/SIP functions for Voice over IP) as needed. Broadcast/Multicast Service (MBMS); Protocols and codecs; (3GPP
With its objective to define an interoperable end-to-end so- TS 26.346 Release 6), ETSI TS 126 346.
[6] Digital Video Broadcasting (DVB);IP Datacast over DVB-H: Content
lution both for Managed Networks and the Open Internet, the Delivery Protocols, ETSI TS 102 472.
integration of communication services and the support of web [7] DVB-IPTV Profiles for TS 102 034, ETSI TS102 826.
based applications and services, the Open IPTV Forum pro- [8] TISPAN; Service Layer Requirements to integrate NGN Services and
vides a unique approach to foster and widen the IPTV market. IPTV, ETSI TS 181 016, Ver. 2.0.0.
[9] TISPAN: Service Layer Requirements to integrate NGN services and
Having its work based on already existing specifications and on- IPTV (R3), ETSI TS 181 016 Ver. 3.0.1.
going work in other standardization bodies and fora will reduce [10] TISPAN; IPTV Architecture; Dedicated subsystem for IPTV functions,
the time to market and helps to increase the acceptance of the ETSI TS 182 028 , Ver. 2.0.0.
[11] TISPAN; IPTV Architecture; Dedicated Subsystem for IPTV Functions,
Forum’s work. 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.
III. CONCLUSIONS [14] TISPAN; IPTV Architecture; IPTV Functions Supported by the IMS
Subsystem, ETSI TS 182 027, Ver. 2.0.
We have just reviewed the five major IPTV standard or- [15] TISPAN; IPTV Architecture; IPTV Functions Supported by the IMS
Subsystem, ETSI TS 182 027, Ver. 3.0.
ganizations and the corresponding specifications that were [16] “Open IPTV Forum, Services and Functions for Release 1, Ver-
completed in 2008 (some of which are still being extended in sion 1.0.,” [Online]. Available: http://www.openiptvforum.org/
2009). It should be noted that in the meantime, another organ- docs/Open_IPTV_Forum_Services_and_Functions_for_Release_1_
ization—The Object Mobile Alliance (OMA)—has stepped V10.pdf
[17] “Open IPTV Forum, Service and Platform Requirements, Version
forward to start a new work item on IPTV as a follow up to its 1.0.,” [Online]. Available: http://www.openiptvforum.org/docs/Open_
work on Mobile TV (OMA BCAST). There are not only signifi- IPTV_Forum_Service_and_Platform_Requirements_V10.pdf
cant overlaps among existing specifications, developments also [18] “Open IPTV Forum, Functional Architecture, Version 1.1.,” [Online].
Available: http://www.openiptvforum.org/docs/OpenIPTV-Func-
seem to evolve towards more divergence within IPTV systems. tional_Architecture-V1_1-2008-01-15_APPROVED.pdf
As before, the upcoming specifications share a lot of common [19] Transport of MPEG-2 TS-Based DVB Services Over IP Based Net-
elements, but fall short of providing interoperability between works, ETSI TS 102 034.
themselves because they differ in many details. There is thus a [20] Remote Management and Firmware Update System for DVB IP Ser-
vices, ETSI TS 102 824.
strong risk to see new standard-based technology islands emerge [21] Carriage of Broadband Content Guide (BCG) Information Over In-
alongside the existing proprietary islands. Because of the large ternet Protocol, ETSI TS 102 539.
number of alternatives, there is a fair chance that one or several [22] “Final Report of the TSB Director’s Consultation Meeting on IPTV
Standardization,” Geneva, Switzerland, FG IPTV-DOC-0046, Apr.
of those islands will eventually wither and die. 4–5, 2006.
However, there will still be issues of interoperability between [23] “Focus Groups: Working Methods and Procedures,” ITU-T Recom-
IPTV systems, and possibly with mobile TV systems. The pur- mendation A.7, Oct. 2000.
suit of a single IPTV standard may have failed, but there may [24] “Mandate and terms of reference of FG IPTV working groups,” in First
Meeting of the FG IPTV, Geneva, Switzerland, Jul. 10–14, 2006, FG
still be room to achieve convergence standards that will bring IPTV-OD-0001.
together those technology islands for the purpose of bridging [25] “Mandate and terms of reference of FG IPTV working groups,” in IBC
their functionality. This is work that the ETSI MCD TC initia- 2007, Amsterdam, The Netherlands, Sep. 7–11, 2007.
[26] “General Overview of NGN,” ITU-T Recommendation Y.2001, Dec.
tive has started to explore. 2004.
With so many available standards, vendors and operators will [27] “Functional Requirements and Architecture of the NGN,” ITU-T Rec-
need to make hard choices, and interoperability may not be pos- ommendation Y.2012, Aug. 2006.
sible before another generation of standards is born, or one wins [28] “IMS for Next Generation Networks,” ITU-T Recommendation
Y.2021, Aug. 2006.
over all the others. Both ways are open, and they may take less [29] “IPTV Architecture," Qawra, Malta, FG IPTV-DOC-0181, Dec.
time than the previous round of exploratory standards. It might 11–18, 2007.
be a long and tortuous path. [30] “Appendix I to P.10/G.100: Definition of QoE,” Geneva, ITU-T
P.10/G.100, Jan. 16–25, 2007.
The published standards dealt with basic IPTV scenarios, but [31] “Telephone Network and ISDN Quality of Service, Network Manage-
the current standard work comes closer to state-of-the-art de- ment and Traffic Engineering: Terms and Definitions Related to Quality
velopments. In the past years, a significant amount of research of Service and Network Performance Including Dependability,” ITU-T
has been done on IPTV related issues, such as channel zap- Recommendation E.800, Aug. 1994.
[32] W. Sun, K. Lin, and Y. Guan, “Performance analysis of a finite duration
ping, QoS/QoE, admission control, and network interconnec- multichannel delivery method in IPTV,” IEEE Trans. Broadcasting,
tivity [32]–[38]. Many articles in this Special Issue focus on vol. 54, no. 3, Sep. 2008.

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
328 www.DownloadPaper.ir
IEEE TRANSACTIONS ON BROADCASTING, VOL. 55, NO. 2, JUNE 2009

[33] H. Joo, H. Song, D.-B. Lee, and I. Lee, “An effective IPTV channel Wei Li is currently a Research Scientist with the
control algorithm considering channel zapping time and network uti- Communications Research Centre (CRC) Canada.
lization,” IEEE Trans. Broadcasting, vol. 54, no. 2, pp. 208–216, Jun. He received the B.E. degree from Shandong Uni-
2008. versity (China) in 1985, the M.S. degree from the
[34] M. Rezaei, M. M. Hannuksela, and M. Gabbouj, “Tune-in time reduc- University of Science and Technology of China
tion in video streaming over DVB-H,” IEEE Trans. Broadcasting, vol. (China) in 1988, and the Ph.D. degree from the
53, no. 1, Part 2, pp. 228–320, Mar. 2007. Instutut National des Sciences Appliqués de Rennes
[35] D. lee, H. Joo, and H. Song, “An effective channel control algorithm for (France) in 1996, all in electrical engineering. In
integrated IPTV services over DOCSIS CATV networks,” IEEE Trans. October 2001, He joined the CRC where his major
Broadcasting, vol. 53, no. 4, pp. 789–796, Dec. 2007. focus is broadband multimedia systems and digital
[36] U. Jennehag, T. Zhang, and S. Pettersson, “Improving transmission ef- television broadcasting.
ficiency in H.264 based IPTV systems,” IEEE Trans. Broadcasting, vol. He was with Motorola Canada Software Centre, Montreal, Canada, from Jan-
53, no. 1, Part 1, pp. 69–78, Mar. 2007. uary 2000 to September 2001, where he conducted R&D in wireless commu-
[37] A. Davy, D. Botvich, and B. Jennings, “Revenue optimized IPTV ad- nication networks. From May 1998 to December 1999, he was with Emulive
mission control using empirical effective bandwidth estimation,” IEEE Imaging in Montreal, Canada. Prior to that, he had worked as a researcher at
Trans. Broadcasting, vol. 54, no. 3, Part 2, pp. 599–611, Sep. 2008. Sherbrooke University, Canada from 1997 to 1998.
[38] I. Diama and T. Ahmed, “A cross-layer interworking of DVB-T and Dr. Li published more than 40 technical papers. He served as session chairs
WLAN for Mobile IPTV service delivery,” IEEE Trans. Broadcasting, for the IEEE International Symposium on Broadband Multimedia Systems and
vol. 53, no. 1, Part 2, pp. 382–390, Mar. 2007. Broadcasting 2006 and 2007. He also served as reviewer for many renowned
international journals and conferences in the area of broadcasting, multimedia
communication and multimedia processing. He was the IPTV tutorial lecturer
in the 56th IEEE Broadcast Symposium and IBC2007, and the BTS IPTV rep-
Julien Maisonneuve holds a Ph.D. in computer resentative at the ITU-T.
systems from University of Paris. After working
for INRIA, he joined Alcatel’s research laboratories
and led successful projects in fault tolerance and
reliability. He represented Alcatel in bodies such Hong Liu is a research engineer at Communications
as the IETF and the OMG where he long served Research Centre Canada, Ottawa, Canada. He re-
as a board and architecture board member. More ceived the B.Sc. degree from Nanchang University,
recently he was a chairman in the architecture group Nanchang, China in 1993 and the M.Sc. degree from
of the ITU-T IPTV Focus Group and TISPAN University of Ottawa, Ottawa, Canada in 2001. From
liaison officer for DVB. He currently is Standard- 1993 to 1998, he worked as a lecturer in Electrical
ization Manager for applications and platforms in Engineering department of East China Jiao Tong
Alcatel-Lucent, representing the company in different standardization bodies University, Nanchang, China. From 2000 to 2001, he
and trade organizations. worked in Nortel Networks at Ottawa as a software
engineer 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 since
Muriel Deschanel Prior to joining Microsoft, Muriel 2006. His research interests include video processing and communication,
worked for TandbergTV and NDS where she was network communication, error control coding and DTV system.
involved in various stages of product development
for Digital TV solutions ranging from design engi-
neering to project management.
Overall, she has been working on Digital TV for Randy Sharpe is a lead technologist with Al-
15 years and on IPTV since 2002. Muriel Deschanel catel-Lucent’s Fixed Access Division Chief
graduated as an electronic engineer from the French Technology Officer (CTO) organization in Raleigh,
Grande Ecole “ENSERG” Grenoble’s National Insti- North Carolina. He received a B.S. in electrical
tute of Electronics and Radio-Electricity; she com- engineering from the University of Michigan in
bined her engineering degree with an advanced re- 1978 and an M.S. in electrical engineering from the
search degree in data processing. Massachusetts Institute of Technology in 1979. Prior
to his tenure at Alcatel-Lucent, he developed digital
video transmission systems at Bell Labs, and was
a founder and system architect at BroadBand Tech-
Juergen Heiles studied electrical engineering at the nologies. He joined Alcatel in 2001, specializing in
University of Applied Sciences Rhineland-Palati- broadband access network topics. His current work focus is on IPTV aspects
nate, Koblenz, Germany and the University of of broadband access networks. He co-chairs the ATIS IPTV Interoperability
Tennessee, Knoxville, United States. Forum Architecture Committee and is involved in other standards activities.
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 the Yiyan Wu (S’85-M’90-SM’95-F’01) is a Principle
standardization of SDH, OTN, GMPLS and Carrier Research Scientist of Communications Research
Ethernet at ETSI, ITU-T, IETF, Optical Internet- Centre Canada. His research interests include
working Forum and Metro Ethernet Forum. Since broadband multimedia communications, digital
2005 he is involved in IPTV related standardization activities for Siemens and broadcasting, and communication systems engi-
later on Nokia Siemens Networks. Currently he leads the common Mobile TV neering. He is an IEEE Fellow, an adjunct professor
and IPTV standardization activities of Nokia and Nokia Siemens Networks and of Carleton University, Ottawa, Canada. Dr. Wu is a
actively participates in the DVB Project’s IPTV activities and the Open IPTV member of the IEEE Broadcast Technology Society
Forum. Administrative Committee, and a member of the
Mr. Heiles is representing Nokia Siemens Networks in the Steering Group of ATSC Board of Directors, representing IEEE. He is
the Open IPTV Forum and leads the standards coordination ad-hoc group of the the Editor-in-Chief of the IEEE TRANSACTIONS ON
Forum which is responsible for the interaction with standardization bodies and BROADCASTING. Dr. Wu has more than 200 publications and received many
other fora. He was a co-chair of the ITU IPTV Focus Group QoS and Perfor- technical awards and patents for his contribution to the research and develop-
mance Aspects working group. ment of digital broadcasting and broadband multimedia communications.

Authorized licensd use limted to: Imperial Coleg Lond. Downlade on June 07,21 at 19:385 UTC from IE Xplore. Restricon aply.
View publication stats