MASTER'S THESIS

Available Bandwidth Measurement in 4G

Networks

Saqlain Haider
Harpal Singh
2013

Master of Science (120 credits)

Computer Science and Engineering

Luleå University of Technology

Department of Computer Science, Electrical and Space Engineering
Available Bandwidth Measurement
in 4G Networks

Author
Harpal Singh Saqlain Haider

Masters in Mobile systems

Department of Computer Science, Electrical and Space Engineering
Luleå University of Technology
Luleå, Sweden

Supervisors
Anders Hedlund Christer Åhlund
Ascom Network Testing AB Luleå University of Technology
www.ascom.com www.ltu.se
Preface

This Master thesis work has been done as a partial fulfilment of Master degree
in Computer Science, Electrical and Space Engineering with specialization in
the field of Mobile Systems at Luleå University of Technology, Luleå, Sweden.
The work was carried out at Terminal and Pocket Division of Ascom Network
Testing AB, Skellefteå, Sweden. Ascom Network Testing AB provide solutions
for drive testing, analysing, benchmarking and monitoring of mobile network
performance. Ascom Network Testing AB’s continuous R & D contributes with
a market share of 40 % in the field of drive testing for wireless communication
networks. Ascom develops technology for deploying, monitoring and assurance
of quality of service for broadband wireless networks.
Acknowledgement

We would like to thank our mentor and external advisor Anders Hedlund (Se-
nior Specialist User Equipment Measurements) at Ascom Network Testing AB,
Skellefteå, Sweden for his support, motivation, valuable comments and time
he invested in this project which allowed us to gain a deeper understanding in
the field of network performance measurements. We got an opportunity to go
beyond the academic and research work to make this a meaningful personal
and professional experience.
We would like to extend our gratitude to Adrain Jakobsson (Department Man-
ager R & D,Terminals & Pockets) at Ascom Network Testing AB, who provided
us a platform to conduct our research. He has been a dedicated manager with
instant response to queries. We would like to acknowledge him for allowing
us to be a part of ongoing research and development in Terminal and pocket
division.
Special thanks to Prof. Christer Åhlund (Program co-ordinator, Masters in
Mobile Systems) from Department of Computer Science, Electrical and Space
Engineering of Luleå University of Technology, Sweden for his supervision to
provide valuable comments and suggestions. He has guided us by the means
of courses offered by the division and provided a strong foundation in the
field of wireless communication. We are grateful for both our supervisors for
sparing valuable time for guidance and thesis report review with meaningful
comments.
We are grateful to our family members, close friends and colleagues from Luleå
University of Technology, for their encouragement and support. At last we
would be thankful to all employees of Ascom Network Testing AB for providing
a friendly and supportive environment throughout the research period.

Luleå, October 2012

Harpal Singh
Saqlain Haider
Abstract

Existing available bandwidth estimation tools were mainly designed for fixed
IP backbone networks and desktops with assumption of First In First Out(FIFO)
Principle. While LTE supports high data rates of 100 Mbps, challenge is to
adapt available bandwidth algorithms for quick and non-intrusive measure-
ments on an Android OS based device supporting different MIMO configu-
rations. This Master thesis presents real time, two way available bandwidth
measurement tool using Two Way Active Measurement Protocol (TWAMP)
for Android OS based devices to measure high speed LTE networks. The tool
performance is verified against FTP throughput measurement with effect of
variation in constant bit rate UDP cross traffic and load on the server on end-
to-end measurements. The results from emulation and tests in a commercial
LTE network show that we can achieve available bandwidth estimations on
both the uplink and downlink in real time. This opens up wide possibility to
include various existing available bandwidth techniques and tools in mobile
application to be used over a wireless link. Further, possible suggestions to
achieve better available bandwidth estimations with native application devel-
opment has been proposed.
Contents

Preface i

Acknowledgement ii

Abstract iii

List of Figures & Tables vi

List of Abbreviations viii

1 Introduction 1
1.1 Bandwidth Related Metrics . . . . . . . . . . . . . . . . . . . . . 3
1.1.1 Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Available Bandwidth . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 Bulk Transfer Capacity (BTC) and TCP throughput . . . . 4
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Thesis Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . 9
1.6 Individual Contribution . . . . . . . . . . . . . . . . . . . . . . . 10
1.7 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Study Review 11
2.1 Available bandwidth estimation tools and techniques . . . . . . . 11
2.1.1 Probe Gap Model . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2 Probe Rate Model . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.3 Performance metrics . . . . . . . . . . . . . . . . . . . . . 16
2.2 LTE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.1 LTE Radio Interface Architecture . . . . . . . . . . . . . . 19
2.2.2 QoS Control in LTE . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Android OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Android supported API’s . . . . . . . . . . . . . . . . . . . 26
2.4 Measurement errors for available bandwidth estimation . . . . . . 30

iv
Contents

3 Two Way Measurement 32

3.1 Two Way Active Measurement Protocol [TWAMP] . . . . . . . . 32
3.1.1 Logical Model: . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.2 TWAMP Control: . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.3 TWAMP Test: . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 TWAMP Implementation: . . . . . . . . . . . . . . . . . . . . . . 34
3.3 TWAMP Light . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4 Architecture Implementation 36
4.1 Test Bed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 TWAMP Client: . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.2 TWAMP Server . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1.3 Cross traffic generator: . . . . . . . . . . . . . . . . . . . . 37
4.1.4 Multiple client Emulator . . . . . . . . . . . . . . . . . . . 37
4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Results 40

6 Conclusion and Future work 43

Bibliography 45

A Format of Test Packet 50

A.1 Test packet from the Session Sender . . . . . . . . . . . . . . . . 50
A.2 Test packet from the Session Reflector . . . . . . . . . . . . . . . 51

v
List of Figures & Tables

1.1 Ericsson: Traffic and Market Report June 2012 . . . . . . . . . . 2

1.2 End-to-end communication path . . . . . . . . . . . . . . . . . . 2
1.3 Narrow and Tight links in Multi-hop network . . . . . . . . . . . 3
1.4 Available bandwidth in an average timescale period . . . . . . . . 4
1.5 Available Bandwidth Estimation . . . . . . . . . . . . . . . . . . 6

2.1 PGM Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 PRM model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Stream Variation with One Way Delay . . . . . . . . . . . . . . . 16
2.4 Pathchirp train structure . . . . . . . . . . . . . . . . . . . . . . 16
2.5 LTE frame structure . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 The bearer and its associated QoS parameters . . . . . . . . . . . 22
2.7 Android OS Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.8 Android SDK flow . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.9 Android NDK flow . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.10 Android Renderscript Flow . . . . . . . . . . . . . . . . . . . . . 29
2.11 Android JNI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 TWAMP logic model . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.2 TWAMP Light model . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 TWAMP implementation with cross traffic . . . . . . . . . . . . . 36

4.2 TWAMP implementation with load on server . . . . . . . . . . . 38

5.1 Available bandwidth and FTP results with cross traffic in Mbps . 40
5.2 Available bandwidth estimation with load on server . . . . . . . . 41

A.1 Test packet from the Session Sender . . . . . . . . . . . . . . . . 50

A.2 Test packet from the Session Reflector . . . . . . . . . . . . . . . 51

vi
List of Abbreviations

AMBR Aggregate Maximum Bit Rate

APN Access Point Name
ARP Allocation and Retention Priority
BART Bandwidth Available in Real Time
BTC Bulk Transfer Capacity
CQI Channel Quality Indicator
DSCP Differentiated Services Code Point
EPC Evolved Packet Core
FDD Frequency Division Duplexing
GBR Guaranteed Bit Rate
IGI Initial Gap Increasing
IMS IP Multimedia Subsystem
LTE Long Term Evolution
MAC Medium Access control
MBR Maximum Bit Rate
MCS Modulation and Coding Scheme
MME Mobility Management Entity
OFDM Orthogonal Frequency Division Multiplexing
OFDMA Orthogonal Frequency Division Multiple Access
PCC Policy and Charging Control
PCRF Policy and Charging Rules Function
PDCP Packet Data Convergence Protocol
PDN Packet Data Network
PGM Probe Gap Model
PMI Pre-coder Matrix Indicator
PPTD Packet Pair/ Train Dispersion
PRB Physical Resource Block
PRM Probe Rate Model
PTR Packet Transmission Rate
QoS Quality of Service
RAN Radio Access Network
RI Rank Indicator
RLC Radio Link Control

viii
List of Figures & Tables

RRC Radio Resource Control

RSRP Reference Signal Received Power
SPRUCE Spread Pair Unused Capacity Estimate
TCP Transmission Control Protocol
TDD Time Division Duplexing
TOPP Train of Packet Pairs
TSG Technical Specifications Group
TWAMP Two Way Active Measurement Protocol
UDP User Datagram Protocol
VPS Variable Packet Size
3GPP Third Generation Partnership Project

ix
Chapter 1
Introduction

Long Term Evolution (LTE) also termed as 4G was introduced in 3GPP re-
lease 8 [2]. This release provides a significant development over existing 3G
UMTS/HSPA networks. The core development in LTE is the use of OFDM
based air interface and flat IP based network architecture for voice and data
traffic. Higher order modulation, larger bandwidth utilization and MIMO us-
age in LTE allows it to achieve asymmetric data rates of up to 100 Mbps
for downlink and 50 Mbps for uplink in user traffic. Support for both Time
Division Duplexing (TDD) and Frequency Division Duplexing (FDD) is pro-
vided and its usage is operator implementation specific. TDD has restrictions
for providing higher data rates due to scheduling pattern which gives prefer-
ence for FDD. Downlink radio link has been optimized for higher throughput
performance whereas the uplink is modified for better power management con-
sidering end-user device perspective.
There would be 5 billion mobile broadband subscriptions by end of year 2017 as
per predictions made by Ericsson [20] regarding the growth rate as illustrated
in figure 1.1. The growth of smart phones usage will increase from 700 million
(2011) to 3 billion (2017). As these devices gets under affordable price ranges,
we will see large penetration in its usage and subscription to mobile internet
usage. The driving force has been the development of dedicated hardware,
efficient mobile operating system and affordable prices for the smart phones
supporting high speed LTE networks.
Available bandwidth estimation is crucial for traffic engineering, QoS manage-
ment, multimedia streaming, server selection in application services, conges-
tion management and network capacity provisioning in wireless mobile net-
works. Available bandwidth measurement can be considered essential to en-
sure that the wireless mobile operators are living up to the standard of the
quality of service guaranteed by them while providing desired date rates to
the users. This can also be considered to compare the performance index of
various Telecom operators in a specific region. Various projects have been de-
veloped by time to measure the network performance metrics by looking into
various characteristics of the network. These studies involved in investigating

1
 Figure 1.1: Ericsson: Traffic and Market Report June 2012

the traffic modelling and characterization in a network and the network topol-
ogy for the end-to-end measurements. These key studies had lead researchers
to adopt these defined characteristics to develop new protocols and simulation
parameters.

Figure 1.2: End-to-end communication path

2
1.1. Bandwidth Related Metrics

1.1 Bandwidth Related Metrics

As shown in figure 1.2, an end-to-end communication path is a single route
that connects two end hosts through a set of communication links or hops
connected via network devices. In order to define bandwidth metrics for an
end-to-end path such as Capacity, Available bandwidth and Bulk Transfer Ca-
pacity (BTC), we need to consider an end-to-end communication path.

1.1.1 Capacity
For N links in a certain end-to-end path, capacity of a path is the maximum
possible IP layer rate the path can transfer from source to receiver. The capac-
ity of the link depends on the underlying transmission technology and prop-
agation medium. The following definitions related to capacity are discussed
below and shown in figure 1.3.

Figure 1.3: Narrow and Tight links in Multi-hop network

Link Capacity: Link capacity of a specified link is defined as maximum

