6 Specification level requirements

28.6273GPPRelease 17RequirementsSelf-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference Point (IRP)Telecommunication managementTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.1 Requirements

6.1.1 Self-Optimization Monitoring and Management

6.1.1.1 Management Part

REQ-SO_MM-FUN-1 IRPManager shall be able to configure objectives and targets for the self-optimization functions.

REQ-SO_MM-FUN-2 For open loop, IRPManager shall be able to configure whether a confirmation is needed before the execution of optimization actions. The necessity of a confirmation will be decided case by case.

REQ-SO_MM-FUN-3 For open loop, IRPManager shall be able to confirm the execution of optimization actions in case IRPManager configured a confirmation is needed.

REQ-SO_MM-FUN-4 For open loop, IRPAgent shall provide information to the IRPManager about the optimization actions. The necessity of this capability will be decided case by case.

REQ-SO_MM-FUN-5 IRPAgent shall provide information to the IRPManager about the execution result of self-optimization actions.

REQ-SO_MM-FUN-6 The IRPAgent shall provide information to the IRPManager about the outcome of self-optimization.

REQ-SO_MM-FUN-7 IRPManager shall be able to configure the values of KPIs or performance counters which may be used to trigger the optimization function.

REQ-SO_MM-FUN-8 When the IRPAgent is aware of disruptive situations for the SON functionality, it shall support optimization functions in coping with them as much as possible without the need for an intervention from the IRPManager. Disruptive situations are e.g. an outage of a cell, the insertion of a new cell, deactivation of a cell etc.

6.1.2 Load Balancing

REQ-SO_LB-FUN-1 The IRPManager shall be able to disable/enable the load balancing function.

REQ-SO_LB-FUN-2 The IRPManager shall be informed about the eNodeB load.

REQ-SO_LB-FUN-3 The IRPManager shall be able to request that load balancing be allowed from source cell to target cell.

REQ-SO_LB-FUN-4 The IRPManager shall be able to request that load balancing be prohibited from source cell to target cell.

REQ-SO_LB-FUN-5 The IRPAgent shall inform the IRPManager about success or failure of IRPManager operations to allow load balancing, prohibit load balancing.

6.1.3 Handover (HO) Parameter optimization

6.1.3.1 HO failure categorization

6.1.3.1.1 HO failures due to too late and too early HO triggering

HO failures can be categorized as follows:

– HO failures due to too late HO triggering

– HO failures due to too early HO triggering

– Failures due to HO to a wrong cell

Consequently, the HO parameter optimisation should aim at detecting and mitigating too early HOs, too late HOs and HOs to a wrong cell. The following subsections provide the scenarios for too early HO, too late HO and HO to a wrong cell triggering leading to HO failures.

6.1.3.1.1.1 Too late HO triggering

Example scenario for too late HO triggering is shown in Figure 6-1. If the UE mobility is more aggressive than what the HO parameter settings allow for, the HO could be triggered when the signal strength of the serving cell is already too low or may not be triggered at all if a radio link failure preempts it. The connection may be re-established on a different cell from the serving cell. This is a common scenario in areas where user mobility is very high, such as along the highways, train lines etc.

3dTower.emf

Due to fast movement and inadequate HO parameter setting, UE leaves the source cell coverage before the HO is triggered

Cell B

Cell A

X = radio link failure

Figure 6-1 – Too late HO triggering scenario

6.1.3.1.1.2 Too early HO triggering

Example scenario for too early HO triggering is shown in Figure 6-2. HO can be triggered when the UE enters unintended island of coverage of the target cell inside the intended coverage area of the serving cell. When the UE exits the island of coverage of the target cell, it cannot acquire the target cell any more and the HO fails, potentially leading to a radio link failure. This is a typical scenario for areas where fragmented cell coverage is inherent to the radio propagation environment, such as dense urban areas.

3dTower.emf

Island of coverage of Cell B inside the coverage area of Cell A

Cell B

Cell A

X = HO failure

= HO triggering

Figure 6-2 – Too early HO triggering scenarios

6.1.3.1.1.3 HO to a wrong cell

Example scenario for HO to a wrong cell is shown in Figure 6-3. In this scenario UE is moved from cell A to cell C, but because the HO parameter not optimized and a cell A sends a wrong HO command performs a handover to cell B and then a RLF happens. After that UE re-establishes connection with cell C.

3dTower.emf

