Timing Requirements In IPTV Solutions

Vandana Upadhyay
Senior Director, Business Development
Symmetricom

November 15, 2006

Driver of Timing
Past Future
Frequency Frequency
Transmission Alignment For Certain Types of Transport Alignment
Real-time services voice, fax Controlling Element Clocks For Real-time
Applications & Services in Packet Networks
Circuit Emulation and Mobile Call Hand-off

Time
Ways to Measure Packet Performance
Billing & Management Application
Synchronize Different Aspects of an End-to-
end Application/Service Delivery

2
IPTV what is it (and is not)

Internet Protocol Television(IPTV) is an end-to-end delivery

of live broadcast and/or stored video signals to users over a
broadband connection using Internet Protocols in a
managed services network with user interactive features

What it is not
Peer to peer video/image sharing
IP streaming over the internet
Digital/Packet/IP video Transport of video over IP/Ethernet
Backbone
DTV

3
IPTV Deployment Is Complex

IPTV Service Is Not the Same As Delivery of Video in

Cable/satellite Broadcast Model

Transport Network Changes

Service/Application Delivery Changes

Last Mile & Home Distribution

Carrier Challenge : Ensuring end-to-end QOS

Customer Satisfaction
4
MPEG Timing Model Requirements
ISO/IEC13818-1/ITUT H.222

Encoder and decoder clocks must be synchronized per

specifications standardized

Related to PCR:
Frequency offset : 30ppm
Frequency drift rate : 2.8 ppb/s
Time-stamp accuracy : better than 500ns
Decoder tolerance is typically 50ms

Related to PAL (color sub-carrier)

Frequency offset : 2.3ppm
Frequency drift rate : 23 ppb/s PAL

MPEG Timing Model assumes constant delay network (e.g. ATM)

5
MPEG Timing Model for encoder and
decoder(STB) synchronization
Encoder Decoder/STB

Constant
delay
Network

STC: System Time Clock PCR: Program Clock Reference

PCR a time stamp generated by encoder STC, inserted into a transport PCRs extracted before the receiver buffer to synchronize decoder STC
stream packet. Used to synchronize decoder STC with encoder STC 6
PCR Integrity in Traditional Video
Network

Encoder -1

Transport Constant Delay Network EDGE RF

STB
Encoder -2 Stream QAM
Mux Virtually no Jitter

Generally ATM/SONET
Encoder -n
PCR Correction

PCR Budget
PCR Jitter Tolerance
Budget Allocation100%

Even in a constant delay network, some jitter is introduced which is handled through buffering at STB
In addition, PCR correction and reinsertion is applied at the edge before the RF segment, particularly
where backbone transport is IP
7
Encoder/STB synchronization in IP
networks

Encoder Decoder/STB

Not a constant delay network

Network jitter adds to PCR

Jitter from other sources

Even brief intervals of high jitter

impact QOS

Buffering, FEC not adequate

8
Mechanism to maintain PCR
Integrity in end-to-end IP Delivery
~

Encoder -1

Packet Network
IP
Streamer Core Metro Access Home STB
Encoder -2

Encoder -n

PCR Budget

Network Jitter exceeds PCR Budget

100%
PCR
Budget

Ensure all encoder clocks are synchronized

Provide network time reference at both ends (ISO/IEC 138181-1)
Currently proprietary implementations, standards being defined e.g. ATIS 9
IPTV Service Requirements
Interactivity/On Demand Is New
Fast channel change response times
New service paradigm interactive/on demand/customized/targeted/ personalized

Service delivery infrastructure is highly distributed

A single service request involves multiple geographically dispersed servers All need to
have consistent time
DRM/ Billing/Authentication/Content Server/Ad Server

Subscriber Authentication and Billing Transaction Handling

Lack of consistent time across all systems could cause service disruption e.g.
DRM license expires while program in progress
BSS/OSS integration
Millions of transactions/day

Network Security and Content Protection is a Must

Secure and authenticated time required
10
Geographically Distributed
Service Delivery

5: VoD server signaled, 4: Billing event sent to policy

unicast video stream initiated server/record keeping
VIDEO
Policy Manager HEADEND

OK ! ! BILL
VoD
RADIUS
! !
MPEG ENCODER HDTV 1
3: End user decides to watch HDTV 2
VoD instead
HDTV 3
DSLAM

REGIONAL NETWORK
ACCESS GW
VoD?
Ch 2? NETWORK PoP
2: Access Gateway with
multicasting functionality
receives signal from STB
1: End user turns on HDTV and passes correct stream to
and begins surfing channels end user

11
Last Mile Complexity

