Each cell broadcast the list of neighbour cells via various SIBs. How a cell knows about the existence of its neighbours ? A conventional way is that network operator manually configure these neighbour cell list for each cell. As you may guess, there would be a couple of big issues with these convetional method.

• It is tedius and labour intensive to investigate and configure all the neighbour list for each cell
• The neighbour cell list would change very frequently for various reasons especially when they are putting a lot of new cells here and there.

Then everybody would ask "Would there be any easier way to do this ?" or "Wouldn't it be possible to come out with any method to do this automatically ?"

Yes, there is an automatic way to do this and it is ANR. The idea is to let each cell to detect its neighbour and update its neighbour cell list automatically.

But there is an issue. Cell does not have any measurement functionality for detecting the existence it's neighbour cell. Then how we solve the problem ? This automatica neighbour detection can be possible if UE helps. Since UE can detect all the cells around it, network can order UE to check the existence of cells around it and extract the neighbour cell information from UE report.    

Overall procedure is as follows.

• i) Network send Measurement Command (Measurement Control) to UE to perform the detection/measurement of cells around it.
• ii) UE detect/performs measurement on the cells and report it to the cells which sent the measurement command
• iii) Opon the reception of the measurement report, the cell extract the cell information from the measurement report message and update its neigbhour cell list.

I will put the details on protocol sequence and decoded RRC messages later when I have it.

The sections below work through what 36.300 and 36.331 actually define for this, and followings are the topics :

• What does the eNB keep for each cell?
• Why is the measurement report not enough on its own?
• How does the eNB ask the UE to read the ECGI?
• What does the UE send back?
• How does the eNB find the X2 address of the new eNB?
• How is it different for inter-RAT and inter-frequency?
• Reference

What does the eNB keep for each cell?

Before following any messages, it helps to know what ANR is filling in. The eNB does not keep one flat list of neighbours. It keeps a table for every cell it serves, and each row in that table carries three flags that decide what the eNB is allowed to do with that neighbour.

36.300 calls the table the Neighbour Cell Relation Table, or NCRT. The ANR function sits in the eNB and owns it. Two parts do the work. A Neighbour Detection Function finds new neighbours and adds them, and a Neighbour Removal Function drops the relations that have gone stale. Both are implementation specific, so vendors differ in how eagerly they add and remove.

A Neighbour Cell Relation means three things at once. The eNB controlling the source cell knows the ECGI and the PCI of the target. It holds an entry for that target in the source cell's table. And the attributes on that entry are defined, either by O&M or left at their default values.

Those attributes are the part worth remembering, because they explain behaviour that otherwise looks like a fault.

One asymmetry surprises people. A Neighbour Cell Relation runs from one cell to one cell in that direction only, so cell A can have a relation to cell B while cell B has none back to A. An X2 link is a different thing. It joins two eNBs and it works both ways. A one-way handover failure is therefore not evidence of a missing X2.

• The table is per cell, not per eNB : an eNB serving three cells keeps three tables, and a neighbour one cell discovers does not appear in the other two by itself.
• Detection and removal are left to the vendor : 36.300 defines the table and the attributes, and calls both functions implementation specific.
• Relations are one way, X2 is two way : the relation is cell to cell and unidirectional, while the X2 link is eNB to eNB and bidirectional.
• O&M keeps the final say : it can add relations, delete them and change the attributes, and it is told whenever the table changes.

Why is the measurement report not enough on its own?

The opening of this page says the UE detects the cells around it and the network extracts the neighbour information from the report. That is true, and it skips the step that makes ANR interesting. An ordinary measurement report does not identify a cell well enough to build a neighbour relation from.

What the UE reports first is the physical cell identity. PhysCellId in 36.331 is an INTEGER (0..503), so a whole network has only 504 of them. They are reused constantly, and two cells sharing a PCI can sit a few kilometres apart. A PCI on its own therefore names a signal rather than a cell.

