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.

Self Healing

Self-healing function aims at automatic detection and localization of most of the failures and applies self-healing mechanisms to solve several failure classes, such as reducing the output power in case of temperature failure or automatic fallback to previous software version.

All areas of the cellular network can display faults from time to time. Many can be overcome without a major problem and in many cases backup hardware may be available.

Following main areas can be considered in self-healing:

1. Self recovery of software - the ability to return to a previous software version should issues arise.

2. Self-healing of board faults - this often involves redundant circuits where a spare can be switched in.

3. Cell outage detection - it must be possible to remotely detect when there is an issue with a particular cell.

4. Cell outage recovery - routines to assist with cell recovery, this may include detection and diagnosis and along with an automatic recovery solution, together with a report of the outcome of the action.

5. Cell outage compensation - methods of maintaining the best service to users while repairs are effected.

Return from cell outage compensation - this action, while obvious needs to be included as it must be possible to easily return to the pre fault status, removing any compensation actions that may have been initiated

Fault management and correction requires a lot of human interventions and should be automated as much as possible; hence identification and self-healing of the faults is a significant solution. The following points are important parts of the solution:

- Automatic fault identification

Equipment faults are normally detected by the equipment itself autonomously. However, fault detection messages cannot always be generated or transmitted when the detection system itself is damaged.Such unidentified faults of eNodeB are commonly mentioned as sleeping cells, and they are detected by performance statistics.

- Cell outage compensation

When an equipment fault is detected, SON analyzes internal logs of the equipment, identifies the root cause, and takes some recovery actions such as fallback to the previous software version or switching to the backup units. When the equipment fault cannot be resolved by these actions, the affected cell and the neighbor cells take cooperative actions to minimize user-perceived quality degradation. For example, in an urban area covered by multiple microcells, relocating users from the faulty cell to the normal cells by adjusting coverage and handover related parameters of the nearby cells cooperatively is effective. This results in a reduced failure recovery time and a more efficient allocation of maintenance personnel.

Self Optmization

Self-optimization process is defined as the process where UE & eNB measurements and performance measurements are used to autotune the network. The self-optimization process collects measurement information from UE and eNB and optimization tool, it auto-tune the configuration data to optimize the network. To maximize network performance, optimizing the configuration while taking into account regional characteristics of radio propagation, traffic and UE mobility in the service area is effective. However, optimization has not been frequently applied because it typically entails a heavy workload for site surveys, analysis of the performance statistics and decision of the optimal parameters. SON automates these tasks by using measurements from network equipments. Optimization is required for ensure that once a cell has been installed it operates to its best level of efficiency.

Specifically, it substitutes measurements from eNodeB and UE for the site survey data. It detects problems with quality, identifies the root cause, and automatically takes remedial actions on the basis of the measurement and performance statistics from the OMC. This autonomous optimization allows problems to be handled faster and network performance to be improved. As depicted in Figure 4, NEC’s selfoptimization includes:

· Neighbor list optimization This optimization automatically reconfigures a neighbor list so that the list contains the minimum set of cells necessary for handover. The neighbor list can be dynamically updated on the basis of UE measurement reports. For example, newly reported cells are added, and cells with very few handover attempts or frequent handover failures are removed from the list. These operations can be decided while considering operator’s individual requirements managed in the OMC.

· Coverage and capacity optimization This optimization aims at maximizing the system capacity and ensuring there is an appropriate overlapping area between adjacent cells. The optimal parameter setting is acquired by cooperatively adjusting antenna tilt and pilot power among the related cells. This optimization should operate with some effect even if the measurement reports from UE do not include their data on their own location.

· Mobility robustness optimization To eliminate unnecessary handover and to provide appropriate handover timing, this optimization automatically adjusts the thresholds related to cell reselection and handover. The adjustment is triggered by the related KPI degradation's and is processed while identifying the root causes of the degradation's such as a handover that is too early or too late or the ping-pong effect.

· Mobility load balancing optimization This optimization automatically gets some UEs in the edge of a congested cell re-select or hand over to the less congested adjacent cells by adjusting the thresholds related to cell reselection and handover. Load balancing should be done by using a minimum number of cell reselection or handover without causing the problem of mobility. Also it should minimize total investment in capacity by taking into account the different sides of load such as radio load, transport network load and HW processing load.

Types of self-optimizing network functionality. There are a number of areas where self-optimisation of the network is undertaken.

1. Mobility robustness optimisation 
2. Mobility load balancing and traffic steering 
3. Energy saving 
4. Coverage and capacity optimisation 
5. RACH optimisation

Self Configuration

Self-configuration strives towards the "plug-and-play" paradigm in the way that new base stations shall automatically be configured and integrated into the network. This means both connectivity establishment, and download of configuration parameters are software. Self-configuration is typically supplied as part of the software delivery with each radio cell by equipment vendors. When a new base station is introduced into the network and powered on, it gets immediately recognized and registered by the network. The neighboring base stations then automatically adjust their technical parameters (such as emission power, antenna tilt, etc.) in order to provide the required coverage and capacity, and, in the same time, avoid the interference.

Ideally a base station or cell that is to be added to an existing network deployment should configure itself, following a “plug & play” principle (self-configuration). Parameters usually configured manually by the network operator should be set automatically based on the measured radio conditions.