amount of bits that can be transmitted per unit time.

Tight Link: The link with the minimum available bandwidth can be defined
as the tight link of the path. Available bandwidth is discussed in section 1.1.2.

Narrow Link: The link with minimum capacity which sets the upper bound
for the capacity of the whole network is called the narrow link of the path.

1.1.2 Available Bandwidth

End-to-end available bandwidth is a time varying metric ( Figure 1.4) which
can be defined as the minimum of all non-utilized link capacities throughout
the communication path for that given time interval. We can define as t

3
1.1. Bandwidth Related Metrics

averaging time-scale over which the available bandwidth estimate is provided.

The available bandwidth of a link depends on the underlying transmission
technology, propagation medium and traffic load on that link.

Figure 1.4: Available bandwidth in an average timescale period

1.1.3 Bulk Transfer Capacity (BTC) and TCP through-

put
A throughput of a TCP connection is essential but various factors affect TCP
throughput such as transfer size, parallel cross traffic (UDP or TCP), number
of established TCP connections, TCP socket buffer size at both ends or pos-
sibility of congestion along acknowledgement on reverse path. Further, router
buffer size, load and capacity of each link on the end-to-end path, initial win-
dow size also affects the TCP throughput measurements.
Bulk Transfer Capacity is defined as the maximum throughput which can be
obtained by a single TCP connection. It is different as compared to the avail-
able bandwidth measurement, as available bandwidth measurement does not
depend on specific transport protocol whereas it usually uses UDP. The results
for BTC measurements depend on how TCP shares the bandwidth with other
TCP flows. In case of available bandwidth measurement it assumes the cross
traffic to be constant and estimates the spare capacity on the link.
Capacity and available bandwidth estimation is done either for individual hops
or for end-to-end path. Variable Packet Size (VPS) probing techniques defined
in tools such as Pathchar [28] and Pchar [37]estimates capacity of individual
hops whereas tools such as CapProbe [32], nettimer [34], pathrate [17], sprobe
[48] come under Packet Pair/Train Dispersion (PPTD) technique. Tools such
as Pathload [29], IGI [24], pathChirp [45] measures end-to-end available band-
width. TReno [38],Cap [6] comes under BTC whereas achievable throughput
can be calculated by TTCP [54], Iperf [53], NetPerf [31].

4
1.2. Background

Measuring end-to-end available bandwidth in a LTE network can be a challeng-

ing task due to varying wireless channel conditions, scheduling & modulation
techniques, pre-configured QoS parameters as well as requirement of dedicated
hardware and underlying OS at both the end measurement points.The limita-
tions to accurate network performance measurements may be the air interface
as well as transport network. Considering the scare wireless resources it is
essential for available bandwidth estimation tools & techniques to be quick &
least intrusive.

1.2 Background
Available bandwidth measurement techniques can be classified into two broad
categories. One being passive estimation and the other being active probing.
Passive estimation is done on the basic of congestion situation, packet loss and
delay performance to estimate the available bandwidth. Active probing on
the other hand sends probe packets over a network to estimate the available
bandwidth. Due to efficiency and the reliability of estimations, active probing
is usually considered. Active probing further consists of probe gap or probe rate
models.
The probe gap model generates the estimate of available bandwidth by estima-
tion of cross traffic rate in the link. Tools developed following this technique
require the previous knowledge of the capacity of the network path to be mea-
sured. The working behind this probing technique is where the sender sends
pair of packets to the receiver. The pair packets are transmitted close enough
together in time for packets to queue together at bottleneck link. Measuring
the change in packet spacing, the receiver can make an estimate of amount of
cross traffic during the measurement time in the link.
The probe rate techniques operate on a basis of self induced congestion where
this mechanism sends stream of packets where the input rate of each stream
is varied either iteratively or exponentially. Here, the available bandwidth
is defined as the lowest input rate which overloads the network. The avail-
able bandwidth estimation in probe rate model does not consider the previous
knowledge of tight link capacity in the network. Each technique under probe
rate model or probe gap model has different probing techniques, levels of in-
trusiveness and estimation time.
Active probing techniques for both probe gap and probe rate models can be
classified into two phases to provide estimates of available bandwidth of the
network. The first phase defines sending probe packets in a selected man-
ner. To measure end-to-end available bandwidth we need to inject probing
packets in to the network so that we could sample it for that specific time.
The motive behind sending probing packets in selective manner is to not add
massive additional traffic on the network to be measured and get close to the
measurement of tight link. Any probe rate higher than the tight link capacity
shows delays within the probing packets crossing through that tight link. This

5
1.2. Background

suffered delay within the probing packets assists us to calculate the available
bandwidth.
There are various probing schemes existing. Initial ones consider probe pack-
ets arranged in multiple packet pairs as shown in 1.5 . This probing sequence
is defined by two parameters. One of them is Intra pair interval defined as
D t
in and the inter Pair interval . Train Of Packet Pairs(TOPP) follows the
D
concept of different parameters of in. Thirdly is to send train of N pack-
ets with varying probe rates and gap within each consecutive probe train.
Fourthly is the usage of sequence of exponentially spaced packets defined as
"Chirps"(Figure 2.4) where the train of packets is sent with increasing probing
rate within two consecutive probing packets.
These inter packet pair time separation may be negative, positive or zero as
D D
shown in Figure 1.5. A negative value ( out < in) occurs when the first
packet gets cross traffic packets in the queue followed by the second packet
D D
whereas a positive value ( out > in) occurs when the cross traffic packets
D
gets inserted between the probing packets pair in the queue. ( out = in) D
occurs when cross traffic has no effect on the inter packet separation.

Figure 1.5: Available Bandwidth Estimation

Further the second phase defines the analysis phase where the received probe
packets are analysed to estimate available bandwidth. The analysis is further
divided into 2 parts. It is either done by one way delay calculations of probe
packet train or packet dispersion of probing packets pairs. Various factors add
noise to the estimation which will be discussed later in chapter 2. To reduce
the factors adding some noise to the estimation, filters such as exponentially
weighted average, intersection filters or kalman filters have been used in some
of the tools.
Most of the available bandwidth measurement tools and techniques consider
available bandwidth measurement in one direction.To measure it on both up-
link and downlink, they need to be deployed on both of the end points with
an complex architecture with each end serving as client as well as server. As
the available bandwidth of uplink and downlink links are asymmetric, the
conventional way of sending packets in one way and then initiating a session

6
1.3. Related Work

on the other link without the knowledge of probe rate does not seem to be
a appropriate choice. This provides a complex architecture for the measure-
ment where the server also initiates a session towards the client for downlink
measurement providing a load on the server where it needs to handle various
clients.We further may need root access to the server to initiate a session. To
address this issue to analyse both the links on real time we propose a mech-
anism to estimate available bandwidth using Two Way Active Measurement
Protocol(TWAMP).

1.3 Related Work

The concept of ICMP ECHO to probe wired IP network paths for its bot-
tleneck link capacity and available bandwidth for round trip paths has been
proposed [14]. However it was not possible to detect the bottleneck link to
be either on the uplink or downlink path. Further, ICMP timestamps and
Traceroute concepts to estimate capacity and cross traffic volume of each link
of network path have also been utilized by some authors [47]. However, the
authors did not consider the existence of cross traffic in the link. Also, the as-
sumption of intermediate nodes along the uplink path and downlink path were
considered the same which are not feasible on real networks. Trace route allow
us to find the intermediate nodes from the source to server destination. Modi-
fied ping program was proposed with an application of packet trains to measure
available bandwidth with a developed tool named GNAPP [35]. It can iden-
tify several tight links along the path with individual available bandwidth. It
utilizes stage filtering and moving averages to provide better estimations. The
results calculated by the author show good accuracy under bursty traffic with
multiple tight links on the path.
It is essential to understand the properties and behaviours of end-to-end paths.
There lies a possibility of congestion in multiple links with probing packets
by all available bandwidth estimation tools and techniques using self-induced
congestion. Hence, individual available bandwidth for all congested links need
to be evaluated to estimate the available bandwidth of the network path. Some
tools such as Delphi [44], IGI/PTR [24], Pathload [29], and PathMon [33]
only estimate a network path with single tight link. MoSeab [57], TOPP
[39], PathChirp [45] can be applied to path with multiple tight link. MoSeab
estimates the available bandwidth of a network path to be measured in case
the available bandwidths of all tight links are the same. TOPP estimates
individual capacities of the congested links and estimates available bandwidth.
Pathchirp can also be applied to multiple tight links on a path while only
estimating available bandwidth of that path.
Various authors have evaluated the performance comparison of available band-
width estimation tools under various scenarios on a fixed IP networks [22]
[9] [3] [21]. In wired networks, available bandwidth may be defined as the
unused capacity of the tight link whereas in case of mobile networks, it is not

7
1.4. Thesis Objective

appropriate to define as such considering varying channel resources, schedul-

ing & modulation techniques, shared channel medium [7] and fading effects
on the wireless networks [23].The Assumption of First In First Out (FIFO)
for probe traffic in wired network is not applicable in the case of wireless mo-
bile networks as the packets can compete in parallel on the network. Cross
traffic available on the path can decrease the signal to noise ratio and can
share common queues along the path providing wrong estimates of the avail-
able bandwidth measurement. Probe packets may not be able to capture the
cross traffic in the network and performance of measurement tools can be af-
fected. In the case of the unused capacity being occupied by the probe traffic
at that moment, higher probe traffic rate may be re-accommodated by the
scheduling provided by mobile networks. Even the interference cross traffic
may re-accommodate in response to the new flow. The throughput capacity
of these networks is considered equal to data rate, mostly due to fluctuating
radio network conditions. For poor radio channel conditions with significant
bit error probability throughput decreases and hence lead to larger separation
within probe packets.Various analysis of Available bandwidth estimation on
802.11 wireless networks [30] [7] [8] [50] with facing challenges [58]and mo-
bile networks [15] [12] [42] have been conducted. Comparative and simulation
based studies on available bandwidth estimation techniques such as TOPP,
SLoPS and pathChirp over a mobile transport network has been concluded
with pathChirp outperforming TOPP and SLoPS technique in the terms of the
accuracy and efficiency [15]. Experiments for estimating available bandwidth
have been performed over commercial UMTS channel [12] to evaluate the ap-
plicability of available bandwidth measurement tools. Results show that it is
possible to achieve available bandwidth estimations in certain circumstances.
In LTE, scheduling and adaptive modulation modifies the data rates where
users are allotted resources according to the capacity which has dependency
on current traffic demand and hence affecting throughput. With an increase
in traffic rate by the user, the user may be allocated more resources with an
upper bound on the limit.
The objective of the thesis is to develop a real time non-intrusive and quick two
way available bandwidth probing mechanism using TWAMP. The implemen-
tation should consider the QoS and resource scheduling in LTE to effectively
produce accurate available bandwidth estimations.

1.4 Thesis Objective

The main objective of the thesis work is to disseminate and to connect knowl-
edge from three sectors, i.e. available bandwidth measurement tools and tech-
niques, Android development and LTE networks, while developing quick and
non-intrusive two way available bandwidth measurement tool to measure 4G
networks on Android OS based device. Here we consider the progress of In-
ternet Engineering Task Force IP Performance Metric (IETF IIPM) group
regarding TWAMP. The IETF is an open international community developing

8
1.5. Research Methodology

Internet standards. It consists of many work groups and the IP Performance

Metrics work group (IIPM) [40] is the one currently releasing standards for
metrics and methods used for network performance measurement.
Objectives of this research can be enlisted as follows:
• State of the art study: Literature review about available bandwidth mea-
surement tools and techniques, Android development, resource schedul-
ing and QoS parameters in LTE networks.
• Tool development and implementation: Select a suitable measurement
technique and develop a quick and non-intrusive two way measurement
tool for Android based OS considering LTE networks. It should consider
minimal power and network resources, providing rich datasets regarding
available bandwidth estimations and network related information.
• Application to 4G network measurement and tool verification: To con-
duct real world experiments and measurements while evaluating the de-
veloped measurement tool.

