A Hierarchical Video-on-Demand System for ATM ... - Semantic Scholar

Proc. Natl. Sci. Counc. ROC(A) Vol. 23, No. 3, 1999. pp. 369-381

A Hierarchical Video-on-Demand System for ATM Networks R EN -H UNG HWANG

AND

M IN -X IOU CHEN

Department of Computer Science and Information Engineering National Chung Cheng University Chiayi, Taiwan, R.O.C. (Received February 5, 1998; Accepted August 31, 1998) ABSTRACT Video-on-Demand (VOD) is expected to be the key residential service in the near future. A VOD system consists of three components: the VOD server, the transport network, and the end user. In this paper, we focus on the design of the network module of a VOD system. We propose a hierarchical VOD network structure which can be used to achieve a low cost, high performance, high scalability, and high reliability VOD system. In this hierarchical VOD system, the level-2 gateway is the most important element. All video streams retrieved from storage systems are pumped by the level-2 gateway to clients. In this paper, three mechanisms are proposed for pumping video streams with throughput, jitter, and delay guarantees. First, due to the large variety of traffic characteristics of Motion Pictures Expert Group-1 (MPEG-1) video streams, we propose to transmit an MPEG-1 video using the Piecewise Constant Rate Transmission and Transport (PCRTT) technique. Second, to guarantee throughput, and to avoid jitter, and delay, a new traffic control algorithm, referred to as the Modified Generic Cell Rate Algorithm (MGCRA), is proposed. Finally, the call admission function is implemented based on PCRTT rates and dynamic Virtual Path (VP) bandwidth allocation. The proposed architecture and mechanisms have been implemented and are shown to be a practical and efficient solution for large scale VOD systems. Key Words: Video-on-Demand, ATM, hierarchical VOD, MPEG

I. Introduction Due to the availability of enormous communication bandwidth and computing power, processing and delivering multimedia data to users in real time is becoming practical. With the advent of multimedia technology, we can expect that Video-on-Demand (VOD) will become the key residential service in the near future. A VOD system consists of three components: the VOD server, the transport network, and the end user. These three components pose different challenges to system designers. Therefore, many researches have focused on one of these components. For example, Sincoskie (1991), Chang et al. (1994), Deloddere et al. (1994), and Little and Venkatesh (1994) proposed general system architectures for a VOD system, Nussbaumer et al. (1995) discussed the configuration of the transport network, Wu et al. (1996), and Tseng and Huang (1994) described how to design high performance VOD servers, and Hsieh et al. (1995) showed how to implement a mass storage system for a VOD system. In the past two years, we have been implementing a VOD system over Asynchronous Transfer Mode

(ATM) networks. We propose a three-level hierarchical network architecture, as shown in Fig. 1, to achieve a low cost, high performance, high scalability, and high reliability VOD system. One of the major costs in deploying a VOD system is the cost for transmitting video streams to users. In the proposed architecture, three-level VOD servers are distributed in an ATM Wide Area Network (WAN). By storing the most

− 369 −

Fig. 1. The hierarchical VOD system architecture.

R.H. Hwang and M.X. Chen popular movies on those servers which are nearest to the VOD clients, referred to as neighborhood servers, most clients’ requests can be served by neighborhood servers. As a consequence, the transmission cost can be reduced. To achieve high performance, real-time control mechanisms (Kao et al., 1996) and high performance Redundant Array of Inexpensive Disk (RAID) systems (Lee and Chen, 1996) are adopted in the implementation of a VOD server. Furthermore, the quality of video streams, pumped by VOD servers and received by VOD clients, must be guaranteed. The level-2 gateway shown in Fig. 1 is responsible for providing such guarantees through ATM services. Two types of video are provided in our VOD system, namely, MPEG1 and MPEG-2 video. MPEG-2 video streams require Constant Bit Rate (CBR) service while MPEG-1 video streams require Variable Bit Rate (VBR) service. The quality of playback video at VOD clients depends on stringent control of jitter. However, it is very difficult to provide a jitter control guarantee for VBR traffic on ATM networks. Therefore, the PCRTT technique is adopted, which divides an MPEG-1 video into several segments, where each segment can be transmitted using CBR. The deployment of VOD service requires that a large number of simultaneous VOD clients be supported. Therefore, scalability is a very important issue in designing a VOD system. Instead of emphasizing the design of a single super server which serves a large number of clients, the proposed hierarchical network structure can support a huge number of VOD clients using low cost VOD servers. Finally, fault tolerant mechanisms are required to prevent service interruption due to network or server failure. Possible fault tolerant mechanisms include fault tolerant servers (Yang et al., 1997) and self-healing ATM service based on the virtual path technique (Huang and Hwang, 1995).

Fig. 3. Storage system .

