8.4 Global procedures

38.4233GPPNG-RANRelease 17TSXn Application Protocol (XnAP)

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

8.4.1 Xn Setup

8.4.1.1 General

The purpose of the Xn Setup procedure is to exchange application level configuration data needed for two NG-RAN nodes to interoperate correctly over the Xn-C interface.

NOTE 1: If Xn-C signalling transport is shared among multiple Xn-C interface instances, one Xn Setup procedure is issued per Xn-C interface instance to be setup, i.e. several Xn Setup procedures may be issued via the same TNL association after that TNL association has become operational.

NOTE 2: Exchange of application level configuration data also applies between two NG-RAN nodes in case the SN (i.e. the gNB) does not broadcast system information other than for radio frame timing and SFN, as specified in the TS 37.340 [8]. How to use this information when this option is used is not explicitly specified.

The procedure uses non UE-associated signalling.

8.4.1.2 Successful Operation

Figure 8.4.1.2: Xn Setup, successful operation

The NG-RAN node₁ initiates the procedure by sending the XN SETUP REQUEST message to the candidate NG-RAN node₂. The candidate NG-RAN node₂ replies with the XN SETUP RESPONSE message.

The AMF Region Information IE in the XN SETUP REQUEST message shall contain a complete list of Global AMF Region IDs to which the NG-RAN node₁ belongs. The AMF Region Information IE in the XN SETUP RESPONSE message shall contain a complete list of Global AMF Region IDs to which the NG-RAN node₂ belongs.

The List of Served Cells NR IE and the List of Served Cells E-UTRA IE, if contained in the XN SETUP REQUEST message, shall contain a complete list of cells served by NG-RAN node₁or, if supported, a partial list of served cells together with the Partial List Indicator IE. The List of Served Cells NR IE and the List of Served Cells E-UTRA IE, if contained in the XN SETUP RESPONSE message, shall contain a complete list of cells served by NG-RAN node₂or, if supported, a partial list of served cells together with the Partial List Indicator IE.

If Supplementary Uplink is configured at the NG-RAN node₁, the NG-RAN node₁ shall include in the XN SETUP REQUEST message the SUL Information IE and the Supported SUL band List IE for each served cell where supplementary uplink is configured.

If Supplementary Uplink is configured at the NG-RAN node₂, the candidate NG-RAN node₂ shall include in the XN SETUP RESPONSE message the SUL Information IE and the Supported SUL band List IE for each served cell where supplementary uplink is configured.

If the NG-RAN node₁ is an ng-eNB, it may include the Protected E-UTRA Resource Indication IE into the XN SETUP REQUEST. If the XN SETUP REQUEST sent by an ng-eNB contains the Protected E-UTRA Resource Indication IE, the receiving gNB should take this into account for cell-level resource coordination with the ng-eNB. The gNB shall consider the received Protected E-UTRA Resource Indication IE content valid until reception of a new update of the IE for the same ng-eNB.

The protected resource pattern indicated in the Protected E-UTRA Resource Indication IE is not valid in subframes indicated by the Reserved Subframes IE, as well as in the non-control region of the MBSFN subframes i.e. it is valid only in the control region therein. The size of the control region of MBSFN subframes is indicated in the Protected E-UTRA Resource Indication IE.

In case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the XN SETUP REQUEST message and the XN SETUP RESPONSE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

If the Intended TDD DL-UL Configuration NR IE is included in the XN SETUP REQUEST or XN SETUP RESPONSE message, the receiving NG-RAN node should take this information into account for cross-link interference management and/or NR-DC power coordination with the sending NG-RAN node. The receiving NG-RAN node shall consider the received Intended TDD DL-UL Configuration NR IE content valid until reception of an update of the IE for the same cell(s).

If the TNL Configuration Info IE is contained in the XN SETUP REQUEST message, the NG-RAN node₂ shall, if supported, take this IE into account for IPSec establishment.

If the TNL Configuration Info IE is contained in the XN SETUP RESPONSE message, the NG-RAN node₁ shall, if supported, take this IE into account for IPSec establishment.

If the Partial List Indicator NR IE or the Partial List Indicator E-UTRA IE is set to "partial" in the XN SETUP REQUEST message the candidate NG-RAN node₂shall, if supported, assume that the List of Served Cells NR IE or the List of Served Cells E-UTRA IE in the XN SETUP REQUEST message includes a partial list of cells.

If the Partial List Indicator NR IE or the Partial List Indicator E-UTRA IE is set to "partial" in the XN SETUP RESPONSE message from the candidate NG-RAN node₂, the NG-RAN node₁ shall, if supported, assume that the List of Served Cells NR IE or the List of Served Cells E-UTRA IE in the XN SETUP RESPONSE message includes a partial list of cells.

If the Cell and Capacity Assistance Information NR IE or the Cell and Capacity Assistance Information E-UTRA IE is present in the XN SETUP REQUEST message the candidate NG-RAN node₂shall, if supported, use it when generating the list of NG-RAN served cell information to include in the XN SETUP RESPONSE message.

If the Cell and Capacity Assistance Information NR IE or the Cell and Capacity Assistance Information E-UTRA IE is present in the XN SETUP RESPONSE message from the candidate NG-RAN node₂, the NG-RAN node₁shall, if supported, store the collected information to be used for future NG-RAN node interface management.

If the CSI-RS Transmission Indication IE is contained in the XN SETUP REQUEST message, the NG-RAN node₂ shall, if supported, take this IE into account for neighbour cell’s CSI-RS measurement.

If the CSI-RS Transmission Indication IE is contained in the XN SETUP RESPONSE message, the NG-RAN node₁ shall, if supported, take this IE into account for neighbour cell’s CSI-RS measurement.

