Mobility Robustness Optimization (MRO)

In traditional mobility management schemes, the handover parameters are set by the mobile operator, which is inefficiency and inaccurate. Recently, mobility robustness optimization (MRO) as one of the usecases in the self-organization networks has been studied to reduce radio link failures (RLFs) and unnecessary handovers due to improper handover parameter settings. However, traditional handover optimization is inappropriate for different characteristics in macrocell-femtocell hybrid deployment compared with those in macrocell due to the dynamic channel conditions and different mobility patterns. On one hand, the large number of femtocells makes it difficult to configure and maintains handover parameter optimization using existing schemes; on the other hand, since femtocell could be frequently turned on/off, channel conditions and neighboring cell list change frequently.

In a cost function based handover parameter optimization scheme incorporating cell load, UE’s velocity and service type, is proposed for 3GPP LTE macrocells. In admission control strategy and handover self-optimization are considered to optimize the handover performance. Joint hysteresis and time to trigger (TTT) optimization scheme is investigated in to reduce handover failures. Most of these studies optimize the handover parameters, such as hysteresis and TTT, based on self-optimization techniques.

Mobility Robustness Optimization (MRO) encompasses the automated optimization of parameters affecting active mode and idle mode handovers to ensure good end-user quality and performance, while considering possible competing interactions with other SON features such as, automatic neighbor relation and load balancing. Incorrect handoff parameter settings can negatively affect user experience and waste network resources due to handoff and radio link failures (RLF). While handoff failures that do not lead to RLFs are often recoverable and invisible to the user, RLFs caused by incorrect handoff parameter settings have a combined impact on user experience and network resources.

In addition to MRO, intra-frequency Mobility Load Balancing (MLB) objective 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.

BENEFITS
The objective of MRO is to dynamically improve the network performance of HO in order to provide improved end-user experience as well as increased network capacity. This is done by automatically adapting cell parameters to adjust handover boundaries based on feedback of performance indicators. Typically, the objective is to eliminate Radio Link Failures and reduce unnecessary handovers. Automation of MRO minimizes human intervention in the network management and optimization tasks.

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 should be the reduction of the number of HO-related radio link failures. Additionally, sub-optimal 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.

Most problems associated with HO failures or sub-optimal system performance can ultimately be categorized, as either too-early or too-late triggering of the handover, provided that the required fundamental network RF coverage exists. Thus, poor HO-related performance can generally be categorized by the following events:

- Intra-RAT late HO triggering
- Intra-RAT early HO triggering
- Intra-RAT HO to an incorrect cell
- Inter-RAT too late HO
- Inter RAT unnecessary HO

Up to Release 9, a UE is required to send RLF report only in case of successful RRC re-establishment after a connection failure. Release 10 allows support for RLF reports to be sent even when the RRC reestablishment does not succeed. The UE is required to report additional information to assist the eNB in determining if the problem is coverage related (no strong neighbors) or handover problems (too early, too late or wrong cell). Furthermore, Release 10 allows for precise detection of too early / wrong cell HO.

INTRA‐RAT LATE HO TRIGGERING

If the UE mobility is faster than the HO parameter settings allow for, handover can be triggered when the signal strength of the source cell is too low, leading to a RLF. The signature of too-late HOs may be summarized by:

- RLF in the source cell before the HO was initiated or during HO procedure
- Terminal re-establishes in a different cell than the source

The general principles of MRO are based on the RLF and Handover Report messages over the X2 link. After a Radio Link Failure (RLF), the UE provides the RLF information to the cell to which it reconnects after the failure. That cell always forwards the RLF message over the X2 to the cell that actually dropped the UE. The information is analyzed by the cell that receives the RLF, and if required, the results of the analysis are forwarded in a Handover Report over the X2 to the cell that needs to take corrective action.

In the too-late case above, a failure occurs in the handover from eNB1(A) to eNB2(C). The UE reconnects to eNB2(C) and the RLF message is forwarded to eNB1. eNB1 analyses the data and, in this case, determines that the problem is resolved by adjusting thresholds at eNB1(A), specifically relating to its neighbor relationship with eNB2(C). There is no need to send a handover report to any other cell. RLF indication and Handover Report are X2 messages and as such are only relevant in the inter-eNB case. For cells on the same site, similar message structures can be used internally without the need for X2 interfaces.

INTRA‐RAT EARLY HO TRIGGERING

Too-early HO can be triggered when the terminal enters an island of coverage of another cell contained inside the coverage area of the serving cell. This is a typical scenario for areas where fragmented cell coverage is inherent to the radio propagation environment, such as dense urban areas. The signature of too-early HO may be summarized by:

- RLF occurs a short time after the HO trigger to the target cell. The HO may or may not be completely successful, depending on the over-the-air-messaging in the target cell.
- Terminal re-acquires the system in the source cell

In the too-early case above, the UE has contiguous coverage from eNB2(C), but due to a region of strong coverage from eNB1(A), a handover takes place to eNB1(A). As the UE exits this region of coverage, an RLF occurs and the UE reconnects to eNB2(C). eNB2 sends the RLF to eNB1 as eNB1(A) actually dropped the UE. eNB1(A) analyses the RLF and checks the length of time it carried the call. If eNB1(A) carried the call for less than Tstore_UE_cntxt seconds, it then concludes that the UE should not have handed to eNB1(A) in the first place. eNB1 sends a Handover Report to eNB2 and the neighbor relationship from eNB2(C) to eNB1(A) is adjusted such that the UE does not handover to eNB1 in the first place.

INTRA‐RAT HO TO AN INCORRECT CELL

It is possible if the cell-neighbor-pair parameters are set incorrectly that the handover may be directed towards a wrong cell. The signature of HO to a wrong cell is summarized by:
- RLF occurs a short time after the HO trigger to the target cell. The HO may or may not be completely successful, depending on the over-the-air-messaging in the target cell.
- Terminal re-establishes in a different cell than the source or target

It is important to note that the messaging sequence is different depending on whether the original handover is successful. The reconnect cell will always send the RLF message to the cell that dropped the UE. If the handover succeeds, the RLF is sent to the original target cell. If the handover fails, the RLF is sent to the source cell. In either case, the original source cell eventually receives either the RLF or Handover Report messages, and takes the necessary corrective action.

Note this event could also be a case of rapid HO – where the terminal quickly and successfully performs handovers from cell A to B to C. This could be argued as either a too-early case for A-B or simply too-late for A-C.

In above figure, the handover to eNB2(B) succeeded, but failure immediately after that indicates that eNB2(B) was not a good candidate. On reconnect to eNB3(C), the RLF gets forwarded to eNB2(B). eNB2 analyses the RLF and determines that since it carried the call for less than Tstore_UE_cntxt seconds, it was therefore never a good candidate. It then sends a Handover Report to eNB1. eNB1(A) needs to correct its relationships such that eNB2(B) becomes less attractive and eNB3(C) becomes more attractive.

Above figure shows the case where a RLF occurs before handover. In this case, the initial handover attempt to eNB2(B) had not been completed when the RLF occurred. After reconnect to eNB3(C), the RLF is sent directly to eNB1(A) since this is the cell that dropped the call. In this case, as eNB1(A) is both the cell that did the RLF analysis and also the cell that needs to make the correction, it is not necessary to send a handover report to another cell.

Most vendors are likely to adjust the Cell Individual Offset (CIO) in order to correct the MRO problems described here. The CIO is a per neighbor offset applied to measurement reporting configuration such that it changes the point at which a measurement report qualifies to get sent to the eNB. The measurement gets sent to the eNB only after the criteria remains valid for a period of Time-To-trigger (TTT). Because of this relationship, TTT is also sometimes used as one of the MRO adjustment parameters.

INTER RAT TOO LATE HO

Delayed inter-RAT handovers when a UE moves from one RAT to another could result in RLF’s and possibly dropped calls. Inter RAT too late handovers may be detected and reported in two ways. The first option is that the UE reports the RLF to the cell where it connects immediately after the RLF. In this case, the reporting is performed in a different RAT than the cell the UE was connected to before RLF. This requires a new message across RATs in order to transfer the information to the cell where the UE was connected to before HO, since this is where the mobility parameters shall be adjusted.

Another option would be to let the UE send the RLF report when it returns to the RAT where it experienced the RLF, but not necessarily to the same cell. In this case, there is no need to send messages across the two different RATs.

INTER RAT UNNECESSARY (TOO EARLY) HO

The HO target cell (UTRAN or GERAN) is configured with minimum radio quality (of E-UTRAN) thresholds during handover preparation phase. The target cell will instruct the incoming UE to continue to measure the source cell (E-UTRAN) after successful IRAT handover. Based on such threshold, the target cell can detect whether or not the handover has been performed too early and report it back to source cell (E-UTRAN).

Coverage And Capacity Optimization

A typical operational task is to optimize the network according to coverage and capacity. The traditional way is to find the problems by drive tests and use planning tools to find possible solutions. This use case aims at discovering the coverage and capacity problems automatically through the measurements at the eNB and those reported by UEs. It minimizes the human intervention and reduces the feedback delay.

