Unicast or Multicast for IP Video? Yes!

Unicast or Multicast for IP Video? Yes!
John Horrobin, Yoav Schreiber
Cisco Systems
Abstract
Cable operators are leading the industry
with innovative cloud-based video solutions
such as TV Everywhere and Cloud DVR.
These solutions are expected to play a
prominent role as operators aim to deliver
more content to more devices and ultimately
transition to all-IP with full-scale, managed
IP Video services. With current-generation
IPTV solutions, operators have the choice of
using unicast or multicast to deliver Linear
TV services, and multicast has proven to be
very efficient in existing IPTV deployments.
However, cloud-based video solutions
currently rely exclusively on unicast delivery,
which can have a dramatic impact on the
cable access network as the number of
subscribers served from the cloud grows.
Thus operators need to carefully consider the
network impact of migrating to cloud-based
video solutions, and look for ways to
optimize the network efficiency.
Using example use cases based on field data
and our own assumptions, we illustrate the
potential for as much as 80% savings in
CMTS capacity and HFC spectrum using
multicast delivery for real-time viewing and
in-home DVR recording. While moving the
DVR functionality to the cloud can increase
the network capacity required for time-
shifted viewing by 40% in our example, it
can also significantly decrease the control
plane traffic load on the CMTS during prime
time. Even with cDVR solutions in place, we
expect multicast will continue to be a
valuable tool for cable operators in serving
non-cDVR subscribers. Hybrid DVR
solutions can offer the best of in-home DVR
and cDVR solutions if the business case
challenges can be overcome.
Many cable operators have deployed TV
Everywhere solutions as an overlay to their
existing digital cable systems. As operators
migrate to all-IP, there are clear benefits to
using a common platform for delivering both
managed and unmanaged IP Video services
to all devices. The TV Everywhere solutions
deployed to date can serve as a foundation
for the common platform to support all IP
Video services in the future. Since these
solutions typically employ ABR streaming,
the development and deployment of multicast
ABR video transport solutions will enable
operators to leverage the benefits of
multicast as they migrate to a common
infrastructure and client for supporting all IP
Video services.
While the optimal solution for delivering full-
scale, managed IP Video services will be
unique to each operator, it will undoubtedly
involve both multicast and unicast delivery
approaches.
INTRODUCTION
Cable operators are responding to their
subscribers’ seemingly insatiable appetite for
compelling TV programming on their
schedule and platform of choice. The
proliferation of Set-top Boxes (STB’s) with
integrated Digital Video Recorder (DVR)
functionality and TV Everywhere services
are just two examples of the cable industry’s
innovations. New solutions such as cloud-
based DVR (cDVR) promise to keep the
cable industry at the forefront of the highly
competitive Service Provider market.
However, one must carefully compare the
impact of in-home and cloud-based solutions
on the network infrastructure when choosing
between these disparate approaches, and look

