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.

Mobility Load Balancing Optimization

MLB is part of the self-organizing network concept, which was introduced in LTE. By applying MLB in the network, gains in terms of higher network performance and a decreasing number of unsatisfied users are the optimization goal. This is supposed to be achieved by reducing highly loaded cells in the network. Usually the MLB monitors the cell load values and tries to distribute the traffic of highly loaded cells among less loaded neighbouring cells in the network.

Mobility load balancing (MLB) is a function where cells suffering congestion can transfer load to other cells, which have spare resources. MLB includes load reporting between eNBs to exchange information about load level and available capacity.

The periodicity of the reporting can be requested in the range of 1 to 10 s. The report can contain, hardware load, S1 transport network load and Radio resource status. The Radio resource status reports are separated in Up Link and Down Link reports, including the total allocation guaranteed and non-guaranteed bit rate traffic, the percentage of allocated Physical Resource Block (PRB) and the percentage of PRBs available for load balancing.

MLB can also be used between different Radio Technologies. In case of inter-RAT the load reporting RAN Information Management (RIM) protocol will be used to transfer the information via the core between the base stations of different radio technologies. A cell capacity class value, set by the OAM-system, will be used to compare and weigh the different technologies radio capacities against each other.

A handover due to load balancing is carried out as a regular handover, but it may be necessary to amend parameters so that the User Equipment (UE) does not return to the congested cell. The amendment must take place in both cells, so that the handover settings remain coherent in both. The eNBs need to estimate how much the cell border needs to be shifted, expressed in dB, to avoid a quick return of the UE.

The objective of Mobility Load Balancing is to intelligently spread user traffic across the system’s radio resources as necessary in order to provide quality end-user experience and performance, while simultaneously optimizing system capacity. Additionally, MLB may be desirable to shape the system load according to operator policy, or to “offload” users from one cell or carrier in order to achieve energy savings. The automating of this minimizes human intervention in the network management and optimization tasks.

DETERMINING A LOAD IMBALANCE CONDITION

Load balancing mechanisms must work together with the scheduler and admission control. For non-Guaranteed Bit Rate (GBR) users, there is no constraint on the minimum performance those users receive except within the scope of the maximum number of users per cell (admission control) and perhaps a vendor-imposed minimum throughput (scheduler). For GBR users, the scheduler must ensure that all radio bearers are granted resources in a manner that satisfies their specific service. Therefore, a system may be considered “in balance” as long as there are no users being denied resources and all active services are being supported within the scope of their QoS needs.
Simple thresholds can be implemented where low, medium and high load conditions equate to a given number of active users in the cell for the non-GBR case. These can serve as triggers to modify idle mode parameters and/or to handover active users to neighbors (i.e. cell-edge intra-carrier, collocated intercarrier or collocated inter-technology handover). However, more intelligent metering is needed for GBR users since it is possible for a small number of such users to “load” a cell depending upon their requirements.

IDLE MODE LOAD BALANCING

The LTE system does not have a real-time, per-cell view of idle mode users. The only time the system becomes aware of the exact cell a user is in, while in idle mode, is when the Tracking Area of the user changes and a TAU 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. Note that this “too-many idle user condition” has no direct bearing on either system capacity or user experience besides increased signaling on core network nodes.

The way around this immeasurable condition is for the system to adjust cell reselection parameters for the idle users based on the current active user condition. As real-time traffic and/or QoS demands increase in a cell, it would be possible for the cell to adjust the cell reselection parameters in order to force users nearest the cell edge to select their strongest neighbor to camp on, or to force a handover to a co-located carrier that has more resources available. Care must be taken to coordinate such parameter adjustments between cells (i.e. utilizing the X2 interface) in order to prevent service-outage holes, as well as to adjust active mode parameters to avoid immediate handover upon an idle to active transition. In LTE, idle mode inter-frequency load balancing is controlled by the cell reselection procedure. System parameters that control cell reselection and the operator's channel frequency preferences are transmitted to UEs in the System Information Blocks (SIBs).

ACTIVE MODE LOAD BALANCING

Active load balancing allows active mode UEs to be load balanced across cells to lower the overall congestion across cells. The advantage of active load balancing is that the system has a direct measurement mechanism and knowledge of each user’s traffic requirements and radio conditions before deciding to load balance. Therefore, in conjunction with the scheduler and interfaces to other base stations (X2 interface for intra-LTE and/or S1 interface for inter-RAT), it is possible to make accurate decisions for load-based HO. A “load-based HO” reason code is included during handover (HO) messaging to allow the target cell knowledge for admission control.

