Abstract

Periodic broadcasting is an effective approach for delivering popular videos. In general, this approach does not provide interactive (i.e., VCR) functions, and thus a client can tolerate playback latency from a video server. The concept behind the approach is partitioning a video into multiple segments, which are then broadcast across individual communication channels in terms of IP multicast. The method improves system throughput by allowing numerous clients to share the channels. For many broadcasting schemes, client receiving bandwidth must equal server broadcasting bandwidth. This limitation causes these schemes to be infeasible in mobile networks because increasing receiving bandwidth at all client sites is expensive, as well as difficult. To alleviate this problem, the fibonacci broadcasting (FiB) scheme allows a client with only two-channel bandwidth to receive video segments. In comparison with other similar schemes, FiB yields smallest waiting time. Extending FiB, this work proposes a new scheme (called FiB+) to achieve smaller client buffering space and the same waiting time under two-channel receiving bandwidth. Extensive analysis shows that FiB+ can yield 34.5% smaller client buffer size than that of FiB. Further simulation results also indicate that FiB+ requires lower client buffering space than several previous schemes.

1. Introduction

Video-on-demand (VOD) services have become popular due to advances in network and computer technology [1, 2]. A VOD system may easily run out of bandwidth since the growth in bandwidth can never keep up with the growth in the number of clients. To alleviate the problem, one way is to simply broadcast popular videos. According to the study in [3, 4], a few very popular videos constitute most client requests. Data broadcasting is thus suitable to transfer popular videos that may be interesting to many clients in a particular period of time. An efficient method for broadcasting a popular video is to divide it into segments, which are simultaneously and periodically transmitted across individual communication channels in terms of IP multicast [5]. Because video broadcasting does not provide VCR functions, a client is able to tolerate playback latency. To ensure continuous playback, clients must simultaneously download and save the video segments from these channels. The clients usually have to wait for the occurrence of the first segment before they can start playing the video. Since the clients cannot watch the video immediately, the broadcasting schemes provide near VOD services.

The fast broadcasting (FB) scheme [6] improves segment partition and arrangement to yield shorter waiting time. To achieve near-minimum waiting time, the recursive frequency-splitting (RFS) scheme [7] broadcasts each segment at the frequency that can keep continuous video playback. A scalable binomial broadcasting scheme [8] transfers a variable-length video using constant bandwidth. To simplify the implementation of multiple channels, the PAS scheme [9] broadcasts video segments over a single channel. The reverse-order scheduling (ROS) scheme [10] transmits segments of the same group in reverse order over a single channel to save buffering space.

With the fast growth of wireless networks, mobile video services become more and more popular. Broadcasting videos under rather restricted client resources is increasingly important. The following schemes address the savings on client buffer size and bandwidth. Modifying the FB scheme [6], the reverse fast broadcasting (RFB) scheme [11] buffers 25% of video size, just half of what is required by FB. By combining RFS and RFB, the hybrid broadcasting scheme (HyB) [12] achieves small client buffering space and waiting time. Different RFB-based hybrid schemes were proposed in [13, 14]. The skyscraper broadcasting (SkB) scheme [15] allows a client to download video data using only a bandwidth of two channels. The client-centric approach (CCA) [16] also permits a client downloading video data via a small number of channels, and CCA+ [17] further yields smaller waiting time than SkB. Like SkB and CCA+, the fibonacci broadcasting (FiB) scheme [18] supports a client with two-channel bandwidth but achieves the minimum waiting time. The authors in [19] proposed an FB-based scheme for heterogeneous clients. The studies in [20, 21] deploy a proxy in VoD systems to serve heterogeneous clients.

The contributions of this study are summarized as follows.(1)Extending FiB, this work proposes a promising scheme, called FiB+, to deliver near VOD services to clients with small receiving bandwidth and buffering space. In comparison with FiB, FiB+ still yields the minimum waiting time under two-channel receiving bandwidth; moreover, FiB+ can save about 34.5% of buffer size.(2)The paper investigates the total client buffer requirements for FiB+ and explains why this scheme requires smaller buffering space than FiB. We further derive the maximum number of segments buffered by an FiB+ client mathematically. Extensive performance analysis has been conducted on FiB+ by comparing a number of past reported counterparts. The results indicate that FiB+ yields relatively lower client buffer requirements than most schemes.