for ways to leverage the strengths of each
approach when deployed together.
In this paper, we will analyze the network
requirements for supporting both real-time
and time-shifted viewing of Linear TV
programming on cable access networks in
three scenarios: non-DVR STB, in-home
DVR, and cDVR. Our focus is on full-scale,
managed IP Video solutions in which all
Linear TV programming is delivered via the
DOCSIS access network; however, the
methodology and results can be applicable in
assessing network requirements for
traditional QAM-based digital video
solutions as well as hybrid QAM + IP Video
solutions.
For the purposes of this paper, Linear TV
viewing is considered to be either real-time,
or time-shifted. Real-time viewing refers to
direct playout of the programming from a
STB or other rendering device as it is
delivered across the cable network, with no
user control beyond “tuning” to the TV
channel. Time-shifted viewing refers to user-
controlled playout from an in-home or
network-based storage device, such as a STB
with DVR capability, a cDVR system, or a
cable operator’s service such as Time Warner
Cable’s Look Back® and Start Over®
services. When properly equipped, a user
may shift between real-time viewing and
time-shifted viewing of the same
programming during the broadcast window.
Also, note that time-shifted viewing may
occur during the broadcast window, or post-
broadcast.
An important distinction between real-time
and time-shifted viewing in IP Video
solutions is that programming viewed in real-
time may be delivered via unicast or
multicast, while time-shifted programming
must be delivered via unicast. Multicast
delivery can result in significant savings in
the HFC spectrum and CMTS capacity
required to support Linear TV services. We
will illustrate the savings of multicast and the
network impact of offering time-shifted
viewing options via in-home DVR and
cDVR solutions.
Analyzing the network impact of Linear TV
viewership on customer-owned-and-
maintained (COAM) devices such as
PC/laptops, tablets, game consoles, smart
TV’s and smartphones, is outside the scope
of this paper. However, we will highlight
how multicast ABR video transport can
enable operators to migrate to a common
infrastructure and client to support both
STB’s and COAM devices.
NON-DVR STB USE CASE
In this scenario, all Linear TV viewership via
STB’s is in real-time. The percentage of
STB’s that are receiving Linear TV at a
given time is referred to as the STB
concurrency. A number of factors affect
STB concurrency, including the time of day,
day of week, programming choices and
popularity, demographics, and even weather
and local events. Cable operators must
consider the impact of these and any other
relevant factors to predict the STB
concurrency in each of their cable systems.
In a recent study of field data from a cable
operator’s network (see [1]), we observed
STB concurrency in the range of 50–60%
during prime time. This is consistent with
some prior studies, and we will assume 60%
peak concurrency in our illustrative examples
below.
Another key factor in estimating the network
impact of Linear TV is the efficiency of
multicast delivery. As we explained in [1],
multicast gain is the average number of
viewers per Linear TV channel (i.e. per-
channel concurrency) within a service group
(SG). The multicast gain that can be
achieved depends on a variety of factors,
most importantly the number of viewers per

SG, the number of TV channels offered, and
the popularity of the programming. In our
examples below, we will assume a multicast
gain of 5, which is consistent with the gain
reported in [1] for service groups of
comparable size.
Table 1 provides an illustrative example of
the methodology for estimating the HFC
spectrum and CMTS downstream (DS)
channel capacity required to support
multicast delivery of Linear TV services to
STB’s. This example assumes all Linear TV
programming delivered to STB’s is encoded
as HDTV with a constant bit rate of 8 Mbps.
Based on our assumptions, a cable operator
would need to allocate 13.7 CMTS DS
channels and associated HFC spectrum for
each SG to support Linear TV services
(assuming an all-switched approach…refer to
[1] for more information on all-switched and
broadcast approaches).
Parameter Value
Homes passed per Service Group 500
Cable TV Take Rate 40%
Cable TV Subscribers per SG 200
STB’s per Subscriber 2.5
STB’s per SG 500
Linear TV STB Concurrency 60%
Linear TV Viewers per SG 300
Multicast Gain 5
Unique Linear TV Streams per SG 60
Linear TV Stream Bit Rate (Mbps) 8
CMTS DS Channel Capacity (Mbps) 35
CMTS DS Channels per SG 13.7
Table 1. Non-DVR STB Use Case
IN-HOME DVR USE CASE
According to the latest Nielsen report on TV
viewership [2], roughly 50% of TV
households have some type of DVR device.
The DVR functionality may be integrated in
the STB provided by the service provider, or
may be a stand-alone device connected to a
STB (or gateway). In either case, the DVR
records Linear TV programming received
from the network according to the
subscriber’s input.
From the cable network perspective, the
DVR recording appears as real-time
viewership. In an IPTV system utilizing IP
multicast for delivering the Linear TV
programming, the DVR client sends an
IGMP (or MLD) Join message to receive the
Linear TV program(s) the subscriber has
scheduled to be recorded. This is
indistinguishable from an IGMP/MLD Join
sent by an IPTV STB when a subscriber
“tunes” to the same Linear TV program. If
the DVR and STB are on the same DOCSIS
bonding group, they will receive the same
multicast video flow (i.e. the CMTS will
send one copy of the Linear TV program on
the DOCSIS bonding group).
If the Linear TV programming being
recorded by DVR’s is the same programming
being viewed in real-time by subscribers,
then no additional network capacity is
required to support the DVR’s. In this case,
DVR recording increases the multicast gain,
since more devices receive a given multicast
video flow. However, if the programming
being recorded is not the same as that being
viewed in real-time, then DVR recording will
increase the amount of network capacity
required to support the Linear TV services.
Although we do not have empirical evidence
on the specific programming being recorded
during prime time, our presumption is that
subscribers with DVR’s predominantly
record the popular programming that is also
viewed in real-time by subscribers without
DVR’s, and thus there is no material impact
on cable network capacity for DVR
recording during prime time.
According to a recent study on DVR usage
[3], 120% of DVR devices record Linear TV
programming during prime time. Exceeding
100% concurrency is possible since most

