Efficient progressive downloading over multimedia broadcast multicast service

Computer Networks 56 (2012) 533–547

Contents lists available at SciVerse ScienceDirect

Computer Networks journal homepage: www.elsevier.com/locate/comnet

Efficient progressive downloading over multimedia broadcast multicast service Zeki Yetgin a,⇑, Turgay Çelik b a b

Computer Engineering Department, Mersin University, Mersin, Turkey Bioinformatics Institute, Agency for Science, Technology and Research, (A⁄STAR), Singapore

a r t i c l e

i n f o

Article history: Received 10 July 2010 Received in revised form 23 September 2011 Accepted 25 September 2011 Available online 20 October 2011 Keywords: 3G MBMS Interleaving Progressive download

a b s t r a c t The paper introduces an efficient way of delivering multimedia files over the multimedia broadcast multicast service (MBMS) and study the performance of the proposed MBMS download system on initial waiting time for progressive downloads of streamable contents. Multimedia streaming or downloading over broadcast and multicast networks is recently become conceivable for mobile users. Now there is an increasing interest to deliver broadcast and multicast data over the third generation (3G) networks such as The universal mobile telecommunication system (UMTS) since ‘‘send once charge many times’’ approach makes this type of services very attractive for 3G operators. The third generation partnership project (3GPP) has recently introduced MBMS to support IP multicasting services in UMTS. Streaming and downloading are two main services considered over MBMS. A third type of service, namely progressive download inherits the advantages of using download mechanism such as efficient usage of radio resources while it also enables users to stream multimedia files with some initial waiting time. However, there is few works that study progressive download in MBMS and current version of MBMS release have not yet an efficient mechanism to support progressive downloading. This article proposes a new approach for MBMS download mechanism that supports progressive download. The proposed systems are tested under various link conditions and packet loss scenarios specific for MBMS. The results, compared with the recent works, which have the same test assumptions, show a dramatic decrease in initial waiting time of the progressive download. Ó 2011 Elsevier B.V. All rights reserved.

1. Introduction Progressive download is a technology that enables clients to playback streamable contents while downloading continues in the background. The client may begin playback of the media after some initial waiting time before the overall delivery of the media is complete. The client experience is similar to streaming media. The main difference between streaming media and progressive download lies in how the multimedia data is received and stored by the end user. The initial waiting time is considered as one of the quality of service (QoS) and/or quality of experi⇑ Corresponding author. Tel.: +90 324 3610001; fax: +90 324 3610032. E-mail address: [email protected] (Z. Yetgin). 1389-1286/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2011.09.017

ence (QoE) parameter to measure the end user satisfaction for the progressive download. Nowadays, progressive download is very popular due to high end users satisfaction. For example, youtube (TM) streaming, which is based on progressive download over ‘‘http’’ protocol, is drawing a great deal of interest among the internet users. However, progressive download over wireless broadcast networks are more attractive for operators due to the ‘‘send once charge many times’’ approach is very beneficial and provides low cost services at the enduser. 3G wireless networks such as UMTS provide high bit-rate data transport, allowing a wide variety of multimedia services such as multimedia streaming. However, UMTS has been designed to transport data in a unicast fashion since services are typically considered to require

534

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

interactions between the service provider and the users, such as telephone conversation and internet browsing. Unicast services are very costly in that separate network resources are assigned per user. Hence, large scale data distribution makes the unicast approach inefficient. In UMTS, multicast/broadcast fashion of transport is considered as a way of saving network resources since the resources are shared among groups of users. Today, 3G operators have been integrating multicast/broadcast facilities to their network architecture to provide data distribution services to masses. Recently, 3GPP introduced support for IP multicasting services in the UMTS architecture known as MBMS [1]. Other enabling and competing technologies for multicast delivery platforms include the third generation partnership project 2 (3GPP2) broadcast and multicast system (BCMCS) [2,3], digital video broadcast for handhelds (DVB-H) [4], digital multimedia broadcasting (DMB) [5], media forward link only (MediaFLO) [6], among others [7]. Media FLO has been deployed commercially in the US for live mobile TV [8]. Norway has recently chosen DMB for mobile TV [9]. Like DVB-H, MBMS technologies such as TDtv are also in trials. In these platforms, with a large number of users receiving the same high data rate services, efficient data distribution becomes essential. MBMS’s streaming and downloading based services are all in a ‘‘one-to-many’’ nature providing groups of users with the information of common interest. Progressive downloading technology covers both streaming and downloading aspects of the MBMS services. Examples of streaming services are mobile TV, radio broadcasting, live video such as football service for which a subscription is required to watch goal replays or the complete match in real time. Download services includes multicast distribution of software updates and multicast downloads of multimedia such as the distribution of the goal replays as 3gp files. Hence, there are two delivery methods defined within MBMS, the download and the streaming delivery mode. The former is for delivering files where primary challenge is transmission reliability, while the latter is for real time multimedia delivery with strict timing constraints. The users in download delivery mode have to wait the delivery to complete before they start playing the multimedia, called legacy download here, while the users in streaming delivery mode can start playing the multimedia as soon as a few packets of the session are available. For streaming, service quality is more important and there are more challenges like the choice of efficient codecs, network latency, packet loss, and quality of service (QoS) parameters. In order to overcome these challenges and to achieve some level of QoS guarantee, streaming uses more network resources, such as bandwidth. To benefit from the advantages of the downloading while keeping the concept of the streaming the download mode has been used as an alternative to the streaming in MBMS [10–13]. An intermediate delivery mode that constitutes an actual bridge between streaming and downloading based on MBMS download delivery mode, called ‘‘preload delivery mode’’ for multimedia of limited duration is proposed in [13]. However, adding new network elements and requirement for a standardization effort are

