Iptv3 5-A 0 0ird

Resource Data Collection, Analysis & Control (RDC)

For
IP-Based Services
Service Specification –
IP Television (IPTV)

Version 3.5-A.0.0
Industry Review Draft

July 26, 2006
© 1999-2006 IPDR.org, Inc.
7/26/2006 1
Preface
Contacts
For general questions regarding this document and referrals to technical experts for
detailed questions, please contact:
Chief Editor: Steve Cotton

Cotton Management Consulting
[email protected]
Business Requirements Working

Group – Protocol Working Group –
Lead: Betty Cockrell Lead: Tal Givoly

BSG Clearing Solutions Amdocs
[email protected]
Editor: Amit Kleinmann
Editor: Pat Walls Amdocs
Syniverse Technologies, Inc.
[email protected]
Acknowledgments
The following member companies contributed materially to the creation of this release of
the document:
Charter Members Supporting Members Associate

Amdocs Member/Liasion Orgs
BSG Clearing Solutions ATIS/OBF IP-NNI
Syniverse Technologies Committee
Abstract
This document is a companion to NDM-U, which specifies the overall business requirements and
protocol generic to all services. The content herein is compliant to those requirements and
specifications and is particular to the service specified.
Change History
Revision Date Author Remarks
Initial Draft March 27, 06 Amit Kleinmann & Steve Cotton
R. Draft 1 April 3, 06 Amit Kleinmann
R. Draft 2 April 10, 06 Amit Kleinmann
R. Draft 3 April 17, 06 Amit Kleinmann & Steve Cotton
R. Draft 4 May 21, 06 Amit Kleinmann & Steve Cotton
7/26/2006 2
Service Specification – IPTV……………… ………………….3.5-A.0.0 Industry Review Draft
R. Draft 5 May 25, 06 Amit Kleinmann & Greg Weber IPv4 address was changes to
general IP address (either v4 or
v6)
R. Draft 6 May 31, 06 Amit Kleinmann & Steve Cotton Added elements to reflect
new use cases, aligned schema
definition
R. Draft 7 July 10, 06 Steve Cotton Added elements to reflect more
IIF use cases
Industry July 26, 06 Steve Cotton At direction of BRWG
Review Draft
7/26/2006 3
Table of Contents
1 Introduction ....................................................................................................................5
1.1 Purpose .................................................................................................................5
1.2 Scope ....................................................................................................................5
1.3 Compatibility .......................................................................................................5
1.4 References ............................................................................................................5
1.5 Overview ..............................................................................................................6
2 IPTV Specification .........................................................................................................7
2.1 IPTV Network Architecture .................................................................................7
2.2 IPTV Services ......................................................................................................10
2.2.1 Main IPTV services .......................................................................................10
2.2.2 Supplementary Features of IPTV Services ....................................................12
2.3 Use Cases .............................................................................................................13
2.3.1 Basic Flow – View a Program on a Pre-Subscribed Channel ........................13
2.3.2 Basic Flow – View PPV Program..................................................................14
2.3.3 Basic Flow – View VOD Program ................................................................15
2.3.4 Advanced Flow – View a Program With Pause and Resume ........................15
2.3.5 Advanced Flow - Multi-Room Viewing ........................................................16
2.3.6 Advanced Flow – Selection of Subtitles and Audio Track ............................17
2.3.7 Receive Caller ID on Screen ..........................................................................17
2.3.8 Alternate Flow – Advertisement Offer ..........................................................18
3 IPTV Accounting Requirements ..................................................................................19
3.1 High Level Requirements of an IPTV Accounting..............................................19
3.2 IPTV Entities Handling Accounting & Usage Collection ...................................20
3.3 Usage Attribute List .............................................................................................21
3.3.1 General IPDR Attributes ................................................................................21
3.3.2 IPTV Usage Data Exporter Information ........................................................22
3.3.3 IPTV Receiving Device Information .............................................................22
3.3.4 IPTV Consumer/Viewer Information ............................................................23
3.3.5 IPTV Record Information ..............................................................................23
3.3.6 IPTV Service Consumption Information .......................................................24
3.3.7 IPTV Quality of Experience (QoE) Information ...........................................25
Table 1 - Service Usage Element Names ............................................................................26
4 Formal Specification ......................................................................................................28
4.1 Schema .................................................................................................................28
4.2 Sample Instance Document..................................................................................35
7/26/2006 4
1 INTRODUCTION
1.1 PURPOSE
This document is intended to specify the business use case and formal XML Schema for an
IP-based television service.
1.2 SCOPE
This document is limited to the discussion of issues as defined by the mission statement of
IPDR.org, namely:
The IPDR Organization (the “Organization”) is organized and operates as a non-stock not
for profit organization for the following purposes:
(a) To develop, agree upon and publish a non-proprietary, open specification for the
representation and encapsulation of Internet Protocol (IP)-based events for use by
business, operations and decision support systems. Such events include, but are not
limited to, IP-based network services, application services and e-commerce
transactions;
(b) To develop, agree upon and publish a non-proprietary, open specification for the
representation and encapsulation of IP-based network and service elements
provisioning events;
(c) To promote work accomplished and uniform specifications to the industry and submit
approved published specifications to the appropriate standards bodies for acceptance in
the public domain; and
(d) To have and exercise all powers necessary or convenient to affect any or all of the
purposes for which the Organization is organized.
1.3 COMPATIBILITY
Future revisions are expected to make every attempt to preserve investments made by
service providers and solution vendors by considering backward and forward compatibility
whenever it is practical.
1.4 REFERENCES
[1] NDM-U 3.0, IPDR.org.
[2] XML Schema Part 1: Structures, W3C Working Draft 7 April 2000.
[3] XML Schema Part 2: Data Types, W3C Working Draft 7 April 2000
7/26/2006 5
1.5 OVERVIEW
This specification is divided into two major chapters:
• Service Specification – description of the specific requirements and business use