DVR devices are able to record multiple
programs simultaneously. This high level of
concurrency is indicative of the tendency for
DVR users to record a large volume of
content (ED: how full is your DVR?) so they
have a wide variety of recorded
programming to choose from whenever they
watch TV.
Using the DVR penetration and recording
concurrency data cited above, we can
estimate the number of DVR recordings to be
expected during prime time, and the resulting
multicast gain, in our example use case. See
Table 2 for the methodology and results.
Parameter Value
Cable TV Subscribers per SG* 200
DVR Take Rate 50%
DVR’s per SG 100
DVR Recording Concurrency 120%
DVR Recordings per SG 120
Linear TV Viewers per SG (STB’s)* 300
Linear TV Viewers + Recordings
per SG
420
Unique Linear TV Streams per SG* 60
Multicast Gain 7
Table 2. In-home DVR Use Case
*See Table 1 for derivation
Assuming the DVR’s in our example use
case are recording the same Linear TV
programming that is being viewed in real-
time by subscribers without DVR’s, the same
number of unique Linear TV streams are
required per SG as in the non-DVR STB use
case. By dividing the total number of real-
time viewers and DVR recordings by the
number of unique streams per SG, we can
calculate the multicast gain for the in-home
DVR case. As shown in Table 2, the
multicast gain is 7 when serving both STB’s
and DVR’s, which represents a 40% increase
in multicast efficiency compared to the non-
DVR STB use case. Figure 1 depicts how in-
home DVR recording increases multicast
efficiency since more end points are served
with each multicast video flow.

Figure 1: Multicast Gain with STB’s and In-Home DVR’s
Our example also illustrates the impact that
DVR recording can have on Linear TV
concurrency. If we assume all DVR’s are
separate from the STB’s, then the overall
concurrency of STB+DVR devices in the in-
home DVR use case is 70% (420 total
viewers + recordings / 600 STB’s + DVR’s),
compared to 60% in the non-DVR STB case.
If all DVR’s are integrated with the STB,
then the overall concurrency is 84% (420
total viewers + recordings / 500 STB’s).
These examples illustrate that in-home DVR
recording can be a significant contributor to
the overall Linear TV concurrency.
Although in-home DVR recording may not
impact the network capacity required for
Linear TV, it does increase the control plane
traffic (i.e. IGMP/MLD and DBC
messaging) that the CMTS must support,
particularly during prime time when a high
percentage of DVR’s are scheduled to record
at the top of the hour. Referring to our
example use case, if 10% of the Linear TV
viewers using STB’s change the channel at
the top of the hour, then the CMTS will
receive 30 IGMP/MLD Join messages
simultaneously. If half of the DVR’s that are
scheduled to record at the top of the hour
initiate a channel change, the CMTS could
receive an additional 60 IGMP/MLD Join
messages, representing a 200% increase.
Clearly the synchronized timing of channel
change requests from pre-programmed
DVR’s can dramatically increase the control
plane traffic load on the CMTS during prime
time.
CLOUD DVR USE CASE
Cloud DVR solutions move the DVR
recording and playout functions to the
network, and enable remote access from
clients on a variety of platforms. With
cDVR, all recording of Linear TV content
takes place in the cloud, and thus requires no
capacity on the cable access network.
However, unlike the in-home DVR case in
which all time-shifted viewing is served from
the DVR and thus has no impact on the cable
network, all time-shifted viewing in the
cDVR case is supported from the cloud, and
thus requires capacity on the cable access
network. Since the cDVR solution utilizes
unicast delivery (i.e. a unique video stream
per user), the amount of network capacity
required is directly proportional to the
number of cDVR subscribers viewing time-
shifted content at any given time.
In order to estimate the impact of cDVR on
the cable network, we refer again to the
recent study of DVR usage described in [3].
According to that study, 20% of DVR’s are
utilized for time-shifted viewing during
prime time (not including stream control of
Live TV programming). We assume the take

