FASTWEB: experiences on Video

over IP

Andrea Lasagna 27 Maggio 2008 PFI Pisa

PG. 2

Agenda

g Fastweb IPTV architecture

g Protocols and network problems

g Video quality of experience

g Closing and summary

PG. 3

FastwebTV, a new way of watching TVFastwebTV, a new way of watching TV

Service Innovation: FastwebTV

… it’s a Gaming Console… it’s a programme guide

… it’s a PVR

… it’s a FAX

… it’s a videoteque

… it’s DTT… it’s Home Cinema… it’s voice mail

…it’s FastwebTV!

… it’s satellite TV with no dish!

… it’s a PC

PG. 4

IPTV building blocks

VideoServers (CDN, DRM)

FTTH

xDSL

STB

DWDM/SDH

FTP

PHYSICALSUPPORT

ANTENNAS

HeadEnd

AM

CDN

CDSCM

Core Backbone

PG. 5

Fastweb Network in figures

Milano

Tokyo

21500 Km

New York

Los Angeles

Milano

Tokyo

21500 Km

New York

Los Angeles

25.000 km

4 billion euros invested since 1999 50% population directly covered 180 local areas

10.000.000 home passed 1000 Local Switches with LLU 25.000 km network

PG. 6

Access Network Home / OfficeCore NetworkServices

IP Core Network

FTTH

xDSL ULL / WS

WI-MAX ?

GSM / UMTS

agnostic towards...

Data, Voice and Video

These advantages allow:

Easy creation of new services with guaranteed QoS

Simplified operations Strong competitive edge

FASTWEB infrastructure:

Fully IP easy addition of new access technologies

Fully owned total freedom in driving evolution

Service-Agnostic Access & Core Technologies

PG. 7

Long Distance

PoP

FASTWEB Network Topology

Metropolitan Network AccessNational IPNetwork

Large Business Access

Bank Headquarter

FTTx Access

Medium Enterprise

Family

xDSL Access

Family

FamilyInterconnection

at local level

OLO Network

TI Network

Central Office

Medium Enterprise

Metropolitan PoP

PG. 8

GR

FOPCPR MORE

AL

NO

BG

TO

BO

GE

RM

NA

MI

FIBA

RE

VRBG

GR

FOPCPR MORE

AL

NO

BG

TO

BO

GE

RM

NA

MI

BA

RE

PD

Customer CPE

Access

B/Bone

Customer CPE

Access

B/Bone

QoS enforcement: end-to-end requirement

Best Effort

Data Hi

Voice

Video

In a packet network, different traffic components compete for shared communication resourcesEach communication trunk and network element contributes to determine the overall quality level of services offered to the Customer baseQoS enforcement policies must be implemented in both the Backbone and Access Layers

PG. 9

GR

FOPCPR MORE

AL

NO

BG

TO

BO

GE

RM

NA

MI

FIBA

RE

VRBG

GR

FOPCPR MORE

AL

NO

BG

TO

BO

GE

RM

NA

MI

BA

RE

PD

Customer CPE

Access

B/Bone

Customer CPE

Access

B/Bone

QoS enforcement: end-to-end requirement

Best Effort

Data Hi

Voice

Video

Traffic Classification at the Edge (source)Traffic Marking

IP (TOS Byte)Ethernet (Tag Control Info)MPLS (EXP Bits)ATM (CLP Bit, ATM Class)

Forwarding classes IdentificationTraffic Matching

Per Hop Behavior EnforcementCongestion Avoidance/Congestion ManagementMarking mantenance, extension, modification

PG. 10

Video over IP services

g Based onto multiple video distribution policiesg Video on Demand Services (Unicast)g Broadcast Video Services (Multicast)

g VoD and Broadcast Video Services based onto MPEG2 over IP streams (H.264 for HD video)

g Each stream requires 4 Mbps on average for SD videog Service elements

g Video Serversg Registration and validation of Customer accesses and service requests

g Video Pumpsg Providing video streams towards client stations

g Video Stationg Client device with extended service access and stream management capabilities

PG. 11

Mil

an

Tu

rin

Ro

me

VOD Video Pumps

VOD Video Pumps

VOD Video Pumps

Back-end Servers

National B-bone

National B-bone

Central-server Overlay MAN

Central-server Overlay MAN

POP

POP

POP

Video Broadcast Streamer

Central-server Overlay Man

Multicast Forwarding trees – TV Channels

Unicast Forwarding paths - VOD

Broadcast TV & VoD distribution

PG. 12

Streaming Farm

Fastweb MiniPoP

Residential Customers

FastwebMiniPoP

PoPPoP

Video PumpsVideo Server Video Access Request

Video Output

Residential Customers

Video Traffic

Signaling traffic

VoD services over FTTH

Video ServerRegistration and validation of the Client station (STB)

Streams activation towards client stations

Video Pumpsdistribute the video flows

Video StationSet Top Box that allows customers to play video contents

PG. 13

Streaming Farm

PoP

Video PumpsVideo Server

VoD services over DSL