In this paper, we focus on implementation issues related to the transport network of our VOD system. We will briefly describe the architecture of the proposed VOD system in Section II. Two transport protocols will be proposed for the hierarchical VOD system in Section III. In Section IV, we will focus on design issues related to the level-2 gateway especially, how to guarantee high quality service for video streams. The design issues related to the level-1 gateway will then be presented in Section V. The performance of a prototype of the proposed system is presented in Section VI. Finally, Section VII will give a conclusion for this paper.

II. System Architecture A VOD system consists of three components: the VOD server, the transport network, and the end user. In this section, we will describe the architecture of each component.

1. VOD Server Figure 2 shows the architecture of an ATM-based VOD server. It consists of three major components, namely, the storage system, the server control system, and the level-2 gateway. Their functions are described in the following subsections, respectively.

A. Storage System

Fig. 2. Architecture of an ATM-based VOD server.

A VOD system requires a large number of storage devices for storing video files since storing a 90-minute MPEG-1 video requires more than 1 GB disk space. Many researches (Wu et al., 1996; Lee and Chen, 1996) have shown that the bottleneck in a storage system is not the bandwidth of the system bus, but the low mechanical delay of the disk, which includes seeking delay and rotation delay. Therefore, a distributed stor− 370 −

A VOD System on ATM Networks age system must support a large number of simultaneous video streams. Figure 3 shows the architecture of our storage system, which consists of more than one storage station. Each storage system has a microprocessor and more than one Small Computer System Interface (SCSI) controller. Each SCSI controller is connected to a disk array. A streaming RAID technique (Tobagi et al., 1993) is adopted to achieve high throughput. The basic idea is to maximize the parallelism of disk reads among different levels of disk arrays. The first level is used to perform multiple disk reads from the disk array on the same SCSI controller. The second level is used to perform multiple disk reads on a “disk cluster” formed by the SCSI controllers of a storage station. Finally, more than one storage station can read from disks simultaneously. The readers are referred to Lee and Chen (1996) for the detailed implementation of the storage system. After one block of video data is read from the disk, it is transmitted to the level-2 gateway on high-speed media. If the server is implemented on a tightly coupled distributed system, the video data can be transmitted on a HIgh-Performance Parallel Interface (HIPPI) or fiber channel. If the server is implemented on a loosely coupled distributed system, the video data can be transmitted by a high-speed Local Area Network (LAN), such as Fast Ethernet, Gigabit Ethernet, Fiber Distributed Data Interface (FDDI) or ATM.

B. Server Control Unit The functions performed by the server control unit include: (1) admission control of user’s requests; (2) video session control such as pause/resume, fast forward, rewind, and stop; (3) control of storage stations; (4) server control, such as load balancing and fault tolerant. Simple admission control is performed by the server control to make sure that the video requested by a VOD client is stored on the storage system of this server, and that the number of requests for this video does not exceed the maximum number of simultaneous accesses allowed. After the request is admitted, the server control unit is responsible for pumping video data from the storage system to the level-2 gateway at constant bit rate. The rate of pumping an MPEG-1 video will be discussed later. The server control unit is also responsible for processing video control commands received from VOD clients. For example, the server control unit will stop pumping video data when a pause command is received. Finally, the server control unit can be implemented by a group of servers

such that when one of the servers is down, its jobs can be migrated to other servers to prevent service interruption (Yang et al., 1997).

C. Level-2 Gateway There are two major functions performed by the level-2 gateway. First, it receives requests from VOD clients and forwards them to the server control unit. Second, it transmits video streams to VOD clients with a quality of service guarantee. The later is a big challenge. The Quality of Service (QOS) required for video data includes guaranteed throughput and bounded delay jitter. To cope with variable-bit-rate MPEG-1 video streams, the PCRTT technique is adopted. Furthermore, admission control on the number of video streams is also performed at the level-2 gateway to ensure that the QOS requirements of all video streams are satisfied. A detailed description of how to implement a level-2 gateway will be given in Section IV.

2. Transport Network The transport network is responsible for transmitting video streams from VOD servers to VOD clients. Three features are required for a good transport network: long distance (wide area), large bandwidth, and provision of a QOS guarantee. The transport network needs to support long distance and large bandwidth transmission because our goal is to design a wide area, large scale VOD system. Most importantly, the transport network must be able to provide a maximum transfer delay and a bounded delay jitter guarantee because video streams are continuous media. Since 1987, the ATM technique has been recognized as the target transport technique for future Broadband Integrated Service Digital Networks (BISDN). ATM networks have all the features required for the transport network of our VOD system. In particular, ATM networks support four classes of traffic: CBR, real-time and non-realtime VBR (rt-VBR, nrt-VBR), Available Bit Rate (ABR), and Unspecified Bit Rate (UBR) (ATM Forum, 1996). Among them, CBR and rt-VBR are suitable for transmitting video streams since the cell loss rate, maximum cell transfer delay, and cell delay jitter can be guaranteed. However, due to the difficulty of modeling the traffic source, it is still an open question as to how a QOS guarantee for VBR traffic can be provided. Therefore, in our implementation, video streams are transmitted on ATM as CBR traffic.