The remainder of this study is organized as follows. The FiB scheme is introduced in Section 2. Section 3 presents FiB+. This section also verifies the on-time video delivery under two-channel client bandwidth. Section 4 evaluates the performance of FiB+. Brief conclusions are drawn in Section 5.

2. Review of FiB

Let be the number of server channels throughout the paper. The FiB scheme [18] unequally divides a video of length into segments, denoted by in sequence. The length of a segment is based on the following equation and equals as follows:

Assume that the data transmission rate of each channel equals the playback rate . The server then periodically broadcasts segment on channel , as illustrated in Figure 1. In the figure, segments downloaded and played by a client are gray. When a client wants to watch a video, the client first downloads segments and on the first two channels and . Once finishing receiving the segment , the client continuously accepts segment and newly downloads segment on channel . The client repeats the process, which starts downloading segment on channel once finishing receiving segment from channel , until all the segments are loaded. An FiB client thus requires a bandwidth of only two channels to download video segments.

3. FiB+

Some of the frequently used terms and their definitions are listed in Table 1. On the server side, the FiB+ scheme includes the following steps. The server equally divides a video into segments, denoted by in sequence, where , where is based on (1). The length of each segment thus equals . From (1), we further yields See Appendix A for details. Thus, . The FiB+ scheme then assembles segments to (i.e., to ) into group sequentially, as illustrated in Figure 2(a). The number of segments of group thus equals . For instance, group includes segments to , and . Channel , where , periodically broadcasts the segments of group in sequence, as shown in Figure 2(b). That is, segments to are transferred one by one on channel . The segments of groups and are cyclically transmitted on channels and in reverse order, respectively. Figure 2(b) shows that the scheme repeatedly broadcasts the segments of group in the order of to and the segments of group in the order of to .

Figure 3 demonstrates the segment broadcasting and downloading for FiB+, where the segments downloaded and played by a client are gray. Let be the time that the client starts receiving video segments and be the origin (i.e., the first time unit) of the time axis. Due to , FiB+ equally divides a video into 32 segments, which are then classified into six groups. The segments of groups to are broadcast sequentially on channels to , respectively. In addition, FiB+ transmits segments of groups and on channels and in reverse order.

A client is assumed to have enough buffers to store video segments downloaded. We further suppose that one time unit equals the length of a segment throughout this study. Playing a video on the client side includes the following steps. Download segments of group on channel during time units to , where and . For example, the client accepts segments from channel during time units to , as shown in Figure 3. The paper next presents how a client receives segments from channels and . (In Figure 3, refer to channels and .) Suppose that a client first sees a segment on a channel at time and sees the next segment at time , where or . (In Figure 3, and .) The client is also assumed to play segments and at time and , respectively. Clearly, if , the client can delay downloading segment at time , without interrupting the playback. Substituting th time unit, th time unit, and into , we obtain If the inequality is true, the client does not receive segment at time , otherwise, performs the downloading immediately. For instance, when the client first sees segment with only diagonal lines on channel at the 7th time unit (i.e., ) in Figure 3, (3) is true, , and the client does not download the segment. Afterwards, the client sees next segment with gray color and diagonal lines at the 20th time unit. The client must receive the segment because (3) does not hold, . The client plays the video in the order of at time . The client stops loading data from networks when all the segments have been received.

FiB+ and FiB differ in three areas.(i)Equal-length segment partition versus variable-length segment partition. FiB+ divides a video into multiple equal-length segments, while FiB partitions a video into variable-length segments. For example, given , FiB divides a video into six segments, whose lengths are , , , , , and . On the other hand, FiB+ partitions a video into 32 segments, whose lengths all equal .(ii)Multiple segments on each channel versus single segment. FiB+ cyclically broadcasts several segments on each channel except the first channel, and FiB transmits only one.(iii)Segment transmission in reverse order. The FiB+ scheme broadcasts segments on the last two channels in reverse order. For example, the scheme transmits segments to on channel and segments to on channel , as illustrated in Figure 3.