case for the service in question.
• Formal Specification – XML Schema description of the IPDR Record for this
service.
7/26/2006 6
2 IPTV SPECIFICATION
2.1 IPTV NETWORK ARCHITECTURE
High Level IPTV Network Architecture
VSO
Metro
SHE: Super Head End
SHE VHO: Video Hub Office
VHO VSO: Video Serving Office
RG: Residential Gateway
VSO
Core
VSO
VHO
VHO Metro
VSO Access RG
Network
VSO Metro VSO

VSO
VSO
Super Head End (SHE) - the locations for acquisition and aggregation of national-level
broadcast TV (or linear) programming. SHEs are also the central point of on-demand
content insertion.
Video Hub Office (VHO) - the video distribution points within a demographic market
area (DMA) National content is received from each SHE. Local content is acquired and
encoded. VOD servers and other application servers typically located in the VHOs.
Insertion of local advertising is also performed in the VHO. IPTV services are provided
from the VHO via the aggregation/access network.
Video Serving Office (VSO) - contains/hosts all access systems used to connect the CO’s
(a VSO assumed to be a Central Office) to the subscribers. In addition, the VSO contains
aggregation equipment to enable efficient and reliable interconnection to the VHO.
Residential Gateway (RG) - Network node dedicated to a single subscriber / household

providing traffic management and routing between the access network and the home
network. The RG function may be integrated with the network termination. The RG is a
trusted device and is managed from the network.
7/26/2006 7
Region-Independent Region-Dependent
Video Content Video Content
Multicast
Traffic Multicast
Unicast Traffic
Traffic Unicast
Traffic
…
…
SHE VHO VSO RG
Core Metro / Aggregation Access

Segment Segment Segment
Core Network Segment - A Service Provider’s IPTV Core Network interconnects a small
number of SHE’s - potentially national in scope and application -- to a larger number of
VHOs -- typically regional in scope and application. Current core IP backbone networks
are likely to be leveraged since they are already in place to many candidate VHOs and
should be able to readily handle the incremental bandwidth that is expected to be
required.
Metro / Aggregation Segment
Access Segment
Home Network – The Network Interface Device (NID) is considered the demarcation
point between the WAN and the home network in copper-to-the-premises deployments,
while the Optical Network Terminal (ONT) is considered the demarcation point between
the WAN and the home network in fiber-to-the-premises deployments
7/26/2006 8
Home Network
T-1 T-1
Wireless Home
LAN Network
Copper NID W-1
NID
T-2 T-2
10/100BaseT End
Device
W-2 LAN Network
Fiber Residential
ONT
ONT W-3 End
Gateway Device
T-3 T-3
Power line
End
LAN Network STB
Device
W-4
Wireless V- Interface
T-4 T-4
Coaxial
LAN Network
U- Interface
W- Interface T - Interface
7/26/2006 9
2.2 IPTV SERVICES
The IPTV services are herby classified into Main IPTV services and supplementary
features of IPTV services. A main IPTV service is any service that is the main cause for
why a user is viewing/interacting-with the TV at a given moment. In contrast a
supplementary feature of an IPTV service is a feature that even when it is consumed by the
user, it is not the main reason why the user views/interacts with the TV.
2.2.1 MAIN IPTV SERVICES
Following is a list of main IPTV services:
1. IPTV Linear/Broadcast TV - the classic form of SDTV/HDTV offered by cable,

terrestrial broadcasters and direct broadcast satellite providers. It provides an
essentially continuous stream flowing from the content provider to the IPTV
RECEIVING DEVICE. In the IPTV context this continuous stream is most
commonly delivered via a one to many or multicast network. The following are
various flavors of IPTV Linear TV with supplementary services:
1.1. Subtitles and captions
1.2. Multilanguage audio tracks
1.3. PPV (Pay Per View) - an offering of pay-television broadcasts to customers in a

manner that they can buy a particular program event separately from any package
or subscription. The program event is shown at the same time to everyone
ordering it.
• PPV Purchase can be done via:
• a phone call to contact an automatic response unit (ARU) utilizing
automatic number identification (ANI)
• a phone call to customer service representative (CSR)
• filling and sending a form in an Internet web site
• filling and sending a form on an interactive TV e.g., on an electronic
program guide, using the remote control.
• PPV prices can be changed to meet demand or to encourage subscribers to
order early.
• PPV purchase time – PPV ordering can be done prior the program and in
certain occasion after the program was already started, e.g., it is possible to
order the program several days in advance, alternatively, in some cases it is
made possible to watch the first few minutes of an event before ordering.
• PPV report back - event purchases may be stored in the set-top box (or the
proper server) until an event based (or time based) request for data is received
and the data is accurately retrieved.
7/26/2006 10
1.4. Digital Video Recording (DVR)
1.5. Linear broadcast with Trick mode functionality
1.6. Multi-room viewing – e.g., ability to stop viewing on TV in one room and
resume viewing on TV in another room.
1.7. Linear broadcast with iTV
1.8. Linear broadcast with communication/messaging
1.9. Customer originated Video
2. IPTV Video on Demand (VOD) - The Video on Demand service enables TV