3. VOD Client

− 371 −

The VOD clients are responsible for providing

R.H. Hwang and M.X. Chen user friendly graphical interfaces for video program selection, VCR-like control functions, and smooth video play back. All these functions are supported via a settop box. Due to the prevalence of the World Wide Web (WWW), we have implemented a plug-in function that allows users to browse and select video programs through the WWW. After the user has made a selection, the request will be sent to the VOD server, and a returned acknowledge will trigger the set-top box to play back the video stream transmitted by the server. For smooth play back with constant bit rate, the settop box is equipped with 1 to 2 MB of RAM. There are many ways to connect a set-top box to the transport network. For example, it can be connected via Common Antenna Television (CATV) or Asymmetric Digital Subscriber Lines (ADSL). In our experiment, high speed LANs, such as FDDI or Fast Ethernet, were used to connect VOD clients to the transport network. Since the local network and the transport network do not need to be the same type of network, a gateway, referred to as the level-1 gateway, is needed to interconnect these two networks. The functions of a level-1 gateway include transfer of user requests from VOD clients to the level-2 gateway and of video streams from the level-2 gateway to VOD clients.

4. Operation Overview Let us describe a scenario for how a VOD client can select and play back a desired video program: (1) Via a set-top box, a VOD client first connects to a WWW server to browse the menu of video programs. The information on the WWW server may include video titles, brief introductions, video clips, etc. The client then chooses a desired video program. The WWW server then sends the video identifier and the name of the level1 gateway to the client and invokes a signaling procedure to be performed at the client’s set-top box. (2) The set-top box sends a request, which contains the video identifier, to the level-1 gateway using the User Datagram Protocol (UDP). (3) Upon receiving the request, the level-1 gateway checks its database to select the corresponding level-2 gateway and VOD server. The video programs are stored in three levels of VOD servers according to their popularity. The most popular movies are stored in the neighborhood server which is nearest to the client. The less popular movies are stored in a local server which serves several regions and is farther away from the client than the neighborhood server. Finally, the − 372 −

rest of the movies are stored in the central server which is the farthest from the client. The database at the level-1 gateway is updated when the movies stored in each server have changed, for example, when new movies arrive. Note that the selection of a level-2 gateway is transparent to clients. This offers flexibility of design and placement of VOD servers. The level-1 gateway then forwards the user’s request to the selected level-2 gateway. (4) Upon receiving a request, the level-2 gateway forwards the request to the server control unit, which searches for the storage system that can provide service. The PCRTT technique is used to transmit MPEG-1 movies. The server control unit keeps a profile for each movie which records details of rate changes. Based on this profile, the server control unit will admit a request only if the storage system has enough capacity to pump this video. If the request is admitted, the server control unit sends a QOS-request packet with the profile of the video to the level-2 gateway. (5) Upon receiving the QOS-request packet, the level-2 gateway then checks if the network has enough bandwidth to transmit the video. The admission control algorithm will be described later. If the network has enough bandwidth, the level-2 gateway forwards the QOS-request packet to the level-1 gateway. (6) Upon receiving the QOS-request packet, the level-1 gateway then checks if the local area network has enough bandwidth to transmit the video. Depending on the underlying high-speed LAN that connects the client to the level-1 gateway, the level-1 gateway may or may not be able to provide deterministic QOS guarantee. If the network has enough bandwidth, the level-1 gateway sends a request-success packet back to the level-2 gateway. (7) The level-2 gateway establishes an AAL 1 connection with the level-1 gateway and sends a request-success packet back to the server control unit. (8) The server control unit then sends a requestpermitted packet to the client and sends commands to the storage system at the speed defined by the profile of the video. (9)The video program is then pumped from the storage system to the level-1 gateway through the level-2 gateway. (10) The level-1 gateway then forwards the video data to the corresponding client via UDP. The advantage of using level-1 and level-2 gate-

A VOD System on ATM Networks

Fig. 4. VCP packet format.

ways is that doing so makes the transport network transparent to clients and servers. Therefore, a client can be served by different levels of servers without realizing their exist while a server can serve any clients without noticing which level of server it is.

Initially, a client is in the idle state. When it receives a request command from the user, it sends the REQC command to the level-l gateway, enters the listen state, and waits for a SUCC response from the server. If it receives a SUCC response, it then enters the play state and starts to play the received video data. On the other hand, if it receives a REJECT response or does not receive any response after timer T2 timeout, it assumes that the server is not available at this time and returns to the idle state. In the meantime, if it does not receive any responses from the server, it will retransmit the REQC command again after timer T1 timeout. The user is able to switch between play mode and pause mode by sending RESUME and PAUSE commands to the server. If it receives a STOP request from the user,

