Full-sharing: efﬁcient bandwidth scheduling for video ...

Multimed Tools Appl (2007) 33:131–156DOI 10.1007/s11042-006-0069-4

Full-sharing: efficient bandwidth scheduling for videostreaming over broadband cable networks (BCNs)

Yingfei Dong · Zhi-Li Zhang · David Hung-Chang Du

Published online: 17 November 2006© Springer Science + Business Media, LLC 2006

Abstract Broadband Cable Networks (BCNs) bring high-speed Internet access tohome and make emerging multimedia streaming applications feasible. However,bandwidth contention is still a challenging problem in providing efficient IP-basedVideo-On-Demand (VOD) service on BCNs, due to the lack of effective approachesto exploit the unique characteristics of BCNs. To address the bandwidth contentionissue, we propose an efficient video scheduling technique, called full-sharing schedul-ing in this paper. This technique fully exploits the unique characteristics of BCNsto reduce the bandwidth consumption of video sessions sharing a cable channel offixed capacity, thereby maximizing the number of simultaneous video sessions onthe single channel. Furthermore, we analyze the expected bandwidth and the sessionblocking probability of a video under the full-sharing scheduling. Based on this analy-sis, we design an efficient video assignment mechanism for maximizing the profit of aVOD system in scheduling videos on BCNs. Through both analysis and simulation,we show that our approach minimizes the bandwidth consumption of video sessionscompared with the previous approaches and has significant advantages on BCNs. Theproposed approach is also directly applicable on other broadcast/multicast networks

This work was supported in part by the National Science Foundation under the grantsANI-0073819, ITR-0085824, and CAREER Award NCR-9734428. Any opinions, findings, andconclusions or recommendations expressed in this paper are those of the authors and do notnecessarily reflect the views of the National Science Foundation.

Y. Dong (B)Department of Electrical Engineering, University of Hawaii, Honolulu, HI 96822, USAe-mail: [email protected]

Z.-L. Zhang · D. Hung-Chang DuDepartment of Computer Science, University of Minnesota, Minneapolis, MN 55455, USAe-mail: [email protected]

D. Hung-Chang Due-mail: [email protected]

132 Multimed Tools Appl (2007) 33:131–156

in which clients have sufficient buffer and downstream bandwidth, e.g., satellitebroadband networks.

Keywords Video streaming · Broadband cable networks · Bandwidth scheduling ·Multimedia networks

1 Introduction

The rapid deployment of broadband services allows us to support many multimediaapplications, such as digital broadcasting, on-demand streaming, interactive games,etc. As one of the most popular forms of broadband services, digital BroadbandCable Networks (BCNs) are capable of providing high access bandwidth to home(potentially more than 5 Gbps), considerably higher than other broadband tech-nologies. Furthermore, cable networks have a wide existing infrastructure, whichhas a coverage of more than 90% of households in the US and more than 65% inEurope [3]. Therefore, BCNs have become an important platform for providing on-demand multimedia services to home. However, little research has been publishedin the area of exploring packet-switching techniques (e.g., IP routing) on BCNs toefficiently support on-demand services on fixed-capacity but shared BCN channels.

In this paper, we address one of the important issues in this area and focus onthe efficient video session scheduling problem in providing IP-based VOD serviceover BCNs.Currently a BCN statically allocates a few downstream channels forits VOD service, and clients on the BCN are usually divided into relatively staticgroups. Each group shares a downstream cable channel with a fixed capacity, suchas 27 or 40 Mbps. When the clients of the same group access the VOD service atthe same time, their requests may be delayed or rejected because they competefor the fixed channel bandwidth. This downstream-bandwidth-contention problemat a cable headend is one of the most challenging issues for current cable networkoperators [14]. The challenge here is how to utilize the limited bandwidth of aBCN channel to satisfy as many VOD requests as possible, each of which resultsin transmission of a large amount of data with stringent timing requirements over along period of time.

To address this bandwidth-contention issue, we design an effective bandwidthmanagement mechanism that is capable of satisfying as many VOD requests as possi-ble on a BCN channel by minimizing the bandwidth consumption of each request. Wepropose a full-sharing scheduling approach that exploits the unique characteristics inthe BCN setting, such as fixed-capacity downstream broadcast channels, potentiallarge cache space on Cable Modems (CMs), fairly high downstream bandwidth, andmoderate user populations on BCN channels. As a result, it is capable of maximizingthe sharing among VOD sessions on a channel so that the bandwidth consumptionof these sessions is minimized. Furthermore, we analyze the expected bandwidth andthe session blocking probability of a video under full-sharing, and also design anefficient video channel assignment mechanism for maximizing the profit of a VODsystem over a BCN.

Although various VOD streaming approaches have been proposed (e.g., patch-ing [17, 23], periodic-broadcast [8, 22, 24, 26]), they are mostly designed for theInternet setting, where sharing among video sessions is rather limited because

Multimed Tools Appl (2007) 33:131–156 133

broadcasting/multicasting on the Internet is not widely supported due to complexityand cost. In addition, those approaches generally assume that clients have fairly lowreceiving bandwidth and rather small buffers. In other words, they do not explicitlytake advantage of the unique sharing and buffering capabilities in a BCN setting, andthus they are generally less efficient when used on BCNs. In contrast, our approachfully exploits the unique characteristics of BCNs so that the bandwidth consumptionof video sessions is minimized.

The remainder of this paper is organized as follows. In Section 2, we introduce acommon BCN architecture and a VOD model on BCNs. In Section 3, we describe theproposed full-sharing scheduling algorithm, and evaluate its performance throughanalysis and simulation. In Section 4, we analyze the expected bandwidth and the ses-sion blocking probability of a video under full-sharing scheduling and further presentan efficient video assignment mechanism. We conclude this paper in Section 5.

2 Common BCN architecture and VOD model

2.1 Common BCN architecture

Figure 1 shows the common BCN architecture, consisting of headends, distributionhubs, fiber nodes and CMs. At the top level, an area headend usually connects to afew distribution hubs (typically five) through an OC-12 or OC-48 fiber loop. At thesecond level, a hub is connected to as many as 40 fiber nodes with an OC-3 (or OC-12)fiber loop (or mesh). A fiber node usually supports up to 500 CMs through a coaxialcable at the bottom level. Generally, a headend serves up to 100,000 CMs, and a hubsupports up to 20,000 CMs. The typical frequency range of a coaxial cable is up to750 MHz (or 1 GHz), in which the frequencies from 5 to 42 MHz are usually assignedfor upstream signals, and the frequencies from 50 to 750 MHz are allocated fordownstream signals. These downstream signals are further partitioned into 6-MHzcable channels using frequency-division multiplexing. While the upstream spectrum

Fig. 1 Architecture of a classical BCN


of a coaxial cable is much smaller than the downstream spectrum because the currentbusiness model assumes that upstream traffic is much less than downstream traffic.

A Cable Modem Termination System (CMTS) placed at a hub or a headend1

manages all CMs in a Media Access Control (MAC) domain, and routes link-layerframes to the CMs. Currently, a MAC domain is restricted to a single cable channeldue to the limitation of CMTS linecards. Between a CMTS and a CM, Data OverCable Service Interface Specification (DOCSIS) [6], the dominant MAC protocolin BCNs, is used for transmitting link-layer frames over a Hybrid-Fiber-Coaxial(HFC) network. A CMTS sends downstream frames to a CM based on the uniqueCM identifier assigned during initialization. As a downstream channel is a sharedmedium, a CMTS broadcasts downstream frames to CMs on the channel, and it canalso easily divide the channel into logical subchannels for a group of CMs. In otherwords, each CM thus has the capability to simultaneously receive broadcast datafrom all the subchannels of the cable channel to which the CM is attached.

