Spectrum Sensing Through Implementation of USRP2

Spectrum Sensing Through Implementation of USRP2
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
Blekinge Institute of Technology
371 79 Karlskrona
Sweden
Internet
Phone
Fax
: www.bth.se/com
: +46 455 38 50 00
: +46 455 38 50 57
ii
ACKNOWLEDGMENT
We really want to thank our supervisor Mr. Alexandru Propescu for his time,
guidance, support and friendly attitude towards us all the time. His valuable advices
paved the way for our research. We would like to extend our thanks to Dr. David
Erman for providing us the experimental equipments and to Mr. Yong Yao, his
interest towards our research and guiding us from precision towards accuracy.
We would also like to thank our families for their support, both financially and
morally. Last but not least we like to say thanks to our friends in Sweden, they make
our stay memorable and joyful.
Adnan Aftab and M. Nabeel Mufti
ABSTRACT
Scarcity of the wireless spectrum has led to the development of new techniques
for better utilization of the wireless spectrum. Demand for high data rates and
better voice quality is resulting in the development of new wireless standard
making wireless spectrum limited than ever. In this era of wireless
communication, service providers and telecom operators are faced with a
dilemma where they need a large sum of the wireless spectrum to meet the ever
increasing quality of service requirements of consumers. This has led to the
development of spectrum sensing techniques to find the unused spectrum in the
available frequency band.
The results presented in this thesis will help out in developing clear
understanding of spectrum sensing techniques. Comparison of different
spectrum sensing approaches. The experiments carried out using USRP2 and
GNU radio will help the reader to understand the concept of underutilized
frequency band and its importance in Cognitive Radios.
Keywords: Cognitive Radio, Spectrum sensing, GNU Radio, USRP2.
ii
Contents
ACKNOWLEDGMENT .......................................................................................................................I
ABSTRACT ......................................................................................................................................... II
List of abbreviation ………………………………………………………………………….iv
List of Figures ……………………………………………………………………………….vi
List of Tables ……………………………………………………………………………….vii
1
INTRODUCTION ....................................................................................................................... 1
1.1
1.2
1.3
2
AIMS AND OBJECTIVES ........................................................................................................... 1
RESEARCH QUESTIONS .......................................................................................................... 1
THESIS OUTLINE ..................................................................................................................... 2
SPECTRUM SENSING............................................................................................................... 4
2.1
COGNITIVE RADIO OPERATION .............................................................................................. 5
2.2
TYPES OF SPECTRUM SENSING ............................................................................................... 5
2.2.1 Energy Detection .............................................................................................................. 6
2.2.2 Cyclostationary Method .................................................................................................... 6
2.2.3 Matched filter detection .................................................................................................... 7
2.2.4 Wavelet Detection ............................................................................................................. 7
2.3
QUALITATIVE ANALYSIS OF SPECTRUM SENSING TECHNIQUES ............................................... 8
2.4
RADIO SPECTRUM OVERVIEW................................................................................................. 8
2.5
RELATED WORK ................................................................................................................... 10
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
ADC
CPC
CPU
DAC
dBm
DC
DDC
DSSS
DUC
F
FFT
FPGA
GHz
GUI
HPSDR
IEEE
Ampere
Analogue to Digital Converter
Cognition enabling pilot channel
Central processing unit
Digital to analogue converter
Milliwatt-decibel
Direct current
Digital down converter
Direct sequence spread spectrum
Digital up converter
Frequency
Fast Fourier transforms
Field programmable gate arrays
Giga hertz
Graphical user interface
High power software defined radio
Institute of Electrical and Electronic
Engineer
Intermediate frequency
Internet protocol
Industrial Scientific Medical
International telecommunication union
Media access control
Mega hertz
Multi input multi output
Millimeter
Mega samples
Open source SCA implementation
embedded
Primary user
Physical
Radio detection and ranging
Radio frequency
Software Communication Architecture
Software defined radio
Signal to noise ratio
Secondary user
Simplified wrapper and interface grabber
Unlicensed based cognitive radio
IF
IP
ISM
ITU-T
MAC
MHZ
MIMO
Mm
MS
OSSIE
PU
PHY
RADAR
RF
SCA
SDR
SNR
SU
SWIG
UBCR
iv
Acronym
Description
UDP
UHD
USB
USRP
WiFi
WPAN
WT
User datagram protocol
Universal hardware devices
Universal serial buss
Universal software radio peripheral
Wireless Fidelity
Wireless personal area network
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 CR‟s operation
comprises of four states as shown in the Figure 2.2. First the available spectrum
is sensed and analyzed to find any available spectrum holes. On the basis of
spectrum analysis a decision is made to opportunistically assign the available
frequency to the secondary user. Spectrum sensing is the most integral part of
CR because all the remaining operations of CR rely on precise sensing of
available spectrum [18].
Spectrum
Decision
Radio
Environment
Spectrum
Analyzing
Spectrum
Sensing
Figure 2.2 Cognitive Radio operation
2.2
Types of Spectrum Sensing
The most important task of spectrum sensing is transmitter detection. Spectrum
sensing plays a key role in the decision making part of CR. There are several
different ways to sense the spectrum. Some of the key methods used for
spectrum sensing are as follows:
1.
2.
3.
4.
Energy Detection
Cyclostationary Method
Matched Filter detection
Wavelet detection
Explanation and comparison of all four methods is given below.
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,
it‟s 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
method‟s working principal can be explained with the Figure2.3
X(t)
Fast
Fourier
Transform
X(f)
Windowing
the Peak
Y(f)
FFT
Magnitude
Decide H0 or H1
Figure 2.3: Energy Detection method
2.2.2
Cyclostationary Method
A Cyclostationary process is defined as the statistical process which repeats
itself cyclically or periodically [6]. Communication signals are Cyclostationary
with multiple periodicities. Mathematically Cyclostationary detection can be
performed as given in equation (3):
𝑹𝒙 𝑻 = 𝑬 𝒙 𝒕 + 𝑻 𝒙∗ 𝒕 − 𝑻 e−j2απ 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)
X(f)
FFT
Decide H0 or H1
Correlation of
x(f+α)x*(f-α)
S(f,α)
Cyclic freq.
Detector
Figure 2.4: Cyclostationary Detection [10]
2.2.3
Matched filter detection
In the matched filter detection method a known signal is correlated with an
unknown signal captured from the available radio resource to detect the
presence of pattern in the unknown signal [6]. Matched filter detection method
is commonly used in Radio Detection and Ranging (RADAR) communication
[10]. The use of matched filter detection is very limited as it requires the prior
information about the unknown signal. For example in case of GSM, the
information about the preamble is required to detect the spectrum through
matched filter detection method. In case of WiMAX signal prior information
about the Pseudo Noise (PN) sequence is required for detection of spectrum.
2.2.4
Wavelet Detection
To detect the wideband signals, wavelet detection method offers advantage
over the rest of the methods in terms of both simplicity and flexibility. It can be
used for dynamic spectrum access. To identify the white spaces or spectrum
holes in the available radio resource, the entire spectrum is treated as the
sequence of frequency sub-bands. Each sub-band of frequency has smooth
power characteristics within the sub-band but changes abruptly on the edge of
next sub-band. By using the wavelet detection method the spectrum holes can
be found at a given instance of time by finding the singularities in the attained
result [10]. The Figure 2.5 shows the wavelet detection implementation for
spectrum sensing.
X(t)
Fast
Fourier
Transform
X(f)
Power spectral
density of X(f)
magnitude
Decide H0 or H1
S(f)
Local maximum
Detection
Figure 2.5: Wavelet Detection method
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
Does not require prior
Energy Detection
information, Efficient, less
complex
Cyclostationary
Works perfectly in low
SNR areas, robust against
interference
Matched Filter
Low computation cost,
accurate detection
Works efficiently for
wideband signal detection
Wavelet Detection
Disadvantages
Limited functionality in
low SNR areas, cannot
differentiate between PU
and SU
Requires
fractional
information about the PU,
less efficient in terms of
computation cost
Requires prior information
about PU
Does not work for DSSS,
more complex
It can clearly be seen from table1 that energy detection is the most suitable
technique for unlicencessed spectrum bands as it does not require any prior
information about the PU and SU.
2.4
Radio spectrum overview
Radio spectrum comprises of electromagnetic frequencies ranging lower than
30GHz or having wavelength larger than 1milimeter (mm). Various parts of the
radio spectrum are allocated for different kinds of communication application
varying from microphones to satellite communication. Today, in most of the
countries radio spectrum is government regulated i.e. governments and some
other governing bodies like International Telecommunication Union (ITU-T)
assign the radio spectrum parts to communication services [1].
There are several different frequency bands defined inside the radio spectrum
on the basis of wavelength (λ) and frequency (f). Generically radio spectrum
can be classified into two categories as licensed spectrum and unlicensed
spectrum. Licensed spectrum comprises of frequency bands governed by
government regulated agencies. It is illegal to use licensed frequency spectrum
without taking permission from the regulatory bodies. Unlicensed frequency
bands can be used by anyone for any scientific or industrial research.
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
13.553–13.567 MHz
26.957–27.283 MHz
40.66–40.70 MHz
433.05-434.79 MHz
902-928 MHz
2.400-2.500 GHz
5.725-5.875 GHz
24-24.25 GHz
61-61.5 GHz
122-123 GHz
244-246 GHz
6.785MHz
13.560 MHz
27.120 MHz
40.68 MHz
433.92 MHz
915 MHz
2.450 GHz
5.800 GHz
24.125 GHz
61.25
122.5 GHz
245 GHz
ITU Region2 only
Most commonly used ISM bands are 2.4GHz and 5.8GHz band. Though these ISM
bands were reserved for the purpose of research but currently these bands are used
for different wireless communication standards. Examples of these bands are
Wireless Local Area Network defined by Institute of Electrical and Electronics
Engineers (IEEE) as 802.11a/b/g/n, Wireless Personal Area Network (WPAN)
defined by IEEE as 802.15 and Cordless phones which operate in the range of
915MHz, 2.4GHz, and 5.8GHz. The research carried out in this thesis is performed
using the 2.4GHz and 5.8GHz ISM band commonly used for WLAN and defined by
IEEE as 802.11. 802.11 standards have defined 13 channels in the range of
2412MHz to 2472MHz [23]. Each channel is 5MHz apart from each other and all the
adjacent channel overlap with each other as each channel is 22MHz wide as shown
in Figure 2.6.
Figure 2.6: Channel allocation in 2.4GHz ISM band [23]
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
C++
C++
C++
C++
C++
SWIG
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
EXECUTION
ADC
RECEIVE RF FRONT END
RX PATH
TRANSMIT RF FRONT END
DAC
CODE
EXECUTION
TX PATH
Figure 3.3: Basic Software Radio
3.3
USRP2 Architecture and Overview
USRP2 allows the creation of a software radio with any computer having
gigabit Ethernet interface. It‟s the upgraded version of its earlier release USRP.
USRP has a USB interface limiting the data throughput from USRP to
Computer at a maximum bandwidth of 8MHz. The design of USRP and
USRP2 is open source and all schematics and component information can be
downloaded from the website of the manufacturer [2]. USRP2 contains field
programmable gate arrays (FPGA) and RF transceiver board which is
connected over FPGA.
14
The main idea behind the design of USRP is to perform all the signal
processing tasks for example modulation and demodulation, filtering at the host
computer. All the general purpose tasks such as decimation, interpolation,
digital up conversion and down conversion are performed inside the FPGA of
USRP2. The Figure 3.4 shows the image of USRP2 with RF daughter board.
USRP2 contains gigabit Ethernet controller, SD card slot and MIMO expansion
slot at the front end with 8 LED indicators. SD card contains the driver for
USRP2 mother board and RF transceiver. It requires 5V DC and 6A to power
up USRP2 [2]. The main features of USRP2 are given in table 3.
Figure 3.4: USRP2 Motherboard and RF daughter card XCVR 2450
15
RX
TX
SD
Memory
MIMO
Expansion
Ethernet
Interface
Figure 3.5: USRP2 Front end
Table 3: Main features of USRP2
Interface
FPGA
RF Bandwidth
ADC
DAC
Daughterboard slots
SRAM
Power
3.3.1
Gigabit Ethernet
Xilinx Spartan 3 2000
25MHz
14 bits, 100MS/s
16 bits, 400 MS/s
1 Tx, 1 Rx
1 MB
5V DC, 3A
USRP2 Operation with GNU Radio
USRP2 operation with GNU Radio can be explained with the help of Figure
3.6. RF transceiver fetches the RF signal from real time environment and
converts it to Intermediate Frequency (IF) around direct current (DC) using
digital down converter (DDC). After converting it to IF the signal is passed to
ADC. USRP2 contains 14-bit ADC converter which provides sampling rate of
100MS/s [2]. The ADC after sampling passes the data to FPGA. The main task
for the FPGA is the down conversion of remaining frequency and data rate
conversion. After processing, FPGA transfers the results to gigabit Ethernet
controller which passes it over to the host computer where the rest of the signal
processing tasks are performed.
16
In case of transmission the same procedure is repeated in reverse order. Firstly
gigabit Ethernet controller of host computer passes the input parameters to
USRP2. After receiving, the complex signal, digital up converter (DUC)
converts the signal to IF before passing it to DAC. The DAC passes the IF
converted signal to the RF transceiver where it is converted to RF signal and
transmitted over the air.
ANTENNA
USRP2
RF DAUGHTER
BOARD
ADC/DAC
APPLICATION
PYTHON
DSP
PROCESSING
XILINX FPGA
DSP BLOCK
C++ ROUTINES
GIGABIT
ETHERNET
CONTROLLER
GIGABIT
ETHERNET
CONTROLLER
HOST PC WITH
GNU RADIO
Figure 3.6: USRP2 operation with GNU Radio
17
Chapter 4
Energy detection implementation
using USRP2 and GNU Radio
18
4
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
Tunning
Parameter
FFT Magnitude
Decimation
Sink
Figure 4.5: USRP2_spectrum.py flow chart
The spectrum sensing algorithm steps across the RF spectrum and takes the
measurement in terms of FFT magnitude bins. The number of FFT bins, gain,
decimation, time delay, dual delay and frequency range are forwarded to the
USRP2_spectrum.py as tuning parameters.
The minimum number of bins is 3 and the maximum is 1024 bins. The FFT
magnitude bins received at a certain frequency consist of 2 parts. First half of
the bins i.e. FFT X[1] to FFT X[N/2 - 1] corresponds to the pass band spectrum
from the center frequency (fc) to +Fs/2. Whereas the rest of the bins from X
[N/2 - 1] to X [N-1] contains spectrum from center frequency to –Fs/2. Here
X[1] represents the first bin value as shown in appendix B and X[N/2 - 1]
represents the middle bin value. For example if we have 256 bins at 2402 MHz
with 8MHz frequency step, the bin 0 to 127 corresponds to 2398 MHz to 2402
MHz and the rest of the bins correspond to 2402 MHz to 2406 MHz.
The gain parameter sets the gain of tuner card. By default the gain of the card is
set to half of maximum gain which is 45dBm in case of XCVR2450. The time
delay and dual delay parameters depends upon the decimation rate and length
of FFT. By default decimation rate is set to 16 with 256 FFT bins and with time
delay of 1ms. Time delay is a key parameter without setting the correct time
delay the results could be altered or false. The reason for it is time delay
displaying the amount of FFT frames from the source to sink should be
23
forwarded in the defined time. Time delay for a given decimation rate and FFT
size can be calculated as follows:
No. of FFT Frames = (Decimation Rate * Time delay) / FFT window Size
(4)
In practice to reduce the non linear response of the DDC we performed FFT
overlapping. Without FFT overlapping we were getting white spaces at the end
of every sweep. We choose an overlap minimum of 25% i.e. we defined the
step size to 8MHz for every step. In some cases we even choose overlapping of
0.75% to get the step size of 1MHz, so that we can get as accurate results as
possible. The USRP2_spectrum.py is invoked in the following manner:
$ Sudo python USRP2_spectrum.py –a2.4G –b2.5G –g45 –d8 >rx.dat
The time delay parameter is set to 1ms in the code by default. –a represents the
starting frequency and –b represents the last frequency, -g is used to set the
gain parameter and-d8 represents that we are using decimation of 8.Decimation
rate of 8 means that USRP2 processed 12.5MS/sec during execution of code.
The USRP2_spectrum.py is provided in appendix A at the end of the thesis.
The typical output of running USRP2_spectrum.py will give us the FFT
magnitude bins at a given center frequency. The gain at any given center
frequency can be calculated by summing the values of all the bins and by
taking square root of the result. After that by taking 20*log(x), where x is the
square root of the sum of the bins, we can get the result in dBm.
The experiments were carried out in Room G403 of Building2 at Blekinge
institute of technology (BTH) in Karlskrona, Sweden. Most of the results were
collected during the same project room except a few instances where the results
were collected in the cafeteria while turning on the microwave to check the
performance of the algorithm in presence of high noise.
4.3
Project Limitations
Project limitations can be classified into two categories i.e.
 Hardware limitations
 Energy Detection Algorithm limitations
4.3.1
Hardware Limitations
The results were attained using decimation rate of 8.i.e 12.5MS/sec. More
precise results can be obtained by using lower decimation value. USRP2 can
monitor maximum bandwidth of 25MHz. The receiver sensitivity can be
increased by using a high gain antenna with the tuner card.
24
4.3.2
Energy detection Algorithm limitations
As previously mentioned energy detection based algorithms cannot
differentiate between PU and SU [11]. The results are solely based on the
threshold level received, or the energy level measured from the
environment. Energy detection method cannot be used in a low noise setup.
The implemented routine can sense large bandwidth but not at the same
time as it steps across the RF spectrum with the change in time domain.
25
Chapter 5
Results
26
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 3dimensional (3D) plots and time, frequency spectrograms.
Figure 5.1 shows the results obtained for 2.4GHz ISM band by using a
frequency step of 20MHz i.e. the above defined routine steps across the ISM
band in steps of 20MHz starting from 2.4GHz and ending at 2.502G. As it can
be observed from the graph, it is hard to find the exact channel utilization of
802.11 WiFi spectrum due to large sweeps across the spectrum. Figure 5.3
shows the same results in 3-dimensions (3-D) by using another axis for time.
The advantage of time axis is that we can monitor the results at any given
instance of time.
Figure 5.1: FFT magnitude plot for 2.4GHz band with 20MHz frequency
step
27
Figure 5.2: Frequency vs. Gain plot for 2.4-2.5GHz ISM band
Figure 5.3: Time, Frequency, and Gain 3D plot for 2.4GHz-2.5GHz using
20MHz frequency step
28
The results obtained using a smaller step of 10MHz is shown in Figure 5.4. We
can easily find the channel utilization of campus WLAN by looking at Figure
5.4 and Figure 5.5. The spikes around 2.43x109 Hz in the plot show the use of
Channel 7 at the time of data collection. Frequency and magnitude plots
provide us gain at a given frequency but still it‟s 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 didn‟t 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. 523–531, 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. 13–18, Aug. 1999.
[19] K. Arshad and K. Moessner, “Impact of User Correlation on Collaborative
Spectrum sensing for Cognitive Radio,” in proc. ICT Mobile Summit 2009, 10-12
June „09, Satander, Spain.
[20] D.Cabric.S.M., Mishra.R.W., Brodersen, “Implementation Issues in Spectrum
Sensing”, In Asilomar Conference on Signal, Systems and Computers, November
2004.
[21] Zhi Yan, Zhangchao Ma, Hanwen Cao, Gang Li, and Wenbo Wang, “Spectrum
Sensing, Access and Coexistence Test bed for Cognitive Radio Using USRP”, 4th
IEEE International Conference on Circuits and Systems for Communications, 2008.
ICCSC 2008, 26-28 May 2008.
[22] GNURadio Wiki, http://gnuradio.org/redmine/wiki/gnuradio
[23] Wikipedia, http://en.wikipedia.com
[24] SCA based open source software defined radio, http://ossie.wireless.vt.edu/
[25] High Performance Software Defined Radio (HPSDR), http://hpsdr.org/
[26] Flex Radio, http://www.flex-radio.com/
41
Appendix A
Code of USRP2_spectrum.py is written in python language. The modified part of the code is
in italics. The rest of the code is taken from usrp_spectrum_sense.py which is a standard
routine available in GNU Radio, and works for USRP first release only. There might be
some indentation errors in the routine which can easily be fixed by copying the code in any
standard python editor e.g. IDLE.
#!/usr/bin/env python
# Copyright 2005,2007 Free Software Foundation, Inc.
# This file is part of GNU Radio
from gnuradio import gr, gru, eng_notation, window
from gnuradio import usrp2
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import sys
import math
import struct
class tune(gr.feval_dd):
"""
This class allows C++ code to call back into python.
"""
def __init__(self, tb):
gr.feval_dd.__init__(self)
self.tb = tb
def eval(self, ignore):
try:
new_freq = self.tb.set_next_freq()
return new_freq
except Exception, e:
print "tune: Exception: ", e
class parse_msg(object):
def __init__(self, msg):
self.center_freq = msg.arg1()
self.vlen = int(msg.arg2())
assert(msg.length() == self.vlen * gr.sizeof_float)
t = msg.to_string()
self.raw_data = t
42
self.data = struct.unpack('%df' % (self.vlen,), t)
class my_top_block(gr.top_block):
def __init__(self):
gr.top_block.__init__(self)
parser = OptionParser(option_class=eng_option)
parser.add_option("-e", "--interface", type="string", default="eth0", help="Select
ethernet interface. Default is eth0")
parser.add_option("-m", "--MAC_addr", type="string", default="", help="Select
USRP2 by its MAC address.Default is auto-select")
parser.add_option("-a", "--start", type="eng_float", default=1e7, help="Start
ferquency [default = %default]")
parser.add_option("-b", "--stop", type="eng_float", default=1e8,help="Stop
ferquency [default = %default]")
parser.add_option("", "--tune-delay", type="eng_float", default=10e-1,
metavar="SECS", help="time to delay (in seconds) after changing frequency
[default=%default]")
parser.add_option("", "--dwell-delay", type="eng_float",default=100e-1,
metavar="SECS", help="time to dwell (in seconds) at a given frequncy
[default=%default]")
parser.add_option("-g", "--gain", type="eng_float", default=None,help="set gain in dB
(default is midpoint)")
parser.add_option("-s", "--fft-size", type="int", default=256, help="specify number of
FFT bins [default=%default]")
parser.add_option("-d", "--decim", type="intx", default=16, help="set decimation to
DECIM [default=%default]")
parser.add_option("-i", "--input_file", default="", help="radio input file",
metavar="FILE")
(options, args) = parser.parse_args()
if options.input_file == "":
self.IS_USRP2 = True
else:
self.IS_USRP2 = False
self.min_freq = options.start
self.max_freq = options.stop
if self.min_freq > self.max_freq:
self.min_freq, self.max_freq = self.max_freq, self.min_freq # swap them
print "Start and stop frequencies order swapped!"
self.fft_size = options.fft_size
# build graph
s2v = gr.stream_to_vector(gr.sizeof_gr_complex, self.fft_size)
mywindow = window.blackmanharris(self.fft_size)
fft = gr.fft_vcc(self.fft_size, True, mywindow)
43
power = 0
for tap in mywindow:
power += tap*tap
c2mag = gr.complex_to_mag_squared(self.fft_size)
#log = gr.nlog10_ff(10, self.fft_size, -20*math.log10(self.fft_size)10*math.log10(power/self.fft_size))
# modifications for USRP2
if self.IS_USRP2:
self.u = usrp2.source_32fc(options.interface, options.MAC_addr)
self.u.set_decim(options.decim)
samp_rate = self.u.adc_rate() / self.u.decim()
else:
self.u = gr.file_source(gr.sizeof_gr_complex, options.input_file, True)
samp_rate = 64e6 / options.decim
self.freq_step =0.75* samp_rate
self.min_center_freq = self.min_freq + self.freq_step/2
nsteps = math.ceil((self.max_freq - self.min_freq) / self.freq_step)
self.max_center_freq = self.min_center_freq + (nsteps * self.freq_step)
self.next_freq = self.min_center_freq
tune_delay = max(0, int(round(options.tune_delay * samp_rate / self.fft_size))) # in
fft_frames
dwell_delay = max(1, int(round(options.dwell_delay * samp_rate / self.fft_size))) # in
fft_frames
self.msgq = gr.msg_queue(16)
self._tune_callback = tune(self)
# hang on to this to keep it from being GC'd
stats = gr.bin_statistics_f(self.fft_size, self.msgq, self._tune_callback, tune_delay,
dwell_delay)
self.connect(self.u, s2v, fft,c2mag,stats)
if options.gain is None:
# if no gain was specified, use the mid-point in dB
g = self.u.gain_range()
options.gain = float(g[0]+g[1])/2
def set_next_freq(self):
target_freq = self.next_freq
self.next_freq = self.next_freq + self.freq_step
if self.next_freq >= self.max_center_freq:
self.next_freq = self.min_center_freq
if self.IS_USRP2:
if not self.set_freq(target_freq):
print "Failed to set frequency to ", target_freq, "Hz"
return target_freq
def set_freq(self, target_freq):
44
return self.u.set_center_freq(target_freq)
def set_gain(self, gain):
self.u.set_gain(gain)
def main_loop(tb):
while 1:
m = parse_msg(tb.msgq.delete_head())
print m.center_freq
print m.data
.
if __name__ == '__main__':
tb = my_top_block()
try:
tb.start()
# start executing flow graph in another thread..
main_loop(tb)
except KeyboardInterrupt:
pass
45
Appendix B
Raw data format
First few samples of data collected through USRP2 and GNU radio using
USRP2_spectrum.py. The values in the parenthesis are the FFT magnitudes at the
center frequency mentioned at beginning of brackets.
2402343750.0
(0.078479491174221039,
0.0021366067230701447,
0.0016706101596355438,
0.0014919996028766036,
0.0018371485639363527,
0.0038519951049238443,
0.0045247073285281658,
0.0043287002481520176,
0.0052246819250285625,
0.0072058727964758873,
0.010452025569975376,
0.010121340863406658,
0.028328873217105865,
0.029274577274918556,
0.017359867691993713,
0.060994364321231842,
0.07691742479801178,
0.045997627079486847,
0.078885406255722046,
0.68123906850814819,
1.815961480140686,
1.7410080432891846,
0.92414122819900513,
1.2561960220336914,
1.3696602582931519,
2.2194290161132812,
1.8912926912307739,
0.67372077703475952,
1.8998949527740479,
2.9818150997161865,
3.6183938980102539,
1.1647709608078003,
0.80838441848754883,
2.5064244270324707,
2.6447768211364746,
0.85805624723434448,
0.77822285890579224,
1.066877007484436,
1.385168194770813,
0.77945518493652344,
0.52458691596984863,
0.81339508295059204,
0.57239365577697754,
0.44689875841140747,
0.077040821313858032,
0.15660923719406128,
0.35701039433479309,
0.040066912770271301,
0.001107402378693223,
0.0020320124458521605,
0.001333131454885006,
0.0019112494774162769,
0.0029116699006408453,
0.0043828110210597515,
0.0051233791746199131,
0.0079239737242460251,
0.0083901183679699898,
0.011384587734937668,
0.0098102204501628876,
0.016683906316757202,
0.02120569534599781,
0.021779812872409821,
0.085704058408737183,
0.087469212710857391,
0.036451626569032669,
0.2981133759021759,
0.5712742805480957,
3.1547107696533203,
1.8966439962387085,
0.65502303838729858,
1.0833464860916138,
1.6419686079025269,
1.4921739101409912,
1.1128083467483521,
0.99898803234100342,
1.767426609992981,
4.2489080429077148,
1.8145967721939087,
0.6286810040473938,
1.0932257175445557,
1.6184374094009399,
1.5150642395019531,
0.80695647001266479,
0.97723042964935303,
1.6649191379547119,
1.2304015159606934,
0.60114175081253052,
0.36764374375343323,
0.50622117519378662,
0.62805533409118652,
0.17851966619491577,
0.13759393990039825,
0.11775496602058411,
0.25196456909179688,
0.0055190813727676868,
0.0019328504567965865,
0.0034777612891048193,
0.0016256794333457947,
0.0021049873903393745,
0.0028225337155163288,
0.0036936171818524599,
0.004700744990259409,
0.0079878270626068115,
0.012011573649942875,
0.010718739591538906,
0.023751826956868172,
0.021510237827897072,
0.018909499049186707,
0.028562052175402641,
0.062144704163074493,
0.061169750988483429,
0.047624539583921432,
0.56199336051940918,
1.022626519203186,
2.9904580116271973,
1.0949727296829224,
0.88575261831283569,
1.6493371725082397,
2.719914436340332,
1.3443087339401245,
0.46113380789756775,
1.1562153100967407,
2.2555630207061768,
4.9478602409362793,
1.5198602676391602,
0.62178975343704224,
2.4948527812957764,
1.942987322807312,
1.6680817604064941,
0.5647236704826355,
1.0299559831619263,
2.0907723903656006,
0.62880885601043701,
0.75301861763000488,
0.44105544686317444,
0.48039990663528442,
0.63090991973876953,
0.14225435256958008,
0.16485799849033356,
0.26699408888816833,
0.11670123040676117,
46
0.055269010365009308,
0.045230839401483536,
0.031556162983179092,
0.012226605787873268, 0.0099316556006669998, 0.0070943846367299557,
0.0052436715923249722, 0.0052291429601609707, 0.0065299035049974918,
0.0034304608125239611, 0.0031522943172603846, 0.0027866777963936329,
0.0019167417194694281, 0.001906857592985034, 0.0013906561071053147,
0.0012801015982404351, 0.0010967451380565763, 0.0025738335680216551,
0.011629209853708744,
0.021526094526052475,
0.011421794071793556,
0.0024552359245717525,
0.00081654638051986694,
0.00074491609120741487,
0.00087696971604600549,
0.00078586529707536101,
0.00071032048435881734,
0.0006499909795820713, 0.00068799924338236451, 0.000849866250064224,
0.00079919432755559683,
0.00075856858165934682,
0.00078854116145521402,
0.00071194040356203914,
0.00067059422144666314,
0.00084492011228576303,
0.00076157570583745837,
0.0007594208000227809,
0.00067484361352398992,
0.00076539855217561126,
0.00088167772628366947,
0.00084834126755595207,
0.0008001718670129776,
0.00080491398693993688,
0.00095775781664997339,
0.00075492350151762366,
0.00084168644389137626,
0.0007911412394605577,
0.0012192637659609318,
0.0012803474674001336,
0.00072430918226018548,
0.00075210718205198646,
0.00084508676081895828,
0.0011267503723502159,
0.0014678185107186437,
0.0011142620351165533,
0.00083363440353423357,
0.0008323927759192884,
0.0007781044696457684,
0.00071245571598410606,
0.0008046915172599256,
0.00094067084137350321,
0.00068867631489410996,
0.00078109797323122621,
0.00084381789201870561,
0.00072479399386793375,
0.00095712661277502775,
0.0008555956301279366,
0.00076716899638995528,
0.00076011696364730597,
0.00097077444661408663,
0.0008456491632387042,
0.00081668398343026638,
0.00072018272476270795,
0.0010230715852230787,
0.00076872180216014385,
0.00068192993057891726,
0.00083688297308981419,
0.00079831457696855068,
0.0010027461685240269,
0.00083487335359677672,
0.00078005483373999596,
0.00081469607539474964,
0.0007705554598942399,
0.00089630088768899441,
0.00071952160215005279,
0.00078048795694485307,
0.00071756489342078567,
0.00082102115266025066,
0.00071246037259697914,
0.0012075777631253004,
0.0011661506723612547,
0.00073863635770976543,
0.00073408539174124599,
0.00086960755288600922,
0.000859142339322716,
0.00086273468332365155,
0.00085836776997894049,
0.0010911953868344426,
0.00086930743418633938,
0.0008030780591070652,
0.00081013055751100183,
0.0008304059156216681, 0.0013898427132517099, 0.0014285683864727616,
0.00084563024574890733,
0.00078523502452298999,
0.00087360222823917866,
0.0013947460101917386,
0.0014321762137115002, 0.0013469539117068052, 0.0011599337449297309,
0.0011492453049868345, 0.003844299353659153, 0.037321273237466812)
2407031250.0
(3.1974740028381348,
4.031559944152832,
3.217695951461792,
2.0523378849029541,
2.2461001873016357,
3.2930624485015869,
2.9177732467651367,
3.1102924346923828,
2.8934581279754639,
3.1583716869354248,
5.5028438568115234,
3.4998223781585693,
3.728071928024292,
2.8119258880615234,
4.1116776466369629,
4.5282888412475586,
6.4161314964294434,
5.9056835174560547,
5.3880019187927246,
5.1316804885864258,
3.1722424030303955,
3.2820501327514648,
3.5894057750701904,
5.1031947135925293,
47
5.9944367408752441,
4.9885139465332031,
3.0611209869384766,
3.3806934356689453,
4.0355067253112793,
5.950444221496582,
4.3682861328125,
6.3907628059387207,
6.3701944351196289,
7.0584292411804199,
6.152287483215332,
13.17851448059082,
10.31685733795166,
6.7908363342285156,
4.681190013885498,
6.555757999420166,
7.2733640670776367,
4.9511837959289551,
7.0115170478820801,
7.5073418617248535,
5.7620663642883301,
10.491754531860352,
8.545628547668457,
7.1336016654968262,
10.993707656860352,
14.538098335266113,
8.4462566375732422,
4.5616464614868164,
5.8710637092590332,
6.3135218620300293,
6.3264636993408203,
3.255685567855835,
4.3830351829528809,
2.7397422790527344,
1.7573552131652832,
1.76539146900177,
1.5097736120223999,
0.98314499855041504,
1.4055907726287842,
1.4201083183288574,
0.41280713677406311,
0.97726327180862427,
1.6822177171707153,
4.3758697509765625,
1.0595099925994873,
0.49527463316917419,
2.0502135753631592,
2.7550060749053955,
1.1020327806472778,
1.9735193252563477,
1.5492707490921021,
2.4999613761901855,
0.8397904634475708,
0.92863726615905762,
1.8714859485626221,
2.4703466892242432,
3.1873459815979004,
1.166181206703186,
2.7041969299316406,
5.9352045059204102,
3.3433778285980225,
4.7254638671875,
3.4352085590362549,
4.1641387939453125,
3.6395854949951172,
6.711235523223877,
5.0542440414428711,
4.2800970077514648,
7.563817024230957,
6.1517653465270996,
5.2938923835754395,
8.7384729385375977,
11.978425979614258,
6.4902448654174805,
4.5423426628112793,
5.1105408668518066,
7.9897575378417969,
7.8920340538024902,
5.4244108200073242,
7.6162238121032715,
6.3882355690002441,
5.3743562698364258,
8.4772605895996094,
7.9041132926940918,
11.792904853820801,
11.894734382629395,
12.99225902557373,
7.3576827049255371,
3.7589983940124512,
5.2951393127441406,
4.8167567253112793,
3.5456728935241699,
3.4054141044616699,
3.6322879791259766,
2.3923275470733643,
2.1140027046203613,
1.568912148475647,
1.4458366632461548,
0.94674640893936157,
2.5000534057617188,
0.81627821922302246,
0.36113214492797852,
1.1921614408493042,
2.2844400405883789,
2.656505823135376,
0.99709200859069824,
0.95600581169128418,
2.1766338348388672,
2.7532544136047363,
1.4120019674301147,
2.9511003494262695,
2.7556734085083008,
2.2758064270019531,
0.90137410163879395,
1.0676389932632446,
1.8402211666107178,
2.1704912185668945,
2.3636045455932617,
0.81706392765045166,
2.4289414882659912,
8.9075870513916016,
2.0493607521057129,
5.943519115447998,
3.8861455917358398,
4.6584477424621582,
4.581965446472168,
9.182032585144043,
4.2773265838623047,
6.594294548034668,
6.2335686683654785,
7.1196331977844238,
3.7152411937713623,
9.4443597793579102,
10.985051155090332,
6.4896612167358398,
3.9046883583068848,
5.5710554122924805,
8.5431900024414062,
6.0835604667663574,
5.5524086952209473,
7.339911937713623,
6.5758600234985352,
7.7268595695495605,
8.8215827941894531,
7.3362040519714355,
10.975196838378906,
16.446784973144531,
11.927684783935547,
7.5367612838745117,
4.76129150390625,
6.4392209053039551,
6.2896203994750977,
3.480363130569458,
3.8168199062347412,
3.2404756546020508,
2.0473501682281494,
2.6542408466339111,
1.4443670511245728,
1.0355499982833862,
0.99487966299057007,
1.6392966508865356,
0.66750556230545044,
0.7205967903137207,
1.4042747020721436,
3.5576410293579102,
0.94340842962265015,
0.83766782283782959,
1.4233869314193726,
1.9012550115585327,
1.422130823135376,
0.93049532175064087,
1.4158855676651001,
2.8711717128753662,
2.3133275508880615,
1.2856817245483398,
0.9720306396484375,
2.3330845832824707,
2.3740203380584717,
1.2329649925231934,
1.5437220335006714,
2.2527797222137451,
7.1699471473693848,
2.8909635543823242,
48
2.3855693340301514,
0.86046326160430908,
2.473766565322876,
2.5137460231781006,
2.3626995086669922,
1.1714987754821777,
1.8526248931884766,
3.3121376037597656,
1.9961237907409668,
4.7797470092773438,
2.8627450466156006,
3.3258025646209717,
2.6326093673706055,
1.7956358194351196,
2.2838873863220215,
5.9786229133605957,
5.7646760940551758)
2.389784574508667,
0.69971579313278198,
2.5478525161743164,
2.0163238048553467,
1.7347713708877563,
1.5879503488540649,
2.1849963665008545,
3.2454426288604736,
1.9406003952026367,
2.3262240886688232,
3.8520331382751465,
2.3263769149780273,
2.5623633861541748,
1.9629738330841064,
2.4823381900787354,
10.225701332092285,
1.5883164405822754,
1.2471919059753418,
2.6224849224090576,
2.9764595031738281,
1.3939838409423828,
1.2804248332977295,
2.5127692222595215,
2.8538851737976074,
3.7038774490356445,
1.3763785362243652,
3.0856180191040039,
3.5551505088806152,
1.7378360033035278,
2.2246809005737305,
3.0893852710723877,
9.9261703491210938,
49
Appendix C
MATLAB2010 scripts to import and plot the data collected through
USRP2_spectrum.py
1) Script for making frequency, magnitude plot
load rec.dat
x= rec(:,1);
y= rec(:,2);
[n,p]=size(rec)
%b=200;
%z=filter(x,b,y)
figure (1)
plot(x,y);
legend('cycle1','cycle2','cycle3',2)
xlabel('Frequency Range')
ylabel('|FFT|')
title('FFT Magnitude')
%figure (2)
%plot(x,z,'k')
y=y/256;
y=sqrt(y);
y=20*log(y);
figure (2)
plot(x,y);
xlabel('Frequency Range')
ylabel('dB')
title('Gain Plot')
% rec.dat is the raw data file.
2) Script for making time, frequency and magnitude 3D plots
load ad58.dat
x= ad58(:,1);
y= ad58(:,2);
%[n,p]=size(twenty)
z=1:1:71
b=256;
%z=filter(x,b,y)
y=y/256;
y=sqrt(y);
y=20*log(y);
stem3(z,x,y,'k')
title('Time,Freq,Gain 3D plot')
xlabel('Time')
ylabel('Frequency Range')
zlabel('dB')
50
Master Thesis
Electrical Engineering
Thesis no: MEE 10-00
December 2010
Study of Abnormal TCP/HTTP Behavior and its
Relationship with Web User.
Adeel Ashfaq and Umer Bilal
School of Engineering
Blekinge Institute of Technology
37179 Karlskrona
Sweden
This thesis is submitted to the School of Engineering at Blekinge Institute of
Technology in partial 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
Blekinge Institute of Technology
371 79 KARLSKRONA SWEDEN
Internet: www.bth.se/com
Phone: +46 455 385000
SWEDEN
Abstract
Web browsing activites have increased to huge volumes in the last decade,
causing more interest in the analysis of web 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 experimental 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 software’s
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 Documents Outine . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Literature Review
2.1 Significance of Web and Web-Users . . . . . . . . . . . . . .
2.2 Quality of Experience (QoE) and Quality of Service (QoS) .
2.3 TCP Connection Management . . . . . . . . . . . . . . . .
2.4 TCP Reset (RST) . . . . . . . . . . . . . . . . . . . . . . .
2.5 HTTP Protocol and TCP connections . . . . . . . . . . . .
2.5.1 HTTP/1.0 [1] . . . . . . . . . . . . . . . . . . . . . .
2.5.2 HTTP/1.1 . . . . . . . . . . . . . . . . . . . . . . . .
2.6 Persistent Connections and Pipelining . . . . . . . . . . . .
2.6.1 Persistent Connection . . . . . . . . . . . . . . . . .
2.6.2 Pipelining . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Possible approaches for acquiring the behavior of web users
2.7.1 Modified Web Browsers . . . . . . . . . . . . . . . .
2.7.2 Web Proxies . . . . . . . . . . . . . . . . . . . . . .
2.7.3 Packet Monitoring . . . . . . . . . . . . . . . . . . .
2.7.4 Web server Monitoring . . . . . . . . . . . . . . . . .
2.8 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . .
2.8.1 User Surfing Model . . . . . . . . . . . . . . . . . . .
ii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
2
3
. 3
. 3
. 5
. 5
. 6
. 6
. 7
. 7
. 7
. 8
. 8
. 9
. 9
. 9
. 9
. 9
. 10
3 Experiments
3.1 Experiment Methodology . . . . . . . .
3.2 Experiment Setup . . . . . . . . . . . .
3.2.1 Tests without User Interruption .
3.2.2 Tests with user interruptions . .
3.3 Experiment Tools and Technique . . . .
3.3.1 Client server Architecture . . . .
3.3.2 Wireshark Network Analyzer . .
3.3.3 Batch File for automatic browser
3.3.4 Web-servers . . . . . . . . . . . .
3.3.5 Clients . . . . . . . . . . . . . . .
3.3.6 Browsers . . . . . . . . . . . . .
3.3.7 Router . . . . . . . . . . . . . . .
3.3.8 Web Pages . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
opening and closing
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
4 Results and Analysis
4.1 Statistical Analysis for Reset Packets . . . . .
4.2 Packet Capture files analysis . . . . . . . . .
4.2.1 User Uninterrupted Tests . . . . . . .
4.2.2 User Interrupted Tests . . . . . . . . .
4.2.3 Comparison of TCP Flows and Ports .
4.3 User Behaviour Extraction Using TCP Resets
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
13
13
13
14
14
14
15
16
16
16
16
16
.
.
.
.
.
.
.
.
.
.
.
.
20
20
22
24
26
28
36
5 Conclusion and Future Work
38
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Futurework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Bibliography
40
A Appendix
A.1 Network Trace files . . . . . . . . . . . . . . . . . . . . . . . . . .
A.1.1 Uninterrupted TCP Flows . . . . . . . . . . . . . . . . . .
A.1.2 Interrupted TCP Flows . . . . . . . . . . . . . . . . . . .
44
44
44
59
iii
List of Figures
2.1
User surfing model. . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1
3.2
3.3
3.4
3.5
Combination cycle of tests. . . . . .
Experiment setup. . . . . . . . . . .
Snapshot of Picture based web Page.
Snapshot of Text based web Page. .
Snapshot of Video based web Page. .
.
.
.
.
.
14
15
17
18
19
4.1
4.2
4.3
4.4
4.5
4.6
Resets Pattern on the bases of Browser types. . . . . . . . . . . .
Resets Pattern on the bases of Web Page types. . . . . . . . . . .
Web pages Trends in TCP Resets. . . . . . . . . . . . . . . . . .
Browser Contribution in TCP Resets. . . . . . . . . . . . . . . .
Network Devices/Users contribution in Resets. . . . . . . . . . .
One Reset Packet in Web session, accessing Text Web page using
IE8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Two Reset in Web session, accessing a video web page using IE8.
Resets due to Router while using OPERA. . . . . . . . . . . . . .
Reset in Web session due to user interruption while using Opera
(Picture Web page). . . . . . . . . . . . . . . . . . . . . . . . . .
Resets in a Web session due to user interruption while using IE8
(text web page). . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resets in a Web session due to user interruption while using
Firefox (Picture web page). . . . . . . . . . . . . . . . . . . . . .
Resets in a Web session due to user interruption while using IE8
(Video Web Page). . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparison of a TCP flow for a Web Session(Normal vs interrupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP flow of Opera browser while accessing a picture web page. .
Firefox using 2 ports to download the whole web page hence no
reset due to browser rather both are due to the User interrupt. .
Comparison of TCP flows for a Web session (Normal vs Browser
interrupted). . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP flow of Internet Explorer browser while accessing a Text
web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TCP flow of Internet Explorer browser while accessing a Video
web page. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
22
23
23
24
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
4.17
4.18
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
25
25
26
26
27
27
27
29
30
31
32
34
35
A.1 Apache Firefox Picture Web Page. . . . . . . . . .
A.2 Apache Firefox Text Web Page. . . . . . . . . . . .
A.3 Apache Firefox Video Web Page. . . . . . . . . . .
A.4 Apache Google Chrome Video Web Page. . . . . .
A.5 Apache Google Chrome Text Web Page. . . . . . .
A.6 Apache Google Chrome Video Web Page. . . . . .
A.7 Apache Internet Explorer Picture Web Page. . . .
A.8 Apache Internet Explorer Picture Text Page. . . .
A.9 Apache Internet Explorer Video Web Page. . . . .
A.10 Apache Opera Picture Web Page. . . . . . . . . . .
A.11 Apache Opera Text Web Page. . . . . . . . . . . .
A.12 Apache Opera Video Web Page. . . . . . . . . . .
A.13 Microsoft IIS Firefox Picture Web Page. . . . . . .
A.14 Microsoft IIS Firefox Text Web Page. . . . . . . .
A.15 Microsoft IIS Firefox Video Web Page. . . . . . . .
A.16 Microsoft IIS Google Chrome Video Web Page. . .
A.17 Microsoft IIS Google Chrome Text Web Page. . . .
A.18 Microsoft IIS Google Chrome Video Web Page. . .
A.19 Microsoft IIS Internet Explorer Picture Web Page.
A.20 Microsoft IIS Internet Explorer Picture Text Page.
A.21 Microsoft IIS Internet Explorer Video Web Page. .
A.22 Microsoft IIS Opera Picture Web Page. . . . . . .
A.23 Microsoft IIS Opera Text Web Page. . . . . . . . .
A.24 Microsoft IIS Opera Video Web Page. . . . . . . .
A.25 Apache Firefox Picture Web Page. . . . . . . . . .
A.26 Apache Firefox Text Web Page. . . . . . . . . . . .
A.27 Apache Firefox Video Web Page. . . . . . . . . . .
A.28 Apache Google Chrome Video Web Page. . . . . .
A.29 Apache Google Chrome Text Web Page. . . . . . .
A.30 Apache Google Chrome Video Web Page. . . . . .
A.31 Apache Internet Explorer Picture Web Page. . . .
A.32 Apache Internet Explorer Picture Text Page. . . .
A.33 Apache Internet Explorer Video Web Page. . . . .
A.34 Apache Opera Picture Web Page. . . . . . . . . . .
A.35 Apache Opera Text Web Page. . . . . . . . . . . .
A.36 Apache Opera Video Web Page. . . . . . . . . . .
A.37 Microsoft IIS Firefox Picture Web Page. . . . . . .
A.38 Microsoft IIS Firefox Text Web Page. . . . . . . .
A.39 Microsoft IIS Firefox Video Web Page. . . . . . . .
A.40 Microsoft IIS Google Chrome Video Web Page. . .
A.41 Microsoft IIS Google Chrome Text Web Page. . . .
A.42 Microsoft IIS Google Chrome Video Web Page. . .
A.43 Microsoft IIS Internet Explorer Picture Web Page.
A.44 Microsoft IIS Internet Explorer Picture Text Page.
A.45 Microsoft IIS Internet Explorer Video Web Page. .
A.46 Microsoft IIS Opera Picture Web Page. . . . . . .
A.47 Microsoft IIS Opera Text Web Page. . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
44
45
45
46
46
47
47
48
48
49
49
50
51
52
52
53
53
54
54
55
55
56
57
58
59
60
61
61
62
62
63
63
64
64
65
65
66
67
67
68
68
69
69
70
70
71
71
A.48 Microsoft IIS Opera Video Web Page. . . . . . . . . . . . . . . . 72
vi
List of Tables
4.1
4.2
4.3
4.4
The amount of
The amount of
Using D. Rossi
Using D. Rossi
resets generated without user interruption
resets generated with user interruption. . .
Criteria for Uninterrupted Flows. . . . . .
Criteria for Interrupted Flows. . . . . . . .
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
36
37
Chapter 1
Introduction
In today’s world the competition between different ISP’s 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 90’s suggested that around 70-75% of the total traffic is comprised of TCP/HTTP [3–5].
Furthermore, a recent study performed over two years of Global Internet traffic 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 responsive 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 traffic. In the early 90’s 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, TCP’s 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 attributes of the web-driven traffic. Studies in the past have also shown that
TCP/HTTP connections generate a substantial amount of resets (RST). According to a data collected at NLAR/MOAT Network Analysis Infrastructure
(NAI), resets occur more than 10% of the total 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 user’s 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 user’s expectations.
Therefore, it becomes very essential to keep a record of end users perception
frequently in order to satisfy the ever changing needs of users [16].
A study conducted in 2008 by Accenture [17] provides a better understanding of the significance of the user satisfaction. The study unveils that disappointed users could cause a chain reaction by sharing their experiences regarding the services to other users: hence, starring the debasement of the service
provider’s profile. This further leads the disappointed user to switch the operators without filing any formal complaint about the service. All this commotion
highlights the issue that how delicate and essential the users presence has become for the service provider.
2.2
Quality of Experience (QoE) and Quality of Service (QoS)
In order to wallop the Internet systems most urgent issues, the Internet society
requires to take measures to provide good and improved service quality. On
3
the other hand, it is observed that some of the most essential issues of the QoS
are 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 user’s 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 improved performance. When it comes to network, there is always been a lack
of perception among the users on its functionalities and the technical terms
used within. The knowledge of a user about the network is more of an abstract
level. This is where the end-to-end QoS or more specifically QoE comes in
picture. The term QoE, also known as “Quality of User Experience,” is a subjective measure of a user’s 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 satisfaction, 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 [22–24], but mostly
in context of multimedia delivery. The main focus of QoE is on the subjective
valuation of services delivered by the end users. Some of the main issues addressed by QoE are to provide reliable services (availability, accessibility, access
time, and continuity), and the comfortability of the services (session quality,
usage and support level) [22]. A good example of QoE would be the (voice over
internet protocol)VoIP services, the users of any VoIP service did not show any
sort of interest in knowing the parameters like packet loss and system throughput, instead his/her interest would be in experiencing good voice quality and
the timeliness of the connection.
2.3
TCP Connection Management
Connections are established in TCP using a three-way handshake in order to
provide a reliable connection management across the network. In the opening
handshake the client side sends TCP SYN (Connection Primitive) bit to the
server. The purpose of this SYN bit is to ensure the originality of the request
and also to check whether if the other end (server) exits and is willing to establish a connection. After receiving the SYN control segment, the server end
acknowledges (ACK) with a SYN ACK control segment. During this initiation
process (handshake), both the end users (client and server) establish the starting sequence number i.e., MSS in order to achieve reliable data transfer in either
direction. The closing handshake initiates with the client side sending the TCP
FIN (CLOSE Primitive) control segment to the server. The purpose of this
FIN 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 example, the arrival of data packets for which all the connections are closed would
generate a TCP reset. Similarly, the TCP segments arriving with an inappropriate sequence number, or the arrival of the SYN ACK packet for which no
SYN response had been generated, would also cause a TCP reset. The original
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 TCP’s 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 RFC’s (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 OS’s 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 Internet. 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 page’s
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 page’s 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 page’s 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-toone mapping between the TCP connection and objects (contents of the web
pages), involves a lot of connections transmitting a modest amount of data.
According to the 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 earlier protocol versions (that include HTTP/0.9). Moreover, HTTP/1.1 improves
the connection; i.e. Keep Alive extension. This new feature of HTTP/1.1, is
termed as Persistent connection, which permits the recovery of multiple web
page contents with only a single TCP connection, hence solving the issues synonymous to HTTP/1.0, though it still requires the ability of clearly delimiting
each of the downloaded web page content. A study based on HTTP 1.1 persistent connection is briefly described in next topic. Content-length (header
with the object’s length) plays a primal role in HTTP/1.1, though sometimes
it becomes impossible to know the size of some of the objects at the very, happening of their transfer. HTTP/1.1 allows the delivery of an object in chunks
each of which is bounded by an extra header (Transfer-Encoding) providing the
size of the chunks, except for the last chunk, that contains the content-length
header, indicating the end of the object. There are two more features that are
comprised within HTTP/1.1 and used for improving the 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
2.6.1
Persistent Connections and Pipelining
Persistent Connection
A study conducted in 1998 for HTTP/1.1 persistent connection on Netscape
Navigator and Internet Explorer for 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 aren’t
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 single socket without waiting for each response. Pipelining is only supported
in HTTP/1.1, hence it is required that both the client and the server should
support it. A client supporting the persistent connections may ”pipeline” its
request, and the server must response to the incoming requests in the same
sequence the requests were received.
Implementation in Web Servers
Studies show that the execution of the pipelining in web server is simply a
matter of ensuring that the network 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 demonstrating 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 available where as that of Opera is of limited options. Apart from that Firefox and
Google chrome are open source and can be used as an option if required.
2.7.2
Web Proxies
Using web proxies [31] for collecting stats is suboptimal as all the users must
be forced to use Web proxy. Although a number of commercial tools also exist
that allow their analysis [32] but their basic function is to assist network administrators. Moreover the work of Mogul et al [33,34] shows their advantages.
2.7.3
Packet Monitoring
The information collected from packet monitoring consists of full HTTP header
information that also includes elaborated timestamps of HTTP and TCP events.
Further packet monitoring is passive and hence oblivious to user. It does not
interfere with the networks performance and the data gathered is more than
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
[36–38] 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 empirical probability for user clicks and transferred data sizes. They analyzed
large packet traces and use the empirical model to implement a web client traffic 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 between 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 implementations and concluded that one of the most used web browser is the main
cause for major amount of resets and not the user.
2.8.1
User 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 software (on client, server end or middle network elements).
The first one relates indirectly to user’s 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 experiment 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 process was interrupted by a Stop and the page is loaded again or refreshed. This
process in a wide sense indicates an actual scenario were the user is bored by
the slow internet speed or when it takes more time to open a web page, the user
reloads the page. After being refreshed when the page contents are completely
downloaded without error and the tcp ports being used for transmission become
idle, the web page is closed and again after 3-5 min the same page is accessed
using the same browser. The whole process is analyzed using Wireshark and
results are obtained.
13
Text Web
Page
Picture Web
page
Video Web
Page
Microsoft Internet
information
system 5.1
Internet Explorer 8
Mozila Firefox
Google Chrome
Opera
Apache Web
Server 2.2
Text Web
Page
Picture Web
page
Video Web
Page
Figure 3.1: Combination cycle of tests.
3.3
3.3.1
Experiment Tools and Technique
Client server Architecture
As described before we created a simple client server architecture using a wired
connection to the server while the same router was connected to a client through
a wireless connection as shown below in figure 3.2.
3.3.2
Wireshark Network Analyzer
Wireshark is a multi-platform, free, and open-source packet analyzing computer application. The main functionalities of wireshark includes; network troubleshooting, analysis, software and communication protocol development, and
educational purpose. All this application makes it one of the easiest and widely
used packet sniffer. With the aid of wireshark, network traffic could be captured 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 network related issues, but these are also used by intruders to obtain unauthorized
information from the network [51].
Our goal is to capture and analyze data packets in a systematic fashion
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 computer 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 MicrosoftIIS 5.1 using windows XP (service pack3) operating system.
3.3.5
Clients
We used windows XP(service pack3) operating system on client end.
3.3.6
Browsers
Internet Explorer 8 (supports persistence connection only), Firefox 3.6 (supports persistence connection & pipelining optional), Google Chrome 4.1.249.1042
(supports persistence connection only), Opera 10.51 (supports persistence connection & Pipelining). Further we disabled all the history and caching options
so that each time a web page was accessed, it acted as if it was the 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 conclude that all the resets were due to any fault in networks hardware or due to
faulty software implementations in client, server or network equipment. Further
from the studies in the past we had come to know that Internet Explorer always closes the port with a reset which can be observed from the stats. Internet
Explorer generates a reset each time the web page is accessed and twice while
accessing a video based website, which is not the proper termination process.
The rest of the browsers did not generate any reset packet specifically in tcp
transmission process and closed the connection gently using a finish and acknowledgement 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
Picture
Text
Video
Picture
Text
IE
FF
10
0
10
0
23
0
11
4
10
4
GC
0
0
4*
(towards
the
router)
when
idle
/1 (from
router)
10
0
4*
(towards
the
router)
when
idle
0
0
23
15
0
4*
(towards
the
router)
when
idle
/1 (from
router)
14
Brwser
o
/Server
OP
Toal
t
Resets
per
web page
(towards
the
router)
when
idle
/1 (from
router)
10
IIS
Video
30
/1(from
server
end)
0
0
Total
Browsers
Reset
Packets
94
8
0
16
31
Table 4.1: The amount of resets generated without user interruption
Apache
Picture
Text
Brwsers
o
/Servers
IE
FF
GC
21
21
10
OP
Toal
t
Resets
per
web page
4*
(towards
the
router)
when
idle
/1 (from
router)
66
20
21
11
11
2*
(towards
the
router)
when
idle
/1 (from
router)
65
Video
Picture
Text
40
11
10
11
4*
(towards
the
router)
when
idle
21
20
11
10
20
20
10
10
72
66
60
IIS
Video
45
10
10
11
4*
(towards
the
router)
when
idle
/1 (from
router)
80
Table 4.2: The amount of resets generated with user interruption.
21
*
Total
Browsers
Reset
Packets
166
103
62
77
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
100
77
94
User Uninterrupted
62
50
19
8
0
0
Internet
Explorer 8
Mozilla Firefox Google Chrome
Opera
Figure 4.1: Resets Pattern on the bases of Browser types.
250
152
200
125
132
150
User Interrupted Tests
User Uninterrupted Tests
100
54
50
24
25
Text web page
Picture Web Page
0
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
24%
28%
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
77%
Google Chrome
Opera
Interrupted
15%
40%
Internet Explorer 8
20%
Mozilla Firefox
Google Chrome
Opera
25%
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 (client’s
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
User Interrupted
Flow
Normal TCP
Flow
SYN
TFS
SYN
ACK
SYN+
SYN+
ACK
ACK
GET
DATA
TCS
GET
DATA
TSS
ACK
ACK
GET
ACK
TCE
GET
A
DAT
DATA
TSE
ACK
TFE
ACK
RST
FIN
ACK
FIN
TFE
T2FS
SYN
ACK
SYN+
Client
Server
TIME
Client
ACK
Server
Figure 4.13: Comparison of a TCP flow for a Web Session(Normal vs interrupted).
29
Uninterrupted Flow
|Time
|
|20.292
|
|20.293
|
|20.296
|
|20.303
|
|21.600
|
|36.819
|
|36.894
|
|
| 192.168.1.4
|
192.168.1.5
|
SYN
|(2165) ------------------> (80)
|
SYN, ACK
|(2165) <------------------ (80)
|
PSH, ACK - Len: 406
|(2165) ------------------> (80)
|
PSH, ACK - Len: 500
|(2165) ------------------> (80)
|
PSH, ACK - Len: 499
|(2165) ------------------> (80)
|
FIN, ACK
|(2165) <------------------ (80)
|
FIN, ACK
|(2165) ------------------> (80)
Interrupted Flow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|Time
|
|0.001
|
|0.002
|
|0.123
|
|0.136
|
|1.304
|
|2.055
|
|2.056
|
|2.057
|
|2.061
|
|4.821
|
|19.945
|
|20.029
|
| 192.168.1.3
|
192.168.1.2
|
SYN
|(1235) ------------------> (80)
|
SYN, ACK
|(1235) <------------------ (80)
|
PSH, ACK - Len: 406
|(1235) ------------------> (80)
|
PSH, ACK - Len: 500
|(1235) ------------------> (80)
|
RST, ACK
|(1235) ------------------> (80)
|
SYN
|(1237) ------------------> (80)
|
SYN, ACK
|(1237) <------------------ (80)
|
PSH, ACK - Len: 483
|(1237) ------------------> (80)
|
PSH, ACK - Len: 500
|(1237) ------------------> (80)
|
PSH, ACK - Len: 499
|(1237) ------------------> (80)
|
FIN, ACK
|(1237) <------------------ (80)
|
FIN, ACK
|(1237) ------------------> (80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.14: TCP flow of Opera browser while accessing a picture web page.
30
Uninterrupted Flow
|Time
|
|0.003
|
|0.005
|
|0.018
|
|0.093
|
|1.332
|
|16.555
|
|29.590
|
| 192.168.1.4
|
192.168.1.5
|
SYN
|(2115) ------------------> (80)
|
SYN, ACK
|(2115) <------------------ (80)
|
PSH, ACK - Len: 365
|(2115) ------------------> (80)
|
PSH, ACK - Len: 377
|(2115) ------------------> (80)
|
PSH, ACK - Len: 346
|(2115) ------------------> (80)
|
FIN, ACK
|(2115) <------------------ (80)
|
FIN, ACK
|(2115) ------------------> (80)
Interrupted Flow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|Time
|
|0.000
|
|0.001
|
|0.015
|
|0.074
|
|0.972
|
|0.972
|
|0.972
|
|0.985
|
|0.986
|
|0.993
|
|1.026
|
|1.046
|
|1.046
|
|5.026
|
|20.065
|
|29.617
|
| 192.168.1.3
|
192.168.1.2
|
SYN
|(1159) ------------------> (80)
|
SYN, ACK
|(1159) <------------------ (80)
|
PSH, ACK - Len: 365
|(1159) ------------------> (80)
|
PSH, ACK - Len: 377
|(1159) ------------------> (80)
|
RST, ACK
|(1159) ------------------> (80)
|
SYN
|(1160) ------------------> (80)
|
SYN
|(1161) ------------------> (80)
|
SYN, ACK
|(1160) <------------------ (80)
|
SYN, ACK
|(1161) <------------------ (80)
|
PSH, ACK - Len: 346
|(1160) ------------------> (80)
|
PSH, ACK - Len: 482
|(1161) ------------------> (80)
|
RST, ACK
|(1160) ------------------> (80)
|
PSH, ACK - Len: 466
|(1161) ------------------> (80)
|
PSH, ACK - Len: 407
|(1161) ------------------> (80)
|
FIN, ACK
|(1161) <------------------ (80)
|
FIN, ACK
|(1161) ------------------> (80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.15: Firefox using 2 ports to download the whole web page hence no reset due
to browser rather both are due to the User interrupt.
31
Normal TCP
Flow
SYN
Browser Interrupted
Flow
TFS
SYN
ACK
SYN+
SYN+
ACK
ACK
GET
DATA
ACK
TCS
GET
DATA
TSS
ACK
ACK
GET
TCE
GET
A
DAT
DATA
TSE
ACK
ACK
FIN
FIN
AC
K
TFE
RST
TFE
FIN
ACK
ACK
Client
Server
TIME
Client
Server
Figure 4.16: Comparison of TCP flows for a Web session (Normal vs Browser interrupted).
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 difference 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) receives 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 phenomena of 2 resets on the same port is also seen in the traces. Hence a very strict
and complex criteria has to be implemented to extract user behavior from tcp
resets.
On the other hand if we revise the characteristics of Internet Explorer which
we also observed in our tests, i.e.the RST packet generated by Internet Explorer
is 60 seconds after the port gets idle, but this only occurred while using the
Microsoft Information Server. When Apache server was used the port was
closed after being idle for 15 seconds by a FIN from the server and a RST
packet was generated by Internet Explorer after 5 seconds.
33
Uninterrupted Flow
|Time
|
|0.192
|
|0.193
|
|0.195
|
|0.614
|
|0.703
|
|0.705
|
interrupted Flow
| 192.168.1.4
||Time
|
192.168.1.5 ||
|
SYN
||0.081
|(1602) ------------------> (80) ||
|
SYN, ACK
||0.082
|(1602) <------------------ (80) ||
|
PSH, ACK - Len: 219
||0.083
|(1602) ------------------> (80) ||
|
PSH, ACK - Len: 206
||2.289
|(1602) ------------------> (80) ||
|
RST, ACK
||2.335
|(1602) ------------------> (80) ||
|
FIN, ACK
||2.436
|(1602) <------------------ (80) ||
|2.436
|
|37.585
|
|102.962
|
| 192.168.1.3
|
192.168.1.2
|
SYN
|(1238) ------------------> (80)
|
SYN, ACK
|(1238) <------------------ (80)
|
PSH, ACK - Len: 219
|(1238) ------------------> (80)
|
RST, ACK
|(1238) ------------------> (80)
|
SYN
|(1239) ------------------> (80)
|
SYN, ACK
|(1239) <------------------ (80)
|
PSH, ACK - Len: 328
|(1239) ------------------> (80)
|
PSH, ACK - Len: 206
|(1239) ------------------> (80)
|
RST, ACK
|(1239) ------------------> (80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.17: TCP flow of Internet Explorer browser while accessing a Text web page.
34
Uninterrupted Flow
|Time
|
|0.000
|
|0.002
|
|0.003
|
|0.544
|
|0.549
|
|0.599
|
|0.600
|
|0.601
|
|1.535
|
|16.837
|
|16.843
|
| 192.168.1.4
|
192.168.1.5
|
SYN
|(1802) ------------------> (80)
|
SYN, ACK
|(1802) <------------------ (80)
|
PSH, ACK - Len: 219
|(1802) ------------------> (80)
|
PSH, ACK - Len: 87
|(1802) ------------------> (80)
|
RST, ACK
|(1802) ------------------> (80)
|
SYN
|(1803) ------------------> (80)
|
SYN, ACK
|(1803) <------------------ (80)
|
PSH, ACK - Len: 206
|(1803) ------------------> (80)
|
PSH, ACK - Len: 211
|(1803) ------------------> (80)
|
FIN, ACK
|(1803) <------------------ (80)
|
RST, ACK
|(1803) ------------------> (80)
interrupted Flow
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|Time
|
|0.000
|
|0.001
|
|0.001
|
|0.073
|
|0.076
|
|0.259
|
|0.260
|
|0.260
|
|0.914
|
|1.671
|
|1.816
|
|1.817
|
|1.817
|
|1.821
|
|1.823
|
|1.922
|
|1.923
|
|1.939
|
|17.780
|
|22.766
|
| 192.168.1.4
|
192.168.1.2
|
SYN
|(2047) ------------------> (80)
|
SYN, ACK
|(2047) <------------------ (80)
|
PSH, ACK - Len: 219
|(2047) ------------------> (80)
|
PSH, ACK - Len: 86
|(2047) ------------------> (80)
|
RST, ACK
|(2047) ------------------> (80)
|
SYN
|(2048) ------------------> (80)
|
SYN, ACK
|(2048) <------------------ (80)
|
PSH, ACK - Len: 206
|(2048) ------------------> (80)
|
PSH, ACK - Len: 210
|(2048) ------------------> (80)
|
RST, ACK
|(2048) ------------------> (80)
|
SYN
|(2049) ------------------> (80)
|
SYN, ACK
|(2049) <------------------ (80)
|
PSH, ACK - Len: 310
|(2049) ------------------> (80)
|
PSH, ACK - Len: 202
|(2049) ------------------> (80)
|
RST, ACK
|(2049) ------------------> (80)
|
SYN
|(2050) ------------------> (80)
|
SYN, ACK
|(2050) <------------------ (80)
|
PSH, ACK - Len: 326
|(2050) ------------------> (80)
|
FIN, ACK
|(2050) <------------------ (80)
|
RST, ACK
|(2050) ------------------> (80)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 4.18: TCP 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 Politecnio 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
s
without
user
interruption
10
10
23
30
10
10
4
4
Sever Browser web
page
AP IE PIC
AP IE TXT
IIS IE VID
IIS IE VID
IIS IE TXT
IIS IE PIC
IIS FF TXT
IIS FF PIC
Rossi Criteria
for user
interrupted
Resets
User Browser
0
10
0
10
10
13
20
10
0
10
0
10
0
4
0
4
Original Reason
for Resets
Percentage
Error
User
0
0
0
0
0
0
0
0
0
0
43.47
66.6
0
0
0
0
Browser
10
10
23
30
10
10
4
4
Table 4.3: Using D. Rossi Criteria for Uninterrupted Flows.
36
Reets
s
without
user
interruption
Sever Browser web
page
Resets with
user
interruption
10
10
30
4
4
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
10
10
10
IIS IE TXT
IIS IE PIC
IIS IE VID
IIS FF PIC
IIS FF TXT
IIS FF VID
IIS GC PIC
IIS GC TXT
IIS GC VID
IIS OP PIC
IIS OP TXT
IIS OP VID
AP OP PIC
AP OP TXT
AP OP VID
AP GC PIC
AP GC TXT
AP GC VID
AP FF PIC
AP FF TXT
AP FF VID
AP IE PIC
AP IE TXT
AP IE VID
20
21
41
20
20
10
11
10
10
10
10
10
10
11
11
10
11
10
21
21
11
21
20
40
Rossi Criteria
for user
interrupted
Resets
User Browser
10
10
11
10
30
11
20
0
20
0
10
0
11
0
10
0
10
0
10
0
10
0
10
0
10
0
11
0
11
0
10
0
11
0
10
0
21
0
21
0
11
0
11
10
0
20
30
10
Original Reason
for Resets
Error
User
10
11
11
20
20
10
11
10
10
10
10
10
10
11
11
10
11
10
21
21
11
11
10
10
0
0
46.3
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
50
50
Browser
10
10
30
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
10
10
30
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 depending on the browser. A reset is caused whenever a user press the refresh, stop
or follow another link before the completion of main link. This was perceived
as a user dissatisfaction, but the follow link behavior cannot be considered a
user dissatisfaction in every case. A possible reason for this is that nowadays,
many websites are bombarded with images and multimedia objects which can
delay the downloading process even if the user have high speed internet access.
Hence, users tend to click quickly on a link within the main website, when they
are familiar with website. Even though the users are clearly the major cause
of resets observed in the experiments, still we cannot explicitly define user dissatisfaction 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, network elements, web pages and web browsers. A stepwise testing moving from
isolated environments to more complex environments can lead to interesting
results. ISP’s and research organizations can also try to devise a relation between 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.
47–57, 2010.
[3] K. Thompson, G. Miller, and R. Wilder, “Wide-area internet traffic patterns and characteristics,” Network, IEEE, vol. 11, no. 6, pp. 10 –23, Dec.
1997.
[4] C. Fraleigh, S. Moon, B. Lyles, C. Cotton, M. Khan, D. Moll, R. Rockell,
T. Seely, and S. Diot, “Packet-level 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. Sandoval, “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. 314–329, 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. 37–44, 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. 289–294.
[17] “High performance in the age of customer centricity,” Accenture 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 multimedia streaming over IP based on customer oriented metrics,” in Computer
Networks, 2006 International Symposium on, 2006, pp. 185 –191.
[22] “Quality of experience (QoE) of mobile services:
Can it
be measured and improved?”
White Paper, Nokia Networks Coporation, October 2004. [Online: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. 25–35, 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 between http/1.0 and http/1.1,” in Proceedings of the eighth international
conference on World Wide Web, ser. WWW ’99, 1999, pp. 1737–1751.
[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. 249–271, 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. 2–2.
[34] V. N. Padmanabhan and J. C. Mogul, “Improving http latency,” Comput.
Netw. ISDN Syst., vol. 28, pp. 25–35, 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. 14–14.
[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. 12–12.
[37] M. Arlitt and C. Williamson, “Internet web servers: workload characterization and performance implications,” Networking, IEEE/ACM Transactions on, vol. 5, no. 5, pp. 631 –645, Oct. 1997.
42
[38] E. Cohen, B. Krishnamurthy, and J. Rexford, “Improving end-to-end performance of the web using server volumes and proxy filters,” in Proceedings
of the ACM SIGCOMM ’98 conference on Applications, technologies, architectures, and protocols for computer communication, ser. SIGCOMM
’98. New York, NY, USA: ACM, 1998, pp. 241–253.
[39] P. Barford and M. Crovella, “Generating representative web workloads
for network and server performance evaluation,” SIGMETRICS Perform.
Eval. Rev., vol. 26, pp. 151–160, June 1998.
[40] H. Abrahamsson and B. Ahlgren, “Using empirical distributions to characterize 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. 321–335, 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:
//www.w3schools.com/browsers/browsers-stats.asp
http:
[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:
//news.netcraft.com/archives/category/web-server-survey/
http:
[50] Market structure, [Online:Varified June,
//en.wikipedia.org/wiki/Web server
http:
2010]. Available:
[51] C. Sanders, Practical Packet Analysis:Using Wireshark to Solve RealWorld 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
|Time
|
|0.003
|
|0.005
|
|0.018
|
|0.093
|
|1.332
|
|16.555
|
|29.590
|
Uninterrupted TCP Flows
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: kdm > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(2115) ------------------> (80)
|
|
TCP: http > kdm [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2115) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2115) ------------------> (80)
|
|
GET /WorldMap.jpg
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(2115) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2115) ------------------> (80)
|
|
TCP: http > kdm [FIN, ACK] |Seq=1162431 Ack=1089 Win=8576 Len=0
|(2115) <------------------ (80)
|
|
TCP: kdm > http [FIN, ACK] |Seq=1089 Ack=1162432 Win=17018 Len=0
|(2115) ------------------> (80)
|
Figure A.1: Apache Firefox Picture Web Page.
44
|Time
|
|30.984
|
|30.986
|
|31.016
|
|31.060
|
|45.555
|
|45.562
|
| 192.168.1.4
|
192.168.1.5
|
TCP: unisql-java > http [SYN]
|(1979) ------------------> (80)
|
TCP: http > unisql-java [SYN, ACK]
|(1979) <------------------ (80)
|
GET / HTTP/1.1
|(1979) ------------------> (80)
|
GET /favicon.ico
|(1979) ------------------> (80)
|
TCP: unisql-java > http [FIN, ACK]
|(1979) ------------------> (80)
|
TCP: http > unisql-java [FIN, ACK]
|(1979) <------------------ (80)
|
|
| Seq=0 Win=16384 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=712 Ack=4543 Win=17520 Len=0
|
|Seq=4543 Ack=713 Win=7504 Len=0
|
Figure A.2: Apache Firefox Text Web Page.
|Time
|
|0.000
|
|0.002
|
|0.018
|
|0.113
|
|0.998
|
|16.195
|
|29.587
|
| 192.168.1.4
|
192.168.1.5
|
TCP: fiorano-msgsvc > http [SYN]
|(1856) ------------------> (80)
|
TCP: http > fiorano-msgsvc [SYN, ACK]
|(1856) <------------------ (80)
|
GET / HTTP/1.1
|(1856) ------------------> (80)
|
GET /favicon.ico
|(1856) ------------------> (80)
|
GET /htmlexample.
|(1856) ------------------> (80)
|
TCP: http > fiorano-msgsvc [FIN, ACK]
|(1856) <------------------ (80)
|
TCP: fiorano-msgsvc > http [FIN, ACK]
|(1856) ------------------> (80)
|
|
|Seq=0 Win=16384 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|
| Seq=107117 Ack=1123 Win=8576 Len=0
|
| Seq=1123 Ack=107118 Win=17520 Len=0
|
Figure A.3: Apache Firefox Video Web Page.
45
|Time
|
|63.658
|
|63.660
|
|63.660
|
|63.675
|
|65.398
|
|80.734
|
|85.460
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: nbx-dir > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2096) ------------------> (80)
|
|
TCP: http > nbx-dir [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|(2096) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2096) ------------------> (80)
|
|
GET /WorldMap.jpg
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(2096) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2096) ------------------> (80)
|
|
TCP: http > nbx-dir [FIN, ACK] |Seq=1162431 Ack=1104 Win=9088 Len=0
|(2096) <------------------ (80)
|
|
TCP: nbx-dir > http [FIN, ACK] | Seq=1104 Ack=1162432 Win=64284 Len=0
|(2096) ------------------> (80)
|
Figure A.4: Apache Google Chrome Video Web Page.
|Time
|
|0.000
|
|0.009
|
|0.010
|
|0.044
|
|15.318
|
|15.318
|
|20.049
|
| 192.168.1.4
|
192.168.1.5
|
TCP: 2194 > http [SYN]
|(2194) ------------------> (80)
|
TCP: http > 2194 [SYN, ACK]
|(2194) <------------------ (80)
|
GET / HTTP/1.1
|(2194) ------------------> (80)
|
GET /favicon.ico
|(2194) ------------------> (80)
|
TCP: http > 2194 [FIN, ACK]
|(2194) <------------------ (80)
|
TCP: http > 2194 [FIN, ACK]
|(2194) <------------------ (80)
|
TCP: 2194 > http [FIN, ACK]
|(2194) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=4543 Ack=741 Win=8000 Len=0
|
|Seq=4543 Ack=741 Win=8000 Len=0
|
| Seq=741 Ack=4544 Win=65536 Len=0
|
Figure A.5: Apache Google Chrome Text Web Page.
46
|Time
|
|0.000
|
|0.002
|
|0.003
|
|0.700
|
|0.701
|
|0.703
|
|0.703
|
|15.834
|
|15.835
|
|20.714
|
|20.714
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: rimf-ps > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2209) ------------------> (80)
|
|
TCP: http > rimf-ps [SYN, ACK]
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|(2209) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2209) ------------------> (80)
|
|
GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(2209) ------------------> (80)
|
|
TCP: noaaport > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2210) ------------------> (80)
|
|
TCP: http > noaaport [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|(2210) <------------------ (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2210) ------------------> (80)
|
|
TCP: http > noaaport [FIN, ACK] |Seq=504 Ack=333 Win=6912 Len=0
|(2210) <------------------ (80)
|
|
TCP: http > rimf-ps [FIN, ACK]
|Seq=106615 Ack=776 Win=8000 Len=0
|(2209) <------------------ (80)
|
|
TCP: noaaport > http [FIN, ACK] |Seq=333 Ack=505 Win=65032 Len=0
|(2210) ------------------> (80)
|
|
TCP: rimf-ps > http [FIN, ACK]
|Seq=776 Ack=106616 Win=64520 Len=0
|(2209) ------------------> (80)
|
Figure A.6: Apache Google Chrome Video Web Page.
|Time
|
|0.000
|
|0.005
|
|0.005
|
|0.484
|
|1.772
|
|16.788
|
|21.772
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: msync > http [SYN]
| Seq=0 Win=16384 Len=0 MSS=1460
|(2072) ------------------> (80)
|
|
TCP: http > msync [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2072) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2072) ------------------> (80)
|
|
GET /WorldMap.jpg
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(2072) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2072) ------------------> (80)
|
|
TCP: http > msync [FIN, ACK] |Seq=1162431 Ack=687 Win=8576 Len=0
|(2072) <------------------ (80)
|
|
TCP: msync > http [RST, ACK] | Seq=687 Ack=1162432 Win=0 Len=0
|(2072) ------------------> (80)
|
Figure A.7: Apache Internet Explorer Picture Web Page.
47
|Time
|
|11.408
|
|11.409
|
|11.409
|
|12.024
|
|27.301
|
|32.017
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: submitserver > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(2028) ------------------> (80)
|
|
TCP: http > submitserver [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2028) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2028) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2028) ------------------> (80)
|
|
TCP: http > submitserver [FIN, ACK] | Seq=4543 Ack=426 Win=7504 Len=0
|(2028) <------------------ (80)
|
|
TCP: submitserver > http [RST, ACK] |Seq=426 Ack=4544 Win=0 Len=0
|(2028) ------------------> (80)
|
Figure A.8: Apache Internet Explorer Picture Text Page.
|Time
|
|0.000
|
|0.002
|
|0.003
|
|0.544
|
|0.549
|
|0.599
|
|0.600
|
|0.601
|
|1.535
|
|16.837
|
|16.843
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: concomp1 > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1802) ------------------> (80)
|
|
TCP: http > concomp1 [SYN, ACK]
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(1802) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1802) ------------------> (80)
|
|
GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(1802) ------------------> (80)
|
|
TCP: concomp1 > http [RST, ACK]
|Seq=307 Ack=1940 Win=0 Len=0
|(1802) ------------------> (80)
|
|
TCP: hp-hcip-gwy > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1803) ------------------> (80)
|
|
TCP: http > hp-hcip-gwy [SYN, ACK]
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(1803) <------------------ (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1803) ------------------> (80)
|
|
GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(1803) ------------------> (80)
|
|
TCP: http > hp-hcip-gwy [FIN, ACK]
|Seq=106639 Ack=418 Win=7504 Len=0
|(1803) <------------------ (80)
|
|
TCP: hp-hcip-gwy > http [RST, ACK]
|Seq=418 Ack=106640 Win=0 Len=0
|(1803) ------------------> (80)
|
Figure A.9: Apache Internet Explorer Video Web Page.
48
|Time
|
|20.292
|
|20.293
|
|20.296
|
|20.303
|
|21.600
|
|36.819
|
|36.894
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: x-bone-api > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(2165) ------------------> (80)
|
|
TCP: http > x-bone-api [SYN, ACK] | Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2165) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2165) ------------------> (80)
|
|
GET /WorldMap.jpg H
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(2165) ------------------> (80)
|
|
GET /favicon.ico HT
|HTTP: GET /favicon.ico HTTP/1.1
|(2165) ------------------> (80)
|
|
TCP: http > x-bone-api [FIN, ACK] |Seq=1162431 Ack=1406 Win=8576 Len=0
|(2165) <------------------ (80)
|
|
TCP: x-bone-api > http [FIN, ACK] |Seq=1406 Ack=1162432 Win=17018 Len=0
|(2165) ------------------> (80)
|
Figure A.10: Apache Opera Picture Web Page.
|Time
|
|0.279
|
|0.281
|
|0.290
|
|0.300
|
|15.515
|
|15.598
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: eye2eye > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1948) ------------------> (80)
|
|
TCP: http > eye2eye [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(1948) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1948) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1948) ------------------> (80)
|
|
TCP: http > eye2eye [FIN, ACK] |Seq=4543 Ack=906 Win=7504 Len=0
|(1948) <------------------ (80)
|
|
TCP: eye2eye > http [FIN, ACK] |Seq=906 Ack=4544 Win=17520 Len=0
|(1948) ------------------> (80)
|
Figure A.11: Apache Opera Text Web Page.
49
|Time
|
|0.286
|
|0.288
|
|0.294
|
|0.300
|
|1.689
|
|16.814
|
|16.915
|
|18.336
|
| 192.168.
|
|
192.168.1.5 |
|
TCP: sugp > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1905) ------------------> (80)
|
|
TCP: http > sugp [SYN, ACK] |Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(1905) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1905) ------------------> (80)
|
|
GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(1905) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1905) ------------------> (80)
|
|
TCP: http > sugp [FIN, ACK] | Seq=107117 Ack=1410 Win=8576 Len=0
|(1905) <------------------ (80)
|
|
TCP: sugp > http [FIN, ACK] |Seq=1410 Ack=107118 Win=17018 Len=0
|(1905) ------------------> (80)
|
|
TCP: sugp > http [FIN, ACK] | Seq=1410 Ack=107118 Win=17018 Len=0
|(1905) ------------------> (80)
|
Figure A.12: Apache Opera Video Web Page.
50
|Time
|
|1.910
|
|1.914
|
|1.915
|
|1.929
|
|4.272
|
|5.351
|
|5.355
|
|5.355
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: pptp > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1723) ------------------> (80)
|
|
TCP: http > pptp [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|(1723) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1723) ------------------> (80)
|
|
GET /WorldMap.jpg
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(1723) ------------------> (80)
|
|
HTTP: [TCP Retransmission] | GET /WorldMap.jpg HTTP/1.1
|(1723) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1723) ------------------> (80)
|
|
TCP: pptp > http [FIN, ACK] | Seq=1089 Ack=1166062 Win=16237 Len=0
|(1723) ------------------> (80)
|
|
TCP: http > pptp [FIN, ACK] | Seq=1166062 Ack=1089 Win=16432 Len=0
|(1723) <------------------ (80)
|
Figure A.13: Microsoft IIS Firefox Picture Web Page.
51
|Time
|
|1.230
|
|1.231
|
|1.231
|
|1.465
|
|1.538
|
|1.538
|
| 192.168.1.4
|
|
192.168.1.5 |
|
TCP: svs-omagent > http [SYN]
| Seq=0 Win=16384 Len=0 MSS=1460
|(1625) ------------------> (80)
|
|
TCP: http > svs-omagent [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|(1625) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1625) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1625) ------------------> (80)
|
|
TCP: svs-omagent > http [FIN, ACK] | Seq=712 Ack=14241 Win=16237 Len=0
|(1625) ------------------> (80)
|
|
TCP: http > svs-omagent [FIN, ACK] | Seq=14241 Ack=712 Win=16809 Len=0
|(1625) <------------------ (80)
|
Figure A.14: Microsoft IIS Firefox Text Web Page.
|Time | 192.168.1.4
|
|
|
192.168.1.5 |
|9.428 |TCP: payrouter > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|
|(1246) ------------------> (80)
|
|9.627 |TCP: http > payrouter [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|(1246) <------------------ (80)
|
|9.629 | GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|
|(1246) ------------------> (80)
|
|9.669 | GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|
|(1246) ------------------> (80)
|
|9.674 TCP: payrouter > http [FIN, ACK] | Seq=712 Ack=4667 Win=16237 Len=0
|
|(1246) ------------------> (80)
|
|9.675 |TCP: http > payrouter [FIN, ACK] |Seq=4667 Ack=712 Win=16809 Len=0
|
|(1246) <------------------ (80)
|
Figure A.15: Microsoft IIS Firefox Video Web Page.
52
|Time
|
|0.000
|
|0.119
|
|0.120
|
|0.125
|
|0.126
|
| 192.168.1.4
|
|
192.168.1.5|
| TCP: directplay > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2234) ------------------> (80)
|
| TCP:http > directplay [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
|(2234) <------------------ (80)
|
| GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2234) ------------------> (80)
|
| HTTP/1.1 404 Object
|HTTP: HTTP/1.1 404 Object Not Found (text/html)
|(2234) <------------------ (80)
|
| TCP: directplay > http [FIN, ACK] |Seq=333 Ack=4205 Win=64252 Len=0
|(2234) ------------------> (80)
|
Figure A.16: Microsoft IIS Google Chrome Video Web Page.
|Time
|
|0.200
|
|0.201
|
|0.202
|
|0.236
|
|0.243
|
|0.244
|
| 192.168.1.4
|
|
192.168.1.5 |
| TCP: mmcal > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2272) ------------------> (80)
|
| TCP: http > mmcal [SYN,ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
|(2272) <------------------ (80)
|
| GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2272) ------------------> (80)
|
| GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2272) ------------------> (80)
|
| TCP: mmcal > http [FIN,ACK] |Seq=741 Ack=5478 Win=64252 Len=0
|(2272) ------------------> (80)
|
| TCP: http > mmcal [FIN,ACK] |Seq=5478 Ack=741 Win=16780 Len=0
|(2272) <------------------ (80)
|
Figure A.17: Microsoft IIS Google Chrome Text Web Page.
53
|Time
|
|0.000
|
|0.250
|
|0.277
|
|0.279
|
|0.279
|
|1.086
|
|1.087
|
|1.209
|
|1.296
|
|240.515
|
|240.516
|
| 192.168.1.4
|
|
192.168.1.5 |
| TCP: njenet-ssl > http [SYN]
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2252) ------------------> (80)
|
| TCP: dtv-chan-req > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|(2253) ------------------> (80)
|
|
http > njenet-ssl
|TCP:http >0njenet-ssl
WS=0 [SYN, ACK] Seq=0 Ack=1 Win=17520 Len=0 MSS=146
|(2252) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2252) ------------------> (80)
|
|
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)
|
|
GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(2252) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2253) ------------------> (80)
|
|
HTTP/1.1 404 Object
|HTTP: HTTP/1.1 404 Object Not Found (text/html)
|(2253) <------------------ (80)
|
| TCP: dtv-chan-req > http [FIN, ACK] | Seq=333 Ack=4205 Win=64252 Len=0
|(2253) ------------------> (80)
|
| TCP: njenet-ssl > http [FIN, ACK]
|Seq=776 Ack=106746 Win=64766 Len=0
|(2252) ------------------> (80)
|
| TCP: http > njenet-ssl [FIN, ACK]
| Seq=106746 Ack=777 Win=16745 Len=0
|(2252) <------------------ (80)
|
Figure A.18: Microsoft IIS Google Chrome Video Web Page.
|Time
|
|15.347
|
|15.348
|
|15.350
|
|15.719
|
|17.265
|
|17.269
|
|17.270
|
| 192.168.1.4
|
|
192.168.1.5 |
| TCP: kmscontrol > http [SYN]
| Seq=0 Win=16384 Len=0 MSS=1460
|(1773) ------------------> (80)
|
| TCP: http > kmscontrol [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|(1773) <------------------ (80)
|
| GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1773) ------------------> (80)
|
| GET /WorldMap.jpg
|HTTP: GET /WorldMap.jpg HTTP/1.1
|(1773) ------------------> (80)
|
| GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1773) ------------------> (80)
|
| TCP: kmscontrol > http [RST, ACK] | Seq=687 Ack=1164779 Win=0 Len=0
|(1773) ------------------> (80)
|
| TCP: http > kmscontrol [FIN, ACK] | Seq=1166062 Ack=687 Win=16834 Len=0
|(1773) <------------------ (80)
|
Figure A.19: Microsoft IIS Internet Explorer Picture Web Page.
54
|Time
|
|0.192
|
|0.193
|
|0.195
|
|0.614
|
|0.703
|
|0.705
|
| 192.168.1.4
|
192.168.1.5
| TCP: inspect > http [SYN]
|(1602) ------------------> (80)
| TCP: http > inspect [SYN,ACK]
|(1602) <------------------ (80)
| GET / HTTP/1.1
|(1602) ------------------> (80)
| GET /favicon.ico
|(1602) ------------------> (80)
| TCP: inspect > http [RST,ACK]
|(1602) ------------------> (80)
| TCP: http > inspect [FIN,ACK]
|(1602) <------------------ (80)
|
|
| Seq=0 Win=16384 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=426 Ack=11498 Win=0 Len=0
|
| Seq=14241 Ack=426 Win=17095 Len=0
|
Figure A.20: Microsoft IIS Internet Explorer Picture Text Page.
|Time
|
|0.373
|
|0.375
|
|0.375
|
|2.789
|
|3.344
|
|3.549
|
|3.650
|
|3.656
|
|3.661
|
| 192.168.1.4
|
192.168.1.5
| TCP: asci-val > http [SYN]
|(1560) ------------------> (80)
| TCP: http > asci-val [SYN, ACK]
|(1560) <------------------ (80)
| GET / HTTP/1.1
|(1560) ------------------> (80)
| GET /htmlexample.
|(1560) ------------------> (80)
| TCP: asci-val > http [RST, ACK]
|(1560) ------------------> (80)
| TCP: facilityview > http [SYN]
|(1561) ------------------> (80)
| TCP: http > facilityview [SYN, ACK]
|(1561) <------------------ (80)
| GET /favicon.ico
|(1561) ------------------> (80)
| TCP: facilityview > http [RST, ACK]
|(1561) ------------------> (80)
|
|
|Seq=0 Win=16384 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|
| Seq=307 Ack=3384 Win=0 Len=0
|
|Seq=0 Win=16384 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=207 Ack=1461 Win=0 Len=0
|
Figure A.21: Microsoft IIS Internet Explorer Video Web Page.
55
|Time
|
|45.485
|
|45.487
|
|45.487
|
|45.491
|
|47.187
|
|47.638
|
|47.739
|
| 192.168.1.4
|
192.168.1.5
| TCP: rsvp-encap-2 > http [SYN]
|(1699) ------------------> (80)
| TCP: http > rsvp-encap-2 [SYN, ACK]
|(1699) <------------------ (80)
| GET / HTTP/1.1
|(1699) ------------------> (80)
| GET /WorldMap.jpg
|(1699) ------------------> (80)
| GET /favicon.ico
|(1699) ------------------> (80)
| TCP: http > rsvp-encap-2 [FIN, ACK]
|(1699) <------------------ (80)
| TCP: rsvp-encap-2 > http [FIN, ACK]
|(1699) ------------------> (80)
|
|
|Seq=0 Win=16384 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=1166062 Ack=1406 Win=16115 Len=0
|
| Seq=1406 Ack=1166063 Win=16237 Len=0
|
Figure A.22: Microsoft IIS Opera Picture Web Page.
56
|Time
|
|0.797
|
|0.798
|
|0.798
|
|0.813
|
|0.818
|
|0.919
|
| 192.168.1.4
|
|
192.168.1.5 |
| TCP: netview-aix-12 > http [SYN]
|Seq=0 Win=16384 Len=0 MSS=1460
|(1672) ------------------> (80)
|
| TCP: http > netview-aix-12 [SYN, ACK] | Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|(1672) <------------------ (80)
|
| GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1672) ------------------> (80)
|
| GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1672) ------------------> (80)
|
| TCP: http > netview-aix-12 [FIN, ACK] | Seq=14241 Ack=906 Win=16615 Len=0
|(1672) <------------------ (80)
|
| TCP: netview-aix-12 > http [FIN, ACK] | Seq=906 Ack=14242 Win=16237 Len=0
|(1672) ------------------> (80)
|
Figure A.23: Microsoft IIS Opera Text Web Page.
57
|Time
|
|0.646
|
|0.647
|
|0.647
|
|0.654
|
|1.798
|
|1.804
|
|2.211
|
| 192.168.1.4
|
|
192.168.1.5 |
| TCP: pip > http [SYN]
| Seq=0 Win=16384 Len=0 MSS=1460
|(1321) ------------------> (80) |
| TCP: http > pip [SYN, ACK] |Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|(1321) <------------------ (80) |
| GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(1321) ------------------> (80) |
| GET /htmlexample.
|HTTP: GET /htmlexample.mpeg HTTP/1.1
|(1321) ------------------> (80) |
| GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(1321) ------------------> (80) |
| TCP: http > pip [FIN, ACK] |Seq=110757 Ack=1410 Win=16111 Len=0
|(1321) <------------------ (80) |
| TCP: pip > http [FIN, ACK] | Seq=1410 Ack=110758 Win=16237 Len=0
|(1321) ------------------> (80) |
Figure A.24: Microsoft IIS Opera Video Web Page.
58
A.1.2
Interrupted TCP Flows
|Time
|
|0.000
|
|0.001
|
|0.015
|
|0.074
|
|0.972
|
|0.972
|
|0.972
|
|0.985
|
|0.986
|
|0.993
|
|1.026
|
|1.046
|
|1.046
|
|5.026
|
|20.065
|
|29.617
|
| 192.168.1.3
|
192.168.1.2
|
TCP: oracle-oms > http [SYN]
|(1159) ------------------> (80)
|
TCP: http > oracle-oms [SYN, ACK]
|(1159) <------------------ (80)
|
GET / HTTP/1.1
|(1159) ------------------> (80)
|
GET /WorldMap.jpg
|(1159) ------------------> (80)
|
TCP: oracle-oms > http [RST, ACK]
|(1159) ------------------> (80)
|
TCP: olsv > http [SYN]
|(1160) ------------------> (80)
|
TCP: health-polling > http [SYN]
|(1161) ------------------> (80)
| TCP: http > olsv [SYN, ACK]
|(1160) <------------------ (80)
|
TCP: http > health-polling [SYN, ACK]
|(1161) <------------------ (80)
|
GET /favicon.ico
|(1160) ------------------> (80)
|
GET / HTTP/1.1
|(1161) ------------------> (80)
|
TCP: olsv > http [RST, ACK]
|(1160) ------------------> (80)
|
GET /WorldMap.jpg H
|(1161) ------------------> (80)
|
GET /favicon.ico
|(1161) ------------------> (80)
|TCP: http > health-polling [FIN, ACK]
|(1161) <------------------ (80)
|
TCP: health-polling > http [FIN, ACK]
|(1161) ------------------> (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|Seq=743 Ack=2468246 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=146
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET / HTTP/1.1
|
|Seq=347 Ack=135781 Win=0 Len=0
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=3568273 Ack=1356 Win=8576 Len=0
|
| Seq=1356 Ack=3568274 Win=64558 Len=0
|
Figure A.25: Apache Firefox Picture Web Page.
59
|Time
|
|1.575
|
|1.717
|
|1.718
|
|2.542
|
|2.544
|
|2.572
|
|2.573
|
|2.573
|
|2.574
|
|2.581
|
|2.596
|
|13.287
|
|136.380
|
|136.382
|
| 192.168.1.3
|
192.168.1.4
|
TCP: x9-icue > http [SYN]
|(1145) ------------------> (80)
|
TCP: http > x9-icue [SYN, ACK]
|(1145) <------------------ (80)
|
GET / HTTP/1.1
|(1145) ------------------> (80)
| TCP: audit-transfer > http [SYN]
|(1146) ------------------> (80)
|
TCP: http > audit-transfer [SYN, ACK]
|(1146) <------------------ (80)
|
TCP: x9-icue > http [RST, ACK]
|(1145) ------------------> (80)
|
GET /favicon.ico
|(1146) ------------------> (80)
| TCP: capioverlan > http [SYN]
|(1147) ------------------> (80)
|
TCP: http > capioverlan [SYN, ACK]
|(1147) <------------------ (80)
|
GET / HTTP/1.1
|(1147) ------------------> (80)
|
TCP: audit-transfer > http [RST, ACK]
|(1146) ------------------> (80)
|
GET /favicon.ico
|(1147) ------------------> (80)
|
TCP: capioverlan > http [FIN, ACK]
|(1147) ------------------> (80)
| TCP: http > capioverlan [FIN, ACK]
|(1147) <------------------ (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
| Seq=366 Ack=828853 Win=0 Len=0
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|Seq=347 Ack=32769 Win=0 Len=0
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=845 Ack=2804661 Win=65535 Len=0
|
| Seq=2804661 Ack=846 Win=16676 Len=0
|
Figure A.26: Apache Firefox Text Web Page.
60
|Time
|
|0.002
|
|0.003
|
|0.015
|
|0.084
|
|0.743
|
|0.745
|
|0.776
|
|1.723
|
|1.723
|
|2.195
|
|17.551
|
|29.599
|
| 192.168.1.4
|
|
192.168.1.2 |
|
TCP: ias-admind > http [SYN]
|Seq=0 Win=65535 Len=0 MSS=1460
|(2141) ------------------> (80)
|
| TCP: http > ias-admind [SYN, ACK]
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2141) <------------------ (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2141) ------------------> (80)
|
|
GET /favicon.ico
|HTTP: GET /favicon.ico HTTP/1.1
|(2141) ------------------> (80)
|
| TCP: tdmoip > http [SYN]
| Seq=0 Win=65535 Len=0 MSS=1460
|(2142) ------------------> (80)
|
| TCP: http > tdmoip [SYN, ACK]
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|(2142) <------------------ (80)
|
|
GET /htmlsample.
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|(2142) ------------------> (80)
|
| TCP: tdmoip > http [RST, ACK]
|Seq=411 Ack=1910217 Win=0 Len=0
|(2142) ------------------> (80)
|
|
GET / HTTP/1.1
|HTTP: GET / HTTP/1.1
|(2141) ------------------> (80)
|
|
GET /htmlsample.
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|(2141) ------------------> (80)
|
|
TCP: http > ias-admind [FIN, ACK]
| Seq=695985 Ack=1667 Win=9648 Len=0
|(2141) <------------------ (80)
|
| TCP: ias-admind > http [FIN, ACK]
| Seq=1667 Ack=695986 Win=65535 Len=0
|(2141) ------------------> (80)
|
Figure A.27: Apache Firefox Video Web Page.
Figure A.28: Apache Google Chrome Video Web Page.
61
Figure A.29: Apache Google Chrome Text Web Page.
|Time
|
|0.084
|
|0.085
|
|0.086
|
|0.915
|
|0.916
|
|0.918
|
|0.918
|
|1.340
|
|1.359
|
|1.369
|
|1.897
|
|1.897
|
|2.052
|
|2.053
|
|2.054
|
|2.056
|
|2.058
|
|2.059
|
|2.059
|
|2.059
|
|17.597
|
|22.591
|
| 192.168.1.4
|
192.168.1.2
|
TCP: netop-school > http [SYN]
|(1971) ------------------> (80)
| TCP: http>netop-school[SYN, ACK]
|(1971) <------------------ (80)
|
GET / HTTP/1.1
|(1971) ------------------> (80)
|
GET /htmlsample.
|(1971) ------------------> (80)
|
TCP: intersys-cache > http [SYN]
|(1972) ------------------> (80)
|
TCP:http>intersys-cache[SYN, ACK]
|(1972) <------------------ (80)
|
GET /favicon.ico
|(1972) ------------------> (80)
|
GET / HTTP/1.1
|(1972) ------------------> (80)
|
TCP: intersys-cache > http [FIN, ACK]
|(1972) ------------------> (80)
|
TCP: http > intersys-cache [FIN, ACK]
|(1972) <------------------ (80)
|
TCP: netop-school > http [FIN, ACK]
|(1971) ------------------> (80)
|
TCP: netop-school > http [RST, ACK]
|(1971) ------------------> (80)
|
TCP: dlsrap > http [SYN]
|(1973) ------------------> (80)
| TCP: http > dlsrap [SYN, ACK]
|(1973) <------------------ (80)
|
GET /htmlsample.
|(1973) ------------------> (80)
|
TCP: dlsrap > http [FIN, ACK]
|(1973) ------------------> (80)
|
TCP: drp > http [SYN]
|(1974) ------------------> (80)
|
TCP: http > dlsrap [FIN, ACK]
|(1973) <------------------ (80)
|
TCP: http > drp [SYN, ACK]
|(1974) <------------------ (80)
|
GET /htmlsample.
|(1974) ------------------> (80)
|
TCP: http > drp [FIN, ACK]
|(1974) <------------------ (80)
|
TCP: drp > http [FIN, ACK]
|(1974) ------------------> (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET / HTTP/1.1
|
| Seq=858 Ack=212532 Win=65326 Len=0
|
| Seq=212532 Ack=859 Win=8000 Len=0
|
|Seq=775 Ack=1305401 Win=1296 Len=0
|
| Seq=776 Ack=1305401 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=486 Ack=192 Win=65344 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
| Seq=192 Ack=487 Win=6912 Len=0
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 WS=6
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=1158352 Ack=430 Win=6912 Len=0
|
| Seq=430 Ack=1158353 Win=65536 Len=0
|
Figure A.30: Apache Google Chrome Video Web Page.
62
|Time
|
|0.000
|
|0.001
|
|0.001
|
|0.077
|
|2.005
|
|2.071
|
|2.072
|
|2.072
|
|2.075
|
|4.068
|
|19.143
|
|24.134
|
| 192.168.1.3
|
192.168.1.2
|
TCP: td-postman > http [SYN]
|(1049) ------------------> (80)
|
TCP: http > td-postman [SYN, ACK]
|(1049) <------------------ (80)
|
GET / HTTP/1.1
|(1049) ------------------> (80)
|
GET /WorldMap.jpg
|(1049) ------------------> (80)
|
TCP: td-postman > http [RST, ACK]
|(1049) ------------------> (80)
| TCP: cma > http [SYN]
|(1050) ------------------> (80)
| TCP: http > cma [SYN, ACK]
|(1050) <------------------ (80)
|
GET / HTTP/1.1
|(1050) ------------------> (80)
|
GET /WorldMap.jpg
|(1050) ------------------> (80)
|
GET /favicon.ico
|(1050) ------------------> (80)
| TCP: http > cma [FIN, ACK]
|(1050) <------------------ (80)
| TCP: cma > http [RST, ACK]
|(1050) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
| Seq=481 Ack=3919119 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=2255744 Ack=895 Win=8576 Len=0
|
|Seq=895 Ack=2255745 Win=0 Len=0
|
Figure A.31: Apache Internet Explorer Picture Web Page.
|Time
|
|0.000
|
|0.002
|
|0.002
|
|15.184
|
|20.152
|
|105.173
|
|105.174
|
|105.174
|
|105.351
|
|120.368
|
|125.355
|
| 192.168.1.3
|
192.168.1.2
| TCP: gpfs > http [SYN]
|(1191) ------------------> (80)
|
TCP: http > gpfs [SYN, ACK]
|(1191) <------------------ (80)
|
GET / HTTP/1.1
|(1191) ------------------> (80)
| TCP: http > gpfs [FIN, ACK]
|(1191) <------------------ (80)
| TCP: gpfs > http [RST, ACK]
|(1191) ------------------> (80)
|
TCP: caids-sensor > http [SYN]
|(1192) ------------------> (80)
|
TCP: http > caids-sensor [SYN, ACK]
|(1192) <------------------ (80)
|
GET /favicon.ico
|(1192) ------------------> (80)
|
GET / HTTP/1.1
|(1192) ------------------> (80)
|
TCP: http > caids-sensor [FIN, ACK]
|(1192) <------------------ (80)
|
TCP: caids-sensor > http [RST, ACK]
|(1192) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|Seq=40820 Ack=220 Win=6432 Len=0
|
|Seq=220 Ack=40821 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET / HTTP/1.1
|
| Seq=212536 Ack=521 Win=7504 Len=0
|
|Seq=521 Ack=212537 Win=0 Len=0
|
Figure A.32: Apache Internet Explorer Picture Text Page.
63
|Time
|
|0.000
|
|0.001
|
|0.001
|
|0.073
|
|0.076
|
|0.259
|
|0.260
|
|0.260
|
|0.914
|
|1.671
|
|1.816
|
|1.817
|
|1.817
|
|1.821
|
|1.823
|
|1.922
|
|1.923
|
|1.939
|
|17.780
|
|22.766
|
| 192.168.1.4
|
192.168.1.2
|
TCP: dls > http [SYN]
|(2047) ------------------> (80)
|
TCP: http > dls [SYN, ACK]
|(2047) <------------------ (80)
|
GET / HTTP/1.1
|(2047) ------------------> (80)
|
GET /htmlsample.
|(2047) ------------------> (80)
|
TCP: dls > http [RST, ACK]
|(2047) ------------------> (80)
|
TCP: dls-monitor > http [SYN]
|(2048) ------------------> (80)
| TCP: http > dls-monitor [SYN, ACK]
|(2048) <------------------ (80)
|
GET /favicon.ico
|(2048) ------------------> (80)
|
GET /htmlsample.
|(2048) ------------------> (80)
|
TCP: dls-monitor > http [RST, ACK]
|(2048) ------------------> (80)
|
TCP: nfs > http [SYN]
|(2049) ------------------> (80)
|
TCP: http > nfs [SYN, ACK]
|(2049) <------------------ (80)
|
GET / HTTP/1.1
|(2049) ------------------> (80)
|
GET /htmlsample.
|(2049) ------------------> (80)
|
TCP: nfs > http [RST, ACK]
|(2049) ------------------> (80)
|
TCP: av-emb-config > http [SYN]
|(2050) ------------------> (80)
|
TCP: http > av-emb-config [SYN, ACK]
|(2050) <------------------ (80)
|
GET /htmlsample.mpe
|(2050) ------------------> (80)
|
TCP: http > av-emb-config [FIN, ACK]
|(2050) <------------------ (80)
|
TCP: av-emb-config > http [RST, ACK]
|(2050) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=306 Ack=3402 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=417 Ack=562446 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=513 Ack=1671 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=2096810 Ack=327 Win=6432 Len=0
|
| Seq=327 Ack=2096811 Win=0 Len=0
|
Figure A.33: Apache Internet Explorer Video Web Page.
|Time
|
|0.001
|
|0.002
|
|0.123
|
|0.136
|
|1.304
|
|2.055
|
|2.056
|
|2.057
|
|2.061
|
|4.821
|
|19.945
|
|20.029
|
| 192.168.1.3
|
192.168.1.2
|
TCP: mosaicsyssvc1 > http [SYN]
|(1235) ------------------> (80)
|
TCP: http > mosaicsyssvc1 [SYN, ACK]
|(1235) <------------------ (80)
|
GET / HTTP/1.1
|(1235) ------------------> (80)
|
GET /WorldMap.jpg
|(1235) ------------------> (80)
|
TCP: mosaicsyssvc1 > http [RST, ACK]
|(1235) ------------------> (80)
|
TCP: tsdos390 > http [SYN]
|(1237) ------------------> (80)
|
TCP: http > tsdos390 [SYN, ACK]
|(1237) <------------------ (80)
|
GET / HTTP/1.1
|(1237) ------------------> (80)
|
GET /WorldMap.jpg
|(1237) ------------------> (80)
|
GET /favicon.ico
|(1237) ------------------> (80)
|
TCP: http > tsdos390 [FIN, ACK]
|(1237) <------------------ (80)
|
TCP: tsdos390 > http [FIN, ACK]
|(1237) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|Seq=907 Ack=2932234 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=6104214 Ack=1483 Win=8576 Len=0
|
| Seq=1483 Ack=6104215 Win=65535 Len=0
|
Figure A.34: Apache Opera Picture Web Page.
64
|Time
|
|0.000
|
|0.032
|
|0.075
|
|0.888
|
|0.888
|
|1.264
|
|1.266
|
|1.309
|
|4.260
|
|127.526
|
|127.528
|
| 192.168.1.3
|
192.168.1.4
|
TCP: mosaicsyssvc1 > http [SYN]
|(1235) ------------------> (80)
| TCP: http > mosaicsyssvc1 [SYN, ACK]
|(1235) <------------------ (80)
|
GET / HTTP/1.1
|(1235) ------------------> (80)
|
TCP: mosaicsyssvc1 > http [RST, ACK]
|(1235) ------------------> (80)
| TCP: mosaicsyssvc1 > http [RST]
|(1235) ------------------> (80)
| TCP: tsdos390 > http [SYN]
|(1237) ------------------> (80)
| TCP: http > tsdos390 [SYN, ACK]
|(1237) <------------------ (80)
|
GET / HTTP/1.1
|(1237) ------------------> (80)
|
GET /favicon.ico
|(1237) ------------------> (80)
| TCP: tsdos390 > http [FIN, ACK]
|(1237) ------------------> (80)
|
TCP: http > tsdos390 [FIN, ACK]
|(1237) <------------------ (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| Seq=407 Ack=1275317 Win=0 Len=0
|
|Seq=407 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=958 Ack=3510148 Win=65098 Len=0
|
| Seq=3510148 Ack=959 Win=16563 Len=0
|
Figure A.35: Apache Opera Text Web Page.
|Time
|
|7.493
|
|7.494
|
|7.562
|
|7.617
|
|9.138
|
|10.238
|
|10.239
|
|10.240
|
|10.755
|
|11.650
|
|27.385
|
|27.490
|
| 192.168.1.4
|
192.168.1.2
|
TCP: intrastar > http [SYN]
|(1907) ------------------> (80)
| TCP: http > intrastar [SYN, ACK]
|(1907) <------------------ (80)
|
GET / HTTP/1.1
|(1907) ------------------> (80)
|
GET /htmlsample.
|(1907) ------------------> (80)
| TCP: intrastar > http [RST, ACK]
|(1907) ------------------> (80)
|
TCP: global-wlink > http [SYN]
|(1909) ------------------> (80)
|
TCP: http > global-wlink [SYN, ACK]
|(1909) <------------------ (80)
|
GET / HTTP/1.1
|(1909) ------------------> (80)
|
GET /htmlsample.
|(1909) ------------------> (80)
|
GET /favicon.ico
|(1909) ------------------> (80)
|
TCP: http > global-wlink [FIN, ACK]
|(1909) <------------------ (80)
|
TCP: global-wlink > http [FIN, ACK]
|(1909) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=910 Ack=147777 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=2545774 Ack=1486 Win=8576 Len=0
|
| Seq=1486 Ack=2545775 Win=65535 Len=0
|
Figure A.36: Apache Opera Video Web Page.
65
|Time
|
|0.000
|
|0.234
|
|0.235
|
|0.248
|
|1.148
|
|1.148
|
|1.153
|
|1.153
|
|1.155
|
|1.155
|
|1.210
|
|1.210
|
|1.218
|
|1.218
|
|1.222
|
|3.337
|
|119.608
|
|119.841
|
| 192.168.1.4
|
192.168.1.2
|
TCP: intellistor-lm > http [SYN]
|(1539) ------------------> (80)
|
TCP: http > intellistor-lm [SYN, ACK]
|(1539) <------------------ (80)
|
GET / HTTP/1.1
|(1539) ------------------> (80)
|
GET /WorldMap.jpg
|(1539) ------------------> (80)
|
TCP: rds > http [SYN]
|(1540) ------------------> (80)
|
TCP: rds2 > http [SYN]
|(1541) ------------------> (80)
|
TCP: intellistor-lm > http [FIN, ACK]
|(1539) ------------------> (80)
|
TCP: intellistor-lm > http [RST, ACK]
|(1539) ------------------> (80)
|
TCP: http > rds [SYN, ACK]
|(1540) <------------------ (80)
|
TCP: http > rds2 [SYN, ACK]
|(1541) <------------------ (80)
|
GET /favicon.ico
|(1540) ------------------> (80)
|
GET / HTTP/1.1
|(1541) ------------------> (80)
|
TCP: rds > http [FIN, ACK]
|(1540) ------------------> (80)
|
TCP: rds > http [RST, ACK]
|(1540) ------------------> (80)
|
GET /WorldMap.jpg
|(1541) ------------------> (80)
|
GET /favicon.ico
|(1541) ------------------> (80)
|
TCP: rds2 > http [FIN, ACK]
|(1541) ------------------> (80)
|
TCP: http > rds2 [FIN, ACK]
|(1541) <------------------ (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=743 Ack=1872305 Win=64359 Len=0
|
| Seq=744 Ack=1873765 Win=0 Len=0
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET / HTTP/1.1
|
|Seq=347 Ack=10221 Win=65535 Len=0
|
| Seq=348 Ack=11681 Win=0 Len=0
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=1333 Ack=4230606 Win=65165 Len=0
|
| Seq=4230606 Ack=1334 Win=16188 Len=0
|
Figure A.37: Microsoft IIS Firefox Picture Web Page.
66
|Time
|
|15.135
|
|15.137
|
|15.137
|
|16.666
|
|16.667
|
|16.668
|
|16.720
|
|16.720
|
|16.721
|
|16.754
|
|16.769
|
|25.746
|
|149.693
|
|149.694
|
| 192.168.1.3
|
192.168.1.2
|
TCP: dfn > http [SYN]
|(1133) ------------------> (80)
|
TCP: http > dfn [SYN, ACK]
|(1133) <------------------ (80)
|
GET / HTTP/1.1
|(1133) ------------------> (80)
|
TCP: aplx > http [SYN]
|(1134) ------------------> (80)
|
TCP: dfn > http [RST, ACK]
|(1133) ------------------> (80)
|
TCP: http > aplx [SYN, ACK]
|(1134) <------------------ (80)
|
GET /favicon.ico
|(1134) ------------------> (80)
|
TCP: omnivision > http [SYN]
|(1135) ------------------> (80)
|
TCP: http > omnivision [SYN, ACK]
|(1135) <------------------ (80)
|
GET / HTTP/1.1
|(1135) ------------------> (80)
|
TCP: aplx > http [RST, ACK]
|(1134) ------------------> (80)
|
GET /favicon.ico
|(1135) ------------------> (80)
|
TCP: omnivision > http [FIN, ACK]
|(1135) ------------------> (80)
|
TCP: http > omnivision [FIN, ACK]
|(1135) <------------------ (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=366 Ack=1291701 Win=0 Len=0
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| Seq=347 Ack=90113 Win=0 Len=0
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=846 Ack=2283010 Win=65535 Len=0
|
| Seq=2283010 Ack=847 Win=16675 Len=0
|
Figure A.38: Microsoft IIS Firefox Text Web Page.
Microsoft IIS_Firefox_Video Web Page
|Time
|
|15.345
|
|15.347
|
|15.347
|
|15.748
|
|16.712
|
|16.781
|
|16.781
|
|17.760
|
|17.761
|
|17.786
|
|18.200
|
|135.101
|
|135.158
|
| 192.168.1.4
|
192.168.1.2
|
TCP: vpjp > http [SYN]
|(1345) ------------------> (80)
|
TCP: http > vpjp [SYN, ACK]
|(1345) <------------------ (80)
|
GET / HTTP/1.1
|(1345) ------------------> (80)
|
GET /favicon.ico
|(1345) ------------------> (80)
|
TCP: alta-ana-lm > http [SYN]
|(1346) ------------------> (80)
|
TCP: http > alta-ana-lm [SYN, ACK]
|(1346) <------------------ (80)
|
GET /htmlsample
|(1346) ------------------> (80)
|
TCP: alta-ana-lm > http [FIN, ACK]
|(1346) ------------------> (80)
|
TCP: alta-ana-lm > http [RST, ACK]
|(1346) ------------------> (80)
|
GET / HTTP/1.1
|(1345) ------------------> (80)
|
GET /htmlsample.mpe
|(1345) ------------------> (80)
|
TCP: vpjp > http [FIN, ACK]
|(1345) ------------------> (80)
|
TCP: http > vpjp [FIN, ACK]
|(1345) <------------------ (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=411 Ack=1203049 Win=65535 Len=0
|
| Seq=412 Ack=1204225 Win=0 Len=0
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=1655 Ack=1389473 Win=65535 Len=0
|
|Seq=1389473 Ack=1656 Win=17520 Len=0
|
Figure A.39: Microsoft IIS Firefox Video Web Page.
67
Figure A.40: Microsoft IIS Google Chrome Video Web Page.
Figure A.41: Microsoft IIS Google Chrome Text Web Page.
68
|Time
|
|5.458
|
|5.615
|
|5.615
|
|6.314
|
|6.315
|
|6.537
|
|6.538
|
|7.031
|
|7.061
|
|7.064
|
|7.616
|
|7.617
|
|7.762
|
|7.765
|
|7.765
|
|7.768
|
|7.769
|
|7.770
|
|7.771
|
|7.772
|
|245.343
|
|245.345
|
| 192.168.1.4
|
192.168.1.2
|
TCP: norton-lambert > http [SYN]
|(2338) ------------------> (80)
|
TCP: http>norton-lambert[SYN, ACK]
|(2338) <------------------ (80)
|
GET / HTTP/1.1
|(2338) ------------------> (80)
|
GET /htmlsample.
|(2338) ------------------> (80)
|
TCP: 3com-webview > http [SYN]
|(2339) ------------------> (80)
|
TCP: http > 3com-webview [SYN, ACK]
|(2339) <------------------ (80)
|
GET /favicon.ico
|(2339) ------------------> (80)
|
GET / HTTP/1.1
|(2339) ------------------> (80)
|
TCP: 3com-webview > http [FIN, ACK]
|(2339) ------------------> (80)
|
TCP: http > 3com-webview [FIN, ACK]
|(2339) <------------------ (80)
|
TCP: norton-lambert > http [FIN, ACK]
|(2338) ------------------> (80)
|
TCP: norton-lambert > http [RST, ACK]
|(2338) ------------------> (80)
|
TCP: wrs_registry > http [SYN]
|(2340) ------------------> (80)
|
TCP: http>wrs_registry[SYN, ACK]
|(2340) <------------------ (80)
|
GET /htmlsample.
|(2340) ------------------> (80)
|
TCP: wrs_registry > http [FIN, ACK]
|(2340) ------------------> (80)
|
TCP: http > wrs_registry [FIN, ACK]
|(2340) <------------------ (80)
|
TCP: xiostatus > http [SYN]
|(2341) ------------------> (80)
|
TCP: http > xiostatus [SYN, ACK]
|(2341) <------------------ (80)
|
GET /htmlsample.
|(2341) ------------------> (80)
|
TCP: xiostatus > http [FIN, ACK]
|(2341) ------------------> (80)
|
TCP: http > xiostatus [FIN, ACK]
|(2341) <------------------ (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
|Seq=0 Ack=1Win=17520Len=0MSS=1460WS=0
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
|Seq=0Ack=1Win=17520 Len=0 MSS=1460 WS=0
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET / HTTP/1.1
|
| Seq=854 Ack=212442 Win=65348 Len=0
|
| Seq=212442 Ack=855 Win=16667 Len=0
|
| Seq=775 Ack=1161069 Win=0 Len=0
|
|Seq=776 Ack=1161069 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
|Seq=0Ack=1Win=17520Len=0MSS=1460 WS=0
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=478 Ack=141 Win=65396 Len=0
|
|Seq=141 Ack=479 Win=17043 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460 WS=1
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460 WS=0
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=422 Ack=1305028 Win=65536 Len=0
|
| Seq=1305028 Ack=423 Win=17099 Len=0
|
Figure A.42: Microsoft IIS Google Chrome Video Web Page.
|Time
|
|11.690
|
|11.691
|
|11.692
|
|11.733
|
|12.764
|
|12.764
|
|12.768
|
|12.773
|
|12.773
|
|12.777
|
|16.017
|
|76.333
|
| 192.168.1.4
|
192.168.1.2
|
TCP: iclpv-sc > http [SYN]
|(1390) ------------------> (80)
|
TCP: http > iclpv-sc [SYN, ACK]
|(1390) <------------------ (80)
|
GET / HTTP/1.1
|(1390) ------------------> (80)
|
GET /WorldMap.jpg
|(1390) ------------------> (80)
|
TCP: iclpv-sc > http [RST]
|(1390) ------------------> (80)
|
TCP: iclpv-sc > http [RST, ACK]
|(1390) ------------------> (80)
|
TCP: iclpv-sas > http [SYN]
|(1391) ------------------> (80)
|
TCP: http > iclpv-sas [SYN, ACK]
|(1391) <------------------ (80)
|
GET / HTTP/1.1
|(1391) ------------------> (80)
|
GET /WorldMap.jpg
|(1391) ------------------> (80)
|
GET /favicon.ico
|(1391) ------------------> (80)
|
TCP: iclpv-sas > http [RST, ACK]
|(1391) ------------------> (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
| Seq=481 Win=0 Len=0
|
| Seq=481 Ack=1944857 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=881 Ack=4169233 Win=0 Len=0
|
Figure A.43: Microsoft IIS Internet Explorer Picture Web Page.
69
|Time
|
|0.081
|
|0.082
|
|0.083
|
|2.289
|
|2.335
|
|2.436
|
|2.436
|
|37.585
|
|102.962
|
| 192.168.1.3
|
192.168.1.2
| TCP: hacl-qs > http [SYN]
|(1238) ------------------> (80)
|
TCP: http > hacl-qs [SYN, ACK]
|(1238) <------------------ (80)
|
GET / HTTP/1.1
|(1238) ------------------> (80)
|
TCP: hacl-qs > http [RST, ACK]
|(1238) ------------------> (80)
|
TCP: nmsd > http [SYN]
|(1239) ------------------> (80)
|
TCP: http > nmsd [SYN, ACK]
|(1239) <------------------ (80)
|
GET / HTTP/1.1
|(1239) ------------------> (80)
|
GET /favicon.ico
|(1239) ------------------> (80)
|
TCP: nmsd > http [RST, ACK]
|(1239) ------------------> (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| Seq=220 Ack=1710953 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=535 Ack=1799464 Win=0 Len=0
|
Figure A.44: Microsoft IIS Internet Explorer Picture Text Page.
|Time
|
|49.101
|
|49.102
|
|49.102
|
|50.012
|
|50.123
|
|50.794
|
|50.955
|
|50.955
|
|56.776
|
|57.836
|
|58.328
|
|58.398
|
|58.398
|
|58.403
|
|58.405
|
|58.510
|
|58.705
|
|58.706
|
|124.858
|
| 192.168.1.4
|
192.168.1.2
|
TCP: netarx > http [SYN]
|(1040) ------------------> (80)
|
TCP: http > netarx [SYN, ACK]
|(1040) <------------------ (80)
|
GET / HTTP/1.1
|(1040) ------------------> (80)
|
GET /htmlsample.
|(1040) ------------------> (80)
|
TCP: netarx > http [RST, ACK]
|(1040) ------------------> (80)
|
TCP: danf-ak2 > http [SYN]
|(1041) ------------------> (80)
|
TCP: http > danf-ak2 [SYN, ACK]
|(1041) <------------------ (80)
|
GET /favicon.ico
|(1041) ------------------> (80)
|
GET /htmlsample.
|(1041) ------------------> (80)
|
TCP: danf-ak2 > http [RST, ACK]
|(1041) ------------------> (80)
|
TCP: afrog > http [SYN]
|(1042) ------------------> (80)
|
TCP: http > afrog [SYN, ACK]
|(1042) <------------------ (80)
|
GET / HTTP/1.1
|(1042) ------------------> (80)
|
GET /htmlsample.
|(1042) ------------------> (80)
|
TCP: afrog > http [RST, ACK]
|(1042) ------------------> (80)
|
TCP: boinc-client > http [SYN]
|(1043) ------------------> (80)
|
TCP: http > boinc-client [SYN, ACK]
|(1043) <------------------ (80)
|
GET /htmlsample
|(1043) ------------------> (80)
|
TCP: boinc-client > http [RST, ACK]
|(1043) ------------------> (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|Seq=306 Ack=3361 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=417 Ack=350342 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=501 Ack=1649 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
| Seq=265 Ack=2195035 Win=0 Len=0
|
Figure A.45: Microsoft IIS Internet Explorer Video Web Page.
70
|Time
|
|0.186
|
|0.188
|
|0.188
|
|0.194
|
|2.346
|
|2.348
|
|2.349
|
|2.352
|
|5.920
|
|127.776
|
|127.777
|
| 192.168.1.4
|
192.168.1.2
|
TCP: timbuktu-srv3 > http [SYN]
|(1419) ------------------> (80)
|
TCP: http > timbuktu-srv3 [SYN, ACK]
|(1419) <------------------ (80)
|
GET / HTTP/1.1
|(1419) ------------------> (80)
|
GET /WorldMap.jpg
|(1419) ------------------> (80)
|
TCP: timbuktu-srv3 > http [RST, ACK]
|(1419) ------------------> (80)
|
TCP: gandalf-lm > http [SYN]
|(1421) ------------------> (80)
|
TCP: http > gandalf-lm [SYN, ACK]
|(1421) <------------------ (80)
|
GET /WorldMap.jpg
|(1421) ------------------> (80)
|
GET /favicon.ico
|(1421) ------------------> (80)
|
TCP: gandalf-lm > http [FIN, ACK]
|(1421) ------------------> (80)
|
TCP: http > gandalf-lm [FIN, ACK]
|(1421) <------------------ (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
| Seq=907 Ack=3661081 Win=0 Len=0
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET /WorldMap.jpg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=1000 Ack=6103598 Win=65535 Len=0
|
| Seq=6103598 Ack=1001 Win=16521 Len=0
|
Figure A.46: Microsoft IIS Opera Picture Web Page.
|Time
|
|22.561
|
|22.562
|
|22.598
|
|24.293
|
|25.157
|
|25.323
|
|25.323
|
|28.794
|
|151.589
|
|151.590
|
| 192.168.1.3
|
192.168.1.2
|
TCP: ff-annunc > http [SYN]
|(1089) ------------------> (80)
|
TCP: http > ff-annunc [SYN, ACK]
|(1089) <------------------ (80)
|
GET / HTTP/1.1
|(1089) ------------------> (80)
|
TCP: ff-annunc > http [RST, ACK]
|(1089) ------------------> (80)
|
TCP: ff-sm > http [SYN]
|(1091) ------------------> (80)
|
TCP: http > ff-sm [SYN, ACK]
|(1091) <------------------ (80)
|
GET / HTTP/1.1
|(1091) ------------------> (80)
|
GET /favicon.ico
|(1091) ------------------> (80)
| TCP: ff-sm > http [FIN, ACK]
|(1091) ------------------> (80)
| TCP: http > ff-sm [FIN, ACK]
|(1091) <------------------ (80)
|
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
|Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
| Seq=407 Ack=2240513 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
|Seq=958 Ack=3510148 Win=65098 Len=0
|
| Seq=3510148 Ack=959 Win=16563 Len=0
|
Figure A.47: Microsoft IIS Opera Text Web Page.
71
|Time
|
|0.198
|
|0.206
|
|0.206
|
|0.212
|
|3.439
|
|4.043
|
|5.157
|
|5.417
|
|5.418
|
|5.936
|
|6.035
|
|128.609
|
|128.610
|
|
| 192.168.1.4
|
192.168.1.2
|
TCP: prm-sm-np > http [SYN]
|(1402) ------------------> (80)
|
TCP: http > prm-sm-np [SYN, ACK]
|(1402) <------------------ (80)
|
GET / HTTP/1.1
|(1402) ------------------> (80)
|
GET /htmlsample.
|(1402) ------------------> (80)
|
GET /favicon.ico
|(1402) ------------------> (80)
|
TCP: prm-sm-np > http [RST, ACK]
|(1402) ------------------> (80)
|
TCP: igi-lm > http [SYN]
|(1404) ------------------> (80)
|
TCP: http > igi-lm [SYN, ACK]
|(1404) <------------------ (80)
|
GET / HTTP/1.1
|(1404) ------------------> (80)
|
GET /htmlsample.
|(1404) ------------------> (80)
|
GET /favicon.ico
|(1404) ------------------> (80)
|
TCP: igi-lm > http [FIN, ACK]
|(1404) ------------------> (80)
|
TCP: http > igi-lm [FIN, ACK]
|(1404) <------------------ (80)
|
|
| Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=1409 Ack=2407071 Win=0 Len=0
|
|Seq=0 Win=65535 Len=0 MSS=1460
|
| Seq=0 Ack=1 Win=17520 Len=0 MSS=1460
|
|HTTP: GET / HTTP/1.1
|
|HTTP: GET /htmlsample.mpeg HTTP/1.1
|
|HTTP: GET /favicon.ico HTTP/1.1
|
| Seq=1573 Ack=212834 Win=65535 Len=0
|
| Seq=212834 Ack=1574 Win=17520 Len=0
|
Figure A.48: Microsoft IIS Opera Video Web Page.
72
Master Thesis
Electrical Engineering
Thesis no: MEE 62-28
December 2010
RELATIONSHIP BETWEEN NETWORK AND
APPLICATION DOWNLOAD TIMES (WEB)
MOHAMMAD SHAFI KOWSAR
KATTA RAVI KUMAR
School of Computing
Blekinge Institute of Technology
37179 Karlskrona
Sweden
This thesis is submitted to the School of Computing at Blekinge Institute
of Technology in partial 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
Blekinge Institute of Technology
371 79 KARLSKRONA SWEDEN
Internet: www.bth.se/com
Phone: +46 455 385000
SWEDEN
Abstract
Internet has dominated the modern communication and information exchange and it is growing enormously day by day. Initially it is designed to
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 important parameter in evaluating the performance of web service. In this work
we try to correlate the web page download times at both application-level
and network-level. In particular, when there is a considerable delay in the
network, we tried to correlate the application perceived download time with
network-level download time. We explained the difference between application and network download times and how it varies with the applied delay.
This work also shows how the download times at both levels are related to
each other and their 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
1.1 Quality of Service and Quality of Experience . . . . . . . . .
1.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Document Structure . . . . . . . . . . . . . . . . . . . . . . .
2
3
4
5
Background
6
2 Background
2.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Transmission Control Protocol . . . . . . . . . . . . . . . . .
2.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
8
10
Experiment Setup
12
3 Experiment Setup
13
3.1 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Testbed Description: . . . . . . . . . . . . . . . . . . . 13
iii
3.2
3.3
3.1.2 Traffic Shaper: . . . . . . . . . . . . . .
3.1.3 Measurement Area Controller (MArC):
3.1.4 Measurement Point: . . . . . . . . . . .
3.1.5 Consumer: . . . . . . . . . . . . . . . .
3.1.6 Users: . . . . . . . . . . . . . . . . . . .
Experiment Approach and Configuration: . . .
Process involved in the experiment: . . . . . . .
3.3.1 MArC . . . . . . . . . . . . . . . . . . .
3.3.2 Traffic Shaper: . . . . . . . . . . . . . .
3.3.3 Measurement Point (MP): . . . . . . . .
3.3.4 Consumer: . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
14
15
15
15
16
17
17
17
17
18
Results
19
4 Results
4.1 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Average download times: . . . . . . . . . . . . . . . . . . . . .
4.2.1 Page download times for various network delays: . . .
4.3 Relation between network and application-level download times:
20
20
22
24
28
Conclusions and Future Work
34
5 Conclusions and Future Work
35
5.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix
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
2.2
Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . . .
Transmission Control Protocol . . . . . . . . . . . . . . . . .
8
9
3.1
3.2
Experiment setup. . . . . . . . . . . . . . . . . . . . . . . . .
Experiment setup design overview . . . . . . . . . . . . . . .
14
16
4.1
4.2
4.3
NW AVG DT for whole experiment . . . . . . . . . . . . . . .
APP AVG DT for whole experiment . . . . . . . . . . . . . .
Network and Application-level average download times for 0
ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network and Application-level average download times for 75
ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network and Application-level average download times for
150 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network and Application-level average download times for
235 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network and Application-level average download times for
310 ms delay . . . . . . . . . . . . . . . . . . . . . . . . . . .
Average Network and Application download times for different delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
23
4.4
4.5
4.6
4.7
4.8
A.1 Experiment Configuration Network Diagram
v
. . . . . . . . .
24
25
25
26
26
28
38
List of Tables
3.1
Web browsing sessions details . . . . . . . . . . . . . . . . . .
14
4.1
4.2
Calculated average download times for sessions . . . . . . . .
Calculated download times per page . . . . . . . . . . . . . .
22
29
vi
Introduction
1
Chapter 1
Introduction
Internet has become an essential part of today’s communication and information 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 sectors 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-toend 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 network and they have become very crucial in the course of evaluation and
analysis of the Internet traffic. The network service providers normally deploy Network Measurement Infrastructure (NMI) in their networks. This
measurement infrastructure is used to identify the end-to-end performance
in the network and also to study the Internet traffic characteristics [3]. Performance measurements can be carried out using two methods; they are
active and passive measurements. In active measurements, packets are introduced into the network to measure one or more parameters. Examples ping trace-route etc. In passive measurements, the 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 analyse the performance at network-level as they have control over the network.
It includes monitoring QoS parameters such as delay, jitter, packet loss and
throughput. Whereas the end users will not be aware of technical parameters and their performance evaluation will be of more subjective [15]. As web
browsing applications are interactive in nature and the end users would like
to browse the web pages without the delay. So their performance evaluation
mostly depends on the web page response time.
1.1
Quality of Service and Quality of Experience
QoS describes the performance of the service and it is been widely to measure the user’s satisfaction level [11]. It is very crucial to understand how
the end user feels about the performance of the service provided by the network and it is difficult to predict the user’s satisfaction level. By analyzing
huge amount of packet data from the operational network, it is possible to
understand the level of user’s satisfaction. If the user’s satisfaction is low,
then it may leads to the connection termination. A big challenge to the service 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
Experience
User Action
User Satisfaction
Level
Figure 1.1: Relation between QoE, QoS, User satisfaction and User actions.
level increases. Increase in satisfaction level leads to more usage of service
which increases the 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
1.3
5
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 networks. 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 challenging issue as Internet applications are inherent in behaviour and relies on
various parameters. Web is one of the popular Internet applications and to
study the behaviour of the Web 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 following 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
Version H Length
Type of Service
(4 bits)
(4 bits)
(8 bits)
20 Bytes
Total Length (16 bits)
R
Identification (16 bits)
Time to Live
(8 bits)
31
D M
F F
Protocol (8 bits)
Fragmentation Offset
(13 bits)
Header Checksum (16 bits)
Source IP Address (32 bits)
Destination IP Address (32 bits)
IP Options ( If Any )
Padding
Payload
Figure 2.1: Internet Protocol
Total length is the length of the datagram including the header and payload.
It is usually measured in octets. Using the header length and total length it
is easy to locate the end of the header and beginning of the payload in the
IP datagram. The maximum size of the IP datagram is 65535 bytes [14]. A
value will be assigned in 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 transfer the data over the Internet. It is responsible for end to end communication
and it uses ports to transfer the data. It receives the data from the upper
layers and processes using the service provided by the underlying protocols
such as IP. TCP is used by many popular applications mainly WWW and
used as transport protocol for most of the Internet traffic [19]. Web browsing is a reliable service so HTTP uses TCP as transport protocol for data
transfer. In our experiment we are interested in capturing only TCP pack-
CHAPTER 2. BACKGROUND
0
4
9
8
15
Source Port Number (16 bits)
31
Destination Port Number (16 bits)
20 Bytes
Sequence Number (32 bits)
TCP Checksum (16 bits)
FIN
RST
SYN
PSH
Reserved
(6 bits)
ACK
H Length
(4 bits)
URG
Acknowledgement Number (32 bits)
Window Size (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 establishes connection using the sequence number and acknowledgement number and begins the process with a three way handshake [6]. In this process,
the data is transmitted from the sender and the receiver has to acknowledge
each byte of the data that it receives. In web browsing if the user wants to
terminate the connection, in this case he can stop or refresh the connection.
For which FIN and RST 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 performance analysis of web browsing applications traffic. The objective of this
research is to map the download times of application-level traffic to networklevel traffic for web browsing applications and based on the results will correlate 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 perspective. 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 passive 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 parameters to determine the user behaviour. The authors suggested that the
inter-arrival time of connection is an important parameter to estimate the
user behaviour.
A study has been done on analysis of HTTP 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 applications 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 approaches have been used to measure the web browsing QoE. Some of the
approaches are subjective in nature. This is done by collecting the user
ratings to evaluate the user perceived performance. In this [16] work it has
been analyzed that the 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 evaluation of Internet traffic. In the present knowledge there is no work which
maps the page download times of Web traffic at both application and networklevel. There is a gap between the application-level and network-level characteristics on which this work is focused. Our research is a continuation of
previous work, which is performed on network-level for Web traffic. This
work describes the correlation between application and network-level performance characteristics. This can be used as a measure to evaluate the
performance of the Web 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 applicationlevel on client machine. Using the captured packets from the measurement
point the network-level download time can also be computed.
3.1.1
Testbed Description:
In this section a detailed explanation of the actual experiment setup is described, which is used to perform the experiments. It consists of various
components and how they work with each other. The block diagram of
the entire setup is shown in Figure 3.2. To compute the download time at
network-level, the packet traces are collected using DPMI. The following
sections describe the complete description of each component of DPMI.
13
CHAPTER 3. EXPERIMENT SETUP
14
Traffic Shaper
Users
Web Server
Measurement
Point
Figure 3.1: Experiment setup.
Table 3.1: Web browsing sessions details
3.1.2
Session
No of Pages
1
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.4
4.1
4.2
4.3
4.4
22
6
6
6
6
6
6
6
6
6
6
6
6
Input Delay to
Traffic Shaper (ms)
0
0
75
150
310
235
150
75
0
75
150
75
235
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 parameters. 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 component in the setup. MArC is the Web server where the web pages are hosted,
CHAPTER 3. EXPERIMENT SETUP
15
which is accessed by the user. The database server (SQL) and apache server
are also installed in this machine. Database server is used to log user and
Web server logging information. MArC provides the GUI to control the
measurement points and also manages MP by supplying filters[1]. The experiment controller manages the remaining elements in the network. MArC
has three interfaces. One of the MArC interface is connected to external
public network. Second interface is connected to the private network in
which user system is connected. The third interface is connected to switch.
MArC acts as DHCP server and it provide private IPs to 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 network elements.
3.1.4
Measurement Point:
It is a network device used to capture the packets at network-level. In the
current scenario, the measurement point is a Linux machine with Endace
DAG (Data Acquisition and Generation) network cards [17]. It is a powerful
packet capture interface card used to capture traffic on high-speed networks.
The DAG card has also port to provide time stamp and clock synchronization. We connected the DAG card to the external NTP server to provide
the clocking synchronization. The MP will intercept the packet transmission
and capture the packets as per the filters which are controlled by Measurement Area Controller (MArC). It further transfers the captured data to
consumer which is connected to Measurement Area Network (MArN).
3.1.5
Consumer:
The consumer is a Linux machine which is directly connected to switch. It
is connected to the management network of the setup. Consumer acquires
dynamic private IP and clocking synchronization from the Web server. The
consumer converts the captured packet data into desired form as per the
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
Traffic Shaper
Measurement
Point
Experiment Controller (or)
WEB Server
Figure 3.2: Experiment setup design overview
network elements in the setup so that the timestamps in all the machines
are accurate.
3.2
Experiment Approach and 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 networklevel. These download times will be compared to that of download times
measured at application-level. The following paragraphs describe the process involved in this experiment.
The user machine and the Web server are connected to the same network so that the user can access the web pages. The web pages consists of
pictures and the user has to rate each web page based on its performance.
At the same time we captured the packet traces of each web page using the
MP. We run this experiment with 20 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 increasing fashion i.e. 0 ms, 75 ms, 150 ms and 310 ms. Session 3 delays are
CHAPTER 3. EXPERIMENT SETUP
17
applied in decreasing fashion i.e. 235 ms, 150 ms, 75 ms and 0 ms. Session
4 delays are applied in alternate fashion. The 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
3.3.1
Process involved in the experiment:
MArC
To measure the accurate time stamp of the packets, all the devices in the
setup are synchronized to external NTP server. The experimental controller
is directly connected to external network using which the remaining devices
in the setup obtain timing synchronization. So before starting the experiment the Web server has to run NTP service using which it acquires synchronization with NTP server. As the apache server is installed in MArC, the
server access logs needs to be cleared so that we can note the correct server
log information. A sample of Web server log is shown below Figure 3.3.1.
And 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
Session
1
2.1
2.2
2.3
2.4
3.1
3.2
3.3
3.4
4.1
4.2
4.3
4.4
4.2
Input Delay to
Traffic Shaper (ms)
0
0
75
150
310
235
150
75
0
75
150
75
235
NW AVG DT (sec)
APP AVG DT (sec)
0.33
0.38
2.35
4.52
8.78
7.17
4.73
2.37
0.42
2.43
4.71
2.48
5.63
0.38
0.44
2.46
4.69
9.09
7.45
4.92
2.48
0.47
2.53
4.88
2.59
5.85
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
Min NW DT
Avg NW DT
Max NW DT
14
Download Time [sec]
12
10
8
6
4
2
0
0
10
20
30
40
50
60
70
80
90
Page Number
Figure 4.1: NW AVG DT for whole experiment
Min APP DT
Avg APP DT
Max APP DT
14
Download Time [sec]
12
10
8
6
4
2
0
0
10
20
30
40
50
60
70
80
Page Number
Figure 4.2: APP AVG DT for whole experiment
90
CHAPTER 4. RESULTS
24
0.8
NW Avg DT
App Avg DT
Download Time [sec]
0.7
0.6
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 experiment, the download time is calculated for each page for all the users and the
graphs are drawn. Figure 4.1 shows the average network-level page download time for the entire experiment. From the 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 browsing the pages the users are allowed to rate the performance of each web
page which can be used to study further. The Figure 4.3 shows the graph
of network as well as application-level web page download times for all the
users without applying any delay at the shaper (0 ms). The maximum
and minimum page download times at network-level are 0.45 sec and 0.35
sec. The maximum and minimum page download times at application-level
are 0.41 sec and 0.51 sec. The average 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
NW Avg DT
App Avg DT
3.3
Download Time [sec]
3
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
Download Time [sec]
5.5
5
4.5
4
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
Download Time [sec]
7.5
7
6.5
6
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
Download Time [sec]
11
10
9
8
7
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 standard deviation (NW DT STD) for all the users. Similarly sixth and seventh
columns represents the application-level page download time (APP AVG
DT) and its standard deviation (APP DT STD). From the table it can be
noted that for some web pages the standard deviation is more than other
web pages like page number 35, 41, 42 and 43 etc. This is due to the fact
that if the download time for one of the user is more than normal time, then
it will increase the standard deviation of that particular page. The same is
shown in both network as well as application-level.
Session
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
2.1
2.1
Page No
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Table 4.2: Calculated download times per page
Input Delay to
NW AVG DT (sec) NW DT STD APP AVG DT (sec)
Traffic Shaper (ms)
0
0.35
0.126
0.43
0
0.37
0.023
0.41
0
0.34
0.026
0.40
0
0.31
0.007
0.37
0
0.32
0.008
0.37
0
0.31
0.014
0.36
0
0.34
0.011
0.38
0
0.33
0.006
0.38
0
0.33
0.082
0.39
0
0.31
0.063
0.38
0
0.33
0.007
0.37
0
0.33
0.006
0.39
0
0.32
0.014
0.38
0
0.33
0.006
0.38
0
0.32
0.014
0.38
0
0.33
0.009
0.38
0
0.31
0.011
0.38
0
0.31
0.015
0.39
0
0.32
0.011
0.37
0
0.34
0.011
0.38
0
0.32
0.006
0.38
0
0.32
0.007
0.38
0
0.45
0.007
0.53
0
0.32
0.01
0.38
0.19
0.03
0.027
0.009
0.007
0.011
0.069
0.009
0.083
0.012
0.017
0.017
0.030
0.009
0.017
0.022
0.013
0.017
0.015
0.014
0.007
0.018
0.025
0.025
APP DT STD
CHAPTER 4. RESULTS
29
Session
2.1
2.1
2.1
2.1
2.2
2.2
2.2
2.2
2.2
2.2
2.3
2.3
2.3
2.3
2.3
2.3
2.4
2.4
2.4
2.4
2.4
2.4
3.1
3.1
Page No
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
Input Delay to
Traffic Shaper (ms)
0
0
0
0
75
75
75
75
75
75
150
150
150
150
150
150
310
310
310
310
310
310
235
235
0.33
0.34
0.32
0.55
2.08
2.41
2.54
2.27
2.66
2.16
4.51
4.50
4.17
5.22
3.98
4.73
8.29
8.57
9.77
8.01
9.26
8.76
7.35
7.50
NW AVG DT (sec)
0.011
0.011
0.007
0.938
0.373
0.253
0.226
0.198
0.163
0.169
1.152
0.415
0.393
0.422
0.326
0.324
1.227
1.642
2.006
0.853
0.622
0.982
0.505
0.453
NW DT STD
0.37
0.38
0.37
0.60
2.18
2.52
2.63
2.37
2.76
2.27
4.66
4.66
4.39
5.33
4.20
4.87
8.48
8.97
10.08
8.48
9.52
9.03
7.62
7.81
APP AVG DT (sec)
0.014
0.018
0.006
0.946
0.377
0.255
0.239
0.196
0.161
0.165
1.137
0.451
0.339
0.482
0.305
0.342
1.341
1.563
2.132
0.737
0.752
1.095
0.535
0.325
APP DT STD
CHAPTER 4. RESULTS
30
Session
3.1
3.1
3.1
3.1
3.2
3.2
3.2
3.2
3.2
3.2
3.3
3.3
3.3
3.3
3.3
3.3
3.4
3.4
3.4
3.4
3.4
3.4
4.1
4.1
4.1
4.1
4.1
4.1
Page No
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
Input Delay to
Traffic Shaper (ms)
235
235
235
235
150
150
150
150
150
150
75
75
75
75
75
75
0
0
0
0
0
0
75
75
75
75
75
75
6.77
6.99
7.23
7.19
5.05
4.46
4.50
4.49
4.80
5.09
2.60
2.36
2.30
2.38
2.41
2.20
0.72
0.34
0.36
0.34
0.37
0.36
2.32
2.36
2.59
2.45
2.38
2.48
NW AVG DT (sec)
0.879
0.489
0.318
0.443
0.452
0.407
0.216
0.194
1.146
1.095
0.419
0.183
0.143
0.194
0.204
0.266
0.096
0.012
0.014
0.015
0.020
0.019
0.297
0.219
0.677
0.341
0.183
0.553
NW DT STD
7.06
7.29
7.50
7.43
5.30
4.64
4.68
4.66
4.98
5.26
2.71
2.47
2.41
2.48
2.51
2.31
0.78
0.41
0.41
0.40
0.43
0.42
2.42
2.47
2.69
2.55
2.47
2.61
APP AVG DT (sec)
0.840
0.443
0.308
0.446
0.363
0.406
0.216
0.195
1.141
1.093
0.414
0.175
0.144
0.191
0.203
0.268
0.094
0.013
0.014
0.013
0.025
0.021
0.297
0.220
0.686
0.341
0.178
0.605
APP DT STD
CHAPTER 4. RESULTS
31
Session
4.2
4.2
4.2
4.2
4.2
4.2
4.3
4.3
4.3
4.3
4.3
4.3
4.4
4.4
4.4
4.4
4.4
4.4
Page No
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
Input Delay to
Traffic Shaper (ms)
150
150
150
150
150
150
75
75
75
75
75
75
235
235
235
235
235
235
4.37
4.84
4.56
5.05
4.56
4.91
2.85
2.25
2.67
2.34
2.31
2.47
5.59
5.83
5.52
5.44
5.95
5.44
NW AVG DT (sec)
0.575
0.571
0.664
0.348
0.315
1.186
0.288
0.309
0.689
0.297
0.278
0.242
0.550
0.556
0.689
0.649
0.615
0.572
NW DT STD
4.55
5.01
4.69
5.22
4.73
5.08
2.94
2.34
2.79
2.47
2.42
2.57
5.88
6.10
5.78
5.63
6.13
5.57
APP AVG DT (sec)
0.573
0.574
0.604
0.347
0.315
1.183
0.293
0.320
0.687
0.241
0.258
0.254
0.503
0.551
0.712
0.606
0.580
0.623
APP DT STD
CHAPTER 4. RESULTS
32
CHAPTER 4. RESULTS
28
10
NW AVG DT
APP AVG DT
page download time [sec]
9
8
7
6
5
4
3
2
1
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 performed 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 download time. We have also measured the application-level page download time
using the web browser. This section describes the mapping between both
download times in order to calculate the 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 network 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 application 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 performance 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 network level. Using the computed values from Table 4.3, the network-level
and application-level average download times can be written as
APP AVG DT = NW AVG DT + ∆tavg
where ∆tavg =


0.05 sec


 0.1 sec

0.2 sec



0.3 sec
for 0 ms applied delay
for 100 ms applied delay
for 200 ms applied delay
for 300 ms applied delay
Table 4.4: Relation between network and application download times
Regression
Correlation 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 regression 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 correlations between the network and application download times. On one side
we measured the application-level download time using the browser log and
on the other side at network-level calculated the download time using the
captured packet traces. We investigated and shown that as the delay increases, the page download time gap between network and application-level
increases and derived a possible relation. We mapped both the levels of
download times and shown that that they are linearly related to each other
and calculated the coefficient of correlation. Using these expressions and
network-level download times, we can evaluate application perceived download times. This relation can also be used as a measure for service providers
in computing the performance of the Web 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-1
eth-2
eth-0
10.0.0.1
eth-0
10.0.0.243
eth-0
10.0.0.215
10.0.1.208
eth-2
194.47.148.77
B if-1
B if-0
eth-1
10.0.1.1
User
Traffic Shaper
Measurement
Point
MArC
Figure A.1: Experiment Configuration Network Diagram
External XPS
Network
Bibliography
[1] Patrik Arlos, Markus Fiedler, and Arne A. Nilsson. A distributed passive measurement infrastructure. In PAM2005, pages 215–227, 2005.
[2] Yogesh Bhole and Adrian Popescu. Measurement and analysis of http
traffic. Journal of Network and Systems Management, 13:357–371,
2005. 10.1007/s10922-005-9000-y.
[3] P. Calyam, D. Krymskiy, M. Sridharan, and P. Schopis. Active and
passive measurements on campus, regional and national network backbone paths. In Computer Communications and Networks, 2005. ICCCN
2005. Proceedings. 14th International Conference on, pages 537 – 542,
2005.
[4] Y. C. Chehadeh, A. Z. Hatahet, A. E. Agamy, M. A. Bamakhrama,
and S. A. Banawan. Investigating distribution of data of http 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 Papagiannaki, and Olivier Bonaventure, editors, Passive and Active Network
Measurement, volume 4427 of Lecture Notes in Computer Science, pages
233–236. Springer Berlin / Heidelberg, 2007. 10.1007/978-3-540-71617425.
[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 characteristics for estimating quality of experience. In GLOBECOM Workshops, 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 Conference on Web Information Systems and Technologies (WebIST2007),
Barcelona, Spain, March 2007.
39
BIBLIOGRAPHY
40
[9] M. Golja, I. Humar, D. Bodnaruk, and J. Bester. Wmpstat: a tool
for measuring the correlation between application and network layer
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 Liakopulos Martin Swany Steven Van den Berghe David Schmitz Maurizio Molina, Andy Van Maele, editor. Deliverable DJ1.2.3 Network
Metric Report, Project GN2. 14.02.06, EC Contract No : 511082, Document Code GN2-05-265v4.
[13] I. Pais and M. Almeida. End user behavior and performance feedback
for service analysis. In Intelligence in Next Generation Networks, 2009.
ICIN 2009. 13th International Conference on, pages 1 –6, 2009.
[14] Venkata Santosh Pemmaraju. Real-Time Live RTT Analyzer. PhD
thesis, Blekinge Institute of Technology, 2010.
[15] Junaid Shaikh, Markus Fiedler, and Denis Collange. Quality of experience from user and network perspectives. Annals of Telecommunications, 65:47–57, 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-capturecards.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 University, School of Innovation, Design and Engineering 2008. Malardalen
University Press Licentiate Theses, ISBN 978-91-86135-08-9; ISSN
1651-9256; 95.
BIBLIOGRAPHY
41
[20] Larry Wall. The perl programming language, [Online; Verified November 2010] Available:. http://www.perl.org.
[21] Meinberg : Solutions for Time and Frequency Synchronization. Meinberg ntp software, [Online; Verified November 2010] Available:.
http://www.meinberg.de/english/sw/ntp.htm.
[22] Mills, D. Network time protocol (version 3) specification, implementation, 1992.
[23] Mozilla Firefox Web Browser, [Online; Verified November 2010] Available:. http://www.mozilla-europe.org/en/firefox/.
[24] Netem
Network
Emulation.
The
linux
foundation,
[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
Blekinge Institute of Technology
371 79 KARLSKRONA SWEDEN
Internet: www.bth.se/com
Phone: +46 455 385000
SWEDEN
Abstract
Over the years, there has been an exponential increase in the capabilities
of networks, evolving from wired networks to wireless, and 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 devices 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’ expectations were not being met. This thesis highlights few interesting points
on the energy consumptions by the most common Internet browsing tasks.
It then presents the measurements of energy consumption on using various
network connection technologies namely Ethernet, Wi-Fi and 3G to access
the Internet. The obtained data from the experiments were then analyzed
to arrive at an idea on the 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
1.1 Introduction . . . . . .
1.2 Background . . . . . .
1.3 Objective of this thesis
1.4 Research Questions . .
1.5 Research Methodology
1.6 Thesis Layout . . . . .
2
2
2
2
3
3
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Analysis
5
2 Related Study
2.1 Introduction . . . . . . . . .
2.2 Network Technologies . . .
2.2.1 Ethernet . . . . . . .
2.2.2 Wi-Fi . . . . . . . .
2.2.3 3G . . . . . . . . . .
2.3 Energy Efficient Technology
6
6
6
6
6
7
7
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Proposals
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2.4
2.5
2.6
Battery Development . . . . .
Customer Perspectives . . . .
QoE . . . . . . . . . . . . . .
2.6.1 QoE Factors . . . . .
2.6.2 User groups and Tasks
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
9
9
9
10
Implementation
12
3 Implementation
3.1 Experimental Setup . . . . . . . .
3.1.1 Configuration and Settings
3.1.2 Network Types . . . . . . .
3.1.3 Browsing Tasks . . . . . . .
3.2 Trial Flowchart . . . . . . . . . . .
3.3 Parameters and Software Tools . .
3.3.1 Parameters . . . . . . . . .
3.3.2 Software Tools . . . . . . .
3.4 Survey . . . . . . . . . . . . . . . .
13
13
13
14
14
15
15
15
17
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Results
21
4 Results
4.1 Introduction . . . . . . . . . . . . .
4.2 Energy Consumption Comparison 4.2.1 Idle Mode . . . . . . . . . .
4.2.2 Browsing Tasks . . . . . . .
4.3 Survey Results . . . . . . . . . . .
22
22
22
22
24
27
. . . . . . . .
Time Based .
. . . . . . . .
. . . . . . . .
. . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Conclusions
33
5.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Future Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Appendix
A Experments and Results
A.1 Survey Data . . . . . .
A.2 Energy Consumptions
A.3 Discharge Curves . . .
35
Data
36
. . . . . . . . . . . . . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . 38
. . . . . . . . . . . . . . . . . . . . . . 50
Bibliography
54
iv
List of Figures
3.1
3.2
3.3
3.4
3.5
3.6
Task Flowchart . . . . .
Charge/Discharge Curve
BatteryMon . . . . . . .
BatteryMon Log File . .
Imtec Battery Mark . .
BatteryCare . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
16
17
18
18
19
19
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
Discharge Rate . . . . . . . . .
Idle Mode Energy Consumption
Ethernet Energy Consumption
Wi-Fi Energy Consumption . .
3G Energy Consumption . . . .
Browsing Tasks . . . . . . . . .
Network Usage . . . . . . . . .
Preference . . . . . . . . . . . .
Quality Parameters . . . . . . .
Willingness . . . . . . . . . . .
Browsing Time . . . . . . . . .
Battery Backup . . . . . . . . .
Battery Upgradation . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
26
26
28
28
29
30
31
31
32
A.1 Discharge Rate (Ethernet) . . . . . . . . . . . . . . . . . . . .
A.2 Discharge Rate (Wi-Fi) . . . . . . . . . . . . . . . . . . . . .
A.3 Discharge Rate (3G) . . . . . . . . . . . . . . . . . . . . . . .
51
52
53
v
List of Tables
2.1
User Groups and tasks . . . . . . . . . . . . . . . . . . . . . .
11
3.1
3.2
Laptop Configuration . . . . . . . . . . . . . . . . . . . . . .
Types of Networks . . . . . . . . . . . . . . . . . . . . . . . .
13
14
4.1
4.2
4.3
Network Usage Vs User Preference . . . . . . . . . . . . . . .
Quality parameters . . . . . . . . . . . . . . . . . . . . . . . .
Time spent on Browsing Vs Battery Backup . . . . . . . . . .
29
30
32
A.1 Network Usage . . . . . . . . . . . . .
A.2 Preference . . . . . . . . . . . . . . . .
A.3 Quality Parameters . . . . . . . . . . .
A.4 Willingness and Battery Upgradation .
A.5 Browsing Time . . . . . . . . . . . . .
A.6 Idle Mode: Ethernet . . . . . . . . . .
A.7 Idle Mode: Wi-Fi . . . . . . . . . . . .
A.8 Idle Mode:3G . . . . . . . . . . . . . .
A.9 Gmail:Ethernet . . . . . . . . . . . . .
A.10 Gmail:Wi-Fi . . . . . . . . . . . . . . .
A.11 Gmail:3G . . . . . . . . . . . . . . . .
A.12 YouTube 720p:Ethernet . . . . . . . .
A.13 YouTube 720p:Wi-Fi . . . . . . . . . .
A.14 YouTube 720p:3G . . . . . . . . . . .
A.15 YouTube 360p:Ethernet . . . . . . . .
A.16 YouTube 360p:Wi-Fi . . . . . . . . . .
A.17 YouTube 360p:3G . . . . . . . . . . .
A.18 Game:Ethernet . . . . . . . . . . . . .
A.19 Game:Wi-Fi . . . . . . . . . . . . . . .
A.20 Game:3G . . . . . . . . . . . . . . . .
A.21 Download:Ethernet . . . . . . . . . . .
A.22 Download:Wi-Fi . . . . . . . . . . . .
A.23 Download:3G . . . . . . . . . . . . . .
A.24 Upload: Wi-Fi . . . . . . . . . . . . .
A.25 Upload: 3G . . . . . . . . . . . . . . .
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
37
37
37
39
39
40
40
41
41
42
42
43
43
44
44
45
45
46
46
47
47
48
48
A.26 Upload:Ethernet . . . . . . . . . . . . . . . . . . . . . . . . .
vii
49
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
haven’t 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 connections and correlate with Quality of Experience (QoE) to see the impacts.
1.3
Objective of this thesis
The study is a search for better choice among the mostly used network
technologies with respect to energy consumption. Features related to battery
capacities and fading of the gap between network connection technologies
2
CHAPTER 1. PROBLEM IDENTIFICATION
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 performed on the Internet?
4. If the answer to the previous question is yes, are there some interesting
observations?
5. Are there any important factors considered by users that 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 questionnaire to the users is followed by a deep look at the literature. Coming
to quantitative approach, an empirical study with experimental setup was
carried on.
The objective of this thesis is 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
1.6
4
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 it’s potential to provide the demanded
power sources to the mobile devices.
Chapter three provides an understanding of the experimental setup which
includes the tools that were used. It discusses about the various tasks that
were chosen to perform and study for the results and analysis. It also explains the conditions and network environment under which the experimentation was carried out. The chapter also contains the information about the
survey targeted to the various user groups.
Chapter four discusses about the results and analysis. The chapter also
shows the results obtained from survey 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 network type. This is termed as Network Interface and is further used in the
document for reference.
2.2.1
Ethernet
An Ethernet LAN typically uses coaxial cable or special types of twisted pair
wires. The most commonly used Ethernet systems are known as 10BASE-T
with transmission speeds up to 10 Mbps. Fast Ethernet or 100BASE-T have
transmission speeds of up-to 100 megabits per second. Gigabit Ethernet is
a transmission technology based on the Ethernet that provides a data rate
of 1 billion bits per second.
2.2.2
Wi-Fi
Wi-Fi is the name for the wireless Ethernet 802.11b standard for WLANs. It
supports data rates of up-to 11 Mbps within distances of up-to 150 meters.
6
CHAPTER 2. RELATED STUDY
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 semiconductor technology, power efficient system designs and implementation has
become extremely important in today’s 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 technologies, 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 potential and also provides the largest energy density per weight. Therefore
Li-ion is rapidly growing and has proved to be most promising battery chemistry. However, the technology has few limitations listed below.
Power density
One of main concerns, power density, was a huge limitation in Lithium
Ion battery technology in the 90s. Though the technology has drastically
changed the way the Lithium Ion batteries are constructed in current times,
constant demand from the users for more power kept demanding for more
and more with no specific satisfactory levels to be met. As the current capacities have not been able to provide such demands, we can say that the Power
density is one of the factors restricting the vendors from manufacturing such
batteries.
Contingencies
Users have been growing continuously with constant rise of expectations for
long performance time intervals without self discharge and multiple years of
service before any replacement. In respect to these demands, Lithium-ion
CHAPTER 2. RELATED STUDY
9
batteries seem to be meeting the performance challenge of some power products, so the maximum we can ask of competitive chemistries is equivalent
power densities at reasonable and comparable costs.
Cost
The cost 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 world’s population are
Internet users. Moreover, 9.5 % of world’s population are mobile broadband 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 regardless of what network interface that is being used. Choosing a type of network
depends on the suitability of a service to that network. However, suitability
of a service is a user specific phenomenon depending on one’s 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 account certain QoE factors related to user(customer) perception were studied
which are listed below. Network resources and pricing were also considered
for the literature.
2.6
QoE
“Quality of Experience (QoE) has been 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 it’ll be worthwhile to know
how important accessibility is to particular user based on his daily usage.
Instantaneity
Instantaneity deals with the duration in which data is transferred and received [21]. How long was the duration of a particular session, and how
much time did it take to establish a connection. The survey showed that
mobile broadband users have 14% lesser satisfaction level in web browsing
activity than fixed broadband users due to many factors such as slower webpage loading [22]. In the context of weight-capacity relationship, Since a
user can only browse for a limited period (due to limited capacities), speed
of a particular network can be a crucial factor which determines how much
time does a user browse the internet.
Integrity
Integrity deals with the success rate with which the data is transferred from
one end to the other [21]. In the case of video streaming, success rate
is a crucial factor because multimedia coding is highly correlated to the
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
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,
Users
Browsing
11
Light
Mobile broadband has some advantages that are appealing to a certain
section of users who perform light browsing tasks such as emailing, on-line
shopping and on-line banking. So, for users who are traveling a lot, mobile
broadband is the best option when factors such as no line rental, lack of
mobility are concerned. but, on the 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, online 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
3.1.1
Experimental Setup
Configuration and Settings
Table 3.1: Configuration of
Component
Processor
Internal Memory
Operating System
Wireless Network Adapter
Ethernet Card
Battery
Packard Bell-EasyNote TJ75
Specifications
Intel Core i5 @ 2.27 GHz
4 GB RAM
Windows 7, 64-bit
Atheros AR5B93
Broadcom Gigabit
Chemical Composition –
Li-ion, Model – Panasonic
AS09A51, Capacity=48600
mWh
For this experiment, Packard Bell-EasyNote TJ75 was used with specific processing and networking configurations as mentioned in Table 3.1.
Therefore, the energy consumptions of the tasks are specific to these specific 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 battery accordingly. However, in order to maintain a balance between the
energy consumption of the screen and proper browsing experience, medium
brightness level was chosen throughout the experiment. All the trials of the
experiment were conducted on Firefox browser[?]. Browser preferences such
as browser.cache.memory.enable and browser.cache.disk.enable were set to
13
CHAPTER 3. IMPLEMENTATION
14
false in order to disable browsing caching. By disabling browser caching,
accurate analysis of results can be done because the browser makes HTTP
request every time the task is conducted. It was made sure that all non
Operating System applications were prevented from running during the experimentation. The only applications which were running during the trials
were critical system processes, browser application and the battery tools.
3.1.2
Network Types
Three types of networks were considered in this experiment. The trials using
Ethernet and Wi-Fi networks were conducted on campus (SUNET/NORDUnet)
and residential (BAHNHOF AB) networks. For 3G network, Telenor subscribed Huawei Technologies Co., Ltd. E220 HSDPA USB Modem modem
was used.
Table 3.2: Types of networks and corresponding
Network Type ISP
Ethernet
BAHNHOF
AB,
SUNET/NORDUnet
Wi-Fi
BAHNHOF
AB,
SUNET/NORDUnet
3G
Telenor
3.1.3
ISPs with network speeds
Speed
Downlink: 95 Mbps and Uplink: 24 Mbps
Downlink: 10 Mbps and Uplink: 9 Mbps
Downlink:2 - 5 Mbps and Uplink: 0.35 Mbps
Browsing Tasks
The tasks selected for this experiment were chosen based on certain criterion. for the trials, browsing tasks were considered since in the Nokia
Siemens survey it was mentioned that web browsing is the most activity
on the Internet. The web browsing activities were divided into tasks such
as video streaming, downloading and uploading, email browsing and online
gaming. Video streaming was done using YouTube360p and YouTube720p
[25] while downloading and uploading is done using popular 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 conducting the browsing tasks. Only the battery tools and OS applications were running in the background to see how much energy was
consumed by these processes alone.
CHAPTER 3. IMPLEMENTATION
15
2. Gmail: Login into the account, read the 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
3.3.1
Parameters and Software Tools
Parameters
The following parameters were analyzed in the experimentation to understand 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
Figure 3.1: Experimentation Process Flowchart
16
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
Figure 3.3: Graphical Interface of BatteryMon
Figure 3.4: BatteryMon Log File
18
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 consumptions 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: Participant’s most used network for Internet browsing.
2. Network Preference: Participant’s 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: Participant’s time spent on browsing per day.
6. Battery Backup: How much time does the participant’s battery last.
7. Battery Upgradation: Is the participant willing to upgrade his battery?
Results
21
Chapter 4
Results
4.1
Introduction
The results from the experiments conducted are discussed and analyzed in
this chapter. Energy consumption using 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
4.2.1
Energy Consumption Comparison - Time Based
Idle Mode
From Fig 4.1, the discharge rate curves of a battery in Idle mode operation
is shown. It can be observed that the discharge rate caused by all networks
is almost equal during the initial stages. However, with the increase in time
there are gradual variations in the discharge rate caused by the three networks. This happens even if the network interfaces are not being used for
data transfer. Therefore, the power that has been consumed should ideally
be due to only the standard processes and applications.
However, mere power ON state of the network interface alone has caused
a 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 compared for each network connection type.
Ethernet
From Fig 4.3, it may be observed that the YouTube 720p task is the highest energy consuming browsing task. After YouTube 720p, it was YouTube
360p which consumed higher energy followed by Online gaming. This is
followed by Gmail and Upload tasks while Download task consumed the
least. It should be observed in the 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 gaming. The upload task has caused relatively lesser discharge than online
gaming. The lowest discharge was during Download task followed by Gmail
access. Even though the value of energy consumptions of download and idle
mode are equal, download task has higher standard deviation than that of
idle mode which may be seen in tables A.7 and A.22. Therefore, it could be
concluded that download task does consume more energy than the idle mode.
3G
From Fig 4.5, it can be observed that online game, YouTube 360 and
YouTube 720 caused the highest discharge rate. The upload task has caused
relatively lesser discharge than online gaming. The lowest discharge was
during Download task followed by Gmail access. From these results, it is
observed that the graphic rich tasks have always caused highest discharge
rates in all the network types.
Overall Comparisons
From the energy consumptions 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 discharge of the battery. The least energy consumption state with each interface turned on is the Idle state. Other tasks that consumed lesser energy
are Gmail, Download and Upload tasks on the Internet. It can be observed
from the 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 ranging from students to employees. The following subsections discuss about the
results obtained through the Survey.
Usage
From the survey conducted as seen in Fig 4.7, it was determined that Wi-Fi
networks are most commonly used networks. This is followed by Ethernet.
The least number of users are connected through 3G for Internet connectivity.
Preference
As the Fig 4.8 shows, it was found that most of the users prefer to use
wireless network technologies to wired networks. Among Wi-Fi and 3G, the
later is of greater preference. This is a 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 observed in Table 4.1. It should be noted that most of the participants of the
survey were familiar to all types of networks. Therefore, each participant
was asked about the level of usage/preference for each type of network, based
CHAPTER 4. RESULTS
Figure 4.7: Network Usage
Figure 4.8: Preference of Network
28
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
Network
Ethernet
Wi-Fi
3G
4.1: Comparison of Network Usage and User Preference
% Usage
% Preference
% Change
85.71%
68.25%
17.4% decrease
96.83%
88.89%
7.9% decrease
44.44%
65.08%
20.6% increase
Quality Parameters
From Fig 4.9, it has also been found from the survey that speed and availability of a network are two very important parameters that users look for
while choosing a network. These are followed by ease of access and cost of
accessing a network . The order of preference for various quality parameters
considered while choosing a network can be found from Table 4.2.
CHAPTER 4. RESULTS
30
Table 4.2: Quality parameters
Parameter
%Importance
Speed
68.25%
Availability
58.73%
Ease of Access 46.03%
Cost
31.75%
Figure 4.10: Willingness to use an other Network
Willingness
From Fig 4.10, One of the interesting 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
Figure 4.11: Time spent browsing on battery
Figure 4.12: Battery Backup on most Laptops
31
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 consumption in 3G networks. It was known that the best of 3G has supporting data
rates much lesser when compared with Ethernet and Wi-Fi. The quality
of experience rating on 3G networks is not up-to Ethernet and Wi-Fi. To
conclude on the energy consumption note in 3G networks, it is the highest
player.
It was found from the survey that as much as 20.6 % increase in the
preference of 3G users from Ethernet and Wi-Fi if the network provision is
available. This can be attributed to the mobility factor with 3G connections. However, few users from this group might as well look for a speedy
connection and lower power consumption. As it is already known, 3G has
the highest power consumption and not so high network speeds compared
to Ethernet and Wi-Fi. The worst impact will be on users who are willing
to move towards 3G networks and are prepared to use services such as video
33
CHAPTER 5. CONCLUSIONS
34
streaming sites like YouTube which have diverse applications to all types of
users ranging from vlogging to on-line classes.
It could also be stated that more number of users as high as 65 % are
willing to shift to an alternate network if it consumes relatively lesser power.
It is also seen that almost 50 percent of the users use the Internet for more
than 4 hours per day on battery power. However, from the survey it was
known that this is not being met. In fact, users who could get battery
backup of more than 4 hours is as low as 16%. It is interesting to observe
that almost 79% of users have plans to upgrade their batteries as the backup
time is not being met. However, current battery technologies have their own
limitations in meeting such high numbers being demanded. Therefore, it can
be concluded that users could be made aware of the power consumptions of
various networks. This would give them a better idea about what options
they get to choose before selecting a particular network. In this way, users
could be encouraged to use Ethernet more, whenever and wherever possible.
This meets the users expectations like able to get more battery backup and
at the same time keeping the QoE standards high.
5.2
Future Scope
Our thesis includes calculating energy consumptions on three types of networks and correlating with survey results based on basic QoE questions.
Future scope could be more 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 measurements are obtained from electronic equipment rather than software.
This would enable one to extend the tasks to longer periods with precise
measurements and observations. A deeper study may be carried out to drill
down onto the reasons for 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
Network Usage
Ethernet
Wi-Fi
3G
Preference
Ethernet
Wi-Fi
3G
37
Table A.1: Network Usage
Never Occasionally Frequently
8
30
13
2
4
14
26
20
4
Table A.2: Preference
Never Occasionally Frequently
7
21
13
0
3
12
12
20
12
Table A.3: Quality Parameters
Parameter NOT IMP LEAST IMP IMP
Speed
1
1
17
Availability
0
7
18
Ease of Access
7
10
17
Cost
12
10
21
Always
11
43
4
Always
12
46
9
V IMP
43
37
29
20
Table A.4: Willingness and Battery Upgradation
Willingness Battery Upgradation
YES
41
50
NO
22
13
Table A.5: Browsing Time
Battery Backup Browsing Time
< 1 Hour
5
10
1-2 Hours
25
13
2-4 Hours
23
10
> 4 Hours
10
30
APPENDIX A. EXPERMENTS AND RESULTS DATA
A.2
Energy Consumptions
38
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial 13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Table A.6: Idle Mode: Ethernet
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48454.2
45781.2
2673
48114
45392.4
2721.6
48308.4
45586.8
2721.6
48600
45878.4
2721.6
48600
45878.4
2721.6
48308.4
45586.8
2721.6
48454.2
45781.2
2673
48600
45878.4
2721.6
48357
45635.4
2721.6
48600
45878.4
2721.6
48454.2
45781.2
2673
48114
45392.4
2721.6
48600
45878.4
2721.6
48308.4
45586.8
2721.6
48600
45878.4
2721.6
48431.52
45720
2711.88
174.1351987
176.6363 20.12231171
Table A.7: Idle Mode: Wi-Fi
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48600
45878.4
2721.6
47968.2
45246.6
2721.6
48600
45927
2673
47968.2
45149.4
2818.8
47968.2
45198
2770.2
48357
45635.4
2721.6
48600
45927
2673
47968.2
45246.6
2721.6
47968.2
45149.4
2818.8
47968.2
45198
2770.2
48600
45878.4
2721.6
47968.2
45149.4
2818.8
48600
45927
2673
47968.2
45246.6
2721.6
47968.2
45198
2770.2
48205
45463.68
2741
305.648723
345.0583702
51.30203
39
Remaining
Time(Hrs)
1.44
1.43
1.44
1.43
1.45
1.44
1.44
1.43
1.45
1.43
1.44
1.43
1.43
1.44
1.45
1.438
0.007746
Remaining
Time(Hrs)
1.41
1.46
1.42
1.4
1.4
1.41
1.42
1.46
1.4
1.4
1.41
1.4
1.42
1.46
1.4
1.418
0.023052735
Remaining
Time(Mins)
86.4
85.8
86.4
85.8
87
86.4
86.4
85.8
87
85.8
86.4
85.8
85.8
86.4
87
86.28
0.464758002
Remaining
Time(Mins)
84.6
87.6
85.2
84
84
84.6
85.2
87.6
84
84
84.6
84
85.2
87.6
84
85.08
1.383164
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
40
Table A.8: Idle Mode:3G
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48065.4
45198
2867.4
48600
45684
2916
48600
45829.8
2770.2
48114
45295.2
2818.8
47919.6
45052.2
2867.4
48357
45441
2916
48065.4
45198
2867.4
48600
45829.8
2770.2
48114
45295.2
2818.8
47919.6
45052.2
2867.4
48065.4
45198
2867.4
47919.6
45052.2
2867.4
48600
45829.8
2770.2
48114
45295.2
2818.8
48551.4
45635.4
2916
48240
45392.4
2848
277.245247
293.9051742
51.30203
Remaining
Time(Hrs)
1.37
1.35
1.39
1.39
1.36
1.35
1.37
1.39
1.39
1.36
1.37
1.36
1.39
1.39
1.35
1.372
0.016561573
Remaining
Time(Mins)
82.2
81
83.4
83.4
81.6
81
82.2
83.4
83.4
81.6
82.2
81.6
83.4
83.4
81
82.32
1.073313
Table A.9: Gmail:Ethernet
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48357
45586.8
2770.2
48600
45586.8
3013.2
48016.8
45246.6
2770.2
48162.6
45343.8
2818.8
48259.8
45489.6
2770.2
48551.4
45538.2
3013.2
48357
45586.8
2770.2
48016.8
45246.6
2770.2
48162.6
45343.8
2818.8
48259.8
45489.6
2770.2
48405.6
45635.4
2770.2
48551.4
45538.2
3013.2
48016.8
45246.6
2770.2
48162.6
45343.8
2818.8
48259.8
45489.6
2770.2
48276
45447.48
2828.5
194.110499
138.521165 97.546525
Remaining
Time(Hrs)
1.42
1.43
1.42
1.4
1.39
1.43
1.42
1.42
1.4
1.39
1.42
1.43
1.42
1.4
1.39
1.412
0.015212777
Remaining
Time(Mins)
85.2
85.8
85.2
84
83.4
85.8
85.2
85.2
84
83.4
85.2
85.8
85.2
84
83.4
84.72
0.912767
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
AVG
STD DEV
41
Table A.10: Gmail:Wi-Fi
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48357
45538.2
2818.8
48016.8
45246.6
2770.2
48259.8
45489.6
2770.2
48114
45343.8
2770.2
48357
45538.2
2818.8
48308.4
45489.6
2818.8
48259.8
45489.6
2770.2
48016.8
45246.6
2770.2
48357
45538.2
2818.8
48114
45343.8
2770.2
48357
45538.2
2818.8
48016.8
45246.6
2770.2
48357
45538.2
2818.8
48114
45343.8
2770.2
48357
45586.8
2770.2
48224
45434.52
2789.6
141.652436
124.404428 24.644698
Remaining
Time(Hrs)
1.41
1.42
1.41
1.4
1.39
1.41
1.42
1.41
1.39
1.4
1.41
1.42
1.39
1.4
1.41
1.406
0.010555973
Table A.11: Gmail:3G
Initial
Final
Capacity(mWh) Capacity(mWh)
47871
44906.4
48600
45343.8
48065.4
45149.4
48551.4
45295.2
47871
44906.4
47871
44906.4
48065.4
45149.4
48600
45343.8
48016.8
45100.8
48168
45122.4
321.866727
183.6397016
Remaining
Time(Hrs)
1.33
1.32
1.34
1.33
1.32
1.33
1.34
1.32
1.33
1.328889
0.00781736
Difference
(mWh)
2964.6
3256.2
2916
3256.2
2964.6
2964.6
2916
3256.2
2916
3045.6
159.34576
Remaining
Time(Mins)
84.6
85.2
84.6
84
83.4
84.6
85.2
84.6
83.4
84
84.6
85.2
83.4
84
84.6
84.36
0.633358
Remaining
Time(Mins)
79.8
79.2
80.4
79.2
79.8
79.8
80.4
79.2
79.8
79.73
0.469042
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
42
Table A.12: YouTube 720:Ethernet
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48357
45392.4
2964.6
47968.2
45003.6
2964.6
48357
45343.8
3013.2
48114
45149.4
2964.6
48065.4
45100.8
2964.6
48308.4
45343.8
2964.6
47968.2
45003.6
2964.6
48162.6
45198
2964.6
48357
45343.8
3013.2
48065.4
45100.8
2964.6
48357
45392.4
2964.6
47968.2
45003.6
2964.6
48357
45343.8
3013.2
48065.4
45100.8
2964.6
48114
45149.4
2964.6
48172
45198
2974.3
159.292809
148.0962043 20.122312
Remaining
Time(Hrs)
1.32
1.31
1.31
1.31
1.31
1.32
1.31
1.31
1.31
1.31
1.32
1.31
1.31
1.31
1.31
1.312
0.004140393
Remaining
Time(Mins)
79.2
78.6
78.6
78.6
78.6
78.6
78.6
78.6
78.6
78.6
79.2
78.6
78.6
78.6
78.6
78.68
0.211119
Table A.13: YouTube 720:Wi-Fi
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48114
45100.8
3013.2
48065.4
45052.2
3013.2
48600
45489.6
3110.4
47919.6
44906.4
3013.2
48600
45538.2
3061.8
48551.4
45441
3110.4
48065.4
45052.2
3013.2
48114
45100.8
3013.2
47919.6
44906.4
3013.2
48600
45538.2
3061.8
48114
45100.8
3013.2
48065.4
45052.2
3013.2
48600
45489.6
3110.4
48551.4
45489.6
3061.8
47919.6
44906.4
3013.2
48253
45210.96
3042.4
287.44323
252.1764484 40.244623
Remaining
Time(Hrs)
1.28
1.32
1.27
1.3
1.27
1.27
1.32
1.28
1.3
1.27
1.28
1.32
1.27
1.27
1.3
1.288
0.020071301
Remaining
Time(Mins)
76.8
79.2
76.2
78
76.2
76.2
79.2
76.8
78
76.2
76.8
79.2
76.2
76.2
78
77.28
1.204278
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
43
Table A.14: YouTube 720p:3G
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
47919.6
44712
3207.6
48308.4
45149.4
3159
48065.4
44906.4
3159
48308.4
45198
3110.4
47968.2
44906.4
3061.8
48016.8
44857.8
3159
48308.4
45149.4
3159
47919.6
44712
3207.6
48308.4
45198
3110.4
47968.2
44906.4
3061.8
47919.6
44712
3207.6
48308.4
45149.4
3159
47968.2
44906.4
3061.8
48308.4
45198
3110.4
48114
44955
3159
48114
44974.44
3139.6
172.317183
185.3365772
51.30203
Remaining
Time(Hrs)
1.26
1.25
1.24
1.26
1.28
1.24
1.25
1.26
1.26
1.28
1.26
1.25
1.28
1.26
1.24
1.258
0.013732131
Table A.15: YouTube 360p:Ethernet
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48308.4
45392.4
2916
47919.6
45003.6
2916
48259.8
45343.8
2916
48308.4
45295.2
3013.2
48114
45149.4
2964.6
48259.8
45343.8
2916
47919.6
45003.6
2916
48357
45441
2916
48308.4
45295.2
3013.2
48114
45149.4
2964.6
48308.4
45392.4
2916
48308.4
45295.2
3013.2
48259.8
45343.8
2916
47968.2
45052.2
2916
48114
45149.4
2964.6
48189
45243.36
2945.2
152.437487
146.3390037 40.244623
Remaining
Time(Hrs)
1.35
1.33
1.34
1.32
1.34
1.34
1.33
1.35
1.32
1.34
1.35
1.32
1.34
1.33
1.34
1.336
0.010556
Remaining
Time(Mins)
75.6
75
74.4
75.6
76.8
74.4
75
75.6
75.6
76.8
75.6
75
76.8
75.6
74.4
75.48
0.823928
Remaining
Time(Mins)
81
79.8
80.4
79.2
80.4
80.4
79.8
81
79.2
80.4
81
79.2
80.4
79.8
80.4
80.16
0.633358
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
44
Table A.16: YouTube 360p:Wi-Fi
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48308.4
45343.8
2964.6
48308.4
45343.8
2964.6
48357
45586.8
2770.2
48600
45586.8
3013.2
48357
45295.2
3061.8
48502.8
45489.6
3013.2
48308.4
45343.8
2964.6
48357
45586.8
2770.2
48308.4
45343.8
2964.6
48357
45295.2
3061.8
48308.4
45343.8
2964.6
48308.4
45343.8
2964.6
48551.4
45538.2
3013.2
48357
45586.8
2770.2
48357
45295.2
3061.8
48376
45421.56
2954.9
95.0943351
122.9493554 102.60406
Remaining
Time(Hrs)
1.31
1.35
1.34
1.32
1.33
1.32
1.35
1.34
1.31
1.33
1.31
1.35
1.32
1.34
1.33
1.33
0.0146385
Remaining
Time(Mins)
78.6
81
80.4
79.2
79.8
79.2
81
80.4
78.6
79.8
78.6
81
79.2
80.4
79.8
79.8
0.87831
Table A.17: YouTube 360p:3G
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48065.4
45052.2
3013.2
48357
45198
3159
48600
45489.6
3110.4
48016.8
44857.8
3159
47968.2
44906.4
3061.8
48551.4
45441
3110.4
48357
45198
3159
48016.8
44857.8
3159
48065.4
45052.2
3013.2
47968.2
44906.4
3061.8
48016.8
44857.8
3159
48357
45198
3159
48600
45489.6
3110.4
48065.4
45052.2
3013.2
47968.2
44906.4
3061.8
48198
45097.56
3100.7
244.016161
230.5056454 58.666116
Remaining
Time(Hrs)
1.27
1.25
1.28
1.23
1.27
1.28
1.25
1.23
1.27
1.27
1.23
1.25
1.28
1.27
1.27
1.26
0.0185164
Remaining
Time(Mins)
76.2
75
76.8
73.8
76.2
76.8
75
73.8
76.2
76.2
73.8
75
76.8
76.2
76.2
75.6
1.110984
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
45
Table A.18: Game:Ethernet
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48357
45489.6
2867.4
47919.6
45003.6
2916
48308.4
45343.8
2964.6
48162.6
45295.2
2867.4
48162.6
45246.6
2916
48357
45489.6
2867.4
47919.6
45003.6
2916
48308.4
45343.8
2964.6
48162.6
45246.6
2916
48114
45246.6
2867.4
48357
45489.6
2867.4
47919.6
45003.6
2916
48211.2
45295.2
2916
48162.6
45295.2
2867.4
48308.4
45343.8
2964.6
48182
45275.76
2906.3
158.868593
164.0924861 37.645398
Remaining
Time(Hrs)
1.35
1.32
1.31
1.35
1.35
1.35
1.32
1.31
1.35
1.34
1.35
1.32
1.35
1.35
1.31
1.3353
0.0176743
Remaining
Time(Mins)
81
79.2
78.6
81
81
81
79.2
78.6
81
80.4
81
79.2
81
81
78.6
80.12
1.060458
Table A.19: Game:Wi-Fi
Initial
Final Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48259.8
45295.2
2964.6
48357
45343.8
3013.2
48211.2
45343.8
2867.4
48357
45392.4
2964.6
48162.6
45246.6
2916
48259.8
45295.2
2964.6
48308.4
45295.2
3013.2
48211.2
45343.8
2867.4
48357
45392.4
2964.6
48162.6
45246.6
2916
48259.8
45295.2
2964.6
48211.2
45343.8
2867.4
48357
45392.4
2964.6
48357
45343.8
3013.2
48162.6
45246.6
2916
48266
45321.12
2945.2
77.6441995
51.52080301
51.30203
Remaining
Time(Hrs)
1.31
1.34
1.3
1.3
1.32
1.31
1.3
1.34
1.3
1.32
1.31
1.34
1.3
1.3
1.32
1.314
0.0154919
Remaining
Time(Mins)
78.6
78
80.4
78
79.2
78.6
78
80.4
78
79.2
78.6
80.4
78
78
79.2
78.84
0.929516
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Table A.20: Game:3G
Initial
Final
Capacity(mWh) Capacity(mWh)
48259.8
45100.8
47968.2
44955
48259.8
45100.8
48065.4
45003.6
47968.2
45003.6
48308.4
45149.4
48259.8
45100.8
47919.6
44906.4
48065.4
45003.6
47968.2
45003.6
48259.8
45100.8
47968.2
44955
47968.2
45003.6
48065.4
45003.6
48259.8
45100.8
48104
45032.76
144.871328
70.6672363
Difference
(mWh)
3159
3013.2
3159
3061.8
2964.6
3159
3159
3013.2
3061.8
2964.6
3159
3013.2
2964.6
3061.8
3159
3071.5
80.489247
Table A.21: Download:Ethernet
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48114
45392.4
2721.6
48016.8
45246.6
2770.2
48016.8
45198
2818.8
48162.6
45392.4
2770.2
48211.2
45489.6
2721.6
48016.8
45198
2818.8
48211.2
45489.6
2721.6
48114
45392.4
2721.6
48162.6
45392.4
2770.2
48016.8
45246.6
2770.2
48162.6
45392.4
2770.2
48211.2
45489.6
2721.6
48016.8
45198
2818.8
48114
45392.4
2721.6
48016.8
45246.6
2770.2
48104
45343.8
2760.48
80.4892468
110.2144403 37.6453981
46
Remaining
Time(Hrs)
1.25
1.26
1.25
1.28
1.27
1.25
1.25
1.26
1.28
1.27
1.25
1.26
1.27
1.28
1.25
1.262
0.0120712
Remaining
Time(Hrs)
1.42
1.43
1.39
1.44
1.41
1.39
1.41
1.42
1.44
1.43
1.44
1.41
1.39
1.42
1.43
1.418
0.0178085
Remaining
Time(Mins)
75
75.6
75
76.8
76.2
75
75
75.6
76.8
76.2
75
75.6
76.2
76.8
75
75.72
0.724273
Remaining
Time(Mins)
85.2
85.8
83.4
86.4
84.6
83.4
84.6
85.2
86.4
85.8
86.4
84.6
83.4
85.2
85.8
85.08
1.06851
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
Trial.No
Trial1
Trial2
Trial3
Trial4
Trial5
Trial6
Trial7
Trial8
Trial9
Trial10
Trial11
Trial12
Trial13
Trial14
Trial15
AVG
STD DEV
47
Table A.22: Download:Wi-Fi
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48308.4
45489.6
2818.8
47968.2
45684
2284.2
48016.8
45198
2818.8
48114
45246.6
2867.4
47919.6
45003.6
2916
48308.4
45489.6
2818.8
48016.8
45198
2818.8
47871
44955
2916
48114
45246.6
2867.4
47968.2
45684
2284.2
48308.4
45489.6
2818.8
48016.8
45198
2818.8
47968.2
45684
2284.2
48162.6
45295.2
2867.4
47919.6
45003.6
2916
48065
45324.36
2741.04
148.096204
249.7113213 239.362489
Remaining
Time(Hrs)
1.38
1.42
1.38
1.39
1.37
1.38
1.42
1.37
1.39
1.38
1.38
1.42
1.38
1.39
1.37
1.388
0.0178085
Remaining
Time(Mins)
82.8
85.2
82.8
83.4
82.2
82.8
85.2
82.2
83.4
82.8
82.8
85.2
82.8
83.4
82.2
83.28
1.06851
Table A.23: Download:3G
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48600
45586.8
3013.2
48016.8
45003.6
3013.2
48065.4
45052.2
3013.2
48114
45052.2
3061.8
47919.6
44955
2964.6
48551.4
45538.2
3013.2
48016.8
45003.6
3013.2
48114
45052.2
3061.8
48065.4
45052.2
3013.2
47919.6
44955
2964.6
47919.6
44955
2964.6
48016.8
45003.6
3013.2
48016.8
45003.6
3013.2
48114
45052.2
3061.8
48600
45586.8
3013.2
48137
45123.48
3013.2
240.814746
234.4246915 31.8161684
Remaining
Time(Hrs)
1.3
1.3
1.3
1.32
1.3
1.3
1.3
1.32
1.3
1.3
1.3
1.3
1.3
1.32
1.3
1.304
0.0082808
Remaining
Time(Mins)
78
78
78
79.2
78
78
78
79.2
78
78
78
78
78
79.2
78
78.24
0.496847
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial 1
Trial 2
Trial 3
Trial 4
Trial 5
Trial 6
Trial 7
Trial 8
Trial 9
Trial 10
Trial 11
Trial 12
Trial 13
Trial 14
Trial 15
avg
std dev
Trial.No
Trial 1
Trial 2
Trial 3
Trial 4
Trial 5
Trial 6
Trial 7
Trial 8
Trial 9
Trial 10
Trial 11
Trial 12
Trial 13
Trial 14
Trial 15
avg
std dev
48
Table A.24: Upload: Wi-Fi
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48357
45489.6
2867.4
48114
45246.6
2867.4
47968.2
45052.2
2916
48259.8
45392.4
2867.4
47919.6
45003.6
2916
47919.6
45003.6
2916
48114
45246.6
2867.4
48357
45489.6
2867.4
48259.8
45392.4
2867.4
47919.6
45003.6
2916
48357
45489.6
2867.4
48259.8
45392.4
2867.4
47968.2
45052.2
2916
48162.6
45295.2
2867.4
47919.6
45003.6
2916
48124
45236.88
2886.84
176.381369
198.8616576 24.6446981
Remaining
Time(Hrs)
1.39
1.4
1.35
1.34
1.35
1.35
1.4
1.39
1.34
1.35
1.39
1.34
1.35
1.4
1.35
1.366
0.0250143
Remaining
Time(Mins)
83.4
84
81
80.4
81
81
84
83.4
80.4
81
83.4
80.4
81
84
81
81.96
1.500857
Table A.25: Upload: 3G
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48065.4
45003.6
3061.8
48162.6
45100.8
3061.8
48600
45295.2
3304.8
48114
45052.2
3061.8
48065.4
45003.6
3061.8
47968.2
45003.6
2964.6
48162.6
45100.8
3061.8
48551.4
45246.6
3304.8
48114
45052.2
3061.8
47968.2
45003.6
2964.6
48065.4
45003.6
3061.8
48211.2
45149.4
3061.8
47968.2
45003.6
2964.6
48114
45052.2
3061.8
48600
45295.2
3304.8
48182
45091.08
3090.96
220.275752
107.4237484 117.332232
Remaining
Time(Hrs)
1.29
1.29
1.31
1.33
1.29
1.31
1.29
1.31
1.33
1.31
1.29
1.29
1.31
1.33
1.31
1.306
0.0154919
Remaining
Time(Mins)
77.4
77.4
78.6
79.8
77.4
78.6
77.4
78.6
79.8
78.6
77.4
77.4
78.6
79.8
78.6
78.36
0.929516
APPENDIX A. EXPERMENTS AND RESULTS DATA
Trial.No
Trial 1
Trial 2
Trial 3
Trial 4
Trial 5
Trial 6
Trial 7
Trial 8
Trial 9
Trial 10
Trial 11
Trial 12
Trial 13
Trial 14
Trial 15
avg
std dev
Table A.26: Upload:Ethernet
Initial
Final
Difference
Capacity(mWh) Capacity(mWh)
(mWh)
48162.6
45392.4
2770.2
47968.2
45149.4
2818.8
48259.8
45489.6
2770.2
48357
45586.8
2770.2
48308.4
45489.6
2818.8
48405.6
45635.4
2770.2
47968.2
45149.4
2818.8
48259.8
45489.6
2770.2
48162.6
45392.4
2770.2
48308.4
45489.6
2818.8
48162.6
45392.4
2770.2
48357
45586.8
2770.2
48259.8
45489.6
2770.2
47919.6
45100.8
2818.8
48308.4
45489.6
2818.8
48211
45421.56
2789.64
152.584983
165.1174335 24.6446981
49
Remaining
Time(Hrs)
1.42
1.42
1.4
1.42
1.38
1.42
1.41
1.4
1.42
1.38
1.42
1.4
1.4
1.42
1.38
1.406
0.0159463
Remaining
Time(Mins)
85.2
85.2
84
85.2
82.8
85.2
84.6
84
85.2
82.8
85.2
84
84
85.2
82.8
84.36
0.95678
APPENDIX A. EXPERMENTS AND RESULTS DATA
A.3
Discharge Curves
50
APPENDIX A. EXPERMENTS AND RESULTS DATA
Figure A.1: Discharge Rate (Ethernet)
51
APPENDIX A. EXPERMENTS AND RESULTS DATA
Figure A.2: Discharge Rate (Wi-Fi)
52
APPENDIX A. EXPERMENTS AND RESULTS DATA
Figure A.3: Discharge Rate (3G)
53
Bibliography
[1] Himayat Nageen. Li Ye. Swami Ananthram. Miao, Guowang. CrossLayer Optimization for Energy-Efficient Wireless Communications: A
Survey. Wireless Communications and Mobile Computing, 9:529–542,
2009.
[2] Himayat Nageen. Li Ye. Swami Ananthram. Miao, Guowang. CrossLayer Optimization for Energy-Efficient Wireless Communications: A
Survey. Wireless Communications and Mobile Computing, 9:529–542,
2009.
[3] K. Pentikousis. In Search of Energy-Efficient Mobile Networking. Communications Magazine, IEEE, 48(1):95 –103, 2010.
[4] M. Pickavet, W. Vereecken, S. Demeyer, P. Audenaert, B. Vermeulen,
C. Develder, D. Colle, B. Dhoedt, and P. Demeester. Worldwide energy needs for ICT: The rise of power-aware networking. In Advanced
Networks and Telecommunication Systems, 2008. ANTS ’08. 2nd International Symposium on, pages 1 –3, 2008.
[5] Cisco Website.
Cisco Visual Networking Index: Forecast and
Methodology, 20092014, [Online; 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 Ratnasamy, and David Wetherall. Reducing Network Energy Consumption via Sleeping and Rate-Adaptation. In Proceedings of the 5th
USENIX Symposium on Networked Systems Design and Implementation, NSDI’08, pages 323–336, Berkeley, CA, USA, 2008. USENIX Association.
[8] C. Gunaratne, K. Christensen, B. Nordman, and S. Suen. Reducing
the Energy Consumption of Ethernet with Adaptive Link Rate (ALR).
Computers, IEEE Transactions on, 57(4):448 –461, 2008.
54
BIBLIOGRAPHY
55
[9] J. Chou.
Proposal of Low-Power Idle:
100basetx,
[Online;
Verified
November]
Available:2010.
http://www.ieee802.org/3/az/public/jan08/chou 01 0108.pdf.
[10] M. Grimwood.
Energy Efficient Ethernet 1000BASET
LPI
Timing
Parameters,
[Online;
Verified
November]
Available:2010.
http://www.ieee802.org/
3/az/public/jul08/grimwood 02 0708.pdf.
[11] P. Reviriego, J.A. Hernandez, D. Larrabeiti, and J.A. Maestro. Performance evaluation of energy 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 Wireless Web Access with Bounded Slowdown. In Proceedings of the 8th
Annual International Conference on Mobile Computing and Networking.
[14] Robin Kravets and P. Krishnan. Power Management Techniques for
Mobile Communication. In Proceedings of the 4th Annual ACM/IEEE
International Conference on Mobile Computing and Networking, MobiCom ’98, pages 157–168, 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:343–358, 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
figures,
[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] Available:2010. http://www.nokiasiemensnetworks.com/news-events/
press-room/press-releases/smart-devices-need-smart-business
-solutions .
BIBLIOGRAPHY
56
[19] D. Lopez, F. Gonzalez, L. Bellido, and A. Alonso. Adaptive multimedia
streaming over IP based on customer oriented metrics. In Computer
Networks, 2006 International Symposium on, pages 185 –191, 2006.
[20] G.P. Perrucci, F.H.P. Fitzek, G. Sasso, W. Kellerer, and J. Widmer. On
the impact of 2G and 3G Network Usage for Mobile Phones’ Battery
Life. In Wireless Conference, 2009. EW 2009. European, pages 255
–259, May 2009.
[21] Yu Du, Wen an Zhou, Bao fu Chen, and Jun de Song. A QoE Based
Evaluation of Service Quality in Wireless Communication Network. In
New Trends in Information and Service Science, 2009. NISS ’09. International Conference on, 30 2009.
[22] Nokia Siemens Networks website.
Smart devices need
smart business solutions, [Online; Verified November] Available:2010. http://www.nokiasiemensnetworks.com/news-events/
press-room/press-releases/smart-devices-need-smart-business
-solutions .
[23] Pablo Belzarena Pedro Casas and Sandrine Vaton. End-2-End Evaluation of IP Multimedia Services, a User Perceived Quality of Service
Approach. In 18th ITC Specialist Seminar on Quality of Experience,
May 2008.
[24] Barry Collins.
Broadband Buyer’s 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
http://www.youtube.com.
November]
Available:2010.
[26] Mediafire,
[Online;
Verified
http://www.mediafire.com.
November]
Available:2010.
[27] Gmail,
[Online;
http://www.gmail.com.
November]
Available:2010.
November]
Available:2010.
Verified
[28] Miniclip,
[Online;
Verified
http://www.miniclip.com.
[29] Chester Simpson.
Characteristics of Rechargable Batteries,
[Online;
Verified
November]
Available:2010.
http://www.national.com/appinfo/power/files/f19.pdf.
[30] American
[Online;
Physical
Society.
Verified
November]
Energy
Units,
Available:2010.
BIBLIOGRAPHY
57
http://www.aps.org/policy/reports/popa-reports/energy/
units.cfm.
[31] Passmark website. BatteryMon, [Online; Verified November] Available:2010. http://www.passmark.com/products/batmon.htm.
[32] Imtec.org. Imtec Battery Mon, [Online; Verified November] Available:2010. http://en.imtec.org.ru/load/7-1-0-5.
[33] Battery Care,
[Online;
Verified November]
http://batterycare.net/en/index.html.
Available:2010.
[34] Speedtest,
[Online;
Verified
http://www.speedtest.com.
Available:2010.
November]
[35] Young-Min Key, Jung-A Kwon, Inkyu Lee, Sang-Chul Han, and
Jee Hyung Lee. The Economic Value of User-Controllable Internet
Speed Service. In Advanced Communication Technology, The 9th International Conference on, volume 1, pages 331 –336, 2007.
Master Thesis
Electrical Engineering
Thesis no: MSC-2010-XXX
December 2010
Analysis of H.264 Sensitivity to Packet Loss and
Delay Variation
Oziel Alejandro Gonzalez Lagunas
School of Computing
Blekinge Institute of Technology
37179 Karlskrona
Sweden
This thesis is submitted to the School of Computing at Blekinge Institute
of Technology in partial 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
Blekinge Institute of Technology
371 79 KARLSKRONA SWEDEN
Internet: www.bth.se/com
Phone: +46 455 385000
SWEDEN
Abstract
The number and popularity of multimedia services and applications on the
Internet has increased greatly in recent years. Services employing real-time
video, such as mobile TV, video-conferencing and tele-medicine are growing,
and the users expectations of quality are increasing.
This thesis analyses the impact on perceived quality of received videos
sent across a network, emulation is used to emulate network characteristics with packet loss and delay variation for video sequences with 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
2 Background
2.1 Key Concepts . . . . . . . .
2.1.1 Video coding . . . .
2.1.2 Video Transmission
2.1.3 Emulation . . . . . .
2.1.4 Quality of Video . .
2.2 Related Work . . . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Design and Implementation
3.1 Aims and Research Questions . . . . . . . . .
3.2 Method . . . . . . . . . . . . . . . . . . . . .
3.3 Design . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Transport Protocol . . . . . . . . . . .
3.3.2 Video Parameters . . . . . . . . . . .
3.3.3 Network emulator . . . . . . . . . . .
3.3.4 Packet loss and delay/delay variation
3.4 Implementation . . . . . . . . . . . . . . . . .
3.4.1 Experimental Setup . . . . . . . . . .
3.4.2 Data Collection . . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
6
6
6
.
.
.
.
.
.
.
.
.
.
9
9
10
11
11
12
15
15
16
16
18
4 Results and Discussion
4.1 Packet loss . . . . . . . .
4.2 Delay variation . . . . . .
4.3 Mobile phone and laptop .
4.4 Validity Threats . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
24
28
31
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
2.2
Spatial and temporal correlation in a video sequence [27] . . .
Example of error propagation [2] . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
Experimental network set-up . . . . . . .
Laptop based assessment . . . . . . . . . .
Mobile Phone assessment . . . . . . . . .
Screen shot of interview set-up for laptop
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
MOS for packet loss displayed on the laptop . . . . . . . . . .
MOS for packet loss displayed on the mobile phone . . . . . .
Confidence interval (95%) for packet loss . . . . . . . . . . . .
Standard deviation for packet loss . . . . . . . . . . . . . . .
MOS for delay variation displayed on the laptop . . . . . . .
MOS for delay variation displayed on the mobile phone . . .
Confidence interval (95%) for delay variation . . . . . . . . .
Standard deviation for delay variation . . . . . . . . . . . . .
MOS packet loss displayed on the laptop and mobile phone .
MOS delay variation displayed on the laptop and mobile phone
25
25
27
27
28
29
29
30
31
32
B.1
B.2
B.3
B.4
Questionnaire
Questionnaire
Questionnaire
Questionnaire
49
49
49
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
5
17
20
20
20
viii
List of Tables
3.1
3.2
11
3.3
3.4
Five-level scale for rating overall quality of video . . . . . . .
Description of video content for the test sequences used in the
subjective test. . . . . . . . . . . . . . . . . . . . . . . . . . .
Video parameters . . . . . . . . . . . . . . . . . . . . . . . . .
Characteristics of encoded videos . . . . . . . . . . . . . . . .
4.1
4.2
4.3
Mean opinion score for packet loss . . . . . . . . . . . . . . .
Mean opinion score for delay variation . . . . . . . . . . . . .
Matched-sample t test results . . . . . . . . . . . . . . . . . .
24
24
33
B.1 Set of videos for the subjective assessment . . . . . . . . . . .
48
ix
12
14
15
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 considered—smaller
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 received—without 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 technology [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 understand 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 recommendations from the International Telecommunications Union (ITU) [25, 5].
The results are calculated and presented using Mean Opinion Score (MOS)
and conventional statistic methods.
The remaining parts of this document are organised as follows. A brief
introduction of the concepts used for this thesis, background and related
work are presented in the Chapter 2. The aims, methodology, design and
implementation of the experiment are addressed in Chapter 3. The results
from the assessment sessions, discussion and validity threats are presented
in Chapter 4. Finally, the conclusions and future work are presented in
Chapter 5.
Chapter 2
Background
This chapter presents the key concepts and related work.
2.1
Key Concepts
This section presents the key concepts that are required to understand the
work discussed in this thesis.
2.1.1
Video coding
Compression is the process of compacting data, in this case specifically raw
video. Compression involves two systems—a compressor (coder) and a decompressor (decoder)—this pair is often called a codec. Video compression
is done by exploiting the redundancies that exist in a video signal. If we
consider that a video is a sequence frames or pictures, then there are two
types of redundancies—temporal (TI) or spatial (SI). Temporal redundancies refer to adjacent frames that are often correlated and it is related to
the number of frames per second (fps). Spatial redundancy refers to the
information of neighbouring pixels, which can be very similar [27] as shown
in Figure 2.1. The codec H.264 uses both of these redundancies to compress
the video.
The Group of Picture (GOP) is a group of successive frames in a encoded
video sequence. There are different types of frames in a GOP—for H.264 the
most common frames are I-frames (intra), P-frames (predicted) and B (bipredictive) [27]. The I-frames are coded independently from the other frames
(reference frame). A GOP always starts with an I-frame; P-frames are coded
predictively from the closest previous reference frame, can be an I or P
frame; B-frames are coded bi-directionally from the preceding or succeeding
reference frame. 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 encoding, 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 communication between streaming servers and clients. Transport protocols for
2.1. KEY CONCEPTS
5
media streaming include the Transport Control Protocol (TCP) and Universal 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 applications. Consequently, UDP is the protocol most widely used for real-time
streaming of video [37, 2].
Video streaming over the Internet using UDP present different distortions 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 Pframes can propagate errors to other P-frames and B-frames. The Figure2.2
shows an example of error propagation and how causes a cascade 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
2.1.3
CHAPTER 2. BACKGROUND
Emulation
Network emulation is a way to simulate the network performance in a controlled and repeatable environment. Traffic shapers are used for the variation 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 objective video quality for the codec H.323. They added disturbances of loss,
delay and jitter to the same video sequence and found that jitter has the
biggest 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 networks. When the videos are used over mobile networks important requirements need to be considered such as frame rates and the screen size [18].
Additionally, studies of video quality perception for mobile devices in
some cases are carried out using a monitor or big LCD display instead of
a mobile phone [3, 32, 36]. Further, in the study from Jumisko et al. [18]
mobile phones were used for the study but the phones were attached to a
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 experiments carried out found that the general rule to be the bigger the image the
better quality perceived [20].
Consequently, a study that tests the user perception of video quality
in 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 experiment design, parameters and tools selected for the experiment. Finally, the
implementation Section 3.4 details the creation of the assessment material,
creation of video sequences with packet loss and delay variation; 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 objective method consists of methods that do not involve human grading. The
videos are evaluated by computers and mathematical algorithms. Different objective methods are described by the Video Quality Experts Group
(VQEG) [34], which was formed to validate and standardise objective methods of video quality. These methods usually employ an error signal ratio that
is a relation between the original video (considered high quality) and the processed signal with distortion or compressed. The most widely used objective
methods are the Mean Squared Error (MSE) and the Peak Signal-to-Noise
Ratio (PSNR) [32, 35]. Objective metrics do not always characterise the
real viewer satisfaction level.
The alternative to objective video quality assessment is subjective video
quality assessment. In subjective quality assessment the description of quality is based on human perception and can be different between subjects [6].
Human perception involves various aspects of human psychology and viewing conditions; such as vision ability, lighting conditions, preference for content, displaying devices, understanding of the rating criteria [35]. 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 simultaneously shown on the same monitor.
Mean Opinion Score (MOS) is a way to assess the quality of video in a
subjective way. It is a metric obtained from a group of subjects that rate
the video sequences according to a scale that represents the quality of the
video in words and then is mapped into numbers as presented in Table 3.1.
Another option considered was the software Perceptual Evaluation Video
Quality (PEVQ) [24]. It is a software approved by the VQEG and ITU that
makes an objective analysis of the video and gives a correlation with the
subjective MOS. Although this method reduces the time necessary to perform the assessment sessions, the variation of parameters is limited, for this
work it was wanted to have control of the display devices. In addition, it was
3.3. DESIGN
11
Table 3.1: Five-level scale for rating overall quality of video
Rating
5
4
3
2
1
MOS
Excellent
Good
Fair
Poor
Bad
Impairment
Imperceptible
Perceptible, but not annoying
Slightly annoying
Annoying
Very annoying
required to acquire the software as it is licensed for a fee. Consequently, this
option was discarded. However, it can be used for future work to compare
the 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 mechanisms that on one hand guarantee the delivery of packets, but introduce
delays that are not acceptable for time critical streaming applications. Consequently, UDP is the protocol most widely used for real-time streaming of
video [37, 2].
12
CHAPTER 3. DESIGN AND IMPLEMENTATION
For this reason the experiment described in this thesis uses UDP as the
transport protocol and IP (Internet Protocol) as the network-layer protocol
to send packets over the network.
The packet size at data link layer in this experiment remains without
change, considering the Maximum Transfer Unit (MTU) of 1500 bytes for
Ethernet.
3.3.2
Video Parameters
This section describes the video parameters that were controlled for this
experiment.
Selection of Video Sequences
Four video sequences were selected for this experiment. Test sequences were
chosen to have 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
Hall-monitor
Foreman
Football
News
Description
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.
Include the face of a man gesticulating. The camera
shakes a little. A the end of the sequence, the camera
suddenly moves and focus to a building in construction.
Scene with high motion of American football.
News media presenters, in the front the two presenters with low movement. In the back, two dancers
performing.
The length of each video sequences is between eight and ten seconds.
This is in the length suggested by the ITU-T [25]. Longer video sequences
3.3. DESIGN
13
will be tedious to the participants and shorter sequences ( 5 seconds) do not
allow enough time for the participants to make correct evaluation.
Resolution
The resolution suggested by the ITU-T [25] for studies of video for mobile devices is Quarter Common Intermediate Format (QCIF) due to the
limitation of the screen size. The ITU-T documentation P.910 was over
10 years ago in 1999, however, and during recent years there have been a
big development in the mobile phones industry. The commercialization of
smart-phones with higher processing capabilities, bigger screens and touchscreens. Previous video studies for mobile have used the QCIF (176 × 144)
resolution [3, 18, 28, 32]; in some cases using mobile devices and some others
displaying the video on a computer monitor displaying the QCIF resolution.
For this study was decided to use higher resolution to cover the new segment
of modern phones. The resolution chosen was VGA (320 × 240), when it was
determined that a wide range of mobile phones brands (eg. Sony Ericsson,
Nokia, iPhone, HTC) now support this resolution.
Frame Rate and Bit Rate
The frame rate refers to the number of frames that is shown per second. The
frame rate used for this experiment is 30 fps as this is a common value [17]
and it is the maximum supported in Android and iPhone devices.
The bit rate refers to the number of bits that the video will process in a
given period of time. The value chosen for the bit rate is 768 kbps. This is
a common value used for mobile devices and creation of podcasts [17] [10].
This bit rate value is also the maximum value allowed by the H.264 baseline
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
Codec
Resolution
Frame-rate
Bit Rate
Container
News, Football, Foreman, Hall-monitor
H.264 Baseline Profile, level 1.3
(320 × 240) (VGA)
30 fps
768kbps
MP4
The above parameters are kept constant for the realization of the experiment, due that changes in these parameters have 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
Foreman
Football
Hall-monitor
3.3.3
Duration
10 sec
8 sec
10 sec
No.Frames
300
260
300
No.I-Frames
2
2
2
No.P-Frames
298
258
298
Size
983 KB
792 KB
929 KB
Network emulator
In emulation, traffic shapers are used to define certain features of a communication 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 modelling 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 user’s 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 150ms±2ms, 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 commands.
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)
X
Server (S)
Receiver (R)
Measurement
Point (MP)
Figure 3.1: Experimental network set-up
The S computer is a laptop Toshiba Satellite A205-SP4027 with an Intel
Core Duo T2450 2.00GHz processor architecture, 1024MB PC2-5300 DDR2
SDRAM, running Ubuntu 10.04 LTS Linux; loaded with VLC media player
version 1.1.3. The computer (R) is a laptop MacBook Pro 15” with an Intel
Core 2 Duo 2.40 GHz processor architecture, 2GB RAM 667 MHz DDR2
SDRAM, running MacOS X 10.5; loaded with VLC media player version
1.1.3. The TS is a computer with an Intel hardware platform running Linux
kernel version: 2.6.23.9, loaded with NetEm. It is important to mention
that after the version 2.6.15 of the Linux kernel, NetEm does re-ordering
of packets if a lot of jitter is emulated, this behaviour can be manipulated
changing the 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 semiautomate the video sequences collection. The procedure followed to create
the video sequences is described in the Appendix A.1.
The procedure was repeated for each of the video sequences (football,
foreman, hall-monitor) and for each experimental value of packet loss and
delay variation. Three samples of each combination were executed to have
a database to select the videos to use in the human perception assessment.
A total of ninety nine videos were collected. The emulated packet loss is
random with NetEm, so having a database of videos we have a pool of videos
to choose with random packets loss and different effects.
NetEm configuration
NetEm [13] was used to set the experimental packet loss values in our experimental network topology, the following commands were used:
1. For the packet loss:
# tc qdisc add dev eth2 root netem loss X %
# tc qdisc change dev eth2 root netem loss X %
where X is the desired packet loss value in %
2. For the delay variation (jitter):
# tc qdisc add dev eth2 root netem delay Y ms Z ms
# tc qdisc change dev eth2 root netem delay Y ms Z ms
where Y is the 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 checking 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 specifications 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 laptop—Toshiba
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 950—and 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 European backgrounds, 15 having Asian backgrounds and seven having other
backgrounds.
Subjects were seated in front of the laptop screen with a viewing distance
set equal to 1–8H, where H is the native height of the picture shown. The
user was able to adjust their distance to the screen within these parameters.
An example of a participant using the laptop is shown in Figure 3.2.
For the mobile phone the user was able to choose the angle and distance
to watch the videos. This imitates what happens in a real-world environment
where the user can move the device as desired to achieve a comfortable
viewing position. An example of a participant using the mobile phone is
shown in Figure 3.3. It was observed that the participants felt comfortable
placing the mobile phone between 20cm and 35cm far from the eyes.
The video sequences shown on the laptop complied with the recommendations made by the ITU-T [25]. The videos were played in VLC using the
original resolution of the video sequence (320 × 240), in the center of the
screen, with the background was set to 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 consisted of three phases: training session, questions and main session. During
the introduction, the assessment methodology was explained, general information of the subject was collected (age, background, experience with video
in computer and phone, use of corrective glasses or lenses);the grading scale
1
HTML Color #808080
20
CHAPTER 3. DESIGN AND IMPLEMENTATION
Figure 3.2: Laptop based assessment
Figure 3.3: Mobile Phone assessment
Figure 3.4: Screen shot of interview set-up for laptop
3.4. IMPLEMENTATION
21
was introduced as shown in Table 3.1; three stabilizing videos, dummy videos
sequences, News with three different distortions were presented to stabilize
participant’s opinion as suggested by the ITU-T [25]. The results for these
three videos are not considered for the data evaluation and that was told to
the observers. Then, during the questions session any concerns by the participants were answered. The main session consisted of thirty three videos
sequences that were presented in the laptop and in the Mobile Phone, the
videos were shown indistinctly in some cases before in the laptop and in
some cases before in the Mobile Phone. For the evaluation we used the Single Stimulus method in which the video sequence is showed alone, without
being compared to the reference version. Each sequence was displayed for
ten or eight seconds and then the participant had 2-5 seconds voting time,
the vote was collected and stored in a web-page form. A sample of the
questionnaire is available in the Appendix B.2.
22
CHAPTER 3. DESIGN AND IMPLEMENTATION
Chapter 4
Results and Discussion
This section presents the collected data from the assessment sessions. Conventional statistics, like mean and variance, were applied to the raw data
and graphs were plotted to compare the results.
During the assessment sessions, thirty four volunteers graded the 33
videos sequences using the scale Excellent (5), Good (4), Fair (3), Poor (2)
and Bad (1). Each video was shown on both a laptop and on a mobile
phone. In total 66 video sequences were shown to the volunteers.
The reliability of the volunteers was evaluated by checking their behaviour when the original videos encoded with H.264 were shown. In these
cases, subjects were expected to give evaluations higher than three. This
helps ensures that they at least understood the instructions and they were
not grading randomly.
Mean and standard deviation were calculated for each of the video sequences (Foreman, Hall-monitor, Football) and for both of the devices—
laptop and mobile phone.
The mean is defined as:
uj k =
N
1 X
uij k
N i=1
(4.1)
The standard deviation is defined as:
v
uN
uX (uj k − uij k )2
sj k = t
N −1
i=1
(4.2)
where : N is the number of observers, uij k is the score of observer i for
test condition j, video sequence k.
The MOS of the collected data is shown in the Table 4.1 and Table 4.2.
The following abbreviations are used: FM (Foreman), HM (Hall-Monitor),
FT (Football). The L denotes that the video sequence was displayed in the
laptop and P denotes that was displayed in the mobile phone.
23
24
CHAPTER 4. RESULTS AND DISCUSSION
Table 4.1: Mean opinion score for packet loss
Loss
0.0%
0.4%
0.8%
3.0%
5.0%
7.0%
FM L
4.44
3.26
2.62
1.85
1.47
1.15
FM P
4.50
3.44
2.56
2.15
1.50
1.15
HM L
4.38
3.56
2.65
1.88
1.76
1.79
HM P
4.29
3.29
2.47
1.94
1.79
1.71
FT L
4.24
3.21
2.26
1.76
1.41
1.41
FT P
4.18
2.82
2.47
1.74
1.29
1.47
Table 4.2: Mean opinion score for delay variation
Delay
150ms ± 2ms
150ms ± 4ms
150ms ± 8ms
150ms ± 12ms
150ms ± 16ms
4.1
FM L
2.00
1.79
1.18
1.09
1.03
FM P
2.18
1.85
1.15
1.06
1.03
HM L
1.88
1.68
1.44
1.12
1.06
HM F
1.88
1.79
1.47
1.12
1.06
FT L
3.03
2.56
1.88
1.18
1.18
FT P
2.71
2.68
1.59
1.29
1.12
Packet loss
Figures 4.1 and 4.2 show the graphs of the MOS for the packet loss for the
laptop and the mobile phone respectively. The graphs show the tendency
that the smaller the values of loss the higher MOS, thus, better user perception of the video. As packet loss increases the MOS drops steeply, but
it remains “fair” until values of packet loss between 0.4% and 0.8%. From
5% packet loss the value of the MOS is close to 1 (bad). This indicates
that at and above this value the user perception quality makes them reject
the video. This behaviour suggest that packet loss is an important factor
to consider as for small values as the perception becomes annoying for the
user. If this video is provided as a service will lead the user to stop watching
the video.
The video sequence encoded with H.264 and without distortions was
graded with a MOS that lies between 4.50 and 4.18. This shows that the
viewers in some cases are reluctant to score the videos as “excellent.” This
behaviour was also found in other studies [26].
For the 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
MOS
3.50
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
MOS
3.50
3.00
2.50
2.00
1.50
1.00
0
1
2
3
4
5
6
Packet Loss [%]
Figure 4.2: MOS for packet loss displayed on the mobile phone
7
26
CHAPTER 4. RESULTS AND DISCUSSION
at 7%.
As recommended by the International Telecommunications Union- Radiocommunications Sector (ITU-R) in the recommendation BT-500 [5] for
subjective assessment of the quality of television pictures, together with the
mean scores calculated previously the 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)
sj k
δj k = 1.96 √
N
(4.4)
where:
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, HMhall-monitor, FT- football), the device that was used to present the video
sequence to the observer (L- laptop, P- mobile phone) and the percentage
of packet loss emulated. The y-axis refers to the MOS. We can appreciate
that there is not a big 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,$
)*$-$#"0,$
.*$+$#"0,$
.*$-$#"0,$
)/$+$#"0,$
)/$-$#"0,$
)*$+$&"#,$
)*$-$&"#,$
.*$+$&"#,$
.*$-$&"#,$
)/$+$&"#,$
)/$-$&"#,$
)*$+$("#,$
)*$-$("#,$
.*$+$("#,$
.*$-$("#,$
)/$+$("#,$
)/$-$("#,$
)*$+$1"#,$
)*$-$1"#,$
.*$+$1"#,$
.*$-$1"#,$
)/$+$1"#,$
)/$-$1"#,$
!"#$
4.1. PACKET LOSS
0
27
("##$
'"##$
&"##$
%"##$
!"##$
%&'()$#(*+(,-(./(0&-(.1)22$
Figure 4.3: Confidence interval (95%) for packet loss
1.00
FM L
0.4
FM P
HM L
HM P
0.8
3.0
FT L
FT P
0.90
0.80
0.70
0.60
0.50
0.40
0.30
0.20
0.10
0.00
Packet Loss [%]
5.0
Figure 4.4: Standard deviation for packet loss
7.0
28
CHAPTER 4. RESULTS AND DISCUSSION
4.2
Delay variation
The delay variation results were plotted in Figures 4.5 and 4.6. It is appreciated that for small increased values of delay variation the MOS decreases
dramatically. For a variation of only ±2ms the MOS for the foreman and
hall-monitor videos decays to a value close to poor. The video sequence
football is less 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
MOS
3.50
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, FTfootball), the device that was used to present the video sequence to the
observer (L- laptop, P- mobile phone) and the percentage of packet loss
emulated. The y-axis refers to the MOS. It is appreciated that the football
video sequence gets higher rates between ±2ms and ±8ms, the higher rates
become less obvious for the values of ±12ms and ±16ms.
The standard deviation was plotted in Figure 4.8). The values range
from 0.17 to 0.95 low values for this indicates minor divergence between the
subject assessments. The standard deviation is low at small values of the
delay variation, these results can be interpreted that at these values the users
perception about the video quality varies less, users agree in a higher extent
that the quality is bad. We can see in the graph slightly bigger values of the
standard deviation for the football video sequence this could be attributed
that the video sequence football got slightly better results than the other
4.2. DELAY VARIATION
29
Foreman
Hall-monitor
Football
5.00
4.50
4.00
MOS
3.50
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
Standard Deviation
0.80
0.70
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. Although we are using another codec in this experiment, we found that in the
case of packet loss the video sequence with the slightly lower MOS is the
football video, which is inline with their results.
Contrary to the 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
MOS
3.50
3.00
2.50
2.00
1.50
Laptop
1.00
0
0.4
0.8
3.0
Packet Loss [%]
5.0
7.0
Mobile
Phone
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
where:
(4.5)
32
CHAPTER 4. RESULTS AND DISCUSSION
Mobile Phone
Laptop
5.00
4.50
4.00
MOS
3.50
3.00
2.50
2.00
1.50
Laptop
1.00
2
4
8
12
Delay Variation [ms]
16
Mobile
Phone
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:
tcalc =
D − uD
sD
√
N
(4.6)
where D and sD are the mean and standard deviation of the difference 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
Table 4.3: Matched-sample t test results
Video sequence
FM 0.0% loss
FM 0.4% loss
FM 0.8% loss
FM 3.0% loss
FM 5.0% loss
FM 7.0% loss
FM ±2ms DV
FM ±4ms DV
FM ±8ms DV
FM ±12ms DV
FM ±16ms DV
HM 0.0% loss
HM 0.4% loss
HM 0.8% loss
HM 3.0% loss
HM 5.0% loss
HM 7.0% loss
HM ±2ms DV
HM ±4ms DV
HM ±8ms DV
HM ±12ms DV
HM ±16ms DV
FT 0.0% loss
FT 0.4% loss
FT 0.8% loss
FT 3.0% loss
FT 5.0% loss
FT 7.0% loss
FT ±2ms DV
FT ±4ms DV
FT ±8ms DV
FT ±12ms DV
FT ±16ms DV
tcalc
−0.63
−1.14
0.42
−2.05
−0.25
0.00
−1.36
0.70
0.44
0.44
0.00
0.90
2.50
1.36
−0.44
−0.27
0.83
0.00
−1.28
−0.37
0.00
0.00
0.42
3.20
−2.03
0.25
1.16
−0.63
2.46
−0.89
2.73
−1.68
0.81
Result
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
Reject the hypothesis.
Fail to reject the hypothesis.
Reject the hypothesis.
Fail to reject the hypothesis.
Fail to reject the hypothesis.
33
34
CHAPTER 4. RESULTS AND DISCUSSION
tween doing the experiment in the mobile phone and in the laptop displaying
the same resolution. Overall, the same results were obtained for both devices.
4.4
Validity Threats
Perceptions of video quality change over time with users having higher expectations of quality as time moves forward. This type of assessments needs
to be updated constantly as results from time to time can vary. As an example, some years ago was not common to have mobile phones with video
capabilities. Improvements in the codecs, network equipment and mechanism to minimise these distortions have been added.
As explained in the results section, for this experiment NetEm drops the
packets randomly, so the results are likely to have some variations. It was
not controlled which type of packets were dropped—I-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 devices—a 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 understand 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 engineers to put in place mechanisms to avoid packet loss and delay variation.
Network engineers could also consider, improvements in networking equipment that would be able to identify 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/, accessed on July 2010.
[2] John G. Apostolopoulos, Wai tian Tan, and Susie J. Wee. Video streaming: Concepts, algorithms, and systems. Technical report, HP Laboratories, 2002.
[3] Hussein Muzahim Aziz, Håkan Grahn, and Lars Lundberg. Eliminating
the freezing frames for the mobile user over unreliable wireless networks.
In Proceedings of the 6th International Conference on Mobile Technology, Application &#38; Systems, Mobility ’09, pages 57:1–57: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 Measurement, volume 3015 of Lecture Notes in Computer Science, pages
137–146. Springer Berlin / Heidelberg, 2004.
[7] L.U. Choi, M.T. Ivrlac, E. Steinbach, and J.A. Nossek. Analysis of
distortion due to packet loss in streaming video transmission over wireless communication links. In Image Processing, 2005. ICIP 2005. IEEE
International Conference on, volume 1, pages I – 189–92, 2005.
[8] Mark Claypool and Jonathan Tanner. The effects of jitter on the peceptual quality of video. In Multimedia ’99: Proceedings of the seventh
ACM international conference on Multimedia (Part 2), pages 115–118,
1999. ACM.
37
38
BIBLIOGRAPHY
[9] F. De Simone, M. Tagliasacchi, M. Naccari, S. Tubaro, and T.
Ebrahimi. A H.264/AVC video database for the evaluation of quality
metrics. In 2010 IEEE International Conference on Acoustics Speech
and Signal Processing (ICASSP), pages 2430 –2433, 2010.
[10] Android developers. Android supported media formats. [Online]
http://developer.android.com/guide/appendix/media-formats.html,
accessed on August 2010.
[11] Endace.
Endace
measurement
systems.
http://www.endace.com/, accessed September 2010.
[Online]
[12] FFMPEG. [Online] http://www.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, volume 1718 of Lecture Notes in Computer Science, pages 45–57. 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 International Symposium on Communications, Control and Signal Processing
(ISCCSP), 2010, pages 1–5, 2010.
[17] Apple Inc.
iPhone 4 technical specifications.
[Online]
http://www.apple.com/iphone/specs.html
and
http://www.apple.com/itunes/podcasts/specs.html,
accessed
on
August 2010.
[18] Satu Jumisko-Pyykkö and Jukka Häkkinen. 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 829–838, 2005.
BIBLIOGRAPHY
39
[21] P. D. Leedy and J. E. Ormrod. Practical Research: Planning and Design. Prentice Hall, 2005.
[22] Ting-Lan Lin, S. Kanumuri, Yuan Zhi, D. Poole, P.C. Cosman, and
A.R. Reibman. A versatile model for packet loss visibility and its application to packet prioritization. Image Processing, IEEE Transactions
on, 19(3):722 –735, 2010.
[23] Dmitri Loguinov and Hayder Radha. Measurement study of low-bitrate
internet video streaming. In Proceedings of the 1st ACM SIGCOMM
Workshop on Internet Measurement, IMW ’01, pages 281–293, 2001.
ACM.
[24] OPTICOM.
Perceptual evaluation of video quality.
http://www.pevq.org/, accessed July 2010.
[Online]
[25] ITU-T P.910. Subjective video quality assessment methods for multimedia applications. International Telecommunications Union Telecommunication Sector, 1999.
[26] M.H. Pinson, S. Wolf, and G. Cermak. HDTV subjective quality of
H.264 vs. MPEG-2, with and without packet loss. Broadcasting, IEEE
Transactions on, 56(1):86 –91, mar. 2010.
[27] Iain E. Richardson. H.264 and MPEG-4 Video Compression: Video
Coding for Next Generation Multimedia. Wiley, 1st Edition, August
2003.
[28] M. Ries, O. Nemethova, and M. Rupp. Video quality estimation for mobile H. 264/AVC video streaming. Journal of Communications, 3(1):41–
50, 2008.
[29] J. Shaikh, T.N. Minhas, P. Arlos, and M. Fiedler. Evaluation of delay
performance of traffic shapers. pages 1 –8, may. 2010.
[30] S. Spirou. Packet reordering effects on the subjective quality of broadband digital television. pages 1 –6, 2006.
[31] Thomas Stockhammer, Miska M. Hannuksela, and Thomas Wiegand.
H.264/AVC in wireless environments. IEEE Transactions on Circuits
and Systems for Video Technology, 13:657–663, 2003.
[32] Vasos Vassiliou, Pavlos Antoniou, Iraklis Giannakou, and Andreas Pitsillides. Requirements for the transmission of streaming video in mobile
wireless networks. In Stefanos Kollias, Andreas Stafylopatis, Wlodzislaw Duch, and Erkki Oja, editors, Artificial Neural Networks ICANN
2006, volume 4132 of Lecture Notes in Computer Science, pages 528–
537. Springer Berlin / Heidelberg, 2006.
40
[33] VideoLAN.
2010.
BIBLIOGRAPHY
[Online] http://www.videolan.org/vlc/, accessed June
[34] VQEG.
Video
quality
experts
group.
http://www.its.bldrdoc.gov/vqeg/, accessed July 2010.
[Online]
[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 1041–1078. CRC Press, 2003.
[36] S. Winkler and F. Dufaux. Video quality evaluation for mobile applications. In Proc. of SPIE Conference on Visual Communications and
Image Processing, volume 5150, pages 593–603. Citeseer, 2003.
[37] Dapeng Wu, Y.T. Hou, Wenwu Zhu, Ya-Qin Zhang, and J.M. Peha.
Streaming video over the internet: approaches and directions. Circuits
and Systems for Video Technology, IEEE Transactions on, 11(3):282
–300, mar. 2001.
Appendix A
Video Encoding Information
This appendix presents information related to the encoding of the video sequences.
A.1
Procedure for video sequences creation
Description of the procedure followed to create the video sequences.
• Initialise VLC client in the R laptop to be able to receive and save the
UDP stream.
vlc -vvv udp://@:1234 --sout file/mp4: /home/oziel/Desktop
/ThesisVideos/Received_Video.mp4
• 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
A.2
APPENDIX A. VIDEO ENCODING INFORMATION
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
A.3
43
Command line FFMPEG
This is the command that was used to encode the raw video with the codec
H.264.
ffmpeg -i /home/oziel/Videos/football_cif.y4m -s 320x240 -r 30
-vcodec libx264 -vpre slow -vpre ipod320 -b 768k
-threads 0 -f ipod /home/oziel/Videos/football\mobile.mp4
A.4
Output information FFMPEG encoding videos
from Raw to H.264
This is the information that FFMPEG gives as feedback after encoding the videos
with the codec H.264.
• Foreman video sequence.
oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/foreman_cif.y4m
-vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0
-f ipod /home/oziel/Pictures/foreman_mobile.mp4
-s 320x240 -r 30
FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers
built on Nov 8 2010 09:30:14 with gcc 4.4.3
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc
--enable-libfaac --enable-libopencore-amrnb
--enable-libopencore-amrwb
--enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid
--enable-x11grab --enable-libvpx
libavutil
50.32. 6 / 50.32. 6
libavcore
0.12. 0 / 0.12. 0
libavcodec
52.94. 3 / 52.94. 3
libavformat
52.84. 0 / 52.84. 0
libavdevice
52. 2. 2 / 52. 2. 2
libavfilter
1.58. 0 / 1.58. 0
libswscale
0.12. 0 / 0.12. 0
libpostproc
51. 2. 0 / 51. 2. 0
[yuv4mpegpipe @ 0x8e8c560] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from ’/home/oziel/Pictures/foreman_cif.y4m’:
Duration: N/A, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
[buffer @ 0x8e95400] w:352 h:288 pixfmt:yuv420p
[scale @ 0x8ef5e80] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004
[libx264 @ 0x8e8d860] using SAR=255/254
[libx264 @ 0x8e8d860] VBV buffer (3000) > level limit (2000)
[libx264 @ 0x8e8d860] using cpu capabilities: MMX2 Cache64
[libx264 @ 0x8e8d860] profile Constrained Baseline, level 1.3
[libx264 @ 0x8e8d860] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec Copyleft 2003-2010 - http://www.videolan.org/x264.html
- options: cabac=0 ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00
mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1
chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0 constrained_intra=0 bframes=0
weightp=0 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1
bitrate=768 ratetol=5.2 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000
ip_ratio=1.41 aq=1:1.00 nal_hrd=none
[ipod @ 0x8e900a0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file
Output #0, ipod, to ’/home/oziel/Pictures/foreman_mobile.mp4’:
Metadata:
encoder
: Lavf52.84.0
Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 300 fps= 32 q=-1.0 Lsize=
983kB time=9.93 bitrate= 810.9kbits/s
video:980kB audio:0kB global headers:0kB muxing overhead 0.321519%
frame I:2
Avg QP:21.82 size: 18688
[libx264 @ 0x8e8d860] frame P:298
Avg QP:22.24 size: 3240
[libx264 @ 0x8e8d860] mb I I16..4: 8.2% 0.0% 91.8%
[libx264 @ 0x8e8d860] mb P I16..4: 0.1% 0.0% 1.4% P16..4: 47.8% 28.9% 14.7% 0.0% 0.0%
skip: 7.1%
[libx264 @ 0x8e8d860] coded y,uvDC,uvAC intra: 91.1% 92.7% 67.4% inter: 43.9% 47.0% 9.0%
[libx264 @ 0x8e8d860] i16 v,h,dc,p: 31% 12% 7% 50%
[libx264 @ 0x8e8d860] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 9% 11% 3% 9% 20% 14% 17% 8% 10%
44
APPENDIX A. VIDEO ENCODING INFORMATION
[libx264 @ 0x8e8d860] i8c dc,h,v,p: 43% 20% 25% 12%
[libx264 @ 0x8e8d860] ref P L0: 69.4% 13.5% 8.9% 4.5%
[libx264 @ 0x8e8d860] kb/s:802.38
3.7%
• Hall-monitor video sequence.
oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/hall_monitor_cif.y4m -s 320x240 -r 30
-vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Pictures/hall_monitor_mobile.mp4
FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers
built on Nov 8 2010 09:30:14 with gcc 4.4.3
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc
--enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb
--enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid
--enable-x11grab --enable-libvpx
libavutil
50.32. 6 / 50.32. 6
libavcore
0.12. 0 / 0.12. 0
libavcodec
52.94. 3 / 52.94. 3
libavformat
52.84. 0 / 52.84. 0
libavdevice
52. 2. 2 / 52. 2. 2
libavfilter
1.58. 0 / 1.58. 0
libswscale
0.12. 0 / 0.12. 0
libpostproc
51. 2. 0 / 51. 2. 0
[yuv4mpegpipe @ 0xa13c560] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from ’/home/oziel/Pictures/hall_monitor_cif.y4m’:
Duration: N/A, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 29.97 fps, 29.97 tbr, 29.97 tbn, 29.97 tbc
[buffer @ 0xa1454e0] w:352 h:288 pixfmt:yuv420p
[scale @ 0xa1a5e50] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004
[libx264 @ 0xa13d830] using SAR=255/254
[libx264 @ 0xa13d830] VBV buffer (3000) > level limit (2000)
[libx264 @ 0xa13d830] using cpu capabilities: MMX2 Cache64
[libx264 @ 0xa13d830] profile Constrained Baseline, level 1.3
[libx264 @ 0xa13d830] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec
- Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=0 ref=5
deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00 mixed_ref=1
me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=1
chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1 interlaced=0
constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=40
intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=768 ratetol=5.2 qcomp=0.60
qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000 ip_ratio=1.41
aq=1:1.00 nal_hrd=none
[ipod @ 0xa1400d0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file
Output #0, ipod, to ’/home/oziel/Pictures/hall_monitor_mobile.mp4’:
Metadata:
encoder
: Lavf52.84.0
Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 300 fps= 32 q=-1.0 Lsize=
930kB time=9.93 bitrate= 766.9kbits/s
its/s
video:927kB audio:0kB global headers:0kB muxing overhead 0.340038%
frame I:2
Avg QP:21.91 size: 13137
[libx264 @ 0xa13d830] frame P:298
Avg QP:22.60 size: 3094
[libx264 @ 0xa13d830] mb I I16..4: 17.8% 0.0% 82.2%
[libx264 @ 0xa13d830] mb P I16..4: 0.1% 0.0% 0.2% P16..4: 60.6% 24.0% 13.1% 0.0% 0.0%
skip: 2.0%
[libx264 @ 0xa13d830] coded y,uvDC,uvAC intra: 91.7% 99.5% 89.9% inter: 30.3% 94.5% 39.2%
[libx264 @ 0xa13d830] i16 v,h,dc,p: 20% 7% 1% 72%
[libx264 @ 0xa13d830] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 21% 13% 2% 11% 13% 11% 12% 8% 9%
[libx264 @ 0xa13d830] i8c dc,h,v,p: 43% 25% 24% 8%
[libx264 @ 0xa13d830] ref P L0: 39.7% 19.4% 18.5% 11.3% 11.2%
[libx264 @ 0xa13d830] kb/s:758.65
• Football video sequence.
oziel@oziel-laptop2:~$ ffmpeg -i /home/oziel/Pictures/football_cif.y4m -s 320x240 -r 30
-vcodec libx264 -vpre slow -vpre ipod320 -b 768k -threads 0 -f ipod /home/oziel/Pictures/football_mobile.mp4
FFmpeg version SVN-r25706, Copyright (c) 2000-2010 the FFmpeg developers
built on Nov 8 2010 09:30:14 with gcc 4.4.3
configuration: --enable-gpl --enable-version3 --enable-nonfree --enable-postproc
--enable-libfaac --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora
--enable-libvorbis --enable-libx264 --enable-libxvid --enable-x11grab --enable-libvpx
libavutil
50.32. 6 / 50.32. 6
libavcore
0.12. 0 / 0.12. 0
libavcodec
52.94. 3 / 52.94. 3
libavformat
52.84. 0 / 52.84. 0
libavdevice
52. 2. 2 / 52. 2. 2
libavfilter
1.58. 0 / 1.58. 0
libswscale
0.12. 0 / 0.12. 0
A.4. OUTPUT INFORMATION FFMPEG ENCODING VIDEOS FROM RAW TO H.26445
libpostproc
51. 2. 0 / 51. 2. 0
[yuv4mpegpipe @ 0x9f00560] Estimating duration from bitrate, this may be inaccurate
Input #0, yuv4mpegpipe, from ’/home/oziel/Pictures/football_cif.y4m’:
Duration: N/A, bitrate: N/A
Stream #0.0: Video: rawvideo, yuv420p, 352x288, PAR 128:117 DAR 1408:1053, 30 fps, 30 tbr, 30 tbn, 30 tbc
[buffer @ 0x9f09410] w:352 h:288 pixfmt:yuv420p
[scale @ 0x9f69f00] w:352 h:288 fmt:yuv420p -> w:320 h:240 fmt:yuv420p flags:0xa0000004
[libx264 @ 0x9f01860] using SAR=255/254
[libx264 @ 0x9f01860] VBV buffer (3000) > level limit (2000)
[libx264 @ 0x9f01860] using cpu capabilities: MMX2 Cache64
[libx264 @ 0x9f01860] profile Constrained Baseline, level 1.3
[libx264 @ 0x9f01860] 264 - core 107 r1745 4785e8e - H.264/MPEG-4 AVC codec
- Copyleft 2003-2010 - http://www.videolan.org/x264.html - options: cabac=0
ref=5 deblock=1:0:0 analyse=0x1:0x111 me=umh subme=8 psy=1 psy_rd=1.00:0.00
mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=0 cqm=0 deadzone=21,11
fast_pskip=1 chroma_qp_offset=-2 threads=3 sliced_threads=0 nr=0 decimate=1
interlaced=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25
scenecut=40 intra_refresh=0 rc_lookahead=50 rc=cbr mbtree=1 bitrate=768
ratetol=5.2 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 vbv_maxrate=768 vbv_bufsize=3000
ip_ratio=1.41 aq=1:1.00 nal_hrd=none
[ipod @ 0x9f040a0] Warning, extension is not .m4a nor .m4v Quicktime/Ipod might not play the file
Output #0, ipod, to ’/home/oziel/Pictures/football_mobile.mp4’:
Metadata:
encoder
: Lavf52.84.0
Stream #0.0: Video: libx264, yuv420p, 320x240 [PAR 255:254 DAR 170:127], q=10-51, 768 kb/s, 30 tbn, 30 tbc
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
frame= 260 fps= 28 q=-1.0 Lsize=
793kB time=8.60 bitrate= 755.0kbits/s
video:790kB audio:0kB global headers:0kB muxing overhead 0.359481%
frame I:2
Avg QP:26.58 size: 8598
[libx264 @ 0x9f01860] frame P:258
Avg QP:31.01 size: 3065
[libx264 @ 0x9f01860] mb I I16..4: 16.3% 0.0% 83.7%
[libx264 @ 0x9f01860] mb P I16..4: 0.4% 0.0% 7.3% P16..4: 38.1% 26.3% 12.6% 0.0% 0.0%
skip:15.3%
[libx264 @ 0x9f01860] coded y,uvDC,uvAC intra: 90.5% 85.9% 52.6% inter: 39.2% 35.0% 3.6%
[libx264 @ 0x9f01860] i16 v,h,dc,p: 18% 66% 2% 14%
[libx264 @ 0x9f01860] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 7% 14% 4% 10% 15% 13% 16% 8% 12%
[libx264 @ 0x9f01860] i8c dc,h,v,p: 51% 20% 20% 10%
[libx264 @ 0x9f01860] ref P L0: 85.7% 6.2% 4.2% 1.9% 2.0%
[libx264 @ 0x9f01860] kb/s:745.82
46
APPENDIX A. VIDEO ENCODING INFORMATION
Appendix B
Assessment material
B.1
Set of videos for the subjective assessment
Table B.1 shows in the first column the video disturbance applied, the second column 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
APPENDIX B. ASSESSMENT MATERIAL
48
delay150v2 2.mp4
loss3 3.mp4
lossP4 1.mp4
delay150v8 3.mp4
original 1.mp4
loss7 2.mp4
delay150v4 1.mp4
lossP8 1.mp4
delay150v16 3.mp4
loss5 2.mp4
delay150v12 3.mp4
Original File Received
hallmonitor loss5 1.mp4
hallmonitor delay150v2 3.mp4
hallmonitor lossP8 2.mp4
hallmonitor delay150v16 1.mp4
hallmonitor loss3 1.mp4
hallmonitor delay150v12 2.mp4
hallmonitor delay150v4 3.mp4
hallmonitor lossP4 1.mp4
hallmonitor delay150v8 3.mp4
hallmonitor original 3.mp4
hallmonitor loss7 1.mp4
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Foreman
Football
Football
Football
Football
Football
Football
Football
Football
Football
Football
Football
A.mp4
B.mp4
C.mp4
D.mp4
E.mp4
F.mp4
G.mp4
H.mp4
I.mp4
J.mp4
K.mp4
A.mp4
B.mp4
C.mp4
D.mp4
E.mp4
F.mp4
G.mp4
H.mp4
I.mp4
J.mp4
K.mp4
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
ForemanM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
FootballM
K.mp4
J.mp4
I.mp4
H.mp4
G.mp4
F.mp4
E.mp4
D.mp4
C.mp4
B.mp4
A.mp4
K.mp4
B.mp4
C.mp4
D.mp4
E.mp4
F.mp4
G.mp4
H.mp4
I.mp4
J.mp4
A.mp4
Table B.1: Set of videos for the subjective assessment
Disturbance
Loss 5%
Delay 150ms ± 2ms
Loss 0.8%
Delay 150ms ± 16ms
Loss 3%
Delay 150ms ± 12ms
Delay 150ms ± 4ms
Loss 0.4%
Delay 150ms ± 8ms
H.264 Original
Loss 7%
football
football
football
football
football
football
football
football
football
football
football
delay150v12 3.mp4
loss5 3.mp4
lossP4 1.mp4
delay150v2 3.mp4
loss3 2.mp4
original 2
delay150v16 2.mp4
delay150v4 3.mp4
lossP8 1.mp4
loss7 1.mp4
delay150v8 2.mp4
Renamed for Mobile Phone
HallMon K.mp4
HallMon J.mp4
HallMon I.mp4
HallMon H.mp4
HallMon G.mp4
HallMon F.mp4
HallMon E.mp4
HallMon D.mp4
HallMon C.mp4
HallMon B.mp4
HallMon A.mp4
Delay 150ms ± 2ms
Loss 3%
Loss 0.4%
Delay 150ms ± 8ms
H.264 Original
Loss 7%
Delay 150ms ± 4ms
Loss 0.8%
Delay 150ms ± 16ms
Loss 5%
Delay 150ms ± 12ms
foreman
foreman
foreman
foreman
foreman
foreman
foreman
foreman
foreman
foreman
foreman
Renamed for Laptop
Hallmonitor A.mp4
Hallmonitor B.mp4
Hallmonitor C.mp4
Hallmonitor D.mp4
Hallmonitor E.mp4
Hallmonitor F.mp4
Hallmonitor G.mp4
Hallmonitor H.mp4
Hallmonitor I.mp4
Hallmonitor J.mp4
Hallmonitor K.mp4
Delay 150ms ± 12ms
Loss 5%
Loss 0.4%
Delay 150ms ± 2ms
Loss 3%
H.264 Original
Delay 150ms ± 16ms
Delay 150ms ± 4ms
Loss 0.8%
Loss 7%
Delay 150ms ± 8ms
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
Blekinge Institute of Technology
SE - 371 79 Karlskrona
Sweden
Internet
Phone
Fax
ii
: www.bth.se /com
: +46 455 38 50 00
: +46 455 38 50 57
ABSTRACT
This thesis proposes a new solution approach for
the simultaneous mobility issues in seamless handover
for next generation wireless networks and envisages the
vision of seamless roaming in IP mobility. We
investigate the key issues of simultaneous mobility:
handover management and the location management. A
new scheme is designed to minimize handover latency
between two homogeneous networks with location
management support while handover occurs. One of the
most emerging techniques in recent research projects
for mobility management is mobile Stream
Transmission Control Protocol (mSCTP). The multihoming feature of Stream Control Transmission
Protocol (SCTP) and dynamic address reconfiguration
(DAR) extension of SCTP are applied in the proposed
solution to achieve improved seamless performance. In
this project, we examined the comprehensive and
thoughtful study of the phenomena ‘Simultaneous
Mobility’ along with ‘Simultaneous Handover’ for
mSCTP. We used an additional Location Server (LS) to
ensure location management between simultaneous
moving mobile nodes (MNs) while crossing a threshold
for a smooth simultaneous handover. The most
important part of this thesis is dedicated to design a new
model of simultaneous mobility based on ‘step_length’
and the implementation of the model i.e., mSCTP with
LS to solve the simultaneous mobility issues. The
proposed scheme implemented on NS2 simulations and
performance evaluations are scrutinized to demonstrate
the comparison of proposed simultaneous handover
latency with LS and without LS. The results show that
our proposed approach has improved performance in
reducing handover delay as well as handling
simultaneous mobility issues in seamless handover.
Keywords
mSCTP, Simultaneous Mobility, Location Management,
Handover Latency, Location Server (LS), step_length,
NS-2.
iii
ACKNOWLEDGEMENTS
We are most grateful to Almighty Allah for his loyal help, which gave us much more
strength for all kind of achievements at the time of our project work and enabled us to
complete the work successfully. We are thankful to our supervisors to give us appropriate
suggestion during our whole project and for exposing us to the beauty of learning.
We are also thankful to all of our friends who inspired us all the time to carry on this thesis.
They provided us their invaluable support and assistance during our whole study period.
………..Mohammad Iqbal & Md. Ibrahim Chowdhury
I am thankful to Allah, the almighty to whom I offer all my worships and sacrifices, who
know the best of knowledge and from whom I expect the best rewards in heaven. I extend
my gratitude to several people. My parents: Abdul Hamid Chowdhury, and Rahima Akhter
Begum, who are my basis of existence in this world. My lifetime mentor and maternal uncle,
Professor Dr. Muhammad Loqman, one of the prominent founders of International Islamic
University Chittagong (IIUC), Bangladesh. My advisors in this thesis, Yong Yao and Kaibo
Zhou who lead towards the right research track and planted the research interests in my heart.
My hearty appreciation goes to all my teachers and friends all over the world. I am grateful
to the examiner Dr. Patrik Arlos and my program manager Mikael Åsman. I also share my
contributions to all the fascinating instructors and inspiring surroundings of BTH.
…………..Md. Ibrahim Chowdhury
First of all, I thank Allah for giving me strength and ability to complete this work. I am
grateful to my family; who are, always with me in every step of my life. Specially, my
brother-in-law, Balaet Hossain, working in Nokia Corporation, always gave me support for
everything from my bachelor study to now. My mother’s 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 world’s 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
Research Design……………………………………………..
1.1.1 Research Methodology …………………………..
1.1.2 Main Problems……………………………………
1.1.3 Research Questions……………………………….
1.1.4 Aims and Objectives …………………………….
1.1.5 Motivation ……………………………………….
1.1.6 Contribution ……………………………………...
Thesis Outline……………………………………………….
2
2
4
5
5
5
6
6
1.1
1.2
Chapter 2. Background……..…………………………………………….....
2.1
2.2
2.3
2.4
2.5
Simultaneous Mobility and Handover………………………
Stream Control Transmission Protocol (SCTP)……………..
2.2.1 SCTP association…………………………………...
2.2.2 Multi-homing…………………………………........
2.2.3 Multi-streaming…………………………….............
SCTP Packet Structure………………………………………
Mobile SCTP (mSCTP)………………………………..........
Related works……………………………………………......
2.5.1 Simultaneous mobility solution by mSCTP with
RSerPool……………………………………………
2.5.2 Simultaneous mobility under asymmetric mobility
conditions…………………………..........................
2.5.3 Managing Simultaneous Mobility of IP hosts……..
Chapter 3. Simulation Tool & Methodology………………………...............
3.1
3.2
3.3
Network Simulator 2 (NS2)……...………………………….
Simulation with NS2………………………………………...
3.2.1 Structure of Wired and Mobile nodes ……………..
3.2.2 Wireless Simulation by NS2……………………….
3.2.3 Trace File………………………………...................
Simulation Methodologies.………………………………….
v
7
7
7
7
8
8
8
9
9
9
10
10
11
11
12
12
12
12
13
Chapter 4. Proposed Model for Simultaneous Mobility with Location
Management………………………………………………………
4.1 NS2 based architectural model for Simultaneous Mobility
with mSCTP………………………………………………...
4.2 Location management with Location Server (LS)…………..
4.2.1 LS setup and management process……………….
4.3 Solution of Simultaneous Mobility issues…………………...
4.3.1 Mobile nodes location detection and configuration
4.3.2 LS enabled Simultaneous Mobility management
and Simultaneous Handover……………………...
4.3.2.1 Association setup……...........................
4.3.2.2 Dynamic Address Reconfiguration
(DAR)…………………………………
4.3.2.3 Simultaneous Mobility process and
Handover………………………………
4.3.2.4 Context Analysis………………………
4.3.2.5 Timing diagram………………………..
4.4 System constraints and Risk analysis………………………..
4.4.1 System constraints………………………………..
4.4.2 Risk analysis………………………………….......
14
14
16
16
18
18
19
20
20
20
21
21
22
22
23
Chapter 5. Implementation…………………………………………………..
5.1 Objectives of analysis……………………..………………...
5.1.1 System requirements and challenges (cost
analysis and etc.)………………………………….
5.1.2 Parameter setup and assumptions of simulation….
5.2 Simulations………………………………….……………….
5.2.1 Definition of performance matrices for simulation
scenarios…………………………………………..
5.2.2 Simulation scenarios and Observations………….
5.2.3 Simulation insight………………………………..
5.2.4 Incorporation of modeling into solution…............
5.2.5 Execution of mSCTP patch……….......................
5.2.6 LS functionalities
5.2.7 Location Management by LS ………...………….
24
24
Chapter 6. Experimental Results…………………………………………….
40
LS performance…………………………………….………..
Handover Latency…………………………………………...
Confidence Interval (CI) analysis……………………….......
40
42
44
Chapter 7. Conclusion and Future work…………………………………….
47
Conclusion…………………………………………………...
Future work………………………………………………….
47
47
REFERENCES………………………………………………………...............
48
APPENDIX…………………………………………………………………….
51
6.1
6.2
6.3
7.1
7.2
vi
24
24
27
27
28
33
34
35
37
37
LIST OF FIGURES
3.1
3.2
3.3
NS-2 Architectural view………………………………………………….
Trace File format…………………………………………………………
SCTP node outlook……………………………………………….............
11
12
13
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
The simultaneous mobility of MN_0 and MN_1…………………………
Simultaneous Mobility model with random ‘step_length’………………
Simultaneous Mobility support by LS……………………………………
Location management Process……………………………………………
Integrated structure of TCL and LS………………………………………
Modified association setup..........................................................................
First address reconfiguration case...............................................................
Mobility Process………………………………………………………….
Timing diagram of new approach of mSCTP for simultaneous mobility...
15
16
17
17
18
19
20
21
22
5.1
5.2
The simultaneous mobility scenario with Brink plane……………………
Showing random movements of MN_0 and MN_1 proceeding with
random ‘step_length’ within range (0-750)…………………....................
Showing random movements of MN_0 and MN_1 proceeding with
random ‘step_length’……………………………………….....................
MN_0 and MN_1 simultaneously moving and handovers occur at step11…………………………………………………………….....................
MN_1 and MN_0, handovers to each other’s region simultaneously with
sequential mobility…………………………..............................................
Data set from a random simulation run out of 30 times, (MN_1 and
MN_0, handovers to each other’s region simultaneously)……………….
(a) mSCTP unable to perform ‘Add-IP’ (b) mSCTP successfully perform
‘’Add-IP’’………………………………………………............................
Showing the Add-IP and Delete-IP in mSCTP connection
procedure………………………………………………………….............
Showing new DAR process activity for mSCTP’s ASCONF patch……..
(a) Random movement of MNs, (b) Simultaneous Movement of
MNs……………………………………………………………….............
LS Data Structure…………………………………………………………
Architecture of location detection inside LS……………………………..
Signalling between MN_0 and MN_1 and ASCONFs to measure the
total handover delay………………………………………………………
25
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
6.1
6.2
6.3
28
30
32
32
33
34
35
35
36
37
38
39
LS server sample file storing all the simultaneous mobility
information...……………………………………………………………... 40
LS registration and update in case of simultaneous mobility……………. 41
(a) Error bars of estimated data 1.989170, (b) Error boundary with
standard deviation………………………………………………………... 45
vii
LIST OF TABLES
4.1
Example of random values for simultaneous mobility…..........
15
5.1
5.2
5.3
5.4
Definition of handover delay parameters……………...........
Simulation results showing overlapping number…………….
Simulation results showing overlapping number…………….
Simulation results showing overlapping number…………….
26
29
30
32
6.1
Different steps to measure handover latency for mSCTP with
and without LS………………………………………………..
Handover latency for different cases of simultaneous
mobility………………………………………………………..
Confidence analysis of estimated values LS with mSCTP
Handover Delay………………………………………………
6.2
6.3
viii
42
43
45
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
everyone‟s life. In fact, it cannot be separated from the remaining peoples‟ lives under
a microscope as an isolated object. Therefore, developing technology for technology‟s
sake could be a vital role to fulfill users‟ expectations [1]. One of the elementary
resources needed to deliver users of the mobile internet with good service quality, is
connectivity. Mobility management protocols like Mobile IPv6 [2] address the
problem of providing connectivity when a node is moving and handing off between
points of attachment to the network. If both ends of the communications session are
mobile nodes, then those protocols cannot handle some situations where both sides
move at the same time. However, the researchers are realizing the obligation to
properly support simultaneous mobility.
Mobile technology brought many more progress especially in the wireless systems
which includes, for example, second, third and fourth generation (2G, 3G, and 4G),
satellite systems, WLANs (802.11) etc. [3]. Thus, it is a challenging issue for the next
generation wireless networks to integrate the existing and eventually coming systems
for managing user mobility among heterogeneous networks [4]. Mobility management
is based on the integration of different mobile standards such that each mobile user can
remain connected while roaming through different networks [5] [6]. There are several
resolutions for mobility management of IP nodes has been proposed. Seven “properties
to fully realize the potential of ubiquitous mobility” are proposed in [7], including
simultaneous mobility, i.e., that “end hosts should be able to move simultaneously
without breaking an ongoing session between them.”
Simultaneous mobility issues in seamless handover can be classified by Location
Management and Handover Management. Location management identifies the current
location of mobile devices and keeps track of the location while moving from one
location to another. Location update information is sent by a mobile node (MN) about
its latest location so it can continue to receive data at its latest location. The signaling
messages conveying such information is often called binding updates. There are a
number of possibilities for the recipients of binding updates, depending on mobility
protocol. The main task of handover management in seamless handover is to maintain
the connection of both endpoints. It can be carried out by different layers of OSIreference model [8]. Researchers mainly focus on the three layers for solving the
simultaneous mobility issues. In network layer MIPv6, in transmission layer mobile
SCTP (mSCTP) and in application layer SIP (Session Initiation Protocol) are
commonly used for solving simultaneous mobility problems.
Recently, solutions to the simultaneous mobility problem have been proposed for
Mobile IPv6 [9], for Mobile IP with Location Registers and SIP mobility [10], and for
TCP migration [11]. In this paper, we extend the analysis of simultaneous mobility
issues in seamless handover with using mSCTP protocol and proposed an alternative
solution based on suggested simultaneous mobility model which has been grounded on
independent location server.
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 nonsimultaneous mobility. Simultaneous mobility may lead to a problem of losing a
binding update from one mobile node because it is sent to a previous address of the
other mobile node moving with a handover. Mobile IP based approaches suffers from
drawbacks such as packet loss, high throughputs and handover latency [10]. Other
application layer protocols like SIP [12] could not solve the simultaneous mobility
problems unless it combines with an additional protocol.
Handover refers to the process of transferring an ongoing call or data session from
one channel connected to the core network to another. The most basic form of
handover is when a phone call in progress is redirected from its current cell (called
source) and its used channel in that cell to a new cell (called target) and a new channel.
Seamless handover is defined as a handover researches, most of them are based on the
pattern that a mobile node communicates with a fixed one. However, in a real world,
both nodes may be mobile, thus simultaneous mobility occurs.
2.2 Stream Control Transmission Protocol (SCTP)
Stream Control Transmission Protocol (SCTP) is a Transport Layer protocol, was
introduced by IETF workgroup SIGTRAN in September 2007 (RFC 4960). It provides
almost all service features of Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP) [13]. AND it also facilitates some more advantages like multi-homing,
multi-streaming, which make it exceptionally good for handling with challenging
problems in transport layer whereas TCP, UDP could not fulfill the current need of
mobility.
2.2.1 SCTP association
It is a protocol relationship between two SCTP endpoints and state information
including Verification Tags and current active set of Transmission Sequence Numbers
(TSNs), etc. The endpoints of an association can be uniquely identified by the
transport addresses used by in the association. SCTP closes of an active association on
request from the SCTP user. SCTP also allows ungraceful termination on request from
the user [14].
An endpoint in a transmitting endpoint considers available for receiving user
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 receiver’s stream buffer until the source retransmits the lost
segment. Yet, other streams can still be passed to the upper-layer application. Multistreaming elude the Head-of-line blocking (HOL) exists in TCP (Transmission Control
Protocol), where a single stream loss can cause subsequent streams to also be delayed.
HOL effect does not affect the SCTP association due to individual streams [18].
2.3 SCTP Packet Structure
The SCTP packet structure divided into two basic sections named the common
header and data chunks. Common header inhabits first 12 bytes of SCTP packet which
consists of Source port, Destination port, Verification tag and Checksum. The
remaining part of the SCTP packet occupies Chunk type, Chunk flags, Chunk length
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 (ASCONFACK). Therefore, DAR extension allows SCTP to dynamically add IP or delete IP
addresses to an association and request the primary path change during an active SCTP
association. This primary path is used during communications between the endpoints.
It is not necessary to reestablish an association after a DAR process during handoff
because of the primary path has been set. [21] [22].
2.5 Related works
In SCTP, multi-homing support is analyzed as the new feature that lays the
foundations to transport-layer mobility support. Besides network and application-layer
solutions approaches, to solve simultaneous mobility at the transport layer is a
challenging issue. Transport-layer-based scheme to solve simultaneous mobility has
several advantages such as triangular route problem never occurs, no dependence on
the concept of home network or additional infrastructure beyond Dynamic Host
Configuration Protocol (DHCP) [23] and Domain Name System (DNS) [24], the
possibility of smooth handovers if the mobile node has multiple interfaces and the
ability to pause transmission during mobility-induced temporary disconnections gives
a great deal of flexibility [25]. Furthermore, network layer schemes such as MIP,
makes simultaneous mobility transparent to upper layers by increasing the burden and
responsibility of the internet infrastructure [26]. Some previous approaches to solve
simultaneous mobility related issues using mSCTP and other protocols are given in the
below sub-sections.
2.5.1 Simultaneous mobility solution by mSCTP with RSerPool
Reliable Server Pooling (RSerPool) [27] is proposed to improve SCTP’s 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 information’s throughput, number of packets etc. [40].
3.2 Simulation with NS2
This section describes simulation components and their structures to build a script
in NS2. These NS2 components included within are nodes, links, Simple Link objects,
packets, agents, and applications.
3.2.1 Structure of Wired and Mobile nodes
NS2 associates two kinds of nodes for wired and wireless environment.
The wired nodes consist of an entry point and two classifiers named Address
Classifier and Port Classifier. The configuration of a mobile node is same like wired
nodes. In a mobile node, packets arrive through the entry point to the address
classifiers to check the address. The packets are then flow through the port classifiers
to the routing agents. Routing agent processed the packet via some layer functionality.
Thus the mobile node can be treated as mobile because of the routing type defined in
the Tcl script [39].
An agent of a mobile node is responsible for packet generations and receptions. It
is also responsible for maintaining the traffics like CBR (Constant Bit Rate), FTP (File
Transfer Protocol) etc. Routing agents (DSDV, DSR, and AODV) are configured multi
hop routes for packets [39].
3.2.2 Wireless Simulation by NS2
Simulation of wireless networking in NS2 has various modules; such as mobile
node, Ad-hoc Routing (DSR, DSDV, AODV), MAC 802.11, Radio Propagation
Model and Channel. Appendix A1 illustrates the basic wireless configuration written
in a Tcl script [39].
3.2.3 Trace File
The trace file format is used to trace files produced by the Trace class.
Figure 3.2: Trace File format
12
Chapter 3: Simulation Tool
Figure 3.2 illustrates nine (9) trace entries of a sctp simulation, from them, the
event column has three enqueue operations (``+''), two dequeue operations (``-''), three
receive events (``r''), and one drop event. In the second column, the simulation time is
in seconds at which each event occurred. The next two columns indicate trace
happenings of two nodes. In the next two fields, the type of a packet and their size is
displayed. SCTP packet trace contains five (5) extra column fields than a TCP trace.
Among these, the chunk type indicates some alphabetic flags like I, D, S, H, B. The
flag I indicate an association initiation control chunk like INIT, INIT-ACK, COOKIEECHO, and COOKIE-ACK. The D, S flags indicate a DATA and a SACK chunk. The
rest chunks H, and B are indicates a HEARTBEAT chunk and HEARTBEAT-ACK
chunk successively [39].
3.3 Simulation Methodologies
To develop new ideas, identify problems and optimize the existing systems, it is
important to evaluate the performance in a research issue. Performance evaluation is
depends upon prototyping a model such that it could be build on a system and make it
to work properly on that system. And also by analytical modeling of the system by
building a mathematical model which can be used to analyze the system. Lastly, the
software model of the system is a simulation process. For larger systems, prototyping
consumes more time and analytical modeling becomes complex, therefore is more
complex to control and observe the system. Simulation fulfills all these deficiencies
available in prototyping and analytical modeling. We strained to focus all the strategies
to select and work on proper simulation tool and methodology.
Henceforth, we select NS2 platform for this project implementation task to suit the
requirement of reaching a solution for simultaneous mobility in seamless handover.
According to NS2 architecture, a SCTP enabled node cannot be multi-homed. A multihomed node actually be the combination of three nodes such that a ‘’core node’’ and a
couple of ‘’interface nodes’’ to simulate the interfaces. All these nodes are SCTP
enabled. But, traffic flows only through the interfaces nodes. The core node has
connection with these interface nodes and is used only for routing. The connection of
core node with the interfaces is a unidirectional link. No traffic flows through the core
node. The following figure illustrates the SCTP node outlook [34].
Figure 3.3: SCTP node outlook
To simulate our proposed scheme, it is a prerequisite to acquire a considerable
handover process for seamless communication of mobile nodes. There is no extension
available for mSCTP with the present module of SCTP, in the latest released version
of NS2 (v-2.34). SCTP needs DAR process enabled to perform a handover procedure.
So, it turns to a great problem to solve the simultaneous mobility issues by using
mSCTP. After extensive searching, an mSCTP patch has been contrived for NS2 (v2.30) [41].
13
Chapter 4: Proposed Model for Simultaneous Mobility with Location Management
CHAPTER 4
PROPOSED MODEL FOR SIMULTANEOUS
MOBILITY WITH LOCATION MANAGEMENT
4
In this chapter, we are going to describe the proposed model to solve the
simultaneous mobility issues. After citing the related and recent research papers in this
area and realizing the problem thoroughly, we suggest a new model as a solution
approach. First, we will go through the architectural model of simultaneous mobility
for mSCTP, which is prototyped on NS2 platform. Then location management is
inscribed for the model and related functionalities. After that the total solution
procedure of simultaneous mobility issues is presented with context analysis and
timing diagram. Lastly, we have discussed about the system constraints of the model
and risk analysis.
4.1 NS2 based architectural model for Simultaneous Mobility with
mSCTP
For simultaneous mobility with current version of mSCTP [42] which achieved for
a mobile node (MN) associated with a fixed node. We first simulate the behavior of
simultaneous mobility, where both of the communicating nodes are mobile in real
context. It was a part of this research not only to understand and visualize the problem
but also for a meaningful solution, we simulate the simultaneous mobility nature
referenced to real network scenarios. Firstly we concentrate on building a proper
model in NS2 environment and working on generating suitable simultaneous mobility
patterns.
We consider the random movement of two mobile nodes, MN_0 and MN_1. The
mobile nodes are assumed to exist within different zones of homogeneous networks,
i.e., MN_0 in Zone_0 and MN_1 in Zone_1. These zones can be worked with
customized ranges. Suppose that MN_0 and MN_1 have the symmetric movement
position along x-axis. In details, the considerable mobility for MNs are taken by means
of one dimensional values, i.e., only x axis. The horizontal movement takes no angle,
i.e., ∡=0°. Let the values for x1 as (100, 0) to x2 as (150, 0) for simplicity of this
project solution. Thus the considerable movement is like that x1(100, 0) to x2(150, 0).
That means MN is moving from the position 100 to 150.
The most important state in this solution is the consideration of the term
‘step_length’. The mobile nodes must pose into their mobility with random steps. Step
is defined as the position or state change of MN. At each step, MN has a specific
‘step_length’. The value of ‘step_length’ is equal to the distance travelled by the MNs
during a uniform interval time Δ. We further assume that two mobile nodes are
simultaneously changes the value of ‘step_length’ after every interval time. In addition
to the value of ‘step_length’; it is randomly generated; after every interval time Δ, and
uniformly distributed. Let t0 denote the starting time of simulation. At time t = t0+ Δn,
where n = {1, 2,……, N}. Thus mobility of MN will be called simultaneous. Also
‘step_length’ determines the logical connection between MNs past and future
movement according to our design concept. The simple algorithmic formula for MNs
14
Chapter 4: Proposed Model for Simultaneous Mobility with Location Management
positions is as follows:
MN_0_init.x + step_length = MN_0_new
MN_1_init.x - step_length = MN_1_new
Where, x is any random value along x-axis
step_length
(5,0)
MN_0 moves towards
MN_1
(14,0)
(19,0)
…
….
(7,0)
(20,0)
…
….
(9,0)
(28,0)
(i)
(ii)
MN_1 moves towards
MN_0
(55,0)
(50,0)
…..
(27,0)
(48,0)
(41,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_0’s position (equation (i)). Similarly the same ‘step_length’ is deducted
from MN_1’s old position to detect MN_1’s 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_1’s 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 MN’s 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 node’s old and new position can be located as paired values. As LS
stores all the ‘step_length’ associated with particular mobile node’s 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 mSCTP’s 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 mSCTP’s 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 other’s zone, they continue to receive
packets thorough Path1 or Path2. This is because their location changes already
notified in LS. With DAR process the corresponding MN_0 and MN_1 nodes path has
been set. The handover latency in this case is the time difference between the send of
the last packet by using Path1 and the receiving of first packet using Path 2. We can
determine the total handover delay by measuring the DAR process execution. The
detail techniques are mentioned in the implementation chapter.
4.4 System constraints and Risk analysis
After modeling the solution approach, we intend to do the implementation tasks.
There are several system constraints and risks have been analyzed beforehand of
execution process. These are noted on the following sub-sections.
4.4.1 System constraints
Most of the real systems constraints are artifacts [47]. The cause for this is the
inability of current tools to translate system requirements into system constraints in an
acceptable mode. The transformation the requirements are usually divided into a
number of simple constraints. Unfortunately, the ad hoc methods used to derive the
constraints often leads to an over-constrained and infeasible system. In our approach,
we try to keep the constraints as close as possible to the original requirements as per
proposal. There are some deviation and relative timing constraints which set us to limit
our goal. For simplification in simulation, we did not consider any access points such
as access routers (AR) or base stations (BS) in the presented solution model.
Considering the real network, it is hard to implement the LS storage. But we used LS
storage only for simulation purpose in this project. We limit our research goals on the
phenomena of realization of simultaneous mobility issues and worked over the
modeled solution of how to achieve seamless handover by LS. We focus to implement
the SCTP supportive LS for location server of simultaneous moving MNs which may
not suit in other heterogeneous networks in big ranges. Under such system constraints
the proposed model development started and progressed as per requirement analysis.
22
Chapter 4: Proposed Model for Simultaneous Mobility with Location Management
4.4.2 Risk analysis
The solution model is a new one for simultaneous mobility. The number of
different approaches have accomplished in this area which includes several models for
location management [48]. Our LS enabled location management with ‘step_length’
appropriately updates the changed location of MNs. Thus, it has low risks of being
failed over. This proposed model has built over NS2 platforms and integrated with Tcl
programming. There are large numbers of header files and configurations programs
needed to be installed and tested for this purposes. Proper backups of data and
software output need to stored and maintained in a sound manner. Beside that huge
number of data spaces is mandatory to work with the bulky packages of Linux system
and maintain trace files of NS2. As a dynamic simulation platform NS2 worked
reputedly well enough but we had to measure the performance of the built model. For
analyzing the results of our simulation, first of all we observed the performance of
mSCTP ASCONF for ns-2.30. It is found in the measurement that the accuracy of
mSCTP ASCONF was above 73% and the failure rate is merely above 25%. It can
vary upon different platforms and machine configuration factors. The failure rate has
been decreasing while we shifting towards new generation incorporated computers.
23
Chapter 5: Implementation
CHAPTER 5
IMPLEMENTATION
5
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 model’s 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 node’s initial position, from where the mobile node
begins to move. The nature of this unit is random.
 MN_#_new: It is the mobile node’s next movement position after random
‘step_length’ added with MN’s 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
Tadd-IP
Tdel-IP
Tset-primary-IP
TASCONF
TASCONF- ACK
TRD
TDAR
TmSCTP
Definition
mSCTP Add-IP time
mSCTP Delete-IP time
mSCTP set-primary-IP time
mSCTP ASCONF chunk send delay
mSCTP ASCONF-ACK chunk send delay
Router discovery period
DAR procedure period between MN_0 and MN_1
mSCTP handover delay from MN_0 and MN_1
Table 5.1: Definition of handover delay parameters
The following equation represents the handover delay when MN_0 and MN_ 1
handovers to each other’s zones:
TmSCTP = TRD + TDAR
From equation (i), TmSCTP = TDAR
(ii)
(iii)
Here, The DAR procedure period is composed of the ASCONF parameters sent
from MN_0 to MN_1.
Therefore, TDAR = Tadd−IP + Tset−primary−IP + Tdel−IP
While, Tadd−IP = TASCONF + TASCONF-ACK
Tset−primary−IP = TASCONF + TASCONF-ACK
Tdel−IP = TASCONF + TASCONF-ACK
(iv)
(v)
(vi)
(vii)
Accordingly, mSCTP handover delay can be expressed as:
TmSCTP = (Tadd−IP + Tset−primary−IP + Tdel−IP)
(viii)
Ideally for SCTP router discovery time can be overlooked because of the multihoming feature of SCTP. For example, a typical SCTP connection can be established
by WiFi card in WLAN for certain router discovery while data can still transmitted via
other heterogeneous network like CDMA2000 card. For our proposed solution for
simultaneous mobility, any of the two mobile nodes (MN_0 or MN_1), always be
multi-homed with LS. As Add-IP and Delete-IP, both of this process involves in
location management. Therefore handover delay is comprehensively depends upon
RTT of three ASCONF chunks (equation viii) for simultaneous handover occurrence.
26
Chapter 5: Implementation
The mSCTP handover delay is the addition of three RTT ASCONF chunks between
MN_0 and MN_1. This is why; we can say mSCTP handover as seamless handover.
Another important assumption we made is that, a handover occurs every time
whenever MN_0 or MN_1, touches the Brink point or enters into the other nodes area.
The handover delay is the total time to build the complete association after entering
into the crossed over zone. This period is the total time of Add-IP, set-primary-path
and Delete-IP. Thus, if MN_0 handovers to zone_1, the handover delay is the amount
of time after entering in this zone until making a successful association with any other
mobile node. The phenomena of simultaneous handover will occur, when both MN_0
and MN_1 crossed into zone_1 and zone_0 at same Δ timestamp, and successful SCTP
association establishment between mobile nodes. This is observed as simultaneous
mobility with simultaneous handover.
5.2 Simulations
Simulation is the imitation which involves building a model of a certain system
under study. It can be mentioned as tool for approximation of reality. Simulations often
validate the models and assumptions, and used for verification the software and code.
The following sub-section will include the definitions of the performance matrices
which are required to be mentioned before building the simulation scenarios. Then, we
will discuss the scenarios based on our assumptions and observed experiments. The
final segment contains the incorporation and validation of our proposed model as a
solution for simultaneous mobility problems.
5.2.1 Definition of performance matrices for simulation scenarios
There are certain performance matrices involved in the simulation scenarios based
on our assumptions and experiments. We defined these as performance matrices which
act as preconditions for understanding the simulation behaviors. The following are
short description of performance metrics:
 Overlap: An overlap occurs when any mobile node i.e. MN_0 or MN_1
passed over their boundary zone at any certain time.
 MN_0 overlaps: When only MN _0 passed over the boundary of zone_0.
 MN_1 overlaps: When only MN_1 passed over the boundary of zone_1.
 Simultaneous Overlaps: It is the phenomenon, when both of the MNs overlap
into each other’s 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 other’s zones.
 MN_0 handover: It is the total number of simultaneous handover in addition
27
Chapter 5: Implementation
with MN_0 overlapping number.
 MN_1 handover: It is the total number of simultaneous handover in addition
with MN_1 overlapping number.
 Avg. step_length: Average step_length is the ‘step_length’ values divided by
total number of simulation run.
5.2.2. Simulation scenarios and observations
Different simulation scenarios are considered to measure and analyze the
integrated solution approach. We have analyzed our simulation work both from
statistical and technical viewpoints.
The following discussions are based on different simulation scenarios and
prospective outcomes:
Scenerio-1: Randomly moving mobile nodes for bigger range
It is assumed that MN_0 starts to move from Zone_0 and MN_1 starts to move
from Zone_1. The considered mobility is random for both the mobile nodes and they
follow uniform distribution. The mobility is simultaneous as we maintained the same
time for their movements. There are different ranges for both zones. Range for Zone_0
is from 0 to 374 and range for Zone_1 is from 376 to 750. The Brink plane value is
considered at 375. At each unit time Δ (1 ms), any mobile node is supposed to move
with a random ‘step_length’. We assumed in the whole simulation that this Brink plane
value is the point after which MN_0 or MN_1 switch over to Zone_0 or Zone_1
successively. Thus, this point is considered as the Brink plane point for simultaneous
handover.
Figure 5.2: Showing random movements of MN_0 and MN_1 proceeding with
random ‘step_length’ within range (0-750)
From the figure 5.2, we can observe that the simultaneous mobility pattern of
MN_0 and MN_1 are random and non-sequential. Within the same range, but two
different zones MN _0 and MN_1 are simultaneously moving.
We have built a Tcl script which can initiate the random movements of mobile
nodes simultaneously with random ‘step_length’ values. In each run of simulations
there are different random movements of MN_0 and MN_1 are observed. Here is the
simple formula which we assumed for our simulation:
28
Chapter 5: Implementation
step_length [0-50]: step_length(RNG)
Zone_0: MN_0_init.x + step_length = MN_0 new
Zone_1: MN_0_init.x - step_length = MN_1 new
At every simulation run, the mobile nodes move according to generated
‘step_length’ value. The values of every step motion are uniformly distributed random
values within 0 to 50. So, we always find a unique value of ‘step_length’ of this range
(Appendix B1). In B1, we can observe that MNs are following the presented solution
model for simultaneous mobility.
Following are some results generated for this specific scenario and parameters:
MN_0
Overlaps
1 time
MN_1
overlaps
1 time
Simultaneous
overlap
No
No overlap
28 times
Simultaneous
Handover
0 time
Table 5.2: Simulation results showing overlapping number
Here, with this observation, we derive the formula for calculating average
step_length.
Average step_length =
=
Total distances travelled within total runs
Number of simulation runs
(ix)
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 other’s zones for MN_0 and MN_1. Our simulation takes for 30 runs.
So, mobile nodes crossing over Brink plane only 2 times within 30 run are statistically
satisfied with estimated data.
 Simulation time for each run=3600 seconds
 Total Simulation = 30 times for each revisited values (30*30/30)
 Total time=3600*30=108000 seconds = 1800 minutes = 30 hour
We did not observe any simultaneous handover of MN_1 and MN_0 together in
these thirty runs of successful simulation. The reason we find that if we imagine the
lower range of data for MN_0 and MN_1, then the probability of simultaneous
overlapping is increased.
Scenario-2: Randomly moving mobile nodes using lower range
For analysing different viewpoints of simulation, we set the following ranges of
simultaneous mobility:
Range for MN_0 is between 50 to 99 = Zone_0
Range for MN_1 is between 101 to 150 =Zone_1
Brink plane position: 100
29
Chapter 5: Implementation
Figure 5.3: Showing random movements of MN_0 and MN_1 proceeding with
random ‘step_length’
We assume that the MN_ 0 is randomly moving between Zone_0 and generating
uniformly distributed values of ‘step_length’ while running. Similarly, MN_1 is
randomly moving within Zone_1 range and generating uniformly distributed values of
step_lengths while moving. Here, the maximum ‘step_length’ is 50 as before. At each
unit time Δ, any mobile node is moving with a random ‘step_length’ (Appendix B2). In
B2, we can observe that MNs are following the presented solution model for
simultaneous mobility.
Δ = 0.001s = 1ms
step_length = RNG (0:50)
For this specific scenario, we changed only the ranges and Brink plane point for
occurring handover. Every parameter remained same as previous scenario. Thus, we
observed the random and non-sequential mobility patters of MN_0 and MN_1 which
shown in figure 5.3.
Following are some results generated for this specific scenario and parameters:
MN_0
overlaps
08 times
MN_0
handover
13times
MN_1
overlaps
02 time
MN_1
handover
07 times
Simultaneous
overlap
05 times
No
overlap
5 times
Simultaneous
Handover
05 times
Table 5.3: Simulation results showing overlapping number
Here, from equation (ix), for calculating average step_length, the average
step_length comes approximately 22.
Zone_0 is spread over 50 to 99 unit distances. Thus, MN_0 mathematically should
cross over zone_0: after every (49/21.5) = approx. 2.27 steps to handover.
Zone_1 is spread over 101 to 150 unit distances. Thus, MN_1 mathematically
should cross over zone_0: after every (49/21.5) = approx. 2.27 steps to handover.
The number of simulation taken is 30. So, the estimated values for occurring
handover are 30/2.27=13.21. Simulation result shows total 15 times overlapping i.e.
handover occurs.
30
Chapter 5: Implementation
Thus approximately it has similarities with statistical data.
 Total simulation time for each run=3600 seconds
 Total Simulation = 30 times for each revisited values (30*30/30)
 Total time=3600*30=108000 seconds = 1800 minutes = 30 hour
We observed both simultaneous mobility and simultaneous handover in this
scenario for non-sequential patterns. The above data sets and measurement clearly
certifies that if the ranges of MN_0 and MN_1 are decreased, then the number of
simultaneous handover will definitely increase. Form the table 5.3; we can also realize
the fact that in simultaneous mobility, the number of simultaneous handover is always
less than handover in MN_0 or MN_1.
Scenerio-3: Sequential random moving and Handover
Now, we are assuming that the mobile nodes are moving sequentially with random
step_lenghts at each run. The simultaneous mobility of mobile nodes: MN_0 and
MN_1 from both zones are assumed to be successive. We consider new ranges:
Zone_0 for MN_0: 0 to 249
Zone_1 for MN_1: 251 to 500
Brink plane position: 250
In this scenario, it is assumed that MN_0 starts from initial position (10, 0) with
random ‘step_length’ in Zone_0. And at the same time from Zone_1, MN_1 starts to
move from (500, 0) position with same random ‘step_length’. At STEP-1 (figure 5.4),
MN_1 is moving from position (500, 0) to position (472, 0) with random ‘step_length’
value 28. And with the same ‘step_length’ value, i.e., 28, MN_0 is moving from the
position (10, 0) to position (38, 0) simultaneously. Hence, by the presented model
described in section 4.1, MN_1 is moving from ‘500’ to ‘472’ and MN_0 is moving
from ‘10’ to ‘38’. The detail MNs position values along with associated ‘step_length’
are shown on figure 5.6.
Here, we have only initialized the random and sequential motions of MN_0 and
MN_1 simultaneously towards each other. Every next movement from previous
positions are generated randomly. At each run of simulation, we inserted the initial
positions only. The ‘step_length’ and next movements are generated by our Tcl code.
Below are some samples simulation results of the movement patterns from trace
file by generated main Tcl code:
Formation of output






M-movement
0.001-time for each movement unit (second)
1/0-id of mobile node
(_.00, _.00, 0.00),-initial position(x1,y1,z1)
(_.00, _.00, 0.00),-new position (x2,y2,z2)
_.00-step_length:distance travelled in each step- unit per step
31
Chapter 5: Implementation
Figure 5.4: MN_0 and MN_1 simultaneously moving and handovers occur at
step-11
In this scenario, every movement is sequential and mobility is remained
simultaneous. At every Δ (1ms) time, random ‘step_length’ is generated and mobile
nodes become nearer to each other. Simulation for this scenario will continue until any
of the mobile nodes i.e. MN_0 or MN_1 handovers to each other’s zone or
simultaneous handover occur.
Figure 5.5: MN_1 and MN_0, handovers to each other’s region
simultaneously with sequential mobility
Following are some results generated for this specific scenario and parameters:
MN_0
overlaps
MN_0
handover
MN_1
overlaps
MN_1
handover
Simultaneous
overlap
Simultaneous
handover
Sequential
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 other’s region simultaneously)
We have tested the sequential and simultaneous random movement patterns of
both MN_0 and MN_1. The results show that the percentage of time MN_0 and MN_1
that is simultaneous handover is less than the percentage of time either MN_0 or
MN_1 handovers to other zones. With the mean step 11 and average ‘step_length’
value 22, the rate for sequential handover is increased. In this scenario, it is observed
that the occurrence of sequential handover is more than simultaneous handover (table
5.4) in compare to scenario-1 and scenario-2. In addition, MN_0 or MN_1 handover is
always more than sequential or simultaneous handover of both MN_0 and MN_1.
5.2.3 Simulation insight
We launch FTP traffic for mSCTP implementation in NS2. FTP is attached with
SCTP agent. Simulation is started at 0.000001s. After that at 0.5s FTP traffic is
generated. Until the simulation time stops which is set as 3600s the simulation will
continue. FTP needed to stop before simulation ends. In our simulation, FTP usually
33
Chapter 5: Implementation
set-off around 20s before simulation ends. Typically at 125.001s, we initialed to call
the ASCONF for mSCTP. Drop-tail queue is followed to store the packets. The duplex
links are set with delay of 200ms and bandwidth of 0.5Mb for interfaces used within
SCTP agent. We started record of all our simulation results after system gets stable.
No results were recorded but observed during warm-up periods. Approximately before
each pattern of simulation, we took 30 min warm-up time to have the system in steady
state. And buffer is flushed after that to get more free memory utilization. We
measured all the data sets for 30 different values where each value consists of 30
different simulations. All the data sets are assumed to follow normal distribution.
5.2.4 Incorporation of modeling into solution
In this subsection, first we briefly analyzed the simultaneous mobility issues based
on the observed simulation scenarios. Thereafter, we approached towards our proposed
modeled solution and validation by simulations.
(a)
(b)
Figure 5.7: (a) mSCTP unable to perform ‘Add-IP’ (b) mSCTP successfully
perform ‘’Add-IP’’
For the above three scenarios in section 5.2.2, SCTP association is lost every time
when both MN_0 and MN_1 simultaneously moving and changing their locations
continuously. mSCTP can cope up with only sequential handover or sequential
mobility for single mobile node. But in case of both MN_0 and MN_1 performs
handover at the same time mSCTP failure occurs. It cannot complete necessary ‘AddIP’ operation and session is lost.
In the figure 5.7 (a), mSCTP unable to maintain mobility in these process and
failed to preserve conventional DAR process when both nodes are mobile. Whereas, in
figure (b), it performs a successful DAR process, hence a handover occurs.
In simultaneous mobility, any mobile node must remain reachable to the rest of the
network via a static identifier regardless of its current location. At this point, we need a
Location manager for the service continuity to keep DAR process alive. Our proposed
solution has LS, which can act as a location identifier. The above problem can be
solved using mSCTP’s ASCONF feature for seamless handover along with proposed
LS. mSCTP’s ASCONF patch is installed on NS-2.34 and necessary programming for
integrating LS is done in Tcl script.
34
Chapter 5: Implementation
Figure 5.8:
procedure
Showing the Add-IP and Delete-IP in mSCTP connection
We used the mSCTP’s 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 mSCTP’s Add-IP is working. The performance of mSCTP handover will
depend on how to configure the triggering rules for ‘adding a new IP addresses’ (AddIP) and ‘changing the primary IP address’ (Primary-Change) to an on-going SCTP
association. mSCTP’s ASCONF patch over NS2, integrate this triggering internally.
Figure 5.9: Showing new DAR process activity for mSCTP’s 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. mSCTP’s 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. That’s 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 MN’s initial position (symmetric for X= ($) =Y).
5.2.7 Location Management by LS
In this solution of simultaneous mobility, the location management is done by LS.
LS facilitate both end-to-end mobility supports for mobile nodes travelling randomly.
First it registers information of mobile movements such as ‘step_length’, MNs initial
positions. By using this information later, it can automatically detects the next
37
Chapter 5: Implementation
movements of specific mobile nodes. Also, LS is capable of storing all the values of
‘step_length’ for which handover is occurring. By exploiting these ‘step_length’ values
for handover, LS can automatically measure the changed new location of mobile
nodes. In addition, LS can find the old initial values for mobile nodes. So, if LS can
detect the random new and old positions of mobiles, it can easily retrieve the lost
binding information. Beside that if location is detected, the session mobility can also
be solved. Thus location management problem is solved by using our simultaneous
mobility model.
Any participating mobile node can efficiently retrieve the values (positions)
associated with given key ‘step_length’ value. It is a convenient way of maintain
mapping from ‘key value’ to ‘associated values’ where information can be scalable.
Thus, this location detection is solved by LS. This infrastructure of LS would be handy
to implement complex services like distributed information systems in LS.
Figure 5.12: Architecture of location detection inside LS
This proposed solution with LS, starts from registering procedure. Every randomly
generated value of simultaneously moving MN_0 and MN_1 with associated
‘step_length’ values are registered into LS. LS verifies and checked if it is already
existing or not for non-occurring data redundancy. Implementation of LS registration
and update procedure is shown in Appendix C1 and C2.
Then, mSCTP operation starts with making data chunk for mobile nodes. The
SCTP association starts with ‘Add-IP’. It initiates by calling ASCONF. New address
location is forwarded from LS. This process finished in two steps. mSCTP always
generating global IP for each association and established virtual connection with
interfaces. After getting the new IP address from the changed location of MN_0
through LS, mSCTP sends ‘Add-IP’ request to the corresponding mobile node and
waits for acknowledgement. After receiving ASCONF request, MN_1 makes its own
data chunk and forwards ASCONF acknowledgement. There exits two ASCONFs in
Add-IP.
38
Chapter 5: Implementation
Figure 5.13: Signalling between MN_0 and MN_1 and ASCONFs to measure
the total handover delay
Thus, mSCTP successfully completes first step ‘Add-IP ‘and proceeding with this
new address for further operation. The next process of ‘Set Primary Path’ starts after
Add-IP is successfully finished. It follows the default DAR process of mSCTP which
consists of two ASCONFs. These two RTT will be added in total handover delay
calculation. The last step is ‘Delete-IP’. This process starts after setting up primary
path. This procedure of ‘Delete-IP’ also consists of two ASCONFs. After data
communication is successfully finished with designated primary path, mSCTP
evaluates this path as no longer needed. This process ends very faster than other two
previous steps of mSCTP operation. Since, it is not needed to send any
acknowledgement to the primary address. It just deleted the old unused IP. But, our
proposed LS keeps the record that which location is already used and no longer
needed. So, at this stage LS updates itself by automatically deleting the old location
stored in the LS.
From figure 5.13, it can be realized that whole mSCTP procedure involved six
ASCONFs. These RTTs will be added while determining handover delay. LS stores the
locations of MNs to be initialized for DAR process and delete location information
from LS after finishing the DAR process. As LS starts instantaneously just before the
DAR, it is expected from our simulation that location management with LS provides
less handover delay. We will see detail in the results chapter.
39
Chapter 6: Experimental Results
CHAPTER 6
EXPERIMENTAL RESULTS
6
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 other’s zones and association with new mobile nodes.
We measured the three different criteria for estimating handover delay in our
solution. The first one is the handover delay of normal random movement of MN_0
and MN_1. In this case there is no location management support given by LS. The
next mentioned on the table 6.1, the handover delay of MN_0 with LS support. It is the
total time of three RTT ASCONF chinks of mSCTP after handovers to zone_1. MN_1
handover time is also calculated by adding the total time of Add-IP, set-primary-path
and Delete-IP ASCONFs. Finally, the simultaneous handover delay of MN_0 and
MN_1 is calculated by taking the time difference of crossing over to Zone_1 and
Zone_0 simultaneously. This will be also the calculated sum of three ASCONFs times
processed by mSCTP.
Parameters for
handover
measurement
Tadd-IP
Tset-primary-IP
Tdel-IP
No Location
management
Location Management
MN_0, MN_1
Handover
random
Movement
Without LS
MN_0
Handover
Simultaneous
Movement
With LS
MN_1
Handover
Simultaneous
Movement
With LS
MN_0, MN_1
Handover
Simultaneous
Movement
With LS
0.692478
0.654933
0.659489
0.67959
0.65468
0.654897
0.679591
0.654683
0.654901
0.67959
0.654681
0.654899
Table 6.1: Different steps to measure handover latency for mSCTP with and
without LS
The table 6.1 shows the time difference of Add-IP, set-primary-path and Delete-IP
between two mobile nodes using mSCTP without LS server and with LS server. At
first, we analysed the association delay of two mobile nodes moving randomly with
independent time difference in their own zones. There is no location management
involved for this. Then the result is based on the simultaneous mobility with handover
occurrence of MN_0 with LS server contribution. The next one is the outcome of
MN_1 handovers when simultaneously moving with LS provision. The rightmost
corner observation is for both MN_0 and MN_1 simultaneous handovers to each
other’s 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 = (Tadd−IP + Tset−primary−IP + Tdel−IP)
42
Chapter 6: Experimental Results
In this equation the three parameters for DAR process is consequently added for
mSCTP. For every occurrence of simultaneous or non-simultaneous handover, we can
measure the handover latency by this derived standard equation of TmSCTP [49].
Thus the coming aftermaths for handover latency of mSCTP with location
management and without location management, for simultaneous mobility are
dissected below:
mSCTP handover without LS (no location management) = (0.692478 + 0.654933
+ 0.659489) = 2.006900 s
mSCTP handover with LS (MN_0 Handovers) = (0.67959 + 0.65468 + 0.654897)
= 1.989167 s
mSCTP handover with LS (MN_1 Handovers) = (0.679591 + 0.654683 +
0.654901) = 1.989175 s
mSCTP handover with LS (MN_0 and MN_1 Handovers) = (0.67959 + 0.654681
+ 0.654899) = 1.989170 s
The above expression (5.1.2) calculates the handover delay of simultaneous
moving mobile nodes in seamless handovers. All the values are measured by taking
average out of 30 independent results i.e. n=30 with revisited 30 times values. The
measurement shows that when only MN_0 handovers, mSCTP with LS achieve
significant improvement i.e. approximately 17.7330ms less latency than the approach
of mSCTP without LS. When MN_1 handovers, there is about 17.725ms less latency
achieved with our proposed location management. While both MN_0 and MN_1
simultaneously handovers the improvement is almost 17.7300ms less latency than
mSCTP without LS approach. Hence, we can say that the overall performance has
improved using LS server with mSCTP. The outcome of average handover latency is
17.73ms with LS based approach which is significant in terms of seamless
communication.
Handover
Latency
Improvement
MN_0 [ms]
MN_1 [ms]
17.7330
17.725
MN_0+MN_1, [ms]
17.7300
Avg,[ms]
17.73
Table 6.2: Handover latency for different cases of simultaneous mobility
From the above results in table 6.2, we can definitely interpret the significant
performance improvement of mSCTP with location management support of LS in case
of simultaneous mobility. In every cases of simultaneous mobility with LS support the
handover latency is curtailed. When simultaneous handover occurs between MN_0 and
MN_1, the proposed scheme has reached the handover latency perfection of
approximately 17.73ms less compared to handover latency of conventional
experimented approach. It can be observed from the table 6.2 that the average
handover delay is lessening to 17.73ms. With this mean value of average handover
latency progress, it is inspected that there is not much vulnerability in case of one
mobile node handovers or both mobile nodes simultaneously handovers. Hence we can
evidently mention that, the unique solution for simultaneous mobility with location
43
Chapter 6: Experimental Results
management support is effectual.
After comparing these above datasets, we can say that in case of simultaneous
mobility pattern this improvement is quite causative. Moreover to maintain the
seamlessness in on-going communication, this performance enhancement of mSCTP
with LS support is vital.
6.3 Confidence Interval (CI) analysis
Confidence interval (CI) is a statistical parameter to indicate reliability of certain
estimation. In case of repeated experiment it is frequently used for the basis of
comparison. For quantitative analysis of measured data CI is often distinguished in
simulations [50].
Formula for calculating CI:
(i)
Where, µ
n
is the unknown value.
is the number of observation.
is the average serves as estimator of µ.
is the estimation of the variance of the mean.
is the term dependent on confidence level (1-α).
For, n ≥ 30 ~ 40; to be revisited.
is the half size of the confidence interval.
is the relative half size of the confidence interval.
is the coefficient of variation.
If anyone would assume a very large number of independent 100(1 – α) %
confidence intervals, each grounded on n interpretations, the proportion of these
intervals that contain the value μ (to be estimated) should be the coverage 1 – α. It tells
the percentage of intervals that would contain the unknown real value μ.
It is for normal distribution with n>= 30 to 40. For sufficiently large n, the error
between
and µ approaches a normal distribution independently of the real
distribution of the error between
and µ. As we worked with approximately n=30
revisited data sets, we follow the normal distribution. All the measured data are
identically distributed and simulated after system to be warmed up.
We assume 95 % confidence level for the population mean in this experiment as
such it is the desired coverage.
So, α = 0.05. Z = Z0.975 ≈ 1.96 (from normal distribution) [51].
44
Chapter 6: Experimental Results
We get the mean of with LS handover delay = 1.989170 s
Standard Deviation = 2.166708 s
CI = 1.96
So, the upper limit = 1.989170 + 1.96 = 3.949 s
The lower limit = 1.989170 – 1.96 = 0.029 s
Similarly, we can calculate the other values of the mean of handover delay with LS
support. From the table 6.3, we can observe the average and standard deviations
measured. The data boundaries found after adding and deducting the CI interval from
the average value of handover latency with LS.
Avg [s]
Std.-dev [s]
95 % Confidence
Interval
Boundaries [ms]
(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 nextgeneration all-IP-based wireless systems, "Wireless Communications, IEEE , vol. 11, no. 4,
pp. 16-28, August 2004.
[2] D. Johnson, C. Perkins, and J. Arkko, “Mobility support in IPv6,” IETF RFC 3775, June
2004.
[3] The Working Group for WLAN Standards. Available:
http://grouper.ieee.org/groups/802/11/
[4] A. Ezzouhairi, A. Quintero, and S. Pierre, “A new SCTP mobility scheme supporting
vertical handover,” in Proc. IEEE WiMob’06, June 2006.
[5] Kelly, A, Muntean, G, Perry, P, and Murphy, J, “Delay-Centric Handover in SCTP over
WLAN”, Transactions on Automatic Control and Computer Science, 49, 63 (2004), 1--6.
[6] R. Ramjee, T. La Porta, S. Thuel, and K. Varadhan, “IP Micro-Mobility support through
HAWAII”, Internet Draft, work in progress, draft-ramjee-micro-mobility-hawaii-OO.txt,
March 1999.
[7] Shelley Zhuang, Kevin Lai, Ion Stoica, Randy Katz, and Scott Shenker, “Host mobility
using an internet indirection infrastructure”, in International Conference on Mobile Systems,
Applications and Services (Mobisys), San Francisco, May 2003.
[8] M. Ratola, “Which Layer for Mobility? – Comparing Mobile IPv6, HIP and SCTP, HUT
T-110.551,” Seminar on Internetworking, 2005. Available: http://www.tml.tkk.fi/Studies/T110.551/2004/papers/Ratola.pdf
[9] Q. Liu, S. Li, H. He, and B. Wang, "A Multi-binding Solution for Simultaneous Mobility
of MIPv6," IEEE International (SOSE'06) China, 2006.
[10] Wong KD, Dutta A, Young K and Schulzrinne H. "Managing simultaneous mobility of
IP hosts".,in IEEE Milcom 2003; vol. 2, pp. 785–790.
[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. 26–31, 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. 69–73.
[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. 305–309.
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. 64–76, 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. Ferrús, A. Brunstrom, et al., “Towards transport-layer mobility:
evolution of SCTP multihoming,” Computer Communications, vol. 31, no. 5, pp. 980–998,
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,
Königswinter/Germany, Nov 2003.
[29] K. Daniel and Lee Woon, Wei Wong, "Analysis of Simultaneous Mobility under
Asymmetric Mobility Conditions," in Military Communications Conference, 2007.
MILCOM 2007. IEEE , Orlando, FL, 2007, pp. 1 - 7.
[30] K.D.Wong and W.L.Woon, “Simultaneous mobility: A new analytical approach,” in
IEEE VTC 2007 Spring. IEEE, April 2007.
[31] Wei-Kuo Chiang and Pei-An Lee, “Simultaneous mobility support with IEEE 802.21
media independent handover,“ International Computer Symposium, vol 1, pp. 649-655,
November 2008.
[32] K.D.Wong and A.Dutta, “Simultaneous mobility in MIPv6,“ in IEEE Electro/
Information Technology Conference (EIT), Lincoln, Nebraska, May 2005.
[33] Network and system Lab. CSIE, NCTU. Available:
http://nsl.csie.nctu.edu.tw/main.html
[34] The Network Simulator - ns-2. Available: http://www.isi.edu/nsnam/ns/
49
[35] Ibrahim F. Haddad and David Gordon, "Using Network Simulator 2 to simulate case
scenarios using SCTP and TCP protocols with FTP and HTTP traffic, "LINUX JOURNAL,
Oct 2002. Available: http://www.linuxjournal.com/article/5929
[36] J. Domzal and A. Jajszczyk, “Approximate Flow-Aware Networking,” in IEEE ICC
2009, Dresden, Germany, June 2009.
[37] REAL 5.0 Overview. Available: http://www.cs.cornell.edu/skeshav/real/overview.html
[38] Routing Protocols in ns-2. Available:
http://sce.uhcl.edu/yang/teaching/csci5931netSecuritySpr05/ns-tutorial.doc
[39] NS manual. Available: http://www.isi.edu/nsnam/ns/doc/ns_doc.pdf
[40] Network Animator (Nam). Available: http://www.isi.edu/nsnam/nam/
[41] Communications Protocols Laboratory. Available: http://protocol.knu.ac.kr/
[42] Seok J. Koh and Qiaobing Xie, “Mobile SCTP (mSCTP) for IP Handover Support,”
IETF Internet draft, Oct 2005.
[43] Wang and Qiang Liu, "A Multibinding Solution for Simultaneous Mobility of MIPv6",
presented at the Second IEEE International Workshop on Service-Oriented System
Engineering, 2006. SOSE ’06, Shanghai, 2006, pp. 143-146.
[44] Patel, A. and Giaretta, G., “Problem Statement for Bootstrapping Mobile IPv6
(MIPv6)”, RFC 4640, September 2006.
[45] Tuexen, M. and Stewart, R., “Stream Control Transmission Protocol (SCTP) Chunk
Flags Registration”, RFC 4960, October 2010.
[46] Thomson S., Narten T. and Jinmei T.,” IPv6 Stateless Address Autoconfiguration”,
RFC 4862, September 2007.
[47] C. Ekelin and J. Jonsson, “Real-Time System Constraints: Where do They Come From
and Where do They Go?”, Proceedings of the International Workshop on Real-Time
Constraints, Alexandria, USA., Oct 1999, pp. 53-57.
[48] Abhishek Roy, Archan Misra and Sajal K. Das, "Location Update versus Paging TradeOff in Cellular Networks: An Approach Based on Vector Quantization," IEEE Transactions
on Mobile Computing, vol. 6, no. 12, pp. 1426-1440, June 2007.
[49] Jung Kee Song and Wenye Wang, "A simulation study of IP-based vertical handoff in
wireless," Wireless Communications and Mobile Computing, vol. 6, no. 5, pp. 629–650, JUL
2006.
[50] Wei Wang and Norman Fenton, "Risk and confidence analysis for fuzzy multicriteria
decision making," Knowledge-Based Systems, vol. 19, no. 6, pp. 430-437, October 2006
[51] Standard Normal Distribution Table. Available:
http://www.mathsisfun.com/data/standard-normal-distribution-table.html
50
APPENDIX
A1. Basic Wireless Configuration
A2. Mobile Node configuration
51
B1. Data sets from randomly generated moving values of MN_0 and MN_1 for bigger
range for scenario-1:
Zone 0
Step_Length MN_0_Init MN_0_New
6
84
90
16
276
292
14
308
322
14
352
366
45
308
353
9
310
319
18
352
370
37
161
198
31
311
342
34
331
365
35
300
335
5
330
335
12
284
296
30
58
88
3
150
153
31
220
251
44
84
128
20
308
328
10
150
160
3
102
105
14
316
330
4
149
153
43
56
99
45
54
99
8
108
116
2
262
264
28
356
384
6
255
261
33
315
348
35
158
193
32
332
364
Zone 1
MN_1_Init MN_1_New
534
528
396
380
508
494
504
490
501
456
402
393
381
363
381
344
470
439
438
404
446
411
387
382
449
437
494
464
476
473
498
467
513
469
423
403
473
463
432
429
411
397
454
450
422
379
440
395
513
505
379
377
407
379
388
382
524
491
515
480
548
516
52
B2. Data sets for randomly generated MN_1 and MN_0 for lower range in scenario-2:
Zone 0
Zone 1
Step_Length MN_0_Init MN_0_New MN_1_Init MN_1_New
36
99
135
142
106
0
96
96
146
146
20
74
94
148
128
9
55
64
101
92
10
90
100
137
127
4
60
64
110
106
17
68
85
150
133
29
59
88
135
106
5
78
83
127
122
8
75
83
142
134
46
96
142
147
101
6
71
77
132
126
8
76
84
109
101
33
75
108
102
69
49
92
141
134
85
33
90
123
142
109
31
73
104
125
94
14
53
67
107
93
20
81
101
147
127
28
98
126
148
120
38
72
110
148
110
19
62
81
127
108
15
68
83
133
118
7
85
92
124
117
14
82
96
126
112
45
86
131
145
100
31
71
102
150
119
43
95
138
137
94
24
51
75
130
106
3
52
55
121
118
53
C1. LS server registration and update, while MN_0 handovers:
54
C2. LS registration and update while MN_1 handovers:
55
D1. Trace file sample SCTP interface (if0):
56
D2. Trace file sample SCTP interface (if1):
57
D3. Multi-homed SCTP node sample trace file:
58
E1. XGRAPH view of SCTP node data transmission of if0:
59
E2. XGRAPH view of SCTP node data transmission of if1:
60
E3. XGRAPH view of Multi-homed SCTP nodes data transmission:
61
F. Code for ADD/Delete IP multiple interfaces of mSCTP:
#make source node(multiple-interface)
#
o
#
/
#
o
#
\
#
o
set h0_core [$ns node]
set h0_if0 [$ns node]
set h0_if1 [$ns node]
$h0_core color red
$h0_if0 color red
$h0_if1 color red
$ns multihome-add-interface $h0_core $h0_if0
$ns multihome-add-interface $h0_core $h0_if1
#make destination node(multiple-interface which can be added
or deleted)
#
o
#
\
#
o
#
/ or not
#
o
set h1_core [$ns node]
set h1_if0 [$ns node]
set h1_if1 [$ns node]
$h1_core color blue
$h1_if0 color blue
$h1_if1 color blue
$ns multihome-add-interface $h1_core $h1_if0
$ns multihome-add-interface $h1_core $h1_if1
#later, can be added or deleted
$ns duplex-link $h0_if0 $h1_if0 0.5Mb 200ms DropTail
$ns duplex-link $h0_if1 $h1_if1 0.5Mb 200ms DropTail
# make SCTP agent and attach to node(host)
set sctp0 [new Agent/SCTP/Asconf]
$ns multihome-attach-agent $h0_core $sctp0
set trace_ch [open trace.sctp w]
$sctp0 set trace_all_ 1
$sctp0 trace rto_
$sctp0 trace errorCount_
$sctp0 attach $trace_ch
set sctp1 [new Agent/SCTP/Asconf]
$ns multihome-attach-agent $h1_core $sctp1
#connect two agent
$ns connect $sctp0 $sctp1
#make application to send traffic
62
set ftp [new Application/FTP]
$ftp attach-agent $sctp0
$sctp0 set-primary-destination $h1_if0
$sctp1 set-primary-destination $h0_if0
#make link objects and
#set link to dynamic (to up/down)
set l0 [$ns get-link $h0_if0 $h1_if0]
set l1 [$ns get-link $h0_if1 $h1_if1]
$l0 dynamic
$l1 dynamic
#condition when to add ip/fuction of mSCTP active
# Standard multi-test if
# {
proc add-ip {agent if1} {
global l1
#if call add_ip, internallay send ASCONF and recv
ASCONF_ACK,
#and select action ADDIP/DELIP/SET_PRIMARY_PATH
$agent add_ip $if1 $l1
}
proc del-ip {agent if1} {
global l0
$agent del_ip $if1 $l0
}
proc set-primary-address {agent_d if1} {
$agent_d set_primary_address $if1
#$agent_s set-primary-destination $if1
}
proc sim_start {} {
global ns
global h0_if1
global h1_if1
set l [$ns get-link $h0_if1 $h1_if1]
$l dynamic
$l color red
$l down
}
63
G. Header file (asconf.h) for mSCTP:
#ifndef ns_sctp_handover_h
#define ns_sctp_handover_h
#include "agent.h"
#include "node.h"
#include "packet.h"
#include "sctp.h"
#define SCTP_CHUNK_ASCONF_LENGTH 24
typedef struct SctpAsconfChunk_S
{
SctpChunkHdr_S sHdr;
u_int uiSeriNum;
u_int uiAddrParam;
u_short usType;
u_short usLength;
u_int uiAsconfReqCorID;
u_int uiIpValue;
SctpDest_S *spDest;
};
typedef SctpAsconfChunk_S SctpAsconfAckChunk_S;
class SctpHandoverAgent : public SctpAgent
{
public:
SctpHandoverAgent();
~SctpHandoverAgent(){}
//virtual
// void Timeout(SctpChunkType_E, SctpDest_S*);
void SackGenTimerExpiration();
protected:
//virtual
int command(int argc, const char*const* argv);
//virtual
int GenChunk(SctpChunkType_E eType, u_char *ucpChunk);
int ProcessAsconfAckChunk(SctpAsconfAckChunk_S
*spAsconfAckChunk);
//virtual
int ProcessChunk(u_char *ucpInChunk, u_char **ucppOutData);
int SendAsconf(SctpDest_S *spDest);
};
#endif
64
H. Random number generator header file in NS2:
/*
==============================================================
========
Global Variables
==============================================================
======== */
const double
RANGE = 250.0;
// transmitter range in
meters
double
TIME = 0.0;
// my clock;
double
MAXTIME = 0.0;
// duration of
simulation
double
double
double
double
u_int32_t
u_int32_t
u_int32_t
u_int32_t
MAXX = 0.0;
MAXY = 0.0;
MAXSPEED = 0.0;
PAUSE = 0.0;
NODES = 0;
RouteChangeCount = 0;
LinkChangeCount = 0;
DestUnreachableCount = 0;
Node
u_int32_t
u_int32_t
*NodeList = 0;
*D1 = 0;
*D2 = 0;
/*
==============================================================
========
Random Number Generation
==============================================================
======== */
#define M
2147483647L
#define INVERSE_M
((double)4.656612875e-10)
char random_state[32];
RNG *rng;
double
uniform()
{
count++;
return rng->uniform_double() ;
}
..............................................................
.......
void
Node::RandomPosition()
{
position.X = uniform() * MAXX;
65
position.Y = uniform() * MAXY;
position.Z = 0.0;
}
void
Node::RandomDestination()
{
destination.X = uniform() * MAXX;
destination.Y = uniform() * MAXY;
destination.Z = 0.0;
assert(destination != position);
}
void
Node::RandomSpeed()
{
speed = uniform() * MAXSPEED;
assert(speed != 0.0);
}
void
Node::Update()
{
position += (speed * (TIME - time_update)) * direction;
if(TIME == time_arrival) {
vector v;
if(speed == 0.0 || PAUSE == 0.0) {
RandomDestination();
RandomSpeed();
v = destination - position;
direction = v / v.length();
time_arrival = TIME + v.length() / speed;
}
else {
destination = position;
speed = 0.0;
time_arrival = TIME + PAUSE;
}
fprintf(stdout, NODE_FORMAT,
TIME, index, destination.X, destination.Y,
speed);
}
time_update = TIME;
time_transition = 0.0;
}
.........................................
66
/*
* Boundary conditions.
*/
if((t1 == 0.0 && t2 > 0.0) || (t2 == 0.0 && t1 >
0.0)) {
m1->reachable = m2->reachable = 1;
m1->time_transition = m2->time_transition =
TIME + max(t1, t2);
}
else if((t1 == 0.0 && t2 < 0.0) || (t2 == 0.0 && t1
< 0.0)) {
m1->reachable = m2->reachable = 0;
m1->time_transition = m2->time_transition =
0.0;
}
/*
* Non-boundary conditions.
*/
else if(t1 > 0.0 && t2 > 0.0) {
m1->time_transition = TIME
m2->time_transition = TIME
}
else if(t1 > 0.0) {
m1->time_transition = TIME
m2->time_transition = TIME
}
else {
m1->time_transition = TIME
m2->time_transition = TIME
}
+ min(t1, t2);
+ min(t1, t2);
+ t1;
+ t1;
+ t2;
+ t2;
/*
==================================================
Update the transition times for both NODEs.
================================================== */
if(time_transition == 0.0 || (m1->time_transition
&&
time_transition > m1->time_transition)) {
time_transition = m1->time_transition;
}
if(n2->time_transition == 0.0 || (m2>time_transition &&
n2->time_transition > m2->time_transition)) {
n2->time_transition = m2->time_transition;
}
next:
if(reachable != m1->reachable && TIME > 0.0) {
LinkChangeCount++;
link_changes++;
n2->link_changes++;
}
}
}
67
I. Sample trace file (SCTP) of calculating RTT and RTO:
time: 0.50000
saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0
rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 0.50000
saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0
rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 0.50000
saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0
rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 0.50000
saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 0
rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 1.67155
saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
2936 pba: 0 out: 2936 ssthresh: 65536 rwnd: 65536 peerRwnd:
62600 rto: 1.000 srtt: 0.030 rttvar: 0.015 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 1.67155
saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 62600
rto: 3.000 srtt: 0.000 rttvar: 0.000 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
...................................
time: 87.79685 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.657 rttvar: 0.020 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 87.79685 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 88.45497 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.657 rttvar: 0.015 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 88.45497 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
68
time: 89.11296 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.657 rttvar: 0.012 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 89.11296 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.696 srtt: 0.669 rttvar: 0.257 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
.......................................
time: 120.10485 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.657 rttvar: 0.039 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 120.10485 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 120.77662 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.659 rttvar: 0.033 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 120.77662 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 121.43681 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.659 rttvar: 0.025 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 121.43681 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 122.07987 saddr: 4 sport: 0 daddr: 6 dport: 0 cwnd:
66060 pba: 0 out: 64592 ssthresh: 65536 rwnd: 65536 peerRwnd:
944 rto: 1.000 srtt: 0.657 rttvar: 0.023 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: TRUE frCount: 0
timeoutCount: 0 rcdCount: 0
time: 122.07987 saddr: 4 sport: 0 daddr: 7 dport: 0 cwnd:
2936 pba: 0 out: 0 ssthresh: 65536 rwnd: 65536 peerRwnd: 944
rto: 1.510 srtt: 0.659 rttvar: 0.213 assocErrors: 0
pathErrors: 0 dstatus: ACTIVE isPrimary: FALSE frCount: 0
timeoutCount: 0 rcdCount: 0
69
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising