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. This page stays with the original LTE core of X2: setup, mobility and load information.
- What are the most common information carried over X2 ?
- How to setup an X2 between one eNB and another eNB ?
- Communication over X2 for Mobility
- Communication over X2 for Load/Interference Information
- 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 Communication over X2 for Mobility 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.
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.
Communication over X2 for Mobility
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.
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.
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