Design & development of an HSPA system simulator for ...430942/FULLTEXT01.pdf · ments for HSPA...

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet

gnipökrroN 47 106 nedewS ,gnipökrroN 47 106-ES

LiU-ITN-TEK-A--11/029--SE

Design & development of an HSPAsystem simulator for network

planningArash Matinrad

2011-05-23

LiU-ITN-TEK-A--11/029--SE

Design & development of an HSPAsystem simulator for network

planningExamensarbete utfört i Elektroteknik

vid Tekniska högskolan vidLinköpings universitet

Arash Matinrad

Examinator Di Yuan

Norrköping 2011-05-23

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare –under en längre tid från publiceringsdatum under förutsättning att inga extra-ordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner,skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat förickekommersiell forskning och för undervisning. Överföring av upphovsrättenvid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning avdokumentet kräver upphovsmannens medgivande. För att garantera äktheten,säkerheten och tillgängligheten finns det lösningar av teknisk och administrativart.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovanbeskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådanform eller i sådant sammanhang som är kränkande för upphovsmannens litteräraeller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press seförlagets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet - or its possiblereplacement - for a considerable time from the date of publication barringexceptional circumstances.

The online availability of the document implies a permanent permission foranyone to read, to download, to print out single copies for your own use and touse it unchanged for any non-commercial research and educational purpose.Subsequent transfers of copyright cannot revoke this permission. All other usesof the document are conditional on the consent of the copyright owner. Thepublisher has taken technical and administrative measures to assure authenticity,security and accessibility.

According to intellectual property law the author has the right to bementioned when his/her work is accessed as described above and to be protectedagainst infringement.

For additional information about the Linköping University Electronic Pressand its procedures for publication and for assurance of document integrity,please refer to its WWW home page: http://www.ep.liu.se/

© Arash Matinrad

Abstract

HSPA planning requires identification of key performance indicators (KPIs),such as infrastructure cost,performance, service quality and the amount of E/Mpollution. To evaluate such a framework describing and linking these key ele-ments for HSPA planning and optimization we need to carry out a set of HSPAsystem-level event-driven simulations under different scenarios. To have such sim-ulations, a new tool should be developed. In this thesis work a simulation tool isdeveloped within NS-3, an open source network simulator. The simulation toolconsists several entities to represent a UMTS network and respective nodes in it,and necessary procedures to form a network dynamically. A simple base stationremoval algorithm in a system level, is developed focusing on the reduction of cap-ital expenditure (CAPEX) of a network. The algorithm defines a cost function inorder to remove the most costly base station from network preserving the targetcoverage percentage.

Baseline results show that the simulation tool is working properly and laterthe results from algorithm indicate that, it is possible to use the algorithm withina dynamic simulation.

1

Acknowledgments

I would like to thank my supervisor Dr. Vangelis Angelakis. He helped me a lotto understand how to do an academic research work. I want to thank ProfessorDi Yuan for his kind support on this project. I also appreciate my wife, Negar, forher great support and heartwarming encouragements.

Finally I want to express my deepest gratitude to my family and my parents,Homa and Ebrahim. It was by their kind and great supports, that I could finishthis thesis work.

3

Contents

1 Introduction 71.1 Overview of the Universal Mobile Telecommunication System (UMTS) 7

1.1.1 Physical layer (PHY) in WCDMA . . . . . . . . . . . . . . 101.2 High Speed Downlink Packet Access . . . . . . . . . . . . . . . . . 11

1.2.1 The High Speed Downlink Shared Channel . . . . . . . . . 121.2.2 MAC-hs and PHY layers . . . . . . . . . . . . . . . . . . . 13

1.3 High Speed Uplink Packet Access . . . . . . . . . . . . . . . . . . . 181.4 Review of Available Simulation Platforms . . . . . . . . . . . . . . 20

1.4.1 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.2 NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4.3 Comparison between NS-2 and NS-3 . . . . . . . . . . . . . 271.4.4 Enhanced UMTS Radio Access Network Extension (EU-

RANE) for NS-2 . . . . . . . . . . . . . . . . . . . . . . . . 301.5 A Brief Survey on Commercial HSPA Simulators . . . . . . . . . . 32

1.5.1 WinProp/ProMan . . . . . . . . . . . . . . . . . . . . . . . 321.5.2 N2NSOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 331.5.3 Prismo Simulator . . . . . . . . . . . . . . . . . . . . . . . . 331.5.4 Atoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351.5.5 3G UMTS FDD with HSPA . . . . . . . . . . . . . . . . . . 35

1.6 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2 Implementation 372.1 Nodes Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.1.1 NetDevices . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.1.2 Physical Layer . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.2 Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.1 Iub Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.2 Radio Channel . . . . . . . . . . . . . . . . . . . . . . . . . 422.2.3 MAC layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

2.3 RLC layer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.4 Internet Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.5 Scheduling and code assignment . . . . . . . . . . . . . . . . . . . 462.6 Routing and Switching . . . . . . . . . . . . . . . . . . . . . . . . . 46

2.6.1 Switching and Routing Process . . . . . . . . . . . . . . . . 46

5

6 Contents

2.7 Helper Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.7.1 Radio Channel Helper . . . . . . . . . . . . . . . . . . . . . 482.7.2 Radio PHY Helper . . . . . . . . . . . . . . . . . . . . . . . 482.7.3 UMTS Radio Helper . . . . . . . . . . . . . . . . . . . . . . 482.7.4 RNC to RBS Helper . . . . . . . . . . . . . . . . . . . . . . 492.7.5 RNC To RBS Star Helper . . . . . . . . . . . . . . . . . . . 492.7.6 Switch Fabric Helper . . . . . . . . . . . . . . . . . . . . . . 49

3 Simulator Validation Results 513.1 Baseline operation results . . . . . . . . . . . . . . . . . . . . . . . 513.2 Multicell scenario and results . . . . . . . . . . . . . . . . . . . . . 55

4 Modelling for A Simple Base Station Removal Algorithm 634.1 Scheduling and Channelization Code assignment . . . . . . . . . . 684.2 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Conclusion 73

6 Future work 75

Bibliography 77

Chapter 1

Introduction

Data communication has become a major part of the mobile networks. The fastgrowth of the services being offered over the Internet lead to an increase of accessto those services by the mobile users such as sending and reading emails, watchingvideos, sharing music, and etc. To provide service to such increasing throughputdemand in a mobile network has always been a challenge for the operators. Toprovide high throughput in the mobile network, High Speed Packet Access (HSPA)was introduced with Release’99 specification of the Universal Mobile Telecommuni-cations System (UMTS). Downlink (HSDPA) and Uplink (HSUPA) enhancementwere extended within release 5 and 6 respectively in UMTS. HSPA network canaccommodate high data rate with the help of link adaptation and reduced latencycomparing to older data channel, DCH, in R’99.

Main key performance indicators (KPIs) for a mobile network can describ the:cost of the network establishment and its maintenance such as Capital Expen-diture (CAPEX) or Operating Expenditures (OPEX), or satisfying the servicerequirements. For the HSPA network high data rates such as 14Mbps and and lowdelays in a link can be defined as the QoS parameters. To study on such KPIs asystem level simulator is required to be developed. Major part of the simulationmodule of these thesis work is to implement a HSDPA network and to includesome specific characteristics such as physical layer realism. Also a model is builtto study on optimization aspect of a HSPA network.The organization of this thesis is as follow: 1) An overview of UMTS and WCDMAnetwork; 2) An introduction to HSDPA and HSUPA; 3) A brief survey on existingtools, frameworks and tool selection; 4) System Model Development; 5) Imple-mentation; 6) Results; 7) Conclusion; 8) Future work.

1.1 Overview of the Universal Mobile Telecom-munication System (UMTS)

A UMTS network comprises a hierarchy of nodes and interfaces, as presented inFigure 1.1. The User Equipment (UE) in 3GPP terminology is a device in the

7

8 Introduction

RNCRNC

PSTN Internet

NodeBNodeB

Core Network

Iu

Iur

Iu

Iub

NodeB

NodeB

Radio Network Subsystem (RNS)

Figure 1.1: Overall Architecture of UMTS network

network which can communicate wirelessly with one, or more, fixed nodes referredto as NodeB. The NodeBs are responsible for all physical layer activities such ascoding, spreading, modulation, transmission, and radio signal reception. A RadioBase Station can be referred to as a NodeB, since the number of cells (normally1 to 3 cells) is defined as a NodeB. The Access part of the network is supportedby the NodeBs. Several NodeBs are connected to the Radio Network Controller(RNC) through out Iu Interface, and network of RNCs and other entities such asgateways, build the Core Network

A radio network controller is in charge of several NodeBs and activities such as:Radio resource control, QoS assurance, interfacing the gateways, and call setup.Similarly to the other layered communication systems, UMTS architecture is alsolayered as shown in Figure 1.3. In the radio interface of the UMTS network thereare 3 layers similar to ISO/OSI model: a) The physical layer; b) The data linklayer; c) The network layer.

The radio link control (RLC) and media access control (MAC) form the datalayer (layer 2) as shown in Figure 1.3. The network layer (Layer 3) is split intocontrol and user planes (C-plane and U-plane), whose main function of controlplane is radio resource control (RRC) and main user plane function is the RLC.Layer 3 and layer 2 are located in the RNC or core network and layer 1 which isthe physical layer in NodeB. The UMTS stack protocol is presented in Figure 1.2.

As shown in Figure 1.3 node-wise, there are two major layers : The RNC andthe NodeB. The Radio Link Protocol (RLC) is located in user plane and controlplane. There are Automatic Repeat-reQuest (ARQ) schemes implemented in the

1.1 Overview of the Universal Mobile Telecommunication System (UMTS) 9

Figure 1.2: Umts protocol stack

RLC. The RKC is responsible for: a) Segmentation of IP packets into RLC protocoldata units (PDU); b) Concatenation and Reassembly of PDUs; c) Padding in thePDUs; d) Error detection and recovery.In Figure 1.3 the Packet Data Convergence Protocol (PDCP) in user plane isan optional function to compress IP headers. Both user plane and control planecontain a Medium Access Control (MAC) layer, which in general handles logicalchannels and transport channels. The MAC layer also multiplexes data fromdifferent logical channels. The MAC sublayers will be discussed later in the HSPAoverview section.

Figure 1.3: UMTS Radio Interface protocol layers [1]

Before introducing the HSPA protocol and the MAC layers a brief review of theWideband code division multiple access (WCDMA) physical layer used in UMTS,

10 Introduction

is discussed in the next section.

1.1.1 Physical layer (PHY) in WCDMAThe Physical layer is responsible for coding, spreading and modulation in additionto transmission and reception the radio signals. The Multiple access method usedin WCDMA is Direct-Sequence code division multiple access or DS-CDMA whichuses a constant chip rate of 3.84 Mcps. The spread information is carried later withthe bandwidth of 5Mhz. The modulation schemes used are QPSK and 16QAM.16QAM was introduced after the release 99 to achieve higher data rate. In thefeasibility studies higher modulations such as 64QAM is proposed. The 16QAMperformance is suitable for a low-bandwidth connection with high Eb/N0 scenariosthat means those user equipment, which are closer to the NodeB. A constellationexample of QPSK and 16QAM is shown in Figure 1.4.

Figure 1.4: QPSK and 16QAM constellation

Coding and Spreading

With the help of several modulation/coding combination schemes, WCDMA has ahigh variable user data rates. A WCDMA frame length is always 10 ms. Althoughuser data rate can not be changed during a frame length, frame to frame, datarate can vary. The spreading is performed by orthogonal variable length Walshchannelization codes, which are also called Orthogonal Variable Spreading Factor(OSVF). The Spreading is used in the uplink to differentiate several user equip-ment, while it is used in the downlink to differentiate cells. The first few levels ofthe OSVF are shown in Figure 1.5.

Power control mechanisms

The WCDMA has a fast power control mechanism originally, both for downlinkand uplink to maximize the capacity that is described as bit power per hertz perunit time. Since all the nodes are most of time using the same frequency and per-haps same timeslots (with different codes), it is important to keep the interferenceas low as possible, specially for the uplink 1. In WCDMA, base station estimatesthe received Signal-to-Interference Radio value (SIR) for each user equipment. If

1Although in WCDMA FDD the uplink and downlink use different frequencies, still theinterference in uplink is more important for the sake of user equipment.

1.2 High Speed Downlink Packet Access 11

Figure 1.5: Channelization Code [10]

the estimated SIR value is higher than the allowed SIR, that is a predefined value,the base station commands the user equipment to lower its power, and if it is lowerthan the target SIR value, base sation commands the user equipment to increaseits transmission power. The whole process is performed 1500 times per secondand is called Closed loop power control. The closed loop power control frequencyis faster than possible fading and path loss.

