FILE-BASED DELIVERY OVER LTE-BASED MBMS

(1)

FILE-BASED DELIVERY OVER LTE-BASED MBMS

Ravichandran Raja Gounder Sivaswamy Geethanjali Soundappan

This thesis is presented as part of degree of Master of Science in Electrical Engineering

Blekinge Institute of Technology January 2013

Blekinge Institute of Technology School of Engineering

Department of Radio Communication

(2)

This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 20 weeks of full time study.

Contact Information:

Authors:

Geethanjali Soundappan

E-mail: geethu10.cbe@gmail.com Ravichandran Raja Gounder Sivaswamy E-mail: ravipgm@gmail.com

External Advisor:

Dr.-Ing.Thomas Stockhammer CEO & Founder

Nomor Research GmbH Phone: +49-1725702667

E-mail: stockhammer@nomor.de

University Advisor:

Thi My Chinh Chu

COM School of Computing

Blekinge Institute of Technology,Sweden E-mail: thi.my.chinh.chu@bth.se

School of Engineering www.bth.se Blekinge Institute of Technology Phone: +46 455 38 50 00 371 79 Karlskrona Fax: +46 455 38 50 57 Sweden.

(3)

i

Abstract

One of the most important emerging aspects of Third Generation Partnership Project (3GPP) is the Multimedia Broadcast/Multicast Service (MBMS) aiming to deliver multimedia contents to mobile users more efficiently in point-to-multipoint way. 3GPP also recommends an Application Layer Forward Error Correction (AL-FEC) scheme, especially for MBMS, in order to provide reliable transmission over mobile networks. Due to many emerging FEC schemes, the existing 3GPP standardized systematic fountain Raptor code FEC scheme is considered to be outdated.

One of the newly emerged codes, namely RaptorQ, has enhanced an AL-FEC scheme by providing higher protection against packet loss and superior flexibility to meet the growing demand in mobile multicast services. In this work, we provide an extensive device based performance evaluation of RaptorQ FEC codes, specified as RFC 6330 in Internet Engineering Task Force (IETF), and notice that the performance always outperforms that of the existing Raptor (RFC 5053) codes in terms of decoding speed, latency and memory. We also include the device based performance comparison of RaptorQ FEC codes in a comparison with other FEC schemes like Supercharged codes and Reed Solomon + Low Density Parity Check codes (RS+

LDPC). Finally, we conduct simulation carried out in the mobile devices for several network parameters like latency, decoding speed and memory in combination with FEC encoding and decoding parameters and investigate that RaptorQ is the best code that suits multicast services.

Keywords: RaptorQ, Raptor, AL-FEC, MBMS, FLUTE

(4)

ii

Acknowledgements

First and foremost thanks to the Almighty for blessing us all the way to begin and finish the thesis successfully. With immense gratitude, we acknowledge the helpful support from our external supervisor Dr.-Ing.Thomas Stockhammer who has given us this wonderful opportunity to begin this thesis. His commitment has paved us a tremendous exposure and knowledge.

Obviously, without him, our thesis has not been possible to thoroughly complete.

We would also like to express our heartfelt thanks to our university advisor Thi My Chinh Chu for her continuous support and suggestions throughout this thesis. Also, we owe a special thanks to our family and friends who has been always been our strength and motivation.

Geethanjali Soundappan Ravichandran Raja Gounder Sivaswamy

(5)

iii

LIST OF TABLES

Table 1: LTE Download Delivery ... 8

Table 2: Parameters for Download Test Cases ... 10

Table 3: PCAP and MD5 for Code X ... 10

Table 4: PCAP Files for Code X after Applying Error Trace ... 12

Table 5: Performance and Result File for Code X after Decoding ... 14

Table 6: Performance Data for Download Delivery Test Cases ... 16

Table 7: LTE Streaming Delivery... 17

Table 8: Parameters for Streaming Test Cases ... 18

Table 9: PCAP Files and Segment List for Code X... 19

Table 10: PCAP Files for Code X after Applying Error Trace... 20

Table 11: Performance and Result File for Code X after Decoding ... 22

Table 12: Performance Data for Streaming Test Cases ... 24

Table 13: Markov Trace Generation for Streaming Cases ... 25

Table 14: Markov Trace Generation for Download Cases ... 26

Table 15: Simulation Scenarios for Download Delivery ... 28

Table 16: Small Memory and Low Overhead ... 29

Table 17: Low Decoding Complexity and Low Overhead ... 29

Table 18: Low Decoding Complexity and Low Memory ... 29

Table 19: Device Based Simulation Scenarios for Streaming Delivery ... 30

Table 20: Comparison of Device Based Download Decoding Speed Values of RaptorQ Code with Supercharged and RS+LDPC Codes ... 31 Table 21: Comparison of Device Based Download Memory Size Values

(6)

iv

of RaptorQ Code with Supercharged and RS+LDPC Codes ... 32 Table 22: Comparison of Device Based Streaming Decoding Speed Values

of RaptorQ Code with Supercharged and RS+LDPC Codes ... 32 Table 23: Comparison of Device Based Streaming Decoding Speed Values

of RaptorQ Code with Supercharged and RS+LDPC Codes ... 33 Table 24: Comparison of Device Based Streaming Decoding Latency Values

of RaptorQ Code with Supercharged and RS+LDPC Codes ... 33

LIST OF FIGURES

Figure 1: Single Cell MBMS Topology... 1 Figure 2: System Setup ... 6 Figure 3: Network Structure ... 27

(7)

v

LIST OF ABBREVIATIONS

3GPP Third Generation Partnership Project

AL-FEC Application Layer Forward Error Correction ARQ Automatic Request for Retransmission FLUTE File Delivery over Unidirectional Transport FDT File Delivery Table

FEC-OTI Forward Error Correction Object Transmission Information

FS File Size

GF Galois Field

IETF Internet Engineering Task Force MD5 Message sum Digest

MBMS Multi Broadcast Multicast Service PCAP Packet Capture

RS + LDPC Reed Solomon + Low Density Parity Check RTCP Real Time Control Protocol

TOI Transport Object Identifier UDP User Datagram Protocol

(8)

vi

Chapter 1

1 Introduction

Internet content delivery over mobile networks is increasing rapidly due to the growth of higher end mobile devices which is driven by high quality displays and superior hardwares.

Multimedia content delivery over unicast service is based on dedicated data link between the server and end device. In unicast, a single server is used to serve any number of clients which leads to increase in the server traffic. Nowadays, there is a significant increase in the demand for multimedia contents over mobile networks. For examples, news and sports video clips, user- contributed media such as clips on YouTube, watching live sport events, high quality movies, visual advertisements, high graphics games and so on are included in multimedia content.

