8.3 Global Procedures

36.4233GPPEvolved Universal Terrestrial Radio Access Network (E-UTRAN)Release 17TSX2 Application Protocol (X2AP)

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

8.3.1 Load Indication

8.3.1.1 General

The purpose of the Load Indication procedure is to transfer load and interference co-ordination information between eNBs controlling intra-frequency neighboring cells, and additionally between eNBs controlling inter-frequency neighboring cells for TDD.

The procedure uses non UE-associated signalling.

8.3.1.2 Successful Operation

Figure 8.3.1.2-1: Load Indication, successful operation

An eNB₁ initiates the procedure by sending LOAD INFORMATION message to a peer eNB₂.

If the UL Interference Overload Indication IE is received in the LOAD INFORMATION message, it indicates the interference level experienced by the indicated cell on all resource blocks, per PRB. If the Extended UL Interference Overload Info IE is received in the LOAD INFORMATION message, the UL Interference Overload Indication IE indicates the interference level experienced by the indicated cell ignoring the UL subframe(s) represented as value "1" in the Associated Subframes IE. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received UL Interference Overload Indication IE value valid until reception of a new LOAD INFORMATION message carrying an update of the same IE.

If the UL High Interference Indication IE is received in the LOAD INFORMATION message, it indicates, per PRB, the occurrence of high interference sensitivity, as seen from the sending eNB. The receiving eNB should try to avoid scheduling cell edge UEs in its cells for the concerned PRBs. The Target Cell ID IE received within the UL High Interference Information IE group in the LOAD INFORMATION message indicates the cell for which the corresponding UL High Interference Indication is meant. The receiving eNB shall consider the value of the UL High Interference Information IE group valid until reception of a new LOAD INFORMATION message carrying an update.

If the Relative Narrowband Tx Power (RNTP) IE is received in the LOAD INFORMATION message, it indicates, per PRB or per subframe per PRB (Enhanced RNTP), whether downlink transmission power is lower than the value indicated by the RNTP Threshold IE. If the Enhanced RNTP IE is included in the Relative Narrowband Tx Power (RNTP) IE, it additionally indicates whether the downlink transmission power is lower than the value specified by the RNTP High Power Threshold IE. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received Relative Narrowband Tx Power (RNTP) IE value valid until reception of a new LOAD INFORMATION message carrying an update. If the Enhanced RNTP IE included in the Relative Narrowband Tx Power (RNTP) IE is present, the receiving eNB shall consider the received Enhanced RNTP IE value valid starting from the subframe indicated by the Start SFN IE and Start Subframe Number IE, if present.

If the ABS Information IE is included in the LOAD INFORMATION message, the ABS Pattern Info IE indicates the subframes designated as almost blank subframes by the sending eNB for the purpose of interference coordination. The receiving eNB may take such information into consideration when scheduling UEs.

The receiving eNB may use the Measurement Subset IE received in the LOAD INFORMATION message, for the configuration of specific measurements towards the UE.

The receiving eNB shall consider the received information as immediately applicable. The receiving eNB shall consider the value of the ABS Information IE valid until reception of a new LOAD INFORMATION message carrying an update.

If an ABS indicated in the ABS pattern info IE coincides with a MBSFN subframe, the receiving eNB shall consider that the subframe is designated as almost blank subframe by the sending eNB.

If the Invoke Indication IE is included in the LOAD INFORMATION message, it indicates which type of information the sending eNB would like the receiving eNB to send back. The receiving eNB may take such request into account.

If the Invoke Indication IE is set to "ABS Information", it indicates the sending eNB would like the receiving eNB to initiate the Load Indication procedure, with the LOAD INFORMATION message containing the ABS Information IE indicating non-zero ABS patterns in the relevant cells. If the Invoke Indication IE is set to "Start NAICS Information", it indicates the sending eNB would like the receiving eNB to initiate the Load Indication procedure with the LOAD INFORMATION message containing the Dynamic DL transmission information IE. The first time the Dynamic DL transmission information IE is signalled after receiving the Invoke Indication IE set to "Start NAICS Information", all the NAICS parameters in the NAICS Information IE shall be included. If the Invoke Indication IE is set to "Stop NAICS Information", it indicates the sending eNB does not need NAICS information and therefore the receiving eNB should stop signalling NAICS parameters for the concerned cell.

If the NAICS Information IE is set to "NAICS Active", the receiving eNB may use it for the configuration of DL interference mitigation assistance information towards the UE. Information included in the NAICS Information IE shall replace corresponding NAICS information existing at the receiver. If the NAICS Information IE is set to "NAICS Inactive", the receiving eNB shall consider the existing NAICS information as invalid.

If the Intended UL-DL Configuration IE is included in the LOAD INFORMATION message, it indicates the UL-DL configuration intended to be used by the indicated cell. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received Intended UL-DL Configuration IE value valid until reception of a new LOAD INFORMATION message carrying an update of the same IE.

If the Extended UL Interference Overload Info IE is received in the LOAD INFORMATION message, the Extended UL Interference Overload Indication IE indicates the interference level experienced by the indicated cell on all resource blocks, per PRB, in the UL subframe(s) which is represented as value "1" in the Associated Subframes IE. The receiving eNB may take such information into account when setting its scheduling policy and shall consider the received Extended UL Interference Overload Info IE value valid until reception of a new LOAD INFORMATION message carrying an update of the same IE.

If the CoMP Information IE is received in the LOAD INFORMATION message, the receiving eNB may take the IE into account for RRM. The receiving eNB shall consider the CoMP Information IE valid starting in the subframe indicated by the Start SFN IE and Start Subframe Number IE, if present. If the Start SFN IE and Start Subframe Number IE are not present, then the receiving eNB shall consider the CoMP Information IE as immediately valid. The receiving eNB shall consider the CoMP Information IE valid until an update of the same IE, received in a new LOAD INFORMATION message, is considered valid.

8.3.1.3 Unsuccessful Operation

Not applicable.

8.3.1.4 Abnormal Conditions

Void.

8.3.2 Error Indication

8.3.2.1 General