viewers to select TV videos from a central repository for viewing on a television at
their desired time. VOD systems are either “streaming VOD” or "push VOD”:
• Streaming VOD is VOD in which rendering on the display device/viewing can
(simultaneously) start as (or at least overlaps with) the video distribution over the
network
• Push VOD is VOD in which the program is brought in its entirety to a set-top box
before viewing starts (it can either be invoked by the viewer or by the operator
without an explicit viewer request).
There maybe multiple independent unicast viewing sessions for a given piece of
content.
There are a few variations of VoD which usually have to do with the method via
which the VoD service is billed/charged to the consumer. These include Subscription
VoD (SVoD), Free VoD (FVoD) etc.
The following are various flavors of VOD with supplementary services:
2.1. VOD with Subtitles and captions
2.2. VOD with Multilanguage audio tracks
2.3. VOD with Trick mode functionality.
2.4. Multi-room viewing VOD
2.5. VOD with iTV
2.6. VOD with communication/messaging
2.7. Customer originated VOD
3. IPTV Audio services
3.1. Dedicated radio/music channels (per genre of music)
7/26/2006 11
3.2. Audio/Music on Demand (MoD) – either streaming or pushed/download to play
4. IPTV gaming
5. IPTV Picture management
6. IPTV directory service (local yellow pages)
2.2.2 SUPPLEMENTARY FEATURES OF IPTV SERVICES
Following is a list of supplementary features of IPTV services:
1. Subtitles and captions - captions on video are text located somewhere on the picture
(covering a portion of the picture).
• CLOSED captions versus OPEN captions – CLOSED captions are captions
that are hidden in the video signal, invisible without a special decoder.
OPEN captions are captions that have been decoded, so they have become
an integral part of the television picture and thus cannot be turned off.
• Translation of the dialog only versus translation of the full audio - Subtitles
and captions are terms that are sometimes used as synonyms. However there
are cases where the term subtitle is used in the context of hearing audiences
while captions in the context of deaf audiences, e.g., subtitles may translate
the dialog into a different language, but rarely show all of the audio (for
example, captions show sound effects (e.g., "phone ringing" and
"footsteps"), while subtitles don't).
• International and Multilingual Captioning - Certain IPTV programs support
International and Multilingual Captioning and allow selection of the desired
language out of a list of supported languages.
• Online versus offline captioning – Online captions can be done from a script,
or actually created in real-time (usually by human transcriber but there are
also trials of using new speech recognition technologies to automatically
convert speech into written text). Offline captioning is done "after the fact,"
in a studio. Examples of offline captioning include television game shows,
videotapes of movies, and corporate videotapes (e.g., training videos). The
text of the captions is created on a computer, and synchronized to the video
using time-codes. They are then transferred to the videotape before it is
broadcast or distributed
2. Multilanguage audio tracks
3. Trick mode functionality - a subset of VCR functionality such as: pause, play, rewind,
fast forward, slow forward, slow rewind, jump to previous/future frame of the video,
etc.
7/26/2006 12
4. Interactive TV (iTV) - allow viewers to interact with TV meta-content or to interact

with the TV content itself, as they view:
• Interaction with TV meta-content - getting more information about what is
on the TV, whether sports, movies, news, or the like. Self ordering, e.g., pay
the bills, getting more information about what is being advertised, along
with the ability to buy it (TV-commerce).
• Interaction with TV content - The program, itself, might change based on
viewer input. Advanced forms, which still have uncertain prospect for
becoming main stream, include dramas where viewers get to choose plot
details and endings. Simpler forms, which are enjoying some success,
include programs that directly incorporate polls, questions, comments, and
other forms of (virtual) audience response back into the show.
5. Customer originated video/audio – TV viewers are able to upload content they create,
and make it available to any other viewer for viewing/listening, live or offline
6. Communication/Messaging – facilitation of convergence of classical Television

services with telephony and internet based communication services
7. Interactive Program Guide (IPG) - IPG is a service facilitated by the middleware,

which provides the viewers detailed information about the content available to them.
A viewer interacts with the network through the IPTV Receiving Device to receive
the information. This viewer interaction may trigger control transactions with the
network.
PiP (Picture in picture) – allows watching more than one TV program (channel) at the
same time on the TV. One program is displayed on the entire TV screen, and another
program or programs are displayed in individual smaller squares on the screen. For
example PiP can be used for the purpose of watching a recording while using the
secondary frame to show the viewer that desired broadcast programming is on, or vice
versa.
2.3 USE CASES
2.3.1 BASIC FLOW – VIEW A PROGRAM ON A PRE-SUBSCRIBED CHANNEL
• DESCRIPTION
A viewer selects a Pre-Subscribed Channel and watch a program that is broadcasted
on this channel.
• ACTORS
Viewer
IPTV set-top box (or IPTV multicast server)
• STEPS
1. Viewer – selects a pre-subscribed channel.
7/26/2006 13
2. IPTV set-top box (or IPTV multicast server) - tunes to the specified channel.
3. Viewer – views a program that is multicasted on the pre-subscribed channel.
2.3.2 BASIC FLOW – VIEW PPV PROGRAM
• DESCRIPTION
A viewer selects a PPV program, pays for it either in advance, instantly, or (if
allowed) few minutes after the program has already started.
• ACTORS
Viewer
• STEPS
1. Alternative 1 – Order Ahead PPV:
a. Viewer – selects a PPV program and orders it (commits to pay a
certain price for viewing it) in advance.
b. Viewer – at the proper date and time, selects the PPV program s/he
already ordered.
c. IPTV set-top box (or IPTV multicast server) - tunes to the specified
channel.
d. Viewer – views a program that is multicasted on the PPV channel.
2. Alternative 2 – Instantly Order PPV:
a. Viewer – at the proper date and time selects a PPV program and orders
it (commits to pay a certain price for viewing it).
b. IPTV set-top box (or IPTV multicast server) - tunes to the specified
channel.
c. Viewer – views a program that is multicasted on the PPV channel.
3. Alternative 3 – Post Order PPV
a. Viewer – at the proper date and time selects a PPV program without
ordering it (if allowed).
b. IPTV set-top box (or IPTV multicast server) - tunes to the specified
channel.
c. Viewer – views a program that is multicasted on the PPV channel for
the allowed period of time (usually first few minutes).
d. Viewer decides whether s/he would like to continue viewing the
program. Only in case the viewer wants to continue viewing the
program, the viewer order the program (commits to pay a certain price
for viewing it).
e. IPTV multicast server – In case the viewer does not express an interest
to continue viewing the program, stops the multicasting/playing of the
media content for the specific viewer.
7/26/2006 14
2.3.3 BASIC FLOW – VIEW VOD PROGRAM
• DESCRIPTION
A viewer selects a VOD program, order it (commit to pay a certain price) and view it
once, or view it any time within a certain time limit (e.g., 24 hours)..
• ACTORS
Viewer
IPTV VOD server
• STEPS
o Viewer – selects a VOD program and orders it (commits to pay a certain price
for viewing it).
o IPTV VOD server – deliver the VOD program to the viewer’s set-top box.
o Viewer – views the VOD program.
2.3.4 ADVANCED FLOW – VIEW A PROGRAM WITH PAUSE AND RESUME
• DESCRIPTION
A viewer view media content of choice that is either:
broadcasted on a Pre-Subscribed Channel,
broadcasted in a PPV manner, or
delivered on demand in a VOD fashion
The viewer, then, may pause and resume the media content. After pausing and
resuming the media content, the viewer may skip (backward and forward)
portions of the media content.
• ACTORS
Viewer
IPTV set-top box (or IPTV multicast/VOD server)
IPTV PVR
• STEPS
1. Viewer – selects a program from a pre-subscribed channel, PPV schedule, or
VOD program list.
2. IPTV set-top box (or IPTV multicast/VOD server) - tunes to the specified channel
and deliver the media content.
3. Viewer – views media content of choice
4. Viewer – may press the pause key on the remote control to pause the media
content
IPTV PVR – start recording the media content
5. Viewer – may press the resume key on the remote control to continue the playing
of the media content
IPTV PVR – stop recording the media content
7/26/2006 15
6. Viewer – may press the fast/slow forward button or the fast/slow backward button
on the remote control to skip to a specific location at the stored media content (in
case there is recorded media content at the PVR).
View Media
Content of Choice
No
No
Yes
Stored Media
No Pause?
Content?
Yes
Yes
Skip?
Resume?
Yes
No
Skip Configured store media

Interval/Direction content
2.3.5 ADVANCED FLOW - MULTI-ROOM VIEWING
• DESCRIPTION
The viewer, then, may pause the playing of the media content at a set-top box located
in a certain room and resume the media content at a different set-top box located in a
different room. After pausing and resuming the media content, the viewer may skip
(backward and forward) portions of the media content.
7/26/2006 16
• ACTORS
Viewer
IPTV PVR
• STEPS
See previous section 2.3.4)
2.3.6 ADVANCED FLOW – SELECTION OF SUBTITLES AND AUDIO TRACK
• DESCRIPTION
A viewer selects subtitle language and/or language of audio track for a program s/he
watches or is about to watch. The program may be delivered over a Pre-Subscribed
Channel or via VOD.
• ACTORS
Viewer
• STEPS
1. Viewer – selects a program to watch (from a pre-subscribed channel, PPV or
VOD schedule)
2. Viewer – may selects subtitle language and/or language of audio track
3. IPTV set-top box (or IPTV multicast server) - tunes to the specified
channel/program.
4. Viewer – views the program.
5. Viewer – may change the subtitle language and/or the (language of the) audio
track
2.3.7 RECEIVE CALLER ID ON SCREEN
• DESCRIPTION
The viewer, then, receives a phone call and the caller ID appears on the TV
screen.
• ACTORS
Viewer
IPTV set-top box
• STEPS
1. Viewer – views media content of choice
7/26/2006 17
2. IPTV set-top box – presents a caller ID on the TV screen
2.3.8 ALTERNATE FLOW – ADVERTISEMENT OFFER
• DESCRIPTION
A viewer selects the type of advertisement s/he prefers to receive. The viewer then
views media content of choice that is either:
• broadcasted on a Pre-Subscribed Channel,
• broadcasted in a PPV manner, or
• delivered on demand in a VOD fashion
An advertisement is presented on the TV screen. It can be presented either on the