A CM acts as a bridge, which encapsulates Ethernet frames generated by a hostat home into DOCSIS frames, and forwards them to its CMTS over a HFC network,and vice versa. After the CMTS receives the DOCSIS frames, it decapsulates themback into Ethernet frames, and then forwards these frames to their destinations.During initialization, a CM obtains an IP address (usually through DHCP), serviceidentifier(s), and downstream- and upstream-channel descriptions from its CMTS.In the current DOCSIS, a CM is rather statically attached to a MAC domain afterit is booted up. As a result, it is generally restricted to a single downstream cablechannel of the MAC domain, which has a typical capacity of 27 or 40 Mbps (via 64-or 256-level Quadrature Amplitude Modulation).

As TV programs are going to be mandatorily digitized soon, digital BCNs aregaining a wider market. In a digital cable network, a Set-Top Box (STB) is usuallyused to decode MPEG programs into standard TV NTSC signals. This STB generallyhas a large cache. For example, a TiVo box can hold more than 40 h of programs [25].In the mean time, as the broadband service over BCNs becomes more prevalent, aunified box is expected to replace the current two boxes (STB and CM) at home.It is foreseeable that a CM is capable of sharing a large buffer with other digitalbroadcasting devices.

2.2 VOD model on a BCN

In a VOD system on a BCN, a server usually sits at a headend and delivers videosto clients via a downstream cable channel. This channel is often further dividedinto subchannels for serving individual requests. Once a VOD session is started, ittypically lasts until the video is ended. To efficiently utilize the channel bandwidth,a VOD server generally employs certain mechanisms to exploit data-sharing amongconcurrent video sessions. As a result, a VOD client usually shares partial data fromother sessions and receives other data through a specific transmission from the serverfor its own request. Because popular videos may be accessed by many clients at thesame time, exploiting data-sharing among these sessions is critical for a VOD system.

1In some cases, a CMTS sits at a headend. However, this requires to bring all upstreams to theheadend, which is expensive because it increases the upstream pipe size between a hub and aheadend.


Due to the broadcast nature of a cable channel, common data can be easily sharedamong concurrent sessions via data prefetching and caching. However, because ofthe limited bandwidth of a channel and the long duration of videos, when manyclients simultaneously access the VOD service on a cable channel, their requests maybe delayed or dropped. Thus a major challenge in the design of a VOD system on aBCN is how to efficiently serve as many VOD requests as possible given fixed channelcapacity.

The VOD model on a BCN has several unique characteristics that are differ-ent from the commonly studied Internet VOD setting. Firstly, although a CM isrestricted to a single downstream cable channel of its MAC domain, it is capableof receiving data from all the subchannels of the downstream cable channel. Thisbroadcast capability of a cable channel provides more sharing opportunities amongsessions on the channel, while data sharing among sessions is fairly expensive andrather limited in the Internet setting. Secondly, a CM potentially has a large bufferthat allows it to prefetch and cache a large amount of data (up to an entire video),while in the Internet setting, researchers often assume that a client has a rathersmall buffer, relative to the large size of a video. Thirdly, the access frequency ofa popular video on a cable channel is moderate, as the client population on a channelis limited (usually 200 to 2,000 active clients at the same time) and many videos maybe streamed on the same channel. In the Internet setting, the access frequency of avideo can be remarkably high, as the client population could be extremely large.Furthermore, clients on a BCN are fairly statically assigned to a channel, whileclients in the Internet setting may dynamically join/leave different VOD channels.In addition, as the same cable channel may be shared by many videos, we cannot indiscriminately reserve bandwidth for individual videos on a cable channel,while most previous broadcast approaches in the Internet setting require bandwidthreservations. Lastly, we have separated devices for receiving and viewing videos inBCNs. In almost all the previous settings, a client acts both a receiver and a player.However, a client in BCNs, a CM or a STB, serves as a receiver only, which is abuffering device dedicated to a player at another node of the same LAN. Becausethey are on the small home LAN, it is relatively easy for the CM/STB to forwardthe stream to a player at another node around the playback rate of a video. Dueto these unique characteristics, we need to develop specific approaches to meet thechallenge of supporting as many simultaneous VOD requests as possible with thelimited capacity of a cable channel.

2.3 Related studies on video streaming

In the following, we introduce existing VOD approaches and discuss their differencescompared with the proposed full-sharing approach. Existing VOD approaches canbe classified into server-initialized (or data-centered, server-push) approaches suchas periodic-broadcast [8, 22, 24, 26], and client-initialized (or on-demand, client-pull)approaches such as batching [1, 5], patching [12, 17], merging [9], etc.

In a server-initialized broadcast approach, a server decides its broadcast scheduleswithout considering individual request arrivals. Such a broadcast approach usuallydivides a video into segments and broadcasts these segments on fixed channels peri-odically. For example, in Pyramid Broadcasting [26], a video is divided into segmentswith increasing sizes and transmitted in logical channels of the same bandwidth.


Other approaches in this family have been proposed to further reduce the band-width and buffer requirements on clients and servers, such as Permutation-basedPyramid Broadcasting [2], Skyscraper Broadcasting [16], Fast Broadcasting [19],and Fibonacci Broadcasting [13, 27]. To address the issue of relatively large client-buffer requirement of pyramid-based broadcasting, Harmonic Broadcasting [18] wasproposed, which divides a video into equal-size segments and transmits the segmentsin logical channels with decreasing bandwidth. Furthermore, a hybrid approach ofpyramid-based and harmonic-based has also been proposed [20].

Broadcast approaches are designed for videos with extremely high accesses, andrequire to reserve bandwidth for individual videos. However, because only a singleBCN channel is available for a group of clients in the current BCN setting andmany videos are usually delivered over a channel, reserving a portion of the channelbandwidth for a video will dramatically decrease the number of videos supported onthis channel. In addition, the access frequency of a video on a BCN is usually nothigh, because the client population sharing a single channel is usually fixed, say 200to 2,000. Therefore, broadcast approaches are usually not appropriate to the BCNsetting.

In a client-initialized approach, a server schedules a new session for a request asin patching or a group of client requests as in batching. When directly applied on aBCN, the previous client-initialized approaches such as batching, patching, mergingand bandwidth skimming generally can not maximally exploit data sharing, sincethey are designed for clients with rather limited receiving and buffering capabilities.In contrast, a CM on a BCN channel can receive from all subchannels at 27 or40 Mbps, such that it allows more efficient sharing to be achieved. In batching, aclient makes a request and then waits until the video is transmitted on a channel;when a channel is available, a server selects a batch of pending requests for a videobased on a scheduling policy, and then transmits the video on the channel. A batchingscheme does not share data between two batches of requests, even when they haveconsiderable overlaps, while full-sharing allows the later batch to obtain most clipsfrom the earlier batch on a BCN channel. In patching, a client not only joins amulticast for buffering the ongoing stream for later playback, but also demands themissed beginning portion of the video through a unicast from a server. A patchingscheme always restarts a continuous video stream (from its beginning) because itonly allows to share continuous video streams; in a full-sharing approach, it is notnecessary to restart a continuous video stream, because discrete clip sets can beshared from all subchannels and only the missing clips need to be sent. Besides, apatching approach limits a client to receive clips from two video streams (a completevideo stream and a partial video stream). If applied on a BCN channel, the highreceiving capability of a CM is under-utilized.