What the eNB needs is the E-UTRAN Cell Global Identifier. An ECGI is a PLMN identity plus a cell identity, and it is globally unique. That is what the NCRT stores, and it is also what lets the eNB work out which eNB owns the cell.

The ECGI never appears in an ordinary measurement report, because it is not something the UE measures. The target cell broadcasts it in system information. So the eNB has to send the UE back to read it, and that extra round trip sits at the centre of ANR.

Figure 1. The intra-frequency ANR sequence. The first report names a PCI and the second one names an ECGI, and everything between the two exists only to turn one into the other.

• Step 1 gives the eNB a signal, not a cell : the report carries physCellId and no cgi-Info, so the eNB knows something is out there and not what it is.
• Step 2 is a normal reconfiguration : the eNB does not invent a new procedure. It changes the measurement configuration, and the change is what makes the UE do the ANR work.
• The dashed arrow is the expensive part : the UE has to decode another cell's SIB1, and it cannot do that and listen to the serving cell at the same time.

• PCI identifies a signal, ECGI identifies a cell : 504 PCI values against a globally unique ECGI.
• The ECGI is read, never measured : it lives in the neighbour's system information, so the UE has to decode that broadcast to get it.
• ANR costs one extra reporting cycle : the first report names the PCI, and only the second one carries the ECGI.

How does the eNB ask the UE to read the ECGI?

Two information elements do this job, and they sit in different halves of the measurement configuration. One names the cell to go and read. The other changes what the report is for. Both have to be present, because on its own neither one tells the UE to do anything new.

The measurement object carries the first of them. The field cellForWhichToReportCGI takes a PhysCellId, and the eNB sets it to the PCI the UE just reported.

Following is based on 36.331 v19.3.0 (Release 19)

MeasObjectEUTRA ::=                 SEQUENCE {
    carrierFreq                         ARFCN-ValueEUTRA,
    allowedMeasBandwidth                AllowedMeasBandwidth,
    presenceAntennaPort1                PresenceAntennaPort1,
    neighCellConfig                     NeighCellConfig,
    offsetFreq                          Q-OffsetRange                   DEFAULT dB0,
    -- Cell list
    cellsToRemoveList                   CellIndexList                   OPTIONAL,   -- Need ON
    cellsToAddModList                   CellsToAddModList               OPTIONAL,   -- Need ON
    -- Excluded list
    excludedCellsToRemoveList           CellIndexList                   OPTIONAL,   -- Need ON
    excludedCellsToAddModList           ExcludedCellsToAddModList       OPTIONAL,   -- Need ON
    cellForWhichToReportCGI             PhysCellId                      OPTIONAL,   -- Need ON
    ...                                 -- the r10 and later extension groups are not ANR related
}

The report configuration carries the other half. Under the periodical trigger type, purpose is set to reportCGI instead of reportStrongestCells. The UE then stops reporting signal levels for that measId and reports identity.

Following is based on 36.331 v19.3.0 (Release 19)

ReportConfigEUTRA ::=               SEQUENCE {
    triggerType                         CHOICE {
        event                               SEQUENCE {
            ...                                 -- the A1 to A6 and later event definitions are not ANR related
        },
        periodical                          SEQUENCE {
            purpose                             ENUMERATED {
                                                    reportStrongestCells, reportCGI}
        }
    },
    triggerQuantity                     ENUMERATED {rsrp, rsrq},
    reportQuantity                      ENUMERATED {sameAsTriggerQuantity, both},
    maxReportCells                      INTEGER (1..maxCellReport),
    reportInterval                      ReportInterval,
    reportAmount                        ENUMERATED {r1, r2, r4, r8, r16, r32, r64, infinity},
    ...,
    [[  si-RequestForHO-r9                  ENUMERATED {setup}              OPTIONAL,   -- Cond reportCGI
        ue-RxTxTimeDiffPeriodical-r9        ENUMERATED {setup}              OPTIONAL    -- Need OR
    ]],
    ...                                 -- later groups; includeMultiBandInfo-r13 also carries -- Cond reportCGI
}

