Progressive Download for Multimedia Broadcast ... - Semantic Scholar

2 downloads 922 Views 940KB Size Report
of the legacy and the interleaved progressive download delivery is provided. .... reliable delivery of media content by appending repair symbols to the original ...
Progressive Download for Multimedia Broadcast Multicast Service* Zeki Yetgin, Gamze Seckin [email protected], [email protected] Abstract-This study focuses on the gain of using progressive download instead of legacy download and proposes ways to increase the gain for streamable multimedia files for 3GPP’s wireless multimedia broadcast multicast system (MBMS). With progressive download, downloadable media can be streamed earlier, after some waiting time. Since MBMS download mechanism uses unreliable multicast, Forward Error Correction (FEC) is used to recover from packet losses. First optimizations are provided for an efficient legacy download. Then based on these optimizations, experimental analyses are provided to show the gain in using progressive download in MBMS. Finally in order to further increase the progressive download performance, an application layer interleaving strategy is applied to MBMS download systems and a performance comparison of the legacy and the interleaved progressive download delivery is provided. Keywords: 3G, MBMS, Interleaving, Progressive Download.

1. INTRODUCTION The advent of new technologies in multimedia applications with a parallel progress in transport technologies has revolutionized the way multimedia services are delivered to masses. Downloading, streaming and progressive downloading [1] of multimedia distribution can be done in the form of unidirectional multicasting or broadcasting for wireless environments. Enabling technologies for these delivery platforms are 3GPP MBMS [2], 3GPP2 [3] BCMCS (Broadcast and Multicast System), DVBH (Digital Video Broadcast for Handhelds) [4] among others [5]. Recently, 3GPP introduced support for IP multicasting services in the UMTS (Universal Mobile Telecommunications System) architecture known as MBMS which enables a service to be offered to thousands of users simultaneously in a point-to-multipoint manner. There are two delivery methods defined within MBMS, the download and the streaming delivery mode. Download delivery mode is for delivering files where transmission reliability is important. Streaming is real time delivery of continuous media. For streaming, the quality is important and there are some challenges like the choice of efficient codecs, network latency, packet loss, and quality of service. Downloading mode consumes less radio recourses despite its longer time of service consumption with regards to streaming mode, but has strict reliability constraints compared to streaming.

Recently progressive download type [1] is discussed as an alternative to the streaming in MBMS. With progressive download, downloadable content can be streamed sooner, after some initial startup delay, also called waiting time in this paper, while the downloading still continues in the background. There are two ways considered to play the media in download delivery. First is to wait for the download *

This work is part of EEEAG 104E163, a project sponsored by Vidiator Technology (US) Inc, TUBITAK, The Turkish National Science Foundation, and Dokuz Eylul University, Department of Computer Engineering.

1

