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: adnan.aftab@ymail.com
Muhammad Nabeel Mufti
E-mail: nabeel.mufti@gmail.com

University advisor:
Alexandru Propescu
School of Computing

School of Computing Internet : www.bth.se/com

Blekinge Institute of Technology Phone : +46 455 38 50 00
371 79 Karlskrona Fax : +46 455 38 50 57
Sweden
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 AIMS AND OBJECTIVES ........................................................................................................... 1
1.2 RESEARCH QUESTIONS .......................................................................................................... 1
1.3 THESIS OUTLINE ..................................................................................................................... 2
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
3 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
4 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 RESULTS ................................................................................................................................... 27
6 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 Description

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

iv
Acronym Description

UDP User datagram protocol

UHD Universal hardware devices
USB Universal serial buss
USRP Universal software radio peripheral
WiFi Wireless Fidelity
WPAN Wireless personal area network
WT Wavelet transforms

v
List of Figures
Figure2.1 Cognitive Radio spectrum sensing 4

Figure 2.2 Cognitive Radio operation 5

Figure 2.3: Energy Detection method 6

Figure 2.4: Cyclostationary Detection 7

Figure 2.5: Wavelet Detection method 7

Figure 2.6: Channel allocation in 2.4GHz ISM band 9

Figure 3.1: GNU Radio software architecture 12

Figure 3.2: GNU Radio Modules 13

Figure 3.3: Basic Software Radio 14

Figure 3.4: USRP2 Motherboard and RF daughter card XCVR 2450 15

Figure 3.5: USRP2 Front end 16

Figure 3.6: USRP2 operation with GNU Radio 17

Figure 4.1: USRP2_probe.py Output 20

Figure 4.2: Experimental Setup 20

Figure 4.3: USRP2_fft.py output 21

Figure 4.4: gr_plot_fft.py output with USRP2_rx_cfile.py data file 22

Figure 4.5: USRP2_spectrum.py flow chart 23

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 28

Figure 5.3: Time, Frequency, and Gain 3D plot for 28

2.4GHz-2.5GHz using 20MHz frequency step

Figure 5.4: Frequency and Magnitude plot with 10MHz step 29

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 30

vi
Figure 5.7: Spectrogram plot using 10MHz step 30

Figure 5.8: Frequency vs. magnitude plot with Frequency step of 5MHz 31

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

Figure 5.10: Spectrogram plot using 5MHz step 32

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

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

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

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

Figure 5.15: Spectrogram for microwave oven frequency 35

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

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

Figure 5.18: Spectrogram for 5.8GHz ISM band 37

List of Tables
Table1. Spectrum sensing techniques comparison 8

Table2: ITU-R allocation of ISM Frequency bands 9

Table 3: Main features of USRP2 16

vii
 Chapter 1

Introduction

viii
1 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?

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

2
 CHAPTER 2

Spectrum Sensing

3
2 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.

4
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 Radio
Decision Environment

Spectrum Spectrum
Analyzing 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. Energy Detection
2. Cyclostationary Method
3. Matched Filter detection
4. Wavelet detection

Explanation and comparison of all four methods is given below.

5
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 X(f) Y(f) Decide H0 or H1

Windowing FFT
Fourier
the Peak Magnitude
Transform

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

6
 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) Decide H0 or H1
X(f) Correlation of S(f,) Cyclic freq.
FFT x(f+)x*(f-) 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 X(f) Power spectral Decide H0 or H1

S(f) Local maximum
Fourier density of X(f)
Detection
Transform magnitude

Figure 2.5: Wavelet Detection method

7
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
Energy Detection Does not require prior
information, Efficient, less
complex
Cyclostationary Works perfectly in low
SNR areas, robust against
interference
Matched Filter Low computation cost,
accurate detection
Wavelet Detection Works efficiently for
wideband signal 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.

8
 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 6.785MHz
13.55313.567 MHz 13.560 MHz
26.95727.283 MHz 27.120 MHz
40.6640.70 MHz 40.68 MHz
433.05-434.79 MHz 433.92 MHz
902-928 MHz 915 MHz ITU Region2 only
2.400-2.500 GHz 2.450 GHz
5.725-5.875 GHz 5.800 GHz
24-24.25 GHz 24.125 GHz
61-61.5 GHz 61.25
122-123 GHz 122.5 GHz
244-246 GHz 245 GHz

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]

9
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
3 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

SWIG
C++ C++ C++

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:

CODE
RECEIVE RF FRONT END ADC
EXECUTION

RX PATH

CODE
TRANSMIT RF FRONT END DAC
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 MIMO
Memory Expansion
Ethernet
Interface

Figure 3.5: USRP2 Front end

Table 3: Main features of USRP2

Interface Gigabit Ethernet
FPGA Xilinx Spartan 3 2000
RF Bandwidth 25MHz
ADC 14 bits, 100MS/s
DAC 16 bits, 400 MS/s
Daughterboard slots 1 Tx, 1 Rx
SRAM 1 MB
Power 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

DSP GIGABIT
RF DAUGHTER
ADC/DAC PROCESSING ETHERNET
BOARD
XILINX FPGA CONTROLLER

GIGABIT
APPLICATION DSP BLOCK
ETHERNET
PYTHON C++ ROUTINES
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 ENERGY DETECTION IMPLEMENTATION USING
USRP2 AND GNU RADIO
4.1 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
FFT Magnitude
Tunning
Parameter

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
5 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 3-
dimensional (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
6 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.040066912770271301, 0.0055190813727676868,
0.0021366067230701447, 0.001107402378693223, 0.0019328504567965865,
0.0016706101596355438, 0.0020320124458521605, 0.0034777612891048193,
0.0014919996028766036, 0.001333131454885006, 0.0016256794333457947,
0.0018371485639363527, 0.0019112494774162769, 0.0021049873903393745,
0.0038519951049238443, 0.0029116699006408453, 0.0028225337155163288,
0.0045247073285281658, 0.0043828110210597515, 0.0036936171818524599,
0.0043287002481520176, 0.0051233791746199131, 0.004700744990259409,
0.0052246819250285625, 0.0079239737242460251, 0.0079878270626068115,
0.0072058727964758873, 0.0083901183679699898, 0.012011573649942875,
0.010452025569975376, 0.011384587734937668, 0.010718739591538906,
0.010121340863406658, 0.0098102204501628876, 0.023751826956868172,
0.028328873217105865, 0.016683906316757202, 0.021510237827897072,
0.029274577274918556, 0.02120569534599781, 0.018909499049186707,
0.017359867691993713, 0.021779812872409821, 0.028562052175402641,
0.060994364321231842, 0.085704058408737183, 0.062144704163074493,
0.07691742479801178, 0.087469212710857391, 0.061169750988483429,
0.045997627079486847, 0.036451626569032669, 0.047624539583921432,
0.078885406255722046, 0.2981133759021759, 0.56199336051940918,
0.68123906850814819, 0.5712742805480957, 1.022626519203186,
1.815961480140686, 3.1547107696533203, 2.9904580116271973,
1.7410080432891846, 1.8966439962387085, 1.0949727296829224,
0.92414122819900513, 0.65502303838729858, 0.88575261831283569,
1.2561960220336914, 1.0833464860916138, 1.6493371725082397,
1.3696602582931519, 1.6419686079025269, 2.719914436340332,
2.2194290161132812, 1.4921739101409912, 1.3443087339401245,
1.8912926912307739, 1.1128083467483521, 0.46113380789756775,
0.67372077703475952, 0.99898803234100342, 1.1562153100967407,
1.8998949527740479, 1.767426609992981, 2.2555630207061768,
2.9818150997161865, 4.2489080429077148, 4.9478602409362793,
3.6183938980102539, 1.8145967721939087, 1.5198602676391602,
1.1647709608078003, 0.6286810040473938, 0.62178975343704224,
0.80838441848754883, 1.0932257175445557, 2.4948527812957764,
2.5064244270324707, 1.6184374094009399, 1.942987322807312,
2.6447768211364746, 1.5150642395019531, 1.6680817604064941,
0.85805624723434448, 0.80695647001266479, 0.5647236704826355,
0.77822285890579224, 0.97723042964935303, 1.0299559831619263,
1.066877007484436, 1.6649191379547119, 2.0907723903656006,
1.385168194770813, 1.2304015159606934, 0.62880885601043701,
0.77945518493652344, 0.60114175081253052, 0.75301861763000488,
0.52458691596984863, 0.36764374375343323, 0.44105544686317444,
0.81339508295059204, 0.50622117519378662, 0.48039990663528442,
0.57239365577697754, 0.62805533409118652, 0.63090991973876953,
0.44689875841140747, 0.17851966619491577, 0.14225435256958008,
0.077040821313858032, 0.13759393990039825, 0.16485799849033356,
0.15660923719406128, 0.11775496602058411, 0.26699408888816833,
0.35701039433479309, 0.25196456909179688, 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.7254638671875, 5.943519115447998,
4.9885139465332031, 3.4352085590362549, 3.8861455917358398,
3.0611209869384766, 4.1641387939453125, 4.6584477424621582,
3.3806934356689453, 3.6395854949951172, 4.581965446472168,
4.0355067253112793, 6.711235523223877, 9.182032585144043,
5.950444221496582, 5.0542440414428711, 4.2773265838623047,
4.3682861328125, 4.2800970077514648, 6.594294548034668,
6.3907628059387207, 7.563817024230957, 6.2335686683654785,
6.3701944351196289, 6.1517653465270996, 7.1196331977844238,
7.0584292411804199, 5.2938923835754395, 3.7152411937713623,
6.152287483215332, 8.7384729385375977, 9.4443597793579102,
13.17851448059082, 11.978425979614258, 10.985051155090332,
10.31685733795166, 6.4902448654174805, 6.4896612167358398,
6.7908363342285156, 4.5423426628112793, 3.9046883583068848,
4.681190013885498, 5.1105408668518066, 5.5710554122924805,
6.555757999420166, 7.9897575378417969, 8.5431900024414062,
7.2733640670776367, 7.8920340538024902, 6.0835604667663574,
4.9511837959289551, 5.4244108200073242, 5.5524086952209473,
7.0115170478820801, 7.6162238121032715, 7.339911937713623,
7.5073418617248535, 6.3882355690002441, 6.5758600234985352,
5.7620663642883301, 5.3743562698364258, 7.7268595695495605,
10.491754531860352, 8.4772605895996094, 8.8215827941894531,
8.545628547668457, 7.9041132926940918, 7.3362040519714355,
7.1336016654968262, 11.792904853820801, 10.975196838378906,
10.993707656860352, 11.894734382629395, 16.446784973144531,
14.538098335266113, 12.99225902557373, 11.927684783935547,
8.4462566375732422, 7.3576827049255371, 7.5367612838745117,
4.5616464614868164, 3.7589983940124512, 4.76129150390625,
5.8710637092590332, 5.2951393127441406, 6.4392209053039551,
6.3135218620300293, 4.8167567253112793, 6.2896203994750977,
6.3264636993408203, 3.5456728935241699, 3.480363130569458,
3.255685567855835, 3.4054141044616699, 3.8168199062347412,
4.3830351829528809, 3.6322879791259766, 3.2404756546020508,
2.7397422790527344, 2.3923275470733643, 2.0473501682281494,
1.7573552131652832, 2.1140027046203613, 2.6542408466339111,
1.76539146900177, 1.568912148475647, 1.4443670511245728,
1.5097736120223999, 1.4458366632461548, 1.0355499982833862,
0.98314499855041504, 0.94674640893936157, 0.99487966299057007,
1.4055907726287842, 2.5000534057617188, 1.6392966508865356,
1.4201083183288574, 0.81627821922302246, 0.66750556230545044,
0.41280713677406311, 0.36113214492797852, 0.7205967903137207,
0.97726327180862427, 1.1921614408493042, 1.4042747020721436,
1.6822177171707153, 2.2844400405883789, 3.5576410293579102,
4.3758697509765625, 2.656505823135376, 0.94340842962265015,
1.0595099925994873, 0.99709200859069824, 0.83766782283782959,
0.49527463316917419, 0.95600581169128418, 1.4233869314193726,
2.0502135753631592, 2.1766338348388672, 1.9012550115585327,
2.7550060749053955, 2.7532544136047363, 1.422130823135376,
1.1020327806472778, 1.4120019674301147, 0.93049532175064087,
1.9735193252563477, 2.9511003494262695, 1.4158855676651001,
1.5492707490921021, 2.7556734085083008, 2.8711717128753662,
2.4999613761901855, 2.2758064270019531, 2.3133275508880615,
0.8397904634475708, 0.90137410163879395, 1.2856817245483398,
0.92863726615905762, 1.0676389932632446, 0.9720306396484375,
1.8714859485626221, 1.8402211666107178, 2.3330845832824707,
2.4703466892242432, 2.1704912185668945, 2.3740203380584717,
3.1873459815979004, 2.3636045455932617, 1.2329649925231934,
1.166181206703186, 0.81706392765045166, 1.5437220335006714,
2.7041969299316406, 2.4289414882659912, 2.2527797222137451,
5.9352045059204102, 8.9075870513916016, 7.1699471473693848,
3.3433778285980225, 2.0493607521057129, 2.8909635543823242,

48
2.3855693340301514, 2.389784574508667, 1.5883164405822754,
0.86046326160430908, 0.69971579313278198, 1.2471919059753418,
2.473766565322876, 2.5478525161743164, 2.6224849224090576,
2.5137460231781006, 2.0163238048553467, 2.9764595031738281,
2.3626995086669922, 1.7347713708877563, 1.3939838409423828,
1.1714987754821777, 1.5879503488540649, 1.2804248332977295,
1.8526248931884766, 2.1849963665008545, 2.5127692222595215,
3.3121376037597656, 3.2454426288604736, 2.8538851737976074,
1.9961237907409668, 1.9406003952026367, 3.7038774490356445,
4.7797470092773438, 2.3262240886688232, 1.3763785362243652,
2.8627450466156006, 3.8520331382751465, 3.0856180191040039,
3.3258025646209717, 2.3263769149780273, 3.5551505088806152,
2.6326093673706055, 2.5623633861541748, 1.7378360033035278,
1.7956358194351196, 1.9629738330841064, 2.2246809005737305,
2.2838873863220215, 2.4823381900787354, 3.0893852710723877,
5.9786229133605957, 10.225701332092285, 9.9261703491210938,
5.7646760940551758)

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

Author:
Adeel Ashfaq and Umer Bilal
email: ashfaq.adeel@gmail.com, umerbilalg@yahoo.com

Supervisor:
Junaid Shaikh
School of Computing, BTH
Blekinge Institute of Technology, Sweden
email: junaid.junaid@bth.se

Examiner:
Dr. Patrik Arlos
School of Computing, BTH
Blekinge Institute of Technology, Sweden
email: Patrik.Arlos@bth.se

School of Engineering Internet: www.bth.se/com

Blekinge Institute of Technology Phone: +46 455 385000
371 79 KARLSKRONA SWEDEN SWEDEN
Abstract

Web browsing activites have increased to huge volumes in the last decade,
causing more interest in the analysis of web traffic 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 experimen-
tal setup has been devised in order to observe the relationship between the TCP
flows 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 different 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 specific 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.

i
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

i
Contents

Abstract i

Acknowledgement i

Contents ii

List of Figures iv

List of Tables vii

1 Introduction 1
1.1 Documents Outine . . . . . . . . . . . . . . . . . . . . . . . . . . 2

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

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

4 Results and Analysis 20

4.1 Statistical Analysis for Reset Packets . . . . . . . . . . . . . . . . 20
4.2 Packet Capture files analysis . . . . . . . . . . . . . . . . . . . . 22
4.2.1 User Uninterrupted Tests . . . . . . . . . . . . . . . . . . 24
4.2.2 User Interrupted Tests . . . . . . . . . . . . . . . . . . . . 26
4.2.3 Comparison of TCP Flows and Ports . . . . . . . . . . . . 28
4.3 User Behaviour Extraction Using TCP Resets . . . . . . . . . . . 36

5 Conclusion and Future Work 38

5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Bibliography 40

A Appendix 44
A.1 Network Trace files . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.1.1 Uninterrupted TCP Flows . . . . . . . . . . . . . . . . . . 44
A.1.2 Interrupted TCP Flows . . . . . . . . . . . . . . . . . . . 59

iii
List of Figures

2.1 User surfing model. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Combination cycle of tests. . . . . . . . . . . . . . . . . . . . . . 14

3.2 Experiment setup. . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Snapshot of Picture based web Page. . . . . . . . . . . . . . . . . 17
3.4 Snapshot of Text based web Page. . . . . . . . . . . . . . . . . . 18
3.5 Snapshot of Video based web Page. . . . . . . . . . . . . . . . . . 19

4.1 Resets Pattern on the bases of Browser types. . . . . . . . . . . . 22

