X2 is the name of the interface that connects one eNB to another eNB as indicated in the illustration below. You can guess there will be a lot of information or messages running along this interface (basically connection line). As you know, almost any data/message exchange you would need some type of protocol. In real network, there are cases where multiple eNB from different vendor are connected. For those eNBs from multiple vendors to properly communicate each other, they would need some common communication protocol. This protocol for communication along X2 interface is called X2AP (X2 Application Protocol). Also you would know from experience, there are some speciall hardware or software or application at each end of any communication. These application that sits at the end of X2 interface (basically within eNB) is called X2AP Service.
Let's follow X2 in the order an eNB meets it. First the eNB has to find its neighbours and set up the X2 link. Then the link carries two kinds of information. One is handover signalling for a UE that moves between cells. The other is load and interference information about the cells themselves. The sections below take them in that order, and each one quotes the ASN.1 of its messages from 36.423.
In the illustration above, eNB 1, eNB 2 and eNB 3 are connected to each other by X2 links. Each eNB also connects to both MME 1 and MME 2 over S1. The X2AP Service sits inside eNB 2, at the end of its X2 links, and it speaks the X2 Application Protocol to its peers.
X2AP has many different functions as summarized below and the main contents of this page is go through each of these functions. (This list came from 3GPP 36.423).
The picture above shows the functions of an early release of 36.423. The current version, v19.1.0, keeps all of them in Table 7-1 and adds more. The picture writes Resource Status Reporting Indication, but the procedure name in the specification is Resource Status Reporting Initiation. The functions added since then are the following.
- Dual Connectivity, where one eNB provides extra radio resources to a UE that another eNB still controls
- E-UTRA-NR Dual Connectivity, the same idea between an eNB and an en-gNB
- X2 Release, Message Transfer and Registration, and Removing the X2, which manage the X2 connection itself
- Inter-eNB UE Context Retrieval, used when a UE resumes or re-establishes its RRC connection in another eNB
- Secondary RAT Data Usage Report, E-UTRA - NR Spectrum Sharing, EN-DC Configuration Transfer and UE Radio Capability ID Mapping
Mobility Management also gained Handover Success and Conditional Handover Cancel. Mobility Robustness Optimisation gained SCG Failure Information Report and SCG Failure Transfer. The sections below cover the original LTE core of X2 and the later EN-DC procedures.
- What are the most common information carried over X2 ?
- Who Uses X2 ?
- X2 Protocol Stacks
- X2AP Signaling Messages
- How to setup an X2 between one eNB and another eNB ?
- When Does X2 Setup Happen ?
- How mobility works ?
- How EN-DC SgNB Addition Works ?
- Communication over X2 for Load/Interference Information
- Other X2 Procedures
- X2-C ASN for Mobility and EN-DC
- Reference
What are the most common information carried over X2 ?
Following informations would be the most common type of information that are being exchanged between one eNB and another eNB over X2 interface. The two kinds differ in what they are about. Handover information concerns one UE, so it uses UE-associated signalling. Load and interference information concerns a cell, so it uses non UE-associated signalling.
- Handover related Information
- load or interference related information
Each kind maps to a small set of 36.423 procedures. Handover information travels in Handover Preparation, SN Status Transfer and UE Context Release. Load and interference information travels in Load Indication, and in the Resource Status Reporting Initiation and Resource Status Reporting pair. The sections How mobility works ? and Communication over X2 for Load/Interference Information take each group in turn.
Both kinds need one thing first. An eNB has to know which cells sit behind the other end of the link. X2 Setup provides that, because each side sends its complete list of served cells. The list gives the PCI, the ECGI, the TAC and the EARFCN of each cell. Later releases added more traffic to the same interface. Release 12 added dual connectivity between two eNBs, and Release 15 added EN-DC between an eNB and an en-gNB.
UE-associated signalling needs a way to name the UE on the link, and X2AP uses a pair of IDs for that. The source eNB allocates the Old eNB UE X2AP ID and sends it in HANDOVER REQUEST. The target eNB allocates the New eNB UE X2AP ID and returns it in HANDOVER REQUEST ACKNOWLEDGE. Each ID is an INTEGER from 0 to 4095, and it identifies the UE over X2 only within the eNB that allocated it.
Two kinds of information use two kinds of signalling : handover messages identify the UE by its X2AP IDs, while load messages identify the cell by its ECGI.X2 Setup comes before everything else : the first message on a new TNL association must be X2 SETUP REQUEST, X2 SETUP RESPONSE or X2 SETUP FAILURE. Anything else is a logical error.X2 is no longer LTE only : the same interface now carries dual connectivity and EN-DC signalling.
Who Uses X2 ?
The endpoints matter more than the word X2 alone. In ordinary LTE mobility, two eNBs use X2 to prepare a UE handover or exchange cell-level information. In EN-DC, an LTE eNB and an en-gNB also use X2, but their task is to coordinate the NR secondary node while EPC remains the core network.
An eNB can manage several LTE cells. X2 Setup sends a list of those cells, not just one PCI. A UE can therefore move between cells of one eNB without an inter-eNB X2 exchange, or move to a cell of another eNB with X2-based handover. The node boundary, not the mere change of cell, decides whether two X2 peers are involved.
| Arrangement | X2 peers | What the exchange does |
|---|---|---|
| LTE to LTE, EPC | Source eNB and target eNB | Prepares inter-eNB handover, transfers PDCP status, and exchanges load or configuration information. |
| EN-DC, EPC | LTE master eNB and NR secondary en-gNB | Adds, modifies, or releases the NR secondary node for a UE through X2-C. |
| NGEN-DC, 5GC | ng-eNB and gNB | Uses Xn-C, not X2-C. Its S-NODE messages are a different protocol family. |
The same physical equipment may implement several logical roles, but a trace still has one interface for each procedure. Do not read an EN-DC SGNB ADDITION REQUEST as an XnAP message. Its X2AP peer is an en-gNB. Conversely, an Xn-C S-NODE ADDITION REQUEST belongs to NG-RAN connected to the 5G Core.
LTE handover crosses two eNBs : X2-C prepares the target only when the UE crosses the eNB boundary.EN-DC also uses X2 : the LTE master and NR secondary node use X2AP SgNB procedures, not XnAP.
X2 Protocol Stacks
What carries an X2AP message, and what carries a forwarded user packet? The two flows share an IP transport network, but they use different upper layers. Figure 1 separates the control plane from the user plane so a packet trace can be read without mixing the two.
Figure 1. X2AP belongs to X2-C over SCTP; forwarded user packets use X2-U over GTP-U and UDP.
X2AP defines messages such as HANDOVER REQUEST, X2 SETUP REQUEST and LOAD INFORMATION. SCTP carries those messages between the peer nodes and provides ordered, reliable signalling transport. X2-U does not carry X2AP ASN.1. It carries GTP-U packets, for example when the source eNB forwards downlink data during handover.
Do not confuse X2-U forwarding with the normal core-network user plane. S1-U connects an eNB toward the S-GW. X2-U connects the source and target RAN nodes for forwarding during a mobility or dual-connectivity procedure. After a handover path switch, new downlink data goes directly toward the target over S1-U; any old forwarded packets may still be arriving over X2-U.
In a trace, first identify the SCTP association and the GTP-U tunnel endpoints. They show which messages control the procedure and which packets merely carry forwarded traffic.
Decode SCTP as X2-C : its payload is X2AP control signalling between peers.Decode GTP-U as X2-U : its payload is forwarded user data, not an X2AP message.
X2AP Signaling Messages
X2AP has more procedures than a handover trace normally shows. The table below groups the messages a reader is most likely to meet. Class 1 procedures define a successful response or a failure outcome. Class 2 procedures send an initiating message without a response message in that procedure.
| Use case | Initiating message | Outcome or next message | What to check |
|---|---|---|---|
| Inter-eNB handover | HANDOVER REQUEST | HANDOVER REQUEST ACKNOWLEDGE or HANDOVER PREPARATION FAILURE | Target cell, UE context, admitted E-RABs, target RRC container. |
| Handover execution | SN STATUS TRANSFER | UE CONTEXT RELEASE after path switch | PDCP COUNT values and release of the old UE context; these are separate Class 2 procedures. |
| Peer setup | X2 SETUP REQUEST | X2 SETUP RESPONSE or X2 SETUP FAILURE | Global eNB ID, complete served-cell list, GU Group IDs. |
| Peer configuration | ENB CONFIGURATION UPDATE | ACKNOWLEDGE or FAILURE | Cells added, modified or deleted after setup. |
| Load and interference | LOAD INFORMATION | No response | Cell ID, uplink interference, RNTP or ABS information. |
| Resource measurements | RESOURCE STATUS REQUEST | RESOURCE STATUS RESPONSE or FAILURE; later RESOURCE STATUS UPDATE | Measurement ID, reporting characteristics, cell results. |
| EN-DC addition | SGNB ADDITION REQUEST | SGNB ADDITION REQUEST ACKNOWLEDGE or REJECT | MeNB/SgNB UE IDs, NR security, requested E-RABs and NR RRC container. |
| EN-DC modification | SGNB MODIFICATION REQUEST or SGNB MODIFICATION REQUIRED | ACKNOWLEDGE/REJECT or CONFIRM/REFUSE | Which node initiated the change and which NR radio configuration is relayed. |
| EN-DC peer setup | EN-DC X2 SETUP REQUEST | EN-DC X2 SETUP RESPONSE or FAILURE | LTE and NR served-cell information for the eNB and en-gNB peers. |
| Error recovery | RESET REQUEST | RESET RESPONSE | UE contexts to clear while stored peer configuration remains. |
The same word REQUEST appears in many rows, so check the procedure and endpoint before interpreting a trace. An inter-eNB HANDOVER REQUEST is not an EN-DC SGNB ADDITION REQUEST. Likewise, RESOURCE STATUS UPDATE is not the response to RESOURCE STATUS REQUEST; RESOURCE STATUS RESPONSE is the response, and UPDATE supplies later measurements.
Read the outcome column first : it separates Class 1 handshakes from one-way Class 2 reports.Keep the UE and cell cases separate : handover and SgNB procedures address a UE; setup and load procedures describe peer nodes or cells.
How to setup an X2 between one eNB and another eNB ?
In order for a eNB to make a connection to another eNB, first it has to know which eNBs located around itself. How an eNB knows the information about other eNBs around it ?
There are roughly two types of methods being used for this as listed below.
- By predefined configuration
- By Automatic Neighbor Relation Function (ANRF)
In ANRF, eNB uses UEs which are connected to it in order to find neighbouring eNBs. It can instruct UE to read the global cell identity (CGI) of neighbouing eNB and report them to the serving eNB. Actually ANRF can be a good example of SON (Self Organizing Network).
Once a eNB find neighbouring eNBs and decided to which one it want to connect, it finds the IP address of the destination eNB and establish TNL (Transport Network Layer). Then you may ask "How an eNB can figure out the IP of a neighbouring eNB ?". Also.. here you can think of roughly two methods.
- By predefined configuration
- By some kind of automatic method. For example, it can query the IP over S1 interface.
The automatic method in the second bullet is defined in S1AP, TS 36.413. The eNB sends an eNB CONFIGURATION TRANSFER message to the MME. Its SON Information Request asks for the X2 TNL Configuration Info of the target eNB. The MME forwards the request to the target eNB in an MME CONFIGURATION TRANSFER message. The target eNB answers along the same path, and its SON Information Reply carries the X2 TNL Configuration Info with its transport layer addresses. The requesting eNB can then set up the TNL and start X2 Setup.
Once a TNL between two eNBs are established, the eNB send X2 SETUP REQUEST message to the other eNB and the other eNB respond with X2 SETUP RESPONSE message as shown below.
< 36.423 Figure 8.3.3.2-1: X2 Setup, successful operation >
The diagram above has only two messages, but the rules around them matter. First, eNB1 sends the complete list of its served cells and, if available, its GU Group IDs. In return, eNB2 sends its own complete list. A cell that is switched off for energy saving is activated first, and it still appears in the list. The procedure also erases any existing application level configuration data in both nodes. It resets the X2 interface as a Reset procedure would. If eNB2 cannot accept the setup, it answers with X2 SETUP FAILURE instead. That message may carry a Time To Wait, and eNB1 then waits at least that long before it tries again.
What kind of information is carried by X2 Setup Request message ? Some important information carried by this message are as follows (The other party would send similar information via X2 Setup Response message) :
- Physical Cell IDs for the cell it manages
- Frequency Band
- Tracking Area Identity and/or the associated PLMN
- Neighbour Information (Optional)
- Number of Antenna Ports (Optional)
- PRACH Configuration (Optional)
- MBSFN Subframe Info (Optional)
- CSG ID (mandatory if the eNB is CSG Cell or Hybrid Cell)
- MultibandInfoList (Optional)
Most of the items above are not at the top level of the listing below. PCI, ECGI and TAC sit in ServedCell-Information, and the EARFCN sits in the EUTRA-Mode-Info it carries. Number of Antenna Ports, PRACH Configuration, MBSFN Subframe Info, CSG ID and MultibandInfoList are extensions in ServedCell-Information-ExtIEs. The CSG ID is optional in the ASN.1. Even so, the procedure text requires it for each CSG cell or hybrid cell.
X2 SETUP REQUEST
The listing below goes from the message down to the cell details. X2SetupRequest-IEs holds only four IEs, and the served cell details sit two levels deeper. Compared with the original listing on this page, the latest release adds three things here. ENB-ID gained short-Macro-eNB-ID of 18 bits and long-Macro-eNB-ID of 21 bits after its extension marker. The message gained the optional LHN-ID. ServedCell-Information-ExtIEs, now added to the listing, holds twelve extensions.
Following is based on
X2SetupRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{X2SetupRequest-IEs}},
...
}
X2SetupRequest-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-GlobalENB-ID CRITICALITY reject TYPE GlobalENB-ID PRESENCE mandatory}|
{ ID id-ServedCells CRITICALITY reject TYPE ServedCells PRESENCE mandatory}|
{ ID id-GUGroupIDList CRITICALITY reject TYPE GUGroupIDList PRESENCE optional}|
{ ID id-LHN-ID CRITICALITY ignore TYPE LHN-ID PRESENCE optional},
...
}
GlobalENB-ID ::= SEQUENCE {
pLMN-Identity PLMN-Identity,
eNB-ID ENB-ID,
iE-Extensions ProtocolExtensionContainer { {GlobalENB-ID-ExtIEs} } OPTIONAL,
...
}
ENB-ID ::= CHOICE {
macro-eNB-ID BIT STRING (SIZE (20)),
home-eNB-ID BIT STRING (SIZE (28)),
... ,
short-Macro-eNB-ID BIT STRING (SIZE(18)),
long-Macro-eNB-ID BIT STRING (SIZE(21))
}
ServedCells ::= SEQUENCE (SIZE (1.. maxCellineNB)) OF SEQUENCE {
servedCellInfo ServedCell-Information,
neighbour-Info Neighbour-Information OPTIONAL,
iE-Extensions ProtocolExtensionContainer { {ServedCell-ExtIEs} } OPTIONAL,
...
}
ServedCell-ExtIEs X2AP-PROTOCOL-EXTENSION ::= {
{ ID id-NRNeighbourInfoToAdd CRITICALITY ignore EXTENSION NRNeighbour-Information PRESENCE optional }|
{ ID id-ServedCellSpecificInfoReq-NR CRITICALITY ignore EXTENSION ServedCellSpecificInfoReq-NR PRESENCE optional },
...
}
ServedCell-Information ::= SEQUENCE {
pCI PCI,
cellId ECGI,
tAC TAC,
broadcastPLMNs BroadcastPLMNs-Item,
eUTRA-Mode-Info EUTRA-Mode-Info,
iE-Extensions ProtocolExtensionContainer { {ServedCell-Information-ExtIEs} } OPTIONAL,
...
}
ServedCell-Information-ExtIEs X2AP-PROTOCOL-EXTENSION ::= {
{ ID id-Number-of-Antennaports CRITICALITY ignore EXTENSION Number-of-Antennaports PRESENCE optional}|
{ ID id-PRACH-Configuration CRITICALITY ignore EXTENSION PRACH-Configuration PRESENCE optional}|
{ ID id-MBSFN-Subframe-Info CRITICALITY ignore EXTENSION MBSFN-Subframe-Infolist PRESENCE optional}|
{ ID id-CSG-Id CRITICALITY ignore EXTENSION CSG-Id PRESENCE optional}|
{ ID id-MBMS-Service-Area-List CRITICALITY ignore EXTENSION MBMS-Service-Area-Identity-List PRESENCE optional}|
{ ID id-MultibandInfoList CRITICALITY ignore EXTENSION MultibandInfoList PRESENCE optional}|
{ ID id-FreqBandIndicatorPriority CRITICALITY ignore EXTENSION FreqBandIndicatorPriority PRESENCE optional}|
{ ID id-BandwidthReducedSI CRITICALITY ignore EXTENSION BandwidthReducedSI PRESENCE optional}|
{ ID id-ProtectedEUTRAResourceIndication CRITICALITY ignore EXTENSION ProtectedEUTRAResourceIndication PRESENCE optional}|
{ ID id-BPLMN-ID-Info-EUTRA CRITICALITY ignore EXTENSION BPLMN-ID-Info-EUTRA PRESENCE optional}|
{ ID id-NPRACHConfiguration CRITICALITY ignore EXTENSION NPRACHConfiguration PRESENCE optional}|
{ ID id-SFN-Offset CRITICALITY ignore EXTENSION SFN-Offset PRESENCE optional},
...
}
Neighbour-Information ::= SEQUENCE (SIZE (0..maxnoofNeighbours)) OF SEQUENCE {
eCGI ECGI,
pCI PCI,
eARFCN EARFCN,
iE-Extensions ProtocolExtensionContainer { {Neighbour-Information-ExtIEs} } OPTIONAL,
...
}
Neighbour-Information-ExtIEs X2AP-PROTOCOL-EXTENSION ::= {
{ ID id-NeighbourTAC CRITICALITY ignore EXTENSION TAC PRESENCE optional}|
{ ID id-eARFCNExtension CRITICALITY reject EXTENSION EARFCNExtension PRESENCE optional},
...
}
GUGroupIDList ::= SEQUENCE (SIZE (1..maxPools)) OF GU-Group-ID
GU-Group-ID ::= SEQUENCE {
pLMN-Identity PLMN-Identity,
mME-Group-ID MME-Group-ID,
iE-Extensions ProtocolExtensionContainer { {GU-Group-ID-ExtIEs} } OPTIONAL,
...
}
The procedure text in 36.423 8.3.3.2 gives the purpose of several newer extensions. BandwidthReducedSI helps the receiving eNB choose a target for BL UEs or UEs in CE. NPRACHConfiguration carries the NB-IoT random access setup, which the peer may use for RACH optimisation. Neighbour-Information-ExtIEs can now carry the TAC of each neighbour. ServedCell-ExtIEs adds NR neighbour information, limited to NR cells that can do EN-DC with the served E-UTRA cell.
X2 SETUP RESPONSE
The response mirrors the request. In it, eNB2 sends its own GlobalENB-ID and its complete served cell list, so after one exchange each end knows the cells of the other. The response adds one IE that the request does not have. CriticalityDiagnostics reports IEs that eNB2 did not comprehend or found missing in the request.
Following is based on
X2SetupResponse ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{X2SetupResponse-IEs}},
...
}
X2SetupResponse-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-GlobalENB-ID CRITICALITY reject TYPE GlobalENB-ID PRESENCE mandatory}|
{ ID id-ServedCells CRITICALITY reject TYPE ServedCells PRESENCE mandatory}|
{ ID id-GUGroupIDList CRITICALITY reject TYPE GUGroupIDList PRESENCE optional}|
{ ID id-CriticalityDiagnostics CRITICALITY ignore TYPE CriticalityDiagnostics PRESENCE optional}|
{ ID id-LHN-ID CRITICALITY ignore TYPE LHN-ID PRESENCE optional},
...
}
CriticalityDiagnostics ::= SEQUENCE {
procedureCode ProcedureCode OPTIONAL,
triggeringMessage TriggeringMessage OPTIONAL,
procedureCriticality Criticality OPTIONAL,
iEsCriticalityDiagnostics CriticalityDiagnostics-IE-List OPTIONAL,
iE-Extensions ProtocolExtensionContainer { {CriticalityDiagnostics-ExtIEs} } OPTIONAL,
...
}
ProcedureCode ::= INTEGER (0..255)
id-handoverPreparation ProcedureCode ::= 0
id-handoverCancel ProcedureCode ::= 1
id-loadIndication ProcedureCode ::= 2
id-errorIndication ProcedureCode ::= 3
id-snStatusTransfer ProcedureCode ::= 4
id-uEContextRelease ProcedureCode ::= 5
id-x2Setup ProcedureCode ::= 6
id-reset ProcedureCode ::= 7
id-eNBConfigurationUpdate ProcedureCode ::= 8
id-resourceStatusReportingInitiation ProcedureCode ::= 9
id-resourceStatusReporting ProcedureCode ::= 10
id-privateMessage ProcedureCode ::= 11
id-mobilitySettingsChange ProcedureCode ::= 12
id-rLFIndication ProcedureCode ::= 13
id-handoverReport ProcedureCode ::= 14
id-cellActivation ProcedureCode ::= 15
id-x2Release ProcedureCode ::= 16
id-x2APMessageTransfer ProcedureCode ::= 17
id-x2Removal ProcedureCode ::= 18
id-seNBAdditionPreparation ProcedureCode ::= 19
id-seNBReconfigurationCompletion ProcedureCode ::= 20
id-meNBinitiatedSeNBModificationPreparation ProcedureCode ::= 21
id-seNBinitiatedSeNBModification ProcedureCode ::= 22
id-meNBinitiatedSeNBRelease ProcedureCode ::= 23
id-seNBinitiatedSeNBRelease ProcedureCode ::= 24
id-seNBCounterCheck ProcedureCode ::= 25
id-retrieveUEContext ProcedureCode ::= 26
id-sgNBAdditionPreparation ProcedureCode ::= 27
id-sgNBReconfigurationCompletion ProcedureCode ::= 28
id-meNBinitiatedSgNBModificationPreparation ProcedureCode ::= 29
id-sgNBinitiatedSgNBModification ProcedureCode ::= 30
id-meNBinitiatedSgNBRelease ProcedureCode ::= 31
id-sgNBinitiatedSgNBRelease ProcedureCode ::= 32
id-sgNBCounterCheck ProcedureCode ::= 33
id-sgNBChange ProcedureCode ::= 34
id-rRCTransfer ProcedureCode ::= 35
id-endcX2Setup ProcedureCode ::= 36
id-endcConfigurationUpdate ProcedureCode ::= 37
id-secondaryRATDataUsageReport ProcedureCode ::= 38
id-endcCellActivation ProcedureCode ::= 39
id-endcPartialReset ProcedureCode ::= 40
id-eUTRANRCellResourceCoordination ProcedureCode ::= 41
id-SgNBActivityNotification ProcedureCode ::= 42
id-endcX2Removal ProcedureCode ::= 43
id-dataForwardingAddressIndication ProcedureCode ::= 44
id-gNBStatusIndication ProcedureCode ::= 45
id-deactivateTrace ProcedureCode ::= 46
id-traceStart ProcedureCode ::= 47
id-endcConfigurationTransfer ProcedureCode ::= 48
id-handoverSuccess ProcedureCode ::= 49
id-conditionalHandoverCancel ProcedureCode ::= 50
id-earlyStatusTransfer ProcedureCode ::= 51
id-cellTrafficTrace ProcedureCode ::= 52
id-endcresourceStatusReporting ProcedureCode ::= 53
id-endcresourceStatusReportingInitiation ProcedureCode ::= 54
id-f1CTrafficTransfer ProcedureCode ::= 55
id-UERadioCapabilityIDMapping ProcedureCode ::= 56
id-accessAndMobilityIndication ProcedureCode ::= 57
id-procedure-code-58-not-to-be-used ProcedureCode ::= 58
id-CPC-cancel ProcedureCode ::= 59
id-rachIndication ProcedureCode ::= 60
id-scgFailureInformationReport ProcedureCode ::= 61
id-scgFailureTransfer ProcedureCode ::= 62
TriggeringMessage ::= ENUMERATED { initiating-message, successful-outcome, unsuccessful-outcome}
Criticality ::= ENUMERATED { reject, ignore, notify }
CriticalityDiagnostics-IE-List ::= SEQUENCE (SIZE (1..maxNrOfErrors)) OF
SEQUENCE {
iECriticality Criticality,
iE-ID ProtocolIE-ID,
typeOfError TypeOfError,
iE-Extensions ProtocolExtensionContainer { {CriticalityDiagnostics-IE-List-ExtIEs} } OPTIONAL,
...
}
The ProcedureCode list shows how much X2 has grown. The original listing on this page stopped at id-cellActivation, code 15. The latest release runs to id-scgFailureTransfer, code 62. Codes 19 to 25 belong to dual connectivity with an SeNB, and most codes from 27 to 43 belong to EN-DC with an en-gNB. Code 58 is reserved as id-procedure-code-58-not-to-be-used. In CriticalityDiagnostics, procedureCode names the procedure of the faulty message. The triggeringMessage field then says whether that message was an initiating message, a successful outcome or an unsuccessful outcome.
Find the neighbour, find its address, then set up X2 : ANR or configuration gives the neighbour, and configuration or S1 gives its transport address.X2 Setup replaces everything : it erases old configuration data in both nodes and resets the interface.The served cell list is the main payload : each side sends every cell it serves, including cells switched off for energy saving.Most detail lives in extensions : antenna ports, PRACH, MBSFN, CSG and band information are all in ServedCell-Information-ExtIEs.
When Does X2 Setup Happen ?
Does each handover open and close X2? No. X2 Setup is a peer-level exchange, not a per-UE exchange. An eNB usually starts it after it has found a neighbour, resolved a reachable transport address and established the X2-C transport association. Normal handovers then reuse that peer relationship.
Figure 2 shows the normal lifecycle and two later branches. A cell-list change uses ENB CONFIGURATION UPDATE while the peer relationship remains in place. A transport failure or deliberate removal can interrupt it; the nodes establish transport and run setup again when the peer returns.
Figure 2. X2 Setup establishes peer application data; later UE procedures reuse the association until disruption or removal.
Power-up can trigger this process if a configured neighbour is reachable, but X2 Setup is not a rule that runs exactly once between power-up and power-down. A new neighbour, address change or recovery after failure can cause another setup. Conversely, a stable peer can handle many UEs without repeating setup for each one.
Do not use RESET REQUEST as another name for X2 SETUP REQUEST. Reset clears UE contexts after an abnormal failure while retaining application-level peer configuration. X2 Setup replaces the exchanged configuration and resets the interface. For an LTE eNB paired with an en-gNB, EN-DC X2 Setup is the corresponding peer setup procedure; an individual SGNB ADDITION REQUEST comes later for a particular UE.
Setup is per peer relationship : it follows transport establishment, not each handover or SgNB addition.Configuration changes need not tear down X2 : peers can use ENB CONFIGURATION UPDATE.Failure changes the lifecycle : transport can drop or X2 can be removed before either eNB powers down.
How mobility works ?
A UE can change its serving LTE cell without always using X2. First ask whether the target cell belongs to the same eNB. If it belongs to another eNB, ask whether the two eNBs can prepare the handover over X2. EN-DC adds another question: is the LTE master cell moving, or only the NR secondary cell group?
| Mobility case | Preparation path | What changes |
|---|---|---|
Intra-eNB handover | Internal to one eNB; LTE RRC toward the UE | LTE PCell changes, but the serving eNB does not. |
X2-based inter-eNB handover | X2AP between source and target eNBs | Serving eNB changes; S1 path switch follows UE arrival. |
S1-based inter-eNB handover | S1AP through the MME | Serving eNB changes when X2 cannot or should not prepare the target. |
Inter-RAT handover | S1 toward the core network; target-RAT signalling beyond it | The UE leaves E-UTRA for another radio access technology. |
EN-DC secondary-node mobility | X2AP SgNB modification or change, with LTE/NR RRC as needed | The NR PSCell or SgNB changes while the LTE MeNB can remain the same. |
For inter-eNB mobility, TS 36.300 generally selects X2 preparation. S1 is used when there is no usable X2 relation, when configured for an EPC-node change, or after certain X2 failures. Inter-RAT handover is separate because its target is not another LTE eNB.
Intra-eNB handover
One eNB can serve more than one LTE cell. If the UE moves between two cells controlled by that same eNB, the source and target cell contexts remain inside one network node. The eNB can prepare the target locally; no X2AP HANDOVER REQUEST or S1AP HANDOVER REQUIRED is needed between separate nodes.
Figure 3. The LTE cell changes inside one eNB, so there is no peer-eNB handover exchange.
The eNB sends RRCConnectionReconfiguration with mobilityControlInfo to identify the target PCell and handover parameters. The UE synchronizes, accesses that cell and returns RRCConnectionReconfigurationComplete. The radio procedure can still be a handover even though a trace on X2 shows nothing. A mere SCell addition or release is not the same as moving the PCell.
X2-based inter-eNB handover
An X2 handover moves a UE from a source eNB to a target eNB, and the two eNBs prepare it between themselves. The MME and S-GW join only at the end, when the target eNB asks them to switch the downlink path. The sequence below shows which steps run over X2, which run over S1 and which run over the air.
Following illustration is duplicated from The LTE Network Architecture - A Comprehensive Tutorial (Alcatel Lucent Whitepaper)
The numbered steps in the sequence above map to 3GPP procedures as follows.
Steps 1 to 3 happen before any X2 message : the MME provides the area restriction, and the source eNB configures UE measurements and decides on the handover.Steps 4 and 6 are X2 Handover Preparation, 36.423 8.2.1 : HANDOVER REQUEST goes to the target eNB and HANDOVER REQUEST ACKNOWLEDGE comes back. The source eNB starts the timer TRELOCprep when it sends the request.Step 5 is admission control in the target eNB : the target reserves resources for the E-RABs it admits before it acknowledges.Step 7 is RRC, not X2 : the source eNB sends the handover command to the UE. The target eNB built that command and returned it inside the acknowledgement.Step 8 is SN STATUS TRANSFER, 36.423 8.2.2 : it gives the target eNB the PDCP sequence number status, so forwarded data continues without loss or duplication.The green area is user plane forwarding : the source eNB forwards user data to the target eNB over X2-U, not over X2AP.Steps 10 and 11 are S1AP Path Switch Request, 36.413 8.4.4 : the target eNB asks the MME to move the downlink path from the source eNB to itself.Step 12 is UE CONTEXT RELEASE, 36.423 8.2.3 : the target eNB informs the source eNB of handover success, and the source eNB releases the UE resources.
Two timers in the source eNB guard this sequence. TRELOCprep starts when HANDOVER REQUEST is sent, and it stops when HANDOVER REQUEST ACKNOWLEDGE arrives. If no response arrives before it expires, the source eNB cancels the preparation with the Handover Cancel procedure. For an immediate handover, the source eNB then starts TX2RELOCoverall. If no UE CONTEXT RELEASE arrives before that timer expires, the source eNB asks the MME to release the UE context. If the UE comes back to the source eNB first, the source eNB stops TX2RELOCoverall and keeps serving the UE.
Reading the X2 Handover Messages
It helps to read this as three phases rather than one long exchange. Preparation is between the eNBs, execution moves the UE and its data, and completion changes the core-network path. The example IDs below identify one illustrative UE; they are not fixed values from the specification.
1. Preparation: HANDOVER REQUEST and ACKNOWLEDGE
The source selects a target cell after measurement evaluation and sends HANDOVER REQUEST on X2-C. Old-eNB-UE-X2AP-ID identifies the UE at the source. TargetCell-ID and GUMMEI identify the destination and serving MME. UE-ContextInformation contains security, aggregate bit rate, E-RABs, their QoS and tunnel information, and an RRC context container. UE-HistoryInformation helps the target's mobility decision.
The target runs admission control before it replies. HANDOVER REQUEST ACKNOWLEDGE gives the same old ID, a new target-side ID, an admitted E-RAB list and the TargeteNBtoSource-eNBTransparentContainer. The source forwards the target-generated radio configuration to the UE without treating it as its own X2AP configuration. If admission fails, HANDOVER PREPARATION FAILURE carries a Cause instead of an acknowledgement.
2. Execution: RRC, forwarding and SN STATUS TRANSFER
The source sends the LTE RRCConnectionReconfiguration handover command on Uu. At about the same time it can forward buffered or newly arriving downlink packets through an X2-U GTP-U tunnel. SN STATUS TRANSFER is a separate X2-C message: it names the old and new X2AP UE IDs and lists the E-RABs whose PDCP COUNT and receive-status state must be transferred. The UE then synchronizes to and accesses the target cell. X2AP does not carry the UE's random access messages.
3. Completion: S1 path switch and UE CONTEXT RELEASE
After the UE reaches the target, the target sends S1AP PATH SWITCH REQUEST to the MME. The MME and S-GW update the user-plane route and the MME sends PATH SWITCH REQUEST ACKNOWLEDGE. These two messages use S1, not X2. Only then does the target send X2AP UE CONTEXT RELEASE with the old and new X2AP UE IDs. This is the source's signal to free its old radio and UE-associated X2 resources. The X2 peer association itself remains available for other UEs.
S1-based inter-eNB handover
A source eNB may need to hand the UE to another eNB without using X2 preparation. Typical reasons are no X2 relation to the target, a configured EPC-node change, or a qualifying X2 failure. The MME then relays preparation over S1AP. The LTE radio command toward the UE is still RRCConnectionReconfiguration.
Figure 4. The MME carries inter-eNB preparation over S1; no X2AP HANDOVER REQUEST appears in this path.
First, the source sends S1AP HANDOVER REQUIRED with the target identity, cause and source-to-target transparent container. The MME sends S1AP HANDOVER REQUEST to the target with the E-RABs to establish. After admission, the target returns HANDOVER REQUEST ACKNOWLEDGE with accepted bearers and a target-to-source transparent container. The MME relays the resulting HANDOVER COMMAND to the source, and the source delivers the target's radio command to the UE.
Once the UE accesses the target, the target sends S1AP HANDOVER NOTIFY to the MME. The MME completes the core-side route change and orders release of the source context. Status transfer or data forwarding may also be arranged, depending on the bearer and forwarding path. Unlike X2 handover, this path does not use X2AP SN STATUS TRANSFER or X2AP UE CONTEXT RELEASE. It also does not use the X2-handover PATH SWITCH REQUEST step: the MME is already involved in preparation.
Inter-RAT handover and radio-link recovery
Not every change of cell is an intra-LTE handover. When a UE leaves E-UTRA for another radio access technology, the source eNB prepares the transfer through S1 and the core network, not through an X2AP handover with a target eNB. The target system then uses its own radio and signalling procedures.
Radio-link failure is different again. If the UE loses its serving link before a planned handover completes, it may attempt RRC connection re-establishment in another cell. The receiving eNB can later send X2AP RLF INDICATION to the previous eNB for mobility diagnosis. That notification is feedback about a failure, not the preparation step that moved the UE. The mobility robustness section shows this feedback path.
EN-DC secondary-node mobility
EN-DC creates another kind of mobility that can occur without moving the LTE master cell. The UE may change its NR PSCell within the same en-gNB, or the MeNB may move its secondary-node resources to another en-gNB. These changes affect the secondary cell group, not necessarily the LTE PCell or the serving MME.
Same SgNB, new PSCell : the secondary node changes its NR cell configuration. Depending on the configuration, NR RRC can reach the UE directly on SRB3, or the MeNB can relay the change; X2-C coordination is needed when the MeNB must participate.Different SgNB : an SgNB can initiate SGNB CHANGE REQUIRED toward the MeNB. The MeNB prepares the new en-gNB, using SGNB ADDITION REQUEST and its acknowledgement, then coordinates UE reconfiguration and release of the old secondary resources. The source SgNB receives SGNB CHANGE CONFIRM or FAILURE for its request.LTE master cell also moves : this becomes an intra-eNB, X2-based or S1-based LTE handover with additional SCG handling. Do not identify it only from an NR PSCell change.
The EN-DC addition section shows how the first SgNB is prepared. Mobility can reuse modification or change procedures rather than repeating initial addition for every NR cell change.
Same eNB : the LTE PCell can change without X2AP or S1AP handover preparation.Different eNB : X2AP normally prepares the target; S1AP through the MME is the alternative when X2 is unavailable or unsuitable.EN-DC : an NR PSCell or SgNB change does not necessarily move the LTE master cell.
How EN-DC SgNB Addition Works ?
In EN-DC, the LTE eNB is the Master eNB (MeNB) and an NR en-gNB is the Secondary gNB (SgNB). The UE keeps its LTE master connection to the EPC while the network adds an NR secondary cell group. This is an X2-C procedure between the MeNB and en-gNB, not an Xn procedure between 5GC-connected nodes. The X2 peer relationship must already have been established.
Figure 5 : MeNB-to-SgNB X2-C preparation, LTE RRC delivery and NR access. The final NR access can overlap with completion signalling.
1. The MeNB asks the en-gNB to prepare NR resources
The MeNB sends SGNB ADDITION REQUEST. The MeNB-UE-X2AP-ID correlates the transaction. NRUESecurityCapabilities and SgNBSecurityKey let the SgNB prepare NR security. E-RABs-ToBeAdded-SgNBAddReqList names each requested bearer, DRB and EN-DC resource configuration. MeNBtoSgNBContainer carries the inter-node RRC information, while MeNBCell-ID identifies the LTE master cell. The en-gNB can reject the request with SGNB ADDITION REQUEST REJECT and a Cause.
2. The en-gNB returns admitted bearers and NR configuration
After admission, the en-gNB sends SGNB ADDITION REQUEST ACKNOWLEDGE. Its SgNB-UE-X2AP-ID is the target-side UE handle. The admitted list identifies accepted E-RABs and the tunnel endpoint appropriate to the selected PDCP placement. SgNBtoMeNBContainer conveys the NR secondary-cell-group configuration that must reach the UE. E-RABs-NotAdmitted-List, when present, explains partial admission.
3. The MeNB configures the UE over LTE RRC
The MeNB embeds the secondary-node configuration in LTE RRCConnectionReconfiguration and sends it over the LTE radio link. The UE replies with RRCConnectionReconfigurationComplete to the MeNB. The MeNB then sends SGNB RECONFIGURATION COMPLETE over X2-C to tell the en-gNB the UE accepted the configuration; this is not a reply to X2 Setup. The UE performs NR random access to the configured PSCell when needed. This step uses the NR radio interface, not X2AP.
After addition, later NR secondary-cell changes need not repeat SgNB Addition. When NR SRB3 is configured, some NR RRC changes can be delivered directly between the en-gNB and UE. Other changes still need X2-C coordination with the MeNB, especially when bearer or master-node context changes. EN-DC therefore does not mean that every NR cell change creates an X2-C message.
Communication over X2 for Load/Interference Information
A eNB frequently exchanges with Neighbouring eNBs about Load and Interference related information for Load balencing or Interference Management (e.g, Interference Coordination as in ABS configuration for eICIC).
How often they exchanges these information would depend on the purpose of these information exchange. There are roughly two kinds of purpose of these information as listed below.
- Load Balancing : The frequency of this information exchange is relatively low.
- RRM Optimization (e.g, Interference Coordination) : The frequency of this information exchange is relatively high (once in every tens of milliseconds).
The two purposes use different procedures. Load balancing information is requested with Resource Status Reporting Initiation. It is then delivered in RESOURCE STATUS UPDATE messages of the Resource Status Reporting procedure.
The interference coordination information is carried by a X2 message Load Indication as shown below.
< 36.423 Figure 8.3.1.2-1: Load Indication, successful operation >
The diagram above has no response message. Load Indication is a Class 2 procedure, so eNB1 sends LOAD INFORMATION and eNB2 answers with nothing. The receiving eNB keeps each received value valid until a new LOAD INFORMATION message carries an update of the same IE.
You can figure out exact contents of informations carried by Load Information from ASN structure of the message as listed below.
Following is based on
LoadInformation ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{LoadInformation-IEs}},
...
}
LoadInformation-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-CellInformation CRITICALITY ignore TYPE CellInformation-List PRESENCE mandatory} ,
...
}
CellInformation-List ::= SEQUENCE (SIZE (1..maxCellineNB)) OF ProtocolIE-Single-Container { {CellInformation-ItemIEs} }
CellInformation-ItemIEs X2AP-PROTOCOL-IES ::= {
{ ID id-CellInformation-Item CRITICALITY ignore TYPE CellInformation-Item PRESENCE mandatory }
}
CellInformation-Item ::= SEQUENCE {
cell-ID ECGI,
ul-InterferenceOverloadIndication UL-InterferenceOverloadIndication OPTIONAL,
ul-HighInterferenceIndicationInfo UL-HighInterferenceIndicationInfo OPTIONAL,
relativeNarrowbandTxPower RelativeNarrowbandTxPower OPTIONAL,
iE-Extensions ProtocolExtensionContainer { {CellInformation-Item-ExtIEs} } OPTIONAL,
...
}
UL-InterferenceOverloadIndication ::= SEQUENCE (SIZE(1..maxnoofPRBs)) OF UL-InterferenceOverloadIndication-Item
UL-InterferenceOverloadIndication-Item ::= ENUMERATED {
high-interference,
medium-interference,
low-interference,
...
}
UL-HighInterferenceIndicationInfo ::= SEQUENCE (SIZE(1..maxCellineNB)) OF UL-HighInterferenceIndicationInfo-Item
UL-HighInterferenceIndicationInfo-Item ::= SEQUENCE {
target-Cell-ID ECGI,
ul-interferenceindication UL-HighInterferenceIndication,
iE-Extensions ProtocolExtensionContainer { {UL-HighInterferenceIndicationInfo-Item-ExtIEs} } OPTIONAL,
...
}
UL-HighInterferenceIndication ::= BIT STRING (SIZE(1..110, ...))
Three fields in CellInformation-Item carry the interference picture, and each one works per PRB. The ul-InterferenceOverloadIndication field reports the uplink interference level that the sending cell experiences on each PRB, as high, medium or low. The ul-HighInterferenceIndicationInfo field names a target cell and gives one bit per PRB. A 1 marks high interference sensitivity as seen from the sending eNB. The receiving eNB should then try to avoid scheduling its cell edge UEs on that PRB. The relativeNarrowbandTxPower field covers the downlink. For each PRB, a 0 bit promises that the transmit power does not exceed the RNTP threshold.
The extension container is where most of the later interference features went. The listing below adds the ABS information for eICIC. It also adds four extensions that the original listing on this page did not have: IntendedULDLConfiguration, ExtendedULInterferenceOverloadInfo, CoMPInformation and DynamicDLTransmissionInformation. InvokeIndication also gained two values, naics-information-start and naics-information-stop.
Following is based on
CellInformation-Item-ExtIEs X2AP-PROTOCOL-EXTENSION ::= { { ID id-ABSInformation CRITICALITY ignore EXTENSION ABSInformation PRESENCE optional }| { ID id-InvokeIndication CRITICALITY ignore EXTENSION InvokeIndication PRESENCE optional }| { ID id-IntendedULDLConfiguration CRITICALITY ignore EXTENSION SubframeAssignment PRESENCE optional }| { ID id-ExtendedULInterferenceOverloadInfo CRITICALITY ignore EXTENSION ExtendedULInterferenceOverloadInfo PRESENCE optional }| { ID id-CoMPInformation CRITICALITY ignore EXTENSION CoMPInformation PRESENCE optional }| { ID id-DynamicDLTransmissionInformation CRITICALITY ignore EXTENSION DynamicDLTransmissionInformation PRESENCE optional }, ... } ABSInformation ::= CHOICE { fdd ABSInformationFDD, tdd ABSInformationTDD, abs-inactive NULL, ... } ABSInformationFDD ::= SEQUENCE { abs-pattern-info BIT STRING (SIZE(40)), numberOfCellSpecificAntennaPorts ENUMERATED {one, two, four, ...}, measurement-subset BIT STRING (SIZE(40)), iE-Extensions ProtocolExtensionContainer { {ABSInformationFDD-ExtIEs} } OPTIONAL, ... } ABSInformationFDD-ExtIEs X2AP-PROTOCOL-EXTENSION ::= { ... } ABSInformationTDD ::= SEQUENCE { abs-pattern-info BIT STRING (SIZE(1..70, ...)), numberOfCellSpecificAntennaPorts ENUMERATED {one, two, four, ...}, measurement-subset BIT STRING (SIZE(1..70, ...)), iE-Extensions ProtocolExtensionContainer { {ABSInformationTDD-ExtIEs} } OPTIONAL, ... } InvokeIndication ::= ENUMERATED{ abs-information, ..., naics-information-start, naics-information-stop } UsableABSInformation ::= CHOICE { fdd UsableABSInformationFDD, tdd UsableABSInformationTDD, ... } UsableABSInformationFDD ::= SEQUENCE { usable-abs-pattern-info BIT STRING (SIZE(40)), iE-Extensions ProtocolExtensionContainer { {UsableABSInformationFDD-ExtIEs} } OPTIONAL, ... } UsableABSInformationFDD-ExtIEs X2AP-PROTOCOL-EXTENSION ::= { ... } UsableABSInformationTDD ::= SEQUENCE { usaable-abs-pattern-info BIT STRING (SIZE(1..70, ...)), iE-Extensions ProtocolExtensionContainer { {UsableABSInformationTDD-ExtIEs} } OPTIONAL, ... }
The ABS pattern is a bitmap over subframes. For FDD it has 40 bits, one per DL subframe, and a 1 marks an almost blank subframe. The first bit corresponds to subframe 0 in the radio frame where SFN = 0, and the pattern repeats continuously. For TDD the length depends on the UL/DL configuration. It is 20 bits for configurations 1 to 5, 60 for configuration 6 and 70 for configuration 0. The measurement-subset field marks the subset of those ABS that the receiving eNB may use to configure specific UE measurements. An InvokeIndication set to abs-information asks the peer to send back its own ABS pattern.
The UsableABSInformation types at the end of the listing are not part of LOAD INFORMATION. They belong to the ABS Status IE, which travels in RESOURCE STATUS UPDATE. The eNB that received an ABS pattern reports there which of those ABS it can use for protected DL scheduling, and what share of their resources it uses. The eNB that designated the ABS uses this report to decide whether to change its pattern. Note that usaable-abs-pattern-info keeps the double a exactly as 36.423 spells it.
Load Indication is one way : it is a Class 2 procedure with no response message.Interference reports work per PRB : overload indication and HII cover the uplink, and RNTP covers the downlink.eICIC works per subframe instead : the ABS pattern marks subframes, not PRBs.Load balancing uses a different procedure : Resource Status Reporting carries the measurement reports, including ABS Status.
Other X2 Procedures
X2AP also handles changes that are not a UE handover. Each procedure below has its own scope: one updates the peer's cell configuration, one requests periodic measurements, and one recovers a failed UE. These messages use X2-C; none is a GTP-U data packet.
eNB Configuration Update
Suppose an eNB adds a cell after the X2 relationship was established. It sends ENB CONFIGURATION UPDATE rather than tearing down X2 and running X2 Setup again. The update identifies served cells being added, modified or deleted. The peer answers with ENB CONFIGURATION UPDATE ACKNOWLEDGE or FAILURE; failure can include a Cause and TimeToWait. This is about the node's advertised configuration, not a per-UE handover.
Figure 6 : The receiving eNB confirms the revised neighbour configuration.
Resource Status Reporting
Load balancing may need repeated measurements rather than a single LOAD INFORMATION notification. An eNB starts Resource Status Reporting with RESOURCE STATUS REQUEST, naming the cells and measurement characteristics it wants. The peer sends RESOURCE STATUS RESPONSE with its measurement ID if it accepts, or RESOURCE STATUS FAILURE with a Cause if it cannot. It then sends RESOURCE STATUS UPDATE reports using the negotiated IDs. Another request can stop or change the reporting. Do not confuse the response, which establishes reporting, with the later updates, which contain measurements such as radio resource status, capacity and ABS status when applicable.
Figure 7 : One accepted request can lead to many reports; a failure replaces the response if reporting cannot start.
Radio-Link Failure Indication and Handover Report
When a UE reconnects to a different eNB after a radio-link failure, the receiving eNB can send RLF INDICATION to the eNB that served the UE before failure. It identifies the failed UE and the re-establishment cell so the previous eNB can analyze the event. If the event indicates a too-early, too-late or wrong-cell handover, the previous eNB may send HANDOVER REPORT to the peer involved. These are mobility-robustness feedback messages; they do not themselves move the UE or change its bearer path.
Figure 8 : RLF INDICATION is a notification; HANDOVER REPORT is optional follow-up analysis, not an acknowledgement.
X2-C ASN for Mobility and EN-DC
The following selected ASN.1 definitions show what the X2-C messages actually carry. They are taken from TS 36.423 v19.1.0. The outer message contains a ProtocolIE-Container, and each named IE set states which information is mandatory or optional. The extracts keep the IEs most useful for reading handover and EN-DC traces; an ellipsis means the full Release 19 definition has further optional or extension IEs. The earlier X2 Setup and LOAD INFORMATION sections show the corresponding structures for those procedures.
HANDOVER REQUEST
The source asks the target to prepare one UE. The target cell and GUMMEI locate the destination; UE-ContextInformation is the heavy part, carrying security, E-RAB setup and RRC context.
Following is based on
HandoverRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{HandoverRequest-IEs}},
...
}
HandoverRequest-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-Old-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-Cause CRITICALITY ignore TYPE Cause PRESENCE mandatory }|
{ ID id-TargetCell-ID CRITICALITY reject TYPE ECGI PRESENCE mandatory }|
{ ID id-GUMMEI-ID CRITICALITY reject TYPE GUMMEI PRESENCE mandatory }|
{ ID id-UE-ContextInformation CRITICALITY reject TYPE UE-ContextInformation PRESENCE mandatory }|
{ ID id-UE-HistoryInformation CRITICALITY ignore TYPE UE-HistoryInformation PRESENCE mandatory },
...
}
HANDOVER REQUEST ACKNOWLEDGE
The response adds the target-side UE ID, says which E-RABs were admitted and carries the target-generated radio command in a transparent container. The rejected-bearer list is optional.
Following is based on
HandoverRequestAcknowledge ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{HandoverRequestAcknowledge-IEs}},
...
}
HandoverRequestAcknowledge-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-Old-eNB-UE-X2AP-ID CRITICALITY ignore TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-New-eNB-UE-X2AP-ID CRITICALITY ignore TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-E-RABs-Admitted-List CRITICALITY ignore TYPE E-RABs-Admitted-List PRESENCE mandatory }|
{ ID id-E-RABs-NotAdmitted-List CRITICALITY ignore TYPE E-RAB-List PRESENCE optional }|
{ ID id-TargeteNBtoSource-eNBTransparentContainer CRITICALITY ignore TYPE TargeteNBtoSource-eNBTransparentContainer PRESENCE mandatory },
...
}
SN STATUS TRANSFER and UE CONTEXT RELEASE
The status message preserves PDCP continuity per E-RAB. UE CONTEXT RELEASE comes later, after path switch, and needs only the pair of UE IDs in its mandatory part.
Following is based on
SNStatusTransfer ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{SNStatusTransfer-IEs}},
...
}
SNStatusTransfer-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-Old-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-New-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-E-RABs-SubjectToStatusTransfer-List CRITICALITY ignore TYPE E-RABs-SubjectToStatusTransfer-List PRESENCE mandatory },
...
}
UEContextRelease ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{UEContextRelease-IEs}},
...
}
UEContextRelease-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-Old-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-New-eNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory },
...
}
SGNB ADDITION REQUEST and ACKNOWLEDGE
These two messages are specific to EN-DC over X2. The request carries NR capabilities, the secondary-node key, bearers to add and the MeNB-to-SgNB container. The acknowledgement identifies admitted E-RABs and supplies the SgNB-to-MeNB container that ultimately configures the UE.
Following is based on
SgNBAdditionRequest ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{SgNBAdditionRequest-IEs}},
...
}
SgNBAdditionRequest-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-MeNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-NRUESecurityCapabilities CRITICALITY reject TYPE NRUESecurityCapabilities PRESENCE mandatory }|
{ ID id-SgNBSecurityKey CRITICALITY reject TYPE SgNBSecurityKey PRESENCE mandatory }|
{ ID id-SgNBUEAggregateMaximumBitRate CRITICALITY reject TYPE UEAggregateMaximumBitRate PRESENCE mandatory }|
{ ID id-E-RABs-ToBeAdded-SgNBAddReqList CRITICALITY reject TYPE E-RABs-ToBeAdded-SgNBAddReqList PRESENCE mandatory }|
{ ID id-MeNBtoSgNBContainer CRITICALITY reject TYPE MeNBtoSgNBContainer PRESENCE mandatory }|
{ ID id-MeNBCell-ID CRITICALITY reject TYPE ECGI PRESENCE mandatory },
...
}
SgNBAdditionRequestAcknowledge ::= SEQUENCE {
protocolIEs ProtocolIE-Container {{SgNBAdditionRequestAcknowledge-IEs}},
...
}
SgNBAdditionRequestAcknowledge-IEs X2AP-PROTOCOL-IES ::= {
{ ID id-MeNB-UE-X2AP-ID CRITICALITY reject TYPE UE-X2AP-ID PRESENCE mandatory }|
{ ID id-SgNB-UE-X2AP-ID CRITICALITY reject TYPE SgNB-UE-X2AP-ID PRESENCE mandatory }|
{ ID id-E-RABs-Admitted-ToBeAdded-SgNBAddReqAckList CRITICALITY ignore TYPE E-RABs-Admitted-ToBeAdded-SgNBAddReqAckList PRESENCE mandatory }|
{ ID id-SgNBtoMeNBContainer CRITICALITY reject TYPE SgNBtoMeNBContainer PRESENCE mandatory },
...
}
Reference
- TS 36.423 v19.1.0 - E-UTRAN; X2 Application Protocol - X2AP
- TS 36.413 v19.2.0 - E-UTRAN; S1 Application Protocol - S1AP
- TS 36.300 v19.2.0 - E-UTRA and E-UTRAN; Overall description; Stage 2
- TS 36.331 v19.4.0 - E-UTRA; Radio Resource Control (RRC); Protocol specification
- TS 36.422 v19.0.0 - E-UTRAN; X2 signalling transport
- TS 36.424 v19.0.0 - E-UTRAN; X2 data transport
- TS 37.340 v19.3.0 - Multi-connectivity; Overall description; Stage 2