1.5 Research Methodology

The work has been carried over commercial 4G network testing and measure-
ments.Various sections of the thesis described below were carried over with
Agile development with scrum process.
ASCOM provided an problem description to estimate two way available band-
width using TWAMP. Initial study on probe rate/gap model with reference
materials related to BART [19] was provided. Sprint planning meetings were
conducted with ASCOM employees and internal supervisor from Luleå Uni-
versity of Technology to provide feedback on the thesis progress. Final presen-
tation of the work was carried out at Ascom and at the university. The thesis
makes following contribution which is described in the remaining chapters of
the thesis.

Identify study related work, state of the art, gaps, open research and
development challenges: Previous studies on comparison of various tools
used in the wired and wireless network under various network scenarios was
carried out. This study is unique as it provides an insight of the usefulness of
the tool development in Android OS while focussing on the resource scheduling
& QoS of 4G networks.

Define, design an implement two way end-to-end available band-

width estimation model: An Android OS based measurement tool and
associated Java based server development implementing TWAMP is accom-
plished. TWAMP logic model used has been discussed in chapter 3 with packet
format usage as described in the appendix.

9
1.6. Individual Contribution

Verification and validation of implemented model through real world

experiments and simulation: Experiments were conducted and the re-
sults were achieved on a real network measurement for two way end-to-end
measurement. Effect on end measurements with load on the server generated
from multi-client emulator is also calculated. These overall results generated
lead to conclusion, discussions and possible future work.

1.6 Individual Contribution

The initial study of related work, design test bed implementation have been
done together. The measurement tool development was carried out with in-
terpretation of achieved results. Whereas the measurement tool development
was divided within each individual. Harpal Singh looked into the development
of the Java based server and emulator and Saqlain Haider was in the role of
development of Android application. Android application development was
considered due to its wide popularity, being open source platform and possi-
bility to look into integration of developed available bandwidth measurement
tool into existing network measurement tool TEMS ™ POCKET developed by
Ascom. Development in Java has been considered due to its widespread usage,
ease of programming and its non dependency on the underlying OS platform.

1.7 Report Outline

The thesis work is categorized into seven chapters covering all aspects of the
research development process. Chapter one provides an introduction and sum-
mary to the work accomplished in the thesis. Chapter two explains about
various available bandwidth estimation tools and techniques, 4G network, An-
droid application development and factors affecting available bandwidth mea-
surement. Chapter three covers two way metrics measurement with TWAMP
to measure available bandwidth over a network path. Chapter four looks
into the test bed for the TWAMP architecture implementation and the end
points in the network. This forms the platform for the estimation of available
bandwidth. Chapter five presents the results achieved over real network with
injection of constant bit rate UDP cross traffic and load on the server. Chap-
ter six discusses and concludes the master thesis from studies performed from
Chapters two, three, four and five. Finally Chapter 7 indicates the future work
possible in this domain.

10
Chapter 2
Study Review

2.1 Available bandwidth estimation tools and

techniques
End-to-end available bandwidth active probing techniques as defined earlier
can be categorized in two ways: The probe gap model (PGM) and the probe
rate model (PRM). Looking into the PGM, it observes the packet pair disper-
sion to calculate the available bandwidth whereas the PRM looks into one way
delay in the probing packets.

2.1.1 Probe Gap Model

According to this model, the probing rate of the consecutive probing packets
pair is set to the capacity of the tight link so that it is larger than the available
bandwidth of the path. Hence the dispersion of the packet pairs is visible at
the tight link. The receiver can calculate the available bandwidth by the input
and the output rates of the probing packet pairs. A probe pair is sent with a
D D
time gap in and the time calculated at the receiver end is out as shown in
figure 2.1. With the assumption of single bottleneck and that the queue does
not become empty between the departure of the first probe in a pair till the
D
arrival of the second probe in pair, then out is defined as the time taken by
bottleneck for the transmission of second probe in pair and the cross traffic
D
that arrived during the in.
D
Hence the time for the transmission of cross traffic is defined as out - in. D
D D D
Further the rate of cross traffic is defined as ( ( out- in)/ in) * C where
the definition of C is known capacity of the bottleneck link. To estimate the
available bandwidth in the link, we determine the amount of cross traffic in
the link which is further subtracted from the known capacity of the tight link.
The packet pair is sent to the path at the rate of the bottleneck link capacity
C. The available bandwidth Ā is defined as follows:

Ā = C ∗ (1 − ) (2.1.1.1)

11
2.1. Available bandwidth estimation tools and techniques

e
Where C is the known capacity of the tight link, is strain and is defined as
follows:
∆out − ∆in
= (2.1.1.2)
∆in
Hence, in PGM it is assumed that the tight link is same as the narrow link i.e

Figure 2.1: PGM Model

bottleneck and follows FIFO model. Further PGM assumes that the capacity
of the link is known in advance so that it can further estimate the available
bandwidth. Tools such as Spruce [52] , Abing [41] and IGI [24] are based on
probe gap model.
Spruce considers Poisson technique by sending 1500-byte packet pairs as com-
pared to packet trains. This makes spruce a non-intrusive and effective method.
Considering the value of the initial gap this method ensures that the bottle-
neck queue does not become empty between the two probes in a pair. This
technique differentiates capacity measurement from the available bandwidth
measurement. Abing sends 40 back to back 1500 byte UDP packet pairs with
a determined separation of 50 ms. When these pass through the tight link,
probing packets can be separated by cross traffic in any place on this path.
Separation between the consecutive packets of the packet pair can happen even
if there is no congestion. Hence the time delays with those probing packet pairs
will be present due to the effect of the cross traffic along the path. The final
time delay between these packet pairs will have information of the amount of
cross traffic with different capacities. We can consider this as a load on the
path. Hence time delay is proportional to the load on the path. According to
this method, it consists of two components, Time delay initial (Tdinit) which
is same for all measurement and this is due to the narrow link . The other
to consider is Time delay variable(Tdvar) which reflects the queuing changes.
Hence final time delay between packet pairs may be defined as follows:-
T d = T dinit + T dvar (2.1.1.3)

Abing is similar to other probe gap model techniques, its uniqueness lies in the

12
2.1. Available bandwidth estimation tools and techniques

way it makes the estimate of cross traffic passing every link in the end-to-end
path to calculate the mean value for Td , available bandwidth and amount of
cross traffic in the path it measures.
IGI also uses the probe gap model. Two packet pair techniques were developed
by the authors to define available bandwidth. One was termed as IGI (Initial
Gap Increasing) and other defined as PTR (Packet Transmission Rate). Both
these algorithms send a sequence of packet trains to the destination with in-
crease in initial gap. The defined algorithms monitor the difference between
D D
average in and out gaps until the difference closes to zero. This is defined
as the turning point after which the narrow link gets overflown by the probing
packets. At this point IGI and PTR formula computes the available band-
width measurement. This is obtained by subtraction of estimated competing
traffic throughput from the capacity of the path measured by any capacity
estimation tool. IGI operates on finding initial probing gap (gB) where the
probing packet trains will interact with the cross traffic in the joint queuing
region as defined by the authors. gB is defined as a gap value of two back to
back probing packets on the bottleneck link.
Looking into tools based on probe gap models, initial probing packet selection
can reduce the accuracy of the tool as well as other factors such as probe packet
size selection and number of probe packets in a train. Small probing packets
can be sensitive to interference. Further sending too many packets can cause
queue overflow and packet loss. IGI suffers from accuracy in a multiple hop
environment with significant cross traffic following through the tight link. It
may also be unresponsive to variations in cross traffic flowing throwing through
the estimation path at high speeds of Gbps.

13
2.1. Available bandwidth estimation tools and techniques

2.1.2 Probe Rate Model

Probe rate model works on the concept of self-induced congestion. PRM does
not consider the capacity of the tight link in advance and does not assume that
narrow link is same with the tight link. In this situation the probe packets
are send in a train with an increasing rates and the end destination calculates
the average one way delay of the train. Here we try to find the turning point
as shown in figure 2.2 where the delay of the probe packets starts increasing.
Considering a train sent at a rate lower than the available bandwidth will see
similar delays. If an train is sent at a rate higher than the available bandwidth
the train of packets will suffer delays due to the existing cross traffic in the link
and delay will be observed within the train of packets. To define the available
bandwidth we probe the turning point where the one way delay initiates and
the train send rate is the available bandwidth measurement of an end-to-
end path.Tools like TOPP [39], Pathload [29], BART [19], pathChirp [45]and
SLoPS are based on the probe rate model.

Figure 2.2: PRM model

TOPP technique sends stream of packet pairs with uniform increase in input
rates in each iteration. The input rate is defined by making changes in the
input gap of each pair. The available bandwidth is defined here as the esti-
mation of maximum input rate which is not larger than the measurement rate
at the destination end. TOPP makes an estimate to measure available band-
width within a fixed range [Rmin, Rmax]. TOPP mechanism sends the packet
pairs with the gradual increase in rates from the source to the destination.
D
Considering the initial dispersion s for the packet pair sent from source to
the destination with probe packet of size L bytes, the rate of pair would be as
follows:-
Ro = L/∆s (2.1.2.1)

14
2.1. Available bandwidth estimation tools and techniques

In the scenario as shown in figure 2.3 where Ro is more than the available
bandwidth, second probe packet will get queued behind the first probe packet
and thus the measurement rate at receiver would be Rm < Ro. For the scenario
Ro< A , the packet pair arrival would be at the same rate Rm = Ro.
BART [19] stands for Bandwidth Available in Real Time which estimates
end-to-end available bandwidth over a network path. BART estimates the
bandwidth quasi continuously in real time. It works on the principle of self in-
duced congestion where it sends sequence of probe packet pairs at randomised
rates and samples the available bandwidth of the network. It generates very
low probe traffic rates in a network. BART uses the concept of Kalman fil-
tering for real time estimation of available bandwidth. A current estimate is
maintained which is incrementally improved with each new inter packet time
separation calculation in a sequence of probe packet pairs. BART can be tuned
for agility vs stability of the available bandwidth estimates.

Pathload operates on SLoPS technique to measure available bandwidth. In this

mechanism a stream of equally spaced packets are sent with input rate based
on a binary search. This mechanism provides a range in which the available
bandwidth lies rather than a single value of estimation. SLoPS works on binary
search with the feedback from destination to determine the next train input
rate. This methodology involves monitoring of variation in one way delays of
the probing packets. In case the stream rate R is greater than the available
bandwidth A of the measured path, then the stream will create a short term
overload in the queue of the tight link. In case the stream rate R is lower
than the available bandwidth A, the probing packets will pass through the
path without overloading the queue at the link. Hence in this mechanism
the sender analysis the one way delay and attempts to bring the stream rate
R close to available bandwidth with iterative algorithm.To obtain network
congestion we send periodic streams of packets with increasing bit rates. When
the trend visibility of increasing one way delay is found to be increasing we
can detect the congestion on the path and hence further analyse the available
bandwidth. This technique specifies a grey region where one way delay is not
clearly increasing or decreasing. It provides a range of variation of available
bandwidth.
PathChirp [45] sends stream of exponentially spaced packets termed as chirps
as shown in figure 2.4. Hence the instantaneous input rate changes within
a single train of packets. With this mechanism only one iteration is required
to get the estimation of available bandwidth as the network is probed with
different input rates in each stream. The source client schedules the probing
packets and the server at the other end receives the packets and analyses the
g
queuing delay of the packets. The spread factor sets the time gap within
the two packets in a chirp. The instantaneous rate within the two consecutive
packets can be defined as :
P P
Rk = = where k = 0, 1....K − 2 (2.1.2.2)
Tk δ γk

