6 Specification level requirements
28.3133GPPManagement and orchestrationRelease 17Self-Organizing Networks (SON) for 5G networksTS
6.1 Requirements
6.1.1 Distributed SON management
6.1.1.1 RACH Optimization (Random Access Optimisation)
REQ-RACH-FUN-1 The producer of provisioning MnS should have a capability allowing the authorized consumer to set and update the targets for RACH optimization function.
REQ-RACH-FUN-2 The producer of provisioning MnS should have a capability allowing an authorized consumer to enable or disable the RACH optimization function.
REQ-RACH-FUN-3 The producer of provisioning MnS should have a capability allowing the authorized consumer to collect performance measurements that are used to evaluate the RACH performance.
6.1.1.2 MRO (Mobility Robustness Optimisation)
REQ-MRO-FUN-1 The producer of provisioning MnS should have a capability allowing the MnS consumer to set the targets, HO offset ranges, and control parameters for MRO function.
REQ-MRO-FUN-2 The producer of provisioning MnS should have a capability allowing the MnS consumer to collect the handover related performance measurements that are used to evaluate the MRO performance.
REQ-MRO-FUN-3 The producer of provisioning MnS should have a capability allowing the MnS consumer to enable or disable the MRO function.
REQ-MRO-FUN-4 The producer of provisioning MnS should have a capability allowing the MnS consumer to update the targets, HO offset ranges, and control information for MRO function.
6.1.1.3 ANR management in NG-RAN
The business level requirements in clause 5.1.1 are decomposed into the following specification level requirements, applicable for NG-RAN:
REQ-NR-ANR-FUN-01 Producer of provisioning MnS shall support a capability allowing an authorized consumer to request establishment of an Xn connection to the neighbour gNB, or an Xn connection to the neighbour ng-eNB.
REQ-NR-ANR-FUN-02 Producer of provisioning MnS shall support a capability allowing an authorized consumer to request that an existing Xn connection to a neighbour gNB, or an Xn connection to a neighbour ng-eNB to be released, and that the establishment of such a connection is prohibited.
REQ-NR-ANR-FUN-03 Producer of provisioning MnS shall support a capability allowing an authorized consumer to request that an NCR is allowed to be removed.
REQ-NR-ANR-FUN-04 Producer of provisioning MnS shall support a capability allowing an authorized consumer to request that an NCR is not allowed to be removed.
REQ-NR-ANR-FUN-05 Producer of provisioning MnS shall support a capability allowing an authorized consumer to disable or enable the ANR function in one or more gNBs.
6.1.1.4 PCI configuration and re-configuration
REQ-DPCI-CONFIG-FUN-1 producer of provisioning MnS should have a capability allowing an authorized consumer to set or update the list(s) of PCI value(s) for NR cell(s).
REQ-DPCI-CONFIG-FUN-2 producer of provisioning MnS should have a capability allowing an authorized consumer to enable or disable the PCI configuration function.
REQ-DPCI-CONFIG-FUN-3 producer of provisioning MnS should have a capability to notify the authorized consumer with the PCI value(s) being selected for NR cell(s).
REQ-DPCI-CONFIG-FUN-4 producer of provisioning MnS should have a capability to notify the authorized consumer about the resolution of PCI collision or PCI confusion problems for NR cells.
REQ-DPCI-CONFIG-FUN-5 producer of provisioning MnS should have a capability allowing an authorized consumer to configure or re-configure the PCI list at the PCI configuration function.
REQ-DPCI-CONFIG-FUN-6 producer of fault supervision MnS should have a capability to generate or clear the alarm to PCI configuration function failure.
6.1.1.5 LBO (Load Balancing Optimisation)
REQ-DLBO-FUN-1 Provisioning MnS for D-LBO function should have a capability allowing an authorized consumer to set or update the ranges of HO and/or reselection parameters, and control parameters for LBO function.
REQ-DLBO-FUN-2 Performance assurance MnS for D-LBO function should have a capability allowing the authorized consumer to collect the LBO related performance measurements that are used to evaluate the LBO performance.
REQ-DLBO-FUN-3 Provisioning MnS for D-LBO function should have a capability to notify the authorized consumer about the LBO actions being performed.
6.1.1.6 CHO management
REQ-DCHO-FUN-1 The producer of NF provisioning MnS should have the capability allowing an authorized consumer to enable or disable Conditional Handover for a gNB.
REQ-DCHO-FUN-2 The producer of NF performance assurance MnS should have the capability to produce measurements related to CHO.
6.1.1.7 DAPS handover management
REQ-DDAPSHO-FUN-1 The producer of NF provisioning MnS should have the capability allowing an authorized consumer to enable or disable DAPS handover for a gNB.
REQ-DDAPSHO-FUN-2 The producer of NF performance assurance MnS should have the capability to produce measurements related to DAPS handover.
6.1.2 Centralized SON
6.1.2.1 PCI configuration
REQ- CPCI-CONFIG-FUN-1 The producer of provisioning MnS should have a capability allowing an authorized consumer to configure or re-configure the PCI value(s) for NR cell(s).
REQ- CPCI-CONFIG-FUN-2 The producer of provisioning MnS should have a capability to notify the authorized consumer with the PCI value(s) being assigned to NR cell(s).
REQ-CPCI-CONFIG-FUN-3 The producer of performance assurance MnS should have a capability allowing an authorized consumer to collect performance measurements about handover degradation which may be caused by PCI collision or PCI confusion problems for NR cells.
REQ-CPCI-CONFIG-FUN-4 The trace data producer MnS should have a capability to supply the authorized consumer with data allowing it to detect PCI collision or PCI confusion problems for NR cells.
REQ-CPCI-CONFIG-FUN-5 The producer of performance assurance MnS should have a capability to notify the authorized consumer about handover improvement which is the result of a resolved PCI collision or PCI confusion problem for NR cells.
6.1.2.2 LBO (Load Balancing Optimisation)
REQ-CLBO-FUN-1 Provisioning MnS for C-LBO function should have a capability allowing an authorized consumer to set or update the ranges of HO and/or reselection parameters for LBO function.
REQ-CLBO-FUN-2 Performance assurance MnS for C-LBO function should have a capability allowing the authorized consumer to collect the LBO load and LBO related performance measurements.
6.1.2.2 Requirements for RAN NE plug and connect to management system
The requirements for plug and connect an NE to management system are specified in TS 28.314 [22].
6.1.2.3 Requirements for self-configuration of a new RAN NE
REQ-SCM-CON-1 The MnS for self-configuration management shall have the capability allowing MnS consumer request MnS producer to create, query and delete Self-configuration management profile.
REQ-SCM-CON-2 The MnS for Self-configuration management shall have the capability allowing MnS consumer obtain the progress of self-configuration process form MnS producer.
6.1.2.4 RRM resources optimization for network slice instance(s)
REQ-RRM-FUN-1 producer of provisioning MnS should have a capability allowing authorized consumer(s) to update the RRM policies.
REQ-RRM-FUN-2 producer of performance assurance MnS should have a capability allowing authorized consumer(s) to collect the RRM related performance measurements on a per network slice instance basis.
6.1.2.5 Centralized Capacity and Coverage Optimization
REQ-CCO-FUN-1 producer of provisioning MnS should have a capability allowing authorized consumer(s) to update the CCO control parameters.
REQ-CCO-FUN-2 producer of performance assurance MnS should have a capability allowing authorized consumer(s) to collect the CCO related measurements, MDT, RLF and RCEF reports.
6.2 Actor roles
See use cases in clause 6.4.
6.3 Telecommunication resources
See use cases in clause 6.4.
6.4 Use cases
6.4.1 Distributed SON management
6.4.1.1 RACH Optimization (Random Access Optimisation)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically configure the RACH parameters in a cell in order to achieve the optimal network performance by reducing the network access time, and minimize the failures. |
|
|
Actors and Roles |
D-SON management function to support RACH Optimization function. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management function decides to enable the RACH Optimization function. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to set the targets for the RACH optimization function. |
|
|
Step 2 (M) |
The D-SON management function requests the producer of provisioning MnS to enable the RACH optimization function. |
|
|
Step 3 (M) |
The D-SON management function collects the RACH related measurements, and analyse them to evaluate the RACH performance. |
|
|
Step 4 (O) |
If the D-SON management function determines that the RACH performance does not meet the target, it updates the targets for RACH optimization function; |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The RACH performance has been optimized. |
|
|
Traceability |
REQ-RACH-FUN-1, REQ-RACH-FUN-2, REQ-RACH-FUN-3 |
6.4.1.2 MRO (Mobility Robustness Optimisation)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically configure the handover parameters in cells or beams in order to improve the handover performance. |
|
|
Actors and Roles |
D-SON management function to support MRO function. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management decides to enable MRO function. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to set the targets, HO offset ranges, and control information for the MRO function. |
|
|
Step 2 (M) |
The D-SON management function requests the producer of provisioning MnS to enable the MRO function. |
|
|
Step 3 (M) |
The MRO function detects handover issues (e.g. too late HO, too early HO and HO to a wrong cell) in intra-RAT or inter-RAT mobility by analysing reports from UEs and network side information, and acts to mitigate the HO issues by adjusting HO related parameters. |
|
|
Step 4 (M) |
The D-SON management function collects MRO related measurements, and analyses them to evaluate the MRO performance. |
|
|
Step 5 (M) |
The D-SON management function performs the following action, if the MRO performance does not meet the target: 1. Update the targets for MRO function. 2. Update the ranges for MRO function. 3. Update the control information for MRO function. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The MRO performance has been optimized. |
|
|
Traceability |
REQ-MRO-FUN-1, REQ- MR-FUN-2, REQ-MRO-FUN-3, REQ-MRO-FUN-4 |
6.4.1.3 ANR management
6.4.1.3.1 Starting the ANR function
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to make the ANR function in the gNB is enabled. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is not active. The gNB may have NCRs. The NCRs may be configured by a MnS consumer or may have been added by the ANR function if the ANR function has been active previously. |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to enable the ANR function in a gNB. |
|
|
Step 1 (M) |
The MnS consumer enables the ANR function in the gNB. |
|
|
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 ANR function in gNB is successfully enabled by the MnS consumer, or if unsuccessful, still disabled. |
|
|
Traceability |
REQ-NR-ANR-FUN-0h |
6.4.1.3.2 Stopping the ANR function
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to make the ANR function in the gNB is disabled. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to disable the ANR function in a gNB. |
|
|
Step 1 (M) |
The MnS consumer disables the ANR function in the gNB. |
|
|
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 ANR function in gNB is successfully disabled by the MnS consumer, or if unsuccessful, still enabled. All existing NCRs, whether created by ANR or otherwise are unaltered. |
|
|
Traceability |
REQ-NR-ANR-FUN-0h |
6.4.1.3.3 Sending notification of added or deleted NCR
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is for the MnS producer to send a notification of added or deleted NCR to the MnS consumer. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management. |
|
|
Telecom resources |
The MnS producer of D-SON management. gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active |
|
|
Begins when |
An NCR is added or deleted. This could be the result of either the ANR function’s action, or the creation of the deletion of an NCR by a MnS consumer. |
|
|
Step 1 (M) |
The MnS producer sends a notification to the MnS consumer. |
|
|
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 MnS consumer is aware of the creation or deletion of the NCR. |
|
|
Traceability |
REQ-NR-ANR-FUN-0m |
6.4.1.3.4 Handover Allowlisting
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to make an NCR present in the NCRT, useful for handovers. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active. |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to allowlist an NCR. |
|
|
Step 1 (O) |
The MnS consumer creates the NCR This step is executed if it the wanted NCR not already present in the NCRT. |
|
|
Step 2 (M) |
The MnS consumer marks the NCR so that handovers are allowed, and so that the ANR function is not allowed to remove the NCR. |
|
|
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 wanted NCR is present in the NCRT. It is protected from being removed by the ANR function. |
|
|
Traceability |
REQ-NR-ANR-FUN-0c, REQ-NR-ANR-FUN-0i |
6.4.1.3.5 Handover Blocklisting
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to make an NCR is present in the NCRT and made unavailable for handovers. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active. |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to blocklist an NCR. |
|
|
Step 1 (O) |
The MnS consumer creates the NCR. This step is executed if it the wanted NCR not already present in the NCRT. |
|
|
Step 2 (M) |
The MnS consumer marks the NCR so that handovers are prohibited, and so that the ANR function is not allowed to remove the NCR. |
|
|
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 wanted NCR is present in the NCRT. It is protected from being removed by the ANR function. |
|
|
Traceability |
REQ-NR-ANR-FUN-0d, REQ-NR-ANR-FUN-0i |
6.4.1.3.6 Prohibiting X2 or Xn connection to a peer node (X2/Xn blocklisting)
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to prohibit a gNB from setting up an X2 or Xn connection to a peer gNB or eNB. If such a connection existed, it is brought down. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active. |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to prohibit the setting up of X2 or Xn connections to a peer node. |
|
|
Step 1 (M) |
The MnS consumer configures the MnS producer with the peer node into the list of nodes for which X2 or Xn connections are prohibited. |
|
|
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 peer node is in the block-list. If an X2 or Xn connection was present to the peer node, it is brought down. |
|
|
Traceability |
REQ-NR-ANR-FUN-0g |
6.4.1.3.7 Prohibiting handover over X2 or Xn (X2/Xn handover blocklisting)
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|
Goal |
The goal is to prohibit a gNB from using an X2 or Xn connection to a peer gNB or eNB for handover. |
|
|
Actors and Roles |
A MnS consumer of the MnS of D-SON management. |
|
|
Telecom resources |
The MnS producer of D-SON management gNB |
|
|
Assumptions |
||
|
Pre-conditions |
The ANR function is active. |
|
|
Begins when |
The Use Case begins when the MnS consumer decides to prohibit using the X2 or Xn connection to a peer node for handover. |
|
|
Step 1 (M) |
The MnS consumer configures the MnS producer to mark the NCR to the peer node so that handovers over the X2 or Xn connection are prohibited. |
|
|
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 gNB is prohibited from using the using the X2 or Xn connection to the peer node for handovers. |
|
|
Traceability |
REQ-NR-ANR-FUN-0o |
6.4.1.4 PCI configuration
6.4.1.4.1 Initial PCI configuration
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically configure the initial PCI for a NR cell,from a list of PCIs . |
|
|
Actors and Roles |
D-SON management function to support initial PCI list configuration. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management function decides to configure the PCI list for a NR cell. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to configure the PCI list for a cell to the PCI configuration function. |
|
|
Step 2 (M) |
The D-SON management function requests the producer of provisioning MnS to enable the PCI configuration function at NR cell(s). |
|
|
Step 3 (M) |
When the cell is about to start operating, the PCI configuration function selects a PCI value from the list of PCI values and provides that to the NR cell. |
|
|
Step 4 (M) |
The producer of provisioning MnS notifies the consumer with the PCI value being assigned for the NR cell. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The PCI value of a NR cell has been configured. |
|
|
Traceability |
REQ-DPCI-CONFIG-FUN-1, REQ-DPCI-CONFIG-FUN-2, REQ-DPCI-CONFIG-FUN-3, REQ-DPCI-CONFIG-FUN-5 |
6.4.1.4.2 PCI re-configuration failure mitigation
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically re-configure the PCI list of an NR cell, due to the failure of PCI configuration function to resolve PCI collision or PCI confusion problems. |
|
|
Actors and Roles |
D-SON management function to support PCI re-configuration. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The PCI configuration function has detected the PCI problem of a PCI collision or a PCI confusion for an NR cell. |
|
|
Step 1 (M) |
The D-SON management function receives an alarm from the producer of fault supervision MnS indicating the PCI configuration function failed to resolve PCI collision or PCI confusion problems for an NR cell(s). |
|
|
Step 2 (M) |
The D-SON management function requests the producer of provisioning MnS to re-configure the PCI list at the PCI configuration function. |
|
|
Step 3 (M) |
The PCI configuration function selects PCI value(s) from the PCI list. |
|
|
Step 4 (M) |
The producer of provisioning MnS notifies the consumer about the new PCI value of the NR cell. |
|
|
Step 5 (M) |
The D-SON management function receives a clear alarm notification from the producer of fault supervision MnS indicating the PCI configuration function has resolved the PCI issues. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The PCI collision or PCI confusion have been resolved. |
|
|
Traceability |
REQ-DPCI-CONFIG-FUN-3, REQ-DPCI-CONFIG-FUN-4, REQ-DPCI-CONFIG-FUN-5, REQ-DPCI-CONFIG-FUN-6 |
6.4.1.4.3 PCI re-configuration
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically re-configure the PCI of an NR cell, PCI collision or PCI confusion problems. |
|
|
Actors and Roles |
D-SON management function to support PCI re-configuration. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The PCI configuration function has detected a PCI collision or a PCI confusion for an NR cell. |
|
|
Step 1 (M) |
The PCI configuration function selects a PCI values from the PCI list, and configures the cell with the new PCI value. |
|
|
Step 2 (M) |
The producer of provisioning MnS notifies the consumer about the new PCI value of the NR cell. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The PCI collision or PCI confusion have been resolved. |
|
|
Traceability |
REQ-DPCI-CONFIG-FUN-3, REQ-DPCI-CONFIG-FUN-4 |
6.4.1.5 LBO (Load Balancing Optimisation)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically distribute user traffic among neighboring cells to ensure the radio resources are efficiently used, while providing quality end-user experience and performance. |
|
|
Actors and Roles |
D-SON management function to support LBO function. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management function decides to enable D-LBO function. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to set the handover and/or reselection parameters ranges (see clause 15.5.1.4 in TS 38.300 [7]), and to enable the D-LBO function. |
|
|
Step 2 (M) |
The D-LBO function perform load balancing as describe in clause 15.5 in TS 38.300 [7] and may notify D-LBO management function when the LBO action has been performed. |
|
|
Step 3 (M) |
The D-SON management function collects LBO related measurements. |
|
|
Step 4 (M) |
The D-SON management function analyses the measurements to evaluate the LBO performance and may request the producer of provisioning MnS to update the ranges for HO and/or reselection parameters. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The LBO performance has been optimized. |
|
|
Traceability |
REQ-DLBO-FUN-1, REQ-DLBO-FUN-2, REQ-DLBO-FUN-3 |
6.4.1.6 CHO (Conditional Handover)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To enable CHO. |
|
|
Actors and Roles |
D-SON management function to support the CHO function. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management function intends to enable CHO for a gNB. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to enable CHO for a gNB. |
|
|
Step 2 (M) |
The D-SON management function collects CHO related measurements and analyses them to evaluate the CHO performance. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
CHO is in operation from for a gNB. |
|
|
Traceability |
REQ-DCHO-FUN-1, REQ-DCHO-FUN-2 |
6.4.1.7 DAPS HO (Dual Active Protocol Stack Handover)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To enable DAPS HO. |
|
|
Actors and Roles |
D-SON management function to support the DAPS HO function. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The D-SON management function intends to enable DAPS HO for a gNB. |
|
|
Step 1 (M) |
The D-SON management function requests the producer of provisioning MnS to enable DAPS HO from a source cell to a target cell. |
|
|
Step 2 (M) |
The D-SON management function collects DAPS HO related measurements and analyses them to evaluate the DAPS HO performance. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
DAPS HO is in operation for a gNB. |
|
|
Traceability |
REQ-DDAPSHO-FUN-1, REQ-DDAPSHO-FUN-2 |
6.4.2 Centralized SON
6.4.2.1 PCI configuration
6.4.2.1.1 Initial PCI configuration
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically configure the PCIs of NR cell(s) that have not been assigned with PCI value(s). |
|
|
Actors and Roles |
C-SON function to support PCI configuration. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The C-SON function decides to configure PCI values for NR cell(s). |
|
|
Step 1 (M) |
The C-SON function determines the PCI value(s) for the NR cell(s) that have no collision or confusion with its neighbours. |
|
|
Step 2 (M) |
The C-SON function requests the producer of provisioning MnS to configure the PCI value(s) at the NR cell(s). |
|
|
Step 3 (M) |
The producer of provisioning MnS notifies the consumer with the PCI value(s) being assigned for the NR cell(s). |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The PCI value of a NR cell has been selected. |
|
|
Traceability |
REQ-CPCI-CONFIG-FUN-1, REQ-CPCI-CONFIG-FUN-2 |
6.4.2.1.2 PCI re-configuration
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically re-configure the PCIs of NR cells, due to the PCI collision or PCI confusion problems. |
|
|
Actors and Roles |
C-SON to support PCI re-configuration. |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The C-SON function requests the producer of performance assurance MnS to collect handover performance related measurements reported by NG-RAN. C-SON finds a potential PCI confusion and/or collision based on received PM data. |
|
|
Step 1 (M) |
Based on the measurements above, the C-SON function requests the producer of trace MnS to collect Radio Link Failure traces from UEs in cells where PCI collision or PCI confusion is suspected. |
|
|
Step 2 (M) |
The C-SON function analyses the PCI related information and detects if NR cells have experienced PCI conflict or confusion issues. If no PCI collision or confusion is found, go to step 5. |
|
|
Step 3 (M) |
When the C-SON function detects PCI collision and/or confusion it determines the new PCI value(s), and requests the producer of provisioning MnS to re-configure the PCI value for the NR cell(s) which experienced PCI conflict or confusion issues. |
|
|
Step 4 (M) |
The producer of provisioning MnS notifies the C-SON function about the resolution of PCI collision or PCI confusion problems for NR cell(s). |
|
|
Step 5 (M) |
The C-SON function requests the producer of performance assurance MnS to collect handover performance related measurements reported by NG-RAN in order to assess whether the PCI collision or confusion was corrected. The C-SON function turns off the collection of RLF data. |
|
|
Ends when |
All the steps identified above are successfully completed. Step 5 is done. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The PCI value of a NR cell has been selected. |
|
|
Traceability |
REQ-CPCI-CONFIG-FUN-1, REQ-CPCI-CONFIG-FUN-2, REQ-CPCI-CONFIG-FUN-3, REQ-CPCI-CONFIG-FUN-4, REQ-CPCI-CONFIG-FUN-5 |
6.4.2.2 Use case for establishment of a new RAN NE in network
6.4.2.2.1 Use case for RAN NE plug and connect to management system
The NE described in this use case can be gNB in non-split scenario and gNB-DU in split scenario.
Note: The NE within virtualization is not addressed.
The details of this use case are covered in plug and connect use case in TS 28.314 [22].
6.4.2.2.2 Use case for self-configuration of a new RAN NE
|
Use Case Stage |
Evolution / Specification |
<<Uses>> Related use |
|---|---|---|
|
Goal (*) |
After installation, put in an automated manner the NE into a state to be ready to carry traffic. |
|
|
Actors and Roles (*) |
MnF providing support for self-configuration process act as MnS Producer for Self-configuration management |
|
|
Telecom resources |
NE MnS Consumer of Self-configuration management |
|
|
Assumptions |
IP network connectivity exists between the NE and the MnF(s) providing support for the self-configuration process. |
|
|
Pre conditions |
The NE is installed and connected to an IP network. |
Clause 6.4.2.2.1 Use case for Plug and connect to management system |
|
Begins when |
The field personnel start the self-configuration process. It is also possible that the process is triggered automatically after the completion of an NE self-test or receiving the self-configuration management profile creation request from MnS Consumer for self-configuration management. |
|
|
Step 1 (O) |
MnF providing support for self-configuration process may notify MnS Consumer of self-configuration management about the start of the self configuration process. |
|
|
Step 1 (*) (M|O) |
The order of the bullet points in the list below does not imply any statements on the order of execution. – An NE IP address is allocated to the new NE. – Basic information about the transport network (e. g. gateways) environment is provided to the NE. With this information the NE is able to exchange IP packets with other internet hosts. – The NE provides information about its type, hardware and other relevant data about itself to the MnF(s) providing support for the self-configuration process. – The address(es) of the MnF(s) providing support for the self-configuration process (e.g. MnF for software download, MnF for configuration data download) is provided to the NE. The address is equal to an IP address and a port number, or a DNS name and port number, or an URI. The address(es) of the MnF(s) providing support for normal OAM functions after completion of the self-configuration process are provided to the NE. The address is equal to an IP address and a port number, or a DNS name and port number, or an URI. – The NE connects to the MnF providing support for the software download. – The decision which software or software packages have to be downloaded to the NE is taken. – The software is downloaded into the NE. – The NE connects to the MnF providing support for the configuration data download. – The configuration data for the NE is made available by either preparing it or making prepared configuration data available. – The configuration data is downloaded into the NE. – Dependent External nodes are updated with new configuration data as well (if required). – The NE connects to the MnF providing support for normal OAM functions after completion of the self-configuration process. – The inventory system in the MnF is informed that a new NE is in the field. – The NE performs a self-test. Self-tests of different types can run at different places within the self-configuration procedure. – The operator is informed about the progress of the self-configuration process and important events occurring during the self-configuration process. – The network resource models are updated during and after the self-configuration process. – SW is installed, i.e. prepared in such a way, that the NE is ready to use it. NE is allowed to use the SW. |
|
|
Step 3 (O) |
MnF providing support for self-configuration process may notify MnS Consumer of Self-configuration management about the progress of the self configuration during self-configuration process. |
|
|
Ends when (*) |
Ends when all steps identified above are successfully completed or when an exception occurs. |
|
|
Exceptions |
||
|
Post Conditions |
The NE is ready to carry traffic. |
|
|
Traceability (*) |
All requirements of clause 6.1.2.3 |
6.4.2.3 RRM resources optimization for network slice instance(s)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To enable the optimization of the RRM resources allocated among network slice instance(s) to ensure the RRM resources are efficiently used, while providing quality end-user experience and performance. |
|
|
Actors and Roles |
C-SON function to support RRM resource optimization for network slice instance(s). |
|
|
Telecom resources |
|
|
|
Assumptions |
N/A |
|
|
Pre-conditions |
|
|
|
Begins when |
The C-SON function has been enabled. |
|
|
Step 1 (M) |
The C-SON function collects RRM related measurements on a per network slice instance basis (e.g. mean DL/UL PRB used for data traffic, mean number of DRBs successfully setup, and mean number of PDU Sessions successfully setup, … etc.), by consuming the MnS of performance assurance. |
|
|
Step 2 (M) |
The C-SON function analyzes the measurements to train the AI/ML model and determines the actions to optimize the RRM resources for network slice instance(s) that include consuming the MnS of provisioning to update the appropriate RRM policies. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The RRM resources for network slice instance(s) have been optimized. |
|
|
Traceability |
REQ-RRM-FUN-1, REQ-RRM-FUN-2 |
6.4.2.4 Centralized Capacity and Coverage Optimization (CCO)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To optimize the capacity and coverage of NR cells to insure the efficient network resource usage, and optimal end-user experience and performance. |
|
|
Actors and Roles |
C-SON function to support CCO. |
|
|
Telecom resources |
|
|
|
Assumptions |
– PM job control and provisioning have been executed to allow C-SON function to receive performance measurements, MDT, RLF, and RCEF reports. |
|
|
Pre-conditions |
|
|
|
Begins when |
The C-SON function has been configured with control information and enabled. |
|
|
Step 1 (M) |
The C-SON function collects measurements (e.g. distribution of RSRP, RSRQ, …), MDT, RLF, and RCEF reports to monitor the issues (e.g. coverage holes, capacity deficiency, …) for NR cells or beams. |
|
|
Step 2 (M) |
The C-SON function analyzes the measurements and MDT, RLF, RCEF reports to determine the actions if needed to optimize the NR cells or beams capacity and coverage according to the coverage optimization control policy i.e. adjusting the adjustable parameters within the specified ranges. |
|
|
Step 3 (O) |
C-SON function consumes the provisioning MnS to re-configure the CCO control parameters. |
|
|
Step 4 (O) |
The C-SON function collects measurements to evaluate whether the CCO actions have resolved the issues. |
|
|
Step 5 (O) |
The C-SON function may re-configure or restore the CCO control parameters, if the issues have not been mitigated. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The capacity and coverage of NR cells have been optimized. |
|
|
Traceability |
REQ-CCO-FUN-1, REQ-CCO-FUN-2, |
6.4.2.5 LBO (Load Balancing Optimisation)
|
Use case stage |
Evolution/Specification |
<<Uses>> |
|---|---|---|
|
Goal |
To automatically distribute user traffic among neighboring cells to ensure the radio resources are efficiently used, while providing quality end-user experience and performance. |
|
|
Actors and Roles |
C-LBO function to support LBO. |
|
|
Telecom resources |
|
|
|
Assumptions |
Both Domain Centralized SON and Cross-Domain Centralized SON are supported. |
|
|
Pre-conditions |
|
|
|
Begins when |
The C-LBO function is enabled. |
|
|
Step 1 (M) |
The C-LBOfunction collects LBO load measurements by consuming the MnS of performance assurance. |
|
|
Step 2 (M) |
The C-LBOfunction analyses measurements to determine the actions to optimize the traffic load distributions among neighboring cells that include consuming the MnS of provisioning to update the ranges for handover parameters. |
|
|
Step 3 (M) |
The C-LBOfunction collects LBO related measurements, and analyses them to evaluate the LBO performance, and may request the producer of provisioning MnS to update the ranges for HO and/or reselection parameters. |
|
|
Ends when |
All the steps identified above are successfully completed. |
|
|
Exceptions |
One of the steps identified above fails. |
|
|
Post-conditions |
The LBO performance has been optimized. |
|
|
Traceability |
REQ-CLBO-FUN-1, REQ-CLBO-FUN-2 |