LTE/SAE Model and its Implementation in NS 2

anisesecretaryΚινητά – Ασύρματες Τεχνολογίες

12 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

815 εμφανίσεις

LTE/SAE Mod
el and its Implementation in NS
2




Abstract


Expectation and requirements for future wireless communication systems continue to grow and evolve. Thus, 3GPP has
considered LTE/SAE to ensure its competitiveness in the future.
In LTE/SAE, o
ne

of the recurring problems is dimensioning and
testing, while model is the effective way to solve this problem because model is easy to generate test scenarios and inexpens
ive in
changing test
configurations

and running test cases through modeling and simu
lation. The objective of this paper is to introduce how to
build an accurate enough LTE/SAE model in NS

2 so that other optimization features can be tested. The simulation model includes
traffic model and network model which concentrates on the air interfa
ce and S1 interface. At last, testing result of one scenario is given
to demonstrate how to use this model.

I.


I
NTRODUCTION

LTE/SAE is an attempt to step into wireless broadband taken by cellular providers and equipment vendors. LTE/SAE
introduces evolved
radio interface with major enhancement coming from the use of Orthogonal Frequency Division Multiplexing
(OFDM) and multiple antenna techniques.
[1]

These technologies are already available on the market and employed in WiMAX as

specified in IEEE 802.16 standard.
[2]

Along with the evolved radio interface, LTE/SAE specifies the evolution of network
architecture. It is designed to be packet
-
based and contain less network
elements which

reduc
e

protocol p
rocessing overhead
,
latency

and network deployment costs.

This paper

will study LTE/SAE model and its implementation in NS2, and this task is the further study of the earlier one
[3]
.

This paper
is organized in thi
s way: first
ly, the
LTE/SAE
overview
and the simulation tool NS

2
are

described; secondly, the
network model and its configuration in NS

2 are introduced. Thirdly, the traffic model and its configuration are presented. At last,
we give an example to demonstrate how to

use the model t
o analyze the performance of LTE/SAE
.

A.

LTE/SAE overview

LTE/SAE is an Evolved Packet System (EPS) which includes the Evolved Universal Terrestrial Radio Access Network (E
-
UTRAN) and the evolved Packet Core (EPC).

The E
-
UTRAN consists of eNB
s, providing the E
-
UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC)
protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are
also connected by means of the S1 interface to the EP
C (Evolved Packet Core), more specifically to the MME (Mobility
Management Entity) by means of the S1
-
MME and to the Serving Gateway (S
-
GW) by means of the S1
-
U. The S1 interface
supports a many
-
to
-
many relation between MMEs / Serving Gateways and eNBs. Th
e E
-
UTRAN architecture is illustrated in
Figure
1
.
[4]


eNB
MME
/
S
-
GW
MME
/
S
-
GW
eNB
eNB
S
1
S
1
S
1
S
1
X
2
X
2
X
2
E
-
UTRAN

Figure
1

E
-
UTRAN architecture

The protocol stack for the user
-
plane is shown in
Figure
2
, wher
e PDCP, RLC and MAC sublayers (terminated in eNB on the
network side) perform the functions listed f
or the user plane
, e.g. header compression, ciphering, scheduling, ARQ and HARQ;


eNB
PHY
UE
PHY
MAC
RLC
MAC
PDCP
PDCP
RLC

Figure
2

user
-
plane protocol stack

The protocol
stack for the control
-
plane is shown in
Figure
3
, where:

-

PDCP sublayer (terminated in eNB on the network side) performs the ciphering and integrity protection functions;

-

RLC and MAC sublayers (terminated in eNB on the network
side) perform the same functions as for the user plane;

-

RRC (terminated in eNB on the network side) performs the following functions:

-


Broadcast;

-

Paging;

-

RRC connection management;

-

RB control;

-

Mobility functions;

-

UE measurement reporting and
control.

-

NAS control protocol (terminated in MME on the network side) performs among other things:

-

EPS bearer management;

-

Authentication;

-

ECM
-
IDLE mobility handling;

-

Paging origination in ECM
-
IDLE;

-

Security control.


eNB
PHY
UE
PHY
MAC
RLC
MAC
MME
RLC
NAS
NAS
RRC
RRC
PDCP
PDCP

Figure
3

control
-
plane protocol stack

The main component of the SAE architecture is the Evolved Packet Core (EPC), also known as SAE Core. The EPC will serve
as equivalent of GPRS networks (via the Mobility Management Entity, Serving Gateway and PDN Gateway

subcomponents). The
subcomponents of the EPC are
:

-