Multistream patching and merging-tree schemes were proposed to allow a clientto exploit more than two streams. Multistream patching (or lambda-patching) [12]is a hybrid of patching and periodic-multicast. It uses multiple patching streams tofurther reduce the size of unicast stream in patching. One potential drawback ofthis approach is the difficulty to determine its multicast cycle. Because the approachmulticasts patching streams in each cycle without considering whether the stream hasbeen requested or not in the cycle, it may cause extra data repeatedly delivered whenclient requests arrive unevenly (or in bursts) across multicast cycles. Another issue ishow to dynamically adjust the multicast cycle when the request pattern of a video is


changed. In contrast, full-sharing delivers each clip based on client requests and doesnot send any extra data. A merging-tree scheme [9] (such as hierarchical multicaststream merging, HMSM) tries to maximize the sharing of different tree branches(sessions). However, because it uses a greedy heuristic for merging a session to itsclosest previous session, some portion of a video is still repeatedly delivered before atree branch is merged to another, as illustrated in Fig. 3. In contrast, these redundanttransmissions can be avoided under full-sharing, as shown in Fig. 9.

3 Full-sharing scheduling for VOD service on BCNs

In this section, we present the details of full-sharing and further evaluate its perfor-mance via both analysis and simulation.

3.1 Definitions and problem formulation

We first lay out several important assumptions and define a few terms used in therest of this paper. Without loss of generality, as in most of the previous studies [9, 11,15, 23], we consider the scheduling of each video individually, since data-sharing canbe achieved only among the sessions of the same video. We assume that each CMhosts at most one VOD client, and the client generates a new request only after itsprevious request has been serviced. We also assume that a VOD system serves clientrequests in a First Come First Serve (FCFS) manner, and it delays the service of arequest (instead of dropping it) when it cannot schedule a session for the request dueto bandwidth constraints.2 Also, once a video session is scheduled (or admitted), therequired bandwidth in each interval of the session has been allocated so that it has acontinuous playback until it ends.

To reduce management costs, we divide the global time into intervals of T1

minutes each. When a request for a new video session arrives in the current interval,the VOD server attempts to schedule the start of the session at the beginning of thenext interval, if possible. Consider a video with a CBR rate of b Mbps and a durationof L minutes, we partition it into a set of Lc = �L/T1� clips, denoted as V = {ck|k isthe clip index, 1 ≤ k ≤ Lc, and ck has a length of T1 minutes }. We define a video clipas a sharable clip if it has been scheduled for delivery in an ongoing session, but canbe cached by a late-arriving session of the same video before its playback time in thislater session.

To serve a client request for a video, we first identify the sharable clips that canbe obtained from ongoing sessions of the video and generate a clip-sharing schedulefor this request, which is used by the client to receive these sharable clips. We alsoschedule a transmission session to deliver the non-sharable clips of the video tothe client. For example, consider a request for a video which arrives at interval ai.Suppose that the requested video session is scheduled to start at interval ai. The clientobtains the sharable clips from the ongoing sessions based on a clip-sharing schedule

2To reduce the service delay of this kind, in an extended approach we will let a server to send thefirst clip immediately (if possible) and schedule the remainder of the video to be delivered at thebeginning of the next interval.


Ri, where Ri = {(k, t)| the kth clip of the video can be received at interval t by sharingfrom the transmission for a previous request, and ai + 1 ≤ t ≤ ai + Lc}. Notice thata client can start to cache clips delivered for ongoing sessions right in interval ai + 1,instead of waiting until its transmission starts in interval ai. Meanwhile, the servertransmits the non-sharable clips of the video to the client based on a transmissionschedule Si, where Si = {(k, t)| the kth clip of the video is delivered from a serverfor request i at interval t, and ai ≤ t ≤ ai + Lc}. The complete receiving schedule,R∗

i = Si ∪ Ri, and |R∗i | = Lc, is sent to the client before the video session is started.

We define the bandwidth consumption of the request as BSi = |Si| · b , where |Si| isthe number of non-sharable clips that are delivered specifically to the client for itsrequest, and b is the CBR rate of the video. Let di denote the service delay of therequest. Then di = ai − ai. We define the mean service delay of all requests during

a time period T as D =∑K

i=1 di

K , where K is the total number of requests serviced inT. Given a threshold of client-tolerable service delay, denoted by T H (in minutes),P(di > T H) represents the probability that the service delay of a request exceeds thethreshold T H.

Based on these definitions, we now formulate the optimal scheduling problem forserving VOD requests (of a single video) with minimum bandwidth consumption.Suppose that K requests of a video arrive at a1, a2, · · · , aK on a cable channelin a time period T, respectively. We assume that we do not know these arrivaltimes a priori. Clearly, in order to simultaneously support as many VOD requestsas possible on a cable channel with a fixed capacity, the bandwidth consumptionof each request should be minimized. We would like to design a video sessionscheduling algorithm such that the total bandwidth consumption of these requests,BS = ∑K

i=1 BSi , is minimized. We propose an algorithm to solve this optimal sessionscheduling problem in the following.

3.2 Full-sharing scheduling for minimizing bandwidth consumption

To minimize the bandwidth consumption of requests, we need to maximumly sharecommon clips among VOD sessions so that a server only needs to transmit as fewerclips as possible for a request. Therefore, exploiting clip-sharing among sessions iscritical. We present the basic idea of full-sharing in the following.

Basic Idea. The concept of full-sharing is mainly based on the unique characteristicsof BCN setting. Because we assume that the mean request arrival rate of a video isknown but exact request arrival times are unknown a priori, a request can share clipsonly from the ongoing sessions of the same video. When a new request arrives, ifother sessions of the same video have already been scheduled on the subchannelsof the same cable channel, the client can cache all the sharable clips not only acrossall ongoing previous sessions, but also from all available discrete clip sets deliveredon the channel. We refer to such a sharing strategy as full-sharing. Intuitively, thisfull-sharing approach results in the minimum number of clips to be transmitted foreach request, as shown in Theorem 1.

The full-sharing strategy works as follows. First, note that to serve a VOD request,each clip in the video clip set V must be received by its playback time. Suppose thatk previous sessions of the video are active at the time when a new request i of thevideo arrives. We first scan all the transmission schedules of the k sessions and find


–

–

–

Fig. 2 Comparison of a full-sharing approach and a patching approach

all sharable clips. We then generate a sharing schedule Ri that includes the indexesof all these sharable clips and their delivery time. Moreover, we determine the set ofnon-sharable clips by Si = V − Ri, and schedule the delivery of each clip in Si by itsplayback time.3