some of the critics, which make the proposed approach difficult to be deployed in practice. Recently progressive download [10,12] is discussed as an alternative to the streaming in MBMS. With progressive download, the media can be streamed earlier, after some initial delay time, also called ‘‘waiting time’’ here, while the downloading process still continues in the background. The works in [10,12] provide the gain in waiting time from having progressive download in MBMS. In [12], interleaving strategy over the progressive download is introduced, and a detailed analysis of service parameters such as forward error correction object transmission information (FEC OTI), service data unit (SDU) and packet data unit (PDU) sizes under various UMTS link conditions is reported. In order to overcome the above mentioned drawbacks, a new approach to efficiently support the progressive download in MBMS is proposed. The motivation behind our approach is that the progressive download combines the advantages of streaming and downloading with a reduced waiting time to start playback of the multimedia for the end-users. The requirement for supporting the progressive download in MBMS is initially mentioned in [14]. However, MBMS current release has no efficient mechanism to support the progressive download yet. Progressive download in MBMS is beneficial for following reasons; (i) it enables charging many users with the little operator cost; (ii) instead of waiting for the download to complete the user satisfaction can be increased if the playback of the media starts much earlier; (iii) adding progressive download capability to MBSM will not require changes in the infrastructure since progressive download will utilize the existing download delivery mode of MBMS; and (iv) download mode uses less network resources compared to streaming in MBMS. The proposed method is based on dynamically changing the sender and the receiver behaviors during the download delivery, which are defined in MBMS release [1], to speed up the delivery process as well as to overcome the problems of packet losses and network fluctuations. Significant improvement is achieved in tolerating losses and delays in the network. With the new scheme the gain in waiting time from progressive download is increased dramatically with regards to the legacy download and the prior work [12]. The paper is organized as follows; Section 2 gives a brief overview of MBMS download delivery and its main components; FEC and file delivery over unidirectional transport (FLUTE) protocol, and discusses gains from MBMS progressive download. The problem formulation and the proposed system model are introduced in Section 3. The experiments and comparisons with the relevant methods are provided in Section 4. Finally, The paper is completed with a conclusion and possible research directions.

2. MBMS download delivery This section gives an overview of the MBMS download delivery, also called legacy download here. Fig. 1 show the MBMS network architecture model for UMTS.

535

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

MBMS Receiver Content Provider GERAN

Core Network

Gmb SGSN

BM-SC

GGSN

Gi UTRAN

IP Network

MBMS Receiver Fig. 1. MBMS network architecture model for GPRS/ UMTS.

The architectures consist of entities involved in providing MBMS services. Content provider publishes the content and broadcast multicast service centre (BM-SC) makes the delivery of the content to a group of users at appropriate schedule. BM-SC is the main entity that is responsible for managing and delivering of IP multicast traffics through the route to the target radio access network (RAN). BMSC has other functionalities as well, such as service discovery/announcement, key management for secure transmissions, additional authentication procedures to avoid unauthorized traffic entering the core network, and so on. GPRS RAN (GERAN) and UMTS RAN (UTRAN) are the two supported radio networks for UMTS. The interfaces between Gateways and BM-SC in Fig. 1, Gmb/ SGmb and Gi/ SGi-mb, are described in detail in 3GPP TS 23.246 [15]. These interfaces provide IP multicast traffic and manages MBMS bearers. The MBMS download delivery method allows the errorfree transmission of files, which is triggered by the network since the users are priori registered to the download service. There is no further user request necessary after the service registration. MBMS download delivery is based on IETF’s FLUTE [16] protocol, which is used to deliver files over unidirectional networks from one sender to many receivers. FLUTE is based on asynchronous layered coding (ALC) protocol [17] that makes the FLUTE well scalable and hence preferable for unidirectional systems. Fig. 2 shows the building components that forms the FLUTE protocol. ALC is an instantiation of layered coding transport (LCT) [18] for FLUTE. LCT describes how to transport an object identified by transport object identifier (TOI) within a

session identified by transport session identifier (TSI). ALC inherits LCT with asynchronous and FEC coding selection as underlying coding technique. Finally the FLUTE protocol inherits the ALC and provides capabilities carried in-band or via file delivery table (FDT) instances to signal the properties of the file including FEC coding descriptions and map them to the ALC protocol. With FLUTE, the only built-in reliability mechanism is provided by appplication layer FEC mechanism since FLUTE protocol uses UDP protocol as underlying transport mechanism. FEC provides reliable delivery of media content by appending repair symbols to the original data called source block prior to transmission across communication network. If some symbols are lost during transmission FEC allows receiver to use repair symbols to recover the original source block without retransmission. A source block is a fragment of the original file. A block of K source symbols constitute a source block. Fig. 3 shows the FEC method used by MBMS where K is the number of original source symbols and N is the number of repair symbols. Together K and N forms the encoding symbols. Encoding symbols is arranged in such way that K source symbols precede N repair symbols. Decoding algorithms allow the recovery of the K source symbols from any K subset of the K + N encoding symbols. Most popular FEC codes are Raptor codes as initially introduced by Shokrollahi in [19] and Reed Solomon codes (Irving S. Reed and Gustave Solomon) [20]. For the MBMS system, Raptor codes have been selected due to their high performance among others. So

K original symbols

FEC Encoder

K + N encoding symbols

FLUTE ALC LCT

CC

FEC

Fig. 2. Building block structure of FLUTE.

Any K symbols of K +N encoding symbols

FEC Decoder

K original symbols

Fig. 3. FEC encoder and decoder for MBMS.

536

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

