Multicast instant channel
change in IPTV systems
1
Outline




Introduction
Instant Channel Change
Conclusion
Experimental Result
2
INTRODUCTION
3
Objective

Traditional Instant Channel Change (ICC)


Having a separate unicast for every user change
channel.
We propose a multicast-based approach



Using a secondary “channel change stream”
associated with each channel.
Carrying only I-frame and associated audio.
The drawback is the 50% additional capacity
required.
4
5
Network Architecture
6
Network Architecture

Content Source & D-Server




Content is buffered at Distribution Server (D-Server) in
the Video Hub Office (VHO)
A separate D-Server could be used for every channel
All D-Server share the link to the VHO
Metro Network


Connects the VHO to a number of Central Offices (CO)
Is usually an optical network with significant capacity
7
INSTANT CHANNEL CHANGE
8
Current Approach (Unicast ICC)
1. Join
D-Server
TV
Client
Multicast
Router
9
Current Approach (Unicast ICC)
1. Join
D-Server
2. Unicast a
stream with a
higher bit rate
TV
Client
Multicast
Router
10
Current Approach (Unicast ICC)
3. Start display
1. Join
D-Server
2. Unicast a
stream with a
higher bit rate
TV
Client
Multicast
Router
11
Current Approach (Unicast ICC)
3. Start display
1. Join
D-Server
2. Unicast a
stream with a
higher bit rate
TV
Client
4. Join multicast
Multicast
Router
12
Current Approach (Unicast ICC)
3. Start display
1. Join
D-Server
2. Unicast a
stream with a
higher bit rate
TV
Client
4. Join multicast
Multicast
Router
5a. Multicast
stream
13
Current Approach (Unicast ICC)
3. Start display
1. Join
D-Server
2. Unicast a
stream with a
higher bit rate
TV
Client
4. Join multicast
Multicast
Router
5a. Multicast
stream
5b. Display full
quality video
14
Drawback


The number of concurrent ICC requests is
small.
When there are a number of concurrent ICC
requests:


substantial load on the network.
service provider have to deploy additional
servers.
15
Multicast ICC (Motivation)




Unicasting the same stream for a given channel is
wasteful.
It is sufficient for the user to briefly (for 1-2 seconds)
see a lower quality.
There are bandwidth constraint on the links from the
DSLAM to CO.
To limit the number of concurrent streams delivered
to a particular DSLAM.
16
Multicast ICC



Secondary lower-bandwidth channel change
stream corresponding to each channel at
the D-Server
This stream will consists of I-frame only
Each channel will add another IP multicast
group called the “Secondary ICC Multicast
Group”
17
Multicast ICC
1. Join
Multicast
Replicator
TV
Client
18
Multicast ICC
1. Join
Multicast
Replicator
TV
Client
2a. I-frame stream
19
Multicast ICC
1. Join
Multicast
Replicator
TV
Client
2a. I-frame stream
2b. Primary multicast stream
20
Multicast ICC
1. Join
Multicast
Replicator
2a. I-frame stream
TV
Client
3. Display the frame from
I-frame stream
2b. Primary multicast stream
21
Multicast ICC
1. Join
Multicast
Replicator
2a. I-frame stream
2b. Primary multicast stream
TV
Client
3. Display the frame from
I-frame stream
4. Buffering the primary
stream
22
Multicast ICC
1. Join
Multicast
Replicator
2a. I-frame stream
2b. Primary multicast stream
TV
Client
3. Display the frame from
I-frame stream
4. Buffering the primary
stream
5. Play the full quality
video
23
CONCLUSION
24



Requires approximately 50% additional
capacity for each channel.
The requirement is relatively independent
of, and does NOT grow with, the user
population request.
Does not take into account the command
processing delay time?
25
26
EXPERIMENT
27
Tool & Objective



Build and NS-2 simulation of the metro/access
network and the VHO servers.
The link between the CO and the DSLAM and the
D-Server I/O were the bottlenecks.
To evaluate the unicast and multicast schemes in
terms of:




Bandwidth consumption
Display latency
Channel switch latency
D-Server I/O
28
NS-2 Settings

With NS-2 simulation constraints, we set



The number of channels at the DSLAM to 10.
The link capacity of DSLAM →CO to 200 Mbps.
The simulation was run for 150 seconds.
29
Channel Change Requests

The empirical distribution of the channel change requests across
all channels initiated from all users.
30
31
32
33
Popular Channel & D-Server I/O



The channel change requests for the most popular channel at a D-Server
collected.
The key bottleneck we examine here is the D-Server I/O.
The popularity of channel is defined by the largest number of users changes.
34
35
36
37
Thanks
Q&A
38