III. Transport Protocols Two transport protocols will be proposed for transmitting control commands and video streams between users and servers. The first protocol, the Video Control Protocol (VCP), is designed for communications between users and servers. The second protocol, the Video Transfer Protocol (VTP), is designed for transmitting video data from servers to clients. In the following, we will describe these two protocols in detail.

1. VCP The packet format for VCP is shown in Fig. 4. The VERSION is the version number of the current VCP. The first bit of COMMAND indicates whether it is a request (sent from a user) or reply (sent from a server). Request commands include: connection requests (REQC), pause (PAUSE), resume (RESUME), fast forward (FF), rewind (REW), stop (TERMREQ), and QOS requests (QOSREQ). Reply commands include: success (SUCC), reject (REJECT), and confirm stop/abort (TERM). The sequence number provides a unique identification for each VCP packet. The IP address and UDP port number of the client are used in receiving video data from the level-1 gateway through the UDP protocol. The Internet Protocol (IP) address and ATM Adaptation Layer (AAL) port number of the level-1 gateway are used by the level-2 gateway to establish an AAL 1 connection with the level-1 gateway. The VCP header is followed by supplementary data required by request commands. For example, it contains the movie identification in a connection request command and the QOS profile in a QOS request command. Figure 5 shows the VCP protocol for VOD clients. − 373 −

Fig. 5. VCP protocol for client.

Fig. 6. VCP protocol for servers.

R.H. Hwang and M.X. Chen it sends a TERMREQ command to the server and waits for a TERM response from the server for confirmation. If the video ends normally, the server will send a TERM message to the VOD client, which will cause it to return to the idle state. Figure 6 shows the VCP protocol for VOD servers. The state diagram is maintained for each connected VOD client. Initially, the server waits for a REQC command from a VOD client. It then checks if the server has enough resources to guarantee the QOS of the requested video. If it does, the server, then sends QOSREQ to the level-2 gateway to ask for a QOS check. If it receives a SUCC response from the level-2 gateway, it starts to send commands to the storage to pump the video data to the client. On the other hand, if either the server or the level-2 gateway cannot provide a QOS guarantee for the requested video, a REJECT message is sent back tothe client. The server stops pumping video data and enters the pause state if it receives a PAUSE command from the client. Finally, it sends a TERM message to the client if the video ends normally or if it receives a TERMREQ command from the client. Figure 7 shows the VCP protocol for level-1 gateways. Initially, it waits for REQC commands from clients. If it receives a REQC command from a client, it checks the database and forwards the command to the corresponding level-2 gateway. If the server and level-2 gateway are able to provide the requested video with guaranteed QOS, the level-1 gateway will receive the QOSREQ command and check for a QOS guarantee

Fig. 7. VCP protocol for level-1 gateways.

Fig. 8. VCP protocol for level-2 gateways.

in the user access network. If the level-1 gateway is able to provide the QOS guarantee, it sends a SUCC command to the level-2 gateway and waits for the level2 gateway to establish an AAL 1 connection. If a SUCC message is then received, the server has granted the request, and the level-1 gateway will send a SUCC message to inform the client. On the other hand, if the QOS cannot be guaranteed at the server or the level1 gateway, a REJECT message is sent to the client. Finally, the level-1 gateway sends a TERM message to the client if it receives a TERM message from the server. Figure 8 shows the VCP protocol for level-2 gateways. Initially, it waits for REQC commands from level-1 gateways. If it receives a REQC command from a level-1 gateway, it forwards the command to the server and enters the listen state to wait for the result of the QOS check from the server. If it receives a QOSREQ command from the server, it checks its resources to see if it can provide a QOS guarantee to the requested video. If it can, it then sends a QOSREQ command to the level-1 gateway for a QOS check. If it receives a SUCC response from the level-1 gateway, the request is granted and it will send a SUCC message to the server. The server will then pump the requested video data to the client. On the other hand, if the QOS check fails

− 374 −


Fig. 9. VTP packet format.

at the server, the level-2 gateway, or the level-1 gateway, a REJECT message will be sent to the client. Finally, a TERM message will be forwarded to the level-1 gateway if it receives a TERM message from the server.

2. VTP When a user request is granted, the server control unit will look up the profile of the requested video and send commands to the storage system to request that the storage system transmit appropriate blocks of video data to the clients according to the rate defined in the profile. In the server control unit, there is a real-time process for each connected client, which is responsible for checking the profile and sending commands according to the profile. When the storage system receives a command from the server control unit, it will then retrieve the data block from the disk array and transmit it to the level-2 gateway according to the VTP packet format. The VTP packet format is shown in Fig. 9. Here, the client ID is used by gateways to determine which clients this video packet belongs to, and a timestamp is used as part of the rate and jitter control function at gateways. The sequence number, which is optional, can be used to check if any packets are lost.

