mobility load balancing in LTE networks in order to minimize the effect of delay in ...... Cell: in mobile networks, a cell is the geographical region covered by the ...
A PREDICTIVE MODEL FOR MOBILITY LOAD BALANCING IN LONG TERM EVOLUTION NETWORKS
BY
AWOSEYI AYOMIKUN ABAYOMI (PG 13/0038) B.Sc. Computer Science-ICT Option (ACU, OYO)
A Dissertation submitted to the Department of Computer Science, College of Physical Sciences, Federal University of Agriculture, Abeokuta, in Partial Fulfillment of the Requirement for the Award of a Degree of Master of Science in Computer Science.
November, 2016
1
DECLARATION I hereby declare that this dissertation has been written by me and is a record of my own research. It has not been presented in any previous application for a higher degree of this or any other university. All citations and sources of information are clearly acknowledged by names of references.
……………………………………………… Awoseyi, Ayomikun Abayomi Date: …………………………………………….
2
CERTIFICATION This Dissertation titled “A Predictive Model for Mobility Load Balancing in Lte Networks” by Awoseyi, Ayomikun Abayomi (PG13/0038) meets the regulation governing the award of the Master of Computer Science of the Federal University of Agriculture, Abeokuta and is approved for its contribution to scientific knowledge and literary presentation.
…………………………………………. Dr. O. A. Ojesanmi (Major Supervisor)
…………………………….. Date
…………………………………………. Dr. O. Folorunso. (Co-Supervisor)
……………………………… Date
…………………………………………. Dr. G. A. Dawodu (Co-Supervisor)
………………………………. Date
…………………………………………. Dr O. A. Ojesanmi Ag. Head, Department of Computer Science
…………………………….. Date
…………………………………………. Prof. A. O. Mustapha Ag. Dean, College of Physical Science
…………………………….. Date
3
ABSTRACT Long Term Evolution (LTE) networks suffer from load imbalance due to lack of prior knowledge of the target cell’s resource capacity and delay in load information transfer. Existing works laid emphasis on estimating load situation at the target cell before load balancing using probabilistic techniques. This work proposed a predictive model for mobility load balancing in LTE networks in order to minimize the effect of delay in load information transfer. Multilayer Perceptron Neural Network (MLP-NN) was adapted and trained to provide the predictive capability of the base station. The MLP-NN was made up of three layers: the input, the hidden, and the output. The input layer consists of five nodes: call arrival rate, call drop rate, average service time, handoff rate and handon rate. The hidden layer was made up of two layers with the first layer consisting of four nodes and three nodes for the second layer. The output layer was made up of one node (the predicted state). The sigmoid function and the Resilient Propagation (RPROP) were used as the activation function and training algorithm respectively. The cell shape was assumed to be hexagonal, the path-loss model adapted was the Cost-231-Hata (sub-urban) model, the handover parameter used was the handover offset. Each base station in the network was equipped with the Predictive Mobility Load Balancing (PMLB) and a priority lookup table that dynamically ranks the cell’s neighboring base stations based on their predicted state. A network simulator was developed using java programming language on which platform the proposed model was implemented and evaluated. PMLB was benchmarked with Without Load Balancing (WLB) and Traditional Load Balancing (TLB) schemes. The evaluation parameters included percentages of satisfied, blocked and unsatisfied requests. The evaluation parameters were considered for 72, 108 and 144 end users on the network. The training results showed that the MLP-NN’s predicted state were able to mimic the 4
actual cell’s state trend to an accuracy of 84.28%. For the satisfied request, the PMLB, TLB, and WLB averaged at 97.83, 31.46 and 29.71%; 97.41, 29.84 and 29.42%; and 36.59, 11.42 and 19.10% for the three end users on the network respectively. The blocked requests averaged at 2.17, 58.33 and 62.99%; 2.59, 62.07, and 63.02%; and 43.48, 57.79, and 65.96% respectively, while the unsatisfied requests averaged at 0.00, 5.21 and 7.30%; 0.00, 8.08 and 8.55%; and 11.23, 20.79 and 14.94% respectively. With these results, it could be concluded that the PMLB is most efficient in handling mobility load balancing challenges of the LTE networks than the TLB and WLB.
5
DEDICATION This dissertation is dedicated to God Almighty, the Creator of the heavens and earth. I also dedicate this work to my parents, my sisters who stood by me in trying times.
6
ACKNOWLEGEMENT I express a deep sense of gratitude to God almighty for the gift of life, good health, direction and guidance throughout the period of this research work. I also appreciate my parents (Dr and Mrs Awoseyi) and three wonderful sisters (Wemimo, Folashade, Opeyemi) and their husbands (Oluwaseyi, Olanrewaju, Ladun) for their support, valuable advice, prayers and most importantly their faith in me. My profound gratitude and regards to my Major Supervisor (Dr O. A. Ojesanmi) for his mentorship, exemplary guidance, painstakingness, and constant encouragement throughout the period of this research work. His wealth of experience which he readily made available remains invaluable for life. I am also grateful to my amiable Co-Supervisors Dr. Folorunso O. whose innovativeness and mentoring is a guide both for this work and in life, and also Dr. Dawodu G. A. whose wealth of information was essential to this research. I also want to appreciate Professor Akinwale and members of staff of the Department of Computer Science; their commitment to the success of their students remains an inspiration to me. I take this opportunity to acknowledge the contributions of Engr. Oronti and Mr Adewusi of the Department of Electrical Engineering (FUNAAB). Mr Yusuf, and Mr Agosu, whose contributions to this research work cannot be quantified and staff of the ICTREC (FUNAAB). Finally, I acknowledge my friends, and course mates whose love, support, constant encouragement and prayers contributed significantly to the success of this research work.
7
TABLE OF CONTENTS Content
Page
TITLE PAGE ............................................................................................................................ 1 DECLARATION ...................................................................................................................... 2 CERTIFICATION .................................................................................................................... 3 ABSTRACT .............................................................................................................................. 4 DEDICATION .......................................................................................................................... 6 ACKNOWLEGEMENT .......................................................................................................... 7 TABLE OF CONTENTS ......................................................................................................... 8 LIST OF TABLES .................................................................................................................. 12 LIST OF FIGURES ................................................................................................................ 13 CHAPTER ONE .............................................................................................................. 1 1.0
INTRODUCTION ........................................................................................... 16
1.1
BACKGROUND ............................................................................................. 16
1.2
DEFINITION OF TERMS ............................................................................... 18
1.3
RESEARCH MOTIVATION ........................................................................... 19
1.4
PROBLEM STATEMENT .............................................................................. 20
1.5
RESEARCH SCOPE ....................................................................................... 20
1.6
RESEARCH OBJECTIVES ............................................................................. 21
CHAPTER TWO ........................................................................................................... 22 2.0
LITERATURE REVIEW ................................................................................. 22
2.1
INTRODUCTION ........................................................................................... 22 8
2.2
2.3
2.4
2.1.1
Evolved Packet System ......................................................................... 22
2.1.2
The Core Network (Evolved Packet Core) ............................................. 23
2.1.3
Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ....... 25
2.1.4
Layer 1: PHY Layer .............................................................................. 26
2.1.5
Layer 2 .................................................................................................. 31
2.1.6
Layer 3 .................................................................................................. 35
2.1.7
Interfaces ............................................................................................... 40
2.1.8
LTE MOBILITY ................................................................................... 41
SELF-ORGANIZING NETWORKS (SON) .................................................... 47 2.2.1
Network Management: .......................................................................... 47
2.2.2
Self-Organizing Networks (SON) .......................................................... 48
2.2.3
SON Standardization and use cases ....................................................... 49
2.2.4
SON Architecture .................................................................................. 51
2.2.5
Challenges of SON ................................................................................ 56
MOBILITY LOAD BALANCING .................................................................. 57 2.3.1
Mobility Load Balancing Operation Modes ........................................... 57
2.3.2
Load balancing mechanism in connected mode: .................................... 58
2.3.3
Relevant Measurement for Mobility Load Balancing ............................. 60
WAVE PROPAGATION AND PATHLOSS MODELS .................................. 61 2.4.1
Okumura Model .................................................................................... 62 9
2.5
2.4.2
Okumura-Hata Model............................................................................ 62
2.4.3
Cost-231-Hata Model ............................................................................ 63
PREDICTIVE MODEL ................................................................................... 63 2.5.1
2.6
Neural Network ..................................................................................... 64
RELATED WORKS ........................................................................................ 66
CHAPTER THREE........................................................................................................ 69 3.0
METHODOLODY .......................................................................................... 69
3.1
INTRODUCTION ........................................................................................... 69
3.2
ASSUMPTIONS AND DESIGN CONSIDERATIONS ................................... 69
3.3
ARCHITECTURE ........................................................................................... 70
3.4
FLOWCHARTS AND ALGORITHMS ........................................................... 73
3.5
MULTILAYER PERCEPTRON FOR MLB .................................................... 82
CHAPTER FOUR .......................................................................................................... 85 4.0
RESULTS AND DISCUSSION ....................................................................... 85
4.1
INTRODUCTION ........................................................................................... 85
4.2
DEVELOPMENTAL PHASE .......................................................................... 85
4.3
IMPLEMENTATION TOOLS ......................................................................... 86
4.4
4.3.1
Java for Network Simulation ................................................................. 86
4.3.2
Encog for Machine Learning ................................................................. 88
LTE SIMULATOR .......................................................................................... 88 10
4.5
SIMULATION AND PARAMETER CONFIGURATION ............................ 106 4.7.1
4.8
SIMULATION SCENARIO .......................................................................... 108 4.8.1
4.9
Simulation ........................................................................................... 106
Parameter Configuration ...................................................................... 108
TRAINING PHASE ....................................................................................... 108 6.9.1
Data Source ......................................................................................... 110
6.9.2
The Propagation Algorithm ................................................................. 110
6.9.3
Pruning the Neural Network ................................................................ 111
4.10 EVALUATION PARAMETERS ................................................................... 114 4.11 RESULTS ...................................................................................................... 115 4.11.1
Users on the Network (72 Users) ......................................................... 115
4.11.2
Users on the Network (108 Users) ....................................................... 118
4.11.3
Comparing 72, 108 and 144 Users Scenarios ....................................... 121
CHAPTER FIVE ......................................................................................................... 131 5.0
DISCUSSION ................................................................................................ 131
5.1
CONCLUSION.............................................................................................. 132
5.2
RECOMMENDATION ................................................................................. 132
REFERENCES ............................................................................................................ 133 APPENDIX (CODES) ................................................................................................. 137
11
LIST OF TABLES Table
Page
Table 1: Number of Sub-carriers and Resource Block for different Bandwidth ............... 30 Table 2: LTE Simulation Parameter Configuration ....................................................... 109 Table 3: The average percentile for Unsatisfied Requests. ............................................ 124 Table 4: The average percentile for Blocked Requests. ................................................. 125 Table 5: The average percentile for Satisfied Requests. ................................................ 127
12
LIST OF FIGURES Figure
Page
Figure 1: The Overall EPS Network Architecture and Interfaces .................................... 24 Figure 2: OFDM Structure. ............................................................................................ 28 Figure 3: Symbols in a Sub-frame. ................................................................................. 32 Figure 4: OFDMA time-frequency multiplexing. ............................................................ 33 Figure 5: Protocols and Layers – Control plane and User Plane. ..................................... 36 Figure 6: PDCP Layer main packet operation. ................................................................ 37 Figure 7: RRC States Transitions. .................................................................................. 39 Figure 8: Handover procedures based on X2 Interface .................................................... 46 Figure 9: Network Operations - A) Today, B) with SON. ............................................... 52 Figure 10: SON Architectures ........................................................................................ 53 Figure 11: Real SON Hybrid Architecture ...................................................................... 55 Figure 12: Load Balancing Solution. .............................................................................. 59 Figure 13: A Typical Representation of a Neural Network. ............................................ 65 Figure 14: Predictive Model Architecture ....................................................................... 71 Figure 15: Energy Saving State Flowchart ...................................................................... 73 Figure 16: Monitoring State Flow Chart. ........................................................................ 75 Figure 17: Reporting State Flow Chart. .......................................................................... 77 Figure 18: Mobility Load Balancing Flow Chart. ........................................................... 79 Figure 19: State-Transition Diagram of an eNodeB. ....................................................... 81 Figure 20: Multilayer Perceptron for MLB ..................................................................... 83 Figure 21: Simple Class Diagram of the Simulator. ........................................................ 90
13
Figure 22: LTE Simulator representation of the 6-celled Network. ................................. 91 Figure 23: Code excerpt from the Network Picture class. ............................................... 92 Figure 24: Code excerpt from the LTE Simulator scheduler. .......................................... 93 Figure 25: Code excerpt from the Abstract Element class. .............................................. 95 Figure 26: Code excerpt from the eNodeB class showing Call admission method. .......... 96 Figure 27: Sector Code showing generateUsers() and generateUserPosition() methods. . 97 Figure 28: UE code excerpt ............................................................................................ 99 Figure 29: Code excerpt showing the UE’s class getPRBEstimator() method ............... 100 Figure 30: UERequest Class code excerpt. ................................................................... 101 Figure 31: The Command abstract class. ...................................................................... 102 Figure 32: PRBEstimator abstract class; code excerpt .................................................. 103 Figure 33: OkumuraHataModel class code excerpt. ...................................................... 104 Figure 34: Cost231HataModel class; code excerpt........................................................ 105 Figure 35: Initializing the neural network in eNodeB class. .......................................... 107 Figure 36: Cell[0]’s Neural Network Training Graph. .................................................. 112 Figure 37: The Final Structure of the Neural Network. ................................................. 113 Figure 38: Graph of Unsatisfied Requests for 72 Users:. .............................................. 116 Figure 39: Graph of Blocked Requests for 72 Users:. ................................................... 117 Figure 40: Graph of Satisfied Requests for 72 Users:.................................................... 119 Figure 41: Graph of Unsatisfied Requests for 108 Users:. ............................................. 120 Figure 42: Graph of blocked request for 108 Users:. ..................................................... 122 Figure 43: Graph of Satisfied Requests for 108 Users:. ................................................. 123 Figure 44: Unsatisfied Request Bar Chart for 72, 108 and 144 Users:. .......................... 128 Figure 45: Blocked Request Bar Chart for 72, 108 and 144 Users:. .............................. 129 14
Figure 46: Satisfied Request Bar Chart for 72, 108 and 144 Users:. .............................. 130
15
CHAPTER ONE 1.0 1.1
INTRODUCTION BACKGROUND
Long distance communication began with the introduction of telegraphs and simple coded pulses, which were used to transmit short messages. Since then numerous technological advances and discoveries have rendered the transfer of information easier and quicker. Wireless communications have evolved over the decades from the first Hertz demonstration of practical radio communication in 1880 (Agrawal and Zeng, 2011) up to the latest Third Generation Partnership Project’s (3GPP) Long Term Evolution (LTE) released in December 2008 (Dahlman et al., 2011). LTE stands for Long Term Evolution, it is a 4G (fourth generation) mobile communication technology and was started as a project in 2004 by telecommunication body known as the Third Generation Partnership Project (3GPP). It evolved from an earlier 3GPP system known as the Universal Mobile Telecommunication System (UMTS), which in turn evolved from the Global System for Mobile Communications (GSM). The term LTE is typically used to represent both LTE and System Architecture Evolution (SAE). SAE is the corresponding evolution of the General Packet Radio Service/third generation (GPRS)/3G packet core network. Related specifications were formally known as the evolved UMTS terrestrial radio access (E-UTRA) and evolved UMTS terrestrial radio access network (EUTRAN). In contrast to the previous cellular systems which uses circuit-switched model, LTE has been designed to support only packet-switched services (Palat and Godin, 2009). The first version of LTE was documented in Release 8 of the 3GPP specifications and was released in December 2008.
16
The Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) specification was introduced to meet the ever growing demand for packet-based mobile broadband systems(Piro et al., 2010). Some of the key features of LTE include; high spectral efficiency, very low latency, support of variable bandwidth, simple protocol architecture, and support for Self-Organizing Networks (SON) operation(Atayero and Luka, 2012). Despite the latest improvements in cellular network technologies, there exists a particular problem that has plagued all cellular network service providers over the years; that is congestion. Congestion can be defined as the situation that arises when the number of calls emanating and terminating from a particular cell is more than the capacity that cell can cater for at that particular time (Mughele et al., 2012). To reduce the effect of congestion and some other challenges when it comes to managing a cellular network, the LTE introduced in its release 9 of the LTE standard the concept of Self Organizing Networks (SON) in 2009 (Suria, 2012) SON operation improves overall system performance through efficient operations and maintenance. The aim of Self Organizing is to substantially reduce human intervention in network operations, which reduces human errors by increasing automation, with the added advantage of reducing capital expenditure (CAPEX) and operational expenditure (OPEX). The SON comprises of Self-Configuration, Self-Optimization, and Self-Healing. The SOCRATES (Self-Optimization and self-ConfiguRATion in wirelEss networkS) project developed self-organization framework for LTE radio networks (Hu et al., 2010). This dissertation concentrates on Mobility Load Balancing (MLB) which is a part of the Self-Optimization functionalities of the Self-Organizing Networks (SON). Load Balancing 17
is a term used to describe any method whereby highly loaded cells share out some of their load (traffic) to less heavily loaded neighbors, this allows for more efficient use of radio resources across the whole Network (Kwan et al., 2010). There are two general methods of load balancing, channel borrowing and load distributing. In the first method, overloaded cells try to borrow resources they need from neighboring cells. However, channel borrowing is not applicable to the LTE systems because the channel reuse factor of the LTE systems is 1. This is due to the access technique used in the LTE system that is, the orthogonal frequency division multiple access (OFDMA)(Al-juboori and AL-Dahwi, 2013). The second method attempts to distribute the traffic load of the heavy loaded cells by controlling the transmitting power of the base station or by adjusting handover regions forcing some mobile stations to handover to neighboring light loaded cells (Yang et al., 2012).
1.2
DEFINITION OF TERMS
Cell: in mobile networks, a cell is the geographical region covered by the transmission of a base station or eNodeB. Evolved Node B (eNodeB or eNB): It is the hardware that is connected to the mobile phone network that communicates directly wirelessly with mobile handsets (UEs), like a base transceiver station (BTS) in GSM networks. With an eNB there is no separate controller element, this simplifies the architecture and lowers response time especially in LTE. Third generation partnership project (3GPP): is a collaboration between groups of telecommunication associations, known as the Organizational Partners. Their mandate includes the development and maintenance of GSM, UMTS, LTE/4G etc. related standards. 18
Target Cell: is the eNodeB chosen by the UE to handover to during the handover or mobility load balancing process. 1.3
RESEARCH MOTIVATION
Congestion in a network is defined as a state of network elements (e.g. switches, concentrators, eNode B, transmission links etc.) in which the network is not able to meet the negotiated network performance objectives for the already established connections or for new connection requests. In mobile networks, load imbalance is a major problem which is due to the non-uniform distribution of users across the network. This may lead to situations where heavily loaded cells are in the neighborhood of lightly loaded cells, this leads to degradation of Quality of Service for users in heavily loaded cells (Atayero and Luka, 2012). If congestion and random events can be predicted to an accuracy of about 80% and above (Gao and Li, 2011; Javed et al., 2011; Meetei and George, 2011; Ogwueleka et al., 2014). Then it is time to start thinking of how to adapt predictive solutions to load imbalance problems. The future of Self Organizing Network (SON) operations is in the use of machine learning to enhance SON functionalities (Hamalainen et al., 2012). The main motivation for this proposed research study is the degradation in Quality of Service caused by load imbalance(Atayero and Luka, 2012) which has the dual effect: (i) Degradation in Quality of Service affects the users or the subscribers to the network negatively, which can frustrate users. This produces unsatisfied users in the network. (ii) When users or subscribers are continuously dissatisfied this can lead to users leaving the providers network; this affects providers in terms of losing profit.
19
1.4
PROBLEM STATEMENT
One of the challenge of the SON’s load balancing functionalities is the delay in information transfer. There are two main problem statements; (i) In a bid to load balance, load intended to be shared to a target cell may exceed available resources at that cell. This is majorly due to lack of prior knowledge of the target cell resource capacity and delay in load information transfer between load balancing cells. Therefore, a need for load estimation at the target cell. (Al-juboori and AL-Dahwi, 2013; Lobinger et al., 2010; Suria, 2012) (ii) Because of the dynamic nature of the load situation in a network vis-à-vis load situation in a cell. There is a need for an estimation model that can a) infer correctly unseen relationships that affect the predicted output b) is data-driven and self-adaptive. The design of a deterministic solution might not be the best approach, however, a probabilistic approach should be better suited (Suria, 2012)
1.5
RESEARCH SCOPE
This research is tailored towards the mobility load balancing operation of the selfoptimization function of the self-organizing network (SON). In mobility load balancing (MLB), there are three types of mobility load balancing and these are: (i) Inter-RAT: the load balancing between different radio access technologies (RAT) e.g. LTE and UMTS. (ii) Inter-frequency: the load balancing between two different frequencies of the LTE network.
20
(iii)Intra-frequency: the load balancing between cells using the same frequency. This research work focuses on the intra-frequency mobility load balancing, since the same basic procedure applies to the three.
1.6
RESEARCH OBJECTIVES
Specific research Objectives are to: (i) Evaluate existing approaches for the load balancing scheme identifying their limitations. (ii) Develop a load balancing scheme based on the cell load prediction model. (iii)Implement (ii) above using Java Programing Language. (iv) Evaluate the performance of the proposed model.
21
CHAPTER TWO 2.0 2.1
LITERATURE REVIEW INTRODUCTION
In contrast to previous cellular mobile network systems which use a circuit-switch model, Long Term Evolution (LTE) has been designed to support packet switch services only. It is considered to be the last step in the evolution of mobile communications systems which extends and modifies the Universal Mobile Telecommunications System (UMTS). It aims to provide seamless Internet Protocol (IP) connectivity between user equipment (UE) and the packet data network (PDN). The term “LTE encompasses the evolution of the UMTS radio access through the EvolvedUMTS Terrestrial Radio Access Network (Evolved-UTRAN/E-UTRAN), it is also accompanied by a non-radio access evolution under the term “System Architecture Evolution (SAE)”, which includes the Evolved Packet Core (EPC) network. Together LTE and SAE comprise of the Evolved Packet System (EPS) (Palat and Godin, 2009).
2.1.1 Evolved Packet System According to Palat and Godin, (2009), the EPS provides each user or UE with IP connectivity to a PDN for accessing the internet, as well as for running services such as Voice over IP (VoIP). EPS uses the concept of EPS bearers to route IP traffic from a gateway in the PDN to the UE. A bearer therefore is an IP packet flow with a defined quality of service (QoS) between the gateway and the UE. The EPS can establish multiple bearers for a user in order to provide different QoS streams or connectivity to different PDNs.
22
Several EPS network elements have different roles. Figure 1 shows the overall network architecture EPS including the network elements and the standardized interfaces. At the top level the network comprised of the Core Network (CN, i.e. EPC) and the access network (E-UTRAN). While the CN consists of many logical nodes, the access network is made up of essentially just one node, the evolved NodeB (eNodeB), which connects to the UEs. Each of these network elements is interconnected by means of interfaces that are standardized in order to allow multi-vendor interoperability.
2.1.2 The Core Network (Evolved Packet Core) According to Stefania et al., (2009), the EPC supports only access to the packet switched services, meaning it no longer supports the circuit switched domain used in older technologies. The EPC contains all functional core network entities which are grouped into the control plane entities and the user plane entities. The control plane entities include, the mobility management entities (MME), the home subscriber service (HSS) and the policy and charging rules function (PCRF) and in the user plane we have serving gateway (S-GW) and the packet gateway (P-GW). A short description of the different entities and some of their important functions are given below: Mobility Management Entity (MME): The MME is the central element of the EPC; it uses a direct logical control plane connection to support the following functions: (i)
Mobility Management: In Idle and Active mode, UE tracking, MME selection and mobility between 3GPP access networks
(ii) Authentication and security through Non Access Stratum (NAS) signaling (iii)Management of subscription profile and service connectivity
23
Legends AuC HSS HLR MME PCRF PDN LTE E-UTRAN S1 MME S1 U S5 S6a Gx S10 SGi Rx
Authorization Center Home Subscriber Server Home Location Register Mobility Management Entity Policy and Charging Rules Function Packet Data Network Long Term Evolution Evolved – UMTS Terrestrial Radio Access Network S1 control application protocol between E-UTRAN and MME Interface for S1 user plane data between E-UTRAN and Gateway Interface for User plane tunneling between Gateway and PDN Interface between MME and HSS Interface between PCRF and PDN Interface between MMEs Interface between PDN and Intranet or Internet Interface between PCRF and IMS Domain
Figure 1: The Overall EPS Network Architecture and Interfaces
24
(iv) Packet core Bearer management functions including dedicated bearer establishment Home Subscriber Server (HSS): database that stores subscriber data such as User identification, addressing and the user-specific security credentials needed for authentication and ciphering. Policy and Charging Rules Function (PCRF): responsible for quality-of-service (QoS) handling, Interfaces with the PDN gateway to convey policy decisions to it and charging. Serving Gateway (S-GW): provides tunneling management between P-GW and eNodeB and switching with some control functions: (i) Mobility anchor for inter-3GPP mobility (ii)Packet routing, forwarding and buffering (iii) Downlink rate enforcement based on aggregate maximum bit rate (AMBR) Packet Data Network Gateway (P-GW): is the router that looks to the outside world (Internet). Its main functions are: (i) User Equipment IP allocation and routing (ii) Per user packet filtering (iii) Charging for UL/DL per UE, per PDN and QoS Class Identifier (iv) Mobility to non-3GPP RATs.
2.1.3 Evolved Universal Terrestrial Radio Access Network (E-UTRAN) An overall description of the E-UTRAN was provided in the 3GPP specification. The EUTRAN is based on a single radio access entity called eNodeB. The eNodeB (eNB) holds
25
all the network functionalities and therefore there is no need for a centralized controller as the Radio Network Controller (RNC) in UMTS or the Base Station Controller (BSC) in GSM (3GPP, 2011). The exclusion of a separate control entity, the Transmission Time Interval (TTI) in LTE is much shorter than in UMTS or GSM allowing for a very fast adaptation to the radio environment as well as a very flexible and fast access during handover and avoidance of single points of failure, hence the “Flatness” of the architecture. For example, if the BSC should fail all base stations under that particular BSC will automatically fail. Note: a BSC can control tens to hundreds of base stations. The Radio Access Network is composed of eNodeBs connected to each other in a mesh like manner through the X2 interface with IP connectivity allowing good scalability of the network: The E-UTRAN also defines a separation between User Plane and Control Plane which make them independent from each other. This fact influences the latency of the system by lowering it and allows a better scalability. The E-UTRAN functions are grouped into three layers which are the layer 1 (PHY-layer), Layer 2, and Layer 3.
2.1.4 Layer 1: PHY Layer The E-UTRAN is a very flexible air interface that supports both frequency division duplex (FDD) and time division duplex (TDD) modes of operation. Thus, most of the design parameters are common to TDD and FDD modes to reduce the complexity of the terminal. In downlink (DL), LTE uses a new multiple access technology called Orthogonal Frequency Division Multiple Access (OFDMA) which is an extension of Orthogonal Frequency Division Multiplexing (OFDM) for multi-user communication systems that utilize the spectrum in a more efficient manner than the Wideband Code Division Multiple
26
Access (WCDMA) in UMTS or the TD/FDMA of the GSM. OFDM is a special case of Frequency Division Multiplexing (FDM) where the carriers are all made orthogonal with the help of a Fourier transform. This leads to the ability of squeezing subcarrier really tight together. The OFDM structure is shown in figure 2. The subcarrier spacing is standardized to Δf = 15 KHz which is a compromise between the overhead of the Cyclic Prefix (CP), used to reduce Inter-Symbol Interference (ISI) due to multi-path propagation. The smallest transmission unit is the Resource Element (RE). Each Resource Element contains a symbol of duration Tsym = 66.67μs transmitted over a single sub-carrier of Δf = 15 KHz, The Downlink and Uplink are divided into Physical Resource Blocks (PRBs). Each Resource Blocks (RB) contains 12 consecutive subcarrier and 6 or 7 symbols (depending on the length of CP) per subcarrier transmitted in a slot (0, 5ms). The OFDM is used to multiplex traffic by allocating specific patterns of sub-carriers in the timefrequency space for different users. Along the frequency domain, bandwidths are allocated in the 1.4MHz, 3MHz, 5MHz, 10MHz, 15MHz and 20MHz. OFDM falls off very slowly out of the OFDM Bandwidth, 10% of the total bandwidth is used as a form of guard band (Dahlman et al., 2011). This 10
means for example if a 5MHz bandwidth is given only (5 – (5 x100)) i.e. 4.5MHz is actually used for transmission by dividing them into subcarriers with peak spacing of Δf = 15 KHz. However the 10% guardband holds for the 3-20 MHz (Zarrinkoub, 2014). These subcarriers are grouped into resource blocks the standard grouping is 1 resource block = 12 subcarriers. A detailed example is shown in figure 2.
27
Figure 2: OFDM Structure. (Kamimura, 2015).
28
Given
a
Bandwidth
of
5MHz,
subcarrier
spacing
Δf
=
15
KHz,
guard band is 10 % of 5MHz = 0.5MHz. Total useful bandwidth Tu = 5 – 0.5 = 4.5MHz Total subcarriers in the bandwidth = Tu / Δf = 4.5 x 1000 / 15 = 300 subcarriers 1 resource block, 1 RB = 12 subcarriers, Total RB = 300 / 12 = 25 RB Table 1 shows a list of Bandwidths and their corresponding number Sub-carriers and maximum Resource Blocks. In the time domain, the smallest transmission unit is Resource Element. Each Resource Element contains a symbol of duration Tsym = 66.67μs transmitted over a single sub-carrier of Δf = 15 KHz. The number of bits per symbol depends on the modulation scheme used e.g. QPSK, 16QAM or 64QAM. In total 6 or 7 symbols are transmitted in each subcarrier depending on the length of the Cyclic Prefix (Suria, 2012). A sub-frame is the combination of two resource blocks equivalent that occupy 2 time slots and a total of 2 RB x (12 subcarriers x 7 symbols), that is 168 Resource Elements. A TTI (Transmission Time Interval) is the smallest scheduling time in LTE equivalent to 1 ms, equivalent to one sub frame or 2 resource blocks. During the scheduling time or TTI the eNodeB decides to which user should be scheduled and which resource blocks are assigned to each one.
29
Table 1: Number of Sub-carriers and Resource Block for different Bandwidth Bandwidth Sub-carriers Resource Blocks 1.4
84
7
3
180
15
5
300
25
10
600
50
15
900
75
20
1200
100
30
Figure 3 and Figure 4 show the symbols in a Transmission Time Interval (TTI) and OFDMA time-frequency multiplexing respectively. In the Uplink (UL), OFMA is not an optimal solution due to the weak peak-to-average power ratio (PAPR) properties of the signal. Instead, SC-FDMA (Single Carrier Frequency Division Multiple Access) with cyclic prefix is used because of its better PAPR properties. 2.1.5 Layer 2 In the 3GPP specification, the layer 2 of the LTE contains three sub-layers these are Media Access Control (MAC) sub-layer, Radio Link Control (RLC) sub-layer and Packet Data Convergence Protocol (PDCP) sub-layer. a)
MAC Sub-layer
The MAC radio protocol sub-layer’s main purpose is to provide an efficient coupling between RLC services and the physical layer. The main functions are (3GPP, 2011): (i) Multiplexing of Radio Bearers (Signaling and Data Bearers): Mapping between Logical channels and transport channels, logical channel identification and transport format selection. (ii) Hybrid Automatic Retransmission request (HARQ): used for Error Correction and allows the network to retransmit faulty packets. (iii)Dynamic Scheduling UL/DL: decides when, where and what kind of data is scheduled and to which UE the data is sent. (iv) Priority Handling: between UEs and between logical channels. (v) Quality of Service QoS Management (vi) Timing Advance: for synchronization of the mobile transmission.
31
Figure 3: Symbols in a Sub-frame = 2 Resource Blocks in a TTI (Sauter, 2010).
32
Figure 4: OFDMA time-frequency multiplexing (Suria, 2012).
33
(vii) MAC Control Messaging: Physical Downlink Control Channel (PDCCH) indicate which resource blocks are allowed to use in the uplink direction (Uplink packet scheduling). (viii) Power headroom report (UL). (ix) Buffer Status Report: Physical Uplink Shared Channel (PUSCH) (x) Padding
b)
RLC Sub-layer
The Radio Link Control (RLC) sub-layer is an entity whose main purpose is to receives/deliver service data units (SDU) from/to upper layer (i.e. RRC, PDCP) and sends/receives RLC protocol data units (PDUs) to/from its peer RLC entities via lower layers (i.e. MAC and physical layers). Due to the peer to peer communications, for a RLC entity at the eNB, there is a peer RLC entity configured at the UE and vice versa (3GPP, 2010). For these purpose three transmissions modes are available and assigned to the different logical channels depending on the type of information the carry: (i) Transparent Mode (TM): Used for general information: it does not change the upper layer data neither does it add a RLC header, it just forwards the data. (ii) Un-acknowledgement Mode (UM): Used for signaling. (iii) Acknowledgement Mode (AM): Used for user data. The main functions of RLC sub-layer are performed depending on the transmission mode (UM or AM): (i.) Segmentation: decides on PDU sizes depending on QoS and available resources (ii.) Automatic Repeat reQuest (ARQ): ensures the correct delivery of data for AM mode over the air interface. 34
(iii.) Reassembly: (UM and AM) it needs a RLC header in the PDU to know the order of the sequence (iv.) Status Report (AM): indicates if retransmission was lost.
c)
PDCP Sub-layer
The Packet Data Convergence Protocol (PDCP) is the third sub-layer of the LTE layer 2 and it has the following functions: (i.) Encapsulation of higher layer protocols (ii.) Packet handling: Buffers packets until they are scheduled by lower layers. (iii.) Packet forwarding: Lossless Retransmission of PDCP SDU to support Handover. (iv.) Queuing: AQM (Active Queue Management) controls the length of the queues and the delays produce by those queues. 2.1.6 Layer 3 As shown in figure 5, the layer 3 can be said to be a control plane layer, because the user plane does not share in the layer 3 protocols, instead the User Data is directly forward to the PDCP Layer as IP packets. PDCP layer packet operation is summarized in figure 6.
a)
RRC Layer
The Radio Resource Control (RRC) is a Layer 3 Access Stratum protocol of the control plane layer, it handles the UE management and controls Layer 2 and Layer 1 parameters as well as UE-eNodeB Signaling (3GPP, 2011). The functions of RRC depend on the RRC state of the UE. The RRC states are RRC_Idle and RRC_Connected. The RRC_Null simply signifies a default state.
35
Figure 5: Protocols and Layers – Control plane and User Plane (Lescuyer and Lucidarme, 2008).
36
Figure 6: PDCP Layer main packet operation (3GPP, 2009).
37
(i)
RRC Connected mode:
(a) RRC Connection management between UE and eNodeB: Radio Resource allocation for the UE and configuration of signaling Radio Bearer (SRB) to send over the control channels. (b) Security functions: such as Key management (c) Quality of service (QoS) management: establishment, maintenance and release of Radio bearers (point to point, MBMS services...) (d) Mobility functions: Handover, inter-cell and inter-RAT mobility and measurements. (e) UE measurement reporting configuration and control: buffer status, downlink channel quality, neighboring cell measurements used for mobility procedures support. (f) UE context transfer between eNodeB at handover (g) Non Access Stratum (NAS) message transfer from/to NAS to/from UE The RRC Layer handles the messaging for the handover of an UE from one serving cell to another target cell. Figure 7 shows the RRC state transitions.
(ii)
RRM Layer
The primary goal of the Radio Resource Management (RRM) Layer is to ensure the efficient utilization and optimization of radio resources by using procedures and adaptation techniques for the different Layers.
38
Figure 7: RRC States Transitions. (Holma and Toskala, 2011).
39
The RRM Layer serves the user according to their minimum QoS requirements to ensure a good user performance. The solutions and algorithms are vendor specific therefore; 3GPP defines just the requirements to support Radio Resource Management such as signaling, QoS requirements and different reporting capabilities (3GPP, 2010). 2.1.7 Interfaces The provision of self-optimizing networks (SONs) is one of the key objectives of LTE; selfoptimization of the network is a high priority for network operators. Hence SON has been placed as a cornerstone of the LTE system from the beginning and is the concept around which all S1 and X2 procedures have been designed (Palat and Godin, 2009). We take a look at two of the interfaces needed for interconnection of the whole EPS. The E-UTRAN is simply a mesh of eNodeBs connected to neighboring eNodeBs with the X2 interface and to the EPC (Evolved Packet Core) through the S1 Interface. (a)
S1 Interface
The S1 Interface connects the eNodeBs to the EPC over an IP connection using the GTP (GPRS Tunnel protocol) protocol. The S1 interface defines 2 types of connections: (i) S1-U: U stand for user plane and the connection is established between the eNodeB and the Serving Gateway(S-GW). This connection uses the GTP-UDP to carry Data Bearers of the users. (ii) S1-MME: is a control plane connection between the MME and the eNodeB to transmit Signaling Bearers over the SCTP/IP protocol. (Stream Control Transmission Protocol). Its main functions are: Bearer Management by SAE (System Architecture Evolution)
Paging over S1 40
Mobility over S1:
(iii)Intra-LTE Handover: just in case there is no X2 interface between eNodeBs. (iv) Inter-3GPP RAT Handover: mobility towards other RATs (Radio Access Technologies) Load management: controls and prevent overload by balancing the load over different MMEs. NAS (Non Access Stratum) signaling transport functions.
(b)
X2 Interface:
The X2 interface connects the eNodeBs to each other in a logical mesh. The X2 interface is not a dedicated physical connection but a logical point to point interconnection between eNodeBs standardized for multi-vendor operability by the 3GPP (3GPP, 2011). The link between eNodeBs is initialized by the identification of neighbors with the help of the ANRF (Automatic Neighbor Relation Function). (i)
X2-U: transmit data bearers over an unreliable GTP-U transport protocol. This type of connection is used to forward data during handover from one eNodeB to another.
(ii)
X2-C: transfers signaling bearers using a reliable SCTP transport protocol.
2.1.8 LTE MOBILITY The procedures for maintaining connectivity depend mostly on the UE state, therefore a distinction between idle mode and connected mode must be made. 3GPP aimed to minimize handover delays and disruptions to provide seamless mobility therefore the architecture used is simple and does not involve the mobility management entities (MME) unless
41
changes to different RATs or different TA (Tracking Areas) are required (Hamalainen et al., 2012).
(i)
Mobility management and User Equipment states
Mobility procedures are divided into two categories, idle mode and connected mode. The transitions between both states are controlled by the eNodeB. UE in Idle Mode: In this state the mobility management is done by the UE, it seeks for the best Public Land Mobile Network (PLMN) and cell to camp on based on parameters provided by the network over the System Information Block (SIB) and its own measurements. Selection and re-selection procedure allows the UE to identify the most appropriated cell or technology for camping. To select the strongest cell the UE needs to measure the different cells that are reachable and suitable based on the S-criterion: Working: (i) RRC asks PHY to scan frequencies and report cells. (ii) Once when UE PHY scans the UE supported frequencies and reports the found out cells during the scan, the results are reported to UE RRC along with their Cell IDs and the Cell specific Power values (RSRP, RSRQ). (iii) UE RRC will select the strongest Cell ID from the list and then will go for Cell validation procedure (iv) When the selected Cell ID passes the cell validation procedure, the UE camps onto it and proceeds to decode the broadcast information (MIB, SIBs). It is during this procedure, that the following calculations take place: Srxlev(dB) > 0 and Squal(dB) > 0
(1)
Srxlev = Qrxlevmeas − (Qrxlevmin + Qrxlevminoffset)
(2)
42
Squal = Qqualmeas − (Qqualmin + Qqualminoffset)
(3)
Where: Srxlev is the Cell selection RX level value (dB); Squal is the Cell selection quality value (dB); Qrxlevmeas is the measured cell RX level value (RSRP), Qqualmeas is the measured cell quality value (RSRQ). Qrxlevmin is the Minimum required RX level in the cell (dBm); Qqualmin is the Minimum required quality level in the cell (dB). The signaled values Qrxlevminoffset and Qqualminoffset are only applied when a cell is evaluated for cell selection as a result of a periodic search for a higher priority PLMN while camped normally in a Visited-PLMN (VPLMN). During this periodic search for higher priority PLMN the UE may check the S criteria of a cell using parameter values stored from a different cell of this higher priority PLMN. The UE retrieves some of those parameters from the SIBs broadcasted over the air interface and then checks the suitability of the cells to make the selection decision based on cell ranking. The following equations describe how the cell ranking is done when the priorities are the same: Rs = Qmeas,serving + Qhyst,s
(4)
Rn = Qmeas,neighbor − Qoffsets,n
(5)
Where Qmeas is the RSRP measurement quantity from either the serving and neighbor cells, Qhyst,s is the power domain hysteresis of the serving to avoid the ping-pong effect and Qoffsets,n is an offset value set to control different frequency specific characteristics or cell specific characteristics between the serving and neighboring cell. Then, the Ranking Algorithm selects the cell: Selected Cell = max{Rs,Rn}
(6) 43
UE in Connected Mode: When an RRC connection exists, the UE is in connected mode. The mobility management is done by the network and it is based on handover. The network controls the mobility decisions based on UE measurement reports from the cells, frequencies and other RAT reachable by the UE. The users satisfaction depends on how these decisions, i.e. finding the best suitable cell, are made and the capabilities of the UE. There are three types of handovers: (i) Inter-Frequency Handover: Occurs between different LTE network Bands to another cell and also vertical Handover within the same cell. (ii) Inter-RAT: Occurs between different radio access technologies (RAT) networks, e.g. WiMAX and LTE, UMTS and LTE, etc. (iii) Intra-Frequency Handover: Occurs within the same LTE network Band between different cells. The intra-frequency handover is the focus of this project. All of the above types of handover have the same basic procedures. Working: (i) UE makes measurements and reports them to the eNodeB; this measurement can be controlled and configured by the eNB through the RRC connection reconfiguration message. (ii) The eNodeB also makes its own measurements and broadcast information over the corresponding SIBs. (iii) The Serving eNodeB makes handover decision, for a UE, to a Target eNodeB based on all the measurement received and available information. The handover procedure can be performed in two ways, the default and most efficient way which is based on the X2 interface and the second one is based on the S1 interface when the conditions and configuration require the intervention of the Management Entities. 44
X2 based Handover: The source eNodeB configures the UE measurements with a RRC connection reconfiguration message and the UE responds with a completion message to acknowledge the configuration parameters. While moving, the UE measures the signals of different reachable cells. When one of the measurement events is triggered, the UE sends measurements reports to his serving eNodeB. The eNodeB decides if the UE should be handed over to a more suitable cell based on the measurements and configuration. When the handover decision is made, the eNodeB send a Handover request to the target eNodeB. If the target eNodeB accepts the handover based on its admission control, it sends back to the requesting eNodeB an acknowledgement to the handover request. The
Serving
eNodeB
informs
the
UE
over
a
Handover
command
(RRC connection reconfiguration message) to change its serving eNodeB. While the UE synchronize to the new Serving eNodeB, the old eNodeB sends the status information and starts forwarding packets to the new eNodeB who buffers them. When the UE is synchronized it send a completion message to the new eNodeB who sends him back the uplink allocation and timing advanced information. Finally, the new Serving eNodeB send a release context message to the old eNodeB and starts sending the buffered packet to the UE. Figure 8 shows the Handover procedure based on X2 Interface.
S1 Interface: S1 mobility management handles handovers when there is no direct connection between neighboring eNodeBs is available, thus no X2 interface has been configured and the main use of the S1 handover is when MME assistance is required to handover the UE such as change in the PLMN, inter-RAT handovers, HeNB handovers or
45
Figure 8: Handover procedures based on X2 Interface.(Suria, 2012)
46
any core-involved handover where the handover procedure is configured to use the S1 interface. The procedure is similar to the X2 handover explained earlier. The packet forwarding will be tunneled over the Serving Gateway (S-GW). If the MME changes during handover additional procedures need to be considered.
2.2
SELF-ORGANIZING NETWORKS (SON)
This section discusses about the self-organizing networks, the need for SON, process of standardization, the use cases standardized by 3GPP and the challenges faced by the implementation of SON functionalities.
2.2.1 Network Management: In today’s network, Network Management (NM) is mostly done in a centralized Operation and Maintenance Center (OMC) based on a centralized Operation, Administration and Maintenance (OAM) architecture. That is, all control parameters are regulated by a centralized entity. However the planning and optimization of the networks is managed by semi-automated tools which need constant human interaction to control the overall performance of the Network (Hu et al., 2010).
Deployment and maintenance of mobile networks is more difficult due to the rapid growth of mobile communications. The complexity of the network increases exponentially as the number of elements increase, as well as the interdependencies between their configurations. The network needs to be constantly monitored in order to maintain good performance. The constant monitoring of the network makes the operator to face strong operational challenges
47
in terms of work effort and cost. Work effort in the sense of the hiring of network expert which is both expensive and prone to human error, both increases cost on the part of the operator.
2.2.2 Self-Organizing Networks (SON) Self-Organizing Networks aim to reduce complexity of the network by means of increasing automation of the network operations. Making the network more automated will reduce operational effort and work load, as well as constant human interaction. Also, it will protect the network from unexpected errors produced by people and will speed-up the operational processes. The SON’s automation of parameter configurations will optimize the settings of every individual parameter in each network element resulting in a global enhancement of the performance of the wireless network. The Self-Organization operation is divided in three parts: (i) Self-Configuration: enables automatic configuration for the Initial Deployment and
planning,
software
installation,
updates,
test,
parameter
setup,
authentication, configurations, neighbor eNB identification and Plug & Play functionalities. (ii) Self-Healing: Aims to minimize the harm that network failures produce. It applies to daily operations of mobile networks, hardware checking for replacement, software updates, network monitoring by measurements and performance analyses, failure recovery and alarm setting for fault detection and triggering of healing mechanisms. (iii) Self-Optimization: automatic real-time control of radio parameters to support the dynamic character of mobile networks, environmental changes, changes on 48
the landscape, changes in user distribution and any other changes that affect the network performance. The optimization decisions depend on the operators’ preferences and policies. Here are some of the tunable parameters: a) Radio parameters: handover parameters, neighbor lists, Random Access Channel (RACH), QoS parameters. b) Transport parameters: optimization of S1 and X2 and routing
2.2.3 SON Standardization and use cases The standardization process of SON functionalities started in the 3GPP with the Release 8 specifications, in December 2008, which introduced the Self-Configuration features. It defines procedures associated with initial equipment installation and integration to support the commercial deployment of LTE networks. The procedures defined are: (i) Automatic Neighbor Relation Function (ANR): which enables a cell to maintain information on its neighbors and define operates based on information available at an eNB. (ii) Automated Configuration of Physical Cell Identity: that enables a cell to select automatically its PCI from an allowed range and avoids PCIs that are reported from outside. (iii)Load reporting of current load information for radio, Transport Network Layer (TNL) and hardware. (iv) Dynamic Radio Configuration (DRC): Automatic configuration of initial radio transmission parameters which allows the base station to become adaptive to the current radio network topology.
49
(v) S1 and X2 setup: this allows the eNodeB to automatically setup the connections between MMEs and Neighbor eNodeBs. The 3GPP Release 9, RAN3 WG (Work Group) continued work on SON functions described in Release 8 and also newly defined in Release 9. These functions are based on Self-Optimization. Here is a list of the different use cases: (i) Mobility load balancing (MLB) optimization which allow network to force users to Handover against the radio condition but due to load situation. Such LB procedure can be executed as an intra-LTE Handover as well as inter RAT HO. In release 9, for the purposes of Load Balancing, procedures have been defined to negotiate Handover settings between eNBs (intra LTE), and procedures to identify appropriate cause values for Handover request or signaling have been defined. (ii) Mobility Robustness Optimization (MRO) which allow on automatic detection and correction of wrong handover settings which may lead to Radio Link Failures (RLF). (iii) RACH Optimization which allows UE to report RACH activity to the eNB. The eNB based on received reports is able to optimize RACH resources and synchronize RACH settings with other eNB by exchanging information over X2 and mitigate interference. (iv) Coverage and Capacity optimization (CCO) which enables the network to detect capacity and coverage problems (e.g. coverage holes). In 3GPP Release 10, SON includes the continuation of the work done in Release 9 which includes enhancements to Mobility Robustness with the focus on inter-RAT Handover and Mobility Load Balancing enhancements to improve intra and inter-RAT procedures, also 50
as a use case Energy saving was added to SON Work Item (WI) (3GPP, 2010). Figure 9 compares Network Operations as presently done and as used in SON.
2.2.4 SON Architecture The three main SON’s architectures, which is classified based on the location of the optimization functionalities; this is influenced by the way data is acquired, the knowledge of the network and the capabilities in each location. The three main architectures are shown in Figure 10. (i.) Localized: The functionalities are executed independently from the surrounding eNodeBs. Therefore, SON functionalities are multi-vendor specific and do not require any standardization. This configuration has no interoperability problems nor is signaling overhead and the delay very low. In the other hand, it just applies to isolated problems in single cells. (ii.) Centralized architecture: All optimization algorithms and functionalities executed in OAM systems. Easy to deploy, vendor specific solutions, slow optimization, enormous amount of data. Thus the response time is slow. No need for inter-eNodeB communication but requires It-N interface support. (iii.) Distributed Architecture: All functionality is executed at the eNodeB, costs a lot of deployment effort to support and coordinate lots of eNodeBs thus
51
Figure 9: Network Operations - A) Today, B) with SON. (Hu et al., 2010).
52
Figure 10: SON Architectures (Feng and Seidel, 2008)
53
Convergence and stability might be difficult. In the other hands, fast solutions are possible because the response time in much smaller. The X2 interface should be extended to allow intercommunication between eNodeBs and standardized for multi-vendor compatibility. Since each one of the different architectures has its advantages and disadvantages, the real SON solution utilizes a Hybrid Architecture, Figure 11 shows the Hybrid Architecture. An approach that implements SON’s deployment on the architecture based on the specific SON functionalities.
Hybrid architecture: The functionalities that need faster response will be implemented closer to the eNodeB and the ones that need a better or wider understanding of the network status will be implemented away from the eNodeB. The time delays acceptable, from collecting the information and application of a solution, depend on the requirements of the different functionalities therefore delays are a key factor when deciding about their locations. Then part of the functionalities is executed in the OAM system and part in the eNodeB which allows a lot of flexibility and diversity in the optimization process. It also needs to support multi-vendor optimizations hence standardization of X2 interface information exchange.
54
Figure 11: Real SON Hybrid Architecture (Feng and Seidel, 2008)
55
2.2.5 Challenges of SON The implementation of SON functionalities has its own challenges especially when implementing solutions for different use cases. In designing an algorithm for the SON, the challenges should be taken into consideration (Suria, 2012). (i)
Interrelation of use cases: some of the decisions made by the different SON use cases may generate opposite solutions or may apply to the same parameters, these situations might not get to a desirable solution therefore some coordination of the use cases is needed.
(ii)
Information availability, consistency and reliability in the network elements would be a major requirement to lead the decision made in different use cases, nevertheless a trade-off between delay and overhead needs to be taken into consideration.
(iii)
Algorithm Design: The information might have delays and are error prone. Because of this a deterministic design to solutions might not be the best approach. However, a probabilistic approach would be better suited.
(iv)
Stability and Convergence: need to be ensure in the solutions especially in dynamic scenarios such as those in the real word
(v)
Evaluation Aspects: evaluation of the performance on the use cases might be difficult to analyze since the use of real networks is prohibitive in terms of costs and most of the information retrieve is confidential. Mobility models, traffic intensities and need to generate their own data to give an estimation of the performance of this use cases.
56
2.3 MOBILITY LOAD BALANCING Mobility Load Balancing (MLB) is part of the Self-Optimization functionalities of SelfOrganizing Networks. The objective of Mobility Load Balancing is to counteract the effect of local traffic load imbalance; when an overload situation appears due to high concentration of users in a specific cell. MLB aims to optimally distribute the users between the under loaded neighboring cells according to the load conditions of the network, the velocity, Quality of Service and Energy consumption of the user. Moreover, MLB moves traffic from high loaded cells to less loaded neighbors as far as interference and coverage situations allow in a certain geographical area by means of controlling mobility parameters and configurations including UE thresholds. MLB changes the mobility parameters, by applying an offset to them. The effect produced by this offset is that, if the user is connected to cell A and he premeasures the received power from the different neighbor eNodeBs, then the best suitable cell might have changed for the user if he is close enough to the border of the cell. MLB solutions should improve QoS, accessibility, and resource utilization within the whole network rather than only on a simple base of neighbor cell relations. Thus, improving the overall system capacity and reduce the congestion in overloaded cells.
2.3.1 Mobility Load Balancing Operation Modes MLB can be subdivided into modes of operations depending on the state of the UE, the different modes of operation are: (i) Idle mode: The main purpose is to prevent the worsening of the overload situation by adjusting cell specific parameters that impact the camping
57
decisions of the UEs in cell selection/reselection procedures by biasing, prioritizing or restricting access to certain Radio Access Technologies (RAT). UEs normally try to connect to the cell where they are currently camped, whenever they change state to connect. (ii)
Redirection during connection: also known as Traffic steering, is another prevention technique that impacts the connection establishment procedure via rejection and redirection of traffic to different Layer/RAT
(iii) Connected Mode: MLB reaches the load balanced situation by shifting UEs from the border of the cell to less congested cells Figure 12 shows the step to load balancing solution.
2.3.2 Load balancing mechanism in connected mode: Load balancing in connected mode is based on changing handover parameters and forcing handovers of edge user to less loaded cells referred to as Mobility Load Balancing. The Mobility Load Balancing can be of three approaches, depending on the type of handover made and the handover parameters being changed and they are: (i) Intra-frequency: in this case, the handover is made on the same system bandwidth as its neighbor and they need to be forced against radio conditions. This research focuses on the intra-frequency. (ii) Inter-frequency: here, the forced handover is produced between different frequencies of the LTE network if available. (iii) Inter-RAT: Similar to inter-frequency, but handovers happen between different Radio Access Technologies.
58
Figure 12: Load Balancing Solution (Lobinger et al., 2010)
59
2.3.3 Relevant Measurement for Mobility Load Balancing Some of the measurements needed to support MLB and reach a certain level of accuracy in the decisions made by the algorithms (3GPP, 2011) (i)
Reference Signal Received Power (RSRP): part of the UE physical layer measurements, It measures the coverage of the LTE cell in the Downlink. It is used to determine the best cell on the Downlink radio interface and select this cell as the serving cell. RSRPc,ue(dB) = Pc − Lue – Lfad
(ii)
(7)
Reference Signal Received Quality (RSRQ): gives an indication of the signal quality and determines the best cell for LTE radio connection in a certain geographic area. Mostly used for initial cell re-selection and handover. 𝑅𝑆𝑅𝑃
𝑅𝑆𝑅𝑄(𝑑𝐵) = 10 ∙ 𝑙𝑜𝑔( 𝑅𝑆𝑆𝐼 ) (iii)
(8)
Total Physical Resource Block (PRB) usage (DL/UP): Average value calculated from the statistic measurements, in time and frequency, of the usage of PRBs resources in the scheduler, by all the users (MAC Layer). This information is signaled over X2 interface between eNodeBs. 𝑡𝑜𝑡 ( ) 𝑃𝑅𝐵𝑢𝑠𝑎𝑔𝑒 % =[
𝑃𝑅𝐵𝑢𝑠𝑎𝑔𝑒 (𝑇) 𝑡𝑜𝑡 (𝑇) 𝑁𝑃𝑅𝐵
∗ 100]
(9)
tot PRBusage is the total PRB in use by UEs in the cell. NPRB is the total PRBs
allocated. (iv)
Composite Available Capacity (CAC): indicates the amount of overall resources that the reporting node is ready to accept. “Composite” means that the reporting node takes into consideration multiple internal resources criteria, via a proprietary evaluation, to build up his report. “Available” estimate of the 60
amount of non-GBR traffic that can be handed over into the cell controlled by the eNodeB. The load transferred should not exceed the capacity reported as available by the TeNB. CAC can have different formats and implementations since the calculations are vendor specific. Here are two possible options: (i)
Simple percentage of the total E-UTRAN resources available (total cell uplink or downlink bandwidth known from the X2 setup procedure).
(ii)
A percentage weighted according to a cell capacity class value which classifies the cell capacity with respect to the other cells available on the network.
2.4 WAVE PROPAGATION AND PATHLOSS MODELS Radio waves are a form of energy that rapidly changes or oscillates; they are essentially a type of electromagnetic radiation. Like all other forms of wave, radio wave has two related properties known as frequency and wavelength. LTE is developed for a number of frequency bands ranging from 800MHz to 3.5GHz (Nkordeh et al., 2014). As with other types of waves, Radio waves are prone to reflection, scattering, refraction, attenuation etc. which causes the wave to fade over distance. Hence a need to model the fading, (i.e. path loss) over distance, of signals generated at the eNodeB. There exist different empirical propagation models ranging from the Okumura, Okumura-Hata, COST231-Hata, COST-231-Walfisch–Ikegami, Sakagam-Kuboi models. These models depend on location, frequency range and clutter type such as urban, sub-urban and countryside
61
(Nadir et al., 2008). The most commonly used models in mobile communications are the Okumura, Okumura-Hata and COST-231-Hata models (Nkordeh et al., 2014; Singh, 2012). 2.4.1 Okumura Model The Okumura model is wholly based on measured data; it is amongst the simplest and best in terms of path loss accuracy in cluttered mobile environment. It is used for frequencies ranging from 150MHz to 1920MHz and can be extrapolated to 3GHz. It can be used for distances ranging from 1Km to 100 Km. Base station antenna heights between 30m to 1000m. Formula for Okumura model is expressed below: Lm(dB) = LF(d)+ Amu(f,d) – G(hr) – G(ht) – GAREA (10)
where Lm = median value of path loss, LF(d) = free space propagation path
loss. Amu(f,d) = median attenuation relative to free space, G(hr) = base station antenna height gain factor, G(ht) = mobile antenna height gain factor, GAREA = gain due to environment. 2.4.2 Okumura-Hata Model This model incorporates the graphical information from Okumura model and develops it further to realize the effects of diffraction, reflection and scattering caused by city structures. This model also has two more varieties for transmission in suburban areas and open areas. It is used for frequencies ranging between 150MHz to 1500MHz. It can be used for distances 1Km to 10Km. Base station antenna heights between 30m to 200m. Mobile stations’ antenna height is between 1m to 10m. Formula for Okumura-Hata model (Nkordeh et al., 2014; Singh, 2012): Lp = A + B log10 (d)
for urban area
Lp = A + B log10 (d) – C for suburban areas
62
(11a) (11b)
Lp = A + B log10 (d) – D for open areas
(11c)
Where Lp = Path loss, A = 69.55 + 26.161log10 (fc) – 13.82 log10 (hb) – a(hm), B = 44.9 – 6.55 log10 (hb), C = 5.4 + 2 [log(fc / 28)]2, D = 40.94 + 4.78[log(fc)]2 – 19.33 log(fc).
2.4.3 Cost-231-Hata Model The Cost-231-hata radio propagation model is an extension of the Okumura-Hata radio propagation model. This model is limited to cases where the base station is placed higher than in surrounding buildings (Nkordeh et al., 2014). It works for frequency ranging 150MHz and 2000MHz. It has models for urban, suburban and open areas. Base station height is between 30m to 200m and the mobile station height of 1m to 10m. The Cost-231Hata path loss model is represented mathematically as. Lp = 46.3 + 33.9log fc – 13.82log hb – a(hm) + (44.9 – 6.55log hb)log d + C
(12)
Where Lp = median path loss, fc = frequency of transmission, hb = base station antenna effective height, hm = mobile station antenna effective height, d = link distance, a(hm) = mobile station antenna height correction factor given as a(hm) = (1.11log fc – 0.7) hm – (1.56log fc – 0.8), C is a constant given as 0 𝑑𝐵 𝑓𝑜𝑟 𝑠𝑢𝑏𝑢𝑟𝑏𝑎𝑛 𝑜𝑟 𝑜𝑝𝑒𝑛 𝑒𝑛𝑣𝑖𝑟𝑜𝑛𝑚𝑒𝑛𝑡 C ={ 3 𝑑𝐵 𝑓𝑜𝑟 𝑢𝑟𝑏𝑎𝑛 𝑜𝑟 𝑚𝑒𝑡𝑟𝑜𝑝𝑜𝑙𝑖𝑡𝑎𝑛 𝑎𝑟𝑒𝑎𝑠 2.5 PREDICTIVE MODEL Predictive models are a collection of mathematical or statistical techniques having a common goal of finding a mathematical or statistical relationship between a target dependent variable and various predictors or independent variables with the goal of using the past and present independent variables to determine the future value of the target or dependent variable (Dickey, 2012). There are two classes of predictive models parametric 63
and non-parametric the former make specific assumptions with regard to one or more of the population parameters, while the latter makes fewer assumptions (Sheskin, 2012). Artificial neural networks (ANN) has the following advantages over other traditional predictive models like the Box-Jenkins series, a) ANN are data-driven and self-adaptive, b) they can be generalized, that is they can correctly infer relationships even if the data is noisy, c) ANN are universal functional approximaters, that is they can approximates any continuous function to any desired accuracy (Macharia et al., 2013).
2.5.1 Neural Network Artificial Neural Networks are very powerful tools that have been used in many domains (Haykin, 2001). Artificial neural networks are modeled to simulate the biological brain. Just like the human brain the neural network is made up of basic building blocks called neurons. A neuron consists of a weighted connections and a threshold which determines if the neuron will fire or not. A typical neural network is constructed of neurons to form layers. Just as the brain a neural network just be trained and then validated. Training the neural network consist of running the neural network over a training data until it learns to recognize the training set with a sufficiently low error rate. Validating occurs when the neural network results are checked. Neural Networks are efficient in solving problems that cannot be expressed as a series of steps such as, pattern recognition, classification, prediction etc. (Heaton, 2008). There are different types of neural network common ones are Hopfield neural networks, MultiLayer FeedForward etc. Figure 13 shows a typical representation of Neural Network architecture.
64
Figure 13: A Typical Representation of a Neural Network.
65
2.6 RELATED WORKS Meetei et al., (2009) worked on the existing handoff procedure of 3GPP modified to include prediction part in order to reduce handoff overhead which could lead to call dropping by predicting user mobility. The model used is a Multilayer Feed Forward Neural Network (predictive model). The main objective of the project is to reduce the two processes of measurement and measurement report. One of the noticed limitations is that in case of a failed prediction the handoff overhead increases which in turn increases the probability of call drops and also resources (channels) are held down.
Lobinger et al., (2010) Mobility load balancing based on signal strength measurement and target cell load estimation after mobility load balancing. This allows the overloaded cell to compare the proposed load to be shed to the load information given it by the target cell. The load estimation is without consideration for cell situations that affects the load on the target cell.
Lv et al., (2010)worked on a distributed load balancing in the LTE. This was done by dynamically adjusting the RRM parameters based on the source cell load and its neighboring cell condition. The limitation include high rate of network signaling and handover negotiations are based on previous resources.
Javed et al., (2011) developed a machine learning framework to predict handoff in the near future. This predicted handoff was used to aid applications in preparing for the degradation in Quality of Service associated with handoffs. It was used in 3G networks evaluated against naïve predictor. 66
Zhang et al., (2011)used a two-layer approach to mobility load balancing. First-layer target cells load estimation is based on the target cells’ neighboring cells, i.e. Second Layer, load estimation. A novel idea that increases the computational complexity in terms of evaluating the target cell load estimation.
Atayero and Luka, (2012) proposed the use of soft computing, i.e. adaptive neuro-fuzzy inference system for dynamic QoS-aware load balancing in 3GPP LTE. Three key performance indicators are used to adjust hysteresis task of load balancing (i.e. no of satisfied user, virtual load and fairness distribution index). The model consist of a 5-layer ANFIS that takes 3 inputs, no of satisfied user, virtual load, fairness distribution index. The output was a Quality of Service indicator that decides either scheduling/handover.
Suria, (2012) considers the interaction between SON MLB use cases in the RRM functionalities in order to optimize the system performance. He used a threshold system which reduces the need for constant signaling over the X2 interface, this threshold system was adopted for this research work. However a probabilistic approach was used in determining the number of free resources at the target cell over a particular period of time. We believe a predictive approach; i.e. the use of machine learning, based on past experiences of the cell could yield a better performance.
Al-juboori and AL-Dahwi, (2013) proposed a general load balancing algorithm to help congested cells handle traffic dynamically. A9-cell model architecture was designed using MATLAB environment. The proposed technique executes handoff to the best cell for the user with guaranteed high service quality by considering both signal strength and load 67
information. Each cell periodically exchanges load information. When the serving cell is congested it uses the reports sent from surrounding eNBs to estimate the target cell load estimation. Then it balances the source eNB by initiating handoff procedure. The limitations noticed include the very iterative technique of load balancing which is computationally inefficient and a very primitive load estimation technique was used and the periodic constant exchange of information on the X2 interface, means heavy traffic along the X2 and load balancing decisions are made based on a previous state.
Raheem and Okereke, (2014) worked on GSM traffic congestion prediction using a predictive model. The predictive model used was Multilayer Perception Neural Network (MLP-NN) with a sigmoidal activation function and Levenberge-Marquadt Algorithms (LMA) as it training algorithm (Back-propagation). Raheem claimed that his model was able to predict the probability of congestion in a network with a correlation coefficient of 0.986 when compared with the actual congestion happening. This work did not provide a model to proactively handle the occurrence of the predicted congestion.
68
CHAPTER THREE 3.0 3.1
METHODOLODY INTRODUCTION
A predictive model for the mobility load balancing problem was designed. The proposed use of the multilayer perceptron neural network, a machine learning algorithm, for PRB estimation to aid load balancing decisions.
3.2
ASSUMPTIONS AND DESIGN CONSIDERATIONS
The following assumptions and design considerations were made in the proposal of this methodology these are highlighted below. (i) The LTE Network: the LTE network like every other mobile communication network technology is divided into cells, a cell can be seen as the base station’s signal reach, theoretically it is circular, practically it is irregular, for this work it is designed to be hexagonally shaped. (ii) Propagation Model: For the path loss model the Cost-231-Hata radio propagation model was adopted. (iii)SON Architecture: This proposal was developed for the SON distributed architecture. (iv) Scope: The scope of these work is limited to the Intra-Frequency Mobility Load balancing (v) HO Parameter: The handover (HO) parameter considered is the HO offset.
69
3.3
ARCHITECTURE
The SON distributed architecture allows the eNodeBs to run different implementations of load balancing scheme and yet interoperate with each other. The predictive implementation will be in two parts: First, implementation in the serving eNodeB, which is the eNodeB that the UEs are connected to, referred to as SeNB. The function of the predictive model is to help the SeNB anticipate its own state based on which a decision is made on which state algorithm to use. Second, implementation is in the Target cell (TeNB) or Neighboring cell (NeNB), which is the cell to which bordering UEs are handed over to, or cells that are in Neighborhood of the SeNB. The predictive model here helps the TeNB and NeNBs to estimate the ratio of PRBs that they can conveniently allocate, referred to as the Composite Available Capacity (CAC), in order to ease the load situation at the SeNB experiencing congestion (mobility load balancing). Figure 14 shows the proposed predictive model architecture. At the Serving Cell, the SeNB does not know what signal strength UE connected to it are receiving as such it waits for the UEs to send a report of the signal strength they are receiving, the number of PRBs that would satisfy their needed data rate. This information helps the SeNB to allocate the required PRBs to the UE which in turn allows the SeNB to calculate its current state through the load ratio. As earlier stated the eNodeB enters the Energy saving mode at initialization and based on the value of the virtual load ̂ 𝜌𝑐 transits into other states. There are four states:
70
Figure 14: Predictive Model Architecture
71
(i)
Energy saving state: This is the idle state were the eNB would perform basic base station functions unless when or load situation requested by NeNBs or it reaches a threshold, thresholdMonitor. Figure 15 shows the flow chart for the energy saving state. Energy saving state algorithm can be seen in Algorithm 1
(ii)
Monitoring State: Like the energy saving state will keep a constant update on the virtual load situation and engage possible predictions when approaching a certain threshold, thresholdReport. Figure 16 shows the flow chart for the monitoring state. This state algorithm is the Algorithm 2
(iii)
Reporting State: In this state the eNB will send a broadcast to all NeNBs to request that they send information about their states or expected load situations. And ranks the NeNBs in its lookup table. Figure 17 shows the flow chart for the Reporting state. Algorithm 3 shows the state algorithm
(iv)
Load Balancing State: In this state the eNodeB begins the process of shedding of excess load to a neighboring cell using any load balancing technique or scheme. Figure 18 shows the flow chart for the load balancing state. Load Balancing algorithm is Algorithm 4.
The state transition diagram is shown in figure 19.
72
3.4
FLOWCHARTS AND ALGORITHMS
Figure 15: Energy Saving State Flowchart 73
Algorithm 1:
EnergySavingState()
Input: integer N, tPRB, nPRB Output: double vLoad Begin Step 0: double dCAC , vLoad int uPRB, N Step 1: Initialize cell parameters Boolean flag = false, signal = false Step 2: do uPRB = 0 for i = 1 to N nPRB = get number of PRB allocated for user[i] uPRB = uPRB + nPRB end for Step 3: vLoad = uPRB / tPRB Step 4: If signal == false then normalBaseStationFunction() else dCAC = computeCAC() sendOut(dCAC) end if while (vLoad = thresholdReport then Step 7: dCAC = computeCAC() end if while (dCAC = thresholdLB) then Step 8: dCAC = computeCAC() Step 9: if (dCAC >= vLoad) then Step 10: LoadBalancingState() end if end if while (dCAC TeNB.getdCAC()) reportState()
80
Energy Saving
Monitoring
Predicting Overloaded cell Reporting
Figure 19: State-Transition Diagram of an eNodeB.
81
Balancing
3.5
MULTILAYER PERCEPTRON FOR MLB
The function of the Multilayer Perceptron is to predict the expected state of the eNB, this is to determine if after a threshold has been crossed is the crossing temporal or is the eNB expected to still be in that new state if yes the eNB switches to the algorithm that takes care of that state. The MLP proposed is to be configured as followed. Figure 20 shows the Multilayer Perceptron Neural Network for MLB. (a) Input Layer: through which the MLP take inputs from the eNB will consist of five nodes which will take the following inputs. (i) Average call arrival rate: This is the rate at which new calls arrive at the cell in the last 60 seconds (ii) Average call drop rate: This is the rate at which calls are dropped in the last 60 seconds (iii)Average call duration: The duration of all completed calls. (iv) Average Hand off Rate: The rate of calls handed off by the cell in question (v) Average Hand on Rate: The rate of calls handed to the cell in questions
(b) Hidden Layer: The hidden layer would be determined at the implementation stage in order to avoid the problem of under-learning or over-fitting.
82
Avg. Call Arrival rate
Avg. Call drop rate
∑
∑
∑
∑
Avg. Service time / Call duration Avg. Hand off rate
Avg. Hand on rate
No of free PRBs
Estimated No of PRBs
∑
∑
∑
∑
Hidden Layers
Figure 20: Multilayer Perceptron for MLB
83
(c) Output layer: The output layer will consist of just one node which will be the expected no of free PRBs which would be used to determine the Composite Available Capacity. (d) Activation Functions: Sigmoidal activation function which is ideal because it produces values between zero and one, good for ratios and percentages. f(x) =
1
(10)
1+ e−x
(e) Backward Propagation: the Levenberge-Marquardt Algorithm (LMA). LMA is reputed to be one of the fastest training algorithms for moderate size feed-forward neural. XK+1 = XK – [JTJ + µI]-1 JT e
(11)
Where XK = vectors of current weights, J = Jacobian matrix (contains first derivatives of errors), e = vector of network errors, µ = a scalar, I = identity matrix and JT = is the transpose of J
84
CHAPTER FOUR 4.0 4.1
RESULTS AND DISCUSSION INTRODUCTION
This chapter discusses about the processes involved in the implementation of the network and the methodology in chapter three. The processes or steps followed to achieve the implementation would best be grouped into phases which are Developmental phase, Simulation and Data collection phase, Training phase, and Evaluation phase.
4.2
DEVELOPMENTAL PHASE
The developmental phase is the genesis of this research work. The goals of this phase is to identify features, entities, models, and theorems that are used in the LTE research environment and group these identified components into three main groups based on how directly important they are to the mobility load balancing area of research: Trivial components, these do not have appreciable effect on mobility load balancing so do not require representation in the LTE simulator for example the channel coding and link adaptation; Semi-Trivial components, these do have certain level of effect on the mobility load balancing but would only need representation in the simulator rather than full implementation for example the Physical Resource Block (PRB); Non-Trivial component, these have direct effect on the mobility load balancing and require as close to full representation as possible an example is the propagation or path-loss models.
85
4.3
IMPLEMENTATION TOOLS
The following tools were used in the simulation and implementation of the proposed work:
Java – Netbeans IDE 8.0.2
JDK- version 1.8.0.
Encog core 3.0.2
System Configuration: Operating System-Windows 10 Pro 64 bits, ProcessorIntel CORE i7 @ 2.00 GHz 2.60 GHz, RAM-8.00 GB.
4.3.1 Java for Network Simulation In a real-life environment where it is considered highly risky to carry out real-life experiments or in a situation where access to the required environment is not available. Simulation has been used in the past to mimic such environments, also, simulation has been used to study the effect of certain events on, or in our case proposed solutions to problems on the system or environment. In order to simulate correctly and efficiently the certain complex interactions of network entities, we need a programing language that supports the following: a)
Object
Oriented
and programming in
Paradigm: which
Is
an
software
approach is
to
primarily
software thought
design of
as
a collection of classes, each class has responsibilities for various operations, and these classes are instantiated at run time to create objects. The network environment is made up of many individualistic entities that continually interact with each other.
86
The best approach to capturing the individualistic features of each entity, which is important for our model, is to use the object oriented paradigm. b)
Abstraction: in Object oriented programming like java Abstraction is a process of hiding the implementation details from the user, only the functionality will be provided to the user.
c)
Encapsulation: Encapsulation in Java is a mechanism of wrapping the data (variables) and code acting on the data (methods) together as single unit, variables of a class will be hidden from other classes, and can be accessed only through the methods of their current class, therefore it is also known as data hiding.
d)
Inheritance: is one of the features of Object-Oriented Programming. The idea of inheritance is simple but powerful: When you want to create a new class and there is already a class that includes some of the code that you want, you can derive your new class from the existing class. Java being an Object Oriented Language supports inheritance.
e)
Polymorphism: is the ability of an object to take on many forms. The most common use of polymorphism in OOP occurs when a parent class reference is used to refer to a child class object.
f)
Modularity: Modularity involves breaking a large system into separate physical entities that ultimately makes the system easier to understand. Employing modularity in the design of large software has advantages which include, scalable development, functionally Scalable, easier Modification & Maintenance, etc.
g)
GUI representation: One of the big advances that Java made when it was introduced in 1995 was the inclusion of standardized "graphical user interface" ("GUI") libraries. This makes interaction with or monitoring of the software performance easier. 87
h)
Multi-Tasking: Multitasking is a process of executing multiple tasks simultaneously. We use multitasking to utilize the CPU. Multitasking can be achieved by two ways: (i) Process-based Multitasking (Multiprocessing), (ii) Thread-based Multitasking (Multithreading). Multithreading is a process of executing multiple threads simultaneously. Thread is basically a lightweight sub-process; a smallest unit of processing. Java Multithreading is mostly used in games, animation etc. Multithreading played a vital role in the development of the LTE-simulator.
4.3.2 Encog for Machine Learning Encog is an advanced Artificial Intelligence Framework. Using Encog; you can create advanced neural network applications. Encog also supports other aspects of Artificial Intelligence programming. The Encog core, as at the time of writing, can be downloaded at: http://www.heatonresearch.com/encog/.
4.4
LTE SIMULATOR
The simulator was developed to ensure modularity, polymorphism, flexibility and performance. It was written in java using the object oriented paradigm as a graphical, eventdriven simulator. Aspects important to mobility load balancing in the LTE such as, propagation models, user mobility, multiple user request, handovers, etc., were adequately represented in the simulator. Since this research assumes intra-frequency deployment, only the E-UTRAN was represented, this is a network of interconnected eNodeBs or cells. The simulator was developed such that as many cells, user equipment (UE) and varying size of
88
physical resource blocks (PRBs) based on the frequency band can be used. The simulator software is made up of over 20 classes, grouped into five modules and over 2,700 lines of code. The simple class diagram of the network’s most important classes are shown Figure 21 and Figure 22 shows the simulator’s representation of the 6-cell network. The program is divided into 5 modules.
The Simulator
Elements
Command
Propagation.
Predictive.
Simulator: The simulator module can be seen as the director and representation of the entire LTE-simulator. It consists of classes that produce the graphical representation and general
properties
of
the
simulator,
for
example
the
NetworkPicture.java,
NetworkProperty.java etc. It also contains the scheduler; the work of the scheduler is to order the commands in terms of their priority; this sorts events in a chronological order, according to their timestamps. In the sense of it, it is a FIFO (first in first out). This helps to keep the simulator’s commands synchronized. Figure 23 shows the code excerpt from the NetworkPicture.java. Figure 24: shows code excerpt from the LTE Simulator scheduler
89
Figure 21: Simple Class Diagram of the Simulator.
90
Cell represented hexagonally
UEs represented by dots
eNodeBs represented by large dot at the center of the cell
Figure 22: LTE Simulator representation of the 6-celled Network; black oval dots represent eNodeBs.
91
Figure 23: Code excerpt from the Network Picture class.
92
Figure 24: Code excerpt from the LTE Simulator scheduler.
93
Elements: The element module is made up of classes that represent majorly, important individual entities, both physical and logical entities, which make up the LTE network in the LTE simulator. Some of the classes included in the simulator are briefly discussed below. (i) Element class: The Element class is an abstract class and a superclass for most of the element classes in the Element module. It encapsulates attributes like the name, id of the subclasses and also contains abstract methods such as the, start(), update() etc. Code excerpt in Figure 25. (ii) eNodeB class: The eNodeB class represents the evolved Node Base station of the LTE networks. It implements the Runnable class which allows for pseudo-independence and concurrent functionality of all eNodeBs on the simulated network. It encapsulates the cell description, and the functionalities of the base stations. It defines the initial default boundary of a cell which is a hexagonal shape. It handles Call Admissions, Handoff or Call Transfer, Data Requests from the UEs; it is also a parent to six sectors. Figure 26 shows code excerpt from the eNodeB class. (iii) Sector class: The sectors are divisions of the cell and the simulator divides the cell (eNodeB class) into six sectors. The sector class apart from representing the cell internal divisions, it also helps in user equipment (UE) generation and positioning on the network with the help of randomly generated radii and angles, UEs are placed in different sectors using the trigonometry paradigm of ACTS (All, Cosine, Tangent, Sine). Figure 27 shows code excerpt from the sector class. (iv) UE class: The UE class encapsulates the concept of the user equipment on the simulated
network. It implements the Runnable class which allows for independence and concurrency. The UE class calculates the path-loss which in turn helps the UE 94
Figure 25: Code excerpt from the Abstract Element class.
95
Figure 26: Code excerpt from the eNodeB class showing Call admission method.
96
Figure 27: Sector Code showing generateUsers() and generateUserPosition() methods.
97
(v) determine the number of PRBs it will need to get its request(s) satisfied. The movements of the UEs were not pushed into the LTE simulator scheduler. The UE class encapsulates the UERequest class. The UERequest class allows the UE to make service request to the eNodeB, the simulator allows for two types of request Data and Call request, both extends the ServiceRequest class, each with its Guarantied Bit Rate; this helps the UE to determine if its satisfied or not. Figure 28 to Figure 30 shows code excerpts from the UE class.
Command: This module is made up of three classes; the abstract class Command, ElementStartCommand and ElementUpdateCommand the last two extends the Command classs. The Command class and subclasses hold the definition and timestamp of most Elements’ commands going through the simulator’s Scheduler. Figure 31 shows the Command class.
Propagation: This module implements the wave propagation models. The wave propagation models implemented are Okumura-Hata and COST-231-Hata models in the OkumuraHataModel class and Cost231Hata Model class respectively. Both these classes extend the PRBEstimator abstract class also implemented in the propagation module. The propagation models implemented are all of the sub-urban area and open areas sub-models. Figure 32-34 shows code excerpt from the PRBEstimator abstract class, OkumuraHataModel class and Cost231HataModel class respectively.
98
Figure 28: UE code excerpt
99
Figure 29: Code excerpt showing the UE’s class getPRBEstimator() method
100
Figure 30: UERequest Class code excerpt.
101
Figure 31: The Command abstract class.
102
Figure 32: PRBEstimator abstract class; code excerpt
103
Figure 33: OkumuraHataModel class code excerpt.
104
Figure 34: Cost231HataModel class; code excerpt.
105
Predictive: This is not a separate module but because of its importance to the research, there is a need to mention its implementation. The Encog core, a machine learning framework for java was used to implement the neural network inside the eNodeB class. Figure 35 shows the neural network declaration in the eNodeB class.
4.5
SIMULATION AND PARAMETER CONFIGURATION
4.7.1 Simulation Due to system limitations the simulated network consists of 6 hexagonally shaped cells; each consisting of 6 Sectors, were modeled as independent entities and the users or user equipment (UE) were also modeled to be independent. The simulation scenario for the evaluation of the predictive model for MLB has 6 simulated cells or eNodeBs, with evenly distributed users (UE) amongst the sectors of each cell at the start of the simulation. The UEs were simulated in such a way that each user randomly moves around the network or decide to remain (i.e. not move). The UEs move by randomly picking a coordinate on the network with the help of its parent, eNodeB’s neighbors list and gradually moves towards the chosen coordinate. This is to help keep the UEs from straying from the entire network. Each UE can also make independent, random multiple service requests; i.e. each UE can receive more than one data service in line with the service multiplexing advances of the LTE. Due to the nature by which the UEs’ were designed to move the most visited eNodeB was the central eNodeB (i.e. Cell0). This makes Cell [0] the main focus of this research.
106
Figure 35: Initializing the neural network in eNodeB class.
107
4.8
SIMULATION SCENARIO
To appreciate the effect of load on a network, the simulation was done in two major steps i.e Step 1: Load the network initially with 72 users which is a total of 12 users per cell for our 6 cell LTE network. Then the network was simulated without any form of load balancing over a period of about 2 minutes. Then the traditional Load Balancing Scheme used by (Al-juboori and AL-Dahwi, 2013) with a probability estimation of the target cells available resources was simulated. And lastly our predictive model was simulated. Step 2: The network Load was increased to 108 users i.e. a total of 18 users per cell at the start of the simulation and the same procedure above was followed. 4.8.1 Parameter Configuration In a bid to make the effect of our simulation as close to the EUTRAN as possible, parameters that were germane to this goal needs to be modeled and/or configured. The basic physical parameters are shown in the table 2.
4.9
TRAINING PHASE
The neural network is trained for both effectiveness and efficiency. Training for effectiveness, ensures the neural network is trained such that there is minimal error between the actual output and target output this is achieved with the help of backward propagation algorithm. Training for efficiency, this is important because we are simulating a real-time environment; the meaning of this to our neural network is finding the simplest neural network architecture that reduces the processing time and yet does not completely compromise effectiveness or accuracy; this is achieved by pruning the network. 108
Table 2: LTE Simulation Parameter Configuration PARAMETER Cell Radius:
SIMULATED 500 meters
Carrier Frequency:
2 GHz
Bandwidth:
20 MHz
Subcarrier spacing:
15 kHz
Total PRB:
100
Bandwidth(PRB):
180 kHz
Propagation Model:
COST231-Hata Model (sub-urban)
DL Access Model:
OFDMA
Base Station antenna height:
250 meters
UE antenna height:
5 meters
Guarantee Bit Rate Service (GBR): Between 256 Kbps to 1024 Kbps Predictive Model:
Multi-Layer Perceptron Neural Network
Activation Function:
Sigmoidal Activation function
109
6.9.1 Data Source The Data for this research was collected during simulation: Where the research environment is a real-time, high-risk, not readily accessible system such as a mobile network, simulation is the best method used to determine if a solution is likely to work in that environment. The data generated for this research includes the following: (i)
Call Arrival rate: The number of calls that arrived within a specified time window
(ii)
Average Service time: The average service time of completed calls within the time window
(iii)
Call drop rate: the number of dropped calls within the specified time window
(iv)
Hand off rate: The number of calls transferred from a cell to another cell within the specified time window
(v)
Hand on rate: The number of calls transferred to a cell from neighboring cells.
(vi)
No of Free PRB (determines a cell’s state): This is our target output, the number of free PRBs or cell state at the start of a new time window.
6.9.2 The Propagation Algorithm Propagation algorithms help train the neural network by adjusting the connection weights of the neural network such that it minimizes the error between our estimated output and actual output. We previously proposed the Levenberge-Marquardt Algorithm as our training but we decided to experiment with some other propagation algorithms. We tried the following algorithms:
110
a) Back propagation Algorithm; b) Manhattan update rule; c) Levenberge-Marquardt Algorithm; and d) Resilient propagation. Both Resilient propagation and LevenbergeMarquardt Algorithm trained the neural network within the acceptable error limit. However, Resilient propagation trained the neural network with fewer iterations, hence the Resilient propagation was adopted for the learning process. Figure 36 shows the graphs of one of the training instances of the neural network in cell[0] and it shows that the neural network was able to mimic the actual trend of Cell[0]’s state transitions to an average accuracy of about 84.28%. 6.9.3 Pruning the Neural Network The goal of pruning is to find an optimal architecture for the neural network such that we optimize computational time without compromising much the efficiency of the neural network. This process is mostly done manually, however many programs have been developed to help neural network programmers evolve their neural network architecture. One of such programs is provided in Encog core API as claimed by its documentations is the NEAT (NeuroEvolution Augmented Topologies). The NEAT is a genetic algorithm program for evolving the structure and weights of the neural network; however as at the time of this research using NEAT was not fully understood so the manual procedure was employed. This is achieved by starting with an arbitrarily large number of neurons in the hidden layer(s) and iteratively reduce the number of neurons until there is a drop in accuracy and then the last iteration architecture is used; in our case we arbitrarily started with 10 neurons for the first hidden layer and 10 neurons for the second hidden layer and iteratively reduced the number of neurons in both hidden layer. The final structure consists of 4neurons in the first hidden layer and 3 neurons in the second layer. This is shown in Figure 37.
111
PRBs (%)
Time (s)
Figure 36: Cell[0]’s Neural Network Training Graph.
112
Figure 37: The Final Structure of the Neural Network.
113
4.10
EVALUATION PARAMETERS
The evaluation parameters employed in this research are the Unsatisfied Requests, Blocked Request, and Satisfied Request. These are explained below: Unsatisfied Request: This is measured in probabilistic terms or in percentage; It represents the ratio of users who have their service requests accepted but did not receive the required PRBs (data rate) to meet their requests minimum Constant Bit Rate (CBR/GBR) over the total number of request within a particular time frame.
𝑅𝑈0 =
̂𝑢 ∑𝑈𝑟=𝑈𝑛𝑠𝑎𝑡 𝑁 𝑁𝑡𝑜𝑡
(t)
(12)
Blocked Request: This represents the ratio of users’ service requests that were denied or blocked to the total number of requests made within a particular time frame. Blocked request occurs mostly as a result of non-availability of radio resources in a network. It is measured in terms of probability or percentage.
𝑅𝑈0 =
̂𝑢 ∑𝑈𝑟=𝐵𝑙𝑜𝑐𝑘𝑒𝑑 𝑁 𝑁𝑡𝑜𝑡
(t)
(13)
Satisfied Request: This represents the ratio of users’ service request that were not only accepted but also have their requests’ minimum CBR/GBR met or exceeded over a particular time frame. It is a probabilistic measurement or can be represented as a percentile.
𝑅𝑈0 =
̂𝑢 ∑𝑈𝑟=𝑆𝑎𝑡 𝑁 𝑁𝑡𝑜𝑡
(t)
(14)
114
4.11
RESULTS
As earlier stated, the simulation was done with the initial network population first without load balancing, then with traditional load balancing and lastly with the predictive load balancing. The observations are discussed below first for 72 users on the network, then for 108 users and then a comparison of both scenarios based on the total time interval duration of the simulation. Due to what was noticed with the increasing number of users, a third scenario was carried out with 144 users on the network.
4.11.1 Users on the Network (72 Users) In this scenario, each cell is initially randomly populated with 12 users or UEs. The UEs move randomly over time using a random walk mobility generation. Because cell[0] is the center cell it has a higher probability of been chosen as a destination (target) cell by the network users. The simulation was run for approximately 3 minutes, a minute each for the three scenarios (without load balancing, traditional load balancing, and predictive load balancing). The graph in Figure 38 shows the progressions of Unsatisfied Requests; in the early phase of the simulations, all the three load balancing scenarios could handle the cell load situation for the first 1 to 8 time frame. The without load balancing scheme started showing signs of un-satisfaction amongst its users the 9th time interval. However, both the traditional and predictive load balancing satisfied all the requests from its users within the simulation time. Figure 39 shows the graph of Blocked Requests, this graph shows greater activity as service requests from the Unsatisfied Request graph. We see that the cell without load balancing started declining request made to it from the 3rd time interval, which steadily increases as
115
120
Traditional LB Without LB Predictive LB
PRBs (% )
100
80
60
40
20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Time (s)
Figure 38: Graph of Unsatisfied Requests: Traditional LB (blue); Without LB (red); Predictive LB (green).
116
120
Traditional LB Without LB Predictive LB
PRBs (%)
100
80
60
40
20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Time (s)
Figure 39: Graph of Blocked Requests: Traditional LB (blue); Without LB (red); Predictive LB (green).
117
the cell didn’t have the logistics to deal with the load situation despite the fact that some of its neighboring cells may be less loaded and could serve its border UEs. At the 18th time interval the traditional load balancing scheme starts showing signs of rejecting service requests also the predictive load balancing started showing signs of rejecting service requests by the 20th time interval. Figure 40, shows the satisfied request, with the cell not implementing any load balancing it started showing signs of reduced satisfaction amongst its users in the 4th time interval and the cell was fully congested from the 13th time interval. The traditional load balancing scheme the cell maintained a good level of users’ satisfaction until the 19th. The predictive load balancing scheme maintained a good level of request satisfaction until the 20th time interval.
4.11.2 Users on the Network (108 Users) The users on the network was increased to 108 i.e. 18 active users per cell. The same movement method as the 72 users’ scenario was employed. Figure 41 shows the graph of Unsatisfied Requests, the without load balancing scheme started showing signs of disturbance at the 3rd time interval with three peaks at the 7th, 14th and 20th time intervals; with the traditional load balancing started showing signs of disturbances at the 7th time interval; the predictive model showed signs of disturbance at the 4th time interval earlier than the traditional which showed in the 7th time interval but was able to normalize from the 6th time interval to the 9th interval. Both the traditional and the predictive did not experience peaks in the unsatisfied requests graph during this period of simulation. 118
120
Traditional LB Without LB Predictive LB
PRBs (%)
100
80
60
40
20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Time (s)
Figure 40: Graph of Satisfied Requests: Traditional LB (blue); Without LB (red); Predictive LB (green).
119
120
Traditional LB Without LB
Predictive LB
PRBs (%)
100
80
60
40
20
0
Time (s) 1
2
3
4
5
6
7
8
9 10 11 12 13 14 15 16 17 18 19 20
Figure 41: Graph of Unsatisfied Requests; Traditional LB (blue); Without LB (red); Predictive LB (green).
120
Figure 42 shows the graph of blocked requests in the “108 user on network” scenario, the without load balancing scheme started showing signs blocking request right from the 1st time interval; the traditional load balancing scheme started showing signs of blocking request at the 2nd time interval and the predictive load balancing scheme also started showing signs at the 2nd time interval. Figure 43 shows the graph of the satisfied requests in the “108 user on network” scenario, the without load balancing scheme showed a near steady decline in the percentage of satisfied requests from the 1st time interval to the 4th time interval and failed or became congested from the 7th time interval; the traditional load balancing scheme started showing reduction in its clients satisfaction at the 2nd time interval and failed at the 11th time interval; the predictive load balancing also started showing reduction in clients satisfaction from the 2nd time interval but finally failed or became congested at the 16th time interval. 4.11.3 Comparing 72, 108 and 144 Users Scenarios In this section we would look at the summary THE load balancing (LB) scenarios in terms of percentage average of the evaluation parameters i.e. Unsatisfied Request (UR), Blocked Request (BR) and Satisfied Request (SR). Table 3 - 5 shows these summaries. The predictive load balancing scheme, on the average during simulation, showed a lower percentage of unsatisfied requests: Table 3; 0.00% for 72 users, 5.21% for 108 users and 7.30% for 144 users of total request made to it. The traditional load balancing scheme gave an average of 0.00% for 72 users 8.08% for 108 users and 8.55% for 144 users. The, “without load balancing” scheme showed an average of 11.23%, 20.79% and 14.94% for 72 users 108 users and 144 users respectively. Table 4 showed the average percentile for blocked requests; the without load balancing scheme’s average of 43.48%, 57.79% and 121
120 Traditional LB Without LB
PRBs (%)
100
Predictive LB
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Time (s)
Figure 42: Graph of blocked request, Traditional LB (blue); Without LB (red); Predictive LB (green).
122
120 Traditional LB
PRBs (%)
Without LB 100
Predictive LB
80
60
40
20
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Time (s)
Figure 43: Graph of Satisfied Requests: Traditional LB (blue); Without LB (red); Predictive LB (green).
123
Table 3: The average percentile for Unsatisfied Requests. No of Users on Network
Traditional LB %
Without LB %
Predictive LB %
72
0.00
11.23
0.00
108
8.08
20.79
5.21
144
8.55
14.94
7.30
124
Table 4: The average percentile for Blocked Requests. No of Users on Network
Traditional LB
Without LB
Predictive LB
72
2.59
43.48
2.17
108
62.07
57.79
58.33
144
63.02
65.96
62.99
125
65.96% for 72 users, 108 and 144 users respectively; the traditional load balancing scheme’s 2.59%, 62.07% and 63.02% for 72 users, 108 users and 144 users respectively; the predictive load balancing scheme showed slight improvement in lowering the block request rates with an average of 2.17%, 58.33% and 62.99% for 72, 108 and 144 users respectively. Table 5 showed the average percentile for satisfied requests; the “without load balancing” scheme had an average of 36.59%, 11.42% and 19.10% for 72, 104 and 144 users respectively; the traditional load balancing scheme showed a slight improvement with an average of 97.41%, 29.84% and 29.42% for 72, 108, and 144 users respectively; the predictive load balancing scheme’s 97.83%, 31.46% and 29.71% for 72, 108, and 144 users respectively. Finally, Figures 44 to 46 showed a summary bar chart of the tables above. It shows the predictive load balancing scheme has slight advantages over the traditional load balancing scheme in terms of performance. It can be concluded that by giving an eNodeB the ability to anticipate its own state, through prediction, and make decisions based on these anticipations. The predictive scheme if further looked into and fine-tuned can help the LTE’s load balancing scheme by cushioning the effect of delay in load information transfer.
126
Table 5: The average percentile for Satisfied Requests. No of Users on Network
Traditional LB
Without LB
Predictive LB
72
97.41
36.59
97.83
108
29.84
11.42
31.46
144
29.42
19.10
29.71
127
25 72 Users 108 Users 144 Users
PRBs (%)
20
15
10
5
0 Traditional LB (UR)
Without LB (UR)
Predictive LB (UR)
Figure 44: Unsatisfied Request Bar Chart showing the three load balancing schemes for 72, 108 and 144 Users.
128
70
PRBs (%)
60
50
40 72 Users 108 Users 30
144 Users
20
10
0 Traditional LB (BR)
Without LB (BR)
Predictive LB (BR)
Figure 45: Blocked Request Bar Chart showing the three load balancing schemes for 72, 108 and 144 Users.
129
120
PRBs (%)
100
80
72 Users 60
108 Users 144 Users
40
20
0 Traditional LB (SR)
Without LB (SR)
Predictive LB (SR)
Figure 46: Satisfied Request Bar Charts showing the three load balancing schemes for 72, 108 and 144 Users.
130
CHAPTER FIVE 5.0 5.1
SUMMARY, CONCLUSION AND RECOMMENDATION SUMMARY
This research work addresses the problem related to load balancing in the Long Term Evolution networks. In this study a new load balancing scheme was proposed to counter the effect of delay in load information transfer during the load balancing procedure, this is achieved by embedding intelligence into the eNodeBs such that load balancing is performed based on the eNodeBs anticipated State. The multilayer perceptron neural network provides this anticipation through prediction. With proper configuration the output (predicted state) trend of multilayer perceptron neural network was able to fairly mimic the trend of the actual state; this means the multilayer perceptron neural network was able to predict its future state fairly accurately. Load balancing in a non-linear, dynamic, and stochastic environment like the mobile communication network environment, is a highly delicate affair. This means delay in the load information transfer may convey a wrong or an outdated information on the neighboring cells load situation. The major contribution of this research is to counter the challenge, faced by load balancing, of delay in load information transfer. This was achieved by embedding intelligence to each base station. Such that they can anticipate their load state. This anticipation was achieved with the help of the Multilayer Perceptron neural network through prediction and load balancing is performed based on the base stations anticipated state.
131
5.2
CONCLUSION
The new predictive approach to mobility load balancing scheme introduced by this research proved to be effective when compared with the traditional load balancing scheme. From the results generated and evaluations during the simulation, it can be concluded that the application of the predictive model to mobility load balancing is a promising approach that requires further researching into, in order to maximize its potential.
5.3
RECOMMENDATION
In the course of this research several areas of future research were identified some of these areas are discussed. First, this research premise was around predicting the state (load situation) of a cell (eNodeB). The future consideration in this regard is the possibility of predicting the actual number of available resources (PRBs), this we believe can further enhance the robustness of the predictive approach to mobility load balancing. Second, due to the conflicting goals of the multiple schemes under the self-optimization operations of the self-organizing networks (SON), many researches are currently on going in the area of joint optimization of multiple self-optimization schemes in order to make the most optimal decision in the face of conflicting interests of individual self-optimization schemes. The future consideration is in jointly optimizing the predictive load balancing scheme and some of the other self-optimization schemes
132
REFERENCES 3GPP, 2011. E-UTRAN; Overall description; Stage 2 (Release 9), 3rd Generation Partnership Project (3GPP). 3GPP, 2010. LTE: Evolved Universal Terrestrial Radio Access (E-UTRA): Radio Link Control (RLC) protocol specification (Release 9), European Telecommunications Standards Institute, pp. 7-8. 3GPP, 2009. 3GPP LTE Packet Data Convergence: Protocol (PDCP) Sub Layer. URL www.eventHelix.com/lte/presentation/ 3GPP-LTE-PDCP, pdf Inc. (accessed June 2015). Agrawal, D.P. and Zeng, Q.-A., 2011. Introduction to Wireless and Mobile Systems, 3rd ed. Cengage Learning, 200 First Stamford Place, Suite 400 Stamford, CT 06902 USA, pp. 3-11 Al-juboori, F.A. and AL-Dahwi, N.S., 2013. Load Balancing Algorithm based Adaptive Handovers and Target Cell Load Estimation. International Journal of Computer Application 84(17), pp. 22–25. Atayero, A.A. and Luka, M.K., 2012. Adaptive Neuro-Fuzzy Inference System for Dynamic Load Balancing in 3GPP LTE. International Journal of Advanced Research in Artificial Intelligence 1(1), pp. 11–16. Dahlman, E., Parkvill, S. and Skold, J., 2011. LTE / LTEAdvanced for Mobile Broadband. Academic Press, pp. 5, 11-13. Dickey, D.A., 2012. Introduction to predictive modeling with examples. Raleigh, N. Carolina State University., North Carolina, United State. SAS Global Forum, paper ID 337 pp. 1-14. Feng, S. and Seidel, E., 2008. Self-organizing networks (SON) in 3GPP long term evolution. Nomor Research GmbH, Munich, Germany, White Paper, pp. 1-15. Gao, Q. and Li, G. X., 2011. A Traffic Prediction Method based on ANN and Adaptive Template Matching. Przegląd Elektrotechniczny, paper ID: PE2257.
133
Hamalainen, S., Sanneck, H. and Cinzia, S., 2012. LTE Self-Organising Networks (SON) Network Management Automation for Operational Efficiency, John Wiley & SONs, Ltd , 1st ed. pp. 360-400. Haykin, S., 2001. Neural Networks, A Comprehensive Foundation, Pearson Education Ltd, 3rd ed. pp. 153-220. Heaton, J., 2008. Introduction to Neural Networks for Java, Heaton Research, Inc.. 2nd ed. pp. 119-131. Holma, H. and Toskala, A., 2011. LTE for UMTS: Evolution to LTE-advanced, John Wiley & SONs, Ltd, 2nd ed. pp. 130-150. Hu, H., Zhang, J., Zheng, X., Yang Y. and Wu, P., 2010. Self-configuration and selfoptimization for LTE networks. Communications Magazine, IEEE 48(2), pp. 94-100. Javed, U., Han, D., Caceres, R., Pang, J., Seshan, S. and Varshavsky, A., 2011. Predicting handoffs in 3G networks. In Proceedings of the 3rd ACM SIGOPS Operating Systems Workshop on Networking, Systems, and Applications on Mobile Handhelds, pp. 65–70. Kamimura, 2015. Int’l Standardization Trend of Next Generation PHS. WillCom, Inc. URL http://www.phsmou.org/newsletter/issue68/p1.php (accessed May 2015). Kwan, R., Arnott, R., Paterson, R., Trivisonno, R. and Kubota, M., 2010. On mobility load balancing for LTE systems, in: 2010 IEEE 72nd Vehicular Technology Conference-Fall, Ottawa. pp. 1–5. Lescuyer, P. and Lucidarme, T., 2008. Front Matter, in Evolved Packet System (EPS): The LTE and SAE Evolution of 3G UMTS, John Wiley & SONs, Ltd, 1st ed.. Lobinger, A., Stefanski, S., Jansen, T. and Balan, I., 2010. Load balancing in downlink LTE self-optimizing networks, 73rd IEEE In Vehicular Technology Conference. pp. 1–5. Lv, W., Li, W., Zhang, H. and Liu, Y., 2010. Distributed mobility load balancing with RRM in LTE, in: In Broadband Network and Multimedia Technology (IC-BNMT), 2010 3rd IEEE International Conference. pp. 457–461. 134
Macharia, B.M., Waititu, A.G. and Wanjoya, A.K., 2013. Application Of Kalman Filter To Artificial Neural Networks Prediction For Foreign Exchange Rates. International Institute for Science, Technology and Education 3(14), pp. 24–34. Meetei, K.P. and George, A., 2011. Handoff management in wireless networks using predictive modelling, in: In Communications (NCC), National Conference. pp. 1–5. Meetei, K.P., Kadambi, G.R., Shobha, B.N. and George, A., 2009. Design and Development of a Handoff Management System in LTE Networks using Predictive Modelling. SASTECH Journal 8: pp. 71–78. Mughele, E.S., Olatokun, W. and Adegbola, T., 2012. Congestion Control Mechanisms and Patterns of Call Distribution in GSM Telecommunication Network: The Case of MTN Nigeria. , African Journal of Computing and ICT 5(1), pp. 29–42. Nadir, Z., Elfadhil, N. and Touati, F., 2008. Pathloss Determination Using Okumura-Hata Model And Spline Interpolation For Missing Data For Oman, In Proceedings of the World Congress on Engineering. pp. 2–4. Nkordeh, N.S., Atayero, A.A.A., Idachaba, F.E. and Oni, O.O., 2014. LTE network planning using the Hata-Okumura and the COST-231 Hata pathloss models. Lecture Notes in Engineering and Computer Science, URL: http://eprints.covenantuniversity.edu.ng/ (accessed June 2015) Ogwueleka, F.N., Misra, S., Ogwueleka, T.C. and Fernandez-Sanz, L., 2014. An artificial neural network model for road accident prediction: a case study of a developing country. Acta Polytechnica Hungarica 11(5), pp. 177–197. Palat, S. and Godin, P., 2009. The LTE Network Architecture, a comprehensive tutorial. URL: www.cse.unt.edu/~rdantu/FALL_2013_WIRELESS_NETWORKS/LTE_Alcatel_ White Paper.pdf. (accessed May 2015). Piro, G., Grieco, L.A., Boggia, G., Capozzi, F. and Camarda, P., 2010. Simulating LTE cellular systems: an open-source framework, In: Vehicular Technology, IEEE Transactions. 60(2) pp. 498–513. 135
Raheem, M.A. and Okereke, O.U., 2014. A Neural Network Approach to GSM Traffic Congestion Prediction. American Journal of Engineering Research (AJER) 3(11), pp. 131– 138. Sauter, M., 2010. From GSM to LTE: An Introduction to Mobile Networks and Mobile Broadband., John Wiley & SONs, Ltd, 1st ed.. Sheskin, D.J., 2012. Handbook of parametric and nonparametric statistical procedures, crc Press, United Kingdom. 4th ed. Singh, Y., 2012. Comparison of Okumura, Hata and COST-231 Models on the Basis of Path Loss and Signal Strength. International Journal of Computer Applications 59(11). Stefania, S., Issam, T. and Matthew, B., 2009. LTE-the UMTS long term evolution: From theory to practice. John Wiley and Sons Ltd, pp. 136-144 Suria, S.N., 2012. SON / RRM Functionality for Mobility Load Balancing in LTE Networks (Masters Dissertation). Department of Telecommunications Engineering, Universidad Politecnica de Valencia, Spain. Yang, Q.P., Kim, J.W. and Kim, T., 2012. Mobility Prediction and Load Balancing Based Adaptive Handovers for LTE Systems. International Journal on Computer Science and Engineering 4(4), pp. 665–674. Zarrinkoub, H., 2014. Understanding LTE with MATLAB: From Mathematical Modeling to Simulation and Prototyping. John Wiley & Sons Ltd, pp. 15-17. Zhang, L., Liu, Y., Zhang, M., Jia, S., and Duan, X., 2011. A two-layer mobility load balancing in LTE self-organization networks. IEEE International Conference on Communication Technology Proceedings, ICCT 2011, pp. 437–444.
136
APPENDIX (CODES) /** * Code Excerpt from LTE Simulator V1 * @author Awoseyi Ayomikun Abayomi (PG 13/0038) */ package lte.simulator.v1; import java.util.LinkedList; import java.util.List; public class NetworkProperty { public static final int DEFAULT_RADIUS = 500; public static final int NUMBER_OF_CELLS = 6; public static final int NoSECTORS = 6; public static final int NUMBER_OF_USERS_SECTOR = 3; public static final int MAX_No_PRB = 100; public static final int DEFAULT_BANDWIDTH = 50; public static final int BW = 180; //KHz public static final int MINIMAL_DISTANCE = 35; public static final double defaultBorder = DEFAULT_RADIUS((DEFAULT_RADIUS*0.1)); public static final int SIMULATION_DURATION = 1000; public static final String training_data_path = ""; public static List InputTrainingData = new LinkedList(); public static List OutputTrainingData = new LinkedList(); public static final int NO_OF_ANN_INPUT = 5; public static final int NO_OF_ANN_OUTPUT = 1; public static final double base_station_height=250; public static final double mobile_station_height=5; public static final double Frequency=2; 137
public static final double base_station_power=10000; public static final PropagationModel ACTIVE_PROPAGATIONMODEL = PropagationModel.COST231; public static final double dormancy_period=1000; public enum PropagationModel { OKUMURAHATA, COST231 } }
package lte.simulator.v1; import lte.simulator.v1.ELEMENTS.Element; import lte.simulator.v1.COMMANDS.Command; import java.io.IOException; import java.util.Calendar; import java.util.Date; import java.util.Enumeration; import java.util.Vector; import java.util.PriorityQueue; public class LTESimulatorV1 implements Runnable { /** * @param args the command line arguments */ private static LTESimulatorV1 instance = null; public static Date simulationStartTime; //public static int counter; private double m_time; public static Date simulationEndTime; private static boolean finished;
// Flag to finish the run() loop 138
// Queue of Command objects private PriorityQueue commands; private Vector elements; private long time_count=0; public static void main(String[] args) { } public LTESimulatorV1(){ elements = new Vector(); commands = new PriorityQueue(); m_time = 0; finished = false; } public void schedule(Command command) { synchronized(commands) { commands.add(command); commands.notifyAll(); } } public void run() { simulationStartTime=Calendar.getInstance().getTime(); while(commands.size() > 0 || !finished) {
139
//Needs to do a busy wait untill there is a command... Command current_command = null; synchronized(commands) { try { while(commands.size() == 0) { System.out.println("waiting......................................................."); commands.wait(); } } catch(InterruptedException e) { e.printStackTrace(); }
current_command = (Command) commands.peek(); commands.poll(); } current_command.dump(); m_time = current_command.getTime(); System.out.println("execute......................................................"+commands.size()); System.out.println("c_name:"+current_command.c_name+"c_time:"+current_command.c _time); HandleCommand hc = new HandleCommand(current_command); Thread thc = new Thread(hc); 140
thc.start(); System.out.println("done c_name:"+current_command.c_name+"c_time:"+current_command.c_time+" .."+commands.size());
} simulationEndTime= Calendar.getInstance().getTime(); System.out.println("simulation finished......................................."+commands.size()); System.exit(0); } public static void error(String message) { System.err.println("*LTE ERROR* " + message); System.exit(1); } public static boolean hasFinished() { return finished; } public double getTimeX() { return m_time; } public double getTimeCount(){ return time_count--; } public static double getCurrentTimeLag(){ return Calendar.getInstance().getTime().getTime()-simulationStartTime.getTime(); 141
} public static void warning(String message) { System.err.println("*LTE WARNING* " + message); } public static LTESimulatorV1 getInstance() { if(instance == null) instance = new LTESimulatorV1(); return instance; } /** @param element the element to add */ public void attach(Element element) { Enumeration e = elements.elements(); elements.addElement(element); } } class HandleCommand implements Runnable{ Command c; HandleCommand(Command c){ this.c=c; } public void run(){ c.execute(); 142
} }
package lte.simulator.v1; import lte.simulator.v1.ELEMENTS.Sector; import lte.simulator.v1.ELEMENTS.eNodeB; import lte.simulator.v1.ELEMENTS.UE; import lte.simulator.v1.ELEMENTS.Network; import java.awt.Color; import java.awt.Graphics; import java.awt.geom.Point2D; import java.util.List; import javax.swing.JPanel; public class NetworkPicture extends JPanel { private boolean entireNetwork=true; //flag for drawing the network private static final long serialVersionUID = 1L; public static int networkRadius; private final int DEFAULT_RADIUS=NetworkProperty.DEFAULT_RADIUS; public NetworkPicture(){ drawPicture(); } @Override public void paintComponent(Graphics g){ super.paintComponent(g); int maxHeight=getHeight(); int maxWidth=getWidth(); int pixelRadius; 143
int radUser; int rad; if(entireNetwork){ if(!((double)maxWidth/(8)>(double)maxHeight/(5*Math.sqrt(3)))){ pixelRadius=(int)((double)maxWidth/(8)); } else { pixelRadius=(int)((double)maxHeight/(5*Math.sqrt(3))); } radUser=2; } else { if(!((double)maxWidth/(2)>(double)maxHeight/(Math.sqrt(3)))){ pixelRadius=(int)((double)maxWidth/(2)); } else { pixelRadius=(int)((double)maxHeight/(Math.sqrt(3))); } radUser=6; } pixelRadius-=5; rad=((int)(NetworkProperty.MINIMAL_DISTANCE*pixelRadius/DEFAULT_R ADIUS)); if(rad