To adjust the allowed SIR in each base station for every single radio link,there is another loop control called Outer loop control that is controlled in theRNC. The outer loop control corresponds with a target bit error rate (BER) orinterchangeably, a block error rate (BLER). The movement and speed of the userequipment are variables that affect the SIR due to both path loss and fading.Hence RNC commands the NodeB to change the allowed target SIR per radio linkover time as shown in Figure 1.6, i.e. Fast moving user equipment will have higherallowed target SIR to stay below the maximum BLER (for example 10%)[15].

Speed of UE

UE is not moving

0

Allowed SIR

Time

Figure 1.6: Outer loop power control mechanism and the allowed SIR of a userequipment according to its speed

1.2 High Speed Downlink Packet AccessAs mentioned earlier HSDPA is an enhancement to the WCDMA and UTMSnetworks since release 4. In the release 5 high data rates up to 8-10Mbps were

12 Introduction

specified. Multi-Input Multi-Output (MIMO) were added to the HSPA specifica-tion as of the release 6 which increased the data rate up to 20Mbps. At the sametime with the newer releases of HSPA (release 7 and later), Long Term Evolu-tion (LTE) started in a workshop in 2004 and was approved in June 2005 [10].LTE is designed to achieve much higher spectral efficiency than in WCDMA andlower delay in data connections. LTE is not backward compatible with HSPA andWCDMA. By the time LTE is still under development (very few major cities inSkandinavia have up to now installed the infrastructure, and the selection of userequipment with LTE available, is not yet in double digit) and evolving to LTE-Advanced, HSPA is also evolving to HSPA+.

HARQ with soft combining, higher order of modulation, turbo coding, andchannelization codes are incorporated in HSDPA to reach highest throughput pos-sible. In this part a more detailed description of the HSDPA will be discussed. Anoverview of the HSDPA protocol architecture is shown in Figure 1.7.

L2

L1

HS-

DSCH

FP

RLC

L2

L1

L2

L1

L2

L1

HS-

DSCH

FP

Iub Iur

PHY

MAC

PHY

RLC

Uu

MAC-

hs /

MAC-

ehs

HS-

DSCH

FPHS-

DSCH

FP

MAC-c/sh

MAC-D

Figure 1.7: HSDPA protocol architecture [2]

1.2.1 The High Speed Downlink Shared ChannelThe High Speed Downlink Shared Channel (HS-DSCH) was introduced in release5. All the users data are carried within the HS-DSCH and the shared channelis the main concept in the HSDPA. The HS-DSCH is power controlled so it usesthe remained power in a cell based on need as shown in Figure 1.8. The shorterTransport Time Interval (TTI) of 2ms comparing to 10,20,40 or 80ms in the release99 helps to have shorter round trip time in favor of high bit rate applications. Theshorter TTI causes in an excessive overhead in the signalings.

The Spreading Factor (SF) is always fixed to 16. The first code is reserved foruse in the High-Speed Shared Control Channel (HS-SCCH) for all user equipment,hence there are just 15 available codes which are mutually orthogonal to be usedby the user equipment in each TTI as shown in Figure 1.9. The code sharing isperformed in the time domain to adapt the user data rate according to the channelvariation, through scheduling mechanism. Each channelization set is referred toas High-Speed Physical Downlink Shared Channel or HS-PDSCH. The HS-SCCH


Unused Power

Dedicated Channels

Time

Power

Common Channels

(a) Unused power with dedicatedchannel only

HS-DSCH Power

Dedicated Channels

Time

Power

Common Channels

Tota

l Available

Cell P

ow

er

(b) HS-DSCH dynamic power alloca-tion

Figure 1.8: HS-DSCH power usage

is used for the downlink signaling and is received by all the terminals which areusing the HS-DSCH regardless of scheduling for the terminal. It uses spreadingfactor of 128 and can contain 40 bit per slot after channel encoding.

Figure 1.9: Time and code structure for HS-DSCH[10]

The dynamic variation of the code assignment per user in HS-DSCH is usedfor the rate-control and the scheduling. To support Hybrid-ARQ (HARQ) aftereach TTI an ACK or a NAK must be sent in the uplink to identify the success ofdata reception in the user equipment from HS-DSCH. The High-Speed DedicatedPhysical Control Channel (HS-DPCCH) is used to send the ACKs and NAKs inuplink. For each user equipment an HS-DPCCH is configured. the measurementinformation of the Channel Quality indication (CQI) needed by NodeB for thescheduling and the rate control is sent within the same HS-DPCCH by each userequipment.

1.2.2 MAC-hs and PHY layersThe MAC-hs in UMTS architecture is a part of MAC layer and resides in NodeBand the user equipment. MAC-hs is responsible for scheduling, rate control andHARQ (along with in sequence delivery to above layers) as shown in Figure 1.10,data is received from the MAC-d to the MAC-hs is going through a priority han-dling and scheduling which will be discussed under the rate control and scheduling.In the physical layer a 25-bit CRC is attached to each transport block to help userequipment and its HARQ mechanism to detect any error.

14 Introduction

CRC attachment

MAC-hs

Scheduler

HARQ

Code block segmentation

Channel Coding

Physical channel

segmentation

Physical Layer Hybrid-ARQ

functionality

HS-DSCH

Interleaving

Physical channel mapping

Constellation

re-arrangement

for 16QAM and 64QAM

Bit Scrambling

Priority

Buffers

Mac-d flows

Figure 1.10: MAC-hs and PHY layers processes

Scheduling and rate Control

The MAC-hs controls the transport block size and the power in each TTI per userwhich is the key feature of the HSDPA performance. The number of users, dis-tance of users to the cell center, carrier to interference of each user that gives thetotal C/I in the cell, and channel conditions are parameters being used to decideabout the power and the transport block in each TTI. There are several methodsfor scheduling such as Round Robin, Max C/I, and Fair channel dependent.


• Round Robin scheduling is the simplest one. All the users who have some-thing to receive will have an equal time share of the HS-DSCH.

• Max C/I strategy is giving a higher priority to the users with better channelcondition.

• Fair channel dependent is based on two main factors:

– Current Channel condition of the user equipment– The Data flow priorities and buffer status of user equipment

The Channel condition of a user equipment is reported by the user equip-ment through a 5-bit CQI report through HS-DPCCH in the uplink to a NodeB.The CQI is not explicitly an indication of the channel condition but rather basedon the received common pilot. The signal-to-noise ratio is calculated by the userequipment and is reported as a recommended transport block size in the CQI.Better channel conditions can lead to use of higher order modulation and lowerorder of coding rates, such procedure is called Adaptive Modulation of Coding(AMC). Both of these settings can be configured in each TTI of 2ms, so it canrespond fast enough to the fast channel condition variations. The transport blocksize can be configured from 137 to 27952 bits with channel coding rates of 1/3 to1. As discussed earlier 16QAM can be used in non-power limited scenarios whichmeans it is available to the users close to the base station and user equipment withadvanced receivers. The power used in the HS-DSCH is limited by the Radio re-source control (RRC) in the RNC to keep the C/I ratio within an acceptable value.The measurements are reported to the RNC by the NodeB and those reports areused to calculate the non HS-DSCH channels power for admission control in theRNC.The data flow priority and buffer status can indicate, how flexible the traffic is; e.g.a streaming service flow cannot be held scheduled for a long time. The priorityqueues are defined in the scheduler and data are selected from each of them basedon the flow priorities. In Figure 1.11 the relations of the scheduler and the priorityqueues are shown.

Hybrid-ARQ with Soft combining

Hybrid-ARQ is used in the MAC-hs in the NodeB and its counterpart in the userequipment. Since HARQ is implemented in NodeB and after that, it is done with-out passing through IuB link from NodeB to the RNC. As a result in case of apoor RNC link any delay is avoided. Each transport block goes through the HARQprocess is transmitted in every TTI of 2ms, and retransmissions are sent per same2ms TTI which means shorter round trip time than R99.

If the user equipment receives an erroneous PDU which cannot be decoded, itsaves it in the HARQ process buffer; sends a NAK to the sender and waits fora retransmission of the same packet. When the retransmitted bits are receivedthe user equipment soft combines its buffer with retransmitted bit for a second

16 Introduction

UE j Flows

UE i Flows

CQI Reports

From UEs

HS-DSCH transport block

Figure 1.11: Queue and priority handling by Scheduler [14]

decoding attempt. Since the process is a stop-and-wait process and a continuousdata flow is necessary in most cases several HARQ processes work in parallel.Based on manufacturers implementations, a user equipment can configure up to8 parallel HARQ processes. Each of the HARQ processes has its own buffer todo the soft combining. In user equipment, according to result of CRC from atransport block a retransmission is requested. There is a single bit indicator thatshows if received data is a new one or a retransmitted block. This bit is set in theMAC-hs at the NodeB for every transmission. The user equipment uses this bitin order to continue to soft combine. The same single-bit indicator can be usedto measure the channel quality in case that user equipment receives an indicatordespite the value it was anticipated. Based on the processing time in the NodeB,up to 8 paralleled HARQ process can be configure and the typical number ofprocesses is 6. The Number of HARQ processes depends on the total round triptime, which consists of the TTI, processing delay in NodeB and user equipment,radio propagation and interference delay in both the uplink and the downlink. AsHARQ processes work independently on their own buffers, so the outcome of allprocesses would be out-of-sync. Therefore there must be a reordering functionto eliminate unnecessary and duplicated-even-correct Mac-hs PDUs and put thecorrect PDUs in order to be sent up to the higher level.The Reordering entity uses the transmission sequence number in MAC-hs headerto reorder the blocks. Reordering buffers are used to keep blocks in respectiveplaces in buffer and pass them to higher level in the correct order. A timer isused to for each block to avoid stalling and only one active timer exist in theprocess. If timer expires for a specific block all the previous blocks will be sent upto MAC-d layer. Since there is a timer defined similar to TCP protocol a windowcan be defined which is called stall-window. When window-based stall avoidancemechanism is used in case of timeout all the blocks reordered within the window


are dispatched to MAC-d layer.

Data flow in HSDPA

In brief the transmission of a TCP/IP packet from the RNC to the user equipmentis as following: the PDCP optionally compresses the IP header and sends it tothe RLC, the RLC segments the received PDCP Protocol Data Unit into typically40-byte of data units called RLC PDU. If any multiplexing is needed in the MAC-d, a header of the MAC-d is added to the RCL PDU and the result is fed intothe MAC-hs in the NodeB. A MAC-hs may include several RCL PDU or onlyone PDU. The MAC-hs header is attached to the frame and a transport block isbuilt. The final result is ready to be sent through physical layer process to betransmitted over the radio channel. The whole process is shown in Figure 1.12.

Higher Layer

L1

Higher Layer PDU

RLC SDU

MAC-d SDU

MAC-d PDU

…

RLCheader

RLC

header…

MAC-d SDU

MAC-d PDU

CRC

…

…

MAC-dheader

MAC-d

headerL2 MAC-d

(non-transparent)

L2 RLC(non-transparent)

Segmentation &Concatenation

Reassembly

Higher Layer PDU

RLC SDU

MAC-hs SDU MAC-hs SDU…MAC-hsheader L2 MAC-hs

(non-transparent)

Transport Block (MAC-hs PDU)

…

Figure 1.12: Data flow example in HSDPA for IP packet traffic [1]

Resource control signaling

Since a channel-dependent scheduling is used in the HSDPA, the RRC is handledin the NodeB instead of RNC to overcome the fast channel changes, but the RNC isstill responsible for the other RRC activities such as handovers and call admission.The NodeB should report to the RNC, the transmitted carrier power of all codesnot used for the HS-PDSCH or the HS-SCCH, which is based on what the RNCwill configure the HSDPA limit in the NodeB. The NodeB is free to set the powerin the HS-DSCH as much as necessary up to the limit set by RNC. Other signalingis defined to report the bit rate measurement to the RNC so the RNC can signalthe guaranteed bit rate to the NodeB which is used in MAC-hs scheduler. Thedirection and the source of signaling channels are shown in Figure 1.13.

18 Introduction

Figure 1.13: Measurement and signaling channels between NodeB and RNC

Mobility

As in the nature of any mobile network, the HSDPA needs to support mobilityfor the user equipment. Handovers are Network driven based on user equipmentmeasurement reports. The RRC will decide to hard handover the user equipmentbased on its active set and its measurement report. During the handover currentNodeB has to sent its current buffer in Mac-hs to the new NodeB, and the newNodeB must initiate an HS-DSCH to serve the coming user equipment. Since theMac-hs protocol is reset during the handover the HARQ buffers are not transferredto the new NodeB so the HARQ buffer must be kept as small as possible[10]. Thereare proposals for transferring the HARQ buffer such as in heterogeneous networkutilizing relay nodes [6][5].

User Equipment Categories

There are different user equipment with different processing power, amount ofmemory, and radio interface. According to these properties each user equipmenttype can reach to a certain throughput. The throughput of all UE type are listedin Table 1.1.

1.3 High Speed Uplink Packet AccessThe High Speed Uplink Packet Access (HSUPA) has been introduced in release 6to increase the data rate and to reduce the latency. The HSUPA shares HARQand scheduling schemes existing in the HSDPA, with some slight changes. Thetransport channel in the uplink is called Enhanced Data Control Channel (E-DCH). There can be one or several E-DCH configured with one or more DedicatedChannel (DCH), so the user equipment can reach higher data rates both in theuplink and the downlink. E-DCH and DCH processes are shown in Figure 1.14.

The main differences between HSDPA and HSUPA are:

• In the HSDPA both the scheduler and the transmission buffers are in theNodeB, but in the HSUPA, since the user equipment is transmitting, the

1.3 High Speed Uplink Packet Access 19

Table 1.1: User equipment categories

HS-DSCHcate-gory

Maximumnumberof HS-DSCHcodesreceived

Minimuminter-TTIinterval

Maximumtrans-portblocksize softbit

Bitrate(Mbps)

Maximumnum-ber ofschemes

Supported mod-ulation

1 5 3 7298 3.6 19200 16QAM,QPSK2 5 3 7298 3.6 28800 16QAM,QPSK3 5 2 7298 3.6 28800 16QAM,QPSK4 5 2 7298 3.6 38400 16QAM,QPSK5 5 1 7298 3.6 57600 16QAM,QPSK6 5 1 7298 3.6 67200 16QAM,QPSK7 10 1 14411 7.2 115200 16QAM,QPSK8 10 1 14411 7.2 134400 16QAM,QPSK9 15 1 20251 10.1 172800 16QAM,QPSK10 15 1 27952 14 172800 16QAM,QPSK11 5 2 3630 1.8 14400 QPSK12 5 1 3630 1.8 28800 QPSK

transmission buffer is in the user equipment. Therefore all the user equip-ment must inform NodeB Scheduler about their transmission buffer.

• In the HSUPA, the user equipment of a cell are sharing the allowed trans-mission power to keep interference below the allowed SIR.

• In contrast to the HSDPA which transmission channels are Orthogonal, E-DCH is Non-Orthogonal. Due to Near-Far problem in the uplink a fastpower control is necessary, which on the contrary in the HSDPA a constanttransmission power is used.

Scheduling

The NodeB grants time to each of the user equipment based on its schedulinggrants and scheduling request received from all of the user equipment. The userequipment are granted to use E-DCH so the interference in NodeB does not exceedthe allowed SIR. More grants (i.e longer time share) means more data rate for userequipment in the uplink but it means also more interference received in NodeB.The NodeB scheduler throttles user equipment to keep SIR for the own cell or inter-cell interference within the limit. The scheduling, similar to HSDPA, is performedper TTI in parallel for several user equipment to admit several high-peek ratedemanding users at the same time.

HARQ and Soft Handover

NodeB sends ACK/NACK to the user equipment, and the user equipment learnsif the transmission was successful or not. Unlike the HSDPA, user equipmentpair for HARQ can be in several NodeBs instead of only one. Hence for the userequipment it is enough to receive ACK/NACK from any of the NodeB in its activeset.

20 Introduction

Figure 1.14: E-DCH and DCH processes [10]

1.4 Review of Available Simulation PlatformsThere were two approaches to realize this thesis project: to use a commercialHSDPA simulator, or to use a non-commercial network simulator and to buildthe HSDPA simulation module. Commercial simulators, such as OPNET, werediscarded due to potential delays in obtaining the necessary license and flexib-lity in programming. In the next sections a short review on two major existingopen-source network simulators are considered. Since NS-3 was chosen to be theplatform to work with the NS-3 section is more in depth to familiarize more thereader with it. Also a brief survey over commercial solutions evaluated is pre-sented.

1.4.1 NS-2The NS (The Network Simulator) or NS-2 as variant of the REAL network simu-lator in 1989, is a discrete event simulator. DARPA has sponsored NS since 1995.NS-2 is written in C++ and OTcl. Its front language to write user scripts for thesimulations is Tcl. The core of the simulator is written in C++ which is mainlyanything with packet processing. To connect Otcl and the Tcl user front-end tothe core of the simulator, there is a one-to-one hierarchy corresponding from C++model to Otcl model, shown in Figure 1.15. NS-2 existing core capabilities are

1.4 Review of Available Simulation Platforms 21

C++ OTcl

Figure 1.15: The Object created on OTcl has a corresponding object in C++

widely ranging from application layer to physical layer for many different types ofprotocols, network devices and etc. There are many contributed codes to NS-2 soit is being still extended and developed, such as WPAN (ZigBee) module, AODV,or DSR routing algorithm. The main NS-2 functionalities are: wired, wireless,satellite network simulation, Transportation layers (TCP, UDP, Mutlicast, Uni-cast), Traffic sources (CBR, FTP, HTTP), Routing algorithms, Queuing policy,QoS, Sensor Networks, Tracing, Random number generator, Mobile IP, Mobilitymodels, and network animation. The advantages in using NS-2 can be briefed asbelow:

• Many protocols are implemented.

• Realistic mobility models.

• A large community to find official support.

• Many samples to start with.

• An animation engine (NSANIM).

• Open-source and GPL license.

Although the above advantages seems promising, there are some disadvantagesas well:

• Long learning curve.

• Documentation is not easy to find, Mostly spread in the Internet.

• Bi-language approach is not easy to deal with.

• Due to bi-language development of NS-2 it is not easy to debug.

• It needs too much of memory in long running scenarios with many packetsbeing transmitted.

• No official support available

22 Introduction

In NS-2 only supported trace sink is ASCII output file. To refine the results atext processor such as python or AWK should be used.

1.4.2 NS-3NS-3 is a discrete-event network simulator similar to NS-2. It is written fromscratch after its predecessor, it is not an upgrade from NS-2 and it is not backwardcompatible. NS-3 core is written with C++ with an interface to support pythonscripting as well, so it is possible to write scenarios in pure C++ or in python.It is completely different than NS-2 whose core was based on C++ and the frontend was accessible only through TCL. Using a single language in developing thecore, simulator, models, topology definitions, and scenarios make the debuggingmuch easier than it is in NS-2 which is a bi-language approach. NS-3 version atthe time of this thesis is 3.9. Upgrades are released every 3 months regularly.NS-3 architecture is organized into NS-3 core, common objects, simulator engine,mobility, node, routing, internet stack, network devices, and helpers shown inFigure 1.16.

Core

Common Simulator

Mobility Node

Routing Internet Stack Devices

Helper

Figure 1.16: Software organization

Key Concepts

The NS-3 Architecture concept is somehow similar to a computer case where thereis a motherboard and some Network Interface Controller(NIC) which are used byseveral applications. The key concepts are: Node, Packet, and Channel.

Node A node in NS-3 can have several interfaces, applications, functionalitiessuch as mobility. For instance a node can have a wireless NIC with UDP trafficthrough it and a wired NIC which is transferring TCP traffic. Nodes are instancesof the class ns3::node. A high level architecture of the node is shown in Figure1.17. The Aggregation concept in NS-3 helps the extension of a node much easierthan before in NS-2. Internet stack, mobility, application, or any other definedobject with proper interface to the node can be aggregated to the node. So it is notrequires to define different types of node to support for different functionalities.

An NIC is a Net Device (NetDevice) in NS-3. Current available netdevices inNS-3 are:


Figure 1.17: High-level architecture of node

• PointToPoint NetDevice

• CSCMA NetDevice

• WiFi NetDevice

• Mesh NetDevice

• Bridge NetDevice

• WiMax

• UAN (Underwater Acoustic Net-work)

Packet Packets are what the most of the simulation is based on. A packet isconsisted of a byte buffer, a list of bytes, packet tags, packet headers and packetmetadata. In NS-2 it was almost a cumbersome duty to define a new type ofpacket. New packet type must be defined both in Tcl library of simulator and alsoin the header file "packet.h".The approach to define a new packet is totally revisedfrom what has been done in NS-2 based on the facts below:

• Staying clear from changing the core and simulator.

• Making it easy to support fragmentation, defragmentation, and concatena-tion which are important in wireless networks.

• Increasing the memory efficiency.

• Possibility to have real data or dummy data based on application and usage.

In NS-2 memory management was not easy; in addition to that NS-2 saves allpackets in memory during the simulation which for large networks is very mem-ory consuming. In NS-3 using virtual buffer of zero-filled helps to use much lessmemory.

24 Introduction

Channel The Channel is attached to the Netdevice that means there is onechannel per Netdevice such as PointToPoint channel model, CSMA channel model,and Wireless channel model. Since in NS-3 it is possible connect netdevices withonly NS-3 sockets, channels are introduced to replace socket programming in NS-3.

Programming Concepts

In NS-3 functions and concepts are used to help users to write scenario and newmodules in higher levels and in a more managed state than in NS-2. Some of themare as below:

CallBack Although there are already methods in C++ to implement thecallback, in NS-3 a separate API is implemented to support callbacks. It is de-signed to enable the developer to call a function or method from any piece of codewithout dependency between modules.

Attribute Attributes are the way to get access to internal member values ofan object. These values can have default values in the code in the traditional wayin C++, addressed with file system-like path, or through command-line arguments.Configuration of the attributes of the objects in the scenarios either with defaultvalues or without them can be done through different approaches:• XML files

• Environment variables

• In the topology (scenario) definition file

• Command prompt

Smart pointer The concept of smart pointer [13] is used instead of classicpointer to help with:• Emulation of garbage collection as existing Java

• Keeping count of object to help memory management

Helper API Usually simulation scenarios consists of several similar objects;in such case defining each of those objects using the API in a object-by-objectfashion would be quite long and a tedious coding style. Hence Helper API isdeveloped to mitigate those problems. The Helper API is aimed to maximumcode reuse. There is a container API, which is used to contain number of sameobjects or a group of objects and also enable the user to perform the same actionon the group. The helpers and the containers are mostly loops to perform recursiveactions.

Random variables There is a pseudo-random number generator (PRNG)available in NS-3. The random numbers can be generated via instances of classRandomVariable and existing random classes derived from RandomVariable are:


• Uniform Variable

• Constant Variable

• Sequential Variable

• Exponential Variable

• Pareto Variable

• Weibull Variable

• Normal Variable

• Empirical Variable

• IntEmpirical Variable

• Deterministic Variable

• LogNormal Variable

• Triangular Variable

• Gamma Variable

• Erlang Variable

• Zipf Variabled

One of the usage for such variables could be to generate traffic. For example apareto variable can be used to define the start/stop time of a TCP traffic over alink.

Logging and Tracing Tracing is completely different than it is in the NS-2approach, it is not necessary to change the core to have a new type of tracingsystem. In NS-3 tracing source remains the same but sink can be customized byuser to have one or several types of output for the tracing. In other word userattaches the source to the customized trace sink as shown in Figure 1.18

Trace Source

Trace Source

Trace Source

Trace Sink

Different trace sources

from different objects

Configureable sink type

by user

Unchangeable format in sources

Figure 1.18: Tracing concept in NS-3

Three different level of tracing can be defined in NS-3:

• High-level: Build-in trace source is attached to user sink

• Mid-level: Customized sink or source are used to trace

• Low-level: Adding new tracing sources to the tracing namespace.

Traces can be saved in ASCII text format or in Pcap compatible format. the latterformat is completely standard and can be read with wireshark or similar network.

26 Introduction

Debugging It is possible to use in code printing to debug or use an API tomake the debugging and code tracing neat and clean. There are several logginglevels (for debugging) that can be enabled in during the simulation. Some thoseare in the following:

• NS_LOG_ERROR (...): Serious error messages only

• NS_LOG_WARN (...): Warning messages

• NS_LOG_INFO (...): Informational messages (eg. banners)

Visualization There are several animation and visualization tools currentlypossible for example:

• Gustavo Carneiro’s PyViz

• George Riley’s NetAnim

• Hagen Paul Pfeifer’s OpenGL animator

• Colorado School of Mines iNSpect tool

• Eugene Dedu, awk scripts for ns-3 and nam

At the time this work, NetAnim can be used for point to point simulation only asin Figure 1.19. PyViz is in progress and is becoming the popular visualizer of NS-3.It is capable to showing real time traffic information on links, or other informationsuch as routing table, traffic type, or number of packets sent and received.

Figure 1.19: NetAnim GUI


Emulation The emulation mode lets user to connect to real world systemsto send and receive data to them, so it is possible to use the real system as atestbed. For example ORBIT testbed which is a laboratory with a 2-dimensionalnetwork of 400 IEEE802.11 radio nodes. In Figure 1.20 a sample of a TestBedemulation is shown.

Figure 1.20: Example of TestBed emulation

Radio Propagation Models available in NS-3

To have a real time realistic simulation of the channel, NS-3 currently has severalpropagation loss models, as following.

• Fixed Rss

• Friis

• Jakes

• Log Distance

• Nakagami

• RandomFixed Rss

• Three Log Distance

• Two-Ray ground reflection

Current propagation delay models available in NS-3 are:

• Random propagation delay

• Constant speed propagation delay

1.4.3 Comparison between NS-2 and NS-3Before moving to next part a comparison between NS-2 and NS-3 is given in Table1.2. The comparison almost covers all the key aspects of a simulator

28 Introduction

Table 1.2: Comparison between NS-2 and NS-3 from different aspects

Flexibility It has been designed as a(TCP/IP) network simulator,and it difficult to simulate thingsother than packet-switching net-works and protocols with it. Ev-erything such as nodes, agents,protocols, links, packet rep-resentation, and network ad-dresses etc is hardcoded. Ev-erything that is new needs tobe written mostly again, almostimpossible in re-usability

Separation of every element innetwork from their actions andcapability or as it is calledin documentation Object ag-gregation model, Standard in-put/output formats so othertools can be used like as wire-shark to read trace outputs.

ProgrammingModel

Mixed-mode: OTcl (Object-Tcl)with underlying C++ classes.OTcl is also used for creat-ing and configuring networks,recording results etc.

Object-oriented, pure C++ lan-guage for modules, models andscenarios, Bindings in Pythonfor scenarios written in python.

Model man-agement

Not clear API, Core is not to-tally separated, Mostly patchesare necessary (ns-default.tcl forexample).

A stand-alone core, Compo-nents are added in separated li-brary done by researcher, Possi-bility to import models (not yetimplemented).

Support forHierarchicalModels

In NS-2, models are "flat": cre-ating subnetworks, or imple-menting a complex protocol as acomposition of several indepen-dent units (that appear as oneunit) are not possible in NS-2.

Object Aggregation lets build-ing complex compound unitsfrom simpler elements.

Debuggingand TracingSupport

Two languages to debug, Octlcode is not easy to debug, Noteasy to change the tracing for-mat.

Easy to debug since there is onlyC++ language.Tracing sink isconfigurable but tracing sourceis same for all modules. Tracescan be read with third partysoftwares like wireshark.

Variety ofModels Avail-able

Since it has been used for longtime in researches, a large num-ber of models and protocols areavailable. Some are still activeand most of them are not.

There are mix of new and portedmodels available. Wirelessmodel is written from scratchaccording to IEEE802.11 speci-fication, New models are beingadded by some universities fromItaly, Russia, Germany and oth-ers recently.


Table 1.2: (continued)

Term NS-2 NS-3Documentation Not enough documentation on

the API. Most of modules arenot documented or rarely doc-umented. Documentation isfound here and there withoutany central library. No main-tainer to keep documents up-to-date.

The core is highly documented.Doxygen is used to generatedocuments for each piece ofcode. Documentation is beingupdated regularly for everythingin NS-3.

Ability toRun LargeNetworks

It is not very good in sim-ulating large networks dueto its memory managementflaw which keeps all data inmemory until the stop timeof simulation. “Segmentationfault”happens mostly due tomemory management.

New memory management andits new core enables users tosimulate very large networks.

Maintenanceof engine andmodels

The engine is still supported bythe owners but since NS-3 isstarted there would be no newversions coming. Modules arenot supported officially by thecontributers. Mostly no contactcan be found in case of problemsand question. There is still anactive mailing list.

A new stable release is outabout every 3 months, Modulesare officially maintained by theowners or contributers, Thereare contacts available for ev-ery module that are responsiblein case of questions and more,There are workshops and web-casts, It also has an active mail-ing list.

Licensing GPL GNUv2

Why NS-3?

The advantages of NS-3 can be listed as below:

• Regular updates (a complete new release every three or four months)

• Available maintainer

• Active mailing list

• Several contributors from universities

• Complete documentation on simulator code

• GNU GPLv2 license

• One single language approach for everything: Used only C++

30 Introduction

• Very good software architecture with planing to keep the NS-3 project alivefor long term

• Good memory management

• Better method to trace, log and to debug

• Flexible API

1.4.4 Enhanced UMTS Radio Access Network Extension(EURANE) for NS-2

Enhanced UMTS Radio Access Network Extension for NS-2 [19], initially startedin 2004, developed within the SEACORN project by Ericsson. It is compatiblewith version NS-2.30 although it is possible to apply the patch to higher versionsbut it is not recommended. In EURANE there are three nodes possible to define:RNC, RBS, UE. Nodes are general NS-2 nodes. 4 types of transport channel aredefined:

• FACH

• RACH

• DCH

• HS-DSCH

The Mac-d and Mac-hs protocols are defined, which Mac-d is defined within theRLC and Mac-hs is defined within the NodeB and the user equipment. The RLCsupports Acknowledged Mode (AM), and Unacknowledged Mode (UM). There areseveral parameters available to tweak which are:

• Downlink Bandwidth

• Downlink TTI

• Uplink Bandwidth

• Uplink TTI

The same parameter can be configured for FACH, RACH, and DCH. As it ismention in section 1.1 the RNC and its NodeBs are communicating through theIuB interface. In EURANE, IuB interface should be defined with configurableparameters follows:

• Downlink bandwidth

• Downlink delay

• Queue type

• Uplink bandwidth

• Uplink delay

• Queue size

In 2006, Abdulmohsen Mutairi [19] provided a static multicell (UE attachmentshould be done in scenario) with a semi-dynamic channel model patch for theexisting EURANE. Fast fading, shadowing, CQI calculation based on BLER fileare added in this new patch.The RLC AM or UM mode can be configure with a wide range of parameters suchas: window size, payload size, ACK size, retransmission time out, TTI. The RLCUM is responsible for :


• Segmentation and reassembly of IP packets into Mac-d PDUs

• Sequence number check of each PDU

• Padding the PDU according to size of incoming packet

• Transfer of user data

And The RLC UM task in EURANE is defined as: RLC UM is responsible for :

• Segmentation and reassembly of IP packets into Mac-d PDUs

• Concatenation

• In sequence delivery of PDUs to higher layer

• Duplicate detection

• Flow control

Mac-hs can be defined in UM mode or in AM mode. Possible configurationsfor the Mac-hs protocol are: TTI, Delay. Mac-hs PDU reordering is also availablewhich its maximum number of flow and priorities can be configured. HARQ isalso implemented with configurable number of processes and also delay of processfor ACK.In initial version of EURANE there is not any real channel type. The only inputto the simulate the channel is input file for CQI/BLER.

Trace format Trace format of EURANE is in text format as it is in NS-2.trace format is shown in Figure 1.21.

Figure 1.21: EURANE trace format

According to latest EURANE manual there is a knonw issue which is notpossible to configure odd number of UE nodes in simulations. As it is mentionedearlier EURANE is developed in NS-2 and it is not being maintained anymore.As it was already discussed, it would be wise not to work on the NS-2 to be ableto well maintain the code and also develop and expand it much easier later. Sothe whole simulation module was decided to be written from scratch and also portsome parts of the EURANE codes to a new NS-3 based module.

32 Introduction

1.5 A Brief Survey on Commercial HSPA Simu-lators

In this section a short survey on some commercial available solutions is presented.Most of them support the HSDPA network and can present the results such asEc/N0 graphically. Most of them support DCH in r99, traffic generator, CQIreport, in addition to HSDPA. There are some simulators that let the user tostudy on specific channels such as CPICH

1.5.1 WinProp/ProManWinProp [22] is a product of AWE Communication Gmbh, it is designed to evalu-ate system performance, measure the throughput (cell and user based), and studyon user QoS for Packet switch network (PS).

(a) Peak rate (b) CQI

Figure 1.22: WinProp Visualization

There is a packet generator, that transmits packet considering the interferencelevels. there are different modulation/coding schemes available to simulate inaddition to different user equipment types. The system performance and theuser QoS can be studied and be changed through network layout or parameters(capacity, coverage). Different simulation can be run in parallel for example HSPAand CS traffic. WinProp support several traffic model with customizable traffic insessions (HTTP, FTP...).

Main Features are:

• Propagation and Scenarios: Rural, urban, indoor, tunnel scenarios

• Service Mix: Spreading factor, PS traffic definition, target SNR, Mobiletypes, multiple services in one simulation run.

1.5 A Brief Survey on Commercial HSPA Simulators 33

• HSDPA: Modulation, Block size, number of codes, packet processing (Seg-mentation/concatenation), Interference level determination, CQI report, HARQ,Higher level retransmission (RLC)

• Link level performance: Import BLER performance tabled, Open ASCIIinterface

• Output: HSDPA peak rate, Reported CQI values, offered and carried traffic,packet transmission statistics, power, code

WinProp can visualize the HSDPA peak rate, CQI. Peak rate is influenced bynetwork layout or better say NodeB antenna vector (as in handbook), the impactcan be studied and visualized with the simulator.

1.5.2 N2NSOFTN2NSOFT [17] is made by the company with same name located in France. Themodule developed by the company within the N2Nsoft to simulate HSPA networkis named NetScale. With NetScale it is possible o design, dimension and optimizenetworks. Traffic models are defined at the end-user level. NetScale claims it canhandle more than 10 millions of concurrent flows to be simulated. Single flowof traffic can be monitored real time. NetScale is made in 3 layers. Simulation

Figure 1.23: 239 tri-sectorial sites of an HSDPA network are simulated

Engine (proprietary engine), XML input parser to run complex scenarios, GUI tovisualize the output of simulation.

HSPA related functionalities are not explained on the website and no datasheet could be found. Yet it can be seen that modulation/coding schemes areavailable, in addition to RLC configuration to find the optimums solutions.

1.5.3 Prismo SimulatorAccording to their website [18] Software Wireless creator of Prismo Simulator islocated in France and have work with Alcatel Mobile, Qualcomm, Arraycomm,

34 Introduction

Figure 1.24: HSDPA adapts its modulation and coding scheme to the radio channelstate

Kyocera Communications, Marconi Mobile, DDI Pocket, SFR/Vodafone.Prismo can be used to:

• Performance and Qos evaluation such as throughput

• dimensioning for example channel elements allocation in the sites

• Comparing different technologies for instance HSDPA and DCH from R99

Figure 1.25: Ec/N0 Prediction map

Prismo can be integrated with Atoll, it has native support for HSDPA and R99simulations. It supports different RAN vendors radio resource management algo-rithms such as Nokia, Siemens, Ericsson...

HSPA module supports:

• HSDPA Schedulers: Round Robin, max C/I, proportional fair.

• Fast simulation time allows for interactive use, with visual feedback of theprocess

1.5 A Brief Survey on Commercial HSPA Simulators 35

1.5.4 AtollAtoll [7] by Forsk is a complete solution to network planning and optimization.Atoll version 2.8 includes support for HSPA+ and MIMO. Atoll UMTS/HSPAmodule supports Monte Carlo UMTS/HSPA/MBMS simulator for DL and ULpower control, RRM, HSDPA/HSUPA to R99 downgrading and carrier allocationalgorithms. it supports plots for Eb/N0 prediction, service areas, handover ar-eas, BER/FER/BLER, Scrambling code allocation, manual and automatic multi-carrier neighbor planning.With Atoll UMTS/HSPA module site sharing (co-sites) and simultaneous displayand analysis of different network type can be done.

Figure 1.26: Sample of Ec/N0 visualization of a HSDPA network in Atoll

1.5.5 3G UMTS FDD with HSPAThis module is developed to be used in MATLAB [21]. it has a graphical userinterface (GUI) for specifying configurations with High Speed Downlink PacketAccess (HSDPA) support. CRC/Interleaving/fade channel simulator are mainfeatures supported by this module. Supported platforms are:

• The MathWorks Simulink

• Agilent SystemVue

This toolbox supports transport channels and physical channels according to re-lease 5 of the 3GPP specifications for uplink and downlink. In HSDPA transmis-sion toolbox it supports HARQ including two stage rate matching with redundancyversioning, 16QAMmodulation with constellation rearranging and multicode, high

36 Introduction

speed shared control channel, XML configuration for subframe by subframe pa-rameter control.In its other block there BER measurement block, clock generator for events, SlotField Multiplexer supporting S-CCPCH, DL-DPCH,UL-DPCCH and PRACH slotformats, and user defined.

Figure 1.27: Steepest Ascend 3G FDD Simulation Library

1.6 MotivationTo study on network properties for instance to measure link properties from ap-plication layer to physical layer, or to study on network capacity requires a fairlyaccurate simulation with lowest cost in terms of time. Static simulations are agood way to research on aspects of a network, but to have dynamic simulationover simulated time is an asset to study on KPIs and deliverance and further morefor the sake of optimization. Such simulation module is basically designed in dif-ferent layers of physical, MAC, and control layer to obtain detailed results. NS-3is chosen to be the simulation framework since it is pure C++ and it is a freshand live ongoing, well maintained project. Although It was not easy to just portEURANE into NS-3 because of C++/Otcl entanglement2, and in addition the bi-language limit it was not usable since the multiple NodeBs are not supported well,still some core ideas are taken from the EURANE multicell patch for the originalEURANE. To build the simulator module a model is required to be developedfirst. The model describing the the work simulated in the NS-3 we produced forthis thesis is presented in the next chapter.