15
2.1. Available bandwidth estimation tools and techniques

Figure 2.3: Stream Variation with One Way Delay

here we define P as the packet size, δ as gap between the two closest packet of
the stream and Tk as instantaneous gap .
In this mechanism the instantaneous rate increases along the train of packets.
To estimate the available bandwidth we analyse the queuing delay. We see
an increase in queuing delay in case the instantaneous rate is higher than
the available bandwidth of the network path. Here we estimate the initial
instantaneous rate where we see the queuing delay. PathChirp with similarity
to Pathload uses information of relative one way delay of the probing packets.

Figure 2.4: Pathchirp train structure

There lies some benefits with the use of chirps in this mechanism as they use
(N-1) packets as compared to (2N-2) packets in TOPP. Further exponential
spacing within packets require only log(G2)-log(G1) packets for probing the
network over the range of [G1,G2] Mbps. PathChirp is able to capture delay
correlation information with the use of small number of probing packets which
packet pair mechanism cannot do.

2.1.3 Performance metrics

During the consideration of the tools for available bandwidth measurement in
mobile networks we may look into following four factors [46] :

16
2.2. LTE Overview

1. Estimation Error: First metric to be considered is the estimation error.

This is estimated with comparison of the available bandwidth estimation
with the real value under controlled test-bed. It is defined as a percentage
error.

2. Overhead: Overhead defines the number of probe packets required by

the tools to be forwarded on a network to make an estimate of avail-
able bandwidth. The definition of overhead is the percentage of traffic
generated by the tool with respect to the capacity of the tight link.

3. Estimation time: Estimation time can be considered as one important

factor for selection of the tool. Estimation time is how long the measure-
ment tool took to provide an estimate of the available bandwidth. It is
usually defined in number of seconds.

4. Reliability: Reliability may be defined as the robustness of the mea-

surement tool in providing the results. It is calculated by percentage
of tests for which the measurement tool was able to provide available
bandwidth estimation. Hence, to define a 100 % reliable measurement
tool is requirement of N trials to provide N estimations.
To define an ideal tool would be the one which provides accurate estimations,
less overhead, quick response time and 100 % reliability. Whereas there is no
mandatory requirement of ideal tools in all scenarios. The tool selection is
based on the application and the network environment.

2.2 LTE Overview

The mobile technology has evolved through times and further labelled into
generations. LTE is an initiative of Third Generation Partnership Project
(3GPP) release 8 which is mostly branded as 4G. However, the true evolution
comes with the progress work of 3GPP release 8 termed as LTE Advanced
under 3GPP release 10 . The concept merely lies here to support more devices
on IP based services. The whole LTE network is based around packet switched
services and was primarily developed to provide higher data rate services, lower
delay for interactive services and higher spectral efficiency to the user.
3GPP is the standard developing body that looks into the LTE /LTE-Advanced
specifications. It was also responsible for the standards of 3G UTRA and 2G
GSM systems. This group further has Technical Specifications Groups (TSGs)
that looks into various sub parts of the network architecture. Considering
3GPP, LTE Advanced may be defined as a major evolution in mobile technol-
ogy which will have a smooth transition from the current LTE release 8. LTE
supports peak data rates of 100 Mbps for downlink and 50 Mbps for uplink
traffic. The advanced antenna techniques and adaptive modulation & coding
with the usage of Orthogonal Frequency Division Multiple Access (OFDMA)
help LTE achieve significant throughput and spectral efficiency enhancement.

17
2.2. LTE Overview

Operators can have the benefit to transfer more data per MHz of spectrum
which allows them to have lower cost per bit. The distribution of functions for
radio access network between 3G RNC and NodeB is now simplified in LTE
with base station or evolved-NodeB (eNodeB). The eNodeB MAC sub layer is
responsible for scheduling transmission over both uplink and downlink. LTE
deploys OFDM and SC-FDMA for downlink and uplink transmission respec-
tively. OFDM allows support for both time and Frequency duplexing modes
(TDD & FDD). It relies on the rapid adaptation to channel conditions and
employs rate adaptation and hybrid soft combining techniques.
LTE architecture can be split into two parts, a radio access network and a core
network. Radio access networks is named as E-UTRAN and handles modula-
tion, compression and handover. The core network is named as Evolved Packet
Core(EPC) which looks into functions like charging and mobility management.
The EPC consists of Mobility Management Entity (MME), Serving Gateway,
Packet Data Network gateway (PDN) and Policy & Charging Rules Function
(PCRF). MME handles control plane functions which are related to subscriber
and session management. Serving Gateway is a routing node for other 3GPP
technologies and for packet flows towards E-UTRAN. PDN Gateway provides
the access to the external network and acts as a router. PCRF manages IP
Multimedia Subsystem(IMS) configuration of each subscriber and manages the
traffic flow.

Figure 2.5: LTE frame structure

18
2.2. LTE Overview

For data transmission LTE uses a frame of 10ms in length divided into 10
subframes in time domain of each 1 ms in length as shown in figure 2.5.
A subframe is divided into 2 slots in the time domain of 0.5 ms in length.
Each of this slot is divided into number of resource blocks in the slot. Each
resource block is 0.5 ms in length containing 12 sub-carriers from each of the
OFDM frequency domain. The channel bandwidth ranging from 1.25 MHz
till up to 20 MHz of LTE network defines the number of resource blocks in
symbol. The cyclic prefix being used defines the number of OFDM symbols
in a resource block. Group of resource blocks make a transport block having
common modulation/coding. To schedule transmission over an air interface
resource block is considered the main unit. Multiple UE’s can be addressed
in a single transport block where the MAC has the control of what to send
at particular time. Using OFDMA, users are allocated specific numbers of
physical resource blocks (PRBs) by the scheduler at eNodeB. Shared channel
transmission is utilized in LTE transmission scheme where the resources are
dynamically shared within the user terminals.

2.2.1 LTE Radio Interface Architecture

The LTE protocol stack consists of Medium Access Control(MAC), Radio
Link Control(RLC), Packet Data Convergence Protocol (PDCP) and Radio
Resource Control(RRC). The data on the downlink channel is transmitted
within the processing chain in the form of IP packets on one of the bearers
over the radio link. PDCP performs IP header compression, ciphering and
integrity protection of transmitted data of the radio interface. On the receiver
side it performs deciphering and decompression. RLC is responsible for seg-
mentation/concatenation, retransmission handling and in sequence delivery to
higher layer in protocol stack located in eNodeB. MAC handles uplink and
downlink scheduling, logical channel multiplexing as well as hybrid-ARQ re-
transmissions. The scheduling is located in eNodeB while the hybrid-ARQ
protocol is present in both eNodeB and the terminal. The MAC provides
services to RLC in the form of logical channels. A channel is defined on the
basis of type of information carried by it, classified as either control channel
utilized for information regarding transmission of control and configuration for
functioning of LTE systems or traffic channel for user data. Physical Layer
(PHY) handles coding/decoding, modulation and demodulation. It also han-
dles multi-antenna mapping. The physical layer provides services to MAC
layer in the form of transport channels. Definition of transport channel may
be considered as how and with what kind of characteristics, the information
has been transmitted over radio interface in LTE system. DL-SCH is the main
channel for data transmission in the downlink. On the control plane RRC
handles radio bearer set up, broadcasting of system information and active
mobility management. NAS protocol is assigned a functionality to deal with
idle mode mobility management and for the service set up.
Scheduler located at eNodeB is defined as the part of the MAC layer being

19
2.2. LTE Overview

responsible for scheduling of shared radio resource blocks for transmission over
the LTE air interface in both uplink and downlink channel and it also deter-
mines the data rate for each link. The data is transferred between the MAC
sub-layers in UE and eNodeB with the usage of constructed transport blocks.
Downlink and uplink shared transport channels (DL-SCH and UL-SCH) are
used for sending these transport blocks. In LTE, the scheduling decision is
possible at once very 1ms with the granularity in frequency domain being
180 kHz.Various scheduling algorithms are implemented for resource block al-
location such as Proportional Fair(PF), Maximum Throughput(MT), Round
Robin, Blind Equal Throughput (BET) or Even Resources (ER).
The downlink scheduler dynamically controls the terminal(s) to transmit to.
It controls the resource blocks upon which the user terminal’s DL-SCH should
be transmitted. The uplink scheduler dynamically controls the mobile ter-
minals who are ready to transmit on their UL-SCH and also defines which
uplink time/frequency resources are available. The uplink scheduling occurs
per mobile terminal and not per radio bearer. The channel-status reports indi-
cating the instantaneous channel quality both in time and frequency domains is
sent by mobile terminals for channel dependent scheduling typically for down-
link. A mobile terminal can also send buffer status information to eNodeB
using a MAC message to assist the uplink scheduler in decision making.The
channel-status report consists of Rank Indication (RI), Precoder Matrix Indi-
cation(PMI), Channel Quality Indication(CQI). The reporting can be either
periodic or a-periodic. Channel dependent scheduling allows to achieve gain
in system capacity.
Scheduling grants, if available to terminal forms the basis of scheduling decision
and provides the user terminal information about the resources available and
the associated transport format to use for the transmission on the UL-SCH.
Similar to the downlink scheduler, the uplink scheduler can retrieve informa-
tion regarding the buffer status, channel conditions and priorities of different
traffic flows. A scheduling request is defined as a flag raised by the terminal
for the request of uplink resources from uplink scheduler. On the reception of
the request the scheduler allots grant to the terminal. The scheduler utilizes
the following input for scheduling decision.

• Radio conditions existing at the UE side

• Buffer status reports

• QoS attributes

• Interference situation in neighbouring cells

2.2.2 QoS Control in LTE

QoS as standardized in 3GPP release 8 provides network operators and service
providers with a set of tools to initiate service and subscriber differentiation.

20
2.2. LTE Overview

It allows them to offer multiple services to the end users. Subscriber differenti-
ation allows service providers to differentiate subscribers for the same service.
It may be such as post or prepaid connections, corporate or private subscribers
and roaming services. LTE utilizes various techniques for radio resource man-
agement to maximize cell throughput while maintaining QoS and fairness for
users and the offered services. At a particular location, to analyse the QoS
experienced by the end user the measurements statistics are averaged over a
period of time. This may actually provide errors on the estimation. Drive
testing is the means of collection of data related to radio interface in different
locations of the cellular network coverage. A lot of information regarding the
signal strength, user throughput, delays due to traffic distribution and infor-
mation about call drops are analysed. Data collection can be categorized as
Instantaneous data collection and time averaged data collection. Instantaneous
data collection collects log information of throughputs values within the resolu-
tion of 1ms as for the Transmission Time Interval (TTI) providing information
for peak throughputs. Whereas these values are dependent on the resource al-
location and scheduling algorithm at the instant in the network. Hence Time
averaged data collection is based on time averaged sample values which are
smoothed for giving information for per TTI basis. These measurements for
various locations allow us to make information network maps.
Various radio measurements provide information on the QoS for the end user.
Main information is the Reference Signal Received Power (RSRP). It is essen-
tial for handover and cell selection procedure. RSRP which is a pilot mea-
surement, defined as a linear average over the power contributions (in W)
of the resource elements that carry cell-specific reference signals within the
considered measurement frequency band. Another radio measurement of user
throughput is Channel Quality Indicator (CQI) or the averaged CQI value for
the whole system bandwidth known as Wideband CQI. LTE defines 16 CQI
levels for different Modulation and Coding Schemes (MCS). WCQI can assist
us an indication for data rate supported by the system for the given channel
conditions. The bitrate per symbol rate obtainable in an LTE network depends
on the SINR for both the links. As discussed earlier CQI is signalled over the
radio interface which determines the coding rate based on modulation such as
QPSK, 16QAM, 64QAM and the amount of redundancy.
The bearer which is short for EPS bearer may be considered as the core element
of QoS in LTE. It identifies the packet flows between terminal and gateway that
receive a common QoS treatment as shown in figure 2.6. The packet filters in
terminal and gateway for uplink and downlink traffic respectively determines
the packet flows association with the bearer. Hence the packet flow which
is mapped to same bearer receives the same packet forwarding treatment(for
example, scheduling policy, queue management policy, rate shaping policy,
link layer configuration). Separate bearers are required for different packet
forwarding treatment. This allow differentiation of traffic in LTE with different
QoS requirements. The system reserves the resources according to the bearer
and associated signalling procedures before the transmission on packet flows

