LTE1685

Neighbour Relation
Robustness
Please always check the latest version of this NEI slides!
Network Engineering Information

LTE1685
• Gay Calaranan
• 17.06.2014
1 26/07/2016 © Nokia 2014 - MBB Customer Support Network Engineering / Gay Calaranan
For internal use
Disclaimer
• Please note that the NEI materials are for internal use only. If they
shall be used as a source for the customer presentation, it is
mandatory to align the contents with the Product Management and/or
local sales teams at first!
• The results of simulations shown in this presentation are examples
only. They demonstrate trends (not absolute values) expected after
feature activation. The presented simulations should be analyzed with
respect to the assumptions taken. They may differ from results
achievable in real networks.
For internal use
LTE1685 Neighbour Relation Robustness
Table of contents
1 2 3 4
Introduction Technical Inter – Benefits and
Details dependencies Gains
Motivation and Feature Detailed Functionality Simulation, Lab and
Interdependencies with
Overview Description Field Findings
other features and Simulation, Lab
functions
1 and Field Findings
5 6 7 8
Configuration Deployment Performance Compliance
Management Aspects Aspects Aspects
Parameters and Activation, 3GPP, IETF, ETSI
Counters and KPIs,
Parameterization Configuration Examples, Feature Impact Analysis
Scenarios Fault Mgmt, Trial Area and Verification
For internal use
Introduction
Table of contents
• Feature in a Nutshell
• Four Sub-features
For internal use
Introduction
• Without LTE1685
- Existing Automatic Neighbour Relations (ANR) Features, using OAM and UE-based
mechanisms create both intra and inter-frequency neighbours, resulting in too many
definitions in eNB database.
- Fault is raised when maximum number of neighbours is reached, but deletion of old NR
has to be done manually or via plan file.
• With LTE1685
The eNB is capable of automatic
mechanisms for:
- Removal of unused neighbour
relations
- Neighbour Relation Re-validation
- Detection of PCI confusion
- NR Exchange at capacity limit
For internal use
Introduction
LTE1685 Neighbour Relation Robustness Sub-Features
Autonomous Removal
of Unused Neighbours • Existing neighbour relations and X2 links are evaluated
if they are being utilized for handover purposes.
• Neighbour cells that remain unused during the pre-
defined monitoring period will qualify for deletion in
eNB database.
A
For internal use
Introduction
Re-Validation of LTE
Neighbour Relations • Out-dated neighbour information, such as PCI or CGI
are verified via CGI measurements.
• New neighbor instance is created in eNB using
information from new ReportCGI message; while the
old NRs are kept in an invalid status until automatically
deleted.
B
For internal use
Introduction
Warning for PCI

Confusion • Toggling of neighbour status indicates that two
neighbour cells with same frequency does not have
unique physical layer identity (PCI).
• The eNB detects this conflict in configuration and
notifies the user or operator in order to make
necessary correction.
C
For internal use
Introduction
Autonomous LTE
neighbour exchange at • If the number of neighbors is already at its maximum
capacity limit count, existing and less important neighbour can be
removed; then, replaced by a newly detected LTE
neighbour.
D
For internal use
Technical Details
Table of contents
• Dependency Table
• LTE1685 sub-features A - D
For internal use
Technical Details
Dependency Table
FDD LTE RL release eNodeB NetAct
Release/version RL70 LN7.0 NetAct8 EP2
TDD LTE RL release eNodeB NetAct

Release/version RL55TD LNT5.0 NetAct8 EP2
Flexi Zone Micro (FZM) RL release eNodeB NetAct

RL70 LNF7.0
Release/version NetAct8 EP2
RL55TD LNZ5.0
HW Specified by
HW & IOT MME SAE GW UE
requirements 3GPP
Release/version FSMR2, FSMR3 - - 3GPP Release 8 (please refer to
chapter 8)
For internal use
Technical Details – LTE1685 Neighbour Relation Robustness
Managed Objects
LNBTS [1…1] LNCEL [0…18] LNADJ [0…255] LNREL [0…388]
- actUeBasedAnrIntraFreqLte - lnCelId - cPlaneIpAddrCtrl - lnRelId
- actUeBasedAnrInterFreqLte - phyCellId - adjEnbId - ecgiAdjEnbId
- anrRobLevel - eutraCelId - x2LinkStatus - ecgiPlmnId
- actAutoLteNeighRemoval - earfcnDL -… - handoverAllowed
- consecHoFailThres -… - nrStatus
LNADJL [0…63]
- s1PrdRevalWaitTmr - removeAllowed
- adjEutraCelId
- x2PrdRevalWaitTmr - …
- fDlEarfcn
- phyCellId
LNBTS: New Structure LNCEL: related structure ANRPRL [0…31]
- ecgiAdjEnbId
- anrIdleTimeThresLte - blacklistHoL - actAlsoForUeBasedANR
-…
• idleTimeThresLteNR • blacklistTopo - targetCarrierFreq
• idleTimeThresNbeNB • freqEutra LNHOIF [1…16] - nrLimitIntraFreq
• idleTimeThresX2 • phyCellIdRange - eutraCarrierInfo - nrLimitInterFreq
• phyCellIdStart -… -…
For internal use
Abbreviations – LTE1685 Neighbour Relation Robustness
Abbreviation Full Name

ANR Automatic Neighbour Relation
NR Neighbour Relation – pertains to LNREL objects
NbeNB Neighbour eNB – refers to LNADJ instances
NbCell Neighbour cell – corresponds to LNADJL
PCI Physical Channel Identity
CPlaneIP@ Control Plane IP Address
ReportCGI UE measurement in which CGI of unknown neighbor cell is retrieved (also known as CGI Resolution)
For internal use
LTE1685-A: Autonomous removal of unused LTE Neighbours
• Activation flag → LNBTS:actAutoLteNeighRemoval
- Manual deletion of neighbour objects (LNREL, LNADJL, LNADJ) is required.

- In RL60/RL45TD-LTE1708, eNB monitors the allowed number of neighbour
eNBs (LNADJ) depending on hardware used:
• For FSMr2 and FZM: 128
• For FSMr3: 256
- New! RL70/RL55TD-CRL2500, maximum number of cells per neighbour
OFF eNB is increased from 24 to 64 cells (LNADJLs per LNADJ).

- Base Station Notification is triggered when limits are reached:
• 6265: EFaultId_MaximumNumberOfNeighbourEnbsOrCellsExceeded
For internal use
• Activation flag → LNBTS:actAutoLteNeighRemoval
- Activation flag affects sub-features A and D (Autonomous removal and

exchange). Sub-features B and C (re-validation and PCI warning) are basic SW
functionalities for LTE1685.
- Upon activation, eNB decides at the end of every hour if removal of objects
needs to be done or not.
- If there are changes done, notification is sent in BTS Site Manager and
NetAct.
ON - HINT: Manual deletion of NR via NetAct/BTSSM is still possible.
For internal use
• REMOVAL OF NR [LNREL]
Candidate for removal • All NRs with are not ‘reserved’  LNREL:removeAllowed = true
Excluded from removal • NRs which are 'reserved by operator' are protected from deletion if
LNREL:removeAllowed = false
• NRs which are blacklisted (LNREL:handoverAllowed = forbidden) must be excluded by
setting LNREL:removeAllowed = false after migration
- Types of outgoing handover events considered if NRs are removed or not: X2, S1, Intra-eNB
- If new NR is added via ANR, it will not be reserved.  LNREL:removeAllowed = ‘true’
- There are cases when an LNREL does not have a corresponding neighbour cell (NbCell/LNADJL).
This could be due to deleted LNADJL via O&M intervention or via X2 Setup/ X2 Configuration
Update procedures
- If NR (LNREL) is not linked to a neighbour cell (LNADJL) and LNREL:removeAllowed is set to:
• TRUE: NR will be autonomously deleted
• FALSE: NR is kept in eNB database with LNREL:nrStatus set to ‘unavailable’.
For internal use
• CLOSING OF X2 LINKS [LNADJ:x2LinkStatus = unavailable]
Candidate for closing • X2 links with enbControlled C-Plane IP Address
• not needed X2 links  no corresponding LNREL
• Unconfirmed IP Address cPlaneIpAddrCtrl = enbControlled
• X2 link configuration: Symmetric (enbControlled) x2LinkStatus = unavailable
Excluded from closing • X2-links with oamControlled C-Plane IP address
- Unconfirmed IP Address – why it exists?

• eNB-controlled X2-link was initially established but SCTP association was closed and X2 link became
unavailable.
• Modification of X2 link – from OAM-controlled (IP Address configured manually) to eNB-controlled.
- Handling of Unconfirmed IP Address
Unconfirmed IP address will not If it becomes relevant again, it Notification in NetAct and BTS Site
be re-established and will be can be learned as new X2 link Manager will only appear if the new IP
candidate for deletion. via LTE492, LTE782 or LTE556. address is different from the
previously unconfirmed value.
For internal use
• CLOSING OF X2 LINKS [LNADJ:x2LinkStatus = unavailable]
- Not symmetric = the link is configured as ‘oamControlled’ in the neighbour eNB  the X2 link
will be re-established).
- Symmetric = the link is also configured as ‘enbControlled’ in the neighbour eNB  the X2 link
will be considered for closing.
LNADJ: eNB1
LNADJ: eNB2 cPlaneIpAddrCtrl = oamControlled
cPlaneIpAddrCtrl = enbControlled
LNADJ: eNB1
x2LinkStatus = available  unavailable cPlaneIpAddrCtrl = enbControlled
eNB1 eNB2
NbeNB
For internal use
• Removal of NbeNB and Nbcell [LNADJ and LNADJL]
Candidate for removal • X2 links with enbControlled C-Plane IP Address
Excluded from removal • X2 links with oamControlled C-Plane IP address
• NOTE:
If the cell (connected to an LNADJL) is deleted in the peer neighbour eNB, it will send eNB
Configuration Update to update its new configuration:
- The associated LNADJL will also be automatically removed but not as part of LTE1685-A.
For internal use
LTE1685-A: BTS point of view - Criteria and Timers (example 1)
No HO, No incoming X2 or S1 HO
IdleTimeThresLteNR (4)
IdleTimeThresX2 (5)
IdleTimeThresNbeNB (4) hours
5 10
LNREL deleted! X2 is closed! LNADJ and LNADJL(s) deleted!

LTE1685-A Removal of Neighbour Relations Closing of X2 Links Removal of NbeNB and NbCell
[LNREL] [LNADJ: x2LinkStatus] [LNADJ & LNADJL]
Criteria to • No handover to NR observed for • No NRs associated to this X2 link • No NR and no X2 link is available to
Removing/Closing longer than a configurable time • No incoming HO via this X2 is an enbControlled NbeNB for at
observed for longer than a least the configurable time
configurable time
HO Idle Timer idleTimeThresLteNR idleTimeThresX2 idleTimeThresNbeNB
Trigger to Re-start  NR is created  X2 becomes available  X2 becomes available
HO Idle timer  HO for NR is triggered  HO Request via this X2 is triggered  NbCell is selected for HO (X2/S1)
For internal use
No HO, No incoming X2 or S1 HO Incoming HO Request!
IdleTimeThresX2 (5)
5 10
LNREL is not deleted!
IdleTimeThresLteNR and IdleTimeThresX2 are restarted.
Criteria to • No handover to neighbour cell • No NRs associated to this X2 link • No NR and no X2 link is available to
Removing/Closing observed for longer than a • No incoming HO via this X2 is an enbControlled NbeNB for at
configurable time observed for longer than a least the configurable time
configurable time
For internal use
No HO, No incoming X2 or S1 HO Incoming X2 HO Request!
IdleTimeThresX2 (5)
5 10
X2 is not closed!
IdleTimeThresX2 is restarted.
LNREL deleted!
Removing/Closing observed for longer than a • No incoming HO via this X2 is an enbControlled NbeNB for at
configurable time observed for longer than a least the configurable time
configurable time
For internal use
No HO, No incoming HO (X2 or S1)
IdleTimeThresX2 (3)
5 10
If at least one LNREL still exists,
X2 is not closed.
LNADJ and corresponding

LNREL deleted! X2 is closed! LNADJL are deleted!
Removing/Closing observed for longer than a • No incoming HO via X2 is observed an enbControlled NbeNB for at
configurable time for longer than a configurable time least the configurable time
- NRs are removed first. The effective time needed to close X2 link is at least MAX(idleTimeThresLteNR,
idleTimeThresX2).
- The total time to delete an neighbor eNB and its cells is MAX(idleTimeThresX2,idleTimeThresLteNR) +
idleTimeThresNbeNB
For internal use
LTE1685-A: Network point of view
No HO, No incoming X2 or S1 HO
IdleTimeThresX2 (5)
5 10
ENB NR List: ENB5 ENB3

• LNADJ-1: ENB1  X2 link: unavailable
available ECGI 32
• LNADJL-1: ECGI 11 - LNREL-1 ENB1
• LNADJL-2: ECGI 12 - LNREL-2 ECGI 51
unavailable
 X2 link: available ECGI 31 ECGI 11,
• LNADJ-2: ENB2
• LNADJL-1: ECGI 21 - LNREL-3 ENB FreqC
• LNADJ-3: ENB3  X2 link: available
• LNADJL-1: ECGI 31 - LNREL-4 Cell-A ECGI 12
• LNADJL-2: ECGI 32 - LNREL-5 FreqC
• LNADJL-1: ECGI 41 - LNREL-6 ENB6
• LNADJ-5: ENB5  X2 link: available ECGI 61
ENB2
• LNADJL-1: ECGI 51 - LNREL-7 ENB4 ECGI 21
• LNADJL-1: ECGI 61 - LNREL-8 ECGI 41
For internal use
LTE1685-B: Re-validation of LTE Neighbour Relations
• The feature enables eNB to automatically update neighbour information when there are
modifications made (examples: PCI, CGI, Global eNB ID, or additional PLMN ID values).
• Re-validation procedures are not activated via feature flag but can be controlled using
these parameters:
Criteria for Re-Validation Related Parameters Description

Consecutive handover LNBTS:consecHoFailThres Activation: Threshold and periodic
execution failure timers should not be set to zero.
Re-start: When re-validation is
Periodic evaluation via S1 – LNBTS:s1PrdRevalWaitTmr
triggered.
wait timer X2 – LNBTS:x2PrdRevalWaitTmr
For internal use
• Pre-requisite: UE-based ANR should be supported in the cell for the specific neighbour
frequency.
• Active ANR mode is triggered by eNB to re-validate NR via CGI resolution.
- ReportStrongestCells and ReportCGI measurements are retrieved from a different UE (not the
UE which requests the handover) that can find the CGI belonging to the requested PCI.
• Newly reported neighbor information is created as additional neighbor eNB (LNADJ) and
neighbor cell (LNADJL).
• The corresponding LNREL for old LNADJL is kept but set to ‘invalid’ nrStatus.
Candidate for Re- All neighbours can be validated vi Both enbControlled and oamControlled* C-
Validation Plane IP address
Excluded from Re- • LNCEL:blacklistHoL:phyCellIdRange • PCI for that frequency is blacklisted for
Validation HO (blacklistHOL)
• LNHENB:pciFirst - pciLast • Configured as HeNB-PCI
* If the neighbour cell belongs to an oamControlled LNADJ, the eNB can change the corresponding LNREL to invalid status
and create a new enbControlled LNADJ object.
For internal use
• Consecutive handover execution failure

- Handover Command is included in RRC Connection Reconfiguration from eNB, followed by re-
establishment procedure that is initiated due to handover failure.
Handover Preparation procedures: MME
S1AP: Handover Required
eNB1 S1AP: Handover Command (TS1RELOCoverall starts…)

UE and expires – HO FAIL!
-- or --
RRC Connection Reconfiguration
eNB2
(+Handover Command) X2AP: Handover Request
X2AP: Handover Request Acknowledge (TX2RELOCoverall starts…)
and expires – HO FAIL!
RRC Connection Re-establishment Request

reestablishmentCause: Result:
handoverFailure or otherFailure • consecutive HO Failure count + 1
• compare with LNBTS: consecHoFailThres  if equal, ReportCGI!
For internal use
• Consecutive handover execution failure

- In case re-validation is triggered repeatedly, eNB waits for specific time before performing
measurements again. This prevents too frequent re-validation.
- ANR robustness level determines the following:
• Wait time between evaluation procedures
• Number of ReportCGI measurements are attempted for given unknown PCI before it is removed
from list of candidates for ECGI derivation (in case of failed ECGI resolution attempts).
Maximum number of ReportCGI requests
ANR Robustness Wait Time
before PCI is removed from list of to be
Level (minutes)
resolved PCIs
None 120 20
Very Low 60 30
Low 30 50
Middle 10 50
High 5 200
Very High 5 500
For internal use
• Periodic evaluation via wait timer

- Report CGI measurement is done to NRs regardless if there is no HO failure that occurred or
neighbour cell is not even selected as HO target due to changed configuration.
- Re-validation is periodically triggered after NR is used for HO preparation, if a configurable
minimum waiting time has expired.
• S1 – LNBTS:s1PrdRevalWaitTmr
• X2 – LNBTS:x2PrdRevalWaitTmr
- If more than this configured time elapsed since the last re-validation, then the eNB shall trigger
a re-validation upon the next handover attempt, (even if this doesn't lead to a handover
failure).
- PCIs of pure S1-handover relations may need to be more frequently validated as there is no
alignment via X2 interface
For internal use
LTE1685-C: Warning for PCI Confusion
• Starting RL50/RL35TD: eNB reports a Warning with fault ‘Neighbour cell ambiguity detected’
towards NetAct and BTS Site Manager. PCI collision is solved by manual PCI re-planning.
Neighbour cell ambiguity detected! PCI Collision!

eNB
• CGI of the cell which detected the collision
• Cell A
Cell A ReportCGI: ECGI-1 • PCI and frequency which are not unique
PCI-1, Freq1 • PCI1, Freq1
PCI-1, Freq1
• List of CGIs for which the collision was detected
• CGIs of CellA and NbCell1
ECGI1
PCI-1, Freq1
NbeNB1
For internal use
• Starting RL50/RL35TD
- Neighbour Relation Status (nrStatus) can either be ‘available’ or ‘unavailable’, which
determines if the CGI exists or not in eNB (LNADJL)
• NR status is evaluated in these events:

- Creation of LNADJL object (via X2, reportCGI or plan file)
- Modification of LNADJL parameters phyCellId or fDlEarfcn (via X2, reportCGI or plan file)
- Deletion of LNADJL (X2, plan file)
- Creation of LNREL object (measurement report, plan file)
- Creation and deletion of LNCEL object (plan file)
- eNB restart (as long as LNCEL creation causes BTS restart)
• Another case of configuration conflict - PCI Confusion - is not detectable.
For internal use
• Starting RL70/RL55TD: PCI confusion is detected via multiple CGI resolutions and warning will be
raised in NetAct and BTSSM. Re-assignment of PCI has to be corrected manually, but BTS notification
makes it easier to detect and resolve the conflict.
ENB Neighbour List:
eNB • LNADJL-1: ECGI-1  LNREL-1 (invalid)
(available)
• LNADJL-2: ECGI-2  LNREL-2 (available)
ReportCGI: ECGI-1
Cell A ReportCGI: ECGI-2 PCI Confusion!
PCI-1, Freq1 • CGI of the cell which detected the PCI confusion
PCI-1, Freq1
• Cell A
• PCI and frequency which are not unique in the eNB
• PCI1, Freq1
ReportCGI: ECGI-1 • List of CGIs of neighbour cells for which the confusion was
detected.
PCI-1, Freq1 ECGI2
• CGIs of NbCell1 and NbCell2
ECGI1 PCI-1, Freq1
PCI-1, Freq1 There could be some cases when PCI Confusion is not detected if LncelId
NbeNB2 and LcrId are different. Please check the loaded SW build. Case like this
should not happen beyond these LN7.0 and LNT5.0 builds: [ref: PR]
NbeNB1 • LN7.0_ENB_1407_551_07
• LNT5.0_ENB_1407_501_00
For internal use
• Neighbour Relation Status (nrStatus) • Unavailable and Invalid LNRELs are not
used for HO
• PCI and target frequency are known to eNB • If LNREL does not have corresponding
• No conflicts to other NR config LNADJL, and removeAllowed = false
• Can be used for HO  nrStatus = unavailable
AVAILABLE • Old LNRELs after re-validation are stored
in eNB database  nrStatus = invalid.
• New report CGI matches with an existing

LNREL.
UNAVAILABLE INVALID • When new PCI re-validation includes an
• PCI and target frequency Initially available LNREL but
invalid LNREL, eNB concludes that PCI-
are not known to eNB was changed after
• No corresponding LNADJL re-validation due to conflictFreq pair toggled between 2 conflicting
(new status in RL70/RL55TD) LNADJLs and it will raise PCI Confusion
Warning.
excluded in mobility functions
For internal use
LTE1685-D: BTS point of view - Criteria and Timers
No HO All criteria are met and new ReportCGI is received!
Next exchange is not yet allowed.
idleTimeThresNbeNBExch (4)
nbEnbExchWaitTmr (4)
hours
5 10
NR exchange!
Select NbeNBold to delete; nbEnbExchWaitTmr expires!
NbeNBnew is created! – prevents excessive exchanges
LTE1685-D
Criteria to NR Exchanging • Autonomous LTE Neighbour removal [actAutoLteNeighRemoval] is set to true.
• Autonomous LTE Neighbour exchange [idleTimeThresNbeNBExch] is greater than 0
• Number of LNAJDs reached the maximum allowed by operator number maxNumOfLnadjLimit
(FSMR2/FZM: 128; FSMR3: 256)
HO Idle Timer idleTimeThresNbeNBExch
Trigger to Re-start Exchange Timer  actAutoLteNeighRemoval is disabled.
[nbEnbExchWaitTmr]  idleTimeThresNbeNBExch is set to 0.
*Note: Timer is not stopped if the number of NbeNBs stored becomes smaller than the maximum
number supported by eNB.
• LTERLCR-3040 (LTE1685-D) was intended for highly loaded network, where maximum number of allowed neighbours is reached but still learning of new
neighbors is required.
For internal use
LTE1685-D: Autonomous LTE neighbour exchange at capacity limit
LTE1685-D NbeNB Set #1 NbeNB Set #2 NbeNB Set #3
Determination • CPlaneIpAddrCtrl = • No associated NR to this NbeNB • No associated NR to this NbeNB
of NbeNB Sets “enbControlled” (regardless of nrStatus) (regardless of nrStatus)
• All NRs associated with NbeNB are • No established X2 link
configured with removeAllowed =
“true“
• No HO for the same or greater
than the idleTimeThresNbeNBExch
Selection of Old • If Set#2 and Set#3 are empty, eNB • If Set#3 is empty, eNB checks Set#3 is first to be checked by eNB.
NbeNB to checks Set#1 and selects the Set#2 and selects the LNADJ with If not empty, the eNB will select
exchange among LNADJ whose corresponding highest LNADJid . among this list according to:
• Select LNADJ/NbeNB with longest
the NbeNB Sets LNREL has the longest idle time.
idle period
• If several NbeNBs in this list have
• If several NbeNBs in this list have
been idle for the same duration, been idle for the same duration, the
the highest LNADJid is selected. highest LNADJid is selected.
• If NbeNB Set#1 is empty, there will be no old LNADJ to be selected as candidate; hence, exchange process will not proceed.
For internal use
Interdependencies
Table of contents
• Prerequisite Features
• Impacted Features
For internal use
Interdependencies – LTE1685 Neighbour Relation Robustness
Pre-requisite Features
LTE782
LTE1685 ANR Intra-LTE, Intra-Frequency Fully UE-based
Neighbour Relation
Robustness LTE556
ANR Intra-LTE, Inter-Frequency Fully UE-based
• Validation process uses the CGI resolution mechanism to measure intra-frequency and inter-
frequency neighbour relations.
• Mandatory to enable:
- Activation flags of LTE782 and LTE556
- ANR Profile UE-based support for the default or specific target frequency.
For internal use
Pre-requisite Features
LTE1685 LTE1383
Neighbour Relation Cell specific neighbour
Robustness relation / PCI handling
• LTE1685 uses the legacy capabilities of LTE1383, such as ANR Robustness Level.
• Management of Neighbour Relations

- Cell-level NR checking
- Cell Validation/Re-validation
- ANR Profile management
For internal use
Impacted Features
LTE1685 LTE539
Neighbour Relation Central ANR
Robustness
• LTE539 feature uses NetAct Optimizer to calculate the most important X2 links for a certain
neighbour eNB.
• Caution is needed when using LTE539 and LTE1685  different mechanisms = different set of X2
- NetAct Optimizer creates new X2 links, which have OAM-controlled IP@, protecting them from
autonomous removal.
- It is possible that NetAct Optimizer may remove existing X2 links added by ANR mechanisms (eNB-
controlled IP@).
• Recommendation  If these features are activated in parallel, the following should be considered:
- Trigger LTE539 only to parts where analysis of X2 links is needed.
- After using NetAct Optimizer, the resulting X2 links are modified to eNB-controlled.
For internal use
Impacted Features
LTE1685 LTE771
Optimization of
Neighbour Relation Intra-LTE neighbour
Robustness relations
• LTE771 feature allows evaluation and blacklisting of bad-performing neighbour cells.

 LNREL.handoverAllowed = “forbidden”
• Blacklisted neighbour relations must be kept to avoid deletion then re-creation as non-blacklisted
NR.
For internal use
Benefits and Gains
Table of contents
For internal use
Benefits and Gains – LTE1685 Neighbour Relation Robustness
LTE1685 reduces the effort for manual neighbour management by using

automatic mechanisms for:
• Removal of unused NRs that results to an optimum neighbour list.
• Re-validation which keeps the neighbour configuration up to-date.
• Warning for PCI Confusion, making it easier to correct configuration conflicts.
For internal use
Let’s have a short coffee break!
For internal use
Configuration
Management
Table of contents
• Basic parameters
• Advanced parameters
For internal use
Configuration Management – LTE1685 Neighbour Relation Robustness
• Definition of terms and rules for parameter classification*

The ‘Basic Parameters’ category contains The ‘Advanced Parameters’ category contains
primary parameters which should be considered the parameters for network optimisation and
during cell deployment and must be adjusted to fine tuning:
a particular scenario:
• Decent network performance should be achieved without tuning
• Network Element (NE) identifiers these parameters
• Planning parameters, e.g. neighbour definitions, frequency, • Universal defaults ensuring decent network performance need
scrambling codes, PCI, RA preambles to be defined for all parameters of this category. If this is not
• Parameters that are the outcome from dimensioning, i.e. basic possible for a given parameter it must be put to the ‘Basic
parameters defining amount of resources Parameters’ category
• Basic parameters activating basic functionalities, e.g. power • Parameters requiring detailed system knowledge and broad
control, admission control, handovers experience unless rules for the ‘Basic Parameters’ category are
• Parameters defining operators’ strategy, e.g. traffic steering, violated
thresholds for power control, handovers, cell reselections, basic • All parameters (even without defaults) related to advanced and
parameters defining feature behaviour very complex features
* - purpose: categories of parameters have been defined to simplify network parameterization. Parameterization effort shall be focused mainly on parameters included in basic
category. Categorization will be reflected in a ‘view’ definition in NetAct CM Editor (released in RL60) i.e. parameters will be displayed according to the category: either in the ‘Basic
parameters’ view or the ‘Advanced parameters’ view.
For internal use
New parameter
actAutoLteNeighRemoval Activate autonomous removal of LTE neighbours
Object: LNBTS Activates autonomous removal of unused LTE neighbour relation and
Range: {true, false} or {1,0} neighbour information.
Step: 1
Unit: - Note:
Default: false (0) • Restart of eNB is not needed after modification.
Multiplicity: 1 • Upon activation, eNB monitors at the end of every hour if the idle
Modification: On-line thresholds for NR, X2, NBeNB/NbCell have been exceeded.
Category: basic • This activation flag affects sub-feature LTE1685–A only. Other sub-
Parameter ID: 325210 features (B and C) re-use the legacy mechanisms for CGI measurements.
Hidden: No - The activation flag has no impact on the validation/re-validation
(PKDB link) process.
For internal use
New parameter
removeAllowed Remove allowed
Object: LNREL Inhibits autonomous removal of the neighbour relation by eNB.
Range: {true, false} or {1,0}
Step: 1 Migration Rule (RL60  RL70):
Unit: - • Protection of blacklisted NR – If LNREL:handoverAllowed is not equal
Default: true (1) to’ ‘allowed’ then LNREL:removeAllowed must be set to ‘false’.
Multiplicity: 1
Modification: On-line
Category: basic
Parameter ID: 325211
Hidden: No
(PKDB Link)
For internal use
LTE1685-C: Warning for PCI Confusion – Modified parameter
nrStatus Neighbour relation status
Object: LNREL Indicates the status of the neighbour relation.
Range: {unavailable (0), unavailable:
available (1), • if the LNADJL or LNCEL object which is referenced by the CGI does not exist
invalid (2)} • not considered for HO
Step: 1 available:
Unit: - • if the LNADJL or LNCEL object which is referenced by the CGI exists and the
Default: - neighbour relation is unambiguous.
Multiplicity: 1 • considered for HO if not blacklisted, i.e. if handoverAllowed is not set to
Modification: Not modifiable 'forbidden'.
Category: basic invalid:
Parameter ID: 139253 • if the relation becomes ambiguous due to modification of the PCI or carrier
Hidden: No frequency of a neighbour cell or creation of a new neighbour cell.
• neighbour relation is considered as not reliable because a CGI measurement
(PKDB Link)
reported a different CGI for the PCI of the neighbour cell the neighbour relation
refers to or because eNB detected a conflict with another existing neighbour
relation
NOTE:
• Invalid NR information (LNREL) is not used for HO but will be kept in eNB
database until deleted by LTE1685-A mechanism, unless operator has it
50 26/07/2016 explicitly/ Gay
© Nokia 2014 - MBB Customer Support Network Engineering deactivated
Calaranan activation flag actAutoLteNeighRemoval.
For internal use • Value set by the system
LTE1685-D: Related parameter
maxNumOfLnadjLimit Max number of LNADJ instances
Object: LNBTS This parameter configures the allowed number of LNADJ instances in the
Range: 0 - 255 eNB.
Step: 1
Unit: - NOTE:
Default: 256 • For FSMr3, up to 256 instances can be configured.
Multiplicity: 1 • For FSMr2 and for FZM HW, the value should not exceed 128.
Modification: On-line • This parameter must never be configured to a value higher than the system
Category: basic informs. For instance in FSMr2, if maxNumOfLnadjLimit is set between 129-
Parameter ID: 328443 256, configuration will not be sent to eNB and BTS Site Manager will indicate
Hidden: No the range violation:
(PKDB Link) - For Offline case: based on static setting in MRBTS-unitList
- For Online case: based on HW information
• If the number of X2 links configured in eNB is in maximum value [256],
processing performance is not compromised nor will not cause overloading in
eNB.
For internal use
New structure
anrIdleTimeThresLte ANR Idle Time Thresholds for LTE
Object: LNBTS This structure includes the 'idle time threshold' values used by eNB for
Range: Structure autonomous removal of LTE Neighbour resources
Step: -
Unit: - Note:
Default: - • Checking of autonomous retrieval happens only at the expiry of
Multiplicity: 1 observation period (every 1 hour) to reduce performance load for the eNB.
Modification: On-line • Observation period is restarted when these events occur:
Category: advanced - HO preparation is triggered
Parameter ID: 325203 - Neighbour object is newly created
Hidden: No
(PKDB Link)
For internal use
New parameter
idleTimeThresLteNR Idle Time Threshold for LTE Neighbour Relations
(anrIdleTimeThresLte)
Object: LNBTS The eNB may autonomously remove a LTE NR, if the LTE NR is not used for
Range: {2 .. 192} handover for at least the time 'idleTimeThresLteNR'.
Step: 1h
Unit: hours Note:
Default: 72h • LTE NRs which are 'reserved by operator' are not autonomously removed
Multiplicity: 1 by eNB.
Modification: On-line • The eNB checks once per hour if a LTE NR has to be removed.
Category: advanced • It is recommended to configure 'idleTimeThresLteNR‘ smaller than
Parameter ID: 325204 'idleTimeThresX2' to avoid that one eNB may autonomously close an X2
Hidden: No link and the peer eNB re-establishes the X2 link again, because
(PKDB Link) autonomous removal of associated unused Neighbour Relations did not
finish yet.
• Observation period is restarted when these events occur:
- HO preparation is triggered for a NR
- NR is newly created
For internal use
New parameter
idleTimeThresX2 Idle Time Threshold for X2 links
Object: LNBTS If for an enbControlled X2 link no LTE Neighbour Relation exists and if for at
Range: {2 .. 192} least the time “idleTimeThresX2” no X2 handover is received, then the eNB
Step: 1h autonomously closes the X2 link.
Unit: hours Note:
Default: 80h • OamControlled X2 links are not autonomously closed by eNB.
Multiplicity: 1 • The eNB checks once per hour if a X2 link has to be closed.
Modification: On-line • It is recommended to chose 'idleTimeThresX2' to be larger than
Category: advanced 'idleTimeThresLteNR' to avoid that one eNB may autonomously close an X2 link
and the peer eNB re-establishes the X2 link again, because autonomous removal
of associated unused Neighbour Relations did not yet occur.
Hidden: No • Since NRs associated to the X2 link should be removed first, the minimum time
(PKDB Link) that X2 link will become inactive is MAX(idleTimeThresLteNR,idleTimeThresX2)
• Observation period is restarted when these events occur:
- HO Request received via X2
- X2 becomes available
For internal use
New parameter
idleTimeThresNbeNB Idle Time Threshold for Neighbour eNBs
Object: LNBTS If for at least the time idleTimeThresNbeNB, an enbControlled NbeNB with
Range: {2 .. 192} no NR and no X2 link available, then the eNB removes the LNADJ/ LNADJL
Step: 1 objects associated with the NbeNB
Unit: hours
Default: 48h Note:
Multiplicity: 1 • Neighbour eNBs and Neighbour Cells which are associated with an
Modification: On-line oamControlled LNADJ object are not autonomously removed by eNB
Category: advanced • The eNB checks once per hour if a LTE NR has to be removed
Parameter ID: 325206 • Observation period is restarted when these events occur:
Hidden: No - Newly created NR is available
(PKDB Link) - X2 becomes available
- HO is triggered via S1
For internal use
LTE1685-D: Re-validation of LTE Neighbour Relations
New parameter
idleTimeThresNbEnbExch Idle Time Threshold for Neighbour eNB Exchange
Object: LNBTS If the maximum number of LTE neighbour eNBs is already stored, then a stored
Range: {0 .. 96} neighbour eNB may be exchanged against a neighbour eNB newly detected via
Step: 1 CGI measurement only, if the idle time for the stored neighbour eNB is at least
Unit: hour equal to idleTimeThresNbeNBExch.
Default: 18
If idleTimeThresNbeNBExch is set to '0', then no exchange of LTE neighbour eNBs
Multiplicity: 1
is triggered.
Category: advanced Note:
Parameter ID: 350148 • The eNB will choose among the 3 sets, whether which old NbeNB is suitable
Hidden: No for exchange process.
(PKDB Link) • If all neighbour eNBs are used for HO, exchange is still not possible even if the
maximum allowed LNADJs are reached.
For internal use
LTE1685-D: Re-validation of LTE Neighbour Relations
New parameter
nbEnbExchWaitTmr Neighbour eNB Exchange Wait Timer
Object: LNBTS This parameter sets the minimum time for eNB to wait before another exchange
Range: {0 .. 96} process is allowed to occur again. It prevents the next exchange process to
Step: 1 trigger too soon and too frequently.
Unit: hour
Note:
Default: 6
• When autonomous NbeNB exchange is disabled (either by setting
Multiplicity: 1
actAutoLteNeighRemoval to ‘false’ or idleTimeThresNbeNBExch to zero.
Modification: On-line • This timer is not stopped if the number of NbeNBs stored becomes smaller
Category: advanced than the maximum number supported by eNB.
Hidden: No
(PKDB Link)
For internal use
Related parameter
anrRobLevel ANR robustness level
Object: LNBTS Specifies the level of robustness of UE-based ANR functions.
Range: {none (0), very low(1),
low(2), middle(3), Note:
high(4), very high(5)} • For high level of robustness, eNB attempts for a longer time period to
Step: 1 resolve a detected unknown neighbour cell via UE-based ANR before
Unit: - stopping these attempts.
Default: middle • For high level of robustness, the minimum wait time between re-
Multiplicity: 1 validations of the same Neighbour Relation becomes shorter
Category: advanced
Hidden: No
(PKDB Link)
For internal use
New parameter
consecHoFailThres Consecutive handover execution failure re-validation
threshold
Object: LNBTS If for a LTE Neighbour Relation (NR) 'consecHoFailThres' consecutive
Range: { 0, 1 .. 15 } handover execution failures are observed, then the eNB triggers a re-
Step: 1 validation for this NR via CGI measurement (if CGI measurements are
Unit: - allowed / UE-based ANR is activated).
Default: 3
Multiplicity: 1 Note:
Modification: On-line • This parameter controls LTE1685-B functionality.
Category: advanced • If 'consecHoFailThres=0', then no re-validation is triggered.
Parameter ID: 325207 • If modified online, the new value will be used for all succeeding
Hidden: No handover failure
(PKDB Link)
For internal use
New parameter
s1PrdRevalWaitTmr S1 periodical revalidation wait timer
Object: LNBTS If for a LTE Neighbour Relation (NR) a S1 handover preparation is started
Range: { 0, 10, 30, 60, 120, and since the last validation of the NR at least the time
180, 240, 480, 960, 1440, 2160, 2880, 's1PrdRevalWaitTmr' has elapsed, then eNB triggers a re-validation for this
4320, 5760, 7200, 10080 } NR via CGI measurement (if CGI measurements are allowed / UE-based
Step: ANR is activated).
Unit: minute
Default: 60 Note:
Multiplicity: 1 • This parameter controls LTE1685-B functionality.
Modification: On-line • If 's1PrdRevalWaitTmr' is set to '0', then no re-validation is triggered.
Category: advanced • After online modification, new value will be observed for all HO
Parameter ID: 325208 preparations.
Hidden: No • If re-validation is triggered, wait time is restarted immediately (no need
(PKDB Link) to wait for CGI measurement)
For internal use
New parameter
x2PrdRevalWaitTmr X2 periodical revalidation wait timer
Object: LNBTS If for a LTE Neighbour Relation (NR) an intra-eNB or X2 handover
Range: { 0, 10, 30, 60, 120, preparation is started and since the last validation of the NR at least the
180, 240, 480, 960, 1440, 2160, 2880, time 'x2PrdRevalWaitTmr' has elapsed, then eNB triggers a re-validation
4320, 5760, 7200, 10080 } for this NR via CGI measurement (if CGI measurements are allowed / UE-
Step: based ANR is activated).
Unit: minute
Default: 480 Note:
Multiplicity: 1 • This parameter controls LTE1685-B functionality.
Modification: On-line • If 'x2PrdRevalWaitTmr' is set to '0', then no re-validation is triggered.
Category: advanced
Hidden: No
(PKDB Link)
For internal use
Deployment
Aspects
Network graphic boxes Network element boxes
Table of contents
• BTS-Level
• Cell-Level
• New and Related Alarms
For internal use
Deployment Aspects – LTE1685 Neighbour Relation Robustness
BTS Level Activation flag for
Neighbour Deletion
Control parameters
for NR re-validation
For internal use
BTS Level
Controlling parameters for NR re-validation
• To make PCI confusion detection more sensitive and faster, a configuration may be chosen which
leads more frequently to PCI re-validations. This can be done by:
- Reduction of the value for ‘consecHoFailThres’
- Reduction of ‘s1/x2PrdRevalWaitTmr’
- Increase of ANR robustness level
• The downside of making PCI confusion detection more sensitive is an increased load for network
and UE.
For internal use
BTS Level
Controlling parameters for NR re-validation
• Since the periodical re-validation trigger is applied to all available NRs, it is expected that a decrease of
‘consecHoFailThres’ is the most effective method for improving the sensitivity of PCI confusion detection.
• If the operator re-configures the CGI of a neighbour cell from CGI#1 to CGI#2 and afterwards back from
CGI#2 to CGI#1 and if this sequence occurs within the time given by ‘ idleTimeThresLteNR’, then the eNB
may misinterpret this series of reconfigurations as a PCI confusion.
• Even though it is expected that such a sequence of reconfigurations will be extremely rare, it is
recommended to consider this possibility when the PCI confusion warning is raised.
For internal use
BTS Level
• Configuration of Idle Time Thresholds for NR Autonomous Deletion
- New Structure
• ANR Profiles
- Default :
• ANR Profile-0
• Applies to all inter-freq.
(empty value)
- Carrier-specific :
• ANR Profile-1 to 31
• Target carrier freq. is
defined and unique to
other ANRPRL objects.
For internal use
BTS Level
• Neighbour Relations
- LNADJ :
Autonomous deletion and re-validation applies only to NR with eNB-controlled C-Plane

IP address.
For internal use
Cell Level
- LNADJ L:
• Physical Cell ID should be unique to the other
LNADJL instances to avoid PCI Confusion.
• If PCI, ECGI and target carrier frequency of this
neighbour cell is present in eNB database, this
NR is considered known and considered for
mobility events, i.e. handovers.
For internal use
Cell Level
- LNREL objects are created via ANR only when HO Caution! Blacklisted NR might be
is triggered to this particular neighbour cell. deleted then added again via ANR,
losing its blacklisting information.
LTE1685 will fully work on this NR,

allowing automatic deletion, re-
validation and warning to PCI
confusion when respective criteria
are fulfilled.
Invalid
If LNREL with ‘Invalid’ status is
removed via plan file, operator
must use new instance ID for the
new LNREL.
If HO Allowed=forbidden:
Protection of blacklisted NR from
autonomous deletion
For internal use
Cell Level
- Migration Rule [RL60/RL45TD  RL70/RL55TD]
Before activation of LTE1685, blacklisted NR

should be protected from deletion:
If LNREL:handoverAllowed is set to ‘forbidden’

then LNREL:removeAllowed must be set to ‘false’.
For internal use
New Alarm
Fault name PCI confusion detected
Fault ID and name 6279: EFaultId_PciConfusionDetectedAl
Reported alarms 7655 CELL NOTIFICATION
Unit status Working
LED display Blinking yellow
Based on CGI measurements it has been detected that two or more cells operating on the same carrier
frequency use the same PCI. Alarm contains:
1. CGI of the cell which detected the PCI confusion.
Meaning 2. The CGI of the NR which is switched from available to invalid
3. The CGI of the NR which is switched from invalid to available
4. [CRL6141] Additional information on the affected LNREL/LNRELW (incl. WCDMA NR info, if applicable).
Unit actions after fault None
detect
Detection method The neighbour relation states 'invalid' and 'available' are exchanged between two LNREL instances of
start/transient the same cell (pointing to the same PCI and frequency) after reception of a CGI measurement report.
Detection method cancel None
Effect Possibly increased handover failure rate for the affected cell.
Check for E-UTRAN cells that operate on the same frequency layer and use the same PCI and that are in
Instructions close vicinity. Re-assign PCIs for the discovered cells.
For internal use
Related Alarm
Fault name Neighbour cell ambiguity detected
Fault ID and name 6274: EFaultId_NeighbourCellAmbiguityDetected
Reported alarms 7655 CELL NOTIFICATION
Unit status Working
LED display Stable green
A handover target cell cannot be uniquely elected because several candidates are available for a certain
PCI value and carrier frequency
Meaning
Additional info: CGI of the cell which detected the condition, PCI and frequency which is not unique, List
of CGIs for which the collision was detected
Unit actions after fault Ambiguous PCI will not be used for handover.
detect
A measurement report is received from UE containing a cell, which physical identity and frequency pair
Detection method
is not unique in the neighbour configuration and no neighbour relation exists for any of those cells nor
start/transient
UE based ANR feature is enabled.
Do not cancel the alarm. The system automatically cancels the alarm when the fault has been
Detection method cancel
corrected.
Effect No handover can be performed to cells with the affected PCI and frequency.
Add the LNREL object pointing to the correct neighbour to allow the handover or enable the UE based
Instructions
72 26/07/2016 © Nokia 2014 - MBB ANR.
Customer Support Network Engineering / Gay Calaranan
For internal use
Related Alarm
Fault name Maximum number of neighbour eNBs/cells exceeded
Fault ID and name 6265: EFaultId_MaximumNumberOfNeighbourEnbsOrCellsExceeded
Reported alarms 7652 BASE STATION NOTIFICATION
Unit status Working
LED display Stable green
Meaning This alarm indicates that the maximum number of LNADJ and/or LNADJL was exceeded in eNB.
Unit actions after fault The new NR object will not be stored.
detect
The alarm is raised if an LTE neighbour cell, which is reported by a UE via ANR (Automatic Neighbour
Detection method
Relation) specific measurements could not be stored because the maximum number of LNADJ or
start/transient
LNADJL instances is reached.
The fault has no effect on the base station operation but LNADJ and/or LNADJL object was not stored
Effect
in eNB
1.Check if maximum number of LNADJ was reached. [FSMr2, FZM: 128, FSMr3: 256 LNADJ objects]. If
yes, check if there are LNADJ objects that can be manually deleted. This makes space for new LNADJ
information.
Instructions
2.Check if maximum number of LNADJL was reached. [(Accdg. to LTERLCR-2500) 64 LNADJL objects
73 26/07/2016 © Nokia 2014 - MBB per LNADJ]
Customer If Network
Support yes, check if there
Engineering / Gayare LNADJL objects related with LNADJ object that can be manually
Calaranan
For internal use deleted. This makes space for new LNADJ information.
Please fill in a short survey
Your feedback is valuable to us!
KIND REQUEST TO YOU:
PLEASE FILL IN THE SURVEY NOW
LINK DISTRIBUTED IN THE CHAT PANEL
To get the certificate proving participation in the training please login

with your NSN credentials and download the certificate after
submitting yours marks.
For internal use
Performance
Aspects
Table of contents
• UE measurement (Drivetest)
• ENB Counters and KPI
For internal use
Performance Aspects – LTE1685 Neighbour Relation Robustness
Feature monitoring
UE Measurements
• Drive test KPIs can be used as basis in analyzing the impact of feature LTE1685.
• Such measurements and analysis can be obtained via Nemo, XCAL or TEMS traces or
logs.
• Neighbor relation measurements
- RSRP (Reference Signal Received Power)
- RSRQ (Reference Signal Received Quality)
- RSSI (Received Signal Strength Indicator)
- Ratio serving/neighbor (RSRP, RSRQ, RSSI)
For internal use
Feature monitoring
ENB Measurements
• No new counters or new KPI formula are introduced for LTE1685.
• Re-Validation of Neighbour Relations are legacy mechanisms of earlier ANR features. Similar counters
are updated for LTE1685.
Number of Report CGI Description
Requests
REPORT_CGI_REQ (M8008C10) This counter provides the total number of attempts to retrieve the CGI of a
neighbour cell from UE.
(LTE_RRC measurements) Trigger event: Transmission of RRCConnectionReconfiguration including
‘reportCGI' measurement configuration to the UE. - (3GPP TS 36.331)
Use case: CGI Success Ratio [LTE_1136a]
CGI_DERIVATION_ SUCC_CGI_REPORTS
= ×100%
SUCCESS_RATE REPORT_CGI_REQ
For internal use
Feature monitoring
ENB Measurements
• No new counters or new KPI formula are introduced for LTE1685.
• Re-Validation of Neighbour Relations are legacy mechanisms of earlier ANR features. Similar counters
are updated for LTE1685.
Number of successful CGI Description
Reports
SUCC_CGI_REPORTS (M8008C11) This counter provides the number of CGI measurement reports received from
UE.
(LTE_RRC measurements) Trigger event: Reception of RRC: Measurement Report message including a
'reportCGI' measurement result. - (3GPP TS 36.331)
Use case: CGI Success Ratio [LTE_1136a]
CGI_DERIVATION_ SUCC_CGI_REPORTS
= ×100%
SUCCESS_RATE REPORT_CGI_REQ
For internal use
ENB measurements
Feature impact How to measure?
IMPROVED HANDOVER SUCCESS RATE (X2-based) KPI 1: E-UTRAN Total HO Success Ratio, Inter eNB X2 based
• Periodic re-validations can resolve handover (LTE_5058c)
preparation failures caused by wrong NRs = 100*sum(SUCC_INTER_ENB_HO) / sum(INTER_ENB_HO_PREP -
FAIL_ENB_HO_PREP_OTHER)
- misleading or wrong CGI measurements
• This KPI describes the total inter eNB X2 based HO Success Ratio
- Outdated or old configuration due to from HO preparation start until successful HO execution.
PCI/Freq modification
- NbCell or NbeNB replacement KPI 2: E-UTRAN HO Success Ratio, Inter eNB X2 based (LTE_5048b)
= 100*sum(SUCC_INTER_ENB_HO) / sum (ATT_INTER_ENB_HO)
• Repeating CGI resolution to update neighbour • This KPI describes the success ratio for the inter eNB X2 based
information will improve HO performance. handover execution phase, when the source eNB receives
information that the UE successfully is connected to the target cell
within target eNB.
• Lower number of failures in X2-Based Inter-eNB KPI 3: E-UTRAN HO Failure Ratio, Inter eNB X2 based (LTE_5055b)
HO events =100*sum(INTER_ENB_HO_FAIL) / sum (ATT_INTER_ENB_HO)
• This KPI describes the ratio of failed inter eNB X2 based
handovers related to all attempted inter eNB handovers. This
KPI represents the case of a failed Handover when all UE resources
are still allocated for the UE.
For internal use
ENB measurements
IMPROVED HANDOVER SUCCESS RATE (S1-based) KPI 1: E-UTRAN Total HO Success Ratio, inter eNB S1 based
• Periodic re-validations can resolve handover (LTE_5084b)
preparation failures caused by wrong NRs = 100*sum(INTER_ENB_S1_HO_SUCC) / sum(INTER_ENB_S1_HO_PREP -
INTER_S1_HO_PREP_FAIL_OTHER)
- misleading or wrong CGI measurements
• This KPI describes the total inter eNB S1 based HO Success Ratio
- Outdated or old configuration due to from HO preparation start until successful HO execution.
PCI/Freq modification
- NbCell or NbeNB replacement KPI 2: E-UTRAN HO Success Ratio, inter eNB S1 based (LTE_5082a)
= 100*sum(INTER_ENB_S1_HO_SUCC) / sum(INTER_ENB_S1_HO_ATT)
• Repeating CGI resolution to update neighbour • This KPI describes the success ratio for the inter eNB S1 based
information will improve HO performance. handover execution phase, when the source eNB receives
information that the UE successfully is connected to the target cell
within target eNB.
• Lower number of failures in S1-Based Inter-eNB KPI 3: E-UTRAN HO Failure Ratio, inter eNB S1 based (LTE_5083a)
HO events =100*sum(INTER_ENB_S1_HO_FAIL) / sum(INTER_ENB_S1_HO_ATT)
• This KPI describes the ratio of failed inter eNB S1 based handovers
related to all attempted inter eNB handovers. This KPI represents
the case of a failed Handover when all UE resources are still
allocated for the UE.
For internal use
ENB measurements
IMPROVED RETAINABILITY KPI 1: E-UTRAN E-RAB Retainability Rate, RAN View, RNL Failure with
• Retainability describes seamless mobility, UE Lost (LTE_5581b)
without termination against the user = 100*sum(ERAB_REL_ENB_ACT_QCI1 + ERAB_REL_ENB_ACT_QCI2 +
ERAB_REL_ENB_ACT_QCI3 + ERAB_REL_ENB_ACT_QCI4 + ERAB_REL_ENB_ACT_NON_GBR)
preferences. / (sum(ERAB_IN_SESSION_TIME_QCI1 + ERAB_IN_SESSION_TIME_QCI2 +
• With higher HO success rate, retainability KPIs ERAB_IN_SESSION_TIME_QCI3
+ ERAB_IN_SESSION_TIME_QCI4 +ERAB_IN_SESSION_TIME_NON_GBR) / (60 * 60))
should also improve due to avoided call drops.
• This KPI provides how often an end-user abnormally loses due to RNL failure with UE
lost cause an E-RAB during the time the E-RAB is active.
• Lower number of E-RAB Dropped calls is KPI 2: E-UTRAN E-RAB Drop Ratio, RAN View (LTE_5025d)
expected. =100*sum(ENB_EPS_BEARER_REL_REQ_RNL+ ENB_EPS_BEARER_REL_REQ_TNL+
ENB_EPS_BEARER_REL_REQ_OTH)/ sum(EPC_EPS_BEARER_REL_REQ_NORM+
EPC_EPS_BEARER_REL_REQ_DETACH+ EPC_EPS_BEARER_REL_REQ_RNL+
EPC_EPS_BEARER_REL_REQ_OTH + ENB_EPSBEAR_REL_REQ_RNL_REDIR+
ENB_EPS_BEARER_REL_REQ_NORM + ENB_EPS_BEARER_REL_REQ_RNL+
ENB_EPS_BEARER_REL_REQ_TNL+ ENB_EPS_BEARER_REL_REQ_OTH+
PRE_EMPT_GBR_BEARER + PRE_EMPT_NON_GBR_BEARER)
• This KPI describes the ratio of abnormally released (dropped) E-RABs from RAN point
of view.
For internal use
ENB measurements
IMPROVED RETAINABILITY KPI 3: E-UTRAN Radio Bearer Drop Ratio (LTE_5004a)
• Retainability describes seamless mobility, = 100*sum(RB_REL_REQ_RNL+ RB_REL_REQ_OTHER) /
without termination against the user sum(RB_REL_REQ_NORM_REL+ RB_REL_REQ_DETACH_PROC+
preferences. RB_REL_REQ_RNL+ RB_REL_REQ_RNL_REDIR+ RB_REL_REQ_OTHER)
• With higher HO success rate, retainability KPIs • The KPI shows the ratio of dropped Radio Bearers.
should also improve due to avoided call drops.
• Lower E-RAB Drops per PDCP SDU volume KPI 4: E-UTRAN E-RAB Drops per PDCP SDU volume, User Perspective
(eNB pre-emptions excluded) (LTE_5812b)
=100*sum ((EPC_EPS_BEARER_REL_REQ_RNL +
EPC_EPS_BEARER_REL_REQ_OTH + ENB_EPS_BEARER_REL_REQ_RNL +
ENB_EPS_BEARER_REL_REQ_TNL + ENB_EPS_BEARER_REL_REQ_OTH -
PRE_EMPT_GBR_BEARER - PRE_EMPT_NON_GBR_BEARER)) /
(sum(PDCP_SDU_VOL_UL + PDCP_SDU_VOL_DL)
• This KPI describes the amount of E-RAB drops per PDCP SDU volume
from user perspective point of view.
For internal use
Compliance
Aspects
Table of contents
• 3GPP References
For internal use
Compliance Aspects – LTE1685 Neighbour Relation Robustness
• 3GPP TR 36.902 – E-UTRA Self-configuring and self-optimizing network (SON) use cases
and solutions
• 3GPP TS 36.133 – E-UTRA Requirements for support of radio resource management
• 3GPP TS 36.331 – E-UTRA Radio Resource Control Protocol specification
• 3GPP TS 36.413 - E-UTRA S1 Application Protocol
• 3GPP TS 36.423 - E-UTRA X2 Application Protocol
For internal use
References – LTE1685 Neighbour Relation Robustness
References
3GPP Specifications
CFAM LTE1685 LTE Neighbour Robustness by Mathias Pieroth
LTE SFS Modules CFAM Common Parameter Module
Network Engineering Information (NEI) slides:

• LTE492 – ANR with OAM-Extension
• LTE782 – ANR Intra-LTE, Intra-frequency Fully-UE based
• LTE556 – ANR Intra-LTE, Inter-Frequency Fully-UE based
• LTE1383 – Cell-Specific Neighbour Relation and PCI Handling
• LTE771 – ANR Optimization of Intra-LTE Neighbour Relations
For internal use
For internal use

LTE1685

Uploaded by

Copyright:

Available Formats

LTE1685

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

LTE1685

Uploaded by

Copyright:

Available Formats

Neighbour Relation

Network Engineering Information

Warning for PCI

TDD LTE RL release eNodeB NetAct

Flexi Zone Micro (FZM) RL release eNodeB NetAct

Abbreviation Full Name

NR Neighbour Relation – pertains to LNREL objects

NbeNB Neighbour eNB – refers to LNADJ instances

NbCell Neighbour cell – corresponds to LNADJL

PCI Physical Channel Identity

CPlaneIP@ Control Plane IP Address

• Activation flag → LNBTS:actAutoLteNeighRemoval

- Manual deletion of neighbour objects (LNREL, LNADJL, LNADJ) is required.

OFF eNB is increased from 24 to 64 cells (LNADJLs per LNADJ).

• Activation flag → LNBTS:actAutoLteNeighRemoval

- Activation flag affects sub-features A and D (Autonomous removal and

ON - HINT: Manual deletion of NR via NetAct/BTSSM is still possible.

- Unconfirmed IP Address – why it exists?

Excluded from removal • X2 links with oamControlled C-Plane IP address

LNREL deleted! X2 is closed! LNADJ and LNADJL(s) deleted!

LNADJ and corresponding

ENB NR List: ENB5 ENB3

Criteria for Re-Validation Related Parameters Description

• Consecutive handover execution failure

eNB1 S1AP: Handover Command (TS1RELOCoverall starts…)

RRC Connection Re-establishment Request

• Consecutive handover execution failure

• Periodic evaluation via wait timer

Neighbour cell ambiguity detected! PCI Collision!

• NR status is evaluated in these events:

• Another case of configuration conflict - PCI Confusion - is not detectable.

• New report CGI matches with an existing

• Management of Neighbour Relations

• LTE771 feature allows evaluation and blacklisting of bad-performing neighbour cells.

Benefits and Gains

LTE1685 reduces the effort for manual neighbour management by using

• Definition of terms and rules for parameter classification*

Controlling parameters for NR re-validation

Controlling parameters for NR re-validation

Autonomous deletion and re-validation applies only to NR with eNB-controlled C-Plane

LTE1685 will fully work on this NR,

Before activation of LTE1685, blacklisted NR

If LNREL:handoverAllowed is set to ‘forbidden’

To get the certificate proving participation in the training please login

CFAM LTE1685 LTE Neighbour Robustness by Mathias Pieroth

LTE SFS Modules CFAM Common Parameter Module

Network Engineering Information (NEI) slides:

You might also like