3.1. Analysis of Segment Playing and Downloading on a Single Channel

We next analyze the segment downloading on channel , where .

For , a client receives segments to from channel during time units to and plays the segments during time units to , as mentioned previously. Suppose that a client sees a segment at the th time unit, where . Figure 4(a) shows how a client downloads and plays segments, where the segments downloaded and played by the client are gray.

For or , a client downloads segments according to (3). We also assume that a client sees a segment at the th time unit, where . A complete segment-downloading diagram for channel is based on (3), as indicated in Figure 4(b). The explanation is as follows.

The client always downloads segment since the inequality of (3) does not hold for and  (i.e., ). In addition, because the segments of group are transmitted once on channel every time units and are played during time units to , the client downloads a segment of group either during time units to or during time units to (i.e., before the downloading of segment ).

3.1.1. Segment Downloading within

Figure 4(b) shows that segments to are broadcast on channel in descending order during time units to , while a client plays these segments in turn. Let be a segment broadcast on channel during this period, and let be the client-playback segment corresponding to . Clearly, if , a client must download segment to ensure continuous playing. Because the number of segments between and on channel equals the number of segments between and on the client playback, and . Substituting this equation to yields . The maximum value of is , and the corresponding value of equals . Figure 4(b) illustrates that the client downloads segments to during time units to and does not download any segment during time units to . Similarly, this study obtains that a client receives segments to during time units to and does not download any segment during time units to .

3.1.2. Segment Downloading within

From (3), the client must download segments to during time units to because the client does not download these segments during time units to , as shown in Figure 4(b). The figure further indicates that the client does not accept segments to during time units to since the client will perform their downloading during time units to . Similarly, the client must receive segments to during time units to because the client does not download these segments during time units to . Furthermore, since the client will download segments to during time units to , the client does not load any segment during time units to , as illustrated in Figure 4(b).

3.2. Workable Verification

This section shows that FiB+ guarantees continuous playback and two-channel bandwidth demand on the client side.

3.2.1. Continuous Playback

To keep on-time video delivery, the study in [7] indicates that a video server must broadcast a segment on a channel at least once in every time units. For FiB+, a server transmits a segment once every time units, where . This paper thus needs to prove . We then evaluate

For FiB+, the segment broadcasting frequency is large enough to let clients receive video data in time.

3.2.2. Two-Channel Bandwidth Demand

From the previous analysis in Figure 4, we make a temporal-channel map of segment downloading for each channel, as indicated in Figure 5. In this figure, segments downloaded and played by a client are gray. This work divides client playback time (in terms of time units) into multiple successive durations for ease of explanation.

For , the client merely receives segments from channels to because the client starts the segment downloading on channel at time unit , as shown in Figure 5. According to Step 1 of segment downloading on the client side, the client uses two-channel bandwidth to load segments in this period.

For , the client receives segments only from channels and because the client finishes receiving segments from channel to before time unit and starts downloading segments on channel at time unit , as indicated in Figure 5.

For , the client simply receives the remaining segments from channels and because the segment downloading on channel completes at time unit .

Accordingly, an FiB+ client can download segments using two-channel bandwidth.

4. Performance Analysis and Comparison

When a client just misses segment of a requested video, the maximum waiting time equals the access time of the segment from the first channel. Thus, , the same as that of FiB. According to the previous studies [15, 17], this work has calculated the values of offered by these schemes at different numbers of channels, as listed in Table 2. The larger the value is, the smaller the waiting time is. The table reveals that FiB and FiB+ yield far bigger values than other schemes. Figure 6 shows maximum waiting time versus server channels. FiB and FiB+ thus achieve much smaller waiting time than SkB and CCA+ under two-channel client bandwidth. For example, when the server bandwidth equals 10 channels, FiB and FIB+ reduce the broadcast latency to less than 32 seconds. By contrast, SkB and CCA+ incur more than 51 and 48 seconds, respectively.

Before analyzing the entire buffer requirements, we first investigate the number of the buffered segments when a client performs segment downloading on a single channel .

Lemma 1. Let be the function of the number of the segments buffered by an FiB+ client on channel at the th time unit.