The Error Indication procedure is initiated by an eNB 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.3.2.2 Successful Operation

Figure 8.3.2.2-1: Error Indication, successful operation.

Figure 8.3.2.2-2: eNB initiated Error Indication for EN-DC, successful operation.

Figure 8.3.2.2-3: en-gNB initiated Error Indication for EN-DC, successful operation.

When the conditions defined in clause 10 are fulfilled, the Error Indication procedure is initiated by an 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 eNB UE X2AP ID IE and the New eNB UE X2AP ID IE shall be included in the ERROR INDICATION message. In case the Error Indication procedure is triggered by UE associated signalling, in the course of signalling for EN-DC, the Old en-gNB UE X2AP ID IE and the New eNB UE X2AP ID IE shall be included in the ERROR INDICATION message. If any of Old eNB UE X2AP ID IE, Old en-gNB UE X2AP ID IE and New eNB UE X2AP ID IE is not correct, the cause shall be set to appropriate value e.g. "unknown Old eNB UE X2AP ID", "unknown Old en-gNB UE X2AP ID", "unknown New eNB UE X2AP ID" or "unknown pair of UE X2AP ID".

If the UE-associated signalling connection is identified by extended eNB UE X2AP IDs the specification text above is applicable for the UE X2AP ID Extension accordingly.

In case of network sharing with multiple cell ID broadcast with shared X2-C signalling transport, as specified in TS 36.300 [15], if the Error Indication procedure is triggered by non UE-associated signalling, the ERROR INDICATION message shall include the Interface Instance Indication IE to identify the corresponding interface instance.

8.3.2.3 Unsuccessful Operation

Not applicable.

8.3.2.4 Abnormal Conditions

Not applicable.

8.3.3 X2 Setup

8.3.3.1 General

The purpose of the X2 Setup procedure is to exchange application level configuration data needed for two eNBs to interoperate correctly over the X2 interface. This procedure erases any existing application level configuration data in the two nodes and replaces it by the one received. This procedure also resets the X2 interface like a Reset procedure would do.

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

The procedure uses non UE-associated signalling.

8.3.3.2 Successful Operation

Figure 8.3.3.2-1: X2 Setup, successful operation

An eNB₁ initiates the procedure by sending the X2 SETUP REQUEST message to a candidate eNB₂. The candidate eNB₂ replies with the X2 SETUP RESPONSE message. The initiating eNB₁ shall transfer the complete list of its served cells and, if available, a list of supported GU Group Ids to the candidate eNB₂. The candidate eNB₂ shall reply with the complete list of its served cells and shall include, if available, a list of supported GU Group Ids in the reply.

If a cell is switched off for energy savings reasons, it should be activated before initiating or responding to the X2 Setup procedure and shall still be included in the list of served cells.

The initiating eNB₁ may include the Neighbour Information IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the Neighbour Information IE in the X2 SETUP RESPONSE message. The Neighbour Information IE shall only include E-UTRAN cells that are direct neighbours of cells in the reporting eNB. A direct neighbour of one cell of a given eNB may be any cell belonging to an eNB that is a neighbour of that given eNB cell e.g. even if the cell has not been reported by a UE. The initiating eNB₁ may include the TAC IE with the Neighbour Information IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the TAC IE with the Neighbour Information IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it according to TS 36.300 [15].

The initiating eNB₁ may include the NR Neighbour Information IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the NR Neighbour Information IE in the X2 SETUP RESPONSE message. The NR Neighbour Information IE shall only include NR cells capable of performing EN-DC with the corresponding served E-UTRA cell. The eNB receiving the NR Neighbour Information IE may use it according to TS 36.300 [15].

The initiating eNB₁ may include the Number of Antenna Ports IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the Number of Antenna Ports IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it according to TS 36.331 [9].

The initiating eNB₁ may include the PRACH Configuration IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the PRACH Configuration IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use this information for RACH optimisation.

The initiating eNB₁ may include the MBSFN Subframe Info IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the MBSFN Subframe Info IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it according to TS 36.331 [9].

For each CSG cell or hybrid cell served by the initiating eNB₁ the X2 SETUP REQUEST message shall contain the CSG ID IE. For each CSG cell or hybrid cell served by the candidate eNB₂ the X2 SETUP RESPONSE message shall contain the CSG ID IE. The eNB receiving the IE shall take this information into account when further deciding whether X2 handover between the source cell and the target cell may be performed.

The initiating eNB₁ may include the MBMS Service Area Identity List IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the MBMS Service Area Identity List IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it according to TS 36.300 [15].

For each cell served by the initiating eNB₁ the X2 SETUP REQUEST message may contain the MultibandInfoList IE and may also contain the FreqBandIndicatorPriority IE. For each cell served by the candidate eNB₂ the X2 SETUP RESPONSE message may contain the MultibandInfoList IE and may also contain the FreqBandIndicatorPriority IE. The eNB receiving the MultibandInfoList IE shall, if supported, take this information into account when further deciding whether subsequent mobility actions between the source cell and the target cell may be performed, and use this IE and the FreqBandIndicatorPriority IE, if received, as specified in TS 36.331 [9].

The initiating eNB₁ may include the LHN ID IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include LHN ID IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it according to TS 36.300 [15].

The initiating eNB₁ may include the BandwidthReducedSI IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include BandwidthReducedSI IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use it to determine a suitable target in case of subsequent outgoing mobility involving BL UEs or UEs requiring CE.

The initiating eNB₁ may include the NPRACH Configuration IE in the X2 SETUP REQUEST message. The candidate eNB₂ may also include the NPRACH Configuration IE in the X2 SETUP RESPONSE message. The eNB receiving the IE may use this information for RACH optimization.

If the Served Cell Specific Info Request IE is included in the X2 SETUP REQUEST message, the eNB₂ shall, if supported, include the Additional Measurement Timing Configuration List IE for the requested NR neighbour cells, capable of performing EN-DC with the served E-UTRA cell in the X2 SETUP RESPONSE message.

Interaction with the EN-DC Configuration Update procedure:

The receiving eNB may forward the Intended TDD DL-UL Configuration NR IE received in the NR Neighbour Information IE in the X2 SETUP REQUEST message or in the X2 SETUP RESPONSE message to neighbouring en-gNBs by triggering the EN-DC Configuration Update procedure.

Interaction with the eNB Configuration Update procedure:

The receiving eNB may forward the Intended TDD DL-UL Configuration NR IE received in the NR Neighbour Information IE in the X2 SETUP REQUEST message or in the X2 SETUP RESPONSE message to neighbouring eNBs by triggering the eNB Configuration Update procedure.

8.3.3.3 Unsuccessful Operation

Figure 8.3.3.3-1: X2 Setup, unsuccessful operation

If the candidate eNB₂ cannot accept the setup it shall respond with an X2 SETUP FAILURE message with appropriate cause value.

If the X2 SETUP FAILURE message includes the Time To Wait IE the initiating eNB₁ shall wait at least for the indicated time before reinitiating the X2 Setup procedure towards the same eNB₂.

8.3.3.4 Abnormal Conditions

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

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

If the initiating eNB₁ receives an X2 SETUP REQUEST message from the peer entity on the same X2 interface:

– In case the eNB₁ answers with an X2 SETUP RESPONSE message and receives a subsequent X2 SETUP FAILURE message, the eNB₁ shall consider the X2 interface as non operational and the procedure as unsuccessfully terminated according to sub clause 8.3.3.3.

– In case the eNB₁ answers with an X2 SETUP FAILURE message and receives a subsequent X2 SETUP RESPONSE message, the eNB₁ shall ignore the X2 SETUP RESPONSE message and consider the X2 interface as non operational.

8.3.4 Reset

8.3.4.1 General

The purpose of the Reset procedure is to align the resources in eNB₁ and eNB₂, or the resources in eNB and en-gNB involved in the EN-DC in the event of an abnormal failure. The procedure resets the X2 interface. This procedure doesn’t affect the application level configuration data exchanged during, e.g., the X2 Setup procedure, EN-DC X2 Setup procedure.

The procedure uses non UE-associated signalling.

8.3.4.2 Successful Operation

Figure 8.3.4.2-1: Reset, successful operation

The procedure is initiated with a RESET REQUEST message sent from the eNB₁ to the eNB₂. Upon receipt of this message, eNB₂shall abort any other ongoing procedures over X2 between eNB₁and eNB_2.The eNB₂shall delete all the context information related to the eNB₁, except the application level configuration data exchanged during the X2 Setup or eNB Configuration Update procedures, and release the corresponding resources. After completion of release of the resources, the eNB₂ shall respond with a RESET RESPONSE message.

Figure 8.3.4.2-2: Reset, successful operation for EN-DC.

The procedure is initiated with a RESET REQUEST message sent from the eNB₁/en-gNB₁ to en-gNB₂/eNB₂. Upon receipt of this message, eNB₂/en-gNB₂shall abort any other ongoing procedures over X2 between both nodes. eNB₂/en-gNB₂shall delete all the context information related to eNB₁/en-gNB₁, except the application level configuration data exchanged during the EN-DC X2 Setup or EN-DC Configuration Update procedures, and release the corresponding resources. After completion of release of the resources, eNB₂/en-gNB₂ shall respond with a RESET RESPONSE message.

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

8.3.4.3 Unsuccessful Operation

Void.

8.3.4.4 Abnormal Conditions

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

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

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

8.3.5 eNB Configuration Update

8.3.5.1 General

The purpose of the eNB Configuration Update procedure is to update application level configuration data needed for two eNBs to interoperate correctly over the X2 interface.

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

The procedure uses non UE-associated signalling.

8.3.5.2 Successful Operation

Figure 8.3.5.2-1: eNB Configuration Update, successful operation

An eNB₁ initiates the procedure by sending an ENB CONFIGURATION UPDATE message to a peer eNB₂. Such message shall include an appropriate set of up-to-date configuration data, including, but not limited to, the complete lists of added, modified and deleted served cells, that eNB₁ has just taken into operational use.

Upon reception of an ENB CONFIGURATION UPDATE message, eNB₂ shall update the information for eNB₁ as follows:

Update of Served Cell Information:

– If Served Cells To Add IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ shall add cell information according to the information in the Served Cell Information IE.

– If Number of Antenna Ports IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, eNB₂ may use this information according to TS 36.331 [9].

– If the PRACH Configuration IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, the eNB receiving the IE may use this information for RACH optimisation.

– If Served Cells To Modify IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ shall modify information of cell indicated by Old ECGI IE according to the information in the Served Cell Information IE.

– If MBSFN Subframe Info IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, eNB₂ may use this information according to TS 36.331 [9]. If a MBSFN subframe indicated in the MBSFN Subframe Info IE coincides with an ABS, the eNB₂ shall consider that the subframe is designated as ABS by the sending eNB.

– If BandwidthReducedSI IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, eNB₂ may use this information to determine a suitable target in case of subsequent outgoing mobility involving BL UEs or UEs requiring CE.

When either served cell information or neighbour information of an existing served cell in eNB₁ need to be updated, the whole list of neighbouring cells, if any, shall be contained in the Neighbour Information IE.

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

The eNB₂ shall overwrite the served cell information and the whole list of neighbour cell information for the affected served cell.

– If Served Cells To Delete IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ shall delete information of cell indicated by Old ECGI IE.

– If MBMS Service Area Identity List IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, the eNB receiving the IE may use it according to TS 36.300 [15].

When the MBMS Service Area Identities of a cell in eNB₁need to be updated, the whole list of MBMS Service Area Identities of the affected cell shall be contained in the Served Cell Information IE.

– If the NPRACH Configuration IE is contained in the Served Cell Information IE in the ENB CONFIGURATION UPDATE message, the eNB receiving the IE may use this information for RACH optimization.

Update of GU Group Id List:

– If GU Group Id To Add List IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ shall add the GU Group Id to its GU Group Id List.

– If GU Group Id To Delete List IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ shall remove the GU Group Id from its GU Group Id List.