21
2.2. LTE Overview

Figure 2.6: The bearer and its associated QoS parameters

over the network with the assistance of admission control function. There is one
bearer for each combination of QoS class and IP address of the user terminal
and different ones for a terminal with different Access Point Names (APN).
For an end-to-end IP system, a tunnel header is attached which contains the
bearer identification allowing the network nodes to associate the packet with
correct QoS parameters. Classification of bearers can be done as follows:
GBR vs Non GBR Bearers: We can differentiate bearers in two kinds:
Guaranteed bit rate(GBR) and non guaranteed bit rate(non-GBR). Services
utilizing GBR do not confer congestion related packet loss whereas for services
with non-GBR can experience congestion related packet loss and are realized by
the admission control function. A GBR bearer reserves transmission resources
for itself in an admission control system when established. Whereas non-GBR
does not block transmission resources and remain established for long period
of time. An operators can define services with GBR bearers to provide better
user experience.
Default versus Dedicated bearers: A bearer can also be defined as a de-
fault bearer or an dedicated bearer. When an terminal attaches to a network
it is connected via a default bearer being associated with per terminal IP ad-
dress till existence of the network connection. The default bearer is considered
as a non-GBR bearer and its associated QoS is based on subscription data.
Different Dedicated bearers are required for packet flows flowing from same

22
2.2. LTE Overview

IP address of the terminal with different QoS parameters. A dedicated bearer

can be defined as a GBR bearer or an non-GBR bearer. PCRF looks into QoS
levels of the dedicated bearers. It defines mapping of specific packet flows to
dedicate bearers. For packets not associated with existing dedicated bearers
or drop of dedicated bearers, they are mapped to default bearers.

QoS Parameters
The QoS concept in EPS is class based where each of the bearer is assigned
only one QoS Class Identifier (QCI) by the network.
QCI is pre-configured by operators and is defined as a scaler used with the
access network as a reference to the node specific parameters which control
packet forwarding treatment on user plane. QCI standardization is to ensure
that the application or services mapped to the QCI receive similar minimum
level of QoS in multi-vendor network deployment and roaming services.
Allocation and retention priority(ARP) provides control plane treatment re-
lated to the set up and retention of the bearers and decide which bearer to be
released during resource limitations.
Maximum Bit Rate(MBR)and Guaranteed Bit Rate(GBR) are defined for GBR
bearers only. MBR is the bit rate that the bearer may not exceed. Whereas
GBR is the bit rate the network guarantees using admission control function.
Set up of MBR higher than GBR is set for future releases of 3GPP.
Aggregate Maximum Bit Rate (AMBR) allows operators to limit the total
amount of bit rate consumption by the subscriber and offer differentiated sub-
scriptions. 3GPP specifies two different AMBR parameters:

• APN-AMBR: This is definition for per subscriber and APN and its
knowledge is only to the gateway

• Terminal-AMBR: This is definition for per subscriber and its knowledge

is with gateway and RAN.

The AMBR definition is for the non-GBR bearers only and its different for
both the uplink and downlink with four definitions as UL APN-AMR, UL
terminal-AMBR. DL APN-AMR and DL terminal-AMBR.

QoS mechanism:
QoS mechanism in EPS can be defined as user plane functions or control-plane
signaling procedures.
Control-plane signalling Procedures: PCRF can issue policy and charging con-
trol (PCC) rules for the gateway. This can be used for new bearer estab-
lishment or modification of existing bearers which handles the packet flow.
UL/DL packet filters describe the packet flow.

23
2.2. LTE Overview

User Plane functions: User plane QoS functions are carried out by configura-
tion of network nodes on packet-flow-level functions, bearer-level functions or
DSCP-level functions.

• Packet-flow-level functions allows network node to manage the bit rate

assigned to the subscriber such as flat rate pricing plan.

• Bearer-level functions: Uplink and downlink packet filtering occurs at

terminal and gateway for mapping of packet flows onto intended bearers.
Limitation and control of the nodes by admission control and conges-
tion control can be implemented by the gateway and the RAN. The
rate policing also occurs at gateway and the RAN to protect network
from overloading and service assurance. Uplink and downlink scheduling
function is implemented by the LTE RAN to distribute Radio resources
which looks into fulfilment of QoS characteristics of bearers as well as
configuration of L1 & L2 protocols and error control protocols. QCI to
DSCP mapping function looks into traffic separation in transport net-
work for the transport form bearer level QoS (QCI) to transport level
QoS (DSCP). Gateway performs the mapping for downlink packets and
LTE RAN maps the uplink packets.

• DSCP-level functions:The transport network forwards each individual

packet based on the DSCP value with the implementation of the queue
management scheme and scheduling algorithm for both the uplink and
downlink traffic .

Network and Terminal initiated QoS Control

Dedicated bearer with a specific QoS can be established either by terminal
initiated or network initiated QoS control paradigms. In the network initi-
ated QoS control, the network looks into the initiation of signal which sets
up the dedicated bearer having specific QoS towards the terminal and RAN.
The client application is not required to be aware of QoS specification of the
access network although it has knowledge of the QoS. In a terminal initiated
QoS control paradigm, the signal to set up a dedicated bearer associated with
specific QoS is initiated by the terminal. The client application on the ter-
minal needs to be aware of the QoS model specifications of access networks
to specify the QoS information for the bearer. Network initiated QoS control
had advantages over terminal initiated QoS control to minimize the terminal
in QoS and policy control.

24
2.3. Android OS

2.3 Android OS
Google’s Android OS has gained a high market presence which includes mid-
dleware, key applications and software stack for the mobile devices. Android
OS is based on the modified version of Linux Kernel version 2.6 which sup-
ports core systems as security, memory management, drivers, process man-
agement and network stack. Google and the other members of Open handset
Alliance [4] have collaborated for Android’s development and release where as
Android Open Source Project (AOSP) [5] is the one for maintenance an further
development of Android. Open handset alliance is a group of various hard-
ware, software and telecom companies looking into the advancement of open
standards for mobile devices. The android OS distribution was released on 5
November 2007 with the foundation of Open Handset Alliance. The Android
code was released under the Apache License, a free software and open source
license. Android OS platform can be subdivide into following 5 layers as shown
in figure 2.7:

Figure 2.7: Android OS Layer

1. Application: Some of the core applications are on the top of the frame-
work which includes such as e-mail client, SMS app, Maps application,
Web browser, Contacts etc.

2. Application Framework: Application Framework acts a base for develop-

ment of applications in Android. The main components within the Ap-
plication Framework are the Activity manager, Window manager, Con-
tent providers, View system, Notification manager, Package manager,
Telephony manager, Resource Manager, Location Manager and XMPP
service.

25
2.3. Android OS

3. Libraries: Android contains a set of C/C++ libraries which are used by

various components of the Android System. The main core libraries de-
fine are Media framework, WebKit, SGL, OpenGL ES, FreeType, SQLite
etc. The developers can access them though the Android Application
Framework.

4. Android Runtime: Android OS includes a set of core libraries which

provide most of the functionality available in the core libraries of the
Java programming language. For every Android application it runs its
own instance of the Dalvik Virtual Machine. Parallel Virtual machines
can run in Dalvik. The .dex(Dalvik Executable) format are executed in
the Dalvik VM which is optimized for minimal CPU and memory usage.

5. Linux Kernel: Android operates on Linux Kernel version 2.6 for the core
system services. They include memory management, process manage-
ment, network stack, security and driver model. It also acts as a hard-
ware abstraction layer between the application and all the hardware.

Memory management is essential in smart phones due to memory constraints

in them. Hence it becomes essential to de-allocate memory allotted to objects
that are no longer required. This can be either taken care by the system or
the developer managing the memory allotment in the program code. Dalvik’s
Garbage Collector(GC) automatically provides the memory management sup-
port. Each process running on an Android device uses separate GC instance
and these collectors do not interfere with the instances of the other running
applications. Dalvik employs a type known as tracing GC and it utilizes mark
and sweep approach. In this type, the initial step is where the collector keeps
mark bits to indicate that a specific object is reachable and hence should not be
garbage collected. At the second phase, all the objects that had been marked
reachable are garbage collected. This algorithm comes with the advantage
to identify and collect garbage even in the presence of reference cycles. On
the other hand it has a disadvantage where the program execution must be
halted to run the algorithm. Android is a asynchronous system where multi-
ple events can be bound to multiple operations. Intents/Notifications/ Signals
can be considered to trigger life cycle state change. Each application launched
runs in its own Linux process with its own VM. Each application has its own
Linux user ID associated to it and the permissions set for the application is
just visible to that specific user or the application itself. Combination of both
mechanisms creates a sandbox which then prevents one application to interrupt
an other.

2.3.1 Android supported API’s

Android provides 3 sets of API namely SDK [27] with Java Support, NDK [25]
with native support and Renderscript support [26].

26
2.3. Android OS

Figure 2.8: Android SDK flow

Figure 2.9: Android NDK flow

27
2.3. Android OS

Android Software Development Kit(SDK) provides necessary tools and libraries

required by the programmers to create applications to be run on an Android
device using Java. The first SDK version was released on 12 December 2007
whereas the latest version currently released is SDK Tools, Revision 20.0.1
(July 2012). Java allows easy development of applications and it can be
portable to various platforms. Java has its own advantages such as language
level security and portability of programs developed in SDK being easily run
on different Android devices. The source code of the applications developed
using SDK is complied to bytecode on a developer machine as shown in fig-
ure 2.8. On the launch of the application developed, DalvikVM as an android
execution engine interprets the bytecode or it uses the JIT compiler for the
compilation of byte code into machine instructions and hence execute it.
Android Native Development Kit(NDK) is a tool set which provides usage of
native code in our Android application. Hence it allows the developers to
create and compile code in C/C++ for an Android platform. The first NDK
version was released on June 2009 and the latest version currently released is
Android NDK, Revision 8 (May 2012). Android NDK allows us to include
native code for performance critical parts of the application and the reuse of
code written in C/C++ language. In Android NDK as shown in figure 2.9, the
code developed is compiled into target machine code and it is then packaged
into .apk execution file. It has to be used with java code in order to run in
Android device. The native code developed is executed through the usage
of Java Native Interface(JNI) as shown in figure 2.11. Usage of native code
is restricted to use functionalities provided by Android. Hence usage of JNI
allows access to all functionalities through SDK API from the native code. For
NDK applications developed to be able to run over various CPU architecture,
the developer needs to develop and built different versions of native library for
target application binary interface.
Renderscript has been introduced since release of Android 3.0 to provide so-
lutions to performance problems seen in SDK with Java and also the porta-
bility issues with NDK with C/C++. It provides API for the functionality
and graphics on an Android device. C99 is adapted in Renderscript as the
base programming language. It operates close to the target architecture. It
has features of C language like flexibility for data manipulation and portabil-
ity over various android platforms. Whereas Renderscript application cannot
function alone without the usage of Android SDK code. The source code
written in Renderscript is complied by C99 frontend compiler slang with two
targets i.e. LLVM bitcode as the intermediate representation of the program
and with reflection Java class as glue layer between Android SDK Java code
and Renderscript code as shown in figure 2.10. SDK code uses the reflection
Java code to invoke Renderscript function, write Renderscript variables and
manage Renderscript memory allocation. The API for the computes part is
a subset of C99, while it adds vector type which allows to facilitate the array
or matrix computation. The graphics part in Renderscript is a wrapper of
OpenGL ES2.0.

