6 Specification level requirements

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

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

3dTower.emf

3dTower.emf

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

X

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

3dTower.emf

3dTower.emf

3dTower.emf

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

Cell B

Cell A

X

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

3dTower.emf

3dTower.emf

3dTower.emf

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

Cell B

Cell A

X

X = radio link failure

3dTower.emf

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

3dTower.emf

3dTower.emf

3dTower.emf

Cell B

Cell A

= HO triggering

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

3dTower.emf

3dTower.emf

3dTower.emf

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 Capacity and coverage optimization

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

REQ-SO_CC-FUN-2 CCO function shall aim at providing optimal capacity and coverage for the radio network while considering the tradeoff 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.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