entire screen or on portion of the screen.
If the advertisement is multi-dimensional advertisement, the viewer may navigate

within the advertisement.
If the advertisement is interactive, the viewer may interact with the advertisement,
order the advertised content or asks for a sales person to contact him/her.
• ACTORS
Viewer
IPTV PVR
IPTV advertisement server
• STEPS
7/26/2006 18
3 IPTV ACCOUNTING REQUIREMENTS

3.1 HIGH LEVEL REQUIREMENTS OF AN IPTV ACCOUNTING
An IPTV service operator requires accounting and usage information for billing, service
assurance purposes and potentially for other contractual obligations, for e.g. settlements
with content partners, and reporting to rating bodies, e.g., Nielsen.
Following are the main requirements of an IPTV network accounting and usage
framework:
1. Simultaneous collection of IPTV usage data from multiple IPTV network elements and
correlation of the collected usage data to a given session or subscriber. Billable events
are typically viewer traceable actions with financial consequences. Service reporting is
largely concerned with adequately identifying service consumption events. Service
consumption events are typically a superset of billable events. Service consumption
events do not always have a financial consequence for the viewer, e.g. IPTV Channel
change events within a pool of IPTV subscribed channels may be an example of a
service consumption event which is not a billable event.
2. Highly reliable usage data collection - In general, an IPTV service provider would
prefer that the IPTV service reporting data be collected securely and reliably. In many
cases this may be achievable on an aggregated basis within the service provider’s
equipment. If network accounting and usage information (e.g., billable events) is to be
used by charging and billing systems, then “high reliability” is an unspoken
requirement for any potential IPTV network usage and accounting framework. High
reliability in this context means that event messages are reliably conveyed from their
source to their destination, regardless of the volume of traffic on the network or
possible failures in the network, network elements, or downstream collectors of such
records. A highly reliable framework should contain mechanisms, such as fail-over,
redundant components, and unique event message IDs, that minimize the risk of lost or
duplicate event messages.
3. Ability to account for IPTV usage and activities in both Real-Time and non Real-Time
(Real-Time and non Real-Time are relative to when the events are sent to the mediation
system and does not imply when the final bill may be available to the customer nor that
events are sent to indicate incremental usage of network resources). Supporting Real-
time Charging Systems that relate the events to the account balance as they occur. This
may be necessary for services like, order ahead PPV (OPPV) or VOD.
4. High performance - The requirement to account for IPTV network usage and activities
in real-time carries with it another unspoken requirement: high-performance. In this
case, high-performance means the efficient use of capabilities of both the network and
the network elements, such that the “real-time” availability of usage records is possible
even in situations where both the network and network elements are stressed by a high
volume of “traffic”. Attaining such efficiency requires:
a. a concise encoding scheme, one that minimizes the size of usage records sent
out on the network.
b. an efficient delivery protocol that minimizes the overhead involved with
delivering event messages, while still enabling the reliable transfer of messages.
7/26/2006 19
c. an efficient delivery protocol that minimizes the impact that network latency
can have on volume of event records that can be delivered from the various
network elements to a central repository.
5. Flexibility and extensibility - the framework for handling network accounting and
usage must also be flexible and extensible enough to support both a wide variety of
IPTV based services as well as the significant number of event messages that can be
generated by the diverse array of network elements supporting each such service.
Furthermore, in addition to supporting possible “common denominator” or
“standardized” event messages, the IPTV network accounting and usage framework
may also need to support custom extensions, in the form of user defined fields in
event messages. The framework also needs to be easily extensible, to be able to
support future requirements imposed by new services and new technologies.
3.2 IPTV ENTITIES HANDLING ACCOUNTING & USAGE COLLECTION
The following IPTV entities are involved in handling of IPTV accounting and collection of
usage date:
1. The Input Device of the IPTV Receiving Device - this entity serves as the device
which: allows the viewer to select IPTV content or channel, provide a feedback on the
IPTV programs, insert a text input, etc. It is typically in a form of a “remote control”,
but it can also be a (wireless) keyboard or any other appropriate input device.
2. The IPTV Receiving Device - this entity, a.k.a. ITF (as defined in the IPTV
Architecture Requirements of the ATIS IPTV Interoperability Forum), represents the
functionality within the consumer network that is responsible for terminating the IP
signal, and converting the content into a renderable format. It is usually a set-top box
(but it can also be a DVR an IPTV-ready TV, etc) capable of functioning as a network
node in an IP network.
The IPTV Receiving Device receives the viewer input, e.g., when a viewer presses on a
remote control key, the IPTV Receiving Device receives a proper signal. The IPTV
Receiving Device should include such functions as are necessary to support reporting
on service usage patterns to the service operator. Especially the IPTV Receiving
Devices supporting the IPTV services shall provide mechanisms to detect and report
service consumption events that are not detectable elsewhere in the IPTV
infrastructure, for example, channel change events within a pool of subscribed channels
are also observable in the network and may not require specific actions at the IPTV
Receiving Device.
Reporting actions may be required at the IPTV Receiving Device when content is
dynamically assembled at the IPTV Receiving Device – e.g. a local insertion of
advertising or the linkage to another human traceable action e.g. URL browsing. The
IPTV Receiving Device functions to be supported will depend on the scope of services
supported and the IPTV Receiving Device packaging. For example, an IPTV
Receiving Device with integrated display capabilities may have different services
supported than an IPTV Receiving Device which terminates the IPTV service, but
(securely) passes the content on to a separate display device or portable media player,
and hence a different set of service reporting functions. Mobile IPTV Receiving
Devices may consume services in a variety of locations.
7/26/2006 20
The IPTV Receiving Device should be uniquely identified by an IPTV Receiving