2Refer to the NS-2 disadvantages, section 1.4.1

Chapter 2

Implementation

In this chapter details of each element in the model is discussed as it is implementedin the real code. To build the HSDPA simulation module, three node types sameas in the real UMTS network exist. Two different channel types are introduced anddeveloped. One for the radio interface which NodeB and all UEs on the networkare connected to and the other channel type is the IuB channel which is betweenRNC and all its associate NodeBs. Three different NetDevices are implementedto support UE, NodeB and RNC functions and two other netdevices to supportlayer 2 routing (NbSwitchFabric and RncSwitchFabric). There are also helpersdeveloped to ease building scenarios. In this chapter channel, Node (NetDevice,PHY, MAC, Routing, Flow Management) are explained. In Figure 2.1 an overviewof nodes and the related objects in NS-3 is shown.

RLC

MAC

MAC-d

PHY (L1)

UE

MAC-hs

PHY (L1)

NodeB

Transport (L1)

Frame

Protocol

RNC

Transport (L1)

Frame

Protocol

RLC

MAC

MAC-d

MAC-hs

IubUu

UmtsRLC

UmtsMacD

UmtsIubPhy

RncNetDevice

UmtsIubChannelUmtsUePhy

UmtsMacHs

UmtsRadioPhy

UmtsIubNetDevice

UmtsIubPhy

UmtsRLC

UmtsMacHs

UmtsRadioChannel

UmtsUeNetDeviceRbsNetDevice

UmtsMacD

NbSwitchFabric

L2

Sw

itch

RncSwitchFabric

L2 Switch

Figure 2.1: Overview of Nodes layers and related objects

In next sections each of the objects shown in the Figure 2.1 will be introduced.

37

38 Implementation

2.1 Nodes StructureEach node has a NetDevice inherited from UmtsNetDevice as in NS-3 definitionwhich a Mac layer connects it to the physical layer of node. All the nodes com-municate through the designated channels. In NS-3 it is possible to connect aNetDevice directly to the channel since the NetDevice already has send and re-ceive interfaces available to use, but as per requirement of the module, MAC andphysical (PHY) layers are developed. The overview of a simple node is shown inFigure 2.2

Node

PHY

MAC

NetDevice

Figure 2.2: A simple node in HSDPA module

Other functions such as mobility, routing, or the Internet stack (IPv4 only)should be aggregated onto the node. The Application layer is aggregated to thenode as well, with the help of helper functions aggregation of this functions arenot cumbersome. The complete schematic of the node is shown in Figure 2.3.

Node

PHY

MAC

NetDevice

Packet Routing

Application (UDP, TCP,...)

Mobility

Internet Stack

Figure 2.3: A complete View to Node in HSDPA module

2.1.1 NetDevicesNetDevices are like network interface controllers in real computers and repre-sent the Link layer in OSI model. Each NetDevice has its appropriate PHY.Such as UmtsUeNetDevice has a radio supporting PHY layer and PHY layer ofRncNetDevice is wired equivalent. In this thesis work, four type of NetDevicesare defined:

2.1 Nodes Structure 39

• UmtsUeNetDevice: To represent the user equipment

• UmtsIubNetDevice: To represent the NetDevice in NodeB connected to IuBchannel.

• RncNetDevice: To represent the RNC.

• RbsRadioNetDevice: To represent the NetDevice in NodeB connected toradio channel.

RncNetDevice

RncNetDevice is a point-to-point device which contains UmtsRLC and UmtsIubPhy.UmtsIubPhy is attached always to UmtsIubChannel. RncNetDevice has also theUmtsMac_d object which is the Mac-d layer.

UmtsIubNetDevice

This NetDevice is used in NodeB to connect to RNC node through its RncNetDevice.It is similar to the RncNetDevice excecpt it does not have UmtsRLC object.

RbsRadioNetDevice

RbsRadioNetDevice is designed to cover the radio access of the NodeB. It has aUmtsRadioPhy that is attached to a UmtsRadioChannel and also includes a Mac-hslayer. RbsRadioNetDevice has a database of all of its UmtsUeNetDevice’s. Thescheduling of traffic to all attached user equipment is done in this netdevice. Itis also possible to limit the maximum number of user equipment admission. Thedefault value is 20.

UeNetDevice

This object represents the user equipment (UE) in the network. It is inheritedfrom the UmtsNetDevice and includes a UmtsUePhy as its physical part.

NbSwitchFabric and RncSwitchFabric

Both of the NetDevices are bridge NetDevices and are inherited from BridgeNetDevicealready developed within NS-3. Both are responsible to switch packets to the cor-rect port similar to a real L2 switch. The bridge port is in fact a NetDevice (e.g. aRncNetDevice or a RbsRadioNetDevice). When packets goes through the switchfabrics they learn about links. If the switch fabric does not know about the nextport it broadcasts the packet to all the ports except the port the packet is receivedoriginally from. To have the correct traffic switching, an extra node which is theinternet gateway should be used, otherwise the traffic can not be switched if it isoriginated in the RNC.

40 Implementation

2.1.2 Physical LayerThe physical layer is implemented in the UmtsPhy class, which is an abstractionfor the other physical types as well. The basic functions within UmtsPhy arechannel and NetDevice assignment. The channel is discussed in section 2.2. Sincedifferent nodes have different physical properties, Two PHY layers are developed.

• UmtsIubPhy: A PHY layer to connect to Iub channel.

• UmtsRadioPhy: A PHY layer to connect NodeB to radio channel.

• UmtsUePhy: A PHY layer to connect user equipment to radio channel.

UmtsIubPhy

This PHY layer is used for the IuB interface between RNC and NodeB. It connectsUmtsIubNetDevice to UmtsIubChannel, No real PHY related is implemented inthis layer and it is implemented for the sake of future use1.

UmtsRadioPhy

The Radio PHY developed in the module supports a 3D antenna pattern. A 2Dmatrix is defined to support horizontal and vertical pattern shown below:

Antenna Pattern =[GH1 GH2 GH3 · · · GH360

GV1 GV2 GV3 · · · GV360

](dBm)

UmtsUePhy

It is inherited from UmtsRadioPhy so shares the same properties with it. butto keep the differences between a NodeB and a user equipment (e.g. a phone) aseparate object is added to the project. The function that is exclusive to UmtsUePhyis the capability to measure the SINR of each TTI and reporting it to its higherlayer (UmtsUeNetDevice).

both radio PHY’s have antenna pattern to calculate the transmission and re-ception gains. The antenna pattern (vertical and horizontal) is read from an MSIformatted file and is save in to an array, as a result a 3D, 360 by 360 pattern issave in the pattern array. The representation of vertical propagation pattern arrayis shown in Figure 2.4.

Currently only MSI antenna pattern file is supported by the physical helper.UmtsRadioPhy2 attributes possible to configure are shown in Table 2.1.

To calculate the correct gain of the antenna from its pattern, two angles aremeasured between transmitter and receiver. The angle φ that is the azimuth angle.and θ which is the tilt angle. As shown in Figure 2.5.

To calculate the azimuth and tilt in the Cartesian coordinate system that isused for the system following equation are used:

1To have functionalities such as CSMA or any kind of delay.2Obviously same for UmtsUePhy

2.1 Nodes Structure 41

0

90

180

270

0 359θ (degrees)

ga

in (

dB

i)

-45

0

Figure 2.4: A sample of polar antenna pattern and its linear representation

Table 2.1: UmtsRadioPhy/UmtsUePhyconfigurable attributes

Parameter UnitTx power dBMinimum RX Level dBAntenna Orientation DegreeAntenna Tilt DegreeAntenna Gain

Sender position vector =< x1, y1, z1 >

Receiver position vector =< x2, y2, z2 >

r =√

∆x2 + ∆y2 + ∆z2

θ = cos−1(

∆zr

)φ = tan−1

(∆y∆x

)When both φ and θ are found, the gain of the antenna pattern is calculated.

The noise level must be calculated in order to have a correct SNR value. TheUmtsRadioPhy have a time window in which it aggregates all the receive signalpower levels received from other NodeBs. So the SINR is measure only in the down-link. Through ns3::UmtsRadioPhy::SetAntOrientation() the azimuth can be

42 Implementation

Z

Y

X

ϴ UE (Pixel j)

NodeB

Antenna Pattern

Φ

Figure 2.5: An example of antenna pattern to find φ and θ

changed. SetAntTilt() function is defined to change only the mechanical tilt ofthe antenna. The electrical tilt is not supported in this module.

2.2 ChannelIn this module two different types of channel are implemented.

• Iub channel, that is connecting RNC to all its associated NodeBs.

• Radio channel, which is the media connecting all the radio interfaces in thenetwork.

Both of them are inherited from UmtsChannel.

2.2.1 Iub ChannelThe Iub channel, UmtsIubChannel, is connecting all the NodeBs to their respectiveRNC. This channel is designed as a point-to-point channel, i.e. one end of theUmtsIubChannel is always the RNC and the other end is one of the NodeBs. Itis implemented as a wired equivalent fullduplex lossless channel. There is not anydelay implemented in this channel. All packets are scheduled to be transmittedimmediately when they are sent to the channel from a UmtsIubPhy object.

2.2.2 Radio ChannelThe radio channel is named UmtsRadioChannel in the module. The physicallayer that must attach to this channel are UmtsRadioPhy and UmtsUePhy which

2.2 Channel 43

the latter is inherited from UmtsRadioPhy. The channel has a list of all theUmtsRadioPhy attached to it. Uplink and downlink channels are basically of thesame UmtsRadioChannel. When the channel receives a packet from the UmtsRadioPhyof a NetDevice, it sends the packet to UmtsRadioPhy objects of all other NetDe-vices that are already attached to the channel. The time that the packet scheduledto be sent is calculated within the propagation delay model. The receive signalpower per each receiver is calculated in the propagation loss model.In section 1.4.2 the loss and delay model are introduced. From those, Two-rayground reflection model is used as default for the loss model, and constant speedpropagation delay is the default delay model. It is possible to use other modelsin the simulation scenario, or even use more than one model at the same time. InTwo-ray ground reflection model, it is only possible to introduce same height forall of the nodes in the Two-ray model(not NetDevices). Since it is not possibleto pass the height of the each antenna separately to the current model, NodeBantenna height can be defined through mobility object that put the node on higherplace.

Uplink and Downlink Channels

In order to implement uplink and downlink channels, same UmtsRadioChannelobject is used. the uplink channel is attached to all user equipment physicals(UmtsUePhy) and all the NodeBs physicals are added to channel list, so it knowsto which object it should send the packets.By the same convention the downlink channel is defined. The downlink channelis attached to the physical objects of all NodeBs (UmtsRadioPhy) and all the userequipment physical objects are added to the channel send-to list. The idea andthe way it is implemented is shown in the Figure 2.6.

Uplink Channel

Downlink Channel

Sen

dR

eceiv

e

UE

Sen

dR

eceiv

e

NodeB

Figure 2.6: Uplink and downlink channel connection

2.2.3 MAC layer

Although there are several MAC layers in the release 6 and later for WCDMAand UMTS network, only Mac-d and Mac-hs are partly implemented in this thesiswork. Mac-d class is present in the module more as a place holder and it does nothave any real Mac-d functions.

44 Implementation

Mac-d

Mac-d is used to tag each of the PDU with a time stamp, PDU direction, and thePDU type. The tag is attached on the way to layer below and it is removed whenthe PDU comes from the same layer.

Mac-hs

Mac-hs in this project was implemented as a throughput mapping function basedon the SINR which includes the HARQ delay as well. In table 2.2 throughputempirical values (shown in Figure 2.7) are shown for each SINR. A linear interpo-lation function is used to find SINR-to-throughput values that are not found as inEquation 2.1.

Figure 2.7: HSDPA data rate as a function of SINR. HARQ and link adaptationeffect is taken into account[14]

y2 = (x2 − x1)(y3 − y1)(x3 − x1) + y1

(2.1)

The RBS node use the same function based on the SINR report received fromthe UE to shape the throughput of the data flow of a UE. Found throughput isused to calculate the number of PDUs (with size of 40KB) to be transmitted ineach TTI (2ms). The NodeB has a list of its active user equipment, and by activeit means a user equipment that has a traffic, and it goes through the list one byone. The amount of data to transfer is found by throughput which is found bylinear interpolation.

2.3 RLC layer protocol 45

Table 2.2: Throughput mapping values

SINR (dB) Throughput (Mbps)25 7.823 7.121 5.7518 4.316 313 2.1511 1.637 0.652 0.0320 0.012

2.3 RLC layer protocolRadio Link Control protocol is between the PDCP and MAC layer. The RLCmode supported in this thesis work is the "Unacknowledged Mode" (UM). RLCUM supports for

• When sending:

– Segmentation of SDU into PDU of 40KB– Adding the RLC UM header to each PDU– sending the PDU down to MAC layer

• When receiving:

– Removing the PDU header– Concatenation of PDUs to build the SDU– sending the SDU to upper layer

The RLC UM header mode complies with the format found in [3]. When RLCreceives a SDU it checks if the SDU needs to be segmented. If it should besegmented then starts to segment the SDU into PDU of 40KB each including theheader size which can vary between 2 to 4 bytes based on the information necessaryto be included in the header. For example if the current PDU is the first one orthe last one, or if the PDU contains the whole SDU or not. There are buffersfor both SDUs and PDUs to be stored in both directions, that are simple FIFOqueues

2.4 Internet StackTo support IP layer in a node, there is an Internet stack already exists in the NS-3which should should be aggregated to the node by the help of InternetStackHelper.

46 Implementation

The Internet stack supports IPv4, IPv6, TCP, UDP, ARP, and other protocols.The HSPDA module in this thesis work is based on IPv4. It is possible to haveany IPv4 address assigned to the interfaces. Ipv4AddressHelper is used to definethe IP base (e.g. "10.1.0.0") and then assign IP to the interfaces later.

2.5 Scheduling and code assignmentThe scheduler resides in this NetDevice. A round robin scheduling function isdeveloped to go through the serving queue every TTI (2ms) based on the availablecodes and the queue size. The number of codes assigned to each user equipmentin every TTI is also done in a round robin fashion. Hence if there are more than15 user equipment in the queue, user equipment after 15th will be served in thenext TTI.

2.6 Routing and SwitchingNS-3 already support layer 3 routing, i.e. ip routing which is not a good choiceto work with in this kinda of network, due to extra IP header for required foreach packet. As a result a layer 2 switching mechanism is added to NodeBand RNC that are called NbSwitchFabric and RncSwitchFabric respectively.NbSwitchFabric is added to every NodeB in order to support switching packetsbetween RbsRadioNetDevice and UmtsIubNetDevice. The RNC node it wouldhave a number of NodeBs attached to it. To support the switching traffic to therespective NodeB or user equipment RncSwitchFabric must be added to RNCnode.

2.6.1 Switching and Routing ProcessAs soon as a NodeB is defined and started, it begins to broadcast a message onits IuB channel to find its RNC. It sends a "Hello" and when the RNC receivesthe message sends back a "HELLO_REP" so both nodes switch fabric get up-dated. When NodeB is started it broadcasts a CPICH message similar to CPICHin UMTS network. The user equipment has to send a RACH message to NodeB.The user equipment has a period of time to scan for the best CPICH prior tosending out RACH. If the RACH is not responded it will send a new RACH to thenext best CPICH in the list. This also corresponds to the method explained in thenext chapter as a part of algorithm. By the time the RACH is received in NodeB,if NodeB has the capacity to admit according to method explained in chapter 4it will sends a AGCH back to user equipment, at the same time it forwards themessage to RNC to update its switch fabric. The process is shown in Figure 2.8.

All the control packets are defined by the UmtsCchTag which is a packet tag.So to the control packet can have a zero size, since the tag is not accounted in thepacket size.

2.7 Helper Functions 47

UE NodeB RNC

4: RACH

5: AGCH

1: HELLO

2: HELLO_REP

3: CPICH

6: RACH_FWD

Figure 2.8: Route request and Route reply procedure

Active Set and User Equipment Database

In order to implement a correct routing process, every user equipment has anactive set that saves the found NodeB address and last received broadcast RXlevel. An example of the active set can be seen in table 2.3.

Table 2.3: Active set example (Sorted ascending)

NodeB MAC Address RX level00:00:00:00:00:c3 -75.988600:00:00:00:00:c3 -75.988600:00:00:00:00:bd -75.238200:00:00:00:00:bf -72.859300:00:00:00:00:bc -71.544700:00:00:00:00:c0 -65.26200:00:00:00:00:c1 -61.5778

In NodeB, a vector (m_admittedUes) is defined to keep track of all the activeuser equipment. Both databases support Print(&ostream os) function to printout either user equipment active set or NodeB’s active user equipment.

2.7 Helper FunctionsHelper functions are developed to speed up and ease the process of building anetwork in NS-3. A helper function basically includes loops to perform repetitiveactions. In this thesis work helper functions developed are:

• UmtsRadioChannelHelper: To build a channel objects

48 Implementation

• UmtsRadioPhyHelper: To build a PHY objects

• UmtsRadioHelper: A wrapper containing another helper

• UeRbsRadioHelper: A helper to build star topology with one RBS and aUE cluster

• RncToRbsHelper: To build a node container of an RNC and an RBS

• RncToRbsStartHelper: To build a star topology with one RNC and a NodeBcluster

• SwitchFabricHelper: To add switch fabric NetDevice to RNC or NodeB

All the helpers that create a NetDevice or more, they have the same basicapproach: a) A PHY is created; then b) the device is introduced to PHY; afterthat c) PHY is added to device; then d) a MAC address is assigned to the device.

2.7.1 Radio Channel HelperThe radio channel helper or UmtsRadioChannelHelper, has functions to set uppropagation loss and delays as well as their parameters. It is mandatory to definethe propagation models prior to creating a channel object.UmtsRadioChannelHelper.Create() lets the user to create a channel object andassigning the propagation models already specified. It is possible to use all thepropagation models already existing in NS-3. Several propagation loss models canbe stacked in the channel to calculate each model effect one by one.

2.7.2 Radio PHY HelperBy UmtsRadioPhyHelper the error model is defined and the antenna pattern is readfrom file by its file path. The UmtsRadioPhyHelper.Create() function creates aPHY object, based on given PHY type and error model defined.

2.7.3 UMTS Radio HelperThe UMTS radio helper is a wrapper for the UeRbsRadioHelper class and thefunctions to:• Assign IP address to radio NetDevices (either an UE or a NodeB),

• Give access to UE cluster NetDevices and nodes

• Give access to NodeB NetDevice of UE cluster

• Attach a specified cluster to a specified channel

• Install internet stack on all cluster nodesThat means it in fact utilized the functions provided by UeRbsRadioHelper

and lift the functionalities a level higher. Each UE cluster consists a number of UENodes, their NetDevice and a RBS NetDevice. With the help of AttachUeClusterToRbsfunction, the RBS NetDevice can be attached to an existing RBS node.

2.7 Helper Functions 49

2.7.4 RNC to RBS HelperRncToRbsHelper creates a RncNetDevice and its UmtsIubPhy, a UmtsIubNetDeviceand its UmtsIubPhy. Both PHYs are attached already to a UmtsIubChannel. TheUmtsIubNetDevice is created to be used in a NodeB later in RncToRbsStartHelper.A MAC address is assigned to each NetDevice as well.

2.7.5 RNC To RBS Star HelperTo build a star topology of one RNC node and its NodeBs, RncToRbsStartHelperclass is used. The input to the class is the number of RBSs and it adds up anothernode as RNC then utilizes the RncToRbsHelper to build pair of RncNetDevice-UmtsIubNetDevice. It has functions to:

• Add internet stack to nodes

• Assign IP addresses to nodes

• Get access to each RBSs node in addition to its NetDevices and IP address

• Get access to RNC node in addition to its NetDevices and IP address

• Get the number of RBSs in the star topology

• Build a serving gate way to the internet through an extra node which isalready paired with the RNC node.

2.7.6 Switch Fabric HelperSwitchFabricHelper is defined to add switch fabrics are added NodeBs and RNCafter the star topology is built. the final The topology looks like Figure 2.9 beforeadding the RbsRadioNetDevice to NodeBs.

In the next chapter results of the baseline scenario and more is presented.

50 Implementation

UmtsIubPhy

UmtsIubPhy

UmtsMac_d

UmtsRLC

RncNetDevice

Um

tsIu

bP

hy

Um

tsM

ac_

d

Um

tsR

LC

Rn

cN

etD

evic

eUm

tsIu

bP

hy

Um

tsM

ac_

d

Um

tsR

LC

Rn

cN

etD

evic

e

UmtsIubNetDevice

Um

tsIu

bC

ha

nn

el

UmtsIubPhy

UmtsIubNetDevice

Um

tsIubChannelUmtsIubPhy

UmtsIubNetDevice

Um

tsIu

bCha

nnel RNC NodeRncSwitchFabric

Figure 2.9: A sample of RNC to NodeB Topology

Chapter 3

Simulator Validation Results

In this chapter more we provide results to verify the correct operation of thesimulation tool we have so for developed. First a proof of concept is shown, then ascenario is provided to measure the maximum number of user equipment in a singlecell regardless of any interference, and in the third scenario a multicell network isexamined to show the capability of the simulation tool. In all of the scenarios UDPconstant bit rate (CBR) traffic is sent to each of the user equipment. UDP CBRtraffic is selected to examine the capabilities regardless of the TCP flow control.All the measurements are done by FlowMonitor module in NS-3. A FlowMonitoragent is installed on each node, as a limitation it can monitor the packets in layer3 only. For all scenarios traffic is started from an internet gateway and sent to allof the user equipment in all scenarios.

3.1 Baseline operation resultsThis section produces evidence that the module we built performs well with respectto the expected results. It serves as a proof of concept for our first but mosttime and effort consuming part at this thesis. A a 65◦ directional antenna with18dBi gain at 2100Mhz, is used to demonstrate the antenna property affect onthe throughput. The antenna pattern is shown in Figure 3.1 for zero degree ofmechanical and electrical tilt. The RBS is located at (1000m, 1000m) on the gridand the user equipment is on (1500m, 1000m). Two scenarios are designed:

• In the first one the user equipment is going away from the RBS by the speedof 3m/s on the x axis.

• In the second scenario the user equipment circles around the RBS and thethroughput is measured. The angular speed of the user equipment is 0.1◦/sor about 0.87m/s with the radius of 500m.

The physical setup of antenna used in the both of scenarios are shown in table3.1. The propagation loss models used are Two-ray ground reflection model andNakagami model.

51

52 Simulator Validation Results

Table 3.1: RBS antenna properties for the baseline scenario

Direction (deg) Tilt (deg) TX power (dBm) Gain (dBi) Hight (m)0 0 35 18 240 3 35 18 240 5 35 18 240 8 35 18 24

Figure 3.1: Antenna pattern for baseline test

The results of the first scenario is shown in Figure 3.2. It can be seen thatthe throughput is increased when tilts is increased (or antenna looks down). Thegraph of 0◦ shows that throughput falls down, that can be explained by the verticalantenna pattern (it can be one of side lobs).

In Figure 3.3 the throughput of the user equipment is shown for mechanicaltilts from 0◦ to 8◦. Since the user equipment is fairly close to the cell center (takingthe quite large TX power), the throughput is affected by the tilt values. Largertilt value results in larger throughput value. The shape of the throughput graphconfirms that the antenna pattern calculation is working well, despite its simpleapproach.

The second set of results are about to find the limit of a single cell. Thisscenario is not a realistic simulation A high value of 8Mbps , 1Mbps as a midrange value, and 500Mbps as a low value are selected for throughput on the linksfrom an internet gateway to all of the user equipment. Although there is parameter

3.1 Baseline operation results 53

0

1

2

3

4

5

6

7

8

1000 1500 2000 2500 3000

Thr

ough

put (

Mbp

s)

Distance (m)

Tilt 0 degreesTitlt 3 degreesTilt 5 degreesTilt 8 degrees

Figure 3.2: User equipment moving away from RBS with the speed of 1m/s, 4runs with 4 antenna tilts

0.2

0.4

0.6

0.8

1

30

210

60

240

90

270

120

300

150

330

Tilt 8 degrees

Tilt 5 degrees

Tilt 3 degrees

Tilt 0 degrees

Figure 3.3: User equipment goes around the RBS with speed of 0.87m/s, 4 runswith 4 antenna tilts

to limit the number of admissions in a cell (default value is 20), the limit is disabledfor the sake of this test scenario. In Figure 3.4 a sample setup network for threeuser equipment is shown. All of the measured value are average values in the


system level. There are three major parameters shown with figures: average ofmean jitter, average of loss packet percentage, and average throughput. It shouldbe mentioned that the per user equipment buffer size in the RBS is not infinite(default value is 500,000 packets and it can be modified).

From Figure 3.5d in which a high value of throughput is chosen, it can be seenthe when number of user equipment increases the throughput decreases fast. Sincetraffic being pushed to all links is concurrent and constantly on, to maintain thethroughput in such high value can not be feasible due to the limit introduced bytime and code sharing. The packet loss percentage goes high faster than what itis in Figure 3.6c which has lower throughput on all of the links. So the higherthroughput values, the longer serving queues would occur, and the packet losswould increase as it is anticipated.

In Figure 3.6c the throughput pushed to all links is 1Mbps, so less packetloss is observed comparing to the scenario with 8Mbps of throughput for all link.The possibility to maintain the high throughput value can be anticipated whichthe figure confirms it. The values in Figure 3.7 shows that with low value ofthroughput on all of the links the possibility of queue overrun is almost zero sothe throughput is well maintained and the packet loss is almost zero.