Radio link failure due to unproper HO parameter setting between cell A and cell B

Cell B

Cell A

X = radio link failure

3dTower.emf

Cell C

= HO triggering

Figure 6-3 –HO to a wrong cell scenarios

6.1.3.2 Reducing inefficient use of network resources due to unnecessary HOs

HO procedure is resource-consuming and therefore costly to the network operator. Sometimes, the combination of user mobility patterns and cell coverage boundary layout can generate frequent unnecessary HOs that consume NW resources inefficiently. This scenario is illustrated in Figure 6-4a. HO parameter optimisation function should aim at detecting such scenarios. These scenarios sometimes can be remedied by HO parameter optimisation, as illustrated in Figure 6-4b. Since the goal of reducing unnecessary HOs can sometimes be opposed to the goal of reducing the number of HO failures, operators should be able to set the tradeoff point.

3dTower.emf

Cell B

Cell A

= HO triggering

Figure 6-4a – Frequent HOs cause inefficient use of NW resources

3dTower.emf

Cell B

Cell A

HOs not triggered due to HO parameter adjustment

Figure 6-4b – HO parameter adjustment prevents frequent Hos

Additionally, incorrect cell reselection parameters setting may result unwanted handover right after RRC connection setup, HO parameter optimization function should also aim at detecting misalignment between cell reselection parameters and handover parameters setting and adjust the parameters to avoid such scenarios.

6.1.3.3 Requirements

REQ-SO_HO-FUN-1 HO parameter optimisation function shall aim at detecting too early handover, too late handover and handover to a wrong cell.

REQ-SO_HO-FUN-2 HO parameter optimisation function shall aim at detecting inefficient use of network resources due to unnecessary HOs.

REQ-SO_HO-FUN-3 HO parameter optimisation function shall aim at meeting the objectives and targets for the HO optimisation function

REQ-SO_HO-FUN-4 The objectives for the HO parameter optimisation function shall reflect the desired tradeoff between the reduction in the number of HO related failures and the reduction of inefficient use of network resources due to HOs.

REQ-SO_HO-FUN-5 The IRPManager shall be able to disable/enable the HO parameter optimization function.

6.1.4 Interference control

REQ-SO_IC-FUN-1 The IRPManager shall be able to disable/enable the Interference Control function.

REQ-SO_IC-FUN-2 The IRPManager shall be able to request that ICIC be allowed from source cell to target cell.

REQ-SO_IC-FUN-3 The IRPManager shall be able to request that ICIC be prohibited from source cell to target cell.

REQ-SO_IC-FUN-4 An IRPAgent shall inform the IRPManager about success or failure of IRPManager operations to allow ICIC, prohibit ICIC.

6.1.5 Coverage and capacity optimization

REQ-SO_CC-FUN-1 Performance measurements with geographical binning may be used as inputs into the coverage and capacity optimization function.

REQ-SO_CC-FUN-2 CCO function shall aim at providing optimal capacity and coverage for the radio network while considering the trade-off between capacity and coverage.

REQ-SO_CC-FUN-3 The IRPAgent shall support a capability allowing the IRPManager to enable or disable the CCO function.

6.1.6 RACH optimization

REQ-SO_RO-FUN-1 The IRPAgent shall support enabling and disabling the RACH optimization function.

6.1.7 SON Coordination

The following requirements apply when the SON coordination function is in NM layer.

REQ-SON_COORD-FUN-1 The IRPAgent shall provide the capability to inform the IRPManager whether a SON function is activated or not.

REQ-SON_COORD-FUN-2 The IRPAgent shall provide the capability to inform the IRPManager about which SON functions modified configuration parameter(s).

REQ-SON_COORD-FUN-3 The IRPAgent should provide the capability to inform the IRPManager about the time duration how long the configuration parameter(s) should not be modified.

REQ-SON_COORD-FUN-4 The IRPAgent should provide the capability to inform the IRPManager about the SON targets which are the justification for the configuration change.

The following requirements apply when the SON coordination function is below Itf-N.

REQ-SON_COORD-FUN-5 The IRPAgent should provide a capability to allow the IRPManager to configure the priority of SON functions in case of conflicts.

REQ-SON_COORD-FUN-6 The IRPAgent shall provide the capability for the IRPManager to be informed when the SON coordination function could not resolve a conflict. This information should include the involved SON functions, the involved configuration parameters and/or the involved SON targets.

6.1.8 NM centralized coverage and capacity optimization