Device ID, such as the IPTV Receiving Device MAC address (i.e., Ethernet addresses).
An IP address may be dynamically assigned to the IPTV Receiving Device via DHCP,
so it may change over time. Current IP addresses of the IPTV Receiving Device should
be recorded for auditing purposes
3. The IPTV Usage Data Exporter – this entity is the IPTV network element where
IPTV Service consumption events are created. In the case of telco-TV it is the network
element which receives the viewer input (and other info messages) from multiple IPTV
Receiving Devices. However, in certain cases, the IPTV Receiving Device itself can
also be an IPTV Usage Date Exporter. The IPTV Usage Data Exporter MUST support
periodic and event based generation of service consumption records. The IPTV Usage
Data Exporter should be identified by host name or another unique string with the same
FQDN format.
4. The IPTV Usage Data Collector
3.3 USAGE ATTRIBUTE LIST
IPDR records for IPTV are constructed from a number of elements that describe IPTV
usage data Exporters that are serving IPTV Receiving Devices, IPTV Receiving Devices,
and IPTV service attributes, counters, and viewer inputs. An IPDR element MUST
describe a single IPTV Usage Billing Record for a single IPTV service and a single IPTV
viewer.
3.3.1 GENERAL IPDR ATTRIBUTES
IPDRCreationTime
7/26/2006 21
The optional IPDRCreationTime element of the general IPDR schema is not required in
IPTV IPDRs and MUST NOT be present.
seqNum
The optional seqNum element of the general IPDR schema is not required in IPTV
IPDRs and MUST NOT be present
3.3.2 IPTV USAGE DATA EXPORTER INFORMATION
An IPTV IPDR contains the following element that identifies the IPTV Usage Data
Exporter. Each IPDR within the IPDRDoc will contain identical values for this element
since all the IPDRs are based on information maintained by the same IPTV Usage Data
Exporter. Note that the IPDR records of the IPTV Usage Data Exporter Information can
be streamed independently from the IPTV IPDR records of the Service consumption
events. These IPDR records can then be correlated at the IPTV Usage Data Collector
using the IPTVExporterHostName element.
IPTVExporterHostName
IPTVExporterHostName is the fully qualified domain name (FQDN) of the IPTV Usage
Data Exporter. This element is required and must not be null. If the IPTV Exporter does
not have an FQDN entry in the DNS, a proper unique FQDN must be configured at the
IPTV Usage Data Exporter that will serve as its identifier.
IPTVExporterIpAddress
IPTVExporterIpAddress is a non-specific version of an IP address (either v4 or v6), of
type hexBinary, determined as to version by the application through lexical parsing. This
is represented in the compact encoding as a 16 byte octet string.
IPTVExporterSysUpTime
IPTVExporterSysUpTime is the elapsed time (in seconds) that the IPTV Usage Data
Exporter has been running since it was last started. This counter displays the difference
between the start time and the current time
3.3.3 IPTV RECEIVING DEVICE INFORMATION
An IPTV IPDR contains the following elements that uniquely identify the IPTV
Receiving Device. Each IPTV IPDR for a given IPTV Receiving Device within the
IPDRDoc will contain identical values for these elements.
IPTVreceivingDeviceID
The IPTV Receiving Device should be uniquely identified by an IPTV Receiving Device
ID, such as the IPTV Receiving Device MAC address (i.e., Ethernet address formatted in
hyphen '-' delimited hex notation such as a1-b2-c3-d4-e5-f6). This element is required.
IPTVreceivingDeviceIpAddress
IPTVreceivingDeviceIpAddress is a non-specific version of an IP address (either v4 or
v6), of type hexBinary, determined as to version by the application through lexical
parsing. It is represented in the compact encoding as a 16 byte octet string.
7/26/2006 22
3.3.4 IPTV CONSUMER/VIEWER INFORMATION
An IPTV IPDR contains the following elements that uniquely identify the IPTV
Consumer and/or the IPTV viewer Profile. Each IPTV IPDR for a given IPTV Viewer
Profile within the IPDRDoc will contain identical values for these elements.
IPTVconsumerID
The IPTV Consumer should be uniquely identified by the IPTV consumer ID
This element is required
IPTVviewerID
The specific IPTV Viewer/s within a consumer household should be uniquely identified
by the IPTV viewer ID
This element is optional.
IPTVviewerProfileID
The IPTV Viewer Profile should be uniquely identified by the IPTV viewer profile ID
This element is optional
3.3.5 IPTV RECORD INFORMATION
Rectype
The record type may have any one of the following values:
• Start - indicates the beginning of a service. A numeric value of 1 in this field
indicates 'Start' service record.
• Interim - indicates a running service - An Interim service flow is reported in each
IPDRDoc that is created while it is running. A numeric value of 2 in this field
indicates 'Interim' service record.
• Stop - indicates a terminated service. An IPDR record of type Stop is only
reported once in an IPDRDoc after the service is deleted. A numeric value of 3 in
this field indicates 'Stop' service record.
• Started & Stopped - indicates a terminated service with only one IPDR record. An
IPDR record of this type is only reported once in the IPDRDoc after the service is
deleted. A numeric value of 4 in this field indicates ‘Started & Stopped’ service
record
This element is required.
RecCreationTime
The RecCreationTime ="yyyy-mm-ddThh:mm:ssZ" UTC time stamp at the time the data
for the record was acquired based on IPTVExporterSysUpTime value. The compact
representation of this element is the 64-bit Long value since EPOCH. This element is
required.
Notes: The time zone is always GMT for IPTV IPDRs
7/26/2006 23
3.3.6 IPTV SERVICE CONSUMPTION INFORMATION
Services are the unit of billing usage data collection for an IPTV viewer. In addition,
since a viewer may change their IPTV Service Package over time, it is very likely that a
given viewer will have several IPDRs, one for each Service they have used during the
collection period.
An IPTV IPDR contains the following elements that identify the IPTV service and
contain the service attributes, viewer inputs, and counters maintained by the IPTV Usage
Data Exporter for that IPTV service. Service consumption information records MUST be
identified by IPTV Receiving Device ID but not necessarily sorted. An individual IPTV
Service consumption Information record should be generated for all currently running
Services as well as all terminated Services that were deleted and logged during the
collection period. Note well that a provisioned or admitted service that was deleted before
it became active is not recorded in the billing document.
serviceIdentifier
The serviceIdentifier element contains the service identifier (SID). This element is
required and is needed to correlate the IPDRs for an individual service between adjacent
IPDR records, e.g., when computing delta counters. To avoid potential confusion in the
billing system, it is desirable that the IPTV Usage Data Exporter assign serviceIdentifier
values with a monotonically increasing pattern.
serviceType
The serviceType element contains a numeric value that represents the type of the service
associated with the service. The type of a service is one of the main IPTV services:
- Linear TV Broadcast
- VOD
- Audio broadcast
- Game
- Picture Management
- Directory service
serviceSubType
The serviceType element contains a bit sequence where each bit value indicates the
existence (=1) or absence (=0) of a feature that is associated with the specific service
type. For example for service of type linear TV broadcast a certain bit may indicate
whether the service is a live broadcast or a pre-recorded broadcast. Another bit may
indicate whether a premium audio is supported or not.
channelID
7/26/2006 24
The channelID element contains the identifier of the main channel the viewer is viewing
at the time of the event.
contentID
The contentID element contains a unique identifier of the specific content the viewer is
viewing at the time of the event.
actionID
The actionID element contains a unique identifier of the specific action the viewer
performed e.g., by pressing on a specific button on the remote control in the context of
the specific channel/content.
viewerInput
The viewerInput element contains a textual input given by the viewer. The viewer input
is the trigger for the event. This element is optional
3.3.7 IPTV QUALITY OF EXPERIENCE (QOE) INFORMATION
Service reporting is also concerned with ensuring that the delivered experience is
adequate, i.e., that the service delivery was achieved within acceptable performance
parameters, and with the identification of failures in service delivery.
The QoE requirements for delivery of digital TV are very demanding, especially for
HDTV.
The IPTV Quality of Experience specification of the ATIS IPTV Interoperability Forum
describes the appropriate metrics for the IPTV Quality of Experience delivered.
The IPTV Services are metered and enforced against a Service Level Agreement (SLA)
that specifies the Quality of Experience (QoE) that an IPTV operator provides to a
viewer.
7/26/2006 25
Table 1 - Service Usage Element Names
Category Name Type Presence Permitted Values Remarks