Residential Customers

VOD Content

Video Access Request

PG. 14

Architecture of Broadcast TV services

Multicast ChannelsMulticast Channels

g Video MPEG2 coding Transport/Program up to 4Mbps g Around 120 Television Channels ‘broadcasted’ in the networkg Video quality with standard resolution PAL 720x576 @25

frame/secg Up to 400 Mbps simultaneous Multicast Traffic per network

link (Backbone & Access)g Contents distribution from the central-server (Milan) towards

all other MAN over the national backbone

PG. 15

Streaming Farm

Fastweb MiniPoP

Residential Customers

FastwebMiniPoP

PoPPoP

Video Pumps Video Server

Residential Customers

Video Output

Broadcast TV over FTTH

Video ServerRegistration and validation of the Client station (STB)

Streams activation towards client stations

Video Pumpsdistribute the video flows

Video StationSet Top Box that allows customers to play video contents

PG. 16

Streaming Farm

PoP

Video PumpsVideo Server

Broadcast TV over DSL

Multicast Channells

Residential Customers

Multicast Channells

Video Access Request

PG. 18

Agenda

g Fastweb IPTV architecture

g Protocols and network problems

g Video quality of experience

g Closing and summary

PG. 19

Design Multicast requirements

g Total number of multicast sources;g Total number of multicast groups;g Dislocation/distribution of multicast sources (sites);g Overall multicast bandwitdh requirement;g Maximum bandwidth per multicast group (and packet size);g Multicast group type of service (Video or transactional);g Multicast services paradigm:

g a) “One to Many” (sources distributed in few sites);g b) “Many to Many” (sources and receivers in all multicast sites)g c) “Some to Many” (different groups of sources and receivers in all

multicast sites);

PG. 20

FW IP Multicast building blocks

g IGMP(v2)g Manages receivers multicast group (channel) request in the receiver LAN

(broadcast domain)g Interface the IP L3 multicast protocol to forward the requested multicast group

in the receiver LAN

g PIM-SMg IP Multicast protocol: builds the distribution trees from the multicast sources to

the receivers that have asked for a multicast groupg The most used, robust and scalable multicast protocol deployed over operators

network

g MSDPg IP multicast protocol used to ‘find’ and exchange multicast source information in

the network

g SSMg IP multicast protocol, actually a subset of PIM-SSM, simpler, usable if multicast

source IP addresses are well known and managed

g Anycastg Technique to guarantee redundancy layering on a IP routing protocol

PG. 21

Multicast forwarding

g Forget unicast forwarding: IP Destination Address, Routing table. When forwarding unicast, the output interface is selected only

matching the incoming packet IP DA in the Routing table where one (and one only) output interface is specified.

g Multicast routing is first concerned about where the packet is coming from (RPF Check) in order to build and maintain check the multicast tree.

g RPF Check:g The routing table used for multicasting is checked against

the “source” IP address in the packet.g If the datagram arrived on the interface specified in the

routing table for the source address; then the RPF check succeeds.

g Otherwise, the RPF Check fails

PG. 22

IGMP

IGMP (v2)Very simple protocol:g Receivers: Join and Leave a multicast group: IPTV Leave Ch1,

Join Ch11g Querier: Maintain the state of the requested channel in

broadcast domain (LAN or VLAN) to cooperate with the L3 multicast protocol and ask for sources down to the LAN

g General Queries (which multicast groups are requested in this LAN?)

g Group Specific Queries

g Can be tuned to optimize perfomance (time-outs, robustness variable, number of queries before expiring a multicast group, etc)

PG. 23

PIM-SM need for a Rendezvous Point

Receiver: I ask for channel1 (multicast group 224.X.X.X)…..IP Router:…. where is the source for group 224.X.X.X?Source: I am source 224.Y.Y.Y, deliver me towards who’s asking

for me….IP Router….where are the receivers?→ A mechanism is needed to make sources and receivers

meet…A Rendezvous Point!In PIM-SM sources and receivers ‘meet’ at the Rendezvous

PointIn PIM SM deployment one or more routers have to provide RP

functionalitiesEvery router in the PIM-SM domain must know the RP!

PG. 24

PIM-SM

‘Pull-mode’ protocolMulticast trees are built from receivers up to source exploiting the Rendezvous

Point

g Shared trees (From Receivers to RP)g Source trees (From RP to sources)g Shortest path trees (From Receivers to sources)

Switch over: when a receiver receives the first multicast packet from the RP through the Shared tree, it can directly build and use the SPT (Action done by the first IP PIM router)

RPF Check: towards RP for shared trees, towards sources for SPT and Source trees

When everything is put together, traffic flows through Shortest Path Trees.SPT connects the closest router to the receiver to closest router to the sourceEach node (router) in the tree will have a:(S,G) state associated to a list of output interfaces.

PG. 25

Multicast in the access

g Ethernet boxes and IP Dslam are well designed for multicast delivery and qos. BNG as well

g ATM equipment is not…

g ATM DSLAM with IGMP Proxy and BNG with Multicast (oif mapping)