to complete and then play the media. Second is to wait for some initial startup time and then play the media while downloading it. First one is called Legacy Download while the latter is called Progressive Download. Hence progressive download is important in that it reduces the waiting time substantially, which will be demonstrated in this work. The progressive download combines the advantages of streaming and downloading in terms of time, reliability and bandwidth. By its nature, it could be considered a software overlay on top MBSM download mode. There are two important parameters for MBMS progressive download; transmission cost and initial startup delay. Minimum waiting time, called downloading time optimization, and minimum transmission cost, called transmission cost optimization, with reliability requirement are the targets for an acceptable service. Transmission cost optimization minimizes the FEC overhead required for a reliable download. However downloading time optimization minimizes the initial startup delay as well as the download duration. MBMS should support the progressive download for three reasons; the first reason is while the media is being downloaded in the background the user doing a legacy download is already assumed to wait until the download completes before playing the media. Instead of waiting for the download to complete the user satisfaction can be increased if media can be started to play much earlier. The second reason is the optimization of MBMS radio resources since download mode uses less bandwidth compared to streaming. The third reason, 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. MBMS Progressive download is still an open issue in 3GPP and related discussions [1] are postponed to future MBMS releases. One of the important reason, among many, is there is no clear work that show the gains from having progressive download in MBMS. The main problem addressed in this paper is to show the possible gains from having progressive download in MBMS for small size 3gp multimedia files, instead of big files, which require long waiting time that is not acceptable for user experience. Constant bit rate encoding is considered since variable bit rate makes waiting time prediction difficult and requires more capability in receiver side. Enhanced AAC+ and H.264 AVC [2] [6] coding with total 128 kbps media play rate is used. To provide further contributions to improve the gains, our downloading time optimization and application layer interleaving strategy are introduced. Interleaving can be used in communications systems to enhance the error correcting capabilities of FEC mechanism. In practice packet losses occur as error bursts. One packet loss possibly causes one or more consecutive packets to be lost. With interleaving mechanism such negative effects can be removed so that a reduction in transmission cost is gained by necessitating less amount of FEC overhead. Hence an increase in download efficiency is observed. By applying application layer interleaving to legacy and progressive download we get so called interleaved-legacy and interleaved-progressive download respectively. This paper studies four MBMS download systems: Legacy, Progressive, InterleavedLegacy and Interleaved-Progressive Downloads. Here after, the term legacy download refers to the downloading time optimized legacy download unless otherwise stated. The paper is organized as follows; second section 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. In the third section the system model including an analytical model to formulize the problem are provided. In the fourth section experimental results of four MBMS download system proposed in this paper; (i) Legacy downloads with optimizations, (ii) Progressive download, (iii) Interleaved-legacy download, (iv) Interleaved-progressive download and their evaluations are provided. Then a conclusion is given in final section. 2. RELATED WORK Recently progressive download of 3GP media files in MBMS is studied in 3GPP working groups [1]. According to PSS specification [7], PSS clients already support progressive download of 3GP media files with HTTP connection over TCP/IP. However, progressive download in MBMS is still in debate and currently few works [1] [8] exist to support MBSM progressive download.

2

MBMS downloading optimization is studied in [9] for minimum FEC overheads for both Reed Solomon and Raptor FEC. In MBMS, FEC mechanisms have been studied on two layers, namely physical layer and application layer, in a complementary way. The tradeoff in applying one or the other or suitable combinations of the two is addressed in [10] and [11]. MBMS download delivery has already been analyzed in 3GPP working groups. Reed-Solomon codes with and without interleaving [12] [9] and Raptor codes, also investigated in [13] [10] for MBMS, are used in these analyses. Generally interleaving mechanism above FEC layer is studied as random transmission of symbols [12]. However random transmission strategy disables the progressive download. Our recommendation is to use an interleaving strategy that also enables progressive downloading. This issue is also addressed in [9]. As an alternative to the streaming, [14] presents an intermediate delivery mode that constitute an actual bridge between streaming and downloading and based on MBMS download delivery mode, called “Preload Delivery Mode”, for multimedia of limited duration. 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. The work extends [9] that only provide the gain in FEC overhead from application layer interleaving method for transmission cost optimized MBMS download delivery. In this work rather than the transmission cost optimization we focus on downloading time optimization since it provides a decrease for waiting time in MBMS download. We extend [9] by applying application layer interleaving to MBMS progressive downloading [8] in order to further decrease the waiting time. So this paper combines the approaches in [8] and [9] to provide the total gain from the interleaved progressive download. As different from [9] followings are provided: (i) Optimizations for Legacy-Download delivery are done to explore Reed Solomon FEC protected MBMS from the progressive download point of view, (ii) Analysis of the Progressive-Download is done to find the gain in waiting time, (iii) Analysis for the Interleaved-Download delivery is done to find the gain in downloading time and transmission cost and, (iv) Analysis for the Interleaved-Progressive-Download delivery is done to find the possible gain in waiting time and transmission cost. 3. MBMS DOWNLOAD DELIVERY This section gives brief overview of MBMS Download delivery. MBMS download delivery is based on FLUTE [15] protocol used to deliver files particularly over unidirectional systems from one sender to many receivers. FLUTE is an IETF protocol based on Asynchronous Layered Coding (ALC) protocol [16] that makes the FLUTE well scalable and hence preferable for unidirectional systems. ALC is an instantiation of Layered Coding Transport (LCT) [17] for FLUTE. LCT manages 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 FDT instances (File Delivery Table) 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 FEC 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 media. A Block of “k” source symbols constitute a source block. Decoding algorithms allow the recovery of the “k” source symbols from any set of the “n” received symbols. Detailed information for FEC can be found in [2] and [18]. Most popular FEC codes are Raptor codes as initially introduced by Shokrollahi in [19] and Reed Solomon codes (1960, Irving S. Reed and Gustave Solomon) [20]. For the MBMS system, Raptor codes have been selected due to their high performance among others. So 3GPP has mandated the support of Raptor codes [2] for their terminals that uses the MBMS service.

