Project topics and materials
Get Complete Project Material File(s) Now! »
UE mobility
In our simulator UEs pop up randomly in the network according to Space Poisson Point Processes (SPPPs) [58]. They may have dierent speeds and movement directions. Their location is updated every every millisecond, i.e. every LTE sub-frame. We consider an File Transfer Protocol (FTP)-like trac, i.e. each UE which arrives in the network aims to download a le (of xed size FS [MBits/UE]). When a UE arrives in the network and wants to download its le, it rst has to attach to a cell. Let RxPow n be the received signal power of UE from cell n (layer 3 ltered, see Annex 1.1 for details). Normally it should choose the one which has the best channel conditions.
At a given time instance, if UE wants to download data it rst goes through the Connection Establishment procedure (Fig. 2.2) in order to attach to a network cell. Specically, it attaches to cell iCell (the time index is omitted): iCell = argmaxn (RxPow n + CIOn) (2.1)
where CIOn is the Cell Individual Oset (CIO) of cell n [5]. If the Connection Establishment is successful then the UE goes into the Receive Data procedure, otherwise the UE is dropped. If the serving cell no longer oers good (or the best) radio channel condition then the UE searches for a new target cell which oers better (or the best) channel conditions. This procedure is called Connection ReConguration or HandOver (HO). To be precise a UE attached to cell sCell starts a Time To Trigger (TTT) countdown for a HO to a target cell tCell6=sCell if: tCell = argmaxn RxPow n + CIOn + HY SsCellIfn=sCellg (2.2) where HY SsCell is the HO Hysteresis (HYS) of sCell [5] . During its data download and even during a HO procedure a UE may loose connection with its serving cell. We call this a Radio Link Failure (RLF). If such an event occurs then the UE goes into the Connection ReEstablishment procedure where the UE attempts to connect to a cell using similar steps as in the Connection Establishment. If the RLF occurs while in the Connection ReEstablishment procedure then the UE is dropped.
Almost Blank Sub-frames
In order to reduce the interference towards the neighbouring cells some cells might be forbidden to transmit at certain time instances. To better understand this we present in Fig. 2.4 the structure of an LTE downlink frame. Thus, a frame has a length of 10 ms. It is composed of 10 sub-frames of 1 ms each. In our simulator, the resources of each sub-frame are allocated to only one user. We assume that all the cells are synchronized on a frame basis. A sub-frame where no user data is transmitted is called an Almost Blank Sub-frame (ABS). The ABS helps reduce the interference towards neighbouring cells. The technique is used typically in heterogeneous networks where sometimes the range of the Pico (or other small) cells is extended and in order to protect the UEs at the cell edge which we forced to attach to the Pico cells we can employ such ABSs on the Macro cells. For details see Appendix 1.3.
SON Coordination SON Coordination in 3GPP
To deal with potential SON conicts Release 10 of 3GPP has introduced the SONCO function [3], [4]. According to [4], the tasks of a SONCO include:
to Avoid as much as possible having conicts (SONCO-A),
to Detect and to Diagnose the conicts (SONCO-D),
to provide conict Resolution mechanisms when needed (SONCO-R). The SONCO-A must properly choose the settings of the SON functions such that the conicts are reduced to a minimum and the network still achieves its target performance. The SONCO-D has to be able to identify what are the potential conicts and which of them are active conicts, i.e. they eectively degrade the network performance. One consequent actions might be to change the settings of the SON functions in order to prevent the conict from occurring in the future (via the SONCO-A), i.e. make the conict in-active. Another consequent action could be to employ a resolution mechanism (SONCO-R) which does not eliminate the conict but instead, at the moment when the conict occurs, it shall take the decision to favour one SON function or another based on predened criteria. Thus, every update request must go through the SONCO-R (see Fig 2.9). Based on the conict types the tasks of the SONCO-R are:
measurement conict resolution: the aim is to improve network stability by reducing the number of unnecessary parameter changes (those which are undone shortly after) caused by the dependence between the parameter tuned by one SON instance and the input of another.
parameter conict resolution: the aim is to nd a judicious way to decide which of update requests to accept and which to deny when facing opposite requests from dierent SON instances targeting the same parameter We dene, a SONCO-A/D/R instance to be a realization of a SONCO-A/D/R function (or of one of its components).
Table of contents :
Acknowledgements
Synthèse en français
Abstract
Nomenclature
List of Figures
List of Tables
1 Introduction
1.1 Context
1.2 Motivation
1.3 Scope and methodology
1.4 Contributions and structure of the thesis
1.5 Publications
2 LTE-A and SON modelling
2.1 LTE-A introduction
2.1.1 UE mobility
2.1.2 Almost Blank Sub-frames
2.2 Introduction to Self Organizing Networks
2.2.1 SON Coordination
2.2.2 SEMAFOUR project
2.3 Simulator snapshot
3 SON Conict Diagnosis
3.1 State of the Art
3.2 System description
3.3 SON conict diagnosis
3.3.1 Symptoms
3.3.2 Causes
3.4 Diagnosis based on the Naive Bayes Classier
3.5 Simulation results
3.6 Logical framework architecture
3.7 Concluding remarks
4 SON Conict Resolution
4.1 State of the Art
4.2 System Description
4.3 SON conict resolution
4.3.1 Markov Decision Process
4.3.2 Value functions
Telecom ParisTech – Orange Labs
4.3.3 Action-value function simplication
4.3.4 Linear Function Approximation
4.4 Reinforcement learning
4.4.1 Algorithm
4.4.2 Multi-dimension regret
4.4.3 Complexity analysis
4.5 Application Scenarios
4.5.1 Scalar regret: measurement conict resolution
4.5.2 Scalar regret: parameter conict resolution
4.5.3 Vector regret: parameter conict resolution
4.6 Logical framework architecture
4.7 Concluding remarks
5 Mobility parameters
5.1 Problem description
5.1.1 HandOver test: two cells
5.1.2 Generalization
5.1.3 Problematic HO parameter congurations
5.2 Preliminaries
5.3 Main results
5.4 Numerical results.
5.4.1 Problematic network congurations
5.4.2 CCH area quantication
5.4.3 Simulation results
5.5 Concluding remarks
6 Conclusions and future work
A Simulator details
1.1 Channel Model
1.2 UE procedures
1.3 Almost Blank Sub-frames
B SON functions for Macro Network scenarios
2.1 MLB for a Macro Network
2.2 MRO for a Macro Network
C SON functions for HetNet scenarios
3.1 (MLB via) CRE for a HetNet
3.2 MRO for a HetNet
3.3 eICIC for a HetNet
D Reinforcement Learning
4.1 Proof of Theorem 4.1
4.2 Proof of proposition 4.1
E Mobility Parameters
5.1 Proof of Lemma 5.2
5.2 Proof of Lemma 5.3
5.3 Proof of Theorem 5.1
5.4 Proof of Theorem 5.2
Bibliography