g ATM switch with Multicast enabled (IGMP Proxy)

PG. 26

Agenda

g Fastweb IPTV architecture

g Protocols and network problems

g Video quality of experience

g Closing and summary

PG. 27

IPTV QoE Engineering approach

g QoE Top Down approach:g Characterize the high

level metrics (Experience, user perspective), to define low level requirements (ie application, coding, network and transport)

g Goal: To guarantee an IPTV flow in respect of the IPTV service requirements from the Source to the end user STB

Source: DSL-FORUM TR 126

PG. 28

System end-to-end view

Define end-to-end network performance requirements to achieve target QoE

Content & Video Headend

Transport, Voice, and

CoreLocal

Content

ContentManagement

VOD /Middleware

Digital Conten

t

Internet

Voice Services

In-HomeAccess

Infrastructure

Courtesy of: Nortel, Tim Rahrer

This is where quality counts!

Need a complete end-to-end view and user needs to ensure network architecture and service success

PG. 29

QoE and IP network requirements

g A subset of user experience requirements for SD IPTV:

g Same video quality as the user is normally used to through other means of distribution (Satellite, terrestrial, cable)

g High availability and continuity of the serviceg Very low visible impairment (error) rate – how low?

g Current standards and guidelines converge to a target of one visible impairment per hour

g Channel Change time comparable to what the user is used to

PG. 30

Network and IP transport layers

g Minimum IP end-to-end bandwidth available for IPTV

g End-to-end IP Transport performance objectives for:

gPacket LossgDelaygDelay variation

g IP QoS support to handle congestion

PG. 31

Based on field experience

TV users may not complain or open a ticket for each error they notice… but they always compare

what they get through IP/DSL with traditionalbroadcasting service, and based on this may decide

whether to subscribe or confirm subscription:

gInput in the network good enough quality video

gPreserve it throughout all the IP delivery chain

PG. 32

g IPTV service is highly sensitive to packet lossg Although the impact of a single packet loss depends of

several factors such as:g Compression algorithm (MPEG2, H.264, etc.)g GOP Structureg Type of information lost (I,P,B frame, other MPEG information,

etc)g Codec performance (encoding and decoding)g Complexity of the video contentg Error concealment at the STB

g It is highly likely that a single IP packet loss produce a visible impairment to the user – Note that a single IP packet usually transports 7 188 Byte MPEG packets

IP Transport performance objectivesPacket Loss

g Packet loss has to be minimized and strictly controlled:

g Simple metrics as average Packet Loss Ratio are not enough to describe the packet loss requirement

g what matters is the loss event, its rate (MTBE) and shape (loss period and distance), not only the ratio lost_packets/received_packets.

PG. 33

IPTV IP Transport performance objectivesDelay

g The delay introduced by a well performing IP network (say up to hundreds of milliseconds for a huge geographical network) is usually negligible for the IPTV service considering that:

g Most of the delay from the live content will be added from the Head-end and video acquisition/coding/transcoding chain

g Current satellite broadcast TV service already may insert a delay up to a few seconds

g Delay in Channel Change time due to network transfer delay signalling processing (IGMP Leave/Join signalling and first packet reception of the requested channel for multicast service) is negligible (up to few tenths of milliseconds) when compared to the time needed to the STB to buffer enough video content for a smooth start for the play out .This time is usually comparable to a GOP interval which for 4 Mbps MPEG2 video streams is about half a second

PG. 34

IP Transport performance objectivesChannel change - Delay variation

gDelay Variation:gBecause of the presence of a quite large play-out/de-jitter buffer at the receiving side (STB), all potential jitter introduced by a well performing IP network is removed for a smooth play-out and virtually no packets is lost due to late arrival.

PG. 35

Agenda

g Fastweb IPTV architecture

g Protocols and network problems

g Video quality of experience

g Closing and summary

PG. 36

Internet Video challenges

g Video over internet is a big challenge

g The growing range of video services available over the Internet is already subject to congestion and contention issues

g Which type of service? Guaranteed or Best effort

g Do contents arrive from the content provider only or also from the consumers?

g Do we need Reliability ? Replication or ACK-based mechanisms ?

g Do we need QoS?

g Rate Adaption codec?

PG. 37

Summary

g Fastweb has the experience of several years of Video services over IP

g Multicast networkingg QoS and QoE measurements and reporting

g We are ready to multicast with everyone

PG. 38

E-MBGP

pim-sm

pim-sm

pim-sm pim-sm

pim-sm

pim-sm

pim-sm

pim-sm pim-sm

pim-sm

E-MBGPE-MBGP

MSDP / RP

RR

pim-sm pim-sm

SWISSCOM

I-MBGP

I-MBGP

I-MGBP

I-MGBP

MSDP

Internet

Nr001 Nr002

Ih001 Ih002

IM

Ir001

Ir005

Ir003

pim-sm

interface loopback239description MSDP/RP ip address 81.208.50.50/32

pim-sm pim-sm

PG. 39

contact: Andrea.Lasagna@fastweb.it