3

A detailed view of the protocol stack for MBMS downloads is described in [21]. A file in application layer, called object in ALC terminology, is partitioned into source blocks (SB) each of which is further divided into “k“ source symbols of size “T” each. Each SB is forwarded to the FEC/FLUTE layer, where FEC encoding is individually applied to each source block. The result is an encoding block (EB) of N encoding symbols, N-K of which is repair symbols. Each encoding symbol is identified by the couple: a source block number (SBN) and an encoding symbol identifier (ESI). A group of G consecutive encoding symbols that share the same SBN is appended to an ALC/FLUTE header (LHF =16 bytes). The result is a FLUTE packet with payload P = G×T. The Flute header contains FEC payload ID that is the ESI and SBN of the first symbol, Transport Session Identifier (TSI), Transport Object Identifier (TOI), and among others as specified in [15]. User datagram protocol (UDP) over IP is used to distribute the FLUTE packets. Further headers are appended to the original packet at the UDP, IP, Logical Link Layer (LLC)/Subnetwork Data Convergence Protocol (SNDCP) or Packet Data Convergence Protocol (PDCP). At the Radio Link layer (RLC), Protocol Data Units (PDU) are obtained and forwarded to the physical layer as usual, where the data is encoded with a convolutional code, is interleaved and transmitted in small bursts. 4. SYSTEM MODEL This section provides system models of proposed MBMS download systems, which are classified as Interleaved-Based Download Delivery Model and Non-Interleaved-Based Download Delivery Model.

(1a)

(1b)

Figure 1. System Models for (1a) Non-Interleaved Download Delivery and (1b) Interleaved Download Delivery The Legacy-Download system is based on Vidiator [22] MBMS download prototype based on [2], [18] and [23], which uses Reed Solomon FEC coding and the term “legacy download” is meant the downloading time optimized Legacy-Download. System architecture of the legacy download is shown in Figure 6 in [9]. Other proposed systems are upgraded from the legacy download. To emulate MBMS link conditions a transmission rate and packet loss control module are implemented. The MBMS link conditions are aligned with [18], [23] and [24]. The media is played at 128 kbps total media rate consisting of 32 kbps enhanced AAC+ and 96 kbps H.264 AVC codec.

4

4.1 Non-Interleaved Based Download Delivery Model The model in this section is valid for both Legacy-Download and Progressive-Download Delivery since progressive download is based on the download mode of the MBMS. The system model for noninterleaved download deliveries is shown in Figure 1a, described in more detail in [9]. In order to support progressive downloading repair symbols are sent just after source symbols. Each SBi is delivered to FEC layer where the result is EBi that includes N encoding symbols (ES). Each encoding symbols is uniquely identified by the couple of its Source Block Number (SBN) and Encoding Symbol ID (ESI). A group of G consecutive encoding symbols (ESG) starting from encoding symbol ID = j for SBi is denoted as ESGi,j and identified by the couple (SBN,ESI) of the first encoding symbol, 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 until no more encoding symbols to send. 4.2 Interleaved Based Download Delivery Model The model in this section is valid for both Interleaved-Download Delivery and InterleavedProgressive-Download Delivery. In Figure 1b, described in more detail in [9], the system model of the interleaved download delivery is provided. It shows the sender side flow of the download delivery with the SB Interleaving of blocksize b. That is, b consecutive SBs constitute an interleaver-block and are sent in parallel in the order of ESIs. All encoding symbols in the interleaver-block with ESI=1 will be sent first, and so on. One more requirement of our interleaving strategy is that each FLUTE packet must include one encoding symbol at a time. However, this process requires all the b EBs to be in memory before they are sent. So the parameter b and SB size can be used to adapt to different service conditions. Minimally the interleaverblock size should be two otherwise interleaving cannot be applicable. However, increasing the interleaver-block size consumes much more memory and complicates the cost of the download process. Memory related issues are out of scope of this study. 4.3 Problem Formulation In this section, the formulization of the problem is provided, hence 3 parameters: Initial Startup Delay, Transmission Cost and Gain. To do so the initial startup delay is defined as “the minimal waiting time required to start playing the media on the terminal after the initialization of the MBMS download service”. So the term “waiting time” implies the initial startup delay in progressive download while it refers the downloading time in legacy downloads. The initial startup delay is maintained on the sender side and sent to the receiver. In order to predict the initial startup delay, two types of receivers; Analyzing Receiver, and Actual Receiver are considered. F (File Size) Fz