IPTV Usage Data EXPORTER Information
Who IPTVExporterHostName String Required e.g IPTV01.ATT.com Refer to Section
Who IPTVExporterIpv4Address IPV4Addr Required nnn.nnn.nnn.nnn Refer to Section
When IPTVExporterSysUpTime UnsignedInt Required 32-bit integer Refer to Section
IPTV Receiving Device Information
Who IPTVreceivingDeviceID String Required Refer to Section
Who IPTVreceivingDeviceIpAddres Ipdr:ipAddr Required Refer to Section
s 3.3.3
Who IPTVreceivingDeviceIpv4Addr IPV4Addr Required nnn.nnn.nnn.nnn Refer to Section
ess
Consumer/Viewer Information
Who IPTVconsumerID String Required Refer to Section
Who IPTVviewerID String Required Refer to Section
What IPTVviewerProfileID String Required Refer to Section
Record Information
What RecType Enumeration Required Start(1) | Interim(2) | Refer to Section
Stop(3)
What RecCreationTime dateTimeMsec Required yyyy-mm- Refer to Section
ddThh:mm:ss.mmmZ
Service Consumption Information
What serviceIdentifier UnsignedInt Required 32-bit integer Refer to Section
What serviceType Enumeration Required Linear TV Broadcast(1) | Refer to Section
VOD(2) | Audio
Broadcast(3) | Game(4) |
Picture Management (5)
What serviceSubType Unsigned Long Required 64-bit counter Refer to Section
What channelID Integer Required Refer to Section
What contentID Integer Optional Refer to Section
What actionID Integer Optional Refer to Section
What viewerInput String Optional Refer to Section
What subtitleSelected Yes/No Optional