If Neighbour Information IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ may use this information to update its neighbour cell relations, or use it for other functions, like PCI selection. The Neighbour Information IE shall only include E-UTRAN cells that are direct neighbours of cells in the reporting eNB. A direct neighbour of one cell of a given eNB may be any cell belonging to an eNB that is a neighbour of that given eNB cell e.g. even if that cell has not been reported by a UE. The Neighbour Information IE may contain the TAC IE of the included cells. The receiving eNB may use TAC IE, as described in TS 36.300 [15].

If the NR Neighbour Information IE is contained in the ENB CONFIGURATION UPDATE message, eNB₂ may use this information to update its neighbour cell relations or use it for other functions. The NR Neighbour Information IE shall only include NR cells capable of performing EN-DC with the corresponding served E-UTRA cell. The eNB receiving the NR Neighbour Information IE may use it according to TS 36.300 [15].

After successful update of requested information, eNB₂ shall reply with the ENB CONFIGURATION UPDATE ACKNOWLEDGE message to inform the initiating eNB₁ that the requested update of application data was performed successfully. In case the peer eNB₂ receives an ENB CONFIGURATION UPDATE without any IE except for Message Type IE it shall reply with ENB CONFIGURATION UPDATE ACKNOWLEDGE message without performing any updates to the existing configuration.

The eNB₁ may initiate a further eNB Configuration Update procedure only after a previous eNB Configuration Update procedure has been completed.

For each cell served by the initiating eNB₁ the ENB CONFIGURATION UPDATE message may contain the MultibandInfoList IE and may also contain the FreqBandIndicatorPriority IE. The eNB receiving the MultibandInfoList IE shall, if supported, take this information into account when further deciding whether subsequent mobility actions between the source cell and the target cell may be performed, and use this IE and the FreqBandIndicatorPriority IE, if received, as specified in TS 36.331 [9].

If the Coverage Modification List IE is present, eNB₂ may use the information in the Cell Coverage State IE to identify the cell deployment configuration enabled by eNB₁ and for configuring the mobility towards the cell(s) indicated by the ECGI IE, as described in TS 36.300 [15]. If the Cell Deployment Status Indicator IE is present in the Coverage Modification List IE, the eNB₂ 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 eNB₂ 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 eNB₂ 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.

Interaction with the eNB Configuration Update procedure:

If an eNB₂ which has not stored a FreqBandIndicatorPriority IE received from eNB₁, but has signaled a FreqBandIndicatorPriority IE to eNB₁ after the TNL association has become available, receives an ENB CONFIGURATION UPDATE message from eNB₁ containing the FreqBandIndicatorPriority IE, the eNB₂ shall initiate the eNB Configuration Update procedure towards eNB₁ including the FreqBandIndicatorPriority IE.

The receiving eNB may forward the Intended TDD DL-UL Configuration NR IE received in the NR Neighbour Information IE in the ENB CONFIGURATION UPDATE message to neighbouring eNBs by triggering the eNB Configuration Update procedure.

Interaction with the EN-DC Configuration Update procedure:

The receiving eNB may forward the Intended TDD DL-UL Configuration NR IE received in the NR Neighbour Information IE in the ENB CONFIGURATION UPDATE message to neighbouring en-gNBs by triggering the EN-DC Configuration Update procedure.

8.3.5.3 Unsuccessful Operation

Figure 8.3.5.3-1: eNB Configuration Update, unsuccessful operation

If the eNB₂ can not accept the update it shall respond with an ENB CONFIGURATION UPDATE FAILURE message and appropriate cause value.

If the ENB CONFIGURATION UPDATE FAILURE message includes the Time To Wait IE the eNB₁ shall wait at least for the indicated time before reinitiating the eNB Configuration Update procedure towards the same eNB₂. Both nodes shall continue to operate the X2 with their existing configuration data.

8.3.5.4 Abnormal Conditions

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

8.3.6 Resource Status Reporting Initiation

8.3.6.1 General

This procedure is used by an eNB to request the reporting of load measurements to another eNB.

The procedure uses non UE-associated signalling.

8.3.6.2 Successful Operation

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

The procedure is initiated with a RESOURCE STATUS REQUEST message sent from eNB₁ to eNB₂. Upon receipt, eNB₂:

– 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

– if supported, stop cell measurements and terminate the reporting for cells indicated in the Cell To Report IE list, in case the Registration Request IE is set to "partial stop"; or

– if supported, add cells indicated in the Cell To Report IE list to the measurements initiated before for the given measurement IDs, in case the Registration Request IE is set to "add".

If the eNB₂ received a RESOURCE STATUS REQUEST message, which includes the Registration Request IE set to "stop", the Cell To Report IE list shall be ignored.

If the Registration Request IE is set to "start" then the Report Characteristics IE shall be included in RESOURCE STATUS REQUEST message. The eNB₂ shall ignore the Report Characteristics IE, if the Registration Request IE is not set to "start".

The Report Characteristics IE indicates the type of objects eNB₂ shall perform measurements on. For each cell, the eNB₂ 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;

– the S1 TNL Load Indicator IE, if the second bit, "TNL Load Ind Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1;

– the Hardware Load Indicator IE, if the third bit, "HW Load Ind Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1;

– the Composite Available Capacity Group IE, if the fourth bit, "Composite Available Capacity Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1. If 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;

– the ABS Status IE, if the fifth bit, "ABS Status Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1 and eNB₁ had indicated the ABS pattern to eNB_2;

– the RSRP Measurement Report List IE, if the sixth bit, "RSRP Measurement Report Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1;

– the CSI Report IE, if the seventh bit, "CSI Report Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1.

– the Radio Resource Status IE within the NR Neithbour Cell Measurement Result IE, if the eighth bit, "Neighbour Cell CAC Periodic" of the Report Characteristics IE included in the RESOURCE STATUS REQUEST message is set to 1.

NOTE: In order to avoid duplication, the eNB₂ may include only one copy of Measurement Result for NR Cells Possibly Aggregated Item per RESOURCE STATUS UPDATE messages per NR cell, even if this NR cell possibly aggregated to multiple E-UTRA cells served by eNB₂. The eNB₂ should only include Measurement Result for NR Cells Possibly Aggregated Item for NR cells that may be aggregated with at least one cell served by eNB₁.

