15 X2 interface
Chapter 15 X2 interface Topic
Page
Introduction .................................................................................................... 571 X2 signalling bearer ....................................................................................... 572 X2AP ............................................................................................................... 573 Handover ................................................................................................... 574 Load indication .......................................................................................... 584 Error Indication ......................................................................................... 586 X2 Setup .................................................................................................... 587 Reset .......................................................................................................... 587 eNB Configuration Update ........................................................................ 588 Resource Status Reporting ........................................................................ 589 Mobility Settings Change .......................................................................... 590 Radio Link Failure Indication ................................................................... 592 Handover Report ....................................................................................... 593
569
Signalling in E-UTRAN / LTE
This page is intentionally left blank
570
15 X2 interface
Introduction The interface allowing to interconnect eNBs with each other is referred to as the X2 interface. The list of functions on the X2 interface is the following: Intra LTE-Access-System Mobility Support for ECM-CONNECTED UE: Context transfer from source eNB to target eNB Control of user plane transport bearers between source eNB and target eNB Handover cancellation UE context release in source eNB Load Management
Inter-cell Interference Coordination: Uplink Interference Load Management
General X2 management and error handling functions: Error indication Reset
Application level data exchange between eNBs Trace functions
Figure 15-1 X2 interface functions The X2 interface protocol architecture consists of two functional layers: •
Radio Network Layer, defines the procedures related to the interaction between eNBs. (The radio network layer consists of a Radio Network Control Plane and a Radio Network User Plane.)
•
The transport network layer provides services for user plane and signalling transport. control plane
user plane
X2AP
UP PDUs
Radio Network Layer
GTP-U SCTP Transport Network Layer
UDP IP
Data Link Layer Physical Layer
Figure 15-2 X2 interface protocol structure 571
Signalling in E-UTRAN / LTE
X2 signall signalling bearer The Transport Network Layer for X2AP is based on IP transport, comprising SCTP on top of IP. The eNB supports the Diffserv Code Point marking. The Payload Protocol Identifier assigned by IANA to be used by SCTP for the application layer protocol X2AP is 27. There is only one SCTP association established between one eNB pair. The Source/Destination Port Number assigned by IANA to be used for X2AP is 36422. An arbitrary eNB is able to initiate the INIT procedure towards another eNB for establishing the SCTP association. Within the SCTP association established between one eNB pair; •
a single pair of stream identifiers is reserved for the sole use of X2AP elementary procedures that utilize non UE-associated signalling.
•
at least one pair of stream identifiers (more than one recommended) is reserved for the sole use of X2AP elementary procedures that utilize UE-associated signalling.
•
a single UE-associated signalling shall use one SCTP stream and the stream should not be changed during the communication of the UE-associated signalling.
Transport network redundancy may be achieved by SCTP multi-homing between two end-points, of which one or both is assigned with multiple IP addresses. SCTP end-points shall support a multi-homed remote SCTP endpoint. The SCTP congestion control may, using an implementation specific mechanism, initiate higher layer protocols to reduce the signalling traffic at the source and prioritise certain messages. The signalling connection provides in sequence delivery of X2AP messages. X2AP is notified if the signalling connection breaks.
572
15 X2 interface
SCTP is used as the transport layer for X2AP eNB supports the Diffserv Code Point marking SCTP Payload Protocol Identifier for X2AP = 27 Only one association between one eNB pair SCTP Source/Destination Port Number = 36422 Single pair of stream identifiers reserved for X2AP non UE-associated signalling At least one pair (more than one recommended) of stream identifiers reserved for X2AP UE-associated signalling Single UE-associated signalling on one SCTP stream A multi-homed remote SCTP end-point supported
Figure 15-3 X2 Signalling bearer
X2AP The X2 interface X2AP procedures are divided into two modules as follows: •
X2AP Basic Mobility Procedures,
•
X2AP Global Procedures.
The X2AP Basic Mobility Procedures module contains procedures used to handle the UE mobility within E-UTRAN. The Global Procedures module contains procedures that are not related to a specific UE. The procedures in this module are in contrast to the above module involving two peer eNBs. Messages for Basic Mobility Procedures: HANDOVER REQUEST HANDOVER REQUEST ACK. HANDOVER PREPARATION FAILURE SN STATUS TRANSFER UE CONTEXT RELEASE HANDOVER CANCEL Messages for global procedures LOAD INFORMATION ERROR INDICATION X2 SETUP REQUEST X2 SETUP RESPONSE X2 SETUP FAILURE RESET REQUEST RESET RESPONSE
ENB CONFIGURATION UPDATE ENB CONFIGURATION UPDATE ACK. ENB CONFIGURATION UPDATE FAILURE RESOURCE STATUS REQUEST RESOURCE STATUS RESPONSE RESOURCE STATUS FAILURE RESOURCE STATUS UPDATE MOBILITY CHANGE REQUEST MOBILITY CHANGE ACKNOWLEDGE MOBILITY CHANGE FAILURE RLF INDICATION HANDOVER REPORT CELL ACTIVATION REQUEST CELL ACTIVATION RESPONSE CELL ACTIVATION FAILURE
Figure 15-4 X2AP messages
573
Signalling in E-UTRAN / LTE
Handover The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. The figure below depicts the basic handover scenario where neither MME nor S-GW changes. MME
S-GW
area restriction provided Measurement control
packet data
Measurement reports HO decision
Handover request Admission control
Connection reconfigur.
Handover request ack SN Status Transfer Buffer packets from source eNB
⓭ Synchronisation, RACH procedure, resource allocation, TA ⓭ Connection reconfiguration complete
⓭ End marker
⓭ Path Switch Req.
⓭ Modify bearer request. Switch DL path
⓭ UE Context Release
⓭ Path Switch Req. Ack.
⓭ Modify bearer resp.
⓭ Release resources
Figure 15-5 X2 Handover ❶ The UE context within the source eNB contains information regarding roaming restrictions which where provided either at connection establishment or at the last TA update. ❷ The source eNB configures the UE measurement procedures according to the area restriction information. Measurements provided by the source eNB may assist the function controlling the UE's connection mobility. ❸ UE is triggered to send RRC MEASUREMENT REPORT by the rules set by i.e. system information, specification etc. ❹ Source eNB makes decision based on RRC MEASUREMENT REPORT and RRM information to hand off UE. ❺ The source eNB issues an X2AP HANDOVER REQUEST message to the target eNB passing necessary information to prepare the HO at the target side 574
15 X2 interface
(UE X2 signalling context reference at source eNB, UE S1 EPC signalling context reference, target cell ID, KeNB*, RRC context including the C-RNTI of the UE in the source eNB, AS-configuration, E-RAB context and physical layer ID of the source cell). UE X2 / UE S1 signalling references enable the target eNB to address the source eNB and the EPC. The E-RAB context includes necessary Radio Network Layer (RNL) and Transport Network Layer (TNL) addressing information, and QoS profiles of the E-RABs. ❻ Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and optionally a RACH preamble. The AS-configuration to be used in the target cell can either be specified independently (i.e. an ‘establishment’) or as a delta compared to the AS-configuration used in the source cell (i.e. a ‘reconfiguration’). ❼ Target eNB prepares HO with L1/L2 and sends the X2AP HANDOVER REQUEST ACKNOWLEDGE to the source eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble, and possibly some other parameters i.e. access parameters, SIBs, etc. The HANDOVER REQUEST ACKNOWLEDGE message may also include RNL/TNL information for the forwarding tunnels, if necessary. As soon as the source eNB receives the X2AP HANDOVER REQUEST ACKNOWLEDGE, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding may be initiated. ❽ The target eNB generates the RRC message to perform the handover, i.e RRC CONNECTION RECONFIGURATION message including the mobilityControlInformation, to be sent by the source eNB towards the UE. The source eNB performs the necessary integrity protection and ciphering of the message. The UE receives the RRC CONNECTION RECONFIGURATION message with necessary parameters (i.e. new C-RNTI, target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and is commanded by the source eNB to perform the HO. The UE does not need to delay the handover execution for delivering the HARQ/ARQ responses to source eNB. ❾ The source eNB sends the X2AP SN STATUS TRANSFER message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status
575
Signalling in E-UTRAN / LTE
preservation applies (i.e. for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL SDU and may include a bit map of the receive status of the out of sequence UL SDUs that the UE needs to retransmit in the target cell, if there are any such SDUs. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new SDUs, not having a PDCP SN yet. The source eNB may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation. ❿ After receiving the RRC CONNECTION RECONFIGURATION message including the mobilityControlInformation , UE performs synchronisation to target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInformation, or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell. ⓫ The target eNB responds with UL allocation and timing advance. ⓬ When the UE has successfully accessed the target cell, the UE sends the RRC CONNECTION RECONFIGURATION COMPLETE message (C-RNTI) to confirm the handover, along with an uplink MAC Buffer Status Report, whenever possible, to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRC CONNECTION RECONFIGURATION COMPLETE message. The target eNB can now begin sending data to the UE. ⓭ The target eNB sends an S1AP PATH SWITCH REQUEST message to MME to inform that the UE has changed cell. ⓮ The MME sends an GTPv2-C MODIFY BEARER REQUEST message to the S-GW and the U-plane path is switched by the S-GW from the source eNB to the target eNB. ⓯ The S-GW switches the DL data path to the target side. The S-GW sends one or more GTPv1-U END MARKER packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB. ⓰ S-GW sends an GTPv2-C MODIFY BEARER RESPONSE message to MME. ⓱ The MME confirms the S1AP PATH SWITCH REQUEST message with the S1AP PATH SWITCH REQUEST ACKNOWLEDGE message. ⓲ By sending X2AP UE CONTEXT RELEASE, the target eNB informs success of HO to source eNB and triggers the release of resources by the 576
15 X2 interface
source eNB. The target eNB sends this message after the S1AP PATH SWITCH REQUEST ACKNOWLEDGE message is received from the MME. â“ł Upon reception of the X2AP UE CONTEXT RELEASE message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.
Path Switch After the downlink path is switched at the S-GW downlink packets on the forwarding path and on the new direct path may arrive interchanged at the target eNB. The target eNB should first deliver all forwarded packets to the UE before delivering any of the packets received on the new direct path. In order to assist the reordering function in the target eNB, the S-GW shall send one or more GTPv1-U END MARKER packets on the old path immediately after switching the path for each E-RAB of the UE. The GTPv1U END MARKER packet shall not contain user data. After completing the sending of the tagged packets the S-GW shall not send any further user data packets via the old path. Upon receiving the GTPv1-U END MARKER packets, the source eNB shall, if forwarding is activated for that bearer, forward the packet toward the target eNB. On detection of an GTPv1-U END MARKER packet the target eNB shall discard the end marker packet and initiate any necessary processing to maintain in sequence delivery of user data forwarded over X2 interface and user data received from the S-GW over S1 as a result of the path switch. GTPv1-U END MARKER
SN
SN
target
source
S-GW
SN
n+2 PDCP SN n+1 n Tx, Re-Tx
Figure 15-6 X2 handover (DL packet forwarding)
577
Signalling in E-UTRAN / LTE
On detection of the GTPv1-U END MARKER packet, the target eNB may also initiate the release of the data forwarding resource. However, the release of the data forwarding resource is implementation dependent and could also be based on other mechanisms (e.g. timer-based mechanism). EPC may change the uplink end-point of the tunnels with Path Switch procedure. However, the EPC should keep the old GTP tunnel end-point(s) sufficiently long time in order to minimise the probability of packet losses and avoid unintentional release of respective E-RAB(s).
Data forwarding for RLCRLC-AM DRBs Upon handover, the source eNB may forward in order to the target eNB all downlink PDCP SDUs with their SN that have not been acknowledged by the UE. In addition, the source eNB may also forward without a PDCP SN fresh data arriving over S1 to the target eNB. Target eNB does not have to wait for the completion of forwarding from the source eNB before it begins transmitting packets to the UE. The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB. Upon handover, the source eNB forwards to the S-GW the UL PDCP SDUs successfully received in-sequence until the sending of the X2AP SN STATUS TRANSFER message to the target eNB. Then at that point of time the source eNB stops delivering uplink PDCP SDUs to the S-GW and shall discard any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB. Then the source eNB shall either: •
discard the UL PDCP SDUs received out of sequence if the source eNB has not accepted the request from the target eNB for UL forwarding or if the target eNB has not requested UL forwarding for the bearer during the Handover Preparation procedure,
•
forward to the target eNB the UL PDCP SDUs received out of sequence if the source eNB has accepted the request from the target eNB for uplink forwarding for the bearer during the Handover Preparation procedure.
The PDCP SN of forwarded SDUs is carried in the ‘PDCP PDU number’ field of the GTP-U extension header. The target eNB shall use the PDCP SN if it is available in the forwarded GTP-U packet.
578
15 X2 interface
For normal HO in-sequence delivery of upper layer PDUs during handover is based on a continuous PDCP SN and is provided by the ‘in-order delivery and duplicate elimination’ function at the PDCP layer.
SN
target
source
S-GW
SN
SN Status Transfer (FMS=n+3, bitmap=1010x) n+6 n+5 n+4 n+3 n+2 n+1 n
n+3 n+5 n+7
PDCP Status Report (FMS=n+3, bitmap=1010x) PDCP SN Rx
Figure 15-7 X2 handover (UL packet forwarding accepted, RLC-AM)
n+6 n+5 n+4 n+3 n+2 n+1 n
SN Status Transfer (FMS=n+3)
PDCP SN Rx
PDCP Status Report (FMS=n+3)
target
source
S-GW
n+3 n+4 n+5 n+6 n+7
Figure 15-8 X2 handover (UL packet forwarding not accepted, RLC-AM)
Data forwarding for for RLCRLC-UM DRBs Upon handover, the source eNB does not forward to the target eNB downlink PDCP SDUs for which transmission had been completed in the source cell. PDCP SDUs that have not been transmitted may be forwarded. In addition, the source eNB may forward fresh downlink data arriving over S1 to the target eNB. The source eNB discards any remaining downlink RLC PDUs. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB. Upon handover, the source eNB forwards all uplink PDCP SDUs successfully received to the S-GW (i.e. including the ones received out of sequence) and
579
Signalling in E-UTRAN / LTE
discards any remaining uplink RLC PDUs. Correspondingly, the source eNB does not forward the uplink RLC context to the target eNB.
Handover Preparation This procedure is used to establish necessary resources in an eNB for an incoming handover. The procedure uses UE-associated signalling.
source
Old eNB UE X2AP ID, Cause (e.g. Handover Desirable for Radio Reasons), Target Cell ID (ECGI), GUMMEI, UE Context Information (MME UE S1AP ID, UE Security Capabilities, AS Security Information, UE AMBR), E-RABs To Be Setup List, RRC Context (RRC HO preparation information message), Handover Restriction List, UE History Information (Last Visited Cell List), SRVCC Operation Possible
target
Handover Request Handover Request Acknowledge Old eNB UE X2AP ID, New eNB UE X2AP ID, E-RABs Admitted List, E-RABs Not Admitted List, Target eNB To Source eNB Transparent Container (RRC E-UTRA Handover Command)
Figure 15-9 Handover preparation The source eNB initiates the procedure by sending the X2AP HANDOVER REQUEST message to the target eNB. The source eNB may include in the GUMMEI IE any GUMMEI corresponding to the source MME node. The target eNB reserves necessary resources, and send the X2AP HANDOVER REQUEST ACKNOWLEDGE message back to the source eNB. The target eNB includes the E-RABs for which resources have been prepared at the target cell in the E-RABs Admitted List IE and the E-RABs that have not been admitted in the E-RABs Not Admitted List IE with an appropriate cause value. The target eNB prepares configuration of the AS security relation between UE and target eNB using the information in UE Security Capabilities IE and the AS Security Information IE in the UE Context Information IE.
580
15 X2 interface
For each E-RAB for which the source eNB proposes to do forwarding of downlink data, the source eNB includes the DL Forwarding IE within the ERABs To be Setup Item IE of the X2AP HANDOVER REQUEST message. For each E-RAB that it has decided to admit, the target eNB may include the DL GTP Tunnel Endpoint IE within the E-RABs Admitted Item IE of the X2AP HANDOVER REQUEST ACKNOWLEDGE message to indicate that it accepts the proposed forwarding of downlink data for this bearer. For each bearer in the E-RABs Admitted List IE, the target eNB may include the UL GTP Tunnel Endpoint IE to indicate that it requests data forwarding of uplink packets to be performed for that bearer. S-GW GT e) P n Tu a lItem E-RABs To Be Setup P nn r el se Forwarding, UL GTP Tunnel (E-RAB ID, QoS,UDL (U Endpoint) ( se l e rP nn lan u source target T e) Handover Request P T G
Handover Request Acknowledge E-RABs Admitted Item (E-RAB ID, DL GTP Tunnel Endpoint , UL GTP Tunnel Endpoint) GTP Tunnel (User Plane) GTP Tunnel (User Plane)
Figure 15-10 DL/UL GTP Tunnel Endpoint If the target eNB does not admit at least one non-GBR E-RAB, or a failure occurs during the Handover Preparation, the target eNB send the X2AP HANDOVER PREPARATION FAILURE message to the source eNB.
SN Status Transfer 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 for each respective E-RAB for which PDCP SN and HFN status preservation applies. The procedure uses UE-associated signalling.
581
Signalling in E-UTRAN / LTE
source
Old eNB UE X2AP ID, new eNB UE X2AP ID E-RABs Subject To Status Transfer List (E-RAB ID, Receive Status Of UL PDCP SDUs, UL COUNT Value, DL COUNT Value)
target
SN Status Transfer Figure 15-11 SN Status Transfer The source eNB initiates the procedure by stop assigning PDCP SNs to downlink SDUs and stop delivering UL SDUs towards the EPC and sending the X2AP SN STATUS TRANSFER message to the target eNB at the time point when it considers the transmitter/receiver status to be frozen. The E-RABs Subject To Status Transfer List IE included in the X2AP SN STATUS TRANSFER message contains the E-RAB ID(s) corresponding to the E-RAB(s) for which PDCP SN and HFN status preservation shall be applied. If the source eNB includes in the X2AP SN STATUS TRANSFER message, the information on the missing and received uplink SDUs in the Receive Status Of UL PDCP SDUs IE for each E-RAB for which the source eNB has accepted the request from the target eNB for uplink forwarding, then the target eNB may use it in a SNDCP STATUS REPORT message sent to the UE over the radio. For each E-RAB for which the DL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall use it to mark with the value contained in the PDCP-SN IE of this IE the first downlink packet for which there is no PDCP SN yet assigned. For each E-RAB for which the UL COUNT Value IE is received in the SN STATUS TRANSFER message, the target eNB shall not deliver any uplink packet which has a PDCP SN lower than the value contained in the PDCP-SN IE of this IE.
UE Context Release The UE Context Release procedure is initiated by the target eNB to signal to indicate the source eNB that radio and control plane resources for the handed over UE context are allowed to be released. The procedure uses UE-associated signalling.
582
15 X2 interface
source
target
Old eNB UE X2AP ID, new eNB UE X2AP ID
UE Context Release Figure 15-12 UE Context Release The UE Context Release procedure is initiated by the target eNB. By sending the X2AP UE CONTEXT RELEASE message the target eNB informs the source eNB of handover success and triggers the release of resources. Upon reception of the X2AP UE CONTEXT RELEASE message, the source eNB may release radio and control plane related resources associated to the UE context. For E-RABs for which data forwarding has been performed, the source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent mechanism decides that data forwarding can be stopped).
Handover Cancel The Handover Cancel procedure is used to enable a source eNB to cancel an ongoing handover preparation or an already prepared handover. The procedure uses UE-associated signalling. source
target
Old eNB UE X2AP ID, New eNB UE X2AP ID, Cause
Handover cancel Figure 15-13 Handover cancel The source eNB initiates the procedure by sending the X2AP HANDOVER CANCEL message to the target eNB. The source eNB shall indicate the reason for cancelling the handover by means of an appropriate cause value. At the reception of the X2AP HANDOVER CANCEL message, the target eNB shall remove any reference to, and release any resources previously reserved to the concerned UE context.
583
Signalling in E-UTRAN / LTE
Load indication The purpose of the Load Indication procedure is to transfer load and interference co-ordination information between eNBs controlling intra-frequency neighbouring cells. The procedure uses non UE-associated signalling. Cell Information Item (Cell ID, UL Interference Overload Indication, UL High Interference Information (Target Cell ID, UL High Interference Indication), Relative Narrowband Tx Power (RNTP Per PRB, RNTP Threshold , Number Of Cell-specific Antenna Ports, P_B, PDCCH Interference Impact))
Load indication Figure 15-14 Load indication An eNB initiates the procedure by sending X2AP LOAD INFORMATION message to eNBs controlling intra-frequency neighbouring cells. If the UL Interference Overload Indication IE is received in the X2AP LOAD INFORMATION message, it indicates the interference level experienced by the indicated cell on all resource blocks, per PRB. 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 X2AP LOAD INFORMATION message carrying an update of the same IE. I HIGH MED LOW PRB 0
f
PRB 0
ECGI=n
Load indication (Cell ID=n, UL Interference Overload Indication= low, high, high, medium, medium, medium, low, low)
Figure 15-15 UL Interference Overload Indication IE
584
f
15 X2 interface
0 - LOW
0 - LOW
0 - LOW
0 - LOW
0 - LOW
1 - HIGH
0 - LOW
1 - HIGH
If the UL High Interference Indication IE is received in the X2 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 X2AP 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 X2AP LOAD INFORMATION message carrying an update.
f
PRB 0
ECGI=m
ECGI=n
Load indication (Cell ID=n, Target Cell ID=m, UL High Interference Indication= 01100000x)
Figure 15-16 UL High Interference (sensitivity) Indication IE If the Relative Narrowband Tx Power (RNTP) IE is received in the X2AP LOAD INFORMATION message, it indicates, per PRB, whether downlink transmission power is lower than the value indicated by the RNTP 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 X2AP LOAD INFORMATION message carrying an update.
585
Signalling in E-UTRAN / LTE
P
1
1 RNTP Threshold 0
0
0
0
0
PRB 0
0
f
ECGI=m
ECGI=n
Load indication (Cell ID=n, Target Cell ID=m, RNTP Threshold, RNTP per PBR = 01100000x)
Figure 15-17 Relative Narrowband Tx Power (RNTP) IE
Error Indication 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.
Old eNB UE X2AP ID, New eNB UE X2AP ID, Cause, Criticality Diagnostics
Error indication Figure 15-18 Error indication The X2AP ERROR INDICATION message contains at least either the Cause IE or the Criticality Diagnostics IE. In case the Error Indication procedure is triggered by UE associated signalling the Old eNB UE X2AP ID IE and New eNB UE X2AP ID IE are included in the X2AP ERROR INDICATION message.
586
15 X2 interface
X2 Setup 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. The procedure uses non UE-associated signalling. Global eNB ID, Served Cells
(PCI, Cell ID=ECGI, TAC, Broadcast PLMNs, FDD info (UL/DL EARFCN, UL/DL Tx Bandwidth, TDD info (EARFCN, Tx Bandwidth, Subframe Assign.), Number of Antenna Ports, PRACH Configuration), Neighbour Information (ECGI, PCI, EARFCN), GU Group Id List (PLMN Id, MME Group Id)
X2 Setup request X2 Setup response Figure 15-19 X2 Setup An eNB initiates the procedure by sending the X2AP X2 SETUP REQUEST message to a candidate eNB. The candidate eNB replies with the X2AP X2 SETUP RESPONSE message. The initiating eNB transfers a list of served cells and, if available, a list of supported GU Group Ids to the candidate eNB. The candidate eNB replies with a list of its served cells and includes, if available, a list of supported GU Group Ids in the reply.
Reset The purpose of the Reset procedure is to align the resources in eNB1 and eNB2 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 the X2 Setup procedure. The procedure uses non UE-associated signalling.
587
Signalling in E-UTRAN / LTE
eNB1
cause
eNB2
Reset request Reset response Figure 15-20 Reset The procedure is initiated with a X2AP RESET REQUEST message sent from the eNB1 to the eNB2. Upon receipt of this message, eNB2 aborts any other ongoing procedures over X2 between eNB1 and eNB2. The eNB2 deletes all the context information related to the eNB1, 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 eNB2 responds with a X2AP RESET RESPONSE message.
eNB Configuration Update 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. The procedure uses non UE-associated signalling.
eNB1
Served Cells To Add/Modify/Delete, GU Group Id To Add/Delete List
eNB2
eNB configuration update eNB configuration update ack. Figure 15-21 eNB Configuration Update An eNB1 initiates the procedure by sending an X2AP ENB CONFIGURATION UPDATE message to a peer eNB2 including an appropriate set of updated configuration data that it has just taken into operational use. After successful update of requested information, eNB2 replies with the X2AP ENB CONFIGURATION UPDATE ACKNOWLEDGE message to inform the initiating eNB1 that the requested update of application data was performed successfully. 588
15 X2 interface
Resource Status Reporting The Resource Status Reporting procedure is used to report the result of measurements requested by the neighbour eNB.
Initiation
eNB1
eNB1 Measurement ID, eNB2 Measurement ID, Registration Request (start/stop), Report Characteristics (PRB Periodic, TNL load Ind Periodic, HW Load Ind Periodic, Composite Available Capacity Periodic), Cell To Report (ECGIs), Reporting Periodicity (1, 2, 5, 10s)
eNB2
Resource status request Resource status response eNB1 Measurement ID, eNB2 Measurement ID,
Figure 15-22 Resource Status Reporting initiation ❶ The procedure is initiated with a X2AP RESOURCE STATUS REQUEST message sent from eNB1 to eNB2. Upon receipt, eNB2 initiates the requested measurement according to the parameters given in the request in case the Registration Request IE set to ‘start’ and terminates the reporting in case the Registration Request IE is set to ‘stop’. If the Registration Request IE is set to ‘start’ then the Report Characteristics IE is included in X2AP RESOURCE STATUS REQUEST message. The Report Characteristics IE indicates the type of measurements eNB2 shall perform. If the Reporting Periodicity IE is included in the X2AP RESOURCE STATUS REQUEST message, eNB2 uses its value as the time interval between two subsequent measurement reports. ❷ If eNB2 is capable to provide resource status information, it initiates the measurements as requested by eNB1, and respond with the X2AP RESOURCE STATUS RESPONSE message. 589
Signalling in E-UTRAN / LTE
If the requested measurement cannot be initiated, eNB2 sends an X2AP RESOURCE STATUS FAILURE message.
Reporting The eNB2 reports the results of the measurements in X2AP RESOURCE STATUS UPDATE message for each requested cell. eNB1
eNB2
Resource status update eNB1 Measurement ID, eNB2 Measurement ID, Cell Measurement Result (cell ID, DL/UL Hardware Load Indicator (low, medium, high, overload), DL/UL S1 TNL Load Indicator, (low, medium, high, overload), Radio Resource Status (DL/UL GBR PRB usage, DL/UL non-GBR PRB usage, DL/UL Total PRB usage), Composite Available Capacity Group (Cell Capacity Class Value (1-100%), Capacity Value (1-100%)))
Figure 15-23 Resource Status Reporting
Mobility Settings Change This procedure enables an eNB to negotiate the handover trigger settings with a peer eNB controlling neighbouring cells. The procedure uses non UEassociated signalling.
eNB1
eNB1 Cell ID, eNB2 Cell ID, eNB1 Mobility Parameters (Handover Trigger Change = -20..20 [0,5 dB]), eNB2 Proposed Mobility Parameters (Handover Trigger Change = -20..20 [0,5 dB]), Cause
Mobility change request Mobility change acknowledged Figure 15-24 Mobility Settings Change 590
eNB2
15 X2 interface
â?ś The procedure is initiated with an X2AP MOBILITY CHANGE REQUEST message sent from eNB1 to eNB2. The eNB1 Mobility Parameters IE describes configuration change in eNB1 cell. The eNB2 Proposed Mobility Parameters IE describes proposed configuration change in eNB2 cell. These IEs contains the change of the Handover Trigger as compared to its current value. The Handover Trigger corresponds to the threshold at which a cell initialises the handover preparation procedure towards a specific neighbour cell. Positive value of the change means the handover is proposed to take place later. â?ˇ Upon receipt, eNB2 evaluates if the proposed eNB2 handover trigger modification may be accepted. If eNB2 is able to successfully complete the request it replies with X2AP MOBILITY CHANGE ACKNOWLEDGE. If the requested parameter modification is refused by the eNB2 , or if the eNB2 is not able to complete the procedure, the eNB2 sends an X2AP MOBILITY CHANGE FAILURE message with the Cause IE set to an appropriate value. The eNB2 may include eNB2 Mobility Parameters Modification Range IE in X2AP MOBILITY CHANGE FAILURE message, for example in cases when the proposed change is out of permitted range. eNB2
eNB1
Mobility change request Mobility change failure eNB1 Cell ID, eNB2 Cell ID, Cause, eNB2 Mobility Parameters Modification Range (Handover Trigger Change Lower Limit, Handover Trigger Change Upper Limit) Figure 15-25 Mobility Settings Change (unsuccessful operation)
591
Signalling in E-UTRAN / LTE
Radio Link Failure Indication The purpose of the Radio Link Failure Indication procedure is to enable mobility robustness improvement in E-UTRAN by passing information connected to a re-establishment request over the X2 interface. When a re-establishment event occurs, the eNB uses the PCI provided by the UE to identify the potentially previous serving cell/eNB. The eNB that received the re-establishment request then sends an X2AP RLF INDICATION message containing identification of the UE to the concerned eNB(s). The previously serving eNB may then match the correct context, and analyze the possible root cause of the radio link failure which preceded the re-establishment request. Failure cell PCI, Re-establishment cell ECGI, C-RNTI ShortMAC-I UE RLF Report Container (RLF-Report (measResultLastServCell (rsrpResult, rsrqResult))) eNB2
eNB1
RLF indication Connection re-establishment req. (PCI, C-RNTI, ShortMAC-I)
UE Info Rsp (RLF-Report)
Figure 15-26 Radio Link Failure Indication eNB2 initiates the procedure by sending the X2AP RLF INDICATION message to eNB1 following a re-establishment attempt from a UE at eNB2, when eNB2 considers that the UE may have previously been served by a cell controlled by eNB1. eNB2 may include the ShortMAC-I IE in the X2AP RLF INDICATION message, which aids the eNB1 to resolve a potential PCI confusion situation. eNB2 may include the UE RLF Report Container IE in the X2AP RLF INDICATION message, which may be used by the eNB1 to determine the nature of the failure.
592
15 X2 interface
Handover Report The purpose of the Handover Report procedure is to enable mobility robustness improvement in E-UTRAN by passing information connected to the analysis of an RLF which occurred shortly after a successful handover. The procedure uses non UE-associated signalling. eNB2
eNB1
Handover report Handover Report Type (HO too early, HO to wrong cell ) Handover Cause Source cell ECGI Failure cell ECGI Re-establishment cell ECGI
Figure 15-27 Handover Report An eNB initiates the procedure by sending an X2AP HANDOVER REPORT message to another eNB controlling neighbouring cells. By sending the message eNB1 indicates to eNB2 that, following a successful handover from a cell of eNB2 to a cell of eNB1, a radio link failure occurred and the UE attempted RRC Re-establishment either at the original cell of eNB2 (Handover Too Early), or at another cell (Handover to Wrong Cell).
Handover preparation eNB1 Connection reconf. cmp. RLF
Connection reconf. (HO)
eNB2
Re-establishment
RLF indication Handover report (HO too early)
Figure 15-28 Handover Too Early scenario
593
Signalling in E-UTRAN / LTE
Handover preparation eNB1
Connection reconf. cmp.
Connection reconf. (HO)
RLF
eNB2
Re-establishment
Handover report (HO to Wrong Cell) Figure 15-29 Handover to Wrong Cell scenario 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 Reestablishment cell ECGI IE is included in the HANDOVER REPORT message.
594