The initiating NG-RAN node₁ may include the PRACH Configuration IE (for served E-UTRA cells) or the NR Cell PRACH Configuration IE (for served NR cells) or the NPRACH Configuration IE (for served NB-IoT cells) in the XN SETUP REQUEST message. The candidate NG-RAN node₂ may also include the PRACH Configuration IE (for served E-UTRA cells) or NR Cell PRACH Configuration IE (for served NR cells) or the NPRACH Configuration IE (for served NB-IoT cells) in the XN SETUP RESPONSE message. The NG-RAN node receiving the IE may use this information for RACH optimisation.

The XN SETUP REQUEST message may contain for each cell served by NG-RAN node₁ NPN related broadcast information. The XN SETUP RESPONSE message may contain for each cell served by NG-RAN node₂ NPN related broadcast information.

If the SFN Offset IE is included in the XN SETUP REQUEST or XN SETUP RESPONSE message, the receiving NG-RAN node shall, if supported, use this information to deduce the SFN0 time offset of the reported cell.The receiving NG-RAN node shall consider the received SFN Offset IE content valid until reception of an update of the IE for the same cell(s).

The NG-RAN node receiving the Supported MBS FSA ID List IE in the XN SETUP REQUEST message or the in XN SETUP RESPONSE message may use it according to TS 38.300 [9].

If the Additional Measurement Timing Configuration List IE is contained in the XN SETUP REQUEST message, the NG-RAN node₂ shall, if supported, take this IE into account for neighbour cell’s CSI-RS measurement.

If the Additional Measurement Timing Configuration List IE is contained in the XN SETUP RESPONSE message, the NG-RAN node₁ shall, if supported, take this IE into account for neighbour cell’s CSI-RS measurement.

If the Local NG-RAN Node Identifier IE is present in the XN SETUP REQUEST message, the NG-RAN node₂shall, if supported, take this into account for future retrieval of the UE contexts from the NG-RAN node₁.

If the Local NG-RAN Node Identifier IE is present in the XN SETUP RESPONSE message, the NG-RAN node₁shall, if supported, take this into account for future retrieval of the UE contexts from the NG-RAN node₂.

If the Neighbour NG-RAN Node List IE is present in the XN SETUP REQUEST message, the NG-RAN node₂may take this into account for Local NG-RAN Node Identifier conflict detection.

If the Neighbour NG-RAN Node List IE is present in the XN SETUP RESPONSE message, the NG-RAN node₁may take this into account for Local NG-RAN Node Identifierconflict detection.

If the Served Cell Specific Info Request IE is included in the XN SETUP REQUEST message and if the NG-RAN node₂ is a gNB, the NG-RAN node₂ shall, if supported, include the Additional Measurement Timing Configuration List IE for the requested NR cells in the XN SETUP RESPONSE message.

If the RedCap Broadcast Information IE is included in the Served Cell Information NR IE in the XN SETUP REQUEST message or the XN SETUP RESPONSE message, the receiving NG-RAN node may use this information to determine a suitable target in case of subsequent outgoing mobility involving RedCap UEs.

If the TAI NSAG Support List IE is contained in the XN SETUP REQUEST or in the XN SETUP RESPONSE message, the receiving NG-RAN node shall, if supported, take this IE into account for slice aware cell reselection.

Interactions with other procedures:

If the NG-RAN node₁ receives a XN SETUP RESPONSE message containing a Local NG-RAN Node Identifier identical to the Local NG-RAN Node Identifier included in the corresponding XN SETUP REQUEST message, the NG-RAN node₁ may initiate the NG-RAN node Configuration Update procedure including in the NG-RAN NODE CONFIGURATION UPDATE message a new Local NG-RAN Node Identifier, different from the Local NG-RAN Node Identifier of each of its neighbour NG-RAN Nodes.

If the NG-RAN node₁ receives a XN SETUP RESPONSE message containing a Local NG-RAN Node Identifier within the Neighbour NG-RAN Node List IE identical to the Local NG-RAN Node Identifier included in the corresponding XN SETUP REQUEST message, the NG-RAN node₁ may initiate the NG-RAN node Configuration Update procedure including in the NG-RAN NODE CONFIGURATION UPDATE message a new Local NG-RAN Node Identifier, different from the Local NG-RAN Node Identifier of each of its neighbour NG-RAN Nodes.

8.4.1.3 Unsuccessful Operation

Figure 8.4.1.3-1: Xn Setup, unsuccessful operation

If the candidate NG-RAN node₂ cannot accept the setup it shall respond with the XN SETUP FAILURE message with appropriate cause value.

If the XN SETUP FAILURE message includes the Time To Wait IE, the initiating NG-RAN node₁ shall wait at least for the indicated time before reinitiating the Xn Setup procedure towards the same NG-RAN node₂.

If case of network sharing with multiple Cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the XN SETUP REQUEST message and the XN SETUP REQUEST FAILURE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

If the Message Oversize Notification IE is included in the XN SETUP FAILURE, the initiating node shall, if supported, deduce that the failure is due to a too large XN SETUP REQUEST message and ensure that the total number of served cells in following XN SETUP REQUEST message is equal to or lower than the value of the Maximum Cell List Size IE.

8.4.1.4 Abnormal Conditions

If the first message received for a specific TNL association is not an XN SETUP REQUEST, XN SETUP RESPONSE, or XN SETUP FAILURE message then this shall be treated as a logical error.

If the initiating NG-RAN node₁ does not receive either XN SETUP RESPONSE message or XN SETUP FAILURE message, the NG-RAN node₁ may reinitiate the Xn Setup procedure towards the same NG-RAN node, provided that the content of the new XN SETUP REQUEST message is identical to the content of the previously unacknowledged XN SETUP REQUEST message.

If the initiating NG-RAN node₁ receives an XN SETUP REQUEST message from the peer entity on the same Xn interface:

– In case the NG-RAN node₁ answers with an XN SETUP RESPONSE message and receives a subsequent Xn SETUP FAILURE message, the NG-RAN node₁ shall consider the Xn interface as non operational and the procedure as unsuccessfully terminated according to sub clause 8.4.1.3.

– In case the NG-RAN node₁ answers with an XN SETUP FAILURE message and receives a subsequent XN SETUP RESPONSE message, the NG-RAN node₁ shall ignore the XN SETUP RESPONSE message and consider the Xn interface as non operational.

8.4.2 NG-RAN node Configuration Update

8.4.2.1 General

The purpose of the NG-RAN node Configuration Update procedure is to update application level configuration data needed for two NG-RAN nodes to interoperate correctly over the Xn-C interface.

NOTE: Update of application level configuration data also applies between two NG-RAN nodes in case the SN (i.e. the gNB) does not broadcast system information other than for radio frame timing and SFN, as specified in the TS 37.340 [8]. How to use this information when this option is used is not explicitly specified.

The procedure uses non UE-associated signalling.

8.4.2.2 Successful Operation

Figure 8.4.2.2-1: NG-RAN node Configuration Update, successful operation

The NG-RAN node₁ initiates the procedure by sending the NG-RAN NODE CONFIGURATION UPDATE message to a peer NG-RAN node₂.

If Supplementary Uplink is configured at the NG-RAN node₁, the NG-RAN node₁ shall include in the NG-RAN NODE CONFIGURATION UPDATE message the SUL Information IE and the Supported SUL band List IE for each cell added in the Served NR Cells To Add IE and in the Served NR Cells To Modify IE.

If Supplementary Uplink is configured at the NG-RAN node₂, the NG-RAN node₂ shall include in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message the SUL Information IE and the Supported SUL band List IE for each cell added in the Served NR Cells IE if any.

If the TAI Support List IE is included in the NG-RAN NODE CONFIGURATION UPDATE message, the receiving node shall replace the previously provided TAI Support List IE by the received TAI Support List IE.

If the Cell Assistance Information NR IE is present, the NG-RAN node₂ shall, if supported, use it to generate the Served NR Cells IE and include the list in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message.

If the Cell Assistance Information E-UTRA IE is present, the NG-RAN node₂ shall, if supported, use it to generate the Served E-UTRA Cells IE and include the list in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message.

If the Partial List Indicator NR IE is included in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message and set to "partial" the NG-RAN node₁ shall, if supported, assume that the Served NR Cells IE in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message includes a partial list of NR cells.

If the Partial List Indicator E-UTRA IE is included in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message and set to "partial" the NG-RAN node₁ shall, if supported, assume that the Served E-UTRA Cells IE in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message includes a partial list of NR cells.

If the Cell and Capacity Assistance Information NR IE is present in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message from the candidate NG-RAN node₂, the NG-RAN node₁shall, if supported, store the collected information to be used for future NG-RAN node interface management.

If the Cell and Capacity Assistance Information E-UTRA IE is present in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message from the candidate NG-RAN node₂, the NG-RAN node₁shall, if supported, store the collected information to be used for future NG-RAN node interface management.

Upon reception of the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall update the information for NG-RAN node₁ as follows:

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the NG-RAN NODE CONFIGURATION UPDATE message and the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

If the TNL Configuration Info IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall take this IE into account for IPSec establishment.

If the TNL Configuration Info IE is contained in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, the NG-RAN node₁ shall take this IE into account for IPSec establishment.

If the CSI-RS Transmission Indication IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall take this IE into account for neighbour cell’s CSI-RS measurement.

The NG-RAN NODE CONFIGURATION UPDATE message may contain for each cell served by NG-RAN node₁ NPN related broadcast information. The NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message may contain for each cell served by NG-RAN node₂ NPN related broadcast information.

If the Additional Measurement Timing Configuration List IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall take this IE into account for neighbour cell’s CSI-RS measurement.

If the Local NG-RAN Node Identifier IE is present in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂shall, if supported, take this into account for future retrieval of the UE contexts from the NG-RAN node₁.

If the Local NG-RAN Node Identifier IE is present in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, the NG-RAN node₁shall, if supported, take this into account for future retrieval of the UE contexts from the NG-RAN node₂.

If the Neighbour NG-RAN Node List IE is present in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂may take this into account for Local NG-RAN Node Identifierconflict detection.

If the Neighbour NG-RAN Node List IE is present in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, the NG-RAN node₁may take this into account for Local NG-RAN Node Identifierconflict detection.

If the Local NG-RAN Node Identifier Removal IE is present in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂shall, if supported, discard it from its context and not use it for future retrieval of the UE contexts from the NG-RAN node₁.

If the Local NG-RAN Node Identifier Removal IE is present in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, the NG-RAN node₁shall, if supported, discard it from its context and not use it for future retrieval of the UE contexts from the NG-RAN node₂.

If the Served Cell Specific Info Request IE is included in the NG-RAN NODE CONFIGURATION UPDATE message and if the NG-RAN node₂ is a gNB, the NG-RAN node₂ shall, if supported, include the Additional Measurement Timing Configuration List IE for the requested NR cells in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message.

If the TAI NSAG Support List IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node shall, if supported, take this IE into account for slice aware cell reselection.

Update of Served Cell Information NR:

– If Served Cells NR To Add IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall add cell information according to the information in the Served Cell Information NR IE.

– If Served Cells NR To Modify IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall modify information of cell indicated by Old NR-CGI IE according to the information in the Served Cell Information NR IE.

– When either served cell information or neighbour information of an existing served cell in NG-RAN node₁ need to be updated, the whole list of neighbouring cells, if any, shall be contained in the Neighbour Information NR IE. The NG-RAN node₂shall overwrite the served cell information and the whole list of neighbour cell information for the affected served cell.

