Abstract
Self-Organizing Networks (SON) is a collection of functions for automatic configuration, optimization, diagnostisation and healing of cellular networks. It is considered to be a necessity in future mobile networks and operations due to the increased cost pressure. The main drivers are essentially to reduce CAPEX and OPEX, which would otherwise increase dramatically due to increased number of network parameters that has to be monitored and set, the rapidly increasing numbers of base stations in the network and parallel operation of 2G, 3G and Evolved Packet Core (EPC) infrastructures. This paper presents evaluations on the use of some of the most important SON components. Mobile networks are getting more complex to configure, optimize and maintain. Many SON functions will give cost savings and performance benefits from the very beginning of a network deployment and these should be prioritized now. But even if many functions are already available and can give large benefits, the field is still in its infancy and more advanced functions are either not yet implemented or have immature implementations. It is therefore necessary to have a strategy for how and when different SON functions should be introduced in mobile networks.
1. Introduction
Briefly, SON is a collection of procedures (or functions) for automatic configuration, optimization, diagnostication, and healing of cellular networks. It is considered to be a major necessity in future mobile networks and operations mainly due to possible savings in capital expenditure (CAPEX) and operational expenditure (OPEX) by introducing SON. The SON family consists of a variety of functions that in nature are very different and which maturity are at different levels. As the number of SON functions will increase with each new vendor releases, one of the main issues for operators will be to determine which functions to introduce and also determine the appropriate timing for activating these functions to obtain a well-behaving and cost-efficient network.
This paper considers SON for the 3GPP family of technologies, but similar functionality is also included in WiMAX [1].
The GSM/3GPP family of technologies consists of GSM, UMTS, and LTE. GSM (global system for mobile communications) is a 2nd generation (2G) mobile technology and provides a digital, circuit switched network optimized for full duplex voice telephony. Circuit switched and packet switched data transport is also supported. UMTS (universal mobile telecommunications system) is a 3rd generation (3G) mobile technology based on wideband code division multiple access (W-CDMA) radio technology with better spectrum efficiency and capacity than GSM. It supports data transfer rates through its enhancement HSPA (high speed packet access). HSPA accounts for the majority of worldwide broadband networks today. LTE (long time evolution) is the latest technology in the family. It is based on orthogonal frequency division multiple access (OFDMA) radio technology offering higher capacities and lower latencies than UMTS. Its network architecture is simpler and based on IP technology. LTE-Advanced, which is an enhancement of LTE, was approved by ITU as one of two 4G technologies (the other being WiMAX 2) in January this year [2].
Although SON is also defined in other contexts like WiMAX, the main drive in the SON development and standardisation up to now comes from 3GPP, primarily for LTE, but also extended towards 2G and 3G networks in later releases. These features are currently not available between 3GPP access technologies and other access technologies like Wi-Fi. This paper will therefore focus on 3GPP SON solutions since this will be in line with the main interest for mobile operators.
The main drivers for introducing SON are to reduce CAPEX and OPEX, which would otherwise increase dramatically. There are three main reasons for this. The first is that the number of parameters that must be set in the network elements has increased significantly from each technology generation to the next. UMTS has a significantly higher number of parameters than GSM, and LTE has even more. Hence, it is not practical to set and maintain these manually. The second reason is that the quick evolution of wireless networks has led to operators having parallel operation of 2G, 3G, and LTE infrastructures, and even also networks using non-3GPP technologies like Wi-Fi. Operators need to coordinate the operations of their network to utilize their network resources as efficiently as possible. This requires inter-RAT (radio access technology) SON functionality. The third reason is that an increasing part of the traffic will be on small cells such as microcells, picocells, and femtocells. Densifying the networks will be necessary to meet the ever increasing demand for capacity since the amount of spectrum available for mobile services is limited. Hence, networks will consist of cells with very variable size from several kilometres for macrocells down to some few tens of meters for femtocells. Such networks of cells with widely varying cell sizes, and possibly also different radio technologies, are denoted HetNets (feterogeneous networks). Compared to the networks today, which mainly consist of macrocells, the number of network elements will increase dramatically with the development towards HetNets. Configuring and optimizing the parameters in all these network elements represent a complexity that just cannot be handled the same way they have been, and new automatic solutions are clearly needed.
To be more specific, the main benefits of introducing SON functions in cellular networks are as follows.(i)Reduced installation time and costs.(ii)Reduced OPEX due to reductions in manual efforts in connection with monitoring, optimizing, diagnosing, and healing of the network.(iii)Reduced CAPEX due to more optimized use of network elements and spectrum.(iv)Improved user experience.(v)Improved network performance.
In the literature, there exist a rather vast collection of papers (and white papers) on the SON subject ranging from overview papers to contributions on more specific topics like performance analysis of various SON functions. The IST project SOCRATES [3] has given several contributions to the understanding and development of SON. Among overview papers are [4–6]. In addition several papers on specific topics, for example, load balancing [7] and cell outage management [8], have been written in the project. Also 4G Americas and next generation mobile networks (NGMN) have provided reports, for example, [9, 10] where the most basic use cases of SON are discussed. Other overview papers on SON in LTE are found in [6, 11], where future challenges are discussed.
This paper identifies and discusses some of the main issues that operators have to consider when introducing SON in cellular networks. In particular, the maturity of the most important SON functions and possible timing for their introduction in live networks is discussed. In Section 2, the architecture options for SON is discussed, while Section 3 is devoted to discuss individual SON components. Then finally, some conclusions are given in Section 4.
2. SON Architecture
There are three main alternatives regarding the architecture of SON functions in cellular networks as illustrated in Figure 1. These are denoted centralized, distributed, and hybrid architectures [12]. Different SON functions can be implemented by different architectures in the same network. In this chapter, we briefly describe the three different architecture options and discuss pros and cons of the different types.
2.1. Centralized SON Architecture
In a centralized SON architecture, the algorithms are executed at the network management level. Commands, requests and parameter settings data flow from the network management level to the network elements, while measurement data and reports flow in the opposite direction. The main benefit of this approach is that the SON algorithms can take information from all parts of the network into consideration. This means that it is possible to jointly optimize parameters of all centralized SON functions such that the network becomes more globally optimized, at least for slowly varying network characteristics. Also, centralized solutions can be more robust against network instabilities caused by the simultaneous operation of SON functions having conflicting goals. Since the control of all SON functions is done centrally, they can easily be coordinated.
Another advantage is that multivendor and third party SON solutions are possible, since functionality can be added at the network management level and not in the network elements where vendor specific solutions are usually required.
The main drawbacks of the centralized SON architecture are longer response times, increased backbone traffic, and that it represents a single point of failure. The longer response time limits how fast the network can adapt to changes and can even cause network instabilities. The backbone traffic increase since measurement data have to be sent from the network elements to the network management system and instructions must be sent in the opposite direction. This traffic will increase as more cells are added to the network. If there are many pico- and femto-cells this traffic will be very significant. Also, the centralized processing power needed will be large.
2.2. Distributed SON Architecture
In a distributed SON architecture, the SON algorithms are run in the network nodes and the nodes exchange SON related messages directly with each other. This architecture can make the SON functions much more dynamic than centralized SON solutions, so that the network can adapt to changes much more quickly. It is also a solution that scales very well as the number of cells in the network increases.
The main drawbacks are that the sum of all the optimizations done at cell level do not necessarily result in optimum operation for the network as a whole and that it is more difficult to ensure that network instabilities do not occur.
Another drawback is that the implementation of the SON algorithm in the network elements will be vendor specific, so third party solutions will be difficult.
Even if the algorithms themselves are executed in the network elements, the network management system is usually able to control the behaviour of the SON function, for example, by setting the optimization criteria, receiving periodic reports, and being able to turn it off if necessary.
2.3. Hybrid SON Architecture
Hybrid SON solution means that part of the SON algorithm is run on the network management level and part is run in the network elements. The solution represents an attempt to combine the advantages of centralized and distributed SON solutions: centralized coordination of SON functions and the ability to respond quickly to changes at the network element level.
Unfortunately, the drawbacks of both centralized and distributed SON are also inherited. The SON related traffic in the backbone will be proportional to the number of network elements in the network, which means that it might not scale well. The same holds for the SON related processing required at the network management level. Also, since parts of the SON algorithms are running in the network elements and the interface between the centralized and distributed SON functions will be proprietary, third party solutions will be difficult.
It should be noted that the term “Hybrid SON” is not clearly defined and is used differently by different vendors. Some vendors classify their solutions as “hybrid” if the network management system can control the SON function by setting main parameters/policies, receiving reports and being able to turn it off if necessary. If such SON functions otherwise are autonomous, they are classified as “distributed” in this paper.
2.4. Discussion
Centralized SON solutions give the operator more control over the network as all information and control are available at the network management level. However, the potential problem with scalability as the number of cells in the network increases is a significant drawback. Also, risk of network wide interruptions due to problems with the centralized network management system or with the communication to it should be noted as a strong argument against centralized SON solutions.
Hybrid SON solutions have the same weaknesses with respect to scalability and single point of failure as centralized SON. Since algorithms can be split between a centralized component and a distributed component in different ways, the “degree” of centralization and hence the amount of backbone traffic will vary.
But even for solutions with low backbone traffic and less scalability problems, the algorithms will not work if the connection to the centralized component or the centralized component itself fails. Hence, the “single point of failure” problem is unavoidable in hybrid SON architecture.
Distributed SON solutions do not have the scalability and single point of failure problem. The operator do not have the same control of the SON functions as in the centralized case, but being able to monitor and control their behaviour through parameter/policy settings is usually sufficient. Coordination of different SON functions, possibly having conflicting goals and operating on different time scales, is more challenging than in the centralized case.
The lack of third party solutions for distributed and hybrid SON is usually not important since it is usually preferable that the SON solutions come from the same vendor as the equipment, so that the operator only has to deal with one vendor and it is obvious who is responsible if something does not work. One possible exception to this is SON functions for subscriber purchased HeNBs (femto-cells). In this case an operator can have HeNBs from several vendors in the network, and a centralized SON solution can be advantageous in order to avoid interworking problems between different vendor specific SON algorithms. However, a centralized SON solution for femto-cells can also generate a huge amount of backbone traffic, which is a strong argument against such a solution.
Comparing the advantages and disadvantages of the different SON architectures, distributed solutions seems to be the most future proof. It is necessary to plan for a high number of cells (macro, micro, pico, femto, etc.) in order to meet future capacity demand; therefore, scalability with respect to the number of cells is important. Also, mobile networks are getting more and more complex and it is important to have an architecture that minimizes the probability of failures that can affect the whole network.
It should be noted that current SON solutions are relatively simple and often collect statistics over long time periods (hours or days) before a network parameter is changed. As the events for the statistics can be counted locally and infrequently reported to the network management system, the amount of traffic generated by current centralized SON solutions will be low. However, as SON functions become more advanced they will be able to adapt to changes on shorter time scales, and significantly more information has to be exchanged with the network management system.
A final remark that should be mentioned is that when SON features from different vendors are considered, it is important to take vendor differences in the definitions of different SON architectures into considerations. For example, some vendors might denote their SON solution as “hybrid” according to their own definition, even though it is “distributed” according to the definition used in this paper.
3. Evaluation of Some Important SON Functions
In this section, we will discuss some of the most important SON functions as seen from an operator’s point of view, where the main issue will be the maturity and possible timing for deploying these features in mobile networks. We will also touch upon possible savings and performance gains by introducing SON but we must admit that the current knowledge is scarce and uncertain.
The SON functions are usually categorized into three main groups [13, 14]: self-configuration, self-optimization, and self-healing. It should be noted that a given SON function can belong to more than one of these categories.
3.1. Self-Configuration SON
The Self-configuration SON is a collection of algorithms that aims at reducing the amount of human intervention in the overall installation process by providing “plug and play” functionality in network elements such as the E-UTRAN NodeBs (eNBs). This will result in faster network deployment and reduced costs for the operator in addition to a more integral inventory management system that is less prone to human errors.
Self-configuration is a broad concept which involves several distinct functions that are covered through specific SON features, such as automatic software management, self test, physical cell ID configuration (PCI), and automatic neighbor relations (ANR). The latter function is not only used during installation but is also an important part during normal operations.
The self-configuration should take care of all soft-configuration aspects of an eNB once it is commissioned and powered up for the first time. It should detect the transport link and establish a connection with the core network elements, download and upgrade to the latest software version, set up the initial configuration parameters including neighbour relations, perform a self-test, and finally set itself to operational mode. In order to achieve these goals, the eNB should be able to communicate with several different entities.
The self-configuration actions will take place after the eNB is physically installed, plugged to the power line and to the transport link. When it is powered on, the eNB will boot and perform a self test, followed by a set of self-discovery functions, which include the detection of the transport type, tower-mounted amplifier (TMA), antenna, antenna cable length and auto-adjustment of the receiver-path.
After the self-detection function, the eNB will configure the physical transport link autonomously and establish a connection with the DHCP/DNS (dynamic host configuration protocol/domain name server) servers, which will then provide the IP addresses for the new node and those of the relevant network nodes, including serving gateway, mobility management entity (MME), and configuration server. After this, the eNB will be able to establish secure tunnels for operations sdministration and maintenance (OAM), S1, and X2 links and will be ready to communicate with the configuration server in order to acquire new configuration parameters.
One of the OAM tunnels created will communicate the eNB with a dedicated management entity, which contains the software package that is required to be installed. The eNB will then download and install the corresponding version of the eNB software, together with the eNB configuration file. Such configuration file contains the preconfigured radio parameters that were previously planned. A finer parameter optimization will take place after the eNB is in operational state (self-optimization functions).
The self-configuration SON functions were among the first standardized by 3GPP (release 8) and have been more or less stable since then. From the roadmaps of different vendors it can be concluded that self-configuration SON is available and mature. These SON features will be extremely useful in the rollout phase to reduce the installation time compared with ordinary installation procedures, and also later when new eNBs are added to increase the network capacity. The actual decrease in OPEX is not easy to give since the corresponding installation without any (self) automatic features is difficult to foresee.
3.2. Self-Optimization SON
SON self-optimization functions are aiming at maintaining network quality and performance with a minimum of manual intervention from the operator. Self-optimization functions monitors and analyzes performance data and automatically triggers optimization action on affected network element(s) when necessary. This significantly reduces manual interventions and replaces them with automatic adjustments keeping the network optimized at all times. Self-optimizing SON functions make it possible to introduce new automatic processes that are too fast, and/or too complex to be implemented manually. This will improve the network performance by making the network more dynamic and adaptable to varying traffic conditions and improve the user experience.
Some of the most important self-optimization SON use cases are:(i)physical cell ID (PCI);(ii)automatic neighbour relations (ANR);(iii)inter-cell Interference coordination (ICIC);(iv)mobility robustness optimization (MRO);(v)mobility load balancing optimization (MLB).
The two first use cases, PCI and ANR, may as well be categorized as self-configuration algorithms since they will be part of initial configuration procedures, but will also play an important part in normal operation and therefore may be viewed as being self-optimization procedures.
3.2.1. Physical Cell ID Configuration (PCI)
The automatic configuration of physical cell ID (PCI) for eNBs in LTE was standardised in 3GPP release 8 as part of “eNB self-configuration.” PCI is a locally defined identifier for eNBs with a restricted range (up to 504 values) and must be reused throughout the network. The PCI numbering of eNBs must locally be unique so that the UEs may be able to communicate and possible perform handovers. The goal of PCI configuration is to set the PCI of a newly introduced cell. The PCI is contained in the SCH (synchronization channel) for user equipment (UE) to synchronize with the cell on the downlink. When a new eNB is established, it needs to select PCIs for all the cells it supports. Since the PCI parameters have a restricted value range, the same value needs to be assigned to multiple cells throughout the network and must be configured collision free, that is, the configured PCI needs to be different from the values configured in all the neighbouring cells.
The PCI automatic configuration was one of the first SON functions to be standardized by 3GPP. The self-configuration feature seems to be quite mature and all of the main vendors have this function implemented in their eNBs. Some vendors report tests with 100% handover success rate in networks where new eNB are introduced and the Automatic PCI Optimization are applied. The physical cell ID configuration is a SON function that should be implemented at eNB rollout.
3.2.2. Automatic Neighbour Relations (ANR)
One of the more labour-intense areas in existing radio technologies is the handling of neighbour relations for handover. A neighbour relation is information that a neighbour cell is a neighbour to an eNB. Each eNB holds a table of detected neighbour cells which are used in connection with handovers. Updating automatic neighbour relations (ANR) is a continuous activity that may be more intense during network expansion, but is still a time consuming task in mature networks. The task is multiplied with several layers of cells when having several networks to manage. With LTE, one more layer of cells is added; thus, optimization of neighbour relations may be more complex. Due to the size of the neighbouring relation tables in radio networks, it is a huge task to maintain the neighbour relations manually. Neighbour cell relations are therefore an obvious area for automation, and ANR is one of the most important features for SON. To explore its full potential, ANR must be supported between network equipment from different vendors. ANR was therefore one of the first SON functions to be standardized in 3GPP. The description of ANR below is based on 3GPP TS 36.300 (release 10) [13].
As with the PCI automatic configuration, the ANR was one of the first SON use cases to be standardised, motivated by possible savings compared to a labour intensive manual configuration of the Neighbour Relations parameters. Especially in a roll-out the ANR may decrease the time needed to get LTE networks up running. Hence, even though the gain integrated over longer periods may not be so big, the initial advantages of this feature could be important during the start-up phase.
The inter-RAT SON is standardised in release 10 and will be important when different network standards such as GSM, UMTS/HSPA, and LTE are deployed to cover the same geographical area. Some vendors have this function already in their roadmaps.
It is recommended that ANR should be implemented at eNB rollout. Inter-RAT ANR should also be included when this function becomes available.
3.2.3. Inter-Cell Interference Coordination (ICIC)
The main idea behind inter-cell interference coordination (ICIC) is to coordinate transmissions in different cells in such a way that the inter-cell interference and/or the effect of it is reduced. With the currently proposed solutions this is achieved by letting each cell omit using some of the spectrum resources (frequency/time slots/power) in order to reduce interference. Omitting to use spectrum resources implies that some capacity is lost, so the gains obtained by operating in an environment with less interference must more than compensate for this loss. The most important gain that can be achieved by ICIC is the ability to provide a more homogeneous service to users located in different regions of the network, especially by improving the cell-edge performance.
The nature and severity of inter-cell interference depends on the cell types involved. Here we will consider macro-macro, macro-pico, and macro-femto cell interference. Macro-cells are large cells with a radius from some hundred metres in urban areas to several kilometres in rural areas. The base stations serving these cells transmit with high powers and are able to handle large number of users. Pico-cells are smaller cells deployed by an operator to enhance the coverage, for example, to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with heavy traffic such as an airport or train station. Femto-cells are very small cells served by a low-power cellular base station, typically designed for use in a home or small business. They are often installed by the customers themselves, but use an operator’s frequencies and are connected to the operator’s infrastructure.
Macro-Macro Cell Interference
When a frequency reuse of 1 is used, macro-cell deployments will experience heavy interference at the cell boundaries. The interference will occur on both uplink and downlink.
Macro-Pico Cell Interference
Pico-eNBs have much lower transmit power than macro eNBs. In conventional cellular systems a UE connects to the BS providing the best downlink Signal to Interference-plus-Noise Ratio (SINR), and since the eNB has low transmit power the coverage of pico eNBs will be small. But UEs receiving signals with larger SINR from a macro eNB might have much lower path loss to a pico eNB and hence cause significant uplink interference to the pico eNB.
If not placed specifically in a hot-spot, only a small number of UEs will be connected to the pico-eNB which will limit the gain from offloading the traffic from the macro cells. One way to improve this is to expand the pico-cell, for example, by introducing a bias in the cell selection based on reference signal received power (RSRP) or perform UE association determined by minimal path loss. This is often referred to as Cell Range Extention (CRE). In this case UEs at the cell-edge of the pico cell will also experience severe downlink interference from the macro eNB.
Macro-Femto Cell Interference
HeNBs or femtocells use low transmission power, usually lower than the power transmitted by a user terminal. The deployment of HeNBs is usually uncoordinated as opposed to deployment of macro and pico cells which are usually planned. A HeNB is typically operated in closed mode meaning that only certain users that are part of a closeds group (CSG) are allowed to connect to the HeNB.
The CSG restriction introduces complex high-interference scenarios in both the uplink and downlink direction. Consider a UE located close to the HeNB, possibly even in the same room as the HeNB, that are not part of the HeNB’s CSG. In this case the UE will experience severe downlink interference from the HeNB. In fact, the HeNB will often create a coverage hole in the macro cell. Also, the HeNB will experience severe uplink interference from the UE.
Solutions
Examples of “early” ICIC schemes are fractional frequency reuse (FFR) and soft frequency reuse (SFR). These should be compared to the two traditional frequency reuse schemes which are full frequency reuse (Full-FR) and Hard Frequency Reuse (HFR).
In a Full-FR scheme there is no coordination between the cells in the network, and all cells use all the frequency resources. This can lead to severe interference between the cells, especially for cell-edge users.
One way to reduce the inter-cell interference is to divide the frequency resources into blocks and allocate these blocks to cells so that neighbouring cells use different blocks. This is the HFR scheme. This approach gives excellent control of the interference, but the network capacity is reduced since each cell can only use a part of the available spectrum resources.
FFR is a kind of combination of full-FR and HFR. In this case the available spectrum is divided into two parts where full-FR is used in one part and FFR is used in the other part. The full-FR part is typically used to serve cell center user since these have less problems with inter-cell interference. The cell-edge users are served by the HFR part since these users are more exposed for interference. These frequency reuse schemes are illustrated in Figure 2.
In a SFR scheme, all cells use all available spectrum but with different power in different parts as illustrated in Figure 3. The frequency blocks with the highest power can then be used for serving cell-edge users giving them a good signal-to-noise ratio since the neighbour cells transmissions will use low power at these frequencies.
LTE Release 8/9 specifies eNB measurements, signalling principles, and messages for ICIC over the X2 interface. The ICIC algorithms, however, are vendor specific.
LTE release 8/9 ICIC is only capable of reducing inter-cell interference between macro cells. The main problem of the Release 8/9 ICIC methods is that they are limited to data channels. Therefore, they do not provide sufficient protection for the downlink control channels in the more severe interference scenarios that occur in the macro-femto case and pico cell range expansion has to be limited to small Hand-Over (HO) threshold offsets to keep control channel errors at a reasonable level.
Time domain ICIC, also called eICIC, was introduced in LTE Release 10 to handle macro-pico and macro-femto interference cases. In addition, new ICIC mechanisms based on optimally exploiting available frequency assets in carrier aggregation (CA) scenarios is currently studied in 3GPP. These are denoted as “carrier-based HetNet ICIC.”
Discussion
The gains that can be expected from using FFR and SFR schemes in real situations are modest. Several studies have indicated that almost comparable performance can be achieved by relying on the use of more robust modulation and coding for UEs with low SINR combined with the interference averaging that occur in practice with bursty, nongreedy traffic, especially with low to moderate network load. This performance can be further improved by introducing QoS-aware packet schedulers, so that users with low experienced SINR conditions are scheduled more often and/or on more physical resource blocks (i.e., in larger bandwidth) to make sure that their minimum QoS requirements are fulfilled. This corresponds to using more effective average transmission power, and potentially also bandwidth, for the coverage limited users.
In the downlink, FFR and SFR will only reduce the interference on the data channels. Hence, cell edge UEs must anyway have a sufficient SINR for receiving the control channels, so reception of data channels using robust coding and modulation is also possible.
On the uplink an UE can experience heavy interference from cell edge users in neighboring cells. This occurs when cell edge UEs of neighboring cells are allocated RBs which overlap with the victim UE’s RBs. But the next time the victim UE transmits the interference will come from different UEs, hence the interference will be different. If the network load is not too high and since the traffic is bursty, the uplink interference will only occasionally be so severe that the transmission is blocked. The HARQ (hybrid automatic repeat request) mechanism will then ensure that the uplink data is correctly transferred.
It is therefore not necessary to include FFR and SFR based ICIC solutions in newly deployed LTE networks. Such solutions could be introduced later when the network load gets high, if it is desired to improve the cell edge user performance.
LTE-Advanced ICIC is more powerful and will be required to handle macro-femto intercell interference, and interference between macro and range extended pico cells with high HO offset bias. As the number of small cells in the LTE network increase, an ICIC function handling HetNet scenarios will be crucial. Hence, advanced ICIC should be included when it becomes mature.
3.2.4. Mobility Robustness Optimization (MRO)
Mobility robustness optimization (MRO) [13] encompasses the automated optimization of parameters affecting active mode and idle mode handovers (HOs) to ensure good end-user quality and performance, while considering possible competing interactions with other SON features such as automatic neighbour relations (ANR) and mobility load balancing (MLB).
Incorrect HO parameter settings can negatively affect user experience and waste network resources by causing HO ping-pongs, HO failures and radio link failures (RLF). While HO failures that do not lead to RLFs are often recoverable and invisible to the user, RLFs caused by incorrect HO parameter settings have a combined impact on user experience and network resources. Therefore, the main objective of mobility robustness optimization is the reduction of the number of HO-related radio link failures. Additionally, suboptimal configuration of HO parameters may lead to degradation of service performance, even if it does not result in RLFs. One example is the incorrect setting of HO hysteresis, which may results in ping-pongs or excessively delayed handovers to a target cell. Therefore, the secondary objective of MRO is the reduction of the inefficient use of network resources due to unnecessary or missed handovers.
During roll-out of an LTE network, there will be areas having limited LTE coverage. Enabling handover from LTE to existing 2G/3G systems will therefore become an important feature. In this scenario, it will be very important to maintain a low drop rate for UEs moving from LTE to 2G/3G.
A SON MRO mechanism was introduced in release 10 for the purpose of detecting unnecessary inter-RAT handover. During the handover preparation the source RAT (LTE) requests optionally the target RAT (GSM/UMTS) to perform UE measurements of the source RAT. The measurements start following the successful handover, and the measurement duration is one of the parameters provided by the source RAT (max 100 seconds). The measurements stop if a new inter-RAT HO takes place during this time interval.
If during this period the UE measurements shows that the source RAT quality remains better than a configurable threshold, the target RAT will report to the source RAT that the handover could have been avoided. The source RAT may then take corrective action, for example, adjust the handover threshold or increase time-to-trigger setting for handovers to the concerned inter-RAT target cell.
MRO is very useful in the LTE network deployment process, reducing the need for extensive drive-testing. Since the LTE coverage often will be spotty in the beginning, inter-RAT MRO will also be very useful. For networks in operation MRO will ensure that the handover thresholds are optimal at all times and remove the need for manual task such as drive-testing, detailed system log, and postprocessing.
The benefits of MRO will be especially useful in HetNets, which are more dynamic where small cells appear and disappear. However, MRO solutions for HetNets are still not fully developed.
MRO is not critical for the operation of LTE networks today. The networks are usually stable macro networks with low to moderate traffic load, and most of the terminals are PC dongles and hence usually stationary when used. However, MRO will become more important as the penetration of handheld terminals becomes larger, the traffic load increases and micro-, pico-, and femto-cells are introduced in the network. It will be beneficial to include MRO in LTE networks from the start but it will not be a critical function when the network is a stable macro network, but will offer reduced installation time and reduced OPEX costs. As the number of small cells in the network increase, MRO will be become more important and an MRO function capable of handling HetNet scenarios should be included.
3.2.5. Mobility Load Balancing Optimization (MLB)
The objective of mobility load balancing (MLB) [13] is to intelligently spread user traffic across the system’s radio resources in order to optimize system capacity while maintaining quality end-user experience and performance. Additionally, MLB can be used to shape the system load according to operator policy, or to empty lightly loaded cells which can then be turned off in order to save energy. The automation of this minimizes human intervention in the network management and optimization tasks.
Basic functionality of mobility load balancing was defined in Release 9. Release 10 added enhancements that addressed inter-RAT scenarios and inter-RAT information exchange.
Support for mobility load balancing consists of one or more of following functions:(i)load reporting;(ii)load balancing action based on handovers;(iii)adapting handover and/or reselection configuration.
Triggering of each of these functions is optional and depends on implementation.
Current implementations of the MLB function are relatively simple. Moving load between cells are achieved by adjusting the handover thresholds and hence the position of the cell boundaries. As this can affect the handover performance, this must be coordinated with the MRO SON function. This can, for example, be achieved by letting the MRO function define an allowed interval for the handover threshold. The MLB function can then adjust the handover threshold within this interval.
One of the weaknesses of current MLB implementations is that the UEs that are moved from one cell to another do not usually constitute the optimal choice and can even cause problems in the target cell. For example, moving an UE that uses a lot of capacity can cause overloading in the target cell. This will lead to new MLB-based handovers and, if necessary precautions are not taken, even to ping-pong effects.
It should be notated that estimating what load an UE will represent in the new cell is not straightforward. The radio conditions in the new cell will be different from what it was in the original cell, hence the radio resources (i.e., the air time) required for a certain capacity will also be different. In the downlink the estimation can be done based on RSRP/RSRQ (reference signal received quality) reports from the UE. However, similar information is not available for uplink and extended information exchange between the eNBs is required.
MLB of idle mode UEs is more difficult than for active mode UEs. There is currently no way to know exactly on which cell an idle mode UE is camping. The only time the system becomes aware of the exact cell an UE is in, while in idle mode, is when the tracking area of the user changes and a tracking area update message is sent by the UE. Therefore, while parameters that control how and when a UE performs cell reselection (idle handover) are modifiable, there is no direct measurement mechanism for the system to determine when there are “too many” idle users. In current implementations the idle mode load balancing is usually done by adjusting the cell reselection parameters for the idle users based on the current active user condition.
The load balancing can be operated in different ways. One possibility is to only activate MLB when a cell becomes congested. Another possibility is to let MLB be a more continuous process trying to keep the load in different cells balanced at all times. In the latter case careful consideration should be given to the network signalling load. Currently, there are limited knowledge on the advantages and disadvantages of operating MLB in different ways, and further studies and field trials should be performed. The way of operation should be configurable by the operator through the network management system.
To increase the effectiveness of the MLB function, especially in HetNet scenarios with many small cells, it will be necessary to develop more advanced algorithms. One potential improvement is to choose which UEs should be moved from one cell to another more carefully. The choice could be based on such parameters as capacity and QoS requirements, possibly including predicted values for these parameters based on historical information. The decision on what cells UEs should be moved to and from could also be performed more optimally, for example, based on current and historical statistical data on the load in different cells.
Basing the MLB related decisions on more information requires extended exchange of data between eNBs, which requires standardization of the necessary signalling support.
Another area for improvement of MLB is its interworking with other SON functions, especially with MRO. In most current MLB implementations, MRO has priority and MLB has to adapt to the adjustments done by MRO. This significantly limits the MLB operation. For inter-RAT and inter-frequency handovers, MLB should probably have priority over MRO. MLB also significantly overlap with the traffic steering and must be coordinated closely with this function.
In newly deployed LTE networks the traffic load will be modest and there will be little need for load balancing between LTE cells and between LTE and 2G/3G cells. As traffic increases, the usefulness of the MLB function also increases. It is therefore not necessary to include MLB in LTE deployments from the start. The usefulness of MLB increases as the network load increase and becomes important when the network develops into a HetNet with many small cells.
3.3. Self-Healing SON
Self-healing functionality was not initially defined a part of the 3GPP SON functionality, but it was taken into the SON standards in release 9 and 10, by 3GPP TS 32.541 “Self-healing concepts and requirements” [14].
Self-healing is a collection of SON procedures which detects problems and solves or mitigates these to avoid user impact and to significantly reduce maintenance costs. Self-healing is triggered by alarms generated by the faulty network elements. If it finds alarms that it might be able to correct or minimize the effects of, it gathers more necessary correlated information (e.g., measurements, testing results, and so forth), does deep analysis, and then trigger the appropriate actions.
The two major areas where the self-healing concept could be applied are as follows.(1)Self-diagnosis: create a model to diagnose, learning from past experiences.(2)Self-healing: automatically start the corrective actions to solve the problem.
Making use and analyzing data from the current optimization tools (alarm supervision system, OAM system, network consistency checks), optimizers can decide if network degradation occurs, which is the most likely cause, and then perform the needed corrections to solve the problem. The experience of optimizers in solving such problems in the past, and the access to a database of historic solved problems is very useful to improve the efficiency in finding solutions.
This whole optimization process could be enhanced in two steps as follows.(i)Diagnosis model creation based on the experience of already solved problems, using a database with faults and their symptoms. Automatic troubleshooting action can be done without human intervention.(ii)Self-test results from the periodic execution of consistency checks would help during the self diagnosis phase, to address better the healing process.
In the recommendation [14] three different Self-healing SON functions are defined:(i)cell outage,(ii)self-recovery of network element (NE) software and(iii)self-healing of board faults.
For the time being only cell outage is available in vendor’s roadmaps and the two latter will therefore not be described in this paper.
3.3.1. Cell Outage
This SON function has two basic components, namely, cell outage detection (COD) and cell outage compensation (COC) which is briefly described below.
COD uses a collection of evidence and information to determine if a particular cell is not working correctly. Detection also includes the simple case where OAM is aware of the fault. However, in the case of complete eNB failure, OAM will be unable to communicate with the eNB to determine whether its cell is in service. Lack of communication could be a symptom of failure on the OAM backhaul rather than an indication that the site is down. In this case, the network manager needs to apply other methods to determine the nature of the problem. Latent fault determination is the term used when the fault detection is based on evidence, such as anomaly statistics, rather than an alarm or state change. This is the most challenging of the cell outage detection scenarios since OAM indications will suggest that it continues to operate normally. This type of detection may be achieved with a combination of statistics and activity watchdog timers. The operator will typically have a set of generic policies defined where each policy describes the combination of stats or events that are deemed to indicate a cell outage. Perhaps the most valuable of the evidence-based detection mechanisms is the use of time/day profiling on a per cell basis. This is achieved by collecting statistics over a period of time and gradually building a picture of expected performance for a given time of day, weekday, or weekend. When statistics collected for a cell deviate significantly from values normally seen for that cell, then there is a likelihood of a latent fault.
The goal of COC is to determine and set network parameters and mitigate the effect of cell outages and thereby minimize the network performance degradation when a cell is in outage. This is done by automatic adjustment of network parameters in order to optimise coverage and performance, and meet operator’s deployment requirements based on coverage and other KPIs (e.g., number of supported users, capacity, and data rates) to the largest possible extent. Automated reconfiguration as a result of cell outage serves at completely, or to the largest extent possible, alleviating, and compensating outage in the area previously served by the missing or low performing cell. Note that there may be an upper limit for the degree of compensation that is actually possible. For example, if a hardware failure resulting in a total shutdown of an eNB, parts of the original cell area can be covered by adjustments in neighbouring cells. Hence, it may be difficult to compensate for the cell outage entirely. Necessary reconfigurations to minimize RB performance degradations must be done in a timely manner, for example, proper actions to mitigate cell outage should be executed no later than a predefined deadline (after detecting the cell outage).
3.3.2. Discussion
For the moment the self-healing SON functions are at its initial phase and are not mature and stable, though some use cases have been indicated by the vendors, like cell outage detection and compensation. COD is an important feature to help detecting malfunctioning base-stations and will be important for operators. In the near future more self-healing SON functions will become available, however, the main impression is that there will be some years before these SON mechanisms are stable and mature. More specifically, for newly deployed LTE networks, it will not be necessary to include self-healing SON from the beginning. Such solutions could be introduced later when these SON mechanisms are available and more mature. However, COD should be part of the SON solution if available.
3.4. Coordination of SON Functions
Up to now, the work on SON has focused mostly on the development of stand-alone functionalities. However, several of the different SON functions may have the same target optimization parameters, that is, the output of two or more algorithms may try to act/optimize the same parameters. This may cause problems if some SON functions tend to tune parameters in different direction and this may lead to instabilities.
Such conflicts can occur if, for example, two different individual SON functions (e.g., cell outage management and interference coordination) aim at different goals when optimising the same parameter, or if the modification of a control parameter by one SON function influences the operation of other SON functions. Such conflicts may cause the whole system to operate far from optimal behaviour, with a negative impact on the operator’s overall objectives on performance and user satisfaction. Thus, the avoidance and/or resolution of conflicts and dependencies between the functions will be beneficial.
A good example of SON functions which need to be coordinated is MRO and MLB which both act and try to optimize the HO parameters and therefore needs to be coordinated.
As the SON suite grows it might be necessary to implement a framework for coordination of SON functions to ensure that the individual SON functions jointly work towards the same goal, formulated by the operator’s high-level objectives. This can be achieved by effectively and appropriately harmonising policies and control actions of the SON functions. A SON coordinator should furthermore ensure that the individual SON functions work with a common set of performance targets and measurements, and enable the operator to control the overall SON system through a single interface and thereby minimise the operational effort.
Initially it will be, at least, desirable to have coordination between some SON function like MRO/MLB and ANR/Phy cell ID. Later, as the SON suite grows in number, it will be necessary to introduce some form of SON coordination framework to secure optimal use of the SON suite.
3.5. Summary
To sum up the discussion in this section we have set up a table to highlight some of the main features that are important for an operator concerning SON:(i)timing of introduction of SON functions,(ii)possible savings,(iii) QoS and performance improvements, and(iv)coordination between SON functions.
In Table 1 we have given our view of important properties of current SON functions. Clearly the self-configuration part of SON are mature and should be included at rollout while most of the self-optimization and self-healing algorithms are not that important to include at roll-out and could be set in operation in two to three years time when the traffic load have increased. When it comes to possible savings and performance improvements we have only classified according to high, medium, and low since actual percentages will depend on several other factors which are outside the scope of this paper.
4. Conclusion
As the demand for mobile communication is steadily increasing, this will lead to an increased complexity in radio access network through addition of femtocells, picocells, as well as WiFi access. It is therefore important to develop SON solutions for heterogeneous access technologies. This work has already started in 3GPP and for some SON functions both Inter-RAT and Intra-RAT solutions are available.
For operators, testing of SON functions will be important. The testing must include a variety of test cases from plain functional testing to large scale testing involving several SON functions where also the stability and interaction between SON components are tested also with high network load. As a powerful supplement to testing, analysis will also be an important tool to investigate the performance of different SON solutions. By analysis several alternative may be compared to find optimal configuration of SON.
Another issue is scalability of SON solutions. It is reason to believe that a very central SON architecture may cause scaling issues that must be considered. Current centralized SON implementations are relatively simple and require little traffic between the network elements and the network management system. However, as more advanced and dynamic SON functionality are developed, this traffic will increase significantly. Hence, a distributed architecture with more autonomous network elements is expected to be the most future-proof solution for most SON functions.
5. Annex. 3GPP SON Standardization
This annex gives an overview of work items where SON functionalities have been developed in the different releases of the 3GPP specification staring with Release 8 (much of the text is taken from 3GPP release description documents [15]).
5.1. Release 8
5.1.1. Self-Establishment of eNBs
Self-configuration includes an automated establishment of IP connectivity between the eNB and the element manager, an automated download of software and an automated download of radio and transport configuration data. It may also include an automatic setup of X2 and S1 interfaces. Appropriate security mechanisms are needed. Newly established eNBs might also perform self-test and send out reports about the results.
This work defines the following items:(i)management reference model supporting this use case,(ii)requirements,(iii)elements for NRM IRPs,(iv)interface IRPs for the interaction patterns on open interfaces,(v)security mechanisms,(vi)mechanisms for software download related to self-establishment,(vii)reports of self-test results.
TS 32.501 [16] covers concepts and requirements for self-establishment of eNodeBs and TS 32.502 [17] contains the stage 2 for self-establishment of eNodeBs.
5.1.2. SON Automatic Neighbour Relations (ANR) List Management
In the context of LTE, it is necessary to automate, as much as possible, the discovery of neighbour relations. The goal is to reduce the reliance on traditional configuration methods (e.g., manual configuration, configuration by planning tools in GSM case) in the context of growing complexity and scale of the new generation of mobile networks.
The automatic neighbour relation (ANR) function includes the relations to LTE cells on other eUTRAN frequencies and 2G and 3G cells.
The objectives are to identify and define functions that collectively support the automation of neighbour relations discovery and, to identify the actors of this automation and to define necessary open interfaces among various identified functions and actors.
This automation is not a replacement of the “traditional configuration methods,” which must work together in a way that operators remain in control of the degree of automation and "traditional configuration methods" involved.
This work includes:(i)defines use cases;(ii)identifies actors and defines various functional blocks that collectively support the subject automation;(iii)identifies interfaces where standardization is required(iv)defines necessary security mechanisms.
TS 32.511 covers concepts and requirements for automatic neighbour relation (ANR) management.
5.2. Release 9
5.2.1. Study on Self-Organizing Networks (SON) Related OAM Interfaces for Home NodeB
UE, NodeB, and OAM system (both element management system (EMS) and network management system (NMS)) are involved in the LTE/UMTS system for supporting SON as listed below:(i)interface between NMS and EMS,(ii)interface between 2 EMSs,(iii)interface between EMS and NodeB,(iv)interface between 2 NodeBs,(v)interface between UE and NodeB.
For both LTE and UMTS home NodeB, SON is necessary because:(i)number of home NodeB can be very big;(ii)subscriber may frequently switch on and off the home NodeB;(iii)operator may not be able to access home NodeB physically as it is located on the subscriber’s premises.
The following work will be conducted:(i)Define SON OAM architecture for both LTE and UMTS home NodeB.(ii)Identify differences between SON OAM architecture for LTE Marco eNodeB and for LTE and UMTS home NodeB; Propose aligned SON OAM architecture.(iii)Identify what can be standardized in SA5 on SON for LTE and UMTS NodeB.(iv)Propose/pave the way for a subsequent Implementation work item.
5.2.2. Study on Self-Healing of Self-Organizing Networks (SON)
Self-testing and self-healing have been recommended as subtasks of SON in the NGMN white paper.
Self-testing and self-healing means that a system detects itself problems and mitigates or solves them avoiding user impact and significantly reducing maintenance costs. This study focuses on self-healing only.
This study collected requirements and identified possible solutions for SON Self-healing.
The results are given in TR 32.823 [18].
5.2.3. SON Self-Optimization Management
SON target is to maintain network quality and performance with a minimum of manual intervention from the operator. Self-optimization functionality monitors and analyzes performance management data, and automatically triggers optimization action on the affected network node(s) when necessary. This significantly reduces manual interventions and replaces them with automatically triggered reoptimizations, reconfigurations, or software reloads/upgrades thereby helping to reduce operating expense.
TSG RAN work on SON for RRM also requires OAM support, hence the scope of SON self optimization also includes:(i)load balancing,(ii)handover Parameter optimization,(iii)interference control,(iv)capacity and coverage optimization, (v)RACH optimization.
Objectives of this work were to:(i)collect and document self-optimization OAM requirements for SON;(ii)define (in cooperation with RAN WGs) inputs to and outputs from the self-optimization Entity, its location in the management architecture, and the degree of standardization of the associated algorithms;(iii)identify and document required self-optimization related additions to the affected specifications;(iv)ensure that the OAM specifications support load balancing, HandOver (HO) parameter optimization, interference control, capacity and coverage optimization and RACH optimization.
The results of this work are found in TS 32.425 [19].
5.2.4. Automatic Radio Network Configuration Data Preparation
When radio Network Elements (NEs) (e.g., cells and/or eNBs) are inserted into an operational radio network, some network configuration parameters cannot be set before-hand because they have interdependencies with the configuration of operational NEs. “Dynamic Radio Network Configuration Data Preparation” comprises the generation and distribution of such interdependent parameters to the newly inserted network element and optionally already operational NEs.
This functionality allows fully automatic establishment of an eNB into a network. Otherwise an operator needs to set these configurations manually. Without this functionality self-configuration cannot be considered not fully as “self”.
This work provides technical solutions for automatic radio network configuration data preparation, that is,(i)analyzes which configuration parameter cannot be determined before-hand by the IRPAgent or by the self-configuration process and what input might be needed to generate them;(ii)defines new functionality to trigger distribution of such parameters. This functionality fits to the existing self-configuration functionalities and re-uses existing IRPs, wherever possible.
5.2.5. Self-Organizing Networks (SON)
SON uses cases are described in LTE TR 36.902 [20]. In release 8 first functions to cover use cases had been implemented, and this work was continued in release 9.
Different SON use cases are relevant at different times of network operation, for example, during initial roll-out, early phases of operation, or operation of a mature network with high load. Release 9 work focussed on the solutions for LTE introduction.
Technical solutions for the goals and requirements were based on existing measurements wherever possible.
This work provides technical solutions for use cases contained in TR 36.902 and with particular relevance to early phases of network roll-out and operation, that is;(i)coverage and capacity optimization (started, but not completed in release 9),(ii)mobility load balancing optimization, (iii)mobility robustness optimization,(iv)RACH optimisation.
5.3. Release 10
5.3.1. SON Self-Healing Management
The target of self-Healing (SH) is to recover from or mitigate errors in the network with a minimum of manual intervention from the operator.
Self-healing functionality will monitor and analyse relevant data like fault management data, alarms, notifications, and self-test results, and so forth and will automatically trigger or perform corrective actions on the affected network element(s) when necessary. This will significantly reduce manual interventions and replace them with automatically triggered reconfigurations, or software reloads/upgrades thereby helping to reduce operating expense.
The main objectives are as follows.(i)Collect and document Self-healing OAM requirements, stage 2 and stage 3 definitions. (ii)Define—if needed in cooperation with RANs—inputs to and outputs from the self-healing functions, its location in the management architecture, and the degree of standardisation of the associated algorithms.(iii)Identify and document required self-healing related additions to the affected existing specifications.(iv)Ensure that the OAM specifications support the management of the self-healing functionalities.
Based on the above, a set of new TSs should capture the SON Self-Healing OAM Requirements and solutions. Some existing specifications (i.e., NRM, PM, etc.) may need some modification according to the output of the work task.
5.3.2. OAM Aspects of Energy Saving in Radio Networks
Energy efficiency is important both from a cost and an environment perspective. There are strong requirements from operators on the management and monitoring of energy saving functions and the evaluation of its impact on the network and service quality. Therefore an efficient and standardized management of energy saving functionality is needed.
Coordination with other functionalities like load balancing and optimization functions is also required.
The objectives of this work item are as follows.(i)Define energy savings management OAM requirements and solutions for the following use cases: (a)eNodeB overlaid,(b)carrier restricted,(c)capacity limited network.(ii)Define OAM requirements and solutions for coordination of ESM with other functions like (a)self-optimization,(b)self-healing,(c)traditional configuration management,(d)fault management.(iii)Select existing measurements which can be used for assessing the impact and effect of energy saving actions corresponding to above energy saving use cases.(iv)Define new measurements which are required for assessing the impact and effect of energy saving actions, including measurements of the energy consumption corresponding to above energy saving use cases.
For all the above existing standardized functionalities shall be reused as much as possible.
5.3.3. Automatic Neighbour Relation (ANR) for UTRAN
In LTE, automatic neighbour relation (ANR) function discussed in both RAN and SA5 in EUTRAN context, which are documented in LTE TS 36.300 [13] and TS 32.521 [21].
It is costly and troublesome to retain neighbour cell relation information. So it is desirable to enable introduction of automated solutions to reduce the operator’s costs for network maintenance and operation. The objective of the automatic neighbour relation (ANR) function for UTRAN is to relieve operators from the burden of manually managing the neighbour cell relations (NRs).
The objective is to specify the ANR feature for the following scenarios:(i)intra-UTRAN case, including intra-RNS and inter-RNS case; the latter is limited to the case where it can rely on existing Iur connections between the two RNCs,(ii)inter-RAT case.
Essential scenarios: both UTRAN to GSM and UTRAN to LTE.
5.3.4. Self Optimizing Networks (SON) Enhancements
This work item (WI) continues work started in Release 9. Some cases that were considered in the initial phases of SON development are listed in the TR 36.902. From this list, almost all use cases are already specified.
Capacity and coverage optimization (CCO) was already nominally part of the release 9 WI, but could not be completed due to amount of work related to other use cases.
Energy savings are a very important topic, especially for operators, as solutions derived for this use case can significantly limit their expenses. According to TR 36.902 [20] this solution should concern switching off cells or whole base stations. This may require additional standardised methods, once there is need identified for.
Basic functionality of mobility load balancing (MLB) and mobility robustness optimization (MRO), also listed in TR 36.902, were defined in release 9. However, successful roll-out of the LTE network requires analysing possible enhancements to the release 9 solutions for MLB and MRO. In particular, enhancements that address inter-RAT scenarios and inter-RAT information exchange must be considered. These enhancements should be addressed in release 10.
There may also be other use cases for LTE for which SON functionality would bring optimizations.
The upcoming LTE-A brings about also new challenges that can be addressed by SON. However, since not all features are clearly defined yet, it is difficult to work on SON algorithms for them. It is therefore proposed to assign lower priority to the features specific for LTE-A.
Objective
Use cases and scenarios elaborated within this WI:
Coverage and Capacity Optimization (CCO). The use case is to enable detection of following problems.(i)Priority 1: coverage problems, for example, coverage holes.(ii)Priority 2: capacity problems.
The work on the detection methods is to be coordinated with the progress of other SON functionalities, in particular MRO and MDT.
It is expected that the work will be conducted in SA5, where methods to make the collected information available for OAM are specified, together with possible tools needed for corrective actions.
Mobility Robustness Optimization (MRO) enhancements. The use case is to enable detection and to provide tools for possible correction of following problems.(i)Connection failures in inter-RAT environment:(a)priority 1: at HOs from LTE to UMTS/GSM,(b)priority 2: at HOs from UMTS/GSM to LTE.(ii)Obtaining UE measurements in case of unsuccessful re-establishment after connection failure.(iii)Ping-pongs in idle mode (inter-RAT and intra-LTE environment).(iv)Ping-pongs in active mode (inter-RAT).(v)HO to wrong cell (in intra-LTE environment) that does not cause connection failure (e.g., short stay problem).
Mobility Load Balancing (MLB) Enhancements. The use case is to fulfil following objectives:(i)improving reliability of MLB in intra-LTE scenarios,(ii)improving functionality of the MLB in inter-RAT scenarios (the transport method agreed for Release 9 should be used for Release 10).
5.3.5. Enhanced ICIC for Non-CA Based Deployments of Heterogeneous Networks for LTE
With growing demand for data services, it is becoming increasingly difficult to meet the required data capacity and cell edge spectrum efficiency through simple cell splitting and current ICIC mechanism in release 8/9. The enhancement of release 8/9 ICIC mechanisms is necessary to efficiently support highly variable traffic loading as well as increasingly complexity and the network deployment scenarios with unbalanced transmit power nodes share the same frequency.
With growing demand for data services, it is becoming increasingly challenging to meet the required data capacity and cell edge spectrum efficiency through simple cell splitting and current ICIC mechanism in release 8/9. The enhancement of Release 8/9 ICIC mechanisms is important to efficiently support highly variable traffic loading as well as increasingly complex network deployment scenarios with unbalanced transmit power nodes sharing the same frequency.
While carrier aggregation (CA-) based solutions are attractive for situations with large availability of spectrum and UEs with CA capability, non-CA (i.e., co-channel) based solutions are important to enable efficient heterogeneous network deployments with small bandwidth availability and UEs without CA capability.
In networks with unbalanced transmit power nodes sharing the same frequency, interference conditions are expected to change from location to location (due to the possibly lower level of network planning of these deployments) and from time to time (due to the variable traffic load at each node). Here coordination of control and data channel interference is important to maintain the downlink and uplink cell coverage and thus good data channel performance.
Objective
(i)Identify and evaluate non-CA-based strategies of heterogeneous network deployments, as well as determine the standardization work necessary to support enhanced inter-cell interference coordination solutions for control and data channels if need is identified(a)The study shall include consideration of release 8/9 techniques and ensure backward compatibility for release 8/9 terminals as well as minimize physical layer air interface impact.(ii)Following completion of the above feasibility evaluation, specify suitable solutions considering enhanced ICIC techniques for control and data channels.
5.4. Release 11
5.4.1. Further Self-Optimizing Networks (SON) Enhancements
(1) Mobility Robustness Optimisation (MRO) enhancements
For LTE, the SON (Self-optimizing networks) concept and many features have been standardized from release 8 to release 10. SON aims at maintaining network quality and performance with minimum manual intervention from the operator. Even though the automatic neighbour relation (ANR) function and the minimization of drive tests (MDT), specified in the LTE context, were introduced during release 10 in UTRAN as well, most problems that have SON solutions in LTE are not addressed in UTRAN. Introducing SON functions for UTRAN is also important for operators to minimize operating expenses.
One of the use cases addressed in Release 10, namely, the mobility robustness optimization enhancements (MRO), was completed with appropriate support for LTE. The need for an adequate inter-RAT solution was identified, but since there was no time to complete it during release 10 due to some work prioritisation, the inter-RAT MRO enhancement topic was postponed. The solution defined for LTE in release 10 enables the network to detect MRO related problems if the UE re-connects to an LTE cell. However, it is possible after a connection failure the UE selects a cell at different RAT. Currently there is no mechanism to detect such event and to enable its correction.
In addition, this MRO enhancement topic may include coordinated configuration of the mobility parameters (e.g., threshold for the measurement) for inter-RAT mobility.(2) Short stay and inter-layer ping-pong scenarios in intra-RAT and inter-RAT environment
Already during the stage-1 work on SON in release 9 some problems related to mobility have been identified, but never solved. As stated in the TR 36.902 [20], there are mobility issues that do not lead to connection failures. There seem to be two groups of problems: (i)unnecessary short stays when moving across a network;(ii)Intra-RAT inter-layer or inter-RAT ping-pongs.
These events may be especially relevant in case of HetNet deployments, where a macro cell overlaps with several low power nodes, but are not exclusive for those deployments: macro cell deployments will also benefit from possible solution. In both cases, the problem is to distinguish unnecessary HO from the one that was needed. Then, once detected, necessary information about the event must be collected and passed to the cell where the issue originates from. Finding solution for these problems shall be the objective of this use case.(3) Selection of the proper RAT based on QoS related information exchanged between RANs of different RATs.
From QoS perspective, it is important to ensure the correct understanding of the supported QoS between UTRAN and E-UTRAN to ensure Inter-RAT (UMTS to LTE may be extended to LTE to UTRAN) Handover performance. (4) Extensions to existing ANR mechanisms
The ANR is now applicable to UTRAN and E-UTRAN, with detection of inter-RAT Neighbour relation in both sides. A signalling-based solution which involved respective networks nodes may give improvement for the inter-RAT neighbouring relation (NR) verification and coordination considering the dynamic changes in network topologies.
In UTRAN, the automatic neighbour relation (ANR) feature was concluded in release 10 without the support of CSG cells. This means an ANR log from the UE will not contain CSG cells either as source or detected cells. It is desirable to extend the automated solutions also to allow any type of HNB (open, hybrid, closed), so that their neighbour relations can be to managed automatically. Hence it could be expected that a report from the UE may contain any, or a combination, of:(1) CSG source cell—CSG detected cell,(2) macro source cell—CSG detected cell,(3) CSG source cell—Macro detected cell.
Also, there is necessity for some improvements in release 10 ANR. That includes better handling of large number of small cells and enhancements to the UE parameters and measurements, solutions for no Iur connectivity, and details concerning behaviour during RAN sharing.(5) Further coordination between MRO and other traffic control mechanism (MLB or traffic steering) to provide necessary robustness of overall SON solution
Another element needed to complete the SON work is coordination between the mechanisms defined for MRO and traffic steering or mobility load balancing (MLB) solutions. MRO reaction may need to be different in case of mobility based purely on radio conditions and that caused by traffic steering or MLB. Such enhancement could minimize the risk of conflicting decisions and help improve overall performance of the system.(6) Investigating and evaluating methods to verify the status of the cell’s radio resources (self-healing)
Currently, SA5 is conducting a study on the self-healing topic. In order to keep the SON work in TSG RAN open for input coming from SA5 during release 11, it is proposed to take this topic into the list of items.
Work on this topic should not start before the feasibility study in SA5 has reached a stable status.