Traditionally, this has been performed based on measurements from the network and using theoretical propagation models in planning tools. It requires extensive data collection from the network including statistics and measurements, such as using extensive drive tests. In current networks, while this task has been semi-automated with the help of Automatic Cell Planning tools, this method is still largely based on measurement estimations. Therefore their results are not very accurate. Furthermore, running such tools is a cumbersome task that requires a significant preparation on the operator side to compile all necessary data inputs, create optimization clusters, and then implement the changes in the network.

Objective:
• Optimization of network coverage
• Maximize the system capacity

Expected results:
• Continuous coverage
• Increased capacity of the system
• Interference reduction
• Controlled cell edge performance
• Savings on drive tests
• Minimized human intervention in network management and optimization tasks
• Self-healing in case of equipment (e.g. eNB) failure by automatic reconfiguration of surrounding eNBs

DESCRIPTION
The term Coverage and Capacity Optimization (CCO) is very generic and covers a broad range of use cases. In reality, many of the SON use cases defined in 3GPP are somehow related to a coverage/capacity optimization effort such as, Cell Outage Compensation, Mobility Load Balancing and the Interaction between Home and Macro eNB. As defined by 3GPP, the CCO use case is understood as automatic cell planning, in which the SON algorithm has to find the optimum antenna and RF parameters for the sectors that serve a certain area for a particular traffic situation. The optimum result should maximize network throughput/capacity while complying with a certain service confidence level, as specified by the operator.

“In the area, where LTE system is offered, users can establish and maintain connections with acceptable or default service quality, according to operator’s requirements. It implies that the coverage is continuous
and users are unaware of cell borders. The coverage must be provided in both, idle and active mode for both, UL and DL. While coverage optimization has higher priority than capacity optimization in Rel-9, the coverage optimization algorithms must take the impact on capacity into account. Since coverage and capacity are linked, a trade-off between the two of them may also be a subject of optimization.”

The term “coverage” could mean coverage of basic service or coverage of user services. Basic service includes reception of DL control channels and setting up a signaling radio bearer. User services refer to services such as speech, video telephony, etc. The term “capacity” could have various interpretations. There are several options for capacity, e.g., cell throughput, median user throughput, xth-percentile cell edge throughput, and number of served users (with a specific service or bit rate requirement).

There is a tradeoff between coverage and capacity. Typically, increasing the coverage results in less spectral efficiency due to deteriorating signal power, resulting in less capacity. One cannot optimize both coverage and capacity at the same time, and therefore there is a need to balance and manage the tradeoff between the two.

The self-optimizing CCO function is a continuously running process which continuously gathers measurements and takes actions, if needed. The operator can specify the desired performance optimization target and the balance between different targets to achieve tradeoffs. Measurements and reports from the network are used by CCO to estimate entities related to coverage and capacity according to the target given by the operator. Minimization of Drive Test reports may be used to monitor and detect coverage problems in the network.

CCO corrective actions comprise changes in radio parameters such as, antenna tilt and UL power control parameters. Deployment of pico cells or coverage/capacity enhancing features are also corrective actions that may be proposed by CCO to reach desired target. The CCO should not react to performance of individual users, but rather compute appropriate CCO actions based on long-term statistics.

As with other aspects of SON development, it is expected that coverage and capacity optimization techniques will change over time, adapting to the maturity level of the networks. In the initial stages of commercial LTE network operation, traffic load will not be a major concern, and it is expected that there will be coverage challenges due to lack of sufficient cell density or configuration errors. Therefore, CCO techniques will primarily be focused around providing service coverage with a certain minimum quality.

The coverage area and capacity of a network, or some cells in the network, may vary due to addition of base stations, malfunctioning base stations, or change in user distribution. Suboptimal coverage area and capacity leads to inefficient use of network resources and lower quality. Furthermore, adapting to network changes manually is very expensive and time consuming. Thus, the CCO function operates continuously to gather measurements and takes actions if needed. CCO should be a slow activity where statistics and measurements are used as basis for decision.

3GPP TS 32.521 specifies the following requirements on CCO:

• Coverage and capacity optimization shall be performed with minimal human intervention.
• Operator shall be able to configure the objectives and targets for the coverage and capacity optimization function.
• Operator shall be able to configure the objectives and targets for the coverage and capacity optimization functions differently for different areas of the network.
• The collection of data used as input into the coverage and capacity optimization function shall be automated to the maximum extent possible and shall require minimum possible amount of dedicated resources.

The 3GPP specifications provide a set of use cases that the CCO function should cover. These use cases are defined in a very generic manner, and simply indicate that the system should have functionality that addresses these particular issues, without providing further guidelines. The following sections describe the specified scenarios.