20.2.2 X2-CP Procedures

36.3003GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN)Overall descriptionRelease 17Stage 2TS

20.2.2.0 Overview of X2-CP procedures

The elementary procedures supported by the X2AP protocol are listed in Table 8.1-1 and Table 8.1-2 of TS 36.423 [42].

20.2.2.1 Handover Preparation procedure

The Handover preparation procedure is initiated by the source eNB if it determines the necessity to initiate the handover via the X2 interface.

Figure 20.2.2.1-1: Handover Preparation procedure

The source eNB sends a HANDOVER REQUEST to the target eNB including the bearers to be setup by the target ENB.

The handover preparation phase is finished upon the reception of the HANDOVER REQUEST ACKNOWLEDGE message in the source eNB, which includes at least radio interface related information (HO Command for the UE), successfully established E-RAB(s) and failed established E-RAB(s).

In case the handover resource allocation is not successful (e.g. no resources are available on the target side) the target eNB responds with the HANDOVER PREPARATION FAILURE message instead of the HANDOVER REQUEST ACKNOWLEDGE message.

If eNB received NAS message from MME during X2 handover procedure, it shall be acted as specified in clause 19.2.2.6.

20.2.2.2 Handover Cancel procedure

This functionality is located in the source eNB to allow cancellation of the handover procedure.

Figure 20.2.2.2-1: Handover Cancel procedure

The source eNB sends a HANDOVER CANCEL message to the target eNB indicating the reason for the handover cancellation.

20.2.2.2a SeNB Addition Preparation procedure

The SeNB Addition Preparation procedure is initiated by the MeNB to request the SeNB to allocate resources for DC operation for a specific UE.

Figure 20.2.2.2a-1: SeNB Addition Preparation procedure

The MeNB sends an SENB ADDITION REQUEST message to the SeNB including the bearers for which DC shall be configured.

In case resource allocation at the SeNB has been performed successfully, the SeNB responds with an SENB ADDITION REQUEST ACKNOWLEDGE message, which includes radio interface related information, successfully established and failed to be established bearers for DC.

In case the SeNB addition is not successful (e.g. no resources are available on the SeNB side) the SeNB responds with the SENB ADDITION REJECT message instead.

20.2.2.2b SeNB Reconfiguration Completion procedure

The SeNB Reconfiguration Complete procedure is initiated by the MeNB to indicate to the SeNB that the UE has been successfully configured with the requested SeNB radio configuration.

Figure 20.2.2.2b-1: SeNB Reconfiguration Completion procedure

The same procedure is also used by the MeNB to indicate that the MeNB finally decided to not request the UE to apply the radio configuration requested by the SeNB.

The SeNB Reconfiguration Completion procedure is used in the course of an SeNB Addition and in the course of an MeNB initiated SeNB Modification if the MeNB initiated SeNB Modification requires signalling towards the UE.

20.2.2.2c MeNB initiated SeNB Modification Preparation procedure

The MeNB initiated SeNB Modification Preparation procedure is initiated by the MeNB to request the SeNB to modify resources allocated for a specific UE at the SeNB.

Figure 20.2.2.2c-1: MeNB initiated SeNB Modification Preparation procedure

The MeNB initiated SeNB Modification does not necessarily result in communication towards the UE.

In case resource modification at the SeNB has been performed successfully, the SeNB responds with an SENB MODICATION REQUEST ACKNOWLEDGE message.

In case the SeNB modification is not successful (e.g. no resources are available on the SeNB side), the SeNB responds with the SENB MODIFICATION REQUEST REJECT message instead.

20.2.2.2d SeNB initiated SeNB Modification procedure

The SeNB initiated SeNB Modification Preparation procedure is initiated to request the modification of the UE context at the SeNB.

Figure 20.2.2.2d-1: SeNB initiated SeNB Modification procedure

The SeNB initiated SeNB Modification does not necessarily result in communication towards the UE.

If the MeNB decides to not follow the SeNBs request it replies with an SENB MODIFICATION REFUSE message.

20.2.2.2e MeNB initiated SeNB Release procedure

The MeNB initiated SeNB Release procedure is triggered by the MeNB to initiate the release of the resources for a specific UE at the SeNB.

Figure 20.2.2.2e-1: MeNB initiated SeNB Release procedure

20.2.2.2f SeNB initiated SeNB Release procedure

The SeNB initiated SeNB Release procedure is triggered by the SeNB to initiate the release of the resources for a specific UE at the SeNB.