At this point, we would like to use examples to show the differences betweenthe full-sharing strategy from some previous approaches developed in the Internetsetting, in particular, patching. As shown in Fig. 2, the shaded box represents a clipdelivered, a white box represents a clip shared from other sessions, and the dashedlines with arrows represent sharing relations between sessions. For the same threerequests, we show the different schedules under full-sharing and patching. First, inpatching, only a continuous set of clips can be shared. As shown in Fig. 2b, thepatching session 3 only shares the continuous set of clips (including clip 5 to clip8) from subchannel 1. In contrast, full-sharing allows us to gather all discrete sets ofsharable clips, thereby minimizing the number of clips that need to be transmittedfrom the server for a request. For example, as shown in Fig. 2a, the full-sharingsession 3 not only collects clip 5 to clip 8 from subchannel 1, but also obtains clip2 and clip 3 from subchannel 2. Thus no extra copies of clip 2 and clip 3 needto be delivered, while they are required under patching (see Fig. 2b). In addition,unlike patching (and other previous approaches) which typically restricts a clientto a few (e.g., mostly two) subchannels, the full-sharing approach allows a clientto obtain clips from all the subchannels, thus exploiting the broadcast nature of acable channel. For example, the full-sharing session 3 in Fig. 2a gathers clips fromall three subchannels, while the patching session 3 in Fig. 2b only obtains clips fromsubchannel 1 and 3. Moreover, because we schedule each clip to be delivered just-in-time for its playback, this policy maximizes the chances of a clip to be shared by futuresessions. As a result, it minimizes the bandwidth requirement of a future session asshown in Theorem 1. As shown in Fig. 2a, because clip 1 and clip 4 are delivered attheir playback time in the full-sharing session 3, (instead of delivering clip 4 in earlieravailable intervals,) a future request arrived before interval a4 is capable of sharingclip 4 from subchannel 3.

We further illustrate the difference between full-sharing and hierarchical multicaststream merging (HMSM) [9] in Fig. 3. HMSM further extends the idea of patching in

3Because a whole set of clips V is scheduled to be received for the latest session, we can also easilyidentify Si as the set of clips transmitted between the latest arrival and the current arrival in all ksessions, as shown in Fig. 5.


Fig. 3 Comparison of a full-sharing approach and a HMSM approach

a fully multicast setting. The key elements of HMSM are: (1) each data transmissionstream is multicast; (2) clients accumulate data faster than their playback rate; (3)clients are merged into a larger and larger groups; (4) once two transmissions aremerged, the clients listen to the same stream(s) to receive the remainder of the file.Figure 3a is the Fig. 5 from [9], which illustrates the HMSM technique for a set offour requests for a video. In this figure, each stream is transmitted at its playbackrate, and clients have receive bandwidth equal to twice of the playback rate. Oneunit of time on the x-axis corresponding to the total time it takes to deliver the file.One unit of data on the y-axis represents the total data for the file. The solid linesrepresent transmission streams, which always progress through the file at a rate equalto one unit of data per unit of time. Four requests arrive from clients A, B, C, and Dat times 0, 0.1, 0.3 and 0.4, respectively. As shown in the figure, the file is divided into10 segments. Figure 3b shows how the full-sharing satisfy the same set of requests inthe same setting with two differences. First, the delivery of segment s5 in the streamfor client C is avoided in full-sharing. Second, segment s4 is delivered for client D ispostponed until its playback time for client D. As a result, any arrivals between 0.6and 0.7 have a chance to share the clip without requesting it again. We further showthe simulation comparison in Fig. 9.

Full-sharing scheduling algorithm on a fixed-capacity link. We use three basic rulesin the full-sharing scheduling algorithm: (1) to maximally share clips on all subchan-nels of a BCN channel, i.e., a session greedily collects sharable clips from the ongoingsessions of the same video; (2) to minimize the total data transmitted, i.e., only thenon-sharable clips of a video are delivered for a new request; (3) to schedule thedelivery of each clip as late as possible.

The algorithm is given in Fig. 4. Ri represents the sharing schedule for a newrequest i arrived at ai, i = 1, · · · , k, which is generated by scanning all the trans-mission schedules of ongoing sessions of the video, as shown in Lines 1 and 2.Function CLI P(X) is used to obtain a set of clips from a schedule X. CLI P(Ri)

represents the set of clips that are shared from the previous sessions. In Line 3,Aclip = V − CLI P(Ri) represents the set of clips that cannot be shared from ongoingprevious sessions and have to be delivered from the server specifically for thisrequest. We use Si to represent the server transmission schedule of clips in Aclip


FS_ f ixed(ai)

Consider the ith request arrives at ai

1. for (each ongoing session)2. find all sharable clips and add them into

sharing schedule Ri;3. obtain the set of clips to be transmitted,

Aclip = V − CLI P(Ri)

4. set the service time ti to ai + 1 and set Si to empty.5. for (each clip c ∈ Aclip with a playback interval tc = ti + c)6. if (the total bandwidth consumption in tc > C)7. we delay the service for one interval, i.e., ti = ti + 1.8. set Si to empty and go to Step 5 to reschedule

the transmission one interval later.9. schedule to deliver c at its playback interval tc;10. add (c, tc) into the transmission schedule Si;11. send the whole receiving schedule R∗

i to a client,R∗

i = Si + Ri;

Fig. 4 Full-sharing scheduling algorithm on a link with a fixed capacity C

for the request. As shown as from Lines 4 to 10, we first initialize the service time tito ai + 1 and set the schedule Si to empty. For each clip c in Aclip, we try to scheduleits delivery in its playback interval tc = ti + c, where c is the index of the clip. If thebandwidth in interval tc has been used up, we have to delay the service of this requestfor one interval (i.e., ti = ti + 1), and try to reschedule the transmission of clips inAclip based on the new service time, as shown from Lines 6 to 8. Otherwise, i.e.,when we have sufficient bandwidth in tc, we are able to schedule c to be delivered intc and add this schedule to Si, as shown in Lines 9 and 10. Lastly, the server sends thecomplete receiving schedule, R∗

i = Si + Ri, to the client as shown in Line 11.The main complexity of this algorithm is in generating clip-sharing schedule Ri

and find the transmission schedule Si. To find all sharable clips, we need to searchall active transmission schedules of the video. The number of such schedules in eachinterval is bounded by the number of VOD subchannels Nsub , and the length of aschedule is limited by the number of clips in the video, Lc. As a result, the complexityof maximizing Ri is O(Nsub · Lc). The complexity of obtaining Si is O(L2

c). Sincetypically Nsub < 27 and Lc < 45, the computational cost of the algorithm is fairlylow.4 The scanning cost can be further reduced by using a table to track the latestcopy of each clip.

Theorem 1 (Full-sharing minimizes bandwidth consumption.) To serve a series ofrequests for a video without knowing the request arrival times a priori, no otherscheduling algorithm can send fewer clips than the full-sharing algorithm, when clientshave sufficient buffer and each request is serviced as fast as possible in a FCFS order.

4Consider a common channel capacity of 27 Mbps and a CBR video rate of 1 Mbps. We have 27subchannels per channel. Consider a typical 90-min video. We have 45 2-min clips per video.


Theorem 1 shows that the full-sharing algorithm minimizes bandwidth consump-tion, and its proof is presented in the Appendix I of [7]. Since we assume that requestarrival times are unknown a priori and each request is served as fast as possible in aFCFS order, full-sharing does not ensure the minimal mean service delay, although itdoes minimize the total bandwidth consumption. To address this issue, we have alsodeveloped delay-oriented adaptation algorithms to reduce the mean service delaywith minimal bandwidth increase. Due to space limit, we refer interested readersto [7] for these schemes.

3.3 Performance evaluation

We first analyze the worst-case performance of the full-sharing scheduling algorithm,and then compare its performance with other video streaming approaches via bothanalysis and simulations.

Worst-case analysis. Figure 5 illustrates how each transmission session is scheduledunder the full-sharing algorithm in the worst case, i.e., at least one request arrivesin each interval. Intuitively, each clip is repeatedly delivered as a sequence, and thedistance between two copies of the same clip is equal to the index of the clip. For avideo with Lc clips, its worst-case bandwidth consumption, denoted as Bworstcase, is aHarmonic sum and can be computed as follows:

Bworstcase =Lc∑

i=1

1

i≈ γ + ψ(Lc + 1) (1)

Fig. 5 Full-sharing scheduling example: the worst case when at least one request arrives in eachinterval


0 200 400 600 800 10001

2

3

4

5

6

7

Number of Clips in the fixed–length Video

Num

ber o

f Cha

nnel

s Re

quire

d Pe

r Vid

eo

Fig. 6 The mean number of required subchannels per interval over a video session period

where γ is the Euler–Mascheroni constant (0.577), ψ(n) = �′(n)

�(n)is the Digamma

function, and �(z) = ∫ ∞0 tz−1e−tdt is a Gamma function. Bworstcase is in units of clips.

Clearly Lc is the key parameter to determine Bworstcase. We will discuss the choice ofLc at the end of this section.

Since small clip sizes mean small service delays in our setting, we first use theabove worst-case analysis to examine the relation between the bandwidth require-ment of a video and the choice of a clip size. Given a fixed-length video, Fig. 6shows the expected number of required subchannels per interval over a video sessionperiod in the worst case, as the number of clips of a fixed-length video increases, i.e.,the clip size decreases. As we see, the expected number of required subchannelsincreases fairly slow as the clip size sharply decreases. This slow growth shows thatthe full-sharing scheduling can achieve small start-up delays for the video with a smallnumber of subchannels. For example, if we divide a 90-min video into 20 clips, thealgorithm can achieve a start-up delay no more than 5 min in the worst case, withonly three subchannels on average.

We now use the worst-case analysis to compare the full-sharing algorithm with theoptimal periodic-broadcast approach, in terms of the number of videos that can besimultaneously supported on a fixed-capacity VOD channel. We use the model5 from[15] to obtain the bandwidth requirement Bbroadcast of the optimal periodic-broadcastapproach as follows:

Bbroadcast = n ·(

n√

L + 1 − 1)

(2)

5Another bandwidth model for broadcast schemes is ln(L · λ + 1) [9], which generates the similarresult as Eq. 2, where L is the duration of a video and λ is the mean request rate of the video.


0 50 100 150 200 250 300 35010

10

10

10

10

10

Link Capacity (Number of Sub–Channels)

Num

ber o

f Vid

eo S

essi

ons

Supp

orte

d

Full–sharing (0.1 request/min)Full–sharing (0.5 requests/min)Full–sharing (1 request/min)Periodical–BroadcastingFull–sharing (5 requests/min)

Fig. 7 Comparison of full-sharing with optimal periodic-broadcast in the number of videos sup-ported on a fixed-capacity channel under different request arrival rates

where n is the number of broadcast subchannels and L is the duration of a video.This model establishes the lower bound for all periodic broadcast protocols as shownin [15]. As shown in Fig. 7, the full-sharing approach has significant advantages overthe optimal periodic-broadcast approach when the arrival rate is moderate, whichis the most likely case in the BCN setting. Note that the y-axis is log-scaled. (Aperiodic-broadcast approach is still favored when the arrival rate is fairly high.) Oneinteresting issue is how to determine the range of request arrival rates in which thefull-sharing approach outperforms broadcast approaches for bandwidth saving. Oneinteresting work [4] has studied a similar issue from the point view of limited clientbuffer capacity. We will perform a detailed analysis of the operation range of full-sharing approach.

Next, we compare the full-sharing approach with the optimal patching approach[11] and the multistream- (or lambda-) patching[12], in terms of the number ofsubchannels required to support the same number of sessions of a video. We use thebandwidth model from [11] to compute the bandwidth requirement of the optimalpatching approach as follows:

Bpatching = √2L · λ + 1 − 1 (3)

where L is the duration of a video and λ is the mean request rate of the video. Thebandwidth model of multistream patching is given as follows[12]:

Bmpatching = L/�m + n + λ�m/2n+1 (4)


Fig. 8 Comparison of thesubchannel requirement of afull-sharing approach in theworst case with that of anoptimal/multistream patchingapproach

where L and λ are the same as the above; �m is the length of multicast stream (up toL); n is the number of additional patching streams, and n ≈ log2(λ�m) − 1. We chose�m = L/2 in this analysis. As shown in Fig. 8, the full-sharing approach requiresless than half of the number of subchannels expected by the optimal/multistreampatching approaches. As the mean arrival rate increases from 0.06 to 1 request perminute, the difference is significantly widened.

Through the above worst-case analysis, we have shown that the full-sharingapproach have significant advantages on the BCN setting over other previousapproaches, when the mean request arrival rate of a video is moderate.

Simulation evaluation. We first introduce the simulation setting on the NetworkSimulator 2 (NS2), and then present the simulation results. We use a 90-min videowith a CBR rate of 1 Mbps. We stream it from a VOD server to clients on a VODbroadcast channel with a fixed capacity of C. The video is partitioned into clips thathave the same length as a global time interval T1. We vary T1 from 0.5 to 20 minto test its effects on scheduling algorithms. All clients can receive video clips on thischannel. As in many previous studies, we generate the client requests as a Poissonprocess with a mean arrival rate λ. We vary λ from two requests per minute to 0.05request per minute. Assume that the peak VOD hours are from 4 p.m. to 1 a.m. in aregular day. We choose the duration of each simulation, T, as 9 h.

In the first set of simulations, we compare the total bandwidth consumption ofthe full-sharing algorithm with that of optimal patching, multistream patching andHMSM without buffer and bandwidth constraints. Figure 9 shows an example whenthe global time interval is 2 min. As we see, the total number of clips sent infull-sharing is 30% (or more) lower than that of optimal patching or multistreampatching. Other simulation results with various input parameters show similartrends. The trend also agrees with the analysis result shown in Fig. 8, whereinoptimal/multistream patching requires more subchannels than full-sharing to supportthe same number of sessions. Furthermore, we also see that full-sharing sends lessclips than HMSM in all test cases. Here we simulate HMSM using the close-targetmerging policy proposed in [9].


Fig. 9 Comparison of thenumber of clips sent infull-sharing, optimal patching,multistream patching andHMSM

0

500

1000

1500

2000

2500

3000

0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2

Tota

l Num

ber o

f Clip

s Tr

ansm

itted

Mean Arrival Rate (requests/minute)

Optimal PatchingMultistream Patching

HMSMFull_Sharing

In the second set of simulations, we compare the full-sharing approach with theoptimal patching approach under a channel bandwidth constraint C. Similar in theFS_fixed algorithm, we restrict the optimal patching algorithm with C and build aP_delay algorithm, which delays a request to the next interval if a bandwidth conges-tion occurs in an interval. Simulations under different input parameters are employedto compare the total bandwidth consumption, the mean delay, the maximum delay,and the probability P(di > T1) under these two algorithms. P(di > T1) is defined asthe probability when the service delay of a request is larger than T1. One set of typicalresults is shown in Fig. 10 when T1 is 2 min and C is 4 Mbps. Figure10a shows thatthe total number of clips sent in full-sharing is generally 30 to 80% less than thatof optimal patching. Figure 10b shows that the mean of service delays Df ull_sharing