si-RequestForHO-r9 is the field that decides how hard the UE may work at it. The condition is marked -- Cond reportCGI, so it is only meaningful in this mode. When the eNB includes it, three things change at once. The UE may use autonomous gaps to acquire the system information, it applies a different value for T321, and it puts different fields in the measurement report.

The timer is worth a second look, because it moves in the direction people do not expect. T321 bounds how long the UE may spend acquiring the CGI. On E-UTRA without si-RequestForHO the UE gets a full second. With si-RequestForHO included it gets 150 ms, or 190 ms for a category 0 UE. The budget gets shorter precisely because the UE is now allowed to take autonomous gaps and stop listening to the serving cell.

None of this is free. 36.300 says the eNB may need to schedule appropriate idle periods so the UE can read the ECGI from the neighbour's broadcast channel. During those periods the serving cell gets nothing from that UE.

• Both IEs are required : cellForWhichToReportCGI names the target and purpose = reportCGI changes the job. One without the other does nothing.
• si-RequestForHO enables autonomous gaps : the UE stops asking for scheduled idle periods and takes them itself.
• A shorter T321 is the sign of a faster method : 150 ms with autonomous gaps against 1 second without them.
• The identity costs throughput : every idle period is time the serving cell cannot schedule that UE.

What does the UE send back?

The second report looks like the first one, with one extra branch filled in. The cgi-Info branch is optional in the ASN.1, and it is present only when the UE actually managed to decode the neighbour's system information before T321 expired.

Following is based on 36.331 v19.3.0 (Release 19)

MeasResultEUTRA ::=                 SEQUENCE {
    physCellId                          PhysCellId,
    cgi-Info                            SEQUENCE {
        cellGlobalId                        CellGlobalIdEUTRA,
        trackingAreaCode                    TrackingAreaCode,
        plmn-IdentityList                   PLMN-IdentityList2          OPTIONAL
    }                                                                   OPTIONAL,
    measResult                          SEQUENCE {
        rsrpResult                          RSRP-Range                  OPTIONAL,
        rsrqResult                          RSRQ-Range                  OPTIONAL,
        ...,
        [[  additionalSI-Info-r9                AdditionalSI-Info-r9    OPTIONAL
        ]],
        ...                                 -- later groups add cgi-Info-v1310 (band information) and
                                            -- cgi-Info-5GC-r15 (5GC cell access information)
    }
}

CellGlobalIdEUTRA ::=               SEQUENCE {
    plmn-Identity                       PLMN-Identity,
    cellIdentity                        CellIdentity
}

AdditionalSI-Info-r9 ::=            SEQUENCE {
    csg-MemberStatus-r9                 ENUMERATED {member}             OPTIONAL,
    csg-Identity-r9                     CSG-Identity                    OPTIONAL
}

Three things come back inside cgi-Info. The first is cellGlobalId, the ECGI itself, and the definition above shows it is only a PLMN identity joined to a cell identity. The second is trackingAreaCode, which tells the eNB which tracking area the neighbour belongs to. The third is plmn-IdentityList, which carries every PLMN the neighbour broadcasts. That last one matters on a shared network, where one physical cell serves several operators.

AdditionalSI-Info-r9 covers the closed subscriber group case. When the detected cell is a CSG or hybrid cell, the UE also reports the CSG identity, and csg-MemberStatus says whether this UE is a member. Without it, an eNB would add a relation to a cell most of its UEs are not allowed to use.

• cgi-Info is optional for a reason : an absent cgi-Info means the acquisition failed, not that the cell has no ECGI.
• The report carries more than the ECGI : the tracking area code and the full PLMN list arrive with it.
• CSG cells identify themselves separately : csg-Identity and csg-MemberStatus arrive in AdditionalSI-Info-r9.

How does the eNB find the X2 address of the new eNB?

Knowing the ECGI tells the eNB which eNB owns the cell. It does not tell it how to reach that eNB over the transport network, and the two eNBs have no path between them yet. So the first exchange has to travel through the MME instead.