– If the Deactivation Indication IE is contained in the Served Cells NR To Modify IE, it indicates that the concerned cell was switched off to lower energy consumption.

– If Served Cells NR To Delete IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall delete information of cell indicated by Old NR-CGI IE.

– If the Intended TDD DL-UL Configuration NR IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ should take this information into account for cross-link interference management and/or NR-DC power coordination with the NG-RAN node₁. The NG-RAN node₂ shall consider the received Intended TDD DL-UL Configuration NR IE content valid until reception of a new update of the IE for the same NG-RAN node₂.

– If the NR Cell PRACH Configuration IE is contained in the Served Cell Information NR IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE may use this information for RACH optimisation.

– If the SFN Offset IE is contained in the Served Cell Information NR IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE shall, if supported, use this information to update the SFN0 time offset of the reported cell.

– If the Supported MBS FSA ID List IE is contained in the Served Cell Information NR IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE may use it according to TS 38.300 [9].

– If the RedCap Broadcast Information IE is contained in the Served Cell Information NR IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ may use this information to determine a suitable target in case of subsequent outgoing mobility involving RedCap UEs.

Update of Served Cell Information E-UTRA:

– If Served Cells E-UTRA To Add IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall add cell information according to the information in the Served Cell Information E-UTRA IE.

– If Served Cells E-UTRA To Modify IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall modify information of cell indicated by Old ECGI IE according to the information in the Served Cell Information E-UTRA IE.

– When either served cell information or neighbour information of an existing served cell in NG-RAN node₁ need to be updated, the whole list of neighbouring cells, if any, shall be contained in the Neighbour Information E-UTRA IE. The NG-RAN node₂ shall overwrite the served cell information and the whole list of neighbour cell information for the affected served cell.

– If the Deactivation Indication IE is contained in the Served Cells E-UTRA To Modify IE, it indicates that the concerned cell was switched off to lower energy consumption.

– If the Served Cells E-UTRA To Delete IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, NG-RAN node₂ shall delete information of cell indicated by Old ECGI IE.

– If the Protected E-UTRA Resource Indication IE is included into the NG-RAN NODE CONFIGURATION UPDATE (inside the Served Cell Information E-UTRA IE), the receiving gNB should take this into account for cell-level resource coordination with the ng-eNB. The gNB shall consider the received Protected E-UTRA Resource Indication IE content valid until reception of a new update of the IE for the same ng-eNB. The protected resource pattern indicated in the Protected E-UTRA Resource Indication IE is not valid in subframes indicated by the Reserved Subframes IE (contained in E-UTRA – NR CELL RESOURCE COORDINATION REQUEST messages), as well as in the non-control region of the MBSFN subframes i.e. it is valid only in the control region therein. The size of the control region of MBSFN subframes is indicated in the Protected E-UTRA Resource Indication IE.

– If the PRACH Configuration IE is contained in the Served Cell Information E-UTRA IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE may use this information for RACH optimisation.

– If the NPRACH Configuration IE is contained in the Served Cell Information E-UTRA IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE may use this information for RACH optimisation.

– If the SFN Offset IE is contained in Served Cell Information E-UTRA IE in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node receiving the IE shall, if supported, use this information to update the SFN0 time offset of the reported cell.

Update of TNL addresses for SCTP associations:

If the TNL Association to Add List IE is included in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall, if supported, use it to establish the TNL association(s) with the NG-RAN node₁. The NG-RAN node₂ shall report to the NG-RAN node₁, in the NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message, the successful establishment of the TNL association(s) with the NG-RAN node₁ as follows:

– A list of successfully established TNL associations shall be included in the TNL Association Setup List IE;

– A list of TNL associations that failed to be established shall be included in the TNL Association Failed to Setup List IE.

If the TNL Association to Remove List IE is included in the NG-RAN NODE CONFIGURATION UPDATE message the NG-RAN node₂ shall, if supported, initiate removal of the TNL association(s) indicated by the received Transport Layer information towards the NG-RAN node₁.

If the TNL Association to Update List IE is included in the NG-RAN NODE CONFIGURATION UPDATE message the NG-RAN node₂ shall, if supported, update the TNL association(s) indicated by the received Transport Layer information towards the NG-RAN node₁.

Update of AMF Region Information:

– If AMF Region Information To Add IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall add the AMF Regions to its AMF Region List.

– If AMF Region Information To Delete IE is contained in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ shall remove the AMF Regions from its AMF Region List.

Update of Cell Coverage:

If the Coverage Modification List IE is present in the NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₂ may use the information in the Cell Coverage State IE to identify the cell deployment configuration enabled by the NG-RAN node₁ and for configuring the mobility towards the cell(s) indicated by the Global NG-RAN Cell Identity IE, as described in TS 38.300 [9].

– If the Cell Deployment Status Indicator IE is present in the Coverage Modification List IE, the NG-RAN node₂ shall consider the cell deployment configuration of the cell to be modified as the next planned configuration and shall remove any planned configuration stored for this cell.

– If the Cell Deployment Status Indicator IE is present and the Cell Replacing Info IE contains non-empty cell list, the NG-RAN node₂ may use this list to avoid connection or re-establishment failures during the reconfiguration, e.g. consider the cells in the list as possible alternative handover targets.

– If the Cell Deployment Status Indicator IE is not present, the NG-RAN node₂ shall consider the cell deployment configuration of cell to be modified as activated and replace any previous configuration for the cells indicated in the Coverage Modification List IE.

If the SSB Coverage Modification List IE is present in the Coverage Modification List IE, the NG-RAN node₂ may use the information in the SSB Coverage State IE to identify the SSB beam deployment configuration enabled by the NG-RAN node₁ and for configuring the mobility towards the beam(s) indicated by the SSB Index IE, as described in TS 38.300 [9].

