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.

RACH Optimization

The configuration of the random access procedure has a critical impact on end-user experience and overall network performance. A poorly configured Random Access CHannel (RACH) may increase access setup time and accesses failures, impacting both call setup and handover performance. With optimal random access parameter setting, maximum end-user experience can be obtained. This is achieved by reaching the desired balance in the radio resource allocation between random accesses and services while at the same time avoiding creating excessive interference. To keep the RACH optimized for all cells during varying conditions, the optimization can be repeated periodically or run continuously.

In LTE, RACH (Random Access Channel) is an uplink unsynchronized channel, used for initial access or uplink synchronization. The triggers for Random Access procedure include:

• Connection setup
• Radio Link Failure
• Downlink data transmission in uplink unsynchronized state
• Uplink data transmission in uplink unsynchronized state
• Handover

So the Random Access procedure performance influences the call setup delay, handover delay, data resuming delay, call setup success rate and handover success rate. Besides, physical resources for RACH are reserved for its special use. So the configuration for RACH influences the capacity of the whole network.

An optimized RACH configuration enables end-user benefits and network performance gains through:

• Reduced connection time
• Higher throughput
• Better cell coverage.

By automating the optimization of RACH, maximum performance is achieved with no operator intervention or effort. The network will dynamically adapt to network changes and end-user behavior to always deliver best possible performance and resource utilization.

Necessity for RACH optimization
The performance of Random Access performance is evaluated by its delay and success rate. The performance depends on following factors:

• Population under the cell coverage;
• Call arrival rate;
• Incoming handover rate;
• Whether the cell is at the edge of a tracking area;
• Traffic pattern, as it affects the DRX (Discontinuous Reception) and uplink synchronization states, and hence the need to use RACH.

These factors are affected by network configurations, such as antenna tilt, transmission power and handover threshold, and also by the load of network. If network configurations or load is changed, the performance of Random Access procedure may change greatly, which influences the performance of other procedures, such as call setup, data resuming and handover. Therefore the automatic optimization of RACH would be beneficial.

Possible RACH optimization algorithm The configurations of RACH include:

• RACH physical resources
• RACH preamble allocation for different sets (dedicated, random-low and randomhigh)
• RACH persistence level and backoff control
• RACH transmission power control

Measurements are done in eNB, recording random access delay, random access success rate and random access load. The random access load can be indicated by the number of received preambles in a cell in a time interval. It is measured per preamble range (dedicated, random-low and random-high), and averaged over the PRACHs configured in a cell.

Thresholds are set separately for random access delay and success rate. If either of the thresholds is reached, RACH optimization is triggered. First, Random access load is analyzed to check if the random access is overload in any of the three preamble ranges. If one of them is overload, RACH preambles are reallocated among these three preamble ranges. If all of them are overload, more physical resources need to be reserved for RACH. If none of them is overload, other parameters need to be adjusted, such as increasing the transmission power step and distributing the backoff time in a wider range.

Description

A User Equipment (UE) in idle state is unknown to an LTE network. In order to start establishing a relation to the LTE network, the UE searches for the most suitable cell and reads its broadcast system information. The broadcast system information (SIB2) from the cell provides the UE with cell-specific random access format and procedure details. These details determine essential parameters, such as preamble format and initial power setting. The UE randomly selects one of the preambles in an attempt to establish a relation to the cell. As long as no other UE is using the selected preamble at the same time instant, the access attempt can succeed. The success also relies on that the preamble can be heard and identified by the eNB. If there is no response or rejection from the eNB, the UE needs to retry until it succeed. The impact on user experience during the random access procedure is mainly delayed access and interrupted transmission during a handover. The automatic RACH optimization function will balance between optimal access performance and least resource utilization needed to meet set quality target such as, an acceptable level of access success rate. By selecting the most suitable preamble format, based on say traffic type, and dynamically adjusting the broadcast power control parameter (P0), the access success rate can be optimized while still maintaining a low interference level. This results in best user experience with fast access and best possible throughput.