IV. Design of Level-2 Gateways One of the most important functions of the level2 gateway is to pump video packets received from the storage system to the level-1 gateway with guaranteed quality of service. The required guarantees include those for throughput, jitter, and delay. For MPEG-1 video streams, the transmission rate varies from time to time, depending on the scenes. The requirement for the guaranteed rate is very stringent since transmitting at too high a rate will cause the client’s buffer to overflow very quickly. On the other hand, transmitting the video at too low a rate will cause the client’s buffer to underflow. A bounded jitter is also desirable since the way to accommodate jitter is to employ a large buffer at the client. However, a large buffer is expensive and not feasible for implementation in a set-top box. Finally, a bounded end-to-end delay guarantee is required to reduce the user’s waiting time. Among

these three QOS guarantees, maintaining the video transmitting rate is the most important guarantee. Unfortunately, most previous researches did not provide such a guarantee. In order to provide throughput, jitter, and delay guarantees, three mechanisms are adopted in the design of level-2 gateways. First, it is extremely difficult to provide a QOS guarantee for MPEG-1 video due to its variable bit rate traffic characteristic. Therefore, for practical reasons, we adopt the PCRTT technique, which partitions an MPEG-1 video into several segments and transmits each segment at constant bit rate. Second, to provide delay and jitter guarantees while maintaining the throughput of a video stream, a new traffic control algorithm is proposed. Finally, admission control based on the PCRTT rate is enforced to provide QOS guarantees to all permitted connections.

1. PCRTT The ideal algorithm for transmitting a video stream from a server to a client sends a video frame every 1/30 second, assuming that the video encoding rate is 30 frames per second. In the our VOD system, the video programs stored in the storage system are MPEG-1 or MPEG-2 encoded. Although the basic unit of an MPEG1 video program is a frame (I-frame, P-frame, or Bframe), the basic unit of the storage system is a data block (2 KB, for example). It is extremely expensive for the storage system to keep frame boundary information due to the variable frame size and the large number of frames per video program. It is even too expensive to simply keep boundary information for a group of pictures. Therefore, it is impossible to have the server to send a frame every 1/30 second because the storage system does not have the concept of a frame. In our VOD system, the server control module commands the storage system to send video data at variable rates, which are specified in number of blocks to be sent per second. It is very important for the server control module to decide on the video data transfer rate because sending video data too fast or too slow will cause the receiver’s buffer to overflow or underflow. Two common methods are employed by VOD servers to transfer video programs. The first one transmits video data at constant bit rate. The other one transmits the video data at variable bit rate. Since MPEG compression technology uses inter-frame compression as well as intra-frame compression, the size of a frame varies dramatically. Therefore, when transmitting video data at constant bit rate, clients must have a very large receiving buffer to avoid buffer overflow or underflow, e.g., at least 20 MB (McManus and Ross, 1996). The

− 375 −

R.H. Hwang and M.X. Chen advantage of this method is that once the transfer rate is determined, the VOD server can set up a Virtual Channel (VC) to the client, usually Switched VC (SVC), with the desired bandwidth allocated. The quality of service will then be guaranteed once the VC is setup. McManus and Ross (1996) proposed a formula to compute the video transmitting rate and satisfy the buffer requirement if an MPEG encoded video program is to be transmitted at constant bit rate. To reduce the buffer space needed at a client, the server needs to transmit the video data at variable bit rate; i.e., the transmission rate is dynamically adjusted according the compression rate of the current video frame. However, if the transmission rate is changed for each video frame, the traffic characteristics will become too complicated to be precisely modeled. Thus, reserving resources for the VC and providing QOS guarantees become very complicated tasks. Therefore, a compromise method is to partition the video program into several segments. Each segment is then transmitted at constant bit rate; however, the transmission rates for different segments may be different. This method was referred to as the PCRTT by McManus and Ross (1996) and was well studied by Salehi et al. (1995). Salehi et al. (1995) provided an algorithm that can partition a video program such that the variable bit rate are optimal smoothing in a stochastic sense. The results of McManus and Ross (1996) and Salehi et al. (1995) cannot be directly applied to our VOD system because they all assumed that frame boundaries are known and that the size of a frame is multiplicative of the payload of an ATM cell. As stated above, such an assumption is impossible for our storage system. We have modified the formulas proposed by McManus and Ross (1996) to fit our VOD system. Let us first describe two lemmas proposed by McManus and Ross (1996). McManus and Ross (1996) assumed that the ith MPEG frame can be encapsulated into x i ATM cells. The buffer size at the client’s settop box is B cells. The client starts to play back after the buffer is loaded with the first d MPEG frames. After the client starts to play back, a frame is retrieved from the buffer every 1/F second. The total number of frames in the video program (or segment) is N. Lemma 1. For all d=1...N

b min(d) =