3GPP has mandated the support of Raptor codes [1] for their terminals that uses the MBMS service. A detailed view of the MBMS download protocol stack is shown in Fig. 4. A file in application layer, called object in ALC terminology, is partitioned into source blocks (SB) of as much equal size as possible. Each SB of size K is forwarded to the FEC/FLUTE layer, where optional FEC encoding is applied to the SB. The result is an encoding block (EB) of K + N encoding symbols, N of which are repair symbols. Each encoding symbol is identified by the couple: a source block number (SBN) and an encoding symbol identifier (ESI). Starting from the first encoding symbol, a group of G consecutive encoding symbols are packed into the FLUTE payload. The FLUTE header contains FEC payload ID, which is the ESI and SBN of the first symbol in the group, transport session identifier (TSI), transport object identifier (TOI), and among others as specified in [16]. User datagram protocol (UDP) over multicast IP is used to distribute the FLUTE packets by appending further headers to the original packet at the UDP, IP, packet data convergence protocol (PDCP). At the radio link layer (RLC), protocol data units (PDU) are obtained and forwarded to the physical layer, where the data is encoded with a convolutional code, is interleaved and transmitted in small bursts. 3. System model This section provides system models of the proposed MBMS download system, which improves and extends the legacy download. The legacy download is described in detail in [12]. To emulate MBMS link conditions a transmission rate and packet loss control module are implemented. The MBMS link conditions are aligned with [21– 23]. The media is played at 128 kbps total media rate consisting of 32 kbps enhanced AAC+ and 96 kbps H.264 AVC codec. 3.1. Legacy download delivery model Fig. 5 shows the system model of the legacy download delivery where a single channel is used to transport both source and repair symbols. Repair symbols are sent just after each source block to support progressive downloading. Each SBi of size K is delivered to FEC layer for encoding.

Download Applications Download Delivery FEC FLUTE UDP IP Multicast PDCP RLC MAC Physical Layer Fig. 4. MBMS download protocol stack.

The result is EBi that includes K + N encoding symbols. A group of G consecutive encoding symbols (ESG) starting from encoding symbol ID = j within SBi is denoted as ESGi,j and identified by the ESG ID, which is (SBN, ESI) pair of the first encoding symbol in the group, here (i, j). The ESGs are packed into FLUTE payload just after the place reserved for FLUTE Payload ID that is assigned to ESG ID, here (i, j), and transported over a single channel. In this way, the symbols in all EBs are transported as ESGs inside FLUTE packet until no more encoding symbols to send. 3.2. The proposed download delivery model The proposed approach relies on the utilization of the waiting time of the progressive download as a time resource during which source and repair symbols are advantageously received over two parallel channels. The initial waiting time is defined as the waiting time from arrival of the first symbol until the start time of the media playback. The proposed system utilize the waiting time by allowing 4 mechanisms; (1) the progressive download, (2) EB interleaving, (3) overlapping of source and repair symbols and (4) FEC decoding to share a common buffer altogether. These 4 mechanisms all require initial buffering of limited time duration. Hopefully, their buffering methods allow a common queue structure to be used as a buffering block. Fig. 6 shows the system model of the proposed download delivery with the EB Interleaving of block-size b. That is, b consecutive SBs constitute an interleave-block and are encoded in parallel. The result is encoded-interleave-block (EIB) of b EBs. All encoding symbols in the EIB are sent in parallel in the order of corresponding ESIs. For example, encoding symbols in the EIB with ESI = 1 will be sent first, those with ESI = 2 will be sent next and so on. There are two channels proposed in the system: K-channel and N-channel. K-channel carries original source symbols while Nchannel is for carrying repair symbols. Both channels are interleaved to minimize the losses arising from burst errors. One requirement of our interleaving strategy is that one encoding symbol must be included into each FLUTE packet. The parameters b and SB size can be used to adapt to different service conditions in that increasing the interleave-block size consumes much more memory and complicates the cost of the download process. Memory related issues are out of scope of this study. Sending the source and repair symbols in parallel can enable receivers to overlap the receiving of the related symbols, those belonging to same EIB, in time so that extra waiting time for the repair symbols becomes unnecessary. As shown in Fig. 6, a separate thread triggered by the main process is used to transmit repair symbols over N-channel in parallel with the main process on K-channel. However, sending source and repair symbols in parallel does not necessarily imply that receivers could receive them in parallel since receiving of source and repair symbols of a source block might not coincide within a time window of limited duration due to fluctuations of inter-symbol delays in the network. In order to overlap them, a buffer should be used to collect related symbols of the blocks within a time window. Hopefully, the progressive download requires each

537

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

File Partitioning

SB 1

SB i

SB Z

SB i + 1

K SB i FEC Encoding SB i EB i

K+N

ESG i , j ES i , j

ES i , j + G

PACKETIZE

IP Header UDP Header FLUTE Header

i,j

ES i , j

ES i , j + G

FLUTE Payload ID = ( i , j )

TRANSPORT

j=j+G Repeat Until j >= K + N Process Next Source Block Fig. 5. System models for the legacy download delivery.

media block to stay in the buffer for a limited time window. Buffering is defined as the saving of encoding symbols into a number of EIB structures, buffer size, for a particular time period called as the time window. The time window of a particular block (EB/SB, EIB/IB) is the waiting time of the block in the buffer until its playout time is reached by the player. The player cannot handle EBs if they are not yet reconstructed to the original SBs. Producer–consumer problem occurs over the buffering block, which is implemented as link list queue of EBs. The client download process puts the received symbols into their original structures in EBs close to tail, and decodes EBs to SBs when they are ready. The client player process consumes the SBs, in front, for their playouts. The player stops when there is no data block to read next in the buffer. This happens if end of file is reached or next SB is unavailable yet in the buffer. All EIBs in the buffering block could be reconstructed eventually to their original IBs within a time window of limited duration if reliability is provided with

