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.