MME (Mobility Management Entity): The MME is the key control
-
node for the LTE access
-
network. It is responsible for
idle mode UE (User Equipment) tracking and paging procedure including
retransmissions. I
t

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 in
tra
-
LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the
user (by interacting with
the 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 roamin
g UEs.

-

S
-
GW (Serving Gateway): The S
-
GW 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 in
terface and relaying the traffic between 2G/3G systems and PDN
-
GW). For idle state UEs, the S
-
GW
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, n
etwork internal routing information. It also performs replication of the user traffic in
case of lawful interception.

-

PDN
-
GW (Packet Data Network Gateway): The PDN
-
GW provides connectivity to the UE to external packet data networks
by being the point of e
xit and entry of traffic for the UE. A UE may have simultaneous connectivity with more than one
PDN
-
GW for accessing multiple PDNs. The PDN
-
GW performs policy enforcement, packet filtering for each user, charging
support, lawful Interception and packet scr
eening. Another key role of the PDN
-
GW is to act as the anchor for mobility
between 3GPP and non
-
3GPP technologies such as WiMAX and 3GPP2 (CDMA 1X and EvDO).

[5]
[6]

B.

NS

2 overview

NS 2 began as a v
ariant of the REAL network simulator in 1989 and has evolved substantially over the past few years. In 1995
NS development was supported by DARPA through the VINT project at LBL, Xerox PARC, UCB, and USC/ISI. Currently NS
development is support through DAR
PA with SAMAN and through NSF with CONSER, both in collaboration with other
researchers including ACIRI. NS has always included substantial contributions from other researchers, including wireless code

from the UCB Daedelus and CMU Monarch projects and Sun

Microsystems.
[7]

NS 2 is a discrete event simulator targeted at networking research. NS

2 provides substantial support for simulation of TCP,
routing, and multicast protocols over wired and wireless (local and satellite)
netwo
rks. In

the
NS 2
simulation, all the data
in the
network
is available, thus the performance of
the
network can be easily analyzed.
What’s more,
NS

2 is free and open source code

and
suitable to build system level simulation
, so we use it to simulate LTE/SA
E.

II.

N
ETWORK MODEL AND CON
FIGURATION

In our model, some network configuration parameters can easily be changed
with

TCL (Tool Command Language), for
example we

can define any number of UE, bandwidth between the network elements and the use of the optimizati
on features
;
others can not be changed so easily

due to the limitation of the implemented model
, such as eNB and aGW number.
T
he LTE/SAE
network model and configuration

are described
in detail in the following sections.

A.

Network model

In our simulated LTE/S
AE network, the following network elements are included:



1 server (provide HTTP, FTP and signaling services).



1 aGW (provide HTTP cache, flow control).



1 eNB (provide flow control information).



Many UEs.


UE
eNB
aGW
Server
DLS1Queue
ULS1Queue
DropTail
DLAirQueue
ULAirQueue
RTPAgent/
RTCPAgent
UdpAgent
TcpAgent
Session
CBR
HTTP/Server
FTP
TcpAgent
HTTP/Cache
RTPAgent/
RTCPAgent
NullAgent
TcpAgent
Session
TcpSink
HTTP/Client

Figure
4

LTE/SAE
networ
k model

Flow control

One of the key targets for the evolution of the radio
-
interface and radio
-
access
network

architecture is 100Mbps peak data rate
in downlink.
[8]

While compared to the lined data rate, the wireless data rate
is still a bottleneck. This means if we do not do the
flow control

in aGW
,
packets

will be buffered in eNB. While the buffer in eNB is limited, packets may be
dropped
.
To

reduce the
harm to the performance of the TCP from packet loss, flow control is neede
d. In our model, DLAirQueue provides each flows
information, such as buffer size and average data rate; DLS1Queue uses this information and current packet size to decide
whether

the packet is allowed to be sent to DLAirQueue. If the buffer of the flow or t
he cell where the flow locates is going to be overflow,
the packet is blocked until both the flow’s buffer and cell’s buffer is not overflow.

Handover

Following defines the handover support within E
-
UTRAN
:
[9]


-

The intra E
-
UTR
A
N handover

in RRC_C
ONNECTED state is UE assisted network

controlled
handover

with
handover

preparation
signaling

in E
-
UTRAN.

-

In E
-
UTRAN RRC_IDLE state, cell reselections are performed and
DRX (Discontinuous Reception)

is supported.

In E
-
UTRAN RRC_CONNECTED

state, network controlled UE assisted handovers are performed and various DRX/DTX

(Discontinuous Transmission)

cycles are supported:

-

UE performs
neighbor

cell measurements based on measurement control and
neighbor

cell information from the network;

-

Ne
twork signals reporting criteria for event
-
triggered and possibly periodical reporting.