Figure 20.2.2.2f-1: SeNB initiated SeNB Release procedure

20.2.2.2g SeNB Counter Check procedure

The SeNB Counter Check procedure is initiated by the SeNB to request the MeNB to execute a counter check procedure to verify the value of the PDCP COUNTs associated with SCG bearers established in the SeNB.

Figure 20.2.2.2g-1: SeNB Counter Check procedure

20.2.2.3 UE Context Release procedure

At handover, the UE Context Release procedure is initiated by the target eNB to signal to the source eNB that resources for the handed over UE context can be released.

For DC, the UE Context Release procedure is initiated by the MeNB to finally release the resources at the SeNB for the specific UE once either the SeNB initiated or the MeNB initiated SeNB Release Procedure has been performed.

Figure 20.2.2.3-1: UE Context Release procedure for handover and DC.

At handover, by sending UE CONTEXT RELEASE the target eNB informs the source eNB of Handover success and triggers the release of resources.

Figure 20.2.2.3-2: UE Context Release procedure for EN-DC.

For EN-DC, the UE Context Release procedure is initiated by the MeNB to finally release the UE context at the SgNB for the specific UE once either the SgNB initiated or the MeNB initiated SgNB Release Procedure has been performed.

20.2.2.4 SN Status Transfer procedure

The purpose of the SN Status Transfer procedure is to transfer the uplink PDCP SN and HFN receiver status and the downlink PDCP SN and HFN transmitter status from the source to the target eNB during an X2 handover, or between MeNB and SgNB involved in EN-DC, or between the old and the new eNB at RRC connection re-establishment for each respective E-RAB for which PDCP SN and HFN status preservation applies.

Figure 20.2.2.4-1: SN Status Transfer procedure for handover.

Figure 20.2.2.4-2: MeNB-initiated SN Status Transfer procedure for EN-DC.

Figure 20.2.2.4-3: SgNB-initiated SN Status Transfer procedure for EN-DC.

Figure 20.2.2.4-4: SN Status Transfer procedure for RRC Connection Re-establishment.

20.2.2.5 Error Indication procedure

The Error Indication procedure is initiated by an eNB or an en-gNB to signal to a peer E-UTRAN node an error situation in a received message, provided it cannot be reported by an appropriate failure message.

Figure 20.2.2.5-1: Error Indication procedure between eNB and eNB

Figure 20.2.2.5-2: en-gNB-initiated Error Indication procedure between en-gNB and eNB

Figure 20.2.2.5-3: eNB-initiated Error Indication procedure between eNB and en-gNB

20.2.2.6 Load Indication procedure

Inter-cell interference coordination in E-UTRAN is performed through the X2 interface. In case of variation in the interference conditions, the eNB signals the new condition to its neighbour eNBs e.g. the neighbour eNBs for which an X2 interface is configured due to mobility reasons.

When the time-domain inter-cell interference coordination is used to mitigate interference, the eNB signals its almost blank subframe (ABS) patterns to its neighbour eNBs, so that the receiving eNB can utilize the ABS of the sending eNB with less interference.

NOTE: A typical use case of the time-domain solution of inter-cell interference coordination is the one where an eNB providing broader coverage and therefore being more capacity constrained determines its ABS patterns and indicates them to eNBs, providing smaller coverage residing in its area.

When inter-eNB CoMP is used, the eNB signals the CoMP hypotheses and associated benefit metrics to its neighbour eNB(s), so that the receiving eNB may take them into account for RRM.

The Load Indication procedure is used to transfer interference co-ordination information between neighbouring eNBs managing intra-frequency cells, and adjacent frequency TDD cells.

Figure 20.2.2.6-1: Load Indication procedure

20.2.2.7 X2 Setup procedure

The purpose of the X2 Setup procedure is to exchange application level data needed for two eNBs to interoperate correctly over the X2 interface.

Figure 20.2.2.7-1: X2 Setup procedure

20.2.2.8 eNB Configuration Update procedure

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.

Figure 20.2.2.8-1: eNB Configuration Update procedure

20.2.2.9 Reset procedure

The Reset procedure is initiated by an eNB or an en-gNB to align the resources with a peer E-UTRAN node in the event of an abnormal failure. The procedure resets the whole X2 interface.

Figure 20.2.2.9-1: Reset procedure between eNBs

