15 Self-Configuration and Self-Optimisation

38.3003GPPNRNR and NG-RAN Overall descriptionRelease 17Stage 2TS

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

15.1 Definitions

Void.

15.2 Void

15.3 Self-configuration

15.3.1 Dynamic configuration of the NG-C interface

15.3.1.1 Prerequisites

The following prerequisites are assumed:

– An initial remote IP end point to be used for SCTP initialisation is provided to the NG-RAN node for each AMF the NG-RAN node is supposed to connect to.

15.3.1.2 SCTP initialization

NG-RAN establishes the first SCTP (IETF RFC 4960 [23]) using a configured IP address.

NOTE: The NG-RAN node may use different source and/or destination IP end point(s) if the SCTP establishment towards one IP end point fails. How the NG-RAN node gets the remote IP end point(s) and its own IP address are outside the scope of this specification.

15.3.1.3 Application layer initialization

Once SCTP connectivity has been established, the NG-RAN node and the AMF shall exchange application level configuration data over NGAP with the NG Setup procedure, which is needed for these two nodes to interwork correctly on the NG interface:

– The NG-RAN node provides the relevant configuration information to the AMF, which includes list of supported TA(s), etc.;

– The AMF provides the relevant configuration information to the NG-RAN node, which includes PLMN ID, etc.;

– When the application layer initialization is successfully concluded, the dynamic configuration procedure is completed and the NG-C interface is operational.

After the application layer initialization is successfully completed, the AMF may add or update or remove SCTP endpoints to be used for NG-C signalling between the AMF and the NG-RAN node pair as specified in TS 23.501 [3].

15.3.2 Dynamic Configuration of the Xn interface

15.3.2.1 Prerequisites

The following prerequisites are necessary:

– An initial remote IP end point to be used for SCTP initialisation is provided to the NG-RAN node.

15.3.2.2 SCTP initialization

NG-RAN establishes the first SCTP (IETF RFC 4960 [23]) using a configured IP address.

NOTE: The NG-RAN node may use different source and/or destination IP end point(s) if the SCTP establishment towards one IP end point fails.

15.3.2.3 Application layer initialization

Once SCTP connectivity has been established, the NG-RAN node and its candidate peer NG-RAN node are in a position to exchange application level configuration data over XnAP needed for the two nodes to interwork correctly on the Xn interface:

– The NG-RAN node provides the relevant configuration information to the candidate NG-RAN node, which includes served cell information;

– The candidate NG-RAN node provides the relevant configuration information to the initiating NG-RAN node, which includes served cell information;

– When the application layer initialization is successfully concluded, the dynamic configuration procedure is completed and the Xn interface is operational;

– The NG-RAN node shall keep neighbouring NG-RAN nodes updated with the complete list of served cells, or, if requested by the peer NG-RAN node, by a limited list of served cells, while the Xn interface is operational.

15.3.3 Automatic Neighbour Cell Relation Function

15.3.3.1 General

The purpose of ANR function is to relieve the operator from the burden of manually managing NCRs. Figure 15.3.3.1-1 shows ANR and its environment:

Figure 15.3.3.1-1: Interaction between gNB and OAM due to ANR

The ANR function resides in the gNB and manages the Neighbour Cell Relation Table (NCRT). Located within ANR, the Neighbour Detection Function finds new neighbours and adds them to the NCRT. ANR also contains the Neighbour Removal Function which removes outdated NCRs. The Neighbour Detection Function and the Neighbour Removal Function are implementation specific.

An existing NCR from a source cell to a target cell means that gNB controlling the source cell:

a) Knows the global and physical IDs (e.g. NR CGI/NR PCI, ECGI/PCI) of the target cell; and

b) Has an entry in the NCRT for the source cell identifying the target cell; and

c) Has the attributes in this NCRT entry defined, either by OAM or set to default values.

NCRs are cell-to-cell relations, while an Xn link is set up between two gNBs. Neighbour Cell Relations are unidirectional, while an Xn link is bidirectional.

NOTE: The neighbour information exchange, which occurs during the Xn Setup procedure or in the gNB Configuration Update procedure, may be used for ANR purpose.

The ANR function also allows OAM to manage the NCRT. OAM can add and delete NCRs. It can also change the attributes of the NCRT. The OAM system is informed about changes in the NCRT.

15.3.3.2 Intra-system Automatic Neighbour Cell Relation Function

ANR relies on NCGI (see clause 8.2) and ANR reporting of E-UTRA cells as specified in TS 36.300 [2].

Figure 15.3.3.2-1: Automatic Neighbour Relation Function

Figure 15.3.3.2-1 depicts an example where the NG-RAN node serving cell A has an ANR function. In RRC_CONNECTED, the NG-RAN node instructs each UE to perform measurements on neighbour cells. The NG-RAN node may use different policies for instructing the UE to do measurements, and when to report them to the NG-RAN node. This measurement procedure is as specified in TS 38.331[12] and TS 36.331 [29].

1. The UE sends a measurement report regarding cell B. This report contains Cell B’s PCI, but not its NCGI/ECGI.

When the NG-RAN node receives a UE measurement report containing the PCI, the following sequence may be used.

2. The NG-RAN node instructs the UE, using the newly discovered PCI as parameter, to read all the broadcast NCGI(s) /ECGI(s), TAC(s), RANAC(s), PLMN ID(s) and, for neighbour NR cells, NR frequency band(s) and the gNB ID length(s). To do so, the NG-RAN node may need to schedule appropriate idle periods to allow the UE to read the NCGI/ECGI from the broadcast channel of the detected neighbour cell. How the UE reads the NCGI/ECGI is specified in TS 38.331 [12] and TS 36.331 [29].

3. When the UE has found out the new cell’s NCGI(s) /ECGI(s), the UE reports all the broadcast NCGI(s)/ECGI(s) to the serving cell NG-RAN node. In addition, the UE reports all the tracking area code(s), RANAC(s), PLMN IDs and, for neighbour NR cells, NR frequency band(s), and the gNB ID length(s) that have been read by the UE. In case the detected NR cell does not broadcast SIB1, the UE may report noSIB1 indication as specified in TS 38.331 [12].

4. The NG-RAN node decides to add this neighbour relation, and can use PCI and NCGI(s)/ECGI(s) to:

a. Lookup a transport layer address to the new NG-RAN node;

b. Update the Neighbour Cell Relation List;

c. If needed, setup a new Xn interface towards this NG-RAN node.

15.3.3.3 Void

15.3.3.4 Void

15.3.3.5 Inter-system Automatic Neighbour Cell Relation Function

For Inter-system ANR, each cell contains an Inter Frequency Search list. This list contains all frequencies that shall be searched. Figure 15.3.3.5-1 depicts an example where the NG-RAN node serving cell A has an ANR function.

Figure 15.3.3.5-1: Automatic Neighbour Relation Function in case of E-UTRAN detected cell

In RRC_CONNECTED, the NG-RAN node instructs a UE to perform measurements and detect E-UTRA cells connected to EPC.:

1 The NG-RAN node instructs a UE to look for neighbour cells in the target system. To do so the NG-RAN node may need to schedule appropriate idle periods to allow the UE to scan all cells in the target system.

2 The UE reports the PCI and carrier frequency of the detected cells in the target system.

NOTE: The NG-RAN node may use different policies for instructing the UE to do measurements, and when to report them to the NG-RAN node.

When the NG-RAN node receives the UE reports containing PCIs of cell(s), the following sequence may be used:

3 The NG-RAN node instructs the UE, using the newly discovered PCI as parameter, to read the ECGI, the TAC and all available PLMN ID(s) of the newly detected cell in case of E-UTRA detected cells. The UE ignores transmissions from the serving cell while finding the requested information transmitted in the broadcast channel of the detected inter-system/inter-frequency neighbour cell. To do so, the NG-RAN node may need to schedule appropriate idle periods to allow the UE to read the requested information from the broadcast channel of the detected inter-system neighbour cell.

4 After the UE has read the requested information in the new cell, it reports the detected ECGI, TAC, and available PLMN ID(s) to the serving cell NG-RAN node.

5 The NG-RAN node updates its inter-system NCRT.

15.3.4 Xn-C TNL address discovery

If the NG-RAN node is aware of the RAN node ID of the candidate NG-RAN node (e.g. via the ANR function) but not of a TNL address suitable for SCTP connectivity, then the NG-RAN node can utilize the 5GC (an AMF it is connected to) to determine the TNL address as follows:

– The NG-RAN node sends the UPLINK RAN CONFIGURATION TRANSFER message to the AMF to request the TNL address of the candidate NG-RAN node, and includes relevant information such as the source and target RAN node ID;

– The AMF relays the request by sending the DOWNLINK RAN CONFIGURATION TRANSFER message to the candidate NG-RAN node identified by the target RAN node ID;

– The candidate NG-RAN node responds by sending the UPLINK RAN CONFIGURATION TRANSFER message containing one or more TNL addresses to be used for SCTP connectivity with the initiating NG-RAN node, and includes other relevant information such as the source and target RAN node ID;

– The AMF relays the response by sending the DOWNLINK CONFIGURATION TRANSFER message to the initiating NG-RAN node identified by the target RAN node ID.

NOTE: Void.

The NG-RAN node may determine the gNB ID length of the candidate gNB based on, e.g.OAM configuration or UE reporting in ANR function. If the NG-RAN node is not able to make this determination, it may include the NR cell identifier in the UPLINK RAN CONFIGURATION TRANSFER message to the AMF. The AMF may, if supported, determine the target gNB ID by matching the NR cell identifier with a gNB ID of a gNB it connects to.

15.4 Support for Energy Saving

15.4.1 General

The aim of this function is to reduce operational expenses through energy savings.

The function allows, for example in a deployment where capacity boosters can be distinguished from cells providing basic coverage, to optimize energy consumption enabling the possibility for an E-UTRA or NR cell providing additional capacity via single or dual connectivity, to be switched off when its capacity is no longer needed and to be re-activated on a need basis.

15.4.2 Solution description

15.4.2.1 Intra-system energy saving

The solution builds upon the possibility for the NG-RAN node owning a capacity booster cell to autonomously decide to switch-off such cell to lower energy consumption (inactive state). The decision is typically based on cell load information, consistently with configured information. The switch-off decision may also be taken by O&M.

The NG-RAN node may initiate handover actions in order to off-load the cell being switched off and may indicate the reason for handover with an appropriate cause value to support the target node in taking subsequent actions, e.g. when selecting the target cell for subsequent handovers.

All neighbour NG-RAN nodes are informed by the NG-RAN node owning the concerned cell about the switch-off actions over the Xn interface, by means of the NG-RAN node Configuration Update procedure.

All informed nodes maintain the cell configuration data, e.g., neighbour relationship configuration, also when a certain cell is inactive. If basic coverage is ensured by NG-RAN node cells, NG-RAN node owning non-capacity boosting cells may request a re-activation over the Xn interface if capacity needs in such cells demand to do so. This is achieved via the Cell Activation procedure. During switch off time period of the boost cell, the NG-RAN node may prevent idle mode UEs from camping on this cell and may prevent incoming handovers to the same cell.

The NG-RAN node receiving a request should act accordingly. The switch-on decision may also be taken by O&M. All peer NG-RAN nodes are informed by the NG-RAN node owning the concerned cell about the re-activation by an indication on the Xn interface.

15.4.2.2 Inter-system energy saving

The solution builds upon the possibility for the NG-RAN node owning a capacity booster cell to autonomously decide to switch-off such cell to dormant state. The decision is typically based on cell load information, consistently with configured information. The switch-off decision may also be taken by O&M. The NG-RAN node indicates the switch-off action to the eNB over NG interface and S1 interface. The NG-RAN node could also indicate the switch-on action to the eNB over NG interface and S1 interface.

The eNB providing basic coverage may request a NG-RAN node’s cell re-activation based on its own cell load information or neighbour cell load information, the switch-on decision may also be taken by O&M. The eNB requests a NG-RAN node’s cell re-activation and receives the NG-RAN node’s cell re-activation reply from the NG-RAN node over the S1 interface and NG interface. Upon reception of the re-activation request, the NG-RAN node’s cell should remain switched on at least until expiration of the minimum activation time. The minimum activation time may be configured by O&M or be left to the NG-RAN node’s implementation.

15.4.3 O&M requirements

Operators should be able to configure the energy saving function.

The configured information should include:

– The ability of an NG-RAN node to perform autonomous cell switch-off;

– The ability of an NG-RAN node to request the re-activation of a configured list of inactive cells owned by a peer NG-RAN node.

O&M may also configure:

– policies used by the NG-RAN node for cell switch-off decision;

– policies used by peer NG-RAN nodes for requesting the re-activation of an inactive cell;

– The minimum time an NG-RAN node’s cell should remain activated upon reception of a re-activation request from an eNB.

15.5 Self-optimisation

15.5.1 Support for Mobility Load Balancing

15.5.1.1 General

The objective of mobility load balancing is to distribute load evenly among cells and among areas of cells, or to transfer part of the traffic from congested cell or from congested areas of cells, or to offload users from one cell, cell area, carrier or RAT to achieve network energy saving. This can be done by means of optimization of cell reselection/handover parameters and handover actions. The automation of such optimisation can provide high quality user experience, while simultaneously improving the system capacity and also to minimize human intervention in the network management and optimization tasks.

Intra-RAT, intra-system inter-RAT and inter-system load balancing scenarios are supported.

In general, support for mobility load balancing consists of one or more of following functions:

– Load reporting for intra-RAT and intra-system inter-RAT load balancing;

– Load balancing action based on handovers;

– Adapting handover and/or reselection configuration;

– Load reporting for inter-system load balancing.

15.5.1.2 Load reporting for intra-RAT and intra-system inter-RAT load balancing

The load reporting function is executed by exchanging load information over the Xn/X2/F1/E1 interfaces.

The following load related information should be supported which consists of:

– Radio resource usage (per-cell and per SSB area PRB usage: DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, DL/UL total PRB usage, and DL/UL scheduling PDCCH CCE usage; PRB usage for slice(s): DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, and DL/UL Total PRB allocation);

– TNL capacity indicator (UL/DL TNL offered capacity and available capacity);

– Cell Capacity Class value (UL/DL relative capacity indicator);

– Capacity value (per cell, per SSB area and per slice: UL/DL available capacity);

– HW capacity indicator (offered throughput and available throughput over E1, percentage utilisation over F1);

– RRC connections (number of RRC connections, and available RRC Connection Capacity);

– Number of active UEs.

To achieve load reporting function, Resource Status Reporting Initiation & Resource Status Reporting procedures are used.

15.5.1.3 Load balancing action based on handovers

The source cell may initiate handover due to load. The target cell performs admission control for the load balancing handovers. A handover preparation related to a mobility load balancing action is distinguishable from other handovers, so that the target cell is able to apply appropriate admission control.

15.5.1.4 Adapting handover and/or reselection configuration

This function enables requesting of a change of handover and/or reselection parameters at target cell. The source cell that initialized the load balancing estimates if it is needed to change mobility configuration in the source and/or target cell. If the amendment is needed, the source cell initializes mobility negotiation procedure toward the target cell.

The source cell informs the target cell about the new mobility setting and provides cause for the change (e.g. load balancing related request). The proposed change is expressed by the means of 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 initialises the handover preparation procedure. Cell reselection configuration may be amended to reflect changes in the HO setting. The target cell responds to the information from the source cell. The allowed delta range for HO 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.

15.5.1.5 Load reporting for inter-system load balancing

The load reporting function for inter-system load balancing is executed by exchanging load information between NG-RAN and E-UTRAN. Both event-triggered and periodic inter-system load reporting are supported. Event-triggered inter-system load reports are sent when the reporting node detects crossing of cell load thresholds.

The following load related information should be supported:

– Cell Capacity Class value (UL/DL relative capacity indicator);

– Capacity value (per cell: UL/DL available capacity);

– RRC connections (number of RRC connections, and available RRC Connection Capacity);

– Number of active UEs;

– Radio Resource Status (per cell PRB usage: UL/DL GBR PRB usage for MIMO, DL/UL non-GBR PRB usage for MIMO, DL/UL total PRB usage for MIMO).

NGAP procedures used for inter-system load balancing are Uplink RAN Configuration Transfer and Downlink RAN Configuration Transfer.

S1AP procedures used for inter-system load balancing are eNB Configuration Transfer and MME Configuration Transfer.

15.5.2 Support for Mobility Robustness Optimization

15.5.2.1 General

Mobility Robustness Optimisation aims at detecting and enabling correction of following problems:

– Connection failure due to intra-system or inter-system mobility;

– Inter-system Unnecessary HO (too early inter-system HO from NR to E-UTRAN with no radio link failure);

– Inter-system HO ping-pong;

– PSCell change failure.

MRO provides means to distinguish the above problems from NR coverage related problems and other problems, not related to mobility.

For detection of a sub-optimal successful handovers, MRO additionally enables observability of:

– Successful HO due to intra-NR mobility.

15.5.2.2 Connection failure

15.5.2.2.1 General

For analysis of connection failures, the UE makes the RLF Report available to the network.

The UE stores the latest RLF Report, including both LTE and NR RLF report until the RLF report is fetched by the network or for 48 hours after the connection failure is detected.

The UE only indicates RLF report availability and only provides the RLF report to the network if the current RPLMN is a PLMN that was present in the UE’s EPLMN List or was the RPLMN at the time the connection failure was detected. In case RLF happens in an E-UTRA cell, the UE makes the LTE RLF Report available to NG-RAN nodes and eNB(s), and in case RLF happens in an NR cell the UE makes the NR RLF Report available to gNB(s).

If the LTE RLF Report is reported to a NG-RAN node, and the last serving node is an E-UTRAN node, the NG-RAN node may transfer it to the E-UTRAN node by triggering the Uplink RAN configuration transfer procedure over NG and the E-UTRAN node can take this into account as defined in TS 36.300 [2].

15.5.2.2.2 Connection failure due to intra-system mobility

One of the functions of Mobility Robustness Optimization is to detect connection failures that occur due to Too Early or Too Late Handovers, or Handover to Wrong Cell. These problems are defined as follows:

– Intra-system Too Late Handover: an RLF occurs after the UE has stayed for a long period of time in the cell; the UE attempts to re-establish the radio link connection in a different cell.

– Intra-system Too Early Handover: an RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in the source cell.

– Intra-system Handover to Wrong Cell: an RLF occurs shortly after a successful handover from a source cell to a target cell or a handover failure occurs during the handover procedure; the UE attempts to re-establish the radio link connection in a cell other than the source cell and the target cell.

In the definition above, the "successful handover" refers to the UE state, namely the successful completion of the RA procedure.

In case of CHO, the Too Late Handover, Too Early Handover and Handover to Wrong Cell in the definition above means Too Late CHO Execution, Too Early CHO Execution and CHO Execution to Wrong Cell.

Detection mechanism

A failure indication may be initiated after a UE attempts to re-establish the radio link connection at NG-RAN node B after a failure at NG-RAN node A. NG-RAN node B may initiate the Failure Indication procedure towards multiple NG-RAN nodes if they control cells which use the PCI signalled by the UE during the re-establishment procedure. The NG-RAN node receiving this selects the UE context that matches the received Failure Cell ID and C-RNTI, and, if available, uses the shortMAC-I to confirm this identification, by calculating the shortMAC-I and comparing it to the received IE.

A failure indication may also be sent to the node last serving the UE when the NG-RAN node fetches the RLF REPORT from UE by triggering:

– The Failure Indication procedure over Xn;

– The Uplink RAN configuration transfer procedure and Downlink RAN configuration transfer procedure over NG.

The detailed detection mechanisms for too late handover, too early handover and handover to wrong cell are carried out through the following in the NG-RAN node that served the UE before the reported connection failure:

– Intra-system Too Late Handover: there is no recent handover for the UE prior to the connection failure e.g. the UE reported timer is absent or larger than the configured threshold (e.g. Tstore_UE_cntxt), or if CHO is configured but the CHO execution is not initiated for the UE prior to the connection failure, e.g. the UE reported timer is absent or larger than the configured threshold (e.g. Tstore_UE_cntxt), or if DAPS HO is configured but an RLF is detected in the source cell with successful DAPS HO.

– Intra-system Too Early Handover: there is a recent handover for the UE prior to the connection failure e.g. the UE reported timer is smaller than the configured threshold (e.g. Tstore_UE_cntxt), and the first re-establishment attempt cell/the successful re-connect cell is the cell that served the UE at the last handover initialisation or fall back to the source cell configuration in case of DAPS HO.

– Intra-system Handover to Wrong Cell: there is a recent handover for the UE prior to the connection failure e.g. the UE reported timer is smaller than the configured threshold (e.g. Tstore_UE_cntxt), and the first re-establishment attempt cell/ the cell UE attempts to re-connect/the cell UE attempts CHO recovery is neither the cell that served the UE at the last handover initialisation nor the cell that served the UE where the RLF happened or the cell that the handover was initialized toward.