rate for the cDVR service is the same as
DVR service, since subscribers should not
care if the DVR functionality is supported in
the home or the cloud as long as the user
experience is equivalent. However, given
that cDVR service is accessible from any
STB in the home (which is not the case with
an in-home DVR unless it is a whole-home
DVR), we will assume the concurrency of
time-shifted viewing among cDVR
subscribers is slightly higher than in-home
DVR subscribers. Finally, since we are
focusing on Linear TV viewership on STB’s,
we will assume the same encode rate for
cDVR service as we did for real-time
viewing and DVR recording (8 Mbps). As
shown in Table 3, we estimate that 5.7
CMTS DS channels and HFC spectrum is
required to support the time-shifted viewing
from a cDVR solution in our example use
case.
Parameter Value
Cable TV Subscribers per SG* 200
cDVR Take Rate 50%
cDVR Subscribers per SG 100
cDVR Time-Shifted Viewing
Concurrency
25%
cDVR Time-Shifted Viewings
per SG
25
Linear TV Stream Bit Rate (Mbps) 8
CMTS DS Channel Capacity (Mbps) 35
CMTS DS Channels per SG 5.7
Table 3. cDVR Use Case
*See Table 1 for derivation
In addition to the time-shifted viewing
estimated in Table 3, there is also real-time
viewing by non-cDVR subscribers (and
cDVR subscribers who choose real-time
viewing). Assuming that time-shifted
viewing does not materially impact the STB
concurrency or multicast gain, we can
estimate that 13.7 DS channels are required
for real-time viewing (per Table 1). Thus a
total of 19.4 CMTS DS channels are required
per SG for Linear TV service (13.7 for real-
time viewing plus 5.7 for time-shifted
viewing). Thus, based on our example use
cases, cDVR solutions can increase the
network capacity and HFC spectrum required
for Linear TV services by roughly 40%
compared to in-home DVR solutions.
Since the cDVR solution performs all
recording in the cloud, the CMTS does not
receive control plane traffic associated with
channel changes for DVR recordings. Given
the propensity of DVR users to record a large
volume of content, especially during prime
time, we expect cDVR solutions to offload a
significant amount of control plane traffic
from the CMTS. While actual results will
depend on a number of factors, our
illustrative example described previously
indicates a 67% reduction in control plane
traffic load on the CMTS if the DVR
recording function is moved to the cloud.
HYBRID DVR USE CASE
The primary benefit of cDVR solutions when
compared to in-home DVR solutions is the
avoidance of costly DVR functionality and
storage in the STB and the higher
maintenance costs of DVR STB’s compared
to non-DVR STB’s. With that in mind, it
seems counter-intuitive to consider a
“hybrid” DVR use case in which operators
deploy both in-home DVR and cDVR
solutions. However, two scenarios may
merit consideration for such an approach.
Both scenarios rely on the assumption that
the popular Linear TV programming will be
delivered via multicast for real-time viewing
by non-DVR subscribers (or by DVR
subscribers that choose real-time viewing in
some instances). If that is the case, then
having an in-home DVR capability that can
provide the stream control functionality (for
a limited duration) could mitigate the
scenario in which a large percentage of
subscribers simultaneously access stream
control from a cDVR solution, resulting in a