28
2.3. Android OS

Figure 2.10: Android Renderscript Flow

Figure 2.11: Android JNI

Comparison and analysis for all the three sets of API with advantages and dis-
advantages with each programming model has been done [43]. Development
in SDK platform is quite easier whereas it has low performance as compared
to NDK and Renderscript. Hence it is not suitable for performance critical
applications. Whereas NDK provided better support for these kind of ap-
plications. An issue with NDK support is its portability to different kind of
microprocessor architecture such as ARM architecture or Intel based Android
devices. Renderscript on the other hand provides the best support over various
devices. Whereas looking into the memory allocation model, programming is
cumbersome and also it is difficult to port legacy code already existing. In
the SDK version the Java Thread API pool executer class is used whereas for

29
2.4. Measurement errors for available bandwidth estimation

the NDK version pthread API in bionic library is used. This improvement of
Android during multi threading can improve with dual core hardware support.
The Android NDK allows Android SDK to build programs in native code using
JNI. Hence Android NDK is an extension of Android SDK. There are advan-
tages an disadvantages to use native code in the application. It can enhance
the performance of the application whereas it may increase the complexity of
the application.
Benchmarking of the run time performance for various algorithms written in
Java and native code on real Android device has been done [36]. The experi-
ments performed shows that the native code runs up to 34.2 % times faster as
compared to algorithm which run on Dalvik VM . A majority of the Available
bandwidth estimation tools are written in C language for the Linux platform.
As Android OS is based on Linux platform, hence code reuse is possible on
the Android platform with the assistance of JNI function.

2.4 Measurement errors for available bandwidth

estimation
The available bandwidth estimation using PGM or PRM models could face
difficulties for the various reasons defined as follows:

• MOBILE DEVICE SYSTEM TIMINGS:

Accuracy of time stamping is essential in the sending procedure and
reception of probe packets over mobile device. Considering the time
stamping of the packets right before sending it through the socket is
actually different from when it is sent. Now further looking at the recep-
tion of the packets the time stamping on arrival may be different than
the original arrival time. The time errors on the mobile device has lot
of dependency on the underlying OS architecture and the access to the
socket layer.

• MOBILE DEVICE TIME RESOLUTION:

As we measure bandwidth at the range of 100 Mbps, the two consecutive
packets timings resolution must be at least defined in microseconds to
measure the tight link. Hence it is essential to have high time resolution
and accuracy at both the measurement ends points. The area of concern
is mobile device which has lower processing capabilities as compared to
the server side.

• CONTEXT SWITCHING:
Context switching can be defined as the procedure when an ongoing
process is abruptly suspended by the operating system to assign the
CPU to another process. This effect can lead to abrupt changes in the
gap time between the packets within the train. In the process of sending
a train of packets, each loop reads the system time as sending timestamp

30
2.4. Measurement errors for available bandwidth estimation

of that packet until the loop sends the whole train of packets. In case of
a context switch the time stamp for each packet will be unreliable.

• SYSTEM CALL DELAYS:

To access the system time and socket operation to send and receive pack-
ets takes time. This could add errors to the measurement and the overall
sending loop.

• END HOST THROUGHPUT:

The developed mobile application requires probing packets to be sent at
a specific rate. However usually the NIC achievable throughput is less
than the capacity defined for the NIC. This can be explained by average
computing power of the mobile device and the other end host. Whereas
considering the routers in the network, they have been designed to handle
such large throughput capacities.

• END-TO-END PATHOLOGIES:
The location of the destination end for the available bandwidth has an
important role. On a multi hop network the location and the link con-
nectivity to it has an dependency on the tight link capacity of the path.
We need to ensure that the location of the server does not become the
tight link capacity of the end-to-end network.

Along with these factors lies the errors associated to mobile network such as
fading, RSNR, scheduling & modulation profiles and resource sharing. Other
limitations possible with mobile networks can be wireless overheads, antenna
polarization & transmitting power limitations.

31
Chapter 3
Two Way Measurement

3.1 Two Way Active Measurement Protocol

[TWAMP]
The IETF’s IP Performance Metrics (IIPM) [40] work group looks in to the
definition of a Two Way Active Measurement Protocol (TWAMP) which is
defined in RFC 5357 [55]. This protocol can be considered as defining a flex-
ible method for measuring round trip IP performance between two devices
in a specified network which may be a wired IP network or a wireless net-
work supporting the TWAMP standard. Considering the deployment of the
TWAMP protocol in a desired network, various service providers can analyse
the IP performance of their end-to-end transport layer. With the assistance of
TWAMP, IT managers can efficiently measure the IP performance of the net-
work through co-operation within the network elements. The incorporation of
TWAMP into the devices for the capability to measure IP performance metrics
is what the service providers who manage large networks seeks. It can assist
the network operators to identify performance issues on the network. It works
on initiating a control session between two end points on a network using TCP
and thereafter sending a test session using UDP packets. These UDP packets
are generated by the client side and these are reflected by the server and on
reception at the client side assists in measuring IP performance statistics for
both uplink and downlink.
Measurement of network capacity can be quite complex considering various
factors of a network. Further additions to the complexity are to build and
use tools & techniques to perform those measurements. Looking into the
definition of the capacity is more over meaningful when defined relative to the
given protocol layer in the network. Moreover the capacity measurements are
estimates rather than an exact picture of the available values.
Two Way Active Measurement Protocol measures capacity metrics such as IP
type-P Available path capacity [RFC5136] [16], Tight Section Capacity (TSC)
[Y1540] [49] and UDP throughput in forward and reverse path links. TWAMP
extends the functionality of One Way Active Measurement Protocol (OWAMP)

32
3.1. Two Way Active Measurement Protocol [TWAMP]

[RFC4656] [51] which is used to measure one way metrics between the network
devices. With OWAMP one can measure one way metrics in both directions
between two network devices by using it bi-directionally. By doing so it does
not accommodate two way measurements. TWAMP defines value added octets
[11] which specifies behaviours of the session sender and the session reflector.
The server and control client agree on value added octets to be used during
the network performance measurement.

3.1.1 Logical Model:

Figure 3.1 shows the simplified logical model of TWAMP. The definition and
roles of entities in the architecture are as follows:
In the TWAMP architecture, session reflector and server are the names of same
entity. The session reflector has the functionality to create and send a mea-
surement train of packets on reception of the whole train of packets. Whereas
the session reflector does not do any calculations on the packets reception.
The server manages one or more TWAMP sessions and its implementation
is application specific. The server is able to manage multiple session from
various clients as well as from the same client. The session reflector uses the
mapping of packet to correct session based either on value added octets in the
field or based on IP. It can differentiate various test sessions with the use of
combination of source IP address, destination IP address, source UDP port
and destination UDP port. The Session Sender or the Control Client is the
end system which initiates requests for TWAMP Test Sessions. It is the one
responsible for initiation and termination of the Test sessions.

Figure 3.1: TWAMP logic model

Two way measurements can be considered beneficial as compared to one way

measurements as we do not need synchronization of clocks within the lo-
cal and remote host. TWAMP follows a similar architecture as that of the
OWAMP. TWAMP requires only two hosts to implements the architecture
with designated roles making it more attractive implementation as compared
to OWAMP. The TWAMP defines two inter related protocols: TWAMP Test
and TWAMP Control. TWAMP Control protocol is the one responsible to ini-
tiate, start and stop the test sessions whereas TWAMP Test protocol is used
for exchange of test packets within the two TWAMP entities.

33
3.2. TWAMP Implementation:

3.1.2 TWAMP Control:

The TWAMP control protocol allows the two end points to initialize a per-
formance monitoring session. The TWAMP architecture comprises of several
entities which are responsible for initialization of monitoring session and ex-
change of packets. Within the TWAMP control protocol, it defines a flexible
option to set up monitoring sessions and exchange information between trans-
mitting and receiving end. TWAMP follows the similar procedure for creation
of the test packets as in case of OWAMP. The set up procedure for session cre-
ation has been kept similar. The exchange of information takes place within
session sender and reflector concerning the address, port and security modes
for the operation.

3.1.3 TWAMP Test:

A lot of changes have been made in every proceeding draft regarding the
TWAMP Test packet for measurement of various performance metrics. TWAMP
test packet with value added octets is shown in the appendix. TWAMP logic
model simplifies the architecture as compared to the OWAMP. It follows sim-
ilar definition with the following exception where session reflector takes place
of a session receiver. The Session reflector has the capability to time stamp
the single packets of the whole train on arrival and thereafter store in a buffer
from the session sender till the last packet in train arrives. The session reflector
does not collect any packet information. After the reception of the last packet
in train, new train of packets similar to the received packet size are created
and send back to the sender with the time stamping when the packet leaves
the reflector. These packets on arrival at the sender side are time stamped
and collected until all the packets in the train are received. The session sender
further computes the two way metric information such as user throughput on
both links.

3.2 TWAMP Implementation:

Effective data collection mechanism to store information retrieved from raw
TWAMP test packets and a data analysis mechanism to process this raw data
to retrieve network metrics has been developed [56]. TWAMP has been utilized
for metrics measurements such as latency, packet loss, packet duplication and
packet reorder to measure the quality of IP networks [10]. The results achieved
were compared with other active measurement tools. Some companies have
implemented TWAMP in their existing products. The TWAMP Protocol has
been continuously evolving with major changes with various drafts available
whereas there is no open source implementation yet available.

34
3.3. TWAMP Light

3.3 TWAMP Light

TWAMP light is designed to help in implementing the standard for entities
which act as active responders to TWAMP controllers within the network,
thus enabling measurement of two way IP performance from anywhere in the
network. In this the role of control client, server and session sender are imple-
mented in one host which is referred as controller, whereas the role of session
reflector is implemented in another host which is referred as a responder as
shown in figure 3.2.

Figure 3.2: TWAMP Light model

This allows a simplified architecture where the roles will be simply to act as
a test point over a network. The controller establishes a test session with
the server through the non-standard means. After the establishment of the
session, the controller part of the network transmits the probe test packets
towards the responder. In the TWAMP Light the session reflector does not
necessarily have the knowledge of the session state. This eliminates the need
for the TWAMP control protocol and it gets with the assumption that the
session reflector is configured and communicates its configuration with the
server through non-standard means.

35
Chapter 4
Architecture Implementation

4.1 Test Bed

We develop a test bed(Figure 4.1) to measure end-to-end available bandwidth
on a real LTE network. An implementation of TWAMP for a two host sce-
nario consisting of a session sender and a session reflector is done. Available
bandwidth measurement tool developed for Android OS based devices acts
as a session sender by generating probe traffic. The server was developed in
Java to act as a Session reflector. The TWAMP Session Sender was targeted
towards an Android OS platform whereas the TWAMP server or the session
reflector was targeted towards a Windows machine.

Figure 4.1: TWAMP implementation with cross traffic

4.1.1 TWAMP Client:

We created an Android OS based available bandwidth measurement tool using
SDK which initiates the TWAMP session by generating UDP probe traffic
towards session reflector based on PRM model. The measurement tool takes
the address to the TWAMP Session reflector and a associated port number as
an input to exchange packets. The number of trains to be sent with the interval

36
4.1. Test Bed

time can be specified. The application receives the reflected train of packets
from the TWAMP server to compute the available bandwidth. The results are
displayed on a graph as well as stored in a log file. The graph displays the
values in Kbps for both uplink and downlink available bandwidth. Further
the log file generated shows the time stamp values of the transmission and
reception times of probe packets for both the session sender and reflector end.