The automatic RACH optimization function can be executed continuously resulting in RACH related parameters being modified automatically. The changes could be based on inputs from both the connected UEs and each cell’s neighboring cells. By collecting the recently introduced RACH report from the UE, the actual access delay can be determined. The RACH report is included in the message UEInformationResponse (3GPP Rel-9 spec TS 36.331). It contains two new parameters: numberOfPreamblesSent and contentionDetected. Based on this new information, the automatic RACH optimization function can adjust the power control parameter (P0) or change the preamble format to reach the set target access delay. By optimizing P0, the probability for an eNB to read the preamble increases. However, as a result, the interference on neighboring cells may also increase. The second option adjusts the preamble format to use, under the premise that a correct preamble format assures successful preamble detection for the traffic type in a cell.

The automatic RACH optimization function automates the required continuous adaptation of the RACH. The automatic RACH optimization function can automatically react when receiving notification over X2 of a RACH parameter change in a neighboring cell. The information is transmitted via the eNB configuration update X2 message. For instance, allocation of same root sequence index in neighboring cells should be avoided to reduce interference. Automatic RACH optimization, based on the optimization on real traffic data and neighbor cell information, makes it well suitable for eNB function localization. The automatic RACH optimization function can execute autonomously with no operator intervention or effort. The operator controls the function with a few policies that set the outer limits for the function. These limits assure that the function will not move to an extreme setting when finding the best tradeoff between access delay and resource utilization.

Energy Savings

Mobile network operators are increasingly aiming at decreasing power consumption in telecom networks to lower their OPEX and reduce greenhouse emissions with network energy saving solutions for long term sustainable development. With the expected deployment of large numbers of mobile network radio equipment, in the form of Home NB/eNBs, OPEX reduction becomes even more crucial.

Energy consumption is a significant part of an operator’s OPEX. OPEX reduction can be accomplished by designing network elements with lower power consumption and temporarily shutting down unused capacity when not needed. Power amplifiers consume a significant portion of the total energy consumption in a wireless network.

When a cell is switched off, there may be a need for the neighboring cells to pick up the load. However switching off a cell should not cause coverage holes or create undue load on the surrounding cells. A switched off cell is not considered a cell outage or a fault condition. All traffic on that cell is expected to be moved to the underlying umbrella cells before any switch off occurs.

When a NE is "switched off" for energy savings purposes, no alarms should be raised to the OAM manager for a condition that is a consequence of a "switched off" NE. The operator should have the capability to prevent the network from automatically compensating based on the cell that is in energy savings mode in order to prevent unnecessary disruption in the network.

OAM of mobile networks can contribute to energy saving by allowing the operator to set policies to minimize consumption of energy, while maintaining coverage, capacity and quality of service. The permitted impact on coverage, capacity and quality of service is determined by an operator’s policy.

3GPP Rel-11 has defined two energy saving states for a cell with respect to energy saving namely: notEnergySaving state and energySaving state.Based on the above energy saving states, a full energy saving solution includes two elementary procedures: energy saving activation (change from notEnergySaving to energySaving state) and energy saving deactivation (change from energySaving to notEnergySaving state).

When a cell is in an energy saving state it may need neighboring cells to pick up the load. However, a cell in energySaving state cannot cause coverage holes or create undue load on the surrounding cells. All traffic on that cell is expected to be drained to other overlaid/umbrella cells before any cell moves to energySaving state.

A cell in energySaving state is not considered a cell outage or a fault condition. No alarms should be raised for any condition that is a consequence of a network element moving into energySaving state.
Criteria for the energySaving state is defined in 3GPP namely: degree of energy saving effect, controllability from the network, and service availability.

The various Energy Savings Management (ESM) concepts can apply to different RATs, for example UMTS and LTE. However, 3GPP has specified that some of these ESM concepts may be limited to specific RATs and network elements, and specific solutions may be required for them.

In Rel-11, three general architectures that are candidates to offer energy savings functionalities are described, namely: distributed, network management centralized, and element management centralized. Energy savings management use cases such as the cell overlay use case and the capacity limited network use case, are described in detail. Requirements for element management centralized energy savings and distributed energy saving are specified. Coordination between energy saving and cell outage is addressed.

ICIC - Fractional Frequency Reuse