Despite of growth in wireless wide area network, the growth of multimedia content delivered to mobile devices are growing much more significantly. Due to these factors the network traffic increases rapidly which requires that the mobile providers and operators are capable to deliver more content to mobile devices economically without bringing a negative impact on user experience.

1.1 Background

1.1.1 Multimedia Broadcast/Multicast Service (MBMS)

Third Generation Partnership Project (3GPP) named its standard as Multimedia Broadcast/Multicast Services (MBMS) [1]. One way to deliver the multimedia content in an efficient and economical manner is by introducing MBMS. MBMS is a feature which efficiently supports point-to-multipoint broadcast, i.e., MBMS has the capability of transferring the same radio resources such as audio and video clips to large number of mobile subscribers at the same time.

Figure 1: Single Cell MBMS Topology

(12)

2

MBMS architecture is divided into two kinds of services including Bearer and User service. MBMS Bearer service supports two basic transmission modes of delivering IP packets namely broadcast and multicast. MBMS User service supports two types of delivery methods namely Download method and Streaming method. The Download method provides delivery of discrete objects (e.g. files) and the Streaming method provides delivery of continuous media (e.g.

speech, audio, and video) through a MBMS streaming session. This thesis mainly focuses on the Streaming and Download Delivery methods. 3GPP highly recommends Application Layer Forward Error Correction (AL-FEC) mechanism for achieving reliability control over MBMS delivery.

1.1.2 Forward Error Correction (FEC)

Forward Error Correction (FEC) is a method for controlling the errors during data transmission that overcomes the limitations of other reliable methods like Automatic Repeat reQuest for retransmission (ARQ) and Data Carousel [2]. ARQ is the most suitable for one-to- one reliable connections where the receivers use a feedback channel to the send the request for retransmission of lost packets to the sender. However, for one-to-many connections, ARQ exposes many limitations because it requires too many feedback channels to send requests from the receivers to the sender. Furthermore, the observed loss pattern is not the same on all receivers and thus receivers may be delayed during retransmission of packets. This may also cause the wastage of bandwidth since the retransmission of packets that are already received by many receivers. Data Carousel is another reliable method used sometimes in satellite transmission.

This method does not employ feedback channel since there is no flow from the receiver to the sender in satellite systems [3]. In Data Carousel, the sender splits the data into equal length, termed as source symbols, which is then placed in a packet and transmitted continuously in a cyclic manner. However, this method has some limitations such as the receiver has to wait an entire round before it gets the chance to receive the lost packet. This also causes wastage of bandwidth since the transmissions of packets are continuous until all the packets are received by the receivers.

In general, FEC is accomplished by encoding the data utilizing an error-correcting code (ECC) at the sender which allows a certain number of errors are detected and corrected at the receivers without request retransmission of data or additional feedback channel. This allows the same packets to be repaired independently and simultaneously at multiple receivers. However, due to adding the redundancy into the data when encoding, FEC comes at the cost of a higher forward channel bandwidth and it must be carefully applied against packet loss and with respect to certain network condition in order to avoid channel bandwidth wastage and to achieve an efficient and reliable service.

(13)

3 1.1.3 RaptorQ Codes (RFC 6330)

Currently, FEC Raptor code is an existing fountain code standardized by 3GPP for more reliable delivery over MBMS due to its high performance over other FEC codes [4]. A newly enhanced version of Raptor codes in the fountain family is the RaptorQ code. This code not only inherits the characteristics of a general FEC scheme to protect against arbitrary packet loss but also provides superior flexibility, better efficiency and also large source block support than the existing Raptor codes as specified in RFC 5053 [5].

The key difference between the existing Raptor code and the enhanced RaptorQ code is that the RaptorQ code operates over Galois Field GF(256) whereas the existing Raptor code operates on GF(2). Since RaptorQ operates on larger finite fields it can recover the data with lower reception overhead than the Raptor codes which allows RaptorQ to overcome the performance limitations of Raptor codes. In RaptorQ technique, a file is broken into number of blocks known as source blocks and it may also further broken into small blocks known as sub- blocks. Then, RaptorQ encoding is applied independently to each source block. RaptorQ codes are capable to encode up to 56,403 source symbols into a source block. Moreover, it can generate large number of encoding symbols up to 16,777,216 and can deliver large files up to 3.5 GB as a single source block.

1.2 Related Works

The authors of [15] described the application of Raptor FEC for both streaming and download MBMS services over 3G mobile cellular networks considering the impact of AL-FEC on the telecommunication cost. Moreover, the authors of [16] analyzed the performance of an MBMS system for several FEC encoding parameters. [17] Presented some preliminary results of MBMS Download Delivery on comparing the performance of RaptorQ and Raptor codes.

Furthermore, the authors of [18] provided a comprehensive analysis of the process behind the design and performance of Raptor and RaptorQ FEC codes. The work of [19] described a comparative analysis of the performance of RS FEC codes against Raptor FEC codes by considering several performance parameters over MBMS services. 3GPP has released several evaluation documents on comparing the candidates involved in AL-FEC schemes during the standardization process of Raptor code. In particular, [20] presented the simulation results on comparing the performance of Raptor codes with RS codes when described AL-FEC for MBMS Download and Streaming services. It is apparent that the related work describes about the analytical explanations of the Raptor FEC against older FEC schemes and our thesis comes to evaluate the real time performance of RaptorQ FEC against other ideal FEC codes in multicast services.

1.3 Thesis Contribution

In this work, we provide a device based performance evaluation of newly introduced RaptorQ code in terms of decoding speed, latency and memory with the existing 3GPP

(14)

4

standardized FEC Raptor code. We also make a result comparison of other FEC codes namely Supercharged codes and RS+LDPC codes. The simulation of RaptorQ FEC codes is conducted on a Samsung Galaxy SII mobile device with Android 4.0 operating system.

The rest of this document is organized as follows. Chapter 2 presents the 3GPP AL-FEC MBMS framework describing in detail about the MBMS user service which includes FEC protection mechanism on Download and Streaming Delivery methods. Chapter 3 provides detailed descriptions and functionalities of various parameters used in the system setup. Chapter 4 presents the obtained simulation results. In Chapter 5, we provide the result comparison of RaptorQ with other FEC codes. Finally, the conclusion and future work are discussed in Chapter 6 and 7, respectively.

(15)

5

Chapter 2

2 AL-FEC MBMS Delivery

To meet the demand of increase in bandwidth usage in multicast services, 3GPP introduced the standardized MBMS in the third generation mobile systems. MBMS provides data transmission from a single entity to multiple mobile points in a unidirectional point-to-multipoint service. Such a service enables to share radio and core resources by multiple mobile subscribers that offer overall better utilization of radio and core resources. MBMS architecture is composed of two kinds of services namely Bearer service and User service. The Bearer service supports two transmission modes such as Broadcast and Multicast whereas User service supports Delivery method including Download Delivery and Streaming method. As discussed earlier, FEC framework is introduced to enhance the transmission robustness and reliability control in the application layer.