large spike in cDVR traffic on the cable
network. This in-home DVR capability
could be limited to stream control only, with
a relatively small cache, and all recording
and storage supported by the cDVR solution.
The second scenario is the ability to push the
popular Linear TV content to in-home DVR
devices with a moderately sized cache, and
avoid the cost of storing the popular Linear
TV programming in the cloud (i.e. licensing
fees and storage capacity). In addition,
recording the most popular programming in-
home has virtually no impact to the cable
network, yet would significantly reduce the
network capacity required to support time-
shifted viewing of the popular programming
from the cloud.
If the hybrid DVR approach is not feasible, a
“pseudo-hybrid” solution can be envisioned
in which the cDVR service falls back to
multicast if the cable network is congested
and cannot provide sufficient capacity to
support the stream control features from the
cDVR solution.
MULTICAST ABR VIDEO TRANSPORT
Many cable operators have deployed TV
Everywhere solutions to enable their
subscribers to access Linear TV and On-
demand services on a variety of customer-
owned-and-maintained (COAM) devices
such as PC/laptops, tablets, game consoles,
smart TV’s and smartphones. In most cases,
the TV Everywhere platform has been
deployed as an overlay to the existing digital
cable platform, and designed to deliver
unmanaged video services to COAM
devices. As operators migrate to all-IP, there
are clear benefits to using a common
platform for delivering both managed and
unmanaged IP Video services to operator-
owned STB’s as well as COAM devices.
The TV Everywhere solutions deployed to
date can serve as a foundation for the
common platform to support all IP Video
services in the future.
The TV Everywhere solutions typically
employ Adaptive Bit Rate (ABR) video
streaming, which dynamically adapts to
network conditions to deliver the best
possible user experience without
provisioning guaranteed quality of service.
The ABR video streams are delivered via IP
unicast with a bi-directional TCP/IP
connection between the ABR client and
server so the client can continually monitor
the network throughput and request the
appropriate ABR video profile from the
server as the throughput fluctuates. As we
described in [1], using unicast delivery for all
Linear TV services in a full-scale IP Video
system is not feasible due to the exorbitant
CMTS capacity and HFC spectrum required.
Hence, an effort is underway within the cable
industry to define and develop a multicast
ABR video transport solution to enable
operators to utilize multicast delivery for
Linear TV services with an ABR-based IP
Video system.
To describe the operation of a multicast ABR
video transport system, let us first review the
operation of multicast delivery in existing
IPTV deployments, as depicted in Figure 2.
A multicast server receives the Linear TV
programming from the source, and outputs a
multicast video flow labeled with a unique
multicast group address. The multicast client
residing on the IPTV STB, which has a priori
knowledge of the multicast group address for
each Linear TV program available to the
user, initiates IGMP or MLD Join/Leave
messages to receive the multicast video flow
based on user input (or DVR recording
activity if so equipped). The CMTS
processes the IGMP/MLD messages in
accordance with the DOCSIS 3.0
specification, sends PIM messages to receive
the specified multicast video flow from the
multicast server, and replicates the flow to
the downstream interface on which the cable

modem/gateway is connected. The CMTS
then sends DOCSIS 3.0 (D30) management
messages to the cable modem/gateway,
instructing it to forward the multicast video
flow to the IPTV STB.
Figure 2: Multicast IPTV System
In a multicast ABR video transport system,
an ABR client residing on the IPTV STB or
COAM device sends HTTP GET messages
to the ABR video server to request a specific
Linear TV program (following standard ABR
video system operation). However, in this
case, a client on the cable modem/gateway
intercepts the HTTP GET messages and,
with a priori knowledge of the programming
available from the multicast server, sends
IGMP or MLD Join/Leave messages to
receive the requisite multicast ABR video
flow from the multicast server. The
multicast server is specially equipped to fetch
the Linear TV stream from the ABR video
server (using HTTP) based on the
IGMP/MLD messages received from the
client, and encapsulate the ABR video
streams into multicast flows. The CMTS
follows the same process described above to
receive the multicast ABR flows from the
multicast server and forward the flow to the
cable modem/gateway. The modem/gateway
then converts the multicast flow back to
unicast for delivery to the IPTV STB or
COAM device.
Figure 3: Multicast ABR Video Transport System
The use of multicast delivery in the cable
network is transparent to the ABR client and
server. If the requested Linear TV program
is not available from the multicast server, the
system falls back to standard ABR video
system operation in which the
modem/gateway client simply forwards the
HTTP GET from the ABR client, and the

