Multicast instant channel change in IPTV systems 1
Multicast instant channel change in IPTV systems
Nov 20, 2014
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
1. Join
Current Approach (Unicast ICC)
9
D-Server
MulticastRouter
TVClient
2. Unicast a stream with a higher bit rate
1. Join
Current Approach (Unicast ICC)
10
D-Server
MulticastRouter
TVClient
3. Start display
2. Unicast a stream with a higher bit rate
1. Join
Current Approach (Unicast ICC)
11
D-Server
MulticastRouter
TVClient
3. Start display
4. Join multicast
2. Unicast a stream with a higher bit rate
1. Join
Current Approach (Unicast ICC)
12
D-Server
MulticastRouter
TVClient
5a. Multicast stream
3. Start display
4. Join multicast
2. Unicast a stream with a higher bit rate
1. Join
Current Approach (Unicast ICC)
13
D-Server
MulticastRouter
TVClient
5b. Display full quality video5a. Multicast
stream
3. Start display
4. Join multicast
2. Unicast a stream with a higher bit rate
1. Join
Current Approach (Unicast ICC)
14
D-Server
MulticastRouter
TVClient
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
18
MulticastReplicator
TVClient
1. Join
2a. I-frame stream
Multicast ICC
19
MulticastReplicator
TVClient
1. Join
2a. I-frame stream
2b. Primary multicast stream
Multicast ICC
20
MulticastReplicator
TVClient
1. Join
2a. I-frame stream
2b. Primary multicast stream
Multicast ICC
21
MulticastReplicator
TVClient
1. Join
3. Display the frame from I-frame stream
2a. I-frame stream
2b. Primary multicast stream
Multicast ICC
22
MulticastReplicator
TVClient
1. Join
3. Display the frame from I-frame stream
4. Buffering the primary stream
2a. I-frame stream
2b. Primary multicast stream
Multicast ICC
23
MulticastReplicator
TVClient
1. Join
3. Display the frame from I-frame stream
4. Buffering the primary stream
5. Play the full quality video
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
Q & AThanks
38
Related Documents