The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure or the time elapsed since the CHO execution until connection failure.

In case of Too Early Handover or Handover to Wrong Cell, the NG-RAN node receiving the failure indication may inform the NG-RAN node controlling the cell where the mobility configuration caused the failure by means of the Handover Report procedure over Xn or the Uplink RAN Configuration Transfer procedure over NG. This may include the RLF report.

Retrieval of information needed for problem analysis

In order to retrieve relevant information collected at the network side as part of the UE context, the UE provides C-RNTI used in the last serving cell. If the cause for the failure is identified as a "Too Early HO" or a "HO to Wrong Cell", the NG-RAN node controlling the last serving cell shall, include in the HANDOVER REPORT message the C-RNTI used in the source cell of the last completed handover before the failure. If the NG RAN node controlling that source cell provided the Mobility Information, it is also included in the HANDOVER REPORT message. If used, the Mobility Information is prepared at the source NG RAN node of a handover and may refer to or identify any handover-related data at this NG RAN node.

Handling multiple reports from a single failure event

In case the RRC re-establishment fails and the RRC connection setup succeeds, MRO evaluation of intra-RAT mobility connection failures may be triggered twice for the same failure event. In this case, only one failure event should be counted.

15.5.2.2.3 Connection failure due to inter-system mobility

One of the functions of Mobility Robustness Optimization is to detect connection failures that occurred due to Too Early or Too Late inter-system handovers. These problems are defined as follows:

– Inter-system/ Too Late Handover: an RLF occurs after the UE has stayed in a cell belonging to an NG-RAN node for a long period of time; the UE attempts to re-connect to a cell belonging to an E-UTRAN node.

– Inter-system/ Too Early Handover: an RLF occurs shortly after a successful handover from a cell belonging to an E-UTRAN node to a target cell belonging to an NG-RAN node; the UE attempts to re-connect to the source cell or to another cell belonging to an E-UTRAN node.

Detection mechanism

A failure indication may be sent to the node last serving the UE when the NG-RAN node fetches the RLF REPORT from UE by triggering:

– The Failure Indication procedure over Xn;

– The Uplink RAN configuration transfer procedure and Downlink RAN configuration transfer procedure over NG.

In case the last serving node is an E-UTRAN node, the detection mechanism proceed as deined in TS 36.300 [2].

In case the last serving node is an NG-RAN node, the detection mechanisms for Too Late Inter-system Handover and Too Early Inter-system Handover are carried out through the following:

– Too Late Inter-system Handover: the connection failure occurs while being connected to a NG-RAN node, and there is no recent handover for the UE prior to the connection failure i.e., the UE reported timer is absent or larger than the configured threshold, e.g., Tstore_UE_cntxt, and the first node where the UE attempts to re-connect is a E-UTRAN node.

– Too Early Inter-system Handover: the connection failure occurs while being connected to a NG-RAN node, and there is a recent inter-system handover for the UE prior to the connection failure i.e., the UE reported timer is smaller than the configured threshold, e.g., Tstore_UE_cntxt, and the first cell where the UE attempts to re-connect and the node that served the UE at the last handover initialisation are both E-UTRAN node.

The "UE reported timer" above indicates the time elapsed since the last handover initialisation until connection failure. The UE may make the RLF Report available to an NG-RAN node. The NG-RAN node may forward the information using the FAILURE INDICATION message over Xn or by means of the Uplink RAN configuration transfer procedure and Downlink RAN configuration transfer over NG to the node that served the UE before the reported connection failure.

In case the failure is a Too Early Inter-system Handover, the NG-RAN node receiving the failure indication may inform the E-UTRAN node by means of the Uplink RAN Configuration Transfer procedure over NG. This may include the RLF report.

15.5.2.3 Inter-system Unnecessary HO

One of the purposes of inter-system Mobility Robustness Optimisation is the detection of a non-optimal use of network resources. In particular, in case of inter-system operations and when NR is considered, the case known as Unnecessary HO to another system is identified. The problem is defined as follows:

– UE is handed over from NR to E-UTRAN even though quality of the NR coverage was sufficient for the service used by the UE. The handover may therefore be considered as unnecessary HO to another system (i.e. EPS) (too early inter-system HO without connection failure).