+1 d F (nΣ x – x i) . Σ i d ≤n ≤N –1 n i =1 i =1

Max

Lemma 2. For B>0 and d0, and n is integer. Based on lemma 5 and lemma 6, we can compute the minimum and maximum transfer rate for a video program given the size of the client’s buffer and the number of pre-loaded frames. However, for most video programs, the amount of buffer space at the client needed in order to transmit the whole video program at constant bit rate is too large, e.g., at least 20 MB. In order to reduce the buffer requirement, we can partition the video program into several segments such that each segment can be transmitted at constant bit rate. In the following, we propose an algorithm, shown in Fig. 10, that can partition the whole video program into a small number of segments. The proposed algorithm is a greedy algorithm. It searches for segments from the first frame to the last frame; each time it

Lemma 5. For all d=1...N n +1

b min(d) =

Max

d ≤n ≤N –1

F{ n

Σy i =1 i P

d

–

Σy i =1 i P

}.

Lemma 6. n +1

b max(d, B) =

Min

0 ≤ n ≤ N(B) – 1

F { n +1

Σy i =1 i P

d

–

Σy i =1 i P

+ B} . Fig. 10. The video partitioning algorithm.

− 377 −

R.H. Hwang and M.X. Chen searches for the largest segment that can be transmitted at constant bit rate while requiring a small buffer. In the following, we will briefly give the purpose for each step in the algorithm. Step 1 initializes the variable d to the number of pre-loaded frames. Step 2 and step 3 initialize two variables, start_point and end_point. The first variable, start_point, will record the beginning position of the current segment, and the second variable, end_point, will record the end position of the current segment. The while loop from step 4 to step 20 is the main algorithm for finding a segment and its transmission rate. Step 5 and step 6 find the maximum and minimum transfer rates using lemma 5 and lemma 6. If the minimum rate is less than maximum rate, i.e., step 7 to step 11, this means that this region can be enlarged. Thus, the end_point is increased by 1, and the algorithm goes back to step 4. On the other hand, if the minimum rate is greater than the maximum rate, i.e., step 12 to step 19, this means that there is no suitable rate for the current segment. Thus, the end_point is decreased by 1, and an output function is called to output the minimum rate and maximum rate based on lemmas 5 and 6. Since a packet may contain more than one frame, step 15 calculates the amount of data that does not belong to the current segment. These data are then used as the next region’s pre-loaded data. Step 16 and step 17 adjust the initial values of the two variables to be used to find the next segment. The algorithm then goes back to step 4 and continues to look for and find the next segment until the algorithm reaches the last video frame.

2. A New Traffic Control Algorithm Since the video streams from storage systems are well controlled by the server control unit, the traffic control function focuses on pumping video data to clients with jitter and delay guarantees while maintaining the transmission rate according to the rate defined by PCRTT. The proposed traffic control algorithm, referred to as MGCRA, is based on the generic cell rate control algorithm (GCRA), defined by the ATM forum UNI 4.0 (ATM Forum, 1996), and the jitter-Earliest Deadline First (jitter-EDD) algorithm (Zhang and Keshav, 1991). The details of the MGCRA algorithm are shown in Fig. 11. In the MGCRA algorithm, Ex A ki is the expected arrival time for the ith packet of the kth session. The expected arrival time for the next packet is always increased by X, which is the inverse of the PCRTT rate. A T ki is the actual arrival time of the ith packet of the kth session. If a packet arrives earlier than its expected arrival time, the packet is held for Ahead of time to control jitter. On the other hand, the deadline of a

Fig. 11. The MGCRA algorithm.

packet is always set to its expected arrival time plus the guaranteed nodal delay whether the packet arrives early or late. By setting the deadline in this way, we can control the end-to-end packet delay as well as guarantee the throughput of a video stream at its negotiated PCRTT rate. (Notice that since the PCRTT rate changes from segment to segment, the value of X also changes according to the current PCRTT rate.) The major difference between the MGCRA algorithm and the original GCRA algorithm is that no rate conformance is required in our MGCRA algorithm. The reason is quite obvious: the output rate of a video stream from the storage system is already controlled by the server control unit. Therefore, there is no need for rate conformance control. However, due to the latency of the network or OS, video packets may not be received at the expected time. Therefore, when packets from different video streams are multiplexed into a buffer, the level-2 gateway must transmit packets according to their expected arrival times, computed according to the PCRTT rate.