36.300 lists what the eNB does once it decides to add the relation. It looks up a transport layer address for the new eNB, updates the neighbour relation list, and sets up an X2 interface if one is needed. The lookup is the part with its own procedure.

The Configuration Transfer Function carries it. The initiating eNB asks the MME for the TNL address of the candidate, naming both eNBs by ID. The MME relays that to the candidate, the candidate answers with one or more TNL addresses, and the MME relays the answer back. The MME only relays here, and it never has to act on the content.

Figure 2. TNL address discovery, then X2 setup. Four S1 messages exist only to learn an IP address, because until the eNB has one there is no way to ask the question directly.

• Steps 1 and 3 are the same message name : eNB CONFIGURATION TRANSFER travels eNB to MME in both directions, and the source and target eNB IDs say which way round it is.
• Steps 2 and 4 are the relayed copies : the MME repackages the request and the answer as MME CONFIGURATION TRANSFER.
• Step 5 is the first direct contact : SCTP comes up between the two eNBs, and only then does X2AP start.
• Step 6 carries served cell information : the X2 Setup exchange tells each eNB what cells the other serves, and 36.300 notes that this exchange may itself feed ANR.

• The MME never needs to understand the request : it routes on the target eNB ID and relays the payload.
• An ECGI is not a transport address : the ECGI identifies the cell, and the TNL address is what SCTP connects to.
• X2 setup is optional : 36.300 says a new X2 interface is set up if needed, and the No X2 attribute can forbid it outright.

How is it different for inter-RAT and inter-frequency?

The shape of the procedure does not change. The UE still reports a PCI, still gets sent back to read an identity, and still reports that identity in a second message. What changes is what counts as a PCI, what the UE has to read, and how much it costs to go and look.

Each cell carries an Inter Frequency Search list, and that list holds every frequency the UE should search. On the table side one attribute disappears. For inter-RAT cells the No X2 attribute is absent from the NCRT, because X2 is only defined between E-UTRAN nodes and there is nothing for the flag to forbid.

The per-RAT details are easy to mix up, so the table below collects them.

The cost is also stated more bluntly for this case. 36.300 says the UE ignores transmissions from the serving cell while it finds the requested information in the neighbour's broadcast channel. On an inter-RAT target that can take a long time, and the timer reflects it. T321 allows 8 seconds for UTRA without si-RequestForHO, against 1 second on E-UTRA.

Later releases extended the same design further. An E-UTRA cell can hold a relation to an NR cell for EN-DC, and that relation gains two more attributes, No EN-DC and Resource Coordination Only. NB-IoT got its own ANR measurement result, ANR-MeasResult-NB-r16, which is the only IE in 36.331 that carries ANR in its name.

• The procedure is the same, the identity is not : a GERAN cell is named by Band Indicator, BSIC and BCCH ARFCN, and a CDMA2000 cell by its PN Offset alone.
• No X2 is missing for inter-RAT rows : there is no X2 towards a UTRAN or GERAN node, so the attribute has nothing to control.
• Inter-RAT acquisition is slower and costs more : 8 seconds of T321 for UTRA against 1 second for E-UTRA, with the serving cell ignored throughout.

Reference

Two specifications carry everything on this page. One describes what ANR is and what the eNB does with the result. The other defines the messages and the fields that make it happen.

• 36.300 - E-UTRA and E-UTRAN; Overall description, v19.2.0. Clause 22.3.2a defines the NCRT and its attributes, 22.3.3 the intra-frequency procedure, 22.3.4 the inter-RAT and inter-frequency case, 22.3.4a the NR additions, and 22.3.6.1 the TNL address discovery shown in Figure 2.
• 36.331 - E-UTRA; Radio Resource Control (RRC) protocol specification, v19.3.0. MeasObjectEUTRA, ReportConfigEUTRA and MeasResultEUTRA carry the fields quoted above, the si-RequestForHO field description gives the autonomous gap rule, and clause 5.5.2.2 carries the T321 values.