Multicast instant channel change in IPTV systems

1
Multicast instant channel change in IPTV systems
2
Outline

• Introduction
• Instant Channel Change
• Conclusion
• Experimental Result

3
INTRODUCTION
4
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.

5
(No Transcript)
6
Network Architecture
7
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

8
INSTANT CHANNEL CHANGE
9
Current Approach (Unicast ICC)
1. Join
TV Client
D-Server
Multicast Router
10
Current Approach (Unicast ICC)
1. Join
TV Client
D-Server
2. Unicast a stream with a higher bit rate
Multicast Router
11
Current Approach (Unicast ICC)
3. Start display
1. Join
TV Client
D-Server
2. Unicast a stream with a higher bit rate
Multicast Router
12
Current Approach (Unicast ICC)
3. Start display
1. Join
TV Client
D-Server
2. Unicast a stream with a higher bit rate
4. Join multicast
Multicast Router
13
Current Approach (Unicast ICC)
3. Start display
1. Join
TV Client
D-Server
2. Unicast a stream with a higher bit rate
4. Join multicast
Multicast Router
5a. Multicast stream
14
Current Approach (Unicast ICC)
3. Start display
1. Join
TV Client
D-Server
2. Unicast a stream with a higher bit rate
4. Join multicast
5b. Display full quality video
Multicast Router
5a. Multicast stream
15
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.

16
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.

17
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

18
Multicast ICC
1. Join
TV Client
Multicast Replicator
19
Multicast ICC
1. Join
TV Client
Multicast Replicator
2a. I-frame stream
20
Multicast ICC
1. Join
TV Client
Multicast Replicator
2a. I-frame stream
2b. Primary multicast stream
21
Multicast ICC
1. Join
TV Client
Multicast Replicator
3. Display the frame from I-frame stream
2a. I-frame stream
2b. Primary multicast stream
22
Multicast ICC
1. Join
TV Client
Multicast Replicator
3. Display the frame from I-frame stream 4.
Buffering the primary stream
2a. I-frame stream
2b. Primary multicast stream
23
Multicast ICC
1. Join
TV Client
Multicast Replicator
3. Display the frame from I-frame stream 4.
Buffering the primary stream 5. Play the full
quality video
2a. I-frame stream
2b. Primary multicast stream
24
CONCLUSION
25

• 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?

26
(No Transcript)
27
EXPERIMENT
28
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

29
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.

30
Channel Change Requests

• The empirical distribution of the channel change
  requests across all channels initiated from all
  users.

31
(No Transcript)
32
(No Transcript)
33
(No Transcript)
34
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.

35
(No Transcript)
36
(No Transcript)
37
(No Transcript)
38
Q A

• Thanks