Fi Fi-1

Ti-1

Ti

D = Td

Tz

T (time)

Figure 2. Download size as a function of time

5

Analyzing receivers estimate the initial startup delays for the target environment for the actual receiver. The way that the sender has the estimated initial startup delays priori to the service and signaling of initial startup delays to receivers is out of scope of our work but it is studied in [1]. The file transmission is organized such that repair packets are transmitted after each source blocks. Figure 2 shows a worst case analyzing receiver obeying two assumptions: reliability and timely manner property where sending rate is less than media play rate and both playing and downloading ends at the same time. By considering the worst case scenario, analyzing receivers estimate the worst case waiting time for the actual receivers. Timely manner property implies that sender transmits symbols approximately at some constant rate and the receiver capability is sufficient enough to handle the decoding of blocks without causing any overflow in the receiver buffer. With such a property and with a reliable delivery property, receivers can be assumed to play the media at some constant rate after waiting D time unit. On receiver side, each time a source block is decoded, i is incremented and Ti is assigned to a timestamp, the time of writing the source block to the file. At time Td media can be started to play progressively by the actual receiver. Congestion and buffering in the network decides the linearity approximation between time and downloaded media size in Figure 2. If the client suffers much from the buffering delays the linearity approximation is good otherwise it will be bad. However, for the receiver doing a progressive download, there is a complete linearity between time and played media size as long as 100% reliability is provided and suitable initial startup delay is given as indicated in [1]. Partial receiving rate ri is defined as the size of source block decoded within a consecutive times Ti-1 and Ti.

ri =

Fi − Fi −1 ∆Fi = Ti − Ti −1 ∆Ti

(1)

where F0 = 0, T0=0; Fi denotes downloaded file size in KB and ri denotes partial receiving rate in Kbps at time Ti, i: 1...z, z is the total number of source block. R is defined as Expected Average Receiving Rate (EARR) computed at time Tz by the analyzing receiver that predicts the average receiving rate of the actual receiver. The analyzing receiver should use all ri sequences up to Tz to find a single rate R that best estimates the actual average receiving rate of the receiver. That is the focus is the expected average receiving rate in near future, let’s say after time Tz. In order to predict the initial startup delay D as well as the download duration for the actual receiver, an EARR function is defined. Choosing a good EARR function is not critical regarding to its effect on waiting time for small file sizes. So our choice is as follows:

Ri =

ri + Ri −1 2

(2)

where Ri is our choice for the EARR at Ti , R0 = r1; i: 1...z. The reason behind our choice for such an EARR function, consider another EARR function that averages all ri sequences. Let r1=50, r2=60, r3=70 kbps where z=3. Then Eq.2 results in R3 = 62.5 kbps however the averaging EARR results in R3 = 60 kbps. Our choice more reacts to the recent changes in ri sequences. That is, it is more reactive to the network conditions such as network congestion and buffering delays. From Figure 2, following approximation is used for the expected download duration of the actual receiver;

D+

F Rmedia

= Tz =

F Rz

(3)

Using Eq.3 the Expected Average Receiving Rate and initial startup delay approximated at the end of file download is as follows;

6

 1 1 D = Td = F *  −  R z R media

  

(4)

where Td or D denotes initial startup delay, Rmedia denotes media play rate in Kbps; F=Fz is media file size in KB; R= Rz is the Expected Average Receiving Rate computed using Eq.2. 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

(5)

 T  (6) G = 100 * 1 − d  T  Z  where Tz denotes the duration of the legacy download of the media in seconds and G is the gain in waiting time with progressive download. 5.

EXPERIMENTAL RESULTS

This section is divided into three parts. First part shows the results of our experimental analyses for two optimizations of the legacy-download: Downloading time optimized versus transmission cost optimized reliability. TABLE 1. PARAMETERS STUDIED ACCROSS LAYERS

