Design &amp; development of an HSPA system simulator for network planning

Full text

(1)LiU-ITN-TEK-A--11/029--SE. Design & development of an HSPA system simulator for network planning Arash Matinrad 2011-05-23. Department of Science and Technology Linköping University SE-601 74 Norrköping , Sw eden. Institutionen för teknik och naturvetenskap Linköpings universitet 601 74 Norrköping.

(2) LiU-ITN-TEK-A--11/029--SE. Design & development of an HSPA system simulator for network planning Examensarbete utfört i Elektroteknik vid Tekniska högskolan vid Linköpings universitet. Arash Matinrad Examinator Di Yuan Norrköping 2011-05-23.

(3) 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 extraordinä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ör ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/ Copyright The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/. © Arash Matinrad.

(4) Abstract HSPA planning requires identification of key performance indicators (KPIs), such as infrastructure cost,performance, service quality and the amount of E/M pollution. To evaluate such a framework describing and linking these key elements for HSPA planning and optimization we need to carry out a set of HSPA system-level event-driven simulations under different scenarios. To have such simulations, a new tool should be developed. In this thesis work a simulation tool is developed within NS-3, an open source network simulator. The simulation tool consists several entities to represent a UMTS network and respective nodes in it, and necessary procedures to form a network dynamically. A simple base station removal algorithm in a system level, is developed focusing on the reduction of capital expenditure (CAPEX) of a network. The algorithm defines a cost function in order to remove the most costly base station from network preserving the target coverage percentage. Baseline results show that the simulation tool is working properly and later the results from algorithm indicate that, it is possible to use the algorithm within a dynamic simulation.. 1.

(5)

(6) Acknowledgments I would like to thank my supervisor Dr. Vangelis Angelakis. He helped me a lot to understand how to do an academic research work. I want to thank Professor Di Yuan for his kind support on this project. I also appreciate my wife, Negar, for her 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 finish this thesis work.. 3.

(7)

(8) Contents 1 Introduction 1.1 Overview of the Universal Mobile Telecommunication System (UMTS) 1.1.1 Physical layer (PHY) in WCDMA . . . . . . . . . . . . . . 1.2 High Speed Downlink Packet Access . . . . . . . . . . . . . . . . . 1.2.1 The High Speed Downlink Shared Channel . . . . . . . . . 1.2.2 MAC-hs and PHY layers . . . . . . . . . . . . . . . . . . . 1.3 High Speed Uplink Packet Access . . . . . . . . . . . . . . . . . . . 1.4 Review of Available Simulation Platforms . . . . . . . . . . . . . . 1.4.1 NS-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 NS-3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.3 Comparison between NS-2 and NS-3 . . . . . . . . . . . . . 1.4.4 Enhanced UMTS Radio Access Network Extension (EURANE) for NS-2 . . . . . . . . . . . . . . . . . . . . . . . . 1.5 A Brief Survey on Commercial HSPA Simulators . . . . . . . . . . 1.5.1 WinProp/ProMan . . . . . . . . . . . . . . . . . . . . . . . 1.5.2 N2NSOFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.3 Prismo Simulator . . . . . . . . . . . . . . . . . . . . . . . . 1.5.4 Atoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.5.5 3G UMTS FDD with HSPA . . . . . . . . . . . . . . . . . . 1.6 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 30 32 32 33 33 35 35 36. 2 Implementation 2.1 Nodes Structure . . . . . . . . . . . . 2.1.1 NetDevices . . . . . . . . . . . 2.1.2 Physical Layer . . . . . . . . . 2.2 Channel . . . . . . . . . . . . . . . . . 2.2.1 Iub Channel . . . . . . . . . . . 2.2.2 Radio Channel . . . . . . . . . 2.2.3 MAC layer . . . . . . . . . . . 2.3 RLC layer protocol . . . . . . . . . . . 2.4 Internet Stack . . . . . . . . . . . . . . 2.5 Scheduling and code assignment . . . 2.6 Routing and Switching . . . . . . . . . 2.6.1 Switching and Routing Process. 37 38 38 40 42 42 42 43 45 45 46 46 46. 5. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 7 7 10 11 12 13 18 20 20 22 27.

(9) 6. Contents 2.7. Helper 2.7.1 2.7.2 2.7.3 2.7.4 2.7.5 2.7.6. Functions . . . . . . . . . Radio Channel Helper . . Radio PHY Helper . . . . UMTS Radio Helper . . . RNC to RBS Helper . . . RNC To RBS Star Helper Switch Fabric Helper . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 47 48 48 48 49 49 49. 3 Simulator Validation Results 3.1 Baseline operation results . . . . . . . . . . . . . . . . . . . . . . . 3.2 Multicell scenario and results . . . . . . . . . . . . . . . . . . . . .. 51 51 55. 4 Modelling for A Simple Base Station Removal Algorithm 4.1 Scheduling and Channelization Code assignment . . . . . . . . . . 4.2 Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63 68 69. 5 Conclusion. 73. 6 Future work. 75. Bibliography. 77.

(10) Chapter 1. Introduction Data communication has become a major part of the mobile networks. The fast growth of the services being offered over the Internet lead to an increase of access to those services by the mobile users such as sending and reading emails, watching videos, sharing music, and etc. To provide service to such increasing throughput demand in a mobile network has always been a challenge for the operators. To provide high throughput in the mobile network, High Speed Packet Access (HSPA) was introduced with Release’99 specification of the Universal Mobile Telecommunications System (UMTS). Downlink (HSDPA) and Uplink (HSUPA) enhancement were extended within release 5 and 6 respectively in UMTS. HSPA network can accommodate high data rate with the help of link adaptation and reduced latency comparing 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 Expenditure (CAPEX) or Operating Expenditures (OPEX), or satisfying the service requirements. For the HSPA network high data rates such as 14Mbps and and low delays in a link can be defined as the QoS parameters. To study on such KPIs a system level simulator is required to be developed. Major part of the simulation module of these thesis work is to implement a HSDPA network and to include some specific characteristics such as physical layer realism. Also a model is built to study on optimization aspect of a HSPA network. The organization of this thesis is as follow: 1) An overview of UMTS and WCDMA network; 2) An introduction to HSDPA and HSUPA; 3) A brief survey on existing tools, frameworks and tool selection; 4) System Model Development; 5) Implementation; 6) Results; 7) Conclusion; 8) Future work.. 1.1. Overview of the Universal Mobile Telecommunication System (UMTS). A UMTS network comprises a hierarchy of nodes and interfaces, as presented in Figure 1.1. The User Equipment (UE) in 3GPP terminology is a device in the 7.