sufficient FEC overhead. An effective progressive download requires a constant stream playback without intermittent stops based on reliable download delivery. During the blocks’ waiting time in the buffer, fluctuations of symbols due to losses and delays in the network, overlapping of source and related repair symbols, and reconstructions of the blocks are all handled in parallel. An example of complete parallelism is shown in Fig. 8b where the shapes used are explained in Fig. 7. The pair i, j of each Ki,j and Ni,j, refer to FLUTE payload ID where i shows the source block number, j shows the encoding symbol ID, K indicates the source symbol while N indicates the repair symbol. In Fig. 8, an example download delivery is considered to transport a file that is partitioned into 3 source blocks (SB1, SB2, SB3) of 2 symbols each. 50% FEC overhead is used for repairing. So each EB contains 3 symbols, consisting of 2 source symbols and 1 repair symbol. A scenario for the legacy download is given in Fig. 8a where the first two source symbols, K1,1, K1,2, and the last repair symbol, N3,3, are lost during the transmission on

538

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

File Partitioning Interleave-Block SB 1

SB i

SB Z

SB i + b

SB i + 1

K

For k : i . . i + b FEC Encoding SB k

Encoded-Interleave-Block EB i

EB i + 1

EB i + b

K+N Send_Interleaved_Source_ Blocks(&SBi )

Send_Interleaved_Repair_ Blocks(&EBi )

Thread

Main Process

For k : i . . i + b

For s : K + 1 . . K + N For k : i . . i + b

For s : 1 . . K Packetize ES k , s = SB k (s)

IP Header UDP Header

FLUTE Header k, s ES

Packetize ES k , s = EB k (s)

k,s

IP Header UDP Header

FLUTE Header k, s ES

k,s

FLUTE Payload ID = (k, s)

FLUTE Payload ID = (k, s)

TRANSPORT on N-channel

TRANSPORT on K-channel

Process Next Interleave-Block Fig. 6. System model for the proposed download delivery.

K i, j Receiver completes receiving the symbol

N i, j Receiver starts receiving the symbol

X

Symbol lost in the network

Fig. 7. Interpretation of the shapes in Figs. 8 and 9.

the network. Since two symbols of the first encoding block (EB1) are lost, SB1 cannot be reconstructed at the receiver

side. However, the last source block (SB3) can be successfully reconstructed due to having two symbols of the last

539

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

(a)

X

N3 , 3

K3 , 2

K3 , 1

N2 , 3

K2 , 2

K2 , 1

N1 , 3

X

(b) K3 , 2

K2 , 2

K1 , 2

X

N3 , 3

X

K1 , 2

K1 , 1

X

K3 , 1

K2 , 1

N2 , 3

Single Channel

X

K1 , 1

N1 , 3

K-Channel

N-Channel

Buffering Block Complete Overlapping with Successfull Reconstruction

(c)

X

X

K3 , 2

K2 , 2

K1 , 2

X

N3 , 3

K3 , 1

K2 , 1

N2 , 3

K1 , 1

N1 , 3

K-Channel

N-Channel

Buffering Block Complete Overlapping with Unsuccessfull Reconstruciton

(d) K3 , 2

K2 , 2

K1 , 2

N3 , 3

K3 , 1

K2 , 1

N2 , 3

K1 , 1

N1 , 3

K-Channel

N-Channel

Buffering Block Partial Overlapping with Successfull Reconstruction

(e)

X

X

K3 , 2

K2 , 2

K1 , 2

N3 , 3

K3 , 1

K2 , 1

N2 , 3

K1 , 1

N1 , 3

K-Channel

N-Channel

Buffering Block Partial Overlapping with Unsuccessfull Reconstruction

(f)

X

K3 , 2

N3 , 3

N2 , 3

K2 , 2

K1 , 2

K3 , 1

K2 , 1

K1 , 1

N1 , 3

K-Channel

N-Channel Buffering Block None Overlapping with Unsuccessfull Reconstruction

(g) K3 , 2

N3 , 3

N2 , 3

K2 , 2

K1 , 2

K3 , 1

K2 , 1

K1 , 1

K-Channel

X

N1 , 3

N-Channel Buffering Block None Overlapping with Successfull Reconstruction

Fig. 8. Examples scenarios for (a) legacy download (b) proposed download in complete overlapping with successful reconstruction (c) proposed download in complete overlapping with unsuccessful reconstruction (d) proposed download in partial overlapping with successful reconstruction (e) proposed download in partial overlapping with unsuccessful reconstruction (f) proposed download in none-overlapping with unsuccessful reconstruction (g) proposed download in none-overlapping with successful reconstruction.

540

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

or have severe performance problems even though reconstructions are done later in time while the downloading aspect could be successful as long as reliability is provided. When the progressive download delivery is considered over two channels, overlapping of related symbols within a time window and the reliability over the time window are main challenges. Hence, the time window or equivalently the buffering block size becomes vital for the proposed download delivery method. Higher initial waiting time results in higher buffering block size, hence, higher probability of overlapping as demonstrated in Fig. 9 where the receiver buffering 2 EIBs sees a complete overlapping even though source and repair symbols of each EIBs are none overlapped in buffering block #1 and #2. There is a self balanced approach in that changing network conditions due to losses and delays cause the waiting time to increase. This means the buffering block size should increase. In turn, higher overlapping of source and repair symbols in the larger buffering block causes the waiting time to decrease. Final situation is a balance at a point in the middle. Any bad condition resulting in larger buffering block size soon creates a positive reaction causing this bad effect to be limited. With this property, the proposed system can adapt to the changing conditions in the network by automatically balancing the buffering block size.