4.2 Resets Pattern on the bases of Web Page types. . . . . . . . . . . 22
4.3 Web pages Trends in TCP Resets. . . . . . . . . . . . . . . . . . 23
4.4 Browser Contribution in TCP Resets. . . . . . . . . . . . . . . . 23
4.5 Network Devices/Users contribution in Resets. . . . . . . . . . . 24
4.6 One Reset Packet in Web session, accessing Text Web page using
IE8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.7 Two Reset in Web session, accessing a video web page using IE8. 25
4.8 Resets due to Router while using OPERA. . . . . . . . . . . . . . 26
4.9 Reset in Web session due to user interruption while using Opera
(Picture Web page). . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.10 Resets in a Web session due to user interruption while using IE8
(text web page). . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.11 Resets in a Web session due to user interruption while using
Firefox (Picture web page). . . . . . . . . . . . . . . . . . . . . . 27
4.12 Resets in a Web session due to user interruption while using IE8
(Video Web Page). . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.13 Comparison of a TCP flow for a Web Session(Normal vs inter-
rupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.14 TCP flow of Opera browser while accessing a picture web page. . 30
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
4.16 Comparison of TCP flows for a Web session (Normal vs Browser
interrupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.17 TCP flow of Internet Explorer browser while accessing a Text
web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.18 TCP flow of Internet Explorer browser while accessing a Video
web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

iv
A.1 Apache Firefox Picture Web Page. . . . . . . . . . . . . . . . . . 44
A.2 Apache Firefox Text Web Page. . . . . . . . . . . . . . . . . . . . 45
A.3 Apache Firefox Video Web Page. . . . . . . . . . . . . . . . . . . 45
A.4 Apache Google Chrome Video Web Page. . . . . . . . . . . . . . 46
A.5 Apache Google Chrome Text Web Page. . . . . . . . . . . . . . . 46
A.6 Apache Google Chrome Video Web Page. . . . . . . . . . . . . . 47
A.7 Apache Internet Explorer Picture Web Page. . . . . . . . . . . . 47
A.8 Apache Internet Explorer Picture Text Page. . . . . . . . . . . . 48
A.9 Apache Internet Explorer Video Web Page. . . . . . . . . . . . . 48
A.10 Apache Opera Picture Web Page. . . . . . . . . . . . . . . . . . . 49
A.11 Apache Opera Text Web Page. . . . . . . . . . . . . . . . . . . . 49
A.12 Apache Opera Video Web Page. . . . . . . . . . . . . . . . . . . 50
A.13 Microsoft IIS Firefox Picture Web Page. . . . . . . . . . . . . . . 51
A.14 Microsoft IIS Firefox Text Web Page. . . . . . . . . . . . . . . . 52
A.15 Microsoft IIS Firefox Video Web Page. . . . . . . . . . . . . . . . 52
A.16 Microsoft IIS Google Chrome Video Web Page. . . . . . . . . . . 53
A.17 Microsoft IIS Google Chrome Text Web Page. . . . . . . . . . . . 53
A.18 Microsoft IIS Google Chrome Video Web Page. . . . . . . . . . . 54
A.19 Microsoft IIS Internet Explorer Picture Web Page. . . . . . . . . 54
A.20 Microsoft IIS Internet Explorer Picture Text Page. . . . . . . . . 55
A.21 Microsoft IIS Internet Explorer Video Web Page. . . . . . . . . . 55
A.22 Microsoft IIS Opera Picture Web Page. . . . . . . . . . . . . . . 56
A.23 Microsoft IIS Opera Text Web Page. . . . . . . . . . . . . . . . . 57
A.24 Microsoft IIS Opera Video Web Page. . . . . . . . . . . . . . . . 58
A.25 Apache Firefox Picture Web Page. . . . . . . . . . . . . . . . . . 59
A.26 Apache Firefox Text Web Page. . . . . . . . . . . . . . . . . . . . 60
A.27 Apache Firefox Video Web Page. . . . . . . . . . . . . . . . . . . 61
A.28 Apache Google Chrome Video Web Page. . . . . . . . . . . . . . 61
A.29 Apache Google Chrome Text Web Page. . . . . . . . . . . . . . . 62
A.30 Apache Google Chrome Video Web Page. . . . . . . . . . . . . . 62
A.31 Apache Internet Explorer Picture Web Page. . . . . . . . . . . . 63
A.32 Apache Internet Explorer Picture Text Page. . . . . . . . . . . . 63
A.33 Apache Internet Explorer Video Web Page. . . . . . . . . . . . . 64
A.34 Apache Opera Picture Web Page. . . . . . . . . . . . . . . . . . . 64
A.35 Apache Opera Text Web Page. . . . . . . . . . . . . . . . . . . . 65
A.36 Apache Opera Video Web Page. . . . . . . . . . . . . . . . . . . 65
A.37 Microsoft IIS Firefox Picture Web Page. . . . . . . . . . . . . . . 66
A.38 Microsoft IIS Firefox Text Web Page. . . . . . . . . . . . . . . . 67
A.39 Microsoft IIS Firefox Video Web Page. . . . . . . . . . . . . . . . 67
A.40 Microsoft IIS Google Chrome Video Web Page. . . . . . . . . . . 68
A.41 Microsoft IIS Google Chrome Text Web Page. . . . . . . . . . . . 68
A.42 Microsoft IIS Google Chrome Video Web Page. . . . . . . . . . . 69
A.43 Microsoft IIS Internet Explorer Picture Web Page. . . . . . . . . 69
A.44 Microsoft IIS Internet Explorer Picture Text Page. . . . . . . . . 70
A.45 Microsoft IIS Internet Explorer Video Web Page. . . . . . . . . . 70
A.46 Microsoft IIS Opera Picture Web Page. . . . . . . . . . . . . . . 71
A.47 Microsoft IIS Opera Text Web Page. . . . . . . . . . . . . . . . . 71

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

vi
List of Tables

4.1 The amount of resets generated without user interruption . . . . 21

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

vii
Chapter 1

Introduction

In todays world the competition between different ISPs is increasing day by

day and more concentration is being given to find those parameters that directly
affect 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 traffic on the Internet in the late 90s sug-
gested that around 70-75% of the total traffic is comprised of TCP/HTTP [35].
Furthermore, a recent study performed over two years of Global Internet traf-
fic represented by NANGO (North American network Operators group) in the
internet observatory report showed that majority of the internet application
traffic has migrated to web and video protocols including video over web [6].
World Wide Web traffic not only dominates the traffic volume on the internet
rather it is also diffused and merges applications which continuously increases
its amount in terms of users. ITU-T has categorized web applications as re-
sponsive and error intolerant [7]. Therefore we must have a close observation of
the web traffic, specifically TCP/HTTP connections [8]. There are vast number
of literatures focusing solely on the behaviour and characterization of web traf-
fic. In the early 90s Leland et al [9] showed that the LAN traffic 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 traffic. Hence despite the
exponential growth of internet traffic in the last years, TCPs congestion control
mechanism has the successfully been able to deal with such traffic bursts [11,12].
However, TCP controls the flow of the traffic 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 at-
tributes of the web-driven traffic. Studies in the past have also shown that
TCP/HTTP connections generate a substantial amount of resets (RST). Ac-
cording to a data collected at NLAR/MOAT Network Analysis Infrastructure
(NAI), resets occur more than 10% of the total traffic 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

1
the other hand, according to the research carried out at NARUS Inc showed
that TCP/HTTP reset flags 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 flags [15].
This thesis relates to the study of the causes and classification 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 surfing.
Hence, we will use these resources to understand and find 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 findings of our
experiment, including how our experiment can be further extended and used in
the future.

2
Chapter 2

Literature Review

Predicting web users behaviour has gained much interest in the last decade
or so. Some have monitored the web traffic to extract web user behaviour
while others used it to generate synthetic traffic or to model web traffic. To
fully understand the scope of this thesis work, let us start with having an
insight in the history of Web user significance. Later we further define 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 traffic analysis
to predict web user behaviour.

2.1 Significance 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 understand-
ing of the significance of the user satisfaction. The study unveils that disap-
pointed users could cause a chain reaction by sharing their experiences regard-
ing the services to other users: hence, starring the debasement of the service
providers profile. This further leads the disappointed user to switch the opera-
tors without filing any formal complaint about the service. All this commotion
highlights the issue that how delicate and essential the users presence has be-
come for the service provider.

2.2 Quality of Experience (QoE) and Quality of Ser-

vice (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 defined 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 effects 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 effects 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 definitions 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 affects on data services. QoS ensures that the networks
traffic could be prioritized by providing guarantees like controlled relay and
dedicated bandwidth. Further, these guarantees could be made available to
different users, in advance depending on their requirements, resulting in im-
proved 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 specifically QoE comes in
picture. The term QoE, also known as Quality of User Experience, is a sub-
jective 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 effective means of providing the
QoS, instead it must also consider factors that contribute to overall user sat-
isfaction, such as, suitability, flexibility, mobility, security cost, personalization

4
and choice [15]. Further, it is often seen that a selfish 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 ad-
dressed 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 through-
put, 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 es-
tablish 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 start-
ing 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 flag 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 flag bit from the client end, the server replies it with an ACK, closes
connection and sends a FIN flag bit to the client end. The client after receiving
the server end FIN flag, 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 flag termed as reset (RST) flag. This RST flag in
TCP header is used to signal the error conditions detected by the TCP. For ex-
ample, the arrival of data packets for which all the connections are closed would
generate a TCP reset. Similarly, the TCP segments arriving with an inappro-
priate 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
specification of TCP reset is documented in RFC 793 [25] in September 1981.
The document delineates the RST flag 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 specific about sending
resets, or not sending resets, in response to flags in the TCP Reserved field. [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 flags, 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 difference among different TCP implementations. In the following section
we would discuss about different 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 In-
ternet. As our work is related to observe the TCP/HTTP flows to detect the
finishing 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 differences 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-configured, 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-to-
one 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 specifications 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 identifiers. 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 ear-
lier 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 syn-
onymous 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 per-
sistent connection is briefly 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, hap-
pening 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 efficiency 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 Persistent Connections and Pipelining

2.6.1 Persistent Connection
A study conducted in 1998 for HTTP/1.1 persistent connection on Netscape
Navigator and Internet Explorer for different servers and proxies, shows that:
Persistent connection is supported by both on different 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 different 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 different
web server, the already opened persistent connections are left loafing until they
are timed out.

2.6.2 Pipelining
HTTP pipelining is the technique of sending multiple requests out to a sin-
gle 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 buffers 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 different approaches for gaining access to information demon-
strating users behavioral patterns on the web:
User accessing modified web browsers.
Web proxies.
Packet Monitoring.
Web Server Monitoring.

8
2.7.1 Modified 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 avail-
able 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 ad-
ministrators. 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
sufficient 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 files 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 influenced by the content that is being
offered 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 sufficient information
regarding time of all aspects of data retrieval. Hence they are more useful for
improvement of server architecture and traffic dimensioning as in [31, 39].

2.8 Related Work

In 2000, H. Abrahamsson & B. Ahlgren [40] modeled a web client using em-
pirical probability for user clicks and transferred data sizes. They analyzed
large packet traces and use the empirical model to implement a web client traf-
fic generator. Using HTTP requests and responses and grouping them into a
download was the theme to differentiate between different 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 differentiates 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 flags 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 traffic. 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 differentiate be-
tween interrupted and uninterrupted tcp flows. They used Fin/RST packets to
detect the aborting of a tcp flow to predict user behaviour, and concluded that
interruption probability is affected 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 different browsers, servers and operating systems to check TCP imple-
mentations 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 Surfing 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 surfing model as shown below.

10
 Session arrival

click

Pabort 1 - Pabort

Pretry
Wait - Abort Wait - Complete

Exit
session Pnext

Think

Exit session

Figure 2.1: User surfing 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 figure 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 finished 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 specified 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 soft-

ware (on client, server end or middle network elements).

The first 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 different scenarios and the ex-
periment setup created to implement these tests. It will also provide an insight
difference 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. Different web pages were loaded on the server
and then accessed by the client repeatedly. We used different servers, web
browsers and web pages to come to any conclusion. This section provides the
detail of the different 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 different 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 specific 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 different browsers and
servers, 60 repetitions using each browser on different web pages and servers
and 240 repetitions accessing different 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 first time. A network packet analyzer was used on both
the server and client end to observer the packets. A combination cycle is shown
in figure 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 five 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
first 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 pro-
cess 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 Experiment Tools and Technique

3.3.1 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 figure 3.2.

3.3.2 Wireshark Network Analyzer

Wireshark is a multi-platform, free, and open-source packet analyzing com-
puter application. The main functionalities of wireshark includes; network trou-
bleshooting, analysis, software and communication protocol development, and
educational purpose. All this application makes it one of the easiest and widely
used packet sniffer. With the aid of wireshark, network traffic could be cap-
tured or data could be read/analyzed from a file 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 net-

work 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
floating around in a network. These captured data packets are further filtered
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 file is basically a text file containing a series of commands for a com-
puter operating system, especially Windows. The name Batch file refers to the
fact that all the sets of command files are batched/bunched together into a
single file, this is done in order to avoid the commotion of presenting each file
to the system one at a time using the keyboard. In this experiment, we have
used Batch file in order to analyze the activities concerning web browsing and

15
resets. Here, the Batch file is used along with the wireshark packet analyzing
tool to make our work accurate and easier. The main function of Batch file
here is to start the web browser (in un-interrupted test) and later to abort it
after four to five 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 Microsoft-
IIS 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 (sup-
ports persistence connection & pipelining optional), Google Chrome 4.1.249.1042
(supports persistence connection only), Opera 10.51 (supports persistence con-
nection & 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 first 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 specific 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 figures 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 files gathered using
Wireshark network analyzer. Different tools were used to analyze the stats of
resets in a typical TCP transmission flow in the experiments and the capture
files 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 differentiate and categorize the types of resets in these
tests from the capture files 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 different
servers. As these tests were without any user interruption, hence we can con-
clude 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 al-
ways 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 specifically in tcp
transmission process and closed the connection gently using a finish and ac-
knowledgement packet.Hence the majority of reset packets in this scenario are
due to browsers themselves specifically 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 file 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
 Apache IIS
Brwser Picture Text Video Picture Text Video Total
o
/Server Browsers
Reset
Packets
IE 10 10 23 11 10 30 94
FF 0 0 0 4 4 /1(from 8
server
end)
GC 0 0 0 0 0 0 0
4* 4* 0 4* 0 16
(towards (towards (towards (towards
OP the the the the
router) router) router) router)
when when when when
idle idle idle idle
/1 (from /1 (from /1 (from
router) router) router)
Toal 10 10 23 15 14 31
t
Resets per
web page

Table 4.1: The amount of resets generated without user interruption

Apache IIS
Brwsers Picture Text Video Picture Text Video Total
o
/Servers Browsers
Reset
Packets
IE 21 20 40 21 20 45 166
FF 21 21 11 20 20 10 103
GC 10 11 10 11 10 10 62
11 11 10 10 11 77
4* 2* 4* 4*
(towards (towards (towards (towards
OP the the the the
router) router) router) router)
when when when when
idle idle idle idle
/1 (from /1 (from /1 (from
router) router) router)
Toal 66 65 72 66 60 80
t
Resets per
web page

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 figures 4.1 and
4.2 gives a clear picture of the difference 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 different web pages and servers. Further we have
compared the percentage contribution of different network devices, browsers
and web pages in interrupted and uninterrupted tcp flows in charts 4.3, 4.4 and
4.5.
300
166

250

200

150 User interrupted

103
94 77 User Uninterrupted
100
62

50
19
8
0
0
Internet Mozilla Firefox Google Chrome Opera
Explorer 8

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

250

152
200

132
125
150
User Interrupted Tests

100 User Uninterrupted Tests

54
50
24 25

0
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 files analysis

The main purpose of the study was to focus on whether or not we can devise
a way to differentiate 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

31%
38%

Picture Web page

Text Web page
Video Web page
31%

Figure 4.3: Web pages Trends in TCP Resets.

Uninterrupted

0% 16%

7%
Internet Explorer 8
Mozilla Firefox
Google Chrome
77%
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 different
browsers, to narrow down our research and find 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 differentiated 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 figure 4.6,
which is a snapshot of wireshark analyzer showing that the source generated a
reset and finishes 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 filter is applied to the traffic 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 figure
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 filter
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 figure 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
flags which forces a receiving computer to skip its buffer and push that traffic
straight ahead of any other traffic. 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
finished 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 specific network device and in idle mood i.e. while
no traffic 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 first
analyze the tcp flows due to Opera and Google chrome which generated only
one reset. The figure 4.9 shows the tcp flow of video based web page accessed
by opera browser. The same filter (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 files shows quiet easy for us to differentiate
between the user interrupted and uninterrupted tcp flows but it is difficult to
differentiate for those resets which occurred in Internet Explorer for all web
pages and Mozilla Firefox when accessing the (Picture/text) web pages. The
figure 4.10 is from the IE web session while accessing a text web page and
figure 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 first 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 differentiating 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 figure 4.12. Hence to further clarify and constrict our research to
sperate user generated and browser generated resets, we will compare the tcp
flows of each of these situations having different types of resets in next section.

4.2.3 Comparison of TCP Flows and Ports

To further clarify the difference between the user initiated and browser (clients
browser) initiated resets, we observed the complete tcp process using a simple
packet flow diagram. The figure 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 flow.
The figure 4.13is divided into the user and client responses and actions on
the bases of time as follows

TF S = TCP flow start (Web session begins).

TF E = TCP flow 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 flow Ends (Server completes the transfer of requested data).

TF2 S = second TCP flow starts (May be a part of same web session or
another).

As we are more interested in the end and beginning of the flow, so this
can also be observed in the actual test based (filtered) tcp packet flow diagram
with port and timing sequence in figure 4.14 of Opera browser while accessing
a picture web page using one port and figure 4.15 of Mozilla Firefox using two
ports. We have filtered our data to only SYN, ACK, RST and FIN packets.
This type of reset is a clear indication of user interruption.
Observing the first two flows as shown in figures 4.14 and 4.15, we see that
a normal flow 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
flow 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 User Interrupted
Flow Flow

TFS
SYN SYN

ACK ACK
SYN+ SYN+

ACK ACK

TCS
GET GET

DATA DATA
TSS
ACK ACK

GET TCE GET

A
DAT DATA
TSE
ACK

ACK
TFE
RST

FIN

ACK
FIN
TFE T2FS
SYN
ACK
ACK
SYN+

Client Server Client Server

TIME

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

29
 Uninterrupted Flow Interrupted Flow

|Time | 192.168.1.4 |Time | 192.168.1.3 |

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

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

30
 Uninterrupted Flow Interrupted Flow

|Time | 192.168.1.4 | |Time | 192.168.1.3 |

| | 192.168.1.5 | | | 192.168.1.2 |
|0.003 | SYN | |0.000 | SYN |
| |(2115) ------------------> (80) | | |(1159) ------------------> (80) |
|0.005 | SYN, ACK | |0.001 | SYN, ACK |
| |(2115) <------------------ (80) | | |(1159) <------------------ (80) |
|0.018 | PSH, ACK - Len: 365 | |0.015 | PSH, ACK - Len: 365 |
| |(2115) ------------------> (80) | | |(1159) ------------------> (80) |
|0.093 | PSH, ACK - Len: 377 | |0.074 | PSH, ACK - Len: 377 |
| |(2115) ------------------> (80) | | |(1159) ------------------> (80) |
|1.332 | PSH, ACK - Len: 346 | |0.972 | RST, ACK |
| |(2115) ------------------> (80) | | |(1159) ------------------> (80) |
|16.555 | FIN, ACK | |0.972 | SYN |
| |(2115) <------------------ (80) | | |(1160) ------------------> (80) |
|29.590 | FIN, ACK | |0.972 | SYN |
| |(2115) ------------------> (80) | | |(1161) ------------------> (80) |
|0.985 | SYN, ACK |
| |(1160) <------------------ (80) |
|0.986 | SYN, ACK |
| |(1161) <------------------ (80) |
|0.993 | PSH, ACK - Len: 346 |
| |(1160) ------------------> (80) |
|1.026 | PSH, ACK - Len: 482 |
| |(1161) ------------------> (80) |
|1.046 | RST, ACK |
| |(1160) ------------------> (80) |
|1.046 | PSH, ACK - Len: 466 |
| |(1161) ------------------> (80) |
|5.026 | PSH, ACK - Len: 407 |
| |(1161) ------------------> (80) |
|20.065 | FIN, ACK |
| |(1161) <------------------ (80) |
|29.617 | 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 Browser Interrupted
Flow Flow

TFS SYN
SYN

ACK ACK
SYN+ SYN+

ACK ACK

TCS
GET GET

DATA DATA
TSS
ACK ACK

TCE GET
GET

A
DAT DATA
TSE
ACK ACK

FIN
FIN

AC
K
ACK
TFE
RST
FIN TFE

ACK

Client Server TIME Client Server

Figure 4.16: Comparison of TCP flows for a Web session (Normal vs Browser inter-
rupted).

32
 Another comparison of normal tcp flow with browser generated reset is
shown in figure 4.16 to differentiate it from user generated resets. The differ-
ence 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 figure 4.17 shows the tcp flow
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) re-
ceives a FIN packet from the server on the same port hence differentiating it
from the interrupted one, but at the same time we see that in user interrupted
flow the last RST packet which is basically due to the browser also does not
have any FIN packet received from the server. Moreover in figure 4.18, shows
the tcp flow of video based web page accessed by Internet Explorer, and shows
2 RST packets in an un-interrupted tcp flow which increases to four when a
user interrupt is introduced. The first 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 phenom-
ena 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 interrupted Flow

|Time | 192.168.1.4 ||Time | 192.168.1.3 |

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

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

34
 Uninterrupted Flow interrupted Flow

|Time | 192.168.1.4 | |Time | 192.168.1.4 |

| | 192.168.1.5 | | | 192.168.1.2 |
|0.000 | SYN | |0.000 | SYN |
| |(1802) ------------------> (80) | | |(2047) ------------------> (80) |
|0.002 | SYN, ACK | |0.001 | SYN, ACK |
| |(1802) <------------------ (80) | | |(2047) <------------------ (80) |
|0.003 | PSH, ACK - Len: 219 | |0.001 | PSH, ACK - Len: 219 |
| |(1802) ------------------> (80) | | |(2047) ------------------> (80) |
|0.544 | PSH, ACK - Len: 87 | |0.073 | PSH, ACK - Len: 86 |
| |(1802) ------------------> (80) | | |(2047) ------------------> (80) |
|0.549 | RST, ACK | |0.076 | RST, ACK |
| |(1802) ------------------> (80) | | |(2047) ------------------> (80) |
|0.599 | SYN | |0.259 | SYN |
| |(1803) ------------------> (80) | | |(2048) ------------------> (80) |
|0.600 | SYN, ACK | |0.260 | SYN, ACK |
| |(1803) <------------------ (80) | | |(2048) <------------------ (80) |
|0.601 | PSH, ACK - Len: 206 | |0.260 | PSH, ACK - Len: 206 |
| |(1803) ------------------> (80) | | |(2048) ------------------> (80) |
|1.535 | PSH, ACK - Len: 211 | |0.914 | PSH, ACK - Len: 210 |
| |(1803) ------------------> (80) | | |(2048) ------------------> (80) |
|16.837 | FIN, ACK | |1.671 | RST, ACK |
| |(1803) <------------------ (80) | | |(2048) ------------------> (80) |
|16.843 | RST, ACK | |1.816 | SYN |
| |(1803) ------------------> (80) | | |(2049) ------------------> (80) |
|1.817 | SYN, ACK |
| |(2049) <------------------ (80) |
|1.817 | PSH, ACK - Len: 310 |
| |(2049) ------------------> (80) |
|1.821 | PSH, ACK - Len: 202 |
| |(2049) ------------------> (80) |
|1.823 | RST, ACK |
| |(2049) ------------------> (80) |
|1.922 | SYN |
| |(2050) ------------------> (80) |
|1.923 | SYN, ACK |
| |(2050) <------------------ (80) |
|1.939 | PSH, ACK - Len: 326 |
| |(2050) ------------------> (80) |
|17.780 | FIN, ACK |
| |(2050) <------------------ (80) |
|22.766 | RST, ACK |
| |(2050) ------------------> (80) |

Figure 4.18: TCP flow 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 flow is a difficult task. Although we can
conclude from the figure 4.5 that majority of the resets represent user behaviour,
but to differentiate them from other resets is a another task. As the client uses
more then one port at a time, hence to discriminate each TCP flow 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 Po-
litecnio di Torino to extract user behaviour solely on TCP resets. They defined
the criteria of user interrupted tcp flows as follows

Interrupted flows = (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
fulfills the requirements of extracting user behaviour from tcp flows.

Reets Sever Browser web Rossi Criteria Original Reason Percentage

s
without user page for user for Resets Error
interruption interrupted
Resets
User Browser User Browser
10 AP IE PIC 0 10 0 10 0
10 AP IE TXT 0 10 0 10 0
23 IIS IE VID 10 13 0 23 43.47
30 IIS IE VID 20 10 0 30 66.6
10 IIS IE TXT 0 10 0 10 0
10 IIS IE PIC 0 10 0 10 0
4 IIS FF TXT 0 4 0 4 0
4 IIS FF PIC 0 4 0 4 0

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

36
 Reets Sever Browser web Resets with Rossi Criteria Original Reason
s
without user page user for user for Resets Error
interruption interruption interrupted
Resets
User Browser User Browser
10 IIS IE TXT 20 10 10 10 10 0
10 IIS IE PIC 21 11 10 11 10 0
30 IIS IE VID 41 30 11 11 30 46.3
4 IIS FF PIC 20 20 0 20 0 0
4 IIS FF TXT 20 20 0 20 0 0
0 IIS FF VID 10 10 0 10 0 0
0 IIS GC PIC 11 11 0 11 0 0
0 IIS GC TXT 10 10 0 10 0 0
0 IIS GC VID 10 10 0 10 0 0
0 IIS OP PIC 10 10 0 10 0 0
0 IIS OP TXT 10 10 0 10 0 0
0 IIS OP VID 10 10 0 10 0 0
0 AP OP PIC 10 10 0 10 0 0
0 AP OP TXT 11 11 0 11 0 0
0 AP OP VID 11 11 0 11 0 0
0 AP GC PIC 10 10 0 10 0 0
0 AP GC TXT 11 11 0 11 0 0
0 AP GC VID 10 10 0 10 0 0
0 AP FF PIC 21 21 0 21 0 0
0 AP FF TXT 21 21 0 21 0 0
0 AP FF VID 11 11 0 11 0 0
10 AP IE PIC 21 11 10 11 10 0
10 AP IE TXT 20 0 20 10 10 50
10 AP IE VID 40 30 10 10 30 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 find out the causes of resets in
a very isolated manner. Tests were devised in scenarios in which different
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 depend-
ing 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 define user dis-
satisfaction using tcp resets. We analyzed in the traces that the network resets
would reach double its amount in a user dissatisfied environment as compare to
a user satisfied 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 file.

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, net-
work 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 be-
tween the number of ports being used and the number of ports reset, to define
a threshold value of resets in a user satisfied 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 traffic pat-
terns 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 traffic measurements from the sprint
IP backbone, Network, IEEE, vol. 17, no. 6, pp. 6 16, december 2003.
[5] C. Williamson, Internet traffic 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. San-
doval, Characterisation of web traffic, 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 traffic (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 traffic:
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:Varified 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:Varified June,
2010]. Available: http://www.cse.ucsd.edu/classes/wi01/cse222/projects/
reports/tcp-flags-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:Varified 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, Ac-

centure Customer Satisfaction Survey, 2008. [Online:Varified
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:Varified 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 Definition. [Online:Varified 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 multime-

dia 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 Net-
works Coporation, October 2004. [Online:Varified June, 2010].
Available: http://www.nokia.com/NOKIA COM 1/About Nokia/Press/
White Papers/pdf files/whitepaper qoe net.pdf

[23] Delivering optimal quality of experience (QoE) for IPTV success.

Spirent: White Paper, Febuary 2006. [Online:Varified 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:Varified 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 differences be-

tween 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 traffic for capacity dimensioning of internet access lines, Perform.
Eval., vol. 34, pp. 249271, December 1998.

[32] Wusage web server log analysis software, [Online:Varified 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 characteri-

zation and performance implications, Networking, IEEE/ACM Transac-
tions on, vol. 5, no. 5, pp. 631 645, Oct. 1997.

42
[38] E. Cohen, B. Krishnamurthy, and J. Rexford, Improving end-to-end per-
formance of the web using server volumes and proxy filters, in Proceedings
of the ACM SIGCOMM 98 conference on Applications, technologies, ar-
chitectures, 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 char-

acterize web client traffic and to generate synthetic traffic, 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 traffic 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:Varified June, 2010]. Available:
http://www.news.cs.nyu.edu/trandinh/publications/sax.pdf

[45] Usage share of web browsers, [Online:Varified June, 2010]. Available:

http://en.wikipedia.org/wiki/Usage share of web browsers

[46] Browser Statistics, [Online:Varified June, 2010]. Available: http:

//www.w3schools.com/browsers/browsers-stats.asp

[47] OS Platform Statistics, [Online:Varified June, 2010]. Available: http:

//www.w3schools.com/browsers/browsers os.asp

[48] Usage share of operating systems, [Online:Varified June, 2010]. Available:

http://en.wikipedia.org/wiki/Usage share of operating-systems

[49] Web server survey, [Online:Varified June, 2010]. Available: http:

//news.netcraft.com/archives/category/web-server-survey/

[50] Market structure, [Online:Varified June, 2010]. Available: http:

//en.wikipedia.org/wiki/Web server

[51] C. Sanders, Practical Packet Analysis:Using Wireshark to Solve Real-

World Network Problems,2007.

includeAppendix

43
Appendix A

Appendix

A.1 Network Trace files

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

A.1.1 Uninterrupted TCP Flows

|Time | 192.168.1.4 |
| | 192.168.1.5 |
|0.003 | TCP: kdm > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(2115) ------------------> (80) |
|0.005 | TCP: http > kdm [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2115) <------------------ (80) |
|0.018 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2115) ------------------> (80) |
|0.093 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(2115) ------------------> (80) |
|1.332 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2115) ------------------> (80) |
|16.555 | TCP: http > kdm [FIN, ACK] |Seq=1162431 Ack=1089 Win=8576 Len=0
| |(2115) <------------------ (80) |
|29.590 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|30.984 | TCP: unisql-java > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(1979) ------------------> (80) |
|30.986 | TCP: http > unisql-java [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1979) <------------------ (80) |
|31.016 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1979) ------------------> (80) |
|31.060 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1979) ------------------> (80) |
|45.555 | TCP: unisql-java > http [FIN, ACK] |Seq=712 Ack=4543 Win=17520 Len=0
| |(1979) ------------------> (80) |
|45.562 | TCP: http > unisql-java [FIN, ACK] |Seq=4543 Ack=713 Win=7504 Len=0
| |(1979) <------------------ (80) |

Figure A.2: Apache Firefox Text Web Page.

|Time | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: fiorano-msgsvc > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1856) ------------------> (80) |
|0.002 | TCP: http > fiorano-msgsvc [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1856) <------------------ (80) |
|0.018 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1856) ------------------> (80) |
|0.113 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1856) ------------------> (80) |
|0.998 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1856) ------------------> (80) |
|16.195 | TCP: http > fiorano-msgsvc [FIN, ACK] | Seq=107117 Ack=1123 Win=8576 Len=0
| |(1856) <------------------ (80) |
|29.587 | TCP: fiorano-msgsvc > http [FIN, ACK] | Seq=1123 Ack=107118 Win=17520 Len=0
| |(1856) ------------------> (80) |

Figure A.3: Apache Firefox Video Web Page.

45
|Time | 192.168.1.4 |
| | 192.168.1.5 |
|63.658 | TCP: nbx-dir > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2096) ------------------> (80) |
|63.660 | TCP: http > nbx-dir [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(2096) <------------------ (80) |
|63.660 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2096) ------------------> (80) |
|63.675 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(2096) ------------------> (80) |
|65.398 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2096) ------------------> (80) |
|80.734 | TCP: http > nbx-dir [FIN, ACK] |Seq=1162431 Ack=1104 Win=9088 Len=0
| |(2096) <------------------ (80) |
|85.460 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: 2194 > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2194) ------------------> (80) |
|0.009 | TCP: http > 2194 [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(2194) <------------------ (80) |
|0.010 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2194) ------------------> (80) |
|0.044 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2194) ------------------> (80) |
|15.318 | TCP: http > 2194 [FIN, ACK] | Seq=4543 Ack=741 Win=8000 Len=0
| |(2194) <------------------ (80) |
|15.318 | TCP: http > 2194 [FIN, ACK] |Seq=4543 Ack=741 Win=8000 Len=0
| |(2194) <------------------ (80) |
|20.049 | TCP: 2194 > http [FIN, ACK] | Seq=741 Ack=4544 Win=65536 Len=0
| |(2194) ------------------> (80) |

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