3. Admission Control Call admission control is required in our VOD server control unit and level-2 gateways to guarantee that the QOS of existing connections will not be disturbed by newly arriving connections. The admission control in the server control unit depends on the processing power, scheduling overhead, and transmission capability of the storage system. The readers are referred to Kao et al. (1996) for details. In the following, we will focus on admission control at level2 gateways. The major function of admission control at level2 gateways is to ensure that the aggregated transmission rate will not exceed the peak rate of the allocated bandwidth on ATM networks. Since the connection set up time is quite long in an ATM WAN, we propose to pre-establish a permanent virtual path with dynamic bandwidth allocation in block size (Ohta and Sato,

− 378 −


Fig. 12. Performance of MGCRA.

1992) between each level-1 and level-2 gateway. For example, initially, a VP may be established with zero bandwidth. When a level-2 gateway receives the first request, it will then try to allocate a block of bandwidth, ∆, e.g., 10 Mbps. (Note that a block is capable of accommodating several video streams.) Now, consider the case where there are K simultaneous connections. Each connection is partitioned into N k, k=1, 2, ..., K, sessions with PCRTT rates {r k1, r k2, ..., r kN } and rate k changes at times {t k1, t k2, ..., t kN } . The rate-change times k of all the sessions are sorted in increasing order, i.e., T={t (0), t (1), ..., t (N)}, where t (0) is the current time and N is the total number of rate-change times of all the sessions. For each time interval, the level-2 gateway can evaluate the required bandwidth by summing up the PCRTT rates of each connection. (The PCRTT rate is set to zero if a connection is not active during that time interval.) When a new request arrives, the level2 gateway inserts the rate-change times into the set T and evaluates the required bandwidth at the same time. If the required bandwidth at each time interval does not exceed the allocated VP bandwidth, the request is granted. On the other hand, if the bandwidth is not large enough, the level-2 gateway will try to allocate one more block of bandwidth on the VP and continue to perform the admission control function. If no bandwidth is available for allocation to the VP, the request is rejected. Since the set of rate-change times for a session is sorted and the set T is also sorted, the complexity of admission control under the worst case is only O(N).

connect to; instead, the level-1 gateway will look up its database to select the “best” server. The “best” choice of server depends on the transmission cost, storage cost, and load balance among servers (Lin, 1997). To provide throughput, jitter, and delay guarantees for transmission of video streams, the MGCRA algorithm and connection admission control function are also implemented in level-1 gateways. However, since clients may connect to a level-1 gateway via highspeed LAN, e.g., Fast Ethernet or FDDI, instead of ATM, MGCRA may not be able to provide the exact guarantee due to the collision-based data link protocol of the high-speed LAN (e.g., Fast Ethernet). The same is true for the admission control. In our experiments, the level-1 gateway was able to pump more than 30 connections on a Fast Ethernet LAN. Due to the low cost of Fast Ethernet, one possible way to solve this problem is to employ a dedicated Fast Ethernet for transmitting video streams and another shared (Fast) Ethernet for transmitting control commands (VCP) and other Internet services.

VI. Implementation We have implemented a prototype of the proposed hierarchical VOD system in our laboratory. Within the server, the control unit, the storage system, and the level-2 gateway were connected via fast Ethernet. VOD clients were also connected to the level-1 gateway via fast Ethernet. Both level-1 and level-2 gateways were implemented on UltraSPARC workstations and connected to a FORE ASX-200 ATM switch. Since we focused on the design of the network module, the performance metrics that we were interested in were the throughput of gateways and the performance of the MGCRA algorithm.

V. Design of Level-1 Gateways The functions of level-1 gateways is to forward control commands between clients and servers, and to pump video streams received from servers to clients with QOS guarantee. With a hierarchical structure, a client does not need to know which server to − 379 −

Fig. 13. Overhead of MGCRA.

R.H. Hwang and M.X. Chen Figure 12 shows the jitters of a sequence of 500 packets observed at a VOD client when there were 20 simultaneous active clients. (Observations were made at a random instants of time.) We can observe from Fig. 12 that when MGCRA was implemented on gateways, the jitter was well controlled within a very small range, as compared to the jitters that occurred without MGCRA control. Implementation of MGCRA causes overhead on gateways, which decreases the maximum number of active clients (i.e., the system capacity). Figure 13 shows the overhead caused by MGCRA. We set the PCRTT rate to 1.57 Mbps and observed the average transmission rate to each client at the level-1 gateway. To guarantee the required video quality, the average transmission rate was kept at 1.57 Mbps. As we can observe from Fig. 13, when there were fewer than 33 clients, the observed average transmission rate to each client was indeed kept at 1.57 Mbps, with or without the MGCRA algorithm. However, when the number of clients exceeded 33, gateways using the MGCRA algorithm could not continue to guarantee a transmission rate of 1.57 Mbps while 34 clients could be guaranteed if MGCRA was not implemented on gateways. Finally, we would expect that the system capacity would be further improved if we implemented the gateway as a module of ATM switches.

