Release 11)
21 3GPP TS 28.628 V11.3.0 (2013-09)
The original cell may go into the energySaving state after the candidate cell outage is recovered and coverage of the original cell can be taken over by candidate cell again.
4.7.3.2
4.7.3.2.1
Coordination among Cell Outage Compensation, Capacity and Coverage Optimization, and Energy Saving Management
Description
Capacity and Coverage Optimization (CCO), Cell Outage Compensation (COC) and Energy Saving Management (ESM) may require changes to the coverage and/or capacity of one or more cells during the same time period, which could lead to the following issue:
Cell3 Cell1 Cell2 Cell4
Figure 4.7.3.2 Coordination among COC, CCO, and ESM
Figure 4.7.3.2 is a typical scenario for the coordination among COC, CCO and ESM.
Cell 1 is detected in outage, COC will try to compensate the outage Cell 1 by reconfiguring the RF configuration of some compensation candidate cells, e.g., TX power, antenna tilt and antenna azimuth of Cell 2 and Cell 3.
Before the outage Cell 1 is compensated, CCO may detect the degrading of coverage related KPI (e.g., success rate of RRC connection establishments, cell throughput) of Cell 1 and its neighbour cells (Cell 2 and other blue cells) and make a conclusion that there is a coverage problem in this KPI degraded area.
Meanwhile, ESM is operating on Cell 2 to compensate the coverage of its neighboring cell (Cell 4) which is going into energySaving state.
From the time point at which the outage Cell 1 is detected until Cell 1 has been compensated by Cell 2 and Cell 3, during this period, if there is no coordination among COC, CCO and ESM, there will be possibly different settings for adjusting TX power, antenna tilt and antenna azimuth of Cell 2 for COC, CCO or ESM purposes respectively. It’s most likely that the adjustment from COC, ESM and optimization from CCO may conflict in the common affected outage compensation candidate cell(s) (Cell 2 in the above example).
It is also possible that ESM is operating on Cell 2 to compensate the coverage of Cell 4 that is in energySaving state, while COC detects that Cell 1 has outage, and requests Cell 2 to compensate the coverage of Cell 1. COC and ESM need to be coordinated to determine if this request can be accepted.
After the outage cell comes back to normal, the COC exits the coordination scenario, while CCO and ESM continute to work and need to be well coordinated. For example, CCO may adjust the antenna tilt of Cell 2 in a downward direction to improve the coverage signal quality, but ESM may adjust the antenna tilt of Cell 2 in an opposite direction to enlarge its coverage area for purpose of ES compensation. Therefore, coordination should be continued between CCO and ESM to resolve the possible configuration conflict on Cell 2. Other conflict scenarios could be:
Cell A is compensating to provide coverage for Cell B that is in energySaving state. COC detects that Cell A has outage. Since Cell A is not able to provide the coverage for Cell B any more, Cell B needs to be covered by another cell, or to deactivate energy saving.
3GPP
Release 11)
22 3GPP TS 28.628 V11.3.0 (2013-09)
Cell A is in energySaving state. COC detects Cell B has outage, and requests Cell A to compensate the coverage of Cell B. Cell A may need to terminate energy saving in order to compensate the coverage of Cell B.
Cell A which is compensating Cell B in outage shall not go into energySaving state as long as its compensation for Cell B is needed.
4.7.3.2.2 Prevention
Prevention is hardly possible.
4.7.3.2.3 Resolution
Refer to clause 4.7.4 General SON coordination solutions.
4.7.3.3
4.7.3.3.1
Coordination between Cell Outage Compensation and Automatic Neighbour Relation
Description
In case one cell is detected in outage, COC will try to compensate the outage cell by reconfiguring the RF configuration of some compensation candidate cells. As a result of this, there will be new NRs (neighbour relations) which reflect the new topology relations.
For a stable network, ANR could be deactivated for the purpose of system resource saving. If ANR is deactivated, the new NRs cannot be captured in NRT by ANR. Network performance, for example, handover will be impacted negatively by the NRT which lacks of the new NRs.
4.7.3.3.2 Prevention
Prevention is hardly possible, except making the cells as outage proof as possible. But cell outages can happen even to the most stable cell in a network.
4.7.3.3.3 Resolution
The ANR function should monitor if a cell outage or cell outage compensation takes place within its area. If this happens, then the ANR function should check the NRs of the affected cells (for example the outage cell and its
neighbours and neighbours’ neighbours). In case the ANR function in the the affected area is deactivated, the possible NRs change of the affected cells should be taken as a factor to reactivate the ANR function.
4.7.3.4
4.7.3.4.1
Coordination between HandOver parameter Optimization and Load Balancing Optimization
Description
HOO function and LBO function both optimize network performance by adjusting handover parameters such as CIO, Hysteresis, TTT, etc. Conflicts may happen when HOO function and LBO function are changing the same or associated handover parameters in opposite direction or towards the same direction but on different scales.
For example, HOO function may adjust handover parameters (e.g. decrease CIO of source cell A to target cell B) to minimize the number of too early handovers from cell A to cell B whilst LBO function may adjust handover parameters (e.g. increase the CIO of source cell A to target cell B) to make the handover from cell A to cell B more easier in case the load of cell B is much less than cell A.
4.7.3.4.2 Prevention
Prevention is hardly possible unless switch off HOO function or LBO function. However, disabling the complete HOO function or LBO function cannot fulfil the requirement that both handover performance and load performance need to be improved at the same time.
3GPP
Release 11)
23 3GPP TS 28.628 V11.3.0 (2013-09)
4.7.3.4.3 Resolution
For the coordination between HOO and LBO, IRPManager should assign priorities for HOO function and LBO function or weights for targets of HOO function and LBO function according to operator’s policy. The policy should cover different scenarios well:
? Policy may assign higher priority for HOO function than LBO function or higher weight for target of HOO function
than targets of LBO function when resolving MRO issues (HO too early/too late/to wrong cell) is the main objective of network optimization, e.g. in handover optimization scenario for better coverage. ? Policy may assign lower priority for HOO function than LBO function or lower weight for target of HOO function
than targets of LBO function when enhancing load performance is the main objective of network optimization, e.g. in load optimization scenario for better capacity. Concrete way of using priority or weights of targets, refers to clause 4.7.4 General SON coordination solutions.
4.7.4
4.7.4.1
General SON coordination solutions
Overview
As described in TS 28.627 [5], multiple SON functions may have conflicting demands on network resources. This situation is considered as “SON functions in conflict” and requires conflict prevention or resolution. A SON Coordination Function will be responsible for preventing or resolving conflicts.
Conflict needs to be detected when there is “SON functions in conflict”. Policies can be preset by operator to SON Coordination Function to avoid conflict on certain associated resources (network elements and/or parameters) among SON functions.
Conflict prevention is to take some advanced methods to prevent the occurrence of conflict. However, no matter what implementation is chosen, it is impossible to guarantee that 100% of conflicts will be prevented, so conflict detection and resolution are needed. Conflict detection should be taken firstly as the pre-condition of conflict resolution. The SON Coordination Function is a logical function, which means it can be implemented as a separate function entity or as part of SON function.
When the SON Coordination Function is implemented as a separate function entity, all the SON functions send the necessary information to the SON Coordination Function, the SON Coordination Function coordinate these SON functions as a centralized control point. This centralized coordination approach fulfills the requirements of SON coordination in a large area scope, for example, the coordination between NM centralized SON functions and distributed SON functions.
In some other situations, coordination is only needed in a smaller area, for example, the coordination between
distributed SON functions inside one domain. Then the SON Coordination Function can be implemented as part of each SON function. The necessary coordination information can be inter-exchanged between each SON functions to achieve coordination as well.
The SON Coordination Function may reside above or below Itf-N. Figure 4.7.4.1 shows an example of a SON Coodination Function, which is a separate function entity, above Itf-N.
3GPP
Release 11)
24 3GPP TS 28.628 V11.3.0 (2013-09)
NM SON Coordination Function SON_X Itf-N EM SON_Y eNB SON_A eNB SON_B eNB EM SON_C
Figure 4.7.4.1: Example of SON Coordination entity located in NM
The SON Coordination Function may be responsible for conflict prevention, conflict resolution, or both in parallel.
4.7.4.2 Conflict prevention
To prevent conflicts between the SON functions, the SON functions may ask the SON Coordination function for
permission before changing some specific configuration parameters. The SON Coordination Function should check the SON coordination interdependancy policy between this requesting SON function and other SON function(s) upon receiving the permission request from the SON function. SON coordination interdependancy policy which is pre-configured can help the SON Coordination Function to find which SON function(s) possibly conflict with this requesting SON function.
As a basis for decisions, the SON Coordination Function will typically use one or some of the following inputs received from the SON function(s) ? ? ? ? ? ? ? ? ? ?
Which SON functions are modifying configuration parameters (including information about vendor, release etc.) Configuration parameters intended to be changed and/or their existing and proposed new values The time duration how long the configuration parameter should not be interfered with (“impact time”) The state of SON functions
The SON targets which are the justification for the configuration change. Possible impact of a parameter change on other objects (“impact area”) The state of certain managed objects
Possible impact of the parameter change on Key Performance Indicators
Priority of SON functions, which can be used to determine the execution order of requests from different SON functions in case of conflicts SON coordination policies
3GPP
相关推荐：
loading