If the Reporting Periodicity IE is included in the RESOURCE STATUS REQUEST message, eNB₂ shall use its value as the time interval between two subsequent RESOURCE STATUS UPDATE messages that include the Radio Resource Status IE, S1 TNL Load Indicator IE, Hardware Load Indicator IE, Composite Available Capacity Group IE, or ABS Status IE.

If the Reporting Periodicity of RSRP Measurement Report IE is included in the RESOURCE STATUS REQUEST message, eNB₂ shall use its value as the minimum time interval between two subsequent RESOURCE STATUS UPDATE messages that include the RSRP Measurement Report List IE.

If the Reporting Periodicity of CSI Report IE is included in the RESOURCE STATUS REQUEST message, eNB₂ shall use its value as the minimum time interval between two subsequent RESOURCE STATUS UPDATE messages that include the CSI Report IE.

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

If eNB₂ is capable to provide some but not all of the requested resource status information and the Partial Success Indicator IE is present in the RESOURCE STATUS REQUEST message, it shall initiate the measurement for the admitted measurement objects and include the Measurement Initiation Result IE in the RESOURCE STATUS RESPONSE message.

8.3.6.3 Unsuccessful Operation

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

If none of the requested measurements can be initiated, eNB₂ shall send a RESOURCE STATUS FAILURE message. The Cause IE shall be set to an appropriate value e.g. "Measurement Temporarily not Available" or "Measurement not Supported For The Object" for each requested measurement object. The eNB may use the Complete Failure Cause Information IE to enhance the failure cause information per measurement in the RESOURCE STATUS FAILURE message.

8.3.6.4 Abnormal Conditions

If the initiating eNB₁ does not receive either RESOURCE STATUS RESPONSE message or RESOURCE STATUS FAILURE message, the eNB₁ may reinitiate the Resource Status Reporting Initiation procedure towards the same eNB, 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 initiating eNB₁ receives the RESOURCE STATUS RESPONSE message including the Measurement Initiation Result IE containing no admitted measurements, the eNB₁ shall consider the procedure as failed.

If the Report Characteristics IE bitmap is set to "0" (all bits are set to "0") in the RESOURCE STATUS REQUEST message then eNB₂ shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "ReportCharacteristicsEmpty".

If the Reporting Periodicity IE value is not specified when at least one of the bits of the Report Characteristics IE, for which semantics is specified, other than the sixth or seventh bit, is set to 1 then eNB₂ shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "NoReportPeriodicity".

If the Reporting Periodicity of RSRP Measurement Report IE value is not specified when the sixth bit of the Report Characteristics IE is set to 1, then eNB₂ shall initiate the RESOURCE STATUS FAILURE message and the cause shall be set to appropriate value e.g. "NoReportPeriodicity".

If the Reporting Periodicity of CSI Report IE value is not specified when the seventh bit of the Report Characteristics IE is set to 1, then eNB₂ shall initiate the RESOURCE STATUS FAILURE message and the cause shall be set to appropriate value e.g. "NoReportPeriodicity".

If the eNB₂ received a RESOURCE STATUS REQUEST message which includes the Registration Request IE set to "start" and the eNB1Measurement ID IE corresponding to an existing on-going load measurement reporting, then eNB₂ shall initiate a RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "ExistingMeasurementID".

If the Registration Request IE is set to "stop", "partial stop" or "add" and the RESOURCE STATUS REQUEST message does not contain eNB2 Measurement ID IE, eNB₂ shall consider the procedure as failed and respond with the RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "Unknown eNB Measurement ID".

If the Registration Request IE is set to "partial stop" and the Cell To Report IE contains cells that have not been initiated for the reporting before, eNB₂ shall consider the procedure as failed and respond with the RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "Cell not Available". If the Registration Request IE is set to "add" and the Cell To Report IE contains cells that have been initiated for the reporting before, eNB₂ shall consider the procedure as failed and respond with the RESOURCE STATUS FAILURE message, the cause shall be set to appropriate value e.g. "Cell not Available".

8.3.7 Resource Status Reporting

8.3.7.1 General

This procedure is initiated by eNB₂ to report the result of measurements admitted by eNB₂ following a successful Resource Status Reporting Initiation procedure.

The procedure uses non UE-associated signalling.

8.3.7.2 Successful Operation

Figure 8.3.7.2-1: Resource Status Reporting, successful operation

The eNB₂ 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, and thus not reported in the Measurement Failed Report Characteristics IE for the concerned cell in the RESOURCE STATUS RESPONSE message.

If the eNB₁ receives the RESOURCE STATUS UPDATE message which includes the UE ID IE in the RSRP Measurement Report List IE, the eNB₁ may use the UE ID IE to link the associated RSRP measurement report with other measurement results (e.g. CSI reports, RSRP measurement reports) of the same UE.

If the CSI Report IE including the CSI Process Configuration Index IE is received, eNB₁ shall interpret this IE as an index identifying one of the CSI process configurations that can be configured for all UEs within the cell where the CSI measurements were collected. For all UEs within the cell, the maximum number of CSI process configurations is given by the maximum value of the CSI Process Configuration Index IE.

If the eNB₁ receives the RESOURCE STATUS UPDATE message, which includes the Cell Reporting Indicator IE set to "stop request" in one or more items of the Cell Measurement Result IE, the eNB₁ should initialise the Resource Status Reporting Initiation procedure to remove all or some of the corresponding cells from the measurement.

8.3.7.3 Unsuccessful Operation

Not applicable.

8.3.7.4 Abnormal Conditions

If the eNB₁ receives a RESOURCE STATUS UPDATE message which includes the ABS Status IE, and all bits in the Usable ABS Pattern Info IE are set to ‘0’, the eNB1 shall ignore the DL ABS Status IE.

8.3.8 Mobility Settings Change

8.3.8.1 General

This procedure enables an eNB to negotiate the handover trigger settings with a peer eNB controlling neighbouring cells.

The procedure uses non UE-associated signalling.