46
|Time | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: rimf-ps > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2209) ------------------> (80) |
|0.002 | TCP: http > rimf-ps [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(2209) <------------------ (80) |
|0.003 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2209) ------------------> (80) |
|0.700 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(2209) ------------------> (80) |
|0.701 | TCP: noaaport > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2210) ------------------> (80) |
|0.703 | TCP: http > noaaport [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(2210) <------------------ (80) |
|0.703 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2210) ------------------> (80) |
|15.834 | TCP: http > noaaport [FIN, ACK] |Seq=504 Ack=333 Win=6912 Len=0
| |(2210) <------------------ (80) |
|15.835 | TCP: http > rimf-ps [FIN, ACK] |Seq=106615 Ack=776 Win=8000 Len=0
| |(2209) <------------------ (80) |
|20.714 | TCP: noaaport > http [FIN, ACK] |Seq=333 Ack=505 Win=65032 Len=0
| |(2210) ------------------> (80) |
|20.714 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: msync > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(2072) ------------------> (80) |
|0.005 | TCP: http > msync [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2072) <------------------ (80) |
|0.005 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2072) ------------------> (80) |
|0.484 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(2072) ------------------> (80) |
|1.772 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2072) ------------------> (80) |
|16.788 | TCP: http > msync [FIN, ACK] |Seq=1162431 Ack=687 Win=8576 Len=0
| |(2072) <------------------ (80) |
|21.772 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|11.408 | TCP: submitserver > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(2028) ------------------> (80) |
|11.409 | TCP: http > submitserver [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2028) <------------------ (80) |
|11.409 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2028) ------------------> (80) |
|12.024 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2028) ------------------> (80) |
|27.301 | TCP: http > submitserver [FIN, ACK] | Seq=4543 Ack=426 Win=7504 Len=0
| |(2028) <------------------ (80) |
|32.017 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: concomp1 > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1802) ------------------> (80) |
|0.002 | TCP: http > concomp1 [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1802) <------------------ (80) |
|0.003 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1802) ------------------> (80) |
|0.544 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1802) ------------------> (80) |
|0.549 | TCP: concomp1 > http [RST, ACK] |Seq=307 Ack=1940 Win=0 Len=0
| |(1802) ------------------> (80) |
|0.599 | TCP: hp-hcip-gwy > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1803) ------------------> (80) |
|0.600 | TCP: http > hp-hcip-gwy [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1803) <------------------ (80) |
|0.601 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1803) ------------------> (80) |
|1.535 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1803) ------------------> (80) |
|16.837 | TCP: http > hp-hcip-gwy [FIN, ACK] |Seq=106639 Ack=418 Win=7504 Len=0
| |(1803) <------------------ (80) |
|16.843 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|20.292 | TCP: x-bone-api > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(2165) ------------------> (80) |
|20.293 | TCP: http > x-bone-api [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2165) <------------------ (80) |
|20.296 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2165) ------------------> (80) |
|20.303 | GET /WorldMap.jpg H |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(2165) ------------------> (80) |
|21.600 | GET /favicon.ico HT |HTTP: GET /favicon.ico HTTP/1.1
| |(2165) ------------------> (80) |
|36.819 | TCP: http > x-bone-api [FIN, ACK] |Seq=1162431 Ack=1406 Win=8576 Len=0
| |(2165) <------------------ (80) |
|36.894 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.279 | TCP: eye2eye > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1948) ------------------> (80) |
|0.281 | TCP: http > eye2eye [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1948) <------------------ (80) |
|0.290 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1948) ------------------> (80) |
|0.300 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1948) ------------------> (80) |
|15.515 | TCP: http > eye2eye [FIN, ACK] |Seq=4543 Ack=906 Win=7504 Len=0
| |(1948) <------------------ (80) |
|15.598 | 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 | 192.168. |
| | 192.168.1.5 |
|0.286 | TCP: sugp > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1905) ------------------> (80) |
|0.288 | TCP: http > sugp [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1905) <------------------ (80) |
|0.294 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1905) ------------------> (80) |
|0.300 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1905) ------------------> (80) |
|1.689 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1905) ------------------> (80) |
|16.814 | TCP: http > sugp [FIN, ACK] | Seq=107117 Ack=1410 Win=8576 Len=0
| |(1905) <------------------ (80) |
|16.915 | TCP: sugp > http [FIN, ACK] |Seq=1410 Ack=107118 Win=17018 Len=0
| |(1905) ------------------> (80) |
|18.336 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|1.910 | TCP: pptp > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1723) ------------------> (80) |
|1.914 | TCP: http > pptp [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1723) <------------------ (80) |
|1.915 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1723) ------------------> (80) |
|1.929 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1723) ------------------> (80) |
|4.272 | HTTP: [TCP Retransmission] | GET /WorldMap.jpg HTTP/1.1
| |(1723) ------------------> (80) |
|5.351 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1723) ------------------> (80) |
|5.355 | TCP: pptp > http [FIN, ACK] | Seq=1089 Ack=1166062 Win=16237 Len=0
| |(1723) ------------------> (80) |
|5.355 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|1.230 | TCP: svs-omagent > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(1625) ------------------> (80) |
|1.231 | TCP: http > svs-omagent [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1625) <------------------ (80) |
|1.231 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1625) ------------------> (80) |
|1.465 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1625) ------------------> (80) |
|1.538 | TCP: svs-omagent > http [FIN, ACK] | Seq=712 Ack=14241 Win=16237 Len=0
| |(1625) ------------------> (80) |
|1.538 | 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 | 192.168.1.4 |
| | 192.168.1.5|
|0.000 | TCP: directplay > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2234) ------------------> (80) |
|0.119 | TCP:http > directplay [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
| |(2234) <------------------ (80) |
|0.120 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2234) ------------------> (80) |
|0.125 | HTTP/1.1 404 Object |HTTP: HTTP/1.1 404 Object Not Found (text/html)
| |(2234) <------------------ (80) |
|0.126 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.200 | TCP: mmcal > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2272) ------------------> (80) |
|0.201 | TCP: http > mmcal [SYN,ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
| |(2272) <------------------ (80) |
|0.202 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2272) ------------------> (80) |
|0.236 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2272) ------------------> (80) |
|0.243 | TCP: mmcal > http [FIN,ACK] |Seq=741 Ack=5478 Win=64252 Len=0
| |(2272) ------------------> (80) |
|0.244 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.000 | TCP: njenet-ssl > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2252) ------------------> (80) |
|0.250 | TCP: dtv-chan-req > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2253) ------------------> (80) |
|0.277 | http > njenet-ssl |TCP:http >0njenet-ssl
WS=0 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=146
| |(2252) <------------------ (80) |
|0.279 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2252) ------------------> (80) |
|0.279 | http > dtv-chan-req |TCP:http>dtv-chan-req
0 WS=0 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=146
| |(2253) <------------------ (80) |
|1.086 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(2252) ------------------> (80) |
|1.087 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2253) ------------------> (80) |
|1.209 | HTTP/1.1 404 Object |HTTP: HTTP/1.1 404 Object Not Found (text/html)
| |(2253) <------------------ (80) |
|1.296 | TCP: dtv-chan-req > http [FIN, ACK] | Seq=333 Ack=4205 Win=64252 Len=0
| |(2253) ------------------> (80) |
|240.515 | TCP: njenet-ssl > http [FIN, ACK] |Seq=776 Ack=106746 Win=64766 Len=0
| |(2252) ------------------> (80) |
|240.516 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|15.347 | TCP: kmscontrol > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(1773) ------------------> (80) |
|15.348 | TCP: http > kmscontrol [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1773) <------------------ (80) |
|15.350 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1773) ------------------> (80) |
|15.719 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1773) ------------------> (80) |
|17.265 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1773) ------------------> (80) |
|17.269 | TCP: kmscontrol > http [RST, ACK] | Seq=687 Ack=1164779 Win=0 Len=0
| |(1773) ------------------> (80) |
|17.270 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.192 | TCP: inspect > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(1602) ------------------> (80) |
|0.193 | TCP: http > inspect [SYN,ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1602) <------------------ (80) |
|0.195 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1602) ------------------> (80) |
|0.614 | GET /favicon.ico | HTTP: GET /favicon.ico HTTP/1.1
| |(1602) ------------------> (80) |
|0.703 | TCP: inspect > http [RST,ACK] | Seq=426 Ack=11498 Win=0 Len=0
| |(1602) ------------------> (80) |
|0.705 | TCP: http > inspect [FIN,ACK] | Seq=14241 Ack=426 Win=17095 Len=0
| |(1602) <------------------ (80) |

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

|Time | 192.168.1.4 |
| | 192.168.1.5 |
|0.373 | TCP: asci-val > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1560) ------------------> (80) |
|0.375 | TCP: http > asci-val [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1560) <------------------ (80) |
|0.375 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1560) ------------------> (80) |
|2.789 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1560) ------------------> (80) |
|3.344 | TCP: asci-val > http [RST, ACK] | Seq=307 Ack=3384 Win=0 Len=0
| |(1560) ------------------> (80) |
|3.549 | TCP: facilityview > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1561) ------------------> (80) |
|3.650 | TCP: http > facilityview [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1561) <------------------ (80) |
|3.656 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1561) ------------------> (80) |
|3.661 | TCP: facilityview > http [RST, ACK] | Seq=207 Ack=1461 Win=0 Len=0
| |(1561) ------------------> (80) |

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

55
|Time | 192.168.1.4 |
| | 192.168.1.5 |
|45.485 | TCP: rsvp-encap-2 > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1699) ------------------> (80) |
|45.487 | TCP: http > rsvp-encap-2 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1699) <------------------ (80) |
|45.487 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1699) ------------------> (80) |
|45.491 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1699) ------------------> (80) |
|47.187 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1699) ------------------> (80) |
|47.638 | TCP: http > rsvp-encap-2 [FIN, ACK] | Seq=1166062 Ack=1406 Win=16115 Len=0
| |(1699) <------------------ (80) |
|47.739 | TCP: rsvp-encap-2 > http [FIN, ACK] | Seq=1406 Ack=1166063 Win=16237 Len=0
| |(1699) ------------------> (80) |

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

56
|Time | 192.168.1.4 |
| | 192.168.1.5 |
|0.797 | TCP: netview-aix-12 > http [SYN] |Seq=0 Win=16384 Len=0 MSS=1460
| |(1672) ------------------> (80) |
|0.798 | TCP: http > netview-aix-12 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1672) <------------------ (80) |
|0.798 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1672) ------------------> (80) |
|0.813 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1672) ------------------> (80) |
|0.818 | TCP: http > netview-aix-12 [FIN, ACK] | Seq=14241 Ack=906 Win=16615 Len=0
| |(1672) <------------------ (80) |
|0.919 | 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 | 192.168.1.4 |
| | 192.168.1.5 |
|0.646 | TCP: pip > http [SYN] | Seq=0 Win=16384 Len=0 MSS=1460
| |(1321) ------------------> (80) |
|0.647 | TCP: http > pip [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1321) <------------------ (80) |
|0.647 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1321) ------------------> (80) |
|0.654 | GET /htmlexample. |HTTP: GET /htmlexample.mpeg HTTP/1.1
| |(1321) ------------------> (80) |
|1.798 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1321) ------------------> (80) |
|1.804 | TCP: http > pip [FIN, ACK] |Seq=110757 Ack=1410 Win=16111 Len=0
| |(1321) <------------------ (80) |
|2.211 | 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 | 192.168.1.3 |
| | 192.168.1.2 |
|0.000 | TCP: oracle-oms > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1159) ------------------> (80) |
|0.001 | TCP: http > oracle-oms [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1159) <------------------ (80) |
|0.015 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1159) ------------------> (80) |
|0.074 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1159) ------------------> (80) |
|0.972 | TCP: oracle-oms > http [RST, ACK] |Seq=743 Ack=2468246 Win=0 Len=0
| |(1159) ------------------> (80) |
|0.972 | TCP: olsv > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1160) ------------------> (80) |
|0.972 | TCP: health-polling > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1161) ------------------> (80) |
|0.985 | TCP: http > olsv [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1160) <------------------ (80) |
|0.986 | TCP: http > health-polling [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=146
| |(1161) <------------------ (80) |
|0.993 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1160) ------------------> (80) |
|1.026 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1161) ------------------> (80) |
|1.046 | TCP: olsv > http [RST, ACK] |Seq=347 Ack=135781 Win=0 Len=0
| |(1160) ------------------> (80) |
|1.046 | GET /WorldMap.jpg H |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1161) ------------------> (80) |
|5.026 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1161) ------------------> (80) |
|20.065 |TCP: http > health-polling [FIN, ACK] |Seq=3568273 Ack=1356 Win=8576 Len=0
| |(1161) <------------------ (80) |
|29.617 | TCP: health-polling > http [FIN, ACK] | Seq=1356 Ack=3568274 Win=64558 Len=0
| |(1161) ------------------> (80) |

Figure A.25: Apache Firefox Picture Web Page.

59
|Time | 192.168.1.3 |
| | 192.168.1.4 |
|1.575 | TCP: x9-icue > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1145) ------------------> (80) |
|1.717 | TCP: http > x9-icue [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1145) <------------------ (80) |
|1.718 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1145) ------------------> (80) |
|2.542 | TCP: audit-transfer > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1146) ------------------> (80) |
|2.544 | TCP: http > audit-transfer [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1146) <------------------ (80) |
|2.572 | TCP: x9-icue > http [RST, ACK] | Seq=366 Ack=828853 Win=0 Len=0
| |(1145) ------------------> (80) |
|2.573 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1146) ------------------> (80) |
|2.573 | TCP: capioverlan > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1147) ------------------> (80) |
|2.574 | TCP: http > capioverlan [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1147) <------------------ (80) |
|2.581 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1147) ------------------> (80) |
|2.596 | TCP: audit-transfer > http [RST, ACK] |Seq=347 Ack=32769 Win=0 Len=0
| |(1146) ------------------> (80) |
|13.287 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1147) ------------------> (80) |
|136.380 | TCP: capioverlan > http [FIN, ACK] | Seq=845 Ack=2804661 Win=65535 Len=0
| |(1147) ------------------> (80) |
|136.382 | TCP: http > capioverlan [FIN, ACK] | Seq=2804661 Ack=846 Win=16676 Len=0
| |(1147) <------------------ (80) |

Figure A.26: Apache Firefox Text Web Page.

60
|Time | 192.168.1.4 |
| | 192.168.1.2 |
|0.002 | TCP: ias-admind > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(2141) ------------------> (80) |
|0.003 | TCP: http > ias-admind [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2141) <------------------ (80) |
|0.015 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2141) ------------------> (80) |
|0.084 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2141) ------------------> (80) |
|0.743 | TCP: tdmoip > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(2142) ------------------> (80) |
|0.745 | TCP: http > tdmoip [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2142) <------------------ (80) |
|0.776 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2142) ------------------> (80) |
|1.723 | TCP: tdmoip > http [RST, ACK] |Seq=411 Ack=1910217 Win=0 Len=0
| |(2142) ------------------> (80) |
|1.723 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2141) ------------------> (80) |
|2.195 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2141) ------------------> (80) |
|17.551 | TCP: http > ias-admind [FIN, ACK] | Seq=695985 Ack=1667 Win=9648 Len=0
| |(2141) <------------------ (80) |
|29.599 | 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 | 192.168.1.4 |
| | 192.168.1.2 |
|0.084 | TCP: netop-school > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(1971) ------------------> (80) |
|0.085 | TCP: http>netop-school[SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(1971) <------------------ (80) |
|0.086 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1971) ------------------> (80) |
|0.915 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1971) ------------------> (80) |
|0.916 | TCP: intersys-cache > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(1972) ------------------> (80) |
|0.918 | TCP:http>intersys-cache[SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(1972) <------------------ (80) |
|0.918 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1972) ------------------> (80) |
|1.340 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1972) ------------------> (80) |
|1.359 | TCP: intersys-cache > http [FIN, ACK] | Seq=858 Ack=212532 Win=65326 Len=0
| |(1972) ------------------> (80) |
|1.369 | TCP: http > intersys-cache [FIN, ACK] | Seq=212532 Ack=859 Win=8000 Len=0
| |(1972) <------------------ (80) |
|1.897 | TCP: netop-school > http [FIN, ACK] |Seq=775 Ack=1305401 Win=1296 Len=0
| |(1971) ------------------> (80) |
|1.897 | TCP: netop-school > http [RST, ACK] | Seq=776 Ack=1305401 Win=0 Len=0
| |(1971) ------------------> (80) |
|2.052 | TCP: dlsrap > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(1973) ------------------> (80) |
|2.053 | TCP: http > dlsrap [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(1973) <------------------ (80) |
|2.054 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1973) ------------------> (80) |
|2.056 | TCP: dlsrap > http [FIN, ACK] |Seq=486 Ack=192 Win=65344 Len=0
| |(1973) ------------------> (80) |
|2.058 | TCP: drp > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(1974) ------------------> (80) |
|2.059 | TCP: http > dlsrap [FIN, ACK] | Seq=192 Ack=487 Win=6912 Len=0
| |(1973) <------------------ (80) |
|2.059 | TCP: http > drp [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
| |(1974) <------------------ (80) |
|2.059 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1974) ------------------> (80) |
|17.597 | TCP: http > drp [FIN, ACK] |Seq=1158352 Ack=430 Win=6912 Len=0
| |(1974) <------------------ (80) |
|22.591 | TCP: drp > http [FIN, ACK] | Seq=430 Ack=1158353 Win=65536 Len=0
| |(1974) ------------------> (80) |

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

62
|Time | 192.168.1.3 |
| | 192.168.1.2 |
|0.000 | TCP: td-postman > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1049) ------------------> (80) |
|0.001 | TCP: http > td-postman [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1049) <------------------ (80) |
|0.001 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1049) ------------------> (80) |
|0.077 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1049) ------------------> (80) |
|2.005 | TCP: td-postman > http [RST, ACK] | Seq=481 Ack=3919119 Win=0 Len=0
| |(1049) ------------------> (80) |
|2.071 | TCP: cma > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1050) ------------------> (80) |
|2.072 | TCP: http > cma [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1050) <------------------ (80) |
|2.072 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1050) ------------------> (80) |
|2.075 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1050) ------------------> (80) |
|4.068 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1050) ------------------> (80) |
|19.143 | TCP: http > cma [FIN, ACK] |Seq=2255744 Ack=895 Win=8576 Len=0
| |(1050) <------------------ (80) |
|24.134 | TCP: cma > http [RST, ACK] |Seq=895 Ack=2255745 Win=0 Len=0
| |(1050) ------------------> (80) |

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

|Time | 192.168.1.3 |
| | 192.168.1.2 |
|0.000 | TCP: gpfs > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1191) ------------------> (80) |
|0.002 | TCP: http > gpfs [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1191) <------------------ (80) |
|0.002 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1191) ------------------> (80) |
|15.184 | TCP: http > gpfs [FIN, ACK] |Seq=40820 Ack=220 Win=6432 Len=0
| |(1191) <------------------ (80) |
|20.152 | TCP: gpfs > http [RST, ACK] |Seq=220 Ack=40821 Win=0 Len=0
| |(1191) ------------------> (80) |
|105.173 | TCP: caids-sensor > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1192) ------------------> (80) |
|105.174 | TCP: http > caids-sensor [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1192) <------------------ (80) |
|105.174 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1192) ------------------> (80) |
|105.351 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1192) ------------------> (80) |
|120.368 | TCP: http > caids-sensor [FIN, ACK] | Seq=212536 Ack=521 Win=7504 Len=0
| |(1192) <------------------ (80) |
|125.355 | TCP: caids-sensor > http [RST, ACK] |Seq=521 Ack=212537 Win=0 Len=0
| |(1192) ------------------> (80) |

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

63
|Time | 192.168.1.4 |
| | 192.168.1.2 |
|0.000 | TCP: dls > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(2047) ------------------> (80) |
|0.001 | TCP: http > dls [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2047) <------------------ (80) |
|0.001 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2047) ------------------> (80) |
|0.073 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2047) ------------------> (80) |
|0.076 | TCP: dls > http [RST, ACK] |Seq=306 Ack=3402 Win=0 Len=0
| |(2047) ------------------> (80) |
|0.259 | TCP: dls-monitor > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(2048) ------------------> (80) |
|0.260 | TCP: http > dls-monitor [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2048) <------------------ (80) |
|0.260 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2048) ------------------> (80) |
|0.914 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2048) ------------------> (80) |
|1.671 | TCP: dls-monitor > http [RST, ACK] | Seq=417 Ack=562446 Win=0 Len=0
| |(2048) ------------------> (80) |
|1.816 | TCP: nfs > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(2049) ------------------> (80) |
|1.817 | TCP: http > nfs [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2049) <------------------ (80) |
|1.817 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2049) ------------------> (80) |
|1.821 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2049) ------------------> (80) |
|1.823 | TCP: nfs > http [RST, ACK] | Seq=513 Ack=1671 Win=0 Len=0
| |(2049) ------------------> (80) |
|1.922 | TCP: av-emb-config > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(2050) ------------------> (80) |
|1.923 | TCP: http > av-emb-config [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(2050) <------------------ (80) |
|1.939 | GET /htmlsample.mpe |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2050) ------------------> (80) |
|17.780 | TCP: http > av-emb-config [FIN, ACK] | Seq=2096810 Ack=327 Win=6432 Len=0
| |(2050) <------------------ (80) |
|22.766 | TCP: av-emb-config > http [RST, ACK] | Seq=327 Ack=2096811 Win=0 Len=0
| |(2050) ------------------> (80) |

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

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

Figure A.34: Apache Opera Picture Web Page.

64
|Time | 192.168.1.3 |
| | 192.168.1.4 |
|0.000 | TCP: mosaicsyssvc1 > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1235) ------------------> (80) |
|0.032 | TCP: http > mosaicsyssvc1 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1235) <------------------ (80) |
|0.075 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1235) ------------------> (80) |
|0.888 | TCP: mosaicsyssvc1 > http [RST, ACK] | Seq=407 Ack=1275317 Win=0 Len=0
| |(1235) ------------------> (80) |
|0.888 | TCP: mosaicsyssvc1 > http [RST] |Seq=407 Win=0 Len=0
| |(1235) ------------------> (80) |
|1.264 | TCP: tsdos390 > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1237) ------------------> (80) |
|1.266 | TCP: http > tsdos390 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1237) <------------------ (80) |
|1.309 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1237) ------------------> (80) |
|4.260 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1237) ------------------> (80) |
|127.526 | TCP: tsdos390 > http [FIN, ACK] |Seq=958 Ack=3510148 Win=65098 Len=0
| |(1237) ------------------> (80) |
|127.528 | TCP: http > tsdos390 [FIN, ACK] | Seq=3510148 Ack=959 Win=16563 Len=0
| |(1237) <------------------ (80) |

Figure A.35: Apache Opera Text Web Page.