In second part the gain obtained from the legacy download is further extended by progressive download approach. Hence second part shows our progressive download analyses to explore the gain in

7

waiting time. In final section the gain obtained from the progressive download is further improved by our application layer interleaving mechanism. Experiments are emulated on a set of computers. Each computer runs a copy of some type of MBMS download system for different configuration parameters which are given in Table 1. Each MBMS download system consists of a single server and a single client. Considering server and client on the same machine allows the full control of our emulations. The MBMS download systems are actually our emulation programs that are based on [2], [18] and [23], which uses Reed Solomon FEC coding. To simulate MBMS link conditions a transmission rate and packet loss control module aligned with [18], [23] and [24] are implemented. Both client and server maintain a database and create a record after each download. The record contains evaluated target parameters for the selected set of configuration parameters shown in Table 1. Several sets 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 all the combinations of the configuration parameters, local databases in each computer are merged into a single database. Experimental results are produced using that merged database. 5.1 Experimental Results for Legacy-Download Delivery

(3a)

(3b)

Figure 3. Comparison of (3a) Transmission cost optimization (3b) Downloading time optimization for 100 KB file Reed Solomon FEC performance is very bad at small source block size. As shown in Figure 3 and Figure 4 increasing source block size will decrease the FEC overhead required for reliability, hence causes an increase in FEC performance. However, the source block size exceeded a threshold value makes the downloading time increase in spite of still reducing the FEC overhead. This property provides trades off between downloading time and FEC overhead. Together with source block size, effects of other sizing parameters, such as symbol length, RLC block size and SDU size all should be considered together. By analyzing many possible combinations of the size choices the downloading time optimized reliability is observed. Downloading time optimized reliability aims faster download with reliability, which also provides savings in initial startup time for progressive download delivery. Increasing SB sizes around up to 80 symbols are observed to decrease the FEC overheads dramatically, where thereafter the decrease slows. Additionally the small size media download shows more fluctuations in terms of FEC overhead required for reliability. These fluctuations can be seen in Figure 3a and Figure 3b. With transmission cost optimizations, shown in Figure 3a and 4a, FEC

8

overhead is reduced with the decreased SDU sizes, hence increased number of symbols. This will increase the downloading time as shown in Table 2. With the downloading time optimizations, shown in Figure 3b and 4b, downloading time is reduced with the increased SDU sizes, hence decreased number of symbols. This will cause the FEC overhead to increase as shown in Table 2.

(4a)

(4b)

Figure 4. Comparison of (4a) Transmission cost optimization (4b) Downloading time optimization for 512 KB file Comparing to both optimizations, transmission cost optimized reliability is usually obtained at same or less SDU sizes and smaller symbol length but higher SB size. It is interesting while our observed SDU size that makes FEC overhead optimized reliability is the one that is high but smaller than the RLC block size, for downloading time optimized reliability, it is the one that is small but higher than the RLC block size. From this clue we can say in general that recommended SDU size should be equal to RLC block size. More detailed comparisons are given in Table 2. TABLE 2. COMPARISION OF OPTIMIZATIONS FOR DIFFERENT TRANSMISSION RATES

The following is a summary of general observations for Reed Solomon FEC protected legacy download in MBMS ; (i) As source block size increases the legacy download system performance increases up to a point. Around that point there can be trade off between FEC overhead and downloading time, (ii) Downloading time optimized legacy download gives up to %18 gain in waiting time regarding to FEC optimized legacy download, (iii) Downloading time optimized legacy download gives up to 8.3 seconds gain in waiting time regarding to FEC optimized legacy download.

9

5.2 Experimental Results for Progressive Download Delivery In this section, the initial startup delays for 100% reliability are obtained for 100KB and 512KB media size in Figure 5a and 5b respectively. Increasing SB size is observed to decrease the initial startup delay as shown in Figure 5 for various loss ratios and transmission rates.

(5a)

(5b)

Figure 5. Comparison of initial startup delay analyses for (5a) 100 KB file and (5b) 512 KB file TABLE 3. COMPARISION OF GAINS IN WAITING TIME FROM PROGRESSIVE DOWNLOAD

