A P P L I C A T I O N N O T E
Assured Linear TV Delivery with TPSDA 2.0
Increasing the Quality of Experience while Optimizing Network Resources for Linear TV

Abstract
As commercial deployments of IPTV-based linear TV service reach mass market uptake, encoding
techniques become more aggressive and providers shift from Standard Definition (SD) to High Definition
(HD) linear TV. In this market, application-level functions such as video packet retransmission (RET)
and Fast Channel Change (FCC) are essential in differentiating linear TV from the competition.
The cost and performance of these functions must be optimized by leveraging distributed, networkenabled
application intelligence built within the Alcatel-Lucent Triple Play Service Delivery
Architecture (TPSDA).
The TPSDA is a purpose-built network foundation that is ideally positioned to evolve to achieve these
goals. TPSDA 2.0 is an evolutionary step for TPSDA, integrating distributed network intelligence
into existing network nodes. Assured Linear TV Delivery, one of TSPDA2.0’s solutions, addresses the
requirements of linear TV by offering a distributed and integrated solution.
This paper describes the challenges that IPTV-based linear TV faces and examines why some of the
existing solutions do not provide a scalable and cost-effective solution. It describes TPSDA 2.0’s Assured
Linear TV Delivery’s solution — a solution that addresses all of these challenges while dramatically
reducing network infrastructure costs, increasing scalability of the network, and offering a superior
viewing experience for the subscriber.

Table of contents
1 1. Introduction
2 2. Market overview and challenges with Linear TV
2 2.1 IPTV market overview
4 2.2 The need for video retransmission in IPTV Linear TV
5 2.3 The need for Fast Channel Change in IPTV Linear TV
8 2.4 Summary of challenges for IPTV Linear TV
8 3. Existing techniques to enhance IPTV Linear TV
8 3.1 Centralized Server-Based RET and FCC
9 3.2 The challenges of centralized server-based RET and FCC
12 3.3 Forward Error Correction
13 4. Alcatel-Lucent’s solution for RET and FCC
13 4.1 The case for caching Linear TV in the network
16 4.2 The approach of Assured Linear TV Delivery
17 4.3 Assured Linear TV delivery – network-enabled RET
20 4.4 Assured Linear TV Delivery – network-enabled Fast Channel Change
23 4.5 Solution Components
24 5. Assured Linear TV Delivery: Integration and evolution
24 5.1 Integration of Assured Linear TV Delivery into TPSDA
25 5.2 The Evolution of Assured Linear TV Delivery and TPSDA 2.0
25 6. Conclusion
26 7. Abbreviations
26 8. References and Sources