Proof. See Appendix B.

Equation (5b) shows that a client buffers at most segments from channel for or . On the other hand, an FiB client needs to buffer segments [18]. Such a difference leads to the result that FiB+ requires much smaller buffering space.

Theorem 2. Let be the maximum number of segments buffered by an FiB+ client. Then, .

Proof. See Appendix C.

Due to [22] and , . This result indicates that an FiB+ client can buffer only 25% of video size, like RFB. We used the Perl language to implement a simulator, which could estimate the buffer requirements for FiB+. The results are listed in Table 3. The buffer size required by FiB+ is quite close to the bound when . Because FiB has to buffer segments, we can derive the buffer reduction rate of FiB+ versus FiB as follows: . FiB+ can reduce buffer requirements by 34.5%, when compared with FiB. Table 3 shows that with the growth of , the reduction rate is close to the bound. For example, for , an FiB client buffers 38.1% of video size. By contrast, an FiB+ client buffers only 25.1%. The reduction rate is 34.1%. According to the previous studies [15, 17], this work presents the buffer sizes required by different broadcasting schemes at different numbers of server channels, as indicated in Figure 7. For , the FiB+ scheme outperforms all the schemes.

5. Conclusions

With the advance of mobile computing technology, many clients access VOD services through their mobile devices. Delivering videos under rather restricted client resources is increasingly important. To fulfill this requirement, several schemes, such as SkB, FiB, and CCA+, are proposed to allow a client to watch a video using two-channel bandwidth. Extending FiB, this work devises FiB+, which exhibits the merits of small client waiting time and buffering space. The scheme still guarantees on-time video delivery under two-channel receiving bandwidth. According to the performance analysis, FiB+ yields the minimum waiting time and requires smaller client buffer size, when compared with most existing schemes.

Appendices

A. Proof of Equation (2)

For mod, let . Then,

For mod, let . Then,

Accordingly, .

B. Proof of Lemma 1

This study first proves (5a). For easy understanding, please refer to Figure 4(a).

For , a client downloads no segment on channel because these segments will appear again during time units to . Thus, .

For , a client continuously accepts one segment every time unit but consumes no segment. Thus, the number of buffered segment equals . When , the client buffers the maximum segments and .

For , Figure 4(a) shows that a client stops loading data but plays the video in this period. The client consumes one segment every time unit, and thus the buffered segments decrease, .

For , a client has finished playing all the segments on channel , and thus .

The proof for (5b) is as follows. For easy understanding, please refer to Figure 4(b).

For , a client does not download any segment on channel , and thus, .

For , the paper divides the value range of into four successive subranges for ease of proof.

     (a) For , Figure 4(b) shows that the client downloads no segment on channel , and thus .

     (b) For ,

     (c) For ,

     (d) For ,

Thus, when .

For , the client plays one segment every time unit while downloading at most one segment. The number of buffered segments is not larger than that at time unit , and thus .

For , the client has played segments, and the number of the remaining segments is

Thus, .

For , the client finishes playing all the segments on channel so .

The proof is complete.

C. Proof of Theorem 2

This work divides client playing time (in terms of time units) into multiple successive durations for ease of proof.

For , Figure 5 shows that the client simply receives segments from channels to . In addition, the client downloads two segments but plays only one every time unit. The number of buffered segments thus increases with time and achieves the maximum at time unit . At this time, the client has finished playing segments from channels to , and thus simply buffers segments from channels and . Accordingly,

For , the client has finished playing all the segments received from channels to and downloads no segment from channel . We thus merely consider the segments on channels to . The client downloads at least one segment from channel but plays only one every time unit. Thus, the maximum number of buffered segments appears at time unit as follows:

For , the client has finished playing all the segments received from channels to , and thus the client only buffers segments from channels to as follows:

For , the client has finished playing all the segments received from channels to and only performs segment downloading on channels and as follows:

For , similarly, the client merely downloads segments on channels and as follows:

For , the client simply performs data downloading on channel , and thus . From (5b), .

The proof is complete.

Acknowledgment

This work was financially supported by National Science Council, Taiwan under a research grant numbered NSC 101-2221-E-152-004.