encoding block at the receiver. In the examples given in Fig. 8b and g, the proposed download system is used where source and repair symbols are carried over K and N-channel respectively, each of which is EB-interleaved with an interleave-block of 3 EB. In Fig. 8b, same download scenario is considered with Fig. 8a. As Fig. 8b and d indicate, all source blocks are successfully reconstructed in less download time by overlapping the source and repair symbols on K and N-channel. In the examples given in Fig. 8b–g, for simplicity, the buffering block is considered to contain a single EIB structure where various overlapping states of source and repair symbols belonging to the EIB are demonstrated. When the receiver has the last successfully received source symbol in the buffering block on K-channel if all related repair symbols that are able to arrive at the receiver has been received already on N-channel the state is called as complete overlapping, shown in Fig. 8b and c. Hence, complete overlapping occurs either there exists no repair symbol (see Fig. 8b) or there exist some lost repair symbols (see Fig. 8c), after the last successfully received source symbol in the buffering-block. Similarly, partial overlapping, shown in Fig. 8d and e, occurs when the receiver has the last successfully received source symbol in the buffering block on K-channel if some related repair symbols are received already and some will be received in later phases of the buffering block (see Fig. 8d and e). None overlapping occurs if no repair symbols are received yet before the last successfully received source symbol of the buffering block (see Fig. 8f). Hence, none overlapping occurs either there exists no repair symbol (see Fig. 8f) or there exist some lost repair symbols (see Fig. 8g), before the last successfully received source symbol of the buffering block. To explain the importance of the buffering block size an example is given in Fig. 9 where the file is partitioned into 6 source blocks of 2 symbols each and 50% FEC overhead is used. So there are totally 2 IBs of 3 SB each. According to Fig. 9, when the buffering block contains one EIB, none of the related symbols are neither overlapped nor reconstructed during the time window. When the buffering block size becomes two EIBs, they become overlapped and reconstructed successfully. Any fail in reconstruction of source-blocks during the time window causes the streaming aspect of the progressive download to be fail

X

K6, 2

N6, 3

K5, 2

X

N5, 3

K4, 2

K6, 1

K5, 1

K4, 1

X N4, 3

N3, 3

N2, 3

Buffering Block#2 None Overlapping with Unsuccessful Reconstruction

3.3. Problem formulation In this section, the formalization of the problem is given. A receiver doing a successful progressive download with the worst case scenario is shown in Figs. 10 and 11 where the receiving rate is less than the media play rate, and downloading and playing finish almost at the same time. The best case when a receiver experiences a higher play rate than the receiving rate is shown in Fig. 12. The term ‘‘waiting time’’ is used to mean the initial waiting time in progressive download while it refers the downloading time in legacy downloads. On receiver side, when an EIB is ready to decode, i is incremented, decoding of EIBi is performed and Ti is assigned to a timestamp, the time of writing the interleave-block (b number of SBs) to the file. At time Ti, perceived receiving rate (Ri) and the time window (TWi) are computed since the buffering block is restructured due to removing EIBi from the queue. Ri and

K3, 2

K2, 2

K1, 2

K3, 1

X

K2, 1

K1, 1

K-Channel

X

N1, 3

Buffering Block#1 None Overlapping with Unsuccessful Reconstruction

Larger Buffering Block Complete Overlapping with Successful Reconstraction Fig. 9. Overlapping and reliability over the time window.

N-Channel

541

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

Fz

TW z= 0

Fz-1

TW z - 1

TW i

Fi Fi - 1

TW1

F1

TW0= T d

0

T0

T1

Ti - 1 Ti

Td

T z -1 T z

Fig. 10. Decreasing time windows for worst case receiver.

Fz

BS z= 0

Fz-1 BS z - 1 Fd Fi BS d= Fd BS i

Fi - 1

F1 0

BS1= F1 T0 T1

Ti - 1 Ti

Td

T z -1

Tz

Fig. 11. Buffer size as a function of time for worst case receiver.

TWi reflect the current state of the system at time Ti since transmission rates, FEC ratios, losses, delays, and overlapping states all affect Ri. Ri, media play rate and buffering block size affects TWi. At time Td media can be started to play progressively by the receiver. Receivers observe the perceived receiving rate after receiving the first interleave-block, which is used as the initial buffering block, the size of which is BS1 at time T1 shown in Fig. 11. During each DTi = Ti  Ti1 one interleave-block is reconstructed. However, due to delays and losses in the network, reconstruction of the interleave-block might be delayed. According to Fig. 10, TW0 is the maximum period

indicating the initial waiting time of the progressive download. That is, initially received symbols are kept in the buffering block until time Td where after the time windows tend to decrease until the end of the download. Similarly, buffering block size increases till time Td where it has the largest value (BSd = Fd) as shown in Fig. 11, thereafter it decreases till it becomes zero at the end of the download. Over TWi the symbols on K-channel and N-channel are forced to be overlapped in the buffering block since source and repair symbols of the EIBi will be eventually combined in the buffer due to the reliable delivery. Receiver’s perceived receiving rate, Ri, is used to approximate the waiting

542

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

TW z

Fz Fz-1

Fd

TW i

Fi Fi - 1

F1 0

TW 1

T0 Td T1

Ti - 1 Ti

Tz

T

Fig. 12. Increasing time window for the best case receiver.

time of the progressive download. First, partial receiving rate ri is defined as the ratio of downloaded file size during the time interval Ti1 and Ti.

F i  F i1 DF i ¼ ; T i  T i1 DT i r i þ Ri1 Ri ¼ ; 2

ri ¼

ð1Þ ð2Þ

where F0 = 0, T0 is the arrival time of the first FLUTE packet of the session on either K or N-channel; Fi denotes downloaded file size in KB and ri denotes partial receiving rate in Kbps, Ri is Perceived Receiving Rate at time Ti, R0 = r1, i: 1 . . . z, z is the total number of interleave-blocks. Approximated value for the initial waiting time of the progressive download at time Ti is as follows;



 1 1 : Di ¼ T d ffi F   Ri Rmedia