(11) 8. Introduction Internet. PSTN. Core Network. Iu. Iu. Iur. RNC. RNC. Radio Network Subsystem (RNS). Iub. NodeB NodeB. NodeB. NodeB. Figure 1.1: Overall Architecture of UMTS network. network which can communicate wirelessly with one, or more, fixed nodes referred to as NodeB. The NodeBs are responsible for all physical layer activities such as coding, spreading, modulation, transmission, and radio signal reception. A Radio Base Station can be referred to as a NodeB, since the number of cells (normally 1 to 3 cells) is defined as a NodeB. The Access part of the network is supported by the NodeBs. Several NodeBs are connected to the Radio Network Controller (RNC) through out Iu Interface, and network of RNCs and other entities such as gateways, 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 also layered as shown in Figure 1.3. In the radio interface of the UMTS network there are 3 layers similar to ISO/OSI model: a) The physical layer; b) The data link layer; c) The network layer. The radio link control (RLC) and media access control (MAC) form the data layer (layer 2) as shown in Figure 1.3. The network layer (Layer 3) is split into control and user planes (C-plane and U-plane), whose main function of control plane 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 is the 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 and the NodeB. The Radio Link Protocol (RLC) is located in user plane and control plane. There are Automatic Repeat-reQuest (ARQ) schemes implemented in the.

(12) 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 protocol data units (PDU); b) Concatenation and Reassembly of PDUs; c) Padding in the PDUs; d) Error detection and recovery. In Figure 1.3 the Packet Data Convergence Protocol (PDCP) in user plane is an optional function to compress IP headers. Both user plane and control plane contain a Medium Access Control (MAC) layer, which in general handles logical channels and transport channels. The MAC layer also multiplexes data from different logical channels. The MAC sublayers will be discussed later in the HSPA overview section.. Figure 1.3: UMTS Radio Interface protocol layers [1] Before introducing the HSPA protocol and the MAC layers a brief review of the Wideband code division multiple access (WCDMA) physical layer used in UMTS,.

(13) 10. Introduction. is discussed in the next section.. 1.1.1. Physical layer (PHY) in WCDMA. The Physical layer is responsible for coding, spreading and modulation in addition to transmission and reception the radio signals. The Multiple access method used in WCDMA is Direct-Sequence code division multiple access or DS-CDMA which uses a constant chip rate of 3.84 Mcps. The spread information is carried later with the bandwidth of 5Mhz. The modulation schemes used are QPSK and 16QAM. 16QAM was introduced after the release 99 to achieve higher data rate. In the feasibility studies higher modulations such as 64QAM is proposed. The 16QAM performance is suitable for a low-bandwidth connection with high Eb /N0 scenarios that means those user equipment, which are closer to the NodeB. A constellation example 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 a high variable user data rates. A WCDMA frame length is always 10 ms. Although user data rate can not be changed during a frame length, frame to frame, data rate can vary. The spreading is performed by orthogonal variable length Walsh channelization codes, which are also called Orthogonal Variable Spreading Factor (OSVF). The Spreading is used in the uplink to differentiate several user equipment, while it is used in the downlink to differentiate cells. The first few levels of the OSVF are shown in Figure 1.5. Power control mechanisms The WCDMA has a fast power control mechanism originally, both for downlink and uplink to maximize the capacity that is described as bit power per hertz per unit time. Since all the nodes are most of time using the same frequency and perhaps same timeslots (with different codes), it is important to keep the interference as low as possible, specially for the uplink 1 . In WCDMA, base station estimates the received Signal-to-Interference Radio value (SIR) for each user equipment. If 1 Although in WCDMA FDD the uplink and downlink use different frequencies, still the interference in uplink is more important for the sake of user equipment..

(14) 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 lower than the target SIR value, base sation commands the user equipment to increase its transmission power. The whole process is performed 1500 times per second and is called Closed loop power control. The closed loop power control frequency is 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 the RNC. The outer loop control corresponds with a target bit error rate (BER) or interchangeably, a block error rate (BLER). The movement and speed of the user equipment 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 link over time as shown in Figure 1.6, i.e. Fast moving user equipment will have higher allowed target SIR to stay below the maximum BLER (for example 10%)[15]. Allowed SIR. Speed of UE. UE is not moving. Time. 0. Figure 1.6: Outer loop power control mechanism and the allowed SIR of a user equipment according to its speed. 1.2. High Speed Downlink Packet Access. As mentioned earlier HSDPA is an enhancement to the WCDMA and UTMS networks since release 4. In the release 5 high data rates up to 8-10Mbps were.