2.1 Download Delivery

MBMS Download Delivery method provides delivery of discrete objects (e.g. files) in a delivery session. This delivery method makes use of the File delivery over Unidirectional Transport (FLUTE) protocol when delivering content over MBMS bearers. FLUTE protocol is used for delivering files over the Internet which supports both multicast and unicast addressing but particularly used for multicast networks. The specification builds on Asynchronous Layered Coding (ALC) which is the base protocol designed for massively scalable multicast distribution.

For more details about FLUTE protocol, let refer to [6].

In FLUTE, the file is partitioned into one or several blocks which are called as source blocks. Every source block consists of k source symbols which are of length T. In order to provide protection for each source block, redundant repair symbols are generated by Raptor encoder. As a result, encoded symbols are obtained as a combination of source symbols and repair symbols assigned by a unique ID. Then, every FLUTE packet payload is loaded with one or more FEC encoding symbols. The resulting packet takes the form of User Datagram Protocol (UDP) packets and is distributed over the IP multicast MBMS bearer.

2.2 Streaming Delivery

MBMS Streaming Delivery method provides delivery of continuous media (e.g. speech, audio, and video) through a MBMS streaming session. Most advanced video and audio codecs such as H.264, H.263, aacPlus codec and mp3lame are used in MBMS. This method uses Real- time Transport Protocol (RTP) in the application layer for MBMS Streaming Delivery and UDP in the transport layer. Similar to Download Delivery method, AL-FEC framework is recommended in Streaming Delivery by 3GPP.

(16)

Chapter 3

3 Test Platform

This part of the thesis provides a test platform for

provide improvements in terms of decoding speed, latency and memory FEC as specified in IETF as RFC 5053.

methods:

1. Download Delivery 2. Streaming Delivery The system setup for both t

elements included in the system setup are Packet CAPture (PCAP) streams, Error Generator, Decoders and network2sd.

In this system, the data is tran

the connection. In the testing procedure, we add an errored PCAP file to the original PCAP file on the PC to substitute for errors induced over the connection.

test procedure will be given as following.

The Laptop which can be Windows/Linux o configurations.

In case of Linux machine, the following softwares must be installed

• Wireshark/Tshark: it is an open source which is used to read packets from the file [7].

6

thesis provides a test platform for evaluation of device-based FEC which s in terms of decoding speed, latency and memory to the existing MBMS s specified in IETF as RFC 5053. The test platform is carried out for two different

1. Download Delivery 2. Streaming Delivery

The system setup for both the delivery methods is shown in the figure below. The main elements included in the system setup are Packet CAPture (PCAP) streams, Error Generator,

Figure 2: System Setup

the data is transmitted from laptop to device and experience

. In the testing procedure, we add an errored PCAP file to the original PCAP file on the PC to substitute for errors induced over the connection. The detailed explanations for the

procedure will be given as following.

top which can be Windows/Linux operating system has the following

In case of Linux machine, the following softwares must be installed for the

Wireshark/Tshark: it is an open source packet analyzer/network protocol analyzer which is used to read packets from the file [7].

based FEC which to the existing MBMS est platform is carried out for two different delivery

he delivery methods is shown in the figure below. The main elements included in the system setup are Packet CAPture (PCAP) streams, Error Generator,

smitted from laptop to device and experiences errors over . In the testing procedure, we add an errored PCAP file to the original PCAP file The detailed explanations for the

as the following

for the simulation:

packet analyzer/network protocol analyzer

(17)

7

• TCPreplay: it is used to resend all packets into the specified network that are stored in a PCAP file [8].

• TCPrewrite: it is a tool that comes along with TCPreplay which is used to rewrite all the packets. In our tests, we used this tool to rewrite the IP/MAC address in the packets.

• Android Software Development Kit (SDK): it provides necessary Application Program Interface (API) libraries and developer tools to build, test, and debug apps for Android [9].

In case of Windows machine, the following softwares must be installed for the simulation:

• Wireshark (Windows version)

• Colasoft packet player: it is used in windows with the same function of TCPreplay in Linux.

• TCPrewrite: it does not support windows version directly and hence pre-written packets are used.

• Android Software Development Kit (SDK) (Windows version)

• Cygwin: it provides a collection of tools that replaces Terminal/Konsole window in linux. Detailed instructions for the cygwin installation can be found in [10].

Requirements for Android device:

• Samsung Galaxy SII (GT-I9100) Smartphone, running Android 4.0.3. The processor is a Dual-core Exynos 4210 1.2GHz processor ARM Cortex-A9.

• Samsung MB-MSBGA Flash memory card, 32 GB microSDHC, 1 x microSDHC SD Card (Class 10).

• Devices must be rooted before using. Rooting device means giving administrative privilege to the device to access all the files that are used only by the manufacturer.

There are many methods available on xda developers website to root the device and one of the simple method can be found in [11].

• SSHDroid- Install SSHDroid in the Samsung device from the Android market.

(18)

8 3.1 LTE Download Delivery Test Cases

For Download Delivery, we considered six different test cases. Each test case denoted as LDX is differentiated by small movie file (Clip), Standard Definition (SD) and High Definition (HD) with respect to file size and error condition.

The file size is chosen as follows

• Clip: 3 * 1024 * 1024 Byte = 3145728 Bytes

• SD: 128 * 1024 * 1024 Byte = 134217728 Bytes

• HD: 1800 * 1024 * 1024 Byte = 1887436800 Bytes.

The process of the Download test cases:

1. Flute packet generation

2. Adding error traces to PCAP files 3. Performance

4. Device based evaluation Test

Cases

Error Conditions Bitrate kbit/s

File File Size (in bytes)

Repetition

LD60 Markov, 3 km/h, 20% 1065.6 HD 1887436800 1

LD108 Markov, 120 km/h, 5% 1065.6 Clip 3145728 20

LD109 1065.6 SD 134217728 5

LD110 1065.6 HD 1887436800 1

LD118 Markov, 120 km/h, 20% 1065.6 Clip 3145728 20

LD119 1065.6 SD 134217728 5

Table 1: LTE Download Delivery

Here LDXX represents the specific test case for Download Delivery which is specified by 3GPP.Markov is a channel condition to generate constant packet loss for each test case with speed and overhead percentage specified by 3GPP.

3.1.1 Test Conditions and Test Procedure 3.1.1.1 Summary of Test Cases

The following test case parameters are specified:

• FS: the file size in bytes.

(19)

9

• FDT is a table which describes various attributes associated with files that are delivered within the file delivery session.

• FEC and OTI are the partitioning and sub-blocking parameters.

• FEC-OTI: FEC Object Transmission Information includes the FEC Encoding ID and if relevant the FEC Instance ID.

