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