Assured Linear TV Delivery with TPSDA 2.0 | Application Note 1
1. Introduction
The delivery of live or real-time video entertainment is undergoing rapid evolutionary changes as
varying technologies and providers compete in this space. Cable multi-system operators (MSOs)
and traditional broadcast operators have been delivering live TV services to the market for decades.
Satellite digital TV providers have now emerged to provide a vast array of quality programming to
areas that cannot be covered by local cable companies. Internet video has also emerged as a source
of on-demand video entertainment by offering archived video clips (e.g. YouTube) as well as providing
an alternate method of delivering full length TV programming (e.g. Joost). IPTV providers are
competing globally for a share of this market by leveraging the Internet protocol (IP) and offering
IPTV while delivering their own brand of live TV — linear TV. Linear TV is also known as
broadcast TV (BTV), a pre-scheduled set of live channels that can be delivered to many viewers at
the same time.
Cable and broadcast operators have traditionally set the benchmark for a quality TV experience.
However, their broadcast technology distributes the entire set of channels to all homes (500-2000)
in the area it serves. This is very inefficient and does not interact with the client’s Set Top Box
(STB). It should be noted that many MSOs are aggressively migrating to Switched Digital Video
(SDV) which allows the STB to provide digital feedback upstream to request specific channels.
This liberates much bandwidth (BW) for the shift toward HD programming. Satellite TV providers
now offer a wide range of digital TV programming with comparable quality to the MSOs. However,
these offerings can be susceptible to deterioration during inclement weather and are essentially a
uni-directional service offering with no mechanism for per-subscriber STB interaction.
In order to compete and differentiate themselves with the emerging conglomeration of video entertainment
services, IPTV providers must ensure that their linear TV service continues to provide the
best experience available while adapting to changing business requirements and trends. IPTV providers
using TPSDA [1] have inherent advantages over their competitors that must be leveraged for
success in this competitive environment. This paper will show that IPTV linear TV delivery across
a TPSDA foundation allows for per-subscriber interaction by leveraging the existing bi-directional
communication channel between the subscriber and the network. This provides application-level
video quality assurance functions such as RET and FCC which can be network-optimized on a
per-subscriber basis.
Internet video service offerings generally provide an interactive personal experience but suffer
from a best-effort (BE) service infrastructure that cannot compete with the rich Quality of Service
(QoS)-enhanced offering of a TPSDA-based IPTV service. In fact, the Internet service definition
was not designed to carry video, especially real-time streaming video. With TPSDA, IPTV providers
increase their quality over Internet-based video offerings and continue to differentiate their service
as a superior lean-back experience.
TPSDA 2.0 [2] is a natural evolution of TPSDA and provides the distribution and integration of
network intelligence into trusted network devices. With TPSDA 2.0, IPTV providers will continue
to leverage the unique strengths of TPSDA and will further bolster them by introducing Assured
Linear TV Delivery. Assured Linear TV Delivery is a distributed and network-integrated approach for
video retransmission (RET) and fast channel change (FCC) that augments the current linear TV
service while optimizing network resources.
Assured Linear TV Delivery with T 2 PSDA 2.0 | Application Note
2. Market overview and challenges with Linear TV
This section details the market overview for IPTV and why providers must ensure that they offer a
superior linear TV experience to their consumers. RET and FCC are introduced as two functions
that allow IPTV providers to differentiate themselves and offer a superior viewing experience for
the subscriber.
2.1 IPTV market overview
There are many advantages of IPTV that have led to its large-scale global adoption. However, some
new trends are jeopardizing the Quality of Experience (QoE) that subscribers receive from IPTV.
These advantages and trends are discussed in this section.
2.1.1 IPTV momentum
IPTV is a well-established service, exceeding 12 million subscribers globally at the end of 2008 and it
represents a large growth opportunity. To continue capturing market share, operators must enhance
the IPTV viewing experience over other forms of digital TV distribution models. Compared to
Cable and Satellite, IPTV has major advantages including:
• A direct per-subscriber interaction due to the bi-directional capabilities of IPTV, which enables
advanced interactivity and personalization.
• An end-to-end IP-based infrastructure that uses every network element to deliver and enforce
policy. This provides a scalable and cost-effective network to distribute vast quantities of multicast
(MC) and unicast (UC) video. This, in turn, enables a dynamic mix of linear and on-demand
personalized TV services such as Video on Demand (VoD), Pause Live TV (PLTV), Time Shifted
TV (TSTV) and Personal Video Recording (PVR).
• An ability to interwork with mobile, communications and web service platforms to enable any
service on the TV screen and provide a natural evolutionary path to multiscreen entertainment.
• Increased upstream capacity that maintains a per-subscriber QoS context.
Compared to Internet video, IPTV is a managed service that has the advantage of delivering the
highest quality of video entertainment to the TV screen — especially essential for Pay TV services.
2.1.2 Superior IPTV-based Linear TV is needed
In order to maintain and even capture more market share by using these advanced features, operators
must ensure that their baseline IPTV service, linear TV, continues to provide the best experience
available. Linear TV offers a lineup of real-time pre-scheduled TV channels tailored for each region
in the IPTV provider’s footprint. Each TV channel is efficiently delivered from either the national
or regional video office via multicast (MC) technology. With multicast, IPTV providers efficiently
utilize their infrastructure by sending only a single copy of any channel across any given link while
replicating only to requested receivers.
IPTV providers must differentiate their linear TV service from their direct competitors: Cable MSOs
and the digital satellite providers. In addition to offering a superior QoE to their competitors, IPTV
providers must adapt to changing business trends faster than their competitors. The shift from SD
to HD TV programming coupled with more advanced encoding available with MPEG4 and H.264
will add more sensitivity to video packet loss and create longer channel change durations. As a result,
the functions RET and FCC were developed to address these new challenges to enhance the already
solid foundation of IPTV linear TV delivery. With TPSDA 2.0 these functions are integrated into
the network devices themselves to offer an optimized and cost-effective performance.
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 3
2.1.3 The Triple Play Service Delivery Architecture reference model
Over 55 IPTV providers across the world have chosen TPSDA as the blueprint to evolve their residential
services. TPSDA 2.0 is an evolution of TPSDA, representing distributed integrated application
intelligence built on TPSDA’s proven framework. The evolution of IPTV and specifically linear TV
will take shape upon TSPDA 2.0’s flexible, resilient, secure, and scalable framework.
As a reference for TPSDA 2.0, a brief overview of TPSDA is provided here. TPSDA allows the
IPTV provider to offer voice, video, and data to the home subscriber. Service delivery is based on
the Internet Protocol (IP) and uses the unicast point-to-point delivery approach to deliver voice,
high speed internet (HSI), and VOD. TPSDA uses the multicast point-to-multipoint delivery
approach to deliver linear TV.
Figure 1 illustrates the high-level framework of the TPSDA that will be referenced throughout this paper.
Figure 1. The Alcatel-Lucent Triple Play Service Delivery Architecture
The major components of the TPSDA are:
• Access – The Broadband Service Access Node (BSAN) is provided by Alcatel-Lucent’s
7302/7330/7342 Intelligent Services Access Manager (ISAM) product suite. The BSAN offers
either digital subscriber line (DSL) or fiber to the home (FTTH) in the form of passive optical
networks (PON) or Point-to-Point (P2P) fiber. The BSAN supports flexible QoS models that
enable managed QoS on a per-service, per-application, and per-subscriber basis. The BSAN
positioned as a fiber-to-the-node (FTTN) access device is illustrated in Figure 1. However, the
BSAN can also be positioned to provide service to a larger number of subscribers and be located
in the CO.
BSA
BSR BSR
BSAN
(FTTN)
Aggregation Service edge
National
video office
Regional
video office
Access
PIM/MPLS
DSL,
GPON
Serves 100000 subscribers
Up to 400000 STBs
Serves 10000 subcribers
Up to 40000 STBs
Serves 200 subcribers
Up to 800 STBs
RG
Assured Linear TV Delivery with T 4 PSDA 2.0 | Application Note
• Aggregation – The Broadband Service Aggregator (BSA) is represented by Alcatel-Lucent’s 7450
Ethernet Service Switch (ESS) and aggregates BSANs using gigabit Ethernet (GE) links. The
BSA is subscriber and service-aware and is the point in the network where hierarchical quality
of service (HQoS) and other per-subscriber policies are applied. A virtual private LAN service
(VPLS) is typically used between the BSA and the BSR pair.
• Service Edge – The Broadband Service Router (BSR) is represented by Alcatel-Lucent’s 7750
service router (SR) and aggregates BSAs using 10 GE links while terminating the VPLSs. Each
BSA is terminated by a pair of BSRs for resiliency. The BSR connects directly to the regional
video office that services that market area via 10 GE links.
• Video Office – The regional video office is where most of the IPTV centralized middleware
servers reside. This is where regional Linear TV channels and VOD streams generally originate
from. The 7750 SR is positioned in these offices as an MPLS/Protocol Independent Multicast
(PIM) router supporting national video routing.
2.2 The need for video retransmission in IPTV Linear TV
This section discusses why Real-Time Transport Protocol (RTP)-based video transmission needs a
packet retransmission mechanism and discusses how the shift from SD to HD programming makes
it even more important.
2.2.1 The general need for RET
Linear TV transmission is real-time and delay-sensitive and uses MC technology for scalable consistent
delivery. Due to these characteristics, most IPTV providers have chosen RTP instead of the Transport
Control Protocol (TCP) to transport linear TV. The challenge with TCP to deliver linear TV is
that it contains a time variable packet acknowledgement and retransmission system and relies upon
a one-to-one source-to-destination relationship. TCP’s packet acknowledgement and retransmission
system may create unwanted delay variance for real-time linear TV streaming. In addition, TCP’s
requirement of a one-to-one source-to-destination relationship is not compatible with multicast
distribution. RTP is carried over the User Datagram Protocol (UDP) which does not contain an
acknowledgement and retransmission service and thus offers a more consistent linear TV performance.
In addition, RTP over UDP is fully compatible with multicast distribution. RTP is specified
in RFC 3550 and is the linear video distribution protocol of choice for many video service providers.
Figure 2 depicts the data encapsulation
hierarchy for linear TV delivery. Linear
TV video distribution uses IP multicast
packets which are encapsulated in UDP
packets which in turn are encapsulated
in RTP protocol data units (PDUs).
Unlike TCP, the weakness of RTP is the
lack of an inherent mechanism to provide
a packet loss recovery mechanism.
Without a mechanism to recover from missing video packets the subscriber sees pixelization, macro
blocking, frame skips or temporary picture freezes. With RET, the network can recover from video
packet loss, occurring anywhere in the network, to provide a better QoE for the subscriber.
Figure 2. The data encapsulation hierarchy for linear TV delivery
• Sequence number for packet loss detection
• Time stamps for timing and synchronization
• Source identifiers to identify proper video source
IP header UDP header RTP header RTP payload
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 5
2.2.2 The need for RET in a DSL environment
DSL encoding technologies such as very high bit rate digital subscriber line (VDSL) allow large
amounts of bandwidth to be sent across a twisted copper pair. Since IPTV providers already have a
massive footprint of copper reaching most of their subscribers, many have selected this technology
for TPSDA deployments.
While advanced DSL technologies greatly reduce line errors, linear TV can still be susceptible to
noise and interference that can ultimately lead to packet loss resulting in video packet impairments.
With RET, these video packet losses can be recovered. In fact, by deploying RET, the IPTV provider
may be able to expand the reach and ultimately the footprint of the overall service offering. The
higher DSL error rates of the fringe customers can be handled by the RET function thus allowing
the IPTV provider to augment the loop lengths of their DSL network.
With RET, the IPTV provider can also address the shift of linear TV from SD to HD. With the
shift to HD and the adoption of more aggressive encoding algorithms such as MPEG4 and H.264,
linear TV channels are more sensitive to packet loss which generates more visual impairments for
the same number of packet losses. With RET, this sensitivity is handled with packet recovery.
In addition to the shift toward HD programming, there is a shift to provide linear TV to multiple
rooms in the home or a multi-room linear TV service. This dramatically increases DSL line rate
requirements and will increase DSL transmission errors. RET is a valuable tool to address this shift.
2.2.3 The need for RET in a home LAN environment
The subscriber’s home LAN is also a common source of video packet loss. Traditionally, many home
networks were based on Ethernet and provided a robust error free LAN. Today, many home LANs
for IPTV are moving toward WiFi and power line communication and are generally very susceptible
to packet loss. Because linear TV must traverse the home LAN, this is another compelling reason
for providers to deploy a RET solution.
2.3 The need for Fast Channel Change in IPTV Linear TV
Within the existing IPTV linear TV framework (without an FCC mechanism), when a subscriber
changes the channel (zapping) using the remote control, there is a 2 to 5 second delay before the
subscriber sees the new channel. This delay should be considered a service interruption. If video
providers strive to eliminate deterioration in the current TV program, it is unacceptable to have
a 2 to 5 second delay consisting of a black screen.
This interruption or delay is due in part to the latency and processing involved in the dynamic multicast
Internet Group Multicast Protocol (IGMP) join process involved with the request of a new channel.
However, this IGMP join latency is a small part of the overall delay that causes the interruption.
More significant contributors to the delay are the I-frame delay and the requirement to fill the STB’s
jitter buffer. Figure 3 uses a cumulative time axis to illustrate all the components that cause the delay
in changing a channel. Note that the most significant component of this delay is the I-frame delay
(described in more detail later). The I-frame delay is significant because it increases with the shift
from SD to HD. Another significant delay is the process of filling the STB to a required level before
decoding and displaying the new channel.
Assured Linear TV Delivery with T 6 PSDA 2.0 | Application Note
Figure 3. The components of the channel change delay
2.3.1 MPEG overview and I-frame delay
Video encoding schemes such as Moving Pictures Expert Group (MPEG) can have a very large
impact to the I-frame delay when a subscriber changes a linear TV channel. To understand this
encoding related delay it is instructive to look at the MPEG protocol in more detail.
The MPEG protocol is based on a layered hierarchy of protocol data units (PDU)s that, at the highest
level, start with a group of pictures (GOP) representing a series of video frames such as intra-coded
frames (I-frames), predictive-coded frames (P-frames), and bi-directionally-predictive coded frames
(B-frames). Each GOP contains only a single I-frame and as these video frames are encapsulated
and transmitted in groups defined by the GOP, the I-frame will be transmitted only once for every
GOP. At lower layers, each video frame is divided into slices, then macroblocks, and finally, the
smallest coding unit within the MPEG standard, the block. Figure 4 depicts these relationships.
Figure 4. The MPEG layered PDUs
An I-frame is a compressed version of a single uncompressed (raw) frame and unlike P-frames and
B-frames, I-frames do not depend on data in the preceding or the following frames to be decoded
and displayed. An I-frame is also considered a reference frame to a P or a B frame. P-frames are
generated using data in the previous reference I or P frame. A P-frame is considered a reference
frame to a B-frame. B-frames are generated using data in both the previous and following reference
frames (I or P). Therefore, B-frames offer the most compression and the smallest size.
When these frames arrive at the STB’s decoder function, the I-frame is the only frame that can
be decoded into an image while not relying on any other frame. The B and P frames depend upon
other frames in order to be decoded and presented as an image to the TV. For this reason, an STB
Decoding and rendering
Waiting for I-frame to arrive
STB buffer filling
Largest contributor
to channel change time
DSL interleaving
IGMP processing in aggregation node
IGMP processing in access node
Aggregated time
Event
STB processing of user request,
sending IGMP leave and IGMP join
I
I
B B P
Group of pictures (GOP)
Pictures
Slice
Macroblock
Block
B B
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 7
client cannot present a picture and initiate the video stream of a new channel on the TV until it
receives and decodes an I-frame first. This creates a source of variable delay to channel changing
because it is unpredictable where an I-frame will first appear in the linear TV video flow.
The size of the GOP is a configurable parameter on an MPEG encoder. The larger the GOP the
more efficient the video encoding is in terms of required bandwidth since the larger I-frames will
be transmitted less often. However, larger GOPs mean longer intervals between I-frames resulting
in longer channel change times. The chart in figure 5 illustrates the relationship between GOP size
(measured in seconds) and bit rate (Mb/s) for an SD and HD stream, when using MPEG4 encoding.
Figure 5. GOP size versus Bit Rate
It is clear from this chart that as the GOP size increases, the bandwidth required to transmit an SD
or HD stream is substantially decreased. This phenomenon is even more apparent for HD streams.
This is an important consideration for an IPTV provider because bandwidth constraints in the first
mile can be severe. This drives most providers to use the most efficient encoding as possible thus
increasing the GOP size, decreasing the bandwidth consumption and, increasing the average channel
change times.
As linear TV transitions to HD and encoding techniques try to transmit more content over less
BW, the average channel change times are increasing. An FCC function will not only allow IPTV
providers to offer a faster channel change but the provider can also eliminate the sensitivity of
channel change durations as encoding techniques change.
2.3.2 Decoder buffer delay
For IPTV, each STB is equipped with a buffer to smooth out jitter from the network and to ensure
the proper ordering of packets. Jitter exists because the encoding process generates a variable bit
rate stream and there is variable delay introduced in the network. It is necessary to use the buffer to
order packets because the order in which pictures are decoded differs from the order in which they
are displayed.
2.4 Summary of challenges for IPTV Linear TV
Figure 6 summarizes the challenges that linear TV faces in the absence of a mechanism to add
application-level functions such as RET and FCC.
Stream bandwidth (Mb/s)
HD
0.5 1.0
GOP size seconds
1.5 2.0
3.45
3 2.86 2.78
8.01
7
9
8
7
6
5
4
3
2
1
0
SD
6.64 6.46
Assured Linear TV Delivery with T 8 PSDA 2.0 | Application Note
Figure 6. Challenges for Linear TV without RET and FCC
Without a mechanism to recover from video packets losses, the quality of linear TV cannot be
assured. DSL and Home LANs are prone to video packet loss and these losses deep in the network
can impact thousands of STB clients. Without a mechanism to provide a faster channel change, users
suffer a service interruption when changing channels. This length of service interruption will be
unacceptable to many viewers who have other choices for spending their video entertainment dollar.
3. Existing techniques to enhance IPTV Linear TV
There are only a few existing approaches that address the requirement of a faster channel change
and video packet recovery for linear TV. The first is based on a client-server model where the server
is located in a centralized location driven by IPTV middleware such as Microsoft (MS) Mediaroom.
Another approach that addresses video packet recovery is application Forward Error Correction (FEC).
This approach uses a companion stream of repair data that can be used by the STB client to repair
lost packets. This section will discuss both approaches along with their respective challenges.
3.1 Centralized Server-Based RET and FCC
The centralized approach for RET and FCC require a set of servers centrally located in a video
office attached to switches or routers to offer these functions. These servers respond to RET/FCC
requests from STB clients. The operation of these servers is discussed in this section.
BSA
BSR BSR
BSAN
Aggregation Service edge
National
video office
Regional
video office
Access
DSL PIM/MPLS
• The multicast (MC) protocol inherently
offers a slow channel change
• The duration of a channel change can
be considered a service interruption
• Channel change duration is longer as
linear TV transitions to HD and MPEG4
• Noise in the home LAN and DSL causes video errors
• Video packet loss deep in the network impacts 10s of thousands
of subscribers
• Since video is UDP-based there is no inherent mechanism
for re-transmission
• Linear TV with MPEG4 and HD is more sensitive to packet loss
STB buffer
... Linear TV
MC source
Video stream delivered efficiently via multicast
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 9
3.1.1 Centralized server-based RET
The RET requirement can be addressed through the deployment of centralized servers to offer an
application-level ability to compensate for video packet loss in a DSL or home LAN environment.
In addition, this function compensates for video packet loss anywhere in the network beyond the
home LAN or DSL. Although deep network errors occur less often than on the DSL or in the
home LAN, they may have a more significant impact to the service because they affect many
more STB clients.
Centralized RET operates in a client-server model where the subscriber’s STB is the client and an
upstream centralized server acts as its server. The STB client uses its own buffer to cache video
packets that it will eventually decode and stream to the TV. The RET function starts when the
STB’s buffer detects lost video packets and its client software issues a UC RET retransmission request
upstream to the server. The server has cached video content from each channel and responds
to the RET retransmission request by re-sending these lost packets. Once the STB receives these
requested video packets, it stitches them back into its buffer before they are needed by the decoder.
3.1.2 Centralized server-based FCC
Similar to RET, centralized FCC can be addressed by deploying centralized servers to offer an
application-level ability to provide faster channel changes. This function operates within a clientserver
model where the client is represented by the subscriber’s STB.
Centralized FCC takes advantage of a centralized server that caches at least an entire GOP of video
frames for each linear TV channel within its circular buffer. When the subscriber changes a channel,
the STB client requests the new channel from the FCC server. The FCC server responds by sending
a UC burst of video packets of the requested channel downstream to the subscriber’s STB client,
starting with an I-frame. Sending an I-frame first allows the STB to immediately decode and stream
the video to the TV. This burst allows the UC content to “catch-up” to the actual multicast stream
as it fills the STB buffer. At the point where the unicast content has caught up with the desired
multicast stream, the video packets join the multicast stream and the UC burst is terminated. Centralized
FCC allows the subscriber to experience a faster channel change (zapping) and reduces a
channel change time to below 0.5s.
3.2 The challenges of centralized server-based RET and FCC
Centralized RET and FCC have functioned in operational networks but there are challenges to
delivering them in a cost-effective and scalable manner within the framework of the provider’s
network; challenges in network scaling, performance and operations.
3.2.1 Network scaling challenges of centralized server-based RET and FCC
Because RET/FCC use a UC delivery mechanism, they do not benefit from the efficiencies reaped
from multicast transmission. Multicast scales per TV channel while UC scales per active STB. As
a result, RET and FCC consume a huge amount of downstream bandwidth. Since these are centralized
functions, all this downstream traffic must traverse several shared links before it reaches the
destination STB.
To demonstrate the magnitude of this consumption, Alcatel-Lucent performed an internal analysis
to demonstrate the significance of RET/FCC in its consumption of downstream bandwidth. This
analysis is based on the subscriber and STB scale illustrated Figure 1, and uses traffic data that was
modeled for RET/FCC at various locations in a TPSDA. Figure 7 illustrates the increase in downstream
bandwidth needed for RET/FCC from the specified location.
Assured Linear TV Delivery with T 10 PSDA 2.0 | Application Note
Figure 7 illustrates the traffic generated
by centralized RET/FCC from key
locations within TPSDA. The chart
shows that RET/FCC traffic leaving
the BSAN (serving 200 subscribers)
amounts to 31 Mb/s. Deeper into the
network this number grows substantially
to 1.587 Gb/s on downstream
traffic coming from the BSA and to
15.870 Gb/s on downstream traffic
coming from the BSR. In the
case of a full scale VHO supporting
1,000,000 subscriber, the projected
downstream traffic required for
RET/FCC is over 158 Gb/s! Moreover,
as providers continue to shift
from SD to HD channels, the BW
requirements becomes even larger.
The centralized RET/FCC has significantly more impact on the network the deeper it lies in the
network. This is a clear indication of the merits of de-centralizing and distributing this function.
Figure 8 shows the relative bandwidth
requirements for each of
the services downstream from the
regional video office. As illustrated,
centralized RET/FCC consumes
over 28% of the total downstream
BW leaving the regional video office.
To put this in perspective, the
downstream bandwidth from RET/
FCC at this point in the network is
almost 70 times the size of the entire
linear TV lineup! This bandwidth
requirement becomes even more
taxing as the shift from SD to HD
linear programming continues. It is
also ironic to note that the network
cost of delivering revenue-generating
linear TV is a fraction of the cost
needed to service it using centralized
RET and FCC.
Figure 7. Downstream BW requirements for centralized RET/FCC
Mb/s
BSAN
RET FCC downstream BW from location
TPSDA location
BSA BSR VHO
31
40000
60000
20000
0
100000
120000
180000
160000
140000
80000
1587
15870
158707
Figure 8. Downstream BW requirements of UC services to the BSR
Gb/s
Linear TV FCC/RET VoD HSI VoIP
.3% 2%
8%
22%
Downstream BW from regional video office
Service
100
0
300
400
500
200
67%
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 11
Another component of network scaling that centralized RET/FCC restricts is the scaling of the regional
video office. A massive amount of router/switch ports are required in the regional video office
to support the RET/FCC requirements. This translates to poor scalability.
3.2.2 Performance challenges of centralized server-based RET and FCC
In addition to massive infrastructure costs to maintain and scale this centralized model for RET/FCC,
the following performance challenges exist:
• Latency – Centralized RET and FCC functions may incur latency issues as more hops must be
traversed to reach the ultimate destination: The client STB.
• RET Storms – Centralized servers in the network used for RET will magnify video losses that
occur deep in the network. This is because many STB clients will request a retransmission of the
same video packet losses. This results in UC retransmissions (originating centrally) to a massive
number of STB clients. This scenario may not scale very well and could exacerbate the original
problem.
• RET Request (NACK) Storms – Centralized servers must be able to withstand retransmission
requests from a massive number of STB clients caused by losses deep in the network.
• FCC Storms – Similar to retransmission storms, FCC storms can occur when a massive number
of subscribers change channels at the same time. This phenomenon can take place during very
popular linear TV events such as The Super Bowl during commercial breaks. The network bandwidth
demand can dramatically spike during these events and can possibly outstrip the capacity
of the network.
3.2.3 Operational challenges of Centralized Server-Based RET and FCC
The following operational challenges exist with a centralized RET/FCC solution:
• Maintenance and Operations – A pool of centralized servers require regular operational maintenance,
monitoring, and upkeep including additional rack space, powering, and cooling considerations.
Moving servers closer to the subscriber (for example distributing to the Central Offices) may
help to reduce network infrastructure costs but may actually increase the operational costs. It
may be more difficult to maintain a vast distributed set of servers in locations that are not staffed
for such activities. Network Equipment Building System (NEBS) compliancy issues can also add
complexity and cost to these servers.
• Targeting of STB clients – Centralized servers servicing a geographically distributed set of STB
clients can create scaling issues as well as complicate the design. For example, each server may
need to service all STB clients; this is a design that scales poorly. For this reason, the pool of
centralized servers may have to partition themselves and load-share geographically across the
STB clients, which adds complexity to the model.
Figure 9 summarizes the overall challenges that centralized RET and FCC functions face. Alcatel-
Lucent’s Assured Linear TV Delivery overcomes these challenges and allows IPTV providers to continue
to offer a superior quality linear TV viewing experience in a scalable and cost effective manner.
Assured Linear TV Delivery with T 12 PSDA 2.0 | Application Note
Figure 9. Summary of challenges for Centralized RET and FCC
3.3 Forward Error Correction
FEC is used as a link-level mechanism that adds redundant bits at one end of a link that can be used
to repair bit errors at the other end. Although this mechanism can be effective in certain instances,
it is limited to link-level error repairs only because it is agnostic to the applications, such as video,
that flow through the link. In addition, bandwidth overhead is a constant cost for FEC; to increase
FEC’s performance, more constant overhead is needed. Application FEC improves upon Link FEC
because it addresses the video stream directly by adding a FEC repair stream for various blocks of video
traffic. However, a constant amount of bandwidth overhead is still needed for this function to work.
Application FEC lacks the ability to target each subscriber’s packet loss condition independently.
In contrast, RET repairs specific video errors that are detected and requested by each STB client.
Retransmissions are requested on a per-subscriber basis only when needed so there is no wasted
bandwidth overhead.
Figure 10 summarizes and contrasts Link FEC, Application FEC and RET.
Aggregation
Service edge
National
video office
Regional
video office
Centralized FCC/
RET servers
Access
DSL PIM/MPLS
Inconsistent FCC/RET
performance to the
subscriber
Very large network costs on
shared network links centralized
unicast FCC/RET does not scale
Scale of VHO is limited
due to centralized
server requirements
Distributing servers may help with network
efficiency but has same or larger
operational requirements
Possible re-transmission and
re-transmission request storms for
video errors deep in the network
Cost, maintenance, space,
powering and cooling of servers that
must scale linearly with subscribers
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 13
Figure 10. Forward Error Correction techniques compared with Centralized RET
4. Alcatel-Lucent’s solution for RET and FCC
One of the hallmarks of TPSDA is its stability and quality. These attributes are required for a streaming
linear TV service that is expected to be “always-on”. This type of service cannot tolerate unpredictable
network outages which result in a user perception of poor service quality and increased customer churn.
Within TPSDA 2.0, Alcatel-Lucent’s Assured Linear TV Delivery solution operates by distributing the
RET and FCC server functionality and integrating it into existing network devices while also caching
content. This solution dramatically improves network scale and performance, and simplifies operations
and maintenance.
4.1 The case for caching Linear TV in the network
As a precursor to introducing Alcatel-Lucent’s solution for RET and FCC, this section outlines why
it makes sense to deploy a distributed network cache in support of the RET and FCC functions.
4.1.1 Cache effectiveness
Alcatel-Lucent has studied the characteristics of various types of traffic (RET, FCC, PLTV, Internet
web surfing, network PVR, VOD, and broadband VOD) to understand the best delivery and caching
methods [3, 4].
One of the starting points for understanding this traffic is to understand cache effectiveness or hit
rate (HR). HR is defined as the percentage of requests likely to be served from a cache. Figure 11
summarizes the various services and the key characteristics that impact their cache effectiveness.
Linear TV cache effectiveness can be modeled by a Zipf distribution. This is simply C/k∝ where
k is the ranking of channels, ∝ represents the steepness of the curve, and C is a constant which
depends on ∝ and the number of objects that represent that service (e.g. number of channels).
Adds redundant bits at one end of
the link that are used to repair the
original bit stream at the other end
How? Adds a stream of repair data
MUXed in with the video streams
RET control channel requests specific
video frames to be submitted
Repairs link-level errors only.
Network level events are not
handled. No end-to-end protection
What does it fix? Repairs video at the application
level but not on a per-subscriber
basis
Repairs all video errors at the application
level per subscriber independent of cause.
End-to-end protection
Requires external transceiver with
FEC capability device at far end of
link and at associated STB
What is needed? Requires an FEC encoder and MUX
at the video source and a FEC
DEMUX decoder at the STB
RET server/cache in the network
and STB RET client in the STB
Bandwidth overhead is increased
to augment performance
Bandwidth overhead is a constant
cost even when no errors are
occurring
Performance? Large bandwidth overhead (up to 20%)
is increased to augment performance
Bandwidth overhead is a constant
cost even when no errors are occurring
Re-transmissions are requested only
when needed
Link FEC Application FEC RET
Assured Linear TV Delivery with T 14 PSDA 2.0 | Application Note
Figure 11. Characteristics of cache effectiveness for various services
While Zipf successfully describes linear TV as well as Internet web surfing, it does not model other
services such as video rentals (from IPTV or broadband VOD) and peer to peer (P2P) downloads
very well. This is primarily because subscribers have a disincentive to pay for video rentals and
download content via P2P. Therefore, they tend not to browse this content. In contrast, linear
TV, FCC/RET or Internet web browsers have a tendency to create more of a browse behavior. The
“watch get once” services are better modeled by a modified Zipf function called the Zipf-Mandelbrot
function which is represented by the function C/(k+q)∝. This function adds a shift factor q which
accounts for the “watch get once” behavior of these services.
The other factor impacting cache effectiveness is the total number of objects to choose from. As the
number of objects increases (e.g. number of channels, number of VOD titles) the caching effectiveness
decreases and the ensuing cache effectiveness curve for that service becomes less steep. For example,
RET/FCC has a small number of objects (400 channels max) and represents content with a high
propensity to be accessed often (browsing). In contrast, Broadband VOD has a massive number of
objects (20,000) and each object is generally viewed only once.
When the cache effectiveness of these services is plotted (see Figure 12), it illustrates that linear TV
and RET/FCC have the steepest curve and represent the most effective service in terms of caching.
Due to the relatively small number of objects (channels) and the propensity of people to view the
most popular ones often, it is very beneficial to deploy a network cache for linear TV and RET/FCC.
P2P files
WWW
zipf ZM
BB/NF VoD
NPVR
FCC
Browse Decreasing HR
Watch/get
once (wgo)
Small/medium
# objects
Large
Decreasing
Decreasing
PLTV
VoD
Decreasing cache HR
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 15
Figure 12. The cache effectiveness curves for various services
The cache effectiveness was expanded to include an overall economic attractiveness to cache content
from various services. This attractiveness is based on the cache effectiveness as well as factors like
traffic consumption and memory requirements and is called cachability. The results of this analysis
show that RET/FCC is much more cachable than the other services.
Typically, the general strategy when caching content from various services is to cache the most
popular objects closest to the subscriber because these objects are requested most often. This results
in the largest network infrastructure savings leading to the largest ROI for the cache. Other less
popular objects are stored deeper into the network to form a hierarchy of caches.
A RET/FCC solution, requires a very small amount of memory in the cache. Unlike VOD, RET/FCC
caches a maximum of a few GOPs from each linear TV channel and thus the overall memory requirement
is not large. This fact, coupled with the relatively small number of objects (e.g. 400 channels),
makes the memory component of caching the entire lineup at each cache location relatively inexpensive.
This is the general approach of Assured Linear TV Delivery.
4.1.2 Reduction in memory cost
Linear TV content and RET/FCC are very conducive to being cached in the network. However, there
are memory costs associated with caching in the network that must be offset by the savings in network
infrastructure costs. By caching in the network, the IPTV provider is trading transport dollars
with memory storage dollars. Two memory types were looked at in this analysis. NAND (not AND),
a type of non-volatile flash memory and Dynamic Random Access Memory (DRAM), a type of
random access memory.
Alcatel-Lucent estimates that network transport costs could be reduced by as much as 11% per year.
Figure 13 displays the price erosion of memory using the cost of storage of an SD and HD title from
2003 to 2011. The cost to store an HD title in 2008 in NAND decreased 55% in 2009. This figure
shows a similar trend for each year up to 2011. These results illustrate that the reduction in memory
costs happens at a much faster rate than of the reduction of transport costs. Therefore, trading
transport dollars for memory dollars is a compelling option.
Probability (%)
LP/FCC/PLTV
0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48
100.0
10.0
0.1
1.0
0
-0.1
NPVR 50K VoD 5K
Zipf-Mandelbrot PMF (linear-linear scale)
Broadband VoD 20K
Assured Linear TV Delivery with T 16 PSDA 2.0 | Application Note
Figure 13. Memory price erosion
4.2 The approach of Assured Linear TV Delivery
Assured Linear TV Delivery replaces or compliments the centralized server-based model with an
intelligent network-optimized hierarchical model; a model in which RET and FCC functions are
de-centralized and integrated into the network devices themselves while distributing them closer
to the STB clients. This distributed model scales much more effectively because the RET/FCC
functions are brought closer to the STB clients. This effectively reduces the amount of downstream
UC bandwidth requirements creating significant cost savings and improved performance while
simplifying operations.
Alcatel-Lucent leads the effort to complete a standard within the Internet Engineering Task Force
(IETF) as well as the digital video broadband (DVB) organization that specifies the underlying
mechanisms used for Assured Linear TV Delivery within the context of the IPTV standard. Several
IETF RFPs and Internet drafts are being used to standardize the mechanism. At the core of this standard
is RFC 3550 which defines the
real-time transport protocol (RTP)
and the real-time transport control
protocol (RTCP). Note that in the
emerging standards for RET and FCC,
RTP and RTCP as defined by RFC
3550 are extended to accommodate
requests per RFC 4585 and RFC 4588
as well as several other Internet drafts.
Figure 14 illustrates the general
relationship between receivers (STB
clients) and servers using RTCP
as the control channel. This is a
standardized approach to providing
upstream feedback to the video
source and is the foundation for RET
and FCC requests. RTP is used to
$/Gb
DRAM
2003
Source: Objective Analysis, August 2007
2900 HD
720 SD
265 HD
66 SD
80 HD
20 SD
24 HD
6 SD
2004 2005 2006 2007
Price erosion for Flash (NAND) and DRAM memory
(storage cost per HD and SD movie)
2008 2009 2010 2011
1000
100
10
0
NAND
Figure 14. RTP and the RTCP control channel
RTCP RTCP
RTCP RTP
RTCP: to send RD/FCC
requests to the server
Video
receiver
Video source
sender
RTP: to send primary
video via IP MC
RTP: to send lost packets
for RD requests and
unicast bursts for
FCC requests
RTCP: to send sender
reports to receivers
Video
receiver
Network
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 17
stream the linear channels while the RTCP represents the control channel used by the client STB
to make RET and FCC requests to the server. In the case of Assured Linear TV Delivery, the server
function is distributed and integrated into the various network devices such as the BSAN, the BSA,
and the BSR.
The basic RTCP/RTP mechanism for network-enabled RET is straightforward. Based on packet
sequence numbers in the RTP header, the video receiver or STB client detects missing video packets
from its buffer. The STB client then sends an upstream RTCP retransmission request for these missing
packets. The network-enabled RET server function receives these RCTP retransmission requests
and sends a retransmission of these missing packets to the STB client. Network-enabled FCC works
in a similar fashion; an RTCP channel change request is made to a network-enabled FCC server
function that handles the request by sending a UC burst of RTP packets of the new channel.
4.3 Assured Linear TV delivery – network-enabled RET
There are several approaches to implement network-enabled RET into the network. These approaches
depend upon factors unique to each provider, such as network topology, subscriber density, cache optimization,
video loss profile, and access technology used. In many cases, the best approach is an initial
deployment of a single-stage solution; integrating the RET function only at one location such as the
BSR, the BSA, or BSAN to serve a given population of STB clients. In other cases, a multi-stage intelligent
hierarchy can be deployed where the RET function is deployed in two or more locations which
further maximizes network efficiency. It is important to note that with Assured Linear TV Delivery
“one size does not fit all” and the solution offers flexibility to adapt to each provider’s unique case.
4.3.3 The single-stage solution for network – enabled RET
The simplest approach to deploy network-enabled RET is as a single-stage solution. In this case,
the RET server function is integrated into only one of the network components such as the BSR,
the BSA, or the BSAN. The RET mechanism involved in the single-stage approach is triggered
when the STB client detects packet loss in its buffer before the packets are needed for decoding.
The STB client sends an RTCP RET request for the lost video packets upstream to the RET server
function (on the BSAN, BSA, or BSR). The RET server, having stored RTP video packets from
each of the linear TV channels that have been streamed to it, retransmits these RTP packets
via UC to the STB client. The STB then stitches these recovered packets into its buffer before
decoding them.
There are various locations where the integrated RET server function can be deployed in a singlestage
solution and this decision may be different for each provider.
• Deploying at the BSAN – covers the section of the network that is the most prone to video packet
loss. However, the solution may not cover all channels and does not address video packet loss
deeper in the network.
• Deploying at the BSA –will generally provide a RET function for all channels. This may be more
economical than deploying at the BSAN, but the solution may still be susceptible to video packet
loss deeper in the network.
• Deploying at the BSR – offers RET coverage for most of the network at a relatively lower cost
than the other options. However, as a server is located deeper in the network it suffers more
from the inefficiencies of a centralized approach.
A multi-stage approach can eliminate the disadvantages of various single-stage approaches and
enjoy all of the advantages.
Network-enabled RET can also compliment existing centralized server environments that support a
standardized approach for RET. A subset of existing centralized servers can provide a RET safety-net
to protect against deep video packet loss while still benefiting from distributing the RET function
into the network.
Assured Linear TV Delivery with T 18 PSDA 2.0 | Application Note
4.3.4 The multi-stage solution – an intelligent hierarchy for network-enabled RET
A fully deployed intelligent hierarchy for RET within a TPSDA network offers the ultimate in network
efficiency and performance. Many single-stage solutions can be augmented to a multi-stage hierarchy
by deploying another RET location closer to the subscriber. The following section discusses the operation
of a hierarchy that includes four stages (BSAN, BSA, BSR, and SR in the video office) of networkenabled
RET. However, the principles are the same for a smaller number of stages.
To provide optimal coverage of video packet loss, the RET server function is distributed in a hierarchy
to the BSAN, the BSA, the BSR, and the 7750 SR in the regional video office. The RET
function must exist deep in the network because video loss can occur on any link and it requires
an upstream function (relative to where the loss occurred) to retransmit lost video packets. In cases
where the provider has already deployed a centralized RET solution in the video office, the RET
function can still be distributed via integration in the BSR, BSA, and BSAN, provided that the
servers support the DVB/IETF standard for RET.
Implementing RET in a distributed hierarchy allows the provider to maintain a “lighter” centralized
function while distributing RET throughout the network to handle video packet loss in various
locations. Figure 15 depicts the evolution of RET as a network-enabled intelligent hierarchy. In this
diagram, we assume that for each subscriber there are 1 to 4 STBs. As the figure illustrates, video
loss between the BSAN and the BSA (second mile) only impacts up to 800 STB clients. However,
video loss between the BSA and the BSR (third mile) impacts up to 40,000 STB clients. The loss is
even higher between the BSR and the regional video office (fourth mile) as video loss here impacts
up to 400,000 STB clients. Under the existing centralized RET approach, a loss in the fourth mile
could precipitate up to 400,000 retransmission requests and associated retransmissions. This could
exacerbate the situation to cause RET Storms or RET Request (NACK) Storms.
To scale RET efficiently, an intelligent hierarchy is created by considering the TPSDA network as a
collection of inter-related RET zones (labeled as the first, second, third, and fourth miles in figure 15).
Figure 15. Assured Linear TV Delivery – RET in an intelligent multi-stage hierarchy
BSR 7750 SR or
centralized
server
VPLS
BSA
BSAN
DSL,
GPON
MPLS
core
Regional
video office
Integrated RET
client/server Integrated RET
client/server
Integrated RET
client/server
Packet loss in
first mile
1-4
STBs impacted
Packet loss in
second mile
200-800
STBs impacted
Packet loss in
third mile
10,000-40,000
STBs impacted
Packet loss in
fourth mile
100,000-400,000
STBs impacted
STB client initiates
RET RTCP request
Cache video content of
existing MC channels
Circular
buffer
...
Circular
buffer
...
Circular
buffer
...
Circular
buffer
...
Circular
buffer
...
Cache video content
of all MC channels
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 19
The first mile is defined as the zone between the STB RET client and the integrated RET proxy/
server on the BSAN. This zone uses RET to protect the DSL or PON line and the home LAN.
When video packet loss occurs in this zone, the STB client detects this loss in its buffer before it is
needed for decoding. The STB RET client sends an RTCP RET request for the lost video packets to
the BSAN’s integrated RET server function. The integrated RET server, having stored RTP video
packets from each of the linear TV channels that have been streamed to it, retransmits the requested
RTP-encapsulated video frames via UC.
The second mile is defined as the zone between the BSAN and the BSA and is used to protect the
GE link between these two devices. The BSAN acts as an RET client to the upstream integrated
RET client/server on the BSA. When video packet loss occurs in this zone, the BSAN’s integrated
RET client first detects this packet loss in its buffer and then sends an RTCP RET request for the
lost video packets upstream to the BSA’s integrated RET server. The integrated RET server stores
RTP video packets from all linear TV channels and retransmits these requested RTP-encapsulated
video packets to the BSAN’s RET client via UC. Once the BSAN’s integrated RET client receives
the single set of requested video packets from the BSA’s integrated RET server, it forwards them via
MC to all the STB clients impacted by this loss. Ideally, the STB clients receive these lost packets
before they need to request a retransmission.
The goal of the integrated client function coupled with the MC transmission to downstream clients
is to repair the packet loss before other downstream STB RET clients even realize they are missing.
Figure 16 provides a complete flow diagram of this hierarchical function in the second mile.
Figure 16. The reliable delivery flow of actions in the second mile
BSA integrated
STB RET client/server
client
BSAN integrated
client/server
Loss in the second mile
200-800 STBs impacted
Loss in the first mile
1-4 STBs impacted
First mile Second mile
3 – When the BSAN’s integrated RET client receives the lost frames
from the BSA’s integrated RET server it will send them down
to all impacted STB clients via MC
1 – The BSAN’s integrated RET client detects video packet
loss in the second mile and requests RTCP retransmission
upstream to the BSA’s integrated RET server
2 – The BSA’s integrated RET service provides via UC a set
of video packets that were indicated as missing from
the RTCP request
Assured Linear TV Delivery with T 20 PSDA 2.0 | Application Note
The operation of the multi-stage hierarchy for video packet loss in the third and fourth miles behaves
in a similar fashion to that of the second mile. The integrated RET clients on the BSA and
BSR issue RET requests for missing video packets upstream to the integrated RET proxy/servers on
the BSR and video head-end server, respectively. By leveraging the integrated proxy functions in
the BSA and the BSR as well as the MC functionality, the network will never have to support more
than a single set of UC RET requests and UC packet retransmissions across any single link.
A multi-stage hierarchy and proxy function eliminates a tremendous amount of RET requests
and associated video packet retransmissions. For example, in the second mile scenario, up to 800
retransmissions for lost video packets is reduced to a single retransmission in this zone. Moreover,
retransmissions in the third and fourth mile are entirely eliminated. The benefits are magnified for
video packet loss in the third and fourth miles as video packet losses in these zones impact up to
40,000 and 400,000 STB clients, respectively. This not only frees up bandwidth but offers a scalable
solution for video packet losses deeper in the network.
Figure 17 presents a summary of the potential video retransmission savings provided by Assured Linear
TV Delivery. The first numbers in each cell represent the number of re-transmission requests needed
with a centralized RET model. The second number (underlined) represents the number of re-transmission
requests needed when using Assured Linear TV Delivery in an optimized hierarchy. This
chart aggregates the retransmissions from all links in a given section of the network.
Figure 17. Reduction in re-transmission requests by using Assured Linear TV Delivery
4.4 Assured Linear TV Delivery – network-enabled Fast Channel Change
In Assured Linear TV Delivery, the centralized server function for FCC is moved from a centralized
location and integrated into the BSR, BSA, or BSAN. Although each of these locations can independently
serve FCC client requests, the most optimal scenario in terms of memory requirements
and bandwidth load may be a two-stage hierarchical deployment. In the two-stage deployment
model, the most popular channels are served on the BSAN while the less popular channels are
served from the BSA or BSR.
In the two-stage deployment model, the BSAN caches (in the form of RTP packets) at least one
GOP of video frames from each of the most popular linear TV channels. This generally incurs
limited additional downstream bandwidth because most of these linear TV channels have arrived
naturally via the dynamic multicast replication process. The BSAN can provide an FCC service to
the STBs it has cached. The BSA (or BSR) caches at least one GOP of video frames from most, if
not all, of the linear TV lineup and is ready to provide an FCC service for the less popular channels
not served by the BSAN.
# re-transmission
in first mile
# re-transmission
in second mile
# re-transmission
in third mile
# re-transmission
in fourth mile
Error in first mile 4 4 4 0 4 0 4 0
Error in second mile 800 800 800 1 800 0 800 0
Error in third mile 40k 40k 40k 50 40k 1 40k 0
Error in fourth mile 400k
# = Number of RET requests and video packet retransmissions with centralized RET
# = Number of RET requests and video packet retransmissions when using a multi-stage hierarchy under assured linear TV delivery
400k 400k 500 400k 10 400k 1
Assured Linear TV Delivery with TPSDA 2.0 | Application Note 21
This two-stage hierarchical FCC function handles the following scenarios:
• Channel change to a new channel whose content is cached on the BSAN
• Channel change to a channel served from the BSA or BSR
The following steps represent the process flow when a STB client requests a channel change to
a new channel whose content is cached on the integrated FCC function on the BSAN:
1. The STB client sends an IGMP leave message to disconnect from the current MC channel.
2. The STB client sends an RTCP request to the integrated FCC server on the BSAN for the new
channel.
3. The integrated FCC server on the BSAN streams a UC burst of RTP packets from the new
channel starting with an I-frame downstream to the STB. It is sent at a rate that is typically 10%
to 30% higher than the normal MC stream because it is sending cached content that is slightly
delayed from the regular MC stream. This higher rate allows the burst to “catch up” to the MC
stream. Because the burst starts with an I-frame, the STB can immediately decode the video
stream to display to the TV. The increased rate of the UC burst allows the STB’s decoder jitter
buffer to begin queueing video packets to the required level while catching up to the regular
MC stream.
4. The FCC server on the BSAN closely monitors the UC stream and the regular MC stream. The
server determines when the UC stream has caught up and is synchronized with the MC stream.
At that point, the UC RTP packets are set with a switch bit to instruct the STB to join the
multicast stream.
5. When the STB receives the RTP packets with the switch bit set, it requests the MC stream by
issuing an IGMP join.
6. Once the regular multicast packets are received, it is safe to turn off the UC burst and the STB
sends an RTCP request to stop the UC burst.
This flow is summarized in Figure 18.
Figure 18. The FCC process flow in Assured Linear TV Delivery
STB
BSAN
1 – The client sends an IGMP Leave to disconnect from the current channel
2 – The client sends an RTCP request for the new channel
3 – The FCC server on the BSAN responds with a UC burst of RTP packets from
the new channel x% higher than the normal MC rate starting with an I-frame.
With an I-frame, the UC stream is decoded and streamed to the TV immediately.
4 – When the UC burst catches up with the MC stream of that channel then the RTP
packets are sent with a switch bit to indicate to join the new channel
5 – The client notices the switch bit in the UC RTP packets and then sends an
IGMP join message to join the MC stream
6 – The client then sends an RTCP message to stop the UC burst
Assured Linear TV Delivery with T 22 PSDA 2.0 | Application Note
When a channel is changed to a channel served from the BSA or BSR, the process flow is identical
to the previous flow but the BSAN is replaced with the BSA or BSR.
Figure 19 illustrates the aforementioned two-stage hierarchical FCC function within the framework
of Assured Linear TV Delivery. Figure 19 also illustrates some of the BW savings that can be realized.
Figure 19. Assured Linear TV Delivery – Two-stage hierarchical FCC function
The immediate benefit with this deployment model is the significant reduction in server and
network infrastructure costs. Using this model, 15.8 Gb/s of UC downstream bandwidth is saved
between the regional video office and each of the BSR pairs. Between the BSR pair and each BSA
1.58 Gb/s is saved. There is also a reduction of downstream bandwidth between the BSA and the
BSAN. This is a significant reduction because this GE link is often oversubscribed and can be a
point of congestion.
Another benefit of this model is the reduction in operating costs and complexity. The elimination
of the FCC servers reduces the cost of the substantial server farm required to support centralized FCC.
This reduction includes server costs as well as space and power costs. This model also eliminates the
requirement to staff and train a team to monitor and maintain these centralized servers. Assured
Linear TV Delivery for FCC represents a