VII. Conclusion In this paper, we have proposed a three-level hierarchical network structure to achieve a low cost, high performance, high scalability, and high reliability VOD system. Since the bottleneck in a storage system is the low mechanical delay of the disk, a distributed storage system has been proposed for the scalability of the server. Furthermore, instead of emphasizing the design of a single super server which can serve a large number of clients, the proposed hierarchical network structure is able to support a huge number of VOD clients based on low cost VOD servers. We have especially focused on the design of level2 gateways. Three mechanisms have been proposed for pumping video streams with throughput, jitter, and delay guarantees. First, due to the large variety of traffic characteristics of MPEG-1 video streams, we have proposed transmission of MPEG-1 video using the PCRTT technique. Second, to guarantee throughput, jitter, and delay, a new traffic control algorithm, referred to as MGCRA, has been proposed. Finally, the call admission function has been implemented based on PCRTT rates and dynamic VP bandwidth allocation. With recent advances in ATM technology and the

low cost of high performance personal computers, we believe that the proposed hierarchical VOD system is a very efficient and practical solution. With the goal of using the proposed solution in a commercial product, we are working on fault tolerant mechanisms which are required to prevent service interruption due to network or server failure.

Acknowledgment This work was supported by the National Science Council under research projects NSC 85-2213-E-194-014 and NSC 86-2213E-194-018. The authors would like to thank Prof. S.L. Lee, Prof. T.W. Kao, Prof. R.F. Chang, and Prof. T.F. Chen for their cooperation.

References ATM Forum (1996) Traffic Management Specification Version 4.0. AF-TM 96-0056.00, ATM Forum Contribution, U.S.A. Chang, Y. H., D. Coggins, D. Pitt, and D. Skellern (1994) An opensystem approach to video on demand. IEEE Communication Magazine, 32(5), 68-80. Deloddere, D., W. Verbiest, and H. Verhille (1994) Interactive video on demand. IEEE Communication Magazine, 32(5), 82-88. Hsieh, J., M. Lin, J. Liu, and D. Du (1995) Performance of a mass storage system for video-on-demand. Journal of Parallel and Distributed Computing, 30(2), 147-167. Huang, H. S. and R. H. Hwang (1995) Self-healing ATM networks based on virtual path restoration. Proceeding of National Computer Symposium, Chung-Li, Taiwan, R.O.C. Kao, T. W., C. H. Huang, S. K. Ni, C. H. Wei, W. R. Yang, and M. L. Hsu (1996) The design and implementation of multimedia operating environments. Second Workshop on Real-Time and Media Systems, Taipei, Taiwan, R.O.C. Lee, E. C. and T. F. Chen (1996) Design and implementation of a multimedia storage server using parallel accessing disk arrays. Second Workshop on Real-Time and Media Systems, Taipei, Taiwan, R.O.C. Lin, J. S. (1997) Video Transmission over ATM Networks. MS. Thesis. Department of Computer Science and Information Engineering, National Chung Cheng University, Chia-Yi, Taiwan, R.O.C. Little, T. D. C. and D. Venkatesh (1994) Prospects for interactive video-on-demand. IEEE Multimedia, 1, 14-24. McManus, J. M. and K. W. Ross (1996) Video on Demand over ATM: Constant-rate Transmission and Transport. IEEE INFOCOM, San Francisco, CA, U.S.A. Nussbaumer, J. P., B. V. Patel, F. Schaffa, and J. P. G. Sterbenz (1995) Networking requirements for interactive video on demand. IEEE Journal on Selected Areas in Communications, 13(5), 779-787. Ohta, S. and K. Sato (1992) Dynamic bandwidth control of the virtual path in an asynchronous transfer mode network. IEEE Transactions on Communications, 40(7), 1239-1247. Salehi, J., Z. L. Zhang, J. F. Kurose, D. Towsley (1995) Supporting Stored Video : Reducing Rate Variability and End-to-End Resource Requirements Through Optimal Smoothing. Technical Report 95-98, Department of Computer Science, University of Massachusetts at Amherst, MA, U.S.A. Sincoskie, W. D. (1991) System architecture for a large scale video on demand service. Computer Networks and ISDN Systems, 22,

− 380 −

A VOD System on ATM Networks 565-570. Tobagi, F. A., J. Pang, R. Baird, and M. Gang (1993) Streaming Raid: a Disk Storage System for Video and Audio Files. ACM Multimedia, Anaheim, CA, U.S.A. Tseng, W. and J. Huang (1994) A high performance video server for karaoke systems. IEEE Transactions on Consumer Electronics, 40(3), 329-336. Wu, C. S., G. K. Ma, and B. S. Lin (1996) A scalable architecture

for video-on-demand servers. IEEE Transactions on Consumer Electronics, 42(4), 1029-1036. Yang, W. R., S. K. Ni, Y. H. Liu, and T. W. Kuo (1997) Supporting fault-tolerance and load balancing on video-on-demand servers. Third Workshop on Real-Time and Media Systems, Taipei, Taiwan, R.O.C. Zhang, H. and S. Keshav (1991) Comparison of Rate-based Service Disciplines. ACM SIGCOM, Zurich, Switzerland.

− 381 −