|Time | 192.168.1.4 |
| | 192.168.1.2 |
|7.493 | TCP: intrastar > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1907) ------------------> (80) |
|7.494 | TCP: http > intrastar [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1907) <------------------ (80) |
|7.562 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1907) ------------------> (80) |
|7.617 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1907) ------------------> (80) |
|9.138 | TCP: intrastar > http [RST, ACK] | Seq=910 Ack=147777 Win=0 Len=0
| |(1907) ------------------> (80) |
|10.238 | TCP: global-wlink > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1909) ------------------> (80) |
|10.239 | TCP: http > global-wlink [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
| |(1909) <------------------ (80) |
|10.240 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1909) ------------------> (80) |
|10.755 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1909) ------------------> (80) |
|11.650 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1909) ------------------> (80) |
|27.385 | TCP: http > global-wlink [FIN, ACK] |Seq=2545774 Ack=1486 Win=8576 Len=0
| |(1909) <------------------ (80) |
|27.490 | TCP: global-wlink > http [FIN, ACK] | Seq=1486 Ack=2545775 Win=65535 Len=0
| |(1909) ------------------> (80) |

Figure A.36: Apache Opera Video Web Page.

65
|Time | 192.168.1.4 |
| | 192.168.1.2 |
|0.000 | TCP: intellistor-lm > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1539) ------------------> (80) |
|0.234 | TCP: http > intellistor-lm [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1539) <------------------ (80) |
|0.235 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1539) ------------------> (80) |
|0.248 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1539) ------------------> (80) |
|1.148 | TCP: rds > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1540) ------------------> (80) |
|1.148 | TCP: rds2 > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1541) ------------------> (80) |
|1.153 | TCP: intellistor-lm > http [FIN, ACK] |Seq=743 Ack=1872305 Win=64359 Len=0
| |(1539) ------------------> (80) |
|1.153 | TCP: intellistor-lm > http [RST, ACK] | Seq=744 Ack=1873765 Win=0 Len=0
| |(1539) ------------------> (80) |
|1.155 | TCP: http > rds [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1540) <------------------ (80) |
|1.155 | TCP: http > rds2 [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1541) <------------------ (80) |
|1.210 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1540) ------------------> (80) |
|1.210 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1541) ------------------> (80) |
|1.218 | TCP: rds > http [FIN, ACK] |Seq=347 Ack=10221 Win=65535 Len=0
| |(1540) ------------------> (80) |
|1.218 | TCP: rds > http [RST, ACK] | Seq=348 Ack=11681 Win=0 Len=0
| |(1540) ------------------> (80) |
|1.222 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1541) ------------------> (80) |
|3.337 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1541) ------------------> (80) |
|119.608 | TCP: rds2 > http [FIN, ACK] |Seq=1333 Ack=4230606 Win=65165 Len=0
| |(1541) ------------------> (80) |
|119.841 | TCP: http > rds2 [FIN, ACK] | Seq=4230606 Ack=1334 Win=16188 Len=0
| |(1541) <------------------ (80) |

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

66
|Time | 192.168.1.3 |
| | 192.168.1.2 |
|15.135 | TCP: dfn > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1133) ------------------> (80) |
|15.137 | TCP: http > dfn [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1133) <------------------ (80) |
|15.137 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1133) ------------------> (80) |
|16.666 | TCP: aplx > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1134) ------------------> (80) |
|16.667 | TCP: dfn > http [RST, ACK] | Seq=366 Ack=1291701 Win=0 Len=0
| |(1133) ------------------> (80) |
|16.668 | TCP: http > aplx [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1134) <------------------ (80) |
|16.720 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1134) ------------------> (80) |
|16.720 | TCP: omnivision > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1135) ------------------> (80) |
|16.721 | TCP: http > omnivision [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1135) <------------------ (80) |
|16.754 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1135) ------------------> (80) |
|16.769 | TCP: aplx > http [RST, ACK] | Seq=347 Ack=90113 Win=0 Len=0
| |(1134) ------------------> (80) |
|25.746 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1135) ------------------> (80) |
|149.693 | TCP: omnivision > http [FIN, ACK] |Seq=846 Ack=2283010 Win=65535 Len=0
| |(1135) ------------------> (80) |
|149.694 | TCP: http > omnivision [FIN, ACK] | Seq=2283010 Ack=847 Win=16675 Len=0
| |(1135) <------------------ (80) |

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

Microsoft IIS_Firefox_Video Web Page

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

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 | 192.168.1.4 |
| | 192.168.1.2 |
|5.458 | TCP: norton-lambert > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2338) ------------------> (80) |
|5.615 | TCP: http>norton-lambert[SYN, ACK] |Seq=0 Ack=1Win=17520Len=0MSS=1460WS=0
| |(2338) <------------------ (80) |
|5.615 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2338) ------------------> (80) |
|6.314 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2338) ------------------> (80) |
|6.315 | TCP: 3com-webview > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2339) ------------------> (80) |
|6.537 | TCP: http > 3com-webview [SYN, ACK] |Seq=0Ack=1Win=17520 Len=0 MSS=1460 WS=0
| |(2339) <------------------ (80) |
|6.538 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(2339) ------------------> (80) |
|7.031 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(2339) ------------------> (80) |
|7.061 | TCP: 3com-webview > http [FIN, ACK] | Seq=854 Ack=212442 Win=65348 Len=0
| |(2339) ------------------> (80) |
|7.064 | TCP: http > 3com-webview [FIN, ACK] | Seq=212442 Ack=855 Win=16667 Len=0
| |(2339) <------------------ (80) |
|7.616 | TCP: norton-lambert > http [FIN, ACK] | Seq=775 Ack=1161069 Win=0 Len=0
| |(2338) ------------------> (80) |
|7.617 | TCP: norton-lambert > http [RST, ACK] |Seq=776 Ack=1161069 Win=0 Len=0
| |(2338) ------------------> (80) |
|7.762 | TCP: wrs_registry > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2340) ------------------> (80) |
|7.765 | TCP: http>wrs_registry[SYN, ACK] |Seq=0Ack=1Win=17520Len=0MSS=1460 WS=0
| |(2340) <------------------ (80) |
|7.765 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2340) ------------------> (80) |
|7.768 | TCP: wrs_registry > http [FIN, ACK] |Seq=478 Ack=141 Win=65396 Len=0
| |(2340) ------------------> (80) |
|7.769 | TCP: http > wrs_registry [FIN, ACK] |Seq=141 Ack=479 Win=17043 Len=0
| |(2340) <------------------ (80) |
|7.770 | TCP: xiostatus > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460 WS=1
| |(2341) ------------------> (80) |
|7.771 | TCP: http > xiostatus [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
| |(2341) <------------------ (80) |
|7.772 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(2341) ------------------> (80) |
|245.343 | TCP: xiostatus > http [FIN, ACK] | Seq=422 Ack=1305028 Win=65536 Len=0
| |(2341) ------------------> (80) |
|245.345 | TCP: http > xiostatus [FIN, ACK] | Seq=1305028 Ack=423 Win=17099 Len=0
| |(2341) <------------------ (80) |

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

|Time | 192.168.1.4 |
| | 192.168.1.2 |
|11.690 | TCP: iclpv-sc > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1390) ------------------> (80) |
|11.691 | TCP: http > iclpv-sc [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1390) <------------------ (80) |
|11.692 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1390) ------------------> (80) |
|11.733 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1390) ------------------> (80) |
|12.764 | TCP: iclpv-sc > http [RST] | Seq=481 Win=0 Len=0
| |(1390) ------------------> (80) |
|12.764 | TCP: iclpv-sc > http [RST, ACK] | Seq=481 Ack=1944857 Win=0 Len=0
| |(1390) ------------------> (80) |
|12.768 | TCP: iclpv-sas > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1391) ------------------> (80) |
|12.773 | TCP: http > iclpv-sas [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1391) <------------------ (80) |
|12.773 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1391) ------------------> (80) |
|12.777 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1391) ------------------> (80) |
|16.017 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1391) ------------------> (80) |
|76.333 | TCP: iclpv-sas > http [RST, ACK] |Seq=881 Ack=4169233 Win=0 Len=0
| |(1391) ------------------> (80) |

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

69
|Time | 192.168.1.3 |
| | 192.168.1.2 |
|0.081 | TCP: hacl-qs > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1238) ------------------> (80) |
|0.082 | TCP: http > hacl-qs [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1238) <------------------ (80) |
|0.083 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1238) ------------------> (80) |
|2.289 | TCP: hacl-qs > http [RST, ACK] | Seq=220 Ack=1710953 Win=0 Len=0
| |(1238) ------------------> (80) |
|2.335 | TCP: nmsd > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1239) ------------------> (80) |
|2.436 | TCP: http > nmsd [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1239) <------------------ (80) |
|2.436 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1239) ------------------> (80) |
|37.585 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1239) ------------------> (80) |
|102.962 | TCP: nmsd > http [RST, ACK] | Seq=535 Ack=1799464 Win=0 Len=0
| |(1239) ------------------> (80) |

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

|Time | 192.168.1.4 |
| | 192.168.1.2 |
|49.101 | TCP: netarx > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1040) ------------------> (80) |
|49.102 | TCP: http > netarx [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1040) <------------------ (80) |
|49.102 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1040) ------------------> (80) |
|50.012 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1040) ------------------> (80) |
|50.123 | TCP: netarx > http [RST, ACK] |Seq=306 Ack=3361 Win=0 Len=0
| |(1040) ------------------> (80) |
|50.794 | TCP: danf-ak2 > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1041) ------------------> (80) |
|50.955 | TCP: http > danf-ak2 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1041) <------------------ (80) |
|50.955 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1041) ------------------> (80) |
|56.776 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1041) ------------------> (80) |
|57.836 | TCP: danf-ak2 > http [RST, ACK] | Seq=417 Ack=350342 Win=0 Len=0
| |(1041) ------------------> (80) |
|58.328 | TCP: afrog > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1042) ------------------> (80) |
|58.398 | TCP: http > afrog [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1042) <------------------ (80) |
|58.398 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1042) ------------------> (80) |
|58.403 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1042) ------------------> (80) |
|58.405 | TCP: afrog > http [RST, ACK] | Seq=501 Ack=1649 Win=0 Len=0
| |(1042) ------------------> (80) |
|58.510 | TCP: boinc-client > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1043) ------------------> (80) |
|58.705 | TCP: http > boinc-client [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1043) <------------------ (80) |
|58.706 | GET /htmlsample |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1043) ------------------> (80) |
|124.858 | TCP: boinc-client > http [RST, ACK] | Seq=265 Ack=2195035 Win=0 Len=0
| |(1043) ------------------> (80) |

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

70
|Time | 192.168.1.4 |
| | 192.168.1.2 |
|0.186 | TCP: timbuktu-srv3 > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1419) ------------------> (80) |
|0.188 | TCP: http > timbuktu-srv3 [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1419) <------------------ (80) |
|0.188 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1419) ------------------> (80) |
|0.194 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1419) ------------------> (80) |
|2.346 | TCP: timbuktu-srv3 > http [RST, ACK] | Seq=907 Ack=3661081 Win=0 Len=0
| |(1419) ------------------> (80) |
|2.348 | TCP: gandalf-lm > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1421) ------------------> (80) |
|2.349 | TCP: http > gandalf-lm [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1421) <------------------ (80) |
|2.352 | GET /WorldMap.jpg |HTTP: GET /WorldMap.jpg HTTP/1.1
| |(1421) ------------------> (80) |
|5.920 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1421) ------------------> (80) |
|127.776 | TCP: gandalf-lm > http [FIN, ACK] | Seq=1000 Ack=6103598 Win=65535 Len=0
| |(1421) ------------------> (80) |
|127.777 | TCP: http > gandalf-lm [FIN, ACK] | Seq=6103598 Ack=1001 Win=16521 Len=0
| |(1421) <------------------ (80) |

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

|Time | 192.168.1.3 |
| | 192.168.1.2 |
|22.561 | TCP: ff-annunc > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1089) ------------------> (80) |
|22.562 | TCP: http > ff-annunc [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1089) <------------------ (80) |
|22.598 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1089) ------------------> (80) |
|24.293 | TCP: ff-annunc > http [RST, ACK] | Seq=407 Ack=2240513 Win=0 Len=0
| |(1089) ------------------> (80) |
|25.157 | TCP: ff-sm > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1091) ------------------> (80) |
|25.323 | TCP: http > ff-sm [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1091) <------------------ (80) |
|25.323 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1091) ------------------> (80) |
|28.794 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1091) ------------------> (80) |
|151.589 | TCP: ff-sm > http [FIN, ACK] |Seq=958 Ack=3510148 Win=65098 Len=0
| |(1091) ------------------> (80) |
|151.590 | TCP: http > ff-sm [FIN, ACK] | Seq=3510148 Ack=959 Win=16563 Len=0
| |(1091) <------------------ (80) |

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

