Analysis and Performance Improvement of TCP during the Handover of LTE

Analysis and Performance Improvement of TCP during the Handover of LTE
Analysis and Performance Improvement
of TCP during the Handover of LTE
DAVIDE PACIFICO
Master’s Degree Project
Stockholm, Sweden 2009
Abstract
Within the Third Generation Partnership Project (3GPP), the new project entitled
Long Term Evolution (LTE) is going to be a new standard. LTE is characterized by a
broadband optimized radio access network, which focuses on supporting a high throughput with low latency by an ip based transport network. During the handover, which is
the procedure to disconnect a mobile user from a base station and connect it to another,
LTE supports the inter-base station packet forwarding to achieve a seamless transition.
However, given the mobility of the end users and the high bandwidth required, the
handover may cause sudden degradation of the throughput of the tcp connection if
the process is not correctly controlled. Moreover, during the handover, congestions
in the transport network could lead to a poor utilization of the transport and radio
resources available, and degrade significantly the user’s throughput.
The aim of this thesis project is to study the impact on the user throughput and
system performance when users with high bit rates tcp services are moving through
cells of the network, and to propose enhancing solutions to counteract to possible
throughput degradations.
First, we have implemented an accurate LTE simulator in the ns-2 . The simulator
implements the tunneling mechanism of LTE for the end users ip packets. It allows
us to switch the ip tunnel between the gateway and radio base station associated with
the moving mobile in the gateway towards the target base station when the terminal
arrives there. The simulator has then been used to investigate the performance of the
handover event during a tcp connection with focus on the data forwarding and the
router buffer dimension, and to propose two solutions to achieve a better end user
throughput. The first solution is based on a prediction technique that avoids data
forwarding, whereas the second solution acts in the transport network with an active
queue management. The simulation results show that the handover prediction could
increase the tcp performance and, second, that the router buffer dimension does matter
for the end user throughput in case of a congested transport network.
The project has been performed at the Automatic Control Lab at KTH in Stockholm and in collaboration with Ericsson Research Lab. The work is part of a joint
effort done with Matteo Pacifico. Further results are available in the master thesis
“Modeling and Performance Improvement of tcp over LTE Handover” [1].
i
Introduction
Long Term Evolution (LTE) is a project within the Third Generation Partnership Project to improve the UMTS mobile phone standard to cope with future
technology evolutions. Goals include improving spectral efficiency, lowering costs,
improving services, making use of new spectrum and reformed spectrum opportunities, and better integration with other open standards.
The data rate increase is due to the new LTE air interface based on Orthogonal
Frequency-Division Multiple Access (OFDMA) in the downlink and Single-carrier
Frequency Division Multiple Access (SC-FDMA) in the uplink that efficiently
supports multi-antenna technologies. The new architecture resulting from this
work is called Evolved Packet System.
Among the main characteristics of this “fourth generation (4G)” network we
find a new core network based on tcp/ip, the core protocol of the Internet on
which all kinds of traffic are routed, including voice. All higher level services built
on top of this so-called All ip Network (AIPN).
Since the 3rd generation wireless networks standardization, the packet data
services have assumed a crucial role for the owners of those networks. The bearer
service is the Internet access. Thus, there is a wide interest on the tcp application
behavior over this mobile network. Main problem of tcp over wireless networks
iii
Introduction
is that it has been designed for wired networks where packet losses are almost
negligible and where delays are mainly caused by congestion. On the contrary,
in wireless networks there are many causes which may seriously degrade the
achievable throughput of the tcp protocol.
During the handover, a window halving or a spurious timeout can occur due
to delay spikes or buffer overflow inside the core network. The consequences are
that tcp drops its transmission window resulting in degraded throughput.
The main goal of this work is to investigate the tcp performance during the
LTE handover procedure taking into account also the possibility of a congested
core network. The starting point is represented by [8] in which are stated the
achieved benefits thank to the user data forwarding.
The impact of LTE handover on user connection has been considered in [2],
where the average number of forwarded packets are estimated. However, the core
network status is not considered. Specifically, such a paper does not consider
the network extra load as a significant element, and suggests some scheduler
modification to mitigate the user throughput variation.
In Chapter 1 the Long Term Evolution concept and its main new features are
introduced, from the introduction of a new air interface to the physical and logical
channel structure and their mapping passing through the system architecture. In
the last section the intra-LTE handover procedure is introduced.
In Chapter 2 a tcp overview is reported, with particular reference to the
architecture and his congestion control algorithm. Some protocol option are also
described.
In Chapter 3 some solutions for the improvement of tcp performance during
iv
Introduction
the LTE handover are introduced. They can be divided in three categories:
forwarding avoidance, active queue management inside the core network, and
buffer size optimization.
In Chapter 4, by using the network simulator ns-2 and a framework called
nsMiracle, a comparative study of all the above solutions in an LTE handover
scenario is provided.
In Chapter 5, conclusions of the work are derived and some future work is
envisaged.
v
Contents
Abstract
i
Introduction
iii
Contents
vi
Abbreviations
xi
1 Long Term Evolution (LTE)
3
1.1
LTE performance . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.2
LTE concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.3
LTE architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
1.4
1.5
1.3.1
LTE protocol stack . . . . . . . . . . . . . . . . . . . . . .
11
1.3.2
OFDM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.3.3
Smart antenna technology . . . . . . . . . . . . . . . . . .
16
1.3.4
Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
1.3.5
Channel structure . . . . . . . . . . . . . . . . . . . . . . .
22
1.3.6
Mobility management
. . . . . . . . . . . . . . . . . . . .
25
LTE handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.4.1
LTE intra-access handover procedure . . . . . . . . . . . .
26
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
vii
Contents
2 TCP over LTE
2.1
31
Transmission Control Protocol . . . . . . . . . . . . . . . . . . . .
32
2.1.1
TCP congestion control . . . . . . . . . . . . . . . . . . .
33
2.1.2
Explicit Congestion Notification (ECN) . . . . . . . . . . .
37
2.1.3
Core network bottleneck . . . . . . . . . . . . . . . . . . .
38
2.2
Key parameters to evaluate TCP Performance . . . . . . . . . . .
42
2.3
Modeling of TCP during LTE handover . . . . . . . . . . . . . . .
43
2.3.1
. . . . . . . . . . . . . . . . . . . . .
46
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
2.4
Scenario description
3 Improving TCP performance during LTE handover
3.1
Forwarding avoidance . . . . . . . . . . . . . . . . . . . . . . . . .
49
3.1.1
cwnd variation during Handover . . . . . . . . . . . . . . .
50
3.1.2
Fast path switch . . . . . . . . . . . . . . . . . . . . . . .
56
3.1.3
Handover prediction . . . . . . . . . . . . . . . . . . . . .
57
AQM in the core network . . . . . . . . . . . . . . . . . . . . . .
58
3.2.1
Random Early Detection (RED) . . . . . . . . . . . . . . .
60
3.2.2
Cross-Network ECN . . . . . . . . . . . . . . . . . . . . .
61
3.3
Buffer dimension optimization . . . . . . . . . . . . . . . . . . . .
62
3.4
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
3.2
4 Simulations and results
65
4.1
Simulator: ns-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.2
Multi InteRfAce Cross Layer Extension . . . . . . . . . . . . . . .
67
4.2.1
nsMiracle inside LTE simulation . . . . . . . . . . . . . . .
69
Simulation scenario . . . . . . . . . . . . . . . . . . . . . . . . . .
71
4.3
viii
49
Contents
4.4
4.5
Experimental results . . . . . . . . . . . . . . . . . . . . . . . . .
72
4.4.1
Comparison between simulator and mathematical model .
73
4.4.2
Forwarding avoidance
. . . . . . . . . . . . . . . . . . . .
75
4.4.3
AQM in the core network . . . . . . . . . . . . . . . . . .
78
4.4.4
Buffer dimension optimization . . . . . . . . . . . . . . . .
79
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
5 Conclusions and future work
83
A Simulator extension
85
A.1 Modules used inside the simulator . . . . . . . . . . . . . . . . . .
85
A.1.1 Application layer . . . . . . . . . . . . . . . . . . . . . . .
85
A.1.2 Transport layer . . . . . . . . . . . . . . . . . . . . . . . .
86
A.1.3 Network layer . . . . . . . . . . . . . . . . . . . . . . . . .
87
A.1.4 Lower layer . . . . . . . . . . . . . . . . . . . . . . . . . .
87
A.2 Nodes overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
Bibliography
93
ix
Abbreviations
3GPP
AIPN
AM
AMC
AQM
ARQ
CDM
CN
CQI
CWR
DAE
DL
DSCP
ECE
ECN
EDGE
eNB
EPC
E-UTRA
E-UTRAN
FDD
FDM
FFT
GPRS
GSM
GTP
3rd Generation Partnership Project
All ip Network
Acknowledged Mode
Adaptive Modulation and Coding
Active Queue Management
Automatic Repeat Request
Code Division Multiplexing
Core Network
Channel Quality Information
Congestion Window Reduced
Differential Algebraic Equation
Downlink
Differentiated Services Code Point
ECN-echo
Explicit Congestion Notification
Enhanced Data rates for GSM Evolution
eNodeB
Evolved Packet Core
Evolved UMTS Terrestrial Radio Access
Evolved UMTS Terrestrial Radio Access Network
Frequency Division Duplex
Frequency Division Multiplexing
Fast Fourier Transform
General Packet Radio Service
Global System for Mobile communications
GPRS Tunneling Protocol
xi
Abbreviations
GW
HARQ
HO
HSPA
HSS
IFFT
IP
LTE
NAS
MAC
ME
MIMO
MISO
MME
MMOG
NAS
NRT
OFDM
PDCP
PDN
PDN GW
PHY
PLMN
QoS
RACH
RAN
RAT
RED
RLC
RNC
ROHC
RRC
RT
RTO
RS
xii
Gateway
Hybrid ARQ
Handover
High Speed Packet Access
Home Subscriber Server
Inverse FFT
Internet Protocol
Long Term Evolution
Non-Access Stratum
Medium Access Control
Mobile Equipment
Multiple Input Multiple Output
Multiple Input Single Output
Mobility Management Entity
Multimedia Online Gaming
Non-Access Stratum
Non Real Time
Orthogonal Frequency Division Multiplexing
Packet Data Convergence Protocol
Packet Data Network
Packet Data Network Gateway
Physical
Public Land Mobile Network
Quality of Services
Random Access Channel
Radio Access Network
Radio Access Technology
Random Early Discard
Radio Link Control
Radio Network Controller
Robust Header Compression
Radio Resource Control
Real Time
Retransmission Timeout
Reference Symbol
Abbreviations
RTT
SAE
SDU
SFN
SGW
SIMO
SISO
SNR
TA
TB
TDD
TDM
TEID
TM
TCP
TOS
TTI
UE
UL
UM
UMTS
VoIP
WCDMA
WFQ
Round Trip Time
System Architecture Evolution
Service Data Unit
Single Frequency Network
Serving Gateway
Single Input Multiple Output
Single Input Single Output
Signal-to-Noise Ratio
Tracking Area
Transport Block
Time Division Duplex
Time Division Multiplexing
Tunnel Endpoint Identifier
Transparent Mode
Transport Control Protocol
Type Of Service
Transmission Time Interval
User Equipment
Uplink
Unacknowledged Mode
Universal Mobile Telecommunications System
Voice over ip
Wireless Coded Division Multiple Access
Weighted Fair Queue
xiii
Chapter 1
Long Term Evolution (LTE)
The recent increase of mobile data usage and emergence of new applications
such as Multimedia Online Gaming (MMOG), mobile TV, Web 2.0, streaming contents have motivated the 3rd Generation Partnership Project (3GPP) to
work on the Long Term Evolution (LTE). LTE is the latest standard in the
mobile network technology tree that previously realized the GSM/EDGE and
UMTS/HSxPA network technologies that now account for over 85% of all mobile subscribers. LTE will ensure 3GPP’s competitive edge over other cellular
technologies.
LTE, whose radio access is called Evolved UMTS Terrestrial Radio Access
Network (E-UTRAN), is expected to improve substantially end-user throughput,
sector capacity and reduce user plane latency, bringing significantly improved
user experience with full mobility. With the emergence of Internet Protocol (ip)
as the protocol of choice for carrying all types of traffic, LTE is scheduled to
provide support for ip-based traffic with end-to-end Quality of service (QoS).
Voice traffic will be supported mainly as Voice over ip (VoIP), which will enable
better integration with other multimedia services. Initial deployments of LTE are
3
1. Long Term Evolution (LTE)
expected by 2010 and commercial availability on a larger scale 1-2 years later.
Unlike High Speed Packet Access (HSPA), which was accommodated within
the Release 99 UMTS architecture, 3GPP is specifying a new Packet Core, the
Evolved Packet Core (EPC) network architecture to support the E-UTRAN
through a reduction in the number of network elements, simpler functionality, improved redundancy but most importantly allowing for connections and handover
to other fixed line and wireless access technologies, giving the service providers
the ability to deliver a seamless mobility experience.
LTE will give high throughput by relaying on physical layer technologies, such
as, Orthogonal Frequency Division Multiplexing (OFDM) and Multiple-Input
Multiple-Output (MIMO) systems, Smart Antennas to achieve these targets. The
main objectives of LTE are the minimization of the system and User Equipment
(UE) complexities, flexible spectrum deployment in existing or new frequency
spectrum, and co-existence with other 3GPP Radio Access Technologies (RATs).
1.1
LTE performance
E-UTRA is expected to support different types of services including web
browsing, FTP, video streaming, VoIP, online gaming, real time video, pushto-talk and push-to-view. Therefore, LTE is being designed to be a high data
rate and low latency system as indicated by the key performance criteria shown
in Table 1.1.1. The bandwidth capability of a UE is expected to be 20MHz for
both transmission and reception. The service provider can however deploy cells
with any of the bandwidths listed in the table. This gives flexibility to the service
providers to tailor their offering dependent on the amount of available spectrum
4
LTE concept 1.2
or the ability to start with limited spectrum for lower upfront cost and grow the
spectrum for extra capacity.
Metric
Peak data rate
Mobility support
Requirement
DL: 100 M b/s
UL: 50 M b/s
(for 20 M Hz spectrum)
Up to 500 km/h but optimized
for low speeds from 0 to 15 km/h
< 100 ms (for idle to active)
Control plane latency
(Transition time to active state)
User plane latency
< 5 ms
Control plane capacity
> 200 users per cell
(for 5 M Hz spectrum)
Coverage (Cell sizes)
5-100 km with slight
degradation after 30 km
Spectrum flexibility
1.25, 2.5, 5, 20 M Hz
Table 1.1.1. LTE performance goal.
1.2
LTE concept
The requirements set for LTE are divided into the following categories [10]:
• Capabilities
• System performance
• Deployment-related aspects
• Architecture and migration
• Radio resource management
5
1. Long Term Evolution (LTE)
• Complexity
• General aspects
Capabilities
100 M b/s are the target for downlink and 50 M b/s for uplink when operating
in 20 M Hz spectrum allocation. Thus, the requirements can be expressed as 5
bit/s/Hz for the downlink and 2.5 bit/s/Hz for uplink.
There are two latency requirements: control-plane requirements and userplane requirements. The control-plane latency requirements address the delay
for transiting from different non-active terminal states to an active state. The
user-plane latency requirement is expressed as the time it takes to transmit a
small ip packet from the terminal to the RAN edge node or vice versa measured
on the ip layer.
System performance
The LTE system performance design targets user throughput, spectrum efficiency, mobility and coverage. The first two are summarized in Table 1.2.2
Performance measure
Downlink target
relative to baseline
3x-4x
Average user throughput
(per M Hz)
Cell-edge user throughput 2x-3x
(per M Hz, 5th percentile)
Spectrum efficiency
3x-4x
(bit/s/Hz/cell)
Uplink target
relative to baseline
2x-3x
2x-3x
2x-3x
Table 1.2.2. LTE user throughput and spectrum efficiency requirements.
6
LTE concept 1.2
The mobility requirements focus on the mobile terminals speed. The best
requirements are set for a speed up to 15 km/h; for speeds up to 120 km/h there
should be high performance, and for a speed above 120 km/h the system should
be able to keep the connection. The maximum speed allowed is set to 350 km/h
or 500 km/h depending on the frequency band.
The coverage requirements focus on the cell range. The cells up to 5 km of
radius allow non-interference-limited scenarios; for cells range up to 30 km, a
slight performances degradation are tolerated and cell ranges up to 100 km are
not precluded but no performance requirements are stated yet.
Deployment-related aspects
The requirement on the deployment scenario includes both the case when the
LTE system is deployed as a stand-alone system and the case when it is deployed
together with WCDMA/HSPA and/or GSM. For mobile terminals supporting
those technologies. Table 1.2.3 lists the interruption requirements, that is, the
longest acceptable interruption in the radio link when moving between the different radio access technologies, for both real-time and non-real-time services.
Non-real-time (ms) Real-time (ms)
relative to baseline relative to baseline
LTE to WCDMA 500
300
LTE to GSM
500
300
Table 1.2.3. Interruption time requirements, LTE-GSM and LTE-WCDMA.
LTE supports a spectrum flexibility by working in the IMT-200 frequency
bands with Frequency Division Duplex (FDD), and Time Division (TDD) (Fig-
7
1. Long Term Evolution (LTE)
ure 1.2.1).
TDD-Based radio access
FDD-Based radio access
Uplink
1900
1920
Downlink
1980
2010
2025
2110
2170
Frequency (MHz)
Figure 1.2.1. FDD and TDD operating bands.
Architecture and migration
The LTE RAN architecture should be packet based (and also support realtime class traffic), simplify and minimize the interface, support an end-to-end
QoS and designed to minimize the jitter (for example, for tcp/ip traffic type
[10]).
Radio resource management
The radio resource management requirements are divided into enhanced support for end-to-end QoS, efficient support for transmission of higher layers, and
support of load sharing and policy management across different radio access technologies.
Complexity and general aspects
LTE complexity requirements imply that the number of options should be
minimized. This has an impact also on the cost and service related aspects and,
specific to the cost, it is desirable to minimize it maintaining desired performance.
8
LTE architecture 1.3
1.3
LTE architecture
The architecture consists of the following functional elements:
Evolved Radio Access Network (RAN)
The evolved RAN for LTE consists of a single node, i.e., the eNodeB (eNB)
that interfaces with the UE. The eNB hosts the PHYsical (PHY), Medium Access
Control (MAC), Radio Link Control (RLC), and Packet Data Control Protocol
(PDCP) layers that include the functionality of user-plane header compression
and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs functions as radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell
information broadcast, ciphering/deciphering of user and control plane data, and
compression/decompression of DL/UL user plane packet headers.
Serving Gateway (SGW)
The SGW routes and forwards user data packets, while also acting as the
mobility anchor for the user plane during inter-eNB handovers and as the anchor
for mobility between LTE and other 3GPP technologies (terminating S4 interface
[9] and relaying the traffic between 2G/3G systems and Packet Data Network
Gateway, PDN GW). For idle state UEs, the SGW terminates the DL data path
and triggers paging when DL data arrives for the UE. It manages and stores
UE contexts, e.g. parameters of the ip bearer service, network internal routing
information. It also performs replication of the user traffic in case of lawful
interception.
9
1. Long Term Evolution (LTE)
User Plane
App
TCP
IP
IP
PDCP
PDCP
GTP
GTP
RLC/MAC
RLC/MAC
UDP/IP
UDP/IP
PHY
PHY
L1
L1
S-GW
S1-UP
eNodeB
S1-CP
ME
IP transport
network
MME
Control Plane
X2
NAS
NAS
RRC
RRC
S1-AP
S1-AP
PDCP
PDCP
SCTP
SCTP
RLC/MAC
RLC/MAC
IP
IP
PHY
PHY
L1
L1
Figure 1.3.1. LTE architecture.
10
LTE architecture 1.3
Mobility Management Entity (MME)
The MME is the key control-node for the LTE access network. It is responsible for idle mode UE tracking and paging procedure including retransmissions.
It is involved in the bearer activation/deactivation process and is also responsible
for choosing the SGW for a UE at the initial attach and at time of intra-LTE
handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the Home Subscriber Server, HSS). The
Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs. It checks
the authorization of the UE to camp on the service provider’s Public Land Mobile
Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling
and handles the security key management. Lawful interception of signaling is also
supported by the MME. The MME also provides the control plane function for
mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface
towards the home HSS for roaming UEs.
1.3.1
LTE protocol stack
In this section, we describe the functions of the different protocol layers and
their location in the LTE architecture. In Figure 1.3.1, the NAS protocol, which
runs between the MME and the UE, is used for control-purposes such as network
attach, authentication, setting up of bearers, and mobility management. All NAS
messages are ciphered and integrity protected by the MME and UE. The RRC
11
1. Long Term Evolution (LTE)
layer in the eNB makes handover decisions based on neighbor cell measurements
sent by the UE, pages for the UEs over the air, broadcasts system information,
controls UE measurement reporting such as the periodicity of Channel Quality
Information (CQI) reports and allocates cell-level temporary identifiers to active
UEs. It also executes transfer of UE context from the Source eNB to the Target
eNB during handover, and does integrity protection of RRC messages. The RRC
layer is responsible for the setting up and maintenance of radio bearers.
In the user-plane, the PDCP layer is responsible for compressing/decompressing the headers of user plane ip packets using Robust Header Compression
(ROHC) to enable efficient use of air interface bandwidth. This layer also performs ciphering of both user plane and control plane data. Because the NAS
messages are carried in RRC, they are effectively double ciphered and integrity
protected, once at the MME and again at the eNB.
The RLC layer is used to format and transport traffic between the UE and the
eNB. RLC provides three different reliability modes for data transport: Acknowledged Mode (AM), Unacknowledged Mode (UM), or Transparent Mode (TM).
The UM mode is suitable for transport of Real Time (RT) services because such
services are delay sensitive and cannot wait for retransmissions. The AM mode,
on the other hand, is appropriate for non-RT (NRT) services such as file downloads. The TM mode is used when the PDU sizes are known a priori such as for
broadcasting system information. The RLC layer also provides in-sequence delivery of Service Data Units (SDUs) to the upper layers and eliminates duplicate
SDUs from being delivered to the upper layers. It may also segment the SDUs
depending on the radio conditions.
12
LTE architecture 1.3
Furthermore, there are two levels of re-transmissions for providing reliability,
namely, the Hybrid Automatic Repeat reQuest (HARQ) at the MAC layer and
outer ARQ at the RLC layer. The outer ARQ is required to handle residual errors
that are not corrected by HARQ that is kept simple by the use of a single bit
error-feedback mechanism. An N-process stop-and-wait HARQ is employed that
has asynchronous re-transmissions in the DL and synchronous re-transmissions
in the UL. Synchronous HARQ means that the re-transmissions of HARQ blocks
occur at pre-defined periodic intervals, hence, no explicit signaling is required to
indicate to the receiver the retransmission schedule. Asynchronous HARQ offers
the flexibility of scheduling re-transmissions based on air interface conditions. The
PDCP, RLC and MAC layers together constitute layer 2 (shown in Figure 1.3.2).
Radio Bearers
ROCH
ROCH
ROCH
ROCH
Security
Security
Security
Security
Segm.
ARQ
Segm.
Segm.
Segm.
ARQ
ARQ
ARQ
PDCP
RLC
BCCH
PCCH
Logical Channels
Scheduling / Priority Handling
MAC
Multiplexing UE1
Multiplexing UEn
HARQ
HARQ
Transport Channels
Figure 1.3.2. Layer 2 structure for Downlink.
The physical layer at the eNB is responsible for protecting data against channel errors using adaptive modulation and coding (AMC) schemes based on channel conditions. It also maintains frequency and time synchronization and performs RF processing including modulation and demodulation. In addition, it
13
1. Long Term Evolution (LTE)
processes measurement reports from the UE such as CQI and provides indications to the upper layers. The minimum unit of scheduling is a time-frequency
block corresponding to one sub-frame (1ms) and 12 sub-carriers. The scheduling
is not done at a sub-carrier granularity in order to limit the control signaling.
QPSK, 16QAM and 64QAM will be the DL and UL modulation schemes in EUTRA. For UL, 64-QAM is optional at the UE. Multiple antennas at the UE are
supported with the 2 receive and 1 transmit antenna configuration being mandatory. MIMO (multiple input multiple output) is also supported at the eNB with
two transmit antennas being the baseline configuration. Orthogonal Frequency
Division Multiple Access (OFDMA) with a sub-carrier spacing of 15 kHz and Single Carrier Frequency Division Multiple Access (SC-FDMA) have been chosen as
the transmission schemes for the DL and UL, respectively. Each radio frame is
10ms long containing 10 sub-frames with each sub-frame capable of carrying 14
OFDM symbols. For more details on these access schemes, refer to [6].
1.3.2
OFDM
In the downlink, OFDM is selected to meet efficiently E-UTRA performance
requirements. With OFDM, it is straightforward to exploit frequency selectivity
of the multi-path channel with low complexity receivers. This allows frequency selective in addition to frequency diverse scheduling and one cell reuse of available
bandwidth. Furthermore, due to its frequency domain nature, OFDM enables
flexible bandwidth operation with low complexity. Smart antenna technologies
are also easier to support with OFDM, since each sub-carrier becomes flat faded
and the antenna weights can be optimized on a per sub-carrier (or block of sub-
14
LTE architecture 1.3
carriers) basis. In addition, OFDM enables broadcast services on a synchronized
single frequency network (SFN) with appropriate cyclic prefix design. This allows broadcast signals from different cells to combine over the air, thus increases
significantly the received signal power and supportable data rates for broadcast
services.
Transmission BW (M Hz)
Sub-frame duration
Sub-carrier spacing
Sampling frequency (M Hz)
FFT size
Number of occupied sub-carriers
Normal
CP length (µs)
Extended
1.4
1.92
128
72
3
5
10
15
1.0 ms
15 KHz
3.84 7.68 15.36 23.04
256 512 1024 1536
180 300
600
900
4.69×6, 5.21×1
16.6
20
30.72
2048
1200
Table 1.3.4. E-UTRA sub-frame parameters.
To provide great operational flexibility, E-UTRA physical layer specifications
are bandwidth agnostic and designed to accommodate up to 20 M Hz system
bandwidth. Table 1.3.4 provides the values of the downlink sub-frame parameters for different spectrum allocations. Sub-frames with one of two cyclic prefix
(CP) durations may be time-domain multiplexed, with the shorter designed for
unicast transmission and the longer designed for larger cells or broadcast SFN
transmission. The useful symbol duration is constant across all bandwidths. The
15 kHz sub-carrier spacing is large enough to avoid degradation from phase noise
and Doppler (250 km/h at 2.6 GHz) with 64QAM modulation.
The downlink reference signal structure for channel estimation, CQI measurement, and cell search/acquisition is shown in Figure 1.3.3. Reference symbols
15
1. Long Term Evolution (LTE)
(RS) are located in the 1st OFDM symbol (1st RS) and 3rd to last OFDM symbol
(2nd RS) of every slot. For FDD, it may be possible to reduce overhead by not
transmitting the 2nd RS for at least low to medium speeds, since adjacent subframes can often be used to improve channel estimation performance. This dual
TDM (or TDM) structure has similar performance to a scattered structure in 0.5
ms sub-frames, and an advantage in that low complexity channel estimation (interpolation) is supported as well as other excellent performance low-complexity
techniques, such as IFFT-based channel estimators. To provide orthogonal signals for multi-antenna implementation, FDM is used for different TX antennas
of the same cell, and CDM is used for different cells.
R0
R0
R1
R0
R0
R0
R0
R1
Slot
R1
R1
l=0
l=6
Slot
(a) Antenna port 0.
Figure 1.3.3.
R1
R1
R0
l=6
l=0
1.3.3
R1
Frequency
Frequency
R0
R1
l=6
l=0
Slot
l=0
l=6
Slot
(b) Antenna port 1.
Downlink reference signal structure - normal cyclic prefix, two
transmit antennas.
Smart antenna technology
Central to LTE is the concept of smart antenna technology (often loosely
referred to as MIMO) which take advantage of spatial diversity in the radio
channel. Smart antenna technologies are classified as: spatial diversity, MIMO,
16
LTE architecture 1.3
and beamforming. These techniques are used to improve signal robustness and
to increase system capacity and single-user data rates. Each technique has its
own performance benefits and costs.
Figure 1.3.4 illustrates the range of possible antenna techniques from simplest
to most complex, indicating how the radio channel is accessed by the system’s
transmitters and receivers.
Transmit
antennas
The radio channel
Receive
antennas
Transmit
antennas
The radio channel
(a) SISO system.
(b) SIMO system.
(c) MISO system.
(d) MIMO system.
Receive
antennas
Figure 1.3.4. Radio channel access modes.
SISO
The basic radio channel access mode is single input single output (SISO), in
which only one transmit antenna and one receive antenna are used. This is the
form of communications that has been the default since radio began and is the
baseline against which all the multiple antenna techniques are compared.
MISO
Slightly more complex than SISO is multiple input single output (MISO)
mode, which uses two or more transmitters and one receiver. (Figure 1.4(c) shows
17
1. Long Term Evolution (LTE)
only two transmitters and one receiver for simplicity.) MISO is more commonly
referred to as transmit diversity. The same data is sent on both transmitting
antennas but coded such that the receiver can identify each transmitter. Transmit diversity increases the robustness of the signal to fading and can increase
performance in low signal-to-noise ratio (SNR) conditions; however, it does not
increase data rates as such, but rather supports the same data rates using less
power. Transmit diversity can be enhanced with closed loop feedback from the
receiver to indicate the balance of phase and power used for each antenna.
SIMO
Figure 1.4(b) is single input multiple output (SIMO), which, in contrast to
MISO, uses one transmitter and two or more receivers. SIMO is often referred
to as receive diversity. Similar to transmit diversity, it is particularly well suited
for low SNR conditions in which a theoretical gain of 3 dB is possible when two
receivers are used. As with transmit diversity, there is no change in the data
rate since only one data stream is transmitted, but coverage at the cell edge is
improved due to the lowering of the usable SNR.
MIMO
Finally the Figure 1.4(d) shows full MIMO, which requires two or more transmitters and two or more receivers. This mode is not just a superposition of SIMO
and MISO since multiple data streams are now transmitted simultaneously in the
same frequency and time, taking full advantage of the different paths in the radio
channel. For a system to be described as MIMO, it must have at least as many
receivers as transmit streams. The number of transmit streams should not be con-
18
LTE architecture 1.3
fused with the number of transmit antennas. Consider the Tx diversity (MISO)
case in which two transmitters are present but only one data stream. Adding
receive diversity (SIMO) does not turn this into MIMO, even though there are
now two Tx and two Rx antennas involved. SIMO + MISO 6= MIMO. It is always possible to have more transmitters than data streams but not the other way
round. If N data streams are transmitted from less than N antennas, the data
cannot be fully descrambled by any number of receivers since overlapping streams
without the addition of spatial diversity just creates interference. However, by
spatially separating N streams across at least N antennas, N receivers will be able
to fully reconstruct the original data streams provided the crosstalk and noise in
the radio channel are low enough.
Another crucial factor for MIMO operation is that the transmissions from each
antenna must be uniquely identifiable so that each receiver can determine what
combination of transmissions has been received. This identification is usually
done with pilot signals, which use orthogonal patterns for each antenna.
The spatial diversity of the radio channel means that MIMO has the potential
to increase the data rate. The most basic form of MIMO assigns one data stream
to each antenna.
In this form, one data stream is uniquely assigned to one antenna. The channel
then mixes up the two transmissions such that at the receivers, each antenna sees a
combination of each stream. Decoding the received signals is the process in which
the receivers, by analyzing the patterns that uniquely identify each transmitter,
determine the combination of received signal. The application of an inverse filter
and summing of the received streams recreates the original data.
19
1. Long Term Evolution (LTE)
The theoretical gains from MIMO are a function of the number of transmit and
receive antennas, the radio propagation conditions, the ability of the transmitter
to adapt to the changing conditions, and the SNR. The ideal case is the one
in which the paths in the radio channel are completely uncorrelated, almost as
if separate, physically cabled connections with no crosstalk existed between the
transmitters and receivers. Such conditions are almost impossible to achieve in
free space, and with the potential for so many variables, it is neither helpful nor
possible to quote MIMO gains without stating the conditions. The upper limit of
MIMO gain in ideal conditions is more easily defined, and for a 2x2 system with
two simultaneous data streams a doubling of capacity is possible. MIMO works
best in high SNR conditions with minimal line of sight.
Beamforming
Beamforming uses the same signal processing and antenna techniques as
MIMO but rather than exploit de-correlation in the radio path, beamforming
aims to exploit correlation so that the radiation pattern from the transmitter is
directed towards the receiver. This is done by applying small time delays to a
calibrated phase array of antennas. The effectiveness of beamforming varies with
the number of antennas. With just two antennas little gain is seen, but with four
antennas the gain is higher. Obtaining the initial antenna timing calibration and
maintaining it in the field are challenge.
Combining beamforming and MIMO
The most advanced form of multiple antenna techniques is probably the combination of beamforming with MIMO. In this mode MIMO techniques could be
20
LTE architecture 1.3
used on sets of antennas, each of which comprises a beamforming array. Given
that beamforming with only two antennas has limited gains, the advantage of
combining beamforming and MIMO will not be realized unless there are many
antennas. This limits the practical use of the technique on cost grounds.
1.3.4
Scheduling
Scheduling controls the allocation of the shared resources among the users and
often is adapted to link variations; if this happens we have a channel-dependent
scheduling (Figure 1.3.5). In LTE a part of the scheduler is the rate adaptation,
so it determines the data rate to be used for each link.
Effective channel variations
seen by the base station
Effective channel variations
seen by the base station
User #1
User #1
User #2
Channel quality
Channel quality
User #2
#1
#2
#1
#2
(a) Time domain scheduling.
Time
#1
#2
#1
#2
#1
#2 Frequency
(b) Frequency domain scheduling.
Figure 1.3.5. Channel-dependent scheduling.
In addition to the time domain, LTE has also access to the frequency domain,
due to the use of OFDM. In other words, scheduling in LTE can take channel
variations into account not only in the time domain, as HSPA, but also in the
frequency domain and this mean that for LTE, scheduling decisions can be taken
as often as once every 1 ms and the granularity in the frequency domain is 180
kHz.
21
1. Long Term Evolution (LTE)
1.3.5
Channel structure
In LTE, there is significant effort to simplify the number and mappings of
logical and transport channels. The different logical and transport channels in
LTE are illustrated in Table 1.3.5 and Table 1.3.6, respectively.
Channel type
Control channels
(carry control
plane info)
Channel Name
Broadcast Control
Channel (BCCH)
Paging
Control
Channel (PCCH)
Common
Control
Channel (CCCH)
Multicast Control
Channel (MCCH)
Dedicated Control
Channel (DCCH)
Traffic channels
(carry user plane
info)
Dedicated
Traffic
Channel (DTCH)
Multicast
Traffic
Channel (MCCH)
Carried information
DL channel for broadcasting system control info
DL channel for transferring paging
UL channel for transmitting control info and used
by UE without RRC connection
DL
point-to-multipoint
channel for transmitting
MBMS control info
DL point-to-point bidirectional channel for
exchanging control information and used by UE
with RRC connection
Bi-directional
channel
dedicated to a single UE
DL
point-to-multipoint
channel for transmission
of MBMS data
Table 1.3.5. Logical channel characterized by the transferred information.
The transport channels are distinguished by the characteristics (e.g. adaptive modulation and coding) with which the data are transmitted over the radio
interface. The MAC layer performs the mapping between the logical channels
22
LTE architecture 1.3
and transport channels, schedules the different UEs and their services in both UL
and DL depending on their relative priorities, and selects the most appropriate
transport format.
Channel type
Channel Name
Broadcast Channel
(BCH)
Downlink
Shared
Channel (DL-SCH)
Downlink
channels
Paging
Channel
(PCH)
Multicast Channel
(MCCH)
Uplink
Channel
SCH)
Shared
(UL-
Uplink channels
Random
Access
Channel (RACH)
Table 1.3.6.
Carried information
fixed transport format
HARQ, dynamic link
adaptation,
support
for UE DRX, dynamic
and semi-static resource
allocation
required to be broadcast
Support for SFN combining and semi-static resource allocation
HARQ, dynamic link
adaptation,
support
for UE DRX, dynamic
and semi-static resource
allocation
limited control information, collision risk
Transport channel characterized by how the data is transferred
over radio interface.
The logical channels are characterized by the information carried by them.
The mapping of the logical channels to the transport channels is shown in Figure 1.3.6.
23
1. Long Term Evolution (LTE)
Downlink or uplink
DTCH
Downlink only
DCCH
BCCH
PCCH
BCH
PCH
MTCH
MCCH
Logical Channels
Transport Channels
DL-SCH
UL-SCH
MCH
Figure 1.3.6. Logical channel mapping onto transport channels.
Power-Up
LTE_ACTIVE
LTE_DETACHED
• IP
• No IP address
• Position not known
address assigned
• Connected to known cell
OUT_OF_SINK
• DL reception possible
• No UL transmission
LTE_IDLE
• IP address assigned
• Position partially known
• DL DRX period
IN_SINK
• DL reception possible
• UL transmission possible
Figure 1.3.7. Mobility states of the UE in LTE.
24
LTE handover 1.4
1.3.6
Mobility management
Mobility management can be classified based on the radio technologies of the
source and the target cells, and the mobility-state of the UE. From a mobility
perspective, the UE can be in one of three states, LTE DETACHED, LTE IDLE,
and LTE ACTIVE as shown in Figure 1.3.7. LTE DETACHED state is typically
a transitory state in which the UE is powered-on but is in the process of searching
and registering with the network. In the LTE ACTIVE state, the UE is registered
with the network and has an RRC connection with the eNB. In LTE ACTIVE
state, the network knows the cell to which the UE belongs and can transmit/
receive data from the UE. The LTE IDLE state is a power-conservation state
for the UE, where typically the UE is not transmitting or receiving packets. In
LTE IDLE state, no context about the UE is stored in the eNB. In this state,
the location of the UE is known only at the MME and only at the granularity of
a tracking area (TA) that consists of multiple eNBs. The MME knows the TA
in which the UE last registered and paging is necessary to locate the UE to any
cell.
1.4
LTE handover
The handover procedure, being one of the most important functionality of a
mobile system, also needs to be designed according to the distributed nature of
the LTE architecture. In LTE there is no soft handover support, mainly due to the
OFDMA access mechanism, and at each handover the user context, including user
plane packets and control plane context need to be relocated from one eNodeB to
25
1. Long Term Evolution (LTE)
other. Note that in WCDMA similar context relocation happens only in the rare
case of serving RNC relocation [5]. In LTE the relocation has to be performed in
a faster and more seamless way than in WCDMA and it remains to verify that
the user perceived performance is not impacted by the relocation based handover
scheme of LTE.
1.4.1
LTE intra-access handover procedure
In case of a handover the protocol endpoints that are located in the eNodeB
will need to be moved from the Source eNodeB to the Target eNodeB. Then,
it is an option whether the full protocol status of the Source eNodeB is transferred to the Target eNodeB or the protocols are reinitialized after the handover.
This raises the question for example, whether the HARQ and ARQ window state
is discarded and reset or transferred during the handover. Since it would be
overly complex and not always feasible to transfer the whole protocol state, it
is an assumption in LTE that the RLC/MAC protocols are reset after a handover. The message sequence diagram of the LTE handover procedure is shown
in Figure 1.4.1.
The figure shows both the control plane messages (black and blue solid arrows)
and the flow of the user plane packets (purple dashed arrows). See also [6] for a
description of the procedure. The UE sends measurement reports to the Source
eNodeB, which may decide on the execution of a handover. The Source eNodeB
requests the preparation of a handover at the Target eNodeB. The Target eNodeB
can perform admission control to check whether the established QoS bearers of
the UE can be accommodated in the target cell.
26
LTE handover 1.4
Source
eNB
UE
Target
eNB
MME
S-GW
0. Area Restriction Provided
1. Measurement Control
Packet Data
Legend
Packet Data
L3 Signaling
UL allocation
User Data
2. Measurement Report
L1/L2 Signaling
3. HO decision
Handover Preparation
4. Handover Request
5. Admission Control
6. Handover Request Ack
DL allocation
7. Handover Command
Detach from old cell and
synchronize to new cell
Deliver buffered and in
transit packets to target
eNB
Handover Execution
8. SN Status Tranfer
Data Forwarding
Buffer packets from
Source eNB
9. Syncronization
10. UL Allocation + TA for UE
11. Handover Confirm
12. Path Switch Request
13. User Plane Update Req
End Marker
16. Path Switch Request Ack
17. Relase Resource
Flush DL buffer, continue
delivering in transit packets
Handover Completion
14. Switch DL Path
15. User Plane Update Reply
Data Forwarding
End Marker
18. Relase Resources
Packet Data
Packet Data
Figure 1.4.1. Message chart of the LTE handover procedure.
27
1. Long Term Evolution (LTE)
Next, the Source eNodeB sends the Handover Command to the UE, which
includes all information that is necessary for the UE to access the target cell. At
the same time the Source eNodeB suspends the RLC/MAC protocols and it may
start to forward the SDUs that have not yet been successfully sent to the UE toward the Target eNodeB. That is, partially transmitted SDUs at the HARQ/ARQ
layers will be forwarded along with the buffered and not yet transmitted SDUs,
also including all the incoming SDUs from the GW. Whether SDU forwarding is
employed at all by the eNodeB is left as a vendor specific implementation detail.
At the same time, the UE starts to execute the handover to reconnect at the
Target eNodeB. The UE needs to perform a random access procedure on the
RACH (Random Access Channel) in the target cell. The UE also needs to get
uplink time alignment assigned, which means that the eNodeB has to measure
on the uplink transmission of the UE (on the RACH) and determine the timing
advance that the UE has to use for its uplink transmissions in order for the received signals from multiple UEs arrive time synchronized at the eNodeB. Note
that in OFDM [7] it is especially important to keep an accurate time synchronization between carriers in order to maintain orthogonality. The UE also needs
to get UL/DL resources scheduled in order to be able to commence user data
transmission. These L1/L2 access procedures, i.e., the radio interruption time at
a handover, are estimated to take approximately 30 ms [8].
Next, the UE sends the Handover Complete message in the target cell, which
is used by the Target eNodeB to verify that it is the right UE that is accessing the
target cell. At that point the Target eNodeB can start sending DL data to the
UE. The Target eNodeB sends the path switch command to the GW and finally,
28
Summary 1.5
it triggers the release of resources at the Source eNodeB. Note that there can be
a time interval after the path switch when packets both on the direct path and
also on the forwarding path arrive in parallel at the Target eNodeB. This may
give rise to the problem of out of order packet delivery as explained below.
In fact, during the handover procedure there is a time interval when packets
on the direct path (GW - Target eNodeB) and packets on the forwarding path
(GW - Source eNodeB - Target eNodeB) may arrive in parallel at the Target
eNodeB. This gives rise to the potential problem of out of order packet delivery
to the UE, since packets on the direct path typically travel a shorter distance and
arrive earlier to the Target eNodeB than packets on the forwarding path. Note
that out of order packet arrivals may have a bad impact on tcp performance and
may result in a loss of system utilization. When three or more packets arrive out
of order, it results in duplicate acks received at the tcp sender, which will react
with a retransmission and congestion window halving.
A solution for this problem can be found in [8], where a packet reordering
feature inside the Target eNB is implemented to avoid the out of order delivering.
1.5
Summary
In this chapter we have described the LTE system by highlighting its performance and architecture, which allow an end-user throughput increasing compared
with previous mobile technology. Then, we have focused our attention on the handover procedure that is the central point of our study. After this introductory
overview, we are ready to introduce the tcp protocol and analyze its behavior
during the LTE handover procedure.
29
Chapter 2
TCP over LTE
Transmission control protocol (tcp) is the most widely used transport protocol for reliable packet data services in wireless networks. It was initially designed for wired networks where packet losses and delays are mainly caused by
congestion. tcp includes drastic recovery mechanism that reacts to congestion
situations with abrupt throughput reductions.
Over wireless networks, where losses are mainly caused by mobility and intermittent poor channel conditions [16], poor tcp performance is experienced.
Common tcp versions misinterpret delays as congestion indications, sometimes
useless retransmissions are experienced and long time is wasted during the slow
start and the congestion avoidance phases. Some solutions have been found introducing changes in the tcp paradigm. Westwood tcp, for example, tries to
improve the classic tcp behavior to apply it over both wireless and wired networks. tcp selective acknowledgments (sack) [18] is proposed to alleviate the
inefficiency of tcp in handling multiple drops in a single data window.
31
2. TCP over LTE
2.1
Transmission Control Protocol
The most commonly used transport layer protocols are tcp and udp. udp [14]
is a connectionless protocol that does not guarantee delivery of data, it doesn’t
make any error check on the payload. It is used in server client type request-reply
situations and in applications where prompt delivery of data is more important
than accurate delivery, as video streaming. tcp [13] is a reliable transport protocol with connection procedure that provides an in-sequence data delivering from
a sender to a receiver. Some of the tcp properties may be desired by certain
applications.
The tcp reliability is achieved using ARQ mechanism based on positive acknowledgments. tcp protocol provides transparent segmentation and reassembly
of user data and handles both data flow and congestion. tcp packets are cumulatively acknowledged when they arrive in sequence, out of sequence packets cause
the generation of duplicate acknowledgments. In Each segment transmission a
retransmission timer is started. Retransmission timers are continuously updated
on a weighted average of previous round trip time (rtt) measurements, i.e., the
time it takes from the transmission of a segment until the paired acknowledgment
is received. tcp sender detects a loss either when multiple duplicate acknowledgments (3 default value) arrive, implying that the next packet was lost, or when
a retransmission timeout (rto) expires. The rto value is calculated dynamically based on rtt measurements. Its accuracy is critical, delayed timeouts slow
down recovery or redundant retransmissions can occur due to mistakes in the
rto evaluation.
32
Transmission Control Protocol 2.1
For the flow control tcp uses a sliding window mechanism. It limits the
amount of data that can be sent without waiting for acknowledgement (ack)
from the receiver and when the window is constant, this results in the so called
ack-clock. As illustrated in the Figure 2.1.1, the window size is the amount of
allowed outstanding data. The sliding window, only after the ack for an “in
sequence” packet permits the transmission of one further packet, and the window
of outstanding data slides forward one packet.
0
9
1
9
0
1
8
2
8
2
7
3
7
3
6
5
4
(a) Before the ack of packet 3.
6
5
4
(b) After the ack of packet 3.
Figure 2.1.1. Sliding window mechanism.
Today all tcp implementations are provided of congestion control algorithms
such as slow start, congestion avoidance, fast retransmit and fast recovery [15].
2.1.1
TCP congestion control
tcp was initially designed to be used in wired networks having very low
transmission losses (BERs lower than 10−10 ), it assumes that all losses are due
to congestion. Therefore, when tcp detects packet losses, it reacts both retransmitting the lost packet and reducing the transmission rate. In this way it allows
a reduction of the router queues length. Afterwards, it gradually increases the
33
2. TCP over LTE
transmission rate to probe the network’s capacity.
The purpose of slow start and congestion avoidance is to prevent the congestion by varying the transmission rate. For this reason tcp use a congestion
window (cwnd), which represents the number of segments that the network might
deliver without congestion occurring. The initial value of the congestion window
can be chosen between one and four segments [19]. The receiver maintains an advertised windows (rwnd) which indicates the maximum number of bytes its buffer
can accept. The value of the rwnd is sent back to the sender together with each
segment going back. At any moment, the amount of outstanding data (wnd ) is
limited by
wnd = min (rwnd, cwnd) .
(2.1.1)
In the slow start phase, the congestion window is increased by one segment
for each acknowledgment received. This phase is used both at the beginning of a
new connections and after retransmissions due to rto expiring. During the slow
start phase cwnd experiences an exponential increase until a timeout occurs or a
threshold value (SSthresh) is reached. In the first case the cwnd value drop to 1
Maximum Segment Size (MSS). Afterwards, the slow start phase ends and the
congestion avoidance phase starts. The main difference between slow start and
congestion avoidance algorithm is the way the cwnd value is updated (the first is
exponential whereas the second is linear), namely
cwnd =
34


 cwnd + 1,
Slow Start;

 cwnd + M SS · M SS , Congestion avoidance.
cwnd
(2.1.2)
Transmission Control Protocol 2.1
During the slow start phase, tcp opens the congestion window quickly to
reach the capacity limit of the link as rapid as possible, the congestion avoidance
algorithm is conceived to transmit at a safe operating point and increase the
congestion window slowly to probe the network for more bandwidth becoming
available.
Timeout
e
anc
20
SStresh
16
sti
gre
Con
void
on A
e
anc
void
A
tion
res
g
Con
12
New SStresh
w
Sta
rt
8
4
Slo
Congestion Window (Segments)
24
w
Slo
0
0
1
2
3
4
5
6
7
8
9
10
t
ar
St
11
12
13
14
15
16
17
Round Trip Times
Figure 2.1.2. tcp slow start and congestion avoidance.
As shown in Figure 2.1.2, if a timeout occurs, the SSthresh is updated to a
half of the current window size
SSthresh =
min (rwnd, cwnd)
.
2
(2.1.3)
Then, congestion window is reduced to 1 MSS, and the slow start phase is entered
again.
A different behavior is assumed by tcp in case of three duplicate acks in
a row. That can happen when the receiver detects an out of order and send
back to the sender the sequence number of the next expected packet. Therefore,
tcp performs a direct retransmission of the missing segment after the reception
35
2. TCP over LTE
of the third dupack even if the retransmission timer has not expired yet. The
SSthresh is set to the same value as in the case of timeout (2.1.3). After the
retransmission, fast recovery is performed until all lost data is recovered. The
congestion window is set to three segments more than SSthresh, which takes into
account the number of segments that have already left the network and that are
buffered by the receiver). For each additional duplicate ack received, the cwnd is
incremented by one according to the following equation
cwnd = cwnd + 1.
(2.1.4)
The fast recovery phase ends when a non-duplicate acknowledgment is detected.
The congestion window is then set SSthresh and a congestion avoidance phase
starts (Figure 2.1.3).
3rd duplicate Ack
e
nc
oida
(fast retransmit)
v
20
nA
stio
gre
16
New Ack
Con
SStresh
e
anc
void
on A
ti
s
re
ong
Fast Recovery
12
C
New SStresh
w
Sta
rt
8
4
Slo
Congestion Window (Segments)
24
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Round Trip Times
Figure 2.1.3. tcp fast retransmit and fast recovery.
With fast retransmit and fast recovery, tcp avoid unnecessary slow starts
phases due to minor congestion incidents (dupacks are used as indicators of
some kind of network congestion).
36
Transmission Control Protocol 2.1
2.1.2
Explicit Congestion Notification (ECN)
ECN is an extension to the Internet Protocol and is defined in [21]. ECN
allows end-to-end notification of network congestion without dropping packets.
It is an optional feature, and is only used when both endpoints signal that they
want to use it during the three way handshaking.
Traditionally, tcp/ip networks signal congestion by dropping packets. When
ECN is successfully negotiated, an ECN-aware router may set one bit in the
ip header instead of dropping a packet in order to signal the beginning of congestion. The receiver of the packet echoes the congestion indication to the sender,
which must react as though a packet drop was detected. Obviously, this policy
is useful only if it is used in a network where the nodes have an Active Queue
Management (AQM) algorithm.
ECN uses two bits in the ipv4 Type of Service (TOS) field in the ip header.
These two bits can be used to encode one of the values ECN-unaware transport,
ECN-aware transport or congestion experienced as shown in Figure 2.1.4.
0
1
2
3
4
5
6
Differentiated Service CodePoint
7
ECN
ECT
CE
0
0
ECN-unaware
0
1
ECN-aware
1
0
ECN-aware
1
1
Congestion Experienced
Figure 2.1.4. The TOS field in ip header and ECN signaling.
In addition to the two ECN bits in the ip header, tcp uses two flags in the
tcp header to signal the sender to reduce the amount of information it sends.
37
2. TCP over LTE
These are the ECN-echo (ECE) and Congestion Window Reduced (CWR) bits
(Figure 2.1.5).
0
1
2
Header Length
3
4
5
6
Reserved
7
8
9
10
11
12
13
14
15
CWR
ECE
URG
ACK
PSH
RST
SYN
FIN
Figure 2.1.5. Bytes 13 and 14 of the tcp header.
Once the receiver get a tcp segment with the Congestion Experienced code
point, the tcp receiver sends an acknowledgement with the ECE flag set. The
ECN-echo bit indicates congestion to the sender, which reduces its congestion
window as for a packet drop. It then acknowledges the congestion indication by
sending a segment with the CWR code point.
2.1.3
Core network bottleneck
The LTE system supports QoS mechanisms over radio and in the transport
network. However no flow control mechanism are supported between the base
station and the gateway. This implies that packet buffering/dropping for elastic
services, like tcp, could occur during congestion in any node of the core network
(e.g., in the base station or a transport network router).
The 3GPP standard assumes that the end-to-end tcp protocol will govern
the congestion control and adapt to the varying network conditions and handle
packet loss.
As already depicted in the Section 1.3 the user plane connection cross the core
network exploiting an ip tunnel, between serving gateway and eNodeB, based on
GPRS Tunneling Protocol (GTP). Due to this tunneling protocol any explicit
38
Transmission Control Protocol 2.1
congestion signaling is not allowed even if the user connection is able to handle it.
The ip header handled by the network router belonging to the tunnel application
rather than the user and all possible signaling will be trashed once the packet
reaches the end of the tunnel.
GPRS Tunneling Protocol (GTP)
GPRS Tunneling Protocol [17] is an ip based protocol to be used within GSM
and UMTS networks as a solution to manage the mobility of the MEs. It can be
used with udp or tcp, but the first solution is adopted generally.
By a deeper analysis we can distinguish two separate protocols for user data
and control data:
GTP-C is used inside the core network for signalling between inner Support
Nodes. This allows the network to activate a session on behalf of users
(PDP context activation), to deactivate the same session, to adjust Quality
of Service parameters or to update a session for a subscriber.
GTP-U is used for carrying user data within mobile core network and between
the Radio Access Network the core network. The transported user data can
be packets in any of ipv4, ipv6 or other formats.
Let us focus our attention on the user plane. GTP-U is a relatively simple
ip based tunneling protocol which permits many tunnels between each set of end
points. When used in LTE, as in the UMTS network, each subscriber will have one
or more tunnels, one for each PDP context they have active plus, possibly separate
tunnels for specific connections with different Quality of Service requirements.
39
2. TCP over LTE
User
Application
Carry the effective payload
IP (user)
It will be the IP header once the packet leave the tunnel connection
GTP
Header used to distinguish and manage different tunnel
UDP
Connectionless transport protocol for GTP
Header used to manage the tunnel application
IP
Depending on the Network Architecture
Layer 2
Figure 2.1.6. GTP-U Protocol Stack.
Figure 2.1.6 show the GTP protocol stack for user data, it shows that a second
ip header is added to manage the tunnel connection while the user ip header is
moved inside the payload of the GTP protocol that works like an application
protocol.
0
Bits 0-2
3
4
5
6
7
8-15
Version
Protpcol
Type
Reserved
Next
Extension
Header
Sequence
Number
N-PDU
Number
Type
16-23
24-31
Total Lentht
TEID
32
Sequence Number
64
N-PDU Number
Next Extension
Header
Figure 2.1.7. GTPv1 header (default and optional fields).
In Figure 2.1.7 we can see the GTP header structure and below there are a
quick description of all field function:
Version is a 3-bit field that indicate the GTP protocol version. For GTPv1, this
has a value of 1.
40
Transmission Control Protocol 2.1
Protocol Type differentiates GTP (value 1) from GTP’ (value 0).
Reserved this field must be 0.
Extension Header (E) is set if there is an Extension Header optional field.
Sequence Number (S) is set if there is a Sequence Number optional field.
N-PDU number (PN) is set if there is a N-PDU number optional field.
Type differentiates the packet type.
Total Length is a 16-bit field that states the length of the packet being encapsulated by GTP (not including the GTP header itself, but including the
optional fields).
Tunnel Endpoint Identifier (TEID) used to multiplex different connections
in the same GTP tunnel.
We can find also some optional fields available only if any of the E, S, or PN bits
are on. These fields are:
Sequence Number must be interpreted only if the S bit is on.
N-PDU number must be interpreted only if the PN bit is on.
Next Extension Header must be interpreted only if the E bit is on.
The separate tunnels are identified by a Tunnel Endpoint Identifier (TEID) in
the GTP-U messages, which should be a dynamically allocated random number.
If this random number is of cryptographic quality, then it will provide a measure of
security against certain attacks. Even so, the requirement of the 3GPP standard
41
2. TCP over LTE
is that all GTP traffic, including user data should be sent within secure private
networks, not directly connected to the Internet.
2.2
Key parameters to evaluate TCP Performance
tcp performance can be measured or evaluated in different ways depending on
the context, such as the system used and the application carried over the tcp connection. tcp performance can be evaluated using the following key parameters
[20]:
Effective throughput also called effective bandwidth. It is the data transmission rate of the application in [bit/s]. The effective throughput is more
significant than the communication channel throughput, since it take into
account the effective amount of data delivered at the tcp layer.
Throughput variation The throughput variation over a given timescale, depending on the application, it is very important to assess end-to-end performance of certain application.
File transfer time This parameter is related to the effective throughput.
Round trip time (rtt) The time between the transmission of a segment and
the reception of the paired acknowledgment. This parameter includes the
delay in the intermediate network nodes and is an estimation of the network
latency. It can limit the effective throughput.
Delay variation or jitter is the variation of the rtt. This variation can have
a direct impact on the appearance of triple duplicate ack or timeout events
42
Modeling of TCP during LTE handover 2.3
(sometimes spurious) and it results in throughput limitation and resource
wasting.
Fairness is an important characteristic, especially when tcp applications are
carried over wireless systems. Unfair resource allocation can have drastic
effects on the effective throughput.
Resource consumption The amount of resources (e.g. buffer space, transmission power) needed to achieve a given effective throughput.
2.3
Modeling of TCP during LTE handover
To show how the LTE handover procedure works we use a fluid-flow model.
This model views the data streams across the network as continuous flows. All
quantities of interest, such as sending rates, window sizes and queue sizes, are
treated as continuous functions of time. In particular we are using a new joint link
model studied by Möller in [3] because it represents a tradeoff between simplicity
and ease implementation (comparison with other models can be found in [1]).
Our scenario is shown in the Figure 2.3.1, where the ME(0) is the mobile that is
doing handover (moving from Source eNodeB - SeNB - to Target eNodeB - TeNB
-) following the procedure stated in the Section 1.4.
We assume to use tcp Reno [15]. Suppose the round trip propagation delay
is constant and denoting it by τ (without taking into account the time spent
in the queue) tcp Reno allows us to send one full windows (w) of data each τ ,
consisting of w/m packets, where m is the packet size.
At this point is better understand what is the “windows size”. We mean by
43
2. TCP over LTE
SeNB
INTERNET
TeNB
ME(0)
ME(n)
ME(1)
ME(i)
Figure 2.3.1. LTE handover scenario.
“windows size” (w(t)) the actual amount of outstanding data, which are packets
that have been transmitted and for which no ackpacket has been received by
the sender yet. Sometimes this definition may create a confusion with congestion
window in tcp, cwnd, which is determined by the window update mechanism,
but there may be a significant discrepancy between w and cwnd.
Let p be the packet loss probability for each packet. There are two possible
window updates:
1. With probability (1 − p), an ack is received, and the additive increase
mechanism rises the window by ∆w = m2 /w.
2. With probability p, the packet is lost, and the multiplicative decrease mechanism updates the window size by ∆w = −w/2.
44
Modeling of TCP during LTE handover 2.3
It follows that the derivative of the continuous function w(t) is [3],
dw
(1 − p)m pw2 (t)
=
−
.
dt
τ
2τ m
(2.3.1)
By extending this result to the time-varying queueing delay, (2.3.1) becomes
dw
(1 − p)m
pw2 (t)
=
−
,
dt
τ + q(t − τb )/c 2m (τ + q(t − τb )/c)
(2.3.2)
where c is the link capacity, τb is the backward delay and q(t) is the quantity of
queued data.
In [3] is shown that for single flow traversing a single bottleneck, the state
equation are:
w(t − τ )
+ w0 (t);
rtt(t)
w(t − τ − τf )
q 0 (t) =
+ w0 (t − τf ) + x(t) − c,
rtt(t − τf )
r(t) =
(2.3.3)
where w0 (t) is defined by (2.3.2) for tcp Reno, x(t) is the cross traffic (it includes all non tcp traffic type) and rtt = τ + q(t − τb )/c, where τ = τf + τb .
τf , r(t) represents the sending rate and τb are the forward and backward delay,
respectively.
When we have multiple flows traversing a single bottleneck, every k-th one
has a window size wk (t), sending at rate rk (t), and experiencing a round trip
propagation delay τk . Then, we can extend (2.3.3) to the case of multiple flows
as follows. Without loss of generality, we can assume that τf,k = 0.
wk (t − τk )
+ wk0 (t);
rttk (t)
X wk (t − τk ) X
q 0 (t) =
+
wk0 (t) + x(t) − c,
rttk (t)
k
k
rk (t) =
(2.3.4)
45
2. TCP over LTE
where now rttk (t) = τ + q(t − τk )/c, in which τk = τb,k .
2.3.1
Scenario description
In this section we will study our scenario by considering three phases:
Before the handover: the ME(0) is still connected to the network by the SeNB
and other mobiles are connected with TeNB.
At the handover: this phase starts at the time in which the mobile ME(0)
starts the handover procedure (at time tHO ) and his data, stored in the
SeNB’s buffer, start to be forwarded to TeNB through the core network
(Router).
After handover: the handover algorithm is finished and the ME(0) is connected
to the network by the TeNB with all other mobiles and share the radio
resource with them.
In the following, we investigate the three phases presented above.
Before the handover
We suppose that the ME(0) is the only mobile attached to SeNB, so we start
the analysis by studying the queue state over the link between the router and
SeNB (see Figure 2.3.1) taking into account that all connections between MEs
and sources uses tcp. It follows that we can model the system as a single tcp flow
traversing a single bottleneck, for which state equations are given by (2.3.3).
Studying the queue state over the link between the router and TeNB (see
Figure 2.3.1), we can suppose to handle the problem as a multiple tcp flows
46
Modeling of TCP during LTE handover 2.3
traversing a single bottleneck; so the state equation will become (2.3.4) with
1 ≤ k < n, where n is the total number of mobiles that are connected to the
TeNB.
At the handover
At the handover time, tHO , we suppose that all data in the SeNB’s buffer are
instantly moved to the TeNB’s buffer in a priority queue to avoid the out of order
packets arrival to ME(0). Hence, the packet amount that are forwarded to the
TeNB at time tHO , is the in-flight data at tHO added to the data sent from the
sources, between the attach time (tAT T ) and path sw time (tP S ), which is 10
ms for LTE. We define by FW such a packet amount. Specifically, for the ME(0)
in the TeNB, we have (by denoting his flow k = 0):
w(t − τ0 )
+ w00 (t);
rtt0 (t)
w(t − τ0 )
q00 (t) =
+ w0 (t − τ0 ) + x(t) − c + FWδ(t − tHO ),
rtt0 (t)
r0 (t) =
(2.3.5)
where
Z
tP S
FW = w(tHO ) +
r0 (t)dt
(2.3.6)
tAT T
and for all the other flows the equations are given by (2.3.4).
After handover
After handover at TeNB the situation will be the same as before, with the
exception of the presence of a further mobile. Therefore, the equations for all the
flows are given by (2.3.4) but now 0 ≤ k < n. At SeNB we do not have any more
tcp connections.
47
2. TCP over LTE
2.4
Summary
In this chapter we have studied the main aspects of the tcp protocol. An
overview of the key parameters to evaluate tcp performance has been given. A
mathematical model of tcp during LTE handover has been introduced. We are
now in the position of analyzing the performance degradation of tcp during the
handover, and propose possible solutions.
48
Chapter 3
Improving TCP performance during LTE
handover
In this chapter we propose three solutions to improve tcp performance during handover. They can be divided into three big categories: (a) forwarding
avoidance, (b) active queue management inside the core network and, (c) buffer
dimension optimization.
Then, the solutions proposed in following sections will be analyzed by simulations in Chapter 4.
3.1
Forwarding avoidance
As described in Section 1.4, during the handover user data are forwarded
from the Source eNB to the Target eNB. Due to this mechanism the rtt of
the forwarded packet will increase specially if the PLMN transport network is
experiencing a congestion.
In Figure 3.1.1 the packet forwarding in a congested transport network is
reported. As we can observe, rtt of the user in handover can double, and it can
lead to resource wasting. In this figure each dot represents the rtt measurement
49
3. Improving TCP performance during LTE handover
0.25
0.2
RTT [s]
0.15
0.1
0.05
0
1
1.5
2
2.5
Time[s]
3
3.5
4
Figure 3.1.1. rtt increase during handover procedure in a congested transport
network.
of each sent packet, whereas the forwarded packets are those whose rtt is greater
than the others. The basic idea is to find a way to avoid the packet forwarding
so to avoid the rtt increasing.
3.1.1
cwnd variation during Handover
Figure 3.1.2 shows all possible behaviors that can be exhibited by the congestion window after the handover.
We are mainly interested in the time interval between rtt1 and rtt2 that
corresponds to a saw tooth of the steady-state congestion window behavior. The
purpose of this model is to study the differences, in terms of throughput during
that interval.
50
Forwarding avoidance 3.1
CWND
CWNDMAX
al
Ide
se
ca
ng
lvi
Handover
CWNDHO
ow
ha
ind
W
SStresh
Timeout
SStreshHO
RTT1
RTT2
RTT
Figure 3.1.2. cwnd during handover in case of ideal case, window halving and
timeout.
Ideal case
In the ideal case the congestion window keeps on following the steady-state
course independently from the handover event. The amount of data delivered
(DI ) during the period of our interest follows the (3.1.1)
DI =
rtt
X2
cwnd(i) =
i=rtt1
cwndM AX
=
·
2
=
cwnd
M AX
X
i=
i=SSthresh
3 cwndM AX
·
2
2
cwndX
M AX /2
cwndM AX
+1 +
i=
2
i=0
cwndM AX
+1
2
(3.1.1)
in which cwndM AX is the maximum value assumed by the cwnd in the steady-state
cwndM AX
phase and SSthresh =
according with the tcp standard.
2
The ideal case here described will be taken as reference with respect to more
realistic situations, as described in the following.
51
3. Improving TCP performance during LTE handover
Window halving
A window halving occurs due to an out-of-order delivering, which happens if
the router buffer exceeds the maximum length during the packet forwarding.
CWNDMAX
CWND
Handover
CWNDHO
UnsentWH
SStresh
SStreshHO
RTT1
RTT
RTT2
Figure 3.1.3. Difference between ideal case and window halving.
In Figure 3.1.3 the difference in terms of throughput between the ideal case
and the case with window halving is shown.
To compute the throughput, we need to subtract from (3.1.1) that the patterned area (U nsentW H ). It follows that
DW H = DI − U nsentW H = DI −
cwnd
M AX
X
(cwndHO − SSthreshHO ) =
i=cwndHO
= DI −
(3.1.2)
cwndHO
· (cwndM AX − cwndHO + 1) ,
2
where cwndHO represents the value assumed by the cwnd at the handover time
cwndHO
and SSthreshHO =
.
2
By using this model the values of cwndHO are those belonging to the interval
52
Forwarding avoidance 3.1
[SSthresh, cwndM AX ] corresponding to all real possible values.
Timeout verification
This is the worst event that can occur during the handover. Practically it
should be a consequence of spurious timeout essentially due to the high jitter
increase, even more highlighted by the data forwarding.
CWNDMAX
CWND
Handover
CWNDHO
UnsentWH
SStresh
k
SStreshHO
UnsentSS
RTT1
RTT
RTT2
Figure 3.1.4. Difference between ideal case and timeout verification.
Analyzing the patterned area in the Figure 3.1.4 we can see that in this case
we have more loss than any other case. The unsent amount of data can be divided
in two different contribution: U nsentW H essentially due to the cwnd halving and
U nsentSS due to the slow-start phase.
53
3. Improving TCP performance during LTE handover
Then the throughput of this case can be written as:
DSS = DI − U nsentW H − U nsentSS =
= DW H − k · (cwndM AX − cwndHO + 1) −
k−1 X
cwndHO
i=0
2
i
−k+i−2
.
(3.1.3)
U nsentSS depends on k, which represents the total number of rtt in which the
slow-start phase is on duty.
SSthreshHO belongs to the following interval
SSthreshHO ∈
SSthresh
cwndM AX
, SSthresh and SSthresh =
2
2
(3.1.4)
and k can be expressed as:
k = dlog2 SSthreshHO e + 1.
(3.1.5)
The cwndHO values must belong to the interval [SSthresh, cwndM AX − 2k + 2]
to use this model. Such an interval does not correspond to all possible values,
because 2k − 2 other possible values are missing. If we want to consider also that
case, we have to extend our observation period to the next saw tooth and take
into account further throughput differences.
In Figure 3.1.5 we can see the normalized throughput for all cases. If we vary
the cwndM AX we can see that performance of the window halving case are almost
the same for all cases. Differently, for the timeout case we observe that an increase
of cwndM AX gives better performance of window halving which is essentially due
to the incidence of the slow start phase (k increase as log2 cwndM AX ).
Figure 3.1.6 shows two different kinds of average to quantify performance.
54
Forwarding avoidance 3.1
100
Normalized Throughput [%]
95
90
85
80
75
70
65
60
Ideal
WH
SS
55
50
40
45
50
55
60
65
70
CWNDHO [Packets]
75
80
(a) cwndM AX = 80.
100
Normalized Throughput [%]
95
90
85
80
75
70
65
60
Ideal
WH
SS
55
50
70
80
90
100
CWNDHO [Packets]
110
120
(b) cwndM AX = 128.
100
Normalized Throughput [%]
95
90
85
80
75
70
65
60
Ideal
WH
SS
55
50
140
160
180
200
CWNDHO [Packets]
220
240
(c) cwndM AX = 256.
Figure 3.1.5. Normalized throughput during the time interval (rtt1 , rtt2 ) for
ideal case, window halving and timeout with cwndM AX as parameter.
55
3. Improving TCP performance during LTE handover
100
Normalized Throughput [%]
95
90
85
80
75
70
65
Ideal
WH
SS
60
55
40
50
60
70
80
90
CWNDMAX [Packets]
100
110
120
Figure 3.1.6. Different averages of the normalized throughput by varying the
cwndM AX parameter.
The continuous lines represent the average made from the normalized throughput
on varying the cwndM AX , the dashed lines assume that in average the handover
occurs in the middle of the interval (SSthresh, cwndM AX ).
3.1.2
Fast path switch
When the spurious timeout leads to a resource wasting, a solution is given by
some modification to the handover procedure depicted in Figure 1.4.1.
A modification is to send the path switch command to the SAE gateway
immediately after the handover command to reduce the amount of forwarded
data.
In Figure 3.1.7 is summarized how the first part of the message chart should be
by this modification. This solution should decrease the amount of user data that
need to be forwarded, leading to better performance in terms of rtt variation.
56
Forwarding avoidance 3.1
Source
eNB
UE
Target
eNB
MME
S-GW
HO decision
Legend
L3 Signaling
Handover Request
Admission Control
User Data
Handover Request Ack
L1/L2 Signaling
DL allocation
Handover Command
Path Switch Request
User Plane Update Req
End Marker
Switch DL Path
Figure 3.1.7. Fast path switch modification to the handover message chart.
3.1.3
Handover prediction
In [26, 27] are described different handover prediction mechanisms to be used
in LTE and between different RATs. In the area of mobility management, in wireless networks, fast and seamless handover should be one of major goal. It is also
required for a 3G LTE system in which only hard handover is allowed. However,
such handover preparation techniques have not been shown in 3G LTE systems
yet. Actually the protocol architecture of 3G systems has already cross-layer
interfaces between a signaling protocol such as RRC and lower-layer protocols
to increase the system efficiency. The cross-layer architecture could be used to
manage a handover prediction.
The basic idea is a prediction of the handover event, so that a generation of
the path switch command before the handover command is performed. Thanks
to this algorithm, the ME should be able to empty his pipe and do the handover
without any data forwarding.
Figure 3.1.8 shows the message chart modification needed for the handover
57
3. Improving TCP performance during LTE handover
Source
eNB
UE
Target
eNB
MME
S-GW
1. Measurement Control
Packet Data
Legend
UL allocation
L3 Signaling
2. Measurement Report
User Data
HO prediction
L1/L2 Signaling
Handover Request
Admission Control
Necessary Prediction time interval
Figure 3.1.8.
Path Switch Request
User Plane Update Req
End Marker
Switch DL Path
Handover Request Ack
DL allocation
Handover Command
Modification to the handover message chart for the handover
prediction.
prediction. The prediction time interval depends on the rtt of the tcp packets
directed towards the mobile that is doing the handover. The main benefit of this
solution is the total avoiding the rtt peak (shown in Figure 3.1.1) experienced
by the segments because no forwarding occurs.
The Figure 3.1.8 shows that the path switch request should be sent to the
MME before the handover to allow the pipe emptying before the handover.
For this solution, as well as for the one depicted in the 3.1.2, a procedure for
resource allocation on the Target eNB after a request made by the network rather
than the mobile is needed.
3.2
AQM in the core network
Active Queue Management (AQM) refers to the control taking place in network routers. The input to the control is the arrival rate and queue size for a
58
AQM in the core network 3.2
particular outgoing link, and the output is a decision on how to mark or drop
packets. Usually the output is applied in a stochastic way. The AQM mechanism selects the probabilities for marking and dropping packets, and then each
forwarded packet is marked/dropped with the given probability. End hosts will
then react to these signals and adjust their sending rates.
There are several motivations for using AQM, corresponding to difference
aspects of quality and performance:
• Reduced packet loss rate.
• Reduced queueing delay and jitter.
• Reduced synchronization between the AIMD window fluctuations of different flows.
• Improved throughput.
Several AQM mechanisms are evaluated in [22], with and without the use of
ECN. The quality measure of this study is user response time for web browsing
and the main results can be summarized as a better performance of the AQM
compared to the simple drop-tail mechanism when the offered traffic is greater
than the 80% of the bottleneck link capacity. Better performance can be achieved
with the ECN implementation.
Section 4.4.3 shows a comparison between classical drop-tail queue management and Random Early Detection (RED) both with and without the marking
feature.
59
3. Improving TCP performance during LTE handover
3.2.1
Random Early Detection (RED)
The idea of RED [23] is that the existence of queues is an early sign of network
congestion, but that transient congestion and longer-lived congestion must be
separated. It is only possible to control longer-lived congestion.
While the transient congestion is characterized by a temporary increase in
the queue, longer-lived congestion can be observed by an increase in the average
queue occupation. Consequently, RED monitors the average queue length, by
filtering the queue size samples, and drops packets in a randomized fashion with
a probability that is set as an increasing piece-wise linear function of the average
queue length. The larger the average queue is, the more congestion and, thus,
the higher probability that a packet is dropped.
Dropping/marking probability
1
Max p
0
thresh
max thresh
Average queue size
Queue size
Figure 3.2.1. Dropping/marking probability of RED queue management.
The probability of dropping/marking packets of this queue management follows the probability shown in Figure 3.2.1. Many parameters must be set when
60
AQM in the core network 3.2
RED is used and varying those parameters implies huge changes in the mechanism performance. The parameters that must be set are thresh, maxthresh and
max p. The first represents the threshold from which the dropping/marking probability will be greater than zero; if the average queue value is between thresh and
maxthresh the probability will follow a linear law from zero to max p; otherwise
if the average queue value is greater then maxthresh the probability will be 1.
RED is widely deployed in Internet routers today, it is however, rarely used
in the pure version due to hard tuning parameters as shown in [24]. A solution is
proposed in [25], which exploits the parameters adaptation and is called Adaptive
RED.
3.2.2
Cross-Network ECN
In the tcp standard is available an option to notify the congestion inside the
network, see Section 2.1.2 for details. In the tunnel connection, between the SAE
Gateway and the eNB transport protocol is udp and typically it does not allow
an ECN notification (Figure 1.3.1). This network configuration is ECN-unaware
even if the user transport protocol provides such a feature.
Than the basic idea is to enable the AQM policy with ECN marking in all
the core network router and forward that signaling to the user ip header at the
end of the tunnel. That means feature enhancement inside the eNB/Gateway to
mark/drop the packets depending on the user transport protocol.
The mark is forwarded by the eNB to the user ip header only if it carries
the ECN-aware sequence, as shown in Figure 3.2(a). Otherwise, when the user
ip header handles a ECN-unaware tcp the packet will be dropped, as shown in
61
3. Improving TCP performance during LTE handover
TOS field of tunnel IP header
TOS field of user IP header
DSCP
X
X
X
ECN
X
X
X
1
DSCP
0
X
X
X
ECN
X
X
X
1
0
(a) ECN-aware 7→ Mark forwarding.
TOS field of tunnel IP header
TOS field of user IP header
DSCP
X
X
X
ECN
X
X
X
1
DSCP
0
X
X
X
ECN
X
X
X
0
0
(b) ECN-unaware 7→ Packet dropping.
Figure 3.2.2. Different cases of ECN mark forwarding.
Figure 3.2(b). Nothing will happen if the user transport protocol is udp because
it does not provide any congestion control mechanism.
3.3
Buffer dimension optimization
If we analyze the tcp behavior we can say that the bottleneck buffer dimension
plays a crucial role on the throughput of the network and of the single mobile
user. A short queue size ensures a little rtt but also leads to a bursty utilization
of the network. Otherwise, a large buffer guarantees the tcp congestion window
enlargement but also increases the rtt of each connection leading to a lower
throughput.
We aim at finding an “optimum” value for the router buffer size that maximizes the throughput of the user taking into account also the average throughput
of the other MEs attached to the Target eNB.
62
Summary 3.4
3.4
Summary
In this chapter we have discussed the tcp behavior during the LTE handover.
We have focused our attention on rtt trend and cwnd update during the handover
time. Three different solutions have been introduced: (a) forwarding avoidance,
which concern about a modification of the handover procedure to avoid the user
data forwarding during it; (b) active queue management inside the core network
and, whose aim is to keep a lower congestion level inside the core network to
minimize the packet dropping; (c) buffer dimension optimization, which analyze
the correct choice of the buffer dimension inside the core network. In the next
chapter performance of all these solutions will be analyzed by simulations.
63
Chapter 4
Simulations and results
In this Chapter we describe briefly the simulator implementation and its environment. Then we analyze all the improvement solutions of tcp during the
LTE handover presented in Chapter 3. Furthermore, we present a validation of
mathematical model by simulations.
4.1
Simulator: ns-2
Ns-2 is a discrete event simulator. It provides substantial software resources
for simulation of tcp, routing, and multicast protocols over wired and wireless
networks.
Ns-2 has been built as an object-oriented simulator mainly developed as part
of the VINT project at the University of California in Berkeley [29]. The distribution is open source and that made the simulator widely used in the academic
community. Many extensions are available to add specific features.
Ns-2 is based on two languages: C++ for the object oriented simulator and
an OTcl interpreter to execute user’s command scripts to exploit the advantages
of both programming languages.
65
4. Simulations and results
The OTcl language represents an object oriented extension of Tcl developed
inside the ns project. It allows users to define arbitrary network topologies
composed of nodes, routers, links and shared media. It also permits to
define which protocols they want to use and to attach them to nodes. This
choice is due to the requirement of a “script” program language for the end
user and to the need of running simulations with different scenarios without
the requirement of the compiler.
The C++ language is the real core of the object oriented simulator. This
choice is due to the requirement of a fast engine for the simulator that
might become tardy if only OTcl were used.
Furthermore there are some tools included in the simulator suite that make it
more useful and user friendly:
Network animator (nam) is a graphical visualizer that assists the users to
get more insights into the simulations by visualizing packet trace data.
nam animation shows network topology, packet flows, queued and dropped
packets at buffers.
Xgraph is another tool that allows to make graphs of all necessary measurements
done during the simulation.
The most important component of the simulator ns-2 is the scheduler; its
task is to keep track if the time flow and to handle all events that occur during
the simulation.
66
Multi InteRfAce Cross Layer Extension 4.2
4.2
Multi InteRfAce Cross Layer Extension
The principal drawback of the simulator ns-2 is that it does not support currently multiple radio interfaces and lacks flexible tools for the cross-layer control
of communication systems. Moreover, in the standard distribution of the simulator, the wireless channel is modelled by an unrealistic models, which may lead
to biased results and, even if alternative implementations of the wireless channel are available, these are neither standardized nor re-usable for different radio
interfaces.
The Multi InteRfAce Cross Layer Extension for ns-2 (nsMiracle) [30] is a
framework conceived as a set of dynamic libraries which are loaded to add support
for multi-technology and cross-layering. It exploits also a patch which facilitates
the use of dynamic libraries in ns-2 [31] that allows to load in the simulator only
the necessary modules and make the simulation faster than before.
One of the primary goals of nsMiracle is to facilitate the interconnection of
different modules of the protocol stack while, at the same time, uniforming the
procedure by which multiple protocol layers are plugged into the same node.
By this extension the node structure becomes fully customizable as shown in
Figure 4.2.1 and the implementation of new modules is easier as well. Also a
cross-layer interface is available to allow in the simulation the exchange of crosslayer message inside the nodes.
All Modules within the same stack are connected to a unique structure called
NodeCore. The role of the NodeCore is twofold. First, it was designed to enable communication among Modules and thus to facilitate cross-layer design.
67
4. Simulations and results
.....
.....
Connector
Module
Layer N-1
.................
NodeCore
Module
Module
Layer N
PlugIn
Module
Module
.....
Module
.....
Layer N-2
PlugIn
Module
Layer N+1
Figure 4.2.1. Example of a general multi-layer architecture within the nsMiracle framework.
Second, NodeCore functionality consists of managing information and providing
functionalities of common interest for all Modules. Another important piece of
this architecture is the PlugIn class. PlugIns are attached to the NodeCore and
are the perfect place for cross-layer algorithms: thanks to the NodeCore, control
messages can be easily exchanged between PlugIns and protocol Modules.
The available distribution of the framework offers the porting of some typical
ns-2 module, such tcp agent, and furthermore it offers a wrapping mechanism to
port all the existing ns-2 in the framework. Also the trace files are fully modular
and every connector can be traced separately.
The main advantages offered by the nsMiracle framework are the following
• People can develop add-ons for ns-2 (e.g. introducing new agents, packet
types, protocols) without the need to modify the core simulator.
• New packet headers and types, as well as packet tracers, could be defined to
assist debugging, collection of statistics and inter-module communication.
These can also be loaded on demand according to user’s needs.
68
Multi InteRfAce Cross Layer Extension 4.2
• Dynamic libraries can be loaded at simulation time, with no need to recompile the whole ns-2 distribution or to keep different ns-2 binaries.
• The installation of third-party ns-2 extensions is made easier, thereby facilitating their dissemination.
• A sandbox is available to develop new modules that can be compiled separately from the distribution and loaded at runtime like all other dynamic
library.
• These modifications will make ns-2 more modular and scalable. Adding
new features to the simulator will be easier and backward compatibility
will be preserved.
4.2.1
nsMiracle inside LTE simulation
Given the arguments reported in the previous section, nsMiracle has been
chosen to develop the ns-2 extension for the LTE network not yet available.
Using that framework, many modules that provide us with all the required
features have been developed.
The developed components are:
LTE Module Inside this module all the features accomplished by the layer
PDCP and RLC/MAC of the real protocol stack have been implemented.
This module provides some basic schedulers for all mobiles connected to
the eNB. The scheduling policy can be chosen among Round Robin and
Weighted Fair Queue (WFQ) and one ME is scheduled each transmission
69
4. Simulations and results
time interval (TTI). This module also calculates the transport block dimension using a probabilistic distribution provided by a more complex LTE
simulator named “RedHawk” that implements in a realistic way the lower
layers. The LTE Module implements also a basic handover predictor to
evaluate the performance improvement of this mechanism.
LTE header it stores all the necessary information for data forwarding during
the handover and all control information about fragmentation and merging
of the packets done by the LTE Module.
Forwarding Module provides the forwarding feature during the handover.
Dumb Channel Module it is needed to link the MEs to the eNB. The default channel module has an inner queue system that in our module has
been removed since the scheduling already provides this feature. However
a propagation delay insertion is still available.
Queue Monitor Porting it is needed to exploit the Queue Monitor features
also under nsMiracle environment.
Web Cross-traffic Generator Porting it is needed to investigate differences
produced by different cross-traffic characteristics.
Other patches introduced to Node Core, Link Module and Routing Module
to manage the tunnel connection and the mobility trough the network.
An detailed description of all the modules we have developed is available in
Appendix A.
70
Simulation scenario 4.3
4.3
Simulation scenario
The reference scenario of all the simulation is shown in Figure 4.3.1.
Source
Cell
Router
eNodeB
Server
ME
Target Cell
Figure 4.3.1. Reference simulation scenario.
It consists of two cells served by two different eNB, a variable number of
MEs, divided among the source and the target cell. The ME doing the handover
is denoted as reference ME, while the remaining MEs are considered competitors.
There is a core network router that connects the two eNB to a server pool in
which each server works as traffic source for more MEs. When not differently
specified, the term “ME” refers to the reference ME.
The tcp version used in our simulations is tcp Reno. Even though some other
versions of tcp, such as sack, could lead to better performance [34], tcp Reno
holds a significant role also in the mobile applications since it is widely used in
the Internet.
71
4. Simulations and results
The communication beginning between each ME and server follows typical
tcp tree way handshaking[13] and typically the file transfer is started by the
server without any request except the case of http cross-traffic in which the web
page requests are randomly generated by the receiver according to an empirical
probability distribution.
Parameter
Cross-traffic
Bitrate of router links
Bitrate of server links
Latency of wired links
eNodeB queue length
Reordering
Detach time
Scheduling policy
Packet size
Value
FTP
12 M b/s
100 M b/s
2 ms
200
Enabled
30 ms
WFQ
1500 byte
Table 4.3.1. Common parameters of all simulation.
Table 4.3.1 shows the parameters common to all simulations then depending
on the investigation type, in the following section, will be used different settings
for further parameters.
4.4
Experimental results
For each category of simulations provided, first we show the specific simulation
settings than we discuss the obtained results.
72
Experimental results 4.4
Parameter
Total simulation time
Nodes attached to SeNB
Nodes attached to TeNB
Queue size
cwndM AX
Handover Time
Table 4.4.2.
4.4.1
Value
10 s
1
4
No Limit
44 ' 64 KB
4s
Simulation parameters to compare simulator and mathematical
model.
Comparison between simulator and mathematical
model
The first simulation is done to compare the mathematical model to the simulator result. Table 4.4.2 shows the settings used for both the simulator and the
Matlab/Simulinkr model implementation.
In Figure 4.4.1(a) the red line represents the simulated bitrate of the reference
ME while the black dot-dashed line is the result of the mathematical model
implementation. Also the behavior of another ME connected to Target eNB is
traced (continuous green for simulation and dot-dashed blue for the model). The
same notation is used also in Figure 4.4.1(c), which represents the rtt of the
departed packets, and in Figure 4.4.1(d), which shows the congestion window
size.
In Figure 4.4.1(b) the queue occupation level for the link between router and
Target eNB (continuous green and black dot-dashed) while dot-dashed blue and
continuous red represent the queue occupation of the link between router and
Source eNB.
73
4. Simulations and results
15
250
BW0 Math
BW1 Math
BW0
200
10
Queues[packets]
Bitrate [Mb/s]
BW1
150
100
5
eNB0 Math
50
eNB1 Math
eNB0
eNB1
0
0
1
2
3
4
5
Time[s]
6
7
8
9
0
0
10
1
(a) Bitrate.
2
3
4
5
Time[s]
6
7
8
9
10
(b) Queue occupation.
50
0.35
45
0.3
40
35
CWND [packets]
RTT [s]
0.25
0.2
0.15
30
25
20
15
0.1
ME0 Math
0.05
ME0 Math
10
ME1 Math
ME0
ME1 Math
ME0
5
ME1
0
0
1
2
3
4
5
Time[s]
(c) rtt.
6
7
8
9
ME1
10
0
0
1
2
3
4
5
Time[s]
6
7
8
9
10
(d) cwnd.
Figure 4.4.1. Model and simulation comparison (continuous line for ns-2 simulation dot-dashed lines for model).
74
Experimental results 4.4
In Figure 4.4.1(c), we can see that if the ME is connected to the TeNB, the rtt
value distribution assumes a “non zero jitter” behavior due to the scheduler that
generates random variable to assign the radio resource to each ME. Observe that
the initial SSthresh in the ns-2 simulation (Figure 4.4.1(d)) has been set to 22
MSS because the mathematical model does not implement the slow start phase.
4.4.2
Forwarding avoidance
With this simulations we investigate the benefits of the various forwarding
avoidance mechanisms.
Parameter
Total simulation time
Nodes attached to SeNB
Nodes attached to TeNB
Router queue size
cwndM AX
Handover Time
Value
5s
1
5
90
44 ' 64 KB
2÷3s
Table 4.4.3. Simulation parameters about forwarding avoidance mechanism.
Table 4.4.3 shows the key parameters. These parameters are mainly referred
to the reference ME making the handover towards Target eNB.
As discussed in Section 3.1.1, this scenario could lead to the spurious timeout
verification due to the delay introduced by the data forwarding.
Figure 4.4.2 shows the congestion window update and the rtt experienced by
all the arrived packets for all cases: (a) and (b) describe the case of standard LTE
handover procedure in which a spurious timeout occurs due to rtt increasing,
(c) and (d) depict the application of the fast path switch procedure that is not
75
0.2
45
0.18
40
0.16
35
0.14
25
0.12
RTT [s]
30
0.1
20
0.08
15
0.06
10
0.04
5
0.02
0
0
0.5
1
1.5
2
2.5
Time[s]
Handover
50
Handover
CWND [packets]
4. Simulations and results
3
3.5
4
4.5
0
5
0
0.2
45
0.18
40
0.16
35
0.14
30
0.12
RTT [s]
0.08
15
0.06
10
0.04
5
0.02
0
0.5
1
1.5
2
2.5
Time[s]
3
3.5
4
4.5
0
5
0
0.2
45
0.18
40
0.16
35
0.14
RTT [s]
15
0.06
10
0.04
5
0.02
0.5
1
1.5
2
1
1.5
0.1
0.08
0
0.5
0.12
20
0
2.5
Time[s]
3
3.5
4
(e) cwnd handover prediction case.
3
3.5
4
4.5
5
2
2.5
Time[s]
3
3.5
4
4.5
5
4.5
5
Handover
50
25
2.5
Time[s]
(d) rtt fast path switch case.
Handover
CWND [packets]
(c) cwnd fast path switch case.
30
2
0.1
20
0
1.5
Handover
50
25
1
(b) rtt standard procedure case.
Handover
CWND [packets]
(a) cwnd standard procedure case.
0.5
4.5
5
0
0
0.5
1
1.5
2
2.5
Time[s]
3
3.5
4
(f) rtt handover prediction case.
Figure 4.4.2. Reference ME connection parameters (cwnd and rtt) during the
handover.
76
Experimental results 4.4
2900
Direct OLD
Forwarding
Direct NEW
2800
Handover
Sequence Number
2850
2750
2700
2650
2600
2.6
2.7
2.8
2.9
Time[s]
3
3.1
3.2
2.6
2.7
(a) Standard procedure case.
2400
Direct OLD
Forwarding
Direct NEW
2300
Handover
Sequence Number
2350
2250
2200
2150
2100
2.1
2.2
2.3
2.4
2.5
Time[s]
(b) Fast path switch case.
Received Sequence Number
2300
Direct OLD
Forwarding
Direct NEW
Handover
Sequence Number
2250
2200
2150
2100
2050
2000
2
2.1
2.2
2.3
Time[s]
2.4
2.5
2.6
(c) Handover prediction case
Figure 4.4.3. Reference ME received sequence number.
77
4. Simulations and results
able to avoid the spurious timeout event, whereas better performance is achieved
by the handover prediction (Figure 4.4.2(e) and (f)), which avoids the spurious
timeout and causes only the window halving due to the packet dropping done by
the router buffer.
In Figure 4.4.3 we can see that between standard handover procedure and
fast path switch procedure there are negligible differences in terms of forwarded
data amount (green line in Figure 4.4.3(a) and (b)). This is due to the fact
that outstanding data correspond always to the window, intended as in (2.1.1),
and at the handover time such a quantity of data has been already pushed in the
network. On the contrary, there are no forwarded data in the handover prediction
procedure (Figure 4.4.3(c)) and that is the main reason of better performance.
4.4.3
AQM in the core network
Here we present simulations to investigate the advantages achieved by using
RED queue management instead of the typical drop-tail policy.
Parameter
Total simulation time
Nodes attached to SeNB
Nodes attached to TeNB
max p
thresh
maxthresh
Router queue size
Handover Time
Value
10 s
4
3
0.1
20
65
90
2÷3s
Table 4.4.4. Simulation parameters about AQM.
Table 4.4.4 shows the parameter settings of the simulator. The RED param-
78
Experimental results 4.4
eters have been set according to the suggestion given in [24].
Implemented
Queue Management
Drop Tail
RED (Dropping)
RED (Marking)
Link R → SeNB Link R → TeNB
Drop Rate [%]
Drop Rate [%]
2.2
3.9
2.2
3.6
2.1
3.3
Table 4.4.5. Active queue management simulation result.
From the simulation result shown in Table 4.4.5 we can see that exploiting
the RED queue management carries to more benefits in the link between router
and Target eNB because after the handover such a queue handles 4 different
tcp connection and then an increased congestion level. According to [23] we can
say that RED allows better performance with a congested network in which the
early dropping works exactly to avoid more drops due to the incoming congestion.
We conclude that if the cross network ECN is implemented, the marking
benefits also can be exploited, this reduces the drop rate specially for the more
congested link.
4.4.4
Buffer dimension optimization
Parameter
Total simulation time
Nodes attached to SeNB
Nodes attached to TeNB
Handover Time
Value
5s
2
5
2s
Table 4.4.6. Simulation parameters about buffer dimension optimization.
We have performed several simulations to check if the buffer dimension mat-
79
4. Simulations and results
ters. Table 4.4.6 shows the general configuration: the queue size for the router
buffer has been set to 30 packets, and then it has been changed every 30 simulations by a 5 packets increasing step, up to 180 packets. From all simulated result
we can extract the average bitrate during the handover (from the handover time
to one second later) for each simulation, then a second average has been done
over all the simulations with the same parameters.
5
ME(0)
other ME
Average Bitrate [Mb/s]
4.5
4
3.5
3
2.5
2
1.5
40
60
80
100
120
140
160
180
Queue size [Packets]
Figure 4.4.4. Average bitrate during handover.
Figure 4.4.4 shows the results in terms of average bitrate of both reference
ME and another ME connected to the Target eNB as function of the buffer
dimension. We see that a small buffer causes an abrupt decrease of the user
throughput (since the reference ME, before the handover, was experiencing a
bitrate of 6 M b/s) while in case of large buffer a rto expiring could occur due
to the large rtt variation.
A good choice for the buffer dimension, taking into account only the red trace
of the Figure 4.4.4, should be 85 packet but, this dimension leads to a worse
80
Summary 4.5
performance for the others attached ME. A good tradeoff between the reference
ME and other MEs is found around 140. Therefore, we conclude that the buffer
size must be carefully chosen by considering the bit rate of all mobile stations in
order to maximize the total throughput during the handover phases.
4.5
Summary
In this chapter we have given an overview on the ns-2 simulator and the nsMiracle framework. We have presented an original simulator extension. Such an
extension is then used to validate the mathematical model introduced in Chapter 2 and to analyze all the solutions to prevent tcp degradation during the
handover that have been proposed in the previous chapter.
81
Chapter 5
Conclusions and future work
In this thesis, tcp performance during the LTE handover has been analyzed,
and some enhancing solutions have been proposed. Our studying has started
from [8], where a data forwarding mechanism for the handover has been studied.
The solution therein proposed ensures in-sequence delivering of packets but, in
the meantime, it may lead to spurious timeout due to a sudden rtt increase.
To achieve better performance of tcp during LTE handover, we have proposed two modification to the LTE handover procedure by sending the path
switch request simultaneously, or before the handover command. We have also
investigated the throughput variation during handover depending on the buffer
size of transport network router and the impact of an active queue management,
such as RED, inside core network.
Simulation results have shown that sending the path switch request simultaneously with the handover command does not lead to a performance improvement
while, if a handover prediction algorithm is implemented all the forwarding procedure could be avoided leading to better performance in terms of user throughput.
We have seen a slight performance enhancement in terms of dropping rete
83
5. Conclusions and future work
inside the transport network if an AQM policy is enabled inside the core network
and that the buffer size must be carefully chosen by considering the bit rate of all
mobile stations in order to maximize the total throughput during the handover
phases.
As future work a mathematical model for optimization of internal router buffer
dimension could be investigated to achieve better performance.
84
Appendix A
Simulator extension
We have implemented an ns-2 based simulator under the nsMiracle framework.
A.1
Modules used inside the simulator
Thanks to the full customizable structure of the used framework many modules have been exploited to build our scenario. Following a top down approach
we describe all them highlighting the major features.
A.1.1
Application layer
It is the higher level of the protocol stack. All the modules in this layer provide
functionalities that are typical to traffic generators. The modules are:
FTP traffic generator
It is a simple module that provides an unlimited quantity of data to be transmitted. It is used mainly to check the available resources of the network and to
study the network resource wasting.
85
A. Simulator extension
Exponential traffic generator
This traffic generator represents a rough approximation of the voice load for
the network. It is used mainly as cross-traffic without any type of congestion
control mechanism.
HTTP traffic generator
This module has been ported in the nsMiracle framework to permit the presence of a non heavy load cross-traffic with congestion control on the file transfer.
It is available on the non-persistent [32] and in the persistent [33] version.
The module can be used only as a cross-traffic generator because it does not
implement any of the real http signaling and its functioning is based on statistical
characterization of Internet traffic.
A.1.2
Transport layer
In this layer we can find two different modules that provide all its typical
functions.
Transport module
It is about a wrap for the common ns-2 transport agent like all the tcp version
and it works just like an interface between the framework and the simulator core
agent. tcp Reno is the transport protocol used for our analysis.
Port module
It provides the typical multiplexing/demultiplexing feature of the transport
layer and allows to handle many tcp agents on the same node
86
Modules used inside the simulator A.1
A.1.3
Network layer
This is the core of a network. It provides all the features related to the routing.
In this layer two modules are exploited:
Network interface module
It is the connection between the routing feature and the different data network
technologies. Under such a layer many different modules can be connected, such
as the LTE module in our case.
Routing module
It provides mainly the routing feature and it can be connected to many network interfaces. It works as a crossroads for the incoming packet and handles the
next hop decision or the forwarding to the upper layer.
A.1.4
Lower layer
It represents all the layers under the Network interface module. For all the
cases in which we want to represent a wired network we can connect the above
layers directly to a link. Otherwise, it is necessary to use another module to give
an abstraction of the applied network technology.
Link module
It is mainly used to connect the lowest layer of nodes. It implements a queue
model and also a queue monitor to trace the link status.
87
A. Simulator extension
1
Low interference
High interference
0,9
0,8
0,7
CDF
0,6
0,5
0,4
0,3
0,2
0,1
0
0
1000
2000
3000
4000
5000
6000
7000
8000
9000
10000
11000
12000
13000
14000
15000
16000
17000
TB size [bit]
Figure A.1.1. CDF of the transport block size for Low and High interference
(simulation settings summarized in Table A.1.1).
Number of users in the system
Cellular layout
Inter-site distance
Velocity of users
Air interface
Uplink scheduler
Retransmission mode (HARQ mode)
Bandwidth
Number of PRBs in uplink
Maximum base station power
Total UE power
Distance-dependent path gain
Shadow fading standard deviation
SINR backoff
Simulation time
Random seed
Low Load
High Load
1
3
3 eNodeB, 1 cell per eNodeB
866 m
20 m/s
SC-FDMA
Multi-cell uplink scheduler
Synchronized Non-Adaptive
5 M Hz
25
20 W
250 mW
−29.03 − 35.2log10 (R)
8 dB
0.5 dB
100 s
1
Table A.1.1. RedHawk configuration parameters.
88
Modules used inside the simulator A.1
LTE module
It gives an abstraction of the LTE PDCP and RLC/MAC layer. A dedicated buffer architecture is implemented. All the attached UE can exploit the
availability of two dedicated FIFO buffer (a normal buffer and a priority buffer
used during the handover procedure to allow the packet reordering). It provides
also the segmentation/reassembly feature combined with the merging of different
PDCP context. All the necessary signaling procedures flow through the LTE
header created on purpose.
It provides two basic scheduling algorithm such Round Robin and WFQ and
each TTI one UE us scheduled to communicate. The amount of the deliverable
data is generated according to the CDF shown in Figure A.1.1 provided by an
accurate simulator for the lower layer (Simulations settings are summarized in
Table A.1.1). The random number generation to calculate the TB size is done
according to


 y(n) = αy(n − 1) + (1 − α) x(n) for n ≥ 0;

 y(−1) = x(−1)