REQ-SO_CC_NM-FUN-1 The IRPAgent shall support a capability allowing the IRPManager to initiate needed performance measurements that are not already active and to receive performance measurements.

REQ-SO_CC_NM-FUN-2 The IRPAgent shall support a capability allowing the IRPManager to order one single trace session for several job types of radio measurements (e.g. a combination of MDT/RLF/RCEF measurements) using one single operation.

REQ-SO_CC_NM-FUN-3 The IRPAgent shall support a capability allowing the IRPManager to receive recorded MDT/RLF/RCEF measurements.

REQ-SO_CC_NM-FUN-4 The IRPAgent shall support a capability allowing the IRPManager to configure attributes that affect coverage and capacity.

REQ-SO_CC_NM-FUN-5 The IRPAgent shall support a capability allowing the IRPManager to receive indications that parameters have changed their values.

6.1.9 AAS management

REQ-SO_AAS-FUN-1 The IRPAgent should support a capability allowing IRPManager to switch on/off the specific AAS operations (including Cell Splitting, Cell Merging, Cell Shaping) respectively.

REQ-SO_AAS-FUN-2 The IRPAgent should support a capability allowing IRPManager to set the quantity of allowed split cells to be split from the original cell.

REQ-SO_AAS-FUN-3 The IRPAgent should support a capability allowing IRPManager to pre-configure the ECGI for the potential split or merged cells.

REQ-SO_AAS-FUN-4 The IRPAgent should support a capability allowing IRPManager to pre-allocate the PCI range(s) for the potential split or merged cells.

REQ-SO_AAS-FUN-5 The IRPAgent should support a capability allowing IRPManager to pre-configure the range of parameters affecting the coverage for each potential split cell.

REQ-SO_AAS-FUN-6 The IRPAgent should be able to notify IRPManager about the creation of split or merged cell as soon as possible after it is split or merged from the original cell(s).

REQ-SO_AAS-FUN-7 The IRPAgent should support a capability allowing IRPManager to modify the ECGI and PCI of the split or merged cells.

REQ-SO_AAS-FUN-8 The IRPAgent should enable management operations with the newly created split cell as soon as possible after it is split from the original cell.

REQ-SO_AAS-FUN-9 For NM centralized AAS SON, the AAS operations (i.e. Cell Splitting, Cell Merging, or Cell Shaping) at the eNB should be configured by OAM in coordination with OAM configuration of the neighbour eNBs to keep coverage, inter-cell interference and handover settings under control.

REQ-SO_AAS-FUN-10 The IRPAgent should support a capability allowing IRPManager to pre-configure the alternative coverage configurations (including a state identifier, the range of parameters which affect coverage (e.g. tilt, power)), then SON for Cell Shaping operation can autonomously select and switch between these configurations.

6.2 Actor roles

No new actor.

6.3 Telecommunications Resources

No new telecommunications resources.

6.4 Use case

6.4.1 Use case Self-Optimization Monitoring and Management

Use Case Stage	Evolution / Specification	<<Uses>> Related use
Goal (*)	Optimize the system in an automated manner.
Actors and Roles (*)	IRPManager as user
Telecom resources	The E-UTRAN/EPC network including its management system.
Assumptions	The network is properly installed and running.
Pre conditions	The self-optimization objectives and targets have been set by operators
Begins when	Based on the monitored input parameters (KPIs, Alarms, etc.), targets for the objectives defined for the self-optimization functions are not met.
Step 1 (*) (M\|O)	The order of the bullet points in the list below does not imply any statements on the order of execution. [SO1] The input parameters (KPIs, Alarms, etc.) are monitored continuously. [SO2] When the monitored parameters do not meet the optimization targets, the optimization function is triggered. [SO3] Optimisation function proposes corrective actions. [SO4] Operator may confirm the execution/activation of the proposed actions if needed. [SO5] Corrective actions are executed. [SO6] Optimisation function monitors system status for a certain pre-defined monitoring time period. [SO7] The configuration prior to the corrective action is memorised if needed. [SO8] If the system status is satisfactory during the monitoring time period, then go to [SO1]. [SO9]Operator may confirm if fallback is needed. [SO10] Fallback is executed. [SO11] The operator is informed about the progress and important events occurring during the self-optimization process.
Step n (M\|O)
Ends when (*)	Ends when all steps identified above are successfully completed or when an exception occurs.
Exceptions	One of the steps identified above fails and retry is unsuccessful..
Post Conditions	System is operating normally.
Traceability (*)	REQ-SO_MM-FUN-1, REQ-SO_MM-FUN-2, REQ-SO_MM-FUN-3, REQ-SO_MM-FUN-4, REQ-SO_MM-FUN-5, REQ-SO_MM-FUN-6