71
|Time | 192.168.1.4 |
| | 192.168.1.2 |
|0.198 | TCP: prm-sm-np > http [SYN] | Seq=0 Win=65535 Len=0 MSS=1460
| |(1402) ------------------> (80) |
|0.206 | TCP: http > prm-sm-np [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1402) <------------------ (80) |
|0.206 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1402) ------------------> (80) |
|0.212 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1402) ------------------> (80) |
|3.439 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1402) ------------------> (80) |
|4.043 | TCP: prm-sm-np > http [RST, ACK] | Seq=1409 Ack=2407071 Win=0 Len=0
| |(1402) ------------------> (80) |
|5.157 | TCP: igi-lm > http [SYN] |Seq=0 Win=65535 Len=0 MSS=1460
| |(1404) ------------------> (80) |
|5.417 | TCP: http > igi-lm [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
| |(1404) <------------------ (80) |
|5.418 | GET / HTTP/1.1 |HTTP: GET / HTTP/1.1
| |(1404) ------------------> (80) |
|5.936 | GET /htmlsample. |HTTP: GET /htmlsample.mpeg HTTP/1.1
| |(1404) ------------------> (80) |
|6.035 | GET /favicon.ico |HTTP: GET /favicon.ico HTTP/1.1
| |(1404) ------------------> (80) |
|128.609 | TCP: igi-lm > http [FIN, ACK] | Seq=1573 Ack=212834 Win=65535 Len=0
| |(1404) ------------------> (80) |
|128.610 | TCP: http > igi-lm [FIN, ACK] | Seq=212834 Ack=1574 Win=17520 Len=0
| |(1404) <------------------ (80) |
|

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

Shafi Kowsar Mohammad

Address: Hanverkaregatan 43, Karlskrona
E-mail: shafikowsar@gmail.com

Ravi Kumar Katta

Address: Hanverkaregatan 43, Karlskrona
E-mail: kravikumar13@gmail.com

University advisor:

Mr. Junaid Shaikh, Ph.D. Student

COM/BTH

School of Computing Internet: www.bth.se/com

Blekinge Institute of Technology Phone: +46 455 385000
371 79 KARLSKRONA SWEDEN SWEDEN
Abstract

Internet has dominated the modern communication and information ex-

change and it is growing enormously day by day. Initially it is designed to
offer various applications like World Wide Web (WWW), Electronic Mail
(E-Mail) and File Transfer (FTP). WWW has become very popular and
today Web traffic constitutes 70-80% in global Internet traffic. Web traffic
generates by the end users, when they request for a web page. The web page
transfers between various Web servers via different service networks to the
end users. Web traffic has become very significant in the present world and
the service providers have to offer 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 influences user satisfaction level, so QoS has
to ensure to promote better QoE.

User perceived QoE depends on page download time and it is an impor-

tant 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 difference between applica-
tion 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 coefficient of correlation.

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

correlation.

i
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
finished. 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 Shafi Kowsar
K Ravi Kumar

ii
Contents

Abstract i

Acknowledgements ii

Contents iii

List of Figures v

List of Tables vi

Introduction 1

1 Introduction 2
1.1 Quality of Service and Quality of Experience . . . . . . . . . 3
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . . 5

Background 6

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

Experiment Setup 12

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

iii
 3.1.2 Traffic Shaper: . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Measurement Area Controller (MArC): . . . . . . . . 14
3.1.4 Measurement Point: . . . . . . . . . . . . . . . . . . . 15
3.1.5 Consumer: . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.6 Users: . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Experiment Approach and Configuration: . . . . . . . . . . . 16
3.3 Process involved in the experiment: . . . . . . . . . . . . . . . 17
3.3.1 MArC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Traffic Shaper: . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Measurement Point (MP): . . . . . . . . . . . . . . . . 17
3.3.4 Consumer: . . . . . . . . . . . . . . . . . . . . . . . . 18

Results 19

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

Conclusions and Future Work 34

5 Conclusions and Future Work 35

5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Appendix 36

A Network Diagram 37

Bibliography 39

iv
List of Figures

1.1 Relation between QoE, QoS, User satisfaction and User actions. 4

2.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Transmission Control Protocol . . . . . . . . . . . . . . . . . 9

3.1 Experiment setup. . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Experiment setup design overview . . . . . . . . . . . . . . . 16

4.1 NW AVG DT for whole experiment . . . . . . . . . . . . . . . 23

4.2 APP AVG DT for whole experiment . . . . . . . . . . . . . . 23
4.3 Network and Application-level average download times for 0
ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Network and Application-level average download times for 75
ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5 Network and Application-level average download times for
150 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 Network and Application-level average download times for
235 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Network and Application-level average download times for
310 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.8 Average Network and Application download times for differ-
ent delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A.1 Experiment Configuration Network Diagram . . . . . . . . . 38

v
List of Tables

3.1 Web browsing sessions details . . . . . . . . . . . . . . . . . . 14

4.1 Calculated average download times for sessions . . . . . . . . 22

4.2 Calculated download times per page . . . . . . . . . . . . . . 29

vi
Introduction

1
Chapter 1

Introduction

Internet has become an essential part of todays communication and infor-

mation exchange. Internet traffic 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 traffic.
World Wide Web (WWW) technology has been widely used in various sec-
tors and Web traffic constitutes the major part of the Internet traffic. Web
traffic 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 different 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, significant work is going on to
study the Web traffic 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
efficiently 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-to-
end performance.
The network service providers should offer 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

2
CHAPTER 1. INTRODUCTION 3

describing the user perceived performance.

Network measurements are used to assess the performance of the net-
work and they have become very crucial in the course of evaluation and
analysis of the Internet traffic. The network service providers normally de-
ploy 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 traffic characteristics [3]. Per-
formance measurements can be carried out using two methods; they are
active and passive measurements. In active measurements, packets are in-
troduced into the network to measure one or more parameters. Examples -
ping trace-route etc. In passive measurements, the traffic is measured and
analyzed without injecting or disturbing any traffic in the network. Passive
measurements can be performed at different levels like packet level, TCP
level and application-level [6].
Both network service providers and end users use different approach to
evaluate the performance of the service. The network service providers anal-
yse 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 parame-
ters 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 mea-
sure 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 net-
work and it is difficult 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 ser-
vice providers is to define the end-to-end performance criteria and threshold
such that the measured performance ensures that the customers are satisfied
and the network works efficiently [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
traffic 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 4

QoS : Network
Performance

QoE : User
User Action
Experience

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 traffic 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 influence 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). Different trends of network delays are applied in different 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 5

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

6
Chapter 2

Background

Internet was initially designed to offer asynchronous applications such as

WWW, email and file transfer. It is necessary to understand and analyze
the network traffic which can be used to predict the traffic for future net-
works. Different experiments and measurements have been performed on
Internet traffic to understand the performance and to identify the traffic
characteristics. Estimation of network performance has become a challeng-
ing 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 traffic it is important to analyse the traffic.
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 traffic and it depends
on various underlying protocols in different layers. To study the Web traffic
characteristics, it is necessary to understand underlying protocols such as
Internet Protocol (IP) and Transmission Control Protocol (TCP). The fol-
lowing sections describe the functioning of these protocols and their header
formats.

2.1 Internet Protocol

In order to capture the Web traffic 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 fields of basic IP header.
The first field in the header represents the version of Internet Protocol
and in the present experiment we used IPV4 version. The second field gives
the length of the IP header and it will in 32 bit words. Type of service is
8 bit field and it species the treatment of datagram during its transmission.

7
CHAPTER 2. BACKGROUND 8

0 4 8 15 31
Version H Length Type of Service
Total Length (16 bits)
(4 bits) (4 bits) (8 bits)
D M Fragmentation Offset
Identification (16 bits) R
F F (13 bits)
20 Bytes

Time to Live
Protocol (8 bits) Header Checksum (16 bits)
(8 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 identification field which is used in the process of
assembling the fragments of a datagram. Identification will assign the value
for the datagram which is used for service precedence. The next field consists
of three flags. The flag R indicates that it is reserved. The flag DF represents
do not fragment and MF represents more fragments. Fragmentation offset
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 different from the response. The
protocol field indicates the higher layer which is TCP. Header checksum is
used for error checking. The other fields 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 trans-
fer 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 traffic [19]. Web brows-
ing 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 9

0 4 8 15 31

Source Port Number (16 bits) Destination Port Number (16 bits)

20 Bytes Sequence Number (32 bits)

Acknowledgement Number (32 bits)

ACK
H Length Reserved

PSH

SYN
URG

RST

FIN
Window Size (16 bits)
(4 bits) (6 bits)

TCP Checksum (16 bits) Urgent Pointer (16 bits)

TCP Options Variable Length ( If any ) Padding

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 fields. The filters 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 first two fields represents
the source and destination port numbers. The sequence number is the first
octet in the packet. If SYN flag is present then the sequence number is
called Initial sequence number (ISN) and the sequence number of first 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 flag
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 flags in the next field. URG indicates urgent pointer. ACK flag is
for acknowledgement. PSH represents push function. RST is for connection
reset. SYN flag is for synchronising the sequence numbers. FIN represents
no more data from the sender or end of data transmission from the sender.
The other fields 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 es-
tablishes connection using the sequence number and acknowledgement num-
ber 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 flags will be called which are responsible termina-
CHAPTER 2. BACKGROUND 10

tion of active connection or transfer. The captured packet traces consists of

various flags using which we can identify whether it is a request or reply. By
using various fields 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 perfor-
mance analysis of web browsing applications traffic. The objective of this
research is to map the download times of application-level traffic to network-
level traffic for web browsing applications and based on the results will cor-
relate them. The following section explains briefly about the relevant work
performed in this field.

2.3 Related Work

Extensive research has been done on Web traffic 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 per-
spective. In this [7] work the authors evaluated the effect of packet loss on
Web traffic characteristics. From the results, they correlate the packet loss
of Web traffic to user quality of experience. The authors performed pas-
sive measurement and evaluated the effect 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 pa-
rameters 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 traffic on application-level.
In [2] the Web traffic (HTTP) is collected using tcpdump from BTH access
network. The collected traffic is augmented using tcptrace for analysis. By
analyzing the application logs, the authors measured various properties of
HTTP traffic. The authors calculated inter-session arrival time, inter-arrival
time and request message size for various HTTP sessions and shown that
they influence the performance of web browsing application traffic. They
also suggested that Web server load and number of transactions within a
HTTP session will also influence the performance of the Web traffic.
In the past, research has been done in the field of video streaming ap-
plications in order to identify the traffic characteristics and performance.
A similar study has been made to correlate between the application-level
traffic and network-level traffic. 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
identified 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 traffic 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 traffic 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 effect of packet loss on TCP traffic.
The authors correlate packet loss with TCP traffic 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 traffic characteristics, various types of methods and ap-
proaches 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 effect 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 eval-
uation of Internet traffic. In the present knowledge there is no work which
maps the page download times of Web traffic at both application and network-
level. There is a gap between the application-level and network-level char-
acteristics on which this work is focused. Our research is a continuation of
previous work, which is performed on network-level for Web traffic. This
work describes the correlation between application and network-level per-
formance characteristics. This can be used as a measure to evaluate the
performance of the Web traffic.
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 traffic shaper. The shaper adds the
mentioned delay in the incoming traffic 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 application-
level 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 de-
scribed, 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

Input Delay to
Session No of Pages
Traffic Shaper (ms)
1 22 0
2.1 6 0
2.2 6 75
2.3 6 150
2.4 6 310
3.1 6 235
3.2 6 150
3.3 6 75
3.4 6 0
4.1 6 75
4.2 6 150
4.3 6 75
4.4 6 235

3.1.2 Traffic 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 param-
eters. We have used NetEM [24], an emulator that inserts desired delay
during the transmission of the packets. The delays are applied at different
levels such that we can study the behaviour of the packets at various levels.
The different 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 compo-
nent 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 filters[1]. The ex-
periment 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 traffic 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 net-
work 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 traffic on high-speed networks.
The DAG card has also port to provide time stamp and clock synchroniza-
tion. 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 filters which are controlled by Measure-
ment 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
filters provided or the format specified by the user. The captured traces
from the consumer are stored in a file 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 Measurement Experiment Controller (or)

Traffic Shaper Point 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 Configuration:

The main aim of this experiment set up is to capture the Web traffic traces at
network-level, which can be used to calculate the download time at network-
level. These download times will be compared to that of download times
measured at application-level. The following paragraphs describe the pro-
cess involved in this experiment.
The user machine and the Web server are connected to the same net-
work 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 different users. This experiment is
repeated one after the other with different users. All the users are students
with telecommunication background. We applied different levels of delays
at different 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 different groups of sessions.
Each session is sub divided into different 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 different levels of delays are applied. Session 2 delays are applied in in-
creasing 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 different 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 different fashions it is possible to study
the packet behaviour in both ways.

3.3 Process involved in the experiment:

3.3.1 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 experi-
ment the Web server has to run NTP service using which it acquires synchro-
nization 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 finally 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 Traffic 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 defined in advance. In
this experiment we assigned a maximum capture length of 512 bytes. Then
finally 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 filters
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 filtering. Consumer filters the captured data and provides
desired output based on the input parameters for further analysis [1]. The
filtering 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 filtered packets are
stored in a .cap file 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 traffic 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 traffic from Web server to the user and dag01
represents the packet flow from user to the Web server. To analyze these
traffic 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 filters the required information or values. To make the analysis easier
we divided the traces into two different files, 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 file contains the packet flow captured
from user to server direction. The server trace file contains the packets that
are captured in the direction from the server to the user. We are interested
in analysing the server trace file which provides us the information about
the traffic from server to the client at network-level. So we run the analysis
tool on server packet trace file. The analysis tool calculates the inter-arrival
time between each packet. Based on the inter arrival time and payload of the
packet, the trace file is divided into different files. So the total packet traces
are divided into 94 files corresponds to 94 web pages. Each file 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
first packet, inter-arrival time, link load and payload.
The experiment was conducted with 20 different users. Each user browsed
four different sessions which contains web pages with various delays that are
applied to the traffic 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
Session NW AVG DT (sec) APP AVG DT (sec)
Traffic Shaper (ms)
1 0 0.33 0.38
2.1 0 0.38 0.44
2.2 75 2.35 2.46
2.3 150 4.52 4.69
2.4 310 8.78 9.09
3.1 235 7.17 7.45
3.2 150 4.73 4.92
3.3 75 2.37 2.48
3.4 0 0.42 0.47
4.1 75 2.43 2.53
4.2 150 4.71 4.88
4.3 75 2.48 2.59
4.4 235 5.63 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 different amount of delays. The browsing period
of each user is divided into various sessions and each session is applied with
different amount of delays. The Table 4.1 has four columns. The first 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 different for different users.
As shown in the Table 4.1, there are about 34 pages for which no delay is
applied. These are placed in different sessions and the average download
time for each session is different. Similarly a network delay of 75 ms is
applied for 24 pages in 4 different sessions. They are 2.2, 3.3, 4.1 and 4.3.
The average download time in each session is slightly different 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 different
sessions. The next paragraph depicts the behaviour of the page download
time for different applied delays.
CHAPTER 4. RESULTS 23

14 Min NW DT
Avg NW DT
Max NW DT
12
Download Time [sec]

10

0
0 10 20 30 40 50 60 70 80 90
Page Number

Figure 4.1: NW AVG DT for whole experiment

14 Min APP DT
Avg APP DT
Max APP DT
12
Download Time [sec]

10

0
0 10 20 30 40 50 60 70 80 90
Page Number

Figure 4.2: APP AVG DT for whole experiment

CHAPTER 4. RESULTS 24

0.8
NW Avg DT
0.7 App Avg DT

0.6
Download Time [sec]

0.5

0.4

0.3

0.2

0.1

0
0 2 4 6 8 10 12 14 16 18 20
User

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 experi-
ment, 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 down-
load time for the entire experiment. From the figure the download time for
the first 28 pages is less as there is no delay is applied to the traffic 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 different users. While brows-
ing 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 difference 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 NW Avg DT
App Avg DT

3
Download Time [sec]

2.7

2.4

2.1

1.8

1.5
0 2 4 6 8 10 12 14 16 18 20
User

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

ms delay

6
NW Avg DT
APP Avg DT
5.5
Download Time [sec]

4.5

3.5

3
0 2 4 6 8 10 12 14 16 18 20
User

Figure 4.5: Network and Application-level average download times for 150
ms delay
CHAPTER 4. RESULTS 26

8
NW Avg DT
APP Avg DT
7.5
Download Time [sec]

6.5

5.5

5
0 2 4 6 8 10 12 14 16 18 20
User

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

12
NW Avg DT
APP Avg DT
11
Download Time [sec]

10

6
0 2 4 6 8 10 12 14 16 18 20
User

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 different 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 traffic shaper. Similarly the Figure
4.6 and Figure 4.7 shows the response of page download time for different
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 first
and second column represents the page number and session number. The
third is the delay that is applied using the traffic shaper. Fourth and fifth
columns are network-level average download time (NW AVG DT) and stan-
dard 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.
 Table 4.2: Calculated download times per page
Input Delay to
Page No Session NW AVG DT (sec) NW DT STD APP AVG DT (sec) APP DT STD
Traffic Shaper (ms)
1 1 0 0.35 0.126 0.43 0.19
2 1 0 0.37 0.023 0.41 0.03
3 1 0 0.34 0.026 0.40 0.027
4 1 0 0.31 0.007 0.37 0.009
5 1 0 0.32 0.008 0.37 0.007
6 1 0 0.31 0.014 0.36 0.011
CHAPTER 4. RESULTS

7 1 0 0.34 0.011 0.38 0.069

8 1 0 0.33 0.006 0.38 0.009
9 1 0 0.33 0.082 0.39 0.083
10 1 0 0.31 0.063 0.38 0.012
11 1 0 0.33 0.007 0.37 0.017
12 1 0 0.33 0.006 0.39 0.017
13 1 0 0.32 0.014 0.38 0.030
14 1 0 0.33 0.006 0.38 0.009
15 1 0 0.32 0.014 0.38 0.017
16 1 0 0.33 0.009 0.38 0.022
17 1 0 0.31 0.011 0.38 0.013
18 1 0 0.31 0.015 0.39 0.017
19 1 0 0.32 0.011 0.37 0.015
20 1 0 0.34 0.011 0.38 0.014
21 1 0 0.32 0.006 0.38 0.007
22 1 0 0.32 0.007 0.38 0.018
23 2.1 0 0.45 0.007 0.53 0.025
29

24 2.1 0 0.32 0.01 0.38 0.025

 Input Delay to
Page No Session NW AVG DT (sec) NW DT STD APP AVG DT (sec) APP DT STD
Traffic Shaper (ms)
25 2.1 0 0.33 0.011 0.37 0.014
26 2.1 0 0.34 0.011 0.38 0.018
27 2.1 0 0.32 0.007 0.37 0.006
28 2.1 0 0.55 0.938 0.60 0.946
29 2.2 75 2.08 0.373 2.18 0.377
30 2.2 75 2.41 0.253 2.52 0.255
31 2.2 75 2.54 0.226 2.63 0.239
CHAPTER 4. RESULTS

32 2.2 75 2.27 0.198 2.37 0.196

33 2.2 75 2.66 0.163 2.76 0.161
34 2.2 75 2.16 0.169 2.27 0.165
35 2.3 150 4.51 1.152 4.66 1.137
36 2.3 150 4.50 0.415 4.66 0.451
37 2.3 150 4.17 0.393 4.39 0.339
38 2.3 150 5.22 0.422 5.33 0.482
39 2.3 150 3.98 0.326 4.20 0.305
40 2.3 150 4.73 0.324 4.87 0.342
41 2.4 310 8.29 1.227 8.48 1.341
42 2.4 310 8.57 1.642 8.97 1.563
43 2.4 310 9.77 2.006 10.08 2.132
44 2.4 310 8.01 0.853 8.48 0.737
45 2.4 310 9.26 0.622 9.52 0.752
46 2.4 310 8.76 0.982 9.03 1.095
47 3.1 235 7.35 0.505 7.62 0.535
48 3.1 235 7.50 0.453 7.81 0.325
30
 Input Delay to
Page No Session NW AVG DT (sec) NW DT STD APP AVG DT (sec) APP DT STD
Traffic Shaper (ms)
49 3.1 235 6.77 0.879 7.06 0.840
50 3.1 235 6.99 0.489 7.29 0.443
51 3.1 235 7.23 0.318 7.50 0.308
52 3.1 235 7.19 0.443 7.43 0.446
53 3.2 150 5.05 0.452 5.30 0.363
54 3.2 150 4.46 0.407 4.64 0.406
55 3.2 150 4.50 0.216 4.68 0.216
56 3.2 150 4.49 0.194 4.66 0.195
57 3.2 150 4.80 1.146 4.98 1.141
CHAPTER 4. RESULTS

58 3.2 150 5.09 1.095 5.26 1.093

59 3.3 75 2.60 0.419 2.71 0.414
60 3.3 75 2.36 0.183 2.47 0.175
61 3.3 75 2.30 0.143 2.41 0.144
62 3.3 75 2.38 0.194 2.48 0.191
63 3.3 75 2.41 0.204 2.51 0.203
64 3.3 75 2.20 0.266 2.31 0.268
65 3.4 0 0.72 0.096 0.78 0.094
66 3.4 0 0.34 0.012 0.41 0.013
67 3.4 0 0.36 0.014 0.41 0.014
68 3.4 0 0.34 0.015 0.40 0.013
69 3.4 0 0.37 0.020 0.43 0.025
70 3.4 0 0.36 0.019 0.42 0.021
71 4.1 75 2.32 0.297 2.42 0.297
72 4.1 75 2.36 0.219 2.47 0.220
73 4.1 75 2.59 0.677 2.69 0.686
74 4.1 75 2.45 0.341 2.55 0.341
31

75 4.1 75 2.38 0.183 2.47 0.178

76 4.1 75 2.48 0.553 2.61 0.605
 Input Delay to
Page No Session NW AVG DT (sec) NW DT STD APP AVG DT (sec) APP DT STD
Traffic Shaper (ms)
77 4.2 150 4.37 0.575 4.55 0.573
78 4.2 150 4.84 0.571 5.01 0.574
79 4.2 150 4.56 0.664 4.69 0.604
80 4.2 150 5.05 0.348 5.22 0.347
CHAPTER 4. RESULTS

81 4.2 150 4.56 0.315 4.73 0.315

82 4.2 150 4.91 1.186 5.08 1.183
83 4.3 75 2.85 0.288 2.94 0.293
84 4.3 75 2.25 0.309 2.34 0.320
85 4.3 75 2.67 0.689 2.79 0.687
86 4.3 75 2.34 0.297 2.47 0.241
87 4.3 75 2.31 0.278 2.42 0.258
88 4.3 75 2.47 0.242 2.57 0.254
89 4.4 235 5.59 0.550 5.88 0.503
90 4.4 235 5.83 0.556 6.10 0.551
91 4.4 235 5.52 0.689 5.78 0.712
92 4.4 235 5.44 0.649 5.63 0.606
93 4.4 235 5.95 0.615 6.13 0.580
94 4.4 235 5.44 0.572 5.57 0.623
32
CHAPTER 4. RESULTS 28

10
NW AVG DT
9 APP AVG DT
8
page download time [sec]
7

0
0 75 150 225 300
Delay [ms]

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

4.3 Relation between network and application-level

download times:
To correlate the network and application-level download times, we per-
formed the experiment using different users and collected the packet traces
at network-level. In the basic analysis part we divided the packet traces into
different files based on different parameters such as source port, source IP
payload etc. Using this traces we calculated the network-level page down-
load 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 coefficient of correlation.

Table 4.3: Average download times of the experiment

Input Delay at NW AVG DT APP AVG DT
tavg (sec)
Traffic 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 net-
work and application-level for the mentioned network delays. The fourth
column is the difference 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 traffic shaper increases the difference between network and ap-
plication download times increases. The more the delay in the transmission
network the greater is the difference between application and network-level
download times. In real time networks, the Web traffic may experience
latency or delay during the transmission. Due to which the service per-
formance degrades. For the network providers, it is difficult 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 net-
work 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

0.05 sec for 0 ms applied delay

0.1 sec for 100 ms applied delay
where tavg =

0.2 sec for 200 ms applied delay


0.3 sec for 300 ms applied delay

Table 4.4: Relation between network and application download times

Regression Correlation Coeffcient 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 re-
gression is strong among the others with coefficient 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 effect of delay on page download times and investigated the correla-
tions 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 in-
creases, 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 coefficient of correlation. Using these expressions and
network-level download times, we can evaluate application perceived down-
load times. This relation can also be used as a measure for service providers
in computing the performance of the Web traffic.

5.2 Future Work

There are different key performance indicators which affects the performance
of the Web traffic. 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 influence the page response time.
Using this we can map both levels of traffic to find the relation between
them. These relations are very much useful for network providers to offer
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

eth-0 eth-0
eth-0 10.0.0.243 10.0.0.1
10.0.1.208 10.0.0.215

eth-2
eth-2 eth-1 B if-0 B if-1 194.47.148.77 External XPS
eth-1 Network
10.0.1.1

User Traffic Shaper

Measurement MArC
Point

Figure A.1: Experiment Configuration Network Diagram

Bibliography

[1] Patrik Arlos, Markus Fiedler, and Arne A. Nilsson. A distributed pas-
sive measurement infrastructure. In PAM2005, pages 215227, 2005.
[2] Yogesh Bhole and Adrian Popescu. Measurement and analysis of http
traffic. 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 back-
bone 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 traffic:
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 traffic characteristics. In Steve Uhlig, Konstantina Papa-
giannaki, 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-71617-
425.
[6] I. Din and N.A. Saqib. Passive packet loss detection and its effect
on web traffic 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 traffic charac-
teristics for estimating quality of experience. In GLOBECOM Work-
shops, 2008 IEEE, 30 2008.
[8] J. Garcia, P. Hurtig, and A. Brunstrom. The effect of packet loss on the
response times of web services. In Proceedings 3rd International Con-
ference 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
traffic 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 Li-
akopulos Martin Swany Steven Van den Berghe David Schmitz Mau-
rizio Molina, Andy Van Maele, editor. Deliverable DJ1.2.3 Network
Metric Report, Project GN2. 14.02.06, EC Contract No : 511082, Doc-
ument 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 expe-
rience from user and network perspectives. Annals of Telecommunica-
tions, 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; Verified November 2010] Available:.
http://www.endace.com/endace-dag-high-speed-packet-capture-
cards.html.
[18] Fasterfox. Performance and network tweaks for firefox
web browser, [Online; Verified November 2010] Available:.
http://fasterfox.mozdev.org/.
[19] Henrik Abrahamsson. Internet traffic management, Malardalen Univer-
sity, 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; Verified Novem-
ber 2010] Available:. http://www.perl.org.

[21] Meinberg : Solutions for Time and Frequency Synchronization. Mein-

berg ntp software, [Online; Verified November 2010] Available:.
http://www.meinberg.de/english/sw/ntp.htm.

[22] Mills, D. Network time protocol (version 3) specification, implementa-

tion, 1992.

[23] Mozilla Firefox Web Browser, [Online; Verified November 2010] Avail-
able:. http://www.mozilla-europe.org/en/firefox/.

[24] Netem Network Emulation. The linux founda-

tion, [Online; Verified November 2010] Available:.
http://www.linuxfoundation.org/collaborate/workgroups/netw-
-orking/netem.
Master Thesis
Electrical Engineering
Thesis no: MSE-2010-6977
November 2010

Energy Efficiency 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 fulfillment 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: chaitu415@gmail.com, ikkiran@aol.com

University advisor(s):

Mr. Junaid Junaid, Ph.d

School of Computer Science and Communications/BTH

School of Computing Internet: www.bth.se/com

Blekinge Institute of Technology Phone: +46 455 385000
371 79 KARLSKRONA SWEDEN SWEDEN
Abstract

Over the years, there has been an exponential increase in the capabilities
of networks, evolving from wired networks to wireless, and finally 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 file 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 de-
vices and subscribers. It becomes more clear that there will be rapid growth
in the demand for more energy-efficient mobile devices. However, due to
relatively slow increase in the battery technologies, the mobile users expec-
tations 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 difference in energy consumptions across various
browsing tasks and access technologies. Later, it involves a survey through
which critical observations with respect to power efficiency 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 affect 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 efficiency.

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

i
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 offer our sincere
thanks to all of our friends for their valuable contributions.

ii
Contents

Abstract i

Acknowledgment ii

Contents iii

List of Figures v

List of Tables vi

Introduction 1

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

Analysis 5

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

iii
 2.4 Battery Development . . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Customer Perspectives . . . . . . . . . . . . . . . . . . . . . . 9
2.6 QoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.1 QoE Factors . . . . . . . . . . . . . . . . . . . . . . . 9
2.6.2 User groups and Tasks . . . . . . . . . . . . . . . . . . 10

Implementation 12

3 Implementation 13
3.1 Experimental Setup . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Configuration and Settings . . . . . . . . . . . . . . . 13
3.1.2 Network Types . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Browsing Tasks . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Trial Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Parameters and Software Tools . . . . . . . . . . . . . . . . . 15
3.3.1 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2 Software Tools . . . . . . . . . . . . . . . . . . . . . . 17
3.4 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Results 21

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

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

Appendix 35

A Experments and Results Data 36

A.1 Survey Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2 Energy Consumptions . . . . . . . . . . . . . . . . . . . . . . 38
A.3 Discharge Curves . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliography 54

iv
List of Figures

3.1 Task Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.2 Charge/Discharge Curve . . . . . . . . . . . . . . . . . . . . . 17
3.3 BatteryMon . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4 BatteryMon Log File . . . . . . . . . . . . . . . . . . . . . . . 18
3.5 Imtec Battery Mark . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 BatteryCare . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Discharge Rate . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Idle Mode Energy Consumption . . . . . . . . . . . . . . . . . 23
4.3 Ethernet Energy Consumption . . . . . . . . . . . . . . . . . 24
4.4 Wi-Fi Energy Consumption . . . . . . . . . . . . . . . . . . . 25
4.5 3G Energy Consumption . . . . . . . . . . . . . . . . . . . . . 26
4.6 Browsing Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 Network Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.8 Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.9 Quality Parameters . . . . . . . . . . . . . . . . . . . . . . . . 29
4.10 Willingness . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.11 Browsing Time . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.12 Battery Backup . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.13 Battery Upgradation . . . . . . . . . . . . . . . . . . . . . . . 32

A.1 Discharge Rate (Ethernet) . . . . . . . . . . . . . . . . . . . . 51

A.2 Discharge Rate (Wi-Fi) . . . . . . . . . . . . . . . . . . . . . 52
A.3 Discharge Rate (3G) . . . . . . . . . . . . . . . . . . . . . . . 53

v
List of Tables

2.1 User Groups and tasks . . . . . . . . . . . . . . . . . . . . . . 11

3.1 Laptop Configuration . . . . . . . . . . . . . . . . . . . . . . 13

3.2 Types of Networks . . . . . . . . . . . . . . . . . . . . . . . . 14

4.1 Network Usage Vs User Preference . . . . . . . . . . . . . . . 29

4.2 Quality parameters . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Time spent on Browsing Vs Battery Backup . . . . . . . . . . 32

A.1 Network Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 37

A.2 Preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3 Quality Parameters . . . . . . . . . . . . . . . . . . . . . . . . 37
A.4 Willingness and Battery Upgradation . . . . . . . . . . . . . . 37
A.5 Browsing Time . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.6 Idle Mode: Ethernet . . . . . . . . . . . . . . . . . . . . . . . 39
A.7 Idle Mode: Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 39
A.8 Idle Mode:3G . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.9 Gmail:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 40
A.10 Gmail:Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.11 Gmail:3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.12 YouTube 720p:Ethernet . . . . . . . . . . . . . . . . . . . . . 42
A.13 YouTube 720p:Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . 42
A.14 YouTube 720p:3G . . . . . . . . . . . . . . . . . . . . . . . . 43
A.15 YouTube 360p:Ethernet . . . . . . . . . . . . . . . . . . . . . 43
A.16 YouTube 360p:Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . 44
A.17 YouTube 360p:3G . . . . . . . . . . . . . . . . . . . . . . . . 44
A.18 Game:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.19 Game:Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.20 Game:3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.21 Download:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . 46
A.22 Download:Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.23 Download:3G . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
A.24 Upload: Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.25 Upload: 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

vi
A.26 Upload:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 49

vii
Introduction

1
Chapter 1

Problem Identification

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 diversification in the types of services provided.
This diversification of services coupled with the diversification 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 different network con-
nections 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 3

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 inefficiency. To conclude, the article introduces some useful
information on networking choices and highlights few open research issues
in the selection of energy efficient future network architectures.

1.4 Research Questions

1. Is there any affect 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 affect and to
what degree?

3. Is there a variation in energy consumption with different tasks per-

formed 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 affect 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 ques-
tionnaire 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 firstly, to measure the energy consumptions
in laptop while using different 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 findings and to draw a few useful conclusions.
CHAPTER 1. PROBLEM IDENTIFICATION 4

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 different 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 ex-
plains the conditions and network environment under which the experimen-
tation 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 filed 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 different network
connection technologies.
Analysis

5
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 different energy
efficient 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 different 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 net-
work 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 7

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 offer 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 Efficient Technology Proposals

Since the battery technology has not been improved as much as the semicon-
ductor technology, power efficient 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 efficiency 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 traffic 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 efficient wireless topologies, network nodes, routers, and
protocols [7]. Initially, there were new and more energy efficient technology
proposals on the Ethernet [8, 9, 10]. While efforts were made to develop or
propose these energy efficient 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 significantly lower
[12]. There are two basic categories of methods to make Wi-Fi or other
high energy-consuming network interfaces more energy-conservative. The
first category of methods, modifies the Wi-Fi and/or upper layer protocols
to make the protocols themselves more energy-conservative [13, 14, 15]. A
CHAPTER 2. RELATED STUDY 8