What audioTrackSelected Yes/No Optional
What languageCode String Conditional ISO 639.2
Rule: Present IFF
(subtitleSelected |
audioTrackSelected)
What callerIDDelivered Yes/No Optional
What advertiesmentOfferAccepted Yes/No Yes/No
What advertisementID String Conditional Rule: Present IFF
advertisementOfferA
ccepted
What gameID String Optional
7/26/2006 26
7/26/2006 27
4 FORMAL SPECIFICATION
4.1 SCHEMA
<?xml version = "1.0" encoding = "UTF-8"?>


<schema xmlns = "http://www.w3.org/2001/XMLSchema"
targetNamespace = "http://www.ipdr.org/namespaces/IPTV"
xmlns:ipdr = "http://www.ipdr.org/namespaces/ipdr"
xmlns:IPTV = "http://www.ipdr.org/namespaces/IPTV"
version = "3.5-A.0.0.ID"
elementFormDefault = "qualified"
attributeFormDefault = "unqualified">
<include schemaLocation = "http://www.ipdr.org/public/IPDRTypes.xsd"/>
<import namespace = "http://www.ipdr.org/namespaces/ipdr" schemaLocation =
"http://www.ipdr.org/public/IPDRDoc3.5.1.xsd"/>
<element name = "IPTVExporterHostName" type = "string"/>
<element name = "IPTVExporterIpAddress" type = "ipdr:ipAddr"/>
<element name = "IPTVExporterSysUpTime" type = "int">
<annotation>
<appinfo>
<units>seconds</units>
</appinfo>
<documentation>
The elapsed time (in seconds) that the Exporter has been
running since it was last started.
This counter displays the difference between the start time
and the current time.
</documentation>
</annotation>
</element>
<element name = "IPTVreceivingDeviceID" type = "string"/>
7/26/2006 28
<element name = "IPTVreceivingDeviceIpAddress" type = "ipdr:ipAddr"/>

