ProgressiveDownloadfor MultimediaBroadcastMulticast Service

Zeki YetginDokuz Eylul University

Gamze SeckinVidiator Technology

The advent of new transport plat-

forms has revolutionized the way

users can access multimedia appli-

cations.1 Enabling technologies for

these platforms include Third Generation Part-

nership Project (3GPP) Multimedia Broadcast

Multicast Service (MBMS), Third Generation

Partnership Project 2 (3GPP2) Broadcast and

Multicast Service, and Digital Video Broadcast

for Handhelds, among others.2-4 Recently,

3GPP (see http://www.3gpp2.org/) introduced

support for IP multicasting services in the

MBMS architecture. This change lets providers

offer service to thousands of users simultane-

ously in a point-to-multipoint manner.

There are two delivery methods defined in

MBMS: download and streaming. Download

mode is for delivering files where transmission

reliability is important, while streaming is for

real-time media delivery. A third type, progres-

sive download, has drawn a great deal of atten-

tion recently as an alternative to MBMS

streaming. With progressive download, content

is streamed after an initial startup delay, and

the download continues in the background.

Progressive download substantially reduces the

user’s waiting time, and combines the advantages

of conventional streaming and downloading.

We believe MBMS should support progressive

download to increase user satisfaction and to

optimize MBMS radio resources. Moreover, adding

progressive-download capabilities to MBMS would

not require changing the infrastructure because

progressive download uses the MBMS standard’s

existing download-delivery mode. Currently,

however, progressive download remains an open

question in 3GPP. One of the main reasons for

the delay is that there is no research demonstrat-

ing the advantage of implementing progressive

download in MBMS. This article demonstrates

the possible advantages of using progressive

download for small multimedia files.

When doing the tests outlined here, we used

constant bit rate encoding because variable bit

rate makes time prediction difficult and requires

more capability on the receiving end. We also

used enhanced AAC+ and H.264 advanced

video coding (AVC) at 128 kbps.5 In addition,

we implemented downloading-time optimiza-

tion and application-layer interleaving. With

an effective interleaving mechanism, we

removed the negative effects of a reduction

in transmission cost and needed less error-

correcting overhead. Altogether, this article

compares four MBMS download systems:

legacy, progressive, interleaved-legacy, and

interleaved-progressive.

MBMS download delivery

MBMS download delivery is based on the File

Delivery over Unidirectional Transport (Flute)6

protocol used to deliver files over unidirectional

systems from one sender to many receivers.

Flute is an IETF protocol based on Asynchronous

Layered Coding (ALC),7 which makes Flute scal-

able and therefore preferable for unidirectional

systems. ALC is an instantiation of Layered Cod-

ing Transport (LCT)8 for Flute. LCT manages the

transport of an object identified by the Trans-

port Object Identifier (TOI) within a session

identified by the Transport Session Identifier

(TSI). ALC inherits LCT with asynchronous and

forward error correction (FEC) coding. Finally,

Flute 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 to map

them to the ALC protocol.

With Flute, the only built-in reliability mech-

anism is provided by the FEC mechanism,

Feature Article

The project outlined

in this article focuses

on using progressive-

download

technology to

improve media

delivery in wireless

Multimedia

Broadcast Multicast

Services.

1070-986X/09/$25.00 �c 2009 IEEE Published by the IEEE Computer Society76

which provides reliable delivery of media con-

tent by appending repair symbols to the origi-

nal data prior to transmission across the

communication network. If some symbols are

lost during transmission, FEC allows the re-

ceiver to use repair symbols to recover the orig-

inal source block without retransmission. A

source block is a fragment of the original

media, with a block of k source symbols consti-

tuting 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 elsewhere.2,9

The most popular FEC codes are Raptor and

Reed Solomon.10,11 The MBMS system uses

Raptor codes due to their high performance.

A detailed overview of the complete proto-

col stack for MBMS downloads is described else-

where.12 A file in the application layer, called

an object in ALC terminology, is partitioned

into source blocks (SBs), each of which is div-

ided 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 SB. The result is an encoding block (EB)

of N encoding symbols. Each encoding symbol

is identified by 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.

Related WorkRecently, 3GPP working groups have been studying pro-

gressive-download technology for MBMS. According to the

packet-switched streaming service (PSS) specification, PSS

clients already support progressive download of media files

with HTTP connection over TCP/IP.1 But progressive down-

load in MBMS is still open to debate, with few projects actu-

ally analyzing it using formal methods.2

In an earlier project, we studied MBMS download optimi-

zation to reduce FEC overhead for both Reed Solomon and

Raptor FEC.3 In other projects, researchers have studied FEC

mechanisms for MBMS on two layers, namely the physical

layer and the application layer, with tradeoffs in applying

one or the other or suitable combinations of the two.4,5

In terms of interleaving, researchers have tested Reed-

Solomon and Raptor codes for MBMSs.6,7 Generally, re-

search approaches interleaving mechanisms above the FEC

layer as random symbol transmissions. However, random

transmission disables progressive download, so our recom-

mendation is to use an interleaving strategy that also enables

progressive downloading.

As an alternative to streaming, one project developed an

intermediate delivery mode that bridges the gap between

streaming and downloading and is based on MBMS down-

load delivery.8 However, the project’s new network elements

and requirements make the approach difficult to standardize

and implement.

In our current study, rather than focus on transmission-cost

optimization, we focus on download-time optimization be-

cause it provides a decrease in waiting time for MBMS down-

loads. We apply application-layer interleaving to progressive

downloading to decrease the wait time even more. Essen-

tially, this study combines our earlier work to focus on the

advantages of interleaved-progressive downloads.

References1. 3GPP TS 26.234, Transparent End-to-End Packet-Switched

Streaming Service (PSS); Protocols and Codecs, v7.2.0, 3GPP,

Mar. 2007.

2. Z. Yetgin and G. Seckin, ‘‘Progressive Download for 3G

Wireless Multicasting,’’ Proc. Future Generation Communica-

tion and Networking (FGCN), vol. 1, IEEE CS Press, 2007,

pp. 289-295.

3. Z. Yetgin and G. Seckin, ‘‘Reliable Download Analyses for

Multimedia Broadcast Multicast Services,’’ World Congress

on Engineering and Computer Science, IAENG, 2007,

pp. 389-394.

4. M. Watson and T. Stockhammer, ‘‘The MBMS Mobile Multi-

media Standard and Application-Layer Forward Error Correc-

tion,’’ white paper, Wireless Design and Development;

http://www.wirelessdesignmag.com/ShowPR.aspx?PUBCODE=

055&ACCT=0031786&ISSUE=0610&RELTYPE=PR&Cat=

13&SubCat=1&PRODCODE=M0210&PRODLETT=

A&CALLFROM=PR&CommonCount=0.

5. M. Luby et al., ‘‘Mobile Data Broadcasting over MBMS Trade-

offs in Forward Error Correction,’’ Proc. 5th Int’l Conf. Mobile

and Ubiquitous Multimedia, vol. 193, ACM Press, 2006, p. 10.

6. Efficient FEC Code for Reliable MBMS User Services, 3GPP TSG

System Aspects tech. doc. SP-050164, Siemens, Mar. 2005;

http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_27/Docs/

PDF/SP-050164.pdf.

7. M. Luby et al., ‘‘Raptor Codes for Reliable Download Delivery

in Wireless Broadcast Systems,’’ Proc. Consumer Communications

and Networking Conf., vol. 1, IEEE Press, 2006, pp. 192-197.

8. Content Preloading for MBMS User Services, 3GPP TSG Sys-

tem Aspects tech. doc. S4-060385, Siemens, 2006; http://

www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_40/Docs/

S4-060385.zip.

Ap

ril�Ju

ne

2009

77

The Flute header contains FEC payload iden-

tifier that is the ESI and SBN of the first symbol,

along with TSI, TOI, and other information.

User datagram protocol (UDP) over IP distributes

the Flute packets, and additional headers are

appended to the original packet in UDP, IP, Log-

ical Link Control, Subnetwork Data Conver-

gence Protocol. At the Radio Link layer,

Protocol Data Units(PDU) are obtained from Ser-

vice Data Unit (SDU) and forwarded to the phys-

ical layer, as usual, where the data is encoded,

interleaved, and transmitted in small bursts.

System model

The legacy-download system is based on the

Vidiator (www.vidiator.com) MBMS download

prototype, which uses Reed Solomon FEC coding.

To emulate MBMS link conditions,10,13,14 we

implemented a module for controlling transmis-

sion rate and packet loss, and played the media at

128 kbps consisting of 32 kbps enhanced AACþand 96 kbps H.264 AVC codec. The model

outlined in this section is valid for legacy-

download and progressive-download delivery

because progressive download is based on the

download mode of the MBMS.

Figure 1a shows the system model for non-

interleaved download deliveries. To support

progressive downloading, repair symbols are

sent just after source symbols. Each SBi is deliv-

ered to FEC layer where the result is EBi, which

includes N encoding symbols (ES). Each ES is

uniquely identified by its SBN and ES identifica-

tion (ESI). An encoding symbol group (ESG)

starting from ESI ¼ 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 the Flute payload just

after the place reserved for Flute payload identi-

fication and transported until there are no

more encoding symbols to send.

Figure 1b illustrates the system model of

the interleaved download delivery. It shows the

sender side flow of the download delivery

with the SB interleaving of block-size 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 are sent first. One require-

ment of our interleaving strategy is that each

Flute packet must include one encoding sym-

bol at a time. However, this process requires

Packetizer

Transport

IPheader

User-Datagram-Protocol header

Fluteheader

Flute payload ID = (i, j)Repeat until j ≥ K + N

(a) (b)

(i, j) ESi, j ESi, j + G

ESi, j

Encoding signal(ES) Gi, j

Encoding block (EB)i

SBi

Sourceblock (SB)1 SB2 SBi

File

Forward-error-correction encoding

SBz

K

K + N

j = j + G

ESi, j + G

Packetize ESk, s

Transport

IPheader

User-Datagram-Protocol header

Fluteheader

Flute payloadID = (k, s)

(k, s) ESk, s

EBi + bEBi + 1EBi

For k:i . . i + b

SB1 SBi SBi + bSBi + 1

File

Forward-error-correction encoding SBk

SBz

K

K + N

For s:1 . . K + N

For k:i . . i + b

Figure 1. System Models

for (a) noninterleaved

download delivery and

(b) interleaved

download delivery.

78

IEEE

Mu

ltiM

ed

ia

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.

At minimum, the interleaver-block size should

be two, otherwise interleaving is not applicable.

However, increasing the interleaver-block size

consumes more memory and complicates the

cost of the download process. Memory-related

issues are beyond the scope of this study.

There are three parameters in turning the

problem into a formula: initial startup delay,

transmission cost, and gain. We define the ini-

tial startup delay as the minimum waiting time

required to start playing the media on the termi-

nal after the initialization of the MBMS down-

load service. The term ‘‘waiting time’’ implies

the initial startup delay in progressive down-

load, while it refers to the downloading time

in legacy downloads. The initial startup delay

is maintained on the sender side and sent to

the receiver. To predict the initial startup

delay, we consider two types of receivers: analyz-

ing receivers and actual receivers. Analyzing

receivers estimate the initial startup delays for

the target environment of the actual receivers.

We organize file transmission so that repair

packets are transmitted after each source block.

Figure 2 shows a worst-case analyzing receiver

where the sending rate is less than the media

play rate and both playing and downloading

end at the same time. By considering the

worst-case scenario, the analyzing receivers esti-

mate the worst-case waiting time for the actual

receivers. The timely manner property implies

that the sender transmits symbols at some con-

stant rate and the receiver can handle decoding

without causing any overflow in the buffer. We

can assume therefore that the receivers play the

media at some constant rate after waiting for a

certain time D. Each time a source block is

decoded on the receiver, i is incremented and

Ti is assigned to a time stamp, the time of writing

the source block to the file. At time Td, media

playback can be started by the receiver.

Congestion and buffering determine the ap-

proximation between time and downloaded

size in Figure 2. If the client suffers from buffer-

ing delays, the linearity approximation is good.

However, for the receiver doing a progressive

download, there is linearity between time and

media size as long as there is 100 percent reliabil-

ity and suitable initial startup delay.1 We define

partial receiving rate ri as the size of source block

decoded within a consecutive times Ti�1 and Ti.

ri ¼Fi � Fi�1

Ti � Ti�1¼ DFi

DTi

where F0 ¼ 0, T0 ¼ 0; Fi denotes downloaded

file size in Kbytes and ri denotes partial

receiving rate in kbps at time Ti. The total

number of source block is 1 . . . z, z.

We define R as expected average receiving rate

(EARR) computed at time Tz by the analyzing re-

ceiver 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. 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

when it comes to its effect on waiting time for

small file sizes. So our choice is as follows:

Ri ¼ri þ Ri�1

2(1)

where Ri is our choice for the EARR at Ti, R0 ¼r1; i: 1 . . . z.

To understand the reasoning behind our

choice for such an EARR function, consider an-

other EARR function that averages all ri sequen-

ces. Let r1 ¼ 50, r2 ¼ 60, and r3 ¼ 70 kbps where

z¼ 3. Equation 1 results in R3¼ 62.5 kbps. How-

ever, the averaging EARR results in R3 ¼ 60 kbps.

Our choice reflects the recent changes in the ri

sequences. That is, the choice is more reactive to

the network conditions such as network conges-

tion and buffering delays. From Figure 2, we use

the following approximation for the expected

download duration of the actual receiver:

Dþ F

Rmedia¼ Tz ¼

F

Rz(2)

Ti–1

Fi–1

Fi

File

siz

e

Fz

D = TdTi Tz

Time

Figure 2. Download

size as a function of

time.

Ap

ril�Ju

ne

2009

79

Using Equation 2, the EARR and initial startup

delay approximated at the end of the file

download is as follows:

D ¼ Td ¼ F�1

Rz� 1

Rmedia

� �

where Td or D denote initial startup delay and

Rmedia denotes media play rate in kbps. F ¼ Fz

indicates media file size in Kbytes, while R ¼ Rz

is the EARR computed using Equation 1.

We define G as the gain in waiting time for

progressive download compared to legacy down-

load. We compute G using R and T as follows:

Tz ¼F

Rz

and

G ¼ 100� 1� Td

Tz

� �

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.

Experimental results

We applied our experimental analyses to

two optimizations of the legacy download:

downloading-time optimization and transmission-

cost optimization. We extended the gains we

obtained in legacy download by using progres-

sive download and extensively analyzed pro-

gressive download to explore differences in

waiting time. As described here, we were able

to improve the gains obtained in progressive

download by implementing out interleaving

mechanism.

We conducted our experiments on a set of

computers, with each computer running a

copy of some type of MBMS for different con-

figuration parameters outlined in Table 1.

Each MBMS consists of a single server and a

single client. Considering server and client

on the same machine allows full control over

Table 1. Parameters studied across layers.

Parameter Unit Layer Experiment set System

File size Kilobyte Application {100,512} All

Transmission cost optimized FEC overheads Percent Application To be determined in this study Legacy

Transmission cost optimized waiting time Second Application To be determined in this study Legacy

Downloading time optimized FEC overheads Percent Application To be determined in this study Legacy

Downloading time optimized waiting time {Second,percent}

Application To be determined in this study Legacy

Gain in waiting time from optimizations {Second,percent}

Application To be determined in this study Legacy

Initial startup delay in progressive download Second Application To be determined in this study Progressive

Gain in initial startup delay from progressive

download

{Second,

percent}

Application To be determined in this study Progressive

Gain in downloading time from interleaving {Second,

percent}

Application To be determined in this study Interleaved

Gain in FEC overhead from interleaving Percent Application To be determined in this study Interleaved

Initial startup delay in interleaved-progressive

download

Second Application To be determined in this study Interleaved-

progressive

Gain in initial startup delay from Interleaved-

progressive download

{Second,

percent}

Application To be determined in this study Interleaved-

progressive

Symbol length Byte FEC {Service data unit � 48} All

Source block size Symbol FEC {10,50,80,100,120,150,180,200,230} All

IP packet size Byte IP {session data unit, or SDU} All

Service data unit block size Byte Core network {400,600,800,1000,1400} All

Protocol data unit block size (radio link control,

or RLC, block size)

Byte RLC radio l. {640,1280} All

PDU (RLC link layer) losses Percent RLC radio l. {1,5,10} All

Transmission rates Kbps All layer {64,128,256} All

Interleaver block size SourceBlock

FEC {2,3,4} Interleaved-progressive

Media play rate Kbps Application {128} All

80

IEEE

Mu

ltiM

ed

ia

our emulations. The MBMSs are actually our

emulation programs that use Reed Solomon

FEC coding. To simulate MBMS link condi-

tions, we implemented a transmission rate

and packet loss control module.

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 parame-

ters shown in Table 1. We scheduled several

sets of configuration parameters to initiate

several downloads with different characteris-

tics. Each download experiment for one set

of configuration parameters goes through

100 download iterations. After performing

all the combinations of the configuration

parameters, we merged local databases in

each computer into a single database, and pro-

duced the experimental results using that

merged database.

Legacy download

Reed Solomon FEC performance is bad with

a small SB size. As shown in Figure 3 and Figure 4,

increasing SB size will decrease the FEC over-

head required for reliability, hence causing an

increase in FEC performance. However, the SB

size exceeded a threshold value, making the

download time increase despite reducing

the FEC overhead. This property provides

tradeoffs between downloading time and FEC

overhead. Together with SB size, effects of

other parameters, such as symbol length,

radio link control (RLC), block size, and ses-

sion data unit (SDU) size, should be consid-

ered. Downloading-time optimization aims

for faster downloading with reliability, which

also provides savings in initial startup time

for progressive-download delivery.

Increasing the SB sizes up to 80 symbols will

decrease the FEC overhead dramatically; there-

after the decrease slows. Additionally, small

downloads show more fluctuations in terms

of FEC overhead required for reliability. These

fluctuations can be seen in Figure 3a and 3b.

With transmission-cost optimizations, shown

in Figure 3a and 4a, FEC overhead is reduced

with the decreased SDU sizes and increased

number of symbols, increasing the download

time as shown in Table 2. With download-time

optimizations, shown in Figure 3b and 4b,

download time is reduced with the increase

in SDU sizes and decreased number of

symbols, causing the FEC overhead to in-

crease, as shown in Table 2.

Compared to both optimizations, transmission-

cost optimization is usually obtained at the

same or smaller SDU sizes and smaller symbol

length but higher SB size. While the SDU size

that optimizes FEC overhead is large but still

smaller than the RLC block size, for download-

time optimization the best SDU size is small

but still larger than the RLC block size. From

this observation, we can say in general that

SDU size should be equal to RLC block size.

Table 2 shows more detailed comparisons.

Generally speaking, as SB size increases, legacy-

download performance increases, but only up

to a point. Around that point there can be

tradeoffs between FEC overhead and download

time. In addition, download-time optimization

offers up to an 18 percent improvement and

Forw

ard-

erro

r-co

rrec

tion

over

head

(%

)

160150

130

110

90

6050

100

120100806040200

(a)

(b)

203040

7080

100

120

140

Source block size (number of symbols)

Forw

ard-

erro

r-co

rrec

tion

over

head

(%

)

180

150

130

110

90

6050

100

120100806040200

203040

7080

100

120

140

160170

Source block size (number of symbols)

RLC block 1,280 bytes, SDU size 1,000 bytes, 10% PDU loss

RLC block 1,280 bytes, SDU size 1,000 bytes, 5% PDU loss

RLC block 1,280 bytes, SDU size 1,000 bytes, 1% PDU loss

RLC block 640 bytes, SDU size 1,000 bytes, 1% PDU lossRLC block 640 bytes, SDU size 1,000 bytes, 10% PDU loss

RLC block 640 bytes, SDU size 1,000 bytes, 5% PDU loss

RLC block 1,280 bytes, SDU size 600 bytes, 10% PDU loss

RLC block 1,280 bytes, SDU size 1,000 bytes, 5% PDU loss

Radio link layer (RLC) block 1,280 bytes, service-data-unit(SDU) size 600 bytes, 1% protocol-data-unit (PDU) loss

RLC block 640 bytes, SDU size 600 bytes, 1% PDU lossRLC block 640 bytes, SDU size 400 bytes, 10% PDU loss

RLC block 640 bytes, SDU size 400 bytes, 5% PDU loss

Figure 3. Comparison

of (a) transmission-

cost optimization

and (b) downloading-

time optimization for

a 100 Kbyte file.

81

Ap

ril�Ju

ne

2009

saves roughly 8.3 seconds in waiting time over

FEC-optimized downloads.

Progressive download

Figure 5a and 5b show the initial startup

delays for 100 percent reliability for 100-Kbyte

and 512-Kbyte media files. Increasing SB size

decreases the initial startup delay for various

loss ratios and transmission rates. Table 3 com-

pares the experimental results for progressive

download to the results we obtained for our

legacy-download tests.

For Reed Solomon FEC-protected downloads,

we obtained higher gains from progressive

downloads with higher transmission rates. We

observed improvements for 256, 128, and 64

kbps transmission rates at around 100, 80, and

40 percent on average. In general, we found

that progressive download provides savings in

initial startup delay of up to 32 seconds (a 32

to 100 percent gain) compared to legacy down-

load. Finally, progressive download provides

savings in initial startup delay of up to 40 sec-

onds (a 45 to 100 percent gain) compared to

FEC-optimized legacy downloads.

Interleaved-progressive download

We found improvement in initial startup

delay and FEC overhead when we applied inter-

leaving to progressive download. Table 4 com-

bines all results for our proposed MBMS.

We found that the improvement derived from

interleaving can save FEC overhead of up to 29

percent and reduce initial startup delay up to

40 percent in progressive download. We also

found improvement in initial startup delay

from interleaved-progressive download obtained

for 256, 128, and 64 kbps transmission rates are

around 100, 85, and 45 percent on average,

when compared to legacy download. Also, we

found that interleaved-progressive download pro-

vides savings in initial startup delay of up to 42

seconds (a 42 to 100 percent gain) compared to

legacy download. Finally, interleaved-progressive

Table 2. Comparison of optimizations for different transmission rates.

Transmission rate 256 Kbps Transmission rate

Transmission-cost

optimization

Download-time

optimization

Transmission-cost

optimization

File size

(Kbytes)

PDU loss

(%)

FEC o.

(%)

Downtime

(sec.)

FEC o.

(%)

Downtime

(sec.)

Download

time gain

(%)

FEC o.

(%)

Downtime

(sec.)

100 1 10 3.7 12 3.4 8 10 7.4

100 5 23 4.4 23 3.7 17 23 8.8

100 10 38 4.8 43 4.0 17 38 9.7

512 1 7 18.5 7 18.5 0 7 37.0

512 5 18 21.4 19 20.9 2 18 42.9

512 10 34 23.7 37 23.5 1 34 47.9

Forw

ard-

erro

r-co

rrec

tion

over

head

(%

) 170

150

130

110

90

6050

100

250200150100500

203040

7080

100

120

140

160

170

150

130

110

90

6050

100

203040

7080

100

120

140

160

Source block size (number of symbols)(a)

(b)

Forw

ard-

erro

r-co

rrec

tion

over

head

(%

)

250200150100500

Source block size (number of symbols)

RLC block 1,280 bytes, SDU size 800 bytes, 10% PDU loss

RLC block 1,280 bytes, SDU size 800 bytes, 5% PDU loss

RLC block 1,280 bytes, SDU size 1,000 bytes, 1% PDU loss

RLC block 640 bytes, SDU size 1,000 bytes, 1% PDU lossRLC block 640 bytes, SDU size 800 bytes, 10% PDU loss

RLC block 640 bytes, SDU size 800 bytes, 5% PDU loss

RLC block 1,280 bytes, SDU size 800 bytes, 10% PDU loss

RLC block 1,280 bytes, SDU size 600 bytes, 5% PDU loss

Radio link layer (RLC) block 1,280 bytes, service-data-unit(SDU) size 1,000 bytes, 1% protocol-data-unit (PDU) loss

RLC block 640 bytes, SDU size 400 bytes, 1% PDU lossRLC block 640 bytes, SDU size 400 bytes, 10% PDU loss

RLC block 640 bytes, SDU size 600 bytes, 5% PDU loss

Figure 4. Comparison of (a) transmission-cost optimization and

(b) downloading-time optimization for a 512 Kbyte file.

82

128 Kbps Transmission rate 64 Kbps

Download-time

optimization

Transmission-cost

optimization

Download-time

optimization

FEC o.

(%)

Downtime

(sec.)

Download

time gain

(%)

FEC o.

(%)

Downtime

(sec.)

FEC o.

(%)

Downtime

(sec.)

Download

time gain

(%)

12 6.8 7 10 15.3 12 13.8 10

23 7.4 17 24 18.5 32 15.3 17

43 8.1 17 42 21.3 53 17.5 18

7 36.9 0 8 82.7 8 74.5 10

19 41.4 4 20 88.3 21 85.3 3

37 47.1 2 37 104.2 41 99.9 4

Figure 5. Comparison

of initial startup

delays for a

(a) 100-Kbyte file and

(b) 512-Kbyte file.

Initi

al s

tart

up d

elay

(se

cond

s)

36

32

28

24

20

16

12

8

4

0140120100806040200

Initi

al s

tart

up d

elay

(se

cond

s)

160

0

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

250200150100Source block size (number of symbols)

Source block size (number of symbols)(a)

(b)

5000

256 Kbps transmission rate, 1,000 bytes SDU size, 1% PDU loss256 Kbps transmission rate, 800 bytes SDU size, 10% PDU loss128 Kbps transmission rate, 800 bytes SDU size, 5% PDU loss64 Kbps transmission rate, 1,000 bytes SDU size, 1% PDU loss64 Kbps transmission rate, 800 bytes SDU size, 10% PDU loss256 Kbps transmission rate, 800 bytes SDU size, 5% PDU loss128 Kbps transmission rate, 1,000 bytes SDU size, 1% PDU loss128 Kbps transmission rate, 800 bytes SDU size, 10% PDU loss64 Kbps transmission rate, 800 bytes SDU size, 5% PDU loss

256 Kbps transmission rate, 1,000 bytes, service-data-unit (SDU)size, 1% protocol-data-unit (PDU) loss256 Kbps transmission rate, 1,000 bytes SDU size, 10% PDU loss128 Kbps transmission rate, 1,000 bytes SDU size, 5% PDU loss64 Kbps transmission rate, 1,000 bytes SDU size, 1% PDU loss64 Kbps transmission rate, 1,000 bytes SDU size, 10% PDU loss256 Kbps transmission rate, 1,000 bytes SDU size, 5% PDU loss128 Kbps transmission rate, 1,000 bytes SDU size, 1% PDU loss128 Kbps transmission rate, 1,000 bytes SDU size, 10% PDU loss64 Kbps transmission rate, 1,000 bytes SDU size, 5% PDU loss

83

Ap

ril�Ju

ne

2009

download provides savings in initial startup of up

to 46 seconds (a 49 to 100 percent gain) com-

pared to FEC-optimized legacy download.

Conclusion

We have explored MBMS from the progres-

sive-download viewpoint by analyzing many

factors to find efficient service parameters.

Our results indicate that interleaving provides

significant savings in FEC transmission cost

and improvement in initial startup delays for

progressive downloads. We hope this research

will help build support for implementing pro-

gressive-download protocols in MBMS. We

also hope our work will be beneficial to service

providers attempting in identifying and resolv-

ing various performance issues. MM

Acknowledgments

This work is part of EEEAG 104E163, a proj-

ect sponsored by Vidiator Technology Inc., The

Scientific and Technological Research Council of

Turkey (TUBITAK), and Dokuz Eylul University.

References

1. Support of Progressive Download in MBMS, 3GPP

TSG System Aspects tech. doc. SP-050164, BenQ

Mobile, 2006, http://www.3gpp.org/ftp/tsg_sa/

WG4_CODEC/TSGS4_39/Docs/S4-060267.zip.

2. 3GPP TS 26.346, Multimedia Broadcast/Multicast Service

(MBMS); Protocols and Codecs, v.7.3.0, 3GPP, 2007.

3. ETSI TS 102 472 v1.2.1, Digital Video Broadcast-

ing; IP Datacast over DVB-H: Content Delivery

Protocols, ETSI, 2006; http://www.dvb.org.

4. ‘‘Mobile TV: The Groundbreaking Dimension,’’

v2.21, white paper, UMTSF/GSMA Joint Mobile

TV Work Group, 2006; http://www.umts-forum.

org/component/option.com_docman/task,doc_

download/gid,1629/Itemid,12/.

5. ITU-T Rec. H.264 (03/05), Advanced Video Coding

for Generic Audiovisual Services, ISO/IEC 14496,

Oct. 2005.

6. T. Paila et al, Flute: File Delivery over Unidirectional

Transport, RFC 3926, IETF, Oct. 2004.

7. M. Luby et al., Asynchronous Layered Coding (ALC)

Protocol Instantiation, RFC 3450, IETF, Dec. 2002.

Table 3. Comparison of waiting time from progressive download.

Transmission rate 256 kbps Transmission rate

File size

(Kbytes)

PDU loss

(%)

FEC o.

(%)

Waiting time in

progress. D.

(sec.)

Waiting time in

legacy

D. (sec.)

Progressive

download gain

(%)

FEC o.

(%)

Waiting time in

progress. D.

(sec.)

100 1 12 0 3.4 100 12 0.6

100 5 23 0 3.7 100 23 1.1

100 10 43 0 4.0 100 43 1.8

512 1 7 0 18.5 100 7 4.9

512 5 19 0 20.9 100 19 9.4

512 10 37 0 23.5 100 37 15.1

Table 4. Summary for interleaved-progressive download.

Transmission rate 256 kbps Transmission rate

File size

(Kbyte)

PDU loss

(%)

FEC

overhead

(%)

Wait time in

interleaved-

progressive

(sec.)

Wait time in

interleaved-

legacy (sec.)

Gain in wait

time from

interleaved-

progressive

over legacy

(%)

Gain in FEC

overhead

from

interleaved-

progressive

(%)

FEC

over-

head

(%)

Wait time in

interleaved-

progressive

(sec.)

100 1 12 0 3.4 100 0 12 0.6

100 5 22 0 3.7 100 4 22 1.1

100 10 36 0 4.0 100 16 36 1.8

512 1 5 0 17.6 100 29 5 3.3

512 5 16 0 19.1 100 16 16 6.4

512 10 32 0 21.0 100 14 32 10.1

84

IEEE

Mu

ltiM

ed

ia

128 kbps Transmission rate 64 kbps

Waiting time

in legacy

D. (sec.)

Progressive

download gain

(%) FEC o. (%)

Waiting time

in progress.

D. (sec.)

Waiting time

in legacy

D. (sec.)

Progressive

download gain

(%)

6.8 92 12 7.5 13.8 45

7.4 85 32 9.0 15.3 41

8.1 77 53 11.3 17.5 36

36.9 87 8 42.5 74.5 43

41.4 77 21 53.3 85.3 38

47.1 68 41 67.9 99.9 32

256 kbps Transmission rate 256 kbps

Wait time in

interleaved-

legacy (sec.)

Gain in waiting

time from in-

terleaved pro-

gressive over

legacy down-

load (%)

Gain in FEC

overhead

from inter-

leaving (%)

FEC over-

head

(%)

Wait time in

interleaved-

progressive

(sec.)

Wait time in

interleaved-

legacy (sec.)

Gain in waiting

time from

interleaved-

progressive

over legacy

download (%)

Gain in FEC

overhead

from inter-

leaving (%)

6.8 92 0 10 7.6 13.9 45 17

7.3 85 4 20 9.2 15.5 40 38

8.0 78 16 38 10.9 17.1 38 28

35.3 91 29 7 39.7 71.7 47 13

38.4 85 16 19 47.8 79.8 44 10

42.1 79 14 37 58.2 90.2 42 10

8. M. Luby et al., Layered Coding Transport (LCT)

Building Block, RFC 3451, IETF, Dec. 2002.

9. Permanent Document On: Simulation Guidelines for

the Evaluation of FEC Methods for MBMS Download

and Streaming Services, 3GPP TSG System Aspects

tech. doc. S4-040348, Digital Fountain, 2004;

http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/

TSGS4_31/Docs/S4-040348.zip.

10. A. Shokrollahi, ‘‘Raptor Codes,’’ IEEE/ACM Trans. Net-

working, vol. 14, no. SI, June 2006, pp. 2551-2567.

11. I.S. Reed and G. Solomon, ‘‘Polynomial Codes

Over Certain Finite Fields,’’ SIAM J. Applied Mathe-

matics, vol. 8, no. 2, 1960, pp. 300-304.

12. T. Gasiba et al., ‘‘System Design and Advanced

Receiver Techniques for MBMS Broadcast Ser-

vices,’’ Int’l Conf. Communications, vol. 12, IEEE

Press, 2006, pp. 5444-5450.

13. Mapping of SDUs to Radio Blocks for FEC Simula-

tions, 3GPP TSG System Aspects tech. doc.

S4-AHP120, Nortel Networks, 2004; http://www.

3gpp.org/FTP/tsg_sa/WG4_CODEC/Ad-hoc_PSM/

Docs/S4-AHP120.zip.

14. 3GPP TS 26.946, Multimedia Broadcast/Multicast

Service (MBMS); User Service Guidelines, v6.1.0,

Sept. 2006.

Zeki Yetgin is working toward a PhD at the Depart-

ment of Computer Engineering, Dokuz Eylul Univer-

sity, Turkey. His research interests include reliable

multimedia transmission over wireless (broadcast)

channels, progressive download in MBMS, parallel

and distributed computing, learning and reasoning

in fuzzy environments, and image/speech processing.

Yetgin has an MS from the Computer Engineering

Department, Eastern Mediterranean University. Con-

tact him at zeki@cs.deu.edu.tr.

Gamze Seckin is a principal engineer in the Network

Evolution and Strategy Team at T-Mobile USA. Her re-

search interests include asynchronous transfer mode,

IP, and mobile and wireless networks. Seckin has a

PhD from the Department of Computer Science and

Engineering, Arizona State University. She is a former

Fulbright Research Scholar, and a member of the IEEE

Communications Society and IEEE Women in Engineer-

ing Society. Contact her at gamze.seckin@t-mobile.com.

85

Ap

ril�Ju

ne

2009