survey of energy-efficient 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 off 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 traffic [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 efforts made to develop energy efficient technolo-
gies, parallel efforts 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 po-
tential and also provides the largest energy density per weight. Therefore
Li-ion is rapidly growing and has proved to be most promising battery chem-
istry. 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 specific satisfactory levels to be met. As the current capac-
ities 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 9

batteries seem to be meeting the performance challenge of some power prod-

ucts, so the maximum we can ask of competitive chemistries is equivalent
power densities at reasonable and comparable costs.

Cost
The cost effectiveness, 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 broad-
band subscriptions and 7.1 % are of fixed broadband subscriptions [17].
This shows the potential of mobile internet which has overtaken the fixed
broadband subscriptions. But, according to a global study [18] conducted
by Nokia Siemens networks mobile broadband, users are up to 22% less
satisfied with the connectivity when compared to fixed broadband users.
There are many services that are available through the Internet regard-
less 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 specific 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 fixed broadband because mobile
broadband provides greater mobility. Taking network technologies into ac-
count 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 defined 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 different 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 fixed 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 affected 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 re-
ceived [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 fixed broadband users due to many factors such as slower web-
page 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
effects of loss on the perceived QoS [23]. As a result, comparing the energy
consumptions of same quality videos on different 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 Office All Tasks
Users.
Wi-Fi Laptop/Portable All Tasks
device Users
3G Travelers, Mobile Gmail, Light
Users Browsing

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 flip 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 offering speeds greater than 6 Mbps, only a few
can afford the pricing. And with the combination of lower data capacities
and higher pricing (compared to fixed broadband) it would repel even those
who could afford it.
For a majority of the Internet users, tasks range from emailing, on-
line shopping to watching on-line videos and transferring large files. But,
when compared to on-line shopping and emailing, tasks such as watching
YouTube videos or file hosting/sharing websites require more bandwidth
and data capacities for better performance. So, for heavy internet usage,
having a fixed broadband connection would be more sensible.The quality of
video and the size of a file also plays an important role.
Implementation

12
Chapter 3

Implementation

3.1 Experimental Setup

3.1.1 Configuration and Settings

Table 3.1: Configuration of Packard Bell-EasyNote TJ75

Component Specifications
Processor Intel Core i5 @ 2.27 GHz
Internal Memory 4 GB RAM
Operating System Windows 7, 64-bit
Wireless Network Adapter Atheros AR5B93
Ethernet Card Broadcom Gigabit
Battery Chemical Composition
Li-ion, Model Panasonic
AS09A51, Capacity=48600
mWh

For this experiment, Packard Bell-EasyNote TJ75 was used with spe-
cific processing and networking configurations as mentioned in Table 3.1.
Therefore, the energy consumptions of the tasks are specific to these spe-
cific configurations and settings. It should be noted that the experiment was
conducted on a new laptop which eliminates any negative effects 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 bat-
tery 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 ex-
perimentation. 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 sub-
scribed Huawei Technologies Co., Ltd. E220 HSDPA USB Modem modem
was used.

Table 3.2: Types of networks and corresponding ISPs with network speeds
Network Type ISP Speed
Ethernet BAHNHOF AB, Downlink: 95 Mbps and Up-
SUNET/NORDUnet link: 24 Mbps
Wi-Fi BAHNHOF AB, Downlink: 10 Mbps and Up-
SUNET/NORDUnet link: 9 Mbps
3G Telenor Downlink:2 - 5 Mbps and Up-
link: 0.35 Mbps

3.1.3 Browsing Tasks

The tasks selected for this experiment were chosen based on certain cri-
terion. 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 file sharing
website www.mediafire.com[26]. For email browsing Gmail [27] was used
and finally 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 con-
ducting the browsing tasks. Only the battery tools and OS applica-
tions 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 first 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 file for the given duration and stop.

7. Upload: Paste the link in the address bar and press enter, upload the
file for the given duration and stop.

3.2 Trial Flowchart

From the figure 3.1, colored part of the flow chart indicates the part of
trial where the task is being performed. It can be seen that all tasks were
performed for a fixed 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 Parameters and Software Tools

3.3.1 Parameters
The following parameters were analyzed in the experimentation to under-
stand the effect of the tasks on the energy consumption through different
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 files 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 fixed 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 file. Num Samples indicates the number of sample measurements
being registered into the log file. For every second, each set of values will
be registered into the designated log file.
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 file with the information from this software can be seen in Fig 3.6.
CHAPTER 3. IMPLEMENTATION 20

Speed Test
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 effect 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 consump-
tions for particular tasks for a particular interface by importing the raw data
from the log files 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 proffesions 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 brows-

ing.

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

tery?
Results

21
Chapter 4

Results

4.1 Introduction
The results from the experiments conducted are discussed and analyzed in
this chapter. Energy consumption using different 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 Energy Consumption Comparison - Time Based

4.2.1 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 net-
works. 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 difference in the usage. This can be observed from the fig 4.2. If turning
ON of the network interface (without using it) had no effect on the energy
consumption in the idle state, the discharges rates should have been similar
in all cases. Hence our first 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 fig 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 com-
pared for each network connection type.

Ethernet
From Fig 4.3, it may be observed that the YouTube 720p task is the high-
est 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 figure 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 gam-
ing. 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 figures 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 dis-
charge of the battery. The least energy consumption state with each inter-
face 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 figure 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 rang-
ing 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 connectiv-
ity.

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 finding 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
offer.
A comparison between current usage and network preferences can be ob-
served 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 difference
between usage and preference which indicates the demand of a network type.

Table 4.1: Comparison of Network Usage and User Preference

Network % Usage % Preference % Change
Ethernet 85.71% 68.25% 17.4% decrease
Wi-Fi 96.83% 88.89% 7.9% decrease
3G 44.44% 65.08% 20.6% increase

Quality Parameters
From Fig 4.9, it has also been found from the survey that speed and avail-
ability 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 finding 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 effect of various network types on
the energy consumption in laptops. The behavior of the battery is studied
and analyzed in various scenarios including different 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 consump-
tion 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 connec-
tions. 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 net-
works and correlating with survey results based on basic QoE questions.
Future scope could be more specific where different protocols from all the
layers of OSI model could be compared to find out energy efficient protocols.
The study can be extended to protocol levels and component level analysis.

The experiments may be conducted in an environment, where the mea-

surements 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 difference 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

Table A.1: Network Usage

Network Usage Never Occasionally Frequently Always
Ethernet 8 30 13 11
Wi-Fi 2 4 14 43
3G 26 20 4 4

Table A.2: Preference

Preference Never Occasionally Frequently Always
Ethernet 7 21 13 12
Wi-Fi 0 3 12 46
3G 12 20 12 9

Table A.3: Quality Parameters

Parameter NOT IMP LEAST IMP IMP V IMP
Speed 1 1 17 43
Availability 0 7 18 37
Ease of Access 7 10 17 29
Cost 12 10 21 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

Table A.6: Idle Mode: Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48454.2 45781.2 2673 1.44 86.4
Trial2 48114 45392.4 2721.6 1.43 85.8
Trial3 48308.4 45586.8 2721.6 1.44 86.4
Trial4 48600 45878.4 2721.6 1.43 85.8
Trial5 48600 45878.4 2721.6 1.45 87
Trial6 48308.4 45586.8 2721.6 1.44 86.4
Trial7 48454.2 45781.2 2673 1.44 86.4
Trial8 48600 45878.4 2721.6 1.43 85.8
Trial9 48357 45635.4 2721.6 1.45 87
Trial10 48600 45878.4 2721.6 1.43 85.8
Trial11 48454.2 45781.2 2673 1.44 86.4
Trial12 48114 45392.4 2721.6 1.43 85.8
Trial 13 48600 45878.4 2721.6 1.43 85.8
Trial14 48308.4 45586.8 2721.6 1.44 86.4
Trial15 48600 45878.4 2721.6 1.45 87
AVG 48431.52 45720 2711.88 1.438 86.28
STD DEV 174.1351987 176.6363 20.12231171 0.007746 0.464758002

Table A.7: Idle Mode: Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48600 45878.4 2721.6 1.41 84.6
Trial2 47968.2 45246.6 2721.6 1.46 87.6
Trial3 48600 45927 2673 1.42 85.2
Trial4 47968.2 45149.4 2818.8 1.4 84
Trial5 47968.2 45198 2770.2 1.4 84
Trial6 48357 45635.4 2721.6 1.41 84.6
Trial7 48600 45927 2673 1.42 85.2
Trial8 47968.2 45246.6 2721.6 1.46 87.6
Trial9 47968.2 45149.4 2818.8 1.4 84
Trial10 47968.2 45198 2770.2 1.4 84
Trial11 48600 45878.4 2721.6 1.41 84.6
Trial12 47968.2 45149.4 2818.8 1.4 84
Trial13 48600 45927 2673 1.42 85.2
Trial14 47968.2 45246.6 2721.6 1.46 87.6
Trial15 47968.2 45198 2770.2 1.4 84
AVG 48205 45463.68 2741 1.418 85.08
STD DEV 305.648723 345.0583702 51.30203 0.023052735 1.383164
APPENDIX A. EXPERMENTS AND RESULTS DATA 40

Table A.8: Idle Mode:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48065.4 45198 2867.4 1.37 82.2
Trial2 48600 45684 2916 1.35 81
Trial3 48600 45829.8 2770.2 1.39 83.4
Trial4 48114 45295.2 2818.8 1.39 83.4
Trial5 47919.6 45052.2 2867.4 1.36 81.6
Trial6 48357 45441 2916 1.35 81
Trial7 48065.4 45198 2867.4 1.37 82.2
Trial8 48600 45829.8 2770.2 1.39 83.4
Trial9 48114 45295.2 2818.8 1.39 83.4
Trial10 47919.6 45052.2 2867.4 1.36 81.6
Trial11 48065.4 45198 2867.4 1.37 82.2
Trial12 47919.6 45052.2 2867.4 1.36 81.6
Trial13 48600 45829.8 2770.2 1.39 83.4
Trial14 48114 45295.2 2818.8 1.39 83.4
Trial15 48551.4 45635.4 2916 1.35 81
AVG 48240 45392.4 2848 1.372 82.32
STD DEV 277.245247 293.9051742 51.30203 0.016561573 1.073313

Table A.9: Gmail:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48357 45586.8 2770.2 1.42 85.2
Trial2 48600 45586.8 3013.2 1.43 85.8
Trial3 48016.8 45246.6 2770.2 1.42 85.2
Trial4 48162.6 45343.8 2818.8 1.4 84
Trial5 48259.8 45489.6 2770.2 1.39 83.4
Trial6 48551.4 45538.2 3013.2 1.43 85.8
Trial7 48357 45586.8 2770.2 1.42 85.2
Trial8 48016.8 45246.6 2770.2 1.42 85.2
Trial9 48162.6 45343.8 2818.8 1.4 84
Trial10 48259.8 45489.6 2770.2 1.39 83.4
Trial11 48405.6 45635.4 2770.2 1.42 85.2
Trial12 48551.4 45538.2 3013.2 1.43 85.8
Trial13 48016.8 45246.6 2770.2 1.42 85.2
Trial14 48162.6 45343.8 2818.8 1.4 84
Trial15 48259.8 45489.6 2770.2 1.39 83.4
AVG 48276 45447.48 2828.5 1.412 84.72
STD DEV 194.110499 138.521165 97.546525 0.015212777 0.912767
APPENDIX A. EXPERMENTS AND RESULTS DATA 41

Table A.10: Gmail:Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48357 45538.2 2818.8 1.41 84.6
Trial2 48016.8 45246.6 2770.2 1.42 85.2
Trial3 48259.8 45489.6 2770.2 1.41 84.6
Trial4 48114 45343.8 2770.2 1.4 84
Trial5 48357 45538.2 2818.8 1.39 83.4
Trial6 48308.4 45489.6 2818.8 1.41 84.6
Trial7 48259.8 45489.6 2770.2 1.42 85.2
Trial8 48016.8 45246.6 2770.2 1.41 84.6
Trial9 48357 45538.2 2818.8 1.39 83.4
Trial10 48114 45343.8 2770.2 1.4 84
Trial11 48357 45538.2 2818.8 1.41 84.6
Trial12 48016.8 45246.6 2770.2 1.42 85.2
Trial13 48357 45538.2 2818.8 1.39 83.4
Trial14 48114 45343.8 2770.2 1.4 84
Trial15 48357 45586.8 2770.2 1.41 84.6
AVG 48224 45434.52 2789.6 1.406 84.36
STD DEV 141.652436 124.404428 24.644698 0.010555973 0.633358

Table A.11: Gmail:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 47871 44906.4 2964.6 1.33 79.8
Trial2 48600 45343.8 3256.2 1.32 79.2
Trial3 48065.4 45149.4 2916 1.34 80.4
Trial4 48551.4 45295.2 3256.2 1.33 79.2
Trial5 47871 44906.4 2964.6 1.32 79.8
Trial6 47871 44906.4 2964.6 1.33 79.8
Trial7 48065.4 45149.4 2916 1.34 80.4
Trial8 48600 45343.8 3256.2 1.32 79.2
Trial9 48016.8 45100.8 2916 1.33 79.8
AVG 48168 45122.4 3045.6 1.328889 79.73
STD DEV 321.866727 183.6397016 159.34576 0.00781736 0.469042
APPENDIX A. EXPERMENTS AND RESULTS DATA 42

Table A.12: YouTube 720:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48357 45392.4 2964.6 1.32 79.2
Trial2 47968.2 45003.6 2964.6 1.31 78.6
Trial3 48357 45343.8 3013.2 1.31 78.6
Trial4 48114 45149.4 2964.6 1.31 78.6
Trial5 48065.4 45100.8 2964.6 1.31 78.6
Trial6 48308.4 45343.8 2964.6 1.32 78.6
Trial7 47968.2 45003.6 2964.6 1.31 78.6
Trial8 48162.6 45198 2964.6 1.31 78.6
Trial9 48357 45343.8 3013.2 1.31 78.6
Trial10 48065.4 45100.8 2964.6 1.31 78.6
Trial11 48357 45392.4 2964.6 1.32 79.2
Trial12 47968.2 45003.6 2964.6 1.31 78.6
Trial13 48357 45343.8 3013.2 1.31 78.6
Trial14 48065.4 45100.8 2964.6 1.31 78.6
Trial15 48114 45149.4 2964.6 1.31 78.6
AVG 48172 45198 2974.3 1.312 78.68
STD DEV 159.292809 148.0962043 20.122312 0.004140393 0.211119

Table A.13: YouTube 720:Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48114 45100.8 3013.2 1.28 76.8
Trial2 48065.4 45052.2 3013.2 1.32 79.2
Trial3 48600 45489.6 3110.4 1.27 76.2
Trial4 47919.6 44906.4 3013.2 1.3 78
Trial5 48600 45538.2 3061.8 1.27 76.2
Trial6 48551.4 45441 3110.4 1.27 76.2
Trial7 48065.4 45052.2 3013.2 1.32 79.2
Trial8 48114 45100.8 3013.2 1.28 76.8
Trial9 47919.6 44906.4 3013.2 1.3 78
Trial10 48600 45538.2 3061.8 1.27 76.2
Trial11 48114 45100.8 3013.2 1.28 76.8
Trial12 48065.4 45052.2 3013.2 1.32 79.2
Trial13 48600 45489.6 3110.4 1.27 76.2
Trial14 48551.4 45489.6 3061.8 1.27 76.2
Trial15 47919.6 44906.4 3013.2 1.3 78
AVG 48253 45210.96 3042.4 1.288 77.28
STD DEV 287.44323 252.1764484 40.244623 0.020071301 1.204278
APPENDIX A. EXPERMENTS AND RESULTS DATA 43

Table A.14: YouTube 720p:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 47919.6 44712 3207.6 1.26 75.6
Trial2 48308.4 45149.4 3159 1.25 75
Trial3 48065.4 44906.4 3159 1.24 74.4
Trial4 48308.4 45198 3110.4 1.26 75.6
Trial5 47968.2 44906.4 3061.8 1.28 76.8
Trial6 48016.8 44857.8 3159 1.24 74.4
Trial7 48308.4 45149.4 3159 1.25 75
Trial8 47919.6 44712 3207.6 1.26 75.6
Trial9 48308.4 45198 3110.4 1.26 75.6
Trial10 47968.2 44906.4 3061.8 1.28 76.8
Trial11 47919.6 44712 3207.6 1.26 75.6
Trial12 48308.4 45149.4 3159 1.25 75
Trial13 47968.2 44906.4 3061.8 1.28 76.8
Trial14 48308.4 45198 3110.4 1.26 75.6
Trial15 48114 44955 3159 1.24 74.4
AVG 48114 44974.44 3139.6 1.258 75.48
STD DEV 172.317183 185.3365772 51.30203 0.013732131 0.823928

Table A.15: YouTube 360p:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48308.4 45392.4 2916 1.35 81
Trial2 47919.6 45003.6 2916 1.33 79.8
Trial3 48259.8 45343.8 2916 1.34 80.4
Trial4 48308.4 45295.2 3013.2 1.32 79.2
Trial5 48114 45149.4 2964.6 1.34 80.4
Trial6 48259.8 45343.8 2916 1.34 80.4
Trial7 47919.6 45003.6 2916 1.33 79.8
Trial8 48357 45441 2916 1.35 81
Trial9 48308.4 45295.2 3013.2 1.32 79.2
Trial10 48114 45149.4 2964.6 1.34 80.4
Trial11 48308.4 45392.4 2916 1.35 81
Trial12 48308.4 45295.2 3013.2 1.32 79.2
Trial13 48259.8 45343.8 2916 1.34 80.4
Trial14 47968.2 45052.2 2916 1.33 79.8
Trial15 48114 45149.4 2964.6 1.34 80.4
AVG 48189 45243.36 2945.2 1.336 80.16
STD DEV 152.437487 146.3390037 40.244623 0.010556 0.633358
APPENDIX A. EXPERMENTS AND RESULTS DATA 44

Table A.16: YouTube 360p:Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48308.4 45343.8 2964.6 1.31 78.6
Trial2 48308.4 45343.8 2964.6 1.35 81
Trial3 48357 45586.8 2770.2 1.34 80.4
Trial4 48600 45586.8 3013.2 1.32 79.2
Trial5 48357 45295.2 3061.8 1.33 79.8
Trial6 48502.8 45489.6 3013.2 1.32 79.2
Trial7 48308.4 45343.8 2964.6 1.35 81
Trial8 48357 45586.8 2770.2 1.34 80.4
Trial9 48308.4 45343.8 2964.6 1.31 78.6
Trial10 48357 45295.2 3061.8 1.33 79.8
Trial11 48308.4 45343.8 2964.6 1.31 78.6
Trial12 48308.4 45343.8 2964.6 1.35 81
Trial13 48551.4 45538.2 3013.2 1.32 79.2
Trial14 48357 45586.8 2770.2 1.34 80.4
Trial15 48357 45295.2 3061.8 1.33 79.8
AVG 48376 45421.56 2954.9 1.33 79.8
STD DEV 95.0943351 122.9493554 102.60406 0.0146385 0.87831

Table A.17: YouTube 360p:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48065.4 45052.2 3013.2 1.27 76.2
Trial2 48357 45198 3159 1.25 75
Trial3 48600 45489.6 3110.4 1.28 76.8
Trial4 48016.8 44857.8 3159 1.23 73.8
Trial5 47968.2 44906.4 3061.8 1.27 76.2
Trial6 48551.4 45441 3110.4 1.28 76.8
Trial7 48357 45198 3159 1.25 75
Trial8 48016.8 44857.8 3159 1.23 73.8
Trial9 48065.4 45052.2 3013.2 1.27 76.2
Trial10 47968.2 44906.4 3061.8 1.27 76.2
Trial11 48016.8 44857.8 3159 1.23 73.8
Trial12 48357 45198 3159 1.25 75
Trial13 48600 45489.6 3110.4 1.28 76.8
Trial14 48065.4 45052.2 3013.2 1.27 76.2
Trial15 47968.2 44906.4 3061.8 1.27 76.2
AVG 48198 45097.56 3100.7 1.26 75.6
STD DEV 244.016161 230.5056454 58.666116 0.0185164 1.110984
APPENDIX A. EXPERMENTS AND RESULTS DATA 45

Table A.18: Game:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48357 45489.6 2867.4 1.35 81
Trial2 47919.6 45003.6 2916 1.32 79.2
Trial3 48308.4 45343.8 2964.6 1.31 78.6
Trial4 48162.6 45295.2 2867.4 1.35 81
Trial5 48162.6 45246.6 2916 1.35 81
Trial6 48357 45489.6 2867.4 1.35 81
Trial7 47919.6 45003.6 2916 1.32 79.2
Trial8 48308.4 45343.8 2964.6 1.31 78.6
Trial9 48162.6 45246.6 2916 1.35 81
Trial10 48114 45246.6 2867.4 1.34 80.4
Trial11 48357 45489.6 2867.4 1.35 81
Trial12 47919.6 45003.6 2916 1.32 79.2
Trial13 48211.2 45295.2 2916 1.35 81
Trial14 48162.6 45295.2 2867.4 1.35 81
Trial15 48308.4 45343.8 2964.6 1.31 78.6
AVG 48182 45275.76 2906.3 1.3353 80.12
STD DEV 158.868593 164.0924861 37.645398 0.0176743 1.060458

Table A.19: Game:Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48259.8 45295.2 2964.6 1.31 78.6
Trial2 48357 45343.8 3013.2 1.34 78
Trial3 48211.2 45343.8 2867.4 1.3 80.4
Trial4 48357 45392.4 2964.6 1.3 78
Trial5 48162.6 45246.6 2916 1.32 79.2
Trial6 48259.8 45295.2 2964.6 1.31 78.6
Trial7 48308.4 45295.2 3013.2 1.3 78
Trial8 48211.2 45343.8 2867.4 1.34 80.4
Trial9 48357 45392.4 2964.6 1.3 78
Trial10 48162.6 45246.6 2916 1.32 79.2
Trial11 48259.8 45295.2 2964.6 1.31 78.6
Trial12 48211.2 45343.8 2867.4 1.34 80.4
Trial13 48357 45392.4 2964.6 1.3 78
Trial14 48357 45343.8 3013.2 1.3 78
Trial15 48162.6 45246.6 2916 1.32 79.2
AVG 48266 45321.12 2945.2 1.314 78.84
STD DEV 77.6441995 51.52080301 51.30203 0.0154919 0.929516
APPENDIX A. EXPERMENTS AND RESULTS DATA 46

Table A.20: Game:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48259.8 45100.8 3159 1.25 75
Trial2 47968.2 44955 3013.2 1.26 75.6
Trial3 48259.8 45100.8 3159 1.25 75
Trial4 48065.4 45003.6 3061.8 1.28 76.8
Trial5 47968.2 45003.6 2964.6 1.27 76.2
Trial6 48308.4 45149.4 3159 1.25 75
Trial7 48259.8 45100.8 3159 1.25 75
Trial8 47919.6 44906.4 3013.2 1.26 75.6
Trial9 48065.4 45003.6 3061.8 1.28 76.8
Trial10 47968.2 45003.6 2964.6 1.27 76.2
Trial11 48259.8 45100.8 3159 1.25 75
Trial12 47968.2 44955 3013.2 1.26 75.6
Trial13 47968.2 45003.6 2964.6 1.27 76.2
Trial14 48065.4 45003.6 3061.8 1.28 76.8
Trial15 48259.8 45100.8 3159 1.25 75
AVG 48104 45032.76 3071.5 1.262 75.72
STD DEV 144.871328 70.6672363 80.489247 0.0120712 0.724273

Table A.21: Download:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48114 45392.4 2721.6 1.42 85.2
Trial2 48016.8 45246.6 2770.2 1.43 85.8
Trial3 48016.8 45198 2818.8 1.39 83.4
Trial4 48162.6 45392.4 2770.2 1.44 86.4
Trial5 48211.2 45489.6 2721.6 1.41 84.6
Trial6 48016.8 45198 2818.8 1.39 83.4
Trial7 48211.2 45489.6 2721.6 1.41 84.6
Trial8 48114 45392.4 2721.6 1.42 85.2
Trial9 48162.6 45392.4 2770.2 1.44 86.4
Trial10 48016.8 45246.6 2770.2 1.43 85.8
Trial11 48162.6 45392.4 2770.2 1.44 86.4
Trial12 48211.2 45489.6 2721.6 1.41 84.6
Trial13 48016.8 45198 2818.8 1.39 83.4
Trial14 48114 45392.4 2721.6 1.42 85.2
Trial15 48016.8 45246.6 2770.2 1.43 85.8
AVG 48104 45343.8 2760.48 1.418 85.08
STD DEV 80.4892468 110.2144403 37.6453981 0.0178085 1.06851
APPENDIX A. EXPERMENTS AND RESULTS DATA 47

Table A.22: Download:Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48308.4 45489.6 2818.8 1.38 82.8
Trial2 47968.2 45684 2284.2 1.42 85.2
Trial3 48016.8 45198 2818.8 1.38 82.8
Trial4 48114 45246.6 2867.4 1.39 83.4
Trial5 47919.6 45003.6 2916 1.37 82.2
Trial6 48308.4 45489.6 2818.8 1.38 82.8
Trial7 48016.8 45198 2818.8 1.42 85.2
Trial8 47871 44955 2916 1.37 82.2
Trial9 48114 45246.6 2867.4 1.39 83.4
Trial10 47968.2 45684 2284.2 1.38 82.8
Trial11 48308.4 45489.6 2818.8 1.38 82.8
Trial12 48016.8 45198 2818.8 1.42 85.2
Trial13 47968.2 45684 2284.2 1.38 82.8
Trial14 48162.6 45295.2 2867.4 1.39 83.4
Trial15 47919.6 45003.6 2916 1.37 82.2
AVG 48065 45324.36 2741.04 1.388 83.28
STD DEV 148.096204 249.7113213 239.362489 0.0178085 1.06851

Table A.23: Download:3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial1 48600 45586.8 3013.2 1.3 78
Trial2 48016.8 45003.6 3013.2 1.3 78
Trial3 48065.4 45052.2 3013.2 1.3 78
Trial4 48114 45052.2 3061.8 1.32 79.2
Trial5 47919.6 44955 2964.6 1.3 78
Trial6 48551.4 45538.2 3013.2 1.3 78
Trial7 48016.8 45003.6 3013.2 1.3 78
Trial8 48114 45052.2 3061.8 1.32 79.2
Trial9 48065.4 45052.2 3013.2 1.3 78
Trial10 47919.6 44955 2964.6 1.3 78
Trial11 47919.6 44955 2964.6 1.3 78
Trial12 48016.8 45003.6 3013.2 1.3 78
Trial13 48016.8 45003.6 3013.2 1.3 78
Trial14 48114 45052.2 3061.8 1.32 79.2
Trial15 48600 45586.8 3013.2 1.3 78
AVG 48137 45123.48 3013.2 1.304 78.24
STD DEV 240.814746 234.4246915 31.8161684 0.0082808 0.496847
APPENDIX A. EXPERMENTS AND RESULTS DATA 48

Table A.24: Upload: Wi-Fi

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial 1 48357 45489.6 2867.4 1.39 83.4
Trial 2 48114 45246.6 2867.4 1.4 84
Trial 3 47968.2 45052.2 2916 1.35 81
Trial 4 48259.8 45392.4 2867.4 1.34 80.4
Trial 5 47919.6 45003.6 2916 1.35 81
Trial 6 47919.6 45003.6 2916 1.35 81
Trial 7 48114 45246.6 2867.4 1.4 84
Trial 8 48357 45489.6 2867.4 1.39 83.4
Trial 9 48259.8 45392.4 2867.4 1.34 80.4
Trial 10 47919.6 45003.6 2916 1.35 81
Trial 11 48357 45489.6 2867.4 1.39 83.4
Trial 12 48259.8 45392.4 2867.4 1.34 80.4
Trial 13 47968.2 45052.2 2916 1.35 81
Trial 14 48162.6 45295.2 2867.4 1.4 84
Trial 15 47919.6 45003.6 2916 1.35 81
avg 48124 45236.88 2886.84 1.366 81.96
std dev 176.381369 198.8616576 24.6446981 0.0250143 1.500857

Table A.25: Upload: 3G

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial 1 48065.4 45003.6 3061.8 1.29 77.4
Trial 2 48162.6 45100.8 3061.8 1.29 77.4
Trial 3 48600 45295.2 3304.8 1.31 78.6
Trial 4 48114 45052.2 3061.8 1.33 79.8
Trial 5 48065.4 45003.6 3061.8 1.29 77.4
Trial 6 47968.2 45003.6 2964.6 1.31 78.6
Trial 7 48162.6 45100.8 3061.8 1.29 77.4
Trial 8 48551.4 45246.6 3304.8 1.31 78.6
Trial 9 48114 45052.2 3061.8 1.33 79.8
Trial 10 47968.2 45003.6 2964.6 1.31 78.6
Trial 11 48065.4 45003.6 3061.8 1.29 77.4
Trial 12 48211.2 45149.4 3061.8 1.29 77.4
Trial 13 47968.2 45003.6 2964.6 1.31 78.6
Trial 14 48114 45052.2 3061.8 1.33 79.8
Trial 15 48600 45295.2 3304.8 1.31 78.6
avg 48182 45091.08 3090.96 1.306 78.36
std dev 220.275752 107.4237484 117.332232 0.0154919 0.929516
APPENDIX A. EXPERMENTS AND RESULTS DATA 49

Table A.26: Upload:Ethernet

Trial.No Initial Final Difference Remaining Remaining
Capacity(mWh) Capacity(mWh) (mWh) Time(Hrs) Time(Mins)
Trial 1 48162.6 45392.4 2770.2 1.42 85.2
Trial 2 47968.2 45149.4 2818.8 1.42 85.2
Trial 3 48259.8 45489.6 2770.2 1.4 84
Trial 4 48357 45586.8 2770.2 1.42 85.2
Trial 5 48308.4 45489.6 2818.8 1.38 82.8
Trial 6 48405.6 45635.4 2770.2 1.42 85.2
Trial 7 47968.2 45149.4 2818.8 1.41 84.6
Trial 8 48259.8 45489.6 2770.2 1.4 84
Trial 9 48162.6 45392.4 2770.2 1.42 85.2
Trial 10 48308.4 45489.6 2818.8 1.38 82.8
Trial 11 48162.6 45392.4 2770.2 1.42 85.2
Trial 12 48357 45586.8 2770.2 1.4 84
Trial 13 48259.8 45489.6 2770.2 1.4 84
Trial 14 47919.6 45100.8 2818.8 1.42 85.2
Trial 15 48308.4 45489.6 2818.8 1.38 82.8
avg 48211 45421.56 2789.64 1.406 84.36
std dev 152.584983 165.1174335 24.6446981 0.0159463 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. Cross-

Layer Optimization for Energy-Efficient Wireless Communications: A
Survey. Wireless Communications and Mobile Computing, 9:529542,
2009.
[2] Himayat Nageen. Li Ye. Swami Ananthram. Miao, Guowang. Cross-
Layer Optimization for Energy-Efficient Wireless Communications: A
Survey. Wireless Communications and Mobile Computing, 9:529542,
2009.
[3] K. Pentikousis. In Search of Energy-Efficient Mobile Networking. Com-
munications 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 en-
ergy needs for ICT: The rise of power-aware networking. In Advanced
Networks and Telecommunication Systems, 2008. ANTS 08. 2nd In-
ternational Symposium on, pages 1 3, 2008.
[5] Cisco Website. Cisco Visual Networking Index: Forecast and
Methodology, 20092014, [Online; Verified 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 Rat-
nasamy, and David Wetherall. Reducing Network Energy Consump-
tion via Sleeping and Rate-Adaptation. In Proceedings of the 5th
USENIX Symposium on Networked Systems Design and Implementa-
tion, NSDI08, pages 323336, Berkeley, CA, USA, 2008. USENIX As-
sociation.
[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: 100base-

tx, [Online; Verified November] Available:2010.
http://www.ieee802.org/3/az/public/jan08/chou 01 0108.pdf.

[10] M. Grimwood. Energy Efficient Ethernet 1000BASE-

T LPI Timing Parameters, [Online; Verified Novem-
ber] 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. Perfor-

mance evaluation of energy efficient 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 Wire-
less Web Access with Bounded Slowdown. In Proceedings of the 8th
Annual International Conference on Mobile Computing and Network-
ing.

[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, Mobi-
Com 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 Efficient 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 fig-

ures, [Online; Verified 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; Verified November] Avail-
able: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. In-
ternational Conference on, 30 2009.

[22] Nokia Siemens Networks website. Smart devices need

smart business solutions, [Online; Verified November] Avail-
able: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 Evalu-
ation 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; Verified November] Available:2010.
http://www.pcauthority.com.au/Feature/141410,broadband
-buyers-guide-fixed-vs-mobile.aspx.

[25] YouTube, [Online; Verified November] Available:2010.

http://www.youtube.com.

[26] Mediafire, [Online; Verified November] Available:2010.

http://www.mediafire.com.

[27] Gmail, [Online; Verified November] Available:2010.

http://www.gmail.com.

[28] Miniclip, [Online; Verified November] Available:2010.

http://www.miniclip.com.

[29] Chester Simpson. Characteristics of Rechargable Bat-

teries, [Online; Verified November] Available:2010.
http://www.national.com/appinfo/power/files/f19.pdf.

[30] American Physical Society. Energy Units,

[Online; Verified November] Available:2010.
BIBLIOGRAPHY 57

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

[31] Passmark website. BatteryMon, [Online; Verified November] Avail-

able:2010. http://www.passmark.com/products/batmon.htm.

[32] Imtec.org. Imtec Battery Mon, [Online; Verified November] Avail-

able:2010. http://en.imtec.org.ru/load/7-1-0-5.

[33] Battery Care, [Online; Verified November] Available:2010.

http://batterycare.net/en/index.html.

[34] Speedtest, [Online; Verified November] Available:2010.

http://www.speedtest.com.

[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 In-
ternational 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 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

Author:
Oziel Alejandro Gonzalez Lagunas
E-mail: ozielglez@gmail.com

University advisor(s):

Tahir Nawaz Minhas

School of Computing

Examiner
Dr Patrik Arlos
School of Computing

School of Computing Internet: www.bth.se/com

Blekinge Institute of Technology Phone: +46 455 385000
371 79 KARLSKRONA SWEDEN 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 characteris-
tics with packet loss and delay variation for video sequences with different
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
different 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 affects the perceived quality of video. In addition, it is
shown that there is no significance difference 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

i
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 filling 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 i

Acknowledgements iii

Contents iv

List of Figures vii

List of Tables viii

1 Introduction 1

2 Background 3
2.1 Key Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Video coding . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Video Transmission . . . . . . . . . . . . . . . . . . . 4
2.1.3 Emulation . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 Quality of Video . . . . . . . . . . . . . . . . . . . . . 6
2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Design and Implementation 9

3.1 Aims and Research Questions . . . . . . . . . . . . . . . . . . 9
3.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1 Transport Protocol . . . . . . . . . . . . . . . . . . . . 11
3.3.2 Video Parameters . . . . . . . . . . . . . . . . . . . . 12
3.3.3 Network emulator . . . . . . . . . . . . . . . . . . . . 15
3.3.4 Packet loss and delay/delay variation . . . . . . . . . 15
3.4 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1 Experimental Setup . . . . . . . . . . . . . . . . . . . 16
3.4.2 Data Collection . . . . . . . . . . . . . . . . . . . . . . 18

v
4 Results and Discussion 23
4.1 Packet loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Delay variation . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Mobile phone and laptop . . . . . . . . . . . . . . . . . . . . . 31
4.4 Validity Threats . . . . . . . . . . . . . . . . . . . . . . . . . 34

5 Conclusion 35

Bibliography 37

A Video Encoding Information 41

A.1 Procedure for video sequences creation . . . . . . . . . . . . . 41
A.2 Pre-set FFMPEG files . . . . . . . . . . . . . . . . . . . . . . 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 Spatial and temporal correlation in a video sequence [27] . . . 4

2.2 Example of error propagation [2] . . . . . . . . . . . . . . . . 5

3.1 Experimental network set-up . . . . . . . . . . . . . . . . . . 17

3.2 Laptop based assessment . . . . . . . . . . . . . . . . . . . . . 20
3.3 Mobile Phone assessment . . . . . . . . . . . . . . . . . . . . 20
3.4 Screen shot of interview set-up for laptop . . . . . . . . . . . 20

4.1 MOS for packet loss displayed on the laptop . . . . . . . . . . 25

4.2 MOS for packet loss displayed on the mobile phone . . . . . . 25
4.3 Confidence interval (95%) for packet loss . . . . . . . . . . . . 27
4.4 Standard deviation for packet loss . . . . . . . . . . . . . . . 27
4.5 MOS for delay variation displayed on the laptop . . . . . . . 28
4.6 MOS for delay variation displayed on the mobile phone . . . 29
4.7 Confidence interval (95%) for delay variation . . . . . . . . . 29
4.8 Standard deviation for delay variation . . . . . . . . . . . . . 30
4.9 MOS packet loss displayed on the laptop and mobile phone . 31
4.10 MOS delay variation displayed on the laptop and mobile phone 32

B.1 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.2 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.3 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4 Questionnaire . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vii
viii
List of Tables

3.1 Five-level scale for rating overall quality of video . . . . . . . 11

3.2 Description of video content for the test sequences used in the
subjective test. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3 Video parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Characteristics of encoded videos . . . . . . . . . . . . . . . . 15

4.1 Mean opinion score for packet loss . . . . . . . . . . . . . . . 24

4.2 Mean opinion score for delay variation . . . . . . . . . . . . . 24
4.3 Matched-sample t test results . . . . . . . . . . . . . . . . . . 33

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

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
effective 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 different purposes,
each with different 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 file to be downloaded. Video
streaming over the Internet can have problems from disturbances in the
network, such as packet loss and delay variation, that affect 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 flow 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
2 CHAPTER 1. INTRODUCTION

for performance assessment, predict impact of change or optimize technol-

ogy [13]. In this thesis emulation is used to create the desired conditions to
test the effects of packet loss and delay variation.
In this thesis we study how packet loss and delay variation in a network
effects the user perception of quality. Specifically this thesis aims to under-
stand the user perception of video quality for defined values of packet loss
and delay variation for the codec H.264. Additionally this thesis aims to
understand if the users have different 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 recom-
mendations 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 specifically raw
video. Compression involves two systemsa compressor (coder) and a de-
compressor (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 redundan-
cies 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 different types of frames in a GOPfor H.264 the
most common frames are I-frames (intra), P-frames (predicted) and B (bi-
predictive) [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. Different frames types have dissimilar compression ratios
and error propagation features [16].
The GOP structure is a factor that affects the video compression ratio,

3
4 CHAPTER 2. BACKGROUND

Figure 2.1: Spatial and temporal correlation in a video sequence [27]

it also affects the distortion sensitivity to packet loss and delay [16]. For
example, if we increase the distance between reference frames when encod-
ing, the compression ratio is bigger; on the other hand the effect of error
propagation due to packet loss also increases as less reference frames are
transmitted.
The H.264 codec has different profiles 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 profiles were created to specify
the requirements for the equipment that will encode and decode the video.
Each profile has some variations in the algorithm that compresses the video,
as the computing capabilities differ. The most extended profiles are the
baseline profile that includes support for I-P-frames as is used for limited
capability devices such as mobile phones. The main and extended profiles
that support I-P-B frames are mainly used for video storage and television
broadcasting [27].
The profiles 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 profiles 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 com-
munication between streaming servers and clients. Transport protocols for
2.1. KEY CONCEPTS 5

media streaming include the Transport Control Protocol (TCP) and Uni-
versal Datagram Protocol (UDP). TCP uses retransmission and flow control
mechanisms that, on one hand, guarantee the delivery of packets, but also
introduce delays that are not acceptable for time critical streaming appli-
cations. Consequently, UDP is the protocol most widely used for real-time
streaming of video [37, 2].
Video streaming over the Internet using UDP present different distor-
tions that affect 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 significantly damage video quality
during transmissions [22]. The losses are generally random and can affect
different frames in a GOP. If a key frame (I-frame or P-frame) is affected
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 P-
frames can propagate errors to other P-frames and B-frames. The Figure2.2
shows an example of error propagation and how causes a cascade effect,
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].
6 CHAPTER 2. BACKGROUND

2.1.3 Emulation
Network emulation is a way to simulate the network performance in a con-
trolled and repeatable environment. Traffic shapers are used for the varia-
tion of parameters such as delay and packet loss to emulate different network
conditions. It is very important that the traffic shapers behave according to
the given specifications 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 different 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 different
codecs; Calyam et al. [6] made a comparative study of subjective and ob-
jective 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 effect. 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 different 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 different GOP structures for H.264 and MPEG-2.
The article by Loguinov and Radha [23] analyses the behaviour of different
parameters in video coded with MPEG-4. Pinson et al. [26] compares High
Definition Television (HDTV) video perception for video with and without
packet loss for H.264 and MPEG-2 codecs. Simone et al. [9] offers 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 efficiency and the propagation of errors when a key frame is
affected. The GOP is defined by the encoding parameters and in some
extent to the H.264 profile used. Studies that have addressed quality of
video for H.264 for different purposes, in some cases does not mention the
2.2. RELATED WORK 7

profile or coding characteristics [3, 7, 23, 32], some other studies mention the
profile used for example [22] and [9] used the high profile, [26] used the main
profile, Ries et al. [28] uses the baseline profile 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 profile for
perception of packet loss and delay variation will have some contribution.
The network conditions for mobile internet differ from traditional net-
works. When the videos are used over mobile networks important require-
ments 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
fixed stand, so the user was not able to manipulate the phone as occurs in
real life scenarios.
People have different perceptions of quality for different media devices.
Television and computers are usually at a fixed 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 experi-
ments 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 different 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.
8 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 experi-
ment 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; defining
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 different 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 different 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 objec-
tive method consists of methods that do not involve human grading. The
videos are evaluated by computers and mathematical algorithms. Differ-
ent objective methods are described by the Video Quality Experts Group
(VQEG) [34], which was formed to validate and standardise objective meth-
ods of video quality. These methods usually employ an error signal ratio that
is a relation between the original video (considered high quality) and the pro-
cessed 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 qual-
ity is based on human perception and can be different between subjects [6].
Human perception involves various aspects of human psychology and view-
ing conditions; such as vision ability, lighting conditions, preference for con-
tent, displaying devices, understanding of the rating criteria [35]. Different
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 first video as a reference, in Pair Comparison
method (PC) the sequences are presented in pairs, they can be simultane-
ously 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 per-
form 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 MOS Impairment

5 Excellent Imperceptible
4 Good Perceptible, but not annoying
3 Fair Slightly annoying
2 Poor Annoying
1 Bad 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 findings 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
different 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 qualification tests [25].

ACR is the method recommended for qualification 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 flow control mech-
anisms that on one hand guarantee the delivery of packets, but introduce
delays that are not acceptable for time critical streaming applications. Con-
sequently, 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 different motion activities, with each sequence representing
a different 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 different 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 Description

Hall-monitor Two subjects in an office 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.
Foreman 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 construc-
tion.
Football Scene with high motion of American football.
News News media presenters, in the front the two presen-
ters with low movement. In the back, two dancers
performing.

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 mo-
bile 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 touch-
screens. 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
profile level 1.3 that is supported by mobile phones.

Container

The container or wrapper defines how the data is stored in a file. 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
files 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 CHAPTER 3. DESIGN AND IMPLEMENTATION

Video Codec
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 profile is supported by mobile phones
running Android, since early version of the iPhone and Symbian phones.
The baseline profile supports intra and inter-coding (using I-frames and
P-frames), does not support inter-coding B-frames, that uses a different
compression algorithm. Application examples of the baseline profile are
videoconferences and wireless transmission [27] .
Some studies have done analysis of H.264 with packet loss and delay,
for different applications and using different profiles of the codec. Pinson et
al. [26] compares packet loss for HDTV using the high profile; 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 profile
but describes the video with IPB-frames; Simone et al. [9] employs the H.264
codec high profile, 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 News, Football, Foreman, Hall-monitor

Codec H.264 Baseline Profile, level 1.3
Resolution (320 240) (VGA)
Frame-rate 30 fps
Bit Rate 768kbps
Container MP4

The above parameters are kept constant for the realization of the exper-
iment, due that changes in these parameters have effect 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 effects 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 files 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 Duration No.Frames No.I-Frames No.P-Frames Size

Foreman 10 sec 300 2 298 983 KB
Football 8 sec 260 2 258 792 KB
Hall-monitor 10 sec 300 2 298 929 KB

3.3.3 Network emulator

In emulation, traffic shapers are used to define certain features of a commu-

nication network. In this thesis, packet loss percentage and delay will be
varied during transmission. Different options are available for traffic shaping
among them NIST Net, NetEm, Dummynet.
A study of the performance of the traffic shapers is presented by Shaikh
et al. [29], in this article the authors compare different delay values for the
above mentioned shapers using two different hardware platforms Advanced
Micro Devices (AMD) and Intel, they show different 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 predefined 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 traffic control.

3.3.4 Packet loss and delay/delay variation

Packet loss parameters

The values of packet loss for this experiment are defined 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 mod-
elling packet loss in different 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
fixed delay values, jitter has bigger effects in the video sequences. Tests
were executed with different fixed delay values from 0ms to 1sec increases of
100ms and the effects 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 fixed 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 fixed delay and D is the delay variation.
The fixed 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] defines 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 traffic 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 configuration and the network emulator configuration com-
mands.

3.4.1 Experimental Setup

A small test network was built to perform the experiments, the Figure 3.1
shows a simplified 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
traffic between S and R passes through the Traffic 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 17

Traffic
Shaper
(TS)

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 tfifo 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 firewall 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 semi-
automate 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 different effects.

NetEm configuration

NetEm [13] was used to set the experimental packet loss values in our ex-
perimental 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 fixed 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 specific disturbance at the TS and check-
ing that the values captured in the MP with the cap files 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 19

Assessment Methodology
The assessment sessions were held in a rooms conforming to the specifi-
cations 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 specifies 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 different ages and backgrounds. In total 12 female
and 22 male volunteers, ranging ages from 19 to 41, with 12 having Eu-
ropean 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 recommen-
dations 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 fifty percent grey1 . A screen shot
indicating this set-up is shown in Figure 3.4.
Each assessment interview lasted for approximately 25 minutes and con-
sisted of three phases: training session, questions and main session. During
the introduction, the assessment methodology was explained, general infor-
mation 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 different 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 par-
ticipants 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 Sin-
gle 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. Con-
ventional 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 be-
haviour 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 se-
quences (Foreman, Hall-monitor, Football) and for both of the devices
laptop and mobile phone.
The mean is defined as:
N
1 X
uj k = uij k (4.1)
N i=1
The standard deviation is defined as:
v
uN
uX (uj k uij k )2
sj k = t (4.2)
i=1
N 1
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 FM L FM P HM L HM P FT L FT P
0.0% 4.44 4.50 4.38 4.29 4.24 4.18
0.4% 3.26 3.44 3.56 3.29 3.21 2.82
0.8% 2.62 2.56 2.65 2.47 2.26 2.47
3.0% 1.85 2.15 1.88 1.94 1.76 1.74
5.0% 1.47 1.50 1.76 1.79 1.41 1.29
7.0% 1.15 1.15 1.79 1.71 1.41 1.47

Table 4.2: Mean opinion score for delay variation

Delay FM L FM P HM L HM F FT L FT P
150ms 2ms 2.00 2.18 1.88 1.88 3.03 2.71
150ms 4ms 1.79 1.85 1.68 1.79 2.56 2.68
150ms 8ms 1.18 1.15 1.44 1.47 1.88 1.59
150ms 12ms 1.09 1.06 1.12 1.12 1.18 1.29
150ms 16ms 1.03 1.03 1.06 1.06 1.18 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 per-
ception 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 different videos affected 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 Hall-monitor Football

5.00

4.50

4.00

3.50
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 Hall-monitor Football

5.00

4.50

4.00

3.50
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- Ra-
diocommunications 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 confidence interval was calculated for
each case. It is suggested to use a 95% confidence interval. This means:

With a probability of 95%, the absolute value of the difference

between the experimental mean score and the true mean score
(for a very high number of observers) is smaller than the 95%
confidence interval [5].

The confidence interval consists of an upper and a lower limit for the
mean u.

[uj k j k , uj k + j k ] (4.3)

where:
sj k
j k = 1.96 (4.4)
N
sj k is calculated from the equation 4.2.

The values calculated for the confidence interval for packet loss are shown
in the Figure 4.3. The x-axis shows the video sequence (FM- foreman, HM-
hall-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 difference within the three different 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 different 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 difficult for the observers to decide the
quality.
 Standard Deviation !"#$

0.00
0.10
0.20
0.30
0.40
0.50
0.60
0.70
0.80
0.90
1.00
!"##$
%"##$
&"##$
'"##$
("##$
)*$+$#"#,$
)*$-$#"#,$

0
.*$+$#"#,$
.*$-$#"#,$
)/$+$#"#,$
)/$-$#"#,$
4.1. PACKET LOSS

)*$+$#"',$
)*$-$#"',$

0.4
.*$+$#"',$
.*$-$#"',$
)/$+$#"',$

