IEEE TRANSACTIONS ON BROADCASTING, VOL. 45, NO. I . MARCH 1999 141

Design of Multicast Delivery for Providing VCR Functionality in Interactive Video-on-Demand Systems

Wilson Wing-Fai POON and Kwok-Tung LO

Department of Electronic and Information Engineering The Hong Kong Polytechnic University

Hung Hom, Hong Kong Email : enwil@videol .en.polyu.edu.hk, enktlo@polyu.edu.hk

Abstract

Multicast delivery is one of the solutions to reduce the cost in a large video-on-demand (VoD) system. However, multicast transmission makes much more difficult in implementation of interactive functions for individual user and introduces start-up delay to the users, which contradicts the idea of on-demand services. In this paper, we first try to explore and evaluate the performance of different multicast VoD systems. A new scheme called Single-Rate Multicast Double-Rate Unicast (SRMDRU) is then developed to minimize the system resources for supporting full VCR functionality in a multicast VoD system. This scheme also allows multicast systems to support true VoD services so customers can be served as soon as the system receives the requests. Computer simulations show that the multicast system using SRMDRU scheme performs much better than the other multicast systems in terms of system blocking probabilities.

Kevwords: Video on demand (VoD), Interactive TV

1. Introduction

using MPEG-2 compressed video, which has a typical bit rate of 6 Mbps.