Figure 20.2.2.9-2: eNB-initiated Reset procedure between eNB and en-gNB

Figure 20.2.2.9-3: en-gNB-initiated Reset procedure between en-gNB and eNB

20.2.2.10 Resource Status Reporting Initiation procedure

The Resource Status Reporting Initiation procedure is used by an eNB to request measurements from another eNB.

Figure 20.2.2.10-1: Resource Status Reporting Initiation procedure

20.2.2.11 Resource Status Reporting procedure

The Resource Status Reporting procedure reports measurement results requested by another eNB.

Figure 20.2.2.11-1: Resource Status Reporting procedure

20.2.2.12 Radio Link Failure Indication procedure

The purpose of the Radio Link Failure Indication procedure is to enable mobility robustness and radio link failure recovery improvement in E-UTRAN by passing information about a failure event over the X2 interface.

When a re-establishment request is received or a connection failure reported after RRC connection setup or an incoming successful handover, the eNB uses the cell identifiers provided by the UE to identify the potentially previous serving cell/eNB. The eNB that received the information about the failure sends a RLF INDICATION message to the concerned eNB(s). The previously serving eNB may then match the correct context, or use the information available in the RLF Report, if included in the RLF INDICATION message, to analyze the possible root cause of the failure. If the previous serving eNB matches the correct context, it may also trigger the Handover Preparation procedure towards the eNB that initiated the Radio Link Failure Indication procedure.

NOTE: When deciding whether to trigger the Handover preparation procedure the previously serving eNB may take into account a number of factors, e.g. the CSFB indicator in the UE Context.

Figure 20.2.2.12-1: Radio Link Failure Indication procedure

20.2.2.13 Handover Report procedure

The purpose of the Handover Report procedure is to enable mobility robustness improvement in E-UTRAN.

The Handover Report procedure is used to pass information connected to the analysis of an RLF which occurred shortly after a successful handover.

The eNB where the RLF occurred (original target eNB) sends a HANDOVER REPORT message to the original source eNB, identifying the source cell, the target cell, and the cell where re-establishment took place.

The Handover Report procedure is also used to pass information connected to potential inter-RAT ping-pong cases. The eNB that detected the potential ping-pong cases sends a HANDOVER REPORT message to the source eNB of the first inter-RAT handover, identifying the source and the target cells of the first inter-RAT handover, and the target cell of the second inter-RAT handover.

Figure 20.2.2.13-1: Handover Report procedure

20.2.2.14 Mobility Settings Change procedure

The purpose of the MOBILITY SETTINGS CHANGE procedure is to enable an eNB to send a MOBILITY CHANGE REQUEST message to a peer eNB to negotiate the handover trigger settings.

Figure 20.2.2.14-1: Mobility Settings Change procedure

20.2.2.15 Cell Activation procedure

The purpose of the Cell Activation procedure is to enable an eNB to send a CELL ACTIVATION REQUEST message to a peer eNB to request the re-activation of one or more cells, controlled by the peer eNB and which had been previously indicated as dormant.

Figure 20.2.2.15-1: Cell Activation procedure

20.2.2.16 X2 Release procedure

The purpose of the X2 Release procedure is to enable an X2 GW to inform the relevant (H)eNBs that the signalling (i.e. SCTP) connection to a peer (H)eNB is unavailable.

Figure 20.2.2.16-1: X2 Release procedure

20.2.2.17 X2AP Message Transfer procedure

The purpose of the X2AP Message Transfer procedure is to allow indirect transport of an X2AP message (except the X2AP MESSAGE TRANSFER message) between two (H)eNBs through an X2 GW, and to allow an (H)eNB to register with an X2 GW.

Figure 20.2.2.17-1: X2AP Message Transfer procedure

20.2.2.18 X2 Removal procedure

The purpose of the X2 Removal procedure is to perform the removal of X2 connectivity between two eNBs in a controlled manner. If the procedure is successful, the receiving eNB responds with the X2 REMOVAL RESPONSE message, after which both eNBs remove the X2 signalling connection between them and may release all associated resources. In case the receiving eNB cannot remove the X2 signalling connection (e.g. because of an ongoing procedure and/or due to local configuration), it responds with the X2 REMOVAL FAILURE message. The initiating eNB may include an X2 removal threshold for removal of a signalling connection.

Figure 20.2.2.18-1: X2 Removal procedure

20.2.2.19 Retrieve UE Context

