Simulation analysis of RLC/MAC for UMTS in Network Simulator version 2

Examensarbete utfrt i Kommunikationssystem av

Anders Bjrsson
LITH-EX-3399-2003 Linkping 2003

Simulation analysis of RLC/MAC for UMTS in Network Simulator version 2

Examensarbete utfrt i Kommunikationssystem vid Linkpings tekniska hgskola av

Anders Bjrsson
LITH-EX-3399-2003 Linkping 2003

Handledare: Frida Gunnarsson Examinator: Fredrik Gunnarsson Linkping 2003-12-19

Avdelning, Institution Division, Department

Datum Date 2003-12-19

Institutionen fr systemteknik 581 83 LINKPING

Sprk Language Svenska/Swedish X Engelska/English Rapporttyp Report category Licentiatavhandling X Examensarbete C-uppsats D-uppsats vrig rapport ____ ISBN ISRN LITH-ISY-EX-3399-2003 Serietitel och serienummer Title of series, numbering ISSN

URL fr elektronisk version http://www.ep.liu.se/exjobb/isy/2003/3399/

Titel Title Frfattare Author

Simulering av RLC/MAC fr UMTS i Network Simulator version 2 Simulation analysis of RLC/MAC for UMTS in Network Simulator version 2 Anders Bjrsson

Sammanfattning Abstract The Internet has mainly been interconnecting stationary computers by wired links, but an increasing number of mobile clients require wireless communication. One way to connect these clients is to use the Universal Mobile Telecommunication System, UMTS. UMTS is a third generation mobile system. A network can be seen as nodes interconnected by links. The functionality of the nodes can be described as a layered hierarchy. A reference model for this hierarchy was developed by OSI. In this model the second lowest layer is called data link layer. The data link layer is responsible for making the raw transmission appear error free to upper layers. The focus for this thesis is the data link layer in the UMTS. Compared to the data link layer in a wired scenario it contains more control and error correction mechanisms. These mechanisms use a lot of timers and triggers, which makes it very difcult to analyze them mathematically. Therefore simulation is the preferred method. For the simulations the network simulator version 2 was used. This is an open source discrete event simulator. It has a modularized wireless stack already implemented. This can not be used to simulate UMTS though. Some modules in this stack were replaced by a new implementation to make simulations on UMTS possible. Tests were performed on the new implementation and the results were what could be expected. The results were also consistent with previous research in the area. Nyckelord Keyword network, simulation, 3G, UMTS, MAC, RLC

Table of contents
CHAPTER 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.1 1.2 1.3 1.4 1.5 1.6 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reading Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbreviations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 3 4 5 5 5

CHAPTER 2 Network Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

2.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Design and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 Elements of Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 Error Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.4 Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5 Wireless Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

CHAPTER 3 Radio Link Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

3.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Transport Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2 Unacknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.3 Acknowledged Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Retransmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Status Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 13 14 15 15 17 18 19 19

CHAPTER 4 Medium Access Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

4.1 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 Multiplexing Modes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Time Division Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4.2 Frequency Division Duplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Channels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.6 High Speed. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 21 21 22 22 22 22 23 23

CHAPTER 5 Physical Layer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .25

5.1 5.2 5.3 General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

CHAPTER 6 Implementation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

6.1 General Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Radio Link Control Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Medium Access Control Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 28 28 29 29 29

CHAPTER 7 Tests and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31

7.1 7.2 7.3 7.4 7.5 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Packet Loss and Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact of Error Model Choice. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact of Poll Prohibit Timer Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact of Poll Timer Value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 32 32 35 36

CHAPTER 8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37

8.1 Future Work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

CHAPTER 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 APPENDIX A User guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

A.1 A.2 A.3 Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Usage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

List of gures
Figure 1-1. Figure 1-2. Figure 2-1. Figure 2-2. Figure 2-3. Figure 2-4. Figure 3-1. Figure 3-2. Figure 3-3. Figure 3-4. Figure 3-5. Figure 3-6. Figure 3-7. Figure 4-1. Figure 4-2. Figure 6-1. Figure 7-1. Figure 7-2. Figure 7-3. Figure 7-4. Figure 7-5. Figure 7-6. Figure 7-7. Figure 7-8. The OSI reference model can be used to describe a network node................................2 The OSI reference model can be used to describe the UMTS protocols. ......................3 Shared object design uses the best features of two languages. ...................................... 8 A general markov chain has several states with different drop probabilities. ................9 The simplest Markov chain has only two states........................................................... 10 The already implemented wireless protocol stack in ns contains several layers..........11 Segmentation means dividing a large packet into several smaller. ..............................13 Filling unused space in a packet with data from the next is called concatenation. ......14 Transparent mode is the simplest mode. ...................................................................... 15 In unacknowledged mode a header is added to each packet. ....................................... 15 Unacknowledged mode uses some complex functions. ............................................... 16 The acknowledged mode model is quite complex. ...................................................... 17 In acknowledged mode a header is added to each packet. ........................................... 18 The packet format for non-high-speed contains a header and an SDU........................24 The packet format for high-speed mode contains a header and several SDUs. ...........24 The new RLC module inherits from LL and it uses one or several RLCFlows. ..........28 A packet loss and its recovery ......................................................................................32 The left gure shows 0% error rate and the right 1% rate based error rate..................33 The left gure shows 10% rate based error rate and the right 20%. ............................33 Markov chains are used to simulate error bursts. ......................................................... 34 These are the results of the burst error tests. ................................................................ 34 The delay for the tests can be compared. ..................................................................... 35 The mean delay increases when the poll prohibit timer value is increased. ................36 The delay increases when the poll timer value is increased......................................... 36

Introduction

This chapter gives an introduction to the subject. In section 1.1 the work is motivated and there is also a description of where in the network the focus for this thesis is. The goal is described in section 1.4 and finally there is a reading guide in section 1.5 and some common abbreviations in section 1.6.

1.1 Background
Performance of communication networks have been an interesting issue since the start of the Internet in the 1960s. The Internet has mainly been interconnecting stationary computers by wired links, but an increasing number of mobile clients require wireless communication. The areas of wired and wireless communications have been separated until this point. The research in one is not necessarily compatible with research in the other. There are several ways to interconnect the mobile clients to the Internet. One way is to use the Universal Mobile Telecommunication System, UMTS. UMTS is a third generation mobile system. The standards for this are maintained by 3GPP, the third generation partnership program [1]. These standards have an important role in this thesis. To understand a network, it can be useful to see it as nodes interconnected by links. Inside a node a layered hierarchy can be used to describe the functionality of the node. The open system interconnection, OSI, has developed a reference model for this hierarchy, see figure 1-1. Each layer in this model is described below [19]. The physical layer is concerned with transmitting raw bits over a communication channel. The key issue is to make sure that when one side transmits a 1 bit the other side receives it as a 1 bit and not a 0 bit. Typical questions for this layer are for example which voltage level represents a 1 bit, how many nanoseconds a bit last and how the initial connection is made. The data link layer is responsible for transforming the raw transmission of the physical layer into a line that appears free from transmission errors. To do this the data is divided into frames. A frame typically contains between a few hundred and a few thousand bytes. The frames received without errors are normally acknowledged by sending a special acknowledgement frame back. Broadcast networks introduce some problems when accessing a channel which is concurrently used by several users. This is dealt with in a sub layer in the data link layer called medium access control or MAC.