In Table 3, the experimental results for progressive download are compared to the results obtained from the legacy download. The following is a summary of our observations for Reed Solomon FEC protected Progressive download in MBMS where the results for 100 KB file is discarded; (i) For higher transmission rates, higher gain from progressive download is obtained. Gain obtained for 256, 128 and 64 Kbps transmission rates are around 100%, 80% and 40% on the average respectively, (ii) In general, progressive download provides savings in initial startup delay up to 32 seconds, from 32% up to 100% gain, with compared to legacy download, (iii) Progressive download provides savings in initial startup delay up to 40 seconds, from 45% up to 100% gain, with compared to FEC optimized legacy download. 5.3 Experimental Results for Interleaved Progressive Download Delivery This section shows the gain in initial startup delay as well as in FEC overhead when the interleaving is applied to the progressive download delivery. Tables 4 combines all results for our proposed MBMS download systems.

10

TABLE 4. SUMMARY FOR INTERLEAVED PROGRESSIVE DOWNLOAD

The following is a summary of our general observations where the results for 100 KB file is discarded; (i) Gain from the interleaving can save FEC overhead up to 29% and save initial startup delay up to 40% in progressive download delivery, (ii) Gain in initial startup delay from interleaved progressive download obtained for 256, 128 and 64 Kbps transmission rates are around 100%, 85% and 45% on the average respectively, when compared to legacy download, (iii) In general, interleaved progressive download provides savings in initial startup delay up to 42 seconds, 42% up to 100% gain, with compared to legacy download, (iv) Interleaved Progressive download provides savings in initial startup delay up to 46 seconds, from 49% up to 100% gain, when compared to FEC optimized legacy download. 6.

CONCLUSION

3GPP’s MBMS download delivery is focused with new novel methodologies applied on it. We particularly show that progressive download services should be supported in MBMS. We identified the issues related to progressive download and showed our approaches to increase the gain further from progressive download in MBMS. For this purpose, we try to explore MBMS from the progressive download point of view by analyzing many combinations of parameters to find efficient service parameters. We consider small 3G mobile media with 128 kbps constant media play rate. With our results, the interleaved download delivery provides savings in FEC transmission cost up to 29% and savings in initial startup delay up to 40% in progressive download delivery. When we use our interleaving, progressive download gives 42% to 100% gain and saves up to 42 seconds in initial startup delay with compared to legacy download. This work will pioneer to support progressive download in MBMS. Our work will be also beneficial for 3G wireless multicast download and streaming service providers for identifying various issues, resolving them and optimizing the system performance.

REFERENCES [1] S4-060267, 3GPP TSG System Aspects Meeting#39,” Support of Progressive Download in MBMS”, Dallas, TX, USA, 15-19 May 2006. [2] 3GPP TS 26.346, "Multimedia Broadcast/Multicast Service (MBMS); Protocols and Codecs", version 7.3.0, March 2007. [3] http://www.3gpp2.org/ [4] ETSI DVB TM-CBMS1167, “IP Datacast over DVB-H: Content Delivery Protocols”, September 2005, http://www.dvb.org [5] UMTSF/GSMA Joint Mobile TV Work Group Report, ”Mobile TV: The Groundbreaking Dimension” v2.21, 2006. [6] ITU-T Recommendation H.264 (03/05): ”Advanced video coding for generic audiovisual services” , ISO/IEC 14496 October 2005. [7] 3GPP TS 26.234, "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", version 7.2.0, March 2007. [8] Z. Yetgin, G. Seckin,” Progressive Download for 3G Wireless Multicasting”, IEEE CS International Conference on Future Generation Communication and Networking (FGCN 2007), Jeju Island, Korea, 2007.

11