ð3Þ

Di should be large enough to support the progressive download and interleaving as well as overlapping of related symbols. To cover minimally one EIB buffering time, which is required for interleaving, initial waiting time of the progressive download is updated at time Ti as follows;

Di ¼ T d ¼ maxðDi ; DT iþ1 Þ:

ð4Þ

In general the waiting time of symbols in the buffering block at time Ti is as follows;

TW i ¼ T d  T i þ

Fi ; Rmedia

T i ¼ F i =Ri :

ð5Þ ð6Þ

By substituting Td Eq. (3) and Ti Eq. (6) in Eq. (5), Eg. 7 is generated.

TW i ¼ F=Ri  F=Rmedia  T i þ F i =Rmedia ¼ F=Ri  F=Rmedia   1 1  F i =Ri þ F i =Rmedia ; TW i ¼ ðF  F i Þ   ; Ri Rmedia

ð7Þ

where TW0 = Td denotes initial waiting time, TWi denotes the time window at time Ti, Rmedia denotes media play rate in Kbps; F = Fz is media file size in KB; Fi is downloaded file size in KB at time Ti; Ri is the perceived receiving rate computed using Eq. (2), i : 1 . . . z, z is the total number of interleave-blocks. At time T0, Fi is zero and TWi approximates to Td. At time TzFi becomes F and TWi becomes zero as shown in Fig. 10. Similarly, to support both progressive download and interleaving. TWi should be large enough to cover minimally one EIB buffering time. So TWi at Eq. (7) is updated as follows;

TW i ¼ maxðTW i ; DT iþ1 Þ;

where i ¼ 0 . . . z  1

ð8Þ

For the best case receiver, shown in Fig. 12, initial waiting time is considered as the buffering time of the first EIB, which is equal to DT1 = T1  T0, due to higher receiving rate than the play rate. So the proposed method requires minimally waiting one EIB buffering time. In contrary to the worst case receiver, the best case receiver observes a small time window first and then increasing windows until the end of the download. So an effective progressive download system should have small time window before the time Td, large or increasing time windows after time Td. The receiver experiencing higher play rate than the receiving rate, observes decreasing time windows after media playback starts. If the receiver has no capability of interleaving and overlapping symbols over two channels, sooner or later the buffer becomes empty and the time window becomes zero where the player must stop the media playback temporarily for the buffer to have more data blocks. However, with the proposed approach this decrease in both buffer size and the time window has a limit in that minimally the buffering block must contain b number of EBs (one EIB) and the parallel channels are still useful to increase the receiving rate. General behavior of the receiver is described as follows;

543

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

i = 0; Buffer = NULL; Wait_Until_First_Flute_Packet (); Ti Current_Time (); While not Session_Closed Do { EIB Wait_Any_EIB_to_Decode () Add_to_Buffer (Buffer,EIB); IB FEC_Decode_on_Buffer (EIB) i i+1 Ti Current_Time(); Write_to_File (IB); Ri Compute_Ri(IB,Ti,Ti1) Di Compute_Initial_Waiting_Time(Ri); If Ti >= Di Then { Start_Media_Playback (Buffer); } }

G is defined as the gain in waiting time for progressive download compared to legacy download. Gain can be computed using R and T as follows:

TZ ¼

F ; RZ

ð9Þ

  Td ; G ¼ 100  1  TZ

ð10Þ

where Tz denotes the duration of the legacy download of the media in seconds. 4. Experimental results This section shows the results of our experimental analyses for the proposed download delivery and provides comparison of the legacy download, legacy progressive download and the proposed progressive download delivery with respect to the initial waiting time. The parameters considered during the experiments are given in Table 1. Experiments are emulated on a set of computers on a LAN of ethernet types. One computer running MBMS download server and the others running the MBMS download clients constitutes an MBMS download system. The MBMS download systems are actually our emulation pro-

grams that are based on [24], and aligned with [21–23]. We have also implemented a service announcement system based on MBMS download. Service announcement system has a user interface with which session files, destination group identified by the multicast group and port, session start-stop times, FEC OTI as well as the other service parameters are selected. Clients’ user interface has option to join to the announcement service. By default all clients know the announcement service by a priori assigned multicast group. Once clients join to the announcement service, they can receive metadata such as service description files of new MBMS services. Many services could be announced over the announcement service. Newly incoming MBMS services are added to a separate panel through which client can join to the service. Server starts delivery of the files to the multicast group when the service’s start time is on. Multicasting is achieved using local multicast to a group based on IP/UDP/FLUTE protocol. Both server and clients have local databases maintaining the configuration parameters given in Table 1. To simulate MBMS link conditions a transmission rate and packet loss control module aligned with [23] are implemented. Transmission rates, IP size, FEC OTI and interleaving parameters are implemented on server side. Playing rate and link layer functionalities such as RLC block sizes, PDU loss ratios and mapping of SDU blocks to RLC blocks are implemented in client side. Each client creates a record after each MBMS download based on a particular set of configuration parameters shown in Table 1. The record contains evaluated target parameters for the selected set of configuration parameters. Several set of configuration parameters are scheduled to initiate several downloads with different characteristics. Each download experiment for one set of configuration parameters has 100 download iterations. After performing experiments for all the combinations of the configuration parameters, optimum target values are selected based on averaging.

4.1. Experimental results for the legacy progressive download model The legacy progressive download analyses using Reed Solomon FEC coding is shown in Fig. 13. Reed Solomon

Table 1 Parameters studied across layers. Parameter

Unit

Layer

Experiment set