Interference management techniques are critical to the performance of heterogeneous cellular networks, which will have dense and overlapping coverage areas, and experience high levels of interference. Fractional frequency reuse (FFR) is an attractive interference management technique due to its low complexity and overhead, and significant coverage improvement for low-percentile (cell-edge) users. FFR sets restrictions on RB allocation between the different UEs in each cell.

FFR method separates the frequency bands allocated to the areas near a base station where no signal interference from adjacent base stations occurs from the frequency bands allocated to the areas far from the base station where signal interference from an adjacent base station can occur. The transmit power is reduced and the frequency-reuse factor is set to 1 for the frequency band allocated to the cell area where no signal interference from adjacent base stations occurs, and conversely, the transmit power is increased and the frequency-reuse factor is set to 3 for the frequency band allocated to the cell area where signal interference from an adjacent base station can occur. This improves the signal to interference plus noise ratio (SINR) and throughput for users located at the cell edge without degrading spectral efficiency.

To implement FFR, the frequency band allocated to a user at a cell edge must be different from that allocated to another user in the adjacent cell, as shown in Figure above . The LTE standard specifies an inter-base-station interface that enables adjacent base stations to exchange information on bands generating large interference in other cells and on bands that are affected by large interference from other cells.

The following describes interference-coordination signals that can be used for implementing ICIC in the downlink and uplink.

1) Downlink
The signal used for interference coordination in the downlink is called relative narrowband transmit power (RNTP). This signal can take a value of 0 or 1 and is sent to multiple base stations serving adjacent cells for each resource block (RB).note 2) Specifically, this value is set to 0 if the ratio between the transmit power of the downlink signal allocated to the RB and the average transmit power of the system frequency band is guaranteed to be under a certain threshold and to 1 otherwise.3) This scheme enables a base station to learn about an RB that may be transmitting at high power in an adjacent cell and to reduce interference by avoiding allocating that RB to a user experiencing poor reception. Increasing the transmit power above the system average for a user experiencing poor reception should also improve the quality of that users reception.

2) Uplink
There are two types of signals for interference coordination in the uplink: high interference indicator (HII) and interference overload indicator (OI). The HII signal is used by a base station to notify to multiple base stations serving adjacent cells of the uplink RB it has allocated to a cell-edge user. This enables cell-edge users in adjacent cells to be allocated different bands, the same as in the downlink approach, which means that improved throughput can be expected for these cell-edge users. The OI signal, on the other hand, is used by a base station to notify to multiple base stations serving adjacent cells the results of measuring interference power for each RB and classifying those results into multiple levels. Thus, the base station of a cell that receives notification of high interference power from an adjacent cell can reduce the transmit power of its users and thereby reduce the amount of interference created in the adjacent cell.

Reference 

Inter-Cell Interference Coordination (ICIC)

LTE uses OFDMA in downlink and SCFDMA in uplink. The inherent orthogonality of these transmission schemes reduces the intracell interference. The problem of intercell interference impacts the UEs at cell edges because as the frequency is reused across the cells, the edge UEs may be allocated the same subcarriers. As these UEs operate on high power to reach the eNBs, the signals interfere strongly. The edge UEs receive equally strong/weak signals from the adjacent cells, and so the strong interference causes difficulty for the UE when receiving downlink transmission.

Interference is caused because cells only know what radio resources their own UEs are using, and not what other UEs in the neighbor cells are using. For example, in the figure above, Cell A knows what resources A1 is using, but not about what B1 is using, and vice versa. And the cells independently schedule radio resources for their own UEs. So, to the UEs at cell edges (A1 in Cell A and B1 in Cell B), same frequency resource can be allocated.

As seen in the figure below, if the two UEs are located in cell centers like A2 and B2, no interference is caused because they use low power to communicate. However, if they are at cell edges like A1 and B1, their signals cause interference for each other because the two use high power to communicate.

ICIC reduces inter-cell interference by having UEs, at the same cell edge but belonging to different cells, use different frequency resources. Base stations that support this feature can generate interference information for each frequency resource (RB), and exchange the information with neighbor base stations through X2 messages. Then, from the messages, the neighbor stations can learn the interference status of their neighbors, and allocate radio resources (frequency, Tx power, etc.) to their UEs in a way that would avoid inter-cell interference.