In last few years, many different VoD systems have been proposed. Most of the systems were designed for one-to-one connection between a user and video server. In these systems, VCR functions such as pause, fast-forward and fast-rewind were not really difficult to implement since a dedicated channel was allocated to each user. The work of incorporating VCR functions into a VoD system has been studied in [l-21. However, such systems are not efficient and cost-effective when many users access the same movie at the same time. To increase the system efficiency, some researchers [3-41 proposed to use multicast delivery, in which one stream is used to serve a number of concurrent customers. Although these techniques reduce the system resource requirement, they cannot provide VCR operations very well. In order to provide full interactive VCR functions, Liao and Li [5] tried to use an access node which is built between the server and the clients so that the customer can join back to the multicast stream after VCR operations. On the other hand, multicast delivery also introduces start-up delay to users, which contradicts the original idea of on-demand services.

Recent development of digital video technology has made possible the communication of full motion-pictures as a type of computer data. Many research works have focused on developing multimedia applications such as video conferencing and video-on-demand (VoD). From this trend, we see that video data will become the main stream of information in future. Thus, how to effectively transmit the video over the bandwidth-limited network has become one of the hottest research topics in recent few years.

VoD is a kind of media service that allows a user to choose and play a movie on a television at any given time like watching it by the videotape machine. After the user’s request, high quality movie can be started with a non- perceivable delay. Moreover, the system provides all interactive functions such as pause, fast-forward and fast- rewind for each customer. In current VoD implementation, the system serves each customer individually by dedicating a transmission channel and a set of server resources. Therefore, providing such services using current technology may be very expensive. For example, a 155-Mbps transmission link is only able to support 26 users when

00 18-93 16/99$10.00 0 I999 IEEE P u b h h e r Item Identifier: S 001 8-93 16(99)02629-3

In this paper, we are going to develop a multicast delivery scheme to support full VCR functionality and true VoD services in interactive VoD systems. For the delivery scheme, our goal is to minimize the number of streams required to serve the interactive customers. Thus, we try to increase the probability of customers merging from the dedicated streams to multicast streams after VCR operations. The paper is organized as follows. In section 2, architecture of Video-on-Demand system will be briefly described. A simple multicast VoD system is discussed in section 3, the implementation of pause and fast-forward functions using the set-top box buffer will also be illustrated in this section. In section 4, Single-Rate Multicast Double- Rate Unicast (SRMDRU) scheme is proposed. By SRMDRU, a unicast customer is forced to join back to multicast stream again so more streams can be used to serve the new customers or VCR operations. In section 5, we will discuss how this method can be enhanced to provide the true VoD services such that customers can start watching the movie immediately. Then, a simulation model is built and the result will be discussed in section 6. Lastly, some concluding remarks are given in section 7.

I32

2. Architecture of VoD System

A VoD syste:n is mainly divided into three components: video server, network and user’s display equipment. Figure 1 shows the arzhitecture of a VoD system.

8 Display

Figure I Architecture of VoD Video Server

The server plays an important role in the VoD system. When a new custoiner arrives, the signal controller should determine whether there are sufficient resources such as disk bandwidth and available network channel for the customer. Then, the storage controller retrieves the requested movie from disk stonge and transmits the incoming video to the user through the high speed network.

Apart from th3 admission control, the signal controller is also responsible for handling the interactive functions such as pause, fast-forward and fast-rewind. For instance, when the signal controller receives a pause request from the user, it will signal the storage controller to stop playing the movie. If the request can not be done, the server may take another action depended on the design of the system and acknowledge the user what the server has done instead.

Transmission Network

In this paper, we assume that ATM network is used for video transmis:;ion. It is assumed that once a connection has been set up, the network can maintain the Quality of Service (QoS). That means the network assures sequential delivery of packets and bounded transmission delay.

User’s Disdav Ecluipment

For a good design of VoD system, the server should mostly handle the complexity. The user’s equipment is only responsible for sendingheceiving signals to/from the VoD server. The buffer is used to store the video data before playback to maintain a continuous and jitters-free display.

3. Basic Principles of Multicast Delivery in VoD System

In order to reduce the cost of VoD system, several techniques were proposed for increasing the number of concurrent customers of movies such that server I/O and network bandwidth can be greatly reduced. One solution is to use batchin;; 131. In a simple multicast VoD system, the

video streams are started at regular fixed time slots. All the customers who request for the same video before the start of a video stream will be grouped together and simultaneously served by the next video stream. Figure 2 illustrates that a new video stream is opened when new requests arrive between tO and t l . The time between the start of a video stream is called slot duration.

Request Arrival

I I .

to t‘\ t j t3\ t\ Y ‘* Open new No request

Figure 2 Basic operation of multicast VoD system

Because of the advantage of batching, less resources are dedicated to the users so that it reduces the number of customers blocked initially and the cost of the system. However, the drawback of multicast delivery is the on- demand nature of the system may be affected since customers have to wait for average half a slot duration before the video starts. In order to preserve the on-demand nature of the system, the slot duration can not be too long. Apart from the start-up delay, it is complicated to implement VCR functions in the system. For example, if a customer requests fast-forward operation, it is impossible to increase the transmission rate without affecting the other users in the same group. One approach for providing VCR functions is to create a new stream to serve the interactive user. After the dedicated stream is opened, the customer will hold onto it until disconnection. This approach will work only if very few customers issue VCR requests. Otherwise, the system will gradually degrade to a non-sharing mode as more and more customers are served by the dedicated streams.

In order to minimize the number of unicast streams for VCR functions, Almeroth and Ammar [4] tried to use the set-top box buffer to provide the pause function. They proposed that the jumping group property in a multicast system could be used to provide continuous pause function. If a customer pauses the movie longer than a slot duration, a change in multicast groups is required. It is because the total frames accumulated during the pause exceed the buffering capacity of the system. For this to be possible, we need to have a buffer large enough to hold a slot’s worth of frames. For instance, 1 12.5Mbytes buffer is required to store 1 SMbps MPEG compressed video for 10 minutes.

Figure 3 shows that a customer jumps from stream i to succeeding stream i+l when the playout frame of stream i+l is the same as the frame the customer pauses. After the change of multicast group, the duplicated buffer content is removed. The frames from group i+l continue to transmit to the buffer. The customer will jump to group i+2, i+3, and so on until he/she resumes the movie again. However, since multicast stream may not be opened at each beginning of slot, there may be no succeeding stream available. If this happens, a unicast stream is opened.

I43

Apart from the pause function, the limited jump forwardhackward can be implemented. For example, if the slot duration is 10 minutes long, the customer can jump forward for, says 10, 20, or 30 minutes. The fineness of the jump depends on the slot width. The smaller slot width lets the customers jump close to exactly what they want. However, small slot width counters to the gain from batching because very few customers are grouped for small slot duration and more multicast streams are required.

slot Ouration

& I

to 11 Time Continue lo

incoming bits from IPausealjlh Pause a1 jth Group i 1,CUme frame + +

Pause at llh frame +

Figure 3 Operation of change group in a multicast system

Although this method attempts to take the advantage of batching, it only supports the interactive operation of pause and resume. Providing fast-forward/rewind is still required by a unicast stream. Therefore, it is also possible that all customers will eventually be served by unicast streams. With a view to reducing the probability of opening unicast streams, set-top box buffer is also used for fast-forward. A dedicated stream for fast-forward is opened only when the customer's buffer is empty. Otherwise, the customer continues receiving the frames from multicast stream but displays the movie at f times the normal playback rate. For instance, if the customer, whose buffer has stored 5 minutes' video data because of the pause action, issues fast-forward request, the playout rate can be increased by not displaying some frames until all buffered frames are removed. Meanwhile, he/she is still receiving the coming frames from the multicast group. The customer should leave the multicast group and be served by a unicast stream if no frame is stored in the buffer. In this example, the buffer can support 5 minutes fast-forward at 2 times the normal playback rate.

Apart from the use of receiver buffer for fast-forward, we let customers in unicast streams be able to join back to the multicast groups. The customers do not hold onto the unicast streams until disconnection. Therefore, more resources can be released for the new customers or VCR operations. In Figure 4, when a customer in a unicast channel pause the movie, the server only needs to stop transmitting the frames. The customer can join to one of multicast group while the playout frame of the multicast stream is the same as the frame being paused.

Served by unicast stream

Pause a t jth frame Join the multicast

LI

Incoming bits

Figure 4 Operation from unicast stream to multicast stream by pause

4. Single-Rate Multicast Double-Rate Unicast (SRMDRU) Scheme

It is seen that the number of unicast streams opened mostly depends on the behavior of VCR operations. If a customer pauses the movie before fast-forward, buffered frames may be sufficient to provide fast-forward and a unicast stream is not required. Besides that, the unicast customer has a chance to join back to one of multicast streams only if hehhe requests pause function. However, since we cannot control the customers' VCR operations, it is difficult to minimize the number of unicast streams required. Thus, we try to develop a method called Single Rate Multicast Double Rate Unicast (SRMDRU) to maximize the probability of releasing the dedicated streams. This method forces customers in unicast streams to be served by multicast streams again after they resume from VCR operations. The idea is to double the transmission rate of the unicast stream so that the customer of normal playback can receive the frame synchronized to the transmitting frame of a multicast group.

In section 3, we know that the pause function can be implemented by using receiver buffer. Actually, by the use of this buffer, we are also able to let unicast customers be served by multicast streams again. Figure 5 shows how SRMDRU works. When a customer resumes from VCR operations, the playout frame is fp(tl). At that time, the transmltting frame of multicast groups of j and j+l is f,g'(tl) and fta'l(tl) respectively. As fP ' ( t1 ) c fp(tl), the customer can never join back to group j except helshe pauses the movie until f,(t)=f$(t). Since it can't be done without the customer's request, we try to make the customer jump back to the group j+ l . In order to merge the customer into group j + l , the transmission rate is doubled until the frame received f,(t2) from the stream is the same as ftd"(t2). At that time, the customer releases the unicast stream and join back to the multicast group. The double rate duration is t2-tl. At frame time t2+1, the customer becomes a member of multicast group j+ l and receives fta"(t2+1). Although the buffered frames are increasing due to the increased transmission rate, buffer overflow will never occur. It is because the buffer is large enough to hold a slot's worth of frames.

I44

tl 12 I I

I playout Received k

PI ayo u t frame fp(t2)

Transmitting frame

Transmltting frame of

f,el(tl) < f,(tl) < f*g”’(tl)

Figure 5 Operation from unicast stream to multicast stream by SRMDRU

As the trans:nission rate of multicast stream is never changed and the opening of multicast stream is at pre- defined intervd (the beginning of each slot), the duration of the double of transmission rate (rD in frame time) can be calculated. Th’: equation is shown as follows,

rD= t-f,(t)+l mod sw ( 1 )

where sw is the slot width, t is the frame time that the customer resumes from VCR operations

From this equation, we see that the buffer should be emptied if a unicast stream is opened due to fast-forwardhewind operation. However, frames may be stored in the buffer when a customer resumes normal play after the pause action. Therefore, we should consider that there are n frames in the buffer. I:f rD I: n, that means the buffer stores a frame that a multicast stream is currently transmitting. Figure 6 shows what happens when rD I n. The location of this frame (fl(t)) in the buffer can be calculated by

In this case, ‘.he customer will release the unicast stream immediately and join back to the multicast stream. Otherwise, if rD > n, the customer resumes the normal playback but the actual duration of doubling transmission rate (TD’) is eq Jal to rD-n.

t t d I +

Frame f,(t) that I

multicast stream i h, ’ Playout

Figure 6 Operation of joining multicast group when rD 5 n

From eqns. (1) and ( 2 ) , we see that rD will not be greater than sw. Therefore, the buffer will not be overflowed even the transmission rate is increased at normal playback.

Actually, there are various methods to implement SRMDRU. In this paper, we assume that a generic network protocol running on a generic network infrastructure. The network protocol must support multicasting operations. Asynchronous Transfer Mode (ATM) may be a typical network for this purpose. We also assume that there are three types of streams serving the customers. The multicast stream (M-Stream) is used to serve a group of customers who request the same movie within a slot duration. The unicast stream (U-Stream) is used to serve the interactive customer. Since the transmission rate may be doubled, D- Stream is used for this purpose. Thus, when the rate is doubled, U-Stream and D-Stream are opened.

Initially, the new customers within a slot duration will be grouped together. At the beginning of each slot, M-Stream is opened to serve a group of customers. If no customer arrives, M-Stream is not required. Hence, in the worst case, if a customer arrives just after M-Stream is opened, he/she should wait a slot duration.

When a customer issues a pause request, he/she sends Pause-Request to the server. Then, the customer’s buffer continues receiving the incoming frame. If the movie is still paused when the buffer is full, Buffer-Full is sent to the server. If there is a suitable multicast stream for the customer, the server will acknowledge the customer moved to the appropriate multicast stream. If no multicast stream is available, U-Stream is prepared to serve the customer. If there is no U-Stream available, the pause action is blocked. A blocked pause action means that the pause is ended early and playout is resumed.

During the pause action, the customer may be able to jump back to a multicast group and release U-Stream. When the movie is resumed in U-Stream, rD is calculated depended on the buffer state. As mentioned above, if rD is smaller than the number of frames in the buffer, U-Stream can be released immediately and the customer can merge into M- Stream again. Otherwise, D-Stream is opened to serve the user to double the transmission rate until the jumping back condition is met. We would like to point out that since there may be no M-Stream available even rD is minus to zero. If it happens, the system creates a new M-Stream to serve the customer.

Apart from the pause action, fast-forward is also supported by the system. When a customer requests a fast-forward function, he/she first checks the buffer state. If there are frames in the buffer, the playback rate is increased. Meanwhile, he/she is still receiving the frame from the multicast group. If all the frames in the buffer are displayed before fast-forward is stopped, Fl-Request is sent to the server. The server opens U-Stream for the interactive customer. If no U-Stream is available, the fast-forward operation is blocked so the action is ended and playout is resumed. Otherwise, the customer will be served by the U- Stream until the end of fast-forward. Then, D-Stream is opened to double the transmission rate until he/she can join back to M-Stream or a new M-Stream initiated by the system.

145

Parameter Range of Values Simulation 6 hours Time No of Movies 200 Movie’s 120 minutes Length Arrival Rate 200-5500 requests /

Slot Width 4-15 minutes Total 400-750 streams

6 hours

In order to implement fast-rewind, U-Stream should be opened when a customer requests fast-rewind and FR-Request is sent to the server. If there is no U-Stream, the request is blocked and playout is resumed. Otherwise, the customer will be served by U-Stream. After the fast-rewind action, D-Stream is opened to double the transmission rate until he/she can join back to M-Stream or a new one initiated by the system.

Nominal Value

3000 requests / 6 hours 10 minutes 600 streams**

5. Enhancement to True VoD System

Streams * Pause

Actually, SRMDRU can be enhanced to a true VoD system so that customers do not have to wait for the beginning of the next time slot to start the movie. As soon as the system receives a video request, it opens U-Stream to serve a customer and, at the same time, the transmission rate is doubled by D-Stream. The duration of doubling the transmission (riD) can be calculated by

1 /3

riD=a-time mod sw, (3)

Probability Mean Normal Play Duration Mean Pause Duration Mean FF/FR Duration

where a-time is the arriving time of the customer. When riD comes to zero, i.e. there is a multicast group suitable for the customer, he/she will merge into the group. Otherwise, a new M-Stream is opened. By this method, if customers arrive within a time slot, after a period of time, they will be finally merged into a multicast group.

10-50 minutes 30 minutes

5 minutes

0.5 minutes

6. Computer Simulations

This section presents the simulation results of the proposed SRMDRU scheme for multicast VoD system. To develop a simulation model, we assume that there are 200 movies in the server. The characteristics of user request are modeled as a Poisson arrival process. The probability of requesting any video is assumed to be qi which follows Zipf‘s distribution [7], i.e., if qr <...I q M , where M is the number of movies, qi=c/i, where c is a normalizing constant such that M C C-=1. i = 1 1

We also assume that the simulation runs from 6pm to 12pm which is known as prime time. We further assume a customer is in one of two states, the normal and the interaction states [7]. He/she starts in the normal state that the video is being played at normal speed. He stays in this state for a period of time that follows an exponential distribution. Then, he/she issues an interactive operation. Uniform distribution is used to determine whether pause, fast-forwgrd or fast-rewind is activated. He/she stays in the intera,ctive state for another period of time that also follows an exponential distribution. He/she shuffles between two states several times until the end of the movies. Table 1 shows the system parameters.

In order to compare the performance of different multicast systems, six different schemes were simulated using the same set of parameters. The descriptions of these systems are as follows:

1.

2.

3.

4.

5.

6.

Unicast system: Each customer is served by dedicated fashion. When a customer arrives, a unicast stream is opened until the end of the movie. Simple Multicast System: As mentioned in section 3, several customers share one multicast stream. When a customer requests VCR operation, a unicast stream is opened. The customer will hold onto it until the end of the movie. Pause with Buffer (PWB) Multicast System: The system is basically same as 2 but use Almeroth and Ammar’s algorithm [4] to implement pause function with buffer. Fast-forward with Buffer (FFWB) Multicast System: The system is same as 3 but a unicast stream is opened for fast-forward only when the set-top box buffer is empty. SRMDRU (SRMDRU) Multicast System: The system is basically same as 4 but use the algorithm in section 4 to force the customer merging into a multicast stream after VCR operations. True VoD (TVoD) Multicast System: It is the enhanced SRMDRU multicast system mentioned in section 5 .

Probability I FF I 113 I - Probability I I FR I 1/3

*Totul Streamr include M-Stream, U-Stream and D-Stream The simulution progrum does not muke any differences among the stream type except the result in Figure 15. The custrimer cun get the different lypes rf stream,from the sume pool.

**700 streumr ure used when the number of requests is varied.

Table I Parameters of simulation model

In evaluating the performance of the multicast VoD systems, we use two performance measures: initial blocking probability and VCR blocking probability. Initial blocking probability is defined as the percentage of initial requests that are blocked. In our system, a request is blocked when there are no free streams to allocate to the new movie

request. The VCR blocking probability is measured as the percentage o F customer VCR function attempts that were blocked because there are no free streams.

Figure 7 and 8 show the initial blocking probability and the VCR blockirg probability of different systems when the number of requests is increased. We find that both the initial blocking probability and the VCR blocking probability are increased as more customers arrive within six hours. Moreover, we see that a better result is obtained from SRMDRU system. Comparing with simple multicast system mentioned in section 3, more than 20% of customers can be admitted using SRMDRU and fewer interactive operations are blocked. From Figure 7, the initial blocking of SRMDRU system is smaller than 10% when the number of requests is 3000. In addition, we see that the performance of SRMDRU sj'stem is still better than the other multicast systems even it is enhanced to True VoD system. When the number of recjuests is small, the initial blocking is very close to the originill SRMDRU system. It is because the total number of streams is enough even the new customers are initially served by dedicated streams on demand basis. However, thr: VCR blocking probability of True VoD system is higher since most unicast streams are used to serve the new customers instead of VCR operations.

Figure 9 and 10 show the blocking probability as a function of number 0' streams. Same as our prediction, both the initial blocking probability and the VCR blocking probability ar: decreased when the total number of streams is increased. It is because more streams are available to serve the new customers and interactive operations. We would like to point out that, comparing with other multicast systems, our system obtains much better results. The initial blocking protiability and the VCR blocking probability of SRMDRU system are only about 10% and 0% respectively when the number of streams is 600.

Figure 11 shcws how slot width affects the initial blocking probability. Vie observe that the blocking probabilities of different systems do not dramatically decrease as the slot width is increased, especially for Simple Multicast System. It is because, in simple multicast system, opening unicast streams only depend on the behavior of customer's VCR operations. In PWB and FFWB systems, although the trend of blocking probabilities is decreasing for longer slot duration, then: are only about 3% to 5% differences when the slot is varied from 4 minutes to 15 minutes. The reason is that fewer multicast streams are opened for longer slot width. However, it also reduces the probability of customers joining back to multicast streams. In SRMDRU system, we observe that ;he initial blocking is decreasing as the slot width increases. Since a longer slot duration requires a larger buffer as mentioned in section 3, more frames can be stored in the buffer when a customer joins back to multicast stream. Therefore, i t reduces the number of unicast streams opened for fist-forward (when a customer request fast- forward, a unicast stream is opened only when the buffer is empty). Ho*ever, when we enhance SRMDRU system to TVoD system, the initial blocking probability is independent to slot width. It is because longer slot width means more unicast streams are required for the new customers. Figure 12 shows the VCR hlocking probability when the slot width

is changed. Same as the initial blocking probability, the VCR blocking probabilities of different systems are also independent to the slot duration. These probabilities are varied less than 5% difference as the slot width is increased.

Figure 13 shows the initial blocking probability when the mean normal playback duration is varied from 10 minutes to 50 minutes. We observe that the unicast system does not decrease as the play duration is increased. The reason is that each user is served by a dedicated link and doesn't need extra stream for performing the VCR operations. Thus, the time between interactive actions does not affect the blocking probability of a unicast system. For the other multicast systems, we find that the blocking probabilities decrease as the play duration is increased. It is because fewer VCR operations result in more streams used for the new customers. However, figure 14 shows that the VCR blocking probabilities of simple, PWB and FFWB systems do not decrease as the play duration is increased. It is because, in these systems, once unicast streams are opened for VCR operations, there is a small probability of releasing the unicast streams. The release of unicast streams mainly depends on whether a customer pauses the movie but longer play duration counters to the interactive actions. On the other hand, using SRMDRU scheme, a longer playback time results in smaller VCR blocking probability. It is because customers are forced to join back to multicast streams again after VCR operations. a longer normal play duration results that customers have enough time to merge into a multicast stream. Therefore, more streams are available for both VCR operations and the new customers.

Apart from the customers requesting the different types of streams from the same pool, we fix the total number of streams as 500 but designate D-Stream as used for doubling the transmission rate and changed from 10 to 180. Figure 15 shows the blocking probability of TVoD system. We observe that the initial blocking probability decreases and then increases as the number of D-Streams is increased. It is because the number of customers merging to multicast streams depends on whether there are streams to double the transmission rate. If it has not sufficient bandwidth for increasing the transmission rate, more customers will stick to the unicast streams and result in higher initial blocking probability. However, if we reserve too many channels for increasing transmission rate, the number of U-Streams and M-Streams decreases. It also results in higher blocking probability. We find that the optimal point is about 50 D- Streams so that the blocking probability is about 20%. Moreover, we also see that the VCR blocking probability is increasing. The reason is that more D-Streams will result in fewer U-Streams for VCR operations. The VCR blocking probability is changed from 3% to 15% as the number of D- Streams increases.

7. Conclusions

In this paper, we explored how VCR operations can be implemented in a multicast VoD system. In a multicast system, one single stream is used to serve a number of concurrent customers. Although it saves the system resources, traditional multicast system does not provide

147

VCR functions very well. The provision of VCR functions will inevitably requires additional resources such as transmission bandwidth and receiver buffer. Therefore, the performance of these systems mostly depends on the interactivity of customers. For example, a simple multicast system mentioned above will gradually degrade to a non- sharing mode if most of the customers issue VCR requests. Actually, from the results, the initial blocking probability of simple system is about 20% even when 700 streams are used for 2500 requests in six hours.

To further reduce the resources requirement, a new scheme called Single-Rate Multicast Double-Rate Unicast is developed in this paper to minimize the number of streams required. By SRMDRU method, the interactive customers will release the unicast streams after VCR operations. The results showed that the initial blocking probability and the VCR blocking probability are much smaller than that of the other multicast systems. Both blocking probabilities are nearly zero in case when 700 streams are used for 2500 requests in six hours. Moreover, the multicast system can be enhanced to support true VoD services using the SRMDRU scheme so customers can be served as soon as the system receives the requests. Simulation result showed that the true VoD system using SRMDRU scheme still performs better than the other multicast systems. Therefore, we can conclude that SRMDRU scheme is most suitable for deployment in interactive VoD systems.

Acknowledgement

This work was supported by The Hong Kong Polytechnic University under Grant A/C V466 and the Research Grant Council (RGC) of the Hong Kong Special Administrative Region under Grant AIC Q245.

References

D. B. Andersen, “A Proposed Method for Creating VCR Functions using MPEG,” Proceedings of the twelfth International Conference on Data Engineering,

W.C. Feng, F. Jahanian and S. Sechrest, “Providing VCR Functionality in a Constant Quality Video-On- Demand Transportation Service”, Proceedings of the 3“’ IEEE International Conference on Multimedia Computing and Systems, pp. 127-135, 1996. A. Dean, D. Sitaram, and P. Shahabuddin, “Scheduling Policies for an On-Demand Video Server with Batching,” Proc. ACM Multimedia ’94, pages 39 1- 398, San Francisco, 1994. K.C. Almeroth and M.H. Ammar, “The Use of

Multicast Delivery to Provide a Scalable and Interactive Video-on-Demand Service,” IEEE J. Selected Areas in Comm., Vol. 14, No. 6, pp.1111- 1122, Aug. 1996. W.J. Liao and O.K. Li, “The Split and Merge Protocol for Interactive Video-on-Demand”, IEEE Multimedia, vo1.14, No. 4, pp. 51-62, 0ct.-Dec. 1997. G. Zjpf, Human Behavior and the Principle of Least Effort. Reading, MA: Addison-Wesley, 1994.

pp. 380-382, 1996.

[7] 0 .K Li, W.J. Liao, X.X. Qiu, and W. M. Wong, “Performance Model of Interactive Video-on-Demand Systems,” IEEE J. Selected Areas in Commun., vo1.14, No.6, pp.1099-1109, August 1996.

60.00%

50.00%

40.00%

30.00%

20.00%

10.00%

0.00% +P

+ S i l a System +PausewilhBuffer -x- FFw Rh Buffer

+-True VOD

g g g g g g g z 8

b.01 Requests 16 hrs

Figure 7 Initial blocking probability as a function of number of requests

” ” ” 3000% T

25.00% ,g n

e p 15.00%

I 10.00%

- 20.00%

r 8

’ 5.00%

E

0.00%

N0.01 Requests16hr.s

Figure 8 VCR blocking probability as a function of number of requests

- __”.

60 00%

-0- Simple System I+ Pause w I h Buff ~r -x-FFwUh Buffer

+-True VoD

Figure 9 Initial blocking probability as a function of number of streams

~~

25 00% T

20.00% 2 - ij

15.00% n cn n g 10.00%

E

' 5.00%

-

0.00%

~~

-a- Unicast

+Pause w ~ h Buffer

Sirrple System

-x-FFwRh Buffer

-x- SRMDRU

-+-True VOD

No. of Streams

Fi);ure 10 VCR blocking probability

~ ~~ ~

+ urucast

4 Sirpie System

4PausewRhBuffer

1-X- FF wRh Buffer

-x- S R m U

-+-True VoD

4 5 6 8 10 12 15

Slot Width (minutes)

I

Figure 1 I Initial blocking probability as a function of Slot Width

6 '7-\ 00%

-0- Siwk System

-A-FausewRhBufferl % 300% -X- FFwRh Buffer

-x- SFhrCRJ

+-True VoD

1 00%

4 !i 6 8 10 12 15

Slot Width (minutes)

Figure 12 VCR blocking probability as a function of slot width

40W% r

+ Ruse wlvl Buffer

-x- FFw Rh Buffer 1 -x- s " J ~L-TWB VOD _ _ J

10 15 20 25 30 35 40 45 50

Time between Interactive Action (minutes)

I I

Figure 13 Initial blocking probability as a function of mean normal play duration

1 600% 500%

- P m

n p 400% - 1

9 300% E g 2 00%

100%

0 00%

I

I+-TrueVoD i L- . .

Figure 14 VCR blocking probability as a function of mean normal play duration

.......... ..... " ,, .... . .. . ....... . ......"..I

40.00%

-u- CaU Bbck Rob

L V C R B k k Rc4l

10 00%

5 00%

0 00% ~ 0 0 0 0 ~ 0 0 0 " " " c ~ ~ ~

No of DStreams

Figure 15 Blocking probability of true VoD system as a function of number of D-Stream