File size Waiting time in legacy and proposed download Gain from proposed download Symbol length SB size IP packet size SDU block size PDU block size (RLC block size) PDU (RLC link layer) Losses Transmission rates Interleave-block size Media play rate

Kilobyte {Second, Percent} {Second, Percent} Byte Symbol Byte Byte Byte Percent Kbps Source block Kbps

Application Application Application FEC FEC IP Core network RLC radio L. RLC Radio L. All layer FEC Application

3078 To be determined in this study To be determined in this study {SDU  48} {10, 50, 80, 100, 120, 150, 180, 200, 230} {SDU} {600, 800, 1000} {640, 1280} {1, 5, 10} {64, 128, 256} {3} {128}

544

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

the receiver observing higher receiving rate than the media play rate, the waiting time increases for large SB size due to the requirement to wait the reconstruction of the first SB (see 256 kbps transmissions in Fig. 13). Although the progressive download using the legacy download provide improvements in waiting time (see Tables 2–4) with respect to using only legacy download, the resulting waiting times are still not acceptable for the networks experiencing high packet losses or low transmission rates. The clients receiving the media minimally around the media play rate, 128 kbps, could experience acceptable initial waiting time. However, observing a receiving rate of 128 kbps is even impossible under the network having 128 kbps transmission rates due to overheads, delays and packet losses. The waiting time of progressive download with 128 kbps transmission rate varies between 30–90 s,

FEC performance is very bad at small SB sizes where high FEC ratios make the waiting time unacceptable. In Fig. 13, the waiting time values above 580 s are not displayed for the purpose of visualization. Increasing SB size decreases the waiting time. The waiting time is dramatically reduced when the SB size is increased up to 50–80 symbols. However, the increase in SB size beyond a threshold value would result in an increase in the waiting time in spite of still reducing the FEC overhead. This property provides trades off between waiting time and FEC overhead. Existing works aim minimum FEC overheads for an optimum system. However, FEC overhead alone is not enough to describe the system performance as a whole. In Fig. 13 slightly higher FEC ratios, given in Tables 2–4, than those of proposed for MBMS [21] are found to provide a time efficient MBMS system with corresponding parameters. For

Fig. 13. Initial waiting time of the legacy progressive download.

Table 2 Comparision of systems for 256 kbps transmission rate. Transmission Rate 256 kbps File size (KB)

PDU loss (%)

FEC overhead (%) Leg. model

Prop. model

3078 3078 3078

1 5 10

7 19 37

5 16 32

Waiting time in Legacy D. (sec.)

Waiting time in leg. progressive D. (sec.)

Waiting time in proposed D. (sec.)

Proposed download gain with respect to legacy D. (%)

Proposed download gain with respect to progressive D. (%)

111 126 143

1 2 3

2 3 3

98 98 98

0 0 0

545

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547 Table 3 Comparision of systems for 128 kbps transmission rate. Transmission rate 128 kbps File size (KB)

PDU loss (%)

3078 3078 3078

1 5 10

FEC overhead (%) Leg. model

Prop. model

7 19 37

5 16 32

Waiting time in legacy D. (sec.)

Waiting time in leg. progressive D. (sec.)

Waiting time in proposed D. (sec.)

Proposed download gain with respect to legacy D. (%)

Proposed download gain with respect to progressive D. (%)

222 249 283

30 57 91

18 19 19

92 92 93

40 66 79

Waiting time in legacy D. (sec.)

Waiting time in leg. progressive D. (sec.)

Waiting time in proposed D. (sec.)

Proposed download gain with respect to legacy D. (%)

Proposed download gain with respect to progressive D. (%)

452 513 598

260 321 406

222 225 232

50 56 61

15 30 43

Table 4 comparision of systems for 64 kbps transmission rate. Transmission rate 64 kbps File size (KB)

PDU loss (%)

3078 3078 3078

1 5 10

FEC overhead (%) Leg. model

Prop. model

8 21 41

7 19 37

Fig. 14. Initial waiting time of the proposed progressive download model.

which is still far away from the acceptable range, 0–5 s. However, it is much better than the legacy download where 222–283 s of waiting time is required to start the media playback.

4.2. Experimental results for the proposed download model The progressive download analyses based on the proposed download model are provided in Fig. 14. Initial

546

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547

waiting time is dramatically decreased when SB size increases up to 50–80 symbols. This is caused by the inefficiency of Reed Solomon FEC performance at small SB sizes. The overlapping of lines in Fig. 14 is an important property of our approach, which is caused by the overlapping of source and repair symbols over two channels. Overlapping ratio increases when SB size increases. However, in contrary to the legacy model, the waiting time increases after SB size 50–80 since increasing SB sizes increases the waiting time to reconstruct one interleave-block. With this property, the proposed approach enables a robust progressive delivery tolerating the delays and losses in the network. As shown in Fig. 14, deliveries considered under %1–10 link layer losses almost perform same with sufficient large SB size. This property gives more supports to the streaming. The network operators could consider using large FEC overheads with the cost of minimum FEC overheads. Furthermore, the proposed approach could tolerate fluctuations during delivering packets. With the proposed approach, a dramatic decrease in waiting time is observed with respect to the legacy based models. For example, with the network having 128 kbps transmission rates and 10% link layer loss, the initial waiting time is 19 s. However, the legacy download takes 283 and progressive download takes 91 s of waiting time for the same download. 4.3. General comparisons of systems Summary of comparisons for the legacy, legacy progressive and proposed progressive download system are provided in Tables 2–4. Since interleaving is used in proposed model FEC ratios are slightly less than the legacy models. It is clear that proposed download model outperforms the legacy models under the same network and link conditions by providing dramatic decrease in waiting time. One exception to that is the network with 256 kbps bearer where the receiver minimally waits until receiving the first interleave block even if the initial waiting time of the progressive download is not required. However, high transmission rates makes this waiting time negligible as shown in Table 2. Comparing with the legacy download, proposed model achieves over 90% performance superiority for high transmissions and over 50% for low transmission rates. Furthermore, proposed model provides 60% and 30% performance increase on the average waiting time for 128 and 64 kbps transmissions with regards to the progressive download. 5. Conclusion 3GPP’s MBMS download delivery is focused with new novel methodologies applied on it. The issues related to progressive download are identified and several approaches are demonstrated to further improve the performance of progressive download in MBMS. It is particularly shown that the progressive download services require more support in MBMS. A new download model that provides an efficient support to the progressive download in MBMS is proposed.