For instance, let's say a UE belonging to Cell A is using high Tx power on frequency resouce (f3) at the cell edge. With ICIC, Cell B then allocates a different frequency resource (f2) to its UE at the cell edge, and f3 to its other UE at the cell center, having the one at the center use low Tx power in communicating.

Inter Macro Cell Interference

The interference problem gets even more complicated in small cells, wherein the small cell overlaps the macro cell. As the small cell eNBs operate at a lower power level, the problem extends to ensuring that a UE actually attaches to small cell eNB in proximity, rather that attaching to a macro eNB operating at high power. In this case, the cell edge is the point where the UE receives similar strength signals from both the macro and small cell.

Inter Macro-Small Cell Interference

Smallcell-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 small cells will be small. But UEs receiving signals with larger SINR from a macro eNB might have much lower path loss to a small cell eNB and hence cause significant uplink interference to the small cell eNB.

If not placed specifically in a hot-spot, only a small number of UEs will be connected to the small cell-eNB which will limit the gain from offloading the traffic from the macro cells. One way to improve this is to expand the small-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.

Automatic Neighbour Relation (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. It 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 and the development of small cells further increases the number of neighbor relations; thus optimization of neighbor relations may be more complex. Even with the best methods at hand, due to the sheer size of large radio networks – with several hundred thousands of neighbor relations for a single operator – it is a huge undertaking to maintain the neighbor relations manually.

Neighbor cell relations are therefore an obvious area for automation, and Automatic Neighbor Relation (ANR) configuration 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 is, therefore, one of the first SON functions to be standardized in 3GPP.

Furthermore, the anticipated massive deployment of smallcells, such as femtocells or picocells, as part of moving towards a heterogeneous network (HetNet) deployment strategy will push the ANR functionality, because the manual management of neighbor relations between cells will become even more challenging if not impossible.

BENEFITS

ANR will remove, or at least minimize, the manual handling of neighbor relations when establishing new eNBs and when optimizing neighbor lists. This will increase the number of successful handovers and lead to less dropped connections due to missing neighbor relations.

Description
The ANR in LTE allows automatic discovery and setup of neighbor relations when a user (UE) moves from a serving eNB to another (target) eNB. ANR also automatically sets up of the LTE unique X2 interface between eNBs, primarily used for handover. There are two LTE distinctive functions that make ANR possible:

1. The UEs in LTE do not require a neighboring list and the reporting of unknown cells is fast enough to be used during handover preparation. It enables ANR to receive handover measurements on unknown cells that are not yet known by the serving eNB.

2. The possibility for the eNB to request the UE to make a full identification of a cell. It allows eNB to determine an unambiguous identity of a neighboring cell.

NEIGHBOR RELATION DISCOVERY

The UE is ordered to report measurements to the serving eNB directly after the RRC connection is set up (i.e. is attached to the cell) and continues to do so while staying in RRC connected mode. The UE reports all detected PCIs (Physical Cell Identities) – the short identity of the LTE cell – that fulfill the measurement criteria set by the eNB at RRC connection. The UE may also measure on legacy radio technologies if it supports multi-mode operation. If there is an unknown cell included in the measurement report then ANR may begin actions to make the cell known and potentially enable handover to the cell.

ANR ACTIONS

If a PCI is reported by a UE that does not correspond to any of the serving eNBs’ defined neighbor cells (i.e. it is not a neighbor cell), the ANR function in the serving eNB may request the UE to retrieve the Global Cell Identity (GCI) of the cell with the unknown PCI in order to identify the cell. This cell is from now called target cell (see figure 4 above). The UE reads the GCI, which is broadcast by the target cell and reports it to the serving eNB. When the serving eNB receives the GCI, it can – with help from MME, one part of SAE – retrieve the target eNB’s IP address, which makes it possible for the serving eNB to contact the target eNB. The serving and target eNBs are now in contact with each other and X2 can be setup. The serving eNB requests X2 setup to the target eNB and includes all necessary cell data to create a neighbor relation (i.e. PCI, GCI, TAC, PLMN-id and frequency) from the target cell to the serving cell. The target cell adds the serving cell to its neighbor list and the target eNB sends the corresponding data for the target cell (PCI, GCI, TAC, PLMN-id and frequency) to the serving cell which in turn adds the target cell to its neighbor list.

With the X2 interface in place, it is possible to use X2 for all future handovers between the cells. For handover from LTE to legacy systems (i.e. GSM and WCDMA), ANR works in the same way with the exception that it only needs to setup a neighbor relation to the target cell and not the X2 since the handover to non-LTE systems is always performed over S1. ANR can automatically remove unused neighbor relations based on the relation usage, handover performance or a combination thereof. When adding and removing neighbors, ANR is under control of policies set by the operator. The black listing allows the operator to decide neighbor relations that ANR may never add as neighbors. The white listing allows the operator to decide permanent neighbor relations that ANR may never remove. These policies are controlled from an Element Management System (EMS) such as OSS.

The goal of ANR is to manage neighbour relation. Since OAM also has some restrictions on neighbour relation due to the requirements of operators, ANR also needs to consider the restrictions from OAM. So how to describe the neighbour relation based on the restrictions and how to manage the neighbour relation is a question of implementation. Below figure gives an example of possible ANR solutions. Here the neighbour relation is described by Neighbour Relation Table. The table composes of two parts. The left part is the list of Neighbour Relation according to the measurement report. The right part is the Neighbour Relation Attributes controlled by OAM. The attributes include: No Remove, No Handover and No X2. The left part will be updated according to measurement report and the right part will be updated according to OAM commands.

Within ANR, it is divided into three functions: Neighbour Removal Function, Neighbour Detection Function and Neighbour Relation Table Management Function. The first two functions decide whether to remove an existing Neighbour Relation or to add a new Neighbour Relation. The third one is responsible for updating the Neighbour Relation Table according to the input of the previous two functions and OAM.

The Neighbour Relation Detection procedure -  instructs RRC to measure the cells on some certain frequency or in another RAT.
1. RRC forwards the measurement reports to Neighbour Detection Function.
2. Neighbour Detection Function decides to add a new Neighbour Relation.
3. Neighbour Relation Table Management Function updates the Neighbour Relation Table.
4. Neighbour Relation Table Management Function sends the updated Neighbour Relation through some standard interface to OAM.
5. OAM will ask Neighbour Relation Table Management Function to update the Neighbour Relation Attributes if necessary.

The Neighbour Relation Removal procedure is similar - neighbour Removal Function receives internal information, such as many times of handover failure to a certain cell.

1. Neighbour Removal Function decides to remove the cell from the neighbour list.
2. The following steps are the same as the detection procedure. The Neighbour Relation Table will be used by eNB for other functions, such as handover and X2 setup.

Physical Cell ID (PCI)

Brief

In mobile networks, approximately 2/3 and more than 70% of calls and data service respectively, have been done indoor, hence it is important for mobile network providers to provide a good indoor signal for voice, video and data. Yet, the result of a survey showed that users have suffered from poor indoor coverage signal and data service quality. These dissatisfaction will increase in the case of fourth generation broadband mobile, such as LTE, due to the high frequency that used in such technology where that leads to higher attenuation losses occurs during walls penetration for indoor users. Hence the need of robust solution is essential.

Small cell or Home evolved Network Base station (HeNB) suit the choice to overcome such problems. However due to the femtocells ability of turning on/off and changing their position, the classical network design schemes for configuring and optimizing femtocell networks are not feasible. Furthermore, most of femtocells users have no technical experience background, hence it is essential for the femtocell units to able to operate autonomously with the capability of self -integration with the radio networks that already existed to avoid any undesirable effects on the communication systems created by the new femtocell.

LTE network needs not only good RSRP levels, but also high Signal to Interference plus Noise Ratio (SINR). If PCI is not planned well, it will cause high interruption of the Reference Signal (RS). This situation may then result in an effective lack of signal coverage. Physical Cell ID (PCI) is one of the most important cell’s identifier in the wireless network of LTE system. Therefore, PCI planning is one of the most important steps in LTE network planning and construction. To assign PCI correctly and efficiently will increase resource utilization and QoS of the LTE system for subscribers. Poor planning results in PCI conflicts or collisions which impact network performance.

Physical Cell Identity(PCI)

PCI is used by User Equipment (UE) to identify a specific small cell. In addition ,PCI is one of the most important parameters in the configuration process in SON. Moreover, the number of unique PCIs that been supported in macrocell is 504 due to the needs of compatibility with legacy base station.For that, reuse PCIs is normal ,for example consider that our task is deploying a LTE network in an urban area that needs 1500 cells, where each of the 1500 cells have to have their own cell ID ,however since there are only 504 physical cell IDs (PCI), then reusing the PCIs is inevitable, where in this case, each PCI must be used for three times .Moreover, the three cells that share the same PCI must not be geographically close to each other, and by not doing so that may bring along with it an interference problems.

PCIs, or Physical Cell Identifiers, in LTE networks provide a psuedo- unique value for identifying eNodeBs. The PCI value is created from two components - PSS and SSS. The PSS, Primary Synchronization Signal, has the value 0, 1, or 2. The SSS, Secondary Synchronization Signal, can have a value between 0 and 167. The PCI value is [(3x SSS)+(PSS)], resulting in a value between 0 and 503. With only these 504 values, PCIs are reused in the network and planning reuse, reuse strategy, options, etc is a study all unto itself.

PCI Collision
A UE is in the coverage of two cells which has the same PCI value. This is illustrated in below figure. PCI Collision occurs when two direct neighbor cells have same PCI as serving cell. TS 36.902 defines “collision-free” : PCI is unique in the cell area that it covers. Hence UE may not be able to access either of the two cells due to the interference generated.

PCI Confusion

PCI Confusion occurs when a eNB discovers two neighbors with the same PCI value. TS 36.902 defines “confusion-free”: a cell shall not have neighbouring cells with identical PCI. PCI confusion may lead to high number of handover failures and call drops.

Standard Approach

The assignment of the Physical Cell Identity (PCI) is one of the first SON techniques that have been tested and deployed in commercial networks. This feature comprises two different use cases, one when a eNB is deployed and activated for the first time, in which case there is a planning function involved during the Self-Configuration stage and a second use case, that runs continuously when the network is operational, and whose objective is to optimize the performance and resolve possible PCI collisions.

To achieve collision- and confusion-free assignments, the LTE-Standard approach is proposed through the released 8 of the 3GPP standard.

• A base station tries to get a valid range of PCls from the OAM. The list of returned PCls depends on the location of the deployment and the operator's planning policies.
• The base station performs neighbor discovery through a broadcasting mechanisms (REM /NMM) to detect the PCls of its neighbor cells, thus avoiding selecting these PCls.
• The X2 interface enables neighbors to exchange a neighbor relation table that contains information about neighbors of neighbors. Therefore, the base station may avoid selecting PCls that result in confusion.
• The base station selects a random PCI from the list of candidate PCls. The base station then sends the selected PCI to the OAM that records this configuration.

In simple words, when eNB is firs time deployed, during boot up, it can sniff neighour cells through NMM (Network Monitoring Mode) or REM (Radio Environment Monitoring) function to know their PCIs.This will become a subset of PCIs that needs to be excluded from OAM configured PCI list to configure PCI.

During operational mode, when eNB establishes X2 connection with various eNBs, with exchange of neighbor cells (ANR table) PCI confusion can be avoided by re-configuring PCI, this may be continuous PCI optimization process.

Distributed SON (D-SON)

In a distributed approach, SON algorithms reside within the eNB’s, thus allowing autonomous decision making at the eNBs based on UE measurements received on the eNBs and additional information from other eNBs being received via the X2 interface. A distributed architecture allows for ease of deployment in multi-vendor networks and optimization on faster time scales. Optimization could be done for different times of the day. However, due to the inability to ensure standard and identical implementation of algorithms in a multi-vendor network, careful monitoring of KPIs is needed to minimize potential network instabilities and ensure overall optimal operation.

Radio Access Network Equipment Vendors offer D-SON to self-configure, optimize, and self-heal their proprietary equipment. D-SON runs on the Vendor’s edge equipment with limited scope and functionality. There are three few limitations to deploying only D-SON.

Limited Data accessibility: D-SON algorithms have access to a limited set of data stored on edge elements, eNodeBs for LTE.

Scope of operation is restricted to a small set of neighboring nodes so as not to negatively impact the performance of the network by overloading the inter-node communication paths (X2 interface for LTE.) 

The Load and coordination overhead increase very quickly as the number of nodes increase. D-SON operates with limited knowledge and control.

Difficulty to handle multi-vendor configurations: D-SON Vendors optimize the performance of their own equipment using proprietary algorithms, data schema, and interfaces. 

The standards don’t currently define the implementation of D-SON functions. So it is not possible to make parameter updates reliably across D-SON Vendors because there are unknown consequences to these black-box updates. This can cause misalignment between neighboring nodes. The problem is particularly strong in small-cell deployment scenarios when multiple-vendor cells are serving same coverage area.

These difficulties with D-SON limit the ability of the Operator to realize the full benefits of SON. D-SON uses a lower level, micro view of local regions of network performance to execute low-latency SON algorithms, such as Inter-cell Interference Coordination (ICIC), Automated Neighbor Relations (ANR), and some use cases of Energy Saving (ES), etc

Centralized SON (C-SON)

In a centralized architecture, SON algorithms for one or more usecases reside on the Element Management System or a separate SON server that manages the eNBs. The output of the SON algorithms namely, the values of specific parameters, are then passed to the eNBs either on a periodic basis or when needed. A centralized approach allows for more manageable implementation of the SON algorithms. It allows for usecase interactions between SON algorithms to be considered before modifying SON parameters. However, active updates to the usecase parameters are delayed since KPIs and UE measurement information must be forwarded to a centralized location for processing. Filtered and condensed information are passed from the eNB to the centralized SON server to preserve the scalability of the solution in terms of the volume of information transported.

Less information is available at the SON server compared to that which would be available at the eNB. Higher latency due to the time taken to collect UE information restricts the applicability of a purely centralized SON architecture to those algorithms that require slower response time. Furthermore, since the centralized SON server presents a single point of failure, an outage in the centralized server or backhaul could result in stale and outdated parameters being used at the eNB due to likely less frequent updates of SON parameters at the eNB compared to that is possible in a distributed solution.

There are three key time intervals associated with Centralized SON.

1. The Collection Interval is the period during which statistics are collected and uploaded. This is also the smallest available granularity for data analysis. This interval is most likely determined by the vendors OAM statistics throughput limitations. Most Network Management solutions would typically support a five minutes interval.

2. The Analysis Interval is the time period considered in the decision process for parameter adjustment. It is beneficial to consider more than a single collection interval in the analysis. While the latest collection interval should have the greatest impact on the analysis, the output should be damped to take into account results from previous intervals.

3. The Change Interval is the period between changes applied to the network by SON. System performance constraints may limit the number of cells for which changes are applied at any given time. This could result in Change Intervals that do not align directly with the Collection Intervals. These limiting factors don’t always apply, but centralized solutions either need to have vastly over provisioned processing and networking capability, or intelligent change management.

Centralized SON (C-SON) are sometimes deployed for Automated Neighbor Recognition (ANR), cell configuration, power control, interference and load management at the network operations center. This is OSS Level SON emerged first for 3G networks as 3GPP introduced a number of Self Organizing Networks (SON) standards starting with Release 8 in 2008 and expanded them in Release 9 with use cases in 2010/11. C-SON provides a centralized architecture that manages all edge radio nodes. It can potentially orchestrate the behavior of radio network equipment across an entire network of multi-vendor and multi-technology environments. C-SON can take into consideration data from all nodes in the network to identify and address network-wide issues. And since the control of all SON functions is done centrally, these interactions can easily be coordinated and managed using a variety of resolution techniques.

C-SON is mostly offered by 3rd-party SON solution providers. Equipment Vendors may also offer some form of centralized SON. C-SON executes at the level of the OSS using standardized IRP as well as proprietary interfaces. Benefits of C-SON are:

• Flexibility of customization satisfies the unique needs and policies of the Operator.
• Access to the converged performance of the entire multi-vendor and multi-technology heterogeneous network (HetNet) including support for segregated shared network configurations.
• Ability to automate optimization and self-healing across network layers.
• Orchestration and coordination of multiple SON functions and across all Vendor-specific D-SON systems.
• Enrichment of SON functions by using business data, for example, Customer Experience Data (CEM) to improve subscriber experience.
• Self-learning capabilities based on patterns of historical network and business data.
• Capability to correlate data across different dimensions including performance measurements, fault management data, configuration changes, and element maintenance activities, etc. to improve root-cause analysis

C-SON operates from a big picture view of the entire network to execute SON algorithms across equipment Vendors, layers, and technologies over time. Also, by using data from Operator business systems, C-SON can be optimized based on business requirements and not just on network needs. C-SON can orchestrate the parameterization and execution D-SON functions as well based on this broader knowledge.

SON Features

3GPP initiated the work towards standardizing self-optimizing and self-organizing capabilities for LTE in Release 8 and Release 9. The standards provide network intelligence, automation and network management features in order to automate the configuration and optimization of wireless networks to adapt to varying radio channel conditions, thereby lowering costs, improving network performance and flexibility.

A key goal of 3GPP standardization has been the ability to support Self-Organizing Networks (SON) features in multi-vendor network environments. Therefore, a significant part of the SON standardization has been devoted to defining the appropriate interfaces to allow exchange of common information which can then be used by each SON algorithm.

Release 8
As such, in Release 8, SON functionality focused on procedures associated with initial equipment installation and integration to support the commercial deployment of the first LTE networks, also known as ‘Enhanced Node Base Station (eNB) self-configuration’. These procedures included:

• Automatic Inventory
• Automatic Software Download
• Automatic Neighbor Relation (ANR)
• Automatic Physical Cell ID (PCI) assignment

Release 9
In Release 9 SON functionality focused on the operational aspects of already deployed commercial networks, in particular key aspects related to network optimization procedures. The Release 9 standardization scope included these additional use cases:

• Mobility Robustness/Handover optimization (MRO)
• Random Access Channel (RACH) Optimization
• Load Balancing Optimization
• Inter-Cell Interference Coordination (ICIC)

Release 10
Release 10 provides a richer suite of SON functions for macro and metro networks overlaid on and inter-operating with existing mobile networks. It includes enhancements to existing use cases and definition of new use cases as follows:

• Coverage & Capacity Optimization (CCO)
• Enhanced Inter-Cell Interference Coordination (eICIC)
• Cell Outage Detection and Compensation
• Self-healing Functions
• Minimization of Drive Testing
• Energy Savings

Release 11
Release 11 provides enhancements to the following features:

• Automatic Neighbor Relations
• Load Balancing Optimization
• Handover Optimization
• Coverage and Capacity Optimization
• Energy Savings
• Coordination between various SON Functions
• Minimization of Drive Tests

SON Architecture

A Self-configuration Subsystem will be created in OAM to be responsible for the self configuration of eNB. For self-optimisation functions, they can be located in OAM or eNB or both of them. So according to the location of optimisation algorithms, SON can be divided into three classes: Centralised SON, Distributed SON and Hybrid SON.

• Centralized SON

In Centralized SON, optimisation algorithms are executed in the OAM System. In such solutions SON functionality resides in a small number of locations, at a high level in the architecture. Below figure shows an example of Centralized SON.

In Centralized SON, all SON functions are located in OAM systems, so it is easy to deploy them. But since different vendors have their own OAM systems, there is low support for optimization cases among different vendors. And it also does not support those simple and quick optimization cases.

• Distributed SON

In Distributed SON, optimisation algorithms are executed in eNB. In such solutions SON functionality resides in many locations at a relatively low level in the architecture. Below figure shows an example of Distributed SON.

In Distributed SON, all SON functions are located in eNB, so it causes a lot of deployment work. And it is also difficult to support complex optimization schemes, which require the coordination of lots of eNBs. But in Distributed SON it is easy to support those cases, which only concern one or two eNBs and require quick optimization responses. For Distributed SON, X2 interface needs to be extended.

• Hybrid SON

In Hybrid SON, part of the optimisation algorithms are executed in the OAM system, while others are executed in eNB. Below figure shows an example of Hybrid SON.In Hybrid SON, simple and quick optimization schemes are implemented in eNB and complex optimization schemes are implemented in OAM. 

So it is very flexible to support different kinds of optimization cases. And it also supports the optimization between different vendors through X2 interface. But on the other hand, it costs lots of deployment effort and interface extension work.