8.3.8.2 Successful Operation

Figure 8.3.8.2-1: Mobility Settings Change, successful operation

The procedure is initiated with a MOBILITY CHANGE REQUEST message sent from eNB₁ to eNB₂.

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

8.3.8.3 Unsuccessful Operation

Figure 8.3.8.3-1: Mobility Settings Change, unsuccessful operation

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

8.3.8.4 Abnormal Conditions

Void.

8.3.9 Radio Link Failure Indication

8.3.9.1 General

The purpose of the Radio Link Failure Indication procedure is to transfer information regarding RRC re-establishment attempts, or received RLF Reports, between eNBs. The signalling takes place from the eNB at which a re-establishment attempt is made, or an RLF Report is received, to an eNB to which the UE concerned may have previously been attached prior to the connection failure. This may aid the detection of radio link failure and handover failure cases (TS 36.300 [15]).

The procedure uses non UE-associated signalling.

8.3.9.2 Successful Operation

Figure 8.3.9.2-1: Radio Link Failure Indication, successful operation

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

eNB₂ may include the ShortMAC-I IE in the RLF INDICATION message, e.g., in order to aid the eNB₁ to resolve a potential PCI confusion situation or to aid the eNB₁ to identify the UE.

eNB₂ may include the UE RLF Report Container IE and optionally also the UE RLF Report Container for extended bands IE in the RLF INDICATION message, which may be used by the eNB₁ to determine the nature of the failure. If the UE RLF Report Container IE is included in the RLF INDICATION message sent after successful re-establishment, the eNB₂ shall use the Re-establishment Cell ECGI IE in the RLF INDICATION message to indicate the ECGI of the cell where the re-establishment was successful.

eNB₂ may include the RRC Conn Setup Indicator IE in the RLF INDICATION message, which indicates that the RLF Report is retrieved after an RRC connection setup or an incoming successful handover.

If the RRC Conn Setup Indicator IE is present in the RLF INDICATION message, the eNB₁ shall ignore the values in the Failure cell PCI IE, Re-establishment cell ECGI IE, C-RNTI IE and ShortMAC-I IE.

eNB₂ may include the RRC Conn Reestab Indicator IE in the RLF INDICATION message, which may be used by the eNB₁ to determine where the failure occurred.

eNB₂ may include the NB-IoT RLF Report Container IE in the RLF INDICATION message, which may be used by the eNB₁ to determine the nature of the failure. If the NB-IoT RLF Report Container IE is included in the RLF INDICATION message sent after successful re-establishment, the eNB₂ shall use the Re-establishment Cell ECGI IE in the RLF INDICATION message to indicate the ECGI of the cell where the re-establishment was successful.

8.3.9.3 Unsuccessful Operation

Not applicable.

8.3.9.4 Abnormal Conditions

Void.

8.3.10 Handover Report

8.3.10.1 General

The purpose of the Handover Report procedure is to transfer mobility related information between eNBs.

The procedure uses non UE-associated signalling.

8.3.10.2 Successful Operation

Figure 8.3.10.2-1: Handover Report, successful operation