The measurement tool utilizes Android’s telephony API to display network

type and connection state. It displays values such as RSSI, MCC, MNC, LAC
of the network we are currently connected to. A basic essential requirement to
create network maps is usage of geolocation services. Android’s location API
is utilized to associate the available bandwidth estimation to the measurement
location. The latitude and longitude values are displayed on screen as well as
added to the log file with associated available bandwidth estimation. Android
application installation and performance of test was done on Samsung Galaxy
SII LTE consisting of a Qualcomm Snapdragon S3 chipset fitted with a Dual
core 1.5 GHz Scorpion processor. It consists of 1 GB RAM with support for
LTE, HSDPA, HSUPA and HSPA+.

4.1.2 TWAMP Server

The TWAMP server created here is a Java based server application deployed on
Windows platform. It operates on port 15001 as defined in TWAMP standard
for exchanging TWAMP test packets. The server accepts incoming datagram
packets on this port from the various clients. The server receive a train of
packets from the client while timestamping on reception of packets and buffers
them until the last packet in the train is received. On reception of last packet
in train, it reflects back the whole train of packets with an interval as defined in
the received packet information. Hence the server merely acts as a reflector by
doing no calculations on the received train of packets as opposed to OWAMP.

4.1.3 Cross traffic generator:

To generate the cross traffic we used JPERF [13] which generates a Constant
Bit Rate(CBR) stream of either TCP or UDP packets. CBR UDP stream
was used for the experimentation. The traffic generated by the cross traffic
generator was fed on the wireless link by tethering a PC running JPERF to the
Android device. The traffic was generated on both the uplink and downlink,
however on the downlink JPERF was ran on the server itself.

4.1.4 Multiple client Emulator

We created a Java based emulator which generates probe packets similar to
PRM model utilized in our Android application for multiple users on a network.
The emulator on initiation creates multiple clients who generate probe traffic
towards the TWAMP session reflector as shown in figure 4.2.

37
4.2. Evaluation

Figure 4.2: TWAMP implementation with load on server

4.2 Evaluation
PRM model has been utilized for available bandwidth estimation where we do
not consider the initial knowledge of the tight link capacity. We define the
available bandwidth as the lowest input rate which overloads the network. We
calculate from the values either from the graph values or the log file gener-
ated at the Android phone to find the turning point to estimate the available
bandwidth.
We divided the experimental measurements in two parts:

1. Estimation of available bandwidth with cross traffic on the network

2. Estimation of available bandwidth with load on the server

The location of the measurement device was kept constant during the experi-
ment at Ascom premises. A FTP throughput measurement was initially done
to know the user throughput values and thereafter we ran our application. The
experimentation was repeated 5 times to have an average value. Thereafter,
experiments were ran with addition of CBR UDP cross traffic using JPERF
on another computer. The computer was tethered to the mobile device so that
we could send the cross traffic on the wireless link we intend to measure.
Timestamp resolution and accuracy is a concern to measure available band-
width on an Android and Windows OS while using Java. Java does not pro-
vide support for microsecond precision. Overall both the underlying OS of
end points do not provide timestamp accuracy in microsecond range required
for available bandwidth measurements. The most suggestive and accurate
approach is to provide a reliable external clock. NTP implementation for An-
droid and Windows OS seems a suitable option. Whereas to measure available
bandwidth we do not necessarily need time synchronization within the two

38
4.2. Evaluation

ends as the available bandwidth measurement works on one way packet train
delay calculation. Rather an accurate and stable time stamping is the main
requirement. Time stamping achieves better performance if done close to ker-
nel level. Our current implementation uses NTP. We initially will present the
results with various cross traffic values and its effects on measurements. Sec-
ondly we will see how the load on the server can effect the results achieved on
the mobile device where we run the TWAMP Session.
TEMS ™ POCKET :
TEMS ™ POCKET, developed by Ascom Network Testing is an industry
leading Android OS based tool which provides solution for wireless network
testing, troubleshooting and optimization on an Android device. It supports
major wireless technologies displaying current wireless network characteristics
and look into the cell coverage and capacity. To investigate the accuracy of
our results obtained, we compare it with the FTP throughput measurement
results using TEMS ™ POCKET on both links.

39
Chapter 5
Results

The achieved results on a commercial LTE network as shown in figure 5.1

provides the values of real time, two-way available bandwidth estimation on
an Android device using TWAMP. The results can be fetched either from the
graphical display or the log file generated and stored locally on the Android
device. Log file generated provides the NTP time stamp values of the received
probe packets. FTP throughput measurements on both links were carried
using TEMS ™ POCKET.

Figure 5.1: Available bandwidth and FTP results with cross traffic in Mbps

The results achieved using our measurement tool does not provide information
regarding existing cross traffic in commercial network. While the experiments
were run during a particular time of the day, an assumption is made for an
existence of constant cross traffic in the network. We compare our measure-
ment tool results with FTP throughput values where the FTP results provides
achievable throughput of the network being less than the theoretical capacity
of the LTE network. It is possible to run experiments to estimate available
bandwidth in LTE networks with existing measurement tools on a computer

40
 Figure 5.2: Available bandwidth estimation with load on server

tethered via LTE enabled phone or Dongle. However, as our thesis objective is
to consider the development and deployment of measurement tool for Android
OS based devices, existing tools for computers is not opted to measure avail-
able bandwidth on LTE networks. Existence of FTP sessions on the Android
device allows us to select it as a benchmarking option against our measure-
ment tool. Hence, consideration of variation in induced CBR UDP cross traffic
during available bandwidth measurements and FTP results is done to evaluate
the accuracy of our measurement tool.
Figure 5.1 shows the measurement tool performance comparison against FTP
throughput and effect of induced constant bit rate(CBR) UDP cross traffic
on end-to-end measurements. The findings show that the available bandwidth
estimates decrease linearly with the increase in injected CBR cross traffic. At
no cross traffic, we achieve 6 Mbps & 22 Mbps for available bandwidth esti-
mate and 10 Mbps & 35 Mbps for FTP throughput for uplink and downlink
respectively. FTP results show higher throughput values as compared to avail-
able bandwidth estimates by our measurement tool. Predominantly, usage of
Java for the measurement tool development restricts the tool to generate a
high probe traffic rate. Added errors to these measurements are system call
delays and NTP timestamping. NTP provides stable clock with high precision
and accuracy. However, Java Implementation of NTP does not permanently
change the system time in Android OS without root access and non-access
to socket layer timestamping. The results are however still prone to context
switching on the Android OS.
The available bandwidth measurement tool was tested for commercial 3G and
Wi-Fi network in Ascom premises and showed better results as compared to
LTE network. However, we did not consider the results obtained for the com-
parison purposes. An essential reason for better results was due to generation
of lower probe traffic rate to make available bandwidth estimates and less
time resolution requirements. Java and NTP timestamp was able to handle

41
measurements more accurately as compared to test done for LTE network.
A constant train of probe packets each of size 1440 Kb and specified differ-
ence between the next trains of packets was generated by the traffic emulator
on single port number 15001 as used in our measurement tool. We did not
consider TWAMP control protocol to establish an authenticated session. The
reception of the packets at the TWAMP receiver is implementation specific,
where we considered single port to accept all test sessions. As the TWAMP
server accepts probe packets from various clients on a singe port, it differen-
tiates them on the basis of sender IP address and sender discriminator. Our
traffic emulator generates probe traffic by differentiating clients on the basis
of sender discriminator and reception of reflected packets in the same order.
This feature also allows to run multiple test sessions on a single device.
Figure 5.2 depicts the results estimate by the measurement tool due to conges-
tion on the server with addition of multiple users connectivity to the TWAMP
server. Large amount of packet generation due to multiple clients showed
packet loss on reception at the Emulator. Hence we maintained smaller in-
creases in connections to the TWAMP server. The results show negative per-
centage decline in the result obtained by the measurement tool with added
number of simultaneous connections to the TWAMP server. The percent-
age change in measurements with added connections to the TWAMP server
are calculated with comparison with available bandwidth estimation obtained
with measurement tool due to single user connectivity to the TWAMP server
with no cross traffic. The negative decline in available bandwidth estimates is
predominantly due to access of all clients on a single TWAMP port. As the
probe packets get queued at the socket, it produces errors in the timestamps
values with system time delays and buffering of data at the port.

42
Chapter 6
Conclusion and Future work

We have developed a PRM based quick and non-intrusive two way available
bandwidth measurement tool using TWAMP to measure 4G networks on an
Android OS based device.
IETF IIPM aims to incorporate TWAMP as a measurement standard to mea-
sure available path capacity, tight section capacity and UDP throughput in
forward and reverse path links. Our work extends the study and applicability
of TWAMP for the deployment of available bandwidth tools and techniques.
TWAMP light utilized in this research work allows creating easy test end points
for the tool deployment. It allows possibility to generate probe traffic accord-
ingly for asymmetric uplink and downlink channel. The conclusion from the
thesis objective in section 1.4 has been addressed as follows:

• State of the art study: PRM for available bandwidth estimation in mo-
bile networks reduces estimation and reliability errors caused by bursty
traffic. Scheduling decision in LTE occurs once at every 1ms based on
existing radio conditions at UE, buffer status reports, QoS attributes
and interference situation in neighbouring cells. QoS attributes such as
MBR, ARP, AMBR with priorities for voice services utilizing GBR re-
strict the bit rate achieved by the generated probe packets. Android
NDK development using JNI allows enhanced performance over Android
SDK using Java whereas it brings increase in complexity of application
and non support for all microprocessor architecture.

• Tool development and implementation: The measurement tool develop-

ment is carried out in Java due to ease of programming and support
in all Android OS platform utilizing TWAMP logic model for two way
measurements. It consists of a Android application and a associates
server. The Android application provides network related information of
the network we are currently connected and a platform to run the tool
to measure available bandwidth. This measurement tool uses minimal
power and network resources making it possible to conduct multiple test

43
 sessions. It provides rich datasets with available bandwidth estimations
with associated geo-location values.

• Application to 4G network measurement and tool verification: The ex-

periments conducted and results achieved on a commercial LTE network
show ability of the measurement tool to make quick and non-intrusive
available bandwidth estimations. Comparison of achieved measurement
tool estimations with FTP throughput measurements on Android OS is
carried out using various cross traffic scenarios where FTP throughput
shows higher values. The measurement tool however shows linear vari-
ations with change in induced constant bit rate UDP cross traffic on
the network. FTP while being TCP based is considered due to lack of
available bandwidth estimation tools being ported over an Android OS.
Upper limit on measurement tool estimation is seen due to system call
delays by Java. Usage of NTP does provides a stable mobile device sys-
tem timings and resolution clock at application level. However, system
level timestamping will produce more accurate results. With load on the
TWAMP server due to multiple client sending probe packet to single port
affects the available bandwidth estimations due to buffer overload, packet
loss error and system call delays at server side. However in real world
scenario hosting of measurement tool on global servers shall limit the
parallel number of users accessing the server to run the measurements.

Due to short span of time for master thesis, native development of available
bandwidth measurement tool using Android NDK could not be considered.
Native development shall provide less system call delays with system level
timestamping and lower adjacent probe packet interval. Work needs to be ex-
tended regarding classification of parameters of competing users per transport
block, effect of SINR on varying scheduling and modulation decision happen-
ing in LTE per TTI of 1ms at eNodeB. Implementation work as defined in
3GPP User Equipment (UE) application layer data throughput performance
(TR 37.901) [1] for LTE gives an insight for test scenarios. Large Scale mea-
surement tool deployment based on TWAMP is possible on publicly available
servers such as M-LAB [18] supporting internet measurement transparency.
It shall allow publicly availability of rich user data sets for researchers being
essential for characterization of LTE traffic, creating network maps and traffic
policy.