In inter-system HO, if the serving cell threshold (NR cell) is set too high, and cell in another system (i.e. EPS) with good signal strength is available, a handover to another system may be triggered unnecessarily, resulting in an inefficient use of the networks. With a lower threshold the UE could have continued in the source system (5GS).

To be able to detect the Unnecessary HO to another system, a gNB node may choose to put additional coverage and quality condition information into the HANDOVER REQUIRED message in the Handover Preparation procedure when an inter-system HO from gNB to another system occurs. The RAN node in the other system, upon receiving this additional coverage and quality information, may instruct the UE to continue measuring the cell(s) in source system during a period of time, while being connected to another system, and send periodic or single measurement reports to the node in other system. When the period of time indicated by the node in source system expires, the RAN node in the other system, may evaluate the received measurement reports with the coverage/quality condition received during the inter-system HO procedure and decide if an inter-system unnecessary HO report should be sent to the gNB in the source system.

The inter-system unnecessary HO report shall only be sent in cases where, in all UE measurement reports collected during the measurement period, any cells in the source system exceed the radio coverage and/or quality threshold (the radio threshold RSRP, RSRQ or/and SINR and the measurement period are indicated in the additional coverage and quality information in the Handover Preparation procedure). If an inter-system handover towards 5GS is executed from EPS within the indicated measurement period, the measurement period expires. In this case, the eNB in EPS may also send the HO Report. No HO Report shall be sent in case no NR cell could be included, or if the indicated period of time is interrupted by an inter-system handover to a system different than 5GS.

The RAN node in the source system (5GS) upon receiving of the report, can decide if/how its parameters (e.g., threshold to trigger Inter-system HO) should be adjusted.

15.5.2.4 Inter-system Ping-pong

One of the functions of Mobility Robustness Optimization is to detect ping-pongs that occur in inter-system environment. The problem is defined as follows:

– A UE is handed over from a cell in a source system (e.g. 5GS) to a cell in a target system different from the source system (e.g. EPS), then within a predefined limited time the UE is handed over back to a cell in the source system, while the coverage of the source system was sufficient for the service used by the UE. The event may occur more than once.

The solution for the problem may consist of the following steps:

1) Statistics regarding inter-system ping-pong occurrences are collected by the responsible node;

2) Coverage verification is performed to check if the mobility to other system was inevitable.

The statistics regarding ping-pong occurrence may be based on evaluation of the UE History Information IE in the HANDOVER REQUIRED message. If the evaluation indicates a potential ping-pong case and the source NG_RAN node of the 1^st inter-system handover is different than the target NG-RAN node of the 2^nd inter-system handover, the target NG-RAN node may use the HANDOVER REPORT message or the UPLINK RAN CONFIGURATION TRANSFER message to indicate the occurrence of potential ping-pong cases to the source NG-RAN node.

If NG-RAN coverage during the potential ping-pong event needs to be verified for the purpose of determining corrective measures, the Unnecessary HO to another system procedure may be used

15.5.2.5 O&M Requirements

All automatic changes of the HO and/or reselection parameters for mobility robustness optimisation shall be within the ranges allowed by OAM and specified below.

The following control parameters shall be provided by OAM to control MRO behaviour:

– Maximum deviation of Handover Trigger: this parameter defines the maximum allowed absolute deviation of the Handover Trigger, from the default point of operation defined by the parameter values assigned by OAM.

– Minimum time between Handover Trigger changes: this parameter defines the minimum allowed time interval between two Handover Trigger change performed by MRO. This is used to control the stability and convergence of the algorithm.

Furthermore, in order to support the solutions for detection of mobility optimisation, the parameter Tstore_UE_cntxt shall be configurable by the OAM system.

15.5.2.6 PSCell change failure

For analysis of PSCell change failures, the UE makes the SCG Failure Information available to the MN. If the MN can perform an initial analysis, it transfers the SCG Failure Information together with the analysis results to the relevant SN which is responsible for the PSCell change failures. Otherwise, the MN transfers the SCG Failure Information to the last serving SN, which may respond using the SCG Failure Transfer procedure to inform the MN it is not responsible for the SCG failure. If needed, the MN transfer the SCG Failure Information to the source SN.

15.5.2.7 Successful HO

One of the functions of Mobility Robustness Optimization is to detect a sub-optimal successful handover event. The aim is to identify underlying conditions during successful ordinary handovers, successful DAPS handovers, or successful Conditional handovers.