Linear TV service is delivered via unicast.
The multicast ABR video transport system is
also compatible with in-home DVR and
cDVR solutions. Hybrid DVR functionality
can also be supported with local caching on
the gateway to support stream control, for
example.
When deploying a multicast ABR video
transport system, cable operators will need to
select which Linear TV programs, and which
ABR profile(s) for each program, to make
available from the multicast server. These
choices will affect the multicast efficiency
that can be achieved. If the popular Linear
TV programming is available from the
multicast server, and all STB’s and DVR’s
access the same ABR profile, then the
multicast efficiency can match that of
standard IPTV multicast systems. In fact, it
is possible to achieve even higher efficiency
if a multicast flow can serve not only STB’s
and DVR’s, but also COAM devices.
Although not shown in Figure 3, an optional
enhancement to the multicast ABR video
transport system is the use of a reliable
multicast transport protocol. This would
enable the multicast server to be notified of
lost packets, and re-transmit those packets
(within a re-transmit window) in order to
improve the quality of experience.
CONCLUSION
Using example use cases, we illustrated a
few key takeaways for cable operators to
consider in assessing the network
requirements for delivering full-scale,
managed IP Video services:
1. Multicast is essential for delivering
popular Linear TV programming in
prime time. Multicast efficiency can
reduce the CMTS capacity and HFC
spectrum required to support Linear TV
services by as much as 80% in our
example.
2. In-home DVR scenarios benefit the most
from multicast; however, multicast is still
a valuable tool in cDVR scenarios where
real-time viewing is still prevalent
(among non-cDVR subscribers and/or
cDVR subscribers who choose real-time
viewing in some instances).
3. cDVR increases the network capacity and
HFC spectrum required for Linear TV
services by 40% in our example; on the
other hand, cDVR reduces the multicast
control plane traffic load on the CMTS
by 67% in our example.
4. Hybrid DVR solutions can enable
operators to leverage multicast to record
the most popular Linear TV
programming in-home with virtually no
impact to the network, and record all
other programming in the cloud. Hybrid
DVR solutions can also avoid the
potential for large spikes in cDVR traffic
associated with stream control during
prime time.
5. Multicast ABR enables operators to
continue to leverage the benefits of
multicast for Linear TV services as they
migrate to a common infrastructure and
client for supporting all IP video services
across a variety of STB and COAM
devices.
The examples provided in this paper are
based on field data where available, and on
our own assumptions where field data is not
available, and thus are for illustrative
purposes only. Cable operators are
encouraged to adapt the methodology
described herein to their own particular
environment. While the optimal solution for
delivering full-scale, managed IP Video
services will be unique to each operator, it
will undoubtedly involve both multicast and
unicast delivery approaches.

REFERENCES
1. John Horrobin and Gitesh Shah,
“Pioneering IPTV in Cable Networks”,
SCTE Cable-Tec Expo, October, 2013
2. The Nielsen Company, “An Era of
Growth: The Cross-Platform Report”, March,
2014
3. Carol Ansley and John Ulm, “The Dawn
of Cloud-based DVR Services”, SCTE
Cable-Tec Expo, October, 2013

Unicast or Multicast for IP Video? Yes!

More Related Content

What's hot (20)

Similar to Unicast or Multicast for IP Video? Yes! (20)

More from Cisco Service Provider (20)

Recently uploaded (20)

Unicast or Multicast for IP Video? Yes!