<element name = "IPTVsubscriberID" type = "string"/>
<element name = "IPTVviewerID" type = "string"/>
<element name = "IPTVviewerProfileID" type = "string"/>
<element name = "RecType">
<simpleType>
<restriction base = "int">
<enumeration value = "1">
<annotation>
<appinfo>
<ipdr:enumMeaning>
Start
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Interim
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Stop
</ipdr:enumMeaning>
7/26/2006 29
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Started and Stopped
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
</restriction>
</simpleType>
</element>
<element name = "RecCreationTime" type = "ipdr:dateTimeMsec"/>
<element name = "serviceIdentifier" type = "int"/>
<element name = "serviceType">
<simpleType>
<restriction base = "int">
<annotation>
<appinfo>
<ipdr:enumMeaning>
Linear TV Broadcast
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
7/26/2006 30
<annotation>
<appinfo>
<ipdr:enumMeaning>
VOD
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Audio Broadcast
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Game
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Picture Management
7/26/2006 31
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
<annotation>
<appinfo>
<ipdr:enumMeaning>
Directory
</ipdr:enumMeaning>
</appinfo>
</annotation>
</enumeration>
</restriction>
</simpleType>
</element>
<element name = "serviceSubType" type = "long"/>
<element name = "channelID" type = "int"/>
<element name = "contentID" type = "int"/>
<element name = "ActionID" type = "int"/>
<element name = "viewerInput" type = "string"/>
<element name = "subtitleSelected" type = "int"/>
<element name = "audioTrackSelected" type = "int"/>
<element name = "languageCode" type = "string">
<annotation>
<documentation>
<appinfo>
<ipdr:reference>
http://www.loc.gov/standards/iso639-2/langcodes.html
</ipdr:reference>
</appinfo>
7/26/2006 32
</documentation>
</annotation>
</element>
<element name = "callerIDDelivered" type = "int"/>
<element name = "advertisementOfferAccepted" type = "int"/>
<element name = "advertisementID" type = "string"/>
<element name = "gameID" type = "string"/>
<complexType name = "IPDR-IPTV-Type">
<complexContent>
<extension base = "ipdr:IPDRType">
<sequence>
<element ref = "IPTV:IPTVExporterHostName"/>
<element ref = "IPTV:IPTVExporterIpAddress"/>
<element ref = "IPTV:IPTVExporterSysUpTime"/>
<element ref =
"IPTV:IPTVIPTVreceivingDeviceID"/>
<element ref =
"IPTV:IPTVIPTVreceivingDeviceIpAddress"/>
<element ref = "IPTV:IPTVsubscriberID "/>
<element ref = "IPTV:IPTVviewerID"/>
<element ref = "IPTV:IPTVviewerProfileID"/>
<element ref = "IPTV:RecType"/>
<element ref = "IPTV:RecCreationTime"/>
<element ref = "IPTV:serviceIdentifier"/>
<element ref = "IPTV:serviceType"/>
<element ref = "IPTV:serviceSubType"/>
<element ref = "IPTV:channelID"/>
<element ref =
"IPTV:contentID" minOccurs = "0"/>
<element ref =
"IPTV:ActionID" minOccurs = "0"/>
<element ref =
7/26/2006 33
"IPTV:viewerInput" minOccurs = "0"/>

<element ref =
"IPTV:subtitleSelected" minOccurs = "0"/>
<element ref =
"IPTV:audioTrackSelected" minOccurs = "0"/>
<element ref =
"IPTV:languageCode" minOccurs = "0"/>
<element ref =
"IPTV:callerIDDelivered" minOccurs = "0"/>
<element ref =
"IPTV:advertisementOfferAccepted" minOccurs = "0"/>
<element ref =
"IPTV:advertisementID" minOccurs = "0"/>
<element ref =
"IPTV:gameID" minOccurs = "0"/>
</sequence>
</extension>
</complexContent>
</complexType>
</schema>
7/26/2006 34
4.2 SAMPLE INSTANCE DOCUMENT
7/26/2006 35

Iptv3 5-A 0 0ird

Uploaded by

Copyright:

Available Formats

Iptv3 5-A 0 0ird

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Iptv3 5-A 0 0ird

Uploaded by

Copyright:

Available Formats

Resource Data Collection, Analysis & Control (RDC)

July 26, 2006

© 1999-2006 IPDR.org, Inc.

Chief Editor: Steve Cotton

Business Requirements Working

Lead: Betty Cockrell Lead: Tal Givoly

Charter Members Supporting Members Associate

[1] NDM-U 3.0, IPDR.org.

This specification is divided into two major chapters:

• Service Specification – description of the specific requirements and business use

High Level IPTV Network Architecture

VSO Metro VSO

Residential Gateway (RG) - Network node dedicated to a single subscriber / household

SHE VHO VSO RG

Core Metro / Aggregation Access

Metro / Aggregation Segment

2.2 IPTV SERVICES

2.2.1 MAIN IPTV SERVICES

Following is a list of main IPTV services:

1. IPTV Linear/Broadcast TV - the classic form of SDTV/HDTV offered by cable,

1.1. Subtitles and captions

1.2. Multilanguage audio tracks

1.3. PPV (Pay Per View) - an offering of pay-television broadcasts to customers in a

1.4. Digital Video Recording (DVR)

1.5. Linear broadcast with Trick mode functionality

1.7. Linear broadcast with iTV

1.8. Linear broadcast with communication/messaging

1.9. Customer originated Video

2. IPTV Video on Demand (VOD) - The Video on Demand service enables TV

2.1. VOD with Subtitles and captions

2.2. VOD with Multilanguage audio tracks

2.3. VOD with Trick mode functionality.

2.4. Multi-room viewing VOD

2.5. VOD with iTV

2.6. VOD with communication/messaging

2.7. Customer originated VOD

3. IPTV Audio services

3.1. Dedicated radio/music channels (per genre of music)

3.2. Audio/Music on Demand (MoD) – either streaming or pushed/download to play

5. IPTV Picture management

6. IPTV directory service (local yellow pages)

2.2.2 SUPPLEMENTARY FEATURES OF IPTV SERVICES

Following is a list of supplementary features of IPTV services:

2. Multilanguage audio tracks

4. Interactive TV (iTV) - allow viewers to interact with TV meta-content or to interact

6. Communication/Messaging – facilitation of convergence of classical Television

7. Interactive Program Guide (IPG) - IPG is a service facilitated by the middleware,

2.3 USE CASES

2.3.1 BASIC FLOW – VIEW A PROGRAM ON A PRE-SUBSCRIBED CHANNEL

2.3.2 BASIC FLOW – VIEW PPV PROGRAM

2.3.3 BASIC FLOW – VIEW VOD PROGRAM

2.3.4 ADVANCED FLOW – VIEW A PROGRAM WITH PAUSE AND RESUME

Skip Configured store media

2.3.5 ADVANCED FLOW - MULTI-ROOM VIEWING

2.3.6 ADVANCED FLOW – SELECTION OF SUBTITLES AND AUDIO TRACK

2.3.7 RECEIVE CALLER ID ON SCREEN

2. IPTV set-top box – presents a caller ID on the TV screen

2.3.8 ALTERNATE FLOW – ADVERTISEMENT OFFER

An advertisement is presented on the TV screen. It can be presented either on the