In our current model, handover process is
simpl
ified

that UE always stays in the same cell.

T
he handover model
will

be
improved

in the later study
.

B.

Network configuratio
n


Queue
LTEQueue
DLS1Queue
ULS1Queue
DLAirQueue
ULAirQueue
REDQueue
DropTail

Figure
5

Queue classes

In
the

model, new queue classes, such as LTEQueue,
ULAirQueue, DLAirQueue, ULS1Queue and DLS1Queue
, are implemented

to simulate the air interface and S1 interface. The queue
class
inheritance is showed i
n
Figure
5
.

The common implementation,
such as whether the optimization feature is used, is defined in the parent class LTEQueue; the interface and direction specif
ic
implementation is defined in other four new
queue
classes.

Clas
sification

When one packet enters LTEQueue, the packet is
classified

to its
corresponding

sub
-
queue according to its
classid
.
If the QoS
feature is triggered, t
he packet
of

class 0, class 1
and

class 2
enters

DropTail

sub
-
queue

respectively
; the packet bel
onging to class 3
enters

REDQueue

sub
-
queue
; if the QoS feature is not triggered, all the packets enter the same DropTail sub
-
queue.

Scheduling

If the QoS feature is triggered, s
trict priority is used when there is one packet can be sent, i.e. the packet t
o be sent is always in the
flowing order class 0, class 1, class 2
and class 3;
if the QoS feature is not triggered, round
-
robin is used to send one packet.

III.

T
RAFFIC MODEL AND CON
FIGURATION

A.

Traffic model


When defining the UMTS QoS classes, also referred to

as traffic classes, the restrictions and limitations of the air interface
have to be taken into account. It is not reasonable to define complex mechanisms as have been in fixed networks due to differ
ent
error characteristics of the air interface. The QoS
mechanisms provided in the cellular network have to be robust and capable of
providing reasonable QoS resolution.
[10]

There are four different QoS classes:

-

conversational class;

-

streaming class;

-

interactive class; and

-

b
ackground class.

The main distinguishing factor between these QoS classes is how delay sensitive the traffic is: Conversational class is meant

for
traffic which is very delay sensitive while Background class is the most delay insensitive traffic class.

Con
versational and Streaming classes are mainly intended to be used to carry real
-
time traffic flows. The main divider between
them is how delay sensitive the traffic is. Conversational real
-
time services, like video telephony, are the most delay sensitive
ap
plications and those data streams should be carried in Conversational class.

Interactive class and Background are mainly meant to be used by traditional Internet applications like WWW, Email, Telnet,
FTP and News. Due to looser delay requirements, compare
to conversational and streaming classes, both provide better error rate
by means of channel coding and retransmission. The main difference between Interactive and Background class is that Interacti
ve
class is mainly used by interactive applications, e.g. i
nteractive Email or interactive Web browsing, while Background class is
meant for background traffic, e.g. background download of Emails or background file downloading. Responsiveness of the
interactive applications is ensured by separating interactive and

background applications. Traffic in the Interactive class has higher
priority in scheduling than Background class traffic, so background applications use transmission resources only when interac
tive
applications do not need them. This is very important in

wireless environment where the bandwidth is
low compared to fixed
networks.

However, these are only typical examples of usage of the traffic classes. There is in particular no strict one
-
to
-
one mapping
between classes of service (as defined in TS 22.105
[11]
) and the traffic classes defined in this TS. For instance, a service
interactive by nature can very well use the Conversational traffic class if the application or the user has tight requirement
s on delay.

B.

Traffic configurat
ion

The QoS supporting in LTE/SAE is simulated.
Table
1

illustrates the QoS classes and simulated traffic for
LTE/SAE
.

Table
1

Traffic classes in LTE/SAE

Traffic class

Conversational class


Streaming class


Interactive class


Background

Fundamental
characteristics

-

Preserve time relation
(variation) between
information entities of the
stream

-

Conversational pattern
stringent and low delay

-

Preserve time relation
(variation) between
information entities o
f
the stream

-

One way
transport

-

Request response
pattern

-

Preserve payload
content

-

Destination is not
expecting the data
within a

certain
time

-

Preserve payload
content

Example of the
application

-

voice over IP

-

video conferencing

-

telephony sp
eech

-

streaming video/audio

-

Web browsing

-

Database retrieval

-

Server access

-

background
download of emails,
database,
measurement
records

Simulation traffic

Session/RTP

-

Session/RTPAgent

-

Session/RTCPAgent

-

CBR/UdpAgent

HTTP/TcpAgent

-

HTTP/Clien
t

-

HTTP/Cache

-