Interactions with other procedures:

If the NG-RAN node₁ receives a NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message containing a Local NG-RAN Node Identifier identical to the Local NG-RAN Node Identifier included in the corresponding NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₁ may initiate the NG-RAN node Configuration Update procedure including in the NG-RAN NODE CONFIGURATION UPDATE message a new Local NG-RAN Node Identifier, different from the Local NG-RAN Node Identifier of each of its neighbour NG-RAN Nodes.

If the NG-RAN node₁ receives a NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message containing a Local NG-RAN Node Identifier within the Neighbour NG-RAN Node List IE identical to the Local NG-RAN Node Identifier included in the corresponding NG-RAN NODE CONFIGURATION UPDATE message, the NG-RAN node₁ may initiate the NG-RAN node Configuration Update procedure including in the NG-RAN NODE CONFIGURATION UPDATE message a new Local NG-RAN Node Identifier, different from the Local NG-RAN Node Identifier of each of its neighbour NG-RAN Nodes.

8.4.2.3 Unsuccessful Operation

Figure 8.4.2.3-1: NG-RAN node Configuration Update, unsuccessful operation

If the NG-RAN node₂ cannot accept the update it shall respond with the NG-RAN NODE CONFIGURATION UPDATE FAILURE message and appropriate cause value.

If the NG-RAN NODE CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE, the NG-RAN node₁ shall wait at least for the indicated time before reinitiating the NG-RAN Node Configuration Update procedure towards the same NG-RAN node₂. Both nodes shall continue to operate the Xn with their existing configuration data.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the NG-RAN NODE CONFIGURATION UPDATE message and the NG-RAN NODE CONFIGURATION UPDATE FAILURE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.4.2.4 Abnormal Conditions

If the NG-RAN node₁ after initiating NG-RAN node Configuration Update procedure receives neither NG-RAN NODE CONFIGURATION UPDATE ACKNOWLEDGE message nor NG-RAN NODE CONFIGURATION UPDATE FAILURE message, the NG-RAN node₁ may reinitiate the NG-RAN node Configuration Update procedure towards the same NG-RAN node₂, provided that the content of the new NG-RAN NODE CONFIGURATION UPDATE message is identical to the content of the previously unacknowledged NG-RAN NODE CONFIGURATION UPDATE message.

8.4.3 Cell Activation

8.4.3.1 General

The purpose of the Cell Activation procedure is to enable an NG-RAN node to request a neighbouring NG-RAN node to switch on one or more cells, previously reported as inactive due to energy saving.

The procedure uses non UE-associated signalling.

8.4.3.2 Successful Operation

Figure 8.4.3.2-1: Cell Activation, successful operation

The NG-RAN node₁ initiates the procedure by sending the CELL ACTIVATION REQUEST message to the peer NG-RAN node₂.

Upon receipt of this message, the NG-RAN node₂ should activate the cell/s indicated in the CELL ACTIVATION REQUEST message and shall indicate in the CELL ACTIVATION RESPONSE message for which cells the request was fulfilled.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the CELL ACTIVATION REQUEST message and the CELL ACTIVATION RESPONSE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

Interactions with NG-RAN Configuration Update procedure:

The NG-RAN node₂ shall not send the NG-RAN CONFIGURATION UPDATE message to the NG-RAN node₁ just for the reason of the cell/s indicated in the CELL ACTIVATION REQUEST message changing cell activation state, as the receipt of the CELL ACTIVATION RESPONSE message by the NG-RAN node₁ is used to update the information about the activation state of NG-RAN node₂ cells in the NG-RAN node₁.

8.4.3.3 Unsuccessful Operation

Figure 8.4.3.3-1: Cell Activation, unsuccessful operation

If the NG-RAN node₂ cannot activate any of the cells indicated in the CELL ACTIVATION REQUEST message, it shall respond with the CELL ACTIVATION FAILURE message with an appropriate cause value.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the CELL ACTIVATION REQUEST message and the CELL ACTIVATION FAILURE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.4.3.4 Abnormal Conditions

Void.

8.4.4 Reset

8.4.4.1 General

The purpose of the Reset procedure is to align the resources in the NG-RAN node₁ and the NG-RAN node₂ in the event of an abnormal failure. The procedure either resets the Xn interface or selected UE contexts. This procedure doesn’t affect the application level configuration data exchanged during, e.g., the Xn Setup procedure.

The procedure uses non UE-associated signalling.

8.4.4.2 Successful Operation

Figure 8.4.4.2-1: Reset, successful operation

The procedure is initiated with the RESET REQUEST message sent from the NG-RAN node₁ to the NG-RAN node₂. Upon receipt of this message,

– if the RESET REQUEST message indicates full reset the NG-RAN node₂shall abort any other ongoing procedures over Xn between the NG-RAN node₁and the NG-RAN node_2.The NG-RAN node₂shall delete all the context information related to the NG-RAN node₁, except the application level configuration data exchanged during the Xn Setup or the NG-RAN node Configuration Update procedures and release the corresponding resources. After completion of release of the resources, the NG-RAN node₂ shall respond with the RESET RESPONSE message.

– if the RESET REQUEST message indicates partial reset, the NG-RAN node₂shall abort any other ongoing procedures only for the indicated UE associated signalling connections identified either by the NG-RAN node1 UE XnAP ID IE or the NG-RAN node1 UE XnAP ID IE or both, for which the NG-RAN node₂shall delete all the context information related to the NG-RAN node₁ and release the corresponding resources. After completion of release of the resources, the NG-RAN node₂ shall respond with the RESET RESPONSE message indicating the UE contexts admitted to be released. The NG-RAN node₂ receiving the request for partial reset does not need to wait for the release or reconfiguration of radio resources to be completed before returning the RESET RESPONSE message. The NG-RAN node₂ receiving the request for partial reset shall include in the RESET RESPONSE message, for each UE association to be released, the same list of UE-associated logical Xn-connections over Xn. The list shall be in the same order as received in the RESET REQUEST message and shall include also unknown UE-associated logical Xn-connections.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the RESET REQUEST message and the RESET RESPONSE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