1. INTRA-LTE MOBILITY LOAD BALANCING

Intra-LTE mobility load balancing refers to a load balanced handover within the current LTE network, typically utilizing the X2 interface to exchange load reporting information, to geographically neighboring cells or co-located cells on a different carrier frequency.

The load information consists of:

• Radio Resource Usage
  o Uplink/Downlink Guaranteed Bit Rate (GBR) Physical Resource Block (PRB) usage
  o Uplink/Downlink non-GBR PRB usage
  o Uplink/Downlink total PRB usage
• Hardware (HW) load indicator
  o Uplink/Downlink HW load: Low, Mid, High, Overload
• Transport Network Load (TNL) indicator
  o Uplink/Downlink TNL load: Low, Mid, High, Overload
• Cell Capacity Class value (Optional)
  o Uplink/Downlink relative capacity indicator
• Capacity value
  o Uplink/Downlink available capacity for load balancing as percentage of total cell capacity

2. INTER-RAT MOBILITY LOAD BALANCING

Inter-RAT MLB refers to a load balanced handover between LTE and another network, utilizing the S1 interface to exchange load reporting information. In the event the handover is to non-3GPP technology, then load reporting on the relevant interfaces still need to be standardized.

A dedicated procedure for inter-RAT cell load request / reporting is provided with minimal impact using a generic SON container extension of the RAN Information Management (RIM) mechanism. Load information is provided in a procedure separated from existing active mode mobility procedures, which is used infrequently and with lower priority with respect to the UE dedicated signaling.

The load information consists of:

• Cell Capacity Class value
  o Uplink/Downlink relative capacity indicator
• Capacity value
  o Uplink/Downlink available capacity for load balancing as percentage of total cell capacity

ADAPTING HANDOVER CONFIGURATION

The adaptation of handover configuration function enables requesting of a change of handover and/or reselection parameters at target cell, as a part of the load balance procedure. The source cell that initialized the load balancing estimates if the mobility configuration in the source and/or target cell needs to be changed. If the amendment is needed, the source cell initializes mobility negotiation procedure toward the target cell. This is applicable for both idle and active mobility cases.

The source cell informs the target cell about the new mobility settings and provides cause for the change such as, load balancing related request. The proposed change is expressed by as the difference (delta) between the current and the new values of the handover trigger. The handover trigger is the cell specific offset that corresponds to the threshold at which a cell initializes the handover preparation procedure. Cell reselection configuration may be amended to reflect changes in the handover setting. The target cell responds to the information from the source cell. The allowed delta range for handover trigger parameter may be carried in the failure response message. The source cell should consider the responses before executing the planned change of its mobility setting. All automatic changes on the HO and/or reselection parameters must be within the range allowed by OAM.

CELL OUTAGE DETECTION AND COMPENSATION

Cell Outage Detection and Compensation provides automatic mitigation of eNB failures especially in the case where the eNB equipment is unable to recognize being out of service and has therefore failed to notify OAM of the outage. Detection and Compensation are two distinct cases that cooperate to provide a complete solution.

Cell Outage Detection typically combines multiple separate mechanisms to determine whether an outage has occurred. This is needed to detect the latent fault case, often described as ‘Sleeping Cell’, where OAM is unaware of the issue. If a cell continues transmitting but does not accept RACH access or hand-ins, it will simply generate interference. The most immediate mitigation available is to stop that cell from transmitting. OAM aspects are addressed in detail in 3GPP 32.541.

Cell Outage Compensation techniques are generally only applied after standard soft recovery techniques have failed to restore normal service. Cell Outage Detection uses a collection of evidence and information to determine that a cell is no longer working correctly. Detection includes active notification to cover the generalized case in which OAM is aware of the fault.

BENEFITS
Detection and Compensation provide distinct benefits to the Operator. Previous generations of cellular infrastructure have experienced failures of which Operators had no knowledge until such time as receiving notification from customer support of problems in the field. Cell Outage Detection ensures that the operator knows about the fault before the end user does.

Cell Outage Compensation provides temporary alleviation of the problem caused by the loss of a Cell from service. Compensation mode alleviates the outage, but the level of service provided to users in the affected area is likely to be restricted by local topology, distance from neighboring serving cells and available capacity.

