Master Thesis Electrical Engineering Thesis no: MEE-27675 November 2010

Spectrum Sensing Through Implementation of USRP2

Adnan Aftab Muhammad Nabeel Mufti

School of Computing Blekinge Institute of Technology 371 79 Karlskrona Sweden

This thesis is submitted to the School of Computing 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 studies.

Contact Information: Authors: Adnan Aftab E-mail: [email protected]

Muhammad Nabeel Mufti E-mail: [email protected]

University advisor: Alexandru Propescu School of Computing

School of Computing Blekinge Institute of Technology 371 79 Karlskrona Sweden

Internet Phone Fax

: www.bth.se/com : +46 455 38 50 00 : +46 455 38 50 57

ii

ACKNOWLEDGMENT

We really want to thank our supervisor Mr. Alexandru Propescu for his time, guidance, support and friendly attitude towards us all the time. His valuable advices paved the way for our research. We would like to extend our thanks to Dr. David Erman for providing us the experimental equipments and to Mr. Yong Yao, his interest towards our research and guiding us from precision towards accuracy. We would also like to thank our families for their support, both financially and morally. Last but not least we like to say thanks to our friends in Sweden, they make our stay memorable and joyful.

Adnan Aftab and M. Nabeel Mufti

ABSTRACT
Scarcity of the wireless spectrum has led to the development of new techniques for better utilization of the wireless spectrum. Demand for high data rates and better voice quality is resulting in the development of new wireless standard making wireless spectrum limited than ever. In this era of wireless communication, service providers and telecom operators are faced with a dilemma where they need a large sum of the wireless spectrum to meet the ever increasing quality of service requirements of consumers. This has led to the development of spectrum sensing techniques to find the unused spectrum in the available frequency band. The results presented in this thesis will help out in developing clear understanding of spectrum sensing techniques. Comparison of different spectrum sensing approaches. The experiments carried out using USRP2 and GNU radio will help the reader to understand the concept of underutilized frequency band and its importance in Cognitive Radios.

Keywords: Cognitive Radio, Spectrum sensing, GNU Radio, USRP2.

ii

Contents
ACKNOWLEDGMENT .......................................................................................................................I ABSTRACT ......................................................................................................................................... II

List of abbreviation .iv List of Figures .vi List of Tables .vii

1 INTRODUCTION ....................................................................................................................... 1 1.1 1.2 1.3 2 AIMS AND OBJECTIVES ........................................................................................................... 1 RESEARCH QUESTIONS .......................................................................................................... 1 THESIS OUTLINE ..................................................................................................................... 2

SPECTRUM SENSING............................................................................................................... 4 2.1 COGNITIVE RADIO OPERATION .............................................................................................. 5 2.2 TYPES OF SPECTRUM SENSING ............................................................................................... 5 2.2.1 Energy Detection .............................................................................................................. 6 2.2.2 Cyclostationary Method .................................................................................................... 6 2.2.3 Matched filter detection .................................................................................................... 7 2.2.4 Wavelet Detection ............................................................................................................. 7 2.3 QUALITATIVE ANALYSIS OF SPECTRUM SENSING TECHNIQUES ............................................... 8 2.4 RADIO SPECTRUM OVERVIEW................................................................................................. 8 2.5 RELATED WORK ................................................................................................................... 10

GNU RADIO AND USRP2 ....................................................................................................... 12 3.1 GNU RADIO OVERVIEW ...................................................................................................... 12 3.1.1 GNU Radio Flow graphs, Sources and Sinks ................................................................. 13 3.2 TYPICAL SOFTWARE RADIO ................................................................................................. 14 3.3 USRP2 ARCHITECTURE AND OVERVIEW ............................................................................. 14 3.3.1 USRP2 Operation with GNU Radio ............................................................................... 16

ENERGY DETECTION IMPLEMENTATION USING USRP2 AND GNU RADIO ........ 19 4.1 PROJECT SETUP .................................................................................................................... 19 4.2 SPECTRUM SENSING ALGORITHM IMPLEMENTATION ........................................................... 22 4.3 PROJECT LIMITATIONS ......................................................................................................... 24 4.3.1 Hardware Limitations ..................................................................................................... 24 4.3.2 Energy detection Algorithm limitations .......................................................................... 25

5 6

RESULTS ................................................................................................................................... 27 CONCLUSION AND FUTURE WORK ................................................................................. 39 6.1 FUTURE WORK ..................................................................................................................... 39

Bibliography.......................................................................................................................... 40 Appendix A............................................................................................................................ 42 Appendix B............................................................................................................................ 46 Appendix C............................................................................................................................ 50

iii

List of abbreviations
Acronym A ADC CPC CPU DAC dBm DC DDC DSSS DUC F FFT FPGA GHz GUI HPSDR IEEE IF IP ISM ITU-T MAC MHZ MIMO Mm MS OSSIE PU PHY RADAR RF SCA SDR SNR SU SWIG UBCR Description Ampere Analogue to Digital Converter Cognition enabling pilot channel Central processing unit Digital to analogue converter Milliwatt-decibel Direct current Digital down converter Direct sequence spread spectrum Digital up converter Frequency Fast Fourier transforms Field programmable gate arrays Giga hertz Graphical user interface High power software defined radio Institute of Electrical and Electronic Engineer Intermediate frequency Internet protocol Industrial Scientific Medical International telecommunication union Media access control Mega hertz Multi input multi output Millimeter Mega samples Open source SCA implementation embedded Primary user Physical Radio detection and ranging Radio frequency Software Communication Architecture Software defined radio Signal to noise ratio Secondary user Simplified wrapper and interface grabber Unlicensed based cognitive radio

iv

Acronym UDP UHD USB USRP WiFi WPAN WT

Description User datagram protocol Universal hardware devices Universal serial buss Universal software radio peripheral Wireless Fidelity Wireless personal area network Wavelet transforms

List of Figures
Figure2.1 Cognitive Radio spectrum sensing Figure 2.2 Cognitive Radio operation Figure 2.3: Energy Detection method Figure 2.4: Cyclostationary Detection Figure 2.5: Wavelet Detection method Figure 2.6: Channel allocation in 2.4GHz ISM band Figure 3.1: GNU Radio software architecture Figure 3.2: GNU Radio Modules Figure 3.3: Basic Software Radio Figure 3.4: USRP2 Motherboard and RF daughter card XCVR 2450 Figure 3.5: USRP2 Front end Figure 3.6: USRP2 operation with GNU Radio Figure 4.1: USRP2_probe.py Output Figure 4.2: Experimental Setup Figure 4.3: USRP2_fft.py output Figure 4.4: gr_plot_fft.py output with USRP2_rx_cfile.py data file Figure 4.5: USRP2_spectrum.py flow chart Figure 5.1: FFT magnitude plot for 2.4GHz band with 20MHz frequency step Figure 5.2: Frequency vs. Gain plot for 2.4-2.5GHz ISM band Figure 5.3: Time, Frequency, and Gain 3D plot for 2.4GHz-2.5GHz using 20MHz frequency step Figure 5.4: Frequency and Magnitude plot with 10MHz step Figure 5.5: Frequency and Magnitude plot with 10MHz step at 2.4GHz ISM band Figure 5.6: Time, Frequency, Magnitude plot using 10MHz step 29 29 30 4 5 6 7 7 9 12 13 14 15 16 17 20 20 21 22 23 27 28 28

vi

Figure 5.7: Spectrogram plot using 10MHz step Figure 5.8: Frequency vs. magnitude plot with Frequency step of 5MHz Figure 5.9: Time, Frequency, gain 3D plot with frequency step of 5MHz Figure 5.10: Spectrogram plot using 5MHz step Figure 5.11: Frequency Vs. Gain plot using 1MHZ step Figure 5.12: Time, Frequency, Gain 3D plot using 1MHz step Figure 5.13: Frequency Vs. Gain plot @ microwave oven range Figure 5.14: Time, Frequency, Gain 3D plot @ microwave oven frequency Figure 5.15: Spectrogram for microwave oven frequency Figure 5.16: Frequency vs. gain plot for 5.8GHz ISM band Figure 5.17: Frequency, Time, Gain plot for 5.8GHz ISM Band Figure 5.18: Spectrogram for 5.8GHz ISM band

30 31 32 32 33 33 34 35 35 36 36 37

List of Tables
Table1. Spectrum sensing techniques comparison Table2: ITU-R allocation of ISM Frequency bands Table 3: Main features of USRP2 8 9 16

vii

Chapter 1 Introduction

viii

INTRODUCTION
The thesis presents the implementation of spectrum sensing through energy detection and wavelet transformation algorithm using GNU Radio and Universal Software Radio Peripheral2 (USRP2). Furthermore comparison of all available spectrum sensing techniques is presented to identify the most efficient method. Spectrum sensing is considered as the prime element of any Cognitive radio (CR). By finding the underutilized frequency in the available spectrum, the radio spectrum scarceness issue can be resolved effectively.

1.1

Aims and objectives

The main aims and objectives of this project are: 1. To analyze different spectrum sensing techniques and find out which one is the most precise in terms of finding spectrum holes in available radio resource. 2. To develop a spectrum sensing algorithm and implement it over Universal Software Radio Peripheral 2(USRP2). Capture the raw data frames for ISM bands specifically 2.4GHz and 5.8GHz in the campus environment at different times according to the traffic intensity. 3. Extraction of raw data from .bin and .dat files and recompile it using graphic modeling tools. 4. To convert data to graphical form so that results can be analyzed and new decision making algorithm can be proposed later based on analysis of graphical results.

1.2

Research Questions
The main research questions for our thesis are as follows: 1. Which spectrum sensing technique is the most robust in terms of available radio resource or wireless spectrum? 2. Is it possible to sense the spectrum without having any prior information about it? 3. How to monitor and sense the spectrum in an efficient way so that spectrum holes can be identified in the defined frequency range? 4. How to find the precise threshold level for sensed spectrum? 5. How to collect the received signals as close as possible to the USRP2 hardware with minimum overhead?

6. What is the most suitable graphical method to analyze the raw data collected through USRP2?

1.3

Thesis outline
The thesis report constitutes of 6 chapters.

Chapter 2 gives insight of technical background and related work done in the area of spectrum sensing. Chapter 3 provides familiarity with the software tools and hardware used in the research. Chapter 4 presents the complete experimental setup. Chapter 5 gives results and the synopsis of results. Chapter 6 Conclusion and future work related to the topic under consideration.

CHAPTER 2 Spectrum Sensing

SPECTRUM SENSING
Cognitive Radio (CR) is a model for radio communication in which a wireless system alters its transmission or reception to effectively communicate with end user avoiding interference from other users present in the spectrum [23]. CR continuously learns about the radio spectrum by sensing the spectrum and changes its transmission or reception parameters according to the user behavior. The spectrum sensing principals of cognitive radio is shown in Figure2.1.

SENSE

LEARN

AWARE

ADAPT

Figure2.1 Cognitive Radio spectrum sensing CR finds the free spectrum holes in the available spectrum range through sensing and learning. CR adapts to the changes in available radio spectrum and varies transmit or receive parameters according to the network condition. In the CR paradigm, there are two types of users known as Primary Users (PU) and Secondary Users (SU). Primary users are the licensed spectrum users who have direct access to the network whereas SUs are the users who rely on the CR decision for spectrum access [18]. There are two main types of spectrum sensing CRs 1. Licensed Band Cognitive Radios (LBCR): in which CR is capable of using licensed frequency bands assigned to users [23]. 2. Unlicensed Band Cognitive Radios (UBCR): which can only make use of the unlicensed part of Radio Frequency (RF) spectrum [23]. The rest of the discussion in this thesis focuses only on the second category of Cognitive Radios referring to it as CR.

2.1

Cognitive Radio Operation

CR emerged as an answer to spectrum crowding problem. Any CRs operation comprises of four states as shown in the Figure 2.2. First the available spectrum is sensed and analyzed to find any available spectrum holes. On the basis of spectrum analysis a decision is made to opportunistically assign the available frequency to the secondary user. Spectrum sensing is the most integral part of CR because all the remaining operations of CR rely on precise sensing of available spectrum [18].

Spectrum Decision

Radio Environment

Spectrum Analyzing

Spectrum Sensing

Figure 2.2 Cognitive Radio operation 2.2

Types of Spectrum Sensing

The most important task of spectrum sensing is transmitter detection. Spectrum sensing plays a key role in the decision making part of CR. There are several different ways to sense the spectrum. Some of the key methods used for spectrum sensing are as follows: 1. 2. 3. 4. Energy Detection Cyclostationary Method Matched Filter detection Wavelet detection

Explanation and comparison of all four methods is given below.

2.2.1

Energy Detection
In energy detection method we measure the energy of available radio resource and compare it against a predefined threshold level. If the measured energy falls below the defined threshold level spectrum is marked as available. When the measure energy level is above the defined threshold, its considered as occupied. Energy detection method does not require any prior information of the signal. In simple words it does not care about the type of modulation used for transmission of signal, phase or any other parameter of signal. It simply tells if the radio resource is available at any given time instant or not without considering the PU and SU [10]. Hypothetically, energy detection can be considered as a method based on binary decision, which can be written as follows: = = +
(1) (2)

Where s(t) is the received signal and n(t) is the additive white Gaussian noise i.e. equally distributed all over the signal. H0 and H1 represent the two outcomes of the energy detection method [4]. The energy detection methods working principal can be explained with the Figure2.3
X(t)

Fast Fourier Transform

X(f)

Windowing the Peak

Y(f)

FFT Magnitude

Decide H0 or H1

Figure 2.3: Energy Detection method

2.2.2

Cyclostationary Method

A Cyclostationary process is defined as the statistical process which repeats itself cyclically or periodically [6]. Communication signals are Cyclostationary with multiple periodicities. Mathematically Cyclostationary detection can be performed as given in equation (3): = + ej2 t (3)

The equation shows the autocorrelation of the observed signal x(t) with periodicity T, E represents the expectation of the outcome and represents the cyclic frequency [6]. After autocorrelation Discrete Fourier Transform over resulting correlation is performed to get the desired result in terms frequency components. The peaks in the acquired data give us the information about the spectrum occupancy. The Cyclostationary detection method requires prior

knowledge of periodicity of signal and it can only be used with the signal possessing Cyclostationary properties. The implementation of Cyclostationary method is shown in Figure2.4.
X(t) X(f)
Decide H0 or H1

FFT

Correlation of x(f+)x*(f-)

S(f,)

Cyclic freq. Detector

Figure 2.4: Cyclostationary Detection [10]

2.2.3

Matched filter detection

In the matched filter detection method a known signal is correlated with an unknown signal captured from the available radio resource to detect the presence of pattern in the unknown signal [6]. Matched filter detection method is commonly used in Radio Detection and Ranging (RADAR) communication [10]. The use of matched filter detection is very limited as it requires the prior information about the unknown signal. For example in case of GSM, the information about the preamble is required to detect the spectrum through matched filter detection method. In case of WiMAX signal prior information about the Pseudo Noise (PN) sequence is required for detection of spectrum.

2.2.4

Wavelet Detection

To detect the wideband signals, wavelet detection method offers advantage over the rest of the methods in terms of both simplicity and flexibility. It can be used for dynamic spectrum access. To identify the white spaces or spectrum holes in the available radio resource, the entire spectrum is treated as the sequence of frequency sub-bands. Each sub-band of frequency has smooth power characteristics within the sub-band but changes abruptly on the edge of next sub-band. By using the wavelet detection method the spectrum holes can be found at a given instance of time by finding the singularities in the attained result [10]. The Figure 2.5 shows the wavelet detection implementation for spectrum sensing.
X(t) Fast Fourier Transform
X(f) Power spectral density of X(f) magnitude
Decide H0 or H1

S(f)

Local maximum Detection

Figure 2.5: Wavelet Detection method

2.3

Qualitative analysis of spectrum sensing techniques

All of the above mentioned spectrum sensing techniques have certain advantages and disadvantages. Some of the techniques are suitable for sensing of licensed spectrum whereas others are suitable for unlicensed spectrum. The qualitative analysis of above mentioned spectrum sensing techniques are presented in Table1.

Table1. Spectrum sensing techniques comparison Sensing technique Advantages Does not require prior Energy Detection information, Efficient, less complex Cyclostationary Works perfectly in low SNR areas, robust against interference Low computation cost, accurate detection Works efficiently for wideband signal detection

Matched Filter Wavelet Detection

Disadvantages Limited functionality in low SNR areas, cannot differentiate between PU and SU Requires fractional information about the PU, less efficient in terms of computation cost Requires prior information about PU Does not work for DSSS, more complex

It can clearly be seen from table1 that energy detection is the most suitable technique for unlicencessed spectrum bands as it does not require any prior information about the PU and SU.

2.4

Radio spectrum overview

Radio spectrum comprises of electromagnetic frequencies ranging lower than 30GHz or having wavelength larger than 1milimeter (mm). Various parts of the radio spectrum are allocated for different kinds of communication application varying from microphones to satellite communication. Today, in most of the countries radio spectrum is government regulated i.e. governments and some other governing bodies like International Telecommunication Union (ITU-T) assign the radio spectrum parts to communication services [1]. There are several different frequency bands defined inside the radio spectrum on the basis of wavelength () and frequency (f). Generically radio spectrum can be classified into two categories as licensed spectrum and unlicensed spectrum. Licensed spectrum comprises of frequency bands governed by government regulated agencies. It is illegal to use licensed frequency spectrum without taking permission from the regulatory bodies. Unlicensed frequency bands can be used by anyone for any scientific or industrial research.

One of the known unlicensed frequency band is Industrial, Scientific and Medical (ISM) frequency band or spectrum. It comprises of several different frequency bands. The ISM band defined by ITU-Regulation is given in the Table2. Table2: ITU-R allocation of ISM Frequency bands [10] Frequency Range Center Frequency Availability 6.765-6.795 MHz 13.55313.567 MHz 26.95727.283 MHz 40.6640.70 MHz 433.05-434.79 MHz 902-928 MHz 2.400-2.500 GHz 5.725-5.875 GHz 24-24.25 GHz 61-61.5 GHz 122-123 GHz 244-246 GHz 6.785MHz 13.560 MHz 27.120 MHz 40.68 MHz 433.92 MHz 915 MHz 2.450 GHz 5.800 GHz 24.125 GHz 61.25 122.5 GHz 245 GHz

ITU Region2 only

Most commonly used ISM bands are 2.4GHz and 5.8GHz band. Though these ISM bands were reserved for the purpose of research but currently these bands are used for different wireless communication standards. Examples of these bands are Wireless Local Area Network defined by Institute of Electrical and Electronics Engineers (IEEE) as 802.11a/b/g/n, Wireless Personal Area Network (WPAN) defined by IEEE as 802.15 and Cordless phones which operate in the range of 915MHz, 2.4GHz, and 5.8GHz. The research carried out in this thesis is performed using the 2.4GHz and 5.8GHz ISM band commonly used for WLAN and defined by IEEE as 802.11. 802.11 standards have defined 13 channels in the range of 2412MHz to 2472MHz [23]. Each channel is 5MHz apart from each other and all the adjacent channel overlap with each other as each channel is 22MHz wide as shown in Figure 2.6.

Figure 2.6: Channel allocation in 2.4GHz ISM band [23]

2.5

Related work
The recent focus on CR technology and advent of Software Defined Radio (SDR) such as GNU Radio has led to the implementation of GNU Radio in terms of Cognitive Radio [3]. There are hundreds of citations available on IEEE explore investigating different aspects of spectrum sensing and CR. Most of the ongoing debate is concerned about finding the right spectrum sensing techniques for CR, channel allocation and transmission power handing for the Media Access Control (MAC) and Physical (PHY) layer implementation [5]. Underutilized bandwidth detection is key element of any spectrum sensing technique [9]. There are number of different platforms available for the implementation of CR in terms of SDR. One of these platforms include Open source Software Communication Architecture (SCA) implementation-Embedded (OSSIE) by Virginia Tech [24]. OSSIE is an open source software radio suite which can be used to model any of SDR and CR applications. Other platforms include High Power SDR (HPSDR) [25] and Flex Radio [26]. There are some other technique that could be considered as alternative to spectrum sensing. One of these techniques is cognition enabling pilot channel (CPC) [6]. According to CPC, a database of licensed users can be created which will monitor the use of spectrum by creating another channel and by advertising the spectrum opportunities in timely manner. But this will restult in additional infrastructure and use of another channel known as CPC. It is not the best approach to overcome spectrum scarcity as it will result in extra overhead in terms of radio resource.

10

CHAPTER 3 GNU Radio and Universal Software Radio Peripheral 2 (USRP2)

11

GNU RADIO AND USRP2

3.1

GNU Radio Overview

GNU Radio is an open source development platform for signal processing and communication applications focusing on implementation of SDRs with low cost external RF hardware. It contains tons of libraries with signal processing routines written in C/C++ programming language. It is widely used in the wireless communication research and real time implementation of software radio systems [16]. GNU Radio applications are mainly written and developed by using Python programming language. Python provides a user friendly frontend environment to the developer to write routines in a rapid way. The performance critical signal processing routines are written in C++ [22]. Python is a high level language; it acts as a glue to integrate the routines written in C++ and executes through python. Python uses simplified wrapper and interface grabber (SWIG) for the purpose of interfacing C++ routines with python frontend application as shown in Figure 3.1. Very high speed integrated circuits hardware description language (VHDL) is a hardware descriptive language. This part of the code is executed in the Field Programmable Gate Array (FPGA) of front end hardware which is USRP2 in our scenario.

Python glue

C++

C++

C++

SWIG

C++

C++

Signal Processing Blocks

VHDL/Verilog FPGA

Figure 3.1: GNU Radio software architecture

12

GNU radio applications can be developed using both Object Oriented Approach and Procedural Approach depending upon the complexity of the problem under consideration. Some of the modules available in the current release of GNU Radio are shown in Figure 3.2:

Figure 3.2: GNU Radio Modules [22]

3.1.1

GNU Radio Flow graphs, Sources and Sinks

Any GNU Radio application can be presented as a collection of flow graphs as in graph theory. The nodes of such flow graphs are called processing blocks. Processing blocks are the code routines written in C++. These processing blocks are tied together through flow graphs or lines connecting blocks. Data flows from one block to another through these flow graphs. All data types which are available in C++ can be used in GNU Radio applications e.g. real or complex integers, floats, etc [22]. Each block connecting one end of flow graph performs one signal processing operation for example encoding, decoding,

13

hardware access etc. Every flow graph in GNU Radio requires at least one source or sink. Source and Sinks can be explained with the example of spectrum sensing scenario explained later in this chapter. In case of spectrum sensing our command line interface acts as sink whereas USRP2 acts as a source. When we use input command line parameters to tune USRP2 in this scenario, the interface acts as a source and USRP2 acts as a sink.

3.2

Typical Software Radio

A typical software radio consists of RF front and Analogue to Digital Converter (ADC) and Digital to Analogue Converter (DAC) interfaced with Central Processing Unit (CPU) and software. Receive and transmit path of typical software radio is shown in Figure3.3:

RECEIVE RF FRONT END

ADC

CODE EXECUTION

RX PATH

TRANSMIT RF FRONT END

DAC

CODE EXECUTION

TX PATH

Figure 3.3: Basic Software Radio

3.3

USRP2 Architecture and Overview

USRP2 allows the creation of a software radio with any computer having gigabit Ethernet interface. Its the upgraded version of its earlier release USRP. USRP has a USB interface limiting the data throughput from USRP to Computer at a maximum bandwidth of 8MHz. The design of USRP and USRP2 is open source and all schematics and component information can be downloaded from the website of the manufacturer [2]. USRP2 contains field programmable gate arrays (FPGA) and RF transceiver board which is connected over FPGA.

14

The main idea behind the design of USRP is to perform all the signal processing tasks for example modulation and demodulation, filtering at the host computer. All the general purpose tasks such as decimation, interpolation, digital up conversion and down conversion are performed inside the FPGA of USRP2. The Figure 3.4 shows the image of USRP2 with RF daughter board. USRP2 contains gigabit Ethernet controller, SD card slot and MIMO expansion slot at the front end with 8 LED indicators. SD card contains the driver for USRP2 mother board and RF transceiver. It requires 5V DC and 6A to power up USRP2 [2]. The main features of USRP2 are given in table 3.

Figure 3.4: USRP2 Motherboard and RF daughter card XCVR 2450

15

RX TX

SD Memory

MIMO Expansion

Ethernet Interface

Figure 3.5: USRP2 Front end Table 3: Main features of USRP2 Interface FPGA RF Bandwidth ADC DAC Daughterboard slots SRAM Power

Gigabit Ethernet Xilinx Spartan 3 2000 25MHz 14 bits, 100MS/s 16 bits, 400 MS/s 1 Tx, 1 Rx 1 MB 5V DC, 3A

3.3.1

USRP2 Operation with GNU Radio

USRP2 operation with GNU Radio can be explained with the help of Figure 3.6. RF transceiver fetches the RF signal from real time environment and converts it to Intermediate Frequency (IF) around direct current (DC) using digital down converter (DDC). After converting it to IF the signal is passed to ADC. USRP2 contains 14-bit ADC converter which provides sampling rate of 100MS/s [2]. The ADC after sampling passes the data to FPGA. The main task for the FPGA is the down conversion of remaining frequency and data rate conversion. After processing, FPGA transfers the results to gigabit Ethernet controller which passes it over to the host computer where the rest of the signal processing tasks are performed.

16

In case of transmission the same procedure is repeated in reverse order. Firstly gigabit Ethernet controller of host computer passes the input parameters to USRP2. After receiving, the complex signal, digital up converter (DUC) converts the signal to IF before passing it to DAC. The DAC passes the IF converted signal to the RF transceiver where it is converted to RF signal and transmitted over the air.

ANTENNA

USRP2

RF DAUGHTER BOARD

ADC/DAC

DSP PROCESSING XILINX FPGA

GIGABIT ETHERNET CONTROLLER

APPLICATION PYTHON

DSP BLOCK C++ ROUTINES

GIGABIT ETHERNET CONTROLLER

HOST PC WITH GNU RADIO

Figure 3.6: USRP2 operation with GNU Radio

17

Chapter 4 Energy detection implementation using USRP2 and GNU Radio

18

4
4.1

ENERGY DETECTION IMPLEMENTATION USING USRP2 AND GNU RADIO

Project Setup
The project setup was created by using GNU Radio installed on Ubuntu Linux 10.10 on personal computer (PC) with the specifications; core 2 Duo, 4 GB ram, 320 GB hard drive, Gigabyte Ethernet interface and ATI Radeon 512 MB graphics card. USRP2 device was used to physically receive the signal from real time environment. The USRP2 was connected to the Ethernet port of Host PC gigabit Ethernet card through CAT6 cable carrying RJ-45 jack at both ends. The USRP2 differs from its predecessor in a way that it requires certain configurations for boot up process unlike USRP which connects through USB port. It requires certain configuration at Linux terminal to make it work with GNU Radio. First the drivers were updated for USRP2 with XCVR2450. Universal Hardware Devices (UHD) provides complete support for the drivers of USRP2 product line. UHD provides both host drivers and Application programming Interface for standalone application development without GNU radio suite. USRP2 communicates at IP/UDP layer. The default IP address for USRP2 is 192.168.10.2, so to make it work Host PC should be assigned an IP address in the same subnet, for example 192.168.10.1. When USRP2 is not assigned an IP address, it communicates with the host pc using UDP broadcast packets, so it is essential to turn off the firewall before establishing the connection with USRP2 [2]. USRP2 can be found on the terminal by entering the following command provided by UHD.
$ sudo find_usrps 00:50:c2:85:35:14 hw_rev = 0x0400

The command returns the MAC address of the USRP2 showing it is available and connected to the interface. GNU radio provides a python routine named USRP2_probe.py which acts as a software RF probe. It is a graphical user interface (GUI) application which returns the frequency range for the transceiver board and its gain in milliWatt-decibel (dBm). The output of the USRP2_probe.py for XCVR2450 dual band transceiver is given in Figure 4.1.

19

Figure 4.1: USRP2_probe.py Output After connecting the USRP2 with GNU radio and bringing it to up and running condition now we can execute any GNU Radio application by writing a routine in python or by using GNU Radio Companion (GRC). The experimental setup is shown in Figure 4.2 :

Figure 4.2: Experimental Setup In this project we developed a routine called USRP2_spectrum.py which is based on usrp_spectrum_sense.py a standard routine available in GNU Radio latest release. The routine works as a software spectrum analyzer and is flexible enough to monitor any RF spectrum. The routine provided in GNU radio libraries was written for USRP first release and has certain limitation in terms of data rate and bandwidth due to USB interface of USRP. It can only monitor a maximum of 8MHz bandwidth at any

20

given time whereas USRP2 has a gigabit Ethernet making it flexible enough to monitor the 25MHz of bandwidth at any given time [2]. Hence we modified the routine to make it work with the USRP2. There are some other routines (written in python) available in GNU Radio but none of these routines are flexible enough to monitor the whole spectrum for a long interval of time. One of these routines is USRP2_fft.py. This is a GUI application which takes the FFT of the received signal in real time and displays it over interface. The limitation with USRP2_fft.py is that, it only provides us with the gain at a given frequency without displaying the spectrum holes. Secondly it is a GUI application and it can only be executed using a low decimation rate, otherwise system specs should be very high. The output of the USRP2_fft.py is shown in Figure 4.3 showing the utilization of channel 1 of 2.4 GHz ISM band in BTH, Karlskrona Campus.

Figure 4.3: USRP2_fft.py output Similarly, there is another application USRP2_rx_cfile.py. The application works as a broad band receiver, it fetches the signal from the external source environment and dumps the Digital down converter output in form of I and Q data directly into the appended file. The data collected at particular time t can be plotted using another GNU radio application named gr_plot_fft.py. The gr_plot_fft.py plots the raw data collection in terms of FFT as shown in Figure 4.4. USRP2_rx_cfile.py has a limitation in terms that it can only extract the data for a given center frequency as shown in Figure4.4. The Figure show the utilization of RF spectrum at 2.437GHz i.e. channel 6 of 2.4GHz ISM band.

21

Figure 4.4: gr_plot_fft.py output with USRP2_rx_cfile.py data file The modified spectrum sensing routine implemented by us overcomes the deficiencies which we have mentioned in available standard routines.

4.2

Spectrum sensing Algorithm implementation

Implementation of spectrum sensing algorithm can be explained with the help of flow graph presented in Figure 4.5. Flow chart shows the flow of data from source i.e., USRP2 to SINK which is Linux command line interface in our scenario. Source i.e. USRP2 fetches the signal of the desired frequency passed to it as a tuning parameter. After passing through USRP2 the raw data bit streams are converted to vectors or arrays of data. FFT is performed on the received raw data with the help of signal processing blocks and it is passed through the Blackman-Harris window to overcome the spectral leakage effect. When the FFT routine is implemented on a non periodic data, it results into spectral leakage i.e. the energy of the signal spreads out to a larger band of frequencies. Window functions helps out in reducing the effect of spectral leakage. After performing the FFT magnitude, decimation of the data is performed. Decimation is the inverse of interpolation. Decimation reduces the sample rate of data by performing down sampling to the desired rate and send to USPR2 as a tuning parameter. After performing decimation the obtained data is appended into a file or it can be plotted on the go through a GUI tool. The data collected is in the form of FFT magnitude bins. By plotting these magnitude bins against the given frequency range the frequency envelop of the signal can be monitored to find the white spaces or spectrum holes. By taking

22

the Power Spectral Density of received FFT magnitude bins we can use the same algorithm for wavelet detection method.

USRP2 SOURCE

Bit stream to Vector Conversion

Blackman-Harris window Tunning Parameter FFT Magnitude

Decimation

Sink

Figure 4.5: USRP2_spectrum.py flow chart The spectrum sensing algorithm steps across the RF spectrum and takes the measurement in terms of FFT magnitude bins. The number of FFT bins, gain, decimation, time delay, dual delay and frequency range are forwarded to the USRP2_spectrum.py as tuning parameters. The minimum number of bins is 3 and the maximum is 1024 bins. The FFT magnitude bins received at a certain frequency consist of 2 parts. First half of the bins i.e. FFT X[1] to FFT X[N/2 - 1] corresponds to the pass band spectrum from the center frequency (fc) to +Fs/2. Whereas the rest of the bins from X [N/2 - 1] to X [N-1] contains spectrum from center frequency to Fs/2. Here X[1] represents the first bin value as shown in appendix B and X[N/2 - 1] represents the middle bin value. For example if we have 256 bins at 2402 MHz with 8MHz frequency step, the bin 0 to 127 corresponds to 2398 MHz to 2402 MHz and the rest of the bins correspond to 2402 MHz to 2406 MHz. The gain parameter sets the gain of tuner card. By default the gain of the card is set to half of maximum gain which is 45dBm in case of XCVR2450. The time delay and dual delay parameters depends upon the decimation rate and length of FFT. By default decimation rate is set to 16 with 256 FFT bins and with time delay of 1ms. Time delay is a key parameter without setting the correct time delay the results could be altered or false. The reason for it is time delay displaying the amount of FFT frames from the source to sink should be

23

forwarded in the defined time. Time delay for a given decimation rate and FFT size can be calculated as follows: No. of FFT Frames = (Decimation Rate * Time delay) / FFT window Size
(4)

In practice to reduce the non linear response of the DDC we performed FFT overlapping. Without FFT overlapping we were getting white spaces at the end of every sweep. We choose an overlap minimum of 25% i.e. we defined the step size to 8MHz for every step. In some cases we even choose overlapping of 0.75% to get the step size of 1MHz, so that we can get as accurate results as possible. The USRP2_spectrum.py is invoked in the following manner: $ Sudo python USRP2_spectrum.py a2.4G b2.5G g45 d8 >rx.dat The time delay parameter is set to 1ms in the code by default. a represents the starting frequency and b represents the last frequency, -g is used to set the gain parameter and-d8 represents that we are using decimation of 8.Decimation rate of 8 means that USRP2 processed 12.5MS/sec during execution of code. The USRP2_spectrum.py is provided in appendix A at the end of the thesis. The typical output of running USRP2_spectrum.py will give us the FFT magnitude bins at a given center frequency. The gain at any given center frequency can be calculated by summing the values of all the bins and by taking square root of the result. After that by taking 20*log(x), where x is the square root of the sum of the bins, we can get the result in dBm. The experiments were carried out in Room G403 of Building2 at Blekinge institute of technology (BTH) in Karlskrona, Sweden. Most of the results were collected during the same project room except a few instances where the results were collected in the cafeteria while turning on the microwave to check the performance of the algorithm in presence of high noise.

4.3

Project Limitations
Project limitations can be classified into two categories i.e. Hardware limitations Energy Detection Algorithm limitations

4.3.1

Hardware Limitations

The results were attained using decimation rate of 8.i.e 12.5MS/sec. More precise results can be obtained by using lower decimation value. USRP2 can monitor maximum bandwidth of 25MHz. The receiver sensitivity can be increased by using a high gain antenna with the tuner card.

24

4.3.2

Energy detection Algorithm limitations

As previously mentioned energy detection based algorithms cannot differentiate between PU and SU [11]. The results are solely based on the threshold level received, or the energy level measured from the environment. Energy detection method cannot be used in a low noise setup. The implemented routine can sense large bandwidth but not at the same time as it steps across the RF spectrum with the change in time domain.

25

Chapter 5 Results

26

RESULTS
The raw data collected by executing the USRP2_spectrum.py routine is appended into .dat and .bin files. These file can be loaded directly into MATLAB or any other plotting tools like octave, SigView or wavelet toolbox software. All the results in this chapter are plotted using Matlab2010 and Sigview. The sample raw data extracted in the .dat file is shown in appendix B. The results obtained show the usage of 2.4GHz WiFi channels in the campus as well as free channels and spectrum holes. The results are collected using both 2.4 GHz ISM band and 5.8 GHz ISM band. The 5.8 GHz band is not used within the campus environment which can easily be observed by looking at frequency and magnitude plot. We have used three different types of plots to verify our results. These are frequency, magnitude and time, frequency, gain 3dimensional (3D) plots and time, frequency spectrograms. Figure 5.1 shows the results obtained for 2.4GHz ISM band by using a frequency step of 20MHz i.e. the above defined routine steps across the ISM band in steps of 20MHz starting from 2.4GHz and ending at 2.502G. As it can be observed from the graph, it is hard to find the exact channel utilization of 802.11 WiFi spectrum due to large sweeps across the spectrum. Figure 5.3 shows the same results in 3-dimensions (3-D) by using another axis for time. The advantage of time axis is that we can monitor the results at any given instance of time.

Figure 5.1: FFT magnitude plot for 2.4GHz band with 20MHz frequency step
27

Figure 5.2: Frequency vs. Gain plot for 2.4-2.5GHz ISM band

Figure 5.3: Time, Frequency, and Gain 3D plot for 2.4GHz-2.5GHz using 20MHz frequency step

28

The results obtained using a smaller step of 10MHz is shown in Figure 5.4. We can easily find the channel utilization of campus WLAN by looking at Figure 5.4 and Figure 5.5. The spikes around 2.43x109 Hz in the plot show the use of Channel 7 at the time of data collection. Frequency and magnitude plots provide us gain at a given frequency but still its not good enough to find the threshold level or to decide which part of spectrum is free because it does not has the time-axis. For this purpose we have used spectrograms.

Figure 5.4: Frequency and Magnitude plot with 10MHz step

Figure 5.5: Frequency and Magnitude plot with 10MHz step at 2.4GHz ISM band
29

Figure 5.6: Time, Frequency, Magnitude plot using 10MHz step Spectrogram shown in Figure 5.7 displays the time frequency relationship with respect to gain. The color bar presented at the right side of the plot shows the different level of energy or gain values. To find the spectrum holes or availability at the defined threshold at any instant, we can compare the color with time and frequency axis. The color red in this

Figure 5.7: Spectrogram plot using 10MHz step

30

Spectrogram shows the spectrum holes or underutilized bandwidth at a given instance of time and Frequency. Due to large frequency step it is hard to differentiate between the colors and it is hard to find the white spaces at the exact location.

To gather even more accurate results we repeated the experiment with 5 MHz frequency step and sweep across the spectrum again. The results obtained are shown in Figure 5.8-5.10. Here we can easily observe the use of channel 1,6,11 in the campus WLAN environment by looking at Figure 5.8 and Figure 5.9.

Figure 5.8: Frequency vs. magnitude plot with Frequency step of 5MHz The spectrogram given in Figure 5.10 is more precise in terms of clarity showing spectrum holes in terms of red tiled surface in the presence of other colors representing different gain values of energy spectrum.

31

Figure 5.9: Time, Frequency, gain 3D plot with frequency step of 5MHz

Figure 5.10: Spectrogram plot using 5MHz step Similarly we gathered the results using 1MHz step. The results obtained are shown in Figure 5.11 and Figure 5.12 showing the utilization of channel 1, 7 and 11 in the WiFi network of the campus.

32

Figure 5.11: Frequency Vs. Gain plot using 1MHZ step

Figure 5.12: Time, Frequency, Gain 3D plot using 1MHz step

33

To check the limitations of our project we conducted another experiment by placing the USRP2 and host PC near microwave ovens to check if energy detection method is susceptible to the high signal strength environment or not. The results attained are shown in Figure 5.13, 5.14 and 5.15. The results clearly show increase in gain in less than 1 second. We received gain values as high as 50dBm and energy detection algorithm didnt identify any other WiFi channel though the university caf is a hotspot and it has a number of wireless routers placed in the vicinity. The spectrogram in Figure 5.15 shows the use of only microwave oven frequency i.e. 2.45 GHz in different colors the rest of the frequency range is red proving microwave frequency magnitude to be high enough to suppress any other signal in the vicinity of cafeteria.

Figure 5.13: Frequency Vs. Gain plot @ 2.45 GHz microwave oven range

34

Figure 5.14: Time, Frequency, Gain 3D plot @ microwave oven frequency

5.15: Spectrogram for microwave oven frequency .

35

Figure 5.16: Frequency vs. gain plot for 5.8GHz ISM band

Figure 5.17: Frequency, Time, Gain plot for 5.8GHz ISM Band

36

Figure 5.18: Spectrogram for 5.8GHz ISM band Final experiment was conducted over 5.8GHz ISM band. Since 5.8GHz frequency band is not used inside the campus, the whole spectrum range appears as white space or underutilized. It can be observed by looking at the Figure 5.17-5.18. A few colored spots in the spectrogram are due to the thermal noise or other hardware noise figure.

37

Chapter 6 Conclusion and Future Work

38

CONCLUSION AND FUTURE WORK

The report presents implementation of energy detection and wavelet based spectrum sensing implementation and analysis of different spectrum sensing techniques. Different experiments were performed to find out the spectrum holes in the occupied 2.4GHz ISM band. The raw data collected by USRP2_spectrum.py is plotted using different plotting techniques to find the spectrum holes. The qualitative analysis of different spectrum sensing methods shows that energy detection is the most reliable and authentic method for the spectrum sensing. The raw data collected in the form of FFT bins is the most efficient way of collecting data for spectrum sensing as it requires just a few signal processing operations. Rest of the work is performed inside the USRP2, This is closest one can get to the hardware for precise results. The results obtained proved that it is possible to find the underutilized bandwidth in a spectrum without having prior knowledge of PU and SU. Wavelet methods though often used in astronomy and acoustics can be used to identify the spectrum holes as shown in the result by plotting spectrograms. The threshold level for any given spectrum of frequencies depends upon several factors such as receiver sensitivity and the number of energy transmitting/receiving nodes.

6.1

Future work
Cognitive radio is relatively new area of research as compared to the rest of communication theory. There are several other methods of spectrum sensing which need to be explored. Energy detection method results can be improved through the use of the Multiple Input Multiple Output (MIMO) approach. This can be done by connecting multiple USRP2 together and sensing the spectrum for a large area. Another way to sense the spectrum is by using cooperative communication and by taking antenna diversity and other factors under consideration. This study could be extended by repeating the same experiment for licensed frequency bands and the results obtained can be compared with ISM band results to get the better understanding of the area of research.

39

Bibliography
[1] J.Mitola. Software radios-survey, critical evaluation and future directions, IEEE National Telesystems Conference, pages 13/15- 13/23, 19-20 May 1992. [2] Matt Ettus. Universal software radio peripheral. http://www.ettus.com. [3] T. Yucek and H. Arslan, A survey of spectrum sensing algorithms for cognitive radio applications, IEEE Communications Surveys & Tutorials, vol. 11, no. 1, First Quarter 2009. [4] M. Sarijari, A. Marwanto, Energy detection sensing based on GNU radio and USRP, An analysis study, 2009 IEEE 9th Malaysia International Conference on Communications (MICC), no.15-17, pp.338-342, Dec. 2009. [5] Shent, B.; Huang, L.; Zhao, C.; Zhou, Z. & Kwak, K. Energy Detection Based Spectrum Sensing for Cognitive Radios in Noise of Uncertain Power, Proc. Int. Symp. Communications and Information Technologies ISCIT 2008, 2008, 628-633 [6] End to End efficiency [E3] white paper, Spectrum Sensing, Nov. 2009. [7] S. J. Shellhammer Spectrum Sensing in IEEE 802.22, Qualcomm Inc. 5755 Morehouse Drive San Diego, CA 92121, 2009. [8] Pooyan Amini, Daryl Wasden, Arash Farhang, Ehsan Azarnasab, Peiman Amini, Behrouz Farhang-Boroujeny, Cognitive spectrum assignment, 2008 Software Defined Radio Technical Conference and Product Exhibition, Oct. 26-30, 2008, Washington D.C., Paper # 1.3-5. Conference Paper, published, 2008. [9]. D. Cabric, A. Tkachenko, R. Brodersen, Experimental study of spectrum sensing based on energy detection and network cooperation, Proc. of the first international workshop on Technology and policy for accessing spectrum,2006. [10] Khaled Ben Letaief. "Cooperative Spectrum Sensing", Cognitive Wireless Communication Networks, 2007 [11] S. Haykin, Cognitive radio: Brain-empowered wireless communications, IEEE Journal on Selected Areas in Communications, February 2005. [12] F. Penna, C. Pastrone, M. A. Spirito, and R. Garello, Energy detection spectrum sensing with discontinuous primary user signal, IEEE Proc. ICC, Jun. 2009.

40

[13] D. Cabric, A. Tkachenko, R. Brodersen, Experimental study of spectrum sensing based on energy detection and network cooperation, Proc. of the first international workshop on Technology and policy for accessing spectrum,2006. [14] H. Urkowitz, Energy detection of unknown deterministic signals, Proc. of IEEE, pp. 523531, Apr. 1967. [15]. R. Tandra, A. Sahai, SNR Walls for Signal Detection, IEEE Journal of Selected Topics in Signal Processing, vol.2, no.1, pp.4-17, Feb. 2008. [16] GNURadio website, http://www.gnu.org/software/gnuradio/. [17] Y. Zeng and Y. C. Liang, Spectrum-sensing algorithms for cognitive radio based on statistical covariances, IEEE Transactions on Vehicular Technology, vol. 58, no. 4, May 2009. [18] J. Mitola and G. Q. Maquire, Cognitive radio: making software radios more personal, IEEE Pers. Commun.,Vol. 6, pp. 1318, Aug. 1999. [19] K. Arshad and K. Moessner, Impact of User Correlation on Collaborative Spectrum sensing for Cognitive Radio, in proc. ICT Mobile Summit 2009, 10-12 June 09, Satander, Spain. [20] D.Cabric.S.M., Mishra.R.W., Brodersen, Implementation Issues in Spectrum Sensing, In Asilomar Conference on Signal, Systems and Computers, November 2004. [21] Zhi Yan, Zhangchao Ma, Hanwen Cao, Gang Li, and Wenbo Wang, Spectrum Sensing, Access and Coexistence Test bed for Cognitive Radio Using USRP, 4th IEEE International Conference on Circuits and Systems for Communications, 2008. ICCSC 2008, 26-28 May 2008. [22] GNURadio Wiki, http://gnuradio.org/redmine/wiki/gnuradio [23] Wikipedia, http://en.wikipedia.com [24] SCA based open source software defined radio, http://ossie.wireless.vt.edu/ [25] High Performance Software Defined Radio (HPSDR), http://hpsdr.org/ [26] Flex Radio, http://www.flex-radio.com/

41

Appendix A
Code of USRP2_spectrum.py is written in python language. The modified part of the code is in italics. The rest of the code is taken from usrp_spectrum_sense.py which is a standard routine available in GNU Radio, and works for USRP first release only. There might be some indentation errors in the routine which can easily be fixed by copying the code in any standard python editor e.g. IDLE.

#!/usr/bin/env python # Copyright 2005,2007 Free Software Foundation, Inc. # This file is part of GNU Radio

from gnuradio import gr, gru, eng_notation, window from gnuradio import usrp2 from gnuradio.eng_option import eng_option from optparse import OptionParser import sys import math import struct

class tune(gr.feval_dd): """ This class allows C++ code to call back into python. """ def __init__(self, tb): gr.feval_dd.__init__(self) self.tb = tb def eval(self, ignore):

try: new_freq = self.tb.set_next_freq() return new_freq except Exception, e: print "tune: Exception: ", e

class parse_msg(object): def __init__(self, msg): self.center_freq = msg.arg1() self.vlen = int(msg.arg2()) assert(msg.length() == self.vlen * gr.sizeof_float) t = msg.to_string() self.raw_data = t

42

self.data = struct.unpack('%df' % (self.vlen,), t)

class my_top_block(gr.top_block): def __init__(self): gr.top_block.__init__(self) parser = OptionParser(option_class=eng_option) parser.add_option("-e", "--interface", type="string", default="eth0", help="Select ethernet interface. Default is eth0") parser.add_option("-m", "--MAC_addr", type="string", default="", help="Select USRP2 by its MAC address.Default is auto-select") parser.add_option("-a", "--start", type="eng_float", default=1e7, help="Start ferquency [default = %default]") parser.add_option("-b", "--stop", type="eng_float", default=1e8,help="Stop ferquency [default = %default]") parser.add_option("", "--tune-delay", type="eng_float", default=10e-1, metavar="SECS", help="time to delay (in seconds) after changing frequency [default=%default]") parser.add_option("", "--dwell-delay", type="eng_float",default=100e-1, metavar="SECS", help="time to dwell (in seconds) at a given frequncy [default=%default]") parser.add_option("-g", "--gain", type="eng_float", default=None,help="set gain in dB (default is midpoint)") parser.add_option("-s", "--fft-size", type="int", default=256, help="specify number of FFT bins [default=%default]") parser.add_option("-d", "--decim", type="intx", default=16, help="set decimation to DECIM [default=%default]") parser.add_option("-i", "--input_file", default="", help="radio input file", metavar="FILE") (options, args) = parser.parse_args() if options.input_file == "": self.IS_USRP2 = True else: self.IS_USRP2 = False self.min_freq = options.start self.max_freq = options.stop if self.min_freq > self.max_freq: self.min_freq, self.max_freq = self.max_freq, self.min_freq # swap them print "Start and stop frequencies order swapped!" self.fft_size = options.fft_size

# build graph s2v = gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size) mywindow = window.blackmanharris(self.fft_size) fft = gr.fft_vcc(self.fft_size, True, mywindow)

43

power = 0 for tap in mywindow: power += tap*tap c2mag = gr.complex_to_mag_squared(self.fft_size) #log = gr.nlog10_ff(10, self.fft_size, -20*math.log10(self.fft_size)10*math.log10(power/self.fft_size))

# modifications for USRP2 if self.IS_USRP2: self.u = usrp2.source_32fc(options.interface, options.MAC_addr) self.u.set_decim(options.decim) samp_rate = self.u.adc_rate() / self.u.decim() else: self.u = gr.file_source(gr.sizeof_gr_complex, options.input_file, True) samp_rate = 64e6 / options.decim self.freq_step =0.75* samp_rate self.min_center_freq = self.min_freq + self.freq_step/2 nsteps = math.ceil((self.max_freq - self.min_freq) / self.freq_step) self.max_center_freq = self.min_center_freq + (nsteps * self.freq_step) self.next_freq = self.min_center_freq tune_delay = max(0, int(round(options.tune_delay * samp_rate / self.fft_size))) # in fft_frames dwell_delay = max(1, int(round(options.dwell_delay * samp_rate / self.fft_size))) # in fft_frames self.msgq = gr.msg_queue(16) self._tune_callback = tune(self) # hang on to this to keep it from being GC'd stats = gr.bin_statistics_f(self.fft_size, self.msgq, self._tune_callback, tune_delay, dwell_delay)

self.connect(self.u, s2v, fft,c2mag,stats) if options.gain is None: # if no gain was specified, use the mid-point in dB g = self.u.gain_range() options.gain = float(g[0]+g[1])/2 def set_next_freq(self): target_freq = self.next_freq self.next_freq = self.next_freq + self.freq_step if self.next_freq >= self.max_center_freq: self.next_freq = self.min_center_freq if self.IS_USRP2: if not self.set_freq(target_freq): print "Failed to set frequency to ", target_freq, "Hz" return target_freq def set_freq(self, target_freq):

44

return self.u.set_center_freq(target_freq) def set_gain(self, gain): self.u.set_gain(gain) def main_loop(tb): while 1: m = parse_msg(tb.msgq.delete_head()) print m.center_freq print m.data . if __name__ == '__main__': tb = my_top_block() try: tb.start() # start executing flow graph in another thread.. main_loop(tb) except KeyboardInterrupt: pass

45

Appendix B
Raw data format
First few samples of data collected through USRP2 and GNU radio using USRP2_spectrum.py. The values in the parenthesis are the FFT magnitudes at the center frequency mentioned at beginning of brackets.
2402343750.0 (0.078479491174221039, 0.0021366067230701447, 0.0016706101596355438, 0.0014919996028766036, 0.0018371485639363527, 0.0038519951049238443, 0.0045247073285281658, 0.0043287002481520176, 0.0052246819250285625, 0.0072058727964758873, 0.010452025569975376, 0.010121340863406658, 0.028328873217105865, 0.029274577274918556, 0.017359867691993713, 0.060994364321231842, 0.07691742479801178, 0.045997627079486847, 0.078885406255722046, 0.68123906850814819, 1.815961480140686, 1.7410080432891846, 0.92414122819900513, 1.2561960220336914, 1.3696602582931519, 2.2194290161132812, 1.8912926912307739, 0.67372077703475952, 1.8998949527740479, 2.9818150997161865, 3.6183938980102539, 1.1647709608078003, 0.80838441848754883, 2.5064244270324707, 2.6447768211364746, 0.85805624723434448, 0.77822285890579224, 1.066877007484436, 1.385168194770813, 0.77945518493652344, 0.52458691596984863, 0.81339508295059204, 0.57239365577697754, 0.44689875841140747, 0.077040821313858032, 0.15660923719406128, 0.35701039433479309, 0.040066912770271301, 0.001107402378693223, 0.0020320124458521605, 0.001333131454885006, 0.0019112494774162769, 0.0029116699006408453, 0.0043828110210597515, 0.0051233791746199131, 0.0079239737242460251, 0.0083901183679699898, 0.011384587734937668, 0.0098102204501628876, 0.016683906316757202, 0.02120569534599781, 0.021779812872409821, 0.085704058408737183, 0.087469212710857391, 0.036451626569032669, 0.2981133759021759, 0.5712742805480957, 3.1547107696533203, 1.8966439962387085, 0.65502303838729858, 1.0833464860916138, 1.6419686079025269, 1.4921739101409912, 1.1128083467483521, 0.99898803234100342, 1.767426609992981, 4.2489080429077148, 1.8145967721939087, 0.6286810040473938, 1.0932257175445557, 1.6184374094009399, 1.5150642395019531, 0.80695647001266479, 0.97723042964935303, 1.6649191379547119, 1.2304015159606934, 0.60114175081253052, 0.36764374375343323, 0.50622117519378662, 0.62805533409118652, 0.17851966619491577, 0.13759393990039825, 0.11775496602058411, 0.25196456909179688, 0.0055190813727676868, 0.0019328504567965865, 0.0034777612891048193, 0.0016256794333457947, 0.0021049873903393745, 0.0028225337155163288, 0.0036936171818524599, 0.004700744990259409, 0.0079878270626068115, 0.012011573649942875, 0.010718739591538906, 0.023751826956868172, 0.021510237827897072, 0.018909499049186707, 0.028562052175402641, 0.062144704163074493, 0.061169750988483429, 0.047624539583921432, 0.56199336051940918, 1.022626519203186, 2.9904580116271973, 1.0949727296829224, 0.88575261831283569, 1.6493371725082397, 2.719914436340332, 1.3443087339401245, 0.46113380789756775, 1.1562153100967407, 2.2555630207061768, 4.9478602409362793, 1.5198602676391602, 0.62178975343704224, 2.4948527812957764, 1.942987322807312, 1.6680817604064941, 0.5647236704826355, 1.0299559831619263, 2.0907723903656006, 0.62880885601043701, 0.75301861763000488, 0.44105544686317444, 0.48039990663528442, 0.63090991973876953, 0.14225435256958008, 0.16485799849033356, 0.26699408888816833, 0.11670123040676117,

46

0.055269010365009308, 0.045230839401483536, 0.031556162983179092, 0.012226605787873268, 0.0099316556006669998, 0.0070943846367299557, 0.0052436715923249722, 0.0052291429601609707, 0.0065299035049974918, 0.0034304608125239611, 0.0031522943172603846, 0.0027866777963936329, 0.0019167417194694281, 0.001906857592985034, 0.0013906561071053147, 0.0012801015982404351, 0.0010967451380565763, 0.0025738335680216551, 0.011629209853708744, 0.021526094526052475, 0.011421794071793556, 0.0024552359245717525, 0.00081654638051986694, 0.00074491609120741487, 0.00087696971604600549, 0.00078586529707536101, 0.00071032048435881734, 0.0006499909795820713, 0.00068799924338236451, 0.000849866250064224, 0.00079919432755559683, 0.00075856858165934682, 0.00078854116145521402, 0.00071194040356203914, 0.00067059422144666314, 0.00084492011228576303, 0.00076157570583745837, 0.0007594208000227809, 0.00067484361352398992, 0.00076539855217561126, 0.00088167772628366947, 0.00084834126755595207, 0.0008001718670129776, 0.00080491398693993688, 0.00095775781664997339, 0.00075492350151762366, 0.00084168644389137626, 0.0007911412394605577, 0.0012192637659609318, 0.0012803474674001336, 0.00072430918226018548, 0.00075210718205198646, 0.00084508676081895828, 0.0011267503723502159, 0.0014678185107186437, 0.0011142620351165533, 0.00083363440353423357, 0.0008323927759192884, 0.0007781044696457684, 0.00071245571598410606, 0.0008046915172599256, 0.00094067084137350321, 0.00068867631489410996, 0.00078109797323122621, 0.00084381789201870561, 0.00072479399386793375, 0.00095712661277502775, 0.0008555956301279366, 0.00076716899638995528, 0.00076011696364730597, 0.00097077444661408663, 0.0008456491632387042, 0.00081668398343026638, 0.00072018272476270795, 0.0010230715852230787, 0.00076872180216014385, 0.00068192993057891726, 0.00083688297308981419, 0.00079831457696855068, 0.0010027461685240269, 0.00083487335359677672, 0.00078005483373999596, 0.00081469607539474964, 0.0007705554598942399, 0.00089630088768899441, 0.00071952160215005279, 0.00078048795694485307, 0.00071756489342078567, 0.00082102115266025066, 0.00071246037259697914, 0.0012075777631253004, 0.0011661506723612547, 0.00073863635770976543, 0.00073408539174124599, 0.00086960755288600922, 0.000859142339322716, 0.00086273468332365155, 0.00085836776997894049, 0.0010911953868344426, 0.00086930743418633938, 0.0008030780591070652, 0.00081013055751100183, 0.0008304059156216681, 0.0013898427132517099, 0.0014285683864727616, 0.00084563024574890733, 0.00078523502452298999, 0.00087360222823917866, 0.0013947460101917386, 0.0014321762137115002, 0.0013469539117068052, 0.0011599337449297309, 0.0011492453049868345, 0.003844299353659153, 0.037321273237466812) 2407031250.0 (3.1974740028381348, 4.031559944152832, 3.217695951461792, 2.0523378849029541, 2.2461001873016357, 3.2930624485015869, 2.9177732467651367, 3.1102924346923828, 2.8934581279754639, 3.1583716869354248, 5.5028438568115234, 3.4998223781585693, 3.728071928024292, 2.8119258880615234, 4.1116776466369629, 4.5282888412475586, 6.4161314964294434, 5.9056835174560547, 5.3880019187927246, 5.1316804885864258, 3.1722424030303955, 3.2820501327514648, 3.5894057750701904, 5.1031947135925293,

47

5.9944367408752441, 4.9885139465332031, 3.0611209869384766, 3.3806934356689453, 4.0355067253112793, 5.950444221496582, 4.3682861328125, 6.3907628059387207, 6.3701944351196289, 7.0584292411804199, 6.152287483215332, 13.17851448059082, 10.31685733795166, 6.7908363342285156, 4.681190013885498, 6.555757999420166, 7.2733640670776367, 4.9511837959289551, 7.0115170478820801, 7.5073418617248535, 5.7620663642883301, 10.491754531860352, 8.545628547668457, 7.1336016654968262, 10.993707656860352, 14.538098335266113, 8.4462566375732422, 4.5616464614868164, 5.8710637092590332, 6.3135218620300293, 6.3264636993408203, 3.255685567855835, 4.3830351829528809, 2.7397422790527344, 1.7573552131652832, 1.76539146900177, 1.5097736120223999, 0.98314499855041504, 1.4055907726287842, 1.4201083183288574, 0.41280713677406311, 0.97726327180862427, 1.6822177171707153, 4.3758697509765625, 1.0595099925994873, 0.49527463316917419, 2.0502135753631592, 2.7550060749053955, 1.1020327806472778, 1.9735193252563477, 1.5492707490921021, 2.4999613761901855, 0.8397904634475708, 0.92863726615905762, 1.8714859485626221, 2.4703466892242432, 3.1873459815979004, 1.166181206703186, 2.7041969299316406, 5.9352045059204102, 3.3433778285980225,

4.7254638671875, 3.4352085590362549, 4.1641387939453125, 3.6395854949951172, 6.711235523223877, 5.0542440414428711, 4.2800970077514648, 7.563817024230957, 6.1517653465270996, 5.2938923835754395, 8.7384729385375977, 11.978425979614258, 6.4902448654174805, 4.5423426628112793, 5.1105408668518066, 7.9897575378417969, 7.8920340538024902, 5.4244108200073242, 7.6162238121032715, 6.3882355690002441, 5.3743562698364258, 8.4772605895996094, 7.9041132926940918, 11.792904853820801, 11.894734382629395, 12.99225902557373, 7.3576827049255371, 3.7589983940124512, 5.2951393127441406, 4.8167567253112793, 3.5456728935241699, 3.4054141044616699, 3.6322879791259766, 2.3923275470733643, 2.1140027046203613, 1.568912148475647, 1.4458366632461548, 0.94674640893936157, 2.5000534057617188, 0.81627821922302246, 0.36113214492797852, 1.1921614408493042, 2.2844400405883789, 2.656505823135376, 0.99709200859069824, 0.95600581169128418, 2.1766338348388672, 2.7532544136047363, 1.4120019674301147, 2.9511003494262695, 2.7556734085083008, 2.2758064270019531, 0.90137410163879395, 1.0676389932632446, 1.8402211666107178, 2.1704912185668945, 2.3636045455932617, 0.81706392765045166, 2.4289414882659912, 8.9075870513916016, 2.0493607521057129,

5.943519115447998, 3.8861455917358398, 4.6584477424621582, 4.581965446472168, 9.182032585144043, 4.2773265838623047, 6.594294548034668, 6.2335686683654785, 7.1196331977844238, 3.7152411937713623, 9.4443597793579102, 10.985051155090332, 6.4896612167358398, 3.9046883583068848, 5.5710554122924805, 8.5431900024414062, 6.0835604667663574, 5.5524086952209473, 7.339911937713623, 6.5758600234985352, 7.7268595695495605, 8.8215827941894531, 7.3362040519714355, 10.975196838378906, 16.446784973144531, 11.927684783935547, 7.5367612838745117, 4.76129150390625, 6.4392209053039551, 6.2896203994750977, 3.480363130569458, 3.8168199062347412, 3.2404756546020508, 2.0473501682281494, 2.6542408466339111, 1.4443670511245728, 1.0355499982833862, 0.99487966299057007, 1.6392966508865356, 0.66750556230545044, 0.7205967903137207, 1.4042747020721436, 3.5576410293579102, 0.94340842962265015, 0.83766782283782959, 1.4233869314193726, 1.9012550115585327, 1.422130823135376, 0.93049532175064087, 1.4158855676651001, 2.8711717128753662, 2.3133275508880615, 1.2856817245483398, 0.9720306396484375, 2.3330845832824707, 2.3740203380584717, 1.2329649925231934, 1.5437220335006714, 2.2527797222137451, 7.1699471473693848, 2.8909635543823242,

48

2.3855693340301514, 0.86046326160430908, 2.473766565322876, 2.5137460231781006, 2.3626995086669922, 1.1714987754821777, 1.8526248931884766, 3.3121376037597656, 1.9961237907409668, 4.7797470092773438, 2.8627450466156006, 3.3258025646209717, 2.6326093673706055, 1.7956358194351196, 2.2838873863220215, 5.9786229133605957, 5.7646760940551758)

2.389784574508667, 0.69971579313278198, 2.5478525161743164, 2.0163238048553467, 1.7347713708877563, 1.5879503488540649, 2.1849963665008545, 3.2454426288604736, 1.9406003952026367, 2.3262240886688232, 3.8520331382751465, 2.3263769149780273, 2.5623633861541748, 1.9629738330841064, 2.4823381900787354, 10.225701332092285,

1.5883164405822754, 1.2471919059753418, 2.6224849224090576, 2.9764595031738281, 1.3939838409423828, 1.2804248332977295, 2.5127692222595215, 2.8538851737976074, 3.7038774490356445, 1.3763785362243652, 3.0856180191040039, 3.5551505088806152, 1.7378360033035278, 2.2246809005737305, 3.0893852710723877, 9.9261703491210938,

49

Appendix C
MATLAB2010 scripts to import and plot the data collected through USRP2_spectrum.py 1) Script for making frequency, magnitude plot
load rec.dat x= rec(:,1); y= rec(:,2); [n,p]=size(rec) %b=200; %z=filter(x,b,y) figure (1) plot(x,y); legend('cycle1','cycle2','cycle3',2) xlabel('Frequency Range') ylabel('|FFT|') title('FFT Magnitude') %figure (2) %plot(x,z,'k') y=y/256; y=sqrt(y); y=20*log(y); figure (2) plot(x,y); xlabel('Frequency Range') ylabel('dB') title('Gain Plot')

% rec.dat is the raw data file. 2) Script for making time, frequency and magnitude 3D plots
load ad58.dat x= ad58(:,1); y= ad58(:,2); %[n,p]=size(twenty) z=1:1:71 b=256; %z=filter(x,b,y) y=y/256; y=sqrt(y); y=20*log(y); stem3(z,x,y,'k') title('Time,Freq,Gain 3D plot') xlabel('Time') ylabel('Frequency Range') zlabel('dB')

50

Master Thesis Electrical Engineering Thesis no: MEE 10-00 December 2010

Study of Abnormal TCP/HTTP Behavior and its Relationship with Web User.

Adeel Ashfaq and Umer Bilal

School of Engineering Blekinge Institute of Technology 37179 Karlskrona Sweden

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

Contact Information:

Author: Adeel Ashfaq and Umer Bilal email: [email protected], [email protected] Supervisor: Junaid Shaikh School of Computing, BTH Blekinge Institute of Technology, Sweden email: [email protected]

Examiner: Dr. Patrik Arlos School of Computing, BTH Blekinge Institute of Technology, Sweden email: [email protected]

School of Engineering Blekinge Institute of Technology 371 79 KARLSKRONA SWEDEN

Internet: www.bth.se/com Phone: +46 455 385000 SWEDEN

Abstract
Web browsing activites have increased to huge volumes in the last decade, causing more interest in the analysis of web trac to extract user behaviour. TCP, the transport layer protocol and HTTP, the application layer protocol plays a major role in web browsing activities. In this thesis an attempt has been made to investigate the anomilies of TCP/HTTP terminations in an application layer environment. An experimental setup has been devised in order to observe the relationship between the TCP ows and user behaviour. We created a simple client server architecture based setup for investigating the TCP connection packets. We categorized the web pages on the bases of their data type i.e. text, picture and video based web pages. We selected the four widely used browsers based on the stats provided by dierent websites. Similarly, the selection of operating system for client and server ends were made on the basis of the stats. Each type of web page is loaded on the server one by one and then accessed by a specic browser ten times. A total of 480 repetitions are performed to get reliable results. A network packet analyzer is used on both ends to analyze the traces and extract the causes of resets. Keywords: Transmission Control Protocol(TCP), Resets, HTTP.

Acknowledgement
First of all we would like to thanks Almighty GOD who gave us strength and wisdom and made us capable of doing this work. We show our bundle of thanks to Mr. Junaid shaikh for his guidance, feedback and support throughout our thesis work. We really appreciate his friendly and encouraging attitude. We thank him for giving us his valuable time in guiding us in sorting out issues related with our thesis by his technical expertise. We are indebted to our professors, colleagues and seniors for their support and help on issues for understanding some key points of simulation softwares and research papers. Alot of appreciation to our venerable parents and family members for their support on each and every step to complete our studies in Sweden.

Adeel Ashfaq and Omer Bilal 2010, Sweden

Contents
Abstract Acknowledgement i i

Contents List of Figures List of Tables

1 Introduction 1.1 Documents Outine . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Literature Review 2.1 Signicance of Web and Web-Users . . . . . . . . . . . . . . 2.2 Quality of Experience (QoE) and Quality of Service (QoS) . 2.3 TCP Connection Management . . . . . . . . . . . . . . . . 2.4 TCP Reset (RST) . . . . . . . . . . . . . . . . . . . . . . . 2.5 HTTP Protocol and TCP connections . . . . . . . . . . . . 2.5.1 HTTP/1.0 [1] . . . . . . . . . . . . . . . . . . . . . . 2.5.2 HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Persistent Connections and Pipelining . . . . . . . . . . . . 2.6.1 Persistent Connection . . . . . . . . . . . . . . . . . 2.6.2 Pipelining . . . . . . . . . . . . . . . . . . . . . . . . 2.7 Possible approaches for acquiring the behavior of web users 2.7.1 Modied Web Browsers . . . . . . . . . . . . . . . . 2.7.2 Web Proxies . . . . . . . . . . . . . . . . . . . . . . 2.7.3 Packet Monitoring . . . . . . . . . . . . . . . . . . . 2.7.4 Web server Monitoring . . . . . . . . . . . . . . . . . 2.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.1 User Surng Model . . . . . . . . . . . . . . . . . . .

ii iv vii
1 2

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

3 . 3 . 3 . 5 . 5 . 6 . 6 . 7 . 7 . 7 . 8 . 8 . 9 . 9 . 9 . 9 . 9 . 10

ii

3 Experiments 3.1 Experiment Methodology . . . . . . . . 3.2 Experiment Setup . . . . . . . . . . . . 3.2.1 Tests without User Interruption . 3.2.2 Tests with user interruptions . . 3.3 Experiment Tools and Technique . . . . 3.3.1 Client server Architecture . . . . 3.3.2 Wireshark Network Analyzer . . 3.3.3 Batch File for automatic browser 3.3.4 Web-servers . . . . . . . . . . . . 3.3.5 Clients . . . . . . . . . . . . . . . 3.3.6 Browsers . . . . . . . . . . . . . 3.3.7 Router . . . . . . . . . . . . . . . 3.3.8 Web Pages . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . opening and closing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

12 12 13 13 13 14 14 14 15 16 16 16 16 16 20 20 22 24 26 28 36

4 Results and Analysis 4.1 Statistical Analysis for Reset Packets . . . . . 4.2 Packet Capture les analysis . . . . . . . . . 4.2.1 User Uninterrupted Tests . . . . . . . 4.2.2 User Interrupted Tests . . . . . . . . . 4.2.3 Comparison of TCP Flows and Ports . 4.3 User Behaviour Extraction Using TCP Resets

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

5 Conclusion and Future Work 38 5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Bibliography A Appendix A.1 Network Trace les . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 Uninterrupted TCP Flows . . . . . . . . . . . . . . . . . . A.1.2 Interrupted TCP Flows . . . . . . . . . . . . . . . . . . . 40 44 44 44 59

iii

List of Figures
2.1 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 User surng model. . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Combination cycle of tests. . . . . . Experiment setup. . . . . . . . . . . Snapshot of Picture based web Page. Snapshot of Text based web Page. . Snapshot of Video based web Page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15 17 18 19 22 22 23 23 24 25 25 26 26 27 27 27 29 30 31 32 34 35

Resets Pattern on the bases of Browser types. . . . . . . . . . . . Resets Pattern on the bases of Web Page types. . . . . . . . . . . Web pages Trends in TCP Resets. . . . . . . . . . . . . . . . . . Browser Contribution in TCP Resets. . . . . . . . . . . . . . . . Network Devices/Users contribution in Resets. . . . . . . . . . . One Reset Packet in Web session, accessing Text Web page using IE8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two Reset in Web session, accessing a video web page using IE8. Resets due to Router while using OPERA. . . . . . . . . . . . . . Reset in Web session due to user interruption while using Opera (Picture Web page). . . . . . . . . . . . . . . . . . . . . . . . . . Resets in a Web session due to user interruption while using IE8 (text web page). . . . . . . . . . . . . . . . . . . . . . . . . . . . Resets in a Web session due to user interruption while using Firefox (Picture web page). . . . . . . . . . . . . . . . . . . . . . Resets in a Web session due to user interruption while using IE8 (Video Web Page). . . . . . . . . . . . . . . . . . . . . . . . . . . Comparison of a TCP ow for a Web Session(Normal vs interrupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP ow of Opera browser while accessing a picture web page. . Firefox using 2 ports to download the whole web page hence no reset due to browser rather both are due to the User interrupt. . Comparison of TCP ows for a Web session (Normal vs Browser interrupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP ow of Internet Explorer browser while accessing a Text web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCP ow of Internet Explorer browser while accessing a Video web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iv

A.1 Apache Firefox Picture Web Page. . . . . . . . . . A.2 Apache Firefox Text Web Page. . . . . . . . . . . . A.3 Apache Firefox Video Web Page. . . . . . . . . . . A.4 Apache Google Chrome Video Web Page. . . . . . A.5 Apache Google Chrome Text Web Page. . . . . . . A.6 Apache Google Chrome Video Web Page. . . . . . A.7 Apache Internet Explorer Picture Web Page. . . . A.8 Apache Internet Explorer Picture Text Page. . . . A.9 Apache Internet Explorer Video Web Page. . . . . A.10 Apache Opera Picture Web Page. . . . . . . . . . . A.11 Apache Opera Text Web Page. . . . . . . . . . . . A.12 Apache Opera Video Web Page. . . . . . . . . . . A.13 Microsoft IIS Firefox Picture Web Page. . . . . . . A.14 Microsoft IIS Firefox Text Web Page. . . . . . . . A.15 Microsoft IIS Firefox Video Web Page. . . . . . . . A.16 Microsoft IIS Google Chrome Video Web Page. . . A.17 Microsoft IIS Google Chrome Text Web Page. . . . A.18 Microsoft IIS Google Chrome Video Web Page. . . A.19 Microsoft IIS Internet Explorer Picture Web Page. A.20 Microsoft IIS Internet Explorer Picture Text Page. A.21 Microsoft IIS Internet Explorer Video Web Page. . A.22 Microsoft IIS Opera Picture Web Page. . . . . . . A.23 Microsoft IIS Opera Text Web Page. . . . . . . . . A.24 Microsoft IIS Opera Video Web Page. . . . . . . . A.25 Apache Firefox Picture Web Page. . . . . . . . . . A.26 Apache Firefox Text Web Page. . . . . . . . . . . . A.27 Apache Firefox Video Web Page. . . . . . . . . . . A.28 Apache Google Chrome Video Web Page. . . . . . A.29 Apache Google Chrome Text Web Page. . . . . . . A.30 Apache Google Chrome Video Web Page. . . . . . A.31 Apache Internet Explorer Picture Web Page. . . . A.32 Apache Internet Explorer Picture Text Page. . . . A.33 Apache Internet Explorer Video Web Page. . . . . A.34 Apache Opera Picture Web Page. . . . . . . . . . . A.35 Apache Opera Text Web Page. . . . . . . . . . . . A.36 Apache Opera Video Web Page. . . . . . . . . . . A.37 Microsoft IIS Firefox Picture Web Page. . . . . . . A.38 Microsoft IIS Firefox Text Web Page. . . . . . . . A.39 Microsoft IIS Firefox Video Web Page. . . . . . . . A.40 Microsoft IIS Google Chrome Video Web Page. . . A.41 Microsoft IIS Google Chrome Text Web Page. . . . A.42 Microsoft IIS Google Chrome Video Web Page. . . A.43 Microsoft IIS Internet Explorer Picture Web Page. A.44 Microsoft IIS Internet Explorer Picture Text Page. A.45 Microsoft IIS Internet Explorer Video Web Page. . A.46 Microsoft IIS Opera Picture Web Page. . . . . . . A.47 Microsoft IIS Opera Text Web Page. . . . . . . . . v

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 45 45 46 46 47 47 48 48 49 49 50 51 52 52 53 53 54 54 55 55 56 57 58 59 60 61 61 62 62 63 63 64 64 65 65 66 67 67 68 68 69 69 70 70 71 71

A.48 Microsoft IIS Opera Video Web Page. . . . . . . . . . . . . . . . 72

vi

List of Tables
4.1 4.2 4.3 4.4 The amount of The amount of Using D. Rossi Using D. Rossi resets generated without user interruption resets generated with user interruption. . . Criteria for Uninterrupted Flows. . . . . . Criteria for Interrupted Flows. . . . . . . . . . . . . . . . . . . . . . . . 21 21 36 37

vii

Chapter 1

Introduction
In todays world the competition between dierent ISPs is increasing day by day and more concentration is being given to nd those parameters that directly aect the user. Hence, user satisfaction is one of the most important topics considered by the service providers and Scrutinizing into quality of experience (QoE) provides us with critical results [2]. Web browsing is one of the most widely used activities on Internet. The quantitative analysis of all the web trac on the Internet in the late 90s suggested that around 70-75% of the total trac is comprised of TCP/HTTP [35]. Furthermore, a recent study performed over two years of Global Internet trafc represented by NANGO (North American network Operators group) in the internet observatory report showed that majority of the internet application trac has migrated to web and video protocols including video over web [6]. World Wide Web trac not only dominates the trac volume on the internet rather it is also diused and merges applications which continuously increases its amount in terms of users. ITU-T has categorized web applications as responsive and error intolerant [7]. Therefore we must have a close observation of the web trac, specically TCP/HTTP connections [8]. There are vast number of literatures focusing solely on the behaviour and characterization of web trafc. In the early 90s Leland et al [9] showed that the LAN trac is bursty on many time scales and can be well described using self similar processes and later Crovella et al [10] showed that this also holds for web trac. Hence despite the exponential growth of internet trac in the last years, TCPs congestion control mechanism has the successfully been able to deal with such trac bursts [11,12]. However, TCP controls the ow of the trac in only one connection; on the other hand the number of connections used is controlled by the users. This shows that the role of the user behaviour plays a very decisive role in the attributes of the web-driven trac. Studies in the past have also shown that TCP/HTTP connections generate a substantial amount of resets (RST). According to a data collected at NLAR/MOAT Network Analysis Infrastructure (NAI), resets occur more than 10% of the total trac whereas in another study this amount was almost 15 [13, 14]. Further the detailed experimental research done on TCP resets at university of Calgary shows that one of the most used web browser is the real cause of these TCP/HTTP connection resets [14]. On

the other hand, according to the research carried out at NARUS Inc showed that TCP/HTTP reset ags generated in a network is inversely proportional to the bandwidth being used by the user. Hence, it was concluded that users with slow internet connections are more likely to generate these reset ags [15]. This thesis relates to the study of the causes and classication of types of reset packets generated during TCP/HTTP transmission. Further we use network traces and point out the measurement of extent we can use to predict user dissatisfaction/satisfaction. In order to achieve this it is required to have the knowledge of the user starting and ending of a session during web surng. Hence, we will use these resources to understand and nd whether these TCP resets can be used as a parameter for user perception about the network quality

1.1

Documents Outine

The rest of the document is divided as followed: Chapter 1 and Chapter 2 will focus on extensive studies based on pervious literature on TCP/HTTP in relation to QoE and QoS. Chapter 3 will discuss the experimental setup and related processes. In Chapter 4, the results will be discussed followed by our conclusion in Chapter 5, which will summarize our basic ndings of our experiment, including how our experiment can be further extended and used in the future.

Chapter 2

Literature Review
Predicting web users behaviour has gained much interest in the last decade or so. Some have monitored the web trac to extract web user behaviour while others used it to generate synthetic trac or to model web trac. To fully understand the scope of this thesis work, let us start with having an insight in the history of Web user signicance. Later we further dene QoE and QoS, TCP/IP management, TCP resets, Hyper Text Transfer Protocol (HTTP), HTTP 1.0 and HTTP 1.1 as prior information about these topics is very important. In the end we describe some approaches to acquire web user behaviour and later the research work done in past on internet trac analysis to predict web user behaviour.

2.1

Signicance of Web and Web-Users

It is a well know fact that users obligation plays a major role in deciding the success of any Quality of Experience management model. Hence, with the advent and emergence of new and improved network services and architecture, it becomes necessary for the service providers to satisfy users expectations. Therefore, it becomes very essential to keep a record of end users perception frequently in order to satisfy the ever changing needs of users [16]. A study conducted in 2008 by Accenture [17] provides a better understanding of the signicance of the user satisfaction. The study unveils that disappointed users could cause a chain reaction by sharing their experiences regarding the services to other users: hence, starring the debasement of the service providers prole. This further leads the disappointed user to switch the operators without ling any formal complaint about the service. All this commotion highlights the issue that how delicate and essential the users presence has become for the service provider.

2.2

Quality of Experience (QoE) and Quality of Service (QoS)

In order to wallop the Internet systems most urgent issues, the Internet society requires to take measures to provide good and improved service quality. On 3

the other hand, it is observed that some of the most essential issues of the QoS are dened on the basis of terms like resource availability and network delivery capacity, instead of issues like user satisfaction. The main hypothesis behind such orthodox views is that the measure of the QoS is closely related to the end-users QoE. This thesis work is about detecting the eects of reset on web browsers along with users behavior and understanding to the service qualities at the application layer. Hence in order to understand the causes and eects of reset and the QoE of user, it is essential to perceive all the facet of the network and its applications. It is always expected by an user that the services he is enjoying must be reliable, uninterrupted, etc. After all in the end it is the user who will experience the service and express his experiences on the basis of his QoE of the network. Some formal denitions of QoS are stated below: Quality of Service ref ers to the capability of a network to provide better service to selected network traf f ic over various technologies, including F rame Relay, Asynchronous T ransf er M ode(AT M ), Ethernet and 802.1 networks, SON ET, and IP routed networks that may use any or all of these underlying technologies. [18] A set of quality requirements on the collective behavior of one or more objects. [19]. QoS can be better described with the parameters like jitter, latency, or bit rate having variable aects on data services. QoS ensures that the networks trac could be prioritized by providing guarantees like controlled relay and dedicated bandwidth. Further, these guarantees could be made available to dierent users, in advance depending on their requirements, resulting in improved performance. When it comes to network, there is always been a lack of perception among the users on its functionalities and the technical terms used within. The knowledge of a user about the network is more of an abstract level. This is where the end-to-end QoS or more specically QoE comes in picture. The term QoE, also known as Quality of User Experience, is a subjective measure of a users experiences with the network services. Some formal statements on QoE are given below: Quality of experience is a subjective measure of perf ormance in a system. QoE relies on human opinion and dif f ers f rom QoS, which can be precisely measured. [20] Quality of Experience has been def ined as an extension of the traditional QoS in the sense that QoE provides inf ormation regarding the delivered services f rom an end user point of view. [21] Hence, QoE cannot be taken as, simply an eective means of providing the QoS, instead it must also consider factors that contribute to overall user satisfaction, such as, suitability, exibility, mobility, security cost, personalization 4

and choice [15]. Further, it is often seen that a selsh user or application tries to improve its own QoE rather than to optimize the QoS of the network. The concept of QoE has been introduced in several white papers [2224], but mostly in context of multimedia delivery. The main focus of QoE is on the subjective valuation of services delivered by the end users. Some of the main issues addressed by QoE are to provide reliable services (availability, accessibility, access time, and continuity), and the comfortability of the services (session quality, usage and support level) [22]. A good example of QoE would be the (voice over internet protocol)VoIP services, the users of any VoIP service did not show any sort of interest in knowing the parameters like packet loss and system throughput, instead his/her interest would be in experiencing good voice quality and the timeliness of the connection.

2.3

TCP Connection Management

Connections are established in TCP using a three-way handshake in order to provide a reliable connection management across the network. In the opening handshake the client side sends TCP SYN (Connection Primitive) bit to the server. The purpose of this SYN bit is to ensure the originality of the request and also to check whether if the other end (server) exits and is willing to establish a connection. After receiving the SYN control segment, the server end acknowledges (ACK) with a SYN ACK control segment. During this initiation process (handshake), both the end users (client and server) establish the starting sequence number i.e., MSS in order to achieve reliable data transfer in either direction. The closing handshake initiates with the client side sending the TCP FIN (CLOSE Primitive) control segment to the server. The purpose of this FIN ag is to ensure that the server end has received and acknowledged all the data segments that were sent when the connection was open. After receiving the FIN ag bit from the client end, the server replies it with an ACK, closes connection and sends a FIN ag bit to the client end. The client after receiving the server end FIN ag, replies with an ACK and hence the connection is closed. This connection record remains in the TIME WAIT for sometime before it is recycled for establishing the new TCP connection.

2.4

TCP Reset (RST)

Each stream of packet in a TCP connection contains a TCP Header, and each of these headers contains a ag termed as reset (RST) ag. This RST ag in TCP header is used to signal the error conditions detected by the TCP. For example, the arrival of data packets for which all the connections are closed would generate a TCP reset. Similarly, the TCP segments arriving with an inappropriate sequence number, or the arrival of the SYN ACK packet for which no SYN response had been generated, would also cause a TCP reset. The original specication of TCP reset is documented in RFC 793 [25] in September 1981. The document delineates the RST ag in the TCP header, and also explained that the resets are devised to preclude old duplicate connection initiations from 5

causing disorder in TCPs three-way handshake. It is also observed that the reset is caused when a host receives data from a TCP connection that is no longer in use. Some formal statements on RST from RFC 793: As a general rule, reset (RST) must be sent whenever a segment arrives which apparently is not intended for the current connection. A reset must not be sent if it is not clear that this is the case. [26] RFC 1122 amends, corrects, and supplements RFC 793. RFC 1122 says nothing specic about sending resets, or not sending resets, in response to ags in the TCP Reserved eld. [26] The above two statements shows that nothing in RFC 793 and RFC 112 suggests the acceptance of sending a reset simply because a SYN packet in the TCP header is using reserved ags, and it is explicitly forbidden to send a reset for the above reasons. TCP protocol is detailed by a series of RFCs (Request for Comments), containing RFC793, RFC1146, RFC1693, RFC2018, RFC2414, RFC2581, RFC2873, RFC2923, RFC2988 and RFC3390. Generally it is seen that, each operating system (OS) has its own implementation of TCP protocol. Hence, each of these OSs introducing their own interpretation of the standards, parameters, and sometimes its own bugs. All these factors are responsible for the dierence among dierent TCP implementations. In the following section we would discuss about dierent HTTP Protocols and TCP connections and their implementations.

2.5

HTTP Protocol and TCP connections

HTTP dominates the major share of web browsing applications over the Internet. As our work is related to observe the TCP/HTTP ows to detect the nishing and starting of a user web session we would like to provide a brief summary on how HTTP modulates data exchange among the client and server, also we would demonstrate the dierences between HTTP/1.0 and HTTP/1.1.

2.5.1

HTTP/1.0 [1]

The standard procedure in which HTTP retrieves web page is as follows: 1) The client initiates a TCP/IP connection with the server, hence sending a page request message. 2) The server responds to the message by sending the pages main body, in Hyper Text Markup Language(HTML) language. Once the data is delivered, server terminates the connection. 3) After receiving the response, the client analyzes the contents of the pages main body. 4) Further, the client initiates a new TCP/IP connection with the server, and hence submits a request message for the contents and pages main body. 5) The server responds to the request by sending the data for the contents and later closes the connection. Studies show that in past web browsing was limited to only single connection at a time. Later, with the advent in the technology, web browsing experience, allowed to have simultaneous TCP connections and a possibility of parallel download with a better and improved performance. The maximum connections may or may not be user-congured, relying on the browser. It is seen that in HTTP, any request or response header is a simple ASCII strings. During a request, the client requests for the name of the resource it wants to download i.e., 6

Uniform Resource Locator(URL). In the response process, the server responds by sending information regarding the requested resource (URL), and if the outcome is positive it attaches it with the response message. Studies done in [27, 28], demonstrate that, HTTP/1.0, a simple one-toone mapping between the TCP connection and objects (contents of the web pages), involves a lot of connections transmitting a modest amount of data. According to the specications shown in [25], higher densities of connections are particularly undesirable because of the presence of TIME WAIT state in TCP. It is seen that a server halt, an obstructed connection in TIME WAIT state for 4 min, and further it might be forced to decline new connections due to shortage of memory or identiers. An extension to this old connection: keep alive extension was documented in [29], this extension was introduced in HTTP/1.0 in order to allow and improvise the retrieval of several objects over one connection.

2.5.2

HTTP/1.1

In order to overcome the limitations of HTTP/1.1 a new and improved version of it was developed, HTTP/1.1. It was designed with a consideration of the fact , that if either the client or server fails to support it, it could be used under its earlier protocol versions (that include HTTP/0.9). Moreover, HTTP/1.1 improves the connection; i.e. Keep Alive extension. This new feature of HTTP/1.1, is termed as Persistent connection, which permits the recovery of multiple web page contents with only a single TCP connection, hence solving the issues synonymous to HTTP/1.0, though it still requires the ability of clearly delimiting each of the downloaded web page content. A study based on HTTP 1.1 persistent connection is briey described in next topic. Content-length (header with the objects length) plays a primal role in HTTP/1.1, though sometimes it becomes impossible to know the size of some of the objects at the very, happening of their transfer. HTTP/1.1 allows the delivery of an object in chunks each of which is bounded by an extra header (Transfer-Encoding) providing the size of the chunks, except for the last chunk, that contains the content-length header, indicating the end of the object. There are two more features that are comprised within HTTP/1.1 and used for improving the eciency of the TCP connection, they are pipelining and data compression. Further details of the HTTP/1.0 and HTTP/1.1 could be found in [30].

2.6
2.6.1

Persistent Connections and Pipelining

Persistent Connection

A study conducted in 1998 for HTTP/1.1 persistent connection on Netscape Navigator and Internet Explorer for dierent servers and proxies, shows that: Persistent connection is supported by both on dierent servers and proxies. The limit of persistent connection to any web server is seen to be 6, though in case of few embedded objects, the connection becomes few. However, it is seen that when the HTML page consists of frames (pictures, videos), or in case of 7

multiple Navigator and pointing to the same web server, the limit of persistent connection exceeds from 6 to 15. It seems that the persistent connections arent timed out by web browsers. Rather, all the inactive connections are placed in a queue. However, when the browser tries to reach a dierent web server, and hence needs to open a fresh persistent connection to the server, all the inactive connections are terminated by the browser with an aid of Least Recently Used (LRU) algorithm. However, in case of Internet Explorer (IE) only 2 persistent connections are allowed to each web server at any moment, and is the same for multiple IE windows for the same web server. In case of IE the persistent connections are timed out after 60 seconds, and when IE connects to a dierent web server, the already opened persistent connections are left loang until they are timed out.

2.6.2

Pipelining

HTTP pipelining is the technique of sending multiple requests out to a single socket without waiting for each response. Pipelining is only supported in HTTP/1.1, hence it is required that both the client and the server should support it. A client supporting the persistent connections may pipeline its request, and the server must response to the incoming requests in the same sequence the requests were received. Implementation in Web Servers Studies show that the execution of the pipelining in web server is simply a matter of ensuring that the network buers are not rejected between requests. Hence, handling a pipelining is easy for all the modern day web servers. Implementation in Web Browsers Once again, the studies show that the pipelining is inactive in most of the web browsers: In IE 8 pipelining requests are not supported, because of the worries concerning buggy proxies and also head-of-line blocking. Pipelining is a default feature of Opera web browser, and Mozilla Firefox 3.6 do support pipelining but it is halted by default.

2.7

Possible approaches for acquiring the behavior of web users

There are many dierent approaches for gaining access to information demonstrating users behavioral patterns on the web: User accessing modied web browsers. Web proxies. Packet Monitoring. Web Server Monitoring. 8

2.7.1

Modied Web Browsers

Modifying the web client by changing its source code can also be used to gather stats for client behavior. This however, can be problematic to some extent, especially since Microsoft Internet Explorer and Safari source code is not available where as that of Opera is of limited options. Apart from that Firefox and Google chrome are open source and can be used as an option if required.

2.7.2

Web Proxies

Using web proxies [31] for collecting stats is suboptimal as all the users must be forced to use Web proxy. Although a number of commercial tools also exist that allow their analysis [32] but their basic function is to assist network administrators. Moreover the work of Mogul et al [33,34] shows their advantages.

2.7.3

Packet Monitoring

The information collected from packet monitoring consists of full HTTP header information that also includes elaborated timestamps of HTTP and TCP events. Further packet monitoring is passive and hence oblivious to user. It does not interfere with the networks performance and the data gathered is more than sucient to extract web user behaviour. We will be using this approach as it meets our requirements and is available to us.

2.7.4

Web server Monitoring

Collecting log les from a web server is also very useful but at the same time we should keep in mind that a single sample web server will not be a representative of all web servers. Users are always inuenced by the content that is being oered by the web server [35,36]. Even if it is possible to set a lot of web servers [3638] it will be non trivial. Web logs do not provide sucient information regarding time of all aspects of data retrieval. Hence they are more useful for improvement of server architecture and trac dimensioning as in [31, 39].

2.8

Related Work

In 2000, H. Abrahamsson & B. Ahlgren [40] modeled a web client using empirical probability for user clicks and transferred data sizes. They analyzed large packet traces and use the empirical model to implement a web client trafc generator. Using HTTP requests and responses and grouping them into a download was the theme to dierentiate between dierent users data and detect the web users cliks. In 2001, C. Chen et al [13] also discovered that impatient users generate a lot of resets and retransmissions wasting bandwidth. They provided good overview about the tcp packet analysis and provided stats for window size, duplicate acks and retransmissions in the traces but did not categorize the reasons for resets. He dierentiates impatient user resets from those due to network by a simple algorithm on the bases of number of bytes of data transferred before a reset. 9

S. Khirman and P. Henriksen (2002) [15] used network traces from an ISP to relate the reset ags in tcp transmission with user dissatisfaction. He concluded this by observing that users with high speed and better bandwidth connections generated less number of resets as compared to those with poor connections speeds. BLT (Bi-layer tracing of HTTP and TCP/IP) [41] was a tool developed by A. Feldman, to extract HTTP and TCP level traces via packet monitoring. They extracted information continuously and online for high speed networks on the expense of high performance hardware. Temporal clustering of internet traces through a free ware HTML reduce has been used by M. Molina et al (2000) [42] to model web trac. They used TCP-Reduce to extract tcp level information and HTML-Reduce extracts useful information such as object size to detect the abort in the clustered download. In 2003, D. Rossi et al [43] used a heuristic approach to dierentiate between interrupted and uninterrupted tcp ows. They used Fin/RST packets to detect the aborting of a tcp ow to predict user behaviour, and concluded that interruption probability is aected by user perceived throughput. A one year study of internet traces done by M. Arlitt C. Williamson (2004) [14] categorized the reasons for resets. They took active measurements and used dierent browsers, servers and operating systems to check TCP implementations and concluded that one of the most used web browser is the main cause for major amount of resets and not the user.

2.8.1

User Surng Model

SAX is another tool developed by D. N. Tran, W. T. Ooi and Y. C. Tay at National university of Singapore to study user behaviour in congestion induced environment [44]. They also use the same concept of grouping HTTP requests and responses into downloads and detect user clicks and aborts. Moreover, a simple and interesting web user practice is shown in this paper with a simple user surng model as shown below.

10

Session arrival

click

Pabort

1 - Pabort

Pretry Wait - Abort Exit session Wait - Complete

Pnext

Think Exit session

Figure 2.1: User surng model.

W here, Click is the user click to start a web session. Pabort is the Probability of aborting a session. Pretry is the Probability of retrying the same page. Pnext is the Probability to move on to next page. As shown above in gure 2.1 the web user behavior comprises of three user states. Basically there are two main states that user follows: a wait-abort state (aborted download), or a wait-complete state (completed download) during an ongoing download process. The third state is called the think state, where the user is following the nished download, followed by the wait-complete state. One could elucidate on this user behavior model by including a sleep time amidst of sessions and non-reactive large downloads.

11

Chapter 3

Experiments
This chapter provides a complete explanation of the experimental setup and the tools used to investigate the abnormal TCP termination process. It initializes with the description and the concept behind the devising of the basic scenario and then moves on to the experiment analysis. Further it shows how the initial results and observations led to more specied relation between the TCP resets and user behavior.

3.1

Experiment Methodology

On the basis of previous literature review and for experimental devising we categorized the main reasons of TCP resets into three main subdivisions as follows TCP resets generated by the user. TCP resets generated due to abnormal behavior of network hardware equipment. TCP resets generated due to erroneous TCP implementation in the software (on client, server end or middle network elements). The rst one relates indirectly to users quality of experience [15] whereas the next two are related to networks quality of service. Hence we categorized our tests into two parts. Tests without user interruption. Tests with user interruption. The next section provides the detail of the dierent scenarios and the experiment setup created to implement these tests. It will also provide an insight dierence between these two tests in terms of TCP termination process.

12

3.2

Experiment Setup

In order to investigate the TCP connection packets we created a simple client server architecture based setup. Dierent web pages were loaded on the server and then accessed by the client repeatedly. We used dierent servers, web browsers and web pages to come to any conclusion. This section provides the detail of the dierent scenarios initially implemented. In the beginning, we categorized the web pages on the bases of their data type i.e. text, picture and video based web pages. We selected 4 most used browsers based on the stats provided by dierent websites [45, 46]. Similarly, the selection of operating system for client end [47, 48] and servers were also selected on the basis of the stats [49, 50]. Each type of web page is loaded on the server one by one and then accessed by a specic browser 10 times. Hence a total of 2 servers and 4 browsers were used to access each type of web page. We got a total of 80 repetitions on each web page through dierent browsers and servers, 60 repetitions using each browser on dierent web pages and servers and 240 repetitions accessing dierent web pages and browsers on each server. Moreover the browser history was disabled so that each time a web page was accessed it acted as the rst time. A network packet analyzer was used on both the server and client end to observer the packets. A combination cycle is shown in gure 3.1to clarify the process.

3.2.1

Tests without User Interruption

In these tests the web pages were uploaded on the web server and accessed by the client in a normal way. The complete process was being analyzed in parallel using Wireshark on both the machines. When the website has been completely downloaded on the user end (with no errors) and we see that the ports become idle, i.e. no transfer of packets can be seen between the server and the client on analyzer. We closed the browser and waited for at least three to ve minutes before reopening the same browser and access the same website. Hence no interruption is introduced from the client end during the transmission process. We had observed the resets generated in a simple TCP transmission. In this rst step, we compiled the number of resets generated during these tests.

3.2.2

Tests with user interruptions

In these tests the same web pages were uploaded on the web server and accessed in a similar way to the last one by the client machine, but the transmission process was interrupted by a Stop and the page is loaded again or refreshed. This process in a wide sense indicates an actual scenario were the user is bored by the slow internet speed or when it takes more time to open a web page, the user reloads the page. After being refreshed when the page contents are completely downloaded without error and the tcp ports being used for transmission become idle, the web page is closed and again after 3-5 min the same page is accessed using the same browser. The whole process is analyzed using Wireshark and results are obtained.

13

Text Web Page Picture Web page Video Web Page

Microsoft Internet information system 5.1 Internet Explorer 8 Mozila Firefox Google Chrome Opera Apache Web Server 2.2

Text Web Page Picture Web page Video Web Page

Figure 3.1: Combination cycle of tests.

3.3
3.3.1

Experiment Tools and Technique

Client server Architecture

As described before we created a simple client server architecture using a wired connection to the server while the same router was connected to a client through a wireless connection as shown below in gure 3.2.

3.3.2

Wireshark Network Analyzer

Wireshark is a multi-platform, free, and open-source packet analyzing computer application. The main functionalities of wireshark includes; network troubleshooting, analysis, software and communication protocol development, and educational purpose. All this application makes it one of the easiest and widely used packet snier. With the aid of wireshark, network trac could be captured or data could be read/analyzed from a le that has recorded the already captured-data packets, and translate these captured data in the format that the users could understand. Wireshark is a network analyzer and also is one 14

Web Servers: Apache 2.2, Microsoft Internet information System 5.1 (IIS) Web Pages: Text , Picture, Video

Web Browsers: Mozilla Firefox 3.6, Internet Explorer 8.1, Google Chrome, Opera. Operating System: WindowsXP (sp3)

Figure 3.2: Experiment setup.

of the most important administrators tools to diagnose and troubleshoot network related issues, but these are also used by intruders to obtain unauthorized information from the network [51]. Our goal is to capture and analyze data packets in a systematic fashion oating around in a network. These captured data packets are further ltered for extracting a wide array of information, such as; TCP/HTTP resets, for troubleshooting network issues, for reading the network behaviour on the basis of packets captured, etc.

3.3.3

Batch File for automatic browser opening and closing

A Batch le is basically a text le containing a series of commands for a computer operating system, especially Windows. The name Batch le refers to the fact that all the sets of command les are batched/bunched together into a single le, this is done in order to avoid the commotion of presenting each le to the system one at a time using the keyboard. In this experiment, we have used Batch le in order to analyze the activities concerning web browsing and

15

resets. Here, the Batch le is used along with the wireshark packet analyzing tool to make our work accurate and easier. The main function of Batch le here is to start the web browser (in un-interrupted test) and later to abort it after four to ve minutes or as per needed. Further, it restarts the browser and repeats the process for at least ten times or per required, for each web page, browsers, servers, etc. Finally, when the process is completed it terminates the operation.

3.3.4

Web-servers

We used Apache 2.2.12 web server using Ubuntu operating system, and MicrosoftIIS 5.1 using windows XP (service pack3) operating system.

3.3.5

Clients

We used windows XP(service pack3) operating system on client end.

3.3.6

Browsers

Internet Explorer 8 (supports persistence connection only), Firefox 3.6 (supports persistence connection & pipelining optional), Google Chrome 4.1.249.1042 (supports persistence connection only), Opera 10.51 (supports persistence connection & Pipelining). Further we disabled all the history and caching options so that each time a web page was accessed, it acted as if it was the rst time.

3.3.7

Router

We used NETGEAR WGR614 Wireless-G Router (IEEE 802.11b, IEEE 802.11g) for our experiments. The router security used WPA-PSK [TKIP] technique and the default MTU size was 1500. This router supports both wired (100Mbps) and wireless LAN (54Mbps).

3.3.8

Web Pages

We used a simple text editor to design three web pages with only a specic type of data i.e, A web page that only contains text, the second one consisted of a picture in JPEG format and a vidoe based web page. The snapshot of these web pages is shown below in gures 3.3,3.4 and 3.5.

16

17
Figure 3.3: Snapshot of Picture based web Page.

18
Figure 3.4: Snapshot of Text based web Page.

19
Figure 3.5: Snapshot of Video based web Page.

Chapter 4

Results and Analysis

This chapter represents the results from the packet capture les gathered using Wireshark network analyzer. Dierent tools were used to analyze the stats of resets in a typical TCP transmission ow in the experiments and the capture les were later analyzed manually to study the behaviour of resets. First the stats of resets are provided to elaborate the amount of resets in our experiments. Further we move on to dierentiate and categorize the types of resets in these tests from the capture les and later in the end we will try to establish a relation for the QoE using resets as a parameter.

4.1

Statistical Analysis for Reset Packets

The initial tests were carried out without any user interruption. The table 4.1 represents the results while accessing the web pages uploaded on dierent servers. As these tests were without any user interruption, hence we can conclude that all the resets were due to any fault in networks hardware or due to faulty software implementations in client, server or network equipment. Further from the studies in the past we had come to know that Internet Explorer always closes the port with a reset which can be observed from the stats. Internet Explorer generates a reset each time the web page is accessed and twice while accessing a video based website, which is not the proper termination process. The rest of the browsers did not generate any reset packet specically in tcp transmission process and closed the connection gently using a nish and acknowledgement packet.Hence the majority of reset packets in this scenario are due to browsers themselves specically Internet Explorer. Further we might conclude for the time being that the reset of the resets are due to abnormal behavior of network hardware equipment which will be discussed in detail in packet capture le analysis. The table 4.2 represents the results of reset packets generated with user interruption while accessing the same web pages in same number. In the tests we noticed a large increase in rests with all the browsers. We observed that in user interrupted tests the browsers gave rise to resets, approximately twice or equal the reload times. As in the case of Internet Explorer8 and Firefox the rests were approximately twice the times the pages were reloaded whereas

20

Br wser o /Server

Apache Picture Text

Video

Picture

Text

IIS Video

IE FF

10 0

10 0

23 0

11 4

10 4

GC

0 (towards the router) when idle /1 (from router) 10

OP

To al t Resets per web page

0 4* (towards the router) when idle /1 (from router) 10

0 4* (towards the router) when idle

0 0

23

15

0 4* (towards the router) when idle /1 (from router) 14

30 /1(from server end) 0 0

Total Browsers Reset Packets 94 8

0 16

31

Table 4.1: The amount of resets generated without user interruption

Br wsers o /Servers

Apache Picture Text

Video

Picture

Text

IIS Video

IE FF GC

21 21 10 4* (towards the router) when idle /1 (from router) 66

OP

To al t Resets per web page

20 21 11 11 2* (towards the router) when idle /1 (from router) 65

40 11 10 11 4* (towards the router) when idle

21 20 11 10

20 20 10 10

72

66

60

45 10 10 11 4* (towards the router) when idle /1 (from router) 80

Total Browsers Reset Packets 166 103 62 77

Table 4.2: The amount of resets generated with user interruption.

21

in Google Chrome and Opera the resets were approximately the same as the number of times the pages were reloaded. Trends shown in gures 4.1 and 4.2 gives a clear picture of the dierence of number of resets generated with and without user interruption on the base of browsers and web page types. These graphs also showed us that improper tcp implementations in Internet Explore give rise to almost four times more resets (in user interrupted tests) in video based web sites as compared to any other browser. In the graph we see that Internet Explorer has the maximum amount of 166 resets generated in a total of 60 repetitions with dierent web pages and servers. Further we have compared the percentage contribution of dierent network devices, browsers and web pages in interrupted and uninterrupted tcp ows in charts 4.3, 4.4 and 4.5.
300 166 250
200

150 103 100

50

User interrupted 77 62
19

94

User Uninterrupted

8 0 Internet Explorer 8

0 Opera

Mozilla Firefox Google Chrome

Figure 4.1: Resets Pattern on the bases of Browser types.

250 152 200 125 150 User Interrupted Tests

100

132

User Uninterrupted Tests 54

50

24

25

Text web page

Picture Web Page

Video Web Page

Figure 4.2: Resets Pattern on the bases of Web Page types.

4.2

Packet Capture les analysis

The main purpose of the study was to focus on whether or not we can devise a way to dierentiate between the resets due to users and those due to faulty network elements. We also wanted to explore if we can use these resets as a parameter to measure user dissatisfaction of a particular network. Hence, each 22

Uninterrupted

28%

24%

Picture Web page Text Web page Video Web page 48%

Interrupted

38%

31% Picture Web page Text Web page Video Web page 31%

Figure 4.3: Web pages Trends in TCP Resets.

Uninterrupted

0% 7%

16%

Internet Explorer 8 Mozilla Firefox 77% Google Chrome Opera

Interrupted

15% 40% 20% Internet Explorer 8 Mozilla Firefox Google Chrome 25% Opera

Figure 4.4: Browser Contribution in TCP Resets.

23

Uninterrupted

1% 2%

Browsers Router Server 97%

Interrupted

1%

0%

28% User Browsers 71% Router Server

Figure 4.5: Network Devices/Users contribution in Resets.

reset has to be studied independently and closely analyzed, the conditions under which they occur and then compared with those occurred in the other tests. Further in this section we will eliminate the resets due to server or network devices and consider mainly resets generated by the browsers. Hence grouping similar types and the resets which occurred in a similar sequence in dierent browsers, to narrow down our research and nd the indications of resets only occurring due to users.

4.2.1

User Uninterrupted Tests

Initially the resets generated due to browsers and network devices should be marked or analyzed in such a way so that they can be dierentiated from those due to user interruption. It was observed from the stats that in uninterrupted tests Internet Explorer, Mozilla Firefox and Opera generated a few resets while Google Chrome was very smooth with no abnormal resets. The closing of port by a reset in a text based web page is shown in gure 4.6, which is a snapshot of wireshark analyzer showing that the source generated a reset and nishes the transmission. This reset occurred in IE every time and few times in Mozilla Firefox exactly in the same way. In this screen shot of wireshark analyzer a lter is applied to the trac analyzer to show only the GET, RST, FIN and SYN packets so that the complete web session could be understood. The abnnormal reset generated by Internet Explorer was also seen in video based web page where two resets where generated as shown in gure 4.7 but showed similar closing pattern at the end of the web session. The reset packet is showed in red colour in TCP stream in the view. The following lter was applied.

24

Filter 1: (http.request.method == GET )||(tcp.f lags.reset == 1)||(tcp.f lags.f in == 1)||(tcp.f lags.syn == 1)

Figure 4.6: One Reset Packet in Web session, accessing Text Web page using IE8.

Figure 4.7: Two Reset in Web session, accessing a video web page using IE8.

Another type of resets observed in the uninterrupted transmission was due to Opera as shown in gure 4.8. This reset was not during the web transmission of objects but was rather due to the communication between the router and the client when in idle mode. Following the tcp stream shows that the tcp port 5000 is used for Universal plug and Play, which listens for XML (eXtensible Markup Language)exchange. If we look closer to the streams, we see a lot of PSH ags which forces a receiving computer to skip its buer and push that trac straight ahead of any other trac. We also see that each port in this session is closed by a reset generated by the browser but the end of whole conversation is nished by a reset (packet number 3786) generated by the router itself. These resets are eliminated as these are local resets and are easily separable because they are generated towards a specic network device and in idle mood i.e. while no trac is being generated between the server and the client.

25

Figure 4.8: Resets due to Router while using OPERA.

4.2.2

User Interrupted Tests

In the user interrupted tests we had already noticed from the stats that in few browsers only one reset was generated which inferred that this was due to the Reload or Stop/Refresh button pressed by the user himself. Hence we rst analyze the tcp ows due to Opera and Google chrome which generated only one reset. The gure 4.9 shows the tcp ow of video based web page accessed by opera browser. The same lter (Filter 1) is used again to show only the required data. Mozilla Firefox only showed the same behavior while accessing video web page.

Figure 4.9: Reset in Web session due to user interruption while using Opera (Picture Web page).

Analyzing these packet capture les shows quiet easy for us to dierentiate between the user interrupted and uninterrupted tcp ows but it is dicult to dierentiate for those resets which occurred in Internet Explorer for all web pages and Mozilla Firefox when accessing the (Picture/text) web pages. The gure 4.10 is from the IE web session while accessing a text web page and gure 4.11 is from the web session using Mozilla Firefox as client browser while accessing a picture web page, showing two resets with red color. In Internet Explorer, the rst one is due to user interruption and the second one due to the fact that this browser always closes a port with a reset,Whereas in Mozilla 26

Figure 4.10: Resets in a Web session due to user interruption while using IE8 (text web page).

Figure 4.11: Resets in a Web session due to user interruption while using Firefox (Picture web page).

Figure 4.12: Resets in a Web session due to user interruption while using IE8 (Video Web Page).

27

Firefox, 2 resets where seen but none of them can be said to be generated by the browser, as Mozilla used 2 ports to download the total web page hence when user interrupts, two rests occur dierentiating it from those in Internet Explorer. The maximum number of resets generated during a web session was while video web page was accessed using Internet Explorer. During the 80 tests conducted using Internet Explorer to access the video web page with both the servers, the amount of resets was never less than four resets in each session as shown in gure 4.12. Hence to further clarify and constrict our research to sperate user generated and browser generated resets, we will compare the tcp ows of each of these situations having dierent types of resets in next section.

4.2.3

Comparison of TCP Flows and Ports

To further clarify the dierence between the user initiated and browser (clients browser) initiated resets, we observed the complete tcp process using a simple packet ow diagram. The gure 4.13 shows the normal or the standard process of a port being reset due to the user interruption compared with a complete un-interrupted tcp ow. The gure 4.13is divided into the user and client responses and actions on the bases of time as follows TF S = TCP ow start (Web session begins). TF E = TCP ow end (web session ends). TCS = Client Flow starts (Client request to server for data). TCE = Client Flow Ends (Client requests ends). TSS = Server Flow starts (Server responds to clients request). TSE = Server ow Ends (Server completes the transfer of requested data).
2 TF S = second TCP ow starts (May be a part of same web session or another).

As we are more interested in the end and beginning of the ow, so this can also be observed in the actual test based (ltered) tcp packet ow diagram with port and timing sequence in gure 4.14 of Opera browser while accessing a picture web page using one port and gure 4.15 of Mozilla Firefox using two ports. We have ltered our data to only SYN, ACK, RST and FIN packets. This type of reset is a clear indication of user interruption. Observing the rst two ows as shown in gures 4.14 and 4.15, we see that a normal ow is ended with FIN from the server and then the client which is actually a four way handshake but when a user interrupt is introduced in a tcp ow the port is abruptly closed with a RST packet from the client without any FIN or RST packet from the server and starts to download the same data using another port by sending another SYN packet, although the data was not yet completely transferred by the server. 28

Normal TCP Flow

User Interrupted Flow

SYN
ACK SYN+

TFS

SYN
ACK

SYN+

ACK GET
DATA ACK

ACK

TCS

GET
DATA ACK

TSS

GET

TCE

GET

A DAT

DATA

TSE
ACK
ACK

TFE

RST

FIN ACK FIN

TFE

T2FS
SYN

ACK

SYN+

ACK

Client

Server

TIME

Client

Server

Figure 4.13: Comparison of a TCP ow for a Web Session(Normal vs interrupted).

29

Uninterrupted Flow |Time | |20.292 | |20.293 | |20.296 | |20.303 | |21.600 | |36.819 | |36.894 | | | 192.168.1.4 | 192.168.1.5 | SYN |(2165) ------------------> (80) | SYN, ACK |(2165) <------------------ (80) | PSH, ACK - Len: 406 |(2165) ------------------> (80) | PSH, ACK - Len: 500 |(2165) ------------------> (80) | PSH, ACK - Len: 499 |(2165) ------------------> (80) | FIN, ACK |(2165) <------------------ (80) | FIN, ACK |(2165) ------------------> (80) |Time | |0.001 | |0.002 | |0.123 | |0.136 | |1.304 | |2.055 | |2.056 | |2.057 | |2.061 | |4.821 | |19.945 | |20.029 |

Interrupted Flow | 192.168.1.3 | 192.168.1.2 | SYN |(1235) ------------------> (80) | SYN, ACK |(1235) <------------------ (80) | PSH, ACK - Len: 406 |(1235) ------------------> (80) | PSH, ACK - Len: 500 |(1235) ------------------> (80) | RST, ACK |(1235) ------------------> (80) | SYN |(1237) ------------------> (80) | SYN, ACK |(1237) <------------------ (80) | PSH, ACK - Len: 483 |(1237) ------------------> (80) | PSH, ACK - Len: 500 |(1237) ------------------> (80) | PSH, ACK - Len: 499 |(1237) ------------------> (80) | FIN, ACK |(1237) <------------------ (80) | FIN, ACK |(1237) ------------------> (80) | | | | | | | | | | | | | | | | | | | | | | | | | |

| | | | | | | | | | | | | | |

Figure 4.14: TCP ow of Opera browser while accessing a picture web page.

30

Uninterrupted Flow |Time | |0.003 | |0.005 | |0.018 | |0.093 | |1.332 | |16.555 | |29.590 | | 192.168.1.4 | 192.168.1.5 | SYN |(2115) ------------------> (80) | SYN, ACK |(2115) <------------------ (80) | PSH, ACK - Len: 365 |(2115) ------------------> (80) | PSH, ACK - Len: 377 |(2115) ------------------> (80) | PSH, ACK - Len: 346 |(2115) ------------------> (80) | FIN, ACK |(2115) <------------------ (80) | FIN, ACK |(2115) ------------------> (80) | | | | | | | | | | | | | | | | |Time | |0.000 | |0.001 | |0.015 | |0.074 | |0.972 | |0.972 | |0.972 | |0.985 | |0.986 | |0.993 | |1.026 | |1.046 | |1.046 | |5.026 | |20.065 | |29.617 |

Interrupted Flow | 192.168.1.3 | 192.168.1.2 | SYN |(1159) ------------------> (80) | SYN, ACK |(1159) <------------------ (80) | PSH, ACK - Len: 365 |(1159) ------------------> (80) | PSH, ACK - Len: 377 |(1159) ------------------> (80) | RST, ACK |(1159) ------------------> (80) | SYN |(1160) ------------------> (80) | SYN |(1161) ------------------> (80) | SYN, ACK |(1160) <------------------ (80) | SYN, ACK |(1161) <------------------ (80) | PSH, ACK - Len: 346 |(1160) ------------------> (80) | PSH, ACK - Len: 482 |(1161) ------------------> (80) | RST, ACK |(1160) ------------------> (80) | PSH, ACK - Len: 466 |(1161) ------------------> (80) | PSH, ACK - Len: 407 |(1161) ------------------> (80) | FIN, ACK |(1161) <------------------ (80) | FIN, ACK |(1161) ------------------> (80) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Figure 4.15: Firefox using 2 ports to download the whole web page hence no reset due to browser rather both are due to the User interrupt.

31

Normal TCP Flow

Browser Interrupted Flow

SYN
ACK SYN+

TFS

SYN
ACK

SYN+

ACK GET
DATA ACK

ACK

TCS

GET
DATA ACK
GET

TSS TCE

GET

A DAT

DATA

TSE
ACK ACK FIN

FIN

AC K

TFE TFE

ACK
RST

FIN
ACK

Client

Server

TIME

Client

Server

Figure 4.16: Comparison of TCP ows for a Web session (Normal vs Browser interrupted).

32

Another comparison of normal tcp ow with browser generated reset is shown in gure 4.16 to dierentiate it from user generated resets. The dierence is visible at the end where a user interrupt generates a reset mediately after pressing the stop/refresh button whereas the browser generated reset may or may not be followed by a FIN packet. The gure 4.17 shows the tcp ow diagram comparison of a Text web page being accessed using Internet Explorer and we observer that the RST packet generated due to the browser (IE8) receives a FIN packet from the server on the same port hence dierentiating it from the interrupted one, but at the same time we see that in user interrupted ow the last RST packet which is basically due to the browser also does not have any FIN packet received from the server. Moreover in gure 4.18, shows the tcp ow of video based web page accessed by Internet Explorer, and shows 2 RST packets in an un-interrupted tcp ow which increases to four when a user interrupt is introduced. The rst reset packet is generated by the browser as soon as the main body in HTML language is received and the request for the data object is sent. This is quite similar to the standard procedure described in HTTP 1.0 but the port is closed by the server and here it is closed by the browser. Similarly when a user interrupt is introduced the port is reset by the browser three times, i.e. once initially when the request for object is sent and once after the user resets the port it again repeats the same procedure. In the end Internet Explorer again resets the port rather then closing it by a FIN packet. Hence, pressing the Refresh/Stop button once while accessing a video based web page using Internet Explorer generates 4 resets. Further a phenomena of 2 resets on the same port is also seen in the traces. Hence a very strict and complex criteria has to be implemented to extract user behavior from tcp resets. On the other hand if we revise the characteristics of Internet Explorer which we also observed in our tests, i.e.the RST packet generated by Internet Explorer is 60 seconds after the port gets idle, but this only occurred while using the Microsoft Information Server. When Apache server was used the port was closed after being idle for 15 seconds by a FIN from the server and a RST packet was generated by Internet Explorer after 5 seconds.

33

Uninterrupted Flow |Time | |0.192 | |0.193 | |0.195 | |0.614 | |0.703 | |0.705 | | 192.168.1.4 ||Time | 192.168.1.5 || | SYN ||0.081 |(1602) ------------------> (80) || | SYN, ACK ||0.082 |(1602) <------------------ (80) || | PSH, ACK - Len: 219 ||0.083 |(1602) ------------------> (80) || | PSH, ACK - Len: 206 ||2.289 |(1602) ------------------> (80) || | RST, ACK ||2.335 |(1602) ------------------> (80) || | FIN, ACK ||2.436 |(1602) <------------------ (80) || |2.436 | |37.585 | |102.962 |

interrupted Flow | 192.168.1.3 | 192.168.1.2 | SYN |(1238) ------------------> (80) | SYN, ACK |(1238) <------------------ (80) | PSH, ACK - Len: 219 |(1238) ------------------> (80) | RST, ACK |(1238) ------------------> (80) | SYN |(1239) ------------------> (80) | SYN, ACK |(1239) <------------------ (80) | PSH, ACK - Len: 328 |(1239) ------------------> (80) | PSH, ACK - Len: 206 |(1239) ------------------> (80) | RST, ACK |(1239) ------------------> (80) | | | | | | | | | | | | | | | | | | | |

Figure 4.17: TCP ow of Internet Explorer browser while accessing a Text web page.

34

Uninterrupted Flow |Time | |0.000 | |0.002 | |0.003 | |0.544 | |0.549 | |0.599 | |0.600 | |0.601 | |1.535 | |16.837 | |16.843 | | 192.168.1.4 | 192.168.1.5 | SYN |(1802) ------------------> (80) | SYN, ACK |(1802) <------------------ (80) | PSH, ACK - Len: 219 |(1802) ------------------> (80) | PSH, ACK - Len: 87 |(1802) ------------------> (80) | RST, ACK |(1802) ------------------> (80) | SYN |(1803) ------------------> (80) | SYN, ACK |(1803) <------------------ (80) | PSH, ACK - Len: 206 |(1803) ------------------> (80) | PSH, ACK - Len: 211 |(1803) ------------------> (80) | FIN, ACK |(1803) <------------------ (80) | RST, ACK |(1803) ------------------> (80) | | | | | | | | | | | | | | | | | | | | | | | | |Time | |0.000 | |0.001 | |0.001 | |0.073 | |0.076 | |0.259 | |0.260 | |0.260 | |0.914 | |1.671 | |1.816 | |1.817 | |1.817 | |1.821 | |1.823 | |1.922 | |1.923 | |1.939 | |17.780 | |22.766 |

interrupted Flow | 192.168.1.4 | 192.168.1.2 | SYN |(2047) ------------------> (80) | SYN, ACK |(2047) <------------------ (80) | PSH, ACK - Len: 219 |(2047) ------------------> (80) | PSH, ACK - Len: 86 |(2047) ------------------> (80) | RST, ACK |(2047) ------------------> (80) | SYN |(2048) ------------------> (80) | SYN, ACK |(2048) <------------------ (80) | PSH, ACK - Len: 206 |(2048) ------------------> (80) | PSH, ACK - Len: 210 |(2048) ------------------> (80) | RST, ACK |(2048) ------------------> (80) | SYN |(2049) ------------------> (80) | SYN, ACK |(2049) <------------------ (80) | PSH, ACK - Len: 310 |(2049) ------------------> (80) | PSH, ACK - Len: 202 |(2049) ------------------> (80) | RST, ACK |(2049) ------------------> (80) | SYN |(2050) ------------------> (80) | SYN, ACK |(2050) <------------------ (80) | PSH, ACK - Len: 326 |(2050) ------------------> (80) | FIN, ACK |(2050) <------------------ (80) | RST, ACK |(2050) ------------------> (80) | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

Figure 4.18: TCP ow of Internet Explorer browser while accessing a Video web page.

35

4.3

User Behaviour Extraction Using TCP Resets

Extracting user behaviour solely on tcp ow is a dicult task. Although we can conclude from the gure 4.5 that majority of the resets represent user behaviour, but to dierentiate them from other resets is a another task. As the client uses more then one port at a time, hence to discriminate each TCP ow is quite tough. Most work in the past used to extract data from HTTP headers to get a precise knowledge. D. Rossi et al used Tstat, developed by a Network Research Group at Politecnio di Torino to extract user behaviour solely on TCP resets. They dened the criteria of user interrupted tcp ows as follows Interrupted ows = (F INs RSTs ) Datas RSTC tgap 1. where tgap = tF E tSE Here we use this approach and further verify to what extent this criteria fullls the requirements of extracting user behaviour from tcp ows.

Re ets s without user interruption

Sever Browser web page

10 10 23 30 10 10 4 4

AP IE PIC AP IE TXT IIS IE VID IIS IE VID IIS IE TXT IIS IE PIC IIS FF TXT IIS FF PIC

Rossi Criteria for user interrupted Resets User Browser 0 10 0 10 10 13 20 10 0 10 0 10 0 4 0 4

Original Reason for Resets

Percentage Error

User 0 0 0 0 0 0 0 0

Browser 10 10 23 30 10 10 4 4

0 0 43.47 66.6 0 0 0 0

Table 4.3: Using D. Rossi Criteria for Uninterrupted Flows.

36

Re ets s without user interruption

Sever Browser web page

Resets with user interruption

10 10 30 4 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 10 10

IIS IE TXT IIS IE PIC IIS IE VID IIS FF PIC IIS FF TXT IIS FF VID IIS GC PIC IIS GC TXT IIS GC VID IIS OP PIC IIS OP TXT IIS OP VID AP OP PIC AP OP TXT AP OP VID AP GC PIC AP GC TXT AP GC VID AP FF PIC AP FF TXT AP FF VID AP IE PIC AP IE TXT AP IE VID

20 21 41 20 20 10 11 10 10 10 10 10 10 11 11 10 11 10 21 21 11 21 20 40

Rossi Criteria for user interrupted Resets User Browser 10 10 11 10 30 11 20 0 20 0 10 0 11 0 10 0 10 0 10 0 10 0 10 0 10 0 11 0 11 0 10 0 11 0 10 0 21 0 21 0 11 0 11 10 0 20 30 10

Original Reason for Resets

Error

User 10 11 11 20 20 10 11 10 10 10 10 10 10 11 11 10 11 10 21 21 11 11 10 10

Browser 10 10 30 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 10 10 30

0 0 46.3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 50 50

Table 4.4: Using D. Rossi Criteria for Interrupted Flows.

From the tables it is clear that D. Rossi approach provided us with a good approximation of user behaviour with 82.8% accuracy. This appraoch has been used on large scale and provided with reliable results. Still the abnormal tcp termination process of browsers will always cause uncertainty in results.

37

Chapter 5

Conclusion and Future Work

5.1 Conclusion

In this thesis we have used active tests to nd out the causes of resets in a very isolated manner. Tests were devised in scenarios in which dierent type of (data) objects e.g. text, video or picture were separately included in a single web page. Creating websites with only a single type of (data) object give us the advantage of observing tcp ports closely. An experimental setup was created using a simple client server architecture with minimum number of inter-networking elements in order to minimize the uncertainty of TCP reset causes. More than 480 repetitions were done with multiple browsers and servers in order to clarify the role of network devices and elements in generating resets. From network traces, it was analyzed that servers and network elements, such as routers, generate the least amount of tcp resets (in our experimental environment). Even when no user interruption was introduced, browsers are one of the major cause of generating TCP resets, especially Internet Explorer. Further as seen in Figure 4.12, resets generated due to video based webpage are twice as much as the text or picture based webpage although the size of each data object was almost same. On the other hand, user generated resets are always directly proportional to the number of times a site is accessed depending on the browser. A reset is caused whenever a user press the refresh, stop or follow another link before the completion of main link. This was perceived as a user dissatisfaction, but the follow link behavior cannot be considered a user dissatisfaction in every case. A possible reason for this is that nowadays, many websites are bombarded with images and multimedia objects which can delay the downloading process even if the user have high speed internet access. Hence, users tend to click quickly on a link within the main website, when they are familiar with website. Even though the users are clearly the major cause of resets observed in the experiments, still we cannot explicitly dene user dissatisfaction using tcp resets. We analyzed in the traces that the network resets would reach double its amount in a user dissatised environment as compare to a user satised environment which will still have notably less amount of resets due to network devices/faulty software. It can also be concluded by saying that, never expect a perfect log le.

38

Increase in the number of network devices, user applications and the amount of internet users will always be a source for new exceptions and one more misbehaved client/server.

5.2

Futurework

The relationship of quality of experience with quality of service is interesting and also a challenging task. We implemented an experimental setup within the available resources which can be extended to large number of repetitions, network elements, web pages and web browsers. A stepwise testing moving from isolated environments to more complex environments can lead to interesting results. ISPs and research organizations can also try to devise a relation between the number of ports being used and the number of ports reset, to dene a threshold value of resets in a user satised network.

39

Bibliography
[1] Hypertext transfer protocol - http/1.0, RFC 1945, IETF, 1995. [2] J. Shaikh, M. Fiedler, and D. Collange, Quality of experience from user and network perspectives, Annals of Telecommunications, vol. 65, pp. 4757, 2010. [3] K. Thompson, G. Miller, and R. Wilder, Wide-area internet trac patterns and characteristics, Network, IEEE, vol. 11, no. 6, pp. 10 23, Dec. 1997. [4] C. Fraleigh, S. Moon, B. Lyles, C. Cotton, M. Khan, D. Moll, R. Rockell, T. Seely, and S. Diot, Packet-level trac measurements from the sprint IP backbone, Network, IEEE, vol. 17, no. 6, pp. 6 16, december 2003. [5] C. Williamson, Internet trac measurement, Internet Computing, IEEE, vol. 5, no. 6, pp. 70 74, Dec. 2001. [6] C. Labovitz, S. Iekel-Johnson, D. McPherson, J. Oberheide, F. Jahanian, and M. Karir, ATLAS, Internet Observatory. Annual Report, 2009. [Online]. Available: http://www.pcmag.com/encyclopedia\ term/0,2542, t=QoE&i=57607,00.asp/ [7] ITU-T G.1010: End-user multimedia QoS [8] E. Casilari, A. Reyes-Lecuona, F. Gonzalez, A. Diaz-Estrella, and F. Sandoval, Characterisation of web trac, in Global Telecommunications Conference, 2001. GLOBECOM 01. IEEE, vol. 3, 2001, pp. 1862 1866 vol.3. [9] W. Leland, M. Taqqu, W. Willinger, and D. Wilson, On the self-similar nature of ethernet trac (extended version), Networking, IEEE/ACM Transactions, vol. 2, no. 1, pp. 1 15, Feb. 1994. [10] M. Crovella and A. Bestavros, Self-similarity in world wide web trac: evidence and possible causes, Networking, IEEE/ACM Transactions on, vol. 5, no. 6, pp. 835 846, Dec. 1997. [11] Congestion control in IP/TCP, 1984, RFC 896, IETF. [12] V. Jacobson, Congestion avoidance and control, SIGCOMM Comput. Commun. Rev., vol. 18, pp. 314329, August 1988. [Online:Varied June, 2010]. Available: http://doi.acm.org/10.1145/52325.52356 40

[13] M. R. N. Chen, C.Mangrulkar and M. Sarkar, Trends in TCP/IP retransmissions and resets, technical Report. [Online:Varied June, 2010]. Available: http://www.cse.ucsd.edu/classes/wi01/cse222/projects/ reports/tcp-ags-13.pdf [14] M. Arlitt and C. Williamson, An analysis of TCP reset behaviour on the internet, SIGCOMM Comput. Commun. Rev., vol. 35, pp. 3744, January 2005. [15] S. Khirman and P. Henriksen, Relationship between quality-of-service and quality-of-experience for public internet service, in In Proc. of the 3rd Workshop on Passive and Active Measurement., Fort Collins, Colorado, USA, March 2002. [Online:Varied June, 2010]. Available: http://www.pamconf.net/2002/Relationship Between QoS and QoE.pdf/ [16] E. Ibarrola, F. liberal, I. Taboada, and R. Ortega, Web QoE evaluation in multi-agent networks: Validation of ITU-T G.1030, in Proceedings of the 2009 Fifth International Conference on Autonomic and Autonomous Systems, 2009, pp. 289294. [17] High performance in the age of customer centricity, Accenture Customer Satisfaction Survey, 2008. [Online:Varied June, 2010]. Available: http://www.accenture.com/Global/Consulting/ Customer Relationship Mgmt/R and I/Accenture2008Survey.html/ [18] Cisco internetworking technology handbook: Chapter 49.QoS Networking. [Online:Varied June, 2010]. Available: http://docwiki.cisco.com/ wiki/Quality of Service Networking/ [19] ITU-T X.902: Inf ormation technology open distributed processing ref erence model. [20] QoE Denition. [Online:Varied June, 2010]. Available: http: //www.pcmag.com/encyclopedia term/0,2542,t=QoE&i=57607,00.asp/ [21] D. Lopez, F. Gonzalez, L. Bellido, and A. Alonso, Adaptive multimedia streaming over IP based on customer oriented metrics, in Computer Networks, 2006 International Symposium on, 2006, pp. 185 191. [22] Quality of experience (QoE) of mobile services: Can it be measured and improved? White Paper, Nokia Networks Coporation, October 2004. [Online:Varied June, 2010]. Available: http://www.nokia.com/NOKIA COM 1/About Nokia/Press/ White Papers/pdf les/whitepaper qoe net.pdf [23] Delivering optimal quality of experience (QoE) for IPTV success. Spirent: White Paper, Febuary 2006. [Online:Varied June, 2010]. Available: http://www.robinsconsult.com/uploads/IPTV Whitepaper FINAL.pdf

41

[24] Using network intelligence to provide carrier-grade VoIP. Sandvine: White paper. [25] Transmission control protocol introduction, RFC 793, September 1981. [26] Inappropriate TCP resets, RFC 3360, August 2002. [27] V. N. Padmanabhan and J. C. Mogul, Improving http latency, Comput. Netw. ISDN Syst., vol. 28, pp. 2535, December 1995. [28] J. Touch, J. Heidemann, and K. Obraczka, Analysis of http performance, August 1996. [Online:Varied June, 2010]. Available: http://www.isi.edu/lsam/publications/http-perf [29] Hypertext transfer protocol - HTTP/1.1, RFC 2068, IETF, January 1997. [30] B. Krishnamurphy, J. C. Mogul, and D. M. Kristol, Key dierences between http/1.0 and http/1.1, in Proceedings of the eighth international conference on World Wide Web, ser. WWW 99, 1999, pp. 17371751. [31] M. Nabe and M. M. H. Miyahara, Analysis and modeling of world wide web trac for capacity dimensioning of internet access lines, Perform. Eval., vol. 34, pp. 249271, December 1998. [32] Wusage web server log analysis software, [Online:Varied June, 2010]. Available: http://www.boutell.com [33] T. M. Kroeger, D. D. E. Long, and J. C. Mogul, Exploring the bounds of web latency reduction from caching and prefetching, in Proceedings of the USENIX Symposium on Internet Technologies and Systems on USENIX Symposium on Internet Technologies and Systems, 1997, pp. 22. [34] V. N. Padmanabhan and J. C. Mogul, Improving http latency, Comput. Netw. ISDN Syst., vol. 28, pp. 2535, December 1995. [35] F. Douglis, A. Feldmann, B. Krishnamurthy, and J. Mogul, Rate of change and other metrics: a live study of the world wide web, in Proceedings of the USENIX Symposium on Internet Technologies and Systems on USENIX Symposium on Internet Technologies and Systems. Berkeley, CA, USA: USENIX Association, 1997, pp. 1414. [36] S. Manley and M. Seltzer, Web facts and fantasy, in Proceedings of the USENIX Symposium on Internet Technologies and Systems on USENIX Symposium on Internet Technologies and Systems. Berkeley, CA, USA: USENIX Association, 1997, pp. 1212. [37] M. Arlitt and C. Williamson, Internet web servers: workload characterization and performance implications, Networking, IEEE/ACM Transactions on, vol. 5, no. 5, pp. 631 645, Oct. 1997.

42

[38] E. Cohen, B. Krishnamurthy, and J. Rexford, Improving end-to-end performance of the web using server volumes and proxy lters, in Proceedings of the ACM SIGCOMM 98 conference on Applications, technologies, architectures, and protocols for computer communication, ser. SIGCOMM 98. New York, NY, USA: ACM, 1998, pp. 241253. [39] P. Barford and M. Crovella, Generating representative web workloads for network and server performance evaluation, SIGMETRICS Perform. Eval. Rev., vol. 26, pp. 151160, June 1998. [40] H. Abrahamsson and B. Ahlgren, Using empirical distributions to characterize web client trac and to generate synthetic trac, in Global Telecommunications Conference, 2000. GLOBECOM 00. IEEE, vol. 1, 2000, pp. 428 433 vol.1. [41] A. Feldmann, Blt: Bi-layer tracing of http and tcp, Comput. Network., vol. 33, pp. 321335, June 2000. [42] M. Molina, P. Castelli, and G. Foddis, Web trac modeling exploiting tcp connections temporal clustering through html-reduce, Network, IEEE, vol. 14, no. 3, pp. 46 55, June 2000. [43] D. Rossi, M. Mellia, and C. Casetti, User patience and the web: a hands-on investigation, in Global Telecommunications Conference, 2003. GLOBECOM 03. IEEE, vol. 7, december 2003, pp. 4163 4168 vol.7. [44] D. Tran, W. Ooi, and Y. Tay, Sax: A tool for studying congestion-induced surfer behavior, PAM, 2006. [Online:Varied June, 2010]. Available: http://www.news.cs.nyu.edu/trandinh/publications/sax.pdf [45] Usage share of web browsers, [Online:Varied June, 2010]. Available: http://en.wikipedia.org/wiki/Usage share of web browsers [46] Browser Statistics, [Online:Varied June, 2010]. Available: //www.w3schools.com/browsers/browsers-stats.asp http:

[47] OS Platform Statistics, [Online:Varied June, 2010]. Available: http: //www.w3schools.com/browsers/browsers os.asp [48] Usage share of operating systems, [Online:Varied June, 2010]. Available: http://en.wikipedia.org/wiki/Usage share of operating-systems [49] Web server survey, [Online:Varied June, 2010]. Available: //news.netcraft.com/archives/category/web-server-survey/ [50] Market structure, [Online:Varied June, //en.wikipedia.org/wiki/Web server 2010]. Available: http: http:

[51] C. Sanders, Practical Packet Analysis:Using Wireshark to Solve RealWorld Network Problems,2007. includeAppendix 43

Appendix A

Appendix
A.1 Network Trace les

Due to huge amount of traces we have included only the rst web session of each type of test.(Actually 10 repetitions of each test was taken). The traces are ltered using the same Filter 1, as dened before in section 4.2.1.

A.1.1

Uninterrupted TCP Flows

|Time | |0.003 | |0.005 | |0.018 | |0.093 | |1.332 | |16.555 | |29.590 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: kdm > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(2115) ------------------> (80) | | TCP: http > kdm [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2115) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2115) ------------------> (80) | | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1 |(2115) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2115) ------------------> (80) | | TCP: http > kdm [FIN, ACK] |Seq=1162431 Ack=1089 Win=8576 Len=0 |(2115) <------------------ (80) | | TCP: kdm > http [FIN, ACK] |Seq=1089 Ack=1162432 Win=17018 Len=0 |(2115) ------------------> (80) |
Figure A.1: Apache Firefox Picture Web Page.

44

|Time | |30.984 | |30.986 | |31.016 | |31.060 | |45.555 | |45.562 |

| 192.168.1.4 | 192.168.1.5 | TCP: unisql-java > http [SYN] |(1979) ------------------> (80) | TCP: http > unisql-java [SYN, ACK] |(1979) <------------------ (80) | GET / HTTP/1.1 |(1979) ------------------> (80) | GET /favicon.ico |(1979) ------------------> (80) | TCP: unisql-java > http [FIN, ACK] |(1979) ------------------> (80) | TCP: http > unisql-java [FIN, ACK] |(1979) <------------------ (80)

| | | Seq=0 Win=16384 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=712 Ack=4543 Win=17520 Len=0 | |Seq=4543 Ack=713 Win=7504 Len=0 |

Figure A.2: Apache Firefox Text Web Page.

|Time | |0.000 | |0.002 | |0.018 | |0.113 | |0.998 | |16.195 | |29.587 |

| 192.168.1.4 | 192.168.1.5 | TCP: fiorano-msgsvc > http [SYN] |(1856) ------------------> (80) | TCP: http > fiorano-msgsvc [SYN, ACK] |(1856) <------------------ (80) | GET / HTTP/1.1 |(1856) ------------------> (80) | GET /favicon.ico |(1856) ------------------> (80) | GET /htmlexample. |(1856) ------------------> (80) | TCP: http > fiorano-msgsvc [FIN, ACK] |(1856) <------------------ (80) | TCP: fiorano-msgsvc > http [FIN, ACK] |(1856) ------------------> (80)

| | |Seq=0 Win=16384 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET /htmlexample.mpeg HTTP/1.1 | | Seq=107117 Ack=1123 Win=8576 Len=0 | | Seq=1123 Ack=107118 Win=17520 Len=0 |

Figure A.3: Apache Firefox Video Web Page.

45

|Time | |63.658 | |63.660 | |63.660 | |63.675 | |65.398 | |80.734 | |85.460 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: nbx-dir > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2096) ------------------> (80) | | TCP: http > nbx-dir [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 |(2096) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2096) ------------------> (80) | | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1 |(2096) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2096) ------------------> (80) | | TCP: http > nbx-dir [FIN, ACK] |Seq=1162431 Ack=1104 Win=9088 Len=0 |(2096) <------------------ (80) | | TCP: nbx-dir > http [FIN, ACK] | Seq=1104 Ack=1162432 Win=64284 Len=0 |(2096) ------------------> (80) |

Figure A.4: Apache Google Chrome Video Web Page.

|Time | |0.000 | |0.009 | |0.010 | |0.044 | |15.318 | |15.318 | |20.049 |

| 192.168.1.4 | 192.168.1.5 | TCP: 2194 > http [SYN] |(2194) ------------------> (80) | TCP: http > 2194 [SYN, ACK] |(2194) <------------------ (80) | GET / HTTP/1.1 |(2194) ------------------> (80) | GET /favicon.ico |(2194) ------------------> (80) | TCP: http > 2194 [FIN, ACK] |(2194) <------------------ (80) | TCP: http > 2194 [FIN, ACK] |(2194) <------------------ (80) | TCP: 2194 > http [FIN, ACK] |(2194) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=4543 Ack=741 Win=8000 Len=0 | |Seq=4543 Ack=741 Win=8000 Len=0 | | Seq=741 Ack=4544 Win=65536 Len=0 |

Figure A.5: Apache Google Chrome Text Web Page.

46

|Time | |0.000 | |0.002 | |0.003 | |0.700 | |0.701 | |0.703 | |0.703 | |15.834 | |15.835 | |20.714 | |20.714 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: rimf-ps > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2209) ------------------> (80) | | TCP: http > rimf-ps [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 |(2209) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2209) ------------------> (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(2209) ------------------> (80) | | TCP: noaaport > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2210) ------------------> (80) | | TCP: http > noaaport [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 |(2210) <------------------ (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2210) ------------------> (80) | | TCP: http > noaaport [FIN, ACK] |Seq=504 Ack=333 Win=6912 Len=0 |(2210) <------------------ (80) | | TCP: http > rimf-ps [FIN, ACK] |Seq=106615 Ack=776 Win=8000 Len=0 |(2209) <------------------ (80) | | TCP: noaaport > http [FIN, ACK] |Seq=333 Ack=505 Win=65032 Len=0 |(2210) ------------------> (80) | | TCP: rimf-ps > http [FIN, ACK] |Seq=776 Ack=106616 Win=64520 Len=0 |(2209) ------------------> (80) |

Figure A.6: Apache Google Chrome Video Web Page.

|Time | |0.000 | |0.005 | |0.005 | |0.484 | |1.772 | |16.788 | |21.772 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: msync > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460 |(2072) ------------------> (80) | | TCP: http > msync [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2072) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2072) ------------------> (80) | | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1 |(2072) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2072) ------------------> (80) | | TCP: http > msync [FIN, ACK] |Seq=1162431 Ack=687 Win=8576 Len=0 |(2072) <------------------ (80) | | TCP: msync > http [RST, ACK] | Seq=687 Ack=1162432 Win=0 Len=0 |(2072) ------------------> (80) |

Figure A.7: Apache Internet Explorer Picture Web Page.

47

|Time | |11.408 | |11.409 | |11.409 | |12.024 | |27.301 | |32.017 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: submitserver > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(2028) ------------------> (80) | | TCP: http > submitserver [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2028) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2028) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2028) ------------------> (80) | | TCP: http > submitserver [FIN, ACK] | Seq=4543 Ack=426 Win=7504 Len=0 |(2028) <------------------ (80) | | TCP: submitserver > http [RST, ACK] |Seq=426 Ack=4544 Win=0 Len=0 |(2028) ------------------> (80) |

Figure A.8: Apache Internet Explorer Picture Text Page.

|Time | |0.000 | |0.002 | |0.003 | |0.544 | |0.549 | |0.599 | |0.600 | |0.601 | |1.535 | |16.837 | |16.843 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: concomp1 > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1802) ------------------> (80) | | TCP: http > concomp1 [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(1802) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1802) ------------------> (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(1802) ------------------> (80) | | TCP: concomp1 > http [RST, ACK] |Seq=307 Ack=1940 Win=0 Len=0 |(1802) ------------------> (80) | | TCP: hp-hcip-gwy > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1803) ------------------> (80) | | TCP: http > hp-hcip-gwy [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(1803) <------------------ (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1803) ------------------> (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(1803) ------------------> (80) | | TCP: http > hp-hcip-gwy [FIN, ACK] |Seq=106639 Ack=418 Win=7504 Len=0 |(1803) <------------------ (80) | | TCP: hp-hcip-gwy > http [RST, ACK] |Seq=418 Ack=106640 Win=0 Len=0 |(1803) ------------------> (80) |

Figure A.9: Apache Internet Explorer Video Web Page.

48

|Time | |20.292 | |20.293 | |20.296 | |20.303 | |21.600 | |36.819 | |36.894 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: x-bone-api > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(2165) ------------------> (80) | | TCP: http > x-bone-api [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2165) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2165) ------------------> (80) | | GET /WorldMap.jpg H |HTTP: GET /WorldMap.jpg HTTP/1.1 |(2165) ------------------> (80) | | GET /favicon.ico HT |HTTP: GET /favicon.ico HTTP/1.1 |(2165) ------------------> (80) | | TCP: http > x-bone-api [FIN, ACK] |Seq=1162431 Ack=1406 Win=8576 Len=0 |(2165) <------------------ (80) | | TCP: x-bone-api > http [FIN, ACK] |Seq=1406 Ack=1162432 Win=17018 Len=0 |(2165) ------------------> (80) |
Figure A.10: Apache Opera Picture Web Page.

|Time | |0.279 | |0.281 | |0.290 | |0.300 | |15.515 | |15.598 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: eye2eye > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1948) ------------------> (80) | | TCP: http > eye2eye [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(1948) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1948) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1948) ------------------> (80) | | TCP: http > eye2eye [FIN, ACK] |Seq=4543 Ack=906 Win=7504 Len=0 |(1948) <------------------ (80) | | TCP: eye2eye > http [FIN, ACK] |Seq=906 Ack=4544 Win=17520 Len=0 |(1948) ------------------> (80) |
Figure A.11: Apache Opera Text Web Page.

49

|Time | |0.286 | |0.288 | |0.294 | |0.300 | |1.689 | |16.814 | |16.915 | |18.336 |

| 192.168. | | 192.168.1.5 | | TCP: sugp > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1905) ------------------> (80) | | TCP: http > sugp [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(1905) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1905) ------------------> (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(1905) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1905) ------------------> (80) | | TCP: http > sugp [FIN, ACK] | Seq=107117 Ack=1410 Win=8576 Len=0 |(1905) <------------------ (80) | | TCP: sugp > http [FIN, ACK] |Seq=1410 Ack=107118 Win=17018 Len=0 |(1905) ------------------> (80) | | TCP: sugp > http [FIN, ACK] | Seq=1410 Ack=107118 Win=17018 Len=0 |(1905) ------------------> (80) |
Figure A.12: Apache Opera Video Web Page.

50

|Time | |1.910 | |1.914 | |1.915 | |1.929 | |4.272 | |5.351 | |5.355 | |5.355 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: pptp > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1723) ------------------> (80) | | TCP: http > pptp [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 |(1723) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1723) ------------------> (80) | | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1 |(1723) ------------------> (80) | | HTTP: [TCP Retransmission] | GET /WorldMap.jpg HTTP/1.1 |(1723) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1723) ------------------> (80) | | TCP: pptp > http [FIN, ACK] | Seq=1089 Ack=1166062 Win=16237 Len=0 |(1723) ------------------> (80) | | TCP: http > pptp [FIN, ACK] | Seq=1166062 Ack=1089 Win=16432 Len=0 |(1723) <------------------ (80) |
Figure A.13: Microsoft IIS Firefox Picture Web Page.

51

|Time | |1.230 | |1.231 | |1.231 | |1.465 | |1.538 | |1.538 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: svs-omagent > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460 |(1625) ------------------> (80) | | TCP: http > svs-omagent [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 |(1625) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1625) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1625) ------------------> (80) | | TCP: svs-omagent > http [FIN, ACK] | Seq=712 Ack=14241 Win=16237 Len=0 |(1625) ------------------> (80) | | TCP: http > svs-omagent [FIN, ACK] | Seq=14241 Ack=712 Win=16809 Len=0 |(1625) <------------------ (80) |
Figure A.14: Microsoft IIS Firefox Text Web Page.

|Time | 192.168.1.4 | | | 192.168.1.5 | |9.428 |TCP: payrouter > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 | |(1246) ------------------> (80) | |9.627 |TCP: http > payrouter [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |(1246) <------------------ (80) | |9.629 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 | |(1246) ------------------> (80) | |9.669 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 | |(1246) ------------------> (80) | |9.674 TCP: payrouter > http [FIN, ACK] | Seq=712 Ack=4667 Win=16237 Len=0 | |(1246) ------------------> (80) | |9.675 |TCP: http > payrouter [FIN, ACK] |Seq=4667 Ack=712 Win=16809 Len=0 | |(1246) <------------------ (80) |
Figure A.15: Microsoft IIS Firefox Video Web Page.

52

|Time | |0.000 | |0.119 | |0.120 | |0.125 | |0.126 |

| 192.168.1.4 | | 192.168.1.5| | TCP: directplay > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2234) ------------------> (80) | | TCP:http > directplay [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 |(2234) <------------------ (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2234) ------------------> (80) | | HTTP/1.1 404 Object |HTTP: HTTP/1.1 404 Object Not Found (text/html) |(2234) <------------------ (80) | | TCP: directplay > http [FIN, ACK] |Seq=333 Ack=4205 Win=64252 Len=0 |(2234) ------------------> (80) |

Figure A.16: Microsoft IIS Google Chrome Video Web Page.

|Time | |0.200 | |0.201 | |0.202 | |0.236 | |0.243 | |0.244 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: mmcal > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2272) ------------------> (80) | | TCP: http > mmcal [SYN,ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 |(2272) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2272) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2272) ------------------> (80) | | TCP: mmcal > http [FIN,ACK] |Seq=741 Ack=5478 Win=64252 Len=0 |(2272) ------------------> (80) | | TCP: http > mmcal [FIN,ACK] |Seq=5478 Ack=741 Win=16780 Len=0 |(2272) <------------------ (80) |

Figure A.17: Microsoft IIS Google Chrome Text Web Page.

53

|Time | |0.000 | |0.250 | |0.277 | |0.279 | |0.279 | |1.086 | |1.087 | |1.209 | |1.296 | |240.515 | |240.516 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: njenet-ssl > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2252) ------------------> (80) | | TCP: dtv-chan-req > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 |(2253) ------------------> (80) | | http > njenet-ssl |TCP:http >0njenet-ssl [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=146 WS=0 |(2252) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2252) ------------------> (80) | | http > dtv-chan-req |TCP:http>dtv-chan-req [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=146 0 WS=0 |(2253) <------------------ (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(2252) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2253) ------------------> (80) | | HTTP/1.1 404 Object |HTTP: HTTP/1.1 404 Object Not Found (text/html) |(2253) <------------------ (80) | | TCP: dtv-chan-req > http [FIN, ACK] | Seq=333 Ack=4205 Win=64252 Len=0 |(2253) ------------------> (80) | | TCP: njenet-ssl > http [FIN, ACK] |Seq=776 Ack=106746 Win=64766 Len=0 |(2252) ------------------> (80) | | TCP: http > njenet-ssl [FIN, ACK] | Seq=106746 Ack=777 Win=16745 Len=0 |(2252) <------------------ (80) |

Figure A.18: Microsoft IIS Google Chrome Video Web Page.

|Time | |15.347 | |15.348 | |15.350 | |15.719 | |17.265 | |17.269 | |17.270 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: kmscontrol > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460 |(1773) ------------------> (80) | | TCP: http > kmscontrol [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 |(1773) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1773) ------------------> (80) | | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1 |(1773) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1773) ------------------> (80) | | TCP: kmscontrol > http [RST, ACK] | Seq=687 Ack=1164779 Win=0 Len=0 |(1773) ------------------> (80) | | TCP: http > kmscontrol [FIN, ACK] | Seq=1166062 Ack=687 Win=16834 Len=0 |(1773) <------------------ (80) |

Figure A.19: Microsoft IIS Internet Explorer Picture Web Page.

54

|Time | |0.192 | |0.193 | |0.195 | |0.614 | |0.703 | |0.705 |

| 192.168.1.4 | 192.168.1.5 | TCP: inspect > http [SYN] |(1602) ------------------> (80) | TCP: http > inspect [SYN,ACK] |(1602) <------------------ (80) | GET / HTTP/1.1 |(1602) ------------------> (80) | GET /favicon.ico |(1602) ------------------> (80) | TCP: inspect > http [RST,ACK] |(1602) ------------------> (80) | TCP: http > inspect [FIN,ACK] |(1602) <------------------ (80)

| | | Seq=0 Win=16384 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | HTTP: GET /favicon.ico HTTP/1.1 | | Seq=426 Ack=11498 Win=0 Len=0 | | Seq=14241 Ack=426 Win=17095 Len=0 |

Figure A.20: Microsoft IIS Internet Explorer Picture Text Page.

|Time | |0.373 | |0.375 | |0.375 | |2.789 | |3.344 | |3.549 | |3.650 | |3.656 | |3.661 |

| 192.168.1.4 | 192.168.1.5 | TCP: asci-val > http [SYN] |(1560) ------------------> (80) | TCP: http > asci-val [SYN, ACK] |(1560) <------------------ (80) | GET / HTTP/1.1 |(1560) ------------------> (80) | GET /htmlexample. |(1560) ------------------> (80) | TCP: asci-val > http [RST, ACK] |(1560) ------------------> (80) | TCP: facilityview > http [SYN] |(1561) ------------------> (80) | TCP: http > facilityview [SYN, ACK] |(1561) <------------------ (80) | GET /favicon.ico |(1561) ------------------> (80) | TCP: facilityview > http [RST, ACK] |(1561) ------------------> (80)

| | |Seq=0 Win=16384 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlexample.mpeg HTTP/1.1 | | Seq=307 Ack=3384 Win=0 Len=0 | |Seq=0 Win=16384 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=207 Ack=1461 Win=0 Len=0 |

Figure A.21: Microsoft IIS Internet Explorer Video Web Page.

55

|Time | |45.485 | |45.487 | |45.487 | |45.491 | |47.187 | |47.638 | |47.739 |

| 192.168.1.4 | 192.168.1.5 | TCP: rsvp-encap-2 > http [SYN] |(1699) ------------------> (80) | TCP: http > rsvp-encap-2 [SYN, ACK] |(1699) <------------------ (80) | GET / HTTP/1.1 |(1699) ------------------> (80) | GET /WorldMap.jpg |(1699) ------------------> (80) | GET /favicon.ico |(1699) ------------------> (80) | TCP: http > rsvp-encap-2 [FIN, ACK] |(1699) <------------------ (80) | TCP: rsvp-encap-2 > http [FIN, ACK] |(1699) ------------------> (80)

| | |Seq=0 Win=16384 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=1166062 Ack=1406 Win=16115 Len=0 | | Seq=1406 Ack=1166063 Win=16237 Len=0 |

Figure A.22: Microsoft IIS Opera Picture Web Page.

56

|Time | |0.797 | |0.798 | |0.798 | |0.813 | |0.818 | |0.919 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: netview-aix-12 > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460 |(1672) ------------------> (80) | | TCP: http > netview-aix-12 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 |(1672) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1672) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1672) ------------------> (80) | | TCP: http > netview-aix-12 [FIN, ACK] | Seq=14241 Ack=906 Win=16615 Len=0 |(1672) <------------------ (80) | | TCP: netview-aix-12 > http [FIN, ACK] | Seq=906 Ack=14242 Win=16237 Len=0 |(1672) ------------------> (80) |
Figure A.23: Microsoft IIS Opera Text Web Page.

57

|Time | |0.646 | |0.647 | |0.647 | |0.654 | |1.798 | |1.804 | |2.211 |

| 192.168.1.4 | | 192.168.1.5 | | TCP: pip > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460 |(1321) ------------------> (80) | | TCP: http > pip [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 |(1321) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(1321) ------------------> (80) | | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1 |(1321) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(1321) ------------------> (80) | | TCP: http > pip [FIN, ACK] |Seq=110757 Ack=1410 Win=16111 Len=0 |(1321) <------------------ (80) | | TCP: pip > http [FIN, ACK] | Seq=1410 Ack=110758 Win=16237 Len=0 |(1321) ------------------> (80) |
Figure A.24: Microsoft IIS Opera Video Web Page.

58

A.1.2

Interrupted TCP Flows

|Time | |0.000 | |0.001 | |0.015 | |0.074 | |0.972 | |0.972 | |0.972 | |0.985 | |0.986 | |0.993 | |1.026 | |1.046 | |1.046 | |5.026 | |20.065 | |29.617 |

| 192.168.1.3 | 192.168.1.2 | TCP: oracle-oms > http [SYN] |(1159) ------------------> (80) | TCP: http > oracle-oms [SYN, ACK] |(1159) <------------------ (80) | GET / HTTP/1.1 |(1159) ------------------> (80) | GET /WorldMap.jpg |(1159) ------------------> (80) | TCP: oracle-oms > http [RST, ACK] |(1159) ------------------> (80) | TCP: olsv > http [SYN] |(1160) ------------------> (80) | TCP: health-polling > http [SYN] |(1161) ------------------> (80) | TCP: http > olsv [SYN, ACK] |(1160) <------------------ (80) | TCP: http > health-polling [SYN, ACK] |(1161) <------------------ (80) | GET /favicon.ico |(1160) ------------------> (80) | GET / HTTP/1.1 |(1161) ------------------> (80) | TCP: olsv > http [RST, ACK] |(1160) ------------------> (80) | GET /WorldMap.jpg H |(1161) ------------------> (80) | GET /favicon.ico |(1161) ------------------> (80) |TCP: http > health-polling [FIN, ACK] |(1161) <------------------ (80) | TCP: health-polling > http [FIN, ACK] |(1161) ------------------> (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |Seq=743 Ack=2468246 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=146 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET / HTTP/1.1 | |Seq=347 Ack=135781 Win=0 Len=0 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=3568273 Ack=1356 Win=8576 Len=0 | | Seq=1356 Ack=3568274 Win=64558 Len=0 |

Figure A.25: Apache Firefox Picture Web Page.

59

|Time | |1.575 | |1.717 | |1.718 | |2.542 | |2.544 | |2.572 | |2.573 | |2.573 | |2.574 | |2.581 | |2.596 | |13.287 | |136.380 | |136.382 |

| 192.168.1.3 | 192.168.1.4 | TCP: x9-icue > http [SYN] |(1145) ------------------> (80) | TCP: http > x9-icue [SYN, ACK] |(1145) <------------------ (80) | GET / HTTP/1.1 |(1145) ------------------> (80) | TCP: audit-transfer > http [SYN] |(1146) ------------------> (80) | TCP: http > audit-transfer [SYN, ACK] |(1146) <------------------ (80) | TCP: x9-icue > http [RST, ACK] |(1145) ------------------> (80) | GET /favicon.ico |(1146) ------------------> (80) | TCP: capioverlan > http [SYN] |(1147) ------------------> (80) | TCP: http > capioverlan [SYN, ACK] |(1147) <------------------ (80) | GET / HTTP/1.1 |(1147) ------------------> (80) | TCP: audit-transfer > http [RST, ACK] |(1146) ------------------> (80) | GET /favicon.ico |(1147) ------------------> (80) | TCP: capioverlan > http [FIN, ACK] |(1147) ------------------> (80) | TCP: http > capioverlan [FIN, ACK] |(1147) <------------------ (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | | Seq=366 Ack=828853 Win=0 Len=0 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |Seq=347 Ack=32769 Win=0 Len=0 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=845 Ack=2804661 Win=65535 Len=0 | | Seq=2804661 Ack=846 Win=16676 Len=0 |

Figure A.26: Apache Firefox Text Web Page.

60

|Time | |0.002 | |0.003 | |0.015 | |0.084 | |0.743 | |0.745 | |0.776 | |1.723 | |1.723 | |2.195 | |17.551 | |29.599 |

| 192.168.1.4 | | 192.168.1.2 | | TCP: ias-admind > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 |(2141) ------------------> (80) | | TCP: http > ias-admind [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2141) <------------------ (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2141) ------------------> (80) | | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1 |(2141) ------------------> (80) | | TCP: tdmoip > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 |(2142) ------------------> (80) | | TCP: http > tdmoip [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 |(2142) <------------------ (80) | | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1 |(2142) ------------------> (80) | | TCP: tdmoip > http [RST, ACK] |Seq=411 Ack=1910217 Win=0 Len=0 |(2142) ------------------> (80) | | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1 |(2141) ------------------> (80) | | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1 |(2141) ------------------> (80) | | TCP: http > ias-admind [FIN, ACK] | Seq=695985 Ack=1667 Win=9648 Len=0 |(2141) <------------------ (80) | | TCP: ias-admind > http [FIN, ACK] | Seq=1667 Ack=695986 Win=65535 Len=0 |(2141) ------------------> (80) |

Figure A.27: Apache Firefox Video Web Page.

Figure A.28: Apache Google Chrome Video Web Page.

61

Figure A.29: Apache Google Chrome Text Web Page.

|Time | |0.084 | |0.085 | |0.086 | |0.915 | |0.916 | |0.918 | |0.918 | |1.340 | |1.359 | |1.369 | |1.897 | |1.897 | |2.052 | |2.053 | |2.054 | |2.056 | |2.058 | |2.059 | |2.059 | |2.059 | |17.597 | |22.591 |

| 192.168.1.4 | 192.168.1.2 | TCP: netop-school > http [SYN] |(1971) ------------------> (80) | TCP: http>netop-school[SYN, ACK] |(1971) <------------------ (80) | GET / HTTP/1.1 |(1971) ------------------> (80) | GET /htmlsample. |(1971) ------------------> (80) | TCP: intersys-cache > http [SYN] |(1972) ------------------> (80) | TCP:http>intersys-cache[SYN, ACK] |(1972) <------------------ (80) | GET /favicon.ico |(1972) ------------------> (80) | GET / HTTP/1.1 |(1972) ------------------> (80) | TCP: intersys-cache > http [FIN, ACK] |(1972) ------------------> (80) | TCP: http > intersys-cache [FIN, ACK] |(1972) <------------------ (80) | TCP: netop-school > http [FIN, ACK] |(1971) ------------------> (80) | TCP: netop-school > http [RST, ACK] |(1971) ------------------> (80) | TCP: dlsrap > http [SYN] |(1973) ------------------> (80) | TCP: http > dlsrap [SYN, ACK] |(1973) <------------------ (80) | GET /htmlsample. |(1973) ------------------> (80) | TCP: dlsrap > http [FIN, ACK] |(1973) ------------------> (80) | TCP: drp > http [SYN] |(1974) ------------------> (80) | TCP: http > dlsrap [FIN, ACK] |(1973) <------------------ (80) | TCP: http > drp [SYN, ACK] |(1974) <------------------ (80) | GET /htmlsample. |(1974) ------------------> (80) | TCP: http > drp [FIN, ACK] |(1974) <------------------ (80) | TCP: drp > http [FIN, ACK] |(1974) ------------------> (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET / HTTP/1.1 | | Seq=858 Ack=212532 Win=65326 Len=0 | | Seq=212532 Ack=859 Win=8000 Len=0 | |Seq=775 Ack=1305401 Win=1296 Len=0 | | Seq=776 Ack=1305401 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=486 Ack=192 Win=65344 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | | Seq=192 Ack=487 Win=6912 Len=0 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=1158352 Ack=430 Win=6912 Len=0 | | Seq=430 Ack=1158353 Win=65536 Len=0 |

Figure A.30: Apache Google Chrome Video Web Page.

62

|Time | |0.000 | |0.001 | |0.001 | |0.077 | |2.005 | |2.071 | |2.072 | |2.072 | |2.075 | |4.068 | |19.143 | |24.134 |

| 192.168.1.3 | 192.168.1.2 | TCP: td-postman > http [SYN] |(1049) ------------------> (80) | TCP: http > td-postman [SYN, ACK] |(1049) <------------------ (80) | GET / HTTP/1.1 |(1049) ------------------> (80) | GET /WorldMap.jpg |(1049) ------------------> (80) | TCP: td-postman > http [RST, ACK] |(1049) ------------------> (80) | TCP: cma > http [SYN] |(1050) ------------------> (80) | TCP: http > cma [SYN, ACK] |(1050) <------------------ (80) | GET / HTTP/1.1 |(1050) ------------------> (80) | GET /WorldMap.jpg |(1050) ------------------> (80) | GET /favicon.ico |(1050) ------------------> (80) | TCP: http > cma [FIN, ACK] |(1050) <------------------ (80) | TCP: cma > http [RST, ACK] |(1050) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | | Seq=481 Ack=3919119 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=2255744 Ack=895 Win=8576 Len=0 | |Seq=895 Ack=2255745 Win=0 Len=0 |

Figure A.31: Apache Internet Explorer Picture Web Page.

|Time | |0.000 | |0.002 | |0.002 | |15.184 | |20.152 | |105.173 | |105.174 | |105.174 | |105.351 | |120.368 | |125.355 |

| 192.168.1.3 | 192.168.1.2 | TCP: gpfs > http [SYN] |(1191) ------------------> (80) | TCP: http > gpfs [SYN, ACK] |(1191) <------------------ (80) | GET / HTTP/1.1 |(1191) ------------------> (80) | TCP: http > gpfs [FIN, ACK] |(1191) <------------------ (80) | TCP: gpfs > http [RST, ACK] |(1191) ------------------> (80) | TCP: caids-sensor > http [SYN] |(1192) ------------------> (80) | TCP: http > caids-sensor [SYN, ACK] |(1192) <------------------ (80) | GET /favicon.ico |(1192) ------------------> (80) | GET / HTTP/1.1 |(1192) ------------------> (80) | TCP: http > caids-sensor [FIN, ACK] |(1192) <------------------ (80) | TCP: caids-sensor > http [RST, ACK] |(1192) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |Seq=40820 Ack=220 Win=6432 Len=0 | |Seq=220 Ack=40821 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET / HTTP/1.1 | | Seq=212536 Ack=521 Win=7504 Len=0 | |Seq=521 Ack=212537 Win=0 Len=0 |

Figure A.32: Apache Internet Explorer Picture Text Page.

63

|Time | |0.000 | |0.001 | |0.001 | |0.073 | |0.076 | |0.259 | |0.260 | |0.260 | |0.914 | |1.671 | |1.816 | |1.817 | |1.817 | |1.821 | |1.823 | |1.922 | |1.923 | |1.939 | |17.780 | |22.766 |

| 192.168.1.4 | 192.168.1.2 | TCP: dls > http [SYN] |(2047) ------------------> (80) | TCP: http > dls [SYN, ACK] |(2047) <------------------ (80) | GET / HTTP/1.1 |(2047) ------------------> (80) | GET /htmlsample. |(2047) ------------------> (80) | TCP: dls > http [RST, ACK] |(2047) ------------------> (80) | TCP: dls-monitor > http [SYN] |(2048) ------------------> (80) | TCP: http > dls-monitor [SYN, ACK] |(2048) <------------------ (80) | GET /favicon.ico |(2048) ------------------> (80) | GET /htmlsample. |(2048) ------------------> (80) | TCP: dls-monitor > http [RST, ACK] |(2048) ------------------> (80) | TCP: nfs > http [SYN] |(2049) ------------------> (80) | TCP: http > nfs [SYN, ACK] |(2049) <------------------ (80) | GET / HTTP/1.1 |(2049) ------------------> (80) | GET /htmlsample. |(2049) ------------------> (80) | TCP: nfs > http [RST, ACK] |(2049) ------------------> (80) | TCP: av-emb-config > http [SYN] |(2050) ------------------> (80) | TCP: http > av-emb-config [SYN, ACK] |(2050) <------------------ (80) | GET /htmlsample.mpe |(2050) ------------------> (80) | TCP: http > av-emb-config [FIN, ACK] |(2050) <------------------ (80) | TCP: av-emb-config > http [RST, ACK] |(2050) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=306 Ack=3402 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=417 Ack=562446 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=513 Ack=1671 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=2096810 Ack=327 Win=6432 Len=0 | | Seq=327 Ack=2096811 Win=0 Len=0 |

Figure A.33: Apache Internet Explorer Video Web Page.

|Time | |0.001 | |0.002 | |0.123 | |0.136 | |1.304 | |2.055 | |2.056 | |2.057 | |2.061 | |4.821 | |19.945 | |20.029 | | 192.168.1.3 | 192.168.1.2 | TCP: mosaicsyssvc1 > http [SYN] |(1235) ------------------> (80) | TCP: http > mosaicsyssvc1 [SYN, ACK] |(1235) <------------------ (80) | GET / HTTP/1.1 |(1235) ------------------> (80) | GET /WorldMap.jpg |(1235) ------------------> (80) | TCP: mosaicsyssvc1 > http [RST, ACK] |(1235) ------------------> (80) | TCP: tsdos390 > http [SYN] |(1237) ------------------> (80) | TCP: http > tsdos390 [SYN, ACK] |(1237) <------------------ (80) | GET / HTTP/1.1 |(1237) ------------------> (80) | GET /WorldMap.jpg |(1237) ------------------> (80) | GET /favicon.ico |(1237) ------------------> (80) | TCP: http > tsdos390 [FIN, ACK] |(1237) <------------------ (80) | TCP: tsdos390 > http [FIN, ACK] |(1237) ------------------> (80) | | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |Seq=907 Ack=2932234 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=6104214 Ack=1483 Win=8576 Len=0 | | Seq=1483 Ack=6104215 Win=65535 Len=0 |

Figure A.34: Apache Opera Picture Web Page.

64

|Time | |0.000 | |0.032 | |0.075 | |0.888 | |0.888 | |1.264 | |1.266 | |1.309 | |4.260 | |127.526 | |127.528 |

| 192.168.1.3 | 192.168.1.4 | TCP: mosaicsyssvc1 > http [SYN] |(1235) ------------------> (80) | TCP: http > mosaicsyssvc1 [SYN, ACK] |(1235) <------------------ (80) | GET / HTTP/1.1 |(1235) ------------------> (80) | TCP: mosaicsyssvc1 > http [RST, ACK] |(1235) ------------------> (80) | TCP: mosaicsyssvc1 > http [RST] |(1235) ------------------> (80) | TCP: tsdos390 > http [SYN] |(1237) ------------------> (80) | TCP: http > tsdos390 [SYN, ACK] |(1237) <------------------ (80) | GET / HTTP/1.1 |(1237) ------------------> (80) | GET /favicon.ico |(1237) ------------------> (80) | TCP: tsdos390 > http [FIN, ACK] |(1237) ------------------> (80) | TCP: http > tsdos390 [FIN, ACK] |(1237) <------------------ (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | Seq=407 Ack=1275317 Win=0 Len=0 | |Seq=407 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=958 Ack=3510148 Win=65098 Len=0 | | Seq=3510148 Ack=959 Win=16563 Len=0 |

Figure A.35: Apache Opera Text Web Page.

|Time | |7.493 | |7.494 | |7.562 | |7.617 | |9.138 | |10.238 | |10.239 | |10.240 | |10.755 | |11.650 | |27.385 | |27.490 |

| 192.168.1.4 | 192.168.1.2 | TCP: intrastar > http [SYN] |(1907) ------------------> (80) | TCP: http > intrastar [SYN, ACK] |(1907) <------------------ (80) | GET / HTTP/1.1 |(1907) ------------------> (80) | GET /htmlsample. |(1907) ------------------> (80) | TCP: intrastar > http [RST, ACK] |(1907) ------------------> (80) | TCP: global-wlink > http [SYN] |(1909) ------------------> (80) | TCP: http > global-wlink [SYN, ACK] |(1909) <------------------ (80) | GET / HTTP/1.1 |(1909) ------------------> (80) | GET /htmlsample. |(1909) ------------------> (80) | GET /favicon.ico |(1909) ------------------> (80) | TCP: http > global-wlink [FIN, ACK] |(1909) <------------------ (80) | TCP: global-wlink > http [FIN, ACK] |(1909) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=910 Ack=147777 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=2545774 Ack=1486 Win=8576 Len=0 | | Seq=1486 Ack=2545775 Win=65535 Len=0 |

Figure A.36: Apache Opera Video Web Page.

65

|Time | |0.000 | |0.234 | |0.235 | |0.248 | |1.148 | |1.148 | |1.153 | |1.153 | |1.155 | |1.155 | |1.210 | |1.210 | |1.218 | |1.218 | |1.222 | |3.337 | |119.608 | |119.841 |

| 192.168.1.4 | 192.168.1.2 | TCP: intellistor-lm > http [SYN] |(1539) ------------------> (80) | TCP: http > intellistor-lm [SYN, ACK] |(1539) <------------------ (80) | GET / HTTP/1.1 |(1539) ------------------> (80) | GET /WorldMap.jpg |(1539) ------------------> (80) | TCP: rds > http [SYN] |(1540) ------------------> (80) | TCP: rds2 > http [SYN] |(1541) ------------------> (80) | TCP: intellistor-lm > http [FIN, ACK] |(1539) ------------------> (80) | TCP: intellistor-lm > http [RST, ACK] |(1539) ------------------> (80) | TCP: http > rds [SYN, ACK] |(1540) <------------------ (80) | TCP: http > rds2 [SYN, ACK] |(1541) <------------------ (80) | GET /favicon.ico |(1540) ------------------> (80) | GET / HTTP/1.1 |(1541) ------------------> (80) | TCP: rds > http [FIN, ACK] |(1540) ------------------> (80) | TCP: rds > http [RST, ACK] |(1540) ------------------> (80) | GET /WorldMap.jpg |(1541) ------------------> (80) | GET /favicon.ico |(1541) ------------------> (80) | TCP: rds2 > http [FIN, ACK] |(1541) ------------------> (80) | TCP: http > rds2 [FIN, ACK] |(1541) <------------------ (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=743 Ack=1872305 Win=64359 Len=0 | | Seq=744 Ack=1873765 Win=0 Len=0 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET / HTTP/1.1 | |Seq=347 Ack=10221 Win=65535 Len=0 | | Seq=348 Ack=11681 Win=0 Len=0 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=1333 Ack=4230606 Win=65165 Len=0 | | Seq=4230606 Ack=1334 Win=16188 Len=0 |

Figure A.37: Microsoft IIS Firefox Picture Web Page.

66

|Time | |15.135 | |15.137 | |15.137 | |16.666 | |16.667 | |16.668 | |16.720 | |16.720 | |16.721 | |16.754 | |16.769 | |25.746 | |149.693 | |149.694 |

| 192.168.1.3 | 192.168.1.2 | TCP: dfn > http [SYN] |(1133) ------------------> (80) | TCP: http > dfn [SYN, ACK] |(1133) <------------------ (80) | GET / HTTP/1.1 |(1133) ------------------> (80) | TCP: aplx > http [SYN] |(1134) ------------------> (80) | TCP: dfn > http [RST, ACK] |(1133) ------------------> (80) | TCP: http > aplx [SYN, ACK] |(1134) <------------------ (80) | GET /favicon.ico |(1134) ------------------> (80) | TCP: omnivision > http [SYN] |(1135) ------------------> (80) | TCP: http > omnivision [SYN, ACK] |(1135) <------------------ (80) | GET / HTTP/1.1 |(1135) ------------------> (80) | TCP: aplx > http [RST, ACK] |(1134) ------------------> (80) | GET /favicon.ico |(1135) ------------------> (80) | TCP: omnivision > http [FIN, ACK] |(1135) ------------------> (80) | TCP: http > omnivision [FIN, ACK] |(1135) <------------------ (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=366 Ack=1291701 Win=0 Len=0 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | Seq=347 Ack=90113 Win=0 Len=0 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=846 Ack=2283010 Win=65535 Len=0 | | Seq=2283010 Ack=847 Win=16675 Len=0 |

Figure A.38: Microsoft IIS Firefox Text Web Page.

Microsoft IIS_Firefox_Video Web Page |Time | |15.345 | |15.347 | |15.347 | |15.748 | |16.712 | |16.781 | |16.781 | |17.760 | |17.761 | |17.786 | |18.200 | |135.101 | |135.158 | | 192.168.1.4 | 192.168.1.2 | TCP: vpjp > http [SYN] |(1345) ------------------> (80) | TCP: http > vpjp [SYN, ACK] |(1345) <------------------ (80) | GET / HTTP/1.1 |(1345) ------------------> (80) | GET /favicon.ico |(1345) ------------------> (80) | TCP: alta-ana-lm > http [SYN] |(1346) ------------------> (80) | TCP: http > alta-ana-lm [SYN, ACK] |(1346) <------------------ (80) | GET /htmlsample |(1346) ------------------> (80) | TCP: alta-ana-lm > http [FIN, ACK] |(1346) ------------------> (80) | TCP: alta-ana-lm > http [RST, ACK] |(1346) ------------------> (80) | GET / HTTP/1.1 |(1345) ------------------> (80) | GET /htmlsample.mpe |(1345) ------------------> (80) | TCP: vpjp > http [FIN, ACK] |(1345) ------------------> (80) | TCP: http > vpjp [FIN, ACK] |(1345) <------------------ (80) | | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=411 Ack=1203049 Win=65535 Len=0 | | Seq=412 Ack=1204225 Win=0 Len=0 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=1655 Ack=1389473 Win=65535 Len=0 | |Seq=1389473 Ack=1656 Win=17520 Len=0 |

Figure A.39: Microsoft IIS Firefox Video Web Page.

67

Figure A.40: Microsoft IIS Google Chrome Video Web Page.

Figure A.41: Microsoft IIS Google Chrome Text Web Page.

68

|Time | |5.458 | |5.615 | |5.615 | |6.314 | |6.315 | |6.537 | |6.538 | |7.031 | |7.061 | |7.064 | |7.616 | |7.617 | |7.762 | |7.765 | |7.765 | |7.768 | |7.769 | |7.770 | |7.771 | |7.772 | |245.343 | |245.345 |

| 192.168.1.4 | 192.168.1.2 | TCP: norton-lambert > http [SYN] |(2338) ------------------> (80) | TCP: http>norton-lambert[SYN, ACK] |(2338) <------------------ (80) | GET / HTTP/1.1 |(2338) ------------------> (80) | GET /htmlsample. |(2338) ------------------> (80) | TCP: 3com-webview > http [SYN] |(2339) ------------------> (80) | TCP: http > 3com-webview [SYN, ACK] |(2339) <------------------ (80) | GET /favicon.ico |(2339) ------------------> (80) | GET / HTTP/1.1 |(2339) ------------------> (80) | TCP: 3com-webview > http [FIN, ACK] |(2339) ------------------> (80) | TCP: http > 3com-webview [FIN, ACK] |(2339) <------------------ (80) | TCP: norton-lambert > http [FIN, ACK] |(2338) ------------------> (80) | TCP: norton-lambert > http [RST, ACK] |(2338) ------------------> (80) | TCP: wrs_registry > http [SYN] |(2340) ------------------> (80) | TCP: http>wrs_registry[SYN, ACK] |(2340) <------------------ (80) | GET /htmlsample. |(2340) ------------------> (80) | TCP: wrs_registry > http [FIN, ACK] |(2340) ------------------> (80) | TCP: http > wrs_registry [FIN, ACK] |(2340) <------------------ (80) | TCP: xiostatus > http [SYN] |(2341) ------------------> (80) | TCP: http > xiostatus [SYN, ACK] |(2341) <------------------ (80) | GET /htmlsample. |(2341) ------------------> (80) | TCP: xiostatus > http [FIN, ACK] |(2341) ------------------> (80) | TCP: http > xiostatus [FIN, ACK] |(2341) <------------------ (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | |Seq=0 Ack=1Win=17520Len=0MSS=1460WS=0 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | |Seq=0Ack=1Win=17520 Len=0 MSS=1460 WS=0 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET / HTTP/1.1 | | Seq=854 Ack=212442 Win=65348 Len=0 | | Seq=212442 Ack=855 Win=16667 Len=0 | | Seq=775 Ack=1161069 Win=0 Len=0 | |Seq=776 Ack=1161069 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | |Seq=0Ack=1Win=17520Len=0MSS=1460 WS=0 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=478 Ack=141 Win=65396 Len=0 | |Seq=141 Ack=479 Win=17043 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 WS=1 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=422 Ack=1305028 Win=65536 Len=0 | | Seq=1305028 Ack=423 Win=17099 Len=0 |

Figure A.42: Microsoft IIS Google Chrome Video Web Page.

|Time | |11.690 | |11.691 | |11.692 | |11.733 | |12.764 | |12.764 | |12.768 | |12.773 | |12.773 | |12.777 | |16.017 | |76.333 |

| 192.168.1.4 | 192.168.1.2 | TCP: iclpv-sc > http [SYN] |(1390) ------------------> (80) | TCP: http > iclpv-sc [SYN, ACK] |(1390) <------------------ (80) | GET / HTTP/1.1 |(1390) ------------------> (80) | GET /WorldMap.jpg |(1390) ------------------> (80) | TCP: iclpv-sc > http [RST] |(1390) ------------------> (80) | TCP: iclpv-sc > http [RST, ACK] |(1390) ------------------> (80) | TCP: iclpv-sas > http [SYN] |(1391) ------------------> (80) | TCP: http > iclpv-sas [SYN, ACK] |(1391) <------------------ (80) | GET / HTTP/1.1 |(1391) ------------------> (80) | GET /WorldMap.jpg |(1391) ------------------> (80) | GET /favicon.ico |(1391) ------------------> (80) | TCP: iclpv-sas > http [RST, ACK] |(1391) ------------------> (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | | Seq=481 Win=0 Len=0 | | Seq=481 Ack=1944857 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=881 Ack=4169233 Win=0 Len=0 |

Figure A.43: Microsoft IIS Internet Explorer Picture Web Page.

69

|Time | |0.081 | |0.082 | |0.083 | |2.289 | |2.335 | |2.436 | |2.436 | |37.585 | |102.962 |

| 192.168.1.3 | 192.168.1.2 | TCP: hacl-qs > http [SYN] |(1238) ------------------> (80) | TCP: http > hacl-qs [SYN, ACK] |(1238) <------------------ (80) | GET / HTTP/1.1 |(1238) ------------------> (80) | TCP: hacl-qs > http [RST, ACK] |(1238) ------------------> (80) | TCP: nmsd > http [SYN] |(1239) ------------------> (80) | TCP: http > nmsd [SYN, ACK] |(1239) <------------------ (80) | GET / HTTP/1.1 |(1239) ------------------> (80) | GET /favicon.ico |(1239) ------------------> (80) | TCP: nmsd > http [RST, ACK] |(1239) ------------------> (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | Seq=220 Ack=1710953 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=535 Ack=1799464 Win=0 Len=0 |

Figure A.44: Microsoft IIS Internet Explorer Picture Text Page.

|Time | |49.101 | |49.102 | |49.102 | |50.012 | |50.123 | |50.794 | |50.955 | |50.955 | |56.776 | |57.836 | |58.328 | |58.398 | |58.398 | |58.403 | |58.405 | |58.510 | |58.705 | |58.706 | |124.858 |

| 192.168.1.4 | 192.168.1.2 | TCP: netarx > http [SYN] |(1040) ------------------> (80) | TCP: http > netarx [SYN, ACK] |(1040) <------------------ (80) | GET / HTTP/1.1 |(1040) ------------------> (80) | GET /htmlsample. |(1040) ------------------> (80) | TCP: netarx > http [RST, ACK] |(1040) ------------------> (80) | TCP: danf-ak2 > http [SYN] |(1041) ------------------> (80) | TCP: http > danf-ak2 [SYN, ACK] |(1041) <------------------ (80) | GET /favicon.ico |(1041) ------------------> (80) | GET /htmlsample. |(1041) ------------------> (80) | TCP: danf-ak2 > http [RST, ACK] |(1041) ------------------> (80) | TCP: afrog > http [SYN] |(1042) ------------------> (80) | TCP: http > afrog [SYN, ACK] |(1042) <------------------ (80) | GET / HTTP/1.1 |(1042) ------------------> (80) | GET /htmlsample. |(1042) ------------------> (80) | TCP: afrog > http [RST, ACK] |(1042) ------------------> (80) | TCP: boinc-client > http [SYN] |(1043) ------------------> (80) | TCP: http > boinc-client [SYN, ACK] |(1043) <------------------ (80) | GET /htmlsample |(1043) ------------------> (80) | TCP: boinc-client > http [RST, ACK] |(1043) ------------------> (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |Seq=306 Ack=3361 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /favicon.ico HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=417 Ack=350342 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=501 Ack=1649 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | | Seq=265 Ack=2195035 Win=0 Len=0 |

Figure A.45: Microsoft IIS Internet Explorer Video Web Page.

70

|Time | |0.186 | |0.188 | |0.188 | |0.194 | |2.346 | |2.348 | |2.349 | |2.352 | |5.920 | |127.776 | |127.777 |

| 192.168.1.4 | 192.168.1.2 | TCP: timbuktu-srv3 > http [SYN] |(1419) ------------------> (80) | TCP: http > timbuktu-srv3 [SYN, ACK] |(1419) <------------------ (80) | GET / HTTP/1.1 |(1419) ------------------> (80) | GET /WorldMap.jpg |(1419) ------------------> (80) | TCP: timbuktu-srv3 > http [RST, ACK] |(1419) ------------------> (80) | TCP: gandalf-lm > http [SYN] |(1421) ------------------> (80) | TCP: http > gandalf-lm [SYN, ACK] |(1421) <------------------ (80) | GET /WorldMap.jpg |(1421) ------------------> (80) | GET /favicon.ico |(1421) ------------------> (80) | TCP: gandalf-lm > http [FIN, ACK] |(1421) ------------------> (80) | TCP: http > gandalf-lm [FIN, ACK] |(1421) <------------------ (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | | Seq=907 Ack=3661081 Win=0 Len=0 | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET /WorldMap.jpg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=1000 Ack=6103598 Win=65535 Len=0 | | Seq=6103598 Ack=1001 Win=16521 Len=0 |

Figure A.46: Microsoft IIS Opera Picture Web Page.

|Time | |22.561 | |22.562 | |22.598 | |24.293 | |25.157 | |25.323 | |25.323 | |28.794 | |151.589 | |151.590 |

| 192.168.1.3 | 192.168.1.2 | TCP: ff-annunc > http [SYN] |(1089) ------------------> (80) | TCP: http > ff-annunc [SYN, ACK] |(1089) <------------------ (80) | GET / HTTP/1.1 |(1089) ------------------> (80) | TCP: ff-annunc > http [RST, ACK] |(1089) ------------------> (80) | TCP: ff-sm > http [SYN] |(1091) ------------------> (80) | TCP: http > ff-sm [SYN, ACK] |(1091) <------------------ (80) | GET / HTTP/1.1 |(1091) ------------------> (80) | GET /favicon.ico |(1091) ------------------> (80) | TCP: ff-sm > http [FIN, ACK] |(1091) ------------------> (80) | TCP: http > ff-sm [FIN, ACK] |(1091) <------------------ (80)

| | |Seq=0 Win=65535 Len=0 MSS=1460 | |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | | Seq=407 Ack=2240513 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | |Seq=958 Ack=3510148 Win=65098 Len=0 | | Seq=3510148 Ack=959 Win=16563 Len=0 |

Figure A.47: Microsoft IIS Opera Text Web Page.

71

|Time | |0.198 | |0.206 | |0.206 | |0.212 | |3.439 | |4.043 | |5.157 | |5.417 | |5.418 | |5.936 | |6.035 | |128.609 | |128.610 | |

| 192.168.1.4 | 192.168.1.2 | TCP: prm-sm-np > http [SYN] |(1402) ------------------> (80) | TCP: http > prm-sm-np [SYN, ACK] |(1402) <------------------ (80) | GET / HTTP/1.1 |(1402) ------------------> (80) | GET /htmlsample. |(1402) ------------------> (80) | GET /favicon.ico |(1402) ------------------> (80) | TCP: prm-sm-np > http [RST, ACK] |(1402) ------------------> (80) | TCP: igi-lm > http [SYN] |(1404) ------------------> (80) | TCP: http > igi-lm [SYN, ACK] |(1404) <------------------ (80) | GET / HTTP/1.1 |(1404) ------------------> (80) | GET /htmlsample. |(1404) ------------------> (80) | GET /favicon.ico |(1404) ------------------> (80) | TCP: igi-lm > http [FIN, ACK] |(1404) ------------------> (80) | TCP: http > igi-lm [FIN, ACK] |(1404) <------------------ (80)

| | | Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=1409 Ack=2407071 Win=0 Len=0 | |Seq=0 Win=65535 Len=0 MSS=1460 | | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 | |HTTP: GET / HTTP/1.1 | |HTTP: GET /htmlsample.mpeg HTTP/1.1 | |HTTP: GET /favicon.ico HTTP/1.1 | | Seq=1573 Ack=212834 Win=65535 Len=0 | | Seq=212834 Ack=1574 Win=17520 Len=0 |

Figure A.48: Microsoft IIS Opera Video Web Page.

72

Master Thesis Electrical Engineering Thesis no: MEE 62-28 December 2010

RELATIONSHIP BETWEEN NETWORK AND APPLICATION DOWNLOAD TIMES (WEB)

MOHAMMAD SHAFI KOWSAR KATTA RAVI KUMAR

School of Computing Blekinge Institute of Technology 37179 Karlskrona Sweden

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

Contact Information Authors: Sha Kowsar Mohammad Address: Hanverkaregatan 43, Karlskrona E-mail: [email protected] Ravi Kumar Katta Address: Hanverkaregatan 43, Karlskrona E-mail: [email protected] University advisor: Mr. Junaid Shaikh, Ph.D. Student COM/BTH School of Computing Blekinge Institute of Technology 371 79 KARLSKRONA SWEDEN Internet: www.bth.se/com Phone: +46 455 385000 SWEDEN

Abstract
Internet has dominated the modern communication and information exchange and it is growing enormously day by day. Initially it is designed to oer various applications like World Wide Web (WWW), Electronic Mail (E-Mail) and File Transfer (FTP). WWW has become very popular and today Web trac constitutes 70-80% in global Internet trac. Web trac generates by the end users, when they request for a web page. The web page transfers between various Web servers via dierent service networks to the end users. Web trac has become very signicant in the present world and the service providers have to oer best service to the customers. Quality of Service (QoS) is a measure of describing the performance of the service. Quality of Experience (QoE) explains the user perceived performance and it is subjective in nature. QoE inuences user satisfaction level, so QoS has to ensure to promote better QoE. User perceived QoE depends on page download time and it is an important parameter in evaluating the performance of web service. In this work we try to correlate the web page download times at both application-level and network-level. In particular, when there is a considerable delay in the network, we tried to correlate the application perceived download time with network-level download time. We explained the dierence between application and network download times and how it varies with the applied delay. This work also shows how the download times at both levels are related to each other and their coecient of correlation.

Keywords: Quality of Service, Quality of Experience, delay and correlation.

Acknowledgements
First of all, we would like to thank our advisor Mr.Junaid Shaikh. Without his generous support and guidance, this thesis work would never have been nished. We also like to thank Dr. Patrik Arlos for providing his valuable suggestions and support in the lab. We are very grateful to our parents for their endless support and prayers.

Md Sha Kowsar K Ravi Kumar

ii

Contents
Abstract Acknowledgements i ii

Contents List of Figures List of Tables Introduction

1 Introduction 1.1 Quality of Service and Quality of Experience . . . . . . . . . 1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . .

iii v vi 1
2 3 4 5

Background
2 Background 2.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Transmission Control Protocol . . . . . . . . . . . . . . . . . 2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
7 7 8 10

Experiment Setup

12

3 Experiment Setup 13 3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1 Testbed Description: . . . . . . . . . . . . . . . . . . . 13 iii

3.2 3.3

3.1.2 Trac Shaper: . . . . . . . . . . . . . . 3.1.3 Measurement Area Controller (MArC): 3.1.4 Measurement Point: . . . . . . . . . . . 3.1.5 Consumer: . . . . . . . . . . . . . . . . 3.1.6 Users: . . . . . . . . . . . . . . . . . . . Experiment Approach and Conguration: . . . Process involved in the experiment: . . . . . . . 3.3.1 MArC . . . . . . . . . . . . . . . . . . . 3.3.2 Trac Shaper: . . . . . . . . . . . . . . 3.3.3 Measurement Point (MP): . . . . . . . . 3.3.4 Consumer: . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

14 14 15 15 15 16 17 17 17 17 18

Results
4 Results 4.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Average download times: . . . . . . . . . . . . . . . . . . . . . 4.2.1 Page download times for various network delays: . . . 4.3 Relation between network and application-level download times:

19
20 20 22 24 28

Conclusions and Future Work

34

5 Conclusions and Future Work 35 5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Appendix
A Network Diagram

36
37

Bibliography

39

iv

List of Figures
1.1 2.1 2.2 3.1 3.2 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Relation between QoE, QoS, User satisfaction and User actions. Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Control Protocol . . . . . . . . . . . . . . . . . Experiment setup. . . . . . . . . . . . . . . . . . . . . . . . . Experiment setup design overview . . . . . . . . . . . . . . . NW AVG DT for whole experiment . . . . . . . . . . . . . . . APP AVG DT for whole experiment . . . . . . . . . . . . . . Network and Application-level average download times for 0 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network and Application-level average download times for 75 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network and Application-level average download times for 150 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . Network and Application-level average download times for 235 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . Network and Application-level average download times for 310 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . Average Network and Application download times for dierent delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8 9 14 16 23 23 24 25 25 26 26 28 38

A.1 Experiment Conguration Network Diagram

List of Tables
3.1 4.1 4.2 Web browsing sessions details . . . . . . . . . . . . . . . . . . Calculated average download times for sessions . . . . . . . . Calculated download times per page . . . . . . . . . . . . . . 14 22 29

vi

Introduction

Chapter 1

Introduction
Internet has become an essential part of todays communication and information exchange. Internet trac is growing enormously in terms of network expansion, type of applications and the number of users. As a result the complexity within the network is increasing to support the growing trac. World Wide Web (WWW) technology has been widely used in various sectors and Web trac constitutes the major part of the Internet trac. Web trac generates when a client or user requests a Web server and the Web server responds to the client in the form of web pages. A web page forms by processing and transfer of large number of data packets through various connections via dierent Web servers [4]. But these all are transparent to the end user and he or she can view only the web page. Web technology has become popular, signicant work is going on to study the Web trac characteristics. The major concern of the users in web browsing is the web page response time [8]. If the page download time is in the order of few seconds then it is acceptable, otherwise the user will get disappointed with the service. Web browsing applications can work eciently if the operator monitors the network performance periodically and acts according to the observations. To measure the performance of web browsing applications, it is very much necessary to understand the end-toend performance. The network service providers should oer best performed service to the customers to meet the service level agreements and to withstand in the present competitive world. They have to ensure that their service is reliable and available at all times. Therefore it is necessary to monitor the service performance for network operators. To measure the service performance, the service providers need to identify the key performance indicators or metrics. Metric is an entity that describes the reliability, performance and the operational state of the network or the network elements [12]. Examples of the network performance metrics of web browsing are delay, jitter, packet loss and throughput [10]. These performance metrics are very useful in

CHAPTER 1. INTRODUCTION

describing the user perceived performance. Network measurements are used to assess the performance of the network and they have become very crucial in the course of evaluation and analysis of the Internet trac. The network service providers normally deploy Network Measurement Infrastructure (NMI) in their networks. This measurement infrastructure is used to identify the end-to-end performance in the network and also to study the Internet trac characteristics [3]. Performance measurements can be carried out using two methods; they are active and passive measurements. In active measurements, packets are introduced into the network to measure one or more parameters. Examples ping trace-route etc. In passive measurements, the trac is measured and analyzed without injecting or disturbing any trac in the network. Passive measurements can be performed at dierent levels like packet level, TCP level and application-level [6]. Both network service providers and end users use dierent approach to evaluate the performance of the service. The network service providers analyse the performance at network-level as they have control over the network. It includes monitoring QoS parameters such as delay, jitter, packet loss and throughput. Whereas the end users will not be aware of technical parameters and their performance evaluation will be of more subjective [15]. As web browsing applications are interactive in nature and the end users would like to browse the web pages without the delay. So their performance evaluation mostly depends on the web page response time.

1.1

Quality of Service and Quality of Experience

QoS describes the performance of the service and it is been widely to measure the users satisfaction level [11]. It is very crucial to understand how the end user feels about the performance of the service provided by the network and it is dicult to predict the users satisfaction level. By analyzing huge amount of packet data from the operational network, it is possible to understand the level of users satisfaction. If the users satisfaction is low, then it may leads to the connection termination. A big challenge to the service providers is to dene the end-to-end performance criteria and threshold such that the measured performance ensures that the customers are satised and the network works eciently [5]. QoE deals with the estimation of user perceived performance [6]. QoE is very important for the network operators in allocation of resources (bandwidth) where it is required and also useful in trac management. The below Figure 1.1 [13] shows the relation between QoS, QoE and user satisfaction. As shown in the QoS parameters set by the operator determines the performance of the network. The QoE largely depends on the QoS of the network. If the customer experiences a good service then their satisfaction

CHAPTER 1. INTRODUCTION

QoS : Network Performance

QoE : User Experience

User Action

User Satisfaction Level

Figure 1.1: Relation between QoE, QoS, User satisfaction and User actions.

level increases. Increase in satisfaction level leads to more usage of service which increases the trac in the network. Therefore these parameters are closely related to each other.

1.2

Objective

One of the objectives of this work is to identify the key parameters that have inuence on user perceived performance at application-level and it can also be measured at network-level. The intention of this work is to map the network performance metric to application performance metric. In this study, we analyze how the web page download times at network and application-level relate to each other when there is a delay in the network. To achieve this we developed a test bench setup using Distributive Passive Measurement Infrastructure (DPMI) [1] at Blekinge Institute of Technology (BTH). Dierent trends of network delays are applied in dierent browsing sessions. Experiments are performed and network-level packets are captured using DPMI. At the same time the application-level browser logs are noted to compute the page download time at the user end. Our investigation shows how the page download time varies at network and user level, when there is a delay in the network. We tried to correlate the download times at both levels for various applied delays.

CHAPTER 1. INTRODUCTION

1.3

Document Structure

The structure of the document is as follows. Chapter 2 explains the technical background and the related work performed in this eld. Chapter 3 describes the experiment setup and the process involved in the experiment. Chapter 4 briefs the analysis of the experiment results. Chapter 5 describes the conclusion and future work.

Background

Chapter 2

Background
Internet was initially designed to oer asynchronous applications such as WWW, email and le transfer. It is necessary to understand and analyze the network trac which can be used to predict the trac for future networks. Dierent experiments and measurements have been performed on Internet trac to understand the performance and to identify the trac characteristics. Estimation of network performance has become a challenging issue as Internet applications are inherent in behaviour and relies on various parameters. Web is one of the popular Internet applications and to study the behaviour of the Web trac it is important to analyse the trac. When the user sends a request for a web page, there will be huge amount of packets that will transfer over the network. Hyper Text Transfer Protocol (HTTP) is predominant protocol responsible for Web trac and it depends on various underlying protocols in dierent layers. To study the Web trac characteristics, it is necessary to understand underlying protocols such as Internet Protocol (IP) and Transmission Control Protocol (TCP). The following sections describe the functioning of these protocols and their header formats.

2.1

Internet Protocol

In order to capture the Web trac traces at network-level, before that we must understand the Internet Protocol header format. IP lies in network layer and it supports the other higher layer protocols such as TCP and UDP. IP is responsible for logical addressing (IP Address). Based on the header format the Measurement Point is designed to capture only IP packets. The following Fig 2.1 shows the various elds of basic IP header. The rst eld in the header represents the version of Internet Protocol and in the present experiment we used IPV4 version. The second eld gives the length of the IP header and it will in 32 bit words. Type of service is 8 bit eld and it species the treatment of datagram during its transmission.

CHAPTER 2. BACKGROUND
0 4 8 15 Version H Length Type of Service (4 bits) (4 bits) (8 bits) Identification (16 bits) 20 Bytes Time to Live (8 bits) Protocol (8 bits) R D M F F 31 Total Length (16 bits) Fragmentation Offset (13 bits)

Header Checksum (16 bits)

Source IP Address (32 bits) Destination IP Address (32 bits) IP Options ( If Any ) Padding

Payload

Figure 2.1: Internet Protocol

Total length is the length of the datagram including the header and payload. It is usually measured in octets. Using the header length and total length it is easy to locate the end of the header and beginning of the payload in the IP datagram. The maximum size of the IP datagram is 65535 bytes [14]. A value will be assigned in identication eld which is used in the process of assembling the fragments of a datagram. Identication will assign the value for the datagram which is used for service precedence. The next eld consists of three ags. The ag R indicates that it is reserved. The ag DF represents do not fragment and MF represents more fragments. Fragmentation oset directs the reassembly of the fragmented datagram. Time to Live (TTL) indicates the life time of the datagram in the network. In our scenario the TTL for the requests to the Web server is dierent from the response. The protocol eld indicates the higher layer which is TCP. Header checksum is used for error checking. The other elds represent the source and destination IP addresses followed by the actual data or payload.

2.2

Transmission Control Protocol

TCP is a connection oriented, reliable data transport protocol used to transfer the data over the Internet. It is responsible for end to end communication and it uses ports to transfer the data. It receives the data from the upper layers and processes using the service provided by the underlying protocols such as IP. TCP is used by many popular applications mainly WWW and used as transport protocol for most of the Internet trac [19]. Web browsing is a reliable service so HTTP uses TCP as transport protocol for data transfer. In our experiment we are interested in capturing only TCP pack-

CHAPTER 2. BACKGROUND
0 4 8 15 Destination Port Number (16 bits) 31

Source Port Number (16 bits)

Sequence Number (32 bits) 20 Bytes Acknowledgement Number (32 bits) H Length (4 bits) Reserved (6 bits)
ACK PSH URG SYN RST FIN

Window Size (16 bits) Urgent Pointer (16 bits) Padding

TCP Checksum (16 bits)

TCP Options Variable Length ( If any )

Payload ( If any )

Figure 2.2: Transmission Control Protocol ets. To capture the TCP packets it is necessary to study the TCP header and its elds. The lters in the DPMI are designed in such a way that the packets belongs to the corresponding protocols can be captured. The above Figure 2.2 represents the TCP datagram header format. TCP uses port numbers as the way for communication and identifying particular TCP connection. In the TCP header the rst two elds represents the source and destination port numbers. The sequence number is the rst octet in the packet. If SYN ag is present then the sequence number is called Initial sequence number (ISN) and the sequence number of rst data byte will become ISN+1. The acknowledge number is the next sequence number of the packet for which the receiver is expecting. When the three way handshake succeeds and the connection establishes then the ACK ag will be turned ON [14]. Header length indicates the length of the TCP header in 32 bit words. It also describes the starting of the payload. There are 6 ags in the next eld. URG indicates urgent pointer. ACK ag is for acknowledgement. PSH represents push function. RST is for connection reset. SYN ag is for synchronising the sequence numbers. FIN represents no more data from the sender or end of data transmission from the sender. The other elds are window size and checksum followed by payload. TCP establishes communication using sockets. A socket consists of source and destination IP addresses and port numbers. Normally TCP establishes connection using the sequence number and acknowledgement number and begins the process with a three way handshake [6]. In this process, the data is transmitted from the sender and the receiver has to acknowledge each byte of the data that it receives. In web browsing if the user wants to terminate the connection, in this case he can stop or refresh the connection. For which FIN and RST ags will be called which are responsible termina-

CHAPTER 2. BACKGROUND

10

tion of active connection or transfer. The captured packet traces consists of various ags using which we can identify whether it is a request or reply. By using various elds of the IP and TCP header we can analyse the captured packet traces which is discussed in chapter 4. As mentioned in the previous chapter, this work describes the performance analysis of web browsing applications trac. The objective of this research is to map the download times of application-level trac to networklevel trac for web browsing applications and based on the results will correlate them. The following section explains briey about the relevant work performed in this eld.

2.3

Related Work

Extensive research has been done on Web trac to identify the parameters which are used to evaluate the performance. Some of the researches are based on QoS parameters and few of them based on QoE from user perspective. In this [7] work the authors evaluated the eect of packet loss on Web trac characteristics. From the results, they correlate the packet loss of Web trac to user quality of experience. The authors performed passive measurement and evaluated the eect of connection duration, size of connection and inter arrival time of connection on packet loss. The results show that the connection duration and size of connection are not key parameters to determine the user behaviour. The authors suggested that the inter-arrival time of connection is an important parameter to estimate the user behaviour. A study has been done on analysis of HTTP trac on application-level. In [2] the Web trac (HTTP) is collected using tcpdump from BTH access network. The collected trac is augmented using tcptrace for analysis. By analyzing the application logs, the authors measured various properties of HTTP trac. The authors calculated inter-session arrival time, inter-arrival time and request message size for various HTTP sessions and shown that they inuence the performance of web browsing application trac. They also suggested that Web server load and number of transactions within a HTTP session will also inuence the performance of the Web trac. In the past, research has been done in the eld of video streaming applications in order to identify the trac characteristics and performance. A similar study has been made to correlate between the application-level trac and network-level trac. In this paper [9] the authors developed tool for measuring application-level parameters for video streaming applications. They designed a test bed for collecting application-level logs. The authors identied and measured the key performance parameters that characterize the quality of video. They presented the results of measuring the correlation between application and network-level trac of video streaming application.

CHAPTER 2. BACKGROUND

11

But a similar study in the case of web browsing is not carried out before which motivated us to work in this area. A similar work has been done to study the QoE from both the operator point of view and from the user perspective [15]. This paper investigates the correlation between the user network-level trac characteristics to user perceived performance. Using the test bed setup, the authors evaluated the relationship between QoE and QoS parameters in a passive measurement environment. In an operational network, they compared QoE with web session volumes and derived relationship between QoE session volumes, loss and throughput. Work has been performed on the eect of packet loss on TCP trac. The authors correlate packet loss with TCP trac characteristics such as connection duration, size and inter arrival time. The authors explained that when packet loss rate increases, then connection becomes shorter and their inter arrival time increases [5]. They also pointed out that dissatisfaction of users leads to termination of connection. Aborted connection consumes network resources and also disturbs the successful connection. In evaluating trac characteristics, various types of methods and approaches have been used to measure the web browsing QoE. Some of the approaches are subjective in nature. This is done by collecting the user ratings to evaluate the user perceived performance. In this [16] work it has been analyzed that the eect of application download times on user QoE ratings and a mapping has been carried out between these two parameters. An experimental test bed was developed and users were tested on it in order to carry out the user QoE evaluation. From the analysis it is found that pages with higher download times (8 seconds and 6 seconds) were easily detected by the users thus resulted in low QoE ratings. It is also noted that the download time should not exceed more than 3 sec. The above paragraphs describe various works performed related to evaluation of Internet trac. In the present knowledge there is no work which maps the page download times of Web trac at both application and networklevel. There is a gap between the application-level and network-level characteristics on which this work is focused. Our research is a continuation of previous work, which is performed on network-level for Web trac. This work describes the correlation between application and network-level performance characteristics. This can be used as a measure to evaluate the performance of the Web trac.

Experiment Setup

12

Chapter 3

Experiment Setup
In this chapter, we are going to discuss about the experiment setup and how the experiments are performed. This includes the experiment setup i.e. DPMI, the process being performed during the experiment and the tool involved in analysing the collected traces. We begin with the experiment setup.

3.1

Design

The main idea in designing the experiment setup is that the users are able to access the web pages which are generated by the Web server. The basic block diagram of the experiment setup is shown in the below Figure 3.1. The client is connected to the server via trac shaper. The shaper adds the mentioned delay in the incoming trac from the server and forwards further it to the client. A measurement point is connected between the shaper and server to capture the packets. The Web server is also connected to the external network to provide the synchronization to all the elements in the network. Using this setup the client is able to browse the pages generated by the Web server. The web page download time can be noted at applicationlevel on client machine. Using the captured packets from the measurement point the network-level download time can also be computed.

3.1.1

Testbed Description:

In this section a detailed explanation of the actual experiment setup is described, which is used to perform the experiments. It consists of various components and how they work with each other. The block diagram of the entire setup is shown in Figure 3.2. To compute the download time at network-level, the packet traces are collected using DPMI. The following sections describe the complete description of each component of DPMI.

13

CHAPTER 3. EXPERIMENT SETUP

14

Users

Traffic Shaper

Web Server

Measurement Point

Figure 3.1: Experiment setup.

Table 3.1: Web browsing sessions details Session 1 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 No of Pages 22 6 6 6 6 6 6 6 6 6 6 6 6 Input Delay to Trac Shaper (ms) 0 0 75 150 310 235 150 75 0 75 150 75 235

3.1.2

Trac Shaper:

It is a device which is used to insert the intended network parameters like delay, errors and duplication etc. in the network. In the current setup the shaper is a Linux machine, which injects delay based on the input parameters. We have used NetEM [24], an emulator that inserts desired delay during the transmission of the packets. The delays are applied at dierent levels such that we can study the behaviour of the packets at various levels. The dierent delays applied for various sessions are shown in the Table 3.1.

3.1.3

Measurement Area Controller (MArC):

The MArC is also called experiment controller, is the main network component in the setup. MArC is the Web server where the web pages are hosted,

CHAPTER 3. EXPERIMENT SETUP

15

which is accessed by the user. The database server (SQL) and apache server are also installed in this machine. Database server is used to log user and Web server logging information. MArC provides the GUI to control the measurement points and also manages MP by supplying lters[1]. The experiment controller manages the remaining elements in the network. MArC has three interfaces. One of the MArC interface is connected to external public network. Second interface is connected to the private network in which user system is connected. The third interface is connected to switch. MArC acts as DHCP server and it provide private IPs to trac shaper, MP and consumer. Also it is connected to Network Time Protocol (NTP)[22] server so that it will provide timing synchronization to the remaining network elements.

3.1.4

Measurement Point:

It is a network device used to capture the packets at network-level. In the current scenario, the measurement point is a Linux machine with Endace DAG (Data Acquisition and Generation) network cards [17]. It is a powerful packet capture interface card used to capture trac on high-speed networks. The DAG card has also port to provide time stamp and clock synchronization. We connected the DAG card to the external NTP server to provide the clocking synchronization. The MP will intercept the packet transmission and capture the packets as per the lters which are controlled by Measurement Area Controller (MArC). It further transfers the captured data to consumer which is connected to Measurement Area Network (MArN).

3.1.5

Consumer:

The consumer is a Linux machine which is directly connected to switch. It is connected to the management network of the setup. Consumer acquires dynamic private IP and clocking synchronization from the Web server. The consumer converts the captured packet data into desired form as per the lters provided or the format specied by the user. The captured traces from the consumer are stored in a le to analyze further.

3.1.6

Users:

The user computer is a Windows XP SP2 based machine. Mozilla Firefox [23] version 2.0 browser is installed in the machine to browse the web pages. The Fasterfox [18] add-on is also installed which is very much used to note download times. The browser log shows the URL of each web page and the time stamp. The user machine assigned with private IP and is connected to one of MArC interface. Meinberg NTP software [21] is also installed in this machine, which acquires timing synchronization from the MArC. By running this software the user machine will be in sync with the other

CHAPTER 3. EXPERIMENT SETUP

16

Consumer

HP Swtich

External XPS Network

User Traffic Shaper

Measurement Point

Experiment Controller (or) WEB Server

Figure 3.2: Experiment setup design overview

network elements in the setup so that the timestamps in all the machines are accurate.

3.2

Experiment Approach and Conguration:

The main aim of this experiment set up is to capture the Web trac traces at network-level, which can be used to calculate the download time at networklevel. These download times will be compared to that of download times measured at application-level. The following paragraphs describe the process involved in this experiment. The user machine and the Web server are connected to the same network so that the user can access the web pages. The web pages consists of pictures and the user has to rate each web page based on its performance. At the same time we captured the packet traces of each web page using the MP. We run this experiment with 20 dierent users. This experiment is repeated one after the other with dierent users. All the users are students with telecommunication background. We applied dierent levels of delays at dierent browsing sessions so that download times at both network-level and application-level can be measured to correlate them. There are 94 web pages designed in the Web server for the user to browse and rate them. The total web pages are divided dierent groups of sessions. Each session is sub divided into dierent phases based on the delays applied. Each session has 4 phases and each phase has 6 web pages. But for session 1, no delay is applied in the shaper and it has 22 web pages. From session 2 dierent levels of delays are applied. Session 2 delays are applied in increasing fashion i.e. 0 ms, 75 ms, 150 ms and 310 ms. Session 3 delays are

CHAPTER 3. EXPERIMENT SETUP

17

applied in decreasing fashion i.e. 235 ms, 150 ms, 75 ms and 0 ms. Session 4 delays are applied in alternate fashion. The dierent levels of delays that are applied are based on the work done previously in the same area [16]. By applying the sequence the delays in dierent fashions it is possible to study the packet behaviour in both ways.

3.3
3.3.1

Process involved in the experiment:

MArC

To measure the accurate time stamp of the packets, all the devices in the setup are synchronized to external NTP server. The experimental controller is directly connected to external network using which the remaining devices in the setup obtain timing synchronization. So before starting the experiment the Web server has to run NTP service using which it acquires synchronization with NTP server. As the apache server is installed in MArC, the server access logs needs to be cleared so that we can note the correct server log information. A sample of Web server log is shown below Figure 3.3.1. And nally need to run the MArC service which initiates SQL, MArC and MArelayd.
10.0.1.208 - - [21/Apr/2010:12:38:08 +0000] "POST /qoeweb2 /qoeweb2 copy/session4 phase3.php HTTP/1.1" 200 744 ** 744 4353 10.0.1.208 - - [21/Apr/2010:12:38:08 +0000] "GET /qoeweb2/ qoeweb2 copy/session4 phase3.php?client time=1271853488758 HTTP/1.1" 200 1282 ** 1282 62155 10.0.1.208 - - [21/Apr/2010:12:38:09 +0000] "GET /qoeweb2/ qoeweb2 copy/pic/P5179784.JPG HTTP/1.1" 200 1028426 ** 1028426 1520638

Figure 3.3.1: Web Server [MArC] log

3.3.2

Trac Shaper:

In this experiment we used NetEM emulator to insert the desired delay in the packet transmission. The NTP service has to be started to provide the timing synchronization. To insert the delay the following command is used. In the command we need to mention the delay time and the interface on which the delay need to be applied. #tc qdisc add dev eth2 root netem delay 75 ms

3.3.3

Measurement Point (MP):

The measurement point is the device which is used to capture the packets. To capture the packets the MP has to be synchronised with the timing

CHAPTER 3. EXPERIMENT SETUP

18

server (NTP). The MP contains DAG interface cards which need to be started. The DAG cards capture length has to be dened in advance. In this experiment we assigned a maximum capture length of 512 bytes. Then nally the MP script needs to be started which will initiates interface cards to capture the packets. The MP will capture the packets based on the lters that are provided, which are controlled by the MArC. The following are the commands used in MP to capture the packets. #/etc/rc.d/dag start 0 #dagthree -d /dev/dag 0 slen=512 #dagpps -d /dev/dag0 #./mp -i dag0 -s eth0

3.3.4

Consumer:

The packets that are captured by the DAG cards in MP are transferred to consumer for ltering. Consumer lters the captured data and provides desired output based on the input parameters for further analysis [1]. The ltering can be done based on interface number, protocol and number of packets etc. Consumer needs to be in sync with the NTP server so that it receives the packets at the correct timestamps. The ltered packets are stored in a .cap le which further needs to be converted into a text for analysis. The following are the commands used in the consumer. #./skmo09con 0.2 -i eth0 01:00:00:00:00:04 -o test.cap #consumer -c test.cap > test.txt

Results

19

Chapter 4

Results
4.1 Analysis

The MP is placed between the trac shaper and Web server. The MP can capture the packets in both the directions i.e. from Web server to the user and vice versa. The consumer converts the captured packets into readable form. A sample of network packet traces that are collected from the consumer is shown in the below Figure 4.1.1.
[6438]:dag00:mp1276:1271853108.372617900250:LINK(1514):CAPLEN ( 512):IP(HDR[20])[Len=1500:ID=22083:TTL=64:Chk=51208:DF Tos:0]: TCP(HDR[20]DATA[5b4]): [A] 10.0.1.1:80 --> 10.0.1.208:4542 PL:5BA73D850ED1A9209E41EFD28B0D304618FBA1 [6439]:dag01:mp1276:1271853108.372851252500:LINK( 60):CAPLEN ( 512):IP(HDR[20])[Len=40:ID=1791:TTL=128:Chk=56576:DF Tos:0]: TCP(HDR[20]DATA[0]): [A] 10.0.1.208:4542 --> 10.0.1.1:80 PL:0000000000005EBF5F4B000000000000000000 [6440]:dag00:mp1276:1271853108.372740924250:LINK(1514):CAPLEN ( 512):IP(HDR[20])[Len=1500:ID=22084:TTL=64:Chk=51207:DF Tos:0]: TCP(HDR[20]DATA[5b4]): [A] 10.0.1.1:80 --> 10.0.1.208:4542 PL:E15D3EE2095A681D7119117940655BB1E7B75A [6441]:dag01:mp1276:1271853108.372930824750:LINK(60):CAPLEN ( 512):IP(HDR[20])[Len=40:ID=1796:TTL=128:Chk=56571:DF Tos:0]: TCP(HDR[20]DATA[0]): [A]10.0.1.208:4542 --> 10.0.1.1:80 PL:00000000000064BC9623000000000000000000

Figure 4.1.1: MP captured packet traces The captured packet traces shows two dag numbers dag00 and dag01. The DAG cards have two ports i.e. source port and destination port. The 20

CHAPTER 4. RESULTS

21

source port is represented by 0 and destination port is represented by 1. We used single DAG card in this experiment and it is represented as DAG 0. So dag00 represents the trac from Web server to the user and dag01 represents the packet ow from user to the Web server. To analyze these trac traces we designed an analysis tool. This tool is developed using PERL [20] scripting language. The analysis tool is designed and run on the captured packet traces, so that it lters the required information or values. To make the analysis easier we divided the traces into two dierent les, based on the DAG number, source port (HTTP port), and source IP (Web server). Each packet trace contains, the time stamp at which the packet is captured, payload, source and destination port. The client trace le contains the packet ow captured from user to server direction. The server trace le contains the packets that are captured in the direction from the server to the user. We are interested in analysing the server trace le which provides us the information about the trac from server to the client at network-level. So we run the analysis tool on server packet trace le. The analysis tool calculates the inter-arrival time between each packet. Based on the inter arrival time and payload of the packet, the trace le is divided into dierent les. So the total packet traces are divided into 94 les corresponds to 94 web pages. Each le represents the packets of a web page and it contains the packet number, time stamp at which the packet is captured, time scale with reference to the arrival of rst packet, inter-arrival time, link load and payload. The experiment was conducted with 20 dierent users. Each user browsed four dierent sessions which contains web pages with various delays that are applied to the trac shaper. The analysis tool calculates the page download time of each web page for all the users at network-level. To calculate the page download time at application-level Fasterfox web browser is installed. It provides the log of the browsed web pages using which we calculated the page download time of each web page at application-level. Below Figure 4.1.2 shows a sample log of the application-level web browser log. Figure 4.1.2: Application-level web browser logs
1271851561521 1271851562490 http://10.0.1.1/qoeweb2/ qoeweb2 copy/session2 phase4.php 1271851562506 1271851569865 http://10.0.1.1/qoeweb2/ qoeweb2 copy/session2 phase4.php?client time=1271851562490 1271851569881 1271851571896 http://10.0.1.1/qoeweb2/ qoeweb2 copy/InitSession3 phase1.php 1271851571912 1271851576772 http://10.0.1.1/qoeweb2/ qoeweb2 copy/InitSession3 phase1.php?client time=1271851571896

CHAPTER 4. RESULTS

22

Table 4.1: Calculated average download times for sessions Input Delay to Trac Shaper (ms) 0 0 75 150 310 235 150 75 0 75 150 75 235

Session 1 2.1 2.2 2.3 2.4 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4

NW AVG DT (sec) 0.33 0.38 2.35 4.52 8.78 7.17 4.73 2.37 0.42 2.43 4.71 2.48 5.63

APP AVG DT (sec) 0.38 0.44 2.46 4.69 9.09 7.45 4.92 2.48 0.47 2.53 4.88 2.59 5.85

4.2

Average download times:

As discussed in the previous chapter to analyze the response of the packets at network-level, we applied dierent amount of delays. The browsing period of each user is divided into various sessions and each session is applied with dierent amount of delays. The Table 4.1 has four columns. The rst column is the session number and the second shows the delay that is applied by the NetEM emulator in the direction from the Web server to the user. The third column represents the network-level average page download time (NW AVG DT) that is calculated for each session for all the users. Similarly, the fourth column is the application-level average page download time (APP AVG DT) for all the users. The download time for a web page depends on various parameters. For the same web page the download time may be dierent for dierent users. As shown in the Table 4.1, there are about 34 pages for which no delay is applied. These are placed in dierent sessions and the average download time for each session is dierent. Similarly a network delay of 75 ms is applied for 24 pages in 4 dierent sessions. They are 2.2, 3.3, 4.1 and 4.3. The average download time in each session is slightly dierent from others. Therefore to calculate the cumulative average download time for each web page, we considered all the four sessions even though they are in dierent sessions. The next paragraph depicts the behaviour of the page download time for dierent applied delays.

CHAPTER 4. RESULTS

23

14 12

Min NW DT Avg NW DT Max NW DT

Download Time [sec]

10 8 6 4 2 0

10

20

30

40

50

60

70

80

90

Page Number

Figure 4.1: NW AVG DT for whole experiment

14 12

Min APP DT Avg APP DT Max APP DT

Download Time [sec]

10 8 6 4 2 0

10

20

30

40

50

60

70

80

90

Page Number

Figure 4.2: APP AVG DT for whole experiment

CHAPTER 4. RESULTS
0.8 0.7 Download Time [sec] 0.6 0.5 0.4 0.3 0.2 0.1 0

24

NW Avg DT App Avg DT

10 User

12

14

16

18

20

Figure 4.3: Network and Application-level average download times for 0 ms delay

To study the behaviour of the page download times for the entire experiment, the download time is calculated for each page for all the users and the graphs are drawn. Figure 4.1 shows the average network-level page download time for the entire experiment. From the gure the download time for the rst 28 pages is less as there is no delay is applied to the trac shaper. Page 23 has slightly more delay when compared to other pages within the same session. The minimum, average and maximum values are depicted for each page. A similar plot has been drawn for application-level download times which are shown in Figure 4.2. For session 2.4, delay of 310 ms is applied due to which it has maximum download time among other sessions.

4.2.1

Page download times for various network delays:

To understand the relation between the network and application download times the experiments are conducted using 20 dierent users. While browsing the pages the users are allowed to rate the performance of each web page which can be used to study further. The Figure 4.3 shows the graph of network as well as application-level web page download times for all the users without applying any delay at the shaper (0 ms). The maximum and minimum page download times at network-level are 0.45 sec and 0.35 sec. The maximum and minimum page download times at application-level are 0.41 sec and 0.51 sec. The average dierence between the network and application-level page download times is 0.5 sec. Figure 4.4 shows the graph between the users and page download times, in which 75 ms of network delay is applied. As the delay is applied, the pages download time increases. The download times at network-level are

CHAPTER 4. RESULTS

25

3.3 3 Download Time [sec] 2.7 2.4 2.1 1.8 1.5

NW Avg DT App Avg DT

10 User

12

14

16

18

20

Figure 4.4: Network and Application-level average download times for 75 ms delay

6 5.5 Download Time [sec] 5 4.5 4 3.5 3

NW Avg DT APP Avg DT

10 User

12

14

16

18

20

Figure 4.5: Network and Application-level average download times for 150 ms delay

CHAPTER 4. RESULTS

26

8 7.5 Download Time [sec] 7 6.5 6 5.5 5

NW Avg DT APP Avg DT

10 User

12

14

16

18

20

Figure 4.6: Network and Application-level average download times for 235 ms delay

12 11 Download Time [sec] 10 9 8 7 6

NW Avg DT APP Avg DT

10 User

12

14

16

18

20

Figure 4.7: Network and Application-level average download times for 310 ms delay

CHAPTER 4. RESULTS

27

in the range of 2.3 sec to 2.55 sec. Similarly the page download times at application-level are between 2.4 sec to 2.7 sec. It is clear that even though the web pages are same for all the users but the page download time varies from user to user. We have also applied a network delay 150 ms, 235 ms and 310 ms and these delays are applied in dierent fashions i.e. increment and decrement mode. Figure 4.5 describes the response of page download time of the users for 150 ms network delay. It obviously shows that the download time of pages is more than that of previous cases due to more amount of delay that is applied at the trac shaper. Similarly the Figure 4.6 and Figure 4.7 shows the response of page download time for dierent users at both network and application-level for an applied delay of 235 ms and 310 ms respectively. The average download time that is shown in the Table 4.2 is calculated by taking all the 94 pages that are browsed during the experiment. These values are calculated by considering average of all the 20 users. The rst and second column represents the page number and session number. The third is the delay that is applied using the trac shaper. Fourth and fth columns are network-level average download time (NW AVG DT) and standard deviation (NW DT STD) for all the users. Similarly sixth and seventh columns represents the application-level page download time (APP AVG DT) and its standard deviation (APP DT STD). From the table it can be noted that for some web pages the standard deviation is more than other web pages like page number 35, 41, 42 and 43 etc. This is due to the fact that if the download time for one of the user is more than normal time, then it will increase the standard deviation of that particular page. The same is shown in both network as well as application-level.

CHAPTER 4. RESULTS

Page No

Session

APP DT STD

29

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2.1 2.1

Table 4.2: Calculated download times per page Input Delay to NW AVG DT (sec) NW DT STD APP AVG DT (sec) Trac Shaper (ms) 0 0.35 0.126 0.43 0 0.37 0.023 0.41 0 0.34 0.026 0.40 0 0.31 0.007 0.37 0 0.32 0.008 0.37 0 0.31 0.014 0.36 0 0.34 0.011 0.38 0 0.33 0.006 0.38 0 0.33 0.082 0.39 0 0.31 0.063 0.38 0 0.33 0.007 0.37 0 0.33 0.006 0.39 0 0.32 0.014 0.38 0 0.33 0.006 0.38 0 0.32 0.014 0.38 0 0.33 0.009 0.38 0 0.31 0.011 0.38 0 0.31 0.015 0.39 0 0.32 0.011 0.37 0 0.34 0.011 0.38 0 0.32 0.006 0.38 0 0.32 0.007 0.38 0 0.45 0.007 0.53 0 0.32 0.01 0.38 0.19 0.03 0.027 0.009 0.007 0.011 0.069 0.009 0.083 0.012 0.017 0.017 0.030 0.009 0.017 0.022 0.013 0.017 0.015 0.014 0.007 0.018 0.025 0.025

CHAPTER 4. RESULTS

Page No 0.33 0.34 0.32 0.55 2.08 2.41 2.54 2.27 2.66 2.16 4.51 4.50 4.17 5.22 3.98 4.73 8.29 8.57 9.77 8.01 9.26 8.76 7.35 7.50 0.011 0.011 0.007 0.938 0.373 0.253 0.226 0.198 0.163 0.169 1.152 0.415 0.393 0.422 0.326 0.324 1.227 1.642 2.006 0.853 0.622 0.982 0.505 0.453 0.37 0.38 0.37 0.60 2.18 2.52 2.63 2.37 2.76 2.27 4.66 4.66 4.39 5.33 4.20 4.87 8.48 8.97 10.08 8.48 9.52 9.03 7.62 7.81 0.014 0.018 0.006 0.946 0.377 0.255 0.239 0.196 0.161 0.165 1.137 0.451 0.339 0.482 0.305 0.342 1.341 1.563 2.132 0.737 0.752 1.095 0.535 0.325

Session

25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

2.1 2.1 2.1 2.1 2.2 2.2 2.2 2.2 2.2 2.2 2.3 2.3 2.3 2.3 2.3 2.3 2.4 2.4 2.4 2.4 2.4 2.4 3.1 3.1

Input Delay to Trac Shaper (ms) 0 0 0 0 75 75 75 75 75 75 150 150 150 150 150 150 310 310 310 310 310 310 235 235 NW AVG DT (sec) NW DT STD APP AVG DT (sec) APP DT STD

30

Page No

Session

NW AVG DT (sec)

NW DT STD

APP AVG DT (sec)

APP DT STD CHAPTER 4. RESULTS 31 0.840 0.443 0.308 0.446 0.363 0.406 0.216 0.195 1.141 1.093 0.414 0.175 0.144 0.191 0.203 0.268 0.094 0.013 0.014 0.013 0.025 0.021 0.297 0.220 0.686 0.341 0.178 0.605

49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76

3.1 3.1 3.1 3.1 3.2 3.2 3.2 3.2 3.2 3.2 3.3 3.3 3.3 3.3 3.3 3.3 3.4 3.4 3.4 3.4 3.4 3.4 4.1 4.1 4.1 4.1 4.1 4.1

Input Delay to Trac Shaper (ms) 235 235 235 235 150 150 150 150 150 150 75 75 75 75 75 75 0 0 0 0 0 0 75 75 75 75 75 75 6.77 6.99 7.23 7.19 5.05 4.46 4.50 4.49 4.80 5.09 2.60 2.36 2.30 2.38 2.41 2.20 0.72 0.34 0.36 0.34 0.37 0.36 2.32 2.36 2.59 2.45 2.38 2.48 0.879 0.489 0.318 0.443 0.452 0.407 0.216 0.194 1.146 1.095 0.419 0.183 0.143 0.194 0.204 0.266 0.096 0.012 0.014 0.015 0.020 0.019 0.297 0.219 0.677 0.341 0.183 0.553 7.06 7.29 7.50 7.43 5.30 4.64 4.68 4.66 4.98 5.26 2.71 2.47 2.41 2.48 2.51 2.31 0.78 0.41 0.41 0.40 0.43 0.42 2.42 2.47 2.69 2.55 2.47 2.61

CHAPTER 4. RESULTS

Page No 4.37 4.84 4.56 5.05 4.56 4.91 2.85 2.25 2.67 2.34 2.31 2.47 5.59 5.83 5.52 5.44 5.95 5.44 0.575 0.571 0.664 0.348 0.315 1.186 0.288 0.309 0.689 0.297 0.278 0.242 0.550 0.556 0.689 0.649 0.615 0.572 4.55 5.01 4.69 5.22 4.73 5.08 2.94 2.34 2.79 2.47 2.42 2.57 5.88 6.10 5.78 5.63 6.13 5.57

Session

77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94

4.2 4.2 4.2 4.2 4.2 4.2 4.3 4.3 4.3 4.3 4.3 4.3 4.4 4.4 4.4 4.4 4.4 4.4

Input Delay to Trac Shaper (ms) 150 150 150 150 150 150 75 75 75 75 75 75 235 235 235 235 235 235 NW AVG DT (sec) NW DT STD APP AVG DT (sec) 0.573 0.574 0.604 0.347 0.315 1.183 0.293 0.320 0.687 0.241 0.258 0.254 0.503 0.551 0.712 0.606 0.580 0.623

APP DT STD

32

CHAPTER 4. RESULTS
10 9 page download time [sec] 8 7 6 5 4 3 2 1 0 0 75 150 Delay [ms] 225 300

28

NW AVG DT APP AVG DT

Figure 4.8: Average Network and Application download times for dierent delays

4.3

Relation between network and application-level download times:

To correlate the network and application-level download times, we performed the experiment using dierent users and collected the packet traces at network-level. In the basic analysis part we divided the packet traces into dierent les based on dierent parameters such as source port, source IP payload etc. Using this traces we calculated the network-level page download time. We have also measured the application-level page download time using the web browser. This section describes the mapping between both download times in order to calculate the coecient of correlation. Table 4.3: Average download times of the experiment Input Delay at NW AVG DT APP AVG DT tavg (sec) Trac Shaper (ms) (sec) (sec) 0 0.382 0.439 0.057 75 2.415 2.520 0.105 150 4.660 4.833 0.173 235 6.405 6.654 0.249 310 8.780 9.097 0.317 Regression analysis is performed on network and application-level page download times. Table 4.3 shows the average download times at both network and application-level for the mentioned network delays. The fourth column is the dierence between the average application and network-level download times (tavg ). Graph [Figure 4.8] is drawn between the page

CHAPTER 4. RESULTS

33

download times and delay. It shows how network and application download time values are close to each other. From the graph it clear that as the input delay to the trac shaper increases the dierence between network and application download times increases. The more the delay in the transmission network the greater is the dierence between application and network-level download times. In real time networks, the Web trac may experience latency or delay during the transmission. Due to which the service performance degrades. For the network providers, it is dicult to predict the service performance from the user end. The network service providers have access only to their network elements and they can measure the performance at network level. So to bridge the gap, we measure the page download time at both network and application level. We correlated both download times and derived a possible expression. The importance of this study is using this expression, the network operators can predict the behaviour of the user perceived performance by measuring parameters (download time) at network level. Using the computed values from Table 4.3, the network-level and application-level average download times can be written as APP AVG DT = NW AVG DT + tavg

where tavg =

0.05 sec 0.1 sec 0.2 sec

0.3 sec

for 0 ms applied delay for 100 ms applied delay for 200 ms applied delay for 300 ms applied delay

Table 4.4: Relation between network and application download times Regression Correlation Coecient Relation Linear 0.996 Y = 1.031 X + 0.035 Logarithmic 0.916 Y = 2.495 ln(X )+ 1.969 Exponential 0.922 Y = 0.689 exp( 0.337 X ) Power 0.992 Y = 1.1 X 0.965 The regression results are shown in Table 4.4. The table shows all the four linear, logarithmic, exponential and power regressions. The linear regression is strong among the others with coecient of correlation of +0.996. Hence we conclude that both network and application-level download times are linearly correlated to each other.

Conclusions and Future Work

34

Chapter 5

Conclusions and Future Work

5.1 Conclusions

This thesis describes the performance measurements of web page download times at application as well as network-level. In this work, we presented the eect of delay on page download times and investigated the correlations between the network and application download times. On one side we measured the application-level download time using the browser log and on the other side at network-level calculated the download time using the captured packet traces. We investigated and shown that as the delay increases, the page download time gap between network and application-level increases and derived a possible relation. We mapped both the levels of download times and shown that that they are linearly related to each other and calculated the coecient of correlation. Using these expressions and network-level download times, we can evaluate application perceived download times. This relation can also be used as a measure for service providers in computing the performance of the Web trac.

5.2

Future Work

There are dierent key performance indicators which aects the performance of the Web trac. In this work, we considered the delay as the parameter and correlated the page download times at both the layers. This work can be extended by considering the other performance parameters such as packet loss and throughout. We can introduce these parameters in the transmission network and study how these will the inuence the page response time. Using this we can map both levels of trac to nd the relation between them. These relations are very much useful for network providers to oer reliable service to the end users. 35

Appendix

36

Appendix A

Network Diagram

37

APPENDIX A. NETWORK DIAGRAM

38

Consumer

eth-1 10.0.0.214

HP Pro Curve Switch

10.0.1.208

eth-0 10.0.0.215

eth-0 10.0.0.243

eth-0 10.0.0.1

eth-2

eth-1

B if-0

B if-1 eth-1 10.0.1.1

eth-2 194.47.148.77

External XPS Network

User

Traffic Shaper Measurement Point MArC

Figure A.1: Experiment Conguration Network Diagram

Bibliography
[1] Patrik Arlos, Markus Fiedler, and Arne A. Nilsson. A distributed passive measurement infrastructure. In PAM2005, pages 215227, 2005. [2] Yogesh Bhole and Adrian Popescu. Measurement and analysis of http trac. Journal of Network and Systems Management, 13:357371, 2005. 10.1007/s10922-005-9000-y. [3] P. Calyam, D. Krymskiy, M. Sridharan, and P. Schopis. Active and passive measurements on campus, regional and national network backbone paths. In Computer Communications and Networks, 2005. ICCCN 2005. Proceedings. 14th International Conference on, pages 537 542, 2005. [4] Y. C. Chehadeh, A. Z. Hatahet, A. E. Agamy, M. A. Bamakhrama, and S. A. Banawan. Investigating distribution of data of http trac: An empirical study. In Innovations in Information Technology, 2006, pages 1 5, 2006. [5] Denis Collange and Jean-Laurent Costeux. Correlation of packet losses with some trac characteristics. In Steve Uhlig, Konstantina Papagiannaki, and Olivier Bonaventure, editors, Passive and Active Network Measurement, volume 4427 of Lecture Notes in Computer Science, pages 233236. Springer Berlin / Heidelberg, 2007. 10.1007/978-3-540-71617425. [6] I. Din and N.A. Saqib. Passive packet loss detection and its eect on web trac characteristics. In Computer and Electrical Engineering, 2008. ICCEE 2008. International Conference on, pages 729 733, 2008. [7] I. Din, N.A. Saqib, and A. Baig. Passive analysis of web trac characteristics for estimating quality of experience. In GLOBECOM Workshops, 2008 IEEE, 30 2008. [8] J. Garcia, P. Hurtig, and A. Brunstrom. The eect of packet loss on the response times of web services. In Proceedings 3rd International Conference on Web Information Systems and Technologies (WebIST2007), Barcelona, Spain, March 2007. 39

BIBLIOGRAPHY

40

[9] M. Golja, I. Humar, D. Bodnaruk, and J. Bester. Wmpstat: a tool for measuring the correlation between application and network layer trac of streaming video over internet. In Electrotechnical Conference, 2004. MELECON 2004. Proceedings of the 12th IEEE Mediterranean, volume 2, pages 657 660 Vol.2, May 2004. [10] ITU-T SG12. Estimating end-to-end performance in IP networks for data applications. ITU-T Recommendation G.1030, May 2005. [11] Hwa-Jong Kim, Kyoung-Hyoun Lee, and Jie Zhang. In-service feedback qoe framework. In Communication Theory, Reliability, and Quality of Service (CTRQ), 2010 Third International Conference on, pages 135 138, 2010. [12] Igor Velimirovic Andreas Hanemann Andreas Solberg Athanassios Liakopulos Martin Swany Steven Van den Berghe David Schmitz Maurizio Molina, Andy Van Maele, editor. Deliverable DJ1.2.3 Network Metric Report, Project GN2. 14.02.06, EC Contract No : 511082, Document Code GN2-05-265v4. [13] I. Pais and M. Almeida. End user behavior and performance feedback for service analysis. In Intelligence in Next Generation Networks, 2009. ICIN 2009. 13th International Conference on, pages 1 6, 2009. [14] Venkata Santosh Pemmaraju. Real-Time Live RTT Analyzer. PhD thesis, Blekinge Institute of Technology, 2010. [15] Junaid Shaikh, Markus Fiedler, and Denis Collange. Quality of experience from user and network perspectives. Annals of Telecommunications, 65:4757, 2010. 10.1007/s12243-009-0142-x. [16] Ashfaq Ahmad Shinwary. Mapping of User Quality of Experience to Application Perceived Performance for Web Applicaiton. PhD thesis, Blekinge Institute of Technology, 2010. [17] Endace DAG. Packet capture interface cards, [Online; Veried November 2010] Available:. http://www.endace.com/endace-dag-high-speed-packet-capturecards.html. [18] Fasterfox. Performance and network tweaks for refox web browser, [Online; Veried November 2010] Available:. http://fasterfox.mozdev.org/. [19] Henrik Abrahamsson. Internet trac management, Malardalen University, School of Innovation, Design and Engineering 2008. Malardalen University Press Licentiate Theses, ISBN 978-91-86135-08-9; ISSN 1651-9256; 95.

BIBLIOGRAPHY

41

[20] Larry Wall. The perl programming language, [Online; Veried November 2010] Available:. http://www.perl.org. [21] Meinberg : Solutions for Time and Frequency Synchronization. Meinberg ntp software, [Online; Veried November 2010] Available:. http://www.meinberg.de/english/sw/ntp.htm. [22] Mills, D. Network time protocol (version 3) specication, implementation, 1992. [23] Mozilla Firefox Web Browser, [Online; Veried November 2010] Available:. http://www.mozilla-europe.org/en/firefox/. [24] Netem Network Emulation. The linux foundation, [Online; Veried November 2010] Available:. http://www.linuxfoundation.org/collaborate/workgroups/netw-orking/netem.

Master Thesis Electrical Engineering Thesis no: MSE-2010-6977 November 2010

Energy Eciency vs. Quality of Experience

Kiran Kishore Isukapatla Chaitanya Sindhu Sontyana

School of Computing Blekinge Institute of Technology 37179 Karlskrona Sweden

This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulllment of the requirements for the degree of Master of Science in Electrical Engineering. The thesis is equivalent to 28 weeks of full time studies.

Contact Information Authors: Chaitanya Sindhu Sontyana Kiran Kishore Isukapatla E-mail: [email protected], [email protected] University advisor(s): Mr. Junaid Junaid, Ph.d School of Computer Science and Communications/BTH School of Computing Blekinge Institute of Technology 371 79 KARLSKRONA SWEDEN Internet: www.bth.se/com Phone: +46 455 385000 SWEDEN

Abstract
Over the years, there has been an exponential increase in the capabilities of networks, evolving from wired networks to wireless, and nally moving towards 4G networks. This evolution has brought forth many ways in which a user can access any service, particularly accessing the Internet. From emailing and social networking to le transferring, users are on a constant venture to exploit the advantages as much as possible. Predictions show that the demand will only increase with increasing number of mobile devices and subscribers. It becomes more clear that there will be rapid growth in the demand for more energy-ecient mobile devices. However, due to relatively slow increase in the battery technologies, the mobile users expectations were not being met. This thesis highlights few interesting points on the energy consumptions by the most common Internet browsing tasks. It then presents the measurements of energy consumption on using various network connection technologies namely Ethernet, Wi-Fi and 3G to access the Internet. The obtained data from the experiments were then analyzed to arrive at an idea on the dierence in energy consumptions across various browsing tasks and access technologies. Later, it involves a survey through which critical observations with respect to power eciency and QoE are collected. The study concludes with a picture that would help users have an insight on the technologies that they may wish to choose to connect to the Internet. It helps manufacturers understand and consider the aect of an interface on the power consumption. It also helps researchers bring better solutions of designing the network interfaces. The aim would be to reduce the energy consumption by the product components rather than struggling to design powerful batteries to meet the increasing power demands from the network components. A wise choice of networking technologies is or what is may be required to gain better energy eciency.

Keywords: Quality of Experience, Energy Consumption, Li-ion, Battery.

Acknowledgment
First of all, we would like to thank our supervisor, Mr. Junaid Junaid for his valuable guidance and patience throughout the course of our Thesis. We would also like to thank Prof. Markus Fielder for his support in providing literature material and equipment for experiments. We would also like to thank our parents for their ever present support. Lastly, we oer our sincere thanks to all of our friends for their valuable contributions.

ii

Contents
Abstract Acknowledgment i ii

Contents List of Figures List of Tables Introduction

1 Problem Identication 1.1 Introduction . . . . . . 1.2 Background . . . . . . 1.3 Objective of this thesis 1.4 Research Questions . . 1.5 Research Methodology 1.6 Thesis Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

iii v vi 1
2 2 2 2 3 3 4

Analysis
2 Related Study 2.1 Introduction . . . . . . . . . 2.2 Network Technologies . . . 2.2.1 Ethernet . . . . . . . 2.2.2 Wi-Fi . . . . . . . . 2.2.3 3G . . . . . . . . . . 2.3 Energy Ecient Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5
6 6 6 6 6 7 7

iii

2.4 2.5 2.6

Battery Development . . . . . Customer Perspectives . . . . QoE . . . . . . . . . . . . . . 2.6.1 QoE Factors . . . . . 2.6.2 User groups and Tasks

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8 9 9 9 10

Implementation
3 Implementation 3.1 Experimental Setup . . . . . . . . 3.1.1 Conguration and Settings 3.1.2 Network Types . . . . . . . 3.1.3 Browsing Tasks . . . . . . . 3.2 Trial Flowchart . . . . . . . . . . . 3.3 Parameters and Software Tools . . 3.3.1 Parameters . . . . . . . . . 3.3.2 Software Tools . . . . . . . 3.4 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12
13 13 13 14 14 15 15 15 17 20

Results
4 Results 4.1 Introduction . . . . . . . . . . . . . 4.2 Energy Consumption Comparison 4.2.1 Idle Mode . . . . . . . . . . 4.2.2 Browsing Tasks . . . . . . . 4.3 Survey Results . . . . . . . . . . . . . . . . . . . Time Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21
22 22 22 22 24 27

5 Conclusions 33 5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2 Future Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Appendix
A Experments and Results A.1 Survey Data . . . . . . A.2 Energy Consumptions A.3 Discharge Curves . . .

35
Data 36 . . . . . . . . . . . . . . . . . . . . . . 36 . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . . . . . . . . . . . . . 50

Bibliography

54

iv

List of Figures
3.1 3.2 3.3 3.4 3.5 3.6 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 Task Flowchart . . . . . Charge/Discharge Curve BatteryMon . . . . . . . BatteryMon Log File . . Imtec Battery Mark . . BatteryCare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 17 18 18 19 19 23 23 24 25 26 26 28 28 29 30 31 31 32 51 52 53

Discharge Rate . . . . . . . . . Idle Mode Energy Consumption Ethernet Energy Consumption Wi-Fi Energy Consumption . . 3G Energy Consumption . . . . Browsing Tasks . . . . . . . . . Network Usage . . . . . . . . . Preference . . . . . . . . . . . . Quality Parameters . . . . . . . Willingness . . . . . . . . . . . Browsing Time . . . . . . . . . Battery Backup . . . . . . . . . Battery Upgradation . . . . . .

A.1 Discharge Rate (Ethernet) . . . . . . . . . . . . . . . . . . . . A.2 Discharge Rate (Wi-Fi) . . . . . . . . . . . . . . . . . . . . . A.3 Discharge Rate (3G) . . . . . . . . . . . . . . . . . . . . . . .

List of Tables
2.1 3.1 3.2 4.1 4.2 4.3 User Groups and tasks . . . . . . . . . . . . . . . . . . . . . . Laptop Conguration . . . . . . . . . . . . . . . . . . . . . . Types of Networks . . . . . . . . . . . . . . . . . . . . . . . . Network Usage Vs User Preference . . . . . . . . . . . . . . . Quality parameters . . . . . . . . . . . . . . . . . . . . . . . . Time spent on Browsing Vs Battery Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13 14 29 30 32 37 37 37 37 37 39 39 40 40 41 41 42 42 43 43 44 44 45 45 46 46 47 47 48 48

A.1 Network Usage . . . . . . . . . . . . . A.2 Preference . . . . . . . . . . . . . . . . A.3 Quality Parameters . . . . . . . . . . . A.4 Willingness and Battery Upgradation . A.5 Browsing Time . . . . . . . . . . . . . A.6 Idle Mode: Ethernet . . . . . . . . . . A.7 Idle Mode: Wi-Fi . . . . . . . . . . . . A.8 Idle Mode:3G . . . . . . . . . . . . . . A.9 Gmail:Ethernet . . . . . . . . . . . . . A.10 Gmail:Wi-Fi . . . . . . . . . . . . . . . A.11 Gmail:3G . . . . . . . . . . . . . . . . A.12 YouTube 720p:Ethernet . . . . . . . . A.13 YouTube 720p:Wi-Fi . . . . . . . . . . A.14 YouTube 720p:3G . . . . . . . . . . . A.15 YouTube 360p:Ethernet . . . . . . . . A.16 YouTube 360p:Wi-Fi . . . . . . . . . . A.17 YouTube 360p:3G . . . . . . . . . . . A.18 Game:Ethernet . . . . . . . . . . . . . A.19 Game:Wi-Fi . . . . . . . . . . . . . . . A.20 Game:3G . . . . . . . . . . . . . . . . A.21 Download:Ethernet . . . . . . . . . . . A.22 Download:Wi-Fi . . . . . . . . . . . . A.23 Download:3G . . . . . . . . . . . . . . A.24 Upload: Wi-Fi . . . . . . . . . . . . . A.25 Upload: 3G . . . . . . . . . . . . . . .

vi

A.26 Upload:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . .

49

vii

Introduction

Chapter 1

Problem Identication
1.1 Introduction

Networking through mobile devices like laptops is in enormous use in the recent years. It has become more of a necessity than as an accessory as there is an increase in the diversication in the types of services provided. This diversication of services coupled with the diversication of networks themselves have opened up unlimited opportunities to the mobile user which he/she could exploit to the maximum advantage.

1.2

Background

With the rise in mobile networking should be rise in the number of mobile devices and power to them. However, advancements in battery technologies havent been showing the same type of success [1]. Particularly where mobile devices are concerned, constraints such as limited size, low heat dissipation, increasing mobile device capabilities have been showing more pressure on the chemists to develop better batteries [2]. This is more evident in the most commonly used mobile devices such as laptops and smart phones [3]. They are not anymore mere low-computational mobile devices but are with extreme capabilities of processing and networking with the ability to access almost any type of network. However, they are on a constant look for power to go on and continue to stay on. From here, comes the need to study the energy consumption levels in mobile devices due to dierent network connections and correlate with Quality of Experience (QoE) to see the impacts.

1.3

Objective of this thesis

The study is a search for better choice among the mostly used network technologies with respect to energy consumption. Features related to battery capacities and fading of the gap between network connection technologies 2

CHAPTER 1. PROBLEM IDENTIFICATION

has been the main motive towards this thesis. The research helps developing a better understanding for device manufacturers and more importantly to mobile networking devices users to make a choice in preferring a network connection technology. It is now known that the current host-centric mobile networking paradigm is based on always-on end-to-end connectivity which leads to energy ineciency. To conclude, the article introduces some useful information on networking choices and highlights few open research issues in the selection of energy ecient future network architectures.

1.4

Research Questions

1. Is there any aect of a network interface on the energy consumption by a mobile device? 2. If the answer to the above question is yes, what is the aect and to what degree? 3. Is there a variation in energy consumption with dierent tasks performed on the Internet? 4. If the answer to the previous question is yes, are there some interesting observations? 5. Are there any important factors considered by users that aect QoE in choosing a network?

1.5

Research Methodology

In the thesis, two approaches were used where one is a qualitative study and the other one being quantitative. In the qualitative study, a subjective questionnaire to the users is followed by a deep look at the literature. Coming to quantitative approach, an empirical study with experimental setup was carried on. The objective of this thesis is rstly, to measure the energy consumptions in laptop while using dierent network connection technologies to access the Internet. Secondly, to perform various, most commonly used browsing tasks with each of the network type and measure the respective energy consumptions. Last but not the least, to consider certain important QoE parameters that helps understand the mobile devices user expectations by conducting a survey. Finally, to analyze the obtained measurements and where possible, correlate the ndings and to draw a few useful conclusions.

CHAPTER 1. PROBLEM IDENTIFICATION

1.6

Thesis Layout

The remainder of the document is organized as follows. Chapter two gives an overview on the various networks and network interfaces. This chapter also contains the various QoE factors that are considered while choosing a particular network interface. It also points out the common tasks by various user groups associated with dierent network interfaces. It later discusses about the battery technologies and its potential to provide the demanded power sources to the mobile devices. Chapter three provides an understanding of the experimental setup which includes the tools that were used. It discusses about the various tasks that were chosen to perform and study for the results and analysis. It also explains the conditions and network environment under which the experimentation was carried out. The chapter also contains the information about the survey targeted to the various user groups. Chapter four discusses about the results and analysis. The chapter also shows the results obtained from survey led by the participants. The last chapter contains the observations and hence the conclusions from the results obtained. It also discusses about the future scope in the relevant context to further study and analyze the power consumptions by dierent network connection technologies.

Analysis

Chapter 2

Related Study
2.1 Introduction

In this chapter, the most familiar types of networks are listed with their supported speeds. Since every type of network has several dierent energy ecient technology implementation proposals, a few of them are listed later in the chapter. Following this, current battery technologies and limitations were shown. Finally, the chapter concludes with a brief discussion about the various critical QoE parameters of the Internet.

2.2

Network Technologies

There are dierent kinds of technologies available to users to connect to the Internet using any networking capable device. There most widely used technologies among these are Ethernet, Wi-Fi and 3G. However, a network device needs special equipment or provision to be able to connect to a network type. This is termed as Network Interface and is further used in the document for reference.

2.2.1

Ethernet

An Ethernet LAN typically uses coaxial cable or special types of twisted pair wires. The most commonly used Ethernet systems are known as 10BASE-T with transmission speeds up to 10 Mbps. Fast Ethernet or 100BASE-T have transmission speeds of up-to 100 megabits per second. Gigabit Ethernet is a transmission technology based on the Ethernet that provides a data rate of 1 billion bits per second.

2.2.2

Wi-Fi

Wi-Fi is the name for the wireless Ethernet 802.11b standard for WLANs. It supports data rates of up-to 11 Mbps within distances of up-to 150 meters. 6

CHAPTER 2. RELATED STUDY

The maximum rate for Wi-Fi (11 Mbps) can only be achieved within a certain range of the transmitter.

2.2.3

3G

3G is a wireless technology with data rates from 384 Kbps up to 2Mbps, although most commercial deployments are only expected to oer data rates of 100Kbps in practice. There are various implementations in 3G like UMTS and HSDPA which support higher data rates which may reach up-to 14.0 Mbps. Further increases in speed is available with HSPA+, which provides speeds of up to 42 Mbps down-link and 84 Mbps.

2.3

Energy Ecient Technology Proposals

Since the battery technology has not been improved as much as the semiconductor technology, power ecient system designs and implementation has become extremely important in todays mobile networking world. It is to be noted that the radio interfaces, including Wi-Fi, Bluetooth and cellular communications account for more than 50% of the overall system energy budget. Hence, energy eciency has been on a constant demand for battery driven wireless mobile communications. Recent studies have shown that the power consumption of ICT is approximately 4% of the annual energy production [4]. The global IP trac has a compound annual growth rate of 34%, quadrupling from 2009 to 2014 [5]. Moreover, the wireless world research forum (WWRF) has a vision of 7 trillion wireless devices serving 7 billion users by 2017 [6]. This indicates that the power consumption of wireless access networks is going to become an important issue in the coming years. The energy consumption of network elements has become more and more important, with growing concern for the Internet power consumption and heat dissipation in mobile network devices like laptops. Previous work has been on energy ecient wireless topologies, network nodes, routers, and protocols [7]. Initially, there were new and more energy ecient technology proposals on the Ethernet [8, 9, 10]. While eorts were made to develop or propose these energy ecient Ethernet technologies, it was also made sure that the performance of the network is not degraded [11]. Emergence of Wi-Fi interfaces in almost every networking device allows users to take full advantages of heterogeneous radio technologies. However, it was not originally designed for energy-constrained devices. As a result, the stand-by times of such devices with a Wi-Fi interface are signicantly lower [12]. There are two basic categories of methods to make Wi-Fi or other high energy-consuming network interfaces more energy-conservative. The rst category of methods, modies the Wi-Fi and/or upper layer protocols to make the protocols themselves more energy-conservative [13, 14, 15]. A

CHAPTER 2. RELATED STUDY

survey of energy-ecient network protocols for wireless networks is available in [15]. This category of methods requires changes to widely accepted and deployed protocols and products. The second category of methods does not change the networking protocols, but instead seeks to minimize the unnecessary consumption of energy by the high energy consuming network interfaces. These include turning o the interfaces, or turning the interface into a low-energy consuming state if possible, during time periods that the interface is not used to carry user trac [16]. Many studies have followed for every kind network constantly thriving to increase the back up times of the mobile devices on battery power. However, it was not always easy to implement such proposals due to several constraints like compatibility, universal acceptance and hardware support.

2.4

Battery Development

While there were constant eorts made to develop energy ecient technologies, parallel eorts were also in place to develop batteries that power these devices. Since most laptop users prefer an almost continuous operation of their laptops as per the situation demands, they are forced to use AC power to operate the laptops and also continuously charge the battery pack. Limitations of Lithium Ion batteries Lithium is the lightest among all the metals with great electrochemical potential and also provides the largest energy density per weight. Therefore Li-ion is rapidly growing and has proved to be most promising battery chemistry. However, the technology has few limitations listed below. Power density One of main concerns, power density, was a huge limitation in Lithium Ion battery technology in the 90s. Though the technology has drastically changed the way the Lithium Ion batteries are constructed in current times, constant demand from the users for more power kept demanding for more and more with no specic satisfactory levels to be met. As the current capacities have not been able to provide such demands, we can say that the Power density is one of the factors restricting the vendors from manufacturing such batteries. Contingencies Users have been growing continuously with constant rise of expectations for long performance time intervals without self discharge and multiple years of service before any replacement. In respect to these demands, Lithium-ion

CHAPTER 2. RELATED STUDY

batteries seem to be meeting the performance challenge of some power products, so the maximum we can ask of competitive chemistries is equivalent power densities at reasonable and comparable costs. Cost The cost eectiveness, durability and environmental friendly nature of the lithium-ion batteries made them a very popular choice for portable power. However, th limitations on their cell sizes, relatively expensive accessories and an up-front cost might be daunting for an average consumer.

2.5

Customer Perspectives

According to ICT statistics for year 2009, 25.9% of worlds population are Internet users. Moreover, 9.5 % of worlds population are mobile broadband subscriptions and 7.1 % are of xed broadband subscriptions [17]. This shows the potential of mobile internet which has overtaken the xed broadband subscriptions. But, according to a global study [18] conducted by Nokia Siemens networks mobile broadband, users are up to 22% less satised with the connectivity when compared to xed broadband users. There are many services that are available through the Internet regardless of what network interface that is being used. Choosing a type of network depends on the suitability of a service to that network. However, suitability of a service is a user specic phenomenon depending on ones needs and priorities. An example would be online banking. For a user who travels a lot, mobility would be a crucial factor in deciding what type of network he would use. So, based on his need for mobility, online banking would be better suited to mobile broadband than xed broadband because mobile broadband provides greater mobility. Taking network technologies into account certain QoE factors related to user(customer) perception were studied which are listed below. Network resources and pricing were also considered for the literature.

2.6

QoE
Quality of Experience (QoE) has been dened as an extension of the traditional quality of service (QoS) in the sense that QoE provides information regarding the delivered services from an end-user point of view.[19]

2.6.1

QoE Factors

The scenario of present battery technology, particularly in laptops is, the capacity of the battery is directly proportional to the weight of the battery

CHAPTER 2. RELATED STUDY

10

[20]. Taking this weight-capacity relationship into account, few critical QoE factors were considered. Accessibility Since most of the mobile devices (laptops, etc) these days have more than one network interface, the accessibility will vary over dierent interfaces for a particular user. If accessibility between two wireless technologies such as Wi-Fi hot spots and 3G networks are compared, then there coverage area has to be taken into picture. As the coverage area of a Wi-Fi hot spot is less than that of a 3G network, user has greater mobility in 3G compared to that in Wi-Fi. However, for a xed broadband, accessibility cannot be considered since it is a wireless QoE factor [21]. When the weight-capacity relationship is taken into context, mobility is going to be aected which is more in the case of 3G than Wi-Fi. Therefore itll be worthwhile to know how important accessibility is to particular user based on his daily usage. Instantaneity Instantaneity deals with the duration in which data is transferred and received [21]. How long was the duration of a particular session, and how much time did it take to establish a connection. The survey showed that mobile broadband users have 14% lesser satisfaction level in web browsing activity than xed broadband users due to many factors such as slower webpage loading [22]. In the context of weight-capacity relationship, Since a user can only browse for a limited period (due to limited capacities), speed of a particular network can be a crucial factor which determines how much time does a user browse the internet. Integrity Integrity deals with the success rate with which the data is transferred from one end to the other [21]. In the case of video streaming, success rate is a crucial factor because multimedia coding is highly correlated to the eects of loss on the perceived QoS [23]. As a result, comparing the energy consumptions of same quality videos on dierent types of networks will yield useful observations. Cost was also considered in the study as it is one among the crucial factors in choosing a type of network.

2.6.2

User groups and Tasks

Based on the QoE factors which were mentioned above, user groups and type of service/tasks were assigned to each interface which is shown in the table below [24].

CHAPTER 2. RELATED STUDY

11

Table 2.1: User Groups and Tasks Network Type User Group Tasks Ethernet Home and Oce All Tasks Users. Wi-Fi Laptop/Portable All Tasks device Users 3G Travelers, Mobile Gmail, Users Browsing

Light

Mobile broadband has some advantages that are appealing to a certain section of users who perform light browsing tasks such as emailing, on-line shopping and on-line banking. So, for users who are traveling a lot, mobile broadband is the best option when factors such as no line rental, lack of mobility are concerned. but, on the ip side, the mobility is restricted only to good coverage areas. The cost factor should also be considered because even though with newer 3G technologies such as HSDPA(high speed download packet access) which are oering speeds greater than 6 Mbps, only a few can aord the pricing. And with the combination of lower data capacities and higher pricing (compared to xed broadband) it would repel even those who could aord it. For a majority of the Internet users, tasks range from emailing, online shopping to watching on-line videos and transferring large les. But, when compared to on-line shopping and emailing, tasks such as watching YouTube videos or le hosting/sharing websites require more bandwidth and data capacities for better performance. So, for heavy internet usage, having a xed broadband connection would be more sensible.The quality of video and the size of a le also plays an important role.

Implementation

12

Chapter 3

Implementation
3.1
3.1.1

Experimental Setup
Conguration and Settings
Table 3.1: Conguration of Component Processor Internal Memory Operating System Wireless Network Adapter Ethernet Card Battery Packard Bell-EasyNote TJ75 Specications Intel Core i5 @ 2.27 GHz 4 GB RAM Windows 7, 64-bit Atheros AR5B93 Broadcom Gigabit Chemical Composition Li-ion, Model Panasonic AS09A51, Capacity=48600 mWh

For this experiment, Packard Bell-EasyNote TJ75 was used with specic processing and networking congurations as mentioned in Table 3.1. Therefore, the energy consumptions of the tasks are specic to these specic congurations and settings. It should be noted that the experiment was conducted on a new laptop which eliminates any negative eects that might occur with older or outdated equipment such as operational and battery conditions. All the trials of the experiment were conducted on Windows 7 balanced power plan which regulates the energy consumption on the battery accordingly. However, in order to maintain a balance between the energy consumption of the screen and proper browsing experience, medium brightness level was chosen throughout the experiment. All the trials of the experiment were conducted on Firefox browser[?]. Browser preferences such as browser.cache.memory.enable and browser.cache.disk.enable were set to

13

CHAPTER 3. IMPLEMENTATION

14

false in order to disable browsing caching. By disabling browser caching, accurate analysis of results can be done because the browser makes HTTP request every time the task is conducted. It was made sure that all non Operating System applications were prevented from running during the experimentation. The only applications which were running during the trials were critical system processes, browser application and the battery tools.

3.1.2

Network Types

Three types of networks were considered in this experiment. The trials using Ethernet and Wi-Fi networks were conducted on campus (SUNET/NORDUnet) and residential (BAHNHOF AB) networks. For 3G network, Telenor subscribed Huawei Technologies Co., Ltd. E220 HSDPA USB Modem modem was used. Table 3.2: Types of networks and corresponding Network Type ISP Ethernet BAHNHOF AB, SUNET/NORDUnet Wi-Fi BAHNHOF AB, SUNET/NORDUnet 3G Telenor ISPs with network speeds Speed Downlink: 95 Mbps and Uplink: 24 Mbps Downlink: 10 Mbps and Uplink: 9 Mbps Downlink:2 - 5 Mbps and Uplink: 0.35 Mbps

3.1.3

Browsing Tasks

The tasks selected for this experiment were chosen based on certain criterion. for the trials, browsing tasks were considered since in the Nokia Siemens survey it was mentioned that web browsing is the most activity on the Internet. The web browsing activities were divided into tasks such as video streaming, downloading and uploading, email browsing and online gaming. Video streaming was done using YouTube360p and YouTube720p [25] while downloading and uploading is done using popular le sharing website www.mediare.com[26]. For email browsing Gmail [27] was used and nally online gaming from www.miniclip.com [28]. These tasks were simple to perform repeatedly and take few minutes for task duration. The URLs for all these websites were stored in a notepad since browser caching was disabled. The tasks are as follows: 1. Idle Mode task: In this task, the trial was conducted without conducting the browsing tasks. Only the battery tools and OS applications were running in the background to see how much energy was consumed by these processes alone.

CHAPTER 3. IMPLEMENTATION

15

2. Gmail: Login into the account, read the rst mail, reply to an email, logout. 3. YouTube 360p: Paste the link in address bar and press enter, watch the video in full-screen mode at 360p resolution. 4. YouTube 720p: Paste the link in the address bar and press enter, select the HD resolution of 720p, watch the video in full-screen mode. 5. Online game: Paste the link in the address bar and press enter, play the game for the given duration and stop. 6. Download: Paste the link in the address bar and press enter, download the le for the given duration and stop. 7. Upload: Paste the link in the address bar and press enter, upload the le for the given duration and stop.

3.2

Trial Flowchart

From the gure 3.1, colored part of the ow chart indicates the part of trial where the task is being performed. It can be seen that all tasks were performed for a xed duration of 5 minutes. For each task, 15 trials were performed, which makes the total trials to 105 trials. Before each trial, it was made sure that the battery charge was a 100%. All the trials were conducted in the range of 100% to 90% of battery capacity (refer Fig 3.2) since the voltage of the battery during this range is maximum. This region is above the mid-point voltage (MPV) where the voltage is 50% of its total capacity [29]. Moreover, the reason for choosing this range is that a laptop user is more likely to use the laptop on battery than at lower percentage capacities, where he is more likely to use the A/C power source.

3.3
3.3.1

Parameters and Software Tools

Parameters

The following parameters were analyzed in the experimentation to understand the eect of the tasks on the energy consumption through dierent network interfaces. 1. Discharge rate: The rate at which the battery is being discharged. Units are in mWh which means Milli watt hours, a standard unit for energy production and consumption [30] (1000 Wh= 3.6 megajoules). It is used in electrical appliances etc.

CHAPTER 3. IMPLEMENTATION

16

Figure 3.1: Experimentation Process Flowchart

CHAPTER 3. IMPLEMENTATION

17

Figure 3.2: Charging and Discharging of the Battery with Time in Terms of Voltage 2. Current capacity: The current amount of charge left in the battery. Units: mWh. 3. Download and upload speed: Measuring the download and upload speed for the link during the particular session. Units: Mbps.

3.3.2

Software Tools

BatteryMon V2.1 This software tool was used to measure discharge rate, current capacity and time remaining before complete discharge, during the period of the trials. It has a graphical interface where it is possible to see the instantaneous measurements of discharge rate, remaining time and current capacity. A sample screen with the information from tool may be seen in Fig 3.3. It also generates log les as in Fig 3.4 containing instantaneous values of above mentioned parameters which were used for plotting graphs and calculation purposes [31]. During the task duration, the Runtime on the graphical interface (which displayed the time spent on battery) was used to maintain the xed duration of 5 minutes for each trial. Two other softwares were also used to verify the values of Batterymon.They are mentioned in the next section. The start and stop buttons are used for recording the measurements into the log le. Num Samples indicates the number of sample measurements being registered into the log le. For every second, each set of values will be registered into the designated log le.

CHAPTER 3. IMPLEMENTATION

18

Figure 3.3: Graphical Interface of BatteryMon

Figure 3.4: BatteryMon Log File

CHAPTER 3. IMPLEMENTATION

19

Figure 3.5: Plots of Imtec Battery Mark

Figure 3.6: Visual Display of BatteryCare Imtec Battery Mark V1.1 Imtec battery mark also has a graphical interface as shown in Fig 3.5 which displays percentage capacity plot against time in real time [32]. However, unlike BatteryMon, Imtec Battery Mark has the option of saving the plots for each trial. Therefore, along with BatteryMon, Imtec was also run for the purpose of saving these plots. BatteryCare V0.9.8 An other software called BatteryCare was used as a backup for verifying values of the parameters with that of the BatteryMon during the trials[33]. A sample le with the information from this software can be seen in Fig 3.6.

CHAPTER 3. IMPLEMENTATION Speed Test

20

www.speedtest.net [34] website was used to calculate both the up-link and down-link speeds. The website was used either before or after a trial. The purpose of noting the up-link and down-link speeds was to see whether they had any eect on the energy consumption during a particular task on a particular interface. MS Excel MS Excel was used for plotting the discharge rate curves, energy consumptions for particular tasks for a particular interface by importing the raw data from the log les generated by BatteryMon.

3.4

Survey

An on-line survey was conducted on www.surveymonkey.com with 63 on-line participants. All types of user groups are targeted in the survey. They are all laptop users and belonging to various proesions ranging from students to employees. The QoE section was framed using the most important quality parameters in the context of network access [35]. Following are the questions posed to the users through the Survey: 1. Network Usage: Participants most used network for Internet browsing. 2. Network Preference: Participants most preferred or suitable type of network based on their browsing habits. 3. Quality Parameters: Which parameters are important to him for a quality browsing experience. 4. Willingness: Willingness to change to another type of network for lesser energy consumption. 5. Browsing Time: Participants time spent on browsing per day. 6. Battery Backup: How much time does the participants battery last. 7. Battery Upgradation: Is the participant willing to upgrade his battery?

Results

21

Chapter 4

Results
4.1 Introduction

The results from the experiments conducted are discussed and analyzed in this chapter. Energy consumption using dierent interfaces in mode as well as by running all the browsing tasks are listed and explained in the following sections. The chapter also contains results from a survey that was conducted on-line with 63 participants.

4.2
4.2.1

Energy Consumption Comparison - Time Based

Idle Mode

From Fig 4.1, the discharge rate curves of a battery in Idle mode operation is shown. It can be observed that the discharge rate caused by all networks is almost equal during the initial stages. However, with the increase in time there are gradual variations in the discharge rate caused by the three networks. This happens even if the network interfaces are not being used for data transfer. Therefore, the power that has been consumed should ideally be due to only the standard processes and applications. However, mere power ON state of the network interface alone has caused a dierence in the usage. This can be observed from the g 4.2. If turning ON of the network interface (without using it) had no eect on the energy consumption in the idle state, the discharges rates should have been similar in all cases. Hence our rst and foremost critical observation is that the USB network interface causes the highest energy consumption even when it is not being used for network access. Of the three interfaces that we have experimented on, the wired interface causes the least energy consumption when it is on,followed by Wi-Fi as observed in g 4.2.

22

CHAPTER 4. RESULTS

23

Figure 4.1: Comparison of Discharge Rates of the Battery

Figure 4.2: Energy Consumption in Idle-Mode with Network Connections Enabled

CHAPTER 4. RESULTS

24

Figure 4.3: Ethernet Energy Consumption on Ethernet

4.2.2

Browsing Tasks

In this section, energy consumptions of the tasks were measured and compared for each network connection type.

Ethernet From Fig 4.3, it may be observed that the YouTube 720p task is the highest energy consuming browsing task. After YouTube 720p, it was YouTube 360p which consumed higher energy followed by Online gaming. This is followed by Gmail and Upload tasks while Download task consumed the least. It should be observed in the gure that there is another lower energy consumption of all which is when the computer is at Idle state. This is obvious as there are no browsing tasks running at this stage and therefore, the network interface is not used to send or receive any data.

Wi-Fi From Fig 4.4, it may be observed that the YouTube task running at 720p resolution has caused the highest discharge. After YouTube 720p, it was

CHAPTER 4. RESULTS

25

Figure 4.4: Energy Consumption on Wi-Fi YouTube 360p which has caused higher discharge followed by online gaming. The upload task has caused relatively lesser discharge than online gaming. The lowest discharge was during Download task followed by Gmail access. Even though the value of energy consumptions of download and idle mode are equal, download task has higher standard deviation than that of idle mode which may be seen in tables A.7 and A.22. Therefore, it could be concluded that download task does consume more energy than the idle mode.

3G From Fig 4.5, it can be observed that online game, YouTube 360 and YouTube 720 caused the highest discharge rate. The upload task has caused relatively lesser discharge than online gaming. The lowest discharge was during Download task followed by Gmail access. From these results, it is observed that the graphic rich tasks have always caused highest discharge rates in all the network types.

Overall Comparisons From the energy consumptions gures that were obtained during various browsing tasks, it was found that graphic-rich tasks have the highest con-

CHAPTER 4. RESULTS

26

Figure 4.5: Energy Consumption on 3G

Figure 4.6: Energy Consumption by Browsing Tasks on the 3 Types of Networks

CHAPTER 4. RESULTS

27

sumption rate. It was seen that in every interface and in each experiment, YouTube 720p, YouTube 360p and online games were causing more discharge of the battery. The least energy consumption state with each interface turned on is the Idle state. Other tasks that consumed lesser energy are Gmail, Download and Upload tasks on the Internet. It can be observed from the gure that the order of energy consumptions by various tasks has almost remained the same across interfaces. Speaking about the interfaces alone, it can be concluded that 3G is the highest power consuming network interface followed by Wi-Fi. The least energy consuming network interface has proven to be Ethernet. This can also be observed in the Fig 4.6. This is for overall picture.

4.3

Survey Results

In this thesis, a survey has been conducted in relation to the networks that are tested and a few important network QoE parameters. It was an on-line survey posted on www.surveymonkey.com with a total of 63 participants. All types of user groups were targeted in the survey in which most of the participants are laptop users. The users belong to various professions ranging from students to employees. The following subsections discuss about the results obtained through the Survey.

Usage From the survey conducted as seen in Fig 4.7, it was determined that Wi-Fi networks are most commonly used networks. This is followed by Ethernet. The least number of users are connected through 3G for Internet connectivity.

Preference As the Fig 4.8 shows, it was found that most of the users prefer to use wireless network technologies to wired networks. Among Wi-Fi and 3G, the later is of greater preference. This is a nding from the survey where a small percentage of users who are currently on Wi-Fi prefer to use 3G. This can be clearly attributed to the mobility factor that these technologies has to oer. A comparison between current usage and network preferences can be observed in Table 4.1. It should be noted that most of the participants of the survey were familiar to all types of networks. Therefore, each participant was asked about the level of usage/preference for each type of network, based

CHAPTER 4. RESULTS

28

Figure 4.7: Network Usage

Figure 4.8: Preference of Network

CHAPTER 4. RESULTS

29

Figure 4.9: Quality Parameters of a Network on their daily internet activity. It ranges from Never Used to Always. The values in the Table 4.1 therefore shows the percentage of the entire survey group for each type of network. The % Change column shows the dierence between usage and preference which indicates the demand of a network type.

Table Network Ethernet Wi-Fi 3G

4.1: Comparison of Network Usage and User Preference % Usage % Preference % Change 85.71% 68.25% 17.4% decrease 96.83% 88.89% 7.9% decrease 44.44% 65.08% 20.6% increase

Quality Parameters From Fig 4.9, it has also been found from the survey that speed and availability of a network are two very important parameters that users look for while choosing a network. These are followed by ease of access and cost of accessing a network . The order of preference for various quality parameters considered while choosing a network can be found from Table 4.2.

CHAPTER 4. RESULTS

30

Table 4.2: Quality parameters Parameter %Importance Speed 68.25% Availability 58.73% Ease of Access 46.03% Cost 31.75%

Figure 4.10: Willingness to use an other Network Willingness From Fig 4.10, One of the interesting nding from the survey was that many users are willing to use an other type of network if it consumes lesser energy. The percentage of users in this category is as high as 65%.

Browsing Time From the survey result shown in Fig 4.11, it was found that almost 50% of the users would use the Internet for more than 4 hours. This is on battery power on any given day.

Battery Backup It was also found as Fig 4.12 shows, that very less number of users get a battery backup of more than 4 hours. Clearly, it is observed that most users would like to have more battery backup. Various browsing time and battery backup times can be seen from Table 4.2. This clearly shows that only 16% of the users get a satisfactory battery backup.

CHAPTER 4. RESULTS

31

Figure 4.11: Time spent browsing on battery

Figure 4.12: Battery Backup on most Laptops

CHAPTER 4. RESULTS

32

Table 4.3: Time spent on Browsing Vs Battery Backup Duration %Browsing time %Battery Backup < 1 Hour 16% 8% 1-2 Hours 21% 40% 2-4 Hours 16% 36% >4 Hours 47% 16%

Figure 4.13: Battery Upgradation Battery Upgradation It is very interesting to observe from Fig 4.13, that almost 80% of users are considering battery up-gradation. This is due to higher browsing times and low battery backups as seen earlier.

Chapter 5

Conclusions
5.1 Conclusion

In this thesis work we have analyzed the eect of various network types on the energy consumption in laptops. The behavior of the battery is studied and analyzed in various scenarios including dierent browsing tasks. Later a survey was conducted for QoE ratings and a mapping has been carried out with the results from the experiments. An experimental test-bed was developed and the energy consumption was observed using Ethernet, Wi-Fi and 3G to connect to the Internet. From the analysis, it is found that 3G is the highest energy consuming network. Looking at the commonly used browsing tasks, it was determined that the graphic-rich browsing tasks have consumed the highest energy. In the survey conducted, it was seen that speed and availability of a network has been of the highest priority to users for considering a network. However, these quality parameters have the lowest values with higher power consumption in 3G networks. It was known that the best of 3G has supporting data rates much lesser when compared with Ethernet and Wi-Fi. The quality of experience rating on 3G networks is not up-to Ethernet and Wi-Fi. To conclude on the energy consumption note in 3G networks, it is the highest player. It was found from the survey that as much as 20.6 % increase in the preference of 3G users from Ethernet and Wi-Fi if the network provision is available. This can be attributed to the mobility factor with 3G connections. However, few users from this group might as well look for a speedy connection and lower power consumption. As it is already known, 3G has the highest power consumption and not so high network speeds compared to Ethernet and Wi-Fi. The worst impact will be on users who are willing to move towards 3G networks and are prepared to use services such as video

33

CHAPTER 5. CONCLUSIONS

34

streaming sites like YouTube which have diverse applications to all types of users ranging from vlogging to on-line classes. It could also be stated that more number of users as high as 65 % are willing to shift to an alternate network if it consumes relatively lesser power. It is also seen that almost 50 percent of the users use the Internet for more than 4 hours per day on battery power. However, from the survey it was known that this is not being met. In fact, users who could get battery backup of more than 4 hours is as low as 16%. It is interesting to observe that almost 79% of users have plans to upgrade their batteries as the backup time is not being met. However, current battery technologies have their own limitations in meeting such high numbers being demanded. Therefore, it can be concluded that users could be made aware of the power consumptions of various networks. This would give them a better idea about what options they get to choose before selecting a particular network. In this way, users could be encouraged to use Ethernet more, whenever and wherever possible. This meets the users expectations like able to get more battery backup and at the same time keeping the QoE standards high.

5.2

Future Scope

Our thesis includes calculating energy consumptions on three types of networks and correlating with survey results based on basic QoE questions. Future scope could be more specic where dierent protocols from all the layers of OSI model could be compared to nd out energy ecient protocols. The study can be extended to protocol levels and component level analysis. The experiments may be conducted in an environment, where the measurements are obtained from electronic equipment rather than software. This would enable one to extend the tasks to longer periods with precise measurements and observations. A deeper study may be carried out to drill down onto the reasons for dierence in energy consumptions across network technologies.

Appendix

35

Appendix A

Experments and Results Data

A.1 Survey Data

36

APPENDIX A. EXPERMENTS AND RESULTS DATA

37

Network Usage Ethernet Wi-Fi 3G

Table A.1: Network Usage Never Occasionally Frequently 8 30 13 2 4 14 26 20 4

Always 11 43 4

Preference Ethernet Wi-Fi 3G

Table A.2: Preference Never Occasionally Frequently 7 21 13 0 3 12 12 20 12

Always 12 46 9

Table A.3: Quality Parameters Parameter NOT IMP LEAST IMP IMP Speed 1 1 17 Availability 0 7 18 Ease of Access 7 10 17 Cost 12 10 21

V IMP 43 37 29 20

Table A.4: Willingness and Battery Upgradation Willingness Battery Upgradation YES 41 50 NO 22 13

Table A.5: Browsing Time Battery Backup Browsing Time < 1 Hour 5 10 1-2 Hours 25 13 2-4 Hours 23 10 > 4 Hours 10 30

APPENDIX A. EXPERMENTS AND RESULTS DATA

38

A.2

Energy Consumptions

APPENDIX A. EXPERMENTS AND RESULTS DATA

39

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial 13 Trial14 Trial15 AVG STD DEV

Table A.6: Idle Mode: Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48454.2 45781.2 2673 48114 45392.4 2721.6 48308.4 45586.8 2721.6 48600 45878.4 2721.6 48600 45878.4 2721.6 48308.4 45586.8 2721.6 48454.2 45781.2 2673 48600 45878.4 2721.6 48357 45635.4 2721.6 48600 45878.4 2721.6 48454.2 45781.2 2673 48114 45392.4 2721.6 48600 45878.4 2721.6 48308.4 45586.8 2721.6 48600 45878.4 2721.6 48431.52 45720 2711.88 174.1351987 176.6363 20.12231171

Remaining Time(Hrs) 1.44 1.43 1.44 1.43 1.45 1.44 1.44 1.43 1.45 1.43 1.44 1.43 1.43 1.44 1.45 1.438 0.007746

Remaining Time(Mins) 86.4 85.8 86.4 85.8 87 86.4 86.4 85.8 87 85.8 86.4 85.8 85.8 86.4 87 86.28 0.464758002

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.7: Idle Mode: Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48600 45878.4 2721.6 47968.2 45246.6 2721.6 48600 45927 2673 47968.2 45149.4 2818.8 47968.2 45198 2770.2 48357 45635.4 2721.6 48600 45927 2673 47968.2 45246.6 2721.6 47968.2 45149.4 2818.8 47968.2 45198 2770.2 48600 45878.4 2721.6 47968.2 45149.4 2818.8 48600 45927 2673 47968.2 45246.6 2721.6 47968.2 45198 2770.2 48205 45463.68 2741 305.648723 345.0583702 51.30203

Remaining Time(Hrs) 1.41 1.46 1.42 1.4 1.4 1.41 1.42 1.46 1.4 1.4 1.41 1.4 1.42 1.46 1.4 1.418 0.023052735

Remaining Time(Mins) 84.6 87.6 85.2 84 84 84.6 85.2 87.6 84 84 84.6 84 85.2 87.6 84 85.08 1.383164

APPENDIX A. EXPERMENTS AND RESULTS DATA

40

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.8: Idle Mode:3G Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48065.4 45198 2867.4 48600 45684 2916 48600 45829.8 2770.2 48114 45295.2 2818.8 47919.6 45052.2 2867.4 48357 45441 2916 48065.4 45198 2867.4 48600 45829.8 2770.2 48114 45295.2 2818.8 47919.6 45052.2 2867.4 48065.4 45198 2867.4 47919.6 45052.2 2867.4 48600 45829.8 2770.2 48114 45295.2 2818.8 48551.4 45635.4 2916 48240 45392.4 2848 277.245247 293.9051742 51.30203

Remaining Time(Hrs) 1.37 1.35 1.39 1.39 1.36 1.35 1.37 1.39 1.39 1.36 1.37 1.36 1.39 1.39 1.35 1.372 0.016561573

Remaining Time(Mins) 82.2 81 83.4 83.4 81.6 81 82.2 83.4 83.4 81.6 82.2 81.6 83.4 83.4 81 82.32 1.073313

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.9: Gmail:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48357 45586.8 2770.2 48600 45586.8 3013.2 48016.8 45246.6 2770.2 48162.6 45343.8 2818.8 48259.8 45489.6 2770.2 48551.4 45538.2 3013.2 48357 45586.8 2770.2 48016.8 45246.6 2770.2 48162.6 45343.8 2818.8 48259.8 45489.6 2770.2 48405.6 45635.4 2770.2 48551.4 45538.2 3013.2 48016.8 45246.6 2770.2 48162.6 45343.8 2818.8 48259.8 45489.6 2770.2 48276 45447.48 2828.5 194.110499 138.521165 97.546525

Remaining Time(Hrs) 1.42 1.43 1.42 1.4 1.39 1.43 1.42 1.42 1.4 1.39 1.42 1.43 1.42 1.4 1.39 1.412 0.015212777

Remaining Time(Mins) 85.2 85.8 85.2 84 83.4 85.8 85.2 85.2 84 83.4 85.2 85.8 85.2 84 83.4 84.72 0.912767

APPENDIX A. EXPERMENTS AND RESULTS DATA

41

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.10: Gmail:Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48357 45538.2 2818.8 48016.8 45246.6 2770.2 48259.8 45489.6 2770.2 48114 45343.8 2770.2 48357 45538.2 2818.8 48308.4 45489.6 2818.8 48259.8 45489.6 2770.2 48016.8 45246.6 2770.2 48357 45538.2 2818.8 48114 45343.8 2770.2 48357 45538.2 2818.8 48016.8 45246.6 2770.2 48357 45538.2 2818.8 48114 45343.8 2770.2 48357 45586.8 2770.2 48224 45434.52 2789.6 141.652436 124.404428 24.644698

Remaining Time(Hrs) 1.41 1.42 1.41 1.4 1.39 1.41 1.42 1.41 1.39 1.4 1.41 1.42 1.39 1.4 1.41 1.406 0.010555973

Remaining Time(Mins) 84.6 85.2 84.6 84 83.4 84.6 85.2 84.6 83.4 84 84.6 85.2 83.4 84 84.6 84.36 0.633358

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 AVG STD DEV

Table A.11: Gmail:3G Initial Final Capacity(mWh) Capacity(mWh) 47871 44906.4 48600 45343.8 48065.4 45149.4 48551.4 45295.2 47871 44906.4 47871 44906.4 48065.4 45149.4 48600 45343.8 48016.8 45100.8 48168 45122.4 321.866727 183.6397016

Dierence (mWh) 2964.6 3256.2 2916 3256.2 2964.6 2964.6 2916 3256.2 2916 3045.6 159.34576

Remaining Time(Hrs) 1.33 1.32 1.34 1.33 1.32 1.33 1.34 1.32 1.33 1.328889 0.00781736

Remaining Time(Mins) 79.8 79.2 80.4 79.2 79.8 79.8 80.4 79.2 79.8 79.73 0.469042

APPENDIX A. EXPERMENTS AND RESULTS DATA

42

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.12: YouTube 720:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48357 45392.4 2964.6 47968.2 45003.6 2964.6 48357 45343.8 3013.2 48114 45149.4 2964.6 48065.4 45100.8 2964.6 48308.4 45343.8 2964.6 47968.2 45003.6 2964.6 48162.6 45198 2964.6 48357 45343.8 3013.2 48065.4 45100.8 2964.6 48357 45392.4 2964.6 47968.2 45003.6 2964.6 48357 45343.8 3013.2 48065.4 45100.8 2964.6 48114 45149.4 2964.6 48172 45198 2974.3 159.292809 148.0962043 20.122312

Remaining Time(Hrs) 1.32 1.31 1.31 1.31 1.31 1.32 1.31 1.31 1.31 1.31 1.32 1.31 1.31 1.31 1.31 1.312 0.004140393

Remaining Time(Mins) 79.2 78.6 78.6 78.6 78.6 78.6 78.6 78.6 78.6 78.6 79.2 78.6 78.6 78.6 78.6 78.68 0.211119

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.13: YouTube 720:Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48114 45100.8 3013.2 48065.4 45052.2 3013.2 48600 45489.6 3110.4 47919.6 44906.4 3013.2 48600 45538.2 3061.8 48551.4 45441 3110.4 48065.4 45052.2 3013.2 48114 45100.8 3013.2 47919.6 44906.4 3013.2 48600 45538.2 3061.8 48114 45100.8 3013.2 48065.4 45052.2 3013.2 48600 45489.6 3110.4 48551.4 45489.6 3061.8 47919.6 44906.4 3013.2 48253 45210.96 3042.4 287.44323 252.1764484 40.244623

Remaining Time(Hrs) 1.28 1.32 1.27 1.3 1.27 1.27 1.32 1.28 1.3 1.27 1.28 1.32 1.27 1.27 1.3 1.288 0.020071301

Remaining Time(Mins) 76.8 79.2 76.2 78 76.2 76.2 79.2 76.8 78 76.2 76.8 79.2 76.2 76.2 78 77.28 1.204278

APPENDIX A. EXPERMENTS AND RESULTS DATA

43

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.14: YouTube 720p:3G Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 47919.6 44712 3207.6 48308.4 45149.4 3159 48065.4 44906.4 3159 48308.4 45198 3110.4 47968.2 44906.4 3061.8 48016.8 44857.8 3159 48308.4 45149.4 3159 47919.6 44712 3207.6 48308.4 45198 3110.4 47968.2 44906.4 3061.8 47919.6 44712 3207.6 48308.4 45149.4 3159 47968.2 44906.4 3061.8 48308.4 45198 3110.4 48114 44955 3159 48114 44974.44 3139.6 172.317183 185.3365772 51.30203

Remaining Time(Hrs) 1.26 1.25 1.24 1.26 1.28 1.24 1.25 1.26 1.26 1.28 1.26 1.25 1.28 1.26 1.24 1.258 0.013732131

Remaining Time(Mins) 75.6 75 74.4 75.6 76.8 74.4 75 75.6 75.6 76.8 75.6 75 76.8 75.6 74.4 75.48 0.823928

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.15: YouTube 360p:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48308.4 45392.4 2916 47919.6 45003.6 2916 48259.8 45343.8 2916 48308.4 45295.2 3013.2 48114 45149.4 2964.6 48259.8 45343.8 2916 47919.6 45003.6 2916 48357 45441 2916 48308.4 45295.2 3013.2 48114 45149.4 2964.6 48308.4 45392.4 2916 48308.4 45295.2 3013.2 48259.8 45343.8 2916 47968.2 45052.2 2916 48114 45149.4 2964.6 48189 45243.36 2945.2 152.437487 146.3390037 40.244623

Remaining Time(Hrs) 1.35 1.33 1.34 1.32 1.34 1.34 1.33 1.35 1.32 1.34 1.35 1.32 1.34 1.33 1.34 1.336 0.010556

Remaining Time(Mins) 81 79.8 80.4 79.2 80.4 80.4 79.8 81 79.2 80.4 81 79.2 80.4 79.8 80.4 80.16 0.633358

APPENDIX A. EXPERMENTS AND RESULTS DATA

44

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.16: YouTube 360p:Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48308.4 45343.8 2964.6 48308.4 45343.8 2964.6 48357 45586.8 2770.2 48600 45586.8 3013.2 48357 45295.2 3061.8 48502.8 45489.6 3013.2 48308.4 45343.8 2964.6 48357 45586.8 2770.2 48308.4 45343.8 2964.6 48357 45295.2 3061.8 48308.4 45343.8 2964.6 48308.4 45343.8 2964.6 48551.4 45538.2 3013.2 48357 45586.8 2770.2 48357 45295.2 3061.8 48376 45421.56 2954.9 95.0943351 122.9493554 102.60406

Remaining Time(Hrs) 1.31 1.35 1.34 1.32 1.33 1.32 1.35 1.34 1.31 1.33 1.31 1.35 1.32 1.34 1.33 1.33 0.0146385

Remaining Time(Mins) 78.6 81 80.4 79.2 79.8 79.2 81 80.4 78.6 79.8 78.6 81 79.2 80.4 79.8 79.8 0.87831

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.17: YouTube 360p:3G Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48065.4 45052.2 3013.2 48357 45198 3159 48600 45489.6 3110.4 48016.8 44857.8 3159 47968.2 44906.4 3061.8 48551.4 45441 3110.4 48357 45198 3159 48016.8 44857.8 3159 48065.4 45052.2 3013.2 47968.2 44906.4 3061.8 48016.8 44857.8 3159 48357 45198 3159 48600 45489.6 3110.4 48065.4 45052.2 3013.2 47968.2 44906.4 3061.8 48198 45097.56 3100.7 244.016161 230.5056454 58.666116

Remaining Time(Hrs) 1.27 1.25 1.28 1.23 1.27 1.28 1.25 1.23 1.27 1.27 1.23 1.25 1.28 1.27 1.27 1.26 0.0185164

Remaining Time(Mins) 76.2 75 76.8 73.8 76.2 76.8 75 73.8 76.2 76.2 73.8 75 76.8 76.2 76.2 75.6 1.110984

APPENDIX A. EXPERMENTS AND RESULTS DATA

45

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.18: Game:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48357 45489.6 2867.4 47919.6 45003.6 2916 48308.4 45343.8 2964.6 48162.6 45295.2 2867.4 48162.6 45246.6 2916 48357 45489.6 2867.4 47919.6 45003.6 2916 48308.4 45343.8 2964.6 48162.6 45246.6 2916 48114 45246.6 2867.4 48357 45489.6 2867.4 47919.6 45003.6 2916 48211.2 45295.2 2916 48162.6 45295.2 2867.4 48308.4 45343.8 2964.6 48182 45275.76 2906.3 158.868593 164.0924861 37.645398

Remaining Time(Hrs) 1.35 1.32 1.31 1.35 1.35 1.35 1.32 1.31 1.35 1.34 1.35 1.32 1.35 1.35 1.31 1.3353 0.0176743

Remaining Time(Mins) 81 79.2 78.6 81 81 81 79.2 78.6 81 80.4 81 79.2 81 81 78.6 80.12 1.060458

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.19: Game:Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48259.8 45295.2 2964.6 48357 45343.8 3013.2 48211.2 45343.8 2867.4 48357 45392.4 2964.6 48162.6 45246.6 2916 48259.8 45295.2 2964.6 48308.4 45295.2 3013.2 48211.2 45343.8 2867.4 48357 45392.4 2964.6 48162.6 45246.6 2916 48259.8 45295.2 2964.6 48211.2 45343.8 2867.4 48357 45392.4 2964.6 48357 45343.8 3013.2 48162.6 45246.6 2916 48266 45321.12 2945.2 77.6441995 51.52080301 51.30203

Remaining Time(Hrs) 1.31 1.34 1.3 1.3 1.32 1.31 1.3 1.34 1.3 1.32 1.31 1.34 1.3 1.3 1.32 1.314 0.0154919

Remaining Time(Mins) 78.6 78 80.4 78 79.2 78.6 78 80.4 78 79.2 78.6 80.4 78 78 79.2 78.84 0.929516

APPENDIX A. EXPERMENTS AND RESULTS DATA

46

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.20: Game:3G Initial Final Capacity(mWh) Capacity(mWh) 48259.8 45100.8 47968.2 44955 48259.8 45100.8 48065.4 45003.6 47968.2 45003.6 48308.4 45149.4 48259.8 45100.8 47919.6 44906.4 48065.4 45003.6 47968.2 45003.6 48259.8 45100.8 47968.2 44955 47968.2 45003.6 48065.4 45003.6 48259.8 45100.8 48104 45032.76 144.871328 70.6672363

Dierence (mWh) 3159 3013.2 3159 3061.8 2964.6 3159 3159 3013.2 3061.8 2964.6 3159 3013.2 2964.6 3061.8 3159 3071.5 80.489247

Remaining Time(Hrs) 1.25 1.26 1.25 1.28 1.27 1.25 1.25 1.26 1.28 1.27 1.25 1.26 1.27 1.28 1.25 1.262 0.0120712

Remaining Time(Mins) 75 75.6 75 76.8 76.2 75 75 75.6 76.8 76.2 75 75.6 76.2 76.8 75 75.72 0.724273

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.21: Download:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48114 45392.4 2721.6 48016.8 45246.6 2770.2 48016.8 45198 2818.8 48162.6 45392.4 2770.2 48211.2 45489.6 2721.6 48016.8 45198 2818.8 48211.2 45489.6 2721.6 48114 45392.4 2721.6 48162.6 45392.4 2770.2 48016.8 45246.6 2770.2 48162.6 45392.4 2770.2 48211.2 45489.6 2721.6 48016.8 45198 2818.8 48114 45392.4 2721.6 48016.8 45246.6 2770.2 48104 45343.8 2760.48 80.4892468 110.2144403 37.6453981

Remaining Time(Hrs) 1.42 1.43 1.39 1.44 1.41 1.39 1.41 1.42 1.44 1.43 1.44 1.41 1.39 1.42 1.43 1.418 0.0178085

Remaining Time(Mins) 85.2 85.8 83.4 86.4 84.6 83.4 84.6 85.2 86.4 85.8 86.4 84.6 83.4 85.2 85.8 85.08 1.06851

APPENDIX A. EXPERMENTS AND RESULTS DATA

47

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.22: Download:Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48308.4 45489.6 2818.8 47968.2 45684 2284.2 48016.8 45198 2818.8 48114 45246.6 2867.4 47919.6 45003.6 2916 48308.4 45489.6 2818.8 48016.8 45198 2818.8 47871 44955 2916 48114 45246.6 2867.4 47968.2 45684 2284.2 48308.4 45489.6 2818.8 48016.8 45198 2818.8 47968.2 45684 2284.2 48162.6 45295.2 2867.4 47919.6 45003.6 2916 48065 45324.36 2741.04 148.096204 249.7113213 239.362489

Remaining Time(Hrs) 1.38 1.42 1.38 1.39 1.37 1.38 1.42 1.37 1.39 1.38 1.38 1.42 1.38 1.39 1.37 1.388 0.0178085

Remaining Time(Mins) 82.8 85.2 82.8 83.4 82.2 82.8 85.2 82.2 83.4 82.8 82.8 85.2 82.8 83.4 82.2 83.28 1.06851

Trial.No Trial1 Trial2 Trial3 Trial4 Trial5 Trial6 Trial7 Trial8 Trial9 Trial10 Trial11 Trial12 Trial13 Trial14 Trial15 AVG STD DEV

Table A.23: Download:3G Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48600 45586.8 3013.2 48016.8 45003.6 3013.2 48065.4 45052.2 3013.2 48114 45052.2 3061.8 47919.6 44955 2964.6 48551.4 45538.2 3013.2 48016.8 45003.6 3013.2 48114 45052.2 3061.8 48065.4 45052.2 3013.2 47919.6 44955 2964.6 47919.6 44955 2964.6 48016.8 45003.6 3013.2 48016.8 45003.6 3013.2 48114 45052.2 3061.8 48600 45586.8 3013.2 48137 45123.48 3013.2 240.814746 234.4246915 31.8161684

Remaining Time(Hrs) 1.3 1.3 1.3 1.32 1.3 1.3 1.3 1.32 1.3 1.3 1.3 1.3 1.3 1.32 1.3 1.304 0.0082808

Remaining Time(Mins) 78 78 78 79.2 78 78 78 79.2 78 78 78 78 78 79.2 78 78.24 0.496847

APPENDIX A. EXPERMENTS AND RESULTS DATA

48

Trial.No Trial 1 Trial 2 Trial 3 Trial 4 Trial 5 Trial 6 Trial 7 Trial 8 Trial 9 Trial 10 Trial 11 Trial 12 Trial 13 Trial 14 Trial 15 avg std dev

Table A.24: Upload: Wi-Fi Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48357 45489.6 2867.4 48114 45246.6 2867.4 47968.2 45052.2 2916 48259.8 45392.4 2867.4 47919.6 45003.6 2916 47919.6 45003.6 2916 48114 45246.6 2867.4 48357 45489.6 2867.4 48259.8 45392.4 2867.4 47919.6 45003.6 2916 48357 45489.6 2867.4 48259.8 45392.4 2867.4 47968.2 45052.2 2916 48162.6 45295.2 2867.4 47919.6 45003.6 2916 48124 45236.88 2886.84 176.381369 198.8616576 24.6446981

Remaining Time(Hrs) 1.39 1.4 1.35 1.34 1.35 1.35 1.4 1.39 1.34 1.35 1.39 1.34 1.35 1.4 1.35 1.366 0.0250143

Remaining Time(Mins) 83.4 84 81 80.4 81 81 84 83.4 80.4 81 83.4 80.4 81 84 81 81.96 1.500857

Trial.No Trial 1 Trial 2 Trial 3 Trial 4 Trial 5 Trial 6 Trial 7 Trial 8 Trial 9 Trial 10 Trial 11 Trial 12 Trial 13 Trial 14 Trial 15 avg std dev

Table A.25: Upload: 3G Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48065.4 45003.6 3061.8 48162.6 45100.8 3061.8 48600 45295.2 3304.8 48114 45052.2 3061.8 48065.4 45003.6 3061.8 47968.2 45003.6 2964.6 48162.6 45100.8 3061.8 48551.4 45246.6 3304.8 48114 45052.2 3061.8 47968.2 45003.6 2964.6 48065.4 45003.6 3061.8 48211.2 45149.4 3061.8 47968.2 45003.6 2964.6 48114 45052.2 3061.8 48600 45295.2 3304.8 48182 45091.08 3090.96 220.275752 107.4237484 117.332232

Remaining Time(Hrs) 1.29 1.29 1.31 1.33 1.29 1.31 1.29 1.31 1.33 1.31 1.29 1.29 1.31 1.33 1.31 1.306 0.0154919

Remaining Time(Mins) 77.4 77.4 78.6 79.8 77.4 78.6 77.4 78.6 79.8 78.6 77.4 77.4 78.6 79.8 78.6 78.36 0.929516

APPENDIX A. EXPERMENTS AND RESULTS DATA

49

Trial.No Trial 1 Trial 2 Trial 3 Trial 4 Trial 5 Trial 6 Trial 7 Trial 8 Trial 9 Trial 10 Trial 11 Trial 12 Trial 13 Trial 14 Trial 15 avg std dev

Table A.26: Upload:Ethernet Initial Final Dierence Capacity(mWh) Capacity(mWh) (mWh) 48162.6 45392.4 2770.2 47968.2 45149.4 2818.8 48259.8 45489.6 2770.2 48357 45586.8 2770.2 48308.4 45489.6 2818.8 48405.6 45635.4 2770.2 47968.2 45149.4 2818.8 48259.8 45489.6 2770.2 48162.6 45392.4 2770.2 48308.4 45489.6 2818.8 48162.6 45392.4 2770.2 48357 45586.8 2770.2 48259.8 45489.6 2770.2 47919.6 45100.8 2818.8 48308.4 45489.6 2818.8 48211 45421.56 2789.64 152.584983 165.1174335 24.6446981

Remaining Time(Hrs) 1.42 1.42 1.4 1.42 1.38 1.42 1.41 1.4 1.42 1.38 1.42 1.4 1.4 1.42 1.38 1.406 0.0159463

Remaining Time(Mins) 85.2 85.2 84 85.2 82.8 85.2 84.6 84 85.2 82.8 85.2 84 84 85.2 82.8 84.36 0.95678

APPENDIX A. EXPERMENTS AND RESULTS DATA

50

A.3

Discharge Curves

APPENDIX A. EXPERMENTS AND RESULTS DATA

51

Figure A.1: Discharge Rate (Ethernet)

APPENDIX A. EXPERMENTS AND RESULTS DATA

52

Figure A.2: Discharge Rate (Wi-Fi)

APPENDIX A. EXPERMENTS AND RESULTS DATA

53

Figure A.3: Discharge Rate (3G)

Bibliography
[1] Himayat Nageen. Li Ye. Swami Ananthram. Miao, Guowang. CrossLayer Optimization for Energy-Ecient Wireless Communications: A Survey. Wireless Communications and Mobile Computing, 9:529542, 2009. [2] Himayat Nageen. Li Ye. Swami Ananthram. Miao, Guowang. CrossLayer Optimization for Energy-Ecient Wireless Communications: A Survey. Wireless Communications and Mobile Computing, 9:529542, 2009. [3] K. Pentikousis. In Search of Energy-Ecient Mobile Networking. Communications Magazine, IEEE, 48(1):95 103, 2010. [4] M. Pickavet, W. Vereecken, S. Demeyer, P. Audenaert, B. Vermeulen, C. Develder, D. Colle, B. Dhoedt, and P. Demeester. Worldwide energy needs for ICT: The rise of power-aware networking. In Advanced Networks and Telecommunication Systems, 2008. ANTS 08. 2nd International Symposium on, pages 1 3, 2008. [5] Cisco Website. Cisco Visual Networking Index: Forecast and Methodology, 20092014, [Online; Veried November] Available:2010. http://www.cisco.com/en/US/solutions/collateral/ns341/ns525 /ns537/ns705/ns827/white paper c11-481360.pdf. [6] Mikko A. Uusitalo. Global Vision for the Future Wireless World from the WWRF. Vehicular Technology Magazine, IEEE, 2006. [7] Sergiu Nedevschi, Lucian Popa, Gianluca Iannaccone, Sylvia Ratnasamy, and David Wetherall. Reducing Network Energy Consumption via Sleeping and Rate-Adaptation. In Proceedings of the 5th USENIX Symposium on Networked Systems Design and Implementation, NSDI08, pages 323336, Berkeley, CA, USA, 2008. USENIX Association. [8] C. Gunaratne, K. Christensen, B. Nordman, and S. Suen. Reducing the Energy Consumption of Ethernet with Adaptive Link Rate (ALR). Computers, IEEE Transactions on, 57(4):448 461, 2008. 54

BIBLIOGRAPHY

55

[9] J. Chou. Proposal of Low-Power Idle: 100basetx, [Online; Veried November] Available:2010. http://www.ieee802.org/3/az/public/jan08/chou 01 0108.pdf. [10] M. Grimwood. Energy Ecient Ethernet 1000BASET LPI Timing Parameters, [Online; Veried November] Available:2010. http://www.ieee802.org/ 3/az/public/jul08/grimwood 02 0708.pdf. [11] P. Reviriego, J.A. Hernandez, D. Larrabeiti, and J.A. Maestro. Performance evaluation of energy ecient ethernet. Communications Letters, IEEE, 13(9):697 699, 2009. [12] Tao Zhang, S. Madhani, P. Gurung, and E. van den Berg. Reducing Energy Consumption on Mobile Devices with WiFi Interfaces. In Global Telecommunications Conference, 2005. GLOBECOM 05. IEEE, 2005. [13] Ronny Krashinsky and Hari Balakrishnan. Minimizing Energy for Wireless Web Access with Bounded Slowdown. In Proceedings of the 8th Annual International Conference on Mobile Computing and Networking. [14] Robin Kravets and P. Krishnan. Power Management Techniques for Mobile Communication. In Proceedings of the 4th Annual ACM/IEEE International Conference on Mobile Computing and Networking, MobiCom 98, pages 157168, New York, NY, USA, 1998. ACM. [15] Christine E. Jones, Krishna M. Sivalingam, Prathima Agrawal, and Jyh Cheng Chen. A Survey of Energy Ecient Network Protocols for Wireless Networks. Wirel. Netw., 7:343358, September 2001. [16] Eugene Shih, Paramvir Bahl, and Michael J. Sinclair. Wake on Wireless: An Event Driven Energy Saving Strategy for Battery Operated Devices. In Proceedings of the 8th Annual International Conference on Mobile Computing and Networking. [17] ITU website. World in 2009,ICT facts and gures, [Online; Veried November] Available:2010. http://www.itu.int/ITU-D/ict/material/Telecom09 flyer.pdf. [18] Nokia Siemens Networks website. Smart devices need smart business solutions, [Online; Veried November] Available:2010. http://www.nokiasiemensnetworks.com/news-events/ press-room/press-releases/smart-devices-need-smart-business -solutions .

BIBLIOGRAPHY

56

[19] D. Lopez, F. Gonzalez, L. Bellido, and A. Alonso. Adaptive multimedia streaming over IP based on customer oriented metrics. In Computer Networks, 2006 International Symposium on, pages 185 191, 2006. [20] G.P. Perrucci, F.H.P. Fitzek, G. Sasso, W. Kellerer, and J. Widmer. On the impact of 2G and 3G Network Usage for Mobile Phones Battery Life. In Wireless Conference, 2009. EW 2009. European, pages 255 259, May 2009. [21] Yu Du, Wen an Zhou, Bao fu Chen, and Jun de Song. A QoE Based Evaluation of Service Quality in Wireless Communication Network. In New Trends in Information and Service Science, 2009. NISS 09. International Conference on, 30 2009. [22] Nokia Siemens Networks website. Smart devices need smart business solutions, [Online; Veried November] Available:2010. http://www.nokiasiemensnetworks.com/news-events/ press-room/press-releases/smart-devices-need-smart-business -solutions . [23] Pablo Belzarena Pedro Casas and Sandrine Vaton. End-2-End Evaluation of IP Multimedia Services, a User Perceived Quality of Service Approach. In 18th ITC Specialist Seminar on Quality of Experience, May 2008. [24] Barry Collins. Broadband Buyers Guide: Fixed vs Mobile, [Online; Veried November] Available:2010. http://www.pcauthority.com.au/Feature/141410,broadband -buyers-guide-fixed-vs-mobile.aspx. [25] YouTube, [Online; Veried http://www.youtube.com. [26] Mediare, [Online; Veried http://www.mediafire.com. [27] Gmail, [Online; http://www.gmail.com. Veried November] November] November] November] Available:2010. Available:2010. Available:2010. Available:2010.

[28] Miniclip, [Online; Veried http://www.miniclip.com.

[29] Chester Simpson. Characteristics of Rechargable Batteries, [Online; Veried November] Available:2010. http://www.national.com/appinfo/power/files/f19.pdf. [30] American [Online; Physical Society. Veried November] Energy Units, Available:2010.

BIBLIOGRAPHY http://www.aps.org/policy/reports/popa-reports/energy/ units.cfm.

57

[31] Passmark website. BatteryMon, [Online; Veried November] Available:2010. http://www.passmark.com/products/batmon.htm. [32] Imtec.org. Imtec Battery Mon, [Online; Veried November] Available:2010. http://en.imtec.org.ru/load/7-1-0-5. [33] Battery Care, [Online; Veried November] http://batterycare.net/en/index.html. [34] Speedtest, [Online; Veried http://www.speedtest.com. November] Available:2010. Available:2010.

[35] Young-Min Key, Jung-A Kwon, Inkyu Lee, Sang-Chul Han, and Jee Hyung Lee. The Economic Value of User-Controllable Internet Speed Service. In Advanced Communication Technology, The 9th International Conference on, volume 1, pages 331 336, 2007.

Master Thesis Electrical Engineering Thesis no: MSC-2010-XXX December 2010

Analysis of H.264 Sensitivity to Packet Loss and Delay Variation

Oziel Alejandro Gonzalez Lagunas

School of Computing Blekinge Institute of Technology 37179 Karlskrona Sweden

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

Contact Information Author: Oziel Alejandro Gonzalez Lagunas E-mail: [email protected]

University advisor(s): Tahir Nawaz Minhas School of Computing Examiner Dr Patrik Arlos School of Computing School of Computing Blekinge Institute of Technology 371 79 KARLSKRONA SWEDEN Internet: www.bth.se/com Phone: +46 455 385000 SWEDEN

Abstract
The number and popularity of multimedia services and applications on the Internet has increased greatly in recent years. Services employing real-time video, such as mobile TV, video-conferencing and tele-medicine are growing, and the users expectations of quality are increasing. This thesis analyses the impact on perceived quality of received videos sent across a network, emulation is used to emulate network characteristics with packet loss and delay variation for video sequences with dierent characteristics. This work aims to understand the user perception of video quality with packet loss and delay variation for videos encoded with H.264 on laptop computers and mobile phones. Further, it seeks to understand if users have dierent video quality expectations for laptops and mobile phones. The Mean Opinion Score (MOS) and statistical methods are used to evaluate the video quality perceived by users. It was found that packet loss and delay variation aects the perceived quality of video. In addition, it is shown that there is no signicance dierence between doing the experiment in the mobile phone or in the laptop displaying the same resolution. Keywords: H.264, subjective video quality, packet loss, delay variation

ii

Acknowledgements
I would like to thank my supervisor, Tahir Nawas Minhas, for his advice, feedback and suggestions through the development of this work. I would also like to extent my gratitude to Dr Patrik Arlos for his guidance. I am grateful to all the people who participated lling in questionnaires. Thanks to Dele for his inputs in early stages of this project. I devote this thesis to my family. Thanks for their love, support and encouragement. Special thanks to Sebastian, for his support, feedback and putting up with my antisocial writing habits. This work was partly funded with a scholarship granted from the State Government of Veracruz, Mexico.

iii

iv

Contents
Abstract Acknowledgements Contents List of Figures List of Tables 1 Introduction 2 Background 2.1 Key Concepts . . . . . . . . 2.1.1 Video coding . . . . 2.1.2 Video Transmission 2.1.3 Emulation . . . . . . 2.1.4 Quality of Video . . 2.2 Related Work . . . . . . . . i iii iv vii viii 1 3 3 3 4 6 6 6 9 9 10 11 11 12 15 15 16 16 18

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

3 Design and Implementation 3.1 Aims and Research Questions . . . . . . . . . 3.2 Method . . . . . . . . . . . . . . . . . . . . . 3.3 Design . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Transport Protocol . . . . . . . . . . . 3.3.2 Video Parameters . . . . . . . . . . . 3.3.3 Network emulator . . . . . . . . . . . 3.3.4 Packet loss and delay/delay variation 3.4 Implementation . . . . . . . . . . . . . . . . . 3.4.1 Experimental Setup . . . . . . . . . . 3.4.2 Data Collection . . . . . . . . . . . . . v

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

4 Results and Discussion 4.1 Packet loss . . . . . . . . 4.2 Delay variation . . . . . . 4.3 Mobile phone and laptop . 4.4 Validity Threats . . . . . 5 Conclusion Bibliography

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

23 24 28 31 34 35 37

A Video Encoding Information 41 A.1 Procedure for video sequences creation . . . . . . . . . . . . . 41 A.2 Pre-set FFMPEG les . . . . . . . . . . . . . . . . . . . . . . 42 A.3 Command line FFMPEG . . . . . . . . . . . . . . . . . . . . 43 A.4 Output information FFMPEG encoding videos from Raw to H.264 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 B Assessment material 47 B.1 Set of videos for the subjective assessment . . . . . . . . . . . 47 B.2 Questionnaire for the assessment session . . . . . . . . . . . . 47

vi

List of Figures
2.1 2.2 3.1 3.2 3.3 3.4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 B.1 B.2 B.3 B.4 Spatial and temporal correlation in a video sequence [27] . . . Example of error propagation [2] . . . . . . . . . . . . . . . . Experimental network set-up . . . . . . . Laptop based assessment . . . . . . . . . . Mobile Phone assessment . . . . . . . . . Screen shot of interview set-up for laptop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 17 20 20 20 25 25 27 27 28 29 29 30 31 32 49 49 49 49

MOS for packet loss displayed on the laptop . . . . . . . . . . MOS for packet loss displayed on the mobile phone . . . . . . Condence interval (95%) for packet loss . . . . . . . . . . . . Standard deviation for packet loss . . . . . . . . . . . . . . . MOS for delay variation displayed on the laptop . . . . . . . MOS for delay variation displayed on the mobile phone . . . Condence interval (95%) for delay variation . . . . . . . . . Standard deviation for delay variation . . . . . . . . . . . . . MOS packet loss displayed on the laptop and mobile phone . MOS delay variation displayed on the laptop and mobile phone Questionnaire Questionnaire Questionnaire Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vii

viii

List of Tables
3.1 3.2 3.3 3.4 4.1 4.2 4.3 Five-level scale for rating overall quality of video . . . . . . . Description of video content for the test sequences used in the subjective test. . . . . . . . . . . . . . . . . . . . . . . . . . . Video parameters . . . . . . . . . . . . . . . . . . . . . . . . . Characteristics of encoded videos . . . . . . . . . . . . . . . . Mean opinion score for packet loss . . . . . . . . . . . . . . . Mean opinion score for delay variation . . . . . . . . . . . . . Matched-sample t test results . . . . . . . . . . . . . . . . . . 11 12 14 15 24 24 33 48

B.1 Set of videos for the subjective assessment . . . . . . . . . . .

ix

Chapter 1

Introduction
The number and popularity of multimedia services and applications on the Internet have is increasing. Services for real-time video, such as mobile TV, video-conferencing and tele-medicine are growing, and the users expectations of quality are higher. Transmission of raw or uncompressed video, video that has no been compressed, consumes a great amount of bandwidth if is transmitted in this form. Raw video is normally compressed before transmission to make eective usage of the transmission media. There are several techniques for video compression [37], one of the most widely used is the codec H.264/AVC (Advanced Video Coding). A few example applications using this codec include YouTube, Blu-ray Discs, iTunes, Digital Video Broadcasting (DVB) and online gaming. There has been increased usage of H.264 for a range of dierent purposes, each with dierent requirements. For example, mobile phones now have increased processing and memory capabilities, colour displays, touch-screens and are used for many tasks beyond making phone calls [4]. However, mobile phones have special characteristics that still need to be consideredsmaller screen displays than televisions or computers monitors and lower processing capabilities than computers. Real-time streaming video is a technique that splits a video into parts, transmits each part in succession and the received decodes the parts as are receivedwithout waiting for the entire le to be downloaded. Video streaming over the Internet can have problems from disturbances in the network, such as packet loss and delay variation, that aect the quality of the received video [2]. The User Datagram Protocol (UDP) is a transport protocol used for streaming real-time video. UDP does not guarantee packet delivery as does not have ow control mechanism [37] meaning packets can be lost or arrive out of order. Network emulation is used to simulate the characteristics of a network 1

CHAPTER 1. INTRODUCTION

for performance assessment, predict impact of change or optimize technology [13]. In this thesis emulation is used to create the desired conditions to test the eects of packet loss and delay variation. In this thesis we study how packet loss and delay variation in a network eects the user perception of quality. Specically this thesis aims to understand the user perception of video quality for dened values of packet loss and delay variation for the codec H.264. Additionally this thesis aims to understand if the users have dierent expectations for video quality on a laptops and mobile phones. In order to achieve these research objectives, an experimental set-up was implemented to emulate the characteristics of a network, over which videos were transmitted. Subjective assessments were realised following the recommendations from the International Telecommunications Union (ITU) [25, 5]. The results are calculated and presented using Mean Opinion Score (MOS) and conventional statistic methods. The remaining parts of this document are organised as follows. A brief introduction of the concepts used for this thesis, background and related work are presented in the Chapter 2. The aims, methodology, design and implementation of the experiment are addressed in Chapter 3. The results from the assessment sessions, discussion and validity threats are presented in Chapter 4. Finally, the conclusions and future work are presented in Chapter 5.

Chapter 2

Background
This chapter presents the key concepts and related work.

2.1

Key Concepts

This section presents the key concepts that are required to understand the work discussed in this thesis.

2.1.1

Video coding

Compression is the process of compacting data, in this case specically raw video. Compression involves two systemsa compressor (coder) and a decompressor (decoder)this pair is often called a codec. Video compression is done by exploiting the redundancies that exist in a video signal. If we consider that a video is a sequence frames or pictures, then there are two types of redundanciestemporal (TI) or spatial (SI). Temporal redundancies refer to adjacent frames that are often correlated and it is related to the number of frames per second (fps). Spatial redundancy refers to the information of neighbouring pixels, which can be very similar [27] as shown in Figure 2.1. The codec H.264 uses both of these redundancies to compress the video. The Group of Picture (GOP) is a group of successive frames in a encoded video sequence. There are dierent types of frames in a GOPfor H.264 the most common frames are I-frames (intra), P-frames (predicted) and B (bipredictive) [27]. The I-frames are coded independently from the other frames (reference frame). A GOP always starts with an I-frame; P-frames are coded predictively from the closest previous reference frame, can be an I or P frame; B-frames are coded bi-directionally from the preceding or succeeding reference frame. Dierent frames types have dissimilar compression ratios and error propagation features [16]. The GOP structure is a factor that aects the video compression ratio, 3

CHAPTER 2. BACKGROUND

Figure 2.1: Spatial and temporal correlation in a video sequence [27] it also aects the distortion sensitivity to packet loss and delay [16]. For example, if we increase the distance between reference frames when encoding, the compression ratio is bigger; on the other hand the eect of error propagation due to packet loss also increases as less reference frames are transmitted. The H.264 codec has dierent proles depending on the application that will use the encoded video and depends on the complexity of the algorithms that are applied to compress the video. These proles were created to specify the requirements for the equipment that will encode and decode the video. Each prole has some variations in the algorithm that compresses the video, as the computing capabilities dier. The most extended proles are the baseline prole that includes support for I-P-frames as is used for limited capability devices such as mobile phones. The main and extended proles that support I-P-B frames are mainly used for video storage and television broadcasting [27]. The proles are divided in levels indicating the limits of parameters such as sample processing rate, picture size, coded bit rate and memory requirements [27]. Using these proles and levels it is easier in the industry to understand what are the requirements of the equipments to encode/decode the video.

2.1.2

Video Transmission

Transport protocols for steaming video are designed to standardise the communication between streaming servers and clients. Transport protocols for

2.1. KEY CONCEPTS

media streaming include the Transport Control Protocol (TCP) and Universal Datagram Protocol (UDP). TCP uses retransmission and ow control mechanisms that, on one hand, guarantee the delivery of packets, but also introduce delays that are not acceptable for time critical streaming applications. Consequently, UDP is the protocol most widely used for real-time streaming of video [37, 2]. Video streaming over the Internet using UDP present dierent distortions that aect the quality of video, in this thesis we focus on packet loss and delay variation.

Packet loss Packet loss over a network occurs when packets sent over the network do not reach their destination. Packet loss can signicantly damage video quality during transmissions [22]. The losses are generally random and can aect dierent frames in a GOP. If a key frame (I-frame or P-frame) is aected this error will be propagated to all the GOP. The B-frames do not propagate errors as these frames are not used as references for other frames [16]. The Pframes can propagate errors to other P-frames and B-frames. The Figure2.2 shows an example of error propagation and how causes a cascade eect, in this case the error occurs in the P-frame and propagates to the other P-frames and will be corrected until the next reference I-frame.

Figure 2.2: Example of error propagation [2]

Delay/Delay variation End-to-end delay that a packet experiences in a network can change from packet to packet. This delay variation is referred to as jitter. Delay variation created a problem in real time streaming video as the receiver should receive, decode and display the frames in the correct order and at a constant rate. If this is not the case, the late frames or out-of-order frames will produce problems in the video quality [2].

CHAPTER 2. BACKGROUND

2.1.3

Emulation

Network emulation is a way to simulate the network performance in a controlled and repeatable environment. Trac shapers are used for the variation of parameters such as delay and packet loss to emulate dierent network conditions. It is very important that the trac shapers behave according to the given specications in order to realise the desired network conditions [29].

2.1.4

Quality of Video

Video quality assessments can be objective and subjective. The objective method consists of methods that do not involve human grading. The videos are evaluated by computers and mathematical algorithms. On the other hand, in subjective quality assessment the human perception of quality is based on individual perception and can be dierent between subjects [6]. Pros and cons about these methods are discussed later in this thesis.

2.2

Related Work

Studies have addressed the video quality perception for video and dierent codecs; Calyam et al. [6] made a comparative study of subjective and objective video quality for the codec H.323. They added disturbances of loss, delay and jitter to the same video sequence and found that jitter has the biggest eect. Claypool et al. [8] realised a subjective perception study for the codec MPEG-1 making variations of jitter and packet loss. Hands and Wilkins [14] performed video quality assessment using the codec MPEG-1 and changing the packet loss and burst size. Previous work have also addressed studies employing the codec H.264, using subjective and objective methods. Jusmisko et al. [18] worked in a subjective analysis comparing dierent codecs H.263, H.264 and XviD for mobile devices. Choi et al. [7] shows an analytical model for the distortion due to packet loss in wireless transmission. Lin et al. [22] present a model for packet prioritization for dierent GOP structures for H.264 and MPEG-2. The article by Loguinov and Radha [23] analyses the behaviour of dierent parameters in video coded with MPEG-4. Pinson et al. [26] compares High Denition Television (HDTV) video perception for video with and without packet loss for H.264 and MPEG-2 codecs. Simone et al. [9] oers a database of H.264 videos and made experiments with packet loss. Stockhammer et al. [31] use simulation for analysis of H.264 for wireless environments. As explained in the previous section the structure of the GOP, determines the coding eciency and the propagation of errors when a key frame is aected. The GOP is dened by the encoding parameters and in some extent to the H.264 prole used. Studies that have addressed quality of video for H.264 for dierent purposes, in some cases does not mention the

2.2. RELATED WORK

prole or coding characteristics [3, 7, 23, 32], some other studies mention the prole used for example [22] and [9] used the high prole, [26] used the main prole, Ries et al. [28] uses the baseline prole for quality estimation based in motion characteristics. In this study we want to use parameters that are common for mobile phones, thus, a study that uses the baseline prole for perception of packet loss and delay variation will have some contribution. The network conditions for mobile internet dier from traditional networks. When the videos are used over mobile networks important requirements need to be considered such as frame rates and the screen size [18]. Additionally, studies of video quality perception for mobile devices in some cases are carried out using a monitor or big LCD display instead of a mobile phone [3, 32, 36]. Further, in the study from Jumisko et al. [18] mobile phones were used for the study but the phones were attached to a xed stand, so the user was not able to manipulate the phone as occurs in real life scenarios. People have dierent perceptions of quality for dierent media devices. Television and computers are usually at a xed distance in contrast with hand-held devices that distance and tilt can be adjusted easily by the user. The perception changes according to the image size. Previous TV experiments carried out found that the general rule to be the bigger the image the better quality perceived [20]. Consequently, a study that tests the user perception of video quality in dierent network conditions for packet loss and delay variation encoded with H.264, and considers characteristics for mobile devices will contribute to understanding the expectations of the users with mobile devices. Further, an understanding of the role the device plays in the user perception of packet loss and delay variation is required.

CHAPTER 2. BACKGROUND

Chapter 3

Design and Implementation

In this chapter the aims and research questions for this work are presented in Section3.1. Section 3.2 explains the method selected and applied to answer the questions. Furthermore, the design Section 3.3 describes the experiment design, parameters and tools selected for the experiment. Finally, the implementation Section 3.4 details the creation of the assessment material, creation of video sequences with packet loss and delay variation; dening the experiment set-up to be used to assess the videos.

3.1

Aims and Research Questions

The aim of this research is to understand user perceptions of video quality with packet loss and delay variation for video encoded with H.264 on selected mobile devices. This research is further broken into three objectives: To understand user perceptions of video quality with packet loss and delay variation for video encoded with H.264 on mobile phones. To understand user perceptions of video quality with packet loss and delay variation for video encoded with H.264 on laptop computers. To understand if users have dierent expectations of video quality on mobile phones and laptop computers. The main research question to be answered by this research is: RQ1: How do users perceive video quality with packet loss and delay variation for video encoded with H.264 on selected mobile devices? This research question is further broken down into three sub-questions: RQ1.1: How do users perceive video quality with packet loss and delay variation for video encoded with H.264 on mobile phones? 9

10

CHAPTER 3. DESIGN AND IMPLEMENTATION RQ1.2: How do users perceive video quality with packet loss and delay variation for video encoded with H.264 on laptop computers? RQ1.3: Do users have dierent expectations of video quality on mobile phones and laptop computers?

3.2

Method

This section describes the methods elected to answer the research questions and a comparison to other alternatives. Video quality assessments can be objective and subjective. The objective method consists of methods that do not involve human grading. The videos are evaluated by computers and mathematical algorithms. Dierent objective methods are described by the Video Quality Experts Group (VQEG) [34], which was formed to validate and standardise objective methods of video quality. These methods usually employ an error signal ratio that is a relation between the original video (considered high quality) and the processed signal with distortion or compressed. The most widely used objective methods are the Mean Squared Error (MSE) and the Peak Signal-to-Noise Ratio (PSNR) [32, 35]. Objective metrics do not always characterise the real viewer satisfaction level. The alternative to objective video quality assessment is subjective video quality assessment. In subjective quality assessment the description of quality is based on human perception and can be dierent between subjects [6]. Human perception involves various aspects of human psychology and viewing conditions; such as vision ability, lighting conditions, preference for content, displaying devices, understanding of the rating criteria [35]. Dierent objective methods are discussed in [25]; Absolute Category Rating (ACR) or Single Stimulus (SS), in which the video sequences are presented each at a time and rated independently, Degradation Category Rating (DCR) video sequences are presented in pairs and the subject rate the impairment of the second video in relation to the rst video as a reference, in Pair Comparison method (PC) the sequences are presented in pairs, they can be simultaneously shown on the same monitor. Mean Opinion Score (MOS) is a way to assess the quality of video in a subjective way. It is a metric obtained from a group of subjects that rate the video sequences according to a scale that represents the quality of the video in words and then is mapped into numbers as presented in Table 3.1. Another option considered was the software Perceptual Evaluation Video Quality (PEVQ) [24]. It is a software approved by the VQEG and ITU that makes an objective analysis of the video and gives a correlation with the subjective MOS. Although this method reduces the time necessary to perform the assessment sessions, the variation of parameters is limited, for this work it was wanted to have control of the display devices. In addition, it was

3.3. DESIGN

11

Table 3.1: Five-level scale for rating overall quality of video Rating 5 4 3 2 1 MOS Excellent Good Fair Poor Bad Impairment Imperceptible Perceptible, but not annoying Slightly annoying Annoying Very annoying

required to acquire the software as it is licensed for a fee. Consequently, this option was discarded. However, it can be used for future work to compare the ndings of this thesis. In this work it was selected to apply the subjective single stimulus ACR methodology as we want to measure viewers perception of quality to the dierent distortions and expectations between mobile devices. Comparison methods were discarded as for this study was necessary to present several video sequences, using these methods would make the assessment sessions longer and tedious for the participants. ACR is easy and fast to implement and the presentation of the stimuli is similar to that of the common use of systems. Thus, ACR is well-suited for qualication tests [25]. ACR is the method recommended for qualication tests and applied in several studies [30, 26, 9].

3.3

Design

This section describes the parameters and tools selected for the experiment; such as protocol, values for packet loss and delay variation selected. The information described in this section will be applied for the creation of the assessment material (video sequences), described in the implementation.

3.3.1

Transport Protocol

Protocols for steaming video are designed to standardise the communication between streaming servers and clients. Transport protocols for media streaming include the Transport Control Protocol (TCP) and UDP. TCP uses retransmission and ow control mechanisms that on one hand guarantee the delivery of packets, but introduce delays that are not acceptable for time critical streaming applications. Consequently, UDP is the protocol most widely used for real-time streaming of video [37, 2].

12

CHAPTER 3. DESIGN AND IMPLEMENTATION

For this reason the experiment described in this thesis uses UDP as the transport protocol and IP (Internet Protocol) as the network-layer protocol to send packets over the network. The packet size at data link layer in this experiment remains without change, considering the Maximum Transfer Unit (MTU) of 1500 bytes for Ethernet.

3.3.2

Video Parameters

This section describes the video parameters that were controlled for this experiment. Selection of Video Sequences Four video sequences were selected for this experiment. Test sequences were chosen to have dierent motion activities, with each sequence representing a dierent level of SI (Spatial Information) and TI (Temporal Information) characteristics, as suggested by the ITU-T [25]. It is suggested to take distinctive sequences to evaluate dierent coding complexities that depends on the SI and TI information in the videos. The videos were taken from a commonly used repository for the purpose of video quality assessment studies [1] as suggested by Simone Et al. [9]. A description of the selected videos is shown in Table 3.2. Table 3.2: Description of video content for the test sequences used in the subjective test. Sequence Name Hall-monitor Description Two subjects in an oce corridor walk in opposite directions lifting and carrying a TV and a briefcase. The background remains still, and the movement is focused in the two subjects. Include the face of a man gesticulating. The camera shakes a little. A the end of the sequence, the camera suddenly moves and focus to a building in construction. Scene with high motion of American football. News media presenters, in the front the two presenters with low movement. In the back, two dancers performing.

Foreman

Football News

The length of each video sequences is between eight and ten seconds. This is in the length suggested by the ITU-T [25]. Longer video sequences

3.3. DESIGN

13

will be tedious to the participants and shorter sequences ( 5 seconds) do not allow enough time for the participants to make correct evaluation. Resolution The resolution suggested by the ITU-T [25] for studies of video for mobile devices is Quarter Common Intermediate Format (QCIF) due to the limitation of the screen size. The ITU-T documentation P.910 was over 10 years ago in 1999, however, and during recent years there have been a big development in the mobile phones industry. The commercialization of smart-phones with higher processing capabilities, bigger screens and touchscreens. Previous video studies for mobile have used the QCIF (176 144) resolution [3, 18, 28, 32]; in some cases using mobile devices and some others displaying the video on a computer monitor displaying the QCIF resolution. For this study was decided to use higher resolution to cover the new segment of modern phones. The resolution chosen was VGA (320 240), when it was determined that a wide range of mobile phones brands (eg. Sony Ericsson, Nokia, iPhone, HTC) now support this resolution. Frame Rate and Bit Rate The frame rate refers to the number of frames that is shown per second. The frame rate used for this experiment is 30 fps as this is a common value [17] and it is the maximum supported in Android and iPhone devices. The bit rate refers to the number of bits that the video will process in a given period of time. The value chosen for the bit rate is 768 kbps. This is a common value used for mobile devices and creation of podcasts [17] [10]. This bit rate value is also the maximum value allowed by the H.264 baseline prole level 1.3 that is supported by mobile phones. Container The container or wrapper denes how the data is stored in a le. A container for video usually contains the video and audio traces. The container chosen for the experiment set-up is MP4. This container is supported by most of the new smart-phones with both Android and iPhone supporting this format [17, 10]. An alternative container is 3GP. This video container mostly used in 3G mobile phones. The MP4 container was selected for the experiment as the les are to be shown on both a laptop and an iPhone. The iPhone does not support the 3GP container [17],so choosing MP4 container covers the majority of the mobile operating systems and is also a format widely used by computer media players.

14 Video Codec

CHAPTER 3. DESIGN AND IMPLEMENTATION

This thesis considers mobile devices, where the decoding complexity must be simpler than for laptops or desktop computers due to the reduced decoding power of these devices. The baseline prole is supported by mobile phones running Android, since early version of the iPhone and Symbian phones. The baseline prole supports intra and inter-coding (using I-frames and P-frames), does not support inter-coding B-frames, that uses a dierent compression algorithm. Application examples of the baseline prole are videoconferences and wireless transmission [27] . Some studies have done analysis of H.264 with packet loss and delay, for dierent applications and using dierent proles of the codec. Pinson et al. [26] compares packet loss for HDTV using the high prole; Vassiliou et al. [32] makes an analysis of the wireless networks and video transmission employing the MPEG-4 codec, but the article does not mention the prole but describes the video with IPB-frames; Simone et al. [9] employs the H.264 codec high prole, that is used for devices with higher processing capabilities than mobile phones. A summarized table with the parameters chosen for the original encoded videos is shown in Table 3.3. Table 3.3: Video parameters Video sequences Codec Resolution Frame-rate Bit Rate Container News, Football, Foreman, Hall-monitor H.264 Baseline Prole, level 1.3 (320 240) (VGA) 30 fps 768kbps MP4

The above parameters are kept constant for the realization of the experiment, due that changes in these parameters have eect in the result of the streamed videos with the added disturbance. The results of the video sequence News are not taken into consideration for the results, this sequence was utilized as dummy for the training session that is discussed in the implementation section. As this study wants to focus on the eects of the packet loss and delay variation in video quality, no audio is included in these sequences. FFMPEG and x264, free cross-platform software solutions, was used to encode the videos [12], the pre-set les and commands are presented in the Appendices A.2 and A.3. Table 3.4 shows the video characteristics of the H.264 encoded video sequences.

3.3. DESIGN

15

Table 3.4: Characteristics of encoded videos Sequence Foreman Football Hall-monitor Duration 10 sec 8 sec 10 sec No.Frames 300 260 300 No.I-Frames 2 2 2 No.P-Frames 298 258 298 Size 983 KB 792 KB 929 KB

3.3.3

Network emulator

In emulation, trac shapers are used to dene certain features of a communication network. In this thesis, packet loss percentage and delay will be varied during transmission. Dierent options are available for trac shaping among them NIST Net, NetEm, Dummynet. A study of the performance of the trac shapers is presented by Shaikh et al. [29], in this article the authors compare dierent delay values for the above mentioned shapers using two dierent hardware platforms Advanced Micro Devices (AMD) and Intel, they show dierent performance depending on the platform selected. NetEm shows to be the most accurate to give the value closer to the set delay for both cases. NetEm is used in this thesis to add predened values of packet loss and delay and delay variation. NetEm default queuing discipline is FIFO, the queuing discipline makes the policy decision of which packets to send based on the settings. NetEm is controlled using the command line tool tc trac control.

3.3.4

Packet loss and delay/delay variation

Packet loss parameters The values of packet loss for this experiment are dened as 0.4%, 0.8%, 3%, 5% and 7%. A packet loss of 1% means that for every hundred packets transmitted one of the packets is dropped. These values were chosen as representative values. Various studies modelling packet loss in dierent networks shows values below 10 15% [2, 3, 14, 9] . For this study, the maximum packet loss value is 7%, as samples taken in the laboratory showed that for packet loss below this levels the video content was lost. For the distribution of the experimental values, special emphasis is given to values below 1%, as studies showed that the distribution of the packet loss failure during a session is higher at small percentages [23].

16

CHAPTER 3. DESIGN AND IMPLEMENTATION

Delay/Delay variation parameters For this experiment, was chosen to use delay variation (jitter) instead of xed delay values, jitter has bigger eects in the video sequences. Tests were executed with dierent xed delay values from 0ms to 1sec increases of 100ms and the eects in the transmitted video sequences were imperceptible or for bigger values a small delay was noticed before start playing the video smoothly. This is caused because all the packets are delayed with the same value, so they arrive in order to the media player. In addition, previous studies have addressed xed delay and found that this have low impact on the end users perception [6]. The values of delay and delay variation for this experiment are expressed as D D ; where D is the xed delay and D is the delay variation. The xed delay (D) selected for this experiment is 150ms and variable delays {2ms, 4ms, 8ms, 12ms, 16ms}. This means that for example for the value 150ms2ms, the delay values are between 148ms and 152ms. These experimental values were chosen from literature review and testing values in the laboratory. Calyam et al. [6] denes 150ms as the transition between good an acceptable in his experiment. The ITU standard G.114, one-way transmission time, states that the delay should not be more than 150ms and jitter should not be more than 20ms to 50ms [19]. Zheng et al. in a theoretical study of voice over IP shows that for a trac load of 0.77, there are 97% packets whose jitters are less than 20ms.

3.4

Implementation

This section describes the experiment implementation, equipment utilised, media player conguration and the network emulator conguration commands.

3.4.1

Experimental Setup

A small test network was built to perform the experiments, the Figure 3.1 shows a simplied diagram. The streaming Server (S) is responsible to send the original encoded video sequences via UDP to the Receiver (R) client. A full duplex link of bandwidth 100Mbps is used from S to D. The trac between S and R passes through the Trac Shaper (TS). The TS acts as a bridge between S and D. TS has the NetEm software installed to introduce the experimental values of packet loss, delay and delay variation. This information is further sent to the Measurement Point (MP) that is equipped with two (Digital Acquisition and Generation) DAG3.5E cards [11] to capture the packets from the input S to TS and from output TS to D.

3.4. IMPLEMENTATION
Trafc Shaper (TS)

17

X
Server (S) Receiver (R)

Measurement Point (MP)

Figure 3.1: Experimental network set-up The S computer is a laptop Toshiba Satellite A205-SP4027 with an Intel Core Duo T2450 2.00GHz processor architecture, 1024MB PC2-5300 DDR2 SDRAM, running Ubuntu 10.04 LTS Linux; loaded with VLC media player version 1.1.3. The computer (R) is a laptop MacBook Pro 15 with an Intel Core 2 Duo 2.40 GHz processor architecture, 2GB RAM 667 MHz DDR2 SDRAM, running MacOS X 10.5; loaded with VLC media player version 1.1.3. The TS is a computer with an Intel hardware platform running Linux kernel version: 2.6.23.9, loaded with NetEm. It is important to mention that after the version 2.6.15 of the Linux kernel, NetEm does re-ordering of packets if a lot of jitter is emulated, this behaviour can be manipulated changing the tfo queuing discipline set by default. In this experiment, we leave packets re-ordering without change as set by default. After the experimental network was built, the streaming of the videos and change of TS parameters in NetEm was implemented. The rewall in the S and D was deactivated in order to allow the transmission of UDP packets. The IP addresses used in the set-up are for S 192.168.0.1 and for R 192.168.1.2, netmask 255.255.255.0. The port used is 1234. VideoLAN Client (VLC) [33], open-source multimedia player and server, supports several codecs, containers and streaming options. VLC can be used to encode the video to H.264 and other codecs, it can transcode the video while streaming into the network. For this thesis VLC will be used to send the UDP stream from S and to receive and save at the video sequence at R, it was decided not to use its encoding capabilities as was wanted to have more control of the encoding parameters chosen, FFMPEG is used instead as described previously. VLC does not support packet re-ordering, if the packets arrive late to be usable, these are discarded.

18

CHAPTER 3. DESIGN AND IMPLEMENTATION

VLC was used using the command line in the Linux terminal to semiautomate the video sequences collection. The procedure followed to create the video sequences is described in the Appendix A.1. The procedure was repeated for each of the video sequences (football, foreman, hall-monitor) and for each experimental value of packet loss and delay variation. Three samples of each combination were executed to have a database to select the videos to use in the human perception assessment. A total of ninety nine videos were collected. The emulated packet loss is random with NetEm, so having a database of videos we have a pool of videos to choose with random packets loss and dierent eects. NetEm conguration NetEm [13] was used to set the experimental packet loss values in our experimental network topology, the following commands were used: 1. For the packet loss: # tc qdisc add dev eth2 root netem loss X % # tc qdisc change dev eth2 root netem loss X % where X is the desired packet loss value in % 2. For the delay variation (jitter): # tc qdisc add dev eth2 root netem delay Y ms Z ms # tc qdisc change dev eth2 root netem delay Y ms Z ms where Y is the xed packet delay value in [ms] and Z is the delay variation in [ms] The experimental set-up was tested before obtaining the assessment video sequences, that was done checking the connectivity between S, R, TS and MP with ping, then, applying specic disturbance at the TS and checking that the values captured in the MP with the cap les were according to the disturbance applied at the TS with NetEm.

3.4.2

Data Collection

Material Preparation From the pool of videos collected at the test network (Figure 3.1) one video sequence was chosen for every characteristic value. The video sequences received at the R, assessment materials, were named according to the value of packet loss or jitter applied at the TS; then, the names were changed as we do not want the observers to relate the disturbance watched in the video with the given name. The appendix B.1 presents a table with the names of the videos presented in the assessment session.

3.4. IMPLEMENTATION Assessment Methodology

19

The assessment sessions were held in a rooms conforming to the specications of the ITU-T [25] at the premises of two academic institutions in Kristianstad and Karlskrona in Sweden. Two mobile devices were used for the assessment. A laptopToshiba Satellite A205-SP4027 with an Intel Core Duo T2450 2.00GHz with a LCD display of de 15.4 (diagonal) widescreen TruBrite TFT, resolution (1280 800), Intel Graphics Media Accelerator 950and an iPhone 3G. The media players used were for the laptop VLC media player version 1.1.3 and for the iPhone Mobile Phone the standard media player from Apple Inc. The number of volunteers was chosen according to the recommendations from the ITU-T[25]. This species that the sample needs to be bigger than four and less than forty individuals for statistical purposes. For the data to be considered a coming from normal sampling distribution a sample of 25 to 30 individuals is recommended by Howell [15]. Thirty four volunteers were involved in the assessment sessions. People that was readily available, those that arrived on the scene, were asked to participate (convenience sampling or accidental sampling) [21]. Volunteers came from a range of dierent ages and backgrounds. In total 12 female and 22 male volunteers, ranging ages from 19 to 41, with 12 having European backgrounds, 15 having Asian backgrounds and seven having other backgrounds. Subjects were seated in front of the laptop screen with a viewing distance set equal to 18H, where H is the native height of the picture shown. The user was able to adjust their distance to the screen within these parameters. An example of a participant using the laptop is shown in Figure 3.2. For the mobile phone the user was able to choose the angle and distance to watch the videos. This imitates what happens in a real-world environment where the user can move the device as desired to achieve a comfortable viewing position. An example of a participant using the mobile phone is shown in Figure 3.3. It was observed that the participants felt comfortable placing the mobile phone between 20cm and 35cm far from the eyes. The video sequences shown on the laptop complied with the recommendations made by the ITU-T [25]. The videos were played in VLC using the original resolution of the video sequence (320 240), in the center of the screen, with the background was set to fty percent grey1 . A screen shot indicating this set-up is shown in Figure 3.4. Each assessment interview lasted for approximately 25 minutes and consisted of three phases: training session, questions and main session. During the introduction, the assessment methodology was explained, general information of the subject was collected (age, background, experience with video in computer and phone, use of corrective glasses or lenses);the grading scale
1

HTML Color #808080

20

CHAPTER 3. DESIGN AND IMPLEMENTATION

Figure 3.2: Laptop based assessment

Figure 3.3: Mobile Phone assessment

Figure 3.4: Screen shot of interview set-up for laptop

3.4. IMPLEMENTATION

21

was introduced as shown in Table 3.1; three stabilizing videos, dummy videos sequences, News with three dierent distortions were presented to stabilize participants opinion as suggested by the ITU-T [25]. The results for these three videos are not considered for the data evaluation and that was told to the observers. Then, during the questions session any concerns by the participants were answered. The main session consisted of thirty three videos sequences that were presented in the laptop and in the Mobile Phone, the videos were shown indistinctly in some cases before in the laptop and in some cases before in the Mobile Phone. For the evaluation we used the Single Stimulus method in which the video sequence is showed alone, without being compared to the reference version. Each sequence was displayed for ten or eight seconds and then the participant had 2-5 seconds voting time, the vote was collected and stored in a web-page form. A sample of the questionnaire is available in the Appendix B.2.

22

CHAPTER 3. DESIGN AND IMPLEMENTATION

Chapter 4

Results and Discussion

This section presents the collected data from the assessment sessions. Conventional statistics, like mean and variance, were applied to the raw data and graphs were plotted to compare the results. During the assessment sessions, thirty four volunteers graded the 33 videos sequences using the scale Excellent (5), Good (4), Fair (3), Poor (2) and Bad (1). Each video was shown on both a laptop and on a mobile phone. In total 66 video sequences were shown to the volunteers. The reliability of the volunteers was evaluated by checking their behaviour when the original videos encoded with H.264 were shown. In these cases, subjects were expected to give evaluations higher than three. This helps ensures that they at least understood the instructions and they were not grading randomly. Mean and standard deviation were calculated for each of the video sequences (Foreman, Hall-monitor, Football) and for both of the devices laptop and mobile phone. The mean is dened as: uj k = 1 N
N

uij k
i=1

(4.1)

The standard deviation is dened as:

N

sj k =
i=1

(uj k uij k )2 N 1

(4.2)

where : N is the number of observers, uij k is the score of observer i for test condition j, video sequence k. The MOS of the collected data is shown in the Table 4.1 and Table 4.2. The following abbreviations are used: FM (Foreman), HM (Hall-Monitor), FT (Football). The L denotes that the video sequence was displayed in the laptop and P denotes that was displayed in the mobile phone. 23

24

CHAPTER 4. RESULTS AND DISCUSSION

Table 4.1: Mean opinion score for packet loss Loss 0.0% 0.4% 0.8% 3.0% 5.0% 7.0% FM L 4.44 3.26 2.62 1.85 1.47 1.15 FM P 4.50 3.44 2.56 2.15 1.50 1.15 HM L 4.38 3.56 2.65 1.88 1.76 1.79 HM P 4.29 3.29 2.47 1.94 1.79 1.71 FT L 4.24 3.21 2.26 1.76 1.41 1.41 FT P 4.18 2.82 2.47 1.74 1.29 1.47

Table 4.2: Mean opinion score for delay variation Delay 150ms 2ms 150ms 4ms 150ms 8ms 150ms 12ms 150ms 16ms FM L 2.00 1.79 1.18 1.09 1.03 FM P 2.18 1.85 1.15 1.06 1.03 HM L 1.88 1.68 1.44 1.12 1.06 HM F 1.88 1.79 1.47 1.12 1.06 FT L 3.03 2.56 1.88 1.18 1.18 FT P 2.71 2.68 1.59 1.29 1.12

4.1

Packet loss

Figures 4.1 and 4.2 show the graphs of the MOS for the packet loss for the laptop and the mobile phone respectively. The graphs show the tendency that the smaller the values of loss the higher MOS, thus, better user perception of the video. As packet loss increases the MOS drops steeply, but it remains fair until values of packet loss between 0.4% and 0.8%. From 5% packet loss the value of the MOS is close to 1 (bad). This indicates that at and above this value the user perception quality makes them reject the video. This behaviour suggest that packet loss is an important factor to consider as for small values as the perception becomes annoying for the user. If this video is provided as a service will lead the user to stop watching the video. The video sequence encoded with H.264 and without distortions was graded with a MOS that lies between 4.50 and 4.18. This shows that the viewers in some cases are reluctant to score the videos as excellent. This behaviour was also found in other studies [26]. For the dierent videos aected with packet loss it is noticed that the video with the lowest MOS, in both cases, the laptop and the mobile phone is the football video. For the video Hall-monitor in both devices the MOS decline to poor (2) and then it seems that there is not a big variation between 3% and 7%. The video sequence foreman is the video with the lower MOS

4.1. PACKET LOSS

25

Foreman
5.00 4.50 4.00 3.50

Hall-monitor

Football

MOS

3.00 2.50 2.00 1.50 1.00 0 1 2 3 4 5 6 7

Packet Loss [%]

Figure 4.1: MOS for packet loss displayed on the laptop

Foreman
5.00 4.50 4.00 3.50

Hall-monitor

Football

MOS

3.00 2.50 2.00 1.50 1.00 0 1 2 3 4 5 6 7

Packet Loss [%]

Figure 4.2: MOS for packet loss displayed on the mobile phone

26

CHAPTER 4. RESULTS AND DISCUSSION

at 7%. As recommended by the International Telecommunications Union- Radiocommunications Sector (ITU-R) in the recommendation BT-500 [5] for subjective assessment of the quality of television pictures, together with the mean scores calculated previously the condence interval was calculated for each case. It is suggested to use a 95% condence interval. This means: With a probability of 95%, the absolute value of the dierence between the experimental mean score and the true mean score (for a very high number of observers) is smaller than the 95% condence interval [5]. The condence interval consists of an upper and a lower limit for the mean u. [uj k j k , uj k + j k ] where: sj k j k = 1.96 N sj k is calculated from the equation 4.2. The values calculated for the condence interval for packet loss are shown in the Figure 4.3. The x-axis shows the video sequence (FM- foreman, HMhall-monitor, FT- football), the device that was used to present the video sequence to the observer (L- laptop, P- mobile phone) and the percentage of packet loss emulated. The y-axis refers to the MOS. We can appreciate that there is not a big dierence within the three dierent video sequences in each of the packet loss values. The tendency shows that for bigger values of packet loss the rate degrades for all the video sequences. In general, for values above 5% of packet loss the observers rate is close to 1 (bad). Slightly higher values of MOS are shown for the Hall-monitor video sequence in both devices for values of packet loss of 5% and 7%. However, the assessment value is close to 1 (bad). The standard deviation for the videos and dierent display devices was plotted in Figure 4.4). The values range from 0.36 to 0.89. Lower values for this index, indicate minor divergence between the subject assessments. Generally, can be observed that the standard deviation is lower for the packet loss values of 5% and 7%, what means that the observers grades have less variability, thus, the observers agree that the quality of the video is between poor and bad. For the packet loss values in the middle it is noticeable higher deviation in the opinion, it is more dicult for the observers to decide the quality. (4.4) (4.3)

Standard Deviation
0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00

!"#$ !"##$ %"##$ &"##$ '"##$ ("##$

0.00

0.10

0.20

4.1. PACKET LOSS

0.4

FM L FM P

0.8

HM L

%&'()$#(*+(,-(./(0&-(.1)22$

Packet Loss [%]

HM P

3.0

FT L FT P

5.0

Figure 4.3: Condence interval (95%) for packet loss

Figure 4.4: Standard deviation for packet loss

7.0

)*$+$#"#,$ )*$-$#"#,$ .*$+$#"#,$ .*$-$#"#,$ )/$+$#"#,$ )/$-$#"#,$ )*$+$#"',$ )*$-$#"',$ .*$+$#"',$ .*$-$#"',$ )/$+$#"',$ )/$-$#"',$ )*$+$#"0,$ )*$-$#"0,$ .*$+$#"0,$ .*$-$#"0,$ )/$+$#"0,$ )/$-$#"0,$ )*$+$&"#,$ )*$-$&"#,$ .*$+$&"#,$ .*$-$&"#,$ )/$+$&"#,$ )/$-$&"#,$ )*$+$("#,$ )*$-$("#,$ .*$+$("#,$ .*$-$("#,$ )/$+$("#,$ )/$-$("#,$ )*$+$1"#,$ )*$-$1"#,$ .*$+$1"#,$ .*$-$1"#,$ )/$+$1"#,$ )/$-$1"#,$

27

28

CHAPTER 4. RESULTS AND DISCUSSION

4.2

Delay variation

The delay variation results were plotted in Figures 4.5 and 4.6. It is appreciated that for small increased values of delay variation the MOS decreases dramatically. For a variation of only 2ms the MOS for the foreman and hall-monitor videos decays to a value close to poor. The video sequence football is less aected by the delay variation for values between 2ms and 8ms. However, for bigger variations the MOS is similar for the three video sequences. Delay variation above 8ms for all the video sequences leads to a MOS close to bad (1) indicating a reject of the video from the observers. In the Figure 4.6 we can see that for the football sequence the MOS does not vary from 2ms to 4ms.
Foreman
5.00 4.50 4.00 3.50

Hall-monitor

Football

MOS

3.00 2.50 2.00 1.50 1.00 0 2 4 6 8 10 12 14 16

Delay Variation [ms]

Figure 4.5: MOS for delay variation displayed on the laptop The Figure 4.7 presents the condence interval values for delay variation. The x-axis shows the video sequence (FM- foreman, HM- hall-monitor, FTfootball), the device that was used to present the video sequence to the observer (L- laptop, P- mobile phone) and the percentage of packet loss emulated. The y-axis refers to the MOS. It is appreciated that the football video sequence gets higher rates between 2ms and 8ms, the higher rates become less obvious for the values of 12ms and 16ms. The standard deviation was plotted in Figure 4.8). The values range from 0.17 to 0.95 low values for this indicates minor divergence between the subject assessments. The standard deviation is low at small values of the delay variation, these results can be interpreted that at these values the users perception about the video quality varies less, users agree in a higher extent that the quality is bad. We can see in the graph slightly bigger values of the standard deviation for the football video sequence this could be attributed that the video sequence football got slightly better results than the other

4.2. DELAY VARIATION

29

Foreman
5.00 4.50 4.00 3.50

Hall-monitor

Football

MOS

3.00 2.50 2.00 1.50 1.00 0 2 4 6 8 10 12 14 16

Delay Variation [ms]

Figure 4.6: MOS for delay variation displayed on the mobile phone

("##$

'"##$

!"#$

&"##$

%"##$

!"##$ )*$+$%,-$ )*$.$%,-$ /*$+$%,-$ /*$.$%,-$ )0$+$%,-$ )0$*$%,-$ )*$+$',-$ )*$.$',-$ /*$+$',-$ /*$.$',-$ )0$+$',-$ )0$.$',-$ )*$+$1,-$ )*$.$1,-$ /*$+$1,-$ /*$.$1,-$ )0$+$1,-$ )0$.$1,-$ )*$+$!%,-$ )*$.$!%,-$ /*$+$!%,-$ /*$.$!%,-$ )0$+$!%,-$ )0$.$!%,-$ )*$+$!2,-$ )*$.$!2,-$ /*$+$!2,-$ /*$.$!2,-$ )0$+$!2,-$ )0$.$!2,-$ %&'()$#(*+(,-(./(0&-(./(123$%24&25),$

Figure 4.7: Condence interval (95%) for delay variation

30

CHAPTER 4. RESULTS AND DISCUSSION

two sequences for delay variation and the users have more discrepancy when assessing the video.
FM L
1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 0.20 0.10 0.00 2 4 8 12 16

FM P

HM L

HM P

FT L

FT P

Standard Deviation

Delay Variation [ms]

Figure 4.8: Standard deviation for delay variation Despite not adding both disturbances to the same video, packet loss and delay variation, we can notice that it is likely that the perception of quality in the video degrades more for small changes in the delay variation. This is similar to the ndings of the study performed by Calyam et al. [6] although their study was for the codec H.263 and adding dierent disturbances to the same video sequence. As we stated before, we chose the video sequences with dierent temporal characteristics as this factor aects the way the video is encoded and the GOP is structured. In the Claypool et al. [8] study for the MPEG-1 codec, they found that videos with few dierences between most frames, such as a talking head has low temporal aspect. This similar to the foreman video sequence chosen in this thesis. Videos with this characteristics may not degrade much under jitter or packet loss since viewers may not notice the delayed or missing frames. Claypool et al. [8] found that videos with high temporal aspect, like sports or music video clips, are more sensitive to these disturbances. Although we are using another codec in this experiment, we found that in the case of packet loss the video sequence with the slightly lower MOS is the football video, which is inline with their results. Contrary to the ndings of Claypool et al. [8], the football video sequence was rated the best for the delay variation case in this experiment. These variations could be caused by the fact that the packet loss and delayed packets emulated by NetEm is random, so we do not have control of which packets and which specic frames are aected. If we are unlucky and we get

4.3. MOBILE PHONE AND LAPTOP

31

an error in one of the key frames (I or P-frames) this error will be propagated to the entire GOP as is shown in Figure 2.2.

4.3

Mobile phone and laptop

The MOS for the packet loss and delay variation was plotted for both devices, the laptop and mobile phone in Figure 4.9 and Figure 4.10 respetively. For both graphs we can notice that the results are almost the same for both of the devices. The biggest dierence is found for packet loss of 0.4% that in the laptop obtained a MOS of 3.19 and in the mobile phone a slightly higher rate of 3.34.
Mobile Phone Laptop

4.50 4.00 3.50

MOS

3.00 2.50 2.00 1.50 1.00 0 0.4 0.8 3.0 5.0 7.0 Laptop Mobile Phone

Packet Loss [%]

Figure 4.9: MOS packet loss displayed on the laptop and mobile phone To identify if these variations are signicant we applied a hypothesis test matched-sample t test. This test is used when we have two matched or correlated samples, and when we need to test the dierence between two means [15]. In this specic case we want to compare the mean between the assessment rates obtained for the laptop and the one obtained when the observers used the mobile phone as displaying device. Thus the hypothesis is if uL = uP is true, then there is no dierence between doing the experiment on the mobile phone or on the laptop when using the same resolution in both devices. If we consider the dierence of the means uD = uL uP , then the hypothesis can also be expressed as: H : uD = uL uP = 0 where: (4.5)

32

CHAPTER 4. RESULTS AND DISCUSSION

Mobile Phone Laptop

5.00 4.50 4.00 3.50

MOS

3.00 2.50 2.00 1.50 1.00 2 4 8 12 16 Mobile Phone Laptop

Delay Variation [ms]

Figure 4.10: MOS delay variation displayed on the laptop and mobile phone uL is the mean for the laptop, uP is the mean for the mobile phone and uD is the dierence in means between the laptop and the mobile phone. This test needs the calculation of the tcalc parameter and then compare it with the ttable that is obtained the Students t distribution table [15]. The ttable value depends on the level of signicance, in this case a 95% condence interval is used. Thus, the level of signicance is 0.05, the degrees of freedom (df) is dened as the number of observers minus one (N-1 ) is 33. The value from the table to compare in our case corresponds ttable = 2.042. The tcalc is dened as: tcalc = D uD
s D N

(4.6)

where D and sD are the mean and standard deviation of the dierence scores (dierence between the data obtained for the laptop and mobile phone); uD in this case is zero as our hypothesis and N is the number of dierence scores (number of pairs). If we nd that tcalc < ttable we fail to reject the hypothesis, so there is no evidence to suggest that the dierent devices aect the perception of the shown video. The Table 4.3presents the results for the calculations for each of the video pairs, referring to the same video sequence presented on the laptop and on the mobile phone. DV stands for delay variation in the table. The tcalc is compared with the ttable as explained before. For the most of the video sequences, there is no evidence to suggest that the dierent devices aect the perception of the shown video. Therefore, we can conclude that there is not a signicant dierence be-

4.3. MOBILE PHONE AND LAPTOP

33

Table 4.3: Matched-sample t test results Video sequence FM 0.0% loss FM 0.4% loss FM 0.8% loss FM 3.0% loss FM 5.0% loss FM 7.0% loss FM 2ms DV FM 4ms DV FM 8ms DV FM 12ms DV FM 16ms DV HM 0.0% loss HM 0.4% loss HM 0.8% loss HM 3.0% loss HM 5.0% loss HM 7.0% loss HM 2ms DV HM 4ms DV HM 8ms DV HM 12ms DV HM 16ms DV FT 0.0% loss FT 0.4% loss FT 0.8% loss FT 3.0% loss FT 5.0% loss FT 7.0% loss FT 2ms DV FT 4ms DV FT 8ms DV FT 12ms DV FT 16ms DV tcalc 0.63 1.14 0.42 2.05 0.25 0.00 1.36 0.70 0.44 0.44 0.00 0.90 2.50 1.36 0.44 0.27 0.83 0.00 1.28 0.37 0.00 0.00 0.42 3.20 2.03 0.25 1.16 0.63 2.46 0.89 2.73 1.68 0.81 Result Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis. Reject the hypothesis. Fail to reject the hypothesis. Reject the hypothesis. Fail to reject the hypothesis. Fail to reject the hypothesis.

34

CHAPTER 4. RESULTS AND DISCUSSION

tween doing the experiment in the mobile phone and in the laptop displaying the same resolution. Overall, the same results were obtained for both devices.

4.4

Validity Threats

Perceptions of video quality change over time with users having higher expectations of quality as time moves forward. This type of assessments needs to be updated constantly as results from time to time can vary. As an example, some years ago was not common to have mobile phones with video capabilities. Improvements in the codecs, network equipment and mechanism to minimise these distortions have been added. As explained in the results section, for this experiment NetEm drops the packets randomly, so the results are likely to have some variations. It was not controlled which type of packets were droppedI-frames or P-frames with the loss of dierent types of packets aecting video quality in dierent ways. This experiment applied the baseline prole and pre-set les suggested for mobile devices. For future studies it is recommended to change the structure of the GOP, increasing frequencies of I-frames and analyse if the cascading eects caused by errors are reduced. During the assessment sessions was noticed that the observers got tired of watching the same video sequences several times and rating a large number of videos. This meant that in the last part of the session participants were not concentrating as much as they were at the beginning. To minimise the aect of this bias, the videos were presented randomly, alternating the order of the displaying devices between participants. For future work we recommend to reduce the number video sequences for participants to evaluate.

Chapter 5

Conclusion
This thesis presents the results of an experiment created to understand user perception of video quality for the codec H.264 aected with packet loss and delay variation on selected mobile devicesa mobile phone and a laptop. An experimental network set-up was created to obtain the video sequences used during assessment sessions. The data collected from the observers was analysed using statistical methods. This thesis aimed to answer one main question: How do users perceive video quality with packet loss and delay variation for video encoded with H.264 on selected mobile devices? This research question was further broken into three sub-questions. The rst research sub-question, RQ1.1, sough to understand user perceptions of video quality with packet loss and delay variation for video encoded with H.264 on mobile phones. It was found that with increasing amounts of packet loss and delay variation the video quality perception degrades. Further, for values above 5% of packet loss the rates were poor for all the videos, which indicates user rejection of the video. The perceived quality of video for the video sequences aected with delay variation shows that for increasing variations the user rate decays rapidly. The videos with a delay variation value greater than 8ms were rated as poor, indicating user rejection of the video. The second research sub-question, RQ1.2, sought to understand user perceptions of video quality with packet loss and delay variation for video encoded with H.264 on laptop computers. The results founded for laptop computers and mobile phones were the same for smaller values of packet loss or delay variation the higher rate was perceived by the users. This takes us to the third research question, RQ1.3, that aims to understand if users have dierent expectations of video quality on mobile phones and laptop computers. The results show the same tendency for both devices. Further, the statistical test applied demonstrates that there is not enough evidence to suggest that the dierent devices aect the user perception. It is important to mention that the resolution of the video needs to be the same 35

36

CHAPTER 5. CONCLUSION

for both devices. These results show that users have the same expectations for laptops and mobile devices. This nding should be of interest to internet service providers as it shows their users expectations are high. They demand to have similar quality when they watch videos using mobile phones or computers, which is a challenge if we consider that mobile phones have lower processing capabilities than computers and less reliable internet infrastructure. These ndings highlight the importance for network providers and engineers to put in place mechanisms to avoid packet loss and delay variation. Network engineers could also consider, improvements in networking equipment that would be able to identify dierent kinds of types of packets and prioritise them according to the signicance to the video. In the case of H.264 this would mean putting a greater priority on I-frames packets, and if packets are dropped, trying to ensure they are the less-critical B-frame packets. Further research needs to be done in to how the structure of the GOP can aects the propagation of errors that aect the quality of video. This includes extension of the experiment presented in this thesis to use dierent proles of the H.264 codec and dierent metrics, like the length of the GOP and distribution of frames. Analysis could also be done of the packets captured in the experimental network to try to understand which packets were lost and how they eect the dierent frames. It may be necessary to conduct further experiments to fully understand the eect of losing dierent types of packets.

Bibliography
[1] Xiph.org test media. [Online] http://media.xiph.org/video/derf/, accessed on July 2010. [2] John G. Apostolopoulos, Wai tian Tan, and Susie J. Wee. Video streaming: Concepts, algorithms, and systems. Technical report, HP Laboratories, 2002. [3] Hussein Muzahim Aziz, H akan Grahn, and Lars Lundberg. Eliminating the freezing frames for the mobile user over unreliable wireless networks. In Proceedings of the 6th International Conference on Mobile Technology, Application &#38; Systems, Mobility 09, pages 57:157:4, 2009. ACM. [4] L. Bouchard. Multimedia software for mobile phones. Software, IEEE, 27(3):8 10, 2010. [5] ITU-R BT.500-11. Methodology for the subjective assessment of the quality of television pictures. International Telecommunications Union Radiocommunication Sector, 2002. [6] Prasad Calyam, Mukundan Sridharan, Weiping Mandrawa, and Paul Schopis. Performance Measurement and Analysis of H.323 trac. In Chadi Barakat and Ian Pratt, editors, Passive and Active Network Measurement, volume 3015 of Lecture Notes in Computer Science, pages 137146. Springer Berlin / Heidelberg, 2004. [7] L.U. Choi, M.T. Ivrlac, E. Steinbach, and J.A. Nossek. Analysis of distortion due to packet loss in streaming video transmission over wireless communication links. In Image Processing, 2005. ICIP 2005. IEEE International Conference on, volume 1, pages I 18992, 2005. [8] Mark Claypool and Jonathan Tanner. The eects of jitter on the peceptual quality of video. In Multimedia 99: Proceedings of the seventh ACM international conference on Multimedia (Part 2), pages 115118, 1999. ACM. 37

38

BIBLIOGRAPHY

[9] F. De Simone, M. Tagliasacchi, M. Naccari, S. Tubaro, and T. Ebrahimi. A H.264/AVC video database for the evaluation of quality metrics. In 2010 IEEE International Conference on Acoustics Speech and Signal Processing (ICASSP), pages 2430 2433, 2010. [10] Android developers. Android supported media formats. [Online] http://developer.android.com/guide/appendix/media-formats.html, accessed on August 2010. [11] Endace. Endace measurement systems. http://www.endace.com/, accessed September 2010. [Online]

[12] FFMPEG. [Online] http://www.mpeg.org, accessed on June 2010. [13] The Linux Foundation. [Online] http://www.linuxfoundation.org/collaborate/ workgroups/networking/netem, accessed on June 2010. [14] David Hands and Miles Wilkins. A study of the impact of network loss and burst size on video streaming quality and acceptability. In Michel Diaz, Philippe Owezarski, and Patrick Snac, editors, Interactive Distributed Multimedia Systems and Telecommunication Services, volume 1718 of Lecture Notes in Computer Science, pages 4557. Springer Berlin / Heidelberg, 1999. [15] David C. Howell. Statistical Methods for Psychology. Wadsworth, 7 edition, 2010. [16] A. Huszak and S. Imre. Analysing GOP structure and packet loss eects on error propagation in MPEG-4 video streams. In 4th International Symposium on Communications, Control and Signal Processing (ISCCSP), 2010, pages 15, 2010. [17] Apple Inc. iPhone 4 technical specications. [Online] http://www.apple.com/iphone/specs.html and http://www.apple.com/itunes/podcasts/specs.html, accessed on August 2010. [18] Satu Jumisko-Pyykk and Jukka Hkkinen. Evaluation of subjective o a video quality of mobile devices. In Multimedia 05: Proceedings of the 13th annual ACM International Conference on Multimedia, pages 535 538, 2005. [19] Brent Kelly. Quality of Service In Internet Protocol (IP) Networks. Wainhouse Research, 2002. [20] Hendrik Knoche, John D. McCarthy, and M.Angela Sasse. Can small be beautiful?: Assessing image resolution requirements for mobile TV. In Multimedia 05: Proceedings of the 13th annual ACM International Conference on Multimedia, pages 829838, 2005.

BIBLIOGRAPHY

39

[21] P. D. Leedy and J. E. Ormrod. Practical Research: Planning and Design. Prentice Hall, 2005. [22] Ting-Lan Lin, S. Kanumuri, Yuan Zhi, D. Poole, P.C. Cosman, and A.R. Reibman. A versatile model for packet loss visibility and its application to packet prioritization. Image Processing, IEEE Transactions on, 19(3):722 735, 2010. [23] Dmitri Loguinov and Hayder Radha. Measurement study of low-bitrate internet video streaming. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, IMW 01, pages 281293, 2001. ACM. [24] OPTICOM. Perceptual evaluation of video quality. http://www.pevq.org/, accessed July 2010. [Online]

[25] ITU-T P.910. Subjective video quality assessment methods for multimedia applications. International Telecommunications Union Telecommunication Sector, 1999. [26] M.H. Pinson, S. Wolf, and G. Cermak. HDTV subjective quality of H.264 vs. MPEG-2, with and without packet loss. Broadcasting, IEEE Transactions on, 56(1):86 91, mar. 2010. [27] Iain E. Richardson. H.264 and MPEG-4 Video Compression: Video Coding for Next Generation Multimedia. Wiley, 1st Edition, August 2003. [28] M. Ries, O. Nemethova, and M. Rupp. Video quality estimation for mobile H. 264/AVC video streaming. Journal of Communications, 3(1):41 50, 2008. [29] J. Shaikh, T.N. Minhas, P. Arlos, and M. Fiedler. Evaluation of delay performance of trac shapers. pages 1 8, may. 2010. [30] S. Spirou. Packet reordering eects on the subjective quality of broadband digital television. pages 1 6, 2006. [31] Thomas Stockhammer, Miska M. Hannuksela, and Thomas Wiegand. H.264/AVC in wireless environments. IEEE Transactions on Circuits and Systems for Video Technology, 13:657663, 2003. [32] Vasos Vassiliou, Pavlos Antoniou, Iraklis Giannakou, and Andreas Pitsillides. Requirements for the transmission of streaming video in mobile wireless networks. In Stefanos Kollias, Andreas Stafylopatis, Wlodzislaw Duch, and Erkki Oja, editors, Articial Neural Networks ICANN 2006, volume 4132 of Lecture Notes in Computer Science, pages 528 537. Springer Berlin / Heidelberg, 2006.

40 [33] VideoLAN. 2010.

BIBLIOGRAPHY [Online] http://www.videolan.org/vlc/, accessed June [Online]

[34] VQEG. Video quality experts group. http://www.its.bldrdoc.gov/vqeg/, accessed July 2010.

[35] Zhou Wang, Hamid R. Sheikh, and Alan C. Bovik. Objective video quality assessment. In In the handbook of video databases: Design and applications, pages 10411078. CRC Press, 2003. [36] S. Winkler and F. Dufaux. Video quality evaluation for mobile applications. In Proc. of SPIE Conference on Visual Communications and Image Processing, volume 5150, pages 593603. Citeseer, 2003. [37] Dapeng Wu, Y.T. Hou, Wenwu Zhu, Ya-Qin Zhang, and J.M. Peha. Streaming video over the internet: approaches and directions. Circuits and Systems for Video Technology, IEEE Transactions on, 11(3):282 300, mar. 2001.

Appendix A

Video Encoding Information

This appendix presents information related to the encoding of the video sequences.

A.1

Procedure for video sequences creation

Description of the procedure followed to create the video sequences. Initialise VLC client in the R laptop to be able to receive and save the UDP stream. vlc -vvv udp://@:1234 --sout file/mp4: /home/oziel/Desktop /ThesisVideos/Received_Video.mp4

Congure the packet loss or delay variation in the TS using the NetEm (see section NetEm conguration) tc commands. Set a le name in the MP to save the information of the captured packets (.cap les) and start the MP. Start VLC server in the S laptop. Set the IP address and port to send the stream, and choose the video sequence to be sent. vlc -vvv /home/oziel/Desktop/ThesisVideos/Videos/ football_mobile.mp4 --sout=#udp{dst=192.168.1.2:1234} --sout-keep

After each video streaming is nished a ush of the DAG cards was performed to force out any remaining packet. 41

42

APPENDIX A. VIDEO ENCODING INFORMATION

A.2

Pre-set FFMPEG les

These are the pre-set les used to encode the video with FFMPEG. These pre-set les are included with the standard installation of the software.

libx264-ipod320.preset coder=0 bf=0 ags2=-wpred-dct8x8 level=13 maxrate=768000 bufsize=3000000 wpredp=0

libx264-slow.preset coder=1 ags=+loop cmp=+chroma partitions=+parti8x8+parti4x4+partp8x8+partb8x8 me method=umh subq=8 me range=16 g=250 keyint min=25 sc threshold=40 i qfactor=0.71 b strategy=2 qcomp=0.6 qmin=10 qmax=51 qdi=4 bf=3 refs=5 directpred=3 trellis=1 ags2=+bpyramid+mixed refs+wpred+dct8x8+fastpskip wpredp=2 rc lookahead=50

A.3. COMMAND LINE FFMPEG

43

A.3

Command line FFMPEG

This is the command that was used to encode the raw video with the codec H.264.
ffmpeg -i /home/oziel/Videos/football_cif.y4m -s 320x240 -r 30 -vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Videos/football\mobile.mp4

A.4

Output information FFMPEG encoding videos from Raw to H.264

This is the information that FFMPEG gives as feedback after encoding the videos with the codec H.264. Foreman video sequence.

oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/foreman_cif.y4m -vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Pictures/foreman_mobile.mp4

-s 320x240 -r 30

FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers built on Nov 8 2010 09:30:14 with gcc 4.4.3 configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-libvpx libavutil 50.32. 6 / 50.32. 6 libavcore 0.12. 0 / 0.12. 0 libavcodec 52.94. 3 / 52.94. 3 libavformat 52.84. 0 / 52.84. 0 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter 1.58. 0 / 1.58. 0 libswscale 0.12. 0 / 0.12. 0 libpostproc 51. 2. 0 / 51. 2. 0 [yuv4mpegpipe @ 0x8e8c560] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from /home/oziel/Pictures/foreman_cif.y4m: Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc [buffer @ 0x8e95400] w:352 h:288 pixfmt:yuv420p [scale @ 0x8ef5e80] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004 [libx264 @ 0x8e8d860] using SAR=255/254 [libx264 @ 0x8e8d860] VBV buffer (3000) > level limit (2000) [libx264 @ 0x8e8d860] using cpu capabilities: MMX2 Cache64 [libx264 @ 0x8e8d860] profile Constrained Baseline, level 1.3 [libx264 @ 0x8e8d860] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=0 ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=768 ratetol=5.2 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000 ip_ratio=1.41 aq=1:1.00 nal_hrd=none [ipod @ 0x8e900a0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file Output #0, ipod, to /home/oziel/Pictures/foreman_mobile.mp4: Metadata: encoder : Lavf52.84.0 Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding frame= 300 fps= 32 q=-1.0 Lsize= 983kB time=9.93 bitrate= 810.9kbits/s video:980kB audio:0kB global headers:0kB muxing overhead 0.321519% frame I:2 Avg QP:21.82 size: 18688 [libx264 @ 0x8e8d860] frame P:298 Avg QP:22.24 size: 3240 [libx264 @ 0x8e8d860] mb I I16..4: 8.2% 0.0% 91.8% [libx264 @ 0x8e8d860] mb P I16..4: 0.1% 0.0% 1.4% P16..4: 47.8% 28.9% 14.7% 0.0% 0.0% skip: 7.1% [libx264 @ 0x8e8d860] coded y,uvDC,uvAC intra: 91.1% 92.7% 67.4% inter: 43.9% 47.0% 9.0% [libx264 @ 0x8e8d860] i16 v,h,dc,p: 31% 12% 7% 50% [libx264 @ 0x8e8d860] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 11% 3% 9% 20% 14% 17% 8% 10%

44

APPENDIX A. VIDEO ENCODING INFORMATION

[libx264 @ 0x8e8d860] i8c dc,h,v,p: 43% 20% 25% 12% [libx264 @ 0x8e8d860] ref P L0: 69.4% 13.5% 8.9% 4.5% [libx264 @ 0x8e8d860] kb/s:802.38

3.7%

Hall-monitor video sequence.

oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/hall_monitor_cif.y4m -s 320x240 -r 30 -vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Pictures/hall_monitor_mobile.mp4 FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers built on Nov 8 2010 09:30:14 with gcc 4.4.3 configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-libvpx libavutil 50.32. 6 / 50.32. 6 libavcore 0.12. 0 / 0.12. 0 libavcodec 52.94. 3 / 52.94. 3 libavformat 52.84. 0 / 52.84. 0 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter 1.58. 0 / 1.58. 0 libswscale 0.12. 0 / 0.12. 0 libpostproc 51. 2. 0 / 51. 2. 0 [yuv4mpegpipe @ 0xa13c560] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from /home/oziel/Pictures/hall_monitor_cif.y4m: Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc [buffer @ 0xa1454e0] w:352 h:288 pixfmt:yuv420p [scale @ 0xa1a5e50] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004 [libx264 @ 0xa13d830] using SAR=255/254 [libx264 @ 0xa13d830] VBV buffer (3000) > level limit (2000) [libx264 @ 0xa13d830] using cpu capabilities: MMX2 Cache64 [libx264 @ 0xa13d830] profile Constrained Baseline, level 1.3 [libx264 @ 0xa13d830] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=0 ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=768 ratetol=5.2 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000 ip_ratio=1.41 aq=1:1.00 nal_hrd=none [ipod @ 0xa1400d0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file Output #0, ipod, to /home/oziel/Pictures/hall_monitor_mobile.mp4: Metadata: encoder : Lavf52.84.0 Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding frame= 300 fps= 32 q=-1.0 Lsize= 930kB time=9.93 bitrate= 766.9kbits/s its/s video:927kB audio:0kB global headers:0kB muxing overhead 0.340038% frame I:2 Avg QP:21.91 size: 13137 [libx264 @ 0xa13d830] frame P:298 Avg QP:22.60 size: 3094 [libx264 @ 0xa13d830] mb I I16..4: 17.8% 0.0% 82.2% [libx264 @ 0xa13d830] mb P I16..4: 0.1% 0.0% 0.2% P16..4: 60.6% 24.0% 13.1% 0.0% 0.0% skip: 2.0% [libx264 @ 0xa13d830] coded y,uvDC,uvAC intra: 91.7% 99.5% 89.9% inter: 30.3% 94.5% 39.2% [libx264 @ 0xa13d830] i16 v,h,dc,p: 20% 7% 1% 72% [libx264 @ 0xa13d830] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 13% 2% 11% 13% 11% 12% 8% 9% [libx264 @ 0xa13d830] i8c dc,h,v,p: 43% 25% 24% 8% [libx264 @ 0xa13d830] ref P L0: 39.7% 19.4% 18.5% 11.3% 11.2% [libx264 @ 0xa13d830] kb/s:758.65

Football video sequence.

oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/football_cif.y4m -s 320x240 -r 30 -vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Pictures/football_mobile.mp4

FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers built on Nov 8 2010 09:30:14 with gcc 4.4.3 configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-libvpx libavutil 50.32. 6 / 50.32. 6 libavcore 0.12. 0 / 0.12. 0 libavcodec 52.94. 3 / 52.94. 3 libavformat 52.84. 0 / 52.84. 0 libavdevice 52. 2. 2 / 52. 2. 2 libavfilter 1.58. 0 / 1.58. 0 libswscale 0.12. 0 / 0.12. 0

A.4. OUTPUT INFORMATION FFMPEG ENCODING VIDEOS FROM RAW TO H.26445

libpostproc 51. 2. 0 / 51. 2. 0 [yuv4mpegpipe @ 0x9f00560] Estimating duration from bitrate, this may be inaccurate Input #0, yuv4mpegpipe, from /home/oziel/Pictures/football_cif.y4m: Duration: N/A, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 30 fps, 30 tbr, 30 tbn, 30 tbc [buffer @ 0x9f09410] w:352 h:288 pixfmt:yuv420p [scale @ 0x9f69f00] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004 [libx264 @ 0x9f01860] using SAR=255/254 [libx264 @ 0x9f01860] VBV buffer (3000) > level limit (2000) [libx264 @ 0x9f01860] using cpu capabilities: MMX2 Cache64 [libx264 @ 0x9f01860] profile Constrained Baseline, level 1.3 [libx264 @ 0x9f01860] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec - Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=0 ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=768 ratetol=5.2 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000 ip_ratio=1.41 aq=1:1.00 nal_hrd=none [ipod @ 0x9f040a0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file Output #0, ipod, to /home/oziel/Pictures/football_mobile.mp4: Metadata: encoder : Lavf52.84.0 Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc Stream mapping: Stream #0.0 -> #0.0 Press [q] to stop encoding frame= 260 fps= 28 q=-1.0 Lsize= 793kB time=8.60 bitrate= 755.0kbits/s video:790kB audio:0kB global headers:0kB muxing overhead 0.359481% frame I:2 Avg QP:26.58 size: 8598 [libx264 @ 0x9f01860] frame P:258 Avg QP:31.01 size: 3065 [libx264 @ 0x9f01860] mb I I16..4: 16.3% 0.0% 83.7% [libx264 @ 0x9f01860] mb P I16..4: 0.4% 0.0% 7.3% P16..4: 38.1% 26.3% 12.6% 0.0% 0.0% skip:15.3% [libx264 @ 0x9f01860] coded y,uvDC,uvAC intra: 90.5% 85.9% 52.6% inter: 39.2% 35.0% 3.6% [libx264 @ 0x9f01860] i16 v,h,dc,p: 18% 66% 2% 14% [libx264 @ 0x9f01860] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 14% 4% 10% 15% 13% 16% 8% 12% [libx264 @ 0x9f01860] i8c dc,h,v,p: 51% 20% 20% 10% [libx264 @ 0x9f01860] ref P L0: 85.7% 6.2% 4.2% 1.9% 2.0% [libx264 @ 0x9f01860] kb/s:745.82

46

APPENDIX A. VIDEO ENCODING INFORMATION

Appendix B

Assessment material
B.1 Set of videos for the subjective assessment

Table B.1 shows in the rst column the video disturbance applied, the second column shows the original received video name and the last two columns the renamed les for the laptop and the mobile phone.

B.2

Questionnaire for the assessment session

Screen-shots of the online questionnaire used during the observers sessions are shown in Figures B.1 B.2, B.3 and B.4.

47

Table B.1: Set of videos for the subjective assessment APPENDIX B. ASSESSMENT MATERIAL
Disturbance Loss 5% Delay 150ms 2ms Loss 0.8% Delay 150ms 16ms Loss 3% Delay 150ms 12ms Delay 150ms 4ms Loss 0.4% Delay 150ms 8ms H.264 Original Loss 7% Delay 150ms 2ms Loss 3% Loss 0.4% Delay 150ms 8ms H.264 Original Loss 7% Delay 150ms 4ms Loss 0.8% Delay 150ms 16ms Loss 5% Delay 150ms 12ms football football football football football football football football football football football foreman foreman foreman foreman foreman foreman foreman foreman foreman foreman foreman Delay 150ms 12ms Loss 5% Loss 0.4% Delay 150ms 2ms Loss 3% H.264 Original Delay 150ms 16ms Delay 150ms 4ms Loss 0.8% Loss 7% Delay 150ms 8ms delay150v2 2.mp4 loss3 3.mp4 lossP4 1.mp4 delay150v8 3.mp4 original 1.mp4 loss7 2.mp4 delay150v4 1.mp4 lossP8 1.mp4 delay150v16 3.mp4 loss5 2.mp4 delay150v12 3.mp4 delay150v12 3.mp4 loss5 3.mp4 lossP4 1.mp4 delay150v2 3.mp4 loss3 2.mp4 original 2 delay150v16 2.mp4 delay150v4 3.mp4 lossP8 1.mp4 loss7 1.mp4 delay150v8 2.mp4 Football Football Football Football Football Football Football Football Football Football Football Foreman Foreman Foreman Foreman Foreman Foreman Foreman Foreman Foreman Foreman Foreman A.mp4 B.mp4 C.mp4 D.mp4 E.mp4 F.mp4 G.mp4 H.mp4 I.mp4 J.mp4 K.mp4 A.mp4 B.mp4 C.mp4 D.mp4 E.mp4 F.mp4 G.mp4 H.mp4 I.mp4 J.mp4 K.mp4 Original File Received hallmonitor loss5 1.mp4 hallmonitor delay150v2 3.mp4 hallmonitor lossP8 2.mp4 hallmonitor delay150v16 1.mp4 hallmonitor loss3 1.mp4 hallmonitor delay150v12 2.mp4 hallmonitor delay150v4 3.mp4 hallmonitor lossP4 1.mp4 hallmonitor delay150v8 3.mp4 hallmonitor original 3.mp4 hallmonitor loss7 1.mp4 Renamed for Laptop Hallmonitor A.mp4 Hallmonitor B.mp4 Hallmonitor C.mp4 Hallmonitor D.mp4 Hallmonitor E.mp4 Hallmonitor F.mp4 Hallmonitor G.mp4 Hallmonitor H.mp4 Hallmonitor I.mp4 Hallmonitor J.mp4 Hallmonitor K.mp4

Renamed for Mobile Phone HallMon K.mp4 HallMon J.mp4 HallMon I.mp4 HallMon H.mp4 HallMon G.mp4 HallMon F.mp4 HallMon E.mp4 HallMon D.mp4 HallMon C.mp4 HallMon B.mp4 HallMon A.mp4 FootballM FootballM FootballM FootballM FootballM FootballM FootballM FootballM FootballM FootballM FootballM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM ForemanM

K.mp4 B.mp4 C.mp4 D.mp4 E.mp4 F.mp4 G.mp4 H.mp4 I.mp4 J.mp4 A.mp4

K.mp4 J.mp4 I.mp4 H.mp4 G.mp4 F.mp4 E.mp4 D.mp4 C.mp4 B.mp4 A.mp4

48

B.2. QUESTIONNAIRE FOR THE ASSESSMENT SESSION

49

Figure B.1: Questionnaire

Figure B.2: Questionnaire

Figure B.3: Questionnaire

Figure B.4: Questionnaire

Master Thesis Telecommunication Engineering Thesis No: MEE21322 November 2010

Simultaneous Mobility Management in Seamless Handover by using mobile SCTP (mSCTP)

Mohammd Iqbal Md. Ibrahim Chowdhury

School of Engineering Blekinge Institute of Technology SE - 371 79 Karlskrona Sweden

i

This thesis is submitted to the School of Computing 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 Twenty weeks of full time studies.

Contact Information: Author(s): Mohammad Iqbal Email: [email protected] Md. Ibrahim Chowdhury Email: [email protected]

University Advisor: Yong Yao & Kaibo Zhou School of Computing Blekinge Institute of Technology

Examiner: Dr. Patrik Arlos, PhD School of Computing Blekinge Institute of Technology School of Engineering Blekinge Institute of Technology SE - 371 79 Karlskrona Sweden

School of Engineering Blekinge Institute of Technology SE - 371 79 Karlskrona Sweden

ii

Internet Phone Fax

: www.bth.se /com : +46 455 38 50 00 : +46 455 38 50 57

ABSTRACT
This thesis proposes a new solution approach for the simultaneous mobility issues in seamless handover for next generation wireless networks and envisages the vision of seamless roaming in IP mobility. We investigate the key issues of simultaneous mobility: handover management and the location management. A new scheme is designed to minimize handover latency between two homogeneous networks with location management support while handover occurs. One of the most emerging techniques in recent research projects for mobility management is mobile Stream Transmission Control Protocol (mSCTP). The multihoming feature of Stream Control Transmission Protocol (SCTP) and dynamic address reconfiguration (DAR) extension of SCTP are applied in the proposed solution to achieve improved seamless performance. In this project, we examined the comprehensive and thoughtful study of the phenomena Simultaneous Mobility along with Simultaneous Handover for mSCTP. We used an additional Location Server (LS) to ensure location management between simultaneous moving mobile nodes (MNs) while crossing a threshold for a smooth simultaneous handover. The most important part of this thesis is dedicated to design a new model of simultaneous mobility based on step_length and the implementation of the model i.e., mSCTP with LS to solve the simultaneous mobility issues. The proposed scheme implemented on NS2 simulations and performance evaluations are scrutinized to demonstrate the comparison of proposed simultaneous handover latency with LS and without LS. The results show that our proposed approach has improved performance in reducing handover delay as well as handling simultaneous mobility issues in seamless handover. Keywords mSCTP, Simultaneous Mobility, Location Management, Handover Latency, Location Server (LS), step_length, NS-2.

iii

ACKNOWLEDGEMENTS
We are most grateful to Almighty Allah for his loyal help, which gave us much more strength for all kind of achievements at the time of our project work and enabled us to complete the work successfully. We are thankful to our supervisors to give us appropriate suggestion during our whole project and for exposing us to the beauty of learning. We are also thankful to all of our friends who inspired us all the time to carry on this thesis. They provided us their invaluable support and assistance during our whole study period. ..Mohammad Iqbal & Md. Ibrahim Chowdhury I am thankful to Allah, the almighty to whom I offer all my worships and sacrifices, who know the best of knowledge and from whom I expect the best rewards in heaven. I extend my gratitude to several people. My parents: Abdul Hamid Chowdhury, and Rahima Akhter Begum, who are my basis of existence in this world. My lifetime mentor and maternal uncle, Professor Dr. Muhammad Loqman, one of the prominent founders of International Islamic University Chittagong (IIUC), Bangladesh. My advisors in this thesis, Yong Yao and Kaibo Zhou who lead towards the right research track and planted the research interests in my heart. My hearty appreciation goes to all my teachers and friends all over the world. I am grateful to the examiner Dr. Patrik Arlos and my program manager Mikael sman. I also share my contributions to all the fascinating instructors and inspiring surroundings of BTH. ..Md. Ibrahim Chowdhury First of all, I thank Allah for giving me strength and ability to complete this work. I am grateful to my family; who are, always with me in every step of my life. Specially, my brother-in-law, Balaet Hossain, working in Nokia Corporation, always gave me support for everything from my bachelor study to now. My mothers prayer is always with me which leads me the success to accomplish this thesis work. I would like to express my deepest gratitude to my supervisors: Mr Yong Yao and Mr. Kaibo Zhou for all of the valuable discussions, useful advice and encouragement through the study. Their overly enthusiasm and integral view on research has made a deep impression on me. I owe my respect to them, for whom we find the right path to solve the thesis conundrum. I appreciate the system of thesis currently running in BTH. I expressed my gratitude to my examiner Dr. Patrik Arlos for his support. My program manager Mikael sman is a helpful man and I got much more help from him during my study period in BTH.

..Mohammad Iqbal
In the end, we are thankful to Blekinge Institute of Technology which gave us sufficient knowledge to the way of build our professional career in current competition of worlds job market.

iv

TABLE OF CONTENTS
Abstract................... Acknowledgments.. Table of Contents....... List of Figures List of Tables . Acronyms Chapter 1. Introduction 1.1 Research Design.. 1.1.1 Research Methodology .. 1.1.2 Main Problems 1.1.3 Research Questions. 1.1.4 Aims and Objectives . 1.1.5 Motivation . 1.1.6 Contribution ... Thesis Outline. III IV V VII VIII IX 1 2 2 4 5 5 5 6 6 7 7 7 7 8 8 8 9 9 9 10 10 11 11 12 12 12 12 13

1.2

Chapter 2. Background....... 2.1 2.2 Simultaneous Mobility and Handover Stream Control Transmission Protocol (SCTP).. 2.2.1 SCTP association... 2.2.2 Multi-homing........ 2.2.3 Multi-streaming............. SCTP Packet Structure Mobile SCTP (mSCTP).......... Related works...... 2.5.1 Simultaneous mobility solution by mSCTP with RSerPool 2.5.2 Simultaneous mobility under asymmetric mobility conditions.......................... 2.5.3 Managing Simultaneous Mobility of IP hosts..

2.3 2.4 2.5

Chapter 3. Simulation Tool & Methodology............... 3.1 3.2 Network Simulator 2 (NS2).... Simulation with NS2... 3.2.1 Structure of Wired and Mobile nodes .. 3.2.2 Wireless Simulation by NS2. 3.2.3 Trace File................... Simulation Methodologies..

3.3

Chapter 4. Proposed Model for Simultaneous Mobility with Location Management 4.1 NS2 based architectural model for Simultaneous Mobility with mSCTP... 4.2 Location management with Location Server (LS).. 4.2.1 LS setup and management process. 4.3 Solution of Simultaneous Mobility issues... 4.3.1 Mobile nodes location detection and configuration 4.3.2 LS enabled Simultaneous Mobility management and Simultaneous Handover... 4.3.2.1 Association setup........................... 4.3.2.2 Dynamic Address Reconfiguration (DAR) 4.3.2.3 Simultaneous Mobility process and Handover 4.3.2.4 Context Analysis 4.3.2.5 Timing diagram.. 4.4 System constraints and Risk analysis.. 4.4.1 System constraints.. 4.4.2 Risk analysis....... Chapter 5. Implementation.. 5.1 Objectives of analysis..... 5.1.1 System requirements and challenges (cost analysis and etc.). 5.1.2 Parameter setup and assumptions of simulation. 5.2 Simulations.. 5.2.1 Definition of performance matrices for simulation scenarios.. 5.2.2 Simulation scenarios and Observations. 5.2.3 Simulation insight.. 5.2.4 Incorporation of modeling into solution............ 5.2.5 Execution of mSCTP patch....................... 5.2.6 LS functionalities 5.2.7 Location Management by LS .... Chapter 6. Experimental Results. 6.1 6.2 6.3 LS performance... Handover Latency... Confidence Interval (CI) analysis.......

14 14 16 16 18 18 19 20 20 20 21 21 22 22 23 24 24 24 24 27 27 28 33 34 35 37 37 40 40 42 44 47 47 47 48 51

Chapter 7. Conclusion and Future work. 7.1 7.2 Conclusion... Future work.

REFERENCES............... APPENDIX.

vi

LIST OF FIGURES
3.1 3.2 3.3 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 NS-2 Architectural view. Trace File format SCTP node outlook............. The simultaneous mobility of MN_0 and MN_1 Simultaneous Mobility model with random step_length Simultaneous Mobility support by LS Location management Process Integrated structure of TCL and LS Modified association setup.......................................................................... First address reconfiguration case............................................................... Mobility Process. Timing diagram of new approach of mSCTP for simultaneous mobility... The simultaneous mobility scenario with Brink plane Showing random movements of MN_0 and MN_1 proceeding with random step_length within range (0-750).................... Showing random movements of MN_0 and MN_1 proceeding with random step_length..................... MN_0 and MN_1 simultaneously moving and handovers occur at step11..................... MN_1 and MN_0, handovers to each others region simultaneously with sequential mobility.............................................. Data set from a random simulation run out of 30 times, (MN_1 and MN_0, handovers to each others region simultaneously). (a) mSCTP unable to perform Add-IP (b) mSCTP successfully perform Add-IP............................ Showing the Add-IP and Delete-IP in mSCTP connection procedure............. Showing new DAR process activity for mSCTPs ASCONF patch.. (a) Random movement of MNs, (b) Simultaneous Movement of MNs............. LS Data Structure Architecture of location detection inside LS.. Signalling between MN_0 and MN_1 and ASCONFs to measure the total handover delay 11 12 13 15 16 17 17 18 19 20 21 22 25 28 30 32 32 33 34 35 35 36 37 38 39

6.1 6.2 6.3

LS server sample file storing all the simultaneous mobility information...... 40 LS registration and update in case of simultaneous mobility. 41 (a) Error bars of estimated data 1.989170, (b) Error boundary with standard deviation... 45

vii

LIST OF TABLES
4.1 5.1 5.2 5.3 5.4 6.1 6.2 6.3 Example of random values for simultaneous mobility.......... Definition of handover delay parameters........... Simulation results showing overlapping number. Simulation results showing overlapping number. Simulation results showing overlapping number. Different steps to measure handover latency for mSCTP with and without LS.. Handover latency for different cases of simultaneous mobility.. Confidence analysis of estimated values LS with mSCTP Handover Delay 15 26 29 30 32 42 43 45

viii

ACRONYMS
IP WLAN OSI HIP HAWAII MIP IDMP TCP UDP SCTP DAR SIP mSCTP MN CN ASCONF ASCONF-ACK Add-IP Delete-IP LS NS-2.34 4G BS RFC IETF TSN CWND DCCP RUDP MTU MAC GPRS HOL CRC Internet Protocol Wireless Local Area Network Open Systems Interconnection Host Identity Protocol Handoff Aware Wireless Access Internet Infrastructure Mobile IP Intra-domain Management Protocol Transmission Control Protocol User Datagram Protocol Streaming Control transport Protocol Dynamic Address Reconfiguration Session Initiation Protocol Mobile Streaming Control Transport Protocol Mobile Node Correspondent Node Address Configuration Change Address Configuration Acknowledgment Adding IP Deleting IP Location Server Network Simulator version 2.34 The 4th generation wireless network Base Station Request for Comments Internet Engineering Task Force Transmission Sequence Number Congestion Window Datagram Congestion Control Protocol Reliable User Datagram Protocol Maximum Transmission Unit Message Authentication Code General Packet Radio Service Head Of Line Cyclic Redundancy Check

ix

DHCP DNS RSerPool ASAP NS ENRP AR LR MTOSM CDMA Cygwin FIFO REAL TCL TK OTcl TClCL NAM XGRAPH ARP IFq NetIF DSR DSDV AODV GOD SACK MN_0 MN_1 MN_#_init MN_#_new step_length del-t TRD RTT RNG

Dynamic Host Configuration Protocol Domain Name System Reliable Server Pooling Asynchronous Service Access Protocol Name Server Endpoint Name Resolution Protocol Access Router Location register Mean time to occurrence of simultaneous mobility Code Division Multiple Access Linux Emulation for Windows First In, First Out Previous name of NS2 Tool Command Language Tool Kit Object oriented extension of TCL TCL with classes Network Animator It is used in NS2 to plot x-y data Address Resolution Protocol Interface Queue Network Interface Dynamic Source Routing Destination Sequenced Distance Vector Ad hoc On Demand Distance Vector General Operations Director Selective Acknowledgement Mobile Node_0 Mobile Node_1 Mobile nodes initial position Mobile nodes new position Numerical length of a step Delta time Time of Router Discovery Round Trip Time Random Number Generator

FTP Drop-tail DHT

File Transfer Protocol A queue management algorithm Distributed Hash Table

xi

Chapter 1: Introduction

CHAPTER 1 INTRODUCTION
In the past years, communication technologies have become an integral part of everyones life. In fact, it cannot be separated from the remaining peoples lives under a microscope as an isolated object. Therefore, developing technology for technologys sake could be a vital role to fulfill users expectations [1]. One of the elementary resources needed to deliver users of the mobile internet with good service quality, is connectivity. Mobility management protocols like Mobile IPv6 [2] address the problem of providing connectivity when a node is moving and handing off between points of attachment to the network. If both ends of the communications session are mobile nodes, then those protocols cannot handle some situations where both sides move at the same time. However, the researchers are realizing the obligation to properly support simultaneous mobility. Mobile technology brought many more progress especially in the wireless systems which includes, for example, second, third and fourth generation (2G, 3G, and 4G), satellite systems, WLANs (802.11) etc. [3]. Thus, it is a challenging issue for the next generation wireless networks to integrate the existing and eventually coming systems for managing user mobility among heterogeneous networks [4]. Mobility management is based on the integration of different mobile standards such that each mobile user can remain connected while roaming through different networks [5] [6]. There are several resolutions for mobility management of IP nodes has been proposed. Seven properties to fully realize the potential of ubiquitous mobility are proposed in [7], including simultaneous mobility, i.e., that end hosts should be able to move simultaneously without breaking an ongoing session between them. Simultaneous mobility issues in seamless handover can be classified by Location Management and Handover Management. Location management identifies the current location of mobile devices and keeps track of the location while moving from one location to another. Location update information is sent by a mobile node (MN) about its latest location so it can continue to receive data at its latest location. The signaling messages conveying such information is often called binding updates. There are a number of possibilities for the recipients of binding updates, depending on mobility protocol. The main task of handover management in seamless handover is to maintain the connection of both endpoints. It can be carried out by different layers of OSIreference model [8]. Researchers mainly focus on the three layers for solving the simultaneous mobility issues. In network layer MIPv6, in transmission layer mobile SCTP (mSCTP) and in application layer SIP (Session Initiation Protocol) are commonly used for solving simultaneous mobility problems. Recently, solutions to the simultaneous mobility problem have been proposed for Mobile IPv6 [9], for Mobile IP with Location Registers and SIP mobility [10], and for TCP migration [11]. In this paper, we extend the analysis of simultaneous mobility issues in seamless handover with using mSCTP protocol and proposed an alternative solution based on suggested simultaneous mobility model which has been grounded on independent location server.

Chapter 1: Introduction

1.1 Research Design

Research design is a systematic approach to research. The core elements of research design include the hypothesis and research paradigm containing a research methodology. Identifying a problem by studying different articles within the area of main research, generating the research questions to draw the conclusions according to the problem statement are the main aim of a research work.

1.1.1 Research Methodology

Research methodology is the scientific approach to organize any research project. It consists of distinguished and consistent ways to clearly present the new knowledge. The process has to be certified by others, who can understand and reproduce results effortlessly. The main steps of the successful research method are: identification, solution, implementation and validation. With the progress of work in this thesis we tried to follow the underneath phases: a. Finding a problem: This is the first step to start with a research project. The motivation comes from studying different contributions and prospects in near future which can impact a great deal in the field of knowledge. The thesis proposal hauled vast attentions and matched with our interested field closely. Thus, we focused to search the particular problems underneath and started to investigate Simultaneous Mobility solution. By questioning and finding the scope of work with limitations are also vital in this phase. b. Research the problem: It is the process of understanding the problem evidently and narrowing down in the specific aspect of the findings. We studied the related works and sorted out the results which gave us the inputs to know the behaviors of the successful outcomes. The future works and limitations of the approaches that have done before are helpful in researching. After analyzing the gathered information from sources i.e. books, journals etc. and fruitful discussions with project supervisor, we practically ensured of the main issues of research. c. Forming hypothesis: Hypothesis can describe about the tentative explanations of the phenomena that may occur and nature expected outcomes from measured data. A research hypothesis inscribes the variables that can affect the research results and demonstrates about the validity of proposed model by using tools. At this stage we defined some selected variables and chose Handover Latency to include in hypothesis as the main performance parameter. Also for the project goal determination we proposed to build a solution approach which can contribute as an alternative solution in this topic. In this project we formulate and design our speculated project hypothesis is as the following: Analyzing the simultaneous mobility issues in seamless handover in aspects of mSCTP and build a solution approach to achieve considerable performance improvement in the handover latency.

Chapter 1: Introduction

d. Validation of hypothesis: After formulation of hypothesis, this stage intends for experiments and design. It also includes statistical analysis which could testify the hypothesis. The understanding of simultaneous mobility problem is a bit intricate. There are different models were proposed and acknowledged to measure the randomness of mobile nodes. Different researcher follow different algorithm to get closer with real-time MNs nature with variable success rate. But for simultaneous mobility measurement, we found really a few analyses which approached beforehand. As this we have to set a new experiment which could supply the exact nature to a certain extend to work with simultaneous movement of MNs. Thus, we suggest an associated simultaneous mobility model based on step length (step_length) with several constraints for simplification of the main solution. Modeling and experiments: Step_length based Simultaneous Mobility Model: With the approach of validating the hypothesis, we have developed the simultaneous mobility model experimented with NS2. With the help of Tcl (Tool Command Language) programming, we successfully generated the simultaneous mobility patterns and behaviors to match with research requirements. Several experimented and correlative variables in this model are step_length, MN_init, MN_new, ranges of MNs zone, which effects in proving the model as appropriate one for the simultaneous mobility issues. This model only generates simultaneous mobility patterns for analysis. Yet we need to look after another research issue which is obvious in maintaining mobility. That is location management problem in simultaneous mobility. After analyzing and thinking of the logical solution, we intend to build an alternative solution to address location management problem. Location management with LS: We have experimentally installed a location server (LS) node which is SCTP supportive, on the topology to store and manage the simultaneously moving MNs locations. After successful implementation of LS, we integrate the step_length model for simultaneous mobility with LS into the main solution. The key variable taken in this location management process is handover latency. e. Implementation and results analysis: In the final phase, we formed different simulation scenarios tested on NS2 platform to validate the proposed model, and performed simulation experiments to compare simultaneous handover latency measurements with LS and without LS. After measuring the estimated and calculated results, we conclude with some improvement in reducing handover latency with LS. The comparisons and confidence analysis represent the quality of the analyzed results. Thus the outcomes appropriately validate our proposed hypothesis. From the above discussions it can be argued that the followed method for this research project is a quantitative research. It has good control over the variables that are determined in different levels of modeling and experiment.

Chapter 1: Introduction

1.1.2 Main Problems

The main problem lies in tracing and locating the mobile SCTP (mSCTP) endpoints while moving from one network to another. There is no provision to track the exact location they (MNs) had and may have to establish signaling between each other, while both MN (mobile node) and CN (corresponding node) moving simultaneously. Mobile SCTP does not handle the simultaneous handover of both SCTP endpoints. If both endpoints perform a handover at the same time, the SCTP association will be lost. mSCTP handover is only for the association triggered by the mobile nodes because the MN knows the movement of itself and the signal strength from the old and new access points. mSCTP can handle handovers of both SCTP endpoints if they happen sequentially but not simultaneously. The hosts IPs, i.e., SCTP endpoints, are changing their address simultaneously while moving across networks. Problem: 1 In SCTP, there is no constant IP like mobile IP. Therefore the host IPs are changing their address simultaneously while moving across networks. MN initiates an SCTP association with the CN by negotiating a list of IP addresses. Amongst these addresses, one is chosen as the primary path for normal transmission, and the other addresses are specified as active IP addresses. While the MN reaches a new network and obtains a new IP address, it sends an Address Configuration Change (ASCONF) Chunk with an AddIP address parameter to inform the CN of the new IP address. On receiving the ASCONF, the CN adds the new IP addresses to the list of association addresses and returns ASCONF-ACK chunk to the MN. While MN is moving, it may change the primary path to the new IP addresses via the path management function. The SCTP association therefore can continue data transmission while moving to new network. The MN also informs CN to delete the IP address of the previous network from the address list by sending an ASCONF Chunk with a Delete IP Address parameter when it confirms that the previous network links has permanently failed. Problem 2: There is no provision of home agent and foreign agent which is needed for mobility management. When the mobile client moves on, it may reach the coverage of another wireless network. It will try to gain seamless mobility while keeping running applications working. mSCTP supports persistent transport layer connections between mobile IP based endpoints and non-mobile server. For two nodes, only one of which is mobile, mSCTP can capable to have the association established. Yet it loses the connectivity for a while and handover to a new network. When we consider both interactive nodes are mobile i.e. what we called simultaneous mobility the situation is a bit complicated. Then the both of the MNs move to a new network simultaneously and change their addresses at the same time. Therefore each of the MN unable to inform the other about its address changes because all the known addresses of the peer already altered. As a result the SCTP association breaks.

Chapter 1: Introduction

1.1.3 Research Questions

After determining the problems it is necessary to identify the research questions that lead the research process to be in the scope. 1. Why should we use transport layer protocol like mSCTP to support simultaneous mobility? 2. How simultaneous mobility issues can be solved using mSCTP? 3. What are the benefits of using step_length based simultaneous mobility model to figure out simultaneous mobility issues? 4. How location management problem can be fixed using LS with mSCTP? 5. Is it possible to decrease the simultaneous handover latency of mSCTP using LS?

1.1.4 Aims and Objectives

The aim of this research is started by gathering knowledge from the architecture of available mobility management technology, wireless technologies, cellular technologies, protocols, and some parameter keywords which were considered in other research issues could be helpful to reach the certain goal. The primary main goal of this thesis is to study the possibility of available mobility protocols and investigate the suitable protocol whether it is useful to improve the current simultaneous mobility issues. To testify the best protocol which fits for handover management when there is an association exists. One of the main aims of this thesis is to understand the simultaneous mobility issues in-depth and define a solution model to solve these issues in seamless handover. The location management problem can be solved by using a Location Server (LS). To achieve these goals, a bunch of simulation frameworks to be created to study and evaluate issues and trade-offs during handover using NS2 simulator. Each of the simulation frameworks have different attribute to justify the nature of the examined mSCTP protocol. Later, we have compared the simulation results for better handover latency for simultaneous mobility. Thus, the main objective of the simultaneous handover management is to minimize the service disruption with lower handover latency during simultaneous handover period.

1.1.5 Motivation
This topic includes the most recent issues of mobility management while both endpoints move simultaneously. With the IP based network, simultaneous mobility solutions attract a great deal of research attention. Mobile Stream Control Transmission Protocol (mSCTP) is newly proposed to support simultaneous mobility in the transport layer without requiring additional network components. mSCTP provides mobility to all applications that use mSCTP as a transport protocol. However, current mSCTP does not include location management service and cannot make connection from a Corresponding Node (CN) to a Mobile Node (MN) without assistance of other mobile protocols. The problems that may occurs when simultaneous mobility phenomena happens, are such a challenging research topic to deal with. Moreover by proper understanding of the issues and focusing on the right

Chapter 1: Introduction

track to solve are also very interesting. Without using any kind of agents like home agent, we intended to build a unique solution which can have some contribution in this topic. The inspirations of seeking advanced knowledge in the mobility protocol and the total scope of work are so much stimulating.

1.1.6 Contribution
We focused firstly to recognize and isolate the problems of simultaneous mobility. For these we built a unique simultaneous mobility model to deal with main aspects of the concerns. The main problem is to figure out suitable solution for location management. This is solves in this research by establishing SCTP supportive static Location Server (LS). With the effective experiments and observations of the results, we find productive inputs to implement the LS enabled simultaneous mobility model. Simultaneous handover was an inside issue in this topic. We discovered it and validate the solution approach by taking fitting parameter. Handover latency is reduced by using LS, while simultaneous handover occurs. From the experimental results and confidence analysis, it is shown than effective improvement is achieved after using LS in simultaneous handover issue. Hence the key contribution of this thesis is to solve the simultaneous mobility issue by adding LS which fulfills the location management and reduces the handover latency as well.

1.2 Thesis Outline

The research is organized into 7 chapters. Chapter 1 provides an introduction to the research, research goal, research questions and motivation of the research. Chapter 2 exhibits an overview of protocols and right protocol selection to achieve the goal. Some previous works in terms of the basic network architecture, simultaneous mobility management and their differences is also described in this chapter. Chapter 3 concludes the details of simulation tool used in this thesis work. Chapter 4 comprises with the simultaneous mobility models and solution approached with LS in detail. Chapter 5 describes the different implementation levels and simulations. Chapter 6 includes the analysis and discussions upon simulation results and confidence analysis. Chapter 7 inscribes the conclusion and future works.

Chapter 2: Background

CHAPTER 2 BACKGROUND
In this chapter, mobility issues like simultaneously movement, handover, protocols etc are described. For transport layer mobility, SCTP and its extensions are thoroughly introduced in this chapter.

2.1 Simultaneous Mobility and Handover

In telecommunication networks, Simultaneous mobility is the case that both end points of a communication session are mobile ones which enabling the needs of handover at the same time. It could be handled properly by mobility protocols. Disruption in the simultaneous mobility is caused by typical break of nonsimultaneous mobility. Simultaneous mobility may lead to a problem of losing a binding update from one mobile node because it is sent to a previous address of the other mobile node moving with a handover. Mobile IP based approaches suffers from drawbacks such as packet loss, high throughputs and handover latency [10]. Other application layer protocols like SIP [12] could not solve the simultaneous mobility problems unless it combines with an additional protocol. Handover refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another. The most basic form of handover is when a phone call in progress is redirected from its current cell (called source) and its used channel in that cell to a new cell (called target) and a new channel. Seamless handover is defined as a handover researches, most of them are based on the pattern that a mobile node communicates with a fixed one. However, in a real world, both nodes may be mobile, thus simultaneous mobility occurs.

2.2 Stream Control Transmission Protocol (SCTP)

Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, was introduced by IETF workgroup SIGTRAN in September 2007 (RFC 4960). It provides almost all service features of Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) [13]. AND it also facilitates some more advantages like multi-homing, multi-streaming, which make it exceptionally good for handling with challenging problems in transport layer whereas TCP, UDP could not fulfill the current need of mobility.

2.2.1 SCTP association

It is a protocol relationship between two SCTP endpoints and state information including Verification Tags and current active set of Transmission Sequence Numbers (TSNs), etc. The endpoints of an association can be uniquely identified by the transport addresses used by in the association. SCTP closes of an active association on request from the SCTP user. SCTP also allows ungraceful termination on request from the user [14]. An endpoint in a transmitting endpoint considers available for receiving user

Chapter 2: Background

messages is an active destination transport address. A SCTP packet contains a chunk header which consists of data chunks and control chunks to places messages and control information. SCTP congestion window (CWND) is a number of limited data in bytes of a SCTP variable that a sender can send to a particular destination transport address before receiving an acknowledgement [14] [15]. A SCTP Association establishment start by a client sends an INIT chunk to the server. Then the client enters the COOKIE-WAIT state after client starts the T1-init timer. The server responds with an INIT ACK chunk. This INIT-ACK chunk contains a state cookie. It comprises a Message Authentication Code (MAC), along with a cookie creation time stamp, the state cookie lifetime, and other information of association establishment. The MAC is provided by the server which is a secret key only known to it. After receiving the INIT-ACK signal, the client sends a COOKIE-ECHO response by echoes the state cookie. The server then verifies the state cookie using the secret key. Then it allocates the resources for the association by sending a COOKIE-ACK response acknowledging the COOKIE-ECHO signal, and moves the association to ESTABLISHED state [16].

2.2.2 Multi-homing
Standard SCTP introduces a new feature called multi-homing. Multi-homing allows the use of multiple source-destinations IP addresses for a single association between two SCTP endpoints. To support multi-homing, the endpoints of a transport protocol must have more than one transport layer addresses. These transport layer addresses are the different paths of the peer towards the endpoint with the multiple transport addresses [17]. Multi-homed nodes can be simultaneously connected through multiple end-to-end paths to increase resilience to path failure. For instance, users might be simultaneously connected through dial-up/broadband or via multiple wireless technologies such as 802.11b and GPRS [18].

2.2.3 Multi-streaming
Multi-streaming is a unidirectional dataflow of multiple streams of an SCTP association. Order of data is preserved as intra stream such that each stream has its own sequencing space. Incoming data from the upper layer application can be multiplexed onto an association in SCTP. When a segment of a certain stream is lost, following segments of the same stream will be stored in the receivers stream buffer until the source retransmits the lost segment. Yet, other streams can still be passed to the upper-layer application. Multistreaming elude the Head-of-line blocking (HOL) exists in TCP (Transmission Control Protocol), where a single stream loss can cause subsequent streams to also be delayed. HOL effect does not affect the SCTP association due to individual streams [18].

2.3 SCTP Packet Structure

The SCTP packet structure divided into two basic sections named the common header and data chunks. Common header inhabits first 12 bytes of SCTP packet which consists of Source port, Destination port, Verification tag and Checksum. The remaining part of the SCTP packet occupies Chunk type, Chunk flags, Chunk length

Chapter 2: Background

and Chunk value [19].

2.4 Mobile SCTP (mSCTP)

Mobile SCTP (mSCTP) could be used to provide the solution for simultaneous mobility in seamless handover. This protocol has been evolutionary for handover management support and, updated the standard SCTP with DAR (Dynamic Address Reconfiguration) [20]. DAR, provides mobile SCTP functionality, was introduced by the IETF in September 2007 [20]. DAR helps transport layer handoff without any interruption and made by modifying the SCTP adding two new chunks with several new parameters. The SCTP association is modified by the Address Configuration Change Chunk (ASCONF) and the Address Configuration Acknowledgment Chunk (ASCONFACK). Therefore, DAR extension allows SCTP to dynamically add IP or delete IP addresses to an association and request the primary path change during an active SCTP association. This primary path is used during communications between the endpoints. It is not necessary to reestablish an association after a DAR process during handoff because of the primary path has been set. [21] [22].

2.5 Related works

In SCTP, multi-homing support is analyzed as the new feature that lays the foundations to transport-layer mobility support. Besides network and application-layer solutions approaches, to solve simultaneous mobility at the transport layer is a challenging issue. Transport-layer-based scheme to solve simultaneous mobility has several advantages such as triangular route problem never occurs, no dependence on the concept of home network or additional infrastructure beyond Dynamic Host Configuration Protocol (DHCP) [23] and Domain Name System (DNS) [24], the possibility of smooth handovers if the mobile node has multiple interfaces and the ability to pause transmission during mobility-induced temporary disconnections gives a great deal of flexibility [25]. Furthermore, network layer schemes such as MIP, makes simultaneous mobility transparent to upper layers by increasing the burden and responsibility of the internet infrastructure [26]. Some previous approaches to solve simultaneous mobility related issues using mSCTP and other protocols are given in the below sub-sections.

2.5.1 Simultaneous mobility solution by mSCTP with RSerPool

Reliable Server Pooling (RSerPool) [27] is proposed to improve SCTPs node reliability and to provide redundant server pools. If any server fails, its client can arrange an application-layer failover to another server to continue the service. RSerPool inserts an extra layer between the transport and the application layer which relieves the application layer from managing communication sessions. When the transport connection breaks due to simultaneous mobility, the RSerPool layer ensures establishment of a new transport association and triggers an application-specific failover procedure. In the RSerPool framework [28], at least one node registers as a pool element of a server pool having a unique handle. The Endpoint Name Resolution Protocol (ENRP) protocol ensures that all Name Server (NS) of the operational scope

Chapter 2: Background

get the updated pool data. Therefore, the NS functionality can be compared to a location register in mobile networks. Using an appropriate pool policy (e.g. the newest element), the caller is now able to let the RSerPool name server resolve the pool handle to the new transport address. Then, it can establish a new association and execute an application-specific failover procedure. After that, the application can continue the communication session.

2.5.2 Simultaneous mobility under asymmetric mobility conditions

The MTOSM (mean time to occurrence of simultaneous mobility) is therefore an indication of the seriousness of the problem [29]. Previous study in this research shows that MTOSM for the case that both nodes move at the same rate. It is a new approach to analyzing the occurrence of simultaneous mobility, by considering the MTOSM for the case of two mobile nodes with identical characteristics (same mean inter-handoff time, and same mean unreachable time after each handoff). This solution has extended [30] by introducing the expression for MTOSM to include asymmetric cases (allowing different mean inter-handoff times and different mean unreachable time after each handoff, in the two mobile nodes). Here one of the key results found was that MTOSM can improve (become larger) if only one of the mobile nodes reduces handoff latency (e.g., implements low latency handoff algorithms), or increase mean inter-handoff time, independently of the corresponding mobile node. However, the performance gain is less than half the gain if both mobile nodes implement such measures. The MTOSM is likely to be reached in some scenarios, especially with higher handoff rates and without low-latency handoffs), and designers of protocols like Mobile IPv6 should take note.

2.5.3 Managing Simultaneous Mobility of IP hosts

Since triangular routing in Mobile IP (MIP) is undesirable. MIP with Route Optimization (MIP-RO) and MIP with Location Registers (MIP-LR) use binding updates that are sent straight to a Correspondent Host. Session Initiation Protocol (SIP) based mobility management also uses direct binding updates between a Mobile Host and a Correspondent Host. In this approach [10], the problems related to simultaneous mobility for SIP based mobility and MP-LR schemes have been identified. However, SIP and MIP-LR have advantages over MIP, especially in networks where survivability and robustness are critical, such as tactical military ad hoc network environments. Since the simultaneous mobility problem could cause serious problems like dropped sessions, the proposed solutions may be considered and implemented in a scenario where two communicating hosts are mobile. Moreover in Simultaneous Mobility Support with IEEE 802.21 Media Independent Handover [31] and Simultaneous Mobility in MIPv6 [32], the suffering and seriousness of the simultaneous mobility problems are impeccably discussed with enhanced solutions.

10

Chapter 3: Simulation Tool

CHAPTER 3 SIMULATION TOOL & METHODOLOGY

Simulation tool and methodology used in this project to accomplish the simulation task. Network simulation is a technique in telecommunication based research when the behavior of a network is modeled either by calculating the interaction between the different network entities (client, host, routers, data links, packets, etc) using mathematical formulas, or actually capturing and playing back observations from a production network [33].

3.1 Network Simulator 2 (NS2)

NS2 is an open-source simulation tool, which was developed by the Information Sciences Institute at the University of Southern California. It is a discreet event simulator available on several platforms such as FreeBSD, Linux, SunOS, Solaris, and also runs under Windows [34]. NS2 build for targeting at networking research and provides many advantages such as support for multiple protocols and capable of giving detailed network traffic graphically [35]. Besides, NS2 supports several algorithms in routing like LAN routing and broadcasting and queuing algorithm like fair queuing, deficit round-robin and FIFO [36]. NS2 started in 1989 as a variant of the REAL network simulator [37]. Simple NS2 scenarios run on any reasonable machine; however, for very large scenarios it is necessary to have large amounts of memory. NS2 requires some additional packages to run properly; these are: Tcl, Tk, OTcl and TclCL [38]. NS2 mainly consists of two languages: C++ and OTcl [38]. Tool Command Language (Tcl) is a very powerful interpreted script language. Tcl scripts are written to configure network topologies and provide linkage for class hierarchy, objects instantiation, variable binding and command dispatching. OTcl is used for periodic or triggered events. Tool Kit (Tk), is an escort program for Tcl, to help create graphical user interface with Tcl. TclCL (Tcl with classes), a Tcl/C++ interface, provides linkage between C++ and OTcl. Event scheduler and Basic network component objects are written and compiled with C++ [34]. OTcl interpreter has these compiled objects available by an OTcl linkage [39].

Figure 3.1: NS-2 Architectural view Network Animator (NAM), is an animation tool which is based on Tcl/TK; examine the network simulation traces and real world packet traces. It provides topology layout, packet level animation, and various data inspection tools, and

11

Chapter 3: Simulation Tool

presents such informations throughput, number of packets etc. [40].

3.2 Simulation with NS2

This section describes simulation components and their structures to build a script in NS2. These NS2 components included within are nodes, links, Simple Link objects, packets, agents, and applications.

3.2.1 Structure of Wired and Mobile nodes

NS2 associates two kinds of nodes for wired and wireless environment. The wired nodes consist of an entry point and two classifiers named Address Classifier and Port Classifier. The configuration of a mobile node is same like wired nodes. In a mobile node, packets arrive through the entry point to the address classifiers to check the address. The packets are then flow through the port classifiers to the routing agents. Routing agent processed the packet via some layer functionality. Thus the mobile node can be treated as mobile because of the routing type defined in the Tcl script [39]. An agent of a mobile node is responsible for packet generations and receptions. It is also responsible for maintaining the traffics like CBR (Constant Bit Rate), FTP (File Transfer Protocol) etc. Routing agents (DSDV, DSR, and AODV) are configured multi hop routes for packets [39].

3.2.2 Wireless Simulation by NS2

Simulation of wireless networking in NS2 has various modules; such as mobile node, Ad-hoc Routing (DSR, DSDV, AODV), MAC 802.11, Radio Propagation Model and Channel. Appendix A1 illustrates the basic wireless configuration written in a Tcl script [39].

3.2.3 Trace File

The trace file format is used to trace files produced by the Trace class.

Figure 3.2: Trace File format

12

Chapter 3: Simulation Tool

Figure 3.2 illustrates nine (9) trace entries of a sctp simulation, from them, the event column has three enqueue operations (``+''), two dequeue operations (``-''), three receive events (``r''), and one drop event. In the second column, the simulation time is in seconds at which each event occurred. The next two columns indicate trace happenings of two nodes. In the next two fields, the type of a packet and their size is displayed. SCTP packet trace contains five (5) extra column fields than a TCP trace. Among these, the chunk type indicates some alphabetic flags like I, D, S, H, B. The flag I indicate an association initiation control chunk like INIT, INIT-ACK, COOKIEECHO, and COOKIE-ACK. The D, S flags indicate a DATA and a SACK chunk. The rest chunks H, and B are indicates a HEARTBEAT chunk and HEARTBEAT-ACK chunk successively [39].

3.3 Simulation Methodologies

To develop new ideas, identify problems and optimize the existing systems, it is important to evaluate the performance in a research issue. Performance evaluation is depends upon prototyping a model such that it could be build on a system and make it to work properly on that system. And also by analytical modeling of the system by building a mathematical model which can be used to analyze the system. Lastly, the software model of the system is a simulation process. For larger systems, prototyping consumes more time and analytical modeling becomes complex, therefore is more complex to control and observe the system. Simulation fulfills all these deficiencies available in prototyping and analytical modeling. We strained to focus all the strategies to select and work on proper simulation tool and methodology. Henceforth, we select NS2 platform for this project implementation task to suit the requirement of reaching a solution for simultaneous mobility in seamless handover. According to NS2 architecture, a SCTP enabled node cannot be multi-homed. A multihomed node actually be the combination of three nodes such that a core node and a couple of interface nodes to simulate the interfaces. All these nodes are SCTP enabled. But, traffic flows only through the interfaces nodes. The core node has connection with these interface nodes and is used only for routing. The connection of core node with the interfaces is a unidirectional link. No traffic flows through the core node. The following figure illustrates the SCTP node outlook [34].

Figure 3.3: SCTP node outlook To simulate our proposed scheme, it is a prerequisite to acquire a considerable handover process for seamless communication of mobile nodes. There is no extension available for mSCTP with the present module of SCTP, in the latest released version of NS2 (v-2.34). SCTP needs DAR process enabled to perform a handover procedure. So, it turns to a great problem to solve the simultaneous mobility issues by using mSCTP. After extensive searching, an mSCTP patch has been contrived for NS2 (v2.30) [41].

13

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

CHAPTER 4 PROPOSED MODEL FOR SIMULTANEOUS MOBILITY WITH LOCATION MANAGEMENT

In this chapter, we are going to describe the proposed model to solve the simultaneous mobility issues. After citing the related and recent research papers in this area and realizing the problem thoroughly, we suggest a new model as a solution approach. First, we will go through the architectural model of simultaneous mobility for mSCTP, which is prototyped on NS2 platform. Then location management is inscribed for the model and related functionalities. After that the total solution procedure of simultaneous mobility issues is presented with context analysis and timing diagram. Lastly, we have discussed about the system constraints of the model and risk analysis.

4.1 NS2 based architectural model for Simultaneous Mobility with mSCTP
For simultaneous mobility with current version of mSCTP [42] which achieved for a mobile node (MN) associated with a fixed node. We first simulate the behavior of simultaneous mobility, where both of the communicating nodes are mobile in real context. It was a part of this research not only to understand and visualize the problem but also for a meaningful solution, we simulate the simultaneous mobility nature referenced to real network scenarios. Firstly we concentrate on building a proper model in NS2 environment and working on generating suitable simultaneous mobility patterns. We consider the random movement of two mobile nodes, MN_0 and MN_1. The mobile nodes are assumed to exist within different zones of homogeneous networks, i.e., MN_0 in Zone_0 and MN_1 in Zone_1. These zones can be worked with customized ranges. Suppose that MN_0 and MN_1 have the symmetric movement position along x-axis. In details, the considerable mobility for MNs are taken by means of one dimensional values, i.e., only x axis. The horizontal movement takes no angle, i.e., =0. Let the values for x1 as (100, 0) to x2 as (150, 0) for simplicity of this project solution. Thus the considerable movement is like that x1(100, 0) to x2(150, 0). That means MN is moving from the position 100 to 150. The most important state in this solution is the consideration of the term step_length. The mobile nodes must pose into their mobility with random steps. Step is defined as the position or state change of MN. At each step, MN has a specific step_length. The value of step_length is equal to the distance travelled by the MNs during a uniform interval time . We further assume that two mobile nodes are simultaneously changes the value of step_length after every interval time. In addition to the value of step_length; it is randomly generated; after every interval time , and uniformly distributed. Let t0 denote the starting time of simulation. At time t = t0+ n, where n = {1, 2,, N}. Thus mobility of MN will be called simultaneous. Also step_length determines the logical connection between MNs past and future movement according to our design concept. The simple algorithmic formula for MNs
14

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

positions is as follows: MN_0_init.x + step_length = MN_0_new MN_1_init.x - step_length = MN_1_new Where, x is any random value along x-axis step_length (5,0)

(i) (ii) MN_1 moves towards MN_0 (55,0) (50,0)

..

MN_0 moves towards MN_1 (14,0) (19,0)

.

(7,0)

(20,0)
.

(27,0) (37,0)

(48,0)
.

(41,0) (32,0)

(9,0)

(28,0)

(41,0)

Table 4.1: Example of random values for simultaneous mobility By this formula, we can easily implement the simultaneous mobility behavior. At any time, MN_0 is moving towards MN_1 from Zone_0 and MN_1 is also moving towards MN_0 from Zone_1. Consequently both MNs are moving closer to each other. In the next movement, new random value of step_length will be added with the previous MN_0s position (equation (i)). Similarly the same step_length is deducted from MN_1s old position to detect MN_1s new location (equation (ii)). Hence, from the table 4.1, we can interpret the simultaneous movements of MNs. For instance, at any random step length value 5, MN_0 is moving from the position 14 to 19 and MN_1 is also moving from 55 to 50 simultaneously at time . For this model, we assume that MN_0 initially starts from a position which is located at inferior distance from MN_1s initial place. According to the architecture of this model the step_length is limited within a certain range of random values, which has to be lower than ranges of Zone_0 and Zone_1. Otherwise MNs random steps may exceed the boundary of its own region. The figure 4.1 demonstrates simultaneous mobility pattern. Here we can perceive an overlapping zone in between Zone_0 and Zone_1.This overlapping zone is essential in measuring handover occurrences. A handover or simultaneous handover of MNs is triggered by any random step_length closer to this overlapping zone. The decision, when to switch from the old zone to the new one; is based on defining the minimal overlapping zone and the choice of random step_length by MNs. These factors of handover process are also significant in setting up an alternative solution of simultaneous mobility. We limit our solution by setting up only these two measurements amongst others factors for gaining seamless handover.

Figure 4.1: The simultaneous mobility of MN_0 and MN_1

15

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

In this solution, simultaneous mobility is successfully observed when simultaneous handover occurs. We successfully implement and observed this very behavior by Tcl programming in NS2. The above figure 4.1 illustrates the simultaneous mobility. In the figure 4.2, the simulation model of simultaneous mobility is illustrated. With the randomly generated step_length values, MN_0 and MN_1 are simultaneously moving towards each other and when they crossed over into Zone_1 and Zone_0 respectively at the same time, simultaneous handover happens. We measure the simultaneous mobility incidents of both MNs. This occurrence plays an important role in measuring the performance of the solution. In the implementation chapter, we included all our assumptions and parameters aimed at followed model.

Figure 4.2: Simultaneous Mobility model with random step_length In this section, we present a simplified scenario to simulate simultaneous handover. But, there is another important factor remained disclose, i.e., location management. In mSCTP, association breaks due to the lack of proper location management.

4.2 Location management with Location Server (LS)

For simultaneous mobility in mSCTP, the binding updates should be reached in the appropriate location to maintain the association. Along with mobility, to keep track of the location is a challenge. mSCTP cannot alone solve this issues as it has no home agent like MIP [43]. To address the location management problem of mSCTP, we intend to suggest an independent location server called LS.

4.2.1 LS setup and management process

The LS works as a static SCTP node. It is multi-homed with all the MNs existing in the network. For instance at any certain time, if MN_0 loses its association with MN_1, MN_0 always remain associated with LS as secondary destination. Accordingly, LS can exchange information with MNs. According to this proposed location management by LS; only in the case of that the mobile node is aware of the coming handover, mobile nodes need the help from LS. In others cases, LS remains unresponsive to MN. Figure 4.3 illustrates LS supported simultaneous mobility.

16

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

Figure 4.3: Simultaneous Mobility support by LS When MN_0 wants to establish an association with corresponding node MN_1, the first step is to determine its current address. Our proposed location management scheme gets the current address from the LS, where a conditional local binding is maintained between the mobile nodes addressed with step_length. This binding update is maintained until MNs get latest location information from LS for keeping the seamless mobility in mSCTP. Thus, LS manages simultaneous mobility in seamless mode. For the whole network, LS is used to maintain binding as a special entity. All the connection paths are routed through LS. The specific functions for location management are defined as follow: Firstly LS registers all the initially generated random values of mobile node (MN_0) and corresponding node (MN_1) with linked step_length value. It always starts before SCTP association.

Figure 4.4: Location management Process New association request is intercepted by the LS. When MN_0 sends an association request to LS, the requested corresponding address (i.e. MN_1) is verified by the LS by querying into its storage if it is the right one.
17

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

The LS forwards the association request to corresponding address (MN_1), if requested address is available. Lastly the LS provide the correct current position of corresponding node (MN_1) with the help of linked step_length. Registration Process in LS is done by our integrated Tcl code which will do registration of mobile nodes for every random step_length values with corresponding initial positions of MN_0 and MN_1. These values will be saved in LS node for future use. Once LS has learned registration, it detects for which step_length value ($) the handover occurs. This registration procedure is helpful to get rid of the issues of bootstrapping problem [44] that may occur in larger deployment scenarios in real world.

4.3 Solution of Simultaneous Mobility issues

This section is composed with main solution approaches made in the simultaneous mobility issues. We divide it into two sub-sections. First we demonstrate about the solution of mobile nodes location detection and configuration. The next sub-section to follow is simultaneous mobility management by LS.

4.3.1 Mobile nodes location detection and configuration

With the approached solution, LS is learnt to update location information of all the mobile nodes. Besides, it is provisioned to manage the step_length of all mobile nodes aware of handover process. Thus, our proposed scheme with LS, maintains the necessary information which will need for location management for seamless handover. For the simulation purposes in NS2, all data set of mobile nodes initial and next predictable movements can be stored with key values of step_length values into a file. LS stores and manages the file location in simpler like .txt format. Our integrated Tcl code can verify the exact data set for step_length and perform necessary action to communicate with LS to save data.

Figure 4.5: Integrated structure of Tcl and LS

18

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

Due to location dependent dynamic assignment of IP addresses to mobile hosts there must be a way to locate the mobile host independently from their dynamically assigned addresses. For solving this particular problem, our proposed LS have a special impact on the solution. As LS is capable of storing all the positions of both MN_0 and MN_1, and step_length values. By assuming every step_length as a key, for each mobile nodes old and new position can be located as paired values. As LS stores all the step_length associated with particular mobile nodes old and new positions into a file, it is easier to retrieve the values when necessary.

4.3.2 LS enabled Simultaneous Mobility management and Simultaneous Handover

Now we considering LS node is established in the network where MN_0 and MN_1 can exchange information via LS. When MNs are moving simultaneously, they can notify LS about their location information. This information only contains handover conscious step_length values of MNs. With this step_length value it is easier to locate any mobile nodes previous and next connection. The same operation of registering and storing mobility information is managed by LS for MN_1 also. As LS is fixed and capable of doing location management, it is easier for mSCTP to maintain simultaneous mobility now. LS functions as independent location manager and mSCTP works with it as mobility protocol. We used here mSCTPs ASCONF patch to establish connection setup between MN_0 and MN_1 with LS, in our proposed solution. Due to the transport layer mobility, all the enduring session for mSCTP are remain alive without being disrupted. Thus, LS can function before initiating association setup or after finished association in DAR process. In order to facilitate MNs to move simultaneously, we need some modifications in mSCTPs features of association setup and dynamic address reconfiguration (DAR) [4]. Moreover another important factor is to configure the location management scheme for mobile nodes at both ends of communication. So, we imagine that there exists a location server (LS) in between MN_0 and MN_1 which keeps track of current location and saves location changes continuously.

Figure 4.6: Modified association setup

19

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

4.3.2.1 Association setup

While initialization in progress, the two mobile nodes exchange their association parameter such as primary IP address, secondary address etc. When MN_0 initiates an association with MN_1, it sends INIT message to the location server (LS), which will forward it to the MN_1. The whole process is visualized in figure 4.7. This enhanced association setup will work only if it is associated with a location management scheme.

4.3.2.2 Dynamic Address Reconfiguration (DAR)

As for simultaneous mobility, we need to make change in existing address reconfiguration process of mSCTP [45]. We assume that while MN is setting up a new primary IP address, MN_1 would not start a DAR process. The DAR process is performed most likely as the conventional mSCTP protocol. But, merely the exception is that MN_0 has to go for registration process with location server (LS). The resulting exchanges of this first case are visualized in figure 4.7.

Figure 4.7: First address reconfiguration case In the next situation, there may have some different possible conditions occur. It can happen that the MN_1 receives the MN_0 request before sending its own DAR request. So, it responds to the MN_0 by sending a special ASCON-ACK to let the MN_1 know about its new primary address. When MN_0 receives this acknowledgement, it sends an ASCONF (Set Primary) message to the MN_1 on its new primary address. Then, MN_1 responds by sending an ASCOF-ACK message on the new primary address of the MN_0. The remaining procedure is to be completed normally.

4.3.2.3 Simultaneous Mobility process and Handover

The equivalent simultaneous mobility process shown in figure 4.8 with context analysis. We can measure the sequential handover and simultaneous handover phenomena. In both of the two cases, the simultaneous mobility process will start after deciding if a handover occurs or not.
20

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

4.3.2.4 Context Analysis

The handover starts with a context analysis. The following are the steps to follow after any handover. At this point, either MN_0 can handovers to zone_1 or MN_1 can handovers to zone_0 or both MN_0 and MN_1 can simultaneously handovers to zone_1 and zone_0 respectively. This decision process is done by Tcl programming which determines ranges of the zone to measure handover occurrence. Obtaining a new IP address: While a mobile node takes an initiative to switch over to another network, it first acquires a new IP address. This task is done by DHCP [23] server or IPv6 stateless auto configuration mechanism [46]. Add IP address to an active mSCTP association: Whenever a MN obtains a new IP address; it adds the new address to the current association to make changes in the current association. Set Primary IP address: The newly added IP address stays inactive until the MN_0 asks the MN_1 to consider it as a primary forwarding path.

Figure 4.8: Mobility Process Delete Old IP address: After acknowledging that the new primary path is working correctly, the old IP address path has to be deleted. Update LS: LS has to update to notify about up to date changes made in the network.

4.3.2.5 Timing diagram

Here we consider a particular scenario where a MN_0 is moving from its own network to another network. And MN_1 is also moving simultaneously from its own network to other network. We assume that both of these networks are homogeneous and performing handover. Considering the movement of MN_0 and MN_1 with respect to time, we can visualize the timing diagram in figure 4.9.

21

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

Figure 4.9: Timing diagram of new approach of mSCTP for simultaneous mobility When MN_0 or MN_1 or both enters each others zone, they continue to receive packets thorough Path1 or Path2. This is because their location changes already notified in LS. With DAR process the corresponding MN_0 and MN_1 nodes path has been set. The handover latency in this case is the time difference between the send of the last packet by using Path1 and the receiving of first packet using Path 2. We can determine the total handover delay by measuring the DAR process execution. The detail techniques are mentioned in the implementation chapter.

4.4 System constraints and Risk analysis

After modeling the solution approach, we intend to do the implementation tasks. There are several system constraints and risks have been analyzed beforehand of execution process. These are noted on the following sub-sections.

4.4.1 System constraints

Most of the real systems constraints are artifacts [47]. The cause for this is the inability of current tools to translate system requirements into system constraints in an acceptable mode. The transformation the requirements are usually divided into a number of simple constraints. Unfortunately, the ad hoc methods used to derive the constraints often leads to an over-constrained and infeasible system. In our approach, we try to keep the constraints as close as possible to the original requirements as per proposal. There are some deviation and relative timing constraints which set us to limit our goal. For simplification in simulation, we did not consider any access points such as access routers (AR) or base stations (BS) in the presented solution model. Considering the real network, it is hard to implement the LS storage. But we used LS storage only for simulation purpose in this project. We limit our research goals on the phenomena of realization of simultaneous mobility issues and worked over the modeled solution of how to achieve seamless handover by LS. We focus to implement the SCTP supportive LS for location server of simultaneous moving MNs which may not suit in other heterogeneous networks in big ranges. Under such system constraints the proposed model development started and progressed as per requirement analysis.
22

Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

4.4.2 Risk analysis

The solution model is a new one for simultaneous mobility. The number of different approaches have accomplished in this area which includes several models for location management [48]. Our LS enabled location management with step_length appropriately updates the changed location of MNs. Thus, it has low risks of being failed over. This proposed model has built over NS2 platforms and integrated with Tcl programming. There are large numbers of header files and configurations programs needed to be installed and tested for this purposes. Proper backups of data and software output need to stored and maintained in a sound manner. Beside that huge number of data spaces is mandatory to work with the bulky packages of Linux system and maintain trace files of NS2. As a dynamic simulation platform NS2 worked reputedly well enough but we had to measure the performance of the built model. For analyzing the results of our simulation, first of all we observed the performance of mSCTP ASCONF for ns-2.30. It is found in the measurement that the accuracy of mSCTP ASCONF was above 73% and the failure rate is merely above 25%. It can vary upon different platforms and machine configuration factors. The failure rate has been decreasing while we shifting towards new generation incorporated computers.

23

Chapter 5: Implementation

CHAPTER 5 IMPLEMENTATION

In this chapter, we present the implementation of the proposed solution. First we sort out objectives for analysis. Then, we illustrate the requirements for setting up simulation environments. Several parameters and assumptions are considered based on previous analysis. Towards the different implementation levels we have dealt with some obvious challenges that will be discussed in the final system requirements and challenges subsection.

5.1 Objectives of analysis

We have proceeded with several objectives to reach our final goal of implementation. The main objective is to provide a comprehensive location management support for simultaneous mobility. Beside that the employment of proposed model for the different types of mobility scenarios are observed. The ultimate goal is to compare the performance of suggested model with location management and in absence of location management for simultaneous mobility. The following objectives are crucial while working with implementation of our proposed solution: Setting up the actual and effective parameters for data analysis and simulation. Equipped with the necessary tools and supports to build modelled solution. Execution and evaluation of main objectives with certain system constraints. Validation of results with confidence interval analysis.

5.1.1 System requirements and challenges (cost analysis and etc.)

Our proposed architecture does not require any changes in the current infrastructure except adding a location server for location management. It may reduce the cost for service providers. Because, current infrastructure has two servers allocated for location management which may higher than installing one server in the system. Changing in the existing protocol working on transport layer may exorbitant to deploy. But, it has been always a trade-offs of employing new models benefit with cost effective resolution. NS2 is a free tool to simulate, is a cost effective way to simulate. But, it takes too much resources e.g., memory, disk-space during run-time. That is why NS2 needs a high configured machine which is costly. NS2 generates huge trace files; as a result software tools e.g., Tracegraph, Trace-analyzer, jTrana for converting a trace file is not capable to load.

5.1.2 Parameter setup and assumptions of simulation

For the execution of proposed solution we need to set up the appropriate parameters. To measure their functionalities in different level of implementation, we go through with several experimental analyses. After examining the effectiveness of
24

Chapter 5: Implementation

number of parameters, we choose some parameters which are really productive to integrate proposed solution with modelling. To proceed with this approach, we define a term called Brink plane. Brink plane is the minimal overlapping zone in between Zone_0 and Zone_1, where MNs are aware of possible handover. We assume that, when any of the simultaneously moving MNs (e.g., MN_0 or MN_1) touches or exceeds this Brink plane a logical handover occurs. And concurrently while both of the MNs touch or crossed the Brink plane at the same time of simulation, simultaneous handover will occur.

Figure 5.1: The simultaneous mobility scenario with Brink plane Alongside with modelling, for measuring different nature of simulation different parameters are selected. The following are the parameters used for execute the proposed solution: MN_#_init: It is mobile nodes initial position, from where the mobile node begins to move. The nature of this unit is random. MN_#_new: It is the mobile nodes next movement position after random step_length added with MNs initial position. Zone_0: Area from where MN_0 starts to move. We set different ranges for building and examining different simulation scenarios. Zone_1: Area from where MN_1 starts to move. We set the different ranges for experimenting with different simulation scenarios. step_length: It is the random distance travelled in uniform interval time by mobile node. Range: This parameter is used to describe the upper and lower limit of specific mobile node. : It is the unit timestamp of both MNs simultaneous movement. It is set as 0.001s=01ms. Handover Delay: This is the time difference between two given moments of simultaneous mobility. We assume different sets of equations based on our simultaneous mobility framework. Mobile nodes initial and newer position can be formulated as MN_init.x + step_length = MN_new. We set this equation as a standard in our work for simultaneous mobility. Every new and older location is calculated based on this equation. All the values for MN_init, MN_new and step_length are measured as
25

Chapter 5: Implementation

uniformly distributed properties generated by Tcl in NS2. The handover delay parameter is conserved for mSCTP in the simulation. It consists of the router discovery time between MN_0 or MN_1 and access router, and DAR procedure performed between MN_0 and MN_1 [49]. As per our proposed model, we did not consider any access points on the networks. Because, the fact is that router discovery (TRD) of mSCTP can be performed while transmitting data packets in an SCTP association exploiting multi-homing feature of SCTP. Hence, actual delay caused by mSCTP router discovery (TRD) can be neglected. That is, TRD 0 Hence, here are some parameters for analysing handover delay in table 5.1: Parameter Tadd-IP Tdel-IP Tset-primary-IP TASCONF TASCONF- ACK TRD TDAR TmSCTP Definition mSCTP Add-IP time mSCTP Delete-IP time mSCTP set-primary-IP time mSCTP ASCONF chunk send delay mSCTP ASCONF-ACK chunk send delay Router discovery period DAR procedure period between MN_0 and MN_1 mSCTP handover delay from MN_0 and MN_1 Table 5.1: Definition of handover delay parameters The following equation represents the handover delay when MN_0 and MN_ 1 handovers to each others zones: TmSCTP = TRD + TDAR From equation (i), TmSCTP = TDAR (ii) (iii) (i)

Here, The DAR procedure period is composed of the ASCONF parameters sent from MN_0 to MN_1. Therefore, TDAR = TaddIP + TsetprimaryIP + TdelIP While, TaddIP = TASCONF + TASCONF-ACK TsetprimaryIP = TASCONF + TASCONF-ACK TdelIP = TASCONF + TASCONF-ACK Accordingly, mSCTP handover delay can be expressed as: TmSCTP = (TaddIP + TsetprimaryIP + TdelIP) (iv) (v) (vi) (vii)

(viii)

Ideally for SCTP router discovery time can be overlooked because of the multihoming feature of SCTP. For example, a typical SCTP connection can be established by WiFi card in WLAN for certain router discovery while data can still transmitted via other heterogeneous network like CDMA2000 card. For our proposed solution for simultaneous mobility, any of the two mobile nodes (MN_0 or MN_1), always be multi-homed with LS. As Add-IP and Delete-IP, both of this process involves in location management. Therefore handover delay is comprehensively depends upon RTT of three ASCONF chunks (equation viii) for simultaneous handover occurrence.
26

Chapter 5: Implementation

The mSCTP handover delay is the addition of three RTT ASCONF chunks between MN_0 and MN_1. This is why; we can say mSCTP handover as seamless handover. Another important assumption we made is that, a handover occurs every time whenever MN_0 or MN_1, touches the Brink point or enters into the other nodes area. The handover delay is the total time to build the complete association after entering into the crossed over zone. This period is the total time of Add-IP, set-primary-path and Delete-IP. Thus, if MN_0 handovers to zone_1, the handover delay is the amount of time after entering in this zone until making a successful association with any other mobile node. The phenomena of simultaneous handover will occur, when both MN_0 and MN_1 crossed into zone_1 and zone_0 at same timestamp, and successful SCTP association establishment between mobile nodes. This is observed as simultaneous mobility with simultaneous handover.

5.2 Simulations
Simulation is the imitation which involves building a model of a certain system under study. It can be mentioned as tool for approximation of reality. Simulations often validate the models and assumptions, and used for verification the software and code. The following sub-section will include the definitions of the performance matrices which are required to be mentioned before building the simulation scenarios. Then, we will discuss the scenarios based on our assumptions and observed experiments. The final segment contains the incorporation and validation of our proposed model as a solution for simultaneous mobility problems.

5.2.1 Definition of performance matrices for simulation scenarios

There are certain performance matrices involved in the simulation scenarios based on our assumptions and experiments. We defined these as performance matrices which act as preconditions for understanding the simulation behaviors. The following are short description of performance metrics: Overlap: An overlap occurs when any mobile node i.e. MN_0 or MN_1 passed over their boundary zone at any certain time. MN_0 overlaps: When only MN _0 passed over the boundary of zone_0. MN_1 overlaps: When only MN_1 passed over the boundary of zone_1. Simultaneous Overlaps: It is the phenomenon, when both of the MNs overlap into each others zone. No overlaps: It occurs when any of the mobile nodes from any zone does not pass their zone border. It means MN_0 or MN_1 is still moving simultaneously in their belonged areas. Sequential Handover: A sequential handover occurs while MN_0 or MN_1 or both moves step by step along with their paths consistent tine intervals and passed the Brink plane. Simultaneous Handover: A simultaneous handover occurs when both MN_0 and MN_1 moving simultaneously and at the same time instance they crossed over each others zones. MN_0 handover: It is the total number of simultaneous handover in addition
27

Chapter 5: Implementation

with MN_0 overlapping number. MN_1 handover: It is the total number of simultaneous handover in addition with MN_1 overlapping number. Avg. step_length: Average step_length is the step_length values divided by total number of simulation run.

5.2.2. Simulation scenarios and observations

Different simulation scenarios are considered to measure and analyze the integrated solution approach. We have analyzed our simulation work both from statistical and technical viewpoints. The following discussions are based on different simulation scenarios and prospective outcomes: Scenerio-1: Randomly moving mobile nodes for bigger range It is assumed that MN_0 starts to move from Zone_0 and MN_1 starts to move from Zone_1. The considered mobility is random for both the mobile nodes and they follow uniform distribution. The mobility is simultaneous as we maintained the same time for their movements. There are different ranges for both zones. Range for Zone_0 is from 0 to 374 and range for Zone_1 is from 376 to 750. The Brink plane value is considered at 375. At each unit time (1 ms), any mobile node is supposed to move with a random step_length. We assumed in the whole simulation that this Brink plane value is the point after which MN_0 or MN_1 switch over to Zone_0 or Zone_1 successively. Thus, this point is considered as the Brink plane point for simultaneous handover.

Figure 5.2: Showing random movements of MN_0 and MN_1 proceeding with random step_length within range (0-750) From the figure 5.2, we can observe that the simultaneous mobility pattern of MN_0 and MN_1 are random and non-sequential. Within the same range, but two different zones MN _0 and MN_1 are simultaneously moving. We have built a Tcl script which can initiate the random movements of mobile nodes simultaneously with random step_length values. In each run of simulations there are different random movements of MN_0 and MN_1 are observed. Here is the simple formula which we assumed for our simulation:
28

Chapter 5: Implementation

step_length [0-50]: step_length(RNG) Zone_0: MN_0_init.x + step_length = MN_0 new Zone_1: MN_0_init.x - step_length = MN_1 new At every simulation run, the mobile nodes move according to generated step_length value. The values of every step motion are uniformly distributed random values within 0 to 50. So, we always find a unique value of step_length of this range (Appendix B1). In B1, we can observe that MNs are following the presented solution model for simultaneous mobility. Following are some results generated for this specific scenario and parameters: MN_0 Overlaps 1 time MN_1 overlaps 1 time Simultaneous overlap No No overlap 28 times Simultaneous Handover 0 time

Table 5.2: Simulation results showing overlapping number Here, with this observation, we derive the formula for calculating average step_length. Average step_length = =

Total distances travelled within total runs Number of simulation runs

638.1 30 = 21.27 approx.: 22 steps.

(ix)

Zone_0 is ranged within 0 to 374 i.e. 364 unit distances. Thus, mathematically MN_0 should cross over to zone_1 after every 16.54, i.e. approx. 16 steps to handover. Zone_1 is ranged within 374 to 750 i.e. 364 unit distances. Thus, mathematically MN_1 should cross over zone_0 after every 17, i.e. approx. 17 steps to handover. It took 16+17=33 estimated runs mathematically calculated steps to crossover two times to each others zones for MN_0 and MN_1. Our simulation takes for 30 runs. So, mobile nodes crossing over Brink plane only 2 times within 30 run are statistically satisfied with estimated data. Simulation time for each run=3600 seconds Total Simulation = 30 times for each revisited values (30*30/30) Total time=3600*30=108000 seconds = 1800 minutes = 30 hour We did not observe any simultaneous handover of MN_1 and MN_0 together in these thirty runs of successful simulation. The reason we find that if we imagine the lower range of data for MN_0 and MN_1, then the probability of simultaneous overlapping is increased. Scenario-2: Randomly moving mobile nodes using lower range For analysing different viewpoints of simulation, we set the following ranges of simultaneous mobility: Range for MN_0 is between 50 to 99 = Zone_0 Range for MN_1 is between 101 to 150 =Zone_1 Brink plane position: 100
29

Chapter 5: Implementation

Figure 5.3: Showing random movements of MN_0 and MN_1 proceeding with random step_length We assume that the MN_ 0 is randomly moving between Zone_0 and generating uniformly distributed values of step_length while running. Similarly, MN_1 is randomly moving within Zone_1 range and generating uniformly distributed values of step_lengths while moving. Here, the maximum step_length is 50 as before. At each unit time , any mobile node is moving with a random step_length (Appendix B2). In B2, we can observe that MNs are following the presented solution model for simultaneous mobility. = 0.001s = 1ms step_length = RNG (0:50) For this specific scenario, we changed only the ranges and Brink plane point for occurring handover. Every parameter remained same as previous scenario. Thus, we observed the random and non-sequential mobility patters of MN_0 and MN_1 which shown in figure 5.3. Following are some results generated for this specific scenario and parameters: MN_0 overlaps 08 times MN_0 handover 13times MN_1 overlaps 02 time MN_1 handover 07 times Simultaneous overlap 05 times No overlap 5 times Simultaneous Handover 05 times

Table 5.3: Simulation results showing overlapping number Here, from equation (ix), for calculating average step_length, the average step_length comes approximately 22. Zone_0 is spread over 50 to 99 unit distances. Thus, MN_0 mathematically should cross over zone_0: after every (49/21.5) = approx. 2.27 steps to handover. Zone_1 is spread over 101 to 150 unit distances. Thus, MN_1 mathematically should cross over zone_0: after every (49/21.5) = approx. 2.27 steps to handover. The number of simulation taken is 30. So, the estimated values for occurring handover are 30/2.27=13.21. Simulation result shows total 15 times overlapping i.e. handover occurs.

30

Chapter 5: Implementation

Thus approximately it has similarities with statistical data. Total simulation time for each run=3600 seconds Total Simulation = 30 times for each revisited values (30*30/30) Total time=3600*30=108000 seconds = 1800 minutes = 30 hour We observed both simultaneous mobility and simultaneous handover in this scenario for non-sequential patterns. The above data sets and measurement clearly certifies that if the ranges of MN_0 and MN_1 are decreased, then the number of simultaneous handover will definitely increase. Form the table 5.3; we can also realize the fact that in simultaneous mobility, the number of simultaneous handover is always less than handover in MN_0 or MN_1. Scenerio-3: Sequential random moving and Handover Now, we are assuming that the mobile nodes are moving sequentially with random step_lenghts at each run. The simultaneous mobility of mobile nodes: MN_0 and MN_1 from both zones are assumed to be successive. We consider new ranges: Zone_0 for MN_0: 0 to 249 Zone_1 for MN_1: 251 to 500 Brink plane position: 250 In this scenario, it is assumed that MN_0 starts from initial position (10, 0) with random step_length in Zone_0. And at the same time from Zone_1, MN_1 starts to move from (500, 0) position with same random step_length. At STEP-1 (figure 5.4), MN_1 is moving from position (500, 0) to position (472, 0) with random step_length value 28. And with the same step_length value, i.e., 28, MN_0 is moving from the position (10, 0) to position (38, 0) simultaneously. Hence, by the presented model described in section 4.1, MN_1 is moving from 500 to 472 and MN_0 is moving from 10 to 38. The detail MNs position values along with associated step_length are shown on figure 5.6. Here, we have only initialized the random and sequential motions of MN_0 and MN_1 simultaneously towards each other. Every next movement from previous positions are generated randomly. At each run of simulation, we inserted the initial positions only. The step_length and next movements are generated by our Tcl code. Below are some samples simulation results of the movement patterns from trace file by generated main Tcl code: Formation of output M-movement 0.001-time for each movement unit (second) 1/0-id of mobile node (_.00, _.00, 0.00),-initial position(x1,y1,z1) (_.00, _.00, 0.00),-new position (x2,y2,z2) _.00-step_length:distance travelled in each step- unit per step

31

Chapter 5: Implementation

Figure 5.4: MN_0 and MN_1 simultaneously moving and handovers occur at step-11 In this scenario, every movement is sequential and mobility is remained simultaneous. At every (1ms) time, random step_length is generated and mobile nodes become nearer to each other. Simulation for this scenario will continue until any of the mobile nodes i.e. MN_0 or MN_1 handovers to each others zone or simultaneous handover occur.

Figure 5.5: MN_1 and MN_0, handovers to each others region simultaneously with sequential mobility Following are some results generated for this specific scenario and parameters:
MN_0 overlaps 07 times MN_0 handover 27 times MN_1 overlaps 03 times MN_1 handover 23 times Simultaneous overlap 20 times Simultaneous handover 20 times Sequential handover 20 times

Table 5.4: Simulation results showing overlapping number Zone_0 is range within 0 to 249 units. Thus, mathematically should cross over zone_0 after every (249/22 =) 11.31, approx. 11 steps to handover. Zone_1 is range from 251 to 500= 249 units thus mathematically should cross over zone_0 after every (249/22 =) 11.31, approx. 11 steps to handover. Here, from equation (ix), for calculating average step_length, we found the mean
32

Chapter 5: Implementation

step_length is approximately 22. It is statistically measured out of 30 different simulations run that it would take average 11 steps every time to occur sequential handover. It is found from the simulation results that it would take approximately average 11 steps every time for MN_0 or MN_1 or both. Thus the estimated result is very closely fit to the actual result. The total number of simulation taken is 30 times. Simulation result shows total 20 times out of 30 times overlapping sequential handover occurred. Total simulation time for each run=3600 seconds Total Simulation = 30 times for each revisited values (30*30/30) Total time=3600*30=108000 seconds = 1800 minutes = 30 hr

Figure 5.6: Data set from a random simulation run out of 30 times, (MN_1 and MN_0, handovers to each others region simultaneously) We have tested the sequential and simultaneous random movement patterns of both MN_0 and MN_1. The results show that the percentage of time MN_0 and MN_1 that is simultaneous handover is less than the percentage of time either MN_0 or MN_1 handovers to other zones. With the mean step 11 and average step_length value 22, the rate for sequential handover is increased. In this scenario, it is observed that the occurrence of sequential handover is more than simultaneous handover (table 5.4) in compare to scenario-1 and scenario-2. In addition, MN_0 or MN_1 handover is always more than sequential or simultaneous handover of both MN_0 and MN_1.

5.2.3 Simulation insight

We launch FTP traffic for mSCTP implementation in NS2. FTP is attached with SCTP agent. Simulation is started at 0.000001s. After that at 0.5s FTP traffic is generated. Until the simulation time stops which is set as 3600s the simulation will continue. FTP needed to stop before simulation ends. In our simulation, FTP usually
33

Chapter 5: Implementation

set-off around 20s before simulation ends. Typically at 125.001s, we initialed to call the ASCONF for mSCTP. Drop-tail queue is followed to store the packets. The duplex links are set with delay of 200ms and bandwidth of 0.5Mb for interfaces used within SCTP agent. We started record of all our simulation results after system gets stable. No results were recorded but observed during warm-up periods. Approximately before each pattern of simulation, we took 30 min warm-up time to have the system in steady state. And buffer is flushed after that to get more free memory utilization. We measured all the data sets for 30 different values where each value consists of 30 different simulations. All the data sets are assumed to follow normal distribution.

5.2.4 Incorporation of modeling into solution

In this subsection, first we briefly analyzed the simultaneous mobility issues based on the observed simulation scenarios. Thereafter, we approached towards our proposed modeled solution and validation by simulations.

(a)

(b)

Figure 5.7: (a) mSCTP unable to perform Add-IP (b) mSCTP successfully perform Add-IP For the above three scenarios in section 5.2.2, SCTP association is lost every time when both MN_0 and MN_1 simultaneously moving and changing their locations continuously. mSCTP can cope up with only sequential handover or sequential mobility for single mobile node. But in case of both MN_0 and MN_1 performs handover at the same time mSCTP failure occurs. It cannot complete necessary AddIP operation and session is lost. In the figure 5.7 (a), mSCTP unable to maintain mobility in these process and failed to preserve conventional DAR process when both nodes are mobile. Whereas, in figure (b), it performs a successful DAR process, hence a handover occurs. In simultaneous mobility, any mobile node must remain reachable to the rest of the network via a static identifier regardless of its current location. At this point, we need a Location manager for the service continuity to keep DAR process alive. Our proposed solution has LS, which can act as a location identifier. The above problem can be solved using mSCTPs ASCONF feature for seamless handover along with proposed LS. mSCTPs ASCONF patch is installed on NS-2.34 and necessary programming for integrating LS is done in Tcl script.

34

Chapter 5: Implementation

Figure 5.8: procedure

Showing the Add-IP and Delete-IP in mSCTP connection

We used the mSCTPs ASCONF patch which yields the flexibility for simultaneous mobility simulation. We incorporate this patch with LS to provide complete seamless handover with location management. As LS is SCTP supported and use multiple IP address, the end to end mobility between LS and mobile node (MN_0/MN_1) can be maintained smoothly.

5.2.5 Execution of mSCTP patch

In each occurrence of position change, the mobile node is capable to change its IP address as mSCTPs Add-IP is working. The performance of mSCTP handover will depend on how to configure the triggering rules for adding a new IP addresses (AddIP) and changing the primary IP address (Primary-Change) to an on-going SCTP association. mSCTPs ASCONF patch over NS2, integrate this triggering internally.

Figure 5.9: Showing new DAR process activity for mSCTPs ASCONF patch In this patch no real IPs are considered, IP address are assigned globally with path changes. We can initiate the sessions of Add-IP, Set Primary Path, and Delete-IP.
35

Chapter 5: Implementation

mSCTP internally assigns the new address when a Add-IP request is sent to specific mobile node by sending an ASCONF request to other mobile node. After this request is acknowledged, Add-IP session is successfully ends. This phenomenon happens every time mobile nodes change its old location or primary address. Next step is to set primary path. The multi-homing feature allows a mobile node to use more than one IP address in order to support more than one communication path, namely a primary path together with several alternative paths in a single SCTP session. The primary path is used to transport the data packets, and the MN will change its primary path to an alternative path when its current primary path has failed. mSCTPs ASCONF patch assigns set primary path after receiving ASCONF ACK from the other communicating endpoint. The last following step is Delete-IP. This operation takes place after mSCTP acknowledged that the old MN address is no longer available or previous association has lost for any reason. As mSCTP alone cannot either detect location of mobile nodes neither it can store any information for future use. Without any type of location management tool mSCTP can only manage two mobile nodes initial random values of an association. But, when the mobile nodes starting to move simultaneously, mSCTP failed to locate mobile nodes and SCTP association breaks. We can observe these phenomena clearly in figure 5.10 (a), (b).

(a)

(b)

Figure 5.10: (a) Random movement of MNs, (b) Simultaneous Movement of MNs
36

Chapter 5: Implementation

mSCTP successfully implemented while mobile nodes moving randomly with time difference, but mSCTP failure occurs while mobile nodes are moving simultaneously. The reason for this failure is there is no location management in simultaneous mobility. For a certain state of simultaneous mobility, it is not enough to contain only known initial position of mobile nodes. Since, simultaneous mobility is a continuous process; mobile nodes must need to be notified about their last and next association. Thats why we need location management scheme to continue the simultaneous mobility process. An LS successfully provides location support.

5.2.6 LS functionalities
For our proposed architecture, LS stores each MN node moving and keeps track of mobility. It functions like a fixed SCTP enabled independent node which stores all the movement positions in different zones as well as step_length values. For each MN_0 and MN_1, in every single step there is a step time called . LS node serves necessary data sets for simultaneous mobility. As the step_length, MN_0 and MN_1s initial variables are random here at every step of mobility; we have to save values of these variables into LS. We observed in simulation running situations that for the same value of step_length it is possible to generate initial positions of mobile nodes which overlap at certain timestamps and also for the same values of step_length, mobile nodes are not crossing over the Brink plane. Thus LS stores of both mobile nodes initial positions and step_length value at each run.

Figure 5.11: LS Data Structure For our proposed location management scheme, we only store the step_length ($) and corresponding MNs initial position (symmetric for X= ($) =Y).

5.2.7 Location Management by LS

In this solution of simultaneous mobility, the location management is done by LS. LS facilitate both end-to-end mobility supports for mobile nodes travelling randomly. First it registers information of mobile movements such as step_length, MNs initial positions. By using this information later, it can automatically detects the next
37

Chapter 5: Implementation

movements of specific mobile nodes. Also, LS is capable of storing all the values of step_length for which handover is occurring. By exploiting these step_length values for handover, LS can automatically measure the changed new location of mobile nodes. In addition, LS can find the old initial values for mobile nodes. So, if LS can detect the random new and old positions of mobiles, it can easily retrieve the lost binding information. Beside that if location is detected, the session mobility can also be solved. Thus location management problem is solved by using our simultaneous mobility model. Any participating mobile node can efficiently retrieve the values (positions) associated with given key step_length value. It is a convenient way of maintain mapping from key value to associated values where information can be scalable. Thus, this location detection is solved by LS. This infrastructure of LS would be handy to implement complex services like distributed information systems in LS.

Figure 5.12: Architecture of location detection inside LS This proposed solution with LS, starts from registering procedure. Every randomly generated value of simultaneously moving MN_0 and MN_1 with associated step_length values are registered into LS. LS verifies and checked if it is already existing or not for non-occurring data redundancy. Implementation of LS registration and update procedure is shown in Appendix C1 and C2. Then, mSCTP operation starts with making data chunk for mobile nodes. The SCTP association starts with Add-IP. It initiates by calling ASCONF. New address location is forwarded from LS. This process finished in two steps. mSCTP always generating global IP for each association and established virtual connection with interfaces. After getting the new IP address from the changed location of MN_0 through LS, mSCTP sends Add-IP request to the corresponding mobile node and waits for acknowledgement. After receiving ASCONF request, MN_1 makes its own data chunk and forwards ASCONF acknowledgement. There exits two ASCONFs in Add-IP.

38

Chapter 5: Implementation

Figure 5.13: Signalling between MN_0 and MN_1 and ASCONFs to measure the total handover delay Thus, mSCTP successfully completes first step Add-IP and proceeding with this new address for further operation. The next process of Set Primary Path starts after Add-IP is successfully finished. It follows the default DAR process of mSCTP which consists of two ASCONFs. These two RTT will be added in total handover delay calculation. The last step is Delete-IP. This process starts after setting up primary path. This procedure of Delete-IP also consists of two ASCONFs. After data communication is successfully finished with designated primary path, mSCTP evaluates this path as no longer needed. This process ends very faster than other two previous steps of mSCTP operation. Since, it is not needed to send any acknowledgement to the primary address. It just deleted the old unused IP. But, our proposed LS keeps the record that which location is already used and no longer needed. So, at this stage LS updates itself by automatically deleting the old location stored in the LS. From figure 5.13, it can be realized that whole mSCTP procedure involved six ASCONFs. These RTTs will be added while determining handover delay. LS stores the locations of MNs to be initialized for DAR process and delete location information from LS after finishing the DAR process. As LS starts instantaneously just before the DAR, it is expected from our simulation that location management with LS provides less handover delay. We will see detail in the results chapter.

39

Chapter 6: Experimental Results

CHAPTER 6 EXPERIMENTAL RESULTS

This chapter, we have analyzed the measured data sets and evaluate the experimental results based on our proposed solution. At the beginning, we are going to discuss about the performance of LS server for simultaneous mobility of mobile nodes. To follow with the main performance parameter of this project, handover delay. And, lastly we determine some confidence analysis of estimated results.

6.1 LS performance
The location management problem of simultaneous mobility is intended to solve by location server (LS). LS can successfully register all the randomly generated step_length values. It is used as the key value to determine the next movement of MN_0 or MN_1. Also implemented LS acts as a multi-homed SCTP node, which facilitates simultaneously moving MN_0 and MN_1 to remain connected and keep mSCTP association intact. When MN_0 or MN_1 moves across to Zone_1 or Zone_0 for handover, LS updates the location of new MN_0 or MN_1. With the measured step_length values, LS provides the new locations of mobile nodes which are to be associated for mSCTP. Thus, it provides location management support. LS provides faster and reliable location support over end-to-end mobility. As, all the mobile nodes communicate via LS, it always aware of the latest condition of the network. Thus LS easily detects the ongoing and outgoing paths of transmission. As location updates can be managed by LS, the binding updates are also maintained by mSCTP with LS.

Figure 6.1: LS server sample file storing all the simultaneous mobility information
40

Chapter 6: Experimental Results

In our simulation environment, LS is capable of notifying the mobile nodes which are intend to join and starts the mSCTP DAR process for Add-IP. And it also deletes the old primary location of mobile nodes which is no longer necessary. For the Delete-IP operation, LS can update itself. This is programmed in Tcl on NS2 platform. The integrated program automatically creates files for storage. Beside it is possible to update on the same file and overwrite positions. For our prototyped small ranged homogeneous network, LS manages the simultaneous handover as well with sufficient privilege for simultaneous mobility of end to end communication for seamlessness.

Figure 6.2: LS registration and update in case of simultaneous mobility In this experiment, LS can store most probable random values of mobile nodes; later through LS every MN can find its next movement with corresponding step_length. But for location management in simultaneous mobility, LS only provides information to MNs that are aware of coming handover. Through the mean value of step_length and mean steps, it is convenient for location management service to measure simultaneous mobility patterns. Moreover the occurrences of simultaneous and non-simultaneous handover are successfully perceived through the modelled simultaneous-sequential mobility scenario which is discussed on simulation chapter.
41

Chapter 6: Experimental Results

6.2 Handover Latency

Handover latency or delay is the most significant measurement for handover. It is the main performance matric to judge the quality of seamless handover in simultaneous mobility. For our project, handover delay is the time difference between mobile nodes entrance to each others zones and association with new mobile nodes. We measured the three different criteria for estimating handover delay in our solution. The first one is the handover delay of normal random movement of MN_0 and MN_1. In this case there is no location management support given by LS. The next mentioned on the table 6.1, the handover delay of MN_0 with LS support. It is the total time of three RTT ASCONF chinks of mSCTP after handovers to zone_1. MN_1 handover time is also calculated by adding the total time of Add-IP, set-primary-path and Delete-IP ASCONFs. Finally, the simultaneous handover delay of MN_0 and MN_1 is calculated by taking the time difference of crossing over to Zone_1 and Zone_0 simultaneously. This will be also the calculated sum of three ASCONFs times processed by mSCTP. Parameters for handover measurement No Location management MN_0, MN_1 Handover random Movement Without LS Tadd-IP Tset-primary-IP Tdel-IP 0.692478 0.654933 0.659489 MN_0 Handover Simultaneous Movement With LS 0.67959 0.65468 0.654897

Location Management MN_1 Handover Simultaneous Movement With LS 0.679591 0.654683 0.654901 MN_0, MN_1 Handover Simultaneous Movement With LS 0.67959 0.654681 0.654899

Table 6.1: Different steps to measure handover latency for mSCTP with and without LS The table 6.1 shows the time difference of Add-IP, set-primary-path and Delete-IP between two mobile nodes using mSCTP without LS server and with LS server. At first, we analysed the association delay of two mobile nodes moving randomly with independent time difference in their own zones. There is no location management involved for this. Then the result is based on the simultaneous mobility with handover occurrence of MN_0 with LS server contribution. The next one is the outcome of MN_1 handovers when simultaneously moving with LS provision. The rightmost corner observation is for both MN_0 and MN_1 simultaneous handovers to each others zone with LS provisioned location update. From the results, we can compare the handover latency of mobile nodes by using mSCTP for our proposed scheme with LS server and without LS server for simultaneous mobility. mSCTP handover delay can be expressed from sub-section 5.1.2: TmSCTP = (TaddIP + TsetprimaryIP + TdelIP)
42

Chapter 6: Experimental Results

In this equation the three parameters for DAR process is consequently added for mSCTP. For every occurrence of simultaneous or non-simultaneous handover, we can measure the handover latency by this derived standard equation of TmSCTP [49]. Thus the coming aftermaths for handover latency of mSCTP with location management and without location management, for simultaneous mobility are dissected below: mSCTP handover without LS (no location management) = (0.692478 + 0.654933 + 0.659489) = 2.006900 s mSCTP handover with LS (MN_0 Handovers) = (0.67959 + 0.65468 + 0.654897) = 1.989167 s mSCTP handover with LS (MN_1 Handovers) = (0.679591 + 0.654683 + 0.654901) = 1.989175 s mSCTP handover with LS (MN_0 and MN_1 Handovers) = (0.67959 + 0.654681 + 0.654899) = 1.989170 s The above expression (5.1.2) calculates the handover delay of simultaneous moving mobile nodes in seamless handovers. All the values are measured by taking average out of 30 independent results i.e. n=30 with revisited 30 times values. The measurement shows that when only MN_0 handovers, mSCTP with LS achieve significant improvement i.e. approximately 17.7330ms less latency than the approach of mSCTP without LS. When MN_1 handovers, there is about 17.725ms less latency achieved with our proposed location management. While both MN_0 and MN_1 simultaneously handovers the improvement is almost 17.7300ms less latency than mSCTP without LS approach. Hence, we can say that the overall performance has improved using LS server with mSCTP. The outcome of average handover latency is 17.73ms with LS based approach which is significant in terms of seamless communication. Handover Latency Improvement MN_0 [ms] 17.7330 MN_1 [ms] 17.725 MN_0+MN_1, [ms] 17.7300 Avg,[ms] 17.73

Table 6.2: Handover latency for different cases of simultaneous mobility From the above results in table 6.2, we can definitely interpret the significant performance improvement of mSCTP with location management support of LS in case of simultaneous mobility. In every cases of simultaneous mobility with LS support the handover latency is curtailed. When simultaneous handover occurs between MN_0 and MN_1, the proposed scheme has reached the handover latency perfection of approximately 17.73ms less compared to handover latency of conventional experimented approach. It can be observed from the table 6.2 that the average handover delay is lessening to 17.73ms. With this mean value of average handover latency progress, it is inspected that there is not much vulnerability in case of one mobile node handovers or both mobile nodes simultaneously handovers. Hence we can evidently mention that, the unique solution for simultaneous mobility with location
43

Chapter 6: Experimental Results

management support is effectual. After comparing these above datasets, we can say that in case of simultaneous mobility pattern this improvement is quite causative. Moreover to maintain the seamlessness in on-going communication, this performance enhancement of mSCTP with LS support is vital.

6.3 Confidence Interval (CI) analysis

Confidence interval (CI) is a statistical parameter to indicate reliability of certain estimation. In case of repeated experiment it is frequently used for the basis of comparison. For quantitative analysis of measured data CI is often distinguished in simulations [50].

Formula for calculating CI:

(i) Where, n is the unknown value. is the number of observation. is the average serves as estimator of . is the estimation of the variance of the mean. is the term dependent on confidence level (1-). For, n 30 ~ 40; to be revisited. is the half size of the confidence interval.

is the relative half size of the confidence interval. is the coefficient of variation.
If anyone would assume a very large number of independent 100(1 ) % confidence intervals, each grounded on n interpretations, the proportion of these intervals that contain the value (to be estimated) should be the coverage 1 . It tells the percentage of intervals that would contain the unknown real value . It is for normal distribution with n>= 30 to 40. For sufficiently large n, the error between and approaches a normal distribution independently of the real distribution of the error between and . As we worked with approximately n=30 revisited data sets, we follow the normal distribution. All the measured data are identically distributed and simulated after system to be warmed up. We assume 95 % confidence level for the population mean in this experiment as such it is the desired coverage. So, = 0.05. Z = Z0.975 1.96 (from normal distribution) [51].
44

Chapter 6: Experimental Results

We get the mean of with LS handover delay = 1.989170 s Standard Deviation = 2.166708 s CI = 1.96 So, the upper limit = 1.989170 + 1.96 = 3.949 s The lower limit = 1.989170 1.96 = 0.029 s Similarly, we can calculate the other values of the mean of handover delay with LS support. From the table 6.3, we can observe the average and standard deviations measured. The data boundaries found after adding and deducting the CI interval from the average value of handover latency with LS. Avg [s] 1.989170 (v1) 1.989154 (v2) 1.989167 (v3) Std.-dev [s] 2.16670 2.71871 4.08221 95 % Confidence Interval 1.96 1.96 1.96 Boundaries [ms] (upper bound, lower bound) (3.94917, 0.02917) (3.94915, 0.02915) (3.94916, 0.02916)

Table 6.3: Confidence analysis of estimated values of LS with mSCTP Handover Delay We can see from the below figure 6.3 (a), that estimated values exits into the boundary of upper and lower bounds. The error graphs shows for three independent simulation results of average performance. The mean value always exists between the error boundaries. If we decrease the confidence level, then the size of the corresponding interval will decreases. An increase in the sample size n (=30), will also decrease the confidence interval without reducing the level of confidence. This is because; standard deviation varies when n varies.

(a) (b) Figure 6.3: (a) Error bars of estimated data 1.989170, (b) Error boundary with standard deviation

45

Chapter 6: Experimental Results

Thus, margin of error in confidence interval is defined to be value added or deducted from the sample mean, which determines the interval of estimated data. Thus, we can analyse from the graph that the confidence is sufficient for handover delay 1.989170s and which indicates a safe estimation.

46

Chapter 7: Conclusion and Future work

CHAPTER 7 CONCLUSION AND FUTURE WORK

In this project, an understanding of simultaneous mobility has been realized through the NS-2 simulator for smooth handover purpose, applying an alternative mobility model. Our main purpose was to solve the location management and handover management for seamless condition when both nodes are mobile.

7.1 Conclusion
Through searching the supplementary tool of vigorous mSCTP to work thoroughly in NS2, a patch is obtained for compatibility. We modified the patch to integrate it with our Tcl code and made it feasible for NS2 version 2.34. This proposed model was simulated based on diverse parameters. Different simulations have been done with respect to different scenarios. The results mentioned articulate the performance of the step_length based simultaneous model. It is derived that with the average step_length and average steps of simultaneous movements of MNs, the estimated and concrete results were approximately same. This validates the step_length model for simultaneous mobility. By justifying several simulation scenarios of simultaneous and random movements of MNs, we worked on the simultaneous with sequential pattern of mobility to generate the actual nature of simultaneous mobility. With the scrutiny of this particular scenario, we proceed to incorporate Location Server (LS) especially for location management with suggested simultaneous mobility model. The location server is also contributing for handover management as well. The handover performance demonstrates that mSCTP provides a smooth handover with LS. From the performance analysis, it is seen that LS influences in reducing resulting handover delay. Finally, preferable end-to-end simultaneous mobility management can be achieved by mSCTP with LS with ample seamlessness.

7.2 Future work

We assumed the networks as homogeneous where in tangible conditions, the networks can be heterogeneous also. In NS-2, the evaluation of mobility scenarios working with mSCTP patch gave some hierarchical addressing problem. So, it will be better to consider all the part for test-bed simulation in future to compare the actual outcomes. Besides, mobile SCTP is comparatively a new protocol, gave some immature impact during handover. The failover of this protocol needs to tested and adopted in huge ranges. The proposed LS server will face challenges with storage of step_length in real networks. In the imminent research it can be an issue to develop. Moreover for higher location management adeptness, the implementation of different DHT algorithms can be useful for LS development issues in future to attain more seamless nature in simultaneous mobility.

47

REFERENCES
[1] Akyildiz, I.F., Jiang Xie and Mohanty, S., "A survey of mobility management in nextgeneration all-IP-based wireless systems, "Wireless Communications, IEEE , vol. 11, no. 4, pp. 16-28, August 2004. [2] D. Johnson, C. Perkins, and J. Arkko, Mobility support in IPv6, IETF RFC 3775, June 2004. [3] The Working Group for WLAN Standards. Available: http://grouper.ieee.org/groups/802/11/ [4] A. Ezzouhairi, A. Quintero, and S. Pierre, A new SCTP mobility scheme supporting vertical handover, in Proc. IEEE WiMob06, June 2006. [5] Kelly, A, Muntean, G, Perry, P, and Murphy, J, Delay-Centric Handover in SCTP over WLAN, Transactions on Automatic Control and Computer Science, 49, 63 (2004), 1--6. [6] R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan, IP Micro-Mobility support through HAWAII, Internet Draft, work in progress, draft-ramjee-micro-mobility-hawaii-OO.txt, March 1999. [7] Shelley Zhuang, Kevin Lai, Ion Stoica, Randy Katz, and Scott Shenker, Host mobility using an internet indirection infrastructure, in International Conference on Mobile Systems, Applications and Services (Mobisys), San Francisco, May 2003. [8] M. Ratola, Which Layer for Mobility? Comparing Mobile IPv6, HIP and SCTP, HUT T-110.551, Seminar on Internetworking, 2005. Available: http://www.tml.tkk.fi/Studies/T110.551/2004/papers/Ratola.pdf [9] Q. Liu, S. Li, H. He, and B. Wang, "A Multi-binding Solution for Simultaneous Mobility of MIPv6," IEEE International (SOSE'06) China, 2006. [10] Wong KD, Dutta A, Young K and Schulzrinne H. "Managing simultaneous mobility of IP hosts".,in IEEE Milcom 2003; vol. 2, pp. 785790. [11] S. Tilak and N. Abu-Ghazaleh, A concurrent migration extension to an end-to-end host mobility architecture, ACM Mobile Computing and Communications Review, vol. 5, no. 3, pp. 2631, July 2001. [12] Rosenberg J., SIP: Session Initiation Protocol, RFC 3261, June 2002. [13] Stewart R., Stream Control Transmission Protocol, RFC 4960, September 2007. [14] SCTP for Beginners: http://datatag.web.cern.ch/datatag/WP3/sctp/primer.htm [15] K. J. Lee, S. S. Nam, and B. I. Mun, SCTP efficient flow control during handover, in Proc. IEEE WCNC, New Orleans, LA, Apr. 2006, pp. 6973. [16] SCTP Association Startup and Shutdown. Available: http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.commadmn /doc/commadmndita/sctp_startup.htm [17] M. Riegel, M. Tuxen, N. Rozic, and D. Begusic, Mobile SCTP transport layer mobility management for the Internet, in Proc. SoftCOM, Oct. 2002, pp. 305309.
48

[18] S. Fu and M. Atiquzzaman, SCTP: State of the art in research, products, and technical challenges, IEEE Commun. Mag., vol. 42, no. 4, pp. 6476, Apr. 2004. [19] Caro, A.L., Jr. et al., "SCTP: a proposed standard for robust Internet data transport," Computer, vol. 36, no. 11, pp. 56-63, Nov. 2003. [20] R. Stewart et al., Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration, RFC 5061, September 2007. . [21] P. Natarajan, F. Baker, P.D. Amer and J.T. Leighton, ''SCTP: What, Why, and How, Internet Computing, vol. 13, no. 5, pp. 81-85, Sept. 2009. [22] Po-Hsun Huang, Hung-Chi Chu and Huai-Hsinh Tsai Lin-Huang Chang, "Mobility Management of VoIP Services Using SCTP Handoff Mechanism," in Symposia and Workshops on Ubiquitous, Autonomic and Trusted Computing, 2009. UIC-ATC '09., Brisbane, 2009, pp. 330-335. [23] R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997. [24] P. Mockapetris, DOMAIN NAMES - CONCEPTS AND FACILITIES, RFC 1034, November 1987. [25] W. M. Eddy, "At what layer does mobility belong? ," IEEE Communications Magazine, vol. 42, no. 10, pp. 155-159, October 2004. [26] . Budzisz, R. Ferrs, A. Brunstrom, et al., Towards transport-layer mobility: evolution of SCTP multihoming, Computer Communications, vol. 31, no. 5, pp. 980998, 2008. [27] P. Lei et al., An Overview of Reliable Server Pooling Protocols, RFC 5351, September 2008. [28] T. Dreibholz, A. Jungmaier, and M. Tuxen, A new Scheme for IP-based Internet Mobility, in Proceedings of the 28th Local Computer Networks Conference, Knigswinter/Germany, Nov 2003. [29] K. Daniel and Lee Woon, Wei Wong, "Analysis of Simultaneous Mobility under Asymmetric Mobility Conditions," in Military Communications Conference, 2007. MILCOM 2007. IEEE , Orlando, FL, 2007, pp. 1 - 7. [30] K.D.Wong and W.L.Woon, Simultaneous mobility: A new analytical approach, in IEEE VTC 2007 Spring. IEEE, April 2007. [31] Wei-Kuo Chiang and Pei-An Lee, Simultaneous mobility support with IEEE 802.21 media independent handover, International Computer Symposium, vol 1, pp. 649-655, November 2008. [32] K.D.Wong and A.Dutta, Simultaneous mobility in MIPv6, in IEEE Electro/ Information Technology Conference (EIT), Lincoln, Nebraska, May 2005. [33] Network and system Lab. CSIE, NCTU. Available: http://nsl.csie.nctu.edu.tw/main.html [34] The Network Simulator - ns-2. Available: http://www.isi.edu/nsnam/ns/

49

[35] Ibrahim F. Haddad and David Gordon, "Using Network Simulator 2 to simulate case scenarios using SCTP and TCP protocols with FTP and HTTP traffic, "LINUX JOURNAL, Oct 2002. Available: http://www.linuxjournal.com/article/5929 [36] J. Domzal and A. Jajszczyk, Approximate Flow-Aware Networking, in IEEE ICC 2009, Dresden, Germany, June 2009. [37] REAL 5.0 Overview. Available: http://www.cs.cornell.edu/skeshav/real/overview.html [38] Routing Protocols in ns-2. Available: http://sce.uhcl.edu/yang/teaching/csci5931netSecuritySpr05/ns-tutorial.doc [39] NS manual. Available: http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf [40] Network Animator (Nam). Available: http://www.isi.edu/nsnam/nam/ [41] Communications Protocols Laboratory. Available: http://protocol.knu.ac.kr/ [42] Seok J. Koh and Qiaobing Xie, Mobile SCTP (mSCTP) for IP Handover Support, IETF Internet draft, Oct 2005. [43] Wang and Qiang Liu, "A Multibinding Solution for Simultaneous Mobility of MIPv6", presented at the Second IEEE International Workshop on Service-Oriented System Engineering, 2006. SOSE 06, Shanghai, 2006, pp. 143-146. [44] Patel, A. and Giaretta, G., Problem Statement for Bootstrapping Mobile IPv6 (MIPv6), RFC 4640, September 2006. [45] Tuexen, M. and Stewart, R., Stream Control Transmission Protocol (SCTP) Chunk Flags Registration, RFC 4960, October 2010. [46] Thomson S., Narten T. and Jinmei T., IPv6 Stateless Address Autoconfiguration, RFC 4862, September 2007. [47] C. Ekelin and J. Jonsson, Real-Time System Constraints: Where do They Come From and Where do They Go?, Proceedings of the International Workshop on Real-Time Constraints, Alexandria, USA., Oct 1999, pp. 53-57. [48] Abhishek Roy, Archan Misra and Sajal K. Das, "Location Update versus Paging TradeOff in Cellular Networks: An Approach Based on Vector Quantization," IEEE Transactions on Mobile Computing, vol. 6, no. 12, pp. 1426-1440, June 2007. [49] Jung Kee Song and Wenye Wang, "A simulation study of IP-based vertical handoff in wireless," Wireless Communications and Mobile Computing, vol. 6, no. 5, pp. 629650, JUL 2006. [50] Wei Wang and Norman Fenton, "Risk and confidence analysis for fuzzy multicriteria decision making," Knowledge-Based Systems, vol. 19, no. 6, pp. 430-437, October 2006 [51] Standard Normal Distribution Table. Available: http://www.mathsisfun.com/data/standard-normal-distribution-table.html

50

APPENDIX
A1. Basic Wireless Configuration

A2. Mobile Node configuration

51

B1. Data sets from randomly generated moving values of MN_0 and MN_1 for bigger range for scenario-1: Zone 0 Step_Length MN_0_Init MN_0_New 6 84 90 16 276 292 14 308 322 14 352 366 45 308 353 9 310 319 18 352 370 37 161 198 31 311 342 34 331 365 35 300 335 5 330 335 12 284 296 30 58 88 3 150 153 31 220 251 44 84 128 20 308 328 10 150 160 3 102 105 14 316 330 4 149 153 43 56 99 45 54 99 8 108 116 2 262 264 28 356 384 6 255 261 33 315 348 35 158 193 32 332 364 Zone 1 MN_1_Init MN_1_New 534 528 396 380 508 494 504 490 501 456 402 393 381 363 381 344 470 439 438 404 446 411 387 382 449 437 494 464 476 473 498 467 513 469 423 403 473 463 432 429 411 397 454 450 422 379 440 395 513 505 379 377 407 379 388 382 524 491 515 480 548 516

52

B2. Data sets for randomly generated MN_1 and MN_0 for lower range in scenario-2: Zone 0 Zone 1 Step_Length MN_0_Init MN_0_New MN_1_Init MN_1_New 36 99 135 142 106 0 96 96 146 146 20 74 94 148 128 9 55 64 101 92 10 90 100 137 127 4 60 64 110 106 17 68 85 150 133 29 59 88 135 106 5 78 83 127 122 8 75 83 142 134 46 96 142 147 101 6 71 77 132 126 8 76 84 109 101 33 75 108 102 69 49 92 141 134 85 33 90 123 142 109 31 73 104 125 94 14 53 67 107 93 20 81 101 147 127 28 98 126 148 120 38 72 110 148 110 19 62 81 127 108 15 68 83 133 118 7 85 92 124 117 14 82 96 126 112 45 86 131 145 100 31 71 102 150 119 43 95 138 137 94 24 51 75 130 106 3 52 55 121 118

53

C1. LS server registration and update, while MN_0 handovers:

54

C2. LS registration and update while MN_1 handovers:

55

D1. Trace file sample SCTP interface (if0):

56

D2. Trace file sample SCTP interface (if1):

57

D3. Multi-homed SCTP node sample trace file:

58

E1. XGRAPH view of SCTP node data transmission of if0:

59

E2. XGRAPH view of SCTP node data transmission of if1:

60

E3. XGRAPH view of Multi-homed SCTP nodes data transmission:

61

F. Code for ADD/Delete IP multiple interfaces of mSCTP:

#make source node(multiple-interface) # o # / # o # \ # o set h0_core [$ns node] set h0_if0 [$ns node] set h0_if1 [$ns node] $h0_core color red $h0_if0 color red $h0_if1 color red $ns multihome-add-interface $h0_core $h0_if0 $ns multihome-add-interface $h0_core $h0_if1 #make destination node(multiple-interface which can be added or deleted) # o # \ # o # / or not # o set h1_core [$ns node] set h1_if0 [$ns node] set h1_if1 [$ns node] $h1_core color blue $h1_if0 color blue $h1_if1 color blue $ns multihome-add-interface $h1_core $h1_if0 $ns multihome-add-interface $h1_core $h1_if1 #later, can be added or deleted $ns duplex-link $h0_if0 $h1_if0 0.5Mb 200ms DropTail $ns duplex-link $h0_if1 $h1_if1 0.5Mb 200ms DropTail # make SCTP agent and attach to node(host) set sctp0 [new Agent/SCTP/Asconf] $ns multihome-attach-agent $h0_core $sctp0 set trace_ch [open trace.sctp w] $sctp0 set trace_all_ 1 $sctp0 trace rto_ $sctp0 trace errorCount_ $sctp0 attach $trace_ch set sctp1 [new Agent/SCTP/Asconf] $ns multihome-attach-agent $h1_core $sctp1 #connect two agent $ns connect $sctp0 $sctp1 #make application to send traffic
62

set ftp [new Application/FTP] $ftp attach-agent $sctp0 $sctp0 set-primary-destination $h1_if0 $sctp1 set-primary-destination $h0_if0 #make link objects and #set link to dynamic (to up/down) set l0 [$ns get-link $h0_if0 $h1_if0] set l1 [$ns get-link $h0_if1 $h1_if1] $l0 dynamic $l1 dynamic #condition when to add ip/fuction of mSCTP active # Standard multi-test if # { proc add-ip {agent if1} { global l1 #if call add_ip, internallay send ASCONF and recv ASCONF_ACK, #and select action ADDIP/DELIP/SET_PRIMARY_PATH $agent add_ip $if1 $l1 } proc del-ip {agent if1} { global l0 $agent del_ip $if1 $l0 } proc set-primary-address {agent_d if1} { $agent_d set_primary_address $if1 #$agent_s set-primary-destination $if1 } proc sim_start {} { global ns global h0_if1 global h1_if1 set l [$ns get-link $h0_if1 $h1_if1] $l dynamic $l color red $l down }

63

G. Header file (asconf.h) for mSCTP:

#ifndef ns_sctp_handover_h #define ns_sctp_handover_h #include "agent.h" #include "node.h" #include "packet.h" #include "sctp.h" #define SCTP_CHUNK_ASCONF_LENGTH 24 typedef struct SctpAsconfChunk_S { SctpChunkHdr_S sHdr; u_int uiSeriNum; u_int uiAddrParam; u_short usType; u_short usLength; u_int uiAsconfReqCorID; u_int uiIpValue; SctpDest_S *spDest; }; typedef SctpAsconfChunk_S SctpAsconfAckChunk_S; class SctpHandoverAgent : public SctpAgent { public: SctpHandoverAgent(); ~SctpHandoverAgent(){} //virtual // void Timeout(SctpChunkType_E, SctpDest_S*); void SackGenTimerExpiration(); protected: //virtual int command(int argc, const char*const* argv); //virtual int GenChunk(SctpChunkType_E eType, u_char *ucpChunk); int ProcessAsconfAckChunk(SctpAsconfAckChunk_S *spAsconfAckChunk); //virtual int ProcessChunk(u_char *ucpInChunk, u_char **ucppOutData); int SendAsconf(SctpDest_S *spDest); }; #endif

64

H. Random number generator header file in NS2: /* ============================================================== ======== Global Variables ============================================================== ======== */ const double RANGE = 250.0; // transmitter range in meters double TIME = 0.0; // my clock; double MAXTIME = 0.0; // duration of simulation double double double double u_int32_t u_int32_t u_int32_t u_int32_t Node u_int32_t u_int32_t MAXX = 0.0; MAXY = 0.0; MAXSPEED = 0.0; PAUSE = 0.0; NODES = 0; RouteChangeCount = 0; LinkChangeCount = 0; DestUnreachableCount = 0; *NodeList = 0; *D1 = 0; *D2 = 0;

/* ============================================================== ======== Random Number Generation ============================================================== ======== */ #define M 2147483647L #define INVERSE_M ((double)4.656612875e-10) char random_state[32]; RNG *rng; double uniform() { count++; return rng->uniform_double() ; } .............................................................. ....... void Node::RandomPosition() { position.X = uniform() * MAXX;
65

position.Y = uniform() * MAXY; position.Z = 0.0; } void Node::RandomDestination() { destination.X = uniform() * MAXX; destination.Y = uniform() * MAXY; destination.Z = 0.0; assert(destination != position); } void Node::RandomSpeed() { speed = uniform() * MAXSPEED; assert(speed != 0.0); } void Node::Update() { position += (speed * (TIME - time_update)) * direction; if(TIME == time_arrival) { vector v; if(speed == 0.0 || PAUSE == 0.0) { RandomDestination(); RandomSpeed(); v = destination - position; direction = v / v.length(); time_arrival = TIME + v.length() / speed; } else { destination = position; speed = 0.0; time_arrival = TIME + PAUSE; } fprintf(stdout, NODE_FORMAT, TIME, index, destination.X, destination.Y, speed); } time_update = TIME; time_transition = 0.0; } .........................................
66

/* * Boundary conditions. */ if((t1 == 0.0 && t2 > 0.0) || (t2 == 0.0 && t1 > 0.0)) { m1->reachable = m2->reachable = 1; m1->time_transition = m2->time_transition = TIME + max(t1, t2); } else if((t1 == 0.0 && t2 < 0.0) || (t2 == 0.0 && t1 < 0.0)) { m1->reachable = m2->reachable = 0; m1->time_transition = m2->time_transition = 0.0; } /* * Non-boundary conditions. */ else if(t1 > 0.0 && t2 > 0.0) { m1->time_transition = TIME m2->time_transition = TIME } else if(t1 > 0.0) { m1->time_transition = TIME m2->time_transition = TIME } else { m1->time_transition = TIME m2->time_transition = TIME }

+ min(t1, t2); + min(t1, t2); + t1; + t1; + t2; + t2;

/* ================================================== Update the transition times for both NODEs. ================================================== */ if(time_transition == 0.0 || (m1->time_transition && time_transition > m1->time_transition)) { time_transition = m1->time_transition; } if(n2->time_transition == 0.0 || (m2>time_transition && n2->time_transition > m2->time_transition)) { n2->time_transition = m2->time_transition; } next: if(reachable != m1->reachable && TIME > 0.0) { LinkChangeCount++; link_changes++; n2->link_changes++; } } }
67

I. Sample trace file (SCTP) of calculating RTT and RTO: time: 0.50000 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0 rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 0.50000 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0 rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 0.50000 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0 rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 0.50000 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0 rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 1.67155 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 2936 pba: 0 out: 2936 ssthresh: 65536 rwnd: 65536 peerRwnd: 62600 rto: 1.000 srtt: 0.030 rttvar: 0.015 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 1.67155 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 62600 rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 ................................... time: 87.79685 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.657 rttvar: 0.020 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 87.79685 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 88.45497 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.657 rttvar: 0.015 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 88.45497 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0
68

time: 89.11296 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.657 rttvar: 0.012 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 89.11296 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 ....................................... time: 120.10485 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.657 rttvar: 0.039 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 120.10485 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 120.77662 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.659 rttvar: 0.033 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 120.77662 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 121.43681 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.659 rttvar: 0.025 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 121.43681 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 122.07987 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd: 66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.000 srtt: 0.657 rttvar: 0.023 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0 timeoutCount: 0 rcdCount: 0 time: 122.07987 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd: 2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944 rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0 pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0 timeoutCount: 0 rcdCount: 0

69