Interactions with other procedures:

If the RESET REQUEST message indicates full reset, the NG-RAN node₂ shall abort any other ongoing procedure (except for a Reset procedures).

If the RESET REQUEST message indicates partial reset, the NG-RAN node₂ shall abort any other ongoing procedure (except for a Reset procedures) on the same Xn interface related to a UE associated signalling connection indicated in the RESET REQUEST message.

8.4.4.3 Unsuccessful Operation

Void.

8.4.4.4 Abnormal Conditions

If the RESET REQUEST message is received, any other ongoing procedure (except another Reset procedure) on the same Xn interface shall be aborted.

If the Reset procedure is ongoing and the responding node receives the RESET REQUEST message from the peer entity on the same Xn interface, it shall respond with the RESET RESPONSE message as specified in 8.4.4.2.

If the initiating node does not receive the RESET RESPONSE message, the initiating node may reinitiate the Reset procedure towards the same NG-RAN node, provided that the content of the new RESET REQUEST message is identical to the content of the previously unacknowledged RESET REQUEST message.

8.4.5 Error Indication

8.4.5.1 General

The Error Indication procedure is initiated by an NG-RAN node to report detected errors in one incoming message, provided they cannot be reported by an appropriate failure message.

If the error situation arises due to reception of a message utilising UE associated signalling, then the Error Indication procedure uses UE-associated signalling. Otherwise the procedure uses non UE-associated signalling.

8.4.5.2 Successful Operation

Figure 8.4.5.2-1: Error Indication, successful operation.

When the conditions defined in clause 10 are fulfilled, the Error Indication procedure is initiated by the ERROR INDICATION message sent from the node detecting the error situation.

The ERROR INDICATION message shall contain at least either the Cause IE or the Criticality Diagnostics IE.

In case the Error Indication procedure is triggered by UE associated signalling, in the course of handover signalling and signalling for dual connectivity, the Old NG-RAN node UE XnAP ID IE and the New NG-RAN node UE XnAP ID IE shall be included in the ERROR INDICATION message. If any of the Old NG-RAN node UE XnAP ID IE and the New NG-RAN node UE XnAP ID IE is not correct, the cause shall be set to an appropriate value.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the ERROR INDICATION message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.4.5.3 Unsuccessful Operation

Not applicable.

8.4.5.4 Abnormal Conditions

Void.

8.4.6 Xn Removal

8.4.6.1 General

The purpose of the Xn Removal procedure is to remove the interface instance between two NG-RAN nodes in a controlled manner. If successful, this procedure erases any existing application level configuration data in the two nodes.

NOTE: In case the signalling transport is shared among several Xn-C interface instances, and the TNL association is still used by one or more Xn-C interface instances, the initiating NG-RAN node should not initiate the removal of the TNL association.

The procedure uses non UE-associated signaling.

8.4.6.2 Successful Operation

Figure 8.4.6.2-1: Xn Removal, successful operation

An NG-RAN node₁ initiates the procedure by sending the XN REMOVAL REQUEST message to a candidate NG-RAN node₂. Upon reception of the XN REMOVAL REQUEST message the candidate NG-RAN node₂ shall reply with the XN REMOVAL RESPONSE message. After receiving the XN REMOVAL RESPONSE message, the initiating NG-RAN node₁ shall initiate removal of the TNL association towards NG-RAN node₂ and may remove all resources associated with that interface instance. The candidate NG-RAN node₂ may then remove all resources associated with that interface instance.

If the Xn Removal Threshold IE is included in the XN REMOVAL REQUEST message, the candidate NG-RAN node₂ shall, if supported, accept to remove the interface instance with NG-RAN node₁ if the Xn Benefit Value of the interface instance determined at the candidate NG-RAN node₂ is lower than the value of the Xn Removal Threshold IE.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the XN REMOVAL REQUEST message and the XN REMOVAL RESPONSE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.4.6.3 Unsuccessful Operation

Figure 8.4.6.3-1: Xn Removal, unsuccessful operation

If the candidate NG-RAN node₂ cannot accept to remove the interface instance with NG-RAN node₁ it shall respond with an XN REMOVAL FAILURE message with an appropriate cause value.

If case of network sharing with multiple cell ID broadcast with shared Xn-C signalling transport, as specified in TS 38.300 [9], the XN REMOVAL REQUEST message and the XN REMOVAL FAILURE message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.4.6.4 Abnormal Conditions

Void.

8.4.7 Failure Indication

8.4.7.1 General

The purpose of the Failure Indication procedure is to transfer information regarding RRC re-establishment attempts, or received RLF Reports, between NG-RAN nodes. The signalling takes place from the NG-RAN node at which a re-establishment attempt is made, or an RLF Report is received, to an NG-RAN node to which the UE concerned may have previously been attached prior to the connection failure. This may aid the detection of radio link failure, handover failure cases.

The procedure uses non UE-associated signalling.

8.4.7.2 Successful Operation

Figure 8.4.7.2-1: Failure Indication, successful operation

NG-RAN node₂ initiates the procedure by sending the FAILURE INDICATION message to NG-RAN node₁, following a re-establishment attempt or an RLF Report reception from a UE at NG-RAN node₂, when NG-RAN node₂ considers that the UE may have previously suffered a connection failure at a cell controlled by NG-RAN node₁.

If the UE RLF Report Container IE is included in the FAILURE INDICATION message, NG-RAN node₁shall use it to derive failure case information.

8.4.7.3 Unsuccessful Operation

Not applicable.