Application

Presentation

Session

Transport

Network

Data link

Physical
Figure 1-1. The OSI reference model can be used to describe a network node.

The network layer controls the operation of the subnet. The key issue here is to determine how packets are routed from source to destination. The routes can be based on static tables that are rarely changed or they can be dynamic, either set up per session or set up per packet. This layer is also responsible for congestion issues such as delay, transmit time and jitter. This is called quality of service or QoS. The transport layer is a true end-to-end layer all the way from source to destination, in contrast to the earlier mentioned layers that communicate only with their immediate neighbors. The transport connection can have different characteristics depending on the type of service the higher layers request. The most common type is an error free point-to-point connection that delivers messages in sequence, but others include broadcasting and delivery out of sequence. The session layer allows users on different machines to establish sessions between them. A session can help to keep track on whose turn it is to transmit. This is called dialog control. It provides token management, useful when two parties not are allowed to attempt the same critical operation at the same time. It also provides synchronization, allowing long transmissions to continue where they were interrupted.

The presentation layer is concerned with the syntax and semantics of the information. It makes it possible for machines with different data representation to communicate. It allows high-level abstract data structures to be defined and exchanged. The application layer contains a lot of protocols that are commonly needed by users. Some examples are HTTP for transferring web pages, FTP for transferring files and IMAP for transferring mail. The OSI reference model can be used to understand the protocol stack of UMTS. The correspondence is depicted in figure 1-2. The physical layer is the radio signals, frequencies and channels. The data link layer is divided into radio link control, RLC and medium access control, MAC. The network layer is the internet protocol, IP. The transport protocol is one of the transport control protocol, TCP or the user datagram protocol, UDP. In UMTS there is also a radio resource control entity, RRC. It manages the radio resources on several levels in the hierarchy. It has no corresponding entity in the OSI model. OSI Transport UMTS TCP/UDP

Network

IP RRC

RLC Data link MAC

Physical

Radio

Figure 1-2. The OSI reference model can be used to describe the UMTS protocols.

The focus of this thesis is the data link layer of the UMTS. Compared to the data link layer in a wired scenario it contains more control and error correction mechanisms. This is because of the many and different errors introduced by the wireless link. These mechanisms use a lot of timers and triggers, which makes it very difficult to analyze them mathematically. Instead, the common approach is to use a simulator to analyze the link layer.

1.2 Previous work

Some research has already been done in this area. In this research there are two fundamentally different ways to simulate a wireless link in a larger network. One is to see the network as a traffic generator. The structure of the network outside the wireless link is ignored and the focus is on making the wireless communication as close to reality as possible. The other 3

is to see the wireless link as nothing but a delay with certain properties. The focus here is the network around the wireless link and how the different type of links interacts. Some of the previous work in this area is described below. Improving 3G performance for the mobile internet [13]. In this report the simulator ns is used. This simulator is further described in section 1.3. The wireless link is modeled using only a delay. The focus is how to utilize the wireless link maximally when changing tcp-algorithms. The results are some suggestions on algorithm choice and settings of some parameters of the algorithms. Simulation analysis of RLC timers in UMTS systems [20]. In this report the simulator used is what later is described as an in house testbed. The network outside the wireless link is modeled only as a trafc generator. The focus is on the settings of timers and triggers in the data link layer. Some relations between the different settings are discovered. The ambition of this thesis is to simulate the details of the wireless link in a simulator that also supports simulations of the entire network. This makes it possible to simulate the large network as well as the details of the wireless link. Concurrent with this work another project on simultion of rate control in UMTS radio network controller [12] was done. This means simulations of layers above the data link layer. The implementations are compatible with each other and an interface has been defined between them. A joint effort from both these theses and their supervisors resulted in a report [11] with some of the results from both theses.

1.3 Simulators
As mentioned above a mathematical analysis of some network layers is difficult. Therefore a simulation is preferred. For the purpose of comparison three different types of simulators are described below. Commercial tools. Opnet [15] is one of the commonly used commercial tools. Opnet is short for optimized network engineering tool. It is distributed by MIL3 Inc. Commercial tools are favoured by the industry, probably because of support agreements and reliability issues. Open source software. Network simulator version 2 [14] is an example of an open source software. Open source software is often developed by user contributions and ns is no exception. Open source software is favored by the academic world, probably because it is free and because it is easier to develop new modules. In house testbeds. There are also a lot of in house testbeds with limited, or even just a single, simulation task. These simulators cannot easily be modified and are not as common as the two previous mentioned. Since the work in this thesis is made in the academic world, an open source software simulator is used for the simulations. The distribution in use is called ns-allinone-2.1b9a, this is further discussed in chapter 2.

1.4 Goal
The goal of this thesis is to implement and test the RLC and MAC layers for UMTS in network simulator version 2. The implementation shall be compliant with the standards specified by 3GPP. Implementing these standards in full could not be done within the time frame of this thesis and therefore parts were left out. A closer specification of which parts are included and which are excluded can be found in chapter 6.

1.5 Reading Guide

In chapter 2 the simulator used for this work is described. Chapters 3, 4 and 5 describe the standards for RLC, MAC and the physical layer respectively. In chapter 6 the design decisions and general implementation issues are described. The tests and the results of the tests that were performed on the implementation are described in chapter 7. In chapter 8 the results are analyzed and discussed.

1.6 Abbreviations
Some of the abbreviations used in this thesis are explained below. 3GPP FDD IP MAC ns OSI OTcl PDU RLC RRC SDU SUFI STL TCP TDD TTI UE Third Generation Partnership Program. An organization formed around the third generation mobile systems. Frequency Division Duplex. A multiplexing mode that uses separate frequencies in each direction. Internet protocol. A network protocol commonly used on the Internet. Medium Access Control. A part of the data link layer in UMTS. Network Simulator. The simulator used for this work. Open systems interconnection. Standards developed by the international standardization organization. Object Tool Control Language. An interpreted programming language. Protocol Data Unit. Packets that are sent to or received from a lower layer. Radio Link Control. A part of the data link layer in UMTS. Radio Resource Control. Manages radio resources on several layers. Service Data Unit. Packets that are sent to or received from a higher layer. Super Field. Building blocks for status packets used in acknowleged mode. Standard Template Library. Implementations of data structures in C++. Transport Control Protocol. A transport protocol commonly used on the Internet. Time Division Duplex. A multiplexing mode that uses time slots. Transmission Time Interval. One timeslot in TDD. User equipment. Often a mobile phone. 5

UMTS UTRAN

Universal Mobile Telecommunication System. UMTS Radio Access Network.

Network Simulator

This chapter describes the network simulator version 2 [14]. The design and structure is discussed on a general level. The wireless stack is shown, because the implementation contains new modules for this stack.

2.1 General
The network simulator, ns, is a discrete event simulator targeted at network research. It is an open source software. It began as a variant of the REAL network simulator [17] in 1989 and has evolved substantially over the past years. Ns has always included contributions from different resarch projects, including wireless code from the UCB Daedelus and CMU Monarch projects and Sun Microsystems. Ns provides support for simulation of TCP, routing, and multicast protocols over wired and wireless networks.

2.2 Design and Implementation

The design of ns uses a paradigm called shared object design. This means that the system is programmed in two languages, but the objects in one are accessible in the other. There are also objects accessible to only one part of the system. This is depicted in figure 2-1. The main part of the simulation engine is written in C++ [10] and the main part of the user interface is written in OTcl [16]. The reason for this is that the system can use the speed of C++ but at the same time the flexibility of OTcl. There are two different types of event schedulers implemented in ns. These are real-time and non-real-time schedulers. The real-time scheduler is for emulation, which allows the simulator to interact with a real network. Currently, emulation is under development but an experimental version is available. The non-real-time scheduler is the default scheduler. The scheduler is used to keep track of simulation time and fire events. To make something happen at a certain time an event or timer is needed. An event can for example be a packet arrival. A timer can be created using the TimerHandler class. To use the simulator a scenario has to be created. The network can be freely designed in a scenario and it is written in OTcl. The scenario contains descriptions for some or all of the elements of simulation described below.

C++

OTcl

Figure 2-1. Shared object design uses the best features of two languages.

2.3 Elements of Simulation

In this section the elements of simulation in ns are described. Nodes in ns handle packet forwarding and can be both receivers and routers at the same time. There are both unicast and multicast nodes. Links interconnect two nodes. Packets works as events in the event driven simulation. Receiving or sending a packet is an event. There are functions for creating, accessing and changing both the packets and the headers of the packets. Queues can be connected to links. The type of dropping (or forwarding) procedure can be chosen from several different types. Error models are used to introduce packet losses in the simulation. These are furher described in section 2.3.1. Agents represent the endpoints for network layer packets in the simulation. They are responsible for creation and destruction of these types of packets. There are several agents already implemented, but only two are of interest for this work; the TCP-agent that handles TCP-packets and the null-agent that simply discards all packets. The TCP-agent is used for the traffic in the simulations and the null-agent is used as drop target. Applications are above the agents. There are two types of applications; traffic generators and simulated applications. The traffic generators generate traffic in a predefined pattern. The pattern can be on/off cycles with certain characteristics or simply a constant bit rate. Simulated applications are for example FTP and telnet where the generated traffic is made as similar to the real applications traffic as possible.

2.3.1 Error Models

Error models are used to introduce packet losses in the simulation. An error model is a linklevel packet loss that can be attached to any link in wired topologies and any node in wireless topologies. The size of the error can be selected by means of corrupting a bit, a byte or the whole packet. The erroneous packet is then either marked by setting the error flag in the header or by sending it to a drop target instead of the original destination. Which entity to corrupt can be selected in a variety of ways, some of the already implemented ones are described below. Rate based is a simple model with a congurable rate at which the entities are corrupted. Deterministic has a predened list of which entities to corrupt. Timer based uses timers to determine which entities to corrupt. Twostate is a more complex model that uses a two state automata with dropping rates 0 and 1 for the two states and congurable state change probabilities. Multistate is the most exible and sophisticated model with a multi state automata. A commonly used error model that can be derived from the multistate model is the markov chain. In a markov chain each state is a rate based error model and states can only change up or down the chain. A general markov chain is depicted in figure 2-2. In this figure S is the states and P, Q and R are state change probabilities. Pi+Qi+Ri=1 must hold for all states.

P1

P2

Pn

Q1 S1 R2 S2

Q2 ... R3

Qn-1 Sn Rn

Figure 2-2. A general markov chain has several states with different drop probabilities.

The most simple markov chain has only two states, this is depicted in figure 2-3. The formula for the total drop rate for this error model is shown in equation 2-1. 1 P1 1 P2 Total = S 1 -------------------------- + S 2 -------------------------2 P1 P2 2 P1 P2

(2-1)

P1

P2

1-P1 S1 1-P2
Figure 2-3. The simplest Markov chain has only two states.

S2

2.4 Protocol Stack

The packet flow in ns goes through a protocol stack. Each protocol is a module that easily can be replaced. The modules implement an interface with the single function recv. Through this function all incoming packets from upper and lower layers are received. A bit in the common headers describe whether the packet is going up or down the stack.

2.5 Wireless Models

Some functionality exists in ns for modeling of wireless scenarios. This has been developed with the same purpose as this study to enable combined simulations for fixed and wireless networks. The focus is on the standard for wireless local area networks, WLANs, and for different mobility simulations with radio propagation delays. Such links, however, are significantly different from the wireless links in UTRAN. The wireless protocol stack already implemented is depicted in figure 2-4. In this figure LL is the link layer and MAC is the media access control as described in the OSI model in section 1.1. ARP is the address resolution protocol. The interface queue is used by the MAC to buffer packets. The network interface and channel corresponds to the physical layer in the OSI model. It contains models for antenna type, channel type and propagation properties. Each of the modules implement the recv function described in section 2.4 and can be replaced by another module that also implements this function.

10

LL

ARP

Interface Queue

MAC

Network Interface

Channel
Figure 2-4. The already implemented wireless protocol stack in ns contains several layers.

11

12

Radio Link Control

This chapter contains a description of the radio link control, RLC. The described functionality is compliant with the 3GPP standard 3GPP TS 25.322 [7]. The implementation does not contain everything described in this chapter, see section 6.2 for implementation details.

3.1 General
The radio link control, RLC is found in the link layer in the OSI architecture described in section 1.1. The link layer in a wireless network contains more functionality and control mechanisms than in a wired network. The reason for this is that a wireless link introduces more and different errors than a wired one. In a wired scenario the errors are most likely to be buffer overflows while in the wireless case the errors are more likely to be transmission errors. A packet sent to a higher layer from RLC or received from a higher layer to RLC is called RLC service data unit, or RLC SDU. A packet sent to a lower layer from RLC or received from a lower layer to RLC is called RLC protocol data unit, or RLC PDU. In this chapter PDU means RLC PDU and SDU means RLC SDU, unless explicitly stated.

3.2 Functions
The services provided to upper layers depend on the transport mode in use, see section 3.3 below. In order to provide all three transport modes in full the functionality described below needs to be implemented. The specifications for these can be found in [7]. Segmentation and reassembly is used to send SDUs that are larger than a PDU. Segmentation means dividing a large packet into several smaller. This is depicted in figure 3-1. Reassembly is the reverse of segmentation, i.e. merging the small packets into the big one.

Figure 3-1. Segmentation means dividing a large packet into several smaller.

Concatenation is used when a PDU not is filled by the last part of an SDU. Data from the next SDU is then used to fill the empty space. This is depicted in figure 3-2. The receiving 13

side uses a length indicator in the headers when reassembling the packets to determine where the second packet starts.

Figure 3-2. Filling unused space in a packet with data from the next is called concatenation.

Padding is used in the same way as concatenation, but instead of data the remaining part of the PDU is filled with pad. The pad can have any content and shall be disregarded by the receiver. The length of the pad is determined by the packet size. Sequence number control is used when reassembling packets to make sure they get merged in the correct order and in error correction to determine which packets were lost. Error correction is done by retransmission of lost packets. This is further described in section 3.4. Duplicate detection is used to make sure that no SDU is delivered twice to upper layers. Each packet is assigned a sequence number. To detect duplicates, the RLC checks these sequence numbers. In-sequence delivery of upper layer PDUs means that the packets arrive to the upper layers in the same order as they were sent. This service can be disabled by upper layers if the order of the packets is unimportant or if the order is restored in higher layers. Transfer of user data is the service provided to upper layers. The transfer uses one of the three transport modes described in section 3.3. SDU discard means that if the RLC is unable to transfer a SDU it can be discarded. Both upper layers and the receiver shall be notified of the discard, if this is configured by upper layers. Ciphering is used to prevent unauthorized acquisition of data. The actual ciphering process is out of the scope of this thesis. Sliding window is a control mechanism that limits the number of packets the sender is allowed to send before receiving acknowledgement. This amount is called the window size. When positive acknowledgements arrive the window moves forward allowing new packets to be sent, therefore the name sliding window. The RLC uses this mechanism.

3.3 Transport Modes

RLC can operate in three different transport modes; transparent, unacknowledged and acknowledged. Each adds new functionality compared to the previous. They are all described below. 14

3.3.1 Transparent Mode

RLC operating in transparent mode, TM, transfers data without adding any headers, see figure 3-3. Segmentation is optional, and is configured by upper layers. If segmentation is not configured each SDU is a PDU. If segmentation is configured, oversized SDUs are segmented into PDUs and the segments from one SDU are sent in the same timeslot. The receiver reassembles the SDUs. RLC operating in transparent mode uses segmentation and reassembly, transfer of user data and SDU discard as described in section 3.2. [7]

Transmitting side

Receiving side

Transmission Buffer

Reassembly

Segmentation

Reception Buffer

Figure 3-3. Transparent mode is the simplest mode.

3.3.2 Unacknowledged Mode

RLC operating in unacknowledged mode, UM, is depicted in figure 3-5. In this mode RLC adds a header to each sent PDU. The packet format is depicted in figure 3-4 and is further described below.

Sequence number Length indicator Length indicator

E E E

(optional) (optional)

Data

Pad

(optional)

Figure 3-4. In unacknowledged mode a header is added to each packet.

15

The fields of the packet are: Sequence number is used in segmentation/concatenation and reassembly to maintain the order of the packets. This eld is 7 bits. E is the extension bit. This is used to indicate whether the next byte is a length indicator or if it is data. Length indicator is used to determine the length of the data. There are also bit patterns with special meanings. The length indicator is 7 or 15 bits. Data is the data to be transferred. Pad is used to ll undersized packets.

Transmitting side

Receiving side

Transmission Buffer

Reassembly

Segmentation & Concatenation

Remove RLC header

Add RLC header

Reception Buffer

Ciphering

Deciphering

Figure 3-5. Unacknowledged mode uses some complex functions.

In this mode RLC uses segmentation and reassembly, concatenation, padding, sequence number control, transfer of user data, ciphering and SDU discard as described in section 3.2. Each SDU is segmented and concatenated into PDUs. If ciphering was configured by upper layers and started, the PDU is ciphered. The receiving side is responsible for deciphering and reassembly.

16

3.3.3 Acknowledged Mode

Acknowledged mode, or AM, is the most complex mode. In addition to the functions in unacknowledged mode it does error correction by retransmission. The acknowledged mode model is depicted in figure 3-6. In this figure an incoming SDU arrive at the top on the left side. The SDU is then segmented and concatenated into PDUs as described earlier. A header is added to each PDU in the next step. Each packet is then put into buffers to be able to retransmit them later if needed. Packets are then moved from these buffers into the retransmission buffer, where the control unit also may add status packets. Before transmitting the packet the headers are set up as described later and the data is ciphered. The receiving side checks if it is a status packet, and reports the status to the control unit if it is. Otherwise the packet sequence number is reported so the correct positive and negative acknowledgements can be transferred later. The packet is then deciphered and put into a reception buffer. In the next step the header is removed and piggybacked status messages are extracted. Finally the PDUs are reassembled to an SDU and delivered to upper layers. Transmitting side Control unit Segmentation & Concatenation Reassembly Add header Remove header & extract information Retransmission buffer&management Reception Buffer Transmission Buffer Deciphering Receiving side

Header setup

Ciphering

Demux

Figure 3-6. The acknowledged mode model is quite complex.

17

D/C Sequence number Sequence number P HE Length indicator E Length indicator E

(optional) (optional)

Data

Pad or piggybacked status

(optional)

Figure 3-7. In acknowledged mode a header is added to each packet.

The headers are depicted in figure 3-7, and each field is further described below. D/C is the data/control bit. It is used to differentiate between data packets and control packets. Sequence number is used to identify the packets in retransmission and reassembly. This eld is 12 bits. P is the poll bit. This is used to request a status report, see section 3.4.1 below. HE is the header extension. It is used to tell if this packet contains a length indicator or not. This eld is two bits. Length indicator is used to determine the length of the data. It tells where the data ends and the padding begins or where the next SDU begins if the packet contains concatenated SDUs, see section 3.2. The length indicator is 7 or 15 bits. E is the extension bit, used to determine if the next octet contains another part of the length indicator or if it is data. Data is the data to be transferred. Pad or piggybacked status is used when needed, see section 3.2.

3.4 Retransmission
To retransmit packets RLC uses polling to request status reports. These functions are described below.

18

3.4.1 Polling
The polling function is used to request a status report from the RLC entity on the other side of the communication, the peer RLC entity. There are several ways to trigger a poll. Which to use is configured by upper layers. Often several triggers are used concurrently. There are two sorts of triggers, periodic and non-periodic. The periodic ones are described below. Poll every n:th PDU means that after a congurable number, n, of PDUs have been sent since the last poll request this mechanism triggers. Poll every n:th SDU works in the same way as the one above but on SDUs instead of PDUs. Timer based means that after a congurable time has passed since the last poll request this mechanism triggers. The non-periodic triggers are deployed in special cases or in case of emergency. These are described below. Poll on last PDU in transmission buffer means that the last packet to be sent triggers this mechanism. Poll on last PDU in retransmission buffer works like the one above but on the retransmission buffer. Window based polling means that if the window is congurable near full this mechanism triggers. Since there often are several triggers active and the polling results in status reports that consume bandwidth, there are also ways to prohibit polling. This mechanism is called poll prohibit and is basically a timer that is used when configured by upper layers. The timer is started when a PDU with a poll request is sent. If one or more mechanisms triggers while the timer is running, only one poll request is sent directly after the timer has run out. This way the overhead consumed by status reports can be kept down. If a configured mechanism triggers and the poll prohibit timer is inactive or not running the next outgoing PDU will contain a poll request. The request is indicated by setting the pollbit in the header, see section 3.3.3.

3.4.2 Status Report

When an incoming PDU contains a poll request, the RLC compiles a status packet. The status packet consists of smaller parts called super fields, or SUFIs. The possible SUFIs are described below. Acknowledgement is a SUFI that contains the sequence number of the last PDU received in sequence without error. List of negative acknowledgements is a SUFI that contains a list of sequence numbers and burst length of PDUs received with error or not received at all. Bitmap of negative acknowledgements is a SUFI that contains the sequence number of the rst missing PDU and a bitmap describing positive and negative acknowledgement for the following PDUs. The bitmap may be up to 128 bits long. 19

 Relative list of negative acknowledgements is a more complex data structure that describes the missing PDUs. This is not further elaborated here. Window size is a SUFI that contains a new window size. RLC may change window size when receiving this SUFI, but the maximum and minimum values is still the ones congured by upper layers. Move receiving window is a SUFI that requests a move of the receiving window and to discard the SDUs affected. Which SDUs to discard is described by giving the sequence number of the last PDU from that SDU. Up to 16 such numbers can be sent in one SUFI. Move receiving window acknowledgement is a SUFI used to acknowledge the move receiving window SUFI described above. No more data is a SUFI that indicates that there are no more SUFIs after this one in this status report.

20

Medium Access Control

This chapter contains a description of the medium access control, MAC. The described functionality is compliant with the 3GPP standard 3GPP TS 25.321 [6]. The implementation does not contain everything described here, see section 6.3 for implementation details.

4.1 General
The medium access control is found in the link layer of the OSI architecture described in section 1.1. The need for medium access control arises when the channel to transmit on is shared. This is the case in UMTS where the medium is the air.

4.2 Services
The services provided by the MAC layer are specified in [4] and are described below. Data transfer is provided in unacknowledged mode between two MAC entities. This service does not provide segmentation or reassembly. That should be taken care of in higher layers. There are exceptions though, these are explained below. Allocation of radio resources is changed when requested by the radio resource control, RRC. This means for example change of transport format set or channel type. Measurement reports such as traffic volume and quality indications are reported to RRC upon request. This means the MAC needs to keep track of such measurements.

4.3 Functions
To be able to provide the services in section 4.2 the MAC layer needs the functions described below. [4] Mapping of logical channels on transport channels is information stored in the MAC layer. Selection of transport format for each transport channel is managed in the MAC layer given the transport format set assigned by the RRC. Priority handling needs to be considered, both between data flows on one UE and between UEs by means of dynamic scheduling. Priorities can for example be calculated based on RLC buffer status. Identication of UEs is used on common channels to keep track of the UEs on the channel.

21

Multiplexing and demultiplexing on transport channels is used on common transport channels when there are several users at once and on transport channels that are used by several RLC instances. Trafc volume measurement is needed by the RRC to make channel switching decisions. Channel type switching means switching between common and dedicated channel. This is done upon request by RRC. Ciphering is used to prevent unauthorized acquisition of data. Ciphering is performed in this layer when RLC is operating in transparent mode. Hybrid automatic request, HARQ, is needed for the high speed mode. This is further described in section 4.6. Assembly and disassembly of high speed mode packets is done in this layer. The packet format is described in section 4.7. The MAC also has mechanisms for delivering these packets in sequence.

4.4 Multiplexing Modes

MAC can operate in two fundamentally different modes depending on the multiplexing mode in use.

4.4.1 Time Division Duplex

Time division duplex, TDD, is a multiplexing mode that uses only one frequency [3]. The sender and receiver use different time intervals, or time slots, when sending data. These are called transmission time interval, TTI. The sender and receiver transmit their data reciprocally.

4.4.2 Frequency Division Duplex

Frequency division duplex, FDD, is a multiplexing mode where the sender and receiver use two separated frequencies [2]. Pairs of frequencies have been specified for this mode. One frequency is used for uplink and the other for downlink.

4.5 Channels
The MAC is responsible for handling a lot of logical channels. These are used in different combinations to transfer data. The channels used for transfer of control information are: broadcast control channel paging control channel dedicated control channel common control channel and shared channel control channel. There are also two types of traffic channels for transfer of user data; dedicated traffic channel and common traffic channel. 22

4.6 High Speed

The MAC can operate in a special high speed mode. It uses hybrid automatic request, HARQ, and adaptive modulation and coding, AMC, to reduce delays and achieve high throughput and peak rates. It relies on a special transport channel called high speed downlink shared channel, HS-DSCH. The principle of adaptive modulation and coding, AMC, is to change the modulation and coding format with variations in the channel conditions. The channel conditions can for example be estimated based on feedback from the receiver. In a system with AMC, users in favorable positions e.g. users close to the base station are typically assigned higher order modulation with higher code rates, while users in unfavorable positions are assigned lower order modulation with lower code rates. The main benefits of this are that the average throughput of the cell is increased and the interference variation is reduced. The latter because the link adaptation is based on variations in the modulation and coding scheme instead of variations in transmit power. The HARQ uses link layer acknowledgements for retransmission decisions. There are several ways to implement the HARQ, but no closer descriptions of these will be given here. Because HARQ autonomously and instantly adapts to the channel conditions and is insensitive to the measurement error, combining it with AMC uses the best of both techniques. AMC provides the coarse data rate selection, while HARQ provides for fine data rate adjustment based on channel conditions.

4.7 Packet Formats

The packet formats for the MAC layer depends on the settings in use. The packet formats for both non-high-speed and high-speed mode are described below [6]. The packet format for non-high-speed communication consists of a header and an SDU. This is depicted in figure 4-1. The fields are described below. TCTF is the target channel type eld. This eld identies the target logical channel. This eld is 1 to 8 bits long. UE-id type describes the type of user equipment identication that is in use. It is 2 bits long. UE-id is the user equipment identication eld. It serves as identication on common transport channels. Depending on the UE-id type this eld is 16 or 32 bits. The C/T-eld provides identication of the logical channel when multiple logical channels are carried over the same transport channel. There may be at most 15 logical channels on one transport channel, therefore this eld is 4 bits.

23

Header TCTF UE-id type UE-id C/T MAC SDU

Figure 4-1. The packet format for non-high-speed contains a header and an SDU.

When operating in high-speed mode the packet format is different. Each packet contains a header and several SDUs. This is depicted in figure 4-2. The fields of the header are described below. Queue ID is the queue identier used for multiple reordering queues. The eld is 3 bits long. TSN is the transmission sequence number. It is used for reordering and in-sequence delivery on the receiving side. This eld is 6 bits long. SID is the size index identier. This is used to identify the size of the SDUs. The possible sizes are congured by upper layers. The eld is 3 bits long. N is the number of consecutive SDUs with the size specied by the SID-eld. The size of this eld is 7 bits. F is a ag indicating if there are more SID-elds or if this was the last one.

Queue ID TSN SID1

N1

F1

SIDk

Nk

Fk

Hs-header

Hs-SDU

Hs-SDU

Padding (optional)

Figure 4-2. The packet format for high-speed mode contains a header and several SDUs.

24

Physical Layer

This chapter contains a description of the physical layer of UMTS. The described functionality is compliant with the 3GPP standard 3GPP TS 25.302 [5]. The implementation does not contain everything described in this chapter, see section 6.4 for implementation details.

5.1 General
The physical layer is the lowest layer in the OSI reference model described in section 1.1. In this layer the access to the actual medium, the air, is controlled by means of sending and recieving radio signals. The forming of signals on different frequencies and radio measurement are typical tasks for this layer.

5.2 Services
The physical layer offers only data transport services to higher layers. These services are accessed through the transport channels of the MAC layer described in Chapter 4.

5.3 Functions
To provide the data transport services the physical layer has the functions described below [5]. Macrodiversity handling and soft handover are related to the possibility of being connected to more than one base station at once. This means functions for combining and distributing data transfers between the stations and to change stations without loosing connectivity, soft handovers. Error detection is performed on transport channels and errors are indicated to higher layers. Forward error correction or FER is a technique that makes it possible to correct a limited number of errors in a data stream. There are functions for FER encoding and decoding of transport channels. Rate matching is used when the number of bits between different TTIs is changed. The bits are then repeated to ensure that the bit rate fills the total bit rate of the allocated physical channel. Multiplexing and demultiplexing of transport channels to the physical channels are used to combine transport channels into physical channels and vice versa. Mapping of transport channels on physical channels is information stored in the physical layer. 25

Power control is used to control the power usage. There are algorithms to adjust output power to minimize errors while using as little power as possible applicable in different situations. Examples of such algorithms are inner loop and outer loop power control. Modulation, spreading, demodulation and despreading on physical channels are related to the wideband code division multiple access, WCDMA, technology. These functions are also part of the physical layer. Frequency and time synchronization are used to synchronize the bits, slots and frames. Radio characteristics measurements are recorded in this layer. Examples of such measurements are the frame error rate and signal to interference ratio. These characteristics are used in the power control algorithms mentioned earlier.

26

Implementation

This chapter describes the implementation. It contains the general design decisions as well as more specific design issues for each part of the system. Information on which parts of the standards described in earlier chapters that are included and which are excluded can also be found here.

6.1 General Design Decisions

Since the implementation is a module in the large system, ns, the design decisions were restricted by this fact. As described in chapter 2, ns uses a shared object design in C++ and OTcl. The new module is mainly written in C++ since it has the desired speed and fast memory handling wanted for the buffers. Hooks to OTcl was also implemented to be able to change settings directly from scenarios. There were two main choices for the implementation of the RLC and MAC layers; either they could be implemented as a link, as described in section 2.3, that represents an already established data flow or they could inherit from the already implemented wireless protocol stack, described in section 2.5. The former is simpler since the data flow is defined from the start, but it is also less flexible since extensions such as interference and handovers are very difficult to implement. The latter is more flexible since it has replaceable modules for channels, antennas and propagation, but it is also more difficult since the data flows are harder to define. The decision was to use the already implemented protocol stack since this would be more flexible and more extendable. For the data structures the standard template library, or STL [18], was used. Some of the modules in ns already use it and it saves a lot of work when building data structures. Since the simulator is event driven no time is consumed by processing data. In reality though, this is a delay that effects performance. The delay is simulated by sending the packet to the next layer after a delay, the simulated processing delay. This delay was set to 15 ms were applicable, in accordance with [8].

27

6.2 Radio Link Control Design

The new radio link control module inherits from the link layer module LL in the wireless protocol stack. To be able to maintain several data flows in one RLC module the class RLCFlow was created which represents one data flow. This is depicted in figure 6-1. LL

1 RLC

1..n RLCFlow

Figure 6-1. The new RLC module inherits from LL and it uses one or several RLCFlows.

The RLCFlow class contains the buffers and timers related to one data flow. In this class all functionality described in section 3.2, except ciphering and SDU-discard is implemented. The out-buffer is an STL list. A pointer in the list refers to the next packet to send. Retransmissions and status reports are added directly after this pointer, so that they are the next to be sent. Acknowledged packets are removed from the out buffer upon reception of a status packet. When a packet going down the protocol stack arrives through the recv function, the first step is to check whether segmentation should be done, see section 3.2. The actual segmentation could not be carried out in the same way as in a real application. This comes from the fact that when a packet is created in ns it allocates space for all possible headers. With the standard configuration it consumes about 3 kb of memory. This made it impossible to just segment the packet with all headers and data into new packets. Instead the same packet is copied and sent several times, with changes in the headers. All fields in the RLC header are set according to section 3.3 and the length field in the ns-specific common header is changed. The in-buffer is also an STL list. The list is sorted and when there are enough packets to reassemble an SDU this is sent upwards and the corresponding packets are removed from the buffer. Control mechanisms make sure that duplicates are not allowed. The poll mechanisms that have time or delay as parameters uses the TimerHandler class described in section 2.2. The ones that count packets simply use integers. All poll mechanisms described in section 3.4.1, except window based polling, are implemented.

6.2.1 Limitations
The main limitation of the implementation is that there is no sliding window. In practice this means that the window size is infinite, the sender is allowed to have any number of unacked packets. Because of this the SUFIs related to the window, see section 3.4.2, were not implemented. It also made it impossible to implement the window based poll trigger. The ciphering function is not implemented, since privacy is not an issue in the simulations.

28

6.3 Medium Access Control Design

The implementation of the MAC layer is quite simple. The multiplexing mode is basically frequency division, FDD. This means that the sender and receiver can transmit at the same time. The transmission is divided into time slots and in each slot a number of packets determined by the send speed is transmitted. The speed is simulated by setting the packet size, the length of the time slots and the number of packets sent in each. These settings are made from the RLC layer. All packets sent in the same time slot is sent concurrently in the beginning of the slot because if they where sent sequentially there would be a risk of overflow into the next time slot. To find the target it uses a virtual address resolution table. On the receiving side the ns-specific common header is checked for errors and erroneous packets are sent to the drop target, which often is a null-agent that just discards the packet. All other packets are forwarded up the protocol stack after a simulated processing delay.

6.3.1 Limitations
The implementation provides the service of data transfer as specified in chapter 4, but not much more. The different logical channels and transport channels were not implemented. This means that the allocation of radio resources is simply changing the TTI and the number of packets sent in each TTI as mentioned above. Also the time division duplex mode, TDD, was excluded as well as the measurement reports and the high-speed mode.

6.4 Physical Layer

The already implemented physical layer contains functions for antennas, propagation delays and topologies. No additional functions were implemented in this layer. This means that the layer provides the data transfer service, but none of the UMTS specific functions described in section 5.2.

29

30

Tests and Results

This chapter describes the tests that were performed on the implementation. The results of the tests are also presented in this chapter.

7.1 Setup
The tests were conducted using ns version 2.1b9a. The same setup of parameters were used in all scenarios, only the parameters subject to the test are changed. Each scenario contains two nodes, a sender and a receiver. Both are wireless nodes, using the new implementations of the RLC and MAC layers. A traffic generator with the constant bit rate 2 kb/s is attached to the sender and a sink is attached to the receiver. Each node has an error model attached to the incoming flow of packets. The tests are using a rate based error model. The dropping rate is set to 10%. This was selected because it was commonly used in [20]. The error model was set to corrupt packets, because the actual data transmitted is ignored in the simulations and corruption of bits or bytes would be undetected. It is possible to send real data in ns, but this function is not needed in these tests. The RLC is set to operate in acknowledged mode, because this is the most complex mode and therefore the most interesting. The MAC is set to operate in TDD mode, because this is the only implemented mode. The settings for other parameters were taken from a common test environment setup in [9] and are described in table 7-1.
Table 7-1. The test setup uses parameters from a common test environment setup. Parameter RLC mode PDU size Poll mode Poll time Poll prohibit time Multiplexing mode TTI Value Acknowledged 40 bytes Timer based 200 ms 200 ms TDD 20 ms

The transmission times for the SDUs are logged during the simulation and are then converted to matlab for analysis. Differencies in delays arise when packets have to be retransmitted. 31

7.2 A Packet Loss and Recovery

To show the effects of a packet loss in detail, two nodes and their communication are studied. One of the nodes is set up as sender and the other as receiver. The receiver is using a deterministic error model, as described in section 2.3. It is set to drop the second packet and nothing else. The sender uses the poll mode poll every n:th PDU described in section 3.4.1, with n set to 3. The result of the simulation is depicted in figure 7-1. Sender Packet 1 Packet 2 Poll Packet 3 (poll) Ackno 1 Status: ACK 1, NACK 2 Packet 2 retransmitted Ackno 3 Ackno 1 Receiver

Figure 7-1. A packet loss and its recovery

The first packet is transmitted without errors and the receiver updates its ackno. The second packet is marked as erroneous and is dropped by the MAC layer in the receiver. When the sender is about to send the third packet the polling mechanism triggers and the poll-bit is set in the headers of the third packet. This packet is transmitted without errors and when the receiver detects the poll request it compiles a status packet. The status packet contains in this case an ACK for packet 1 and a NACK for packet 2. When the status packet is received at the sender it deletes packet 1 from the buffers, since it was acknowledged, and it fetches packet 2 for retransmission. This time packet 2 is successfully transmitted and the receiver can update its ackno.

7.3 Impact of Error Model Choice

In reality the errors introduced by the wireless link can have different characteristics. These first tests show the effect of an increasing error rate. The parameter changed during the tests is the dropping rate of the rate based error model.

32

50 40
Packets [%]
Packets [%]

50 40 30 20 10

30 20 10 0 0 1 2 3

Delay [s]

0 0

Delay [s]

Figure 7-2. The left gure shows 0% error rate and the right 1% rate based error rate.

The first test, shown to the left in figure 7-2, is using 0% error rate. This is used as reference and comparison with the other results. The left bar in the graph is the acknowledgement packets and the right is the data packets. The latter takes a little longer to transmit because of the larger size. The next test is using a rate based error model with 1% error rate, the results can be found to the right in figure 7-2. This shows that a few packets are somewhat delayed.
50 40
Packets [%]

50 40
Packets [%]

30 20 10 0 0 1 2 3

30 20 10 0 0 1 2 3

Delay [s]

Delay [s]

Figure 7-3. The left gure shows 10% rate based error rate and the right 20%.

With the increasing error rate the delay increases. This is shown in figure 7-3 where the left figure shows 10% error rate and the right 20%. Overall this is the expected behavior. The peaks around 0.5 s and 1.1 s come from the fact that the delay for retransmission is similar to every packet and the total delay depends on this when packets are dropped.

33

95%

95%

90%

70%

5% 0% 5%
Figure 7-4. Markov chains are used to simulate error bursts.

10% 0% 30%

20%

40%

To test how the implementation reacts to error bursts two markov chains were constructed. These are depicted in figure 7-4. The total error rate for each is calculated in equation 7-1 and equation 7-2 respectively. The probabilities were selected so that a total error rate of 10% was achieved in both cases.

1 0.95 1 0.95 Total = 0 ----------------------------------- + 0.20 ----------------------------------- = 0.1 2 0.95 0.95 2 0.95 0.95

(7-1)

1 0.90 1 0.70 Total = 0 ----------------------------------- + 0.40 ----------------------------------- = 0.1 2 0.90 0.70 2 0.90 0.70

(7-2)

50 40
Packets [%]

50 40
Packets [%]

30 20 10 0 0 1 Delay [s] 2 3

30 20 10 0 0 1 Delay [s] 2 3

Figure 7-5. These are the results of the burst error tests.

The results for the markov chains are shown in figure 7-5. The left figure shows the results corresponding to the left chain in figure 7-4 and the right figure the results corresponding 34

to the right chain in figure 7-4. The results have similar characteristics compared to each other and there is no significant difference in characteristics compared to the tests with rate based error models.
0.8

0.8

0.6
Dealy [s]

0.6
Dealy [s]
0% 1% 10% Error rate 20%

0.4

0.4

0.2

0.2

10%

Markov1 Markov2

Figure 7-6. The delay for the tests can be compared.

The mean delays for each of the rate based tests are depicted to the left in figure 7-6. This shows that an increasing error rate gives an increasing mean delay. This is what could be expected. The values for the delays have the same characteristics as the results found in [20] with the same setup. The right image in figure 7-6 shows a comparison between the mean delay times for the test with 10% rate based error and the tests with markov chains. This shows that the delay times are almost the same regardless if the errors are evenly distributed or if they come in bursts.

7.4 Impact of Poll Prohibit Timer Value

The poll prohibit timer is useful to avoid flooding the receiver with poll requests, as described in section 3.4.1. This is especially useful when there are several active poll triggers. Tests were performed with the poll prohibit timer set to 0.2, 1.0 and 2.0 s. The mean delay was calculated using matlab. The results are shown in figure 7-7. As expected the mean delay increases when the poll prohibit value is increased. This comes from the fact

35

that status packets are sent more seldom and the time before the retransmission occurs is increased. The results are similar to the results on poll triggers in [20].
3 2.5
Delay [s]

2 1.5 1 0.5 0 0.2 s 1.0 s 2.0 s Poll prohibit time

Figure 7-7. The mean delay increases when the poll prohibit timer value is increased.

7.5 Impact of Poll Timer Value

The poll timer value is the main poll trigger when using timer based polling. Tests were performed with the poll timer set to 0.1, 0.5 and 1.0 s. The mean delay was calculated using matlab. The results are shown in figure 7-8. As expected the delay increases when the poll timer value increases. This comes from the fact that status packets are sent more seldom and the time before the retransmission occurs is increased. The results are similar to the results on poll triggers in [20].
1 0.8
Delay [s]

0.6 0.4 0.2 0

0.1 s

0.5 s 1.0 s Poll timer value

Figure 7-8. The delay increases when the poll timer value is increased.

36

Conclusions

The simulator ns is built to be easily extendable and has replaceable modules, but implementing the radio link control and the media access control according to the UMTS standard was not as trivial as is seemed. A subset of the radio link control layer as well as a very simple media access control layer was successfully implemented. For the physical layer the already implemented modules were used. Tests on the modules showed that the retransmission mechanism worked as expected when packets were dropped. The performance tests also showed the expected results in terms of changes in delay times as different timing settings in the radio link control layer were changed. The delay times in the performance tests were also similar to the results found in [20].

8.1 Future Work

The implementation is far from a complete implementation of the standards specified by 3GPP. The main limitation is that there is no window in the radio link control layer. There are also some triggers and status packets concerned with the window that could not be implemented. The high-speed mode in the media access control layer is not implemented. This could be an interesting part to implement as the behavior in this mode is quite different. There is also a lot of functionality in the physical layer that could be interesting to simulate.

