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, one 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 inexpensive in changing test configurations and running test cases through modeling and simulation. 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 interface and S1 interface. At last, testing result of one scenario is given to demonstrate how to use this model.
I. Introduction
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 reduce protocol processing 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 this way: firstly, 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 to 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 eNBs, 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 EPC (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. The E-UTRAN architecture is illustrated in Figure 1.[3]
The protocol stack for the user-plane is shown in Figure 2, where PDCP, RLC and MAC sublayers (terminated in eNB on the network side) perform the functions listed for the user plane, e.g. header compression, ciphering, scheduling, ARQ and HARQ;
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.
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. 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 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.
- 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 interface 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, network 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 exit 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 screening. 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). [4] [5]
B. NS 2 overview
NS 2 began as a variant 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 DARPA 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.[6]
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) networks. 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/SAE.
II. Network model and configuration
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 optimization features; others can not be changed so easily due to the limitation of the implemented model, such as eNB and aGW number. The LTE/SAE network model and configuration are described in detail in the following sections.
A. Network model
In our simulated LTE/SAE 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.
Figure 4 LTE/SAE network 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.[7] 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 needed. 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 the 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: [8]
- The intra E-UTRAN handover in RRC_CONNECTED 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;
- Network signals reporting criteria for event-triggered and possibly periodical reporting.
In our current model, handover process is simplified that UE always stays in the same cell. The handover model will be improved in the later study.
B. Network configuration
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 in Figure 5. The common implementation, such as whether the optimization feature is used, is defined in the parent class LTEQueue; the interface and direction specific implementation is defined in other four new queue classes.
Classification
When one packet enters LTEQueue, the packet is classified to its corresponding sub-queue according to its classid. If the QoS feature is triggered, the packet of class 0, class 1 and class 2 enters DropTail sub-queue respectively; the packet belonging 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, strict priority is used when there is one packet can be sent, i.e. the packet to 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. Traffic model and configuration
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 different 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. [8]
There are four different QoS classes:
- conversational class;
- streaming class;
- interactive class; and
- background 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.
Conversational 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 applications 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 Interactive class is mainly used by interactive applications, e.g. interactive 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 interactive 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 [8]) 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 requirements on delay.
B. Traffic configuration
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 of 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 speech
|
- 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/Client
- HTTP/Cache
- HTTP/Server
|
- FTP/TcpAgent
|
Main configuration 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 interval
|
- configure the TCP parameters
|
IV. Testing rsult of the model
This section demonstrates 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. Configure the network model’s parameter: such as the number of UEs, 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 statistic 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. Conclusion
In this paper, a LTE/SAE model and its implementation 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 improve the performance of the LTE/SAE network in the future.