FM L
)/$-$#"',$
)*$+$#"0,$
)*$-$#"0,$

FM P

0.8
.*$+$#"0,$
.*$-$#"0,$
)/$+$#"0,$

HM L
)/$-$#"0,$
)*$+$&"#,$
)*$-$&"#,$

Packet Loss [%]

HM P
.*$+$&"#,$

3.0
.*$-$&"#,$
)/$+$&"#,$

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

FT L
)/$-$&"#,$
)*$+$("#,$
)*$-$("#,$

FT P
.*$+$("#,$

5.0
.*$-$("#,$
)/$+$("#,$

Figure 4.4: Standard deviation for packet loss

)/$-$("#,$
Figure 4.3: Confidence interval (95%) for packet loss )*$+$1"#,$
)*$-$1"#,$
.*$+$1"#,$

7.0
.*$-$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 appre-
ciated 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 affected 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 Hall-monitor Football

5.00

4.50

4.00

3.50
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 confidence interval values for delay variation.
The x-axis shows the video sequence (FM- foreman, HM- hall-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. 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 Hall-monitor Football

5.00

4.50

4.00

3.50
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: Confidence 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 FM P HM L HM P FT L FT P

1.00

0.90

0.80

0.70
Standard Deviation

0.60

0.50

0.40

0.30

0.20

0.10

0.00
2 4 8 12 16
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 findings of the study performed by Calyam et al. [6] although
their study was for the codec H.263 and adding different disturbances to the
same video sequence.
As we stated before, we chose the video sequences with different temporal
characteristics as this factor affects 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 differences 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. Al-
though 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 findings 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 specific frames are affected. 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 difference 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

3.00
MOS

2.50

2.00

1.50
Laptop
1.00
0 0.4 0.8 3.0 5.0 7.0 Mobile
Phone
Packet Loss [%]

Figure 4.9: MOS packet loss displayed on the laptop and mobile phone

To identify if these variations are significant 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 difference between two
means [15]. In this specific 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 difference
between doing the experiment on the mobile phone or on the laptop when
using the same resolution in both devices.
If we consider the difference of the means uD = uL uP , then the
hypothesis can also be expressed as:

H : uD = uL uP = 0 (4.5)

where:
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
Laptop
1.00
2 4 8 12 16 Mobile
Phone
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 difference 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 significance, in this case a 95% confidence
interval is used. Thus, the level of significance is 0.05, the degrees of freedom
(df) is defined 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 defined as:

D uD
tcalc = sD (4.6)

N

where D and sD are the mean and standard deviation of the differ-
ence scores (difference 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
difference scores (number of pairs).
If we find that tcalc < ttable we fail to reject the hypothesis, so there is no
evidence to suggest that the different devices affect 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 different devices affect the perception of the shown video.
Therefore, we can conclude that there is not a significant difference be-
4.3. MOBILE PHONE AND LAPTOP 33

Table 4.3: Matched-sample t test results

Video sequence tcalc Result

FM 0.0% loss 0.63 Fail to reject the hypothesis.
FM 0.4% loss 1.14 Fail to reject the hypothesis.
FM 0.8% loss 0.42 Fail to reject the hypothesis.
FM 3.0% loss 2.05 Fail to reject the hypothesis.
FM 5.0% loss 0.25 Fail to reject the hypothesis.
FM 7.0% loss 0.00 Fail to reject the hypothesis.
FM 2ms DV 1.36 Fail to reject the hypothesis.
FM 4ms DV 0.70 Fail to reject the hypothesis.
FM 8ms DV 0.44 Fail to reject the hypothesis.
FM 12ms DV 0.44 Fail to reject the hypothesis.
FM 16ms DV 0.00 Fail to reject the hypothesis.
HM 0.0% loss 0.90 Fail to reject the hypothesis.
HM 0.4% loss 2.50 Reject the hypothesis.
HM 0.8% loss 1.36 Fail to reject the hypothesis.
HM 3.0% loss 0.44 Fail to reject the hypothesis.
HM 5.0% loss 0.27 Fail to reject the hypothesis.
HM 7.0% loss 0.83 Fail to reject the hypothesis.
HM 2ms DV 0.00 Fail to reject the hypothesis.
HM 4ms DV 1.28 Fail to reject the hypothesis.
HM 8ms DV 0.37 Fail to reject the hypothesis.
HM 12ms DV 0.00 Fail to reject the hypothesis.
HM 16ms DV 0.00 Fail to reject the hypothesis.
FT 0.0% loss 0.42 Fail to reject the hypothesis.
FT 0.4% loss 3.20 Reject the hypothesis.
FT 0.8% loss 2.03 Fail to reject the hypothesis.
FT 3.0% loss 0.25 Fail to reject the hypothesis.
FT 5.0% loss 1.16 Fail to reject the hypothesis.
FT 7.0% loss 0.63 Fail to reject the hypothesis.
FT 2ms DV 2.46 Reject the hypothesis.
FT 4ms DV 0.89 Fail to reject the hypothesis.
FT 8ms DV 2.73 Reject the hypothesis.
FT 12ms DV 1.68 Fail to reject the hypothesis.
FT 16ms DV 0.81 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 de-
vices.

4.4 Validity Threats

Perceptions of video quality change over time with users having higher ex-
pectations 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 ex-
ample, some years ago was not common to have mobile phones with video
capabilities. Improvements in the codecs, network equipment and mecha-
nism 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 different types of packets affecting video quality in different
ways.
This experiment applied the baseline profile and pre-set files 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 effects 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 affect
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 affected 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
first 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 affected 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 under-
stand if users have different 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 different devices affect 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 finding 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 findings highlight the importance for network providers and engi-
neers to put in place mechanisms to avoid packet loss and delay variation.
Network engineers could also consider, improvements in networking equip-
ment that would be able to identify different kinds of types of packets and
prioritise them according to the significance 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 affects the propagation of errors that affect the quality of video. This
includes extension of the experiment presented in this thesis to use different
profiles of the H.264 codec and different 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 effect
the different frames. It may be necessary to conduct further experiments to
fully understand the effect of losing different types of packets.
Bibliography

[1] Xiph.org test media. [Online] http://media.xiph.org/video/derf/, ac-

cessed on July 2010.

[2] John G. Apostolopoulos, Wai tian Tan, and Susie J. Wee. Video stream-
ing: Concepts, algorithms, and systems. Technical report, HP Labora-
tories, 2002.

[3] Hussein Muzahim Aziz, Hakan 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 Technol-
ogy, 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 traffic. In
Chadi Barakat and Ian Pratt, editors, Passive and Active Network Mea-
surement, 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 wire-
less 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 effects of jitter on the pe-
ceptual 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. [Online]
http://www.endace.com/, accessed September 2010.
[12] FFMPEG. [Online] http://www.ffmpeg.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, vol-
ume 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
effects on error propagation in MPEG-4 video streams. In 4th Interna-
tional Symposium on Communications, Control and Signal Processing
(ISCCSP), 2010, pages 15, 2010.
[17] Apple Inc. iPhone 4 technical specifications. [On-
line] http://www.apple.com/iphone/specs.html and
http://www.apple.com/itunes/podcasts/specs.html, accessed on
August 2010.
[18] Satu Jumisko-Pyykko and Jukka Hakkinen. Evaluation of subjective
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 De-

sign. 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 ap-
plication 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. [Online]

http://www.pevq.org/, accessed July 2010.

[25] ITU-T P.910. Subjective video quality assessment methods for multi-
media applications. International Telecommunications Union Telecom-
munication 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 mo-
bile 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 traffic shapers. pages 1 8, may. 2010.

[30] S. Spirou. Packet reordering effects on the subjective quality of broad-

band 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 Pit-
sillides. Requirements for the transmission of streaming video in mobile
wireless networks. In Stefanos Kollias, Andreas Stafylopatis, Wlodzis-
law Duch, and Erkki Oja, editors, Artificial Neural Networks ICANN
2006, volume 4132 of Lecture Notes in Computer Science, pages 528
537. Springer Berlin / Heidelberg, 2006.
40 BIBLIOGRAPHY

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

2010.

[34] VQEG. Video quality experts group. [Online]

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 appli-
cations. 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 se-
quences.

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

Configure the packet loss or delay variation in the TS using the NetEm
(see section NetEm configuration) tc commands.

Set a file name in the MP to save the information of the captured

packets (.cap files) 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 finished a flush of the DAG cards was
performed to force out any remaining packet.

41
42 APPENDIX A. VIDEO ENCODING INFORMATION

A.2 Pre-set FFMPEG files

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

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

libx264-slow.ffpreset
coder=1
flags=+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
qdiff=4
bf=3
refs=5
directpred=3
trellis=1
flags2=+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 -s 320x240 -r 30

-vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0
-f ipod /home/oziel/Pictures/foreman_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 @ 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% 3.7%
[libx264 @ 0x8e8d860] kb/s:802.38

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 first column the video disturbance applied, the second col-
umn shows the original received video name and the last two columns the renamed
files 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
Disturbance Original File Received Renamed for Laptop Renamed for Mobile Phone
APPENDIX B. ASSESSMENT MATERIAL

Loss 5% hallmonitor loss5 1.mp4 Hallmonitor A.mp4 HallMon K.mp4

Delay 150ms 2ms hallmonitor delay150v2 3.mp4 Hallmonitor B.mp4 HallMon J.mp4
Loss 0.8% hallmonitor lossP8 2.mp4 Hallmonitor C.mp4 HallMon I.mp4
Delay 150ms 16ms hallmonitor delay150v16 1.mp4 Hallmonitor D.mp4 HallMon H.mp4
Loss 3% hallmonitor loss3 1.mp4 Hallmonitor E.mp4 HallMon G.mp4
Delay 150ms 12ms hallmonitor delay150v12 2.mp4 Hallmonitor F.mp4 HallMon F.mp4
Delay 150ms 4ms hallmonitor delay150v4 3.mp4 Hallmonitor G.mp4 HallMon E.mp4
Loss 0.4% hallmonitor lossP4 1.mp4 Hallmonitor H.mp4 HallMon D.mp4
Delay 150ms 8ms hallmonitor delay150v8 3.mp4 Hallmonitor I.mp4 HallMon C.mp4
H.264 Original hallmonitor original 3.mp4 Hallmonitor J.mp4 HallMon B.mp4
Loss 7% hallmonitor loss7 1.mp4 Hallmonitor K.mp4 HallMon A.mp4
Delay 150ms 2ms football delay150v2 2.mp4 Football A.mp4 FootballM K.mp4
Loss 3% football loss3 3.mp4 Football B.mp4 FootballM B.mp4
Loss 0.4% football lossP4 1.mp4 Football C.mp4 FootballM C.mp4
Delay 150ms 8ms football delay150v8 3.mp4 Football D.mp4 FootballM D.mp4
H.264 Original football original 1.mp4 Football E.mp4 FootballM E.mp4
Loss 7% football loss7 2.mp4 Football F.mp4 FootballM F.mp4
Delay 150ms 4ms football delay150v4 1.mp4 Football G.mp4 FootballM G.mp4
Loss 0.8% football lossP8 1.mp4 Football H.mp4 FootballM H.mp4
Delay 150ms 16ms football delay150v16 3.mp4 Football I.mp4 FootballM I.mp4
Loss 5% football loss5 2.mp4 Football J.mp4 FootballM J.mp4
Delay 150ms 12ms football delay150v12 3.mp4 Football K.mp4 FootballM A.mp4
Delay 150ms 12ms foreman delay150v12 3.mp4 Foreman A.mp4 ForemanM K.mp4
Loss 5% foreman loss5 3.mp4 Foreman B.mp4 ForemanM J.mp4
Loss 0.4% foreman lossP4 1.mp4 Foreman C.mp4 ForemanM I.mp4
Delay 150ms 2ms foreman delay150v2 3.mp4 Foreman D.mp4 ForemanM H.mp4
Loss 3% foreman loss3 2.mp4 Foreman E.mp4 ForemanM G.mp4
H.264 Original foreman original 2 Foreman F.mp4 ForemanM F.mp4
Delay 150ms 16ms foreman delay150v16 2.mp4 Foreman G.mp4 ForemanM E.mp4
Delay 150ms 4ms foreman delay150v4 3.mp4 Foreman H.mp4 ForemanM D.mp4
48

Loss 0.8% foreman lossP8 1.mp4 Foreman I.mp4 ForemanM C.mp4

Loss 7% foreman loss7 1.mp4 Foreman J.mp4 ForemanM B.mp4
Delay 150ms 8ms foreman delay150v8 2.mp4 Foreman K.mp4 ForemanM A.mp4
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: iqbal99@gmail.com
Md. Ibrahim Chowdhury
Email: ibrahimiiuc@gmail.com

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 Internet : www.bth.se /com

Blekinge Institute of Technology Phone : +46 455 38 50 00
SE - 371 79 Karlskrona Fax : +46 455 38 50 57
Sweden
ii
 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 multi-
homing 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................... III

Acknowledgments.. IV

Table of Contents....... V

List of Figures VII

List of Tables . VIII

Acronyms IX

Chapter 1. Introduction 1
1.1 Research Design.. 2
1.1.1 Research Methodology .. 2
1.1.2 Main Problems 4
1.1.3 Research Questions. 5
1.1.4 Aims and Objectives . 5
1.1.5 Motivation . 5
1.1.6 Contribution ... 6
1.2 Thesis Outline. 6

Chapter 2. Background....... 7
2.1 Simultaneous Mobility and Handover 7
2.2 Stream Control Transmission Protocol (SCTP).. 7
2.2.1 SCTP association... 7
2.2.2 Multi-homing........ 8
2.2.3 Multi-streaming............. 8
2.3 SCTP Packet Structure 8
2.4 Mobile SCTP (mSCTP).......... 9
2.5 Related works...... 9
2.5.1 Simultaneous mobility solution by mSCTP with 9
RSerPool
2.5.2 Simultaneous mobility under asymmetric mobility 10
conditions..........................
2.5.3 Managing Simultaneous Mobility of IP hosts.. 10

Chapter 3. Simulation Tool & Methodology............... 11

3.1 Network Simulator 2 (NS2).... 11
3.2 Simulation with NS2... 12
3.2.1 Structure of Wired and Mobile nodes .. 12
3.2.2 Wireless Simulation by NS2. 12
3.2.3 Trace File................... 12
3.3 Simulation Methodologies.. 13

v
Chapter 4. Proposed Model for Simultaneous Mobility with Location
Management 14
4.1 NS2 based architectural model for Simultaneous Mobility
with mSCTP... 14
4.2 Location management with Location Server (LS).. 16
4.2.1 LS setup and management process. 16
4.3 Solution of Simultaneous Mobility issues... 18
4.3.1 Mobile nodes location detection and configuration 18
4.3.2 LS enabled Simultaneous Mobility management
and Simultaneous Handover... 19
4.3.2.1 Association setup........................... 20
4.3.2.2 Dynamic Address Reconfiguration
(DAR) 20
4.3.2.3 Simultaneous Mobility process and
Handover 20
4.3.2.4 Context Analysis 21
4.3.2.5 Timing diagram.. 21
4.4 System constraints and Risk analysis.. 22
4.4.1 System constraints.. 22
4.4.2 Risk analysis....... 23

Chapter 5. Implementation.. 24
5.1 Objectives of analysis..... 24
5.1.1 System requirements and challenges (cost
analysis and etc.). 24
5.1.2 Parameter setup and assumptions of simulation. 24
5.2 Simulations.. 27
5.2.1 Definition of performance matrices for simulation
scenarios.. 27
5.2.2 Simulation scenarios and Observations. 28
5.2.3 Simulation insight.. 33
5.2.4 Incorporation of modeling into solution............ 34
5.2.5 Execution of mSCTP patch....................... 35
5.2.6 LS functionalities 37
5.2.7 Location Management by LS .... 37

Chapter 6. Experimental Results. 40

6.1 LS performance... 40
6.2 Handover Latency... 42
6.3 Confidence Interval (CI) analysis....... 44

Chapter 7. Conclusion and Future work. 47

7.1 Conclusion... 47
7.2 Future work. 47

REFERENCES............... 48

APPENDIX. 51

vi
 LIST OF FIGURES
3.1 NS-2 Architectural view. 11
3.2 Trace File format 12
3.3 SCTP node outlook............. 13

4.1 The simultaneous mobility of MN_0 and MN_1 15

4.2 Simultaneous Mobility model with random step_length 16
4.3 Simultaneous Mobility support by LS 17
4.4 Location management Process 17
4.5 Integrated structure of TCL and LS 18
4.6 Modified association setup.......................................................................... 19
4.7 First address reconfiguration case............................................................... 20
4.8 Mobility Process. 21
4.9 Timing diagram of new approach of mSCTP for simultaneous mobility... 22

5.1 The simultaneous mobility scenario with Brink plane 25

5.2 Showing random movements of MN_0 and MN_1 proceeding with
random step_length within range (0-750).................... 28
5.3 Showing random movements of MN_0 and MN_1 proceeding with
random step_length..................... 30
5.4 MN_0 and MN_1 simultaneously moving and handovers occur at step-
11..................... 32
5.5 MN_1 and MN_0, handovers to each others region simultaneously with
sequential mobility.............................................. 32
5.6 Data set from a random simulation run out of 30 times, (MN_1 and
MN_0, handovers to each others region simultaneously). 33
5.7 (a) mSCTP unable to perform Add-IP (b) mSCTP successfully perform
Add-IP............................ 34
5.8 Showing the Add-IP and Delete-IP in mSCTP connection
procedure............. 35
5.9 Showing new DAR process activity for mSCTPs ASCONF patch.. 35
5.10 (a) Random movement of MNs, (b) Simultaneous Movement of
MNs............. 36
5.11 LS Data Structure 37
5.12 Architecture of location detection inside LS.. 38
5.13 Signalling between MN_0 and MN_1 and ASCONFs to measure the
total handover delay 39

6.1 LS server sample file storing all the simultaneous mobility

information...... 40
6.2 LS registration and update in case of simultaneous mobility. 41
6.3 (a) Error bars of estimated data 1.989170, (b) Error boundary with
standard deviation... 45

vii
 LIST OF TABLES
4.1 Example of random values for simultaneous mobility.......... 15
5.1 Definition of handover delay parameters........... 26
5.2 Simulation results showing overlapping number. 29
5.3 Simulation results showing overlapping number. 30
5.4 Simulation results showing overlapping number. 32
6.1 Different steps to measure handover latency for mSCTP with
and without LS.. 42
6.2 Handover latency for different cases of simultaneous
mobility.. 43
6.3 Confidence analysis of estimated values LS with mSCTP
Handover Delay 45

viii
 ACRONYMS

IP Internet Protocol
WLAN Wireless Local Area Network
OSI Open Systems Interconnection
HIP Host Identity Protocol
HAWAII Handoff Aware Wireless Access Internet Infrastructure
MIP Mobile IP
IDMP Intra-domain Management Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
SCTP Streaming Control transport Protocol
DAR Dynamic Address Reconfiguration
SIP Session Initiation Protocol
mSCTP Mobile Streaming Control Transport Protocol
MN Mobile Node
CN Correspondent Node
ASCONF Address Configuration Change
ASCONF-ACK Address Configuration Acknowledgment
Add-IP Adding IP
Delete-IP Deleting IP
LS Location Server
NS-2.34 Network Simulator version 2.34
4G The 4th generation wireless network
BS Base Station
RFC Request for Comments
IETF Internet Engineering Task Force
TSN Transmission Sequence Number
CWND Congestion Window
DCCP Datagram Congestion Control Protocol
RUDP Reliable User Datagram Protocol
MTU Maximum Transmission Unit
MAC Message Authentication Code
GPRS General Packet Radio Service
HOL Head Of Line
CRC Cyclic Redundancy Check

ix
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
RSerPool Reliable Server Pooling
ASAP Asynchronous Service Access Protocol
NS Name Server
ENRP Endpoint Name Resolution Protocol
AR Access Router
LR Location register
MTOSM Mean time to occurrence of simultaneous mobility
CDMA Code Division Multiple Access
Cygwin Linux Emulation for Windows
FIFO First In, First Out
REAL Previous name of NS2
TCL Tool Command Language
TK Tool Kit
OTcl Object oriented extension of TCL
TClCL TCL with classes
NAM Network Animator
XGRAPH It is used in NS2 to plot x-y data
ARP Address Resolution Protocol
IFq Interface Queue
NetIF Network Interface
DSR Dynamic Source Routing
DSDV Destination Sequenced Distance Vector
AODV Ad hoc On Demand Distance Vector
GOD General Operations Director
SACK Selective Acknowledgement
MN_0 Mobile Node_0
MN_1 Mobile Node_1
MN_#_init Mobile nodes initial position
MN_#_new Mobile nodes new position
step_length Numerical length of a step
del-t Delta time
TRD Time of Router Discovery
RTT Round Trip Time
RNG Random Number Generator

x
FTP File Transfer Protocol
Drop-tail A queue management algorithm
DHT 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 OSI-
reference 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.

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

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

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

4
 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

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

6
 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 non-
simultaneous 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

7
 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. Multi-
streaming 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

8
 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 (ASCONF-
ACK). 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

9
 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, COOKIE-
ECHO, 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 multi-
homed 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 (v-
2.30) [41].

13
 Chapter 4: Proposed Model for Simultaneous Mobility with Location Management

CHAPTER 4 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 (i)

MN_1_init.x - step_length = MN_1_new (ii)
Where, x is any random value along x-axis
MN_0 moves towards MN_1 moves towards
step_length
MN_1 MN_0
(5,0) (14,0) (19,0) (55,0) (50,0)
. ..
(7,0) (20,0) (27,0) (48,0) (41,0)
. .
(9,0) (28,0) (37,0) (41,0) (32,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 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 (i)

Hence, here are some parameters for analysing handover delay in table 5.1:
Parameter Definition
Tadd-IP mSCTP Add-IP time
Tdel-IP mSCTP Delete-IP time
Tset-primary-IP mSCTP set-primary-IP time
TASCONF mSCTP ASCONF chunk send delay
TASCONF- ACK mSCTP ASCONF-ACK chunk send delay
TRD Router discovery period
TDAR DAR procedure period between MN_0 and MN_1
TmSCTP 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 (ii)

From equation (i), TmSCTP = TDAR (iii)

Here, The DAR procedure period is composed of the ASCONF parameters sent
from MN_0 to MN_1.

Therefore, TDAR = TaddIP + TsetprimaryIP + TdelIP (iv)

While, TaddIP = TASCONF + TASCONF-ACK (v)
TsetprimaryIP = TASCONF + TASCONF-ACK (vi)
TdelIP = TASCONF + TASCONF-ACK (vii)

Accordingly, mSCTP handover delay can be expressed as:

TmSCTP = (TaddIP + TsetprimaryIP + TdelIP) (viii)

Ideally for SCTP router discovery time can be overlooked because of the multi-
homing 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 MN_1 Simultaneous Simultaneous
No overlap
Overlaps overlaps overlap Handover
1 time 1 time No 28 times 0 time

Table 5.2: Simulation results showing overlapping number

Here, with this observation, we derive the formula for calculating average
step_length.
Total distances travelled within total runs
Average step_length = (ix)
Number of simulation runs
= 638.1 30 = 21.27 approx.: 22 steps.

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 MN_0 MN_1 MN_1 Simultaneous No Simultaneous
overlaps handover overlaps handover overlap overlap Handover
08 times 13times 02 time 07 times 05 times 5 times 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 MN_0 MN_1 MN_1 Simultaneous Simultaneous Sequential

overlaps handover overlaps handover overlap handover handover
07 times 27 times 03 times 23 times 20 times 20 times 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 Add-
IP 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: Showing the Add-IP and Delete-IP in mSCTP connection

procedure

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 (Add-
IP) 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 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 No Location

handover management Location Management
measurement
MN_0, MN_1 MN_0 MN_1 MN_0, MN_1
Handover Handover Handover Handover
random Simultaneous Simultaneous Simultaneous
Movement Movement Movement Movement
Without LS With LS With LS With LS
Tadd-IP 0.692478 0.67959 0.679591 0.67959
Tset-primary-IP 0.654933 0.65468 0.654683 0.654681
Tdel-IP 0.659489 0.654897 0.654901 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 MN_0 [ms] MN_1 [ms] MN_0+MN_1, [ms] Avg,[ms]

Latency
Improvement 17.7330 17.725 17.7300 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, is the unknown value.

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

95 % Confidence Boundaries [ms]

Avg [s] Std.-dev [s]
Interval (upper bound, lower bound)
1.989170 (v1) 2.16670 1.96 (3.94917, 0.02917)

1.989154 (v2) 2.71871 1.96 (3.94915, 0.02915)

1.989167 (v3) 4.08221 1.96 (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 next-
generation 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/T-
110.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 Trade-
Off 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 Zone 1
Step_Length MN_0_Init MN_0_New MN_1_Init MN_1_New
6 84 90 534 528
16 276 292 396 380
14 308 322 508 494
14 352 366 504 490
45 308 353 501 456
9 310 319 402 393
18 352 370 381 363
37 161 198 381 344
31 311 342 470 439
34 331 365 438 404
35 300 335 446 411
5 330 335 387 382
12 284 296 449 437
30 58 88 494 464
3 150 153 476 473
31 220 251 498 467
44 84 128 513 469
20 308 328 423 403
10 150 160 473 463
3 102 105 432 429
14 316 330 411 397
4 149 153 454 450
43 56 99 422 379
45 54 99 440 395
8 108 116 513 505
2 262 264 379 377
28 356 384 407 379
6 255 261 388 382
33 315 348 524 491
35 158 193 515 480
32 332 364 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 MAXX = 0.0;

double MAXY = 0.0;
double MAXSPEED = 0.0;
double PAUSE = 0.0;
u_int32_t NODES = 0;
u_int32_t RouteChangeCount = 0;
u_int32_t LinkChangeCount = 0;
u_int32_t DestUnreachableCount = 0;

Node *NodeList = 0;
u_int32_t *D1 = 0;
u_int32_t *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 + min(t1, t2);
m2->time_transition = TIME + min(t1, t2);
}
else if(t1 > 0.0) {
m1->time_transition = TIME + t1;
m2->time_transition = TIME + t1;
}
else {
m1->time_transition = TIME + t2;
m2->time_transition = TIME + 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