6.4.2 Use case Load Balancing Allowed/Prohibited Management

Use Case Stage	Evolution / Specification	<<Uses>> Related use
Goal (*)	The load balancing (LB) can be allowed/prohibited from a source cell to a target cell by the IRPManager.
Actors and Roles (*)	IRPManager as user
Telecom resources	The E-UTRAN/EPC network including its OSS.
Assumptions	There is operator’s policy for LB allowing/prohibiting management. For example: LB from the higher priority cell to the lower priority cell is allowed; reverse is prohibited. LB between an eNB cell and another eNB cell which belongs to another unwanted PLMN is prohibited.
Pre conditions	The network is operational.
Begins when
Step 1 (*) (M)	The IRPManager makes a decision to allow/prohibit LB from a source cell to a target cell: According to operator’s policy, or According to some information got in run time. For example: LB would always fail between some particular cells in case of some inappropriate parameters setting. In that situation, the LB function located at eNB may make a decision to prohibit LB between these particular cells and notify this infomation to the IRPManager. After the CM parameters adjusting, the LB between those cells may be allowed again based on the good values of relative PM counters.
Step 2 (*) (M)	The IRPAgent is instructed by the IRPManager to allow/prohibit LB from the source cell to the target cell.
Step 3 (*) (M)	The LB is allowed / prohibited from the source cell to the target cell by the corresponding eNB(s).
Step 4 (*) (M)	Reporting of the allowing/prohibiting LB operation result to the IRPManager.
Ends when (*)	Ends when all steps identified above are completed or when an exception occurs.
Exceptions	One of the steps identified above fails and retry is unsuccessful.
Post Conditions	The LB is allowed/prohibited from a source cell to a target cell successfully or unsuccessfully.
Traceability (*)	REQ-SO_LB-FUN-3, REQ-SO_LB-FUN-4, REQ-SO_LB-FUN-5

6.4.3 Use case NM centralized Coverage and Capacity Optimization

Use Case Stage	Evolution / Specification	<<Uses>> Related use
Goal	Optimize the Coverage and Capacity in the network
Actors and Roles	IRPManager as user and IRPAgent as client
Telecom resources	The E-UTRAN network including its NM and DM/EM. The CCO function that is located in the NM.
Assumptions	There is no EM centralised CCO function in operation.
Pre-conditions	The network is operational. The CCO function requests the IRPAgent to subscribe the needed performance measurements via the IRPManager that are not already subscribed. The IRPAgent initiates the requested performance measurements that are not already active.
Begins when	The operator turns on the CCO function.
Step 1 (M)	The CCO function waits for performance measurements.
Step 2 (M)	The IRPAgent delivers the performance measurements to the CCO function via the IRPManager.
Step 3 (M)	The CCO function evaluates if there are any potential improvements to be made. If no more detailed information is needed to determine an improvement action, go to step 9.
Step 4 (M)	The CCO function initiates detailed improvement analysis, e.g. MDT measurements, in the area for which a potential improvement has been identified, via the IRPManager to the IRPAgent.
Step 5 (M)	The IRPAgent initiates the requested session and transfers the result to the TCE specified by the CCO function.
Step 6 (M)	The network information is transferred to the CCO function that evaluates whether an improvement action can be applied.
Step 7 (M)	The CCO function initiates the IRPManager to instruct the IRPAgent to apply improvement actions (re-configure some attributes).
Step 8 (M)	The IRPAgent applies the improvement actions and informs the CCO function via the IRPManager.
Step 9 (M)	The CCO function goes to step 1.
Ends when	Ends when the operator turns off the CCO function.
Exceptions	If no improvement action can be applied and the coverage and capacity situation is very bad (e.g. no coverage on any RAT is detected in an area), the operator is informed and the CCO function is turned off for that area.
Post Conditions	The network is operational.
Traceability	REQ-SO_CC_NM-FUN-1, REQ-SO_CC_NM-FUN-2, REQ-SO_CC_NM-FUN-3, REQ-SO_CC_NM-FUN-4 and REQ-SO_CC_NM-FUN-5.