(A.1.1)
it is the seed.
where x(n) is the realization of a random variable whose PDF is uniformily distributed in [0, 1], y(n) will keep memory of realizations according to the weight
α. y(n) will be used to invert the CDF function of the TB size so to obtain the
available bandwidth at each scheduling interval.
Forwarding module
It is a part of the simulator extension that provides the data forwarding feature
during the handover. It is located inside the eNB module stack and uses the
89
A. Simulator extension
information inside the LTE header to implement this feature.
A.2
Nodes overview
All nodes are implemented with custom module stack exploiting all features
available in the framework and are further described in the following section.
Server node
App #1
App #2
...
App #n
TCP #1
TCP #2
...
TCP #n
Port Module
Routing Module
Network Interface
Link Module
Figure A.2.1. Module stack of the server node.
It represents the source or the traffic, in the application layer we can find any
of the module depicted in the Section A.1.1. It can work as source for many sinks
and then the port module manages this multiplexing/demultiplexing mechanism.
The link module at the bottom is configured as a real link in which we can set
bandwidth, propagation delay, queue management and queue size.
Router node
The main characteristic of this node is the multiple network interface to handle
the routing inside the network. The first interface links the router to the severs,
the other two interfaces provide the connections towards both Source and Target
90
Nodes overview A.2
Routing Module
Network #1
Network #2
Network #3
Link #1
Link #2
Link #3
Figure A.2.2. Module stack of the router node.
eNB.
eNB node
Routing Module
Network #1
Forwarding
LTE Module
Network #2
Link Module
Link Module
Figure A.2.3. Module stack of the eNB node.
This node works as interface between the wired core network and the wireless
access network. Under the first network interface there are the modules that
provide the abstraction of the LTE lower layer. Furthermore, the link under the
LTE module is configured as an ideal link because all the parameters concerning
bandwidth, queue size and propagation delay, are directly or indirectly inside the
LTE module.
91
A. Simulator extension
TCP Sink
Port Module
Routing Module
Network Interface
Link Module
Figure A.2.4. Module stack of the mobile equipment node.
ME node
It is the simplest node of the chain, it has the same configuration of the server
but without any module in the application layer, because the sink provide the
necessary acknowledgement to the tcp source.
92
Bibliography
[1] Matteo Pacifico, “Modeling and Performance Improvement of tcp over LTE
Handover ”, Msc Thesis, February 2009.
[2] Bajzik, Horvath, Korossy, and Vulkan, “Impact of Intra-LTE Handover with
Forwarding on the User Connections”, Mobile and Wireless Communications, 2007.
[3] Niels Möller, “Window-based congestion control - Modeling, analysis and
design”, Phd Thesis, January 2008.
[4] Krister Jacobsson, “Dynamic modeling of Internet congestion control ”, Phd
Thesis, April 2008.
[5] Ojanperä, Prasad, “WCDMA: Towards IP Mobility and Mobile Internet”,
Artech House, 2001.
[6] 3GPP TS 36.300, “Evolved UTRA and evolved UTRAN, overall description”,
http://www.3gpp.org/ftp/Specs/archive/36_series/36.300/, 2006.
[7] R. van Nee, R. Prasad, “OFDM for Multimedia Wireless Communications”,
Artech House, 2000.
93
Bibliography
[8] A. Racz, A. Temesvary, N. Reider, “Handover Performance in 3GPP Long
Term Evolution (LTE) Systems”, Mobile and Wireless Communications
Summit, 2007.
[9] 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”,
http://www.3gpp.org/ftp/specs/archive/23_series/23.402/, 2006.
[10] 3GPP TS 25.913, “Requirements for Evolved UTRA (E-UTRA) and Evolved
UTRAN (E-UTRAN)”, http://www.3gpp.org/ftp/specs/archive/25_
series/25.913/, 2006.
[11] 3GPP TS 36.101, “E-UTRA and UE radio transmission and reception”,
http://www.3gpp.org/ftp/Specs/archive/36_series/36.300/, 2008.
[12] J. Wang, D. X. Wei, and S. H. Low. “Modelling and stability of fast tcp.
In Proceedings of IEEE Infocom, Miami, March 2005.
[13] J. Postel, “RFC 793: Transmission Control Protocol ”, IETF, Tech. Rep.,
September 1981.
[14] J. Postel, “RFC 768: User Datagram Protocol ”, IETF, Tech. Rep., August
1980.
[15] M. Allman, V. Paxson, and W. R. Stevens, “RFC 2581: tcp congestion
control ”, IETF, Tech. Rep., April 1999.
[16] Dahlen and P. Ernstrm, “tcp over umts”, RVK02, 2002.
94
Bibliography
[17] 3GPP TS 29.060, “GPRS tunnelling protocol across the Gn and Gp interface (Rel 7)”, http://www.3gpp.org/ftp/specs/archive/29_series/29.
060/, 2006.
[18] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, “RFC 2018: tcp selective acknowledgment options”, IETF, Tech. Rep., April 1996.
[19] M. Allman, S. Floyd and C. Partridge, “RFC 3390: Increasingtcp’s initial
window ”, IETF, Tech. Rep., October 2002.
[20] G. Xylomenos, G. C. Polyzos, M. Saaranen, and P. Mähönen, “tcp/ip Performance over Wireless Networks”, M. HASSAN and R. JAIN, Eds. PRENTICE HALL, 2002.
[21] K. Ramakrishnan, S. Floyd and D. Black, “RFC 3168: The Addition of
Explicit Congestion Notification (ECN) to ip”, IETF, Tech. Rep., September
2001.
[22] L. Le, J. Aikat, K. Jeffay and F. D. Smith, “The effects of active queue management on web performance”, In Proceedings of the 2003 conference on
Applications, technologies, architectures, and protocols for computer communications, Karlsruhe, 2003.
[23] S. Floyd and V. Jacobson, “Random Early Detection Gateways for Congestion Avoidance”, Transactions on Networking, August 1993.
[24] S. Floyd, “RED: Discussions of Setting Parameters”, November 1997, http:
//www.aciri.org/floyd/REDparameters.txt.
95
Bibliography
[25] W. Feng, D. Kandlur, D. Saha, and K. Shin, “A Self-Configuring RED Gateway”, Infocom, March 1999.
[26] Tae-Hyong Kim, Qiping Yang, Jae-Hyoung Lee, Soon-Gi Park and YeonSeung Shin, “A Mobility Management Technique with Simple Handover Prediction for 3G LTE Systems”, Vehicular Technology Conference, 2007.
[27] Hyeyeon Kwon, Mi-Jeong Yang, Ae-Soon Park and S.Venkatesan, “Handover
Prediction Strategy for 3G-WLAN Overlay Networks”, Network Operations
and Management Symposium, April 2008.
[28] Nicola Baldo, Federico Maguolo, Marco Miozzo, Michele Rossi and Michele
Zorzi, “ns2-MIRACLE: a Modular Framework for Multi-Technology and
Cross-Layer Support in Network Simulator 2 ”, NSTools ’07, October 2007,
Nantes, France.
[29] “The network simulator ns-2 ”, http://www.isi.edu/nsnam/ns/.
[30] “ns-MIRACLE: Multi InteRfAce Cross Layer Extension for ns-2 ”, http:
//www.dei.unipd.it/ricerca/signet/tools/nsmiracle.
[31] “Dynamic Modules in ns-2 ”, http://telecom.dei.unipd.it/ns/miracle/
ns_dynamic_libraries/.
[32] T. Berners-Lee, R. Fielding and H. Frystyk, “RFC 1945: Hypertext Transfer
Protocol (HTTP/1.0)”, IETF, Tech. Rep., May 1996.
[33] R. Fielding, J. Gettys and H. Frystyk, “RFC 2616: Hypertext Transfer Protocol (HTTP/1.1)”, IETF, Tech. Rep., May 1996.
96
Bibliography
[34] F. Xinz and A. Jamalipour, “TCP throughput and fairness performance in
presence of delay spikes in wireless networks”, International Journal of Communication Systems, March 2005.
[35] A. Speranzon Fischione C. and K.H. Johansson, “Distributed and collaborative estimation over wireless sensor networks”, IEEE Conference on Decision
and Control, 2006.
[36] A. Speranzon Fischione C. and K.H. Johansson, and A. SangiovanniVincentelli, “A Distributed Minimum Variance Estimator for Sensor Networks”, IEEE Journal on Selected Areas in Communications, Special Issue
on Control and Communication, May 2008, p. 609-621, vol. 26.
[37] Speranzon Fischione C. and K.H. Johansson, and A. Sangiovanni-Vincentelli,
“Peer-to-Peer Estimation over Wireless Sensor Networks via Lipschitz Optimization”, ACM/IEEE IPSN, 2009.
97
Was this manual useful for you? yes no
Thank you for your participation!

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

Download PDF

advertising