is only about 10 to 30% of Dpatching. The maximum delay in full-sharing among allrequests is generally less than half of that of optimal patching as shown in Fig. 10c.Under algorithm FS_fixed, P(di > T1) is reduced by one to ten times compared withthat under P_delay algorithm, as in the example shown in Fig. 10d. Other simulationresults show the similar trend. In summary, the ability to share discrete clip sets makesthe full-sharing algorithm remarkably outperform the patching algorithm in eachcategory.

4 Analysis of expected bandwidth and blocking probability

The expected bandwidth and the service blocking probability of a video are criticalparameters for bandwidth and quality management in a VOD system. In this section,we determine these parameters for a popular video under full-sharing scheduling. Inaddition, we verify the analysis through simulations and build a video assignmentmechanism based on the analytic results.


400

500

600

700

800

900

1000

1100

1200

1300

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Tota

l Num

ber o

f Clip

s Tr

ansm

itted


PatchingFull_Sharing

(a) Total Bandwidth.

0

2

4

6

8

10

12

14

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Mea

n D

elay

(Min

utes

)



(b) Mean of delays.

0

5

10

15

20

25

30

35

40

45

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Max

imum

Del

ay (M

inut

es)



(c) Maximum delay.

0

0.2

0.4

0.6

0.8

1

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

Prob

abilit

y



(d) P (di > T 1 ).

Fig. 10 Comparison of a full-sharing algorithm and an optimal patching algorithm (T1 = 2 min andC = 4 Mbps)

4.1 Expected bandwidth and blocking probability

We first assume that a video vm is delivered on a cable channel without any band-width constraint, and derive its expected bandwidth. Then, we use this analytic resultto study the case with a bandwidth constraint.

We define the expected number of clips delivered per session of the video asits session expected bandwidth, denoted as E(Bm). We also define the deliveryprobability of the ith clip of the video, denoted as pi, as the probability that it isscheduled in a session, where 1 ≤ i ≤ Lc and Lc is the number of clips in the video.Therefore, E(Bm) = ∑Lc

i=1 pi clips. Note that p1 is 1, since the first clip is alwaysdelivered.

We assume that session arrivals follow a Binomial distribution with a parameterPm, because in the full-sharing scheduling, we either start a session or not at thebeginning of an interval (of length T1). Pm is the probability that a session of videovm arrives in an interval, which can be measured at a server. Under the full-sharing


Fig. 11 Clip deliveryprobabilities pi

scheduling, a new session shares clips only from previous sessions started in the lastLc − 1 intervals. Consider the ith clip ci in a new session. It is either shared fromprevious sessions started in the last i − 1 intervals, or sent in the new session if noneof the previous sessions transmits ci. The probability that j sessions started in thelast i − 1 intervals is C j

i−1 P jm(1 − Pm)i−1− j, where C j

i−1 is the number of combinationsof choosing j from i − 1. The probability that these j sessions do not deliver ci is(1 − pi)

j. Therefore, we obtain pi from the following relations, 1 ≤ i ≤ Lc.

p1 = 1, p2 = 1/(1 + Pm)

pi =i−1∑

j=0

C ji−1 · P j

m(1 − Pm)i−1− j(1 − pi)j (5)

For a video consisting of 20 5-min clips, Fig. 11 shows that its pi generally decreasesas the clip index increases. In addition, the decrease of pi is slow when Pm is small,e.g., 0.1, as in such scenarios the probability of clip-sharing is rather low. The bottomcurve shows the lower bound of pi when Pm = 1.0.

Fig. 12 Expected percentageof a video delivered v.s. Pm

0 0.2 0.4 0.6 0.8 110

20

30

40

50

60

70

Pm

Percentage of a video delivered Per Session


Table 1 Expected bandwidth of a video with Lc = 20

Pm 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9

E(vm) 1.24 1.96 2.52 2.97 3.37 3.72 4.03 4.32 4.59

The value of Pm heavily affects the expected amount of video data delivered persession. As shown in Fig. 12, when Pm = 1.0, only less than 20% of the video isexpected be delivered per session, and the other 80% is shared from other sessions.However, when Pm = 0.1, about 62% of the video is expected to be delivered foreach session. As a result, the sharing from other sessions is less than 40%.

The expected bandwidth of a video is a key parameter in the bandwidth manage-ment of a VOD system. We define the expected bandwidth of video vm as E(vm) =Pm

∑Lci=1 pi in our setting. Table 1 shows that E(vm) increases gradually as Pm

increases. Figure 13 shows the expected bandwidth usage from the view of a newsession. Note that the expected bandwidth usage in the current interval (clip index1 in the figure) is equal to E(vm). Therefore, to avoid blocking a session, sufficientbandwidth (at least E(vm)) is needed to accommodate the first clip of the new session.For example, we need to allocate at least three units of bandwidth for the video inorder to reduce the chance of a session being blocked when Pm = 0.5, as shown inthe figure.

We now consider the case where the cable channel has a limited capacity of Bm.In this case, some video sessions may be delayed due to insufficient bandwidth. Fora new session started in the current interval, only the sessions started in the lastLc − 1 intervals compete for the limited bandwidth. We obtain the session blockingprobability Pb

m of vm under Bm using the following relation:

Pbm =

Lc−1∑

x=1

p′x, (6)

where p′x is the blocking probability when x sessions are scheduled in the last

Lc − 1 intervals and they block the new session to be scheduled in some of these

Fig. 13 Expected bandwidthusage from the view of a newsession. Assume the video hasa CBR rate of one unit

0 5 10 15 200

0.5

1

1.5

2

2.5

3

3.5

4

Clip Index in a new session

Expe

cted

BW

requ

irem

ent Pm=0.1

Pm=0.5Pm=0.9Pm=1.0


Fig. 14 Blocking probabilityunder Bm

1 1.5 2 2.5 3 3.50

0.05

0.1

0.15

0.2

am

= 0.1a

m = 0.3

am

= 0.5a

m = 0.7

am

= 0.9

Ratio of Bi to E(v

m)

Blo

ckin

g Pr

obab

ility

intervals, 1 ≤ x ≤ Lc − 1. We have p′x = ∑Cx

Lc−1

k=1 p′′k, where Cx

Lc−1 is the number ofcombinations of choosing x from Lc − 1, and p

′′k is the probability when congestion

(defined below) occurs due to the x sessions. We have

p′′k =