The model is tested under different scenarios considered for MBMS. It has been shown that the proposed model efficiently reduces the waiting time to start playing the media. It is also shown that the proposed model provides time efficient and robust downloading under changing network conditions. With the proposed model, the network operators could provide services with high QoS as well as high QoE. The work will also be useful for wireless multicast/broadcast service providers for identifying various issues, resolving them and optimizing the system performance. References [1] 3GPP TS 26.346, Multimedia Broadcast/Multicast Service (MBMS); Protocols and Codecs, version 9.4.1, March 2011. [2] J. Wang, R. Sinnarajaj, T. Chen, Y. Wei, E. Tiedemann, Broadcast and multicast services in cdma2000, IEEE Communication Magazine 42 (2004) 76–82. [3] 3GPP2 TS C.S0054-A, CDMA2000 high rate broadcast-multicast packet data air interface specification, version 1.0, February 2006. [4] ETSI TS 102 472, Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Content Delivery Protocols, version 1.3.1, June 2009. [5] ETSI TS 102 428, Digital Audio Broadcasting (DAB); DMB video service; User application specification, version 1.2.1 April 2009. [6] F. -Long, Luo, mobile multimedia broadcasting standards, in: Q. Gao, M. Chari, A. Chen, F. Ling, K. Walker (Eds.), MediaFLO Technology: FLO Air Interface Overview, Qualcomm Inc.,, San Diego, USA, 2009, pp. 189–220. [7] F. -Long, Luo, Mobile Multimedia Broadcasting Standards Technology and Practice, Springer Sci., 2009. [8] (10 September 2011). [9] (10 September 2011). [10] Z. Yetgin, G. Seckin, Progressive download for 3G wireless multicasting, IEEE CS, Proceedings of the Future Generation Communication and Networking 1 (2007) 289–295. [11] Z. Yetgin, G. Seckin, Reliable download analyses for multimedia broadcast multicast services, in: IAENG The World Congress on Engineering and Computer Science, San Francisco, USA, October, 2007. [12] Z. Yetgin, G. ve Seckin, Progressive download for multimedia broadcast multicast service, IEEE MultiMedia 16 (2009) 76–85. [13] 3GPP TSG Tech. Doc. S4-060385, Content Preloading for MBMS User Services, Sophia Antipolis, France, August 2006, (10 September 2011). [14] 3GPP TSG Tech. Doc. S4-060267, Support of Progressive Download in MBMS, Dallas, TX, USA, May 2006, (10 September 2011). [15] 3GPP TS 23.246, Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional description, version 9.5.0, June 2010. [16] T. Paila et al,, FLUTE, File delivery over unidirectional transport, IETF RFC 3926, (10 September 2011). [17] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft, Asynchronuous layered coding (ALC) protocol instantiation, IETF RFC 3450, (10 September 2011). [18] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, J. Crowcroft, Layered coding transport (LCT) building block, IETF RFC 3451, (10 September 2011). [19] A. Shokrollahi, Raptor codes, IEEE/ACM Transactions on Networking 14 SI (2006) 2551–2567. [20] J. Lacan, V. Roca, J.Peltotalo, S. Peltotalo, Reed Solomon forward error correction, IETF RFC 5510, (10 September 2011). [21] 3GPP TSG Tech. Doc. S4-040348, Permanent document on: simulation guidelines for the evaluation of FEC methods for MBMS download and streaming services, Canada, May 2004, (10 September 2011). [22] 3GPP TSG Tech. Doc., S4-AHP120, Mapping of SDUs to Radio Blocks for FEC simulations, April 2004, (10 September 2011).

Z. Yetgin, T. Çelik / Computer Networks 56 (2012) 533–547 [23] 3GPP TS 26.946, Multimedia Broadcast/Multicast Service (MBMS); User service guidelines, version 9.0.1, March 2011. [24] MAD-FLUTE project, (10 july 2011).

Turgay Celik received the Ph.D degree in Engineering from University of Warwick, U.K. He is currently a Research Fellow at the Bioinformatics Institute, Agency for Science, Technology and Research (A⁄STAR), Singapore. He has produced extensive publications in various international journals and conferences. He has been acting as a Reviewer for various international journals and conferences. His research interests are in the areas of biophysics, digital signal, image and video processing, pattern recognition and artificial intelligence. These include fluorescent microscopy, digital image/video coding, wavelets and filter banks, image/ video processing, content-based image indexing and retrieval, and scene analysis and recognition.

547

Zeki Yetgin studied mathematics in Science Faculty in Gazi University, Ankara, Turkey. He received a B.Sc. degree in 1999 and an M.Sc. degree in 2002 from Eastern Mediterrenean University, Computer Engineering Department, Famagusta, Northern Cyprus, Turkey. He has received his Ph.D in Department of Computer Engineering from Dokuz Eylul University, Izmir, Turkey. His research interests are mainly in the area of reliable multimedia transmission over wireless channels. He is particularly involved in MBMS. His other interests are researches including Parallel and Distributed Computing, Learning and Reasoning in Fuzzy environments and Image/Speech processing.