The purpose of the Retrieve UE Context procedure is to retrieve the UE context for a UE which attempts to resume its RRC connection in an eNB (the new eNB) different from the eNB (the old eNB) where the RRC connection was suspended or 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.

If the new eNB is able to identify the old eNB based on the Resume ID or based on the Physical Cell ID received from the UE, it triggers the Retrieve UE Context procedure towards the old eNB.

If the old eNB is able to match the UE context with the Resume ID or with the ShortMAC-I, C-RNTI, failed PCI and new E-UTRAN Cell Identifier included in the RETRIEVE UE CONTEXT REQUEST message it responds with the RETRIEVE UE CONTEXT RESPONSE message containing UE context information.

Upon resumption of the UE Context in the new eNB, the new eNB resumes/re-establishes the RRC connection and performs the S1-AP Path Switch procedure to establish a S1 UE associated signalling connection to the serving MME and to request the MME to resume the UE context and related bearer contexts in the EPC (for resuming UEs) and update the downlink path (for resuming and re-establishing UEs). In case of re-establishment of the RRC connection, the new eNB may provide a data forwarding address per re-established E-RAB to the old eNB by means of the X2-AP Data Forwarding Address Indication procedure if DL forwarding was proposed by the old eNB. After the S1-AP Path Switch procedure the new eNB triggers release of the UE Context at the old eNB by means of the X2-AP UE Context Release procedure.

Figure 20.2.2.19-1: Retrieve UE Context procedure (highlighted in blue) for cases of UE context resumption. Successful case

Figure 20.2.2.19-1A: Retrieve UE Context procedure (highlighted in blue) for cases of UE re-establishment. Successful case

In case the old eNB cannot find UE Context Information corresponding to the Resume ID or to the ShortMAC-I, C-RNTI, failed PCI and new E-UTRAN Cell Identifier received from the UE, it responds with the RETRIEVE UE CONTEXT FAILURE message and the new eNB fails the RRC connection resume/re-establishment procedure as specified in TS 36.331 [16].

Figure 20.2.2.19-2: Retrieve UE Context procedure (highlighted in blue) for cases of UE context resumption. Unsuccessful case

Figure 20.2.2.19-3: Retrieve UE Context procedure (highlighted in blue) for cases of UE re-establishment. Unsuccessful case

20.2.2.20 SgNB Addition Preparation procedure

The SgNB Addition Preparation procedure is initiated by the MeNB to request the SgNB to allocate resources for EN-DC operation for a specific UE.

Figure 20.2.2.20-1: SgNB Addition Preparation procedure

The MeNB sends an SGNB ADDITION REQUEST message to the SgNB including the bearers for which EN-DC shall be configured.

In case resource allocation at the SgNB has been performed successfully, the SgNB responds with an SGNB ADDITION REQUEST ACKNOWLEDGE message, which includes radio interface related information, successfully established and failed to be established bearers for EN-DC.

In case the SgNB Addition is not successful (e.g. no resources are available on the SgNB side) the SgNB responds with the SGNB ADDITION REJECT message instead.

20.2.2.21 SgNB Reconfiguration Completion procedure

The SgNB Reconfiguration Complete procedure is initiated by the MeNB to indicate to the SgNB that the UE has been successfully configured with the requested SgNB radio configuration.

Figure 20.2.2.21-1: SgNB Reconfiguration Completion procedure

The same procedure is also used by the MeNB to indicate that the MeNB finally decided to not request the UE to apply the radio configuration requested by the SgNB.

The SgNB Reconfiguration Completion procedure is used in the course of an SgNB Addition and in the course of an MeNB initiated SgNB Modification if the MeNB initiated SgNB Modification requires signalling towards the UE.

20.2.2.22 MeNB initiated SgNB Modification Preparation procedure

The MeNB initiated SgNB Modification Preparation procedure is initiated by the MeNB to request the SgNB to modify resources allocated for a specific UE at the SgNB.

Figure 20.2.2.22-1: MeNB initiated SgNB Modification Preparation procedure

The MeNB initiated SgNB Modification does not necessarily result in communication towards the UE.

In case resource modification at the SgNB has been performed successfully, the SgNB responds with an SGNB MODICATION REQUEST ACKNOWLEDGE message.

In case the SgNB modification is not successful (e.g. no resources are available on the SgNB side), the SgNB responds with the SGNB MODIFICATION REQUEST REJECT message instead.

20.2.2.23 SgNB initiated SgNB Modification Preparation procedure