8.4.7.4 Abnormal Conditions

Void.

8.4.8 Handover Report

8.4.8.1 General

The purpose of the Handover Report procedure is to transfer mobility related information between NG-RAN nodes.

The procedure uses non UE-associated signalling.

8.4.8.2 Successful Operation

Figure 8.4.8.2-1: Handover Report, successful operation

NG-RAN node₁ initiates the procedure by sending the HANDOVER REPORT message to NG-RAN node₂. When receiving the message NG-RAN node₂ shall assume that a mobility-related problem was detected.

If the Handover Report Type IE is set to "HO too early" or "HO to wrong cell", then NG-RAN node₁ indicates to NG-RAN node₂ that, following a successful handover from a cell of NG-RAN node₂ to a cell of NG-RAN node₁, a radio link failure occurred and the UE attempted RRC Re-establishment or re-connected either at the original cell of NG-RAN node₂ (Handover Too Early), or at another cell (Handover to Wrong Cell). The detection of Handover Too Early and Handover to Wrong Cell events is made according to TS 38.300 [9].

The HANDOVER REPORT message may include:

– the Mobility Information IE, if the Mobility Information IE was sent for this handover from NG-RAN node₂ (in case the NG-RAN node₂ provided it more than once, the most recent Mobility Information IE is included in the HANDOVER REPORT message);

– the Source cell C-RNTI IE.

– the CHO Configuration IE, if the CHO Configuration IE was sent for this handover from NG-RAN node₂.

If received, NG-RAN node₂ uses the above information according to TS 38.300 [9].

If the Handover Report Type IE is set to "Inter-system ping-pong", then NG-RAN node₂ shall deduce that a completed handover from a cell of NG-RAN node₂ to a cell in another system might have resulted in an inter-system ping-pong and the UE was successfully handed over to a cell of NG-RAN node₁ (indicated with Target cell CGI IE).

Interaction with the Failure Indication procedure:

If NG-RAN node₁ receives a UE RLF Report from an NG-RAN node via the FAILURE INDICATION message, as described in TS 38.300 [9], NG-RAN node₁ may also include it in the UE RLF Report Container IE included in the HANDOVER REPORT message.

8.4.8.3 Unsuccessful Operation

Not applicable.

8.4.8.4 Abnormal Conditions

Void.

8.4.9 Mobility Settings Change

8.4.9.1 General

This procedure enables an NG-RAN node to negotiate the handover trigger settings with a peer NG-RAN node controlling neighbouring cells.

The procedure uses non UE-associated signalling.

8.4.9.2 Successful Operation

Figure 8.4.9.2-1: Mobility Settings Change, successful operation

NG-RAN node₁ initiates the procedure by sending the MOBILITY CHANGE REQUEST message to NG-RAN node₂.

Upon receipt, NG-RAN node₂ shall evaluate if the proposed NG-RAN node₂ handover trigger modification may be accepted. If NG-RAN node₂is able to successfully complete the request it shall reply with MOBILITY CHANGE ACKNOWLEDGE message.

If the NG-RAN node1 SSB Offsets IE is included in the MOBILITY CHANGE REQUEST, the NG-RAN node₂ should take into account the value of SSB Offset IE for UE measurements received for the SSB Area indicated by the SSB Index IE.

If the NG-RAN node2 Proposed SSB Offsets IE is included in the MOBILITY CHANGE REQUEST, the NG-RAN node₂ shall, if supported, evaluate if the proposed value of SSB Offset IE may be accepted for the SSB Area indicated by the SSB Index IE. If NG-RAN node₂is able to successfully complete the request it shall reply with MOBILITY CHANGE ACKNOWLEDGE message.

8.4.9.3 Unsuccessful Operation

Figure 8.4.9.3-1: Mobility Settings Change, unsuccessful operation

If the requested parameter modification is refused by NG-RAN node₂, or if NG-RAN node₂ is not able to complete the procedure, NG-RAN node₂ shall send the MOBILITY CHANGE FAILURE message with the Cause IE set to an appropriate value. NG-RAN node₂ may include the Mobility Parameters Modification Range IE in the MOBILITY CHANGE FAILURE message, for example in cases when the proposed change is out of the permitted range.

NG-RAN node₂ may include the SSB Offset Modification Range IE in the MOBILITY CHANGE FAILURE message, for example in cases when the proposed change is out of the permitted range.

8.4.9.4 Abnormal Conditions

Void.

8.4.10 Resource Status Reporting Initiation

8.4.10.1 General

This procedure is used by an NG-RAN node to request the reporting of load measurements to another NG-RAN node.

The procedure uses non UE-associated signalling.

8.4.10.2 Successful Operation

Figure 8.4.10.2-1: Resource Status Reporting Initiation, successful operation

NG-RAN node₁ initiates the procedure by sending the RESOURCE STATUS REQUEST message to NG-RAN node₂ to start a measurement, stop a measurement or add cells to report for a measurement. Upon receipt, NG-RAN node₂:

– shall initiate the requested measurement according to the parameters given in the request in case the Registration Request IE set to "start"; or

– shall stop all cells measurements and terminate the reporting in case the Registration Request IE is set to "stop"; or

– shall add cells indicated in the Cell To Report List IE to the measurements initiated before for the given measurement IDs, in case the Registration Request IE is set to "add". If measurements are already initiated for a cell indicated in the Cell To Report List IE, this information shall be ignored.

If the Registration Request IE is set to "start" in the RESOURCE STATUS REQUEST message and the Report Characteristics IE indicates cell specific measurements, the Cell To Report List IE shall be included.

If Registration Request IE is set to "add" in the RESOURCE STATUS REQUEST message, the Cell To Report List IE shall be included.

If NG-RAN node₂is capable to provide all requested resource status information, it shall initiate the measurement as requested by NG-RAN node₁ and respond with the RESOURCE STATUS RESPONSE message.