CELL OUTAGE DETECTION
Cell Outage Detection uses a collection of evidence and information to determine that a cell is no longer working correctly. Detection includes active notification to cover the generalized case in which OAM is aware of the fault.

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 have other evidence to determine the nature of the problem. If the cell is still in service, it will continue to interact with the core network, so the Network Manager should be able to determine from core network metrics whether there is ongoing interaction with a specific eNB or cell.

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. This may be enhanced using a set of “Cell Type” specific rules where all cells of a specific type use a separate or additional policy. 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 stats over a period of time and gradually building a statistical picture of expected performance for a given time of day, weekday, or weekend. When stats collected for a cell deviate significantly from values normally seen for that cell, then there is a likelihood of a latent fault.

CELL OUTAGE COMPENSATION
Before considering the many complex reconfigurations available to ensure that neighboring cells provide service in the area affected by cell outage, it is important to understand that in most urban cases, the majority of external users are likely to have at least a minimum level of service from those neighboring cells even without any reconfiguration.

There are three main areas that need to be addressed in trying to improve on the existing default Cell overlap.
1. Neighbors
With a given cell out of service, it is essential that neighboring cells on opposite sides of the outage are configured as neighbors. In most cases, this relationship is likely to exist by default, since most neighbor planning, both manual and automatic, tends to include a second ring of neighboring cells and not just those on the immediate border. It may also be advantageous to enable the Automatic Neighbor Relationships use case (ANR) on cells surrounding the outage to ensure that no essential relationships are missed. In most cases, neighbors that are added to enable support of a neighboring cell outage will not subsequently need to be deleted after normal service has been restored.

2. Physical Layer Cell Identities (PCIs)
The implicit change in neighbor relationships in the case of an outage, also requires a recheck of the rules relating to PCIs.

- A cell and its neighbor must not have the same PCI.
- Neighbors of a given cell must not share the same PCI.

By revalidating the PCIs in the same way that the operator used to recheck the neighbors, one can ensure that neither of these rules is broken. As in the case for new neighbors, it is generally advantageous to plan PCI allocation for worst case as represented by a cell providing coverage for a neighbor’s outage.

3. Coverage Footprint
There are three methods for adjusting a cell’s coverage footprint:

a. Handover Parameter offsets
It is possible within limits to adjust a cell’s handover boundary with an immediate neighbor through change of cell individual offsets (CIO) or similar parameters, however this has no relevance in the case of adjusting coverage in the direction of a Cell Outage.

b. Transmit Power
Transmit power has an immediate impact on the cell boundary, however, most cell planning makes maximum use of available power, leaving very little positive headroom to enable a cell to increase its coverage in the direction of a neighboring outage.

c. Antenna adjustment
Most discussions on cell outage coverage adjustment focus on change of antenna pattern to achieve the additional coverage for the neighbor. In most cases, changes are achieved with antenna tilt, i.e. alteration of the vertical pattern. However, newer antenna technology enables many complex adjustments of the coverage pattern on demand. There are industry collaborations between Radio Planning Tool vendors and Antenna manufacturers in which Beam-Shaping adjustment is guided by data from the Radio Planning Tool.

The real challenge with use of antenna pattern adjustment in support of any SON features, is ensuring there is a control loop to guarantee that antenna adjustment to improve coverage in one area, doesn’t either worsen coverage or create too much interference in another area. SON needs to collect sufficient measurements to profile the impact of antenna pattern adjustment. The goal for SON is to converge to a point where a cell outage results in each of the surrounding cells adjusting their patterns by an amount that is preconfigured for that specific neighbor relationship to shrink the coverage hole that was created.

Above figure represents the generalized case of Cell Outage Detection and Compensation. It separates the roles of Cell Outage Detection, Fault Management (FM) and Cell Outage Compensation. The specific details will vary significantly between implementations. However, it is expected that detection would be based on the following generic data to address those cases where the RAN OAM path is down but the Network Elements are functional:

- FM information for conventional alarmed failures;
- Statistics for detection of latent fault conditions;
- Neighbor reports to help detect latent failures, and
- Core statistics to catch those cases where the RAN OAM path is down but the Network Elements remain functional.

Cell Fault conditions are passed to normal FM procedures. Some vendors or operators may choose to do this manually. Cell Outage Compensation technique is utilized when a fault cannot be resolved remotely in a few minutes. During Cell Outage Compensation, SON will continue to monitor the impacted cell and once advised that it is ready for service, it will re-initialize the cell and back out the compensation.