[9] Z. Yetgin, G. Seckin,” Reliable Download Analyses for Multimedia Broadcast Multicast Services”, IAENG The World Congress on Engineering and Computer Science San Francisco, USA, 24-26 October, 2007. [10] M. Watson and T. Stockhammer, “The MBMS Mobile Multimedia Standard and Application-Layer Forward Error Correction”, available at http://www.wirelessdesignmag.com/ShowPR.aspx?PUBCODE=055&ACCT=0031786&ISSUE=0610&RELTY PE=PR&Cat=13&SubCat=1&PRODCODE=M0210&PRODLETT=A&CALLFROM=PR&CommonCount=0 [11] M. Luby, M. Watson, T. Gasiba, T. Stockhammer, “Mobile Data Broadcasting over MBMS Tradeoffs in Forward Error Correction “, in Proc. ACM ; Proceedings of the 5th international conference on Mobile and ubiquitous multimedia Vol. 193, Stanford, California , Article No. 10 , 2006, ISBN:1-59593-607-6, October 2006. [12] SP-050164, 3GPP TSG System Aspects Meeting#27, “Efficient FEC code for reliable MBMS user services”, Tokyo, Japan, 14-17 March 2005. [13] M. Luby, M. Watson, T. Gasiba, T. Stockhammer, and W. Xu, “Raptor Codes for Reliable Download Delivery in Wireless Broadcast Systems”. CCNC 2006, Las Vegas, NV, January 2006. [14] S4-060385, 3GPP TSG System Aspects Meeting#40, ” Content Preloading for MBMS User Services”, Sophia Antipolis, France, 28 August- 1 September, 2006. [15] T. Paila et al, RFC 3926, "FLUTE, File Delivery over Unidirectional Transport”, October 2004. [16] M. Luby, J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and J. Crowcroft, “Asynchronuous Layered Coding (ALC) Protocol Instantiation”, RFC 3450 Tech. Rep., Dec. 2002. [17] M. Luby , J. Gemmell, L. Vicisano, L. Rizzo, M. Handley, and J. Crowcroft ,"Layered Coding Transport (LCT) Building Block", RFC 3451 Tech. Rep, December 2002. [18] S4-040348, 3GPP TSG System Aspects Meeting #31,” Permanent document on: simulation guidelines for the evaluation of FEC methods for MBMS download and streaming services”, Canada, May 2004. [19] A. Shokrollahi, “Raptor codes,” Digital Fountain”, DR2003-06-001 Tech. Rep., June 2003. [20] J. Lacan, V. Roca, J.Peltotalo, S. Peltotalo, “Reed Solomon Forward Error Correction“, draft-ietf-rmt-bb-fecrs-03.txt , May 2007. [21] T. Gasiba, T. Stockhammer, J. Afzal, W. Xu,”System Design and Advanced Receiver Techniques for MBMS Broadcast Services”, IEEE International Conference on Communications, Istanbul, Turkey, ISSN: 81649547,vol. 12, pages 5444-550. [22] www.vidiator.com [23] S4-AHP120, 3GPP TSG System Aspects, ” Mapping of SDUs to Radio Blocks for FEC simulations”, April 2004. [24] 3GPP TS 26.946, "Multimedia Broadcast/Multicast Service (MBMS); User service guidelines", version 6.1.0, September 2006.

AUTHORS

Zeki Yetgin ([email protected]) studied mathematics in Science Faculty in Gazi University in Ankara. He received a B.Sc. degree in 1999 and an M.Sc. degree in 2002 from Eastern Mediterrenean University, Computer Engineering Department, Famagusta, Cyprus, Turkey. Since 2003 he has been doing Ph.D. in Dokuz Eylul University, Department of Computer Engineering, Izmir, Turkey. He is actively involved in a TUBITAK (The Turkish National Science Foundation) project where 3G wireless multicasting in UMTS is studied. His research interests are mainly in the area of reliable multimedia transmission over wireless (broadcast) channels. He is particularly involved in progressive download in MBMS. His other interests are researches including Parallel and Distributed Computing, Learning and Reasoning in Fuzzy environments and Image/Speech processing.

12

Gamze Seckin ([email protected]) received her Ph.D. in Arizona State University in the Department of Computer Science and Engineering in 2000, after the completion of her B.S. and M.S. in the Department of Computer Engineering in Ege University, in 1992 and 1994 respectively. She is a former Fulbright Research Scholar, a member of IEEE Communications Society and IEEE Women in Engineering Society. She has awards, publications, pending patent applications, international standardization contributions, and a book chapter on research topics specializing ATM, IP, mobile and wireless networks. She worked at Vidiator Technology (US) Inc. (formerly Luxxon Corporation), a Hutchison Whampoa Company, for more than 7 years, first as Research Engineer then as the Director of Technology. Currently Gamze works as the Principal Engineer in the Network Evolution and Strategy Team in T-Mobile USA.

13