44
Bibliography

[1] 3GPP TR 37.901. "user equipment (ue) application layer data throughput
performance". Ts, 3rd Generation Partnership Project (3GPP).

[2] 3GPP. "release 8". Technical report, 3rd Generation Partnership Project.

[3] A.A. Ali, F. Michaut, and F. Lepage. "end-to-end available bandwidth

measurement tools: A comparative evaluation of performances", 2007.

[4] O.H. Alliance. "industry leaders announce open platform for mobile de-
vices". Press release, 2007.

[5] O.H. Alliance. "android open source project", 2011.

[6] M. Allman. "measuring end-to-end bulk transfer capacity". In Proc. of the

1st ACM SIGCOMM Workshop on Internet Measurement, pages 139–143.
ACM, 2001.

[7] M.A. Alzate, J.C. Pagan, N.M. Pena, and M.A. Labrador. "end-to-end
bandwidth and available bandwidth estimation in multi-hop ieee 802.11
b ad hoc networks". In 42nd Annual Conference on Information Sciences
and Systems, CISS, pages 659–664. IEEE, 2008.

[8] A. Amamra and K.M. Hou. "available bandwidth estimation in wireless

ad hoc network: accuracy and probing time". In 11th IEEE International
Conference on Computational Science and Engineering, pages 379–387.
IEEE, 2008.

[9] L. Angrisani, S. D’Antonio, M. Esposito, and M. Vadursi. "techniques for

available bandwidth measurement in ip networks: a performance compar-
ison". Computer Networks, 50(3):332–349, 2006.

[10] I. Backstrom. "performance measurement of ip networks using the two-

way active measurement protocol". Master’s thesis.

[11] S. Baillargeon, C. Flinta, S. Ekelin, and A. Johnsson. "twamp value-added

octets". 2012.

45
Bibliography

[12] E. Bergfeldt, S. Ekelin, and J.M. Karlsson. "a performance study of band-
width measurement tools over mobile connections". In 69th Vehicular
Technology Conference, pages 1–5. IEEE, 2009.

[13] T Brethour and K Gibbs. Jperf version 1.0 the iperf front end. The Board
of Trustees of the University of Illinois, 2003.

[14] R.L. Carter and M.E. Crovella. "measuring bottleneck link speed in
packet-switched networks". In Journal of Performance evaluation, 27:297–
318, 1996.

[15] C.U. Castellanos, D.L. Villa, O.M. Teyeb, J. Elling, and J. Wigard. "com-
parison of available bandwidth estimation techniques in packet-switched
mobile networks". In 17th International Symposium on Personal, Indoor
and Mobile Radio Communications, pages 1–5. IEEE, 2006.

[16] P. Chimento and J. Ishac. "defining network capacity". 2008.

[17] C. Dovrolis and R. Prasad. "pathrate: A measurement tool for the capac-
ity of network paths", 2004.

[18] Constantine Dovrolis, Krishna Gummadi, Aleksandar Kuzmanovic, and

Sascha D Meinrath. "measurement lab: overview and an invitation to
the research community". ACM SIGCOMM Computer Communication
Review, 40(3):53–56, 2010.

[19] S. Ekelin, M. Nilsson, E. Hartikainen, A. Johnsson, J.E. Mangs, B. Me-

lander, and M. Bjorkman. "real-time measurement of end-to-end available
bandwidth using kalman filtering". In 10th IEEE/IFIP Network Opera-
tions and Management Symposium, pages 73–84. IEEE, 2006.

[20] June) Ericsson. (2012. "ericsson: Traffic and market report [ online].
available: http://www.ericsson.com/traffic-market-report.

[21] E. Goldoni and M. Schivi. "end-to-end available bandwidth estimation

tools, an experimental comparison". In Journal of Traffic Monitoring and
Analysis, pages 171–182, 2010.

[22] C.D. Guerrero and M.A. Labrador. "on the applicability of available band-
width estimation techniques and tools". In Journal of Computer Commu-
nications, 33(1):11–22, 2010.

[23] M. Haenggi. "a geometric interpretation of fading in wireless networks:

Theory and applications". In journal of Transactions on Information
Theory, 54(12):5500–5510, 2008.

[24] N. Hu and P. Steenkiste. "evaluation and characterization of available

bandwidth probing techniques". In IEEE Journal on Selected Areas in
Communications, 21(6):879–894, 2003.

46
Bibliography

[25] Google Inc. "android ndk", 2012.

[26] Google Inc. "android renderscript", 2012.

[27] Google Inc. "android sdk", 2012.

[28] V. Jacobson. "pathchar: A tool to infer characteristics of internet paths",

1997.

[29] M. Jain and C. Dovrolis. "pathload: A measurement tool for end-to-end

available bandwidth". In Proceedings of Passive and Active Measurements
(PAM) Workshop. Citeseer, 2002.

[30] A. Johnsson, B. Melander, and M. Bjorkman. "bandwidth measurement

in wireless networks". In Journal of Challenges in Ad Hoc Networking,
pages 89–98, 2006.

[31] R. Jones. "the netperf homepage", 2007.

[32] R. Kapoor, L.J. Chen, A. Nandan, M. Gerla, and MY. Sanadidi. "cap-
probe: a simple and accurate capacity estimation technique for wired
and wireless environments". In SIGMETRICS Performance Evaluation
Review, volume 32, pages 390–391. ACM, 2004.

[33] D. Kiwior, J. Kingston, and A. Spratt. "pathmon, a methodology

for determining available bandwidth over an unknown network". In
IEEE/Sarnoff Symposium on Advances in Wired and Wireless Commu-
nication, pages 27–30. IEEE, 2004.

[34] K. Lai and M. Baker. "nettimer: A tool for measuring bottleneck link
bandwidth". In Proc. of the USENIX Symposium on Internet Technologies
and Systems, volume 134, 2001.

[35] M. Li, Y.L. Wu, and C.R. Chang. "available bandwidth estimation for the
network paths with multiple tight links and bursty traffic". In Journal of
Network and Computer Applications, 2012.

[36] C.M. Lin, J.H. Lin, C.R. Dow, and C.M. Wen. "benchmark dalvik and
native code for android system". In Second International Conference on
Innovations in Bio-inspired Computing and Applications (IBICA), pages
320–323. IEEE, 2011.

[37] B.A. Mah. "pchar: A tool for measuring internet path characteristics",
2001.

[38] M. Mathis and M. Allman. "a framework for defining empirical bulk
transfer capacity metrics". Technical report, RFC 3148, July, 2001.

47
Bibliography

[39] B. Melander, M. Bjorkman, and P. Gunningberg. "a new end-to-end

probing and analysis method for estimating bandwidth bottlenecks". In
Global Telecommunications Conference(GLOBECOM ), volume 1, pages
415–420. IEEE, 2000.

[40] I.P.P. Metrics. "working group, ietf". Homepage: http://www. ietf.

org/html. charters/ippm-charter. html, 2010.

[41] J. Navratil and R.L. Cottrell. "abwe: A practical approach to available

bandwidth estimation". In Proc. of the 4th Passive and Active Measure-
ment Workshop. Citeseer, 2003.

[42] J.A. Negreira, J. Pereira, S. Perez, and P. Belzarena. "end-to-end mea-

surements over gprs-edge networks". In Proc. of the 4th international
IFIP/ACM Latin American conference on Networking, pages 121–131.
ACM, 2007.

[43] X. Qian, G. Zhu, and X.F. Li. "comparison and analysis of the three
programming models in google android".

[44] V. Ribeiro, M. Coates, R. Riedi, S. Sarvotham, B. Hendricks, and R. Bara-

niuk. "multifractal cross-traffic estimation". In Proc. of ITC specialist
seminar on IP traffic Measurement, 2000.

[45] V. Ribeiro, R. Riedi, R. Baraniuk, J. Navratil, and L. Cottrell. "pathchirp:

Efficient available bandwidth estimation for network paths". In Passive
and active measurement workshop, volume 4, 2003.

[46] C.G. Santander. "End-to-end available bandwidth estimation and moni-

toring". PhD thesis, University of South Florida, 1994.

[47] S. Sargento and R. Valadas. "capacity and cross-traffic estimation of

all links in a path using icmp timestamps". In International Confer-
ence on Networking, International Conference on Systems and Interna-
tional Conference on Mobile Communications and Learning Technologies.,
ICN/ICONS/MCL, pages 49–49. IEEE, 2006.

[48] S. Saroiu, P.K. Gummadi, and S.D. Gribble. "sprobe: A fast technique
for measuring bottleneck bandwidth in uncooperative environments". In
proc. of INFOCOM, page 1. IEEE, 2002.

[49] N. Seitz. "itu-t qos standards for ip-based networks". In Journal of Com-
munications Magazine, 41(6):82–89, 2003.

[50] S.H. et al. Shah. "available bandwidth estimation in ieee 802.11-based

wireless networks". In 1st Bandwidth Estimation Workshop (BEst), 2003.

[51] S. Shalunov, B. Teitelbaum, A. Karp, J. Boote, and M. Zekauskas. "rfc

4656: A one-way active measurement protocol (owamp)". Internet Engi-
neering Task Force, 2006.

48
Bibliography

[52] J. Strauss, D. Katabi, and F. Kaashoek. "a measurement study of avail-

able bandwidth estimation tools". In Proc. of the 3rd ACM SIGCOMM
conference on Internet measurement, pages 39–44. ACM, 2003.

[53] A. Tirumala, F. Qin, J. Dugan, J. Ferguson, and K. Gibbs. "iperf: The

tcp/udp bandwidth measurement tool". http://dast. nlanr. net/Projects,
2005.

[54] T. Utility. "test tcp (ttcp) benchmarking tool for measuring tcp and udp
performance", 2003.

[55] K. Yum, J.Z. Babiarz, K. Hedayat, R.M. Krzanowski, and A. Morton. "A
Two-Way Active Measurement Protocol (TWAMP)", 2008.

[56] B. Zhang, C. Zhang, B.H. He, and S. Liu. "design and implementation
of data collection and analysis based on twamp". In Journal of Applied
Mechanics and Materials, 148:254–257, 2012.

[57] M. Zhang, C. Luo, and J. Li. "estimating available bandwidth using mul-
tiple overloading streams". In IEEE International Conference on Com-
munications, volume 2, pages 495–502. IEEE, 2006.

[58] H. Zhao, S. Wang, D. Ma, and J. Wei. "challenges to estimate end-to-end

available bandwidth in ieee 802.11-based ad hoc networks". In Youth Con-
ference on Information, Computing and Telecommunication (YC-ICT),
pages 479–482. IEEE, 2009.

49
Appendix A
Format of Test Packet

This document shows the different test packets transmitted by TWAMP pro-
tocol in unauthenticated mode.

A.1 Test packet from the Session Sender

The below diagram shows the format of test packet transmitted by TWAMP
session sender. It contains 32 bit Packet sequence number, 64 bit timestamp,
32 bit error estimate of the synchronization and version of the test packets
used i.e either in unauthenticated, authenticated or encrypted mode. Further
it contains 32 bit sender discriminator, 32 bit last packet in train, 32 bit desired
reverse packet interval and optional packet padding of variable length.

Figure A.1: Test packet from the Session Sender

50
A.2. Test packet from the Session Reflector

A.2 Test packet from the Session Reflector

The below diagram shows the format of test packet transmitted by TWAMP
session reflector. It contains 32 bit Packet sequence number of packets gener-
ated by reflector, 64 bit timestamp of when the reflector transmits the packet,
32 bit error estimate of the synchronization and version of the test packets
used i.e either in unauthenticated, authenticated or encrypted mode, 32 bit
receive packet information and the packet information of the received packet.

Figure A.2: Test packet from the Session Reflector

51