(15) 12. Introduction. specified. Multi-Input Multi-Output (MIMO) were added to the HSPA specification as of the release 6 which increased the data rate up to 20Mbps. At the same time with the newer releases of HSPA (release 7 and later), Long Term Evolution (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 and lower delay in data connections. LTE is not backward compatible with HSPA and WCDMA. By the time LTE is still under development (very few major cities in Skandinavia have up to now installed the infrastructure, and the selection of user equipment with LTE available, is not yet in double digit) and evolving to LTEAdvanced, HSPA is also evolving to HSPA+. HARQ with soft combining, higher order of modulation, turbo coding, and channelization codes are incorporated in HSDPA to reach highest throughput possible. In this part a more detailed description of the HSDPA will be discussed. An overview of the HSDPA protocol architecture is shown in Figure 1.7. RLC. RLC. MAC. MAC-D HSDSCH FP. HSDSCH FP. L2. L2. L2. L1. L1. L1. MAC-c/sh MAChs / MACehs. PHY. PHY. Uu. HSDSCH FP. HSDSCH FP. L2. L1. I ub. I ur. Figure 1.7: HSDPA protocol architecture [2]. 1.2.1. The High Speed Downlink Shared Channel. The High Speed Downlink Shared Channel (HS-DSCH) was introduced in release 5. All the users data are carried within the HS-DSCH and the shared channel is the main concept in the HSDPA. The HS-DSCH is power controlled so it uses the remained power in a cell based on need as shown in Figure 1.8. The shorter Transport Time Interval (TTI) of 2ms comparing to 10,20,40 or 80ms in the release 99 helps to have shorter round trip time in favor of high bit rate applications. The shorter TTI causes in an excessive overhead in the signalings. The Spreading Factor (SF) is always fixed to 16. The first code is reserved for use 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 used by the user equipment in each TTI as shown in Figure 1.9. The code sharing is performed in the time domain to adapt the user data rate according to the channel variation, through scheduling mechanism. Each channelization set is referred to as High-Speed Physical Downlink Shared Channel or HS-PDSCH. The HS-SCCH.

(16) 1.2 High Speed Downlink Packet Access Power. Unused Power. Dedicated Channels. Common Channels. Time. (a) Unused power with dedicated channel only. Total Available Cell Power. Power. 13. HS-DSCH Power. Dedicated Channels. Common Channels. Time. (b) HS-DSCH dynamic power allocation. Figure 1.8: HS-DSCH power usage is used for the downlink signaling and is received by all the terminals which are using the HS-DSCH regardless of scheduling for the terminal. It uses spreading factor 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 used for the rate-control and the scheduling. To support Hybrid-ARQ (HARQ) after each TTI an ACK or a NAK must be sent in the uplink to identify the success of data reception in the user equipment from HS-DSCH. The High-Speed Dedicated Physical Control Channel (HS-DPCCH) is used to send the ACKs and NAKs in uplink. For each user equipment an HS-DPCCH is configured. the measurement information of the Channel Quality indication (CQI) needed by NodeB for the scheduling and the rate control is sent within the same HS-DPCCH by each user equipment.. 1.2.2. MAC-hs and PHY layers. The MAC-hs in UMTS architecture is a part of MAC layer and resides in NodeB and the user equipment. MAC-hs is responsible for scheduling, rate control and HARQ (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 handling 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 user equipment and its HARQ mechanism to detect any error..

(17) 14. Introduction Mac-d ﬂows. Priority Buﬀers. Scheduler. HARQ MAC-hs. CRC attachment. Bit Scrambling. Code block segmentation. Channel Coding. Physical Layer Hybrid-ARQ functionality. Physical channel segmentation. HS-DSCH Interleaving. Constellation re-arrangement for 16QAM and 64QAM. Physical channel mapping. 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 user which is the key feature of the HSDPA performance. The number of users, distance of users to the cell center, carrier to interference of each user that gives the total C/I in the cell, and channel conditions are parameters being used to decide about the power and the transport block in each TTI. There are several methods for scheduling such as Round Robin, Max C/I, and Fair channel dependent..

(18) 1.2 High Speed Downlink Packet Access. 15. • Round Robin scheduling is the simplest one. All the users who have something 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 channel condition. • 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 equipment 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 based on the received common pilot. The signal-to-noise ratio is calculated by the user equipment and is reported as a recommended transport block size in the CQI. Better channel conditions can lead to use of higher order modulation and lower order 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 can respond fast enough to the fast channel condition variations. The transport block size can be configured from 137 to 27952 bits with channel coding rates of 1/3 to 1. As discussed earlier 16QAM can be used in non-power limited scenarios which means it is available to the users close to the base station and user equipment with advanced receivers. The power used in the HS-DSCH is limited by the Radio resource 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 are used to calculate the non HS-DSCH channels power for admission control in the RNC. 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 priority queues are defined in the scheduler and data are selected from each of them based on the flow priorities. In Figure 1.11 the relations of the scheduler and the priority queues are shown. Hybrid-ARQ with Soft combining Hybrid-ARQ is used in the MAC-hs in the NodeB and its counterpart in the user equipment. Since HARQ is implemented in NodeB and after that, it is done without passing through IuB link from NodeB to the RNC. As a result in case of a poor RNC link any delay is avoided. Each transport block goes through the HARQ process is transmitted in every TTI of 2ms, and retransmissions are sent per same 2ms TTI which means shorter round trip time than R99. If the user equipment receives an erroneous PDU which cannot be decoded, it saves it in the HARQ process buffer; sends a NAK to the sender and waits for a retransmission of the same packet. When the retransmitted bits are received the user equipment soft combines its buffer with retransmitted bit for a second.

(19) 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 continuous data flow is necessary in most cases several HARQ processes work in parallel. Based on manufacturers implementations, a user equipment can configure up to 8 parallel HARQ processes. Each of the HARQ processes has its own buffer to do the soft combining. In user equipment, according to result of CRC from a transport block a retransmission is requested. There is a single bit indicator that shows if received data is a new one or a retransmitted block. This bit is set in the MAC-hs at the NodeB for every transmission. The user equipment uses this bit in order to continue to soft combine. The same single-bit indicator can be used to measure the channel quality in case that user equipment receives an indicator despite 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 of processes is 6. The Number of HARQ processes depends on the total round trip time, which consists of the TTI, processing delay in NodeB and user equipment, radio propagation and interference delay in both the uplink and the downlink. As HARQ processes work independently on their own buffers, so the outcome of all processes would be out-of-sync. Therefore there must be a reordering function to eliminate unnecessary and duplicated-even-correct Mac-hs PDUs and put the correct PDUs in order to be sent up to the higher level. The Reordering entity uses the transmission sequence number in MAC-hs header to reorder the blocks. Reordering buffers are used to keep blocks in respective places in buffer and pass them to higher level in the correct order. A timer is used to for each block to avoid stalling and only one active timer exist in the process. If timer expires for a specific block all the previous blocks will be sent up to MAC-d layer. Since there is a timer defined similar to TCP protocol a window can be defined which is called stall-window. When window-based stall avoidance mechanism is used in case of timeout all the blocks reordered within the window.

(20) 1.2 High Speed Downlink Packet Access. 17. 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 equipment is as following: the PDCP optionally compresses the IP header and sends it to the RLC, the RLC segments the received PDCP Protocol Data Unit into typically 40-byte of data units called RLC PDU. If any multiplexing is needed in the MACd, a header of the MAC-d is added to the RCL PDU and the result is fed into the MAC-hs in the NodeB. A MAC-hs may include several RCL PDU or only one PDU. The MAC-hs header is attached to the frame and a transport block is built. The final result is ready to be sent through physical layer process to be transmitted over the radio channel. The whole process is shown in Figure 1.12.. Reassembly. RLC SDU. RLC SDU. …. MAC-d SDU. Higher Layer. L2 RLC (non-transparent). …. RLC header. MAC-hs header. Higher Layer PDU. …. Segmentation & Concatenation. MAC-d header. Higher Layer PDU. RLC. header. MAC-d. header. MAC-d SDU L2 MAC-d (non-transparent). MAC-d PDU. …. MAC-d PDU. MAC-hs SDU. …. MAC-hs SDU L2 MAC-hs (non-transparent). Transport Block (MAC-hs PDU). CRC. … L1. 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 handled in the NodeB instead of RNC to overcome the fast channel changes, but the RNC is still 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 codes not used for the HS-PDSCH or the HS-SCCH, which is based on what the RNC will configure the HSDPA limit in the NodeB. The NodeB is free to set the power in the HS-DSCH as much as necessary up to the limit set by RNC. Other signaling is defined to report the bit rate measurement to the RNC so the RNC can signal the guaranteed bit rate to the NodeB which is used in MAC-hs scheduler. The direction and the source of signaling channels are shown in Figure 1.13..

(21) 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 mobility for the user equipment. Handovers are Network driven based on user equipment measurement reports. The RRC will decide to hard handover the user equipment based on its active set and its measurement report. During the handover current NodeB has to sent its current buffer in Mac-hs to the new NodeB, and the new NodeB must initiate an HS-DSCH to serve the coming user equipment. Since the Mac-hs protocol is reset during the handover the HARQ buffers are not transferred to the new NodeB so the HARQ buffer must be kept as small as possible[10]. There are proposals for transferring the HARQ buffer such as in heterogeneous network utilizing relay nodes [6][5]. User Equipment Categories There are different user equipment with different processing power, amount of memory, and radio interface. According to these properties each user equipment type can reach to a certain throughput. The throughput of all UE type are listed in Table 1.1.. 1.3. High Speed Uplink Packet Access. The High Speed Uplink Packet Access (HSUPA) has been introduced in release 6 to increase the data rate and to reduce the latency. The HSUPA shares HARQ and scheduling schemes existing in the HSDPA, with some slight changes. The transport channel in the uplink is called Enhanced Data Control Channel (EDCH). There can be one or several E-DCH configured with one or more Dedicated Channel (DCH), so the user equipment can reach higher data rates both in the uplink 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 the NodeB, but in the HSUPA, since the user equipment is transmitting, the.

(22) 1.3 High Speed Uplink Packet Access. 19. Table 1.1: User equipment categories HSDSCH category. 1 2 3 4 5 6 7 8 9 10 11 12. Maximum number of HSDSCH codes received 5 5 5 5 5 5 10 10 15 15 5 5. Minimum interTTI interval. 3 3 2 2 1 1 1 1 1 1 2 1. Maximum transport block size soft bit 7298 7298 7298 7298 7298 7298 14411 14411 20251 27952 3630 3630. Bit Maximum Supported modrate(Mbps) numulation ber of schemes. 3.6 3.6 3.6 3.6 3.6 3.6 7.2 7.2 10.1 14 1.8 1.8. 19200 28800 28800 38400 57600 67200 115200 134400 172800 172800 14400 28800. 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK 16QAM,QPSK QPSK QPSK. transmission buffer is in the user equipment. Therefore all the user equipment must inform NodeB Scheduler about their transmission buffer. • In the HSUPA, the user equipment of a cell are sharing the allowed transmission power to keep interference below the allowed SIR. • In contrast to the HSDPA which transmission channels are Orthogonal, EDCH is Non-Orthogonal. Due to Near-Far problem in the uplink a fast power control is necessary, which on the contrary in the HSDPA a constant transmission power is used. Scheduling The NodeB grants time to each of the user equipment based on its scheduling grants and scheduling request received from all of the user equipment. The user equipment are granted to use E-DCH so the interference in NodeB does not exceed the allowed SIR. More grants (i.e longer time share) means more data rate for user equipment 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 intercell interference within the limit. The scheduling, similar to HSDPA, is performed per TTI in parallel for several user equipment to admit several high-peek rate demanding users at the same time. HARQ and Soft Handover NodeB sends ACK/NACK to the user equipment, and the user equipment learns if the transmission was successful or not. Unlike the HSDPA, user equipment pair for HARQ can be in several NodeBs instead of only one. Hence for the user equipment it is enough to receive ACK/NACK from any of the NodeB in its active set..

(23) 20. Introduction. Figure 1.14: E-DCH and DCH processes [10]. 1.4. Review of Available Simulation Platforms. There were two approaches to realize this thesis project: to use a commercial HSDPA simulator, or to use a non-commercial network simulator and to build the HSDPA simulation module. Commercial simulators, such as OPNET, were discarded due to potential delays in obtaining the necessary license and flexiblity in programming. In the next sections a short review on two major existing open-source network simulators are considered. Since NS-3 was chosen to be the platform to work with the NS-3 section is more in depth to familiarize more the reader with it. Also a brief survey over commercial solutions evaluated is presented.. 1.4.1. NS-2. The NS (The Network Simulator) or NS-2 as variant of the REAL network simulator 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 the simulations is Tcl. The core of the simulator is written in C++ which is mainly anything with packet processing. To connect Otcl and the Tcl user front-end to the 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.

(24) 1.4 Review of Available Simulation Platforms. C++. 21. 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 of protocols, network devices and etc. There are many contributed codes to NS-2 so it 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, Unicast), Traffic sources (CBR, FTP, HTTP), Routing algorithms, Queuing policy, QoS, Sensor Networks, Tracing, Random number generator, Mobile IP, Mobility models, and network animation. The advantages in using NS-2 can be briefed as below: • 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 disadvantages as 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 packets being transmitted. • No official support available.

(25) 22. Introduction. In NS-2 only supported trace sink is ASCII output file. To refine the results a text processor such as python or AWK should be used.. 1.4.2. NS-3. NS-3 is a discrete-event network simulator similar to NS-2. It is written from scratch after its predecessor, it is not an upgrade from NS-2 and it is not backward compatible. NS-3 core is written with C++ with an interface to support python scripting 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 front end was accessible only through TCL. Using a single language in developing the core, simulator, models, topology definitions, and scenarios make the debugging much easier than it is in NS-2 which is a bi-language approach. NS-3 version at the 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 in Figure 1.16. Helper Routing. Internet Stack Node. Devices Mobility. Common. Simulator Core. Figure 1.16: Software organization. Key Concepts The NS-3 Architecture concept is somehow similar to a computer case where there is a motherboard and some Network Interface Controller(NIC) which are used by several applications. The key concepts are: Node, Packet, and Channel. Node A node in NS-3 can have several interfaces, applications, functionalities such as mobility. For instance a node can have a wireless NIC with UDP traffic through it and a wired NIC which is transferring TCP traffic. Nodes are instances of the class ns3::node. A high level architecture of the node is shown in Figure 1.17. The Aggregation concept in NS-3 helps the extension of a node much easier than before in NS-2. Internet stack, mobility, application, or any other defined object with proper interface to the node can be aggregated to the node. So it is not requires to define different types of node to support for different functionalities. An NIC is a Net Device (NetDevice) in NS-3. Current available netdevices in NS-3 are:.

(26) 1.4 Review of Available Simulation Platforms. 23. Figure 1.17: High-level architecture of node. • PointToPoint NetDevice. • Bridge NetDevice. • CSCMA NetDevice. • WiMax. • WiFi NetDevice • Mesh NetDevice. • UAN (Underwater Acoustic Network). Packet Packets are what the most of the simulation is based on. A packet is consisted of a byte buffer, a list of bytes, packet tags, packet headers and packet metadata. In NS-2 it was almost a cumbersome duty to define a new type of packet. New packet type must be defined both in Tcl library of simulator and also in the header file "packet.h".The approach to define a new packet is totally revised from 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 concatenation 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 all packets in memory during the simulation which for large networks is very memory consuming. In NS-3 using virtual buffer of zero-filled helps to use much less memory..

(27) 24. Introduction. Channel The Channel is attached to the Netdevice that means there is one channel per Netdevice such as PointToPoint channel model, CSMA channel model, and Wireless channel model. Since in NS-3 it is possible connect netdevices with only 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 new modules in higher levels and in a more managed state than in NS-2. Some of them are as below: CallBack Although there are already methods in C++ to implement the callback, in NS-3 a separate API is implemented to support callbacks. It is designed to enable the developer to call a function or method from any piece of code without dependency between modules. Attribute Attributes are the way to get access to internal member values of an object. These values can have default values in the code in the traditional way in C++, addressed with file system-like path, or through command-line arguments. Configuration of the attributes of the objects in the scenarios either with default values 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 classic pointer 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-object fashion would be quite long and a tedious coding style. Hence Helper API is developed to mitigate those problems. The Helper API is aimed to maximum code reuse. There is a container API, which is used to contain number of same objects or a group of objects and also enable the user to perform the same action on the group. The helpers and the containers are mostly loops to perform recursive actions. Random variables There is a pseudo-random number generator (PRNG) available in NS-3. The random numbers can be generated via instances of class RandomVariable and existing random classes derived from RandomVariable are:.

(28) 1.4 Review of Available Simulation Platforms. 25. • Uniform Variable. • IntEmpirical Variable. • Constant Variable. • Deterministic Variable. • Sequential Variable. • LogNormal Variable. • Exponential Variable • Triangular Variable • Pareto Variable • Gamma Variable. • Weibull Variable • Normal Variable. • Erlang Variable. • Empirical Variable. • Zipf Variabled. One of the usage for such variables could be to generate traffic. For example a pareto variable can be used to define the start/stop time of a TCP traffic over a link. Logging and Tracing Tracing is completely different than it is in the NS-2 approach, it is not necessary to change the core to have a new type of tracing system. In NS-3 tracing source remains the same but sink can be customized by user to have one or several types of output for the tracing. In other word user attaches the source to the customized trace sink as shown in Figure 1.18 Different trace sources from different objects. Trace Source. Trace Source Trace Sink. Trace Source. 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 latter format is completely standard and can be read with wireshark or similar network..

(29) 26. Introduction. Debugging It is possible to use in code printing to debug or use an API to make the debugging and code tracing neat and clean. There are several logging levels (for debugging) that can be enabled in during the simulation. Some those are 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 currently possible 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 as in 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 information such as routing table, traffic type, or number of packets sent and received.. Figure 1.19: NetAnim GUI.

(30) 1.4 Review of Available Simulation Platforms. 27. Emulation The emulation mode lets user to connect to real world systems to send and receive data to them, so it is possible to use the real system as a testbed. For example ORBIT testbed which is a laboratory with a 2-dimensional network of 400 IEEE802.11 radio nodes. In Figure 1.20 a sample of a TestBed emulation 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 several propagation loss models, as following. • Fixed Rss. • Nakagami. • Friis. • RandomFixed Rss. • Jakes. • Three Log Distance. • 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-3. Before moving to next part a comparison between NS-2 and NS-3 is given in Table 1.2. The comparison almost covers all the key aspects of a simulator.

(31) 28. Introduction Table 1.2: Comparison between NS-2 and NS-3 from different aspects. Flexibility. Programming Model. Model management. Support for Hierarchical Models. Debugging and Tracing Support. Variety of Models Available. It has been designed as a (TCP/IP) network simulator, and it difficult to simulate things other than packet-switching networks and protocols with it. Everything such as nodes, agents, protocols, links, packet representation, and network addresses etc is hardcoded. Everything that is new needs to be written mostly again, almost impossible in re-usability Mixed-mode: OTcl (Object-Tcl) with underlying C++ classes. OTcl is also used for creating and configuring networks, recording results etc. Not clear API, Core is not totally separated, Mostly patches are necessary (ns-default.tcl for example). In NS-2, models are "flat": creating subnetworks, or implementing a complex protocol as a composition of several independent units (that appear as one unit) are not possible in NS-2. Two languages to debug, Octl code is not easy to debug, Not easy to change the tracing format.. Since it has been used for long time in researches, a large number of models and protocols are available. Some are still active and most of them are not.. Separation of every element in network from their actions and capability or as it is called in documentation Object aggregation model, Standard input/output formats so other tools can be used like as wireshark to read trace outputs.. Object-oriented, pure C++ language for modules, models and scenarios, Bindings in Python for scenarios written in python. A stand-alone core, Components are added in separated library done by researcher, Possibility to import models (not yet implemented). Object Aggregation lets building complex compound units from simpler elements.. Easy to debug since there is only C++ language.Tracing sink is configurable but tracing source is same for all modules. Traces can be read with third party softwares like wireshark. There are mix of new and ported models available. Wireless model is written from scratch according to IEEE802.11 specification, New models are being added by some universities from Italy, Russia, Germany and others recently..

(32) 1.4 Review of Available Simulation Platforms. 29. Table 1.2: (continued) Term NS-2 Documentation Not enough documentation on the API. Most of modules are not documented or rarely documented. Documentation is found here and there without any central library. No maintainer to keep documents up-todate. Ability to It is not very good in simRun Large ulating large networks due Networks to its memory management flaw which keeps all data in memory until the stop time of simulation. “Segmentation fault”happens mostly due to memory management. Maintenance The engine is still supported by of engine and the owners but since NS-3 is models started there would be no new versions coming. Modules are not supported officially by the contributers. Mostly no contact can be found in case of problems and question. There is still an active mailing list. Licensing. GPL. NS-3 The core is highly documented. Doxygen is used to generate documents for each piece of code. Documentation is being updated regularly for everything in NS-3.. New memory management and its new core enables users to simulate very large networks.. A new stable release is out about every 3 months, Modules are officially maintained by the owners or contributers, There are contacts available for every module that are responsible in case of questions and more, There are workshops and webcasts, It also has an active mailing list. 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++.

(33) 30. Introduction • Very good software architecture with planing to keep the NS-3 project alive for 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 started in 2004, developed within the SEACORN project by Ericsson. It is compatible with version NS-2.30 although it is possible to apply the patch to higher versions but 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 are defined: • FACH. • DCH. • RACH. • HS-DSCH. The Mac-d and Mac-hs protocols are defined, which Mac-d is defined within the RLC and Mac-hs is defined within the NodeB and the user equipment. The RLC supports Acknowledged Mode (AM), and Unacknowledged Mode (UM). There are several parameters available to tweak which are: • Downlink Bandwidth. • Uplink Bandwidth. • Downlink TTI. • Uplink TTI. The same parameter can be configured for FACH, RACH, and DCH. As it is mention in section 1.1 the RNC and its NodeBs are communicating through the IuB interface. In EURANE, IuB interface should be defined with configurable parameters follows: • Downlink bandwidth. • Uplink bandwidth. • Downlink delay. • Uplink delay. • Queue type. • Queue size. In 2006, Abdulmohsen Mutairi [19] provided a static multicell (UE attachment should be done in scenario) with a semi-dynamic channel model patch for the existing EURANE. Fast fading, shadowing, CQI calculation based on BLER file are added in this new patch. The RLC AM or UM mode can be configure with a wide range of parameters such as: window size, payload size, ACK size, retransmission time out, TTI. The RLC UM is responsible for :.

(34) 1.4 Review of Available Simulation Platforms. 31. • 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 configurations for the Mac-hs protocol are: TTI, Delay. Mac-hs PDU reordering is also available which its maximum number of flow and priorities can be configured. HARQ is also implemented with configurable number of processes and also delay of process for ACK. In initial version of EURANE there is not any real channel type. The only input to 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 not possible to configure odd number of UE nodes in simulations. As it is mentioned earlier 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 able to well maintain the code and also develop and expand it much easier later. So the whole simulation module was decided to be written from scratch and also port some parts of the EURANE codes to a new NS-3 based module..

(35) 32. Introduction. 1.5. A Brief Survey on Commercial HSPA Simulators. 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 as Ec /N0 graphically. Most of them support DCH in r99, traffic generator, CQI report, in addition to HSDPA. There are some simulators that let the user to study on specific channels such as CPICH. 1.5.1. WinProp/ProMan. WinProp [22] is a product of AWE Communication Gmbh, it is designed to evaluate system performance, measure the throughput (cell and user based), and study on 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 interference levels. there are different modulation/coding schemes available to simulate in addition to different user equipment types. The system performance and the user QoS can be studied and be changed through network layout or parameters (capacity, coverage). Different simulation can be run in parallel for example HSPA and CS traffic. WinProp support several traffic model with customizable traffic in sessions (HTTP, FTP...). Main Features are: • Propagation and Scenarios: Rural, urban, indoor, tunnel scenarios • Service Mix: Spreading factor, PS traffic definition, target SNR, Mobile types, multiple services in one simulation run..

(36) 1.5 A Brief Survey on Commercial HSPA Simulators. 33. • HSDPA: Modulation, Block size, number of codes, packet processing (Segmentation/concatenation), Interference level determination, CQI report, HARQ, Higher level retransmission (RLC) • Link level performance: Import BLER performance tabled, Open ASCII interface • 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 by network layout or better say NodeB antenna vector (as in handbook), the impact can be studied and visualized with the simulator.. 1.5.2. N2NSOFT. N2NSOFT [17] is made by the company with same name located in France. The module developed by the company within the N2Nsoft to simulate HSPA network is named NetScale. With NetScale it is possible o design, dimension and optimize networks. Traffic models are defined at the end-user level. NetScale claims it can handle more than 10 millions of concurrent flows to be simulated. Single flow of 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 to visualize the output of simulation. HSPA related functionalities are not explained on the website and no data sheet could be found. Yet it can be seen that modulation/coding schemes are available, in addition to RLC configuration to find the optimums solutions.. 1.5.3. Prismo Simulator. According to their website [18] Software Wireless creator of Prismo Simulator is located in France and have work with Alcatel Mobile, Qualcomm, Arraycomm,.

(37) 34. Introduction. Figure 1.24: HSDPA adapts its modulation and coding scheme to the radio channel state. 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 R99 simulations. It supports different RAN vendors radio resource management algorithms 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 the process.

(38) 1.5 A Brief Survey on Commercial HSPA Simulators. 1.5.4. 35. Atoll. Atoll [7] by Forsk is a complete solution to network planning and optimization. Atoll version 2.8 includes support for HSPA+ and MIMO. Atoll UMTS/HSPA module supports Monte Carlo UMTS/HSPA/MBMS simulator for DL and UL power control, RRM, HSDPA/HSUPA to R99 downgrading and carrier allocation algorithms. it supports plots for Eb /N0 prediction, service areas, handover areas, BER/FER/BLER, Scrambling code allocation, manual and automatic multicarrier neighbor planning. With Atoll UMTS/HSPA module site sharing (co-sites) and simultaneous display and 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 HSPA. This module is developed to be used in MATLAB [21]. it has a graphical user interface (GUI) for specifying configurations with High Speed Downlink Packet Access (HSDPA) support. CRC/Interleaving/fade channel simulator are main features supported by this module. Supported platforms are: • The MathWorks Simulink • Agilent SystemVue This toolbox supports transport channels and physical channels according to release 5 of the 3GPP specifications for uplink and downlink. In HSDPA transmission toolbox it supports HARQ including two stage rate matching with redundancy versioning, 16QAM modulation with constellation rearranging and multicode, high.

(39) 36. Introduction. speed shared control channel, XML configuration for subframe by subframe parameter control. In its other block there BER measurement block, clock generator for events, Slot Field Multiplexer supporting S-CCPCH, DL-DPCH,UL-DPCCH and PRACH slot formats, and user defined.. Figure 1.27: Steepest Ascend 3G FDD Simulation Library. 1.6. Motivation. To study on network properties for instance to measure link properties from application layer to physical layer, or to study on network capacity requires a fairly accurate simulation with lowest cost in terms of time. Static simulations are a good way to research on aspects of a network, but to have dynamic simulation over simulated time is an asset to study on KPIs and deliverance and further more for the sake of optimization. Such simulation module is basically designed in different layers of physical, MAC, and control layer to obtain detailed results. NS-3 is chosen to be the simulation framework since it is pure C++ and it is a fresh and live ongoing, well maintained project. Although It was not easy to just port EURANE into NS-3 because of C++/Otcl entanglement2 , and in addition the bilanguage 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 original EURANE. To build the simulator module a model is required to be developed first. The model describing the the work simulated in the NS-3 we produced for this thesis is presented in the next chapter.. 2 Refer. to the NS-2 disadvantages, section 1.4.1.

(40) Chapter 2. Implementation In this chapter details of each element in the model is discussed as it is implemented in the real code. To build the HSDPA simulation module, three node types same as in the real UMTS network exist. Two different channel types are introduced and developed. One for the radio interface which NodeB and all UEs on the network are connected to and the other channel type is the IuB channel which is between RNC and all its associate NodeBs. Three different NetDevices are implemented to support UE, NodeB and RNC functions and two other netdevices to support layer 2 routing (NbSwitchFabric and RncSwitchFabric). There are also helpers developed to ease building scenarios. In this chapter channel, Node (NetDevice, PHY, MAC, Routing, Flow Management) are explained. In Figure 2.1 an overview of nodes and the related objects in NS-3 is shown. NbSwitchFabric. RncSwitchFabric. RNC. UE NodeB. RLC. RLC. MAC. MAC. MAC-d. MAC-hs. L2 Switch. L2 Switch MAC-d. MAC-hs. PHY (L1). Uu. Frame Protocol PHY (L1). Transport (L1). Frame Protocol. Iub. UmtsUeNetDevice RbsNetDevice UmtsIubNetDevice UmtsRLC UmtsMacD UmtsMacHs UmtsMacHs UmtsUePhy UmtsRadioChannel UmtsRadioPhy UmtsIubPhy UmtsIubChannel. Transport (L1). RncNetDevice UmtsRLC UmtsMacD UmtsIubPhy. 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.

(41) 38. 2.1. Implementation. Nodes Structure. Each node has a NetDevice inherited from UmtsNetDevice as in NS-3 definition which a Mac layer connects it to the physical layer of node. All the nodes communicate through the designated channels. In NS-3 it is possible to connect a NetDevice directly to the channel since the NetDevice already has send and receive interfaces available to use, but as per requirement of the module, MAC and physical (PHY) layers are developed. The overview of a simple node is shown in Figure 2.2 Node. NetDevice MAC PHY. 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 the node as well, with the help of helper functions aggregation of this functions are not cumbersome. The complete schematic of the node is shown in Figure 2.3. Application (UDP, TCP,...) Node Internet Stack Mobility Packet Routing NetDevice MAC PHY. Figure 2.3: A complete View to Node in HSDPA module. 2.1.1. NetDevices. NetDevices are like network interface controllers in real computers and represent the Link layer in OSI model. Each NetDevice has its appropriate PHY. Such as UmtsUeNetDevice has a radio supporting PHY layer and PHY layer of RncNetDevice is wired equivalent. In this thesis work, four type of NetDevices are defined:.

(42) 2.1 Nodes Structure. 39. • UmtsUeNetDevice: To represent the user equipment • UmtsIubNetDevice: To represent the NetDevice in NodeB connected to IuB channel. • RncNetDevice: To represent the RNC. • RbsRadioNetDevice: To represent the NetDevice in NodeB connected to radio channel. RncNetDevice RncNetDevice is a point-to-point device which contains UmtsRLC and UmtsIubPhy. UmtsIubPhy is attached always to UmtsIubChannel. RncNetDevice has also the UmtsMac_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 a UmtsRadioPhy that is attached to a UmtsRadioChannel and also includes a Mac-hs layer. RbsRadioNetDevice has a database of all of its UmtsUeNetDevice’s. The scheduling of traffic to all attached user equipment is done in this netdevice. It is also possible to limit the maximum number of user equipment admission. The default value is 20. UeNetDevice This object represents the user equipment (UE) in the network. It is inherited from the UmtsNetDevice and includes a UmtsUePhy as its physical part. NbSwitchFabric and RncSwitchFabric Both of the NetDevices are bridge NetDevices and are inherited from BridgeNetDevice already developed within NS-3. Both are responsible to switch packets to the correct port similar to a real L2 switch. The bridge port is in fact a NetDevice (e.g. a RncNetDevice or a RbsRadioNetDevice). When packets goes through the switch fabrics they learn about links. If the switch fabric does not know about the next port it broadcasts the packet to all the ports except the port the packet is received originally from. To have the correct traffic switching, an extra node which is the internet gateway should be used, otherwise the traffic can not be switched if it is originated in the RNC..

(43) 40. Implementation. 2.1.2. Physical Layer. The physical layer is implemented in the UmtsPhy class, which is an abstraction for the other physical types as well. The basic functions within UmtsPhy are channel and NetDevice assignment. The channel is discussed in section 2.2. Since different 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 connects UmtsIubNetDevice to UmtsIubChannel, No real PHY related is implemented in this 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 2D matrix is defined to support horizontal and vertical pattern shown below: " GH1 Antenna Pattern = GV1. GH2 GV2. GH3 GV3. ··· ···. # GH360 (dBm) GV360. UmtsUePhy It is inherited from UmtsRadioPhy so shares the same properties with it. but to keep the differences between a NodeB and a user equipment (e.g. a phone) a separate object is added to the project. The function that is exclusive to UmtsUePhy is the capability to measure the SINR of each TTI and reporting it to its higher layer (UmtsUeNetDevice). both radio PHY’s have antenna pattern to calculate the transmission and reception gains. The antenna pattern (vertical and horizontal) is read from an MSI formatted file and is save in to an array, as a result a 3D, 360 by 360 pattern is save in the pattern array. The representation of vertical propagation pattern array is 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 are measured 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 is used for the system following equation are used: 1 To. have functionalities such as CSMA or any kind of delay. same for UmtsUePhy. 2 Obviously.

(44) 2.1 Nodes Structure. 41 90. 180. 0. 270 0. θ (degrees). 359. gain (dBi). 0. -45. Figure 2.4: A sample of polar antenna pattern and its linear representation Table 2.1: UmtsRadioPhy/UmtsUePhyconfigurable attributes Parameter Tx power Minimum RX Level Antenna Orientation Antenna Tilt Antenna Gain. Unit dB dB Degree Degree. Sender position vector =< x1 , y1 , z1 > Receiver position vector =< x2 , y2 , z2 > p r = ∆x2 + ∆y 2 + ∆z 2 ∆z θ = cos−1 r ∆y φ = tan−1 ∆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. The UmtsRadioPhy have a time window in which it aggregates all the receive signal power levels received from other NodeBs. So the SINR is measure only in the downlink. Through ns3::UmtsRadioPhy::SetAntOrientation() the azimuth can be.

(45) 42. Implementation. Z. NodeB Antenna Pattern. X. Φ. ϴ. UE (Pixel j). Y Figure 2.5: An example of antenna pattern to find φ and θ changed. SetAntTilt() function is defined to change only the mechanical tilt of the antenna. The electrical tilt is not supported in this module.. 2.2. Channel. In 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 the network. Both of them are inherited from UmtsChannel.. 2.2.1. Iub Channel. The Iub channel, UmtsIubChannel, is connecting all the NodeBs to their respective RNC. This channel is designed as a point-to-point channel, i.e. one end of the UmtsIubChannel is always the RNC and the other end is one of the NodeBs. It is implemented as a wired equivalent fullduplex lossless channel. There is not any delay implemented in this channel. All packets are scheduled to be transmitted immediately when they are sent to the channel from a UmtsIubPhy object.. 2.2.2. Radio Channel. The radio channel is named UmtsRadioChannel in the module. The physical layer that must attach to this channel are UmtsRadioPhy and UmtsUePhy which.

(46) 2.2 Channel. 43. the latter is inherited from UmtsRadioPhy. The channel has a list of all the UmtsRadioPhy attached to it. Uplink and downlink channels are basically of the same UmtsRadioChannel. When the channel receives a packet from the UmtsRadioPhy of a NetDevice, it sends the packet to UmtsRadioPhy objects of all other NetDevices that are already attached to the channel. The time that the packet scheduled to be sent is calculated within the propagation delay model. The receive signal power 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-ray ground reflection model is used as default for the loss model, and constant speed propagation delay is the default delay model. It is possible to use other models in the simulation scenario, or even use more than one model at the same time. In Two-ray ground reflection model, it is only possible to introduce same height for all of the nodes in the Two-ray model(not NetDevices). Since it is not possible to pass the height of the each antenna separately to the current model, NodeB antenna height can be defined through mobility object that put the node on higher place.. Uplink and Downlink Channels. Send. NodeB. Send. Uplink Channel. UE. Downlink Channel. Receive. Receive. In order to implement uplink and downlink channels, same UmtsRadioChannel object 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 knows to which object it should send the packets. By the same convention the downlink channel is defined. The downlink channel is attached to the physical objects of all NodeBs (UmtsRadioPhy) and all the user equipment physical objects are added to the channel send-to list. The idea and the way it is implemented is shown in the Figure 2.6.. 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 WCDMA and UMTS network, only Mac-d and Mac-hs are partly implemented in this thesis work. Mac-d class is present in the module more as a place holder and it does not have any real Mac-d functions..

(47) 44. Implementation. Mac-d Mac-d is used to tag each of the PDU with a time stamp, PDU direction, and the PDU type. The tag is attached on the way to layer below and it is removed when the PDU comes from the same layer. Mac-hs Mac-hs in this project was implemented as a throughput mapping function based on the SINR which includes the HARQ delay as well. In table 2.2 throughput empirical values (shown in Figure 2.7) are shown for each SINR. A linear interpolation function is used to find SINR-to-throughput values that are not found as in Equation 2.1.. Figure 2.7: HSDPA data rate as a function of SINR. HARQ and link adaptation effect 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 from the UE to shape the throughput of the data flow of a UE. Found throughput is used to calculate the number of PDUs (with size of 40KB) to be transmitted in each TTI (2ms). The NodeB has a list of its active user equipment, and by active it means a user equipment that has a traffic, and it goes through the list one by one. The amount of data to transfer is found by throughput which is found by linear interpolation..

(48) 2.3 RLC layer protocol. 45. Table 2.2: Throughput mapping values SINR (dB) 25 23 21 18 16 13 11 7 2 0. 2.3. Throughput (Mbps) 7.8 7.1 5.75 4.3 3 2.15 1.63 0.65 0.032 0.012. RLC layer protocol. Radio Link Control protocol is between the PDCP and MAC layer. The RLC mode supported in this thesis work is the "Unacknowledged Mode" (UM). RLC UM 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 RLC receives a SDU it checks if the SDU needs to be segmented. If it should be segmented then starts to segment the SDU into PDU of 40KB each including the header size which can vary between 2 to 4 bytes based on the information necessary to be included in the header. For example if the current PDU is the first one or the last one, or if the PDU contains the whole SDU or not. There are buffers for both SDUs and PDUs to be stored in both directions, that are simple FIFO queues. 2.4. Internet Stack. To support IP layer in a node, there is an Internet stack already exists in the NS-3 which should should be aggregated to the node by the help of InternetStackHelper..

(49) 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 have any IPv4 address assigned to the interfaces. Ipv4AddressHelper is used to define the IP base (e.g. "10.1.0.0") and then assign IP to the interfaces later.. 2.5. Scheduling and code assignment. The scheduler resides in this NetDevice. A round robin scheduling function is developed to go through the serving queue every TTI (2ms) based on the available codes and the queue size. The number of codes assigned to each user equipment in every TTI is also done in a round robin fashion. Hence if there are more than 15 user equipment in the queue, user equipment after 15th will be served in the next TTI.. 2.6. Routing and Switching. NS-3 already support layer 3 routing, i.e. ip routing which is not a good choice to work with in this kinda of network, due to extra IP header for required for each packet. As a result a layer 2 switching mechanism is added to NodeB and RNC that are called NbSwitchFabric and RncSwitchFabric respectively. NbSwitchFabric is added to every NodeB in order to support switching packets between RbsRadioNetDevice and UmtsIubNetDevice. The RNC node it would have a number of NodeBs attached to it. To support the switching traffic to the respective NodeB or user equipment RncSwitchFabric must be added to RNC node.. 2.6.1. Switching and Routing Process. As soon as a NodeB is defined and started, it begins to broadcast a message on its IuB channel to find its RNC. It sends a "Hello" and when the RNC receives the message sends back a "HELLO_REP" so both nodes switch fabric get updated. When NodeB is started it broadcasts a CPICH message similar to CPICH in 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 to sending out RACH. If the RACH is not responded it will send a new RACH to the next best CPICH in the list. This also corresponds to the method explained in the next 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 4 it will sends a AGCH back to user equipment, at the same time it forwards the message 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 the packet size..

Design &amp;amp; development of an HSPA system simulator for network planning

Design & development of an HSPA system simulator for network planning