• MD5: MD is an algorithm which is utilized to ensure a digital signature and file integrity.

• Packets are units of binary data capable of being routed through a computer network.

• PCAP refers to the file that contains several packets.

• Kt is the total number of source symbols, i.e., Kt = ceil(FS/T).

• Nt is the total number of symbols defined as Kt*(1+O/100).

• O is the percent of transmission overhead according to the table provided by the proponents.

• TOI identifies for which object the packet contains.

• T’ is the FEC payload size.

• T is the symbol size. Typically, T = T’ unless there are multiple symbols per packet.

• Z is the total number of source blocks.

• SeSt is the sending strategy with Interleaved (IL) and Sequential (SQ).

Sequential: send all packets for the first source block, followed by all packets for the second source block, followed by all symbols for the third source block, etc.

Interleaved: send a first packet for each of the Z source blocks, followed by a second packet for each of the Z source blocks, followed by a third packet for each of the Z source blocks, etc.

By default setting, the symbols within each source block are assumed sent in order of increasing ESI-value starting with the first source symbol. If any other sending order for symbols within each source block is utilized, it should be explicitly noted under Notes.

(20)

10

Common Code-Specific (These are examples only) Test

Cases

Error Conditions

File Size FS

T’ Kt Z T O Nt

LD60 Markov, 3km/h, 20%

HD 1288 1465402 53 1288 26 1852820 LD108 Markov,

120km/h, 5%

Clip 1288 2443 1 1288 7 2614

LD109 SD 1288 104207 4 1288 6 110749

LD110 HD 1288 1465402 53 1288 6 1558210

LD118 Markov, 120km/h, 20%

Clip 1288 2443 1 1288 29 3154

LD119 SD 1288 104207 4 1288 27 132757

Table 2: Parameters for Download Test Cases

3.1.1.2 Generate FLUTE Packet Test Streams

• First, generate packets according to FLUTE standard. Next, all the packets are grouped as PCAP file. Then, apply the following actions on the host, i.e., Laptop.

• Consider a movie file, e.g. ed-pixlet.mov which was provided for our experiment. We have six different test cases in Download delivery. Each test case takes the form LDXX according to Table 1.

• Generate a temporary file of size FS. Use the command “head -c <file size> ed- pixlet.mov > data.tmp” and create MD5 for this file.

• Encode the PCAP file using FEC encoder. The resulting PCAP file consists of stream of packets which has FDT as the first packet that specifies TOI and FEC-OTI.

• The resulting PCAP file takes the form LDXX_codeX.cap and the LDXX.md5 file has the generated MD5 value.

Test Cases Error Conditions PCAP Files MD5 Files No of Trials S

LD60 Markov, 3km/h, 20% ld060_codeX.cap ld060.md5 1

LD109 ld109_codeX.cap ld109.md5 5

Table 3: PCAP and MD5 Files for Code X

(21)

11 3.1.1.3 Apply Error Traces to PCAP Streams

A tool named “pcaploss” is used for introducing loss to the PCAP files in a controlled manner on adding Markov error traces. For more details on Markov error trace, refer to Section 3.3. This tool takes pcap file as input and transforms it into another altered pcap file. The usage for pcaploss is:

Pcaploss : Usage: ./pcaploss <pcap_in> <pcap_out> <loss_file> [<#pkts>]

If the optional argument #pkts is present, only the number of packets indicated in this fields is read in from pcap_in before pcaploss closes the output file and stops. The pcap files which are transmitted need to be included the right MAC/IP addresses for both sender and receiver. On the sender side, MAC and IP can be obtained by using the command ‘ipconfig/ all’

on Windows, i.e.,

Ethernet adapter Local Area Connection 4:

Connection-specific DNS Suffix :

Description . . . : SAMSUNG Mobile USB Remote NDIS Network Device Physical Address. . . : 02-65-64-60-6E-0B

DHCP Enabled. . . : Yes Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . : fe80::117:1bc9:34df:dd76%26(Preferred) IPv4 Address. . . : 192.168.42.149(Preferred)

Subnet Mask . . . : 255.255.255.0

Lease Obtained. . . : Monday, July 16, 2012 3:37:43 PM Lease Expires . . . : Monday, July 16, 2012 4:37:50 PM Default Gateway . . . : 192.168.42.129

DHCP Server . . . : 192.168.42.129 DHCPv6 IAID . . . : 855795044

DHCPv6 Client DUID. . . : 00-01-00-01-14-97-F4-E0-F4-CE-46-AC-6F-32 DNS Servers . . . : 192.168.42.129

NetBIOS over Tcpip. . . : Enabled

For the above example, the MAC and IP addresses are 02:65:64:60:6E:0B and 192.168.42.149, respectively. On the receiver side, the associated multicast IP address could be 01:00:5e:66:14:14:0a and 230.20.20.10, respectively. Taking into account the above information, now, we apply the following process on each test case LDXX in Table 3 and each trace number trno.

./tcprewrite --pnat=0.0.0.0/0:230.20.20.10 --enet-dmac= 01:00:5e:66:14:14:0a -- pnat=0.0.0.0/0: 192.168.42.149 --enet-smac=02:65:64:60:6E:0B --fixcsum -i ldXX_codeX.cap -o temp.cap

(22)

12

./pcaploss temp.cap ldY_codeX_ldY_<trno>.cap errortrace_ldY_<trno>.txt

The outcome of the above process consists of ‘S’ PCAP and PCAP files for each test case is summarized in the following Table 4.

Test Cases Error Conditions File Size S PCAP File

LD60 Markov, 3km/h, 20% HD 1 ld060_codeX_ld060_<trno>.cap LD108 Markov, 120km/h, 5% Clip 20 ld108_codeX_ld108_<trno>.cap

LD109 SD 5 ld109_codeX_ld109_<trno>.cap

LD110 HD 1 ld110_codeX_ld110_<trno>.cap

LD118 Markov, 120km/h, 20% Clip 20 ld118_codeX_ld118_<trno>.pcap

LD119 SD 5 ld119_codeX_ld119_<trno>.pcap

Table 4: PCAP Files for Code X after Applying Error Trace 3.1.1.4 Generate Device Performance Measures

The following softwares are used on the Android device:

• The network2sd software is used for reading packets from network interface and writing it in a suitable manner to the SD card in order to optimize reading while decoding. For more details, refer to Section 3.1.1.7.1.

• The ld_decoder software receives reads input data from SD card and writing it back to SD card sub-block by sub-block. For more details, refer to Section 3.1.1.7.2.

• Move the Unix 'time' tool to the device. For details, refer to Section 3.6.

• An ssh server is installed and run on the device to get shell access while USB tethering is active.

The following operations are performed between the host PC and the Android device:

• The host PC is connected to the Android device using USB tethering through an interface. It is assumed that the interface has assigned the name Samsung.

• The host has installed a function that permits to push the stored PCAP files to the device, e.g. Colasoft packet player/ TCPreplay suite.

• More details of connecting the Android device and host PC are provided in Section 3.6.

Process

For each test case LDXX from Table 4 and each <trno>, the following processes are carried out in the following sequence.

(23)

13

On the Android device with wifi IP of 192.168.2.102 and an ssh server running on port

2222, we start the following process in directory

/data/data/berserker.android.apps.sshdroid/home 1. ssh -p 2222 root@192.168.2.102.

2. When asked for passwd, type: "admin"

3. Use ‘rm’ to clear all disk space on SD card 4. time -v ./network2sd info.txt 2> time1.txt

On the host, start the Colasoft Packet Player with the following.

1. Adapter: Samsung

2. Packet File: Add -> File of type: libpcap (*.cap) 3. Select file ldY_codeX_ldY_<trno>.cap

4. Click button "Play"

After termination at the device, the following is carried on the device 1. echo 1 > /proc/sys/vm/drop_caches (# this is for clearing caches) 2. time -v ./ld_decoder info.txt 2> time2.txt

After termination at the device, the following is carried out on the host 1. scp –P 2222

root@192.168.2.102:/data/data/berserker.android.apps.sshdroid/home/out.txt ldY_codeX_ldY_<trno>.out

2. scp –P 2222

root@192.168.2.102:/data/data/berserker.android.apps.sshdroid/home/time1.txt ldY_codeX_ldY_<trno>.time1

3. scp –P 2222

root@192.168.2.102:/data/data/berserker.android.apps.sshdroid/home/time2.txt ldY_codeX_ldY_<trno>.time2

The outcome of this process is one performance file and obtaining one result file for each test case. The files are summarized in Table 5.

(24)

14

Test Case S Result Performance Files

LD60 1 ld060_codeX_ld060_<trno>.out ld060_codeX_ld060_<trno>.time LD108 20 ld108_codeX_ld108_<trno>.out ld108_codeX_ld108_<trno>.time LD109 5 ld109_codeX_ld109_<trno>.out ld109_codeX_ld109_<trno>.time LD110 1 ld110_codeX_ld110_<trno>.out ld110_codeX_ld110_<trno>.time LD118 20 ld118_codeX_ld118_<trno>.out ld118_codeX_ld118_<trno>.time LD119 5 ld119_codeX_ld119_<trno>.out ld119_codeX_ld119_<trno>.time

Table 5: Performance and Result File for Code X after Decoding 3.1.1.5 Performance Evaluation

The content of ldXX_codeX_ldXX_,trno>.time file will look like below.

Command being timed: "ld_decoder"

User time (seconds): 1.49 System time (seconds): 0.36 Percent of CPU this job got: 73%

Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 2.52s Average shared text size (kbytes): 0

Average unshared data size (kbytes): 0 Average stack size (kbytes): 0

Average total size (kbytes): 0

Maximum resident set size (kbytes): 165456 Average resident set size (kbytes): 0

Major (requiring I/O) page faults: 1

Minor (reclaiming a frame) page faults: 21740 Voluntary context switches: 9659

Involuntary context switches: 10442 Swaps: 0

File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0

Page size (bytes): 4096 Exit status: 0

The relevant entries here are "system time", "user time", and "Maximum resident set size". The sum of “system time” and “user time” is reported as the processing cost and 1/4 of

“Maximum resident set size” is considered as the memory usage in an unpatched busybox 1.19.0 The reason for this division by 4 is that busybox has a bug which causes it to overestimate

(25)

15

memory usage by a factor of 4, just like the GNU time utility from which it is presumably inheriting this mistake. See the bug report [12].

The following performance data measurements are proposed:

• Generate the numbers from above for the considered test case

• Generate the numbers from above for a zero loss trace

• Report the following parameters for each test case and zero loss trace:

U: User time (in s)

S: System time (in s)

P: Percent of CPU this job got

W: Elapsed (wall clock) time (h:mm:ss or m:ss):

M: Maximum resident set size (kbytes)

• Generate the following performance evaluation based on the above results and the object size F (in bytes) for each test case and trace number:

Speed: Average decoding speed (in MBit/s): F*8/(1000000*(U+S))

Time1: Decoding time (in s): U+S

Time2: weighted elapsed time (in s): P*W/100

Memory: Peak memory usage (in MBytes): M/4096 3.1.1.6 Performance Documentation

The following values are to be reported for each test case by using the results from each trno = 0 to S-1 and the error free decoding.

• Np: the total number of packets used for decoding

• E: the total number of file delivery attempts that failed (should be 0)

• AvSpeed: the average speed over all S decoding attempts

• AvTime1: the average decode time over all S decoding attempts

• AvTime2: the weighted elapsed time over all S decoding attempts

• MinSpeed: the minimum speed over all S decoding attempts

• MaxTime1: the maximum decoding over all S decoding attempts

(26)

16

• MaxTime2: the weighted elapsed time over all S decoding attempts

• MaxMem: the maximum memory over all S decoding attempts

• EfSpeed: the speed for error-free decoding attempt

• EfTime1: the Time for error-free decoding attempt

• EfTime2: the Time for error-free decoding attempt

• EfMem: the Memory for error-free decoding attempt

These are examples only Test

Cases

S Np AvSpeed

(MBit/s)

Avg Time1

(sec)

Avg Time2

(sec)

Min Speed (MBit/s

)

Max Time1

(sec)

Max Time2

(sec)

Max Mem (MByte)

LD60 1 1482256 101.55 148.69 148.41 101.55 148.41 148.69 9.50 LD108 20 2483 179.76 0.14 0.14 157.29 0.16 0.16 2.60 LD109 5 105211 104.31 10.29 10.16 103.44 10.22 10.38 8.90

LD110 1 1480299 103.73 145.57 143.64 103.73 143.64 145.57 9.50 LD118 20 2523 174.76 0.14 0.14 148.03 0.17 0.17 2.60 LD119 5 106205 101.58 10.57 10.41 101.20 10.47 10.61 9.00

Table 6: Performance Data for Download Delivery Test Cases 3.1.1.7 Code-Specific Tools

3.1.1.7.1 Read from Network and Write to SD

The network2sd software reads packets from network interface and writes it in a suitable manner to the SD card in order to optimize the reading rate of the decoder while decoding. The network2sd writes some information to stdout, which is used by ld_decoder as input to locate the relevant information. For the purpose of receiving payload data, reading and writing to flash/disk, standard Android procedures and functions shall be used.

3.1.1.7.2 Decode from and to SD Card

The ld_decoder software reads input data from SD card and writes it back to SD card sub-block by sub-block. The ld_decoder receives information from the network2sd process in order to locate the relevant data.

(27)

17 3.2 LTE Streaming Delivery Test Cases

For Streaming Delivery, we considered nine different test cases. Each test case is denoted as LSXX differentiated with respect to segment duration and error condition as shown in the Table 7.

Test Cases

Segment Duration (seconds)

Bearer Bitrate (kbit/s)

Duration (seconds) LS21 Markov, 3 km/h,

20%

1 1065.6 1800

LS49 2 1065.6 1800

LS24 4 1065.6 1800

LS33 Markov, 120 km/h, 5%

1 1065.6 1800

LS50 2 1065.6 1800

LS36 4 1065.6 1800

LS45 Markov, 120 km/h, 20%

1 1065.6 1800

LS51 2 1065.6 1800

LS48 4 1065.6 1800

Table 7: LTE Streaming Delivery

3.2.1 Test Conditions and Test Procedure 3.2.1.1 Summary of Test Cases

The following are specified for test cases.

K: number of source symbols N’: number of transmitted symbols T: symbol size

(28)

18

Common Parameters

Code-specific Parameters (These are examples only) Test Cases Error

Conditions

Segment Duration

T’ N’ Packet Interval

Number Segments Y (time=30min)

K Segment Size S

Media Rate

LS21 Markov, 3km/h,

20%

1s 1288 100 10ms 1800 35 45080 360.64

LS49 2s 1288 200 10ms 900 103 132664 530.66

LS24 4s 1288 400 10ms 450 248 319424 638.85

LS33 Markov, 120km/h,

5%

1s 1288 100 10ms 1800 85 109480 875.84

LS50 2s 1288 200 10ms 900 177 227976 911.90

LS36 4s 1288 400 10ms 450 363 467544 935.09

20%

1s 1288 100 10ms 1800 65 83720 669.76

LS51 2s 1288 200 10ms 900 139 179032 716.13

LS48 4s 1288 400 10ms 450 291 374808 749.62

Table 8: Parameters for Streaming Test Cases

3.2.1.2 Generating FLUTE Packet Test Streams

• Generate packets according to FLUTE standard and then group all the packets as PCAP file. Apply the following actions on the host (i.e., Laptop).

• Consider a movie file (e.g. ed-pixlet.mov) which was provided for our experiment.

• We have nine different test cases in Download Delivery. Each test case takes the form LSXX according to Table 8.

• Generate temporary file of size FS using the command “head -c <file size> ed-pixlet.mov

> data.tmp” and create MD5 for the created file.

• Encode the PCAP file using FEC encoder. The resulting PCAP file consists of stream of packets which has FDT as the first packet that specifies TOI and FEC-OTI.

• Segment the given movie file with a fixed duration (in our tests it is taken as 1s, 2s and 4s) and then encode each segment sequentially with increasing TOI numbers from 1 to Y into the ALC/LCT packets. Provide UDP payload and include the timing for the real-time bitrate, i.e., 1 packet for every fixed interval according to the packet interval in Table 8.

Note that the tool pcaploss rewrites correctly the packet timestamps with the right transmission time interval.

• The output of this process consists of a file which has TOI and MD5 for each of the segments and a PCAP file that contains a sequence of segments prefixed with a single multi-packet FDT that summarizes the entire sequence. The PCAP file name for a code with code name X is provided in the Table 9 along with the total number of packets.

(29)

19 Test

Cases

Error Conditions PCAP File Number of Data Packets

Segment List LS21 Markov, 3km/h, 20% ls21_codeX.cap 180000 ls21.md5

LS49 ls49_codeX.cap 180000 ls49.md5

LS33 Markov, 120km/h, 5% ls33_codeX.cap 180000 ls33.md5

LS45 Markov, 120km/h, 20% ls45_codeX.cap 180000 ls45.md5

Table 9: PCAP Files and Segment List for Code X

3.2.1.3 Apply Error Traces to PCAP Streams

A tool named “pcaploss” is used for introducing loss to the PCAP files in the same manner as adding Markov error traces. For more details on Markov error trace refer to Section 3.3. This tool takes pcap file as input and transforms it into another altered pcap file. The usage for pcaploss.

Pcaploss : Usage: ./pcaploss <pcap_in> <pcap_out> <loss_file> [<#pkts>]

If the optional argument #pkts is present, only the number of packets indicated here will be read in from pcap_in before pcaploss closes the output file and stops. The pcap for transmission may be prepared with the right MAC/IP addresses for both sender and receiver. On the sender side MAC and IP can be obtained with the command ‘ipconfig/ all’ on Windows, e.g,

Ethernet adapter Local Area Connection 4:

Connection-specific DNS Suffix . :

Description . . . : SAMSUNG Mobile USB Remote NDIS Network Device Physical Address. . . : 02-65-64-60-6E-0B

DHCP Enabled. . . : Yes Autoconfiguration Enabled . . . . : Yes

Link-local IPv6 Address . . . : fe80::117:1bc9:34df:dd76%26(Preferred) IPv4 Address. . . : 192.168.42.149(Preferred)

Subnet Mask . . . : 255.255.255.0

Lease Obtained. . . : Monday, July 16, 2012 3:37:43 PM Lease Expires . . . : Monday, July 16, 2012 4:37:50 PM Default Gateway . . . : 192.168.42.129

DHCP Server . . . : 192.168.42.129 DHCPv6 IAID . . . : 855795044

(30)

20

DHCPv6 Client DUID. . . : 00-01-00-01-14-97-F4-E0-F4-CE-46-AC-6F-32 DNS Servers . . . : 192.168.42.129

NetBIOS over Tcpip. . . : Enabled

where hardware and IP addresses are 02:65:64:60:6E:0B and 192.168.42.149, respectively. On the receiver side, a multicast IP address and associated MAC could be 230.20.20.10 and 01:00:5e:66:14:14:0a.

./tcprewrite --pnat=0.0.0.0/0:230.20.20.10 --enet-dmac= 01:00:5e:66:14:14:0a -- pnat=0.0.0.0/0: 192.168.42.149 --enet-smac=02:65:64:60:6E:0B --fixcsum -i lsXX_codeX.cap -o temp.cap

./pcaploss temp.cap lsY_codeX_lsY.cap errortrace_lsY.txt

Note that the integration of the Ethernet and IP addresses with tcprewrite is optional. The outcome of the Apply Error Traces to PCAP Streams process consists of one PCAP file for each test case and they are summarized as shown in Table 10.

Test Cases

Error Trace Number of Packets (CODE DEPENDENT) These are examples only LS21 Markov, 3km/h, 20% ls21_codeX_ls21.cap 144000

LS49 ls49_codeX_ls49.cap 144000

LS33 Markov, 120km/h, 5% ls33_codeX_ls33.cap 171000

LS45 Markov, 120km/h, 20%

ls45_codeX_ls45.cap 144000

Table 10: PCAP Files for Code X after Applying Error Trace 3.2.1.4 Generate Device Performance Measures

The following softwares are used on the Android device:

• The ls_decoder software for FEC decoding available on the device. The ls_decoder software receives its input data via the network interface card (UDP/ALC/LCT packets) and writes on stdout decoded source block. If correction of the segment is successful, this application writes on stdout:

[ TOI (32-bit) | length (32-bit) | <sequence of segment bytes>]

(31)

21

where TOI in bytes is the segment Transport Object Identifier followed by the length of the decoded segment in bytes and the actual recovered segment data.

• Verifysegm is used for generating MD5 for a received segment, pushing the data to stdout with TOI and length.

• Move the Unix 'time' tool to the device. For details, refer Section 3.5.

• An ssh server is installed and runs on the device to get shell access while USB tethering is active.

The following operations are performed between the host PC and the Android device.

• The host PC is connected to the Android device using USB tethering through an interface. It is assumed that the interface has assigned the name Samsung.

• The host does have a functionality installed that permits to push the stored PCAP files to the device, E.g., Colasoft packet player/ TCPreplay suite.

• More details of connecting device and host PC are provided in Section 4.7.

Process

For each test case LSXX from Table 10, the following processes are carried out in the following sequence.

With device wifi IP of 192.168.2.102 and an ssh server runningon port 2222, start the following process in directory /data/data/berserker.android.apps.sshdroid/home.

1. ssh -p 2222 root@192.168.2.102 2. When asked for passwd, type: "admin"

3. Use ‘rm’ to clear all disk space on SD card

time -v ./ls_decoder 2> time.txt | time –v verifysegm > out.txt On the host with adapter Samsung

1. Packet File: Add -> File of type: libpcap (*.cap) 2. Select file lsY_codeX_lsY.cap

3. Click button "Play"

After termination at the device, the following command is implemented on the device 1. echo 1 > /proc/sys/vm/drop_caches (# this is for clearing caches)

(32)

22

After termination at the device, the following command is implemented on the host 1. Scp –P 2222

root@192.168.2.102:/data/data/berserker.android.apps.sshdroid/home/out.txt lsY_codeX_lsY.out

2. scp –P 2222

root@192.168.2.102:/data/data/berserker.android.apps.sshdroid/home/time.txt lsY_codeX_lsY.time

The above process is also applied for error-free PCAP files also. The output of this process is one performance file and one result file for each test case. The files are summarized in Table 11.

Test Cases

Result Performance Error-Free

Performance LS21 Markov,

3km/h, 20%

ls21_codeX_ls21.out ls21_codeX_ls21.time ls21_codeX.time LS49 ls49_codeX_ls49.out ls49_codeX_ls49.time ls49_codeX.time LS24 ls24_codeX_ls24.out ls24_codeX_ls24.time ls24_codeX.time LS33 Markov,

120km/h, 5%

ls33_codeX_ls33.out ls33_codeX_ls33.time ls33_codeX.time LS50 ls50_codeX_ls50.out ls50_codeX_ls50.time ls50_codeX.time LS36 ls36_codeX_ls36.out ls36_codeX_ls36.time ls36_codeX.time LS45 Markov,

120km/h, 20%

ls45_codeX_ls45.out ls45_codeX_ls45.time ls45_codeX.time LS51 ls51_codeX_ls51.out ls51_codeX_ls51.time ls51_codeX.time LS48 ls48_codeX_ls48.out ls48_codeX_ls48.time ls48_codeX.time

Table 11: Performance and Result File for Code X after Decoding 3.2.1.5 Performance Evaluation

After all test cases are completed, the output files are available as in Table 11. These files are moved back to the host for evaluation. The number of successfully decoded segments can be computed as follows (on a UNIX machine):

cat lsY_codeX.md5 lsY_codeX.out | sort | uniq –d | wc –l The output of lsY_codeX(_lsY).time will be,

Command being timed: "ls_decoder"

User time (seconds): 1.49 System time (seconds): 0.36 Percent of CPU this job got: 73%

Elapsed (wall clock) time (h:mm:ss or m:ss): 0m 2.52s

(33)

23 Average shared text size (kbytes): 0 Average unshared data size (kbytes): 0 Average stack size (kbytes): 0

Average total size (kbytes): 0

Maximum resident set size (kbytes): 165456 Average resident set size (kbytes): 0

Major (requiring I/O) page faults: 1

Minor (reclaiming a frame) page faults: 21740 Voluntary context switches: 9659

Involuntary context switches: 10442 Swaps: 0

File system inputs: 0 File system outputs: 0 Socket messages sent: 0 Socket messages received: 0 Signals delivered: 0

Page size (bytes): 4096 Exit status: 0

The relevant entries here are "system time", "user time" (the sum of which is to be reported as the processing cost), and "Maximum resident set size". The memory usage to be reported is 1/4 of that given as the "Maximum resident set size" in an unpatched busybox 1.19.0.

The reason for this division by 4 is that busybox has a bug which causes it to overestimate memory usage by a factor of 4. See the bug report [12].

The following performance data measurement is proposed:

• Generate the numbers from the output of lsY_codeX_lsY.time for the considered test case.

• Generate the numbers from the output of lsY_codeX.time for a zero loss trace.

(34)

24

• Report the following numbers for each test case and the zero loss trace:

U: User time (seconds)

S: System time (seconds)

P: Percent of CPU this job got

W: Elapsed (wall clock) time (h:mm:ss or m:ss):

M: Maximum resident set size (kbytes)

• Generate the following numbers for performance evaluation based on the above results and the segment duration D (seconds), the media bit rate R (kBit/s) and the duration of the media data t (seconds):

Speed: Average decoding speed (in MBit/s): R*t/(1000*(U+S))

Latency: Average decoding latency (in ms): D*(1000*(U+S))/t

Memory: Peak memory usage (in MBytes): M/4096

EF : Error-Free test cases 3.2.1.6 Performance Documentation

The performance should be documented according to Table 12. The right three columns document the performance for error-free transmission. The Table 12 value represents examples only.

Test Cases

K Speed (MBit/s)

Latency (ms)

Memory (MByte)

EF Speed (MBit/s)

EF- Latency

(ms)

EF- Memory (MByte) LS21 Markov,

3km/h, 20%

35 110.40 3.27 0.61 130.61 2.76 0.61

LS49 103 140.88 7.53 0.80 175.26 6.06 0.80

LS24 248 152.51 16.76 1.15 194.90 13.11 1.15

5%

85 153.21 5.72 0.72 253.87 3.45 0.55

LS50 177 160.30 11.38 0.97 303.97 6.00 0.69

LS36 363 157.30 23.78 1.46 315.20 11.87 0.94

20%

65 145.95 4.59 0.68 230.51 2.91 0.55

LS51 139 156.63 9.14 0.87 266.33 5.38 0.64

LS48 291 158.00 18.87 1.28 282.87 10.60 0.84

Table 12: Performance Data for Streaming Test Cases

(35)

25 3.3 Generating Markov Error Traces

The provided packages “LossGenrator.java” and “Random.java” are used to generate the loss traces independently. The package is compiled and then executed as follows:

javac LossGenerator.java

java LossVectorGenerator p q gBLER bBLER subsamp n seed offset vectorfile with:

p (transition probability from good to bad state) q (transition probability from bad to good state) gBLER (BLER for the good markov state) bBLER (BLER for the bad markov state) subsamp (subsampling for markov trace) n (length of the vector to be generated) seed (for the prng)

offset (iterate n times before generating the vector) vectorFile (file name where to output the vector)

Table 13 provides the values for the arguments that are passed to the java program to generate the error traces for the Streaming test cases.

Test Cases

Test Script Parameters LS21 Markov, 3km/h,

20%

0.0461 0.1680 0.0016 0.8920 1 180000 0 0 errortrace_ls21.txt LS49 0.0461 0.1680 0.0016 0.8920 1 180000 0 0 errortrace_ls49.txt LS24 0.0461 0.1680 0.0016 0.8920 1 180000 0 0 errortrace_ls24.txt LS33 Markov,

120km/h, 5%

0.2707 0.7095 0.0000 0.1954 1 180000 0 0 errortrace_ls33.txt LS50 0.2707 0.7095 0.0000 0.1954 1 180000 0 0 errortrace_ls50.txt LS36 0.2707 0.7095 0.0000 0.1954 1 180000 0 0 errortrace_ls36.txt LS45 Markov,

120km/h, 20%

0.3560 0.6329 0.0972 0.4040 1 180000 0 0 errortrace_ls45.txt LS51 0.3560 0.6329 0.0972 0.4040 1 180000 0 0 errortrace_ls51.txt LS48 0.3560 0.6329 0.0972 0.4040 1 180000 0 0 errortrace_ls48.txt

Table 13: Markov Trace Generation for Streaming Test Cases

Table 14 provides the values for the arguments that are passed to the java program to generate the error traces for the Streaming test cases. The <length> corresponds to the Length in

(36)

26

the table and the <offset> is the trace number minus one multiplied by the length. The trno runs from 1 to S.

Test Cases S Length PCAP File

LD60 1 2000000 0.0461 0.1680 0.0016 0.8920 1 <length> 0 <offset>

error_trace_ld60_<trno>.pcap

LD108 20 3400 0.2707 0.7095 0.0000 0.1954 1 <length> 0 <offset>

LD109 5 150000 0.2707 0.7095 0.0000 0.1954 1 <length> 0 <offset>

LD110 1 2000000 0.2707 0.7095 0.0000 0.1954 1 <length> 0 <offset>

LD118 20 3400 0.3560 0.6329 0.0972 0.4040 1 <length> 0 <offset>

LD119 5 150000 0.3560 0.6329 0.0972 0.4040 1 <length> 0 <offset>

error_trace_ld119_<trno>.pcap Table 14: Markov Trace Generation for Download Test Cases

3.4 Root Acess for Galaxy SII

Once the phone is rooted, to turn on performance mode and disable the second CPU core:

• cd /sys/devices/system/cpu/cpu0/cpufreq: used to view the current CPU frequency.

• cat scaling_governor : this will tell the current mode (on-demand or performance).

• echo performance > scaling_governor: to turn on performance mode.

It is noted that the performance mode will keep the mobile cpu at 1.5GHz, even at idle condition whereas in ondemand mode, at idle condition, the cpu operates at lower speed.

• cat scaling_cur_freq - display current clock frequency in kHz.

• cd /sys/devices/system/cpu/cpu1/cpufreq: to check the settings for cpu1.

It is noted that if core 1 is not on, the cpufreq directory won't exist.

• cd /sys/devices/system/cpu/cpu1: cat online; if it outputs 1, cpu1 is still up.

• echo 0 > /sys/devices/system/cpu/cpu1/online: shuts a given cpu down.

• chmod 444 /sys/devices/system/cpu/cpu1/online: ensures that the cpu is not restarted again.

(37)

27 3.5 Time Command on Android Device

• To enable the time command on an Android device, the Busybox needs to be installed.

• ARM pre-compiled busybox can be downloaded from

http://busybox.net/downloads/binaries/1.19.0/ (the ARMv6l works well on Android).

• Then push it on the phone by

renaming it 'time': adb push busybox-armv6l /data/local/tmp/time

making sure it's executable (adb shell chmod 0777 /data/local/tmp/time).

3.6 USB Tethering of Android Devices

• Enable USB tethering on Android

• Switch ON "Tethering" option in "Setting->Wireless and Networks”.

• You can check the IP address of the newly created interface using the "adb" tool from the Android SDK. Once in the Android shell use the "netcfg" command, the IP address should be "192.168.42.129" (Hardcoded in Android source code).

Android terminal Linux/Win PC

========================= =========================

| | | |

| <<connection status>> | | <<connection status>> |

| - USB Tethering mode | | - Recognizes Android |

| | | terminal as NIC |

| <<interface>> | USB Connection | |

| - New NIC |<==============> | <<interface>> |

| 192.168.42.129 | |- New NIC |

| | | IP from Android |

| | | device (DHCP) |

| <<action>> | | <<action>> |

|- Receive multicast | |- Send multicast |

| packets (pcap) | | packets (pcap) |

========================= =========================

Figure 3: Network Structure

(38)

28

Chapter 4

4 Simulation Results

4.1 Simulation Results for Download Delivery

Download delivery has six different cases where each case is differentiated with respect to file size and error condition. Three different simulation scenarios are performed for these six cases. The three different simulation scenarios are shown below.

1. Small memory and low overhead

The main idea behind this case is to significantly reduce the computational resource by sub-blocking the source blocks.

2. Low decoding complexity and low overhead

This case is used to significantly increase the decoding speed which is done without sub- blocking.

3. Low decoding complexity and low memory

This case is used to significantly reduce the computational resource and increase the decoding speed without undergoing sub-blocking by varying the number of source blocks.

Small memory (Mbytes): The memory used by the decoder in the mobile device for successful decoding process.

Low decoding complexity (Mbit/s): Is defined as the speed of the decoder to decode the file.

Low overhead (%): Defined as the ratio of non-application bytes to the total number of bytes in the message.

The simulation has three parameters namely small memory, low decoding complexity and low overhead. Each simulation process sacrifices one parameter which as shown in Table 15.

Simulation Small Memory Low Decoding Complexity Low Overhead

1 + - +

2 - + +

3 + + -

Table 15: Simulation Scenarios for Download Delivery

FILE-BASED DELIVERY OVER LTE-BASED MBMS