37

38

9
[1] [2] [3]

References

3GPP. Third generation partnership program. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.212. Multiplexing and channel coding (FDD), version 5.2, 2002. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.222. Multiplexing and channel coding (TDD), version 5.2, 2002. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.301 Radio Interface Protocol Architecture, version 5.2, 2002. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.302 Services provided by the physical layer, version 5.2, 2002. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.321. MAC protocol specication, version 5.2, 2002. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 25.322. Radio Link Control (RLC) protocol specication, version 5.2, 2002. Available via www.3gpp.org [2003-01-10] 3GPP TR 25.853. Delay Budget within the Access Stratum, version 4.0, 2001. Available via http://www.3gpp.org [2003-01-10] 3GPP TS 34.108. Common test environments for User Equipment (UE), version 4.6, 2003. Available via http://www.3gpp.org [2003-03-30]

[4]

[5]

[6]

[7]

[8]

[9]

[10] The C++ resources network. Available via http://www.cplusplus.com [2003-01-10] [11] F. Gunnarsson, A. Bjrsson, B. Knutsson, F. Gunnarsson and F. Gustafsson. Radio access network (UTRAN) modeling for heterogenous network simulations. Technical Report LiTH-ISY-R-2533, Dept. of Electrical Engineering, Linkpings universitet, 2003. Avaliable via http://www.control.isy.liu.se/publications [2003-10-01]

39

[12] B. Knutsson. Simulation of rate control in UMTS radio network controller. Unpublished master of science thesis, Linkpings universitet. [13] E. Lundsten. Improving 3G performance for the mobile internet. Master of science thesis, Kungliga tekniska hgskolan, 2002. [14] NS UCB/LBNL/VINT Network Simulator. Available via http://www.isi.edu/nsnam/ns/ [2003-01-10] [15] OPNET Technologies Inc. Available via http://www.opnet.com [2003-01-10] [16] OTcl. MIT Object Tool Control Language. Available via http://otcl-tclcl.sourceforge.net/otcl/ [2003-01-10] [17] REAL network simulator Avaliable via http://minnie.tuhs.org/REAL/ [2003-01-10] [18] Standard Template Library Available via http://www.sgi.com/tech/stl/ [2003-01-10] [19] A. Tanenbaum. Computer networks (fourth edition). Prentice Hall, Upper Saddle River, NJ, 2003 [20] X. Xu, Y-C. Chen, H. Xu, E. Gonen and P. Liu. Simulation analysis of RLC timers in UMTS systems. In Winter simultaion Conference, 2002.

40

User guide

A.1 Installation
Download all the files from http://www.rt.isy.liu.se/~frida/nsmodules and store *.cc and *.h in RLCMAC_CC_LIB and *.tcl in RLCMAC_TCL_LIB under your main ns directory. For all files file.cc add RLCMAC_CC_LIB/file.o to the OBJ_CC macro in the Makefile. Also add RLCMAC_TCL_LIB/file.tcl to the NS_TCL_LIB macro for all .tcl-files. After downloading all files and adding the necessary changes for the modules you want to install run make depend and then make the main ns directory. RLC/MAC works best with NOAH, a wireless routing agent that only supports direct communication between base stations and mobile nodes. It is avaliable at: http://www.icsi.berkeley.edu/~widmer/mnav/ns-extension/

A.2 Usage
Use the RLC and MAC-3G as replacements for the LL and MAC-layer in wireless simulations. This is set up using the node-config command. It could look like this:
$ns node-config \ -adhocRouting -llType -macType -ifqType -ifqLen -antType -propType -phyType -channel -topoInstance -wiredRouting -addressType NOAH \ LL/RLC \ Mac/3G \ Queue/DropTail/PriQueue \ 300 \ Antenna/OmniAntenna \ Propagation/TwoRayGround \ Phy/WirelessPhy \ $channel \ $topo \ OFF \ hierarchical

A.3 Example
A simple example of two nodes, a sender and a receiver using the implementation.
#Setup global options set ns [new Simulator] set tracefd [open twonodes.tr w] $ns trace-all $tracefd create-god 2

41

#Setup topography and channel set topo [new Topography] $topo load_flatgrid 500 500 set channel [new Channel/WirelessChannel] #Create the error procedure proc ErrorProc {} { set rng [new RNG] $rng seed 0 set ranvar [new RandomVariable/Uniform] $ranvar use-rng $rng set errormodel [new ErrorModel] $errormodel ranvar $ranvar $errormodel unit packet $errormodel set rate_ 0.01 return $errormodel } #Configure node $ns node-config \ -adhocRouting -llType -macType -ifqType -ifqLen -antType -propType -phyType -channel -topoInstance -wiredRouting -addressType -IncomingErrProc

NOAH \ LL/RLC \ Mac/3G \ Queue/DropTail/PriQueue \ 300 \ Antenna/OmniAntenna \ Propagation/TwoRayGround \ Phy/WirelessPhy \ $channel \ $topo \ OFF \ hierarchical \ ErrorProc

#Create the sender set sender [$ns node 0.0.1] $sender set X_ 5.0 $sender set Y_ 2.0 $sender set Z_ 0.0 $sender random-motion 0 #Create the receiver set receiver [$ns node 0.0.2] $receiver set X_ 6.0 $receiver set Y_ 1.0 $receiver set Z_ 0.0

42

$receiver random-motion 0 #Create TCP agents set tcp [new Agent/TCP] $tcp set class_ 2 $ns attach-agent $sender $tcp set sink [new Agent/TCPSink] $ns attach-agent $receiver $sink $ns connect $tcp $sink #Create an application set ftp [new Application/FTP] $ftp attach-agent $tcp #Setup $ns at $ns at $ns at $ns at $ns at events 1.0 "$ftp start" 60.0 "$sender reset" 60.0 "$receiver reset" 60.0 "stop" 60.1 "$ns halt"

proc stop {} { global ns tracefd $ns flush-trace close $tracefd } #Start simulation $ns run

43

P svenska Detta dokument hlls tillgngligt p Internet eller dess framtida ersttare under en lngre tid frn publiceringsdatum under frutsttning att inga extraordinra omstndigheter uppstr. Tillgng till dokumentet innebr tillstnd fr var och en att lsa, ladda ner, skriva ut enstaka kopior fr enskilt bruk och att anvnda det ofrndrat fr ickekommersiell forskning och fr undervisning. verfring av upphovsrtten vid en senare tidpunkt kan inte upphva detta tillstnd. All annan anvndning av dokumentet krver upphovsmannens medgivande. Fr att garantera ktheten, skerheten och tillgngligheten nns det lsningar av teknisk och administrativ art. Upphovsmannens ideella rtt innefattar rtt att bli nmnd som upphovsman i den omfattning som god sed krver vid anvndning av dokumentet p ovan beskrivna stt samt skydd mot att dokumentet ndras eller presenteras i sdan form eller i sdant sammanhang som r krnkande fr upphovsmannens litterra eller konstnrliga anseende eller egenart. Fr ytterligare information om Linkping University Electronic Press se frlagets hemsida http://www.ep.liu.se/ In English The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linkping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/ Anders Bjrsson