VIDEO/ Games
Cable/Sat VIDEO
(IPTV)
Games

Internet
Internet

Voice VoIP

Ensuring QoS in the Last Mile a challenge

Video delivery is on a shared pipe with other services

Last mile prone to physical layer impairments

Contention within the home network

New requirements for synchronization emerging

12
 IPTV QoS Measurement

Content Provider Service Provider Network Domain Measurements

Content Source
Off-line 0
Content
Ingestion 1
Content
Encoding 2 A
Video Head End
[Core]
IP/Transport Layer
Well known e.g. packet loss,
B packet delay, jitter
Content Video Hub Office
Playout 3 [-]
Media/Service Layer
C being defined in standards
Content Source 0 Content Content 2 Video Serving
Off-Air 0 Acquisition 1 Trans-coding 4 Office [Metro] bodies IETF, ITU, ATIS

D IPTV is an asymmetric
Tranaction
Access service
Content Domain
Server
One way delay
measurements

Home Networks
STB
7 Measurement points
E & Routers F Network Stack Decoder 8 Display 9
7
6 Many points between
Customer Domain headend and the end device
Measurement points require
ATIS IPTV QoS Measurement Model precise time reference
(Original Contribution by Simon Jones/Bob Bissell, British Telecom)
Key Metrics
Packet Loss
A Video Headend Office(Core) D Access Network Packet delay
PCR Jitter
B Video Hub Office E Residential Gateway Channel Change Delay
DRM Key Arrival
C Video Serving Office(Metro) F STB
13
Timing in IPTV Delivery

Encoder -1

Packet Network

IPTV STB
Encoder -2 Server(s) Core Metro Access Home

Encoder -n

DRM

Billing

Ad server

All
elements in IPTV delivery system need to be synchronized
Synchronization granularity varies
However, synchronization implementation must support high transaction volumes and availability 14
Timing In IPTV Deployment

Timing
Timing
Distribution Purpose Where
Parameter
Protocol

- BITS Signals - C.O.

Network
Transport - Frequency - Packet Based Synchronization - Access Network
Protocols PON, DSLAM, etc.

- Service
Management
- Video Headend
- Time of Day - NTP - DRM, Program
Management - Video Serving Office
- Time Stamps - NTP Guide
- CO
- QoS
Measurement

- Video Headend
- Time Stamps - NTP - Video encoding - Video Serving Office /
Application
- Time of day - NTP - Ad insertion CO
- STB / Res. Gateway

15
IPTV Timing Solution

Timing implementation depends on

Middleware implementation and features

STB Specifics

Network architecture

Standards
Effort underway ATIS IIF, ITU FG IPTV

Engineered solution for each Implementation

16
IPTV Timing Solution Key Requirements

Scalability Availability
Network Accuracy and
Precision
Capacity
Implementation
Peak Conditions Architecture

IPTV
Timing and Synchronization
Solution

Reliability Security
System Uptime Secure Time
Failover recovery Trusted Time

17
IPTV Standards Efforts

ITU FG IPTV

ATIS IPTV Interoperability Forum(IIF)

Primary standards development organization
Service Provider Focus

IEEE/IETF

18
Key Provisions in ATIS IIF Standard
Publications
ATIS is Association of Telecom Industry Solutions.
North American Telecom Standards Body. Represents North America in ITU
Appointed lead standards body by GSC
ITU FG IPTV following ATIS IIF

Requirements
Common stable frequency reference traceable to national frequency standards required
for delivering content from different sources
Stable time reference required for service aspects such as DRM, billing, ad insertion
The IPTV security solution to provide mechanisms to support secure accurate time on the
IPTV Receiving Device
QoS Metrics Measurement e.g. one way delay

Implementation
Time and frequency reference needs to be provided to the IPTV Terminal and the headend
Non service affecting provisioning of Time and frequency distribution, particularly in the
last mile

Areas of Further Work

Ensuring MPEG Timing Model in high jitter environment
Accuracy and precision specifications for various functions

References : ATIS 0800002, ATIS 0800001, ATIS IIF WT-004

19
Symmetricom Leadership in IPTV Timing
and Synchronization Requirements
Developing Fundamental Technology to address
requirements

Testing at Symmetricom NGN Lab and with operators/

vendors

Development of recommended practices in collaboration

with IPTV infrastructure and middleware vendors

Standards
ATIS IPTV Interoperability Forum
Co-chair, Quality of Service Metrics Task Force
Working with the industry(service providers and vendors) to define
Timing and Synchronization standards for IPTV

20
 Thank You
Contacts
Vandana Upadhyay,Vupadhyay@symmetricom.com
Phil Mann, Pmann@symmetricom.com