For analysis of successful handover, the UE supports Successful Handover Report based on configuration by network, if received, and makes the Successful Handover Report available to the network as specified in TS 38.331 [12].

The UE stores the Successful Handover Report until the Successful Handover Report is fetched by the network or for 48 hours after the Successful Handover Report is recorded.

Upon retrieval of a Successful Handover Report, the receiving node may analyse whether its mobility configuration needs adjustment.

15.5.3 Support for RACH Optimization

RACH optimization is supported by UE reported information made available at the NG RAN node as specified in TS 38.331 [12] and by PRACH parameters exchange between NG RAN nodes.

The contents of the RACH information report comprise of the following:

– Contention detection indication per RACH attempt;

– Indexes of the SSBs and number of RACH preambles sent on each tried SSB listed in chronological order of attempts;

– Indication whether the selected SSB is above or below the configured RSRP threshold per RACH attempt;

– 2-step RACH information as specified in clause 5.7.10.4 of TS 38.331 [12].

The UE operating in NR-DC, may also support SgNB RACH information report.

15.5.4 UE History Information from the UE

The source NG-RAN node collects and stores the UE History Information for as long as the UE stays in one of its cells.

The UE may report the UE history information when connecting to a cell of the NG-RAN node, consisting of PCell and PSCell mobility history information, as specified in TS 38.331 [12].

When information needs to be discarded because the list is full, such information will be discarded in order of its position in the list, starting with the oldest cell record. If the list is full, and the UE history information from the UE is available, the UE history information from the UE should also be discarded.

The resulting information is then used in subsequent handover preparations by means of the Handover Preparation procedures over the NG and XN interfaces, which provide the target NG-RAN node with a list of previously visited cells and associated (per-cell) information elements. The Handover Preparation procedures also trigger the target NG-RAN node to start collection and storage of UE history Information and thus to propagate the collected information.

15.5.5 Support for Coverage and Capacity Optimisation

15.5.5.1 General

The objective of NR Coverage and Capacity Optimization (CCO) function is to detect and resolve or mitigate CCO issues, e.g. coverage and cell edge interference issues.

15.5.5.2 OAM requirements

Each NG-RAN node may be configured with alternative coverage configurations by OAM. The alternative coverage configurations contain relevant radio parameters and may also include a range for how each parameter is allowed to be adjusted.

15.5.5.3 Dynamic coverage configuration changes

An NG-RAN node may autonomously adjust within and switch between coverage configurations. When a change is executed, a NG-RAN node may notify its neighbour NG-RAN nodes using the NG-RAN NODE CONFIGURATION UPDATE message with the list of cells and SSBs with modified coverage included. The list contains the CGI of each modified cell with its coverage state indicator and optionally the SSB index of each modified SSB with its coverage state indicator.

The coverage state indicator may be used at the receiving NG-RAN node to adjust the functions of the Mobility Robustness Optimisation, e.g. by using the coverage state indicator to retrieve a previously stored Mobility Robustness Optimisation state. The coverage state indicator may also be used at the receiving NG-RAN node to adopt coverage configurations matching with neighbouring cells coverage configurations.

If the list includes indication about planned reconfiguration and possibly a list of replacing cells, the receiving NG-RAN node may use this to avoid connection or re-establishment failures during the reconfiguration. Also, if the sending NG-RAN node adds cells in inactive state, the receiving NG-RAN node may use this information to avoid connection or re-establishment failures. The receiving NG-RAN node may also use the notification to reduce the impact on mobility. The receiving NG-RAN node should avoid triggering handovers towards cell(s) that are indicated to be inactive.

15.5.6 Support for PCI Optimisation

The PCI Optimization Function in split gNB case is specified in TS 38.401 [4].

15.5.6.1 Centralized PCI Assignment

For centralized PCI assignment in gNB, the OAM assigns a single PCI for each NR cell in the gNB, and the gNB selects this value as the PCI of the NR cell.

15.5.6.2 Distributed PCI Assignment

For distributed PCI assignment in gNB, the OAM assigns a list of PCIs for each NR cell in the gNB, and the gNB selects a PCI value from the list of PCIs. The gNB may restrict this list by removing some PCIs that are reported by UEs, reported over the Xn interface by neighboring gNBs, and/or acquired through other methods, e.g. detected over the air using a downlink receiver.