An eNB initiates the procedure by sending an HANDOVER REPORT message to another eNB. By sending the message eNB₁ indicates to eNB₂ 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 the eNB₁ indicates to eNB₂ that, following a successful handover from a cell of eNB₂ to a cell of eNB₁, a radio link failure occurred and the UE attempted RRC Re-establishment either at the original cell of eNB₂ (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 36.300 [15].

If the UE-related information is available in eNB₁, the eNB₁ should include in HANDOVER REPORT message:

– the Mobility Information IE, if the Mobility Information IE was sent for this handover from eNB₂;

– the Source cell C-RNTI IE.

If received, the eNB₂ uses the above information according to TS 36.300 [15].

If the UE RLF Report received from the eNB sending the RLF INDICATION message, as described in TS 36.300 [15], is available, the eNB₁ may also include it in the HANDOVER REPORT as UE RLF Report Container IE and optionally also UE RLF Report Container for extended bands IE.

If the Handover Report Type IE is set to "InterRAT ping-pong", then the eNB₁ indicates to eNB₂ that a completed handover from a cell of eNB₂ to a cell in other RAT might have resulted in an inter-RAT ping-pong and the UE was successfully handed over to a cell of eNB₁ (indicated with the Failure cell ECGI IE).

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

The report contains the source and target cells, and cause of the handover. If the Handover Report Type IE is set to "HO to wrong cell", then the Re-establishment cell ECGI IE shall be included in the HANDOVER REPORT message. If the Handover Report Type IE is set to "InterRAT ping-pong", then the Target cell in UTRAN IE shall be included in the HANDOVER REPORT message. If the Handover Report Type IE is set to "Inter-system ping-pong", then the Target cell in NG-RAN IE shall be included in the HANDOVER REPORT message.

8.3.10.3 Unsuccessful Operation

Not applicable.

8.3.10.4 Abnormal Conditions

Void.

8.3.11 Cell Activation

8.3.11.1 General

The purpose of the Cell Activation procedure is to request to a neighbouring eNB to switch on one or more cells, previously reported as inactive due to energy saving reasons.

The procedure uses non UE-associated signalling.

8.3.11.2 Successful Operation

Figure 8.3.11.2-1: Cell Activation, successful operation

An eNB₁ initiates the procedure by sending a CELL ACTIVATION REQUEST message to a peer eNB₂.

Upon receipt of this message, eNB₂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.

Interactions with eNB Configuration Update procedure:

eNB₂ shall not send an ENB CONFIGURATION UPDATE message to eNB₁ just for the reason of the cell(s) indicated in the CELL ACTIVATION REQUEST message changing state, as the receipt of the CELL ACTIVATION RESPONSE message by eNB₁ is used to update the information about cell activation state of eNB₂ cells in eNB₁.

8.3.11.3 Unsuccessful Operation

Figure 8.3.11.3-1: Cell Activation, unsuccessful operation

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

8.3.11.4 Abnormal Conditions

Not applicable.

8.3.12 X2 Removal

8.3.12.1 General

The purpose of the X2 Removal procedure is to remove the signaling connection between two eNBs in a controlled manner. If successful, this procedure erases any existing application level configuration data in the two nodes.

The procedure uses non UE-associated signaling.

8.3.12.2 Successful Operation

Figure 8.3.12.2-1: X2 Removal, successful operation

An eNB₁ initiates the procedure by sending the X2 REMOVAL REQUEST message to a candidate eNB₂. Upon reception of the X2 REMOVAL REQUEST message the candidate eNB₂ shall reply with the X2 REMOVAL RESPONSE message. After receiving the X2 REMOVAL RESPONSE message, the initiating eNB₁ shall initiate removal of the TNL association towards eNB₂ and may remove all resources associated with that signaling connection. The candidate eNB₂ may then remove all resources associated with that signaling connection.

If the X2 Removal Threshold IE is included in the X2 REMOVAL REQUEST message, the candidate eNB₂ shall, if supported, accept to remove the signalling connection with eNB₁ if the X2 Benefit Value of the signalling connection determined at the candidate eNB₂ is lower than the value of the X2 Removal Threshold IE.

8.3.12.3 Unsuccessful Operation

Figure 8.3.12.3-1: X2 Removal, unsuccessful operation

If the candidate eNB₂ cannot accept to remove the signaling connection with eNB₁ it shall respond with an X2 REMOVAL FAILURE message with an appropriate cause value.

8.3.12.4 Abnormal Conditions

Void.

8.3.13 Retrieve UE Context

8.3.13.1 General

The purpose of the Retrieve UE Context procedure is to retrieve the UE context from the eNB where the RRC connection has been suspended (old eNB) and transfer it to the eNB where the RRC Connection has been requested to be resumed (new eNB) or to retrieve the UE context for a UE which attempts to re-establish its RRC connection in an eNB (the new eNB) different from the eNB (the old eNB) where the RRC connection failed, e.g. due to RLF.

The procedure uses UE-associated signalling.

8.3.13.2 Successful Operation

Figure 8.3.13.2-1: Retrieve UE Context, successful operation

The new eNB initiates the procedure by sending the RETRIEVE UE CONTEXT REQUEST message to the old eNB.

If the old eNB is able to identify the UE context and to successfully verify the UE by means of the Resume ID, the ShortMAC-I, optionally the C-RNTI, the failure cell PCI and the E-UTRAN Cell Identifier of the new cell contained in the RETRIEVE UE CONTEXT REQUEST message, it shall respond with the RETRIEVE UE CONTEXT RESPONSE message. The allocation of resources according to the values of the Allocation and Retention Priority IE included in the E-RAB Level QoS Parameters IE shall follow the principles described for the E-RAB Setup procedure in TS 36.413 [4].

If the C-RNTI IE is present in the RETRIEVE UE CONTEXT REQUEST, the old eNB shall ignore the Resume ID IE.

The old eNB may include in the GUMMEI IE any GUMMEI corresponding to the source MME node.

If the PLMN of the new cell is not the Serving PLMN stored in the UE Context the old eNB shall replace the Serving PLMN with the PLMN of the new cell and move the Serving PLMN to the equivalent PLMN list, before propagating the roaming and access restriction information to the new eNB.The new eNB shall act upon reception of the

– UE Security Capabilities IE,

– AS Security Information IE,

– Subscriber Profile ID for RAT/Frequency priority IE,

– Additional RRM Policy Index IE,

– Handover Restriction List IE,

– Location Reporting Information IE,

– Management Based MDT Allowed IE

– Management Based MDT PLMN List IE

– Trace Activation IE,

– SRVCC Operation Possible IE,

– Masked IMEISV IE

– Expected UE Behaviour IE,

– ProSe Authorized IE,

– V2X Services Authorized IE,

– Aerial UE subscription information IE,

– Subscription Based UE Differentiation Information IE,

– EPC Handover Restriction List Container IE,

– Security Indication IE,

within the RETRIEVE UE CONTEXT RESPONSE message as specified for the new eNB upon reception of the HANDOVER REQUEST message for the Handover Preparation procedure.

If the UE Sidelink Aggregate Maximum Bit Rate IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, use it for the concerned UE’s sidelink communication in network scheduled mode for V2X services.

If the Aerial UE subscription information IE is included in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, store this information in the UE context and use it as defined in TS 36.300 [15].

For each E-RAB for which the old eNB proposes to do forwarding of downlink data, the old eNB shall include the DL Forwarding IE within the E-RABs To Be Setup Item IE of the RETRIEVE UE CONTEXT RESPONSE message.

If the Bearer Type IE is included in the RETRIEVE UE CONTEXT RESPONSE message and is set to "non IP", then the new eNB shall not perform IP header compression for the concerned E-RAB.

If the Ethernet Type IE is included in the RETRIEVE UE CONTEXT RESPONSE message and is set to "True", then the new eNB shall, if supported, take this into account to perform header compression appropriately for the concerned E-RAB.

If the NR UE Sidelink Aggregate Maximum Bit Rate IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, use it for the concerned UE’s sidelink communication in network scheduled mode for NR V2X services.

If the NR V2X Services Authorized IE is contained in the RETRIEVE UE CONTEXT RESPONSE message and it contains one or more IEs set to "authorized", the eNB shall, if supported, consider that the UE is authorized for the relevant service(s).

If the PC5 QoS Parameters IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, use it for the concerned UE’s NR sidelink communication as specified in TS 23.285 [41].

If the UE Radio Capability ID IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, store this information in the UE context and use it as specified in TS 23.401 [12].

If the IMS voice EPS fallback from 5G IE is contained in the RETRIEVE UE CONTEXT RESPONSE message, the new eNB shall, if supported, store this information in the UE context and consider that the UE was previously handed over from NG-RAN to E-UTRAN due to an IMS voice fallback.

8.3.13.3 Unsuccessful Operation

Figure 8.3.13.3-1: Retrieve UE Context, unsuccessful operation

If the old eNB is not able to identify the UE context by means of the Resume ID, or with the ShortMAC-I, C-RNTI, failed cell PCI and new E-UTRAN Cell Identifier contained in the RETRIEVE UE CONTEXT REQUEST message, it shall respond to the new eNB with the RETRIEVE UE CONTEXT FAILURE message.

8.3.13.4 Abnormal Conditions

Void.

8.3.14 EN-DC X2 Removal

8.3.14.1 General

The purpose of the EN-DC X2 Removal procedure is to remove the interface instance between eNB and en-gNB 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 X2-C interface instances, and the TNL association is still used by one or more X2-C interface instances, the initiating node should not initiate the removal of the TNL association.

The procedure uses non UE-associated signaling.

8.3.14.2 Successful Operation

Figure 8.3.14.2-1: eNB Initiated EN-DC X2 Removal, successful operation

Figure 8.3.14.2-2: en-gNB Initiated EN-DC X2 Removal, successful operation

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

eNB initiated EN-DC X2 Removal:

An eNB initiates the procedure by sending the EN-DC X2 REMOVAL REQUEST message to a candidate en-gNB. Upon reception of the EN-DC X2 REMOVAL REQUEST message the candidate en-gNB shall reply with the EN-DC X2 REMOVAL RESPONSE message. After receiving the EN-DC X2 REMOVAL RESPONSE message, the initiating eNB shall initiate removal of the TNL association towards en-gNB and may remove all resources associated with that interface instance. The candidate eNB may then remove all resources associated with that interface instance.

If the X2 Removal Threshold IE is included in the EN-DC X2 REMOVAL REQUEST message, the candidate en-gNB shall, if supported, accept to remove the interface instance with eNB if the X2 Benefit Value of the interface instance determined at the candidate en-gNB is lower than the value of the X2 Removal Threshold IE.

en-gNB initiated EN-DC X2 Removal:

An en-gNB initiates the procedure by sending the EN-DC X2 REMOVAL REQUEST message to a candidate eNB. Upon reception of the EN-DC X2 REMOVAL REQUEST message the candidate eNB shall reply with the EN-DC X2 REMOVAL RESPONSE message. After receiving the EN-DC X2 REMOVAL RESPONSE message, the initiating en-gNB shall initiate removal of the TNL association towards eNB and may remove all resources associated with that interface instance. The candidate eNB may then remove all resources associated with that interface instance.

If the X2 Removal Threshold IE is included in the EN-DC X2 REMOVAL REQUEST message, the candidate eNB shall, if supported, accept to remove the interface instance with en-gNB if the X2 Benefit Value of the interface instance determined at the candidate eNB is lower than the value of the X2 Removal Threshold IE.

8.3.14.3 Unsuccessful Operation

Figure 8.3.14.3-1: eNB Initiated EN-DC X2 Removal, unsuccessful operation

Figure 8.3.14.3-2: en-gNB Initiated EN-DC X2 Removal, unsuccessful operation

If the candidate receiving node cannot accept to remove the interface instance with initiating node it shall respond with an EN-DC X2 REMOVAL FAILURE message with an appropriate cause value.

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

8.3.14.4 Abnormal Conditions

Void.

8.3.15 Data Forwarding Address Indication

8.3.15.1 General

The purpose of the Data Forwarding Address Indication procedure is to allow the new eNB to provide data forwarding addresses to the old eNB in case the RRC connection has been re-established, as specified in TS 36.300 [15].

For Dual Connectivity or EN-DC, the Data Forwarding Address Indication procedure is used during a Conditional Handover to provide data forwarding related information from the MeNB to the SeNB as specified in TS 36.300 [15], or from the MeNB to the en-gNB as specified in TS 37.340 [32].

The procedure uses UE-associated signalling.

8.3.15.2 Successful Operation

Figure 8.3.15.2-1: Data Forwarding Address Indication, successful operation

Figure 8.3.15.2-2: Data Forwarding Address Indication for Conditional Handover, successful operation

The new eNB initiates the procedure by sending a DATA FORWARDING ADDRESS INDICATION message to the old eNB.

For each E-RAB included in E-RABs Data Forwarding Address List IE, the new eNB indicates that it requests data forwarding of downlink packets to the GTP TEID indicated in the DL GTP Tunnel Endpoint IE.

If the DATA FORWARDING ADDRESS INDICATION message includes the CHO DC Indicator IE, the SeNB (respectively, the en-gNB for EN-DC) shall, if supported, consider that the DATA FORWARDING ADDRESS INDICATION message concerns a Conditional Handover, and act as specified in TS 36.300 [15] for dual connectivity (respectively, act as specified in TS 37.340 [32] for EN-DC).

If the DATA FORWARDING ADDRESS INDICATION message includes the CHO DC Early Data Forwarding Indicator IE set to "stop", the SeNB (respectively, the en-gNB for EN-DC) shall, if supported and if already initiated, stop early data forwarding for the provided E-RABs Data Forwarding Address information.

If the DATA FORWARDING ADDRESS INDICATION message includes the CPC Data Forwarding Indicator IE set to “triggered”, the en-gNB for EN-DC shall, if supported, consider that the DATA FORWARDING ADDRESS INDICATION message concerns a Conditional PSCell Change, and act as specified in TS 37.340 [32]. If the CPC Data Forwarding Indicator IE is set to "early data transmission stop", the en-gNB shall, if supported and if already initiated, stop early data forwarding for the provided Data Forwarding Address information.

EN-DC

If the MeNB sends the message to the en-gNB, then the SgNB UE X2AP ID IE shall be included in the DATA FORWARDING ADDRESS INDICATION message, while the New eNB UE X2AP ID IE is ignored. The SgNB UE X2AP ID IE is used as the new UE ID.

8.3.15.3 Unsuccessful Operation

Not applicable.

8.3.15.4 Abnormal Conditions

Void.

8.3.16 Access and Mobility Indication

8.3.16.1 General

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

8.3.16.2 Successful Operation

Figure 8.3.16.2-1: Access and Mobility Indication. Successful operation – eNB-initiated

The eNB initiates the procedure by sending the ACCESS AND MOBILITY INDICATION message sent to theen-gNB.

8.3.16.3 Abnormal Conditions

Not applicable.