One of the first standardized SON features, related to the “self-configuration” category, is automatic neighbor relation (ANR). ANR significantly reduces the time required to set up a base station by automatically managing neighbor cell relations, thus replacing time-consuming manual setup. ANR relies on the mobile terminal’s capability to report cells that it has detected but that are not part of the neighbor list broadcasted by the LTE network.

Self-configuration process is defined as the process where newly deployed nodes (eNBs) are configured by automatic installation procedures to get the necessary basic configuration for system operation. Self-configuration process works in pre-operational state, which starts from when the eNB is powered up and has backbone connectivity until the RF transmitter is switched on. 

As shown in Figure, self-configuration includes two stages: basic setup and initial radio configuration. 

1. An IP address is allocated to the new eNB and the information of the Self configuration Subsystem of OAM (Operation and Management) is given to the eNB. 

2. A GW is configured for the new eNB so that the eNB can exchange IP packets with other internet nodes. 

3. The new eNB provides its information, including type, hardware and etc., to the Self-configuration Subsystem for authentication. Necessary software and configuration data are downloaded from the Self-configuration Subsystem. 

4. The new eNB is configured based on the transport and radio configuration data.

5. The new eNB connects to the normal OAM subsystems for other management functions. 6. S1 and necessary X2 interfaces are established

The self-configuration should take care of all soft-configuration aspects of an eNB once it is commissioned and powered up for the first time. It should detect the transport link and establish a connection with the core network elements, download and upgrade to the latest software version, set up the initial configuration parameters including neighbor relations, perform a self-test, and finally set itself to operational mode. In order to achieve these goals, the eNB should be able to communicate with several different entities.

The self-configuration actions will take place after the eNB is physically installed, plugged to the power line and to the transport link. When it is powered on, the eNB will boot and perform a self test, followed by a set of self-discovery functions, which include the detection of the transport type, tower-mounted amplifier (TMA), antenna, antenna cable length and auto-adjustment of the receiver-path.

After the self-detection function, the eNB will configure the physical transport link autonomously and establish a connection with the DHCP/DNS (dynamic host configuration protocol/domain name server) servers, which will then provide the IP addresses for the new node and those of the relevant network nodes, including serving gateway, mobility management entity (MME), and configuration server. After this, the eNB will be able to establish secure tunnels for operations, administration and maintenance (OAM), S1, and X2 links will be ready to communicate with the configuration server in order to acquire new configuration parameters

SON Introduction

Self-organizing networks (SON) are the attempt to simplify and speed up the planning, configuration, management, optimization and healing of mobile communications networks. Well-designed and efficient SON functions are able to achieve and maintain high levels of network performance by continuously finding improvement patterns that may not be easily distinguishable to an expert. This is done so via the modification of various network parameters and by using rollback algorithms. These operations can be performed efficiently due to the availability of rich statistical models on Key Performance Indicators (KPI), their dependencies on one another and their interactions with each other. 

Aim -

• Reducing the operating cost by reducing the level of human intervention in network design, build and operation. 
• Reducing capital expenditure by optimizing the use of available resources, 
• Protecting revenue by reducing the number of human errors.

Definition -

• SON, can be defined as a set of use cases that govern a network including the planning, set up and maintenance activities. In this way the self-organizing networks enable the network to set itself up and then manage the resources to enable the optimum performance to be achieved at all times.

The significant increase in the number of mobile users as well as the amount of online content has caused the demand for high-speed data to rise exponentially. This has played a major role in recent developments in mobile networks. In order to accommodate this growing demand, mobile operators are having to deploy increasingly complex networks. These networks are comprised of multiple radio access technologies, several different cell types and various users, all of whom have different Quality of Service (QoS) requirements.

Mobile operators now need to be able to manage these ever-increasingly complex networks efficiently with minimal costs. In order to do this new and existing networks need to be managed with minimal manual efforts. Thus, SON functionalities are essential in future as well as existing networks.

The complexity of LTE system also place new demands on the Operations and Maintenance of the network. Self-Organizing Networks (SON) is seen as one of the promising area for an operator to save operational expenditures and this is the main reason for mobile operators to implement SON to help decrease their capital and operating expenditures. SON functions can help decrease the costs in all 3 stages (planning, deployment and operation) of a network life cycle.

Main Drivers for SON 

The main drivers for SON are:

1. The number and structure of network parameters have become large and complex; 
2. Quick evolution of wireless networks has led to parallel operation of 2G, 3G, EPC infrastructures; 
3. The rapidly expanding number of Base Stations (especially Home eNB) needs to be configured and managed with the least possible human interaction. SON aims to configure and optimize the network automatically, so that the interaction of human can be reduced and the capacity of the network can be increased.

The main elements of SON include:

Self configuration: The aim for the self configuration aspects of LTE SON is to enable new base stations to become essentially "Plug and Play" items. They should need as little manual intervention in the configuration process as possible. Not only will they be able to organise the RF aspects, but also configure the backhaul as well. 

Self optimisation: Once the system has been set up, LTE SON capabilities will enable the base station to optimise the operational characteristics to best meet the needs of the overall network. 

Self-healing: Another major feature of LTE SON is to enable the network to self-heal. It will do this by changing the characteristics of the network to mask the problem until it is fixed. For example, the boundaries of adjacent cells can be increased by changing antenna directions and increasing power levels, etc..