The SgNB initiated SgNB Modification Preparation procedure is initiated to request the modification of the UE context at the SgNB.

Figure 20.2.2.23-1: SgNB initiated SgNB Modification procedure

The SgNB initiated SgNB Modification does not necessarily result in communication towards the UE.

If the MeNB decides to not follow the SgNBs request it replies with an SGNB MODIFICATION REFUSE message.

20.2.2.24 MeNB initiated SgNB Release procedure

The MeNB initiated SgNB Release procedure is triggered by the MeNB to initiate the release of the resources for a specific UE at the SgNB.

Figure 20.2.2.24-1: MeNB initiated SgNB Release procedure

20.2.2.25 SgNB initiated SgNB Release procedure

The SgNB initiated SgNB Release procedure is triggered by the SgNB to initiate the release of the resources for a specific UE at the SgNB.

Figure 20.2.2.25-1: SgNB initiated SgNB Release procedure

20.2.2.26 SgNB initiated SgNB Change procedure

The SgNB initiated SgNB Change procedure is triggered by the SgNB to initiate the transfer of the resources for a specific UE at the SgNB to another en-gNB.

Figure 20.2.2.26-1: SgNB initiated SgNB Change procedure

In case the transfer of the UE context to the target en-gNB has been performed successfully, the MeNB responds with an SGNB CHANGE CONFIRM message.

If the MeNB is not able to transfer the UE context to the target en-gNB, it replies with an SGNB CHANGE FAILURE message.

20.2.2.27 SgNB Counter Check procedure

The SgNB Counter Check procedure is initiated by the SgNB to request the MeNB to execute a counter check procedure to verify the value of the PDCP COUNTs associated with SCG bearers or SCG split bearers.

Figure 20.2.2.27-1: SgNB Counter Check procedure

20.2.2.28 EN-DC X2 Setup procedure

The purpose of the EN-DC X2 Setup procedure is to exchange application level data needed for an eNB and an en-gNB to interoperate correctly over the X2 interface in EN-DC case. The procedure is triggered by the eNB or by the en-gNB.

Figure 20.2.2.28-1: EN-DC X2 Setup procedure triggered by the eNB.

Figure 20.2.2.28-2: EN-DC X2 Setup procedure triggered by the en-gNB.

20.2.2.29 EN-DC Configuration Update procedure

The purpose of the EN-DC Configuration Update procedure is to update application level configuration data needed for an eNB and an en-gNB to interoperate correctly over the X2 interface in EN-DC case. The procedure is triggered by the eNB or by the en-gNB.

Figure 20.2.2.29-1: EN-DC Configuration Update procedure triggered by the eNB.

Figure 20.2.2.29-2: EN-DC Configuration Update procedure triggered by the en-gNB.

20.2.2.30 EN-DC Cell Activation procedure

The purpose of the EN-DC Cell Activation procedure is to enable an eNB to request the re-activation of one or more NR cells controlled by an en-gNB, and which had been previously indicated as dormant.

Figure 20.2.2.30-1: EN-DC Cell Activation procedure

20.2.2.31 E-UTRA – NR Cell Resource Coordination procedure

The purpose of the E-UTRA – NR Cell Resource Coordination procedure is to exchange information needed for an eNB and an en-gNB to coordinate cell resources when E-UTRA and NR cells are deployed on overlapping carrier. The procedure is triggered by the eNB or by the en-gNB.

Figure 20.2.2.31-1: E-UTRA – NR Cell Resource Coordination procedure triggered by the eNB.

Figure 20.2.2.31-2: E-UTRA – NR Cell Resource Coordination procedure triggered by the en-gNB.

20.2.2.32 Partial Reset procedure for EN-DC

The Partial Reset procedure for EN-DC is triggered by the en-gNB or the MeNB to initiate the release of the resources for a list of UEs with the EN-DC configuration.

Figure 20.2.2.32-1: Partial Reset procedure for EN-DC (initiated at the en-gNB)

Figure 20.2.2.32-2: Partial Reset procedure for EN-DC (initiated at the MeNB)

20.2.2.33 UE Radio Capability ID Mapping procedure

The purpose of the UE Radio Capability ID Mapping Request procedure is to enable the en-gNB to request the MeNB to provide the UE Radio Capability information that maps to a specific UE Radio Capability ID.

Figure 20.2.2.33-1: UE Radio Capability ID Mapping procedure