HTTP/Server

-

FTP/TcpAgent

Main c
onfiguration

parameters

-

AMR rate

-

multi
-
side call

-

RTP interval

-

RTP packet size

-

CBR rate

-

CBR packet size

-

random noise in the
interval

-

average page size

-

average page age

-

average request in
terval

-

configure the TCP
parameters



IV.

T
ESTING RSULT OF THE
MODEL

This section
demonstrate
s

how to use
the

model to do other
optimization of LTE/SAE network:

1.

Configure the simulation time, routing protocol, used feature

(such as QoS, flow control)
.

2.

Confi
gure the network model’s par
ameter: such as the number of UE
s, buffer size of each class
.

3.

Configure the traffic model’s parameter: such as the packet size,
data rate.

4.

Run the
simulation
with the test script.

5.

Analyze the test result
according to the statis
tic file
.

Evaluation of the network performance is mainly based on the following criteria (These values can be got directly from the
statistics file):



throughput



average delay



packet lost percent

Here is the example of one scenario:


From above figures,
we can see




V.

C
ONCUSION

In this paper, a
LTE/SAE

model and it
s imple
mentatio
n in NS

2

are presented
.
To

get more exact model, some
additional

work
needs to be done, such as
handover

model
.
We will study some optimization algorithms
based
on this model to i
mprove the
performance of the LTE/SAE network

in the future
.

R
EFERENCES

[1]


“Clash of the Titans


WiMAX and 4G: The Battle for Convergence is joined,” Market report, Maravedis Research and Analysis, July 2006.

[2]


IEEE Std. 802.16
-
2001, IEEE Standard for Local
and Metropolitan Area Networks, part 16, “Air Interface for Fixed Broadband Wireless Access Systems,”
IEEE Press, 2001.

[3]

Qinlong Qiu, Dongmei Zhang, Jian Ma, “GPRS network model in NS 2”, in proceedings of IEEE The Joint Conference of 10th Asia
-
Pacific Conf
erence on
Communications and 5th International Symposium on Multi
-
Dimensional Mobile Communications, Aug. 29


Sep.1, 2004, Tsinghua University, Beijing,
China, pp.700~704.

[4]

3GPP TS 36.300
,
3rd Generation Partnership Project;

Technical Specification Group R
adio Access Network;

Evolved Universal Terrestrial Radio Access
(E
-
UTRA) and Evolved Universal Terrestrial Radio Access Network (E
-
UTRAN);Overall description;Stage 2

(Release 8)
,
650 Route des Lucioles
-

Sophia
Antipolis

Valbonne


FRANCE
,
2009
-
03
.

[5]

3GPP TS

23.401, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio S
ervice (GPRS)
enhancements for Evolved Universal Terrestrial Radio Access Network (E
-
UTRAN) access (Release 9) 650 Route des Lucio
les
-

Sophia Antipolis Valbonne


FRANCE, 2009
-
03.

[6]

3GPP TS 23.402, 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Architecture e
nhancements for non
-
3GPP accesses (Release 9) 650 Route des Lucioles
-

Sophia An
tipolis Valbonne


FRANCE, 2009
-
03.

[7]

NS
-
2 notes and documents, VINT project,
http://www.isi.edu/nsnam/ns
.

[8]

3GPP TR 25.913
,
3rd Generation Partnership Project;

Technical Specification Group Radio Access Network;

Re
quirements for Evolved UTRA (E
-
UTRA)
and Evolved UTRAN (E
-
UTRAN)

(Release 8)
,
650 Route des Lucioles
-

Sophia Antipolis

Valbonne


FRANCE
,
2008
-
12
.

[9]

3GPP TR 25.813
, 3
rd Generation Partnership Project;

Technical Specification Group Radio Access Network;

Evol
ved Universal Terrestrial Radio Access
(E
-
UTRA) and Evolved Universal Terrestrial Radio Access Network (E
-
UTRAN);

Radio interface protocol aspects

(Release 7)
,
650 Route des Lucioles
-

Sophia Antipolis

Valbonne


FRANCE
,
2006
-
9
.

[10]

3GPP TS 23.107, 3rd Generat
ion Partnership Project; Technical Specification Group Services and System Aspects; Quality of Service (QoS) concept and
architecture (Release 8), 650 Route des Lucioles
-

Sophia Antipolis Valbonne


FRANCE, 2008
-
12.

[11]

3GPP TS 22.105, 3rd Generation Partners
hip Project; Technical Specification Group Services and System Aspects Service aspects; Services and service
capabilities (Release 9), 650 Route des Lucioles
-

Sophia Antipolis Valbonne


FRANCE, 2008
-
12.