Mean jitter value follows the same trend, when the per flow queue start togrow with more number of user equipment, the serving time increases which leadsto more jitter. Since the every flow queue drops packets after the limit is reachedso the delay can not be measured accurately for high data rates when the numberof user equipment is higher than the maximum available codes.

In the next chapter a system model is developed to produce an approach inorder to remove base stations to reduce the cost of the network.

Figure 3.4: Setup of network for the admission limit tests

Number of user equipment increases by one on every run. The mobility modelis constant position, i.e. it is similar to a snapshot type of simulation for a minutesimulation time length.

3.2 Multicell scenario and results 55

3.2 Multicell scenario and resultsIn this section five NodeBs are located on an area with size of (20000m, 20000m).The location of NodeBs can be found in table 3.2. All of the user equipment arerandomly spread in the are and will attach to the cell automatically by means ofactive set and reading the broadcast channel as it is discussed in section 2.6.1. Inthe first run 40 user equipment are generated, in the second run 60 user equipment, and the third run, 100 user equipment are generated. It can not be guaranteedthat all the cells have the same number of user equipment due to random anduneven distribution of user equipment in the area.

Table 3.2: NodeB location coordinates

X (m) Y (m)3000 30003000 1700010000 1000017000 300017000 17000

In these scenarios traffic is not pushed to all the user equipment at the sametime for the whole simulation time. To have more realistic condition traffic isgenerated by an Pareto UDP application to simulate web traffic [4]. The start timeand stop time of the traffic source applications are also set by Pareto variables.The shape value of the Pareto distribution used to generate value is 1.5 that iscommon for web applications. The same traffic scenario is used in all of the threetests. The target throughput is 8Mbps (that is a high value) for all the three runs.

In Figure 3.8a the throughput value of each second is shown. It can be seenwhen more links are activated and traffic is started for each, the interference startsto show its effect on the average throughput of all active flows. The throughputis almost maintained for most of links when there are less than about 16 linksactivated that is anticipated from previous scenarios and measurements. In allof the three runs, some links are not activated, in other word, did not receivedany traffic. Due to nature of the traffic, there are links active for periods of timeoverlapping others, hence there are nodes suffering from poor SINR, or better saythey are in shadowed areas (dark spots) [20].

To have a more intense test, the multicell scenario with low data rate is repeatedwith 6 times more NodeBs. All NodeBs are located in the area with the distanceof 1000m from other NodeBs (horizontally, vertically, and diagonally). Since theoutput power of the NodeBs is much smaller, 20dBm comparing to 43dBm inprevious scenarios, the area size of the network is smaller, (6000m, 6000m). Thelocation of all nodes in the area is shown in Figure 3.11 There are 250 user equip-ment randomly positioned in the area and the simulation runs for one simulationminute.


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

50000

100000

150000

200000

250000

300000

Num

ber

of

packets

Rx Packets Tx Packets

(a) Number of packets transmitted and received

1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

0.0005

0.001

0.0015

0.002

0.0025

0.003

Mean o

f Jitt

er

(Second)

(b) Mean jitter

1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

20

40

60

80

100

Lost

packet

perc

enta

ge

(c) Lost packet percentage

1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

1

2

3

4

5

6

7

Avera

ge t

hro

ughput

(Mbps)

(d) Average throughput

Figure 3.5: 8 Mbps UDP CBR traffic sent concurrently to all the active userequipment for 1 minute


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

5000

10000

15000

20000

25000

30000

35000

Num

ber

of

packets

Tx Packets Rx Packets


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

0.0005

0.001

0.0015

0.002

0.0025

0.003

0.0035

Mean o

f jitt

er

(Second)

(b) Mean jitter

1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

10

20

30

40

50

60

70

Lost

packet

perc

enta

ge


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

0.2

0.4

0.6

0.8

1

Avera

ge t

hro

ughput

(Mbps)


Figure 3.6: 1 Mbps UDP CBR traffic sent concurrently to all the active userequipment for 1 minute


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

11000

12000

13000

14000

15000

16000

Num

ber

of

packets

Tx Packets Rx Packets

500Kbps CBR traffic downloading concurrently to all UEs for 1 minute


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

0.001

0.002

0.003

0.004

0.005

Mean o

f jitt

er

(Second)

(b) Mean jitter

1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

5

10

15

20

25

30

Lost

packet

perc

enti

le


1 2 3 4 5 6 7 8 9 10 15 20 30

Number of Nodes

0

0.1

0.2

0.3

0.4

0.5

Avera

ge t

hro

ughput

(Mbps)


Figure 3.7: 500 kbps UDP CBR traffic sent concurrently to all the active userequipment for 1 minute


3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

2000

4000

6000

8000

10000

Thro

ughput

(Kbps)

(a) Average throughput of flows

3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

10

20

30

40

Num

ber

of

flow

s

(b) Number of flows in time

0 5000 10000 15000 20000

Distance (m)

0

5000

10000

15000

20000

Dis

tance (

m)

UE NodeB

(c) Location of nodes

Figure 3.8: 8 Mbps UDP Pareto traffic sent the active user equipment for 1 simu-lated minute, 40 user equipment are generated


3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

1000

2000

3000

4000

5000

6000

7000

8000

Thro

ughput

(Kbps)


3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

10

20

30

40

50

60

Num

ber

of

flow

s


0 5000 10000 15000 20000

Distance (m)

0

5000

10000

15000

20000

Dis

tance (

m)

UE NodeB


Figure 3.9: 8 Mbps UDP Pareto traffic sent the active user equipment for 1 simu-lated minute, 60 user equipment are generated


3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

2000

4000

6000

8000

10000

Thro

ughput

(Kbps)


3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

20

40

60

80

100

Num

ber

of

flow

s


0 5000 10000 15000 20000

Distance (m)

0

5000

10000

15000

20000

Dis

tance (

m)

UE NodeB


Figure 3.10: 8 Mbps UDP Pareto traffic sent the active user equipment for 1simulated minute, 100 user equipment are generated


0 1000 2000 3000 4000 5000 60000

1000

2000

3000

4000

5000

6000

UE NodeB

Figure 3.11: Position of nodes in the large scale scenatio

3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

50

100

150

200

Num

ber

of

flow

s

Figure 3.12: Number of flows in time for 250 user equipment and 30 NodeBs

3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

100

200

300

400

500

600

Thro

ughput

(Kbps)

Figure 3.13: Average throughput of 500Kbps UDP Pareto traffic sent the activeuser equipment for 1 simulated minute, 250 user equipment are generated

Chapter 4

Modelling for A Simple BaseStation Removal Algorithm

A wireless network can be studied based on its different properties. Such as totalsystem capacity, total coverage area, or per user average experienced signal-to-noise ratio. In this thesis, HSPA network is the object of study, hence the ma-jor properties to focus on are: 1) maximum system throughput; 2) user averagethroughput. Throughput is an indirect function of SINR that is a common matterof studies in all WCDMA network related problems. In order to get the maxi-mum system throughput as well as every single user average throughput, a modelis required to study on. The model to develop in this thesis, is focused on theexperienced SINR at each user equipment and its throughput as a result of SINR.In the rest of this chapter the model is introduced and explained.

In an HSPA network as in a conventional mobile network, there are user equip-ment spread on the coverage area of the network. By coverage it means that theuser equipment has the possibility to reach to a certain throughput above a min-imum limit. The NodeBs in the network provide the coverage and are connectedto one or more RNCs. All these entities are going to be called nodes. Exceptthe RNC node, all the nodes physical locations are necessary to be known in themodel to calculate the propagation loss and delay values. This is a typically com-mon assumption in the literature, justified by GPS or other means of locationpositioning. The RNC location is not considered neither in the model nor in theimplementation later on. The model developed for this master thesis is consist ofUMTS network nodes and the area of the coverage area of the network.

The coverage area is a flat rectangular area with limited length and widththat is called the grid as in [20, 9] and there is not any kind of obstacle on it.The grid is divided into smaller squares, called pixels. The set of all pixels isdenoted by J . The pixels on grid have the same area and are assumed to be smallenough in size so that almost there can be only one UE or a NodeB in each at atime. The pixel(s) covered by a NodeB make(s) a cell which is in the set of cells

63

64 Modelling for A Simple Base Station Removal Algorithm

denoted by C, are located on the grid. In this model all the NodeBs on the gridare connected to a single RNC. The connection between NodeBs and RNC is alossless wired equivalent and without any delay link. Later in the implementationchapter we can see that there are objects foreseen in case of adding more detailsto the NodeB-RNC link model.

J = {1, ..., j, ..., J} Set of pixels (4.1)C = {1, ..., i, ...,C} Set of cells (4.2)

Figure 4.1: Network grid and pixels

Each cell i ∈ C can admit a number of pixels up to a limit denoted by JTi . A

binary function is defined to indicate if a cell is congested or still admitting newcell as below:

yi ={

1 If JTi > 0

0 If JTi = 0

(4.3)

A pixel is assumed to be covered (same as the user equipment), when its SINR canreached to a minimum acceptable throughput. Every pixel in the grid can reachto a certain throughput according to its type (see Table 1.1). As it is discussedearlier in the introduction chapter, the interference plays a major role in a UMTSnetwork. To calculate the interference, the accumulated signal power received fromall all cells on the grid, except the serving cell, is accounted for the interferencelevel. If pixel j is served by cell i, the received power from all the other cells ∈ Cis accounted for the interference as in Equation 4.4.

Iij :

∑t∈C,t6=i

P trj (4.4)

65

where,Ii

j : Interference detected in pixel j served by cell tP t

rj : Received signal power in pixel j from cell tgij : Path gain

(4.5)

The received signal strength at pixel j from cell i can be written as:

P irj = gijP

jti (4.6)

where,P j

ti : Transmitted signal power from cell i to pixel j(4.7)

In order to find the gain of a link between every two radio nodes (gij) thephysical properties of the nodes should be known. The major properties of thephysical part of a radio device in this model are: gain, direction, and the antennapattern. In this model the antenna type is basically defined by the antenna pat-tern1. The path gain in this model is chosen to be either based on Friis model ortwo-ray ground reflection model as shown in equation 4.8

gij = GtGrλ2

(4πd)2LFriis Propagation (4.8)

gij = GtGrH2t H

2r

d4LTwo-ray ground Propagation (4.9)

Gt : Transmitter gainGr : Receiver gainλ2 : Carrier wavelengthd : Distance between two nodes

Ht : Transmitter antenna heightHr : Receiver antenna heightL : Path loss

Each pixel or NodeB has a 3D position vector in Cartesian coordination systemas : < x, y, z > that z corresponds to the height of the entities. By addingInterference to noise level in SINR is used instead of SNR. Using Equation 4.4,the SINR calculated at pixel j served by cell i, denoted by SINRi

j is:1To know about the antenna pattern refer to the implementation chapter


SINRij = gijP

jti

Iij +N0

(4.10)

The SINR in every pixel is mapped to a throughput value by function Φ(SINR).The Φ function can be obtained empirically such as the one presented in Figure2.7and is a discreet function. To find the correct throughput by Φ(SINR) the spread-ing factor of 16 must be taken into account in equation 4.11 so it reads

SINRij = SF16

gijPjti

Iij +N0

(4.11)

The throughput of pixel is denoted by αj and is calculated as αj = Φ(SINRj).Binary function, xj is introduced to indicate if a pixel is active or not. A pixel isactive when it is using the bandwidth. So in later formulation only active pixelsare counted in the calculation of throughput per cell.

xj ={

1 If SINRJ ≥ θ0 If SINRJ < θ

(4.12)

There is a maximum offered throughput for every cell. This value must belarge enough to support the sum of minimum acceptable throughput of all thepixels in the coverage area of the cell. The maximum offered cell throughput isdenoted by αT

i as shown in Equation 4.13. As the notation conveys for every celli the αT

i can be different from other cells ∈ C

αTi >>

∑j∈Ji

xj × Φ(θ) (4.13)

Each pixel can sense all the cells on the grid, regardless of any physical layerconstraints as in the implementation. So it has a SINR value for each of the cells.The best SINR value sensed in the pixel, implies which cell is preferred to attachto. In UMTS network the notion of active set plays a similar role and specificallyas the active set in user equipment is a sorted list of all the NodeBs the userequipment can "hear". The ordering of the active set is according to the receivedsignal strength, which is practically what is modeled here, that is a good emulationof what really happens in a real UMTS network active set. When the preferredcell is found in each pixel, every active cell starts to admit pixels based on theircell preferences. A cell can admit the pixels up to its limit of JT

i . The total sumof throughput demand from all the pixels in a cell coverage area is:

αi =∑j∈Ji

xj × αj (4.14)

If αi ≤ αTi , all the pixels in the coverage area of cell can reach to their expected

throughput. The other case is that αi > αTi , means some of the pixels in the

67

coverage area would not reach to the throughput the SINRij conditions enable

them to get. To allocate resouces for this case, a fair distribution of the availablecell throughput is proposed. The available throughput in a cell after serving allpixel with the minimum acceptable of throughput is:

αavaili = αT

i − Φ(θ)×∑j∈Ji

xj (4.15)

The "‘excess demand"’ throughput of a pixel above the minimum acceptablevalue is:

αexcessj = Φ(SINRi

j)− Φ(θ) (4.16)

The total sum of excess throughput demand in a cell that is over αTi is:

αexcessi =

∑j∈Ji

Φ(SINRij)− Φ(θ)×

∑j∈Ji

xj (4.17)

To find the real throughput of each pixel according to the available excess cellcapacity and what the pixel is demanding, equation below is formulated:

α′j = min < αavaili

αexcessj

αexcessi

,Φ(SINRiJ) > (4.18)

In Equation 4.18 the minimum operator ensures that the pixel either attainsto the highest throughput available in the cell, or gets to the exact value it isdemanding for (Φ(SINRJ)).

All the notations can be summarized as in below:

C: Set of cells in gridJ : Set of pixels in gridJi: Coverage area of cell i ∈ CJT

i : Maximum number of pixels in the coverage area of cell i ∈ CΦ(SINR): A discrete function to map SINR to throughput

αTi : Maximum throughput offered by a cell

αminj : Minimum acceptable throughput for a pixel ∈ Ji

αminj = Φ(θ)

When the real throughput of each pixel is known, it is possible to find themost costly cell. To find the cost the ratio of total throughput being served to thenumber of admitted pixel in the serve is calculated as in equation 4.19. The cellwith the largest ration is the one to remove first from the network [12].

H(i) =

∑j∈Ji

α′j

|Ji|(4.19)


4.1 Scheduling and Channelization Code assign-ment

The method to share the throughput between pixels explained in previous sectionis similar to the Max C/I scheduler. It is clear that not all the pixels in the cov-erage area of a cell would have same SINR and throughput, so It is possible toshare the bandwidth between pixels according to their SINR. The drawback inthis method is low priority of those pixels with low SINR. Since pixels demand forbandwidth is in a greedy fashion in the method explained before, those pixels withlow SINR values are consequently low prioritized by the cell scheduler regardlessof other parameters such as traffic class defined within QoS.

As it is mentioned in section 2.5, round robin with throughput found by 4.18is chosen to be the implemented scheduler in the NodeB in this thesis. In roundrobin, all pixels (or users), shares the bandwidth equally regardless of their channelcondition. This simple approach to share the cell capacity would result in band-width loss because of time consumed for pixels with low SINR. The pixels withlow SINR will use the same number of time slot as other pixels but can not utilizemost of the bandwidth granted to them. An example of round robin scheduling isshown in Figure 4.2.

TTI = 2ms

Pixel 1 Pixel 2 Pixel 3 Pixel 4 Pixel 1 Pixel 2 Pixel 3 Pixel 4

Figure 4.2: An example of round robin scheduling method

It’s already known that, there are 15 channelization code assigned in a roundrobin fashion. To incorporate the channelization code effect on the throughputfunction Φ(SINRi

J) will become as

Φ(SINRiJ)× 15

Number Active Users (4.20)

4.2 Case Study 69

and the equation 4.18 becomes as below

α′j = min < αavaili

αexcessj

αexcessi

,Φ(SINRiJ)× (Number of available code) > (4.21)

the throughput value found by equation would be the throughput of each user ateach transmission interval (TTI).

4.2 Case Study: Using the simulator to evaluatethe simple base station removal algorithm

An appealing approach to saving energy in cellular networks is to completely turnoff selected base stations when the traffic load becomes light, e.g., see [16, 23].Switching off base stations leads to considerable energy savings, since traffic inpeak hours can be as much as 10 times higher than the traffic in off-peak periodsin the same area [11]. To maintain a smooth network operation guaranteeing usersatisfaction, base stations that are turned off should know when to automaticallyswitch based on local intelligent decisions, external triggers, or a reconfigurationschedule. The benefits of such a Self-organizing-network expand beyond designinggreen networks. In fact, they can be used for efficient operation and maintenanceand for reducing CAPEX (capital expenditures) and OPEX (operational expen-ditures) [8] by eliminating many on-site operations and reducing the workloadfor site survey and analysis of network performances, respectively. The currentstate-of-the-art approaches for intelligently switching base stations on and off arereactive, i.e., the network plan and BS sites are fixed and then while on operationmeasures are implemented to decide which sites to switch on/off and which sitesto reconfigure as network conditions change.

In the following we present results of the model developed in last chapter. Thescenario started with has 8 base stations and there are 150 user equipment on thearea of (2500m, 3000m). The base stations are located 1000m away from theirneighbor base stations. The configuration of base stations is in table 4.1. Theantenna type is omni-directional so the TX power chosen to be small to have leastpossible interference. The position of all nodes for the scnario can be seen inFigure 4.3

Table 4.1: Base station configuration for the removal algorithm scenario

Direction (deg) Tilt (deg) TX power (dBm) Gain (dBi) Hight (m)0 0 10 10 24

The scenario is run for 1 minute with the minimum acceptable coverage of 80%.A Pareto traffic of 500Kbps is sent to all user equipment with random start-stoptimings. After three round there was possible to remove totally three base stationsfrom the network. The throughput before and after are shown in Figure 4.4. Withthe same scenario and setup, we reduced the minimum acceptable coverage limit


0 500 1000 1500 2000 2500 3000

Distance (m)

0

500

1000

1500

2000

2500

Dis

tance (

m)

UE NodeB

Figure 4.3: Position of nodes

from 90% to 50%, to see how the number of possible removal increases. In Figure4.5 the result can be seen.

3 6 9 12 15 18 21 24 27 30 33 36 39 42 45 48 51 54 57

Time (s)

0

100

200

300

400

500

Thro

ughput

(Kbps)

Before After

Figure 4.4: Average throughput of 150 user before base station removal and after

4.2 Case Study 71

90 85 80 70 60 50

Target coverage percentage

0

1

2

3

4

5

6

Num

ber

of

rem

oved B

ase S

tati

ons

Figure 4.5: Number of Base Stations removed for minimum acceptable coveragepercentage

Chapter 5

Conclusion

In this thesis a simulation tool for HSPA network was developed in NS-3, an opensource network simulation. The tool comprises access and core entities requiredto emulate the network. Two communication channels are developed to representIuB and radio channels. These communication channels have their own physicallayer. The radio PHY layer includes antenna pattern information. Parameterssuch as transmit power, recevied signal sensitivity, direction, gain, and tilt can beconfigured in the scenarios. Six NetDevices were implemented to facilitate userequipment, NodeB, and RNC nodes in addition to Layer-Two switches in RNCand NodeB. The latter are used to let the network form dynamically, rather thanhaving a predefined topology. A user equipment admission procedure is introducedto the simulator that emulates the real UMTS UE admission process. The NodeBcan also limit the number of admitted user equipment. An empirical function isused to find the throughput of each user equipment based on its experienced SINR.The measured SINR is reported to NodeB each TTI. A round robin scheduler isassumed in the NodeB. There are 15 codes to assign to user equipment, whichis also done in a round robin fashion. The throughput pushed to every userequipment in each TTI is calculated using the throughput function and numberof available codes.

Proof of concept scenarios are designed to show the basic capabilities of thetool. In order to find the maximum capacity of a cell different single scenarioswere designed. To present the capability of the tool to simulate multicell scenarios,several multicell scenarios are presented and the results show that the simulatorgives good results.

A simple base station removal algorithm was also developed and our tool de-signed, was used to test it. It is designed taking the CAPEX criteria into account.Base stations are removed greedily with respect to their cost, maintaining theminimum acceptable coverage. The throughput experienced at each point of thenetwork area will contribute to the cost of the the cell being served by. The cost isdefined as the ratio of total sum of throughput pushed from a cell to the number ofuser equipment being served by the cell. Different scenarios were designed to eval-uate the removal algorithm using our tool. Results of the algorithm using dynamic

73

74 Conclusion

simulation show that the tool is reliable to incorporate models and algorithm intosimulator tool, and the designed algorithm performs well.

Chapter 6

Future work

In order to bring our simulator tool to a higher level, there are some realizationsthat can be added to the code. For instance, the HSUPA, or the uplink part of theHSPA is not developed due to the load of work, thesis scope, and the contributionof the base station removal algorithm. Since the tool can simulate a multicell sce-nario, adding the hand-over capability is also very useful. Towards more realism,assumptions and simplifications can be converted to real functionalities, such asMac-Hs, HARQ and other scheduling types. It is strongly advised to look intothe EURANE code to realize the latter cases. With the hand-over, in HSUPAthe mechanism to redirect the user equipment data route to another NodeB canbe added through same cell selection procedure explained in the implementationchapter.

Since NS-3 suppports python programming, it is possible to generate pythonbindings of the module. Then it is also possible to generate necessary codes tohave animation using the PyViz module in NS-3. PyViz can show the real-timethroughput on each link, in both direction.

75

Bibliography

[1] 3rd Generation Partnership Project. 3GPP TS 25.301, Radio Interface Pro-tocol Architecture , V9.2.0, 6 2010.

[2] 3rd Generation Partnership Project. 3GPP TS 25.308, High Speed DownlinkPacket Access (HSDPA); Overall description; Stage 2, V10.1.0, 6 2010.

[3] 3rd Generation Partnership Project. 3GPP TS 25.322, Radio Link Controller(RLC) protocol specification, V9.0.0, 2 2010.

[4] Robert Adler, Raya Feldman, and Murad Taqqu (Eds.). A Practical Guideto Heavy Tails. Springer, 1998. ISBN ISBN 978-0-8176-3951-8.

[5] Alcatel-Lucent and Alcatel-Lucent Shanghai Bell. Type II Relay Operationin LTE-A, R2-093817. Technical report, 3rd Generation Partnership Project,2009 ,June 29th - July 3rd.

[6] Alcatel-Lucent and CHTTL. System design frameworks to support type iirelay operation in lte-a,r1-092157, May 4th - 8th 2009.

[7] Atoll. http://www.forsk.com/web/EN/15-umtshsdpa.php, March Accessed2011.

[8] SJ. M. Celentano. Carrier capital expenditures. September 2009.

[9] Lei Chen. Coverage Planning and Resource Allocation in Broadband CellularAccess. PhD thesis, Linköping University, 2010.

[10] Erik Dahlman, Stefan Parkvall, Johan Sköld, and Per Beming. 3G Evolution,HSPA and LTE for Mobile Broadband. Academic Press, 2 edition, 2008. ISBN978-0-12-374538-5.

[11] EARTH. Energy Aware Radio and neTwork technologies. Technical report,EU Funded Research Project FP7-ICT-2009-4-24733-EARTH, Jan. 2010 -June 2012.

[12] V. Angelakis et al. Spa planning and optimization framework. Technicalreport, FP7-PEOPLE-2007-3-1-IAPP project #218309: IAPP@RANPLAN,Nov. 2010. D. Yuan (ed.), public deliverable D.1.3.

77

78 Bibliography

[13] Francis Glassborow. You Can Program in C++: A Programmer’s Introduc-tion. John Wiley and Sons, 2006. ISBN 0470014687, 9780470014684.

[14] Harri Holma and Antti Toskala. HSDPA/HSUPA for UMTS. Wiley, 5 edition,2006. ISBN 10 0-470-01884-4.

[15] Harri Holma and Antti Toskala. WCDMA for UMTS: HSPA Evolution andLTE. Wiley, 5 edition, 2010. ISBN 978-0-470-68646-1.

[16] M.A. Marsan, L. Chiaraviglio, D. Ciullo, , and M. Meo. Optimal energysavings in cellular access networks. June 2009.

[17] N2NSOFT. http://www.n2nsoft.com/index.php?page=solutions, March2011.

[18] Prismo. Prismo Simulator. http://www.softwavenet.com/products/simulator, March Accessed 2011.

[19] SEACORN. Enhanced umts radio access network for ns-2. http://eurane.ti-wmc.nl/eurane/, Accessed 2011 March.

[20] Iana Siomina, Di Yuan, and Fredrik Gunnarsson. Handbook of HS-DPA/HSUPA Technology, pages 271–295. CRC Press, 2011. Print ISBN:978-1-4200-7863-3.

[21] SteepestAscent. 3G UMTS FDD with HSPA. http://www.steepestascent.com/content/default.asp?page=s2_11, March Accessed 2011.

[22] WinProp. WCDMA HSPA Simulations. http://www.awe\-communications.com/Network/3G/Applications/HSDPA.html, MarchAccessed 2011.

[23] S. Zhou, J. Gong, Z. Yang, Z. Niu, and P. Yang. Green mobile access networkwith dynamic base station energy saving. September 2009.

Date post:	26-Mar-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Design & development of an HSPA system simulator for ...430942/FULLTEXT01.pdf · ments for HSPA...

Documents