{Px

m · (1 − Pm)Lc−1−x, congested0, otherwise

(7)

We define the expected available bandwidth in an interval t, denoted as at, as thedifference between the bandwidth limit Bm and the total expected bandwidth usageof the x sessions in the interval t, i.e., at = Bm − ∑x

l=1 pl · Pm, where pl = py, andpy is the probability that the yth clip of the lth session is scheduled in the interval t,1 ≤ y ≤ Lc and 1 ≤ l ≤ x. When at is less than pi, the expected requirement of thenew session in interval t, we say that congestion occurs in t.

Because of the dependency among sessions, we can not know the exact deliveryprobability pi of clip ci in the limited bandwidth case. However, we do know itslower bound from Eq. 5. Using the lower bound, we can estimate the expectedblocking probability of the video, as shown in Fig. 14. As Bm increases over E(vm),the blocking probability drops fairly fast when Pm is high. The x-axis represents theratio of Bm to E(vm). We know that E(vm) is a lower bound of the actual expectedbandwidth because it is computed using the lower bound of pi. As a result, whenassigning a video vm to a channel, we need to allocate Bm = Fm · E(vm) from thechannel capacity in order to ensure Pb

m lower than a threshold, where Fm is a fudgefactor for vm.

4.2 Simulation verification of the analysis

We verify the above analysis using simulations built on NS2. For the unlimitedbandwidth case, the measured mean session bandwidth in simulations is almostidentical to the one obtained from the analysis. Therefore, we focus on comparing thelimited bandwidth case in the following. Consider the case when a video is deliveredunder a dedicated bandwidth B1. In our simulations, we let Lc=20, b=1 MBps, andT1=5 min, i.e., the clip length is 5 min.

Table 2 lists the blocking probability measured in simulations. We allocate B1 asa multiple of b (from 2 to 9 MBps) because clips are delivered at rate b . Recall the


Table 2 Blocking probability of a single video under a limited bandwidth B1 MBps

B1 2 3 4 5 6 7 8 9

Pm Blocking probability

0.1 0.182 0 0 0 0 0 0 00.2 0.409 0 0 0 0 0 0 00.3 0.625 0.094 0 0 0 0 0 00.4 0.558 0.140 0.023 0 0 0 0 00.5 0.593 0.185 0.056 0 0 0 0 00.6 0.508 0.200 0.062 0 0 0 0 00.7 0.553 0.329 0.066 0 0 0 0 00.8 0.581 0.291 0.070 0 0 0 0 00.9 0.598 0.309 0.113 0.021 0 0 0 01.0 0.602 0.287 0.167 0.120 0.074 0.019 0.009 0

E(vm)’s in Table 1. This set of simulations confirm that E(vm) is indeed a lower boundof the expected session bandwidth.

In practice, multiple videos typically share a single channel, because the channelcapacity (e.g., 27 MBps) is much higher than the expected bandwidth of a singlepopular video. Hence, we further compare the analytic results with simulations,where we multiplex multiple videos on a fixed-capacity channel. We group n j =�27/(Fm · E(vm)) videos with the same Lc, b and Pm on a channel. Figure 15 showsthe measured session blocking probabilities of videos under various fudge factors anddifferent Pm’s. Clearly, to achieve similar Pb

m, the Fm obtained through simulationsis usually much lower than the Fm derived through the analysis due to multiplexingeffects. It also shows that E(vm)’s from the analysis are applicable when multiplexingvideos with Pm ≥ 0.3 on a channel. Another trend in simulations is also consistentwith the analysis, i.e., the smaller value of Pm, the bigger fudge factor is needed toensure a low blocking probability.

Through the simulation verification, we can see that the analysis provides us fairlyclose estimations of the expected bandwidths and the session blocking probabilitiesof videos.

Fig. 15 Blocking probabilityvs. fudge factor on a channelwith a fixed C

0

0.05

0.1

0.15

0.2

0.6 0.7 0.8 0.9 1 1.1 1.2 1.3 1.4 1.5 1.6

Bloc

king

Prob

abilit

y

Fudge Factor

Pm = 0.1Pm = 0.3Pm = 0.5Pm = 0.7Pm = 0.9


4.3 Multiple video channel assignment

The above analytic and simulation results are useful for us to manage the bandwidthand service quality in a VOD system over a BCN, In the following, we design a videochannel assignment mechanism to maximize the system profit by applying the resultsfrom the above studies. Assume a VOD service on a BCN provides videos overmultiple channels. However, a CM is able to access only one such channel for service.Based on video popularity, we classify videos into hot, popular and cold videos. Weuse the full-sharing scheduling to deliver popular videos with a quality guarantee,i.e., Pb

m is lower than a threshold; we employ Polyharmonic Broadcast (PHB) [21]to deliver hot videos that have Pm > 0.8,6 and use unicast to deliver cold videos. Inthe following, we focus on how to service as many sessions of M popular videos aspossible on given N channels. We assume that we have to provide the service for freeif we cannot service a session within T1 minutes. Hence, the system profit is defined asSp = ∑M

m=1 Pm(1 − Pbm) · Dm, where Pm is the probability that a session of a popular

video vm arrives during an interval; Pbm is the session blocking probability of vm, i.e.,

the probability that the session cannot be serviced within T1; and Dm is the profitmade from servicing a session of vm, 1 ≤ m ≤ M. To maximize Sp, we thus need tominimize Pb

m.We first propose a simple greedy algorithm. Since a CM cannot receive video

streams from multiple channels, the M popular videos have to be divided into N setson N channels. Starting from the most popular video, the greedy algorithm assignsa video to a channel with the maximum available bandwidth until all channels areoccupied. However, this strategy does not guarantee the maximum system profitbecause the interactions among sessions of different videos on a channel also affectthe blocking probability of a session on the channel. To address this issue, we design aheuristic assignment algorithm. Recall the two following observations we made in thesimulations. First, the higher value of Pm, the smaller Fm is needed for ensuring lowPb

m, because the E(vm) estimation is more accurate when the value of Pm is high. Asa result, when we group videos with high Pm’s together on a channel, we do not needto use a large Fm and allocate extra bandwidth for them on a channel. Therefore,we make more profits from the fixed-capacity of the channel than multiplexing thesevideos with other videos having low Pm’s. Second, the multiplexing gain is higherwhen grouping videos with low Pm’s on a channel, because the expected bandwidthof such a video is low and then more these videos can be multiplexed on the fixed-capacity channel. As a result, we also make more profits from the fixed-capacity ofthe channel than multiplexing videos regardless of their Pm’s.

We compare two assignment algorithms with ten sets of videos in simulations andpresent the number of sessions serviced in 10 h in Fig. 16. Each sample set has 200100-min videos and is divided into seven classes. All videos in each class have thesame Pm, which is equal to 0.1, 0.2, 0.3, 0.4, 0.5, 0.6, or 0.7, respectively. In the firstset of videos, all seven classes have the equal percentages (14.3%). For other samplesets, we generate the percentages by keeping the mean unchanged and increasing thevariance; then we randomly assign the percentages to the classes. In the simulation,we assign videos to 20 channels from a sample set using the two algorithms. Consider

6We use PHB to broadcast a video with a Pm ≥ 0.8 because its expected bandwidth is higher thanthe broadcast bandwidth.


Fig. 16 Comparison ofassignment algorithms

0 2 4 6 8 107000

7500

8000

8500

9000

9500

10000

10500

11000

11500

Index of Video Sample Sets

Num

ber

of S

essi

ons

Ser

ved

HeuristicGreedy

the profit made from each video session is the same. As shown in the figure, theheuristic algorithm outperforms the greedy algorithm, in some cases above 20%.

5 Conclusions and future work

In this paper, we have proposed the full-sharing scheduling for VOD service onBCNs that exploits the unique BCN characteristics. In fact, this approach is alsoapplicable for many broadcasting networks such as satellite broadband networks,in which clients have sufficient buffer and downstream bandwidth. We have alsoanalyzed the expected bandwidth and the service blocking probability of a videounder full-sharing. Based on the analysis, we have designed a video assignmentmechanism that maximizes VOD system profits. Our simulation results demonstratethe efficacy of the proposed approaches. We will study the choice of clip size forscheduling multiple videos with variable request rates on a single cable channel.We will also investigate video channel migration schemes to deal with long-termpopularity changes when streaming videos on next generation BCNs with multiplechannels.

References

1. Aggarwal C, Wolf J, Yu P (1996) On optimal batching policies for video-on-demand storageservers. In: Proceedings of the IEEE international conference on multimedia systems ’96,Hiroshima, Japan. IEEE Computer Society, Washington DC, pp 253–258, June

2. Aggarwal C, Wolf J, Yu P (1996) A permutation-based pyramid broadcasting scheme for video-on-demand. In: Proceedings of the IEEE international conference on multimedia systems ’96,Hiroshima, Japan. IEEE Computer Society Washington, DC, pp 118–126, June

3. Cable Television Laboratories, Inc. (2004) DOCSIS Overview. http://www.cablemodem.com/downloads/slideshow.ppt, June

http://www.cablemodem.com/downloads/slideshow.ppt

http://www.cablemodem.com/downloads/slideshow.ppt


4. Chan S-H, Yeung S-H (2002) Client buffering techniques for scalable video broadcasting overbroadband networks with low user delay. IEEE Trans Broadcast 48:19–26

5. Dan A, Shahabuddin P, Sitaram D (1994) Scheduling policies for an on-demand video serverwith batching. In: Proceedings of ACM multimedia. ACM, New York, NY, pp 15–23, Oct

6. DOCSIS 1.1 Radio Frequency Interface Specification, SP-RFIv1.1-I07-010829, http://www.cablemodem.com/Specs/

7. Dong Y, Zhang Z-L, Du D (2003) Full-sharing optimal scheduling for vod service on broadbandcable networks. Technical report 02-028, Dept. of Computer Science and Engineering, Univer-sity of Minnesota, 2002. Also in: Proceedings of IEEE packet video ’03, Nantes, France, April,2003. http://www.cs.umn.edu/~dong/papers/full-sharing-tech-report.ps

8. Eager D, Vernon M (1998) Dynamic skyscraper broadcast for video-on-demand. In: Lecturenotes of computer science vol 1058. Springer, Berlin Heidelberg New York, pp 18–32 (Istanbul)

9. Eager D, Vernon M, Zahorjan J (1999) Minimizing bandwidth requirements for on-demanddata delivery. In: Proceedings of 5th international workshop on multimedia information sys-tems, pp. 21–23, Oct

10. Eager D, Vernon M, Zahorjan J (2000) Bandwidth skimming: a technique for cost-effectivevideo-on-demand. In: Proceedings of MMCN ’00, San Jose, CA, 25–27 Jan 2000

11. Gao L, Towsley D (1999) Supplying instantaneous video-on-demand services using controlledmulticast. In: Proceedings of IEEE multimedia computing and systems, Florence, Italy, vol 2.IEEE Computer Society, p 117

12. Griwodz C, Liepert M, Zink M, Steinmetz R (2000) Tune to lambda patching. ACM PerformEval Rev 27(4):20–26

13. Guo Y, Gao L, Towsley D, Sen S (2002) Seamless workload adaptive broadcast. In: Proceedingsof international packet video workshop 2002, Pittsburgh, PA, 24–26 April 2002

14. Hogan M (2001) Cable’s big dilemma: managing bandwidth, multichannel news, June 18.Reed Business Information, a division of Reed Elsevier Inc. It is online publisher athttp://www.multichannel.com/

15. Hu A (2001) Video-on-demand broadcasting protocols: a comprehensive study. In: Proceedingsof INFOCOM ’01, Anchorage, AZ, 22–26 April 2001

16. Hua KA, Sheu S (1997) Skyscraper broadcasting: a new broadcasting scheme for metropolitanvideo-on-demand systems. In: ACM SIGCOMM. ACM, New York, NY, pp 89–100, Sept

17. Hua K, Cai Y, Sheu S (1998) Patching: a multicast technique for true video-on-demand services.In Proceedings of ACM multimedia. ACM, New York, NY pp 191–200, Sept

18. Juhn L, Tseng L (1997) Harmonic broadcasting for video-on-demand Service. IEEE TransBroadcast 43(3):268–271

19. Juhn L, Tseng L (1998) Fast data broadcasting and receiving scheme for popular video service.IEEE Trans Broadcast 44(1):100–105

20. Paris J, Carter S, Long D (1999) A hybrid broadcasting protocol for video on demand. In:Proceedings of MMCN’99, San Jose, CA, pp 317–326, Jan

21. Paris J-F (1999) A simple low-bandwidth broadcasting protocol for video-on-demand. In: Pro-ceedings of 8th international conference on computer communications and networks (ICCCN’99), Boston, MA, pp 118–123, 11–13 October 1999

22. Saparilla D, Ross K, Reisslein M (1999) Periodic broadcasting with vbr-encoded video. In:Proceedings of INFOCOM ’99, New York, NY, 21–25 March 1999

23. Sen S, Gao L, Rexford J, Towsley D (1999) Optimal patching scheduling for efficient multime-dia streaming. In: Proceedings of IEEE NOSSDAV ’99, Basking Ridge, NJ, June

24. Sen S, Gao L, Towsley D (2001) Frame-based periodical broadcast and fundamental resourcetradeoffs. In: IEEE international performance, computing, and communications conference(IPCCC 2001), Phoenix, AZ, 4–6 April 2001

25. TiVo, Inc., The TiVo Box, http://www.tivo.com/1.1.asp.26. Viswanathan S, Imielinski T (1996) Metropolitan area video-on-demand service using pyramid

broadcasting. Multimedia Syst 4(5):197–20827. Yan E, Kameda T (2003) An efficient vod broadcasting scheme with user bandwidth limit. In:

Proceedings of ACM/SPIE MMCN 2003, vol 5019, San Clara, pp 200–208, Jan

http://www.cablemodem.com/Specs/

http://www.cablemodem.com/Specs/

http://www.cs.umn.edu/~dong/papers/full-sharing-tech-report.ps

http://www.multichannel.com/

http://www.tivo.com/1.1.asp.


Yingfei Dong received his B.S. degree and MS degree in Computer Science from Harbin Instituteof Technology in 1989 and 1992, respectively, his doctor degree in engineering from TsinghuaUniversity in 1995, his PhD degree in Computer and Information Science from the Universityof Minnesota in 2003. He is currently an assistant professor at the Department of Electrical andComputer Engineering, Univ. of Hawaii. Dr. Dong’s main research interests are in the areas of com-puter networking, networking security, multimedia content delivery, Internet services, distributedsystems, and advanced computer architecture.

Zhi-Li Zhang received a B.S. degree in Computer Science from Nanjing University, China, and hisM.S. and Ph.D. degree from University of Massachusetts, Amherst, in 1992 and 1997, respectively.He joined the Computer Science faculty at the University on Minnesota in 1997, where he is currentlyan associate professor. His current research interests include high speed networks, multimedia andreal-time systems, and modelling and performance evaluation of computer and communicationsystems. He received the National Science Foundation CAREER award in 1997. He is also aco-recipient of a 1996 ACM Sigmetrics Conference Best Paper award.


David H.C. Du received the B.S. degree in mathematics from National Tsing-Hua University,Taiwan, R.O.C., in 1974, and the M.S. and Ph.D. degrees in computer science from the University ofWashington, Seattle, in 1980 and 1981, respectively. He is currently a Professor with the ComputerScience and Engineering Department at the University of Minnesota in Minneapolis. His researchinterests include multimedia computing, storage systems, high-speed networking, high-performancecomputing over clusters of workstations, database design and CAD for VLSI circuits. He hasauthored and coauthored more than 150 technical papers, including 80 refereed journal publicationsin his research areas.

Full-sharing: efﬁcient bandwidth scheduling for video ...

Documents

Transcript of Full-sharing: efﬁcient bandwidth scheduling for video ...