Interaction with other procedures

When starting a measurement, the Report Characteristics IE in the RESOURCE STATUS REQUEST indicates the type of objects NG-RAN node₂ shall perform measurements on. For each cell, NG-RAN node₂ shall include in the RESOURCE STATUS UPDATE message:

– the Radio Resource Status IE, if the first bit, "PRB Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1". If NG-RAN node₂ is a gNB and if the cell for which Radio Resource Status IE is requested to be reported supports more than one SSB, the Radio Resource Status IE for such cell shall include the SSB Area Radio Resource Status Item IE for all SSB areas supported by the cell. If the SSB To Report List IE is included for a cell, the Radio Resource Status IE for such cell shall include the requested SSB Area Radio Resource Status List IE; If the cell for which Radio Resource Status IE is requested to be reported supports more than one slice, and if the Slice To Report List IE is included for a cell, the Radio Resource Status IE for such cell shall, if supported, include the requested Slice Radio Resource Status Item IE;

– the TNL Capacity Indicator IE, if the second bit, "TNL Capacity Ind Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1". The received TNL Capacity Indicator IE represents the lowest TNL capacity available for the cell, only taking into account interfaces providing user plane transport.

– the Composite Available Capacity Group IE, if the third bit, "Composite Available Capacity Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1". If the Cell Capacity Class Value IE is included within the Composite Available Capacity Group IE, this IE is used to assign weights to the available capacity indicated in the Capacity Value IE. If NG-RAN node₂ is a gNB and if the cell for which Composite Available Capacity Group IE is requested to be reported supports more than one SSB, the Composite Available Capacity Group IE for such cell shall include the SSB Area Capacity Value List for all SSB areas supported by the cell, providing the SSB area capacity with respect to the Cell Capacity Class Value. If the SSB To Report List IE is included for a cell, the Composite Available Capacity Group IE for such cell shall include the requested SSB Area Capacity Value List IE.

If the cell for which Composite Available Capacity Group IE is requested to be reported supports more than one slice, and if the Slice To Report List IE is included for a cell, the Slice Available Capacity IE for such cell shall include the requested Slice Available Capacity Value Downlink IE and Slice Available Capacity Value Uplink IE, providing the slice capacity with respect to the Cell Capacity Class Value.

– the Number of Active UEs IE, if the fourth bit, "Number of Active UEs" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1";

– the RRC Connections IE, if the fifth bit, "RRC Connections" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1".

– the NR-U Channel List IE, if the sixth bit, "NR-U Channel List" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to "1".

If the Reporting Periodicity IE in the RESOURCE STATUS REQUEST is present, this indicates the periodicity for the reporting of periodic measurements. the NG-RAN node₂ shall report only once, unless otherwise requested within the Reporting Periodicity IE.

8.4.10.3 Unsuccessful Operation

Figure 8.4.10.3-1: Resource Status Reporting Initiation, unsuccessful operation

If any of the requested measurements cannot be initiated, NG-RAN node₂ shall send the RESOURCE STATUS FAILURE message with an appropriate cause value.

8.4.10.4 Abnormal Conditions

For the same Measurement ID, if the initiating NG-RAN node₁ does not receive either the RESOURCE STATUS RESPONSE message or the RESOURCE STATUS FAILURE message, the NG-RAN node₁ may reinitiate the Resource Status Reporting Initiation procedure towards the same NG-RAN node, provided that the content of the new RESOURCE STATUS REQUEST message is identical to the content of the previously unacknowledged RESOURCE STATUS REQUEST message.

If the NG-RAN node₂ receives a RESOURCE STATUS REQUEST message which includes the Registration Request IE set to "add" or "stop" and if the NG-RAN node₂ Measurement ID value received in the RESOURCE STATUS REQUEST message is not used, the NG-RAN node₂ shall initiate RESOURCE STATUS FAILURE message with an appropriate cause value.

If the Report Characteristics IE bitmap is set to "0" (all bits are set to "0") in the RESOURCE STATUS REQUEST message then NG-RAN node₂ shall initiate a RESOURCE STATUS FAILURE message with an appropriate cause value.

If the NG-RAN node₂ receives a RESOURCE STATUS REQUEST message which includes the Registration Request IE set to "start" and the NG-RAN node1Measurement ID IE corresponding to an existing on-going load measurement reporting, then NG-RAN node₂ shall initiate a RESOURCE STATUS FAILURE message with an appropriate cause value.

8.4.11 Resource Status Reporting

8.4.11.1 General

This procedure is initiated by an NG-RAN node to report the result of measurements admitted by the NG-RAN node following a successful Resource Status Reporting Initiation procedure.

The procedure uses non UE-associated signalling.

8.4.11.2 Successful Operation

Figure 8.4.11.2-1: Resource Status Reporting, successful operation

NG-RAN node₂ shall report the results of the admitted measurements in RESOURCE STATUS UPDATE message. The admitted measurements are the measurements that were successfully initiated during the preceding Resource Status Reporting Initiation procedure.

8.4.11.3 Unsuccessful Operation

Not applicable.

8.4.11.4 Abnormal Conditions

Void

8.4.12 Access And Mobility Indication

8.4.12.1 General

The purpose of the Access and Mobility Indication procedure is to transfer Access and Mobility related information between NG-RAN nodes.

8.4.12.2 Successful Operation

Figure 8.2.12.2-1: Access And Mobility Indication, successful operation

NG-RAN node₁ initiates the procedure by sending the ACCESS AND MOBILITY INDICATION message sent toNG-RAN node₂.

If the Successful HO Report IE is included in the ACCESS AND MOBILITY INDICATION message, NG-RAN node₂may use it to optimize handover configurations.

8.4.12.3 Abnormal Conditions

Not applicable.