WO2003103292A1

WO2003103292A1 - Bandwidth allocation for video-on-demand

Info

Publication number: WO2003103292A1
Application number: PCT/AU2003/000677
Authority: WO
Inventors: Santosh Kulkarni
Original assignee: Telstra New Wave Pty Ltd
Priority date: 2002-05-30
Filing date: 2003-05-30
Publication date: 2003-12-11
Also published as: AUPS267402A0

Abstract

A bandwidth allocation process for a video-on-demand (VoD) system, including receiving a new request for a video service, and allocating all available channels to the new request if no other requests are being served, otherwise identifying a previous request having more than one of the channels allocated thereto, and reallocating at least one of the channels allocated to the previous request to the new request. The process identifies a request with more than one of the channels allocated thereto when a request having less allocated channels is complete, and assigns at least one channel of the completed request to the identified request. A head-end of the system (12) includes a video server (2) for serving the video streams on the channels in response to requests from equipment of users (8, 10), and the streams are served to network nodes (14), that in turn serve the user equipment (8, 10), which may comprise a STU (10). The VoD system can be implemented on an HFC network (6) that uses DVB as the transmission protocol.

Description

BANDWIDTH ALLOCATION FOR VIDEO-ON-DEMAND

FIELD OF THE INVENTION

The present invention relates to a bandwidth allocation process for a video-on-demand (VoD) system, and a VoD server for executing the process.

BACKGROUND OF THE INVENTION

Video-on-demand (VoD) systems have been developed to deliver video content to users over an existing communications networks. The term video-on-demand is sometimes used to describe pay per view (PPV) or near video on demand (N-VOD). PPV is usually limited to a small number of channels (typically 5-7) with content delivered at fixed times, and N- VOD broadcasts particular movies at staggered intervals. However, neither PPV nor N- VOD provide interactive functionality to the user. True video-on-demand supports full interactivity, and should provide a video channel when requested with full VCR functionality. Users should be able to fast forward, pause, rewind and play the video content just like a VCR. True video-on-demand involves the transmission of a dedicated video stream for each and every request.

A VoD system can be designed using three primary network configurations: centralised, networked and distributed. In a centralised system there is one central server that stores all the video content. All the clients are connected to this server to satisfy their requests. In a networked system architecture, multiple video servers are distributed throughout the network. Each video server controls and manages a subset of the video content and is responsible for a subset of the client requests. In a distributed configuration there is one central server that stores all the content with smaller servers located near the network edges that are used to store high demand content. When a client requests that a particular video be played, the video server responsible for the request reserves sufficient processing capacity and network bandwidth for the video stream to guarantee continuous playback of the video. Transmission of video streams requires high network bandwidth and this can be very expensive, especially in the core section of the network. Network bandwidth is therefore considered to be the most expensive resource in a VoD system and is a major consideration in providing an affordable true video-on-demand service. High transmission cost is a continuing problem hindering the widespread proliferation of VoD. Therefore an important part of VoD system design is to optimise network bandwidth.

Considerable research has been conducted to solve the bandwidth problem and design cost effective, reliable, efficient and robust video-on-demand systems. Different techniques are discussed in:

(i) Dan, D. Sitaram and P. Shahabuddin. Dynamic Batching Policies for an On- Demand Video Server, Multimedia Systems, 4(3): 112-121, June 1996. (ii) Kien A. Hua, Ying Cai and Simon Sheu. Patching: A Multicast Technique for True Video-on-Demand Services, In Proc. of ACM Multimedia, pp 191-200, Bristol, U.K, September 1998. (iii) Ying Cai and Kien A. Hua. An Efficient Bandwidth-Sharing Technique for True Video-on-Demand Systems, ACM Multimedia, 1999. (iv) Wanjiun Liao and Victor O. K. Li. The Split and Merge (SAM) Protocol for Interactive Video-on-Demand Systems, IEEE Multimedia, pp51-62. October 1997. (v) Zhe Xiang, Yuzhuo Zhong and Shiqiang Yang. PeriodPatch: An Efficient Stream Schedule for Video-On-Demand, Proceedings of SPIE, vol 4210 (2000), ρp341- 347. (vi) Lixin Gao and Don Towsley. Supplying Instantaneous Video-on-Demand Services Using Controlled Multicast, in Proceedings of IEEE International Conference on Multimedia Computing and Systems, Florence, Italy, June 1999.

All the techniques described in the above papers suffer from one primary disadvantage. The performance of the proposed systems is generally universally proportional to the level of interaction with the system. As customers or users use the interactive features of the

VoD system, such as fast forward, rewind etc, the performance of the system deteriorates.

For this reason, most of the discussed techniques are not being used commercially.

Accordingly, it is desired to provide a bandwidth allocation process and VoD system that alleviates this disadvantage or at least provides a useful alternative. SUMMARY OF THE INVENTION

In accordance with the present invention there is provided a bandwidth allocation process for a video-on-demand system, including: receiving a new request for a video service; and allocating all available channels to said new request if no other requests are being served, otherwise identifying a previous request having more than one of said channels allocated thereto, and reallocating at least one of said channels allocated to said previous request to said new request.

The process preferably further includes identifying a request with more than one of said channels allocated thereto when a request having less allocated channels is complete, and assigning at least one channel of the completed request to the identified request. The process preferably also includes assigning all available channels to a subsequent server request when a request with more than one channel allocated thereto is complete.

The present invention also provides a video-on-demand system including a video server for serving video streams in response to requests from users, said server being adapted to execute the bandwidth allocation process. Advantageously, the video-on-demand system can be implemented on a hybrid fibre and coaxial cable network using the Digital Video Broadcasting (DVB) protocol.

The present invention also provides management software for a video-on-demand server, including code for executing the bandwidth allocation process.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein: Figure 1 is a block diagram of an embodiment of a video-on-demand system; Figure 2 is a diagram of a network of the VoD system;

Figure 3 is a graph of channels required against requests received based on a uniform request arrival pattern for the VoD system; and

Figure 4 is a graph of channels required against requests received for a random request arrival pattern for the VoD system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A video-on-demand (VoD) system, as shown in Figures 1 and 2, includes a central video server 2 located at a head-end 12 and having a database 4, or database server, that stores all of the video content for delivery to a customer or user over a communications network 6. The video content includes sequences of visual images, with or without accompanying audio, that is intended to be displayed in real-time, such as movies and television programs. The VoD server 2 includes a communications interface for communicating with and allocating communications channels to set-top units (STUs) 10 of customers or users of the system. The STUs 10 allow each user to interact with the system 2 and request video content, which is sent to the STU 10 as a video stream over an allocated channel. The STUs deliver the requested content to a visual display device 8, such as a television, that is connected to each STU 10. The video server 2 may be one of a number of video servers provided by different vendors, such as Silicon Graphics, Inc. (ie the Origin 300 and TP 900 VoD servers), nCUBE Corporation and Sea Change International, Inc. The STUs 10 may be an Explorer™ STU manufactured by Scientific- Atlanta, Inc.

The communications network used by the VoD system may employ a networked or distributed configuration. For example, in a distributed VoD system smaller VoD servers are located near edges of the network 6 that are used to cache video content of the central server 2 currently requested by the local users. The VoD system described below is implemented on a Hybrid Fibre and Coaxial Cable (HFC) network 6. In a HFC network system, as shown in Figure 2, the central server 2 is located at the head-end 12 and caching VoD servers are located at nodes 14. The user's equipment 8, 10 is connected to the nodes 14 and the head-end 12 by hubs 16 that serve a group of users 8, 10. One or more hubs 16 may be connected to the nodes 14. In the HFC network, all communication links between the head-end 12, nodes 14, and hub 16 are optical links. The hubs 16 include optical to electrical converters to provide the users with radio frequency channels over a coaxial cable. Although the equipment employed is the same, usage of the terms nodes and hubs is often reversed when describing HFC networks used in North America and Europe.

An important part of the VoD system is the section between the head-end 12 and a node 14, as each node 14 has to serve a large number of users, eg about 20,000 for the applicant's HFC network in Australia. Beyond a node 16 there is a fibre connection to each hub 16 that serves a much smaller number of users, eg about 750 for the applicant's HFC network in Australia. The rest of the system therefore does not have the bandwidth restrictions that apply to the part between the head-end 12 and the node 14. A HFC network typically has a total spectrum of 750MHz. This is divided into individual analogue channels of approximately 8MHz each for Australia. These channels are used for content services such as high speed Internet and pay TV. If a VoD service is deployed on an HFC network a fixed number of analogue channels are assigned for its use. One 8MHz analogue channel can transmit approximately 38Mbps using QAM- 128 (Quadrature Amplitude Modulation). If the video content is encoded at 3.5Mbps (which is a rate used by commercial VoD systems), then one analogue channel can support approximately 10 digital video streams on 10 respective digital channels simultaneously. A request for particular video content, such as a movie title, to be delivered as a video stream on one of the digital channels, is made on a return communications path to the head-end 12. The return path uses the 0-50 MHz band of the available spectrum. A request is considered to be complete or satisfied when the content has been delivered to a node 14, or STU 10, or the stream has been paused or stopped for a predetermined period of time. Once a digital channel has been allocated to a request, delivery of the video content on the monitor 8 may be controlled by commands issued by the STU 10, such as rewind, pause, fast forward. The commands may be sent on the return path to the node 14.

Based on the above, if 4 analogue channels are assigned for VoD, then a maximum of 40 requests for a video stream can be served at each node 14 at any given time during a peak period. Any further requests would be blocked due to unavailability of free channels. This is a major limitation in most commercial VoD systems. As a VoD service becomes more popular and more users try to use the service, the blocking factor increases and eventually the system is not a true video-on-demand system. The prior art techniques described previously can be used to reduce bandwidth requirements but unfortunately their benefit diminishes as the level of interaction with the system increases. One way to overcome the limitation is to allocate additional channels for the VoD service, to the detriment of the other services delivered on the HFC network. Another alternative is to change the infrastructure of the network, at significant cost, to introduce advanced networking technologies, such as dense wave division multiplexing (DWDM) described in "DWDM and New Switching Architectures", Michael Finneran, Network Intelligence, July 1998.

The video server 2 uses a bandwidth allocation process that alleviates the problem without having to allocate additional channels or introduce expensive infrastructure changes to the network. The process, referred to herein as BEVA, is executed as part of VoD management software of the central server 2. The process could also be executed by an Application Specific Integrated Circuit that is part of the server 2, if desired. The server 2 uses the Digital Video Broadcasting (DVB) protocol to send the streams on the digital channels. The BEVA process, described in detail below, takes advantage of the fact that requests for video content during peak time do not arrive at exactly the same time. The objective is to maximise the utilization of all of the available channels whenever a request is processed. The process assigns all the available channels to the first request when it arrives (allowing it to be served faster than real-time). When a second request arrives, it is assigned the minimum amount of bandwidth required to finish the request in the time required for video (real-time) transmission. The rest of the bandwidth is still assigned to the first request. If a third request arrives, it is assigned the minimum amount of bandwidth to satisfy the request as well. This is continued for every new request until a request is completed. When a request is completed or satisfied, all the free channels are allocated to the subsequent request.

For the HFC network 6, assuming the VoD system has access to 40 digital channels, when the first VoD service request arrives, all of the available 40 digital channels are assigned to this request, and the selected video title is transferred to the corresponding node 14 at 40 times the normal rate that is required for delivery of the service. Accordingly it will take l/40^th of the total time that would normally be required to complete or satisfy the request, assuming all 40 channels are allocated for the entire duration. The node 14 is able to cache the transmitted content for delivery to the user, as requested. The STU 10 may be able to cache the content from the node 14. When a second request arrives it is assigned 1 digital channel for real time transmission and the first request now has 39 digital channels. When a third request arrives, it is also assigned 1 digital channel and the first request now has 38 channels. This process is continued until the first request is complete. All the free channels are then assigned to the next unfinished request. This is continued as long as new requests keep arriving. Using this process, requests are completed at a much faster rate than normal as they use the free capacity before the arrival of subsequent requests. The amount of savings that can be achieved using this approach depends on the duration of peak period, as discussed below.

The BEVA process controls the actions of the server 2 as it receives requests for video content. Depending on the number of requests currently being served, the server 2 assigns an appropriate number of channels to this request and starts streaming the video content. The BEVA process can be described as:

When a new request RN arrives at time ti,

if (there are no other requests currently being served) then assign all the channels to the request RN_; else identify the request Ri with the maximum number of channels assigned; if (number of channels used by Ri > 1) then free one channel from the identified request Rr; assign the channel to the newly arrived request R_N; else refuse request; endif endif

When a request Re is completed at time t₂,

if (there are other requests being served) then if (request Re had only one channel assigned) then identify the request Ri with more than one channel assigned; assign the free channel to request Ri; elseif (Re had more than one channel assigned) assign all the free channels to the next request that is not complete; endif elseif (there are no other requests being served) mark all the channels as free channels; endif

The BEVA process operates on two events, receipt of a new request R , and completion of a content request Re to adjust the chamiels allocated to requests received from the user equipment 8, 10.

Two different sets of tests were devised to assess the performance of the BEVA process. In the first test, the BEVA arrival rate of requests was set to be uniform, in that requests arrived at a uniform rate. For example, if the peak request arrival rate is 10 requests/minute, then 1 request arrives every 1/10 of a minute for the entire duration of peak time. The second test used a random approach where the requests arrived randomly during peak period.

The number of channels required to satisfy all the requests during peak time for a conventional VoD system and the server 2 using the BEVA process were compared. The graph in Figure 3 shows the number of channels required if new requests keep arriving at a uniform rate that is equal to the peak rate. In this case, the peak rate is set to 1 request/minute and the average length of video title is set to 2 hours. The continuous graph 30 shows the number of channels required for a conventional VoD system and the dotted graph 32 shows the number of channels required by the server 2. The channel requirements are reduced substantially by the use of the BEVA process. The amount of bandwidth that can be saved depends on how long the peak period lasts. Statistics obtained from existing VoD trials show that peak period usually lasts for about 2 hours. Based on this, 120 requests would need to be served in the 2 hours of peak traffic as a peak rate of 1 request/minute or 60 requests/hr is assumed. After peak time, the arrival rate would drop to a lower value and bandwidth allocation would not be a problem. From Figure 3 approximately 70 channels would be needed in contrast to the 120 channels required in conventional VoD systems to satisfy the 120 requests. Figure 4 shows the same two graphs using a random arrival pattern. Similar results can be observed in this case. The channel requirements fluctuate because of the random arrival pattern. By varying the arrival rate and the average length of a video title, the results obtained were very similar to those in Figures 3 and 4.

The BEVA process employed by the video server 2 reduces bandwidth requirements and has the advantages of having no associated overheads, not affecting the level of interaction available to a user, and not reducing the efficiency of the system when the level of interaction increases. The amount of bandwidth savings that can be achieved depends on how long the peak period lasts. As can be observed from the graphs in Figures 3 and 4, only in the unlikely case that the peak period lasts for an infinite amount of time, would the BEVA process not result in any savings, hi the usual case when the peak period lasts for 2 hours, BEVA reduces the bandwidth requirements of the system by about 40% as shown in

Figures 3 and 4. In the results obtained, BEVA saved about 50 digital channels for VoD. If

10 digital channels can be accommodated in 1 analogue channel, then the total number of analogue channels saved is 5. This is a significant saving considering the high cost of the entire cable spectrum in a HFC network. These savings can reduce the overall cost of the

VoD system substantially. An important advantage is that the bandwidth savings achieved are not affected by the level of interaction in the system. This is in contrast to most of the existing bandwidth reduction techniques for VoD.

Many modifications will be apparent to those skilled in the art, without departing from the scope of the present invention as herein described with reference to the accompanying drawings.

Claims

CLAIMS:

1. A bandwidth allocation process for a video-on-demand system, including: receiving a new request for a video service; and allocating all available channels to said new request if no other requests are being served, otherwise identifying a previous request having more than one of said channels allocated thereto, and reallocating at least one of said channels allocated to said previous request to said new request.

2. A bandwidth allocation process as claimed in claim 1, including identifying a request with more than one of said channels allocated thereto when a request having less allocated channels is complete, and assigning at least one channel of the completed request to the identified request.

3. A bandwidth allocation process as claimed in claim 2, including assigning all available channels to a subsequent server request when a request with more than one channel allocated thereto is complete.

4. A bandwidth allocation process as claimed in claim 1, wherein said process is executed by a video server at a head-end of said system, said video server serving respective video streams in response to a request.

5. A bandwidth allocation process as claimed in claim 2 or 3, wherein a request is complete when the service has been delivered or delivery has been paused or stopped for a predetermined period of time.

6. A bandwidth allocation process as claimed in claim 1, wherein said video stream is delivered to a network node or equipment of a user requesting the service.

7. A bandwidth allocation process for a video-on-demand system, including performing when a new request RN for a video stream arrives at a video server of said system: if there are no other requests currently being served by said server then assign all available video stream delivery channels to the request R _; else identify a request Ri with the maximum number of channels assigned; if the number of channels used by Rr is greater than 1 then release at least one channel from the identified request Ri and assign to the request R_N; else refuse the request RN. endif endif

8. A bandwidth allocation process as claimed in claim 7, including performing when a request Re is completed: if there are other requests being served by said server then if the request Re had one channel assigned then identify a request Ri with more than one channel assigned and assign the channel of request Re to request R_τ; elseif Re had more than one channel assigned assign all channels of Re to a next request that is not complete; endif elseif there are no other requests being served mark all channels as free channels; endif

9. A bandwidth allocation process as claimed in claim 7 or 8, wherein said available channels are from said video server to a serving network node of said video-on-demand system.

10. A bandwidth allocation process as claimed in claim 1 or 9, wherein said streams are delivered using the DVB protocol.

11. A video-on-demand system including a video server for serving video streams in response to requests from equipment of users, said server being adapted to execute a bandwidth allocation process as claimed in any one of the proceeding claims.

12. A system as claimed in claim 11, having a head-end including said video server, and a number of network nodes for sending said streams to said equipment.

13. A system as claimed in claim 12, wherein said equipment comprises a STU.

14. A system as claimed in claim 12, wherein said head-end, said nodes, and said equipment are connected by a HFC network.

15. Management software for a video-on-demand server, stored on memory and for performing a bandwidth allocation process as claimed in any one of claims 1 to 10.