Configuration Management: Radio Network Design For Roll Outs

Configuration Management
Radio Network Design for Roll Outs
Soc Classification level

1 © Nokia Siemens Networks Presentation / Author / Date
Contents
• Parameter structure (MOC) and Site Configuration

• Idle Mode Mobility Configuration
• Connected Mode Mobility Configuration
• Neighbours Configuration
• S1 Handover Configuration
• Blacklisting
• Exercise
• Plan Creation Methods
• Exercise

Parameter structure (Managed Object
Classes) and Site Configuration

Introduction
• Parameters are organised into Managed Object Classes (MOC) that follow a
hierarchical structure containing three main areas :
– Radio Network Parameters (RNW) Focus of the training
– Site Configuration Parameters (HW)
– LTE BTS Transport Parameters (FTM)
• Majority of MOCs are stable between releases but some of them can be
added/removed between releases. Same applies for the parameters under each
MOC. They can be found in NOLS Operating Documentation
• Not all MOCs are mandatory (i.e. they don’t need to be configured)
• This section is about configuring different MOCs based on the network

characteristics needed when creating a site configuration file (also can be used as
site template)

Managed Object Hierarchy (RL30)
ANTL
BTSSCL LCELL
PLMN MRBTS
MHA
LNBTS
RET
FTM
RMOD Site
Configurati
SMOD
ADIPNO on
Parameters
CTRLTS MTRACE
SYNC STPG
LNADJ LNADJL
TAC LTAC
GTPU
IPNO IEIF IVIF
LNCEL CDFIM
ETHLK QOS
PRMNL GFIM GNFL
IPSECC IPRT
LNADJG IAFIM
CERTH INTP
LNADJW IRFIM
UNIT IPRM
LNADLP LNHOG
AMRG IHCP
SCTP LNHOIF
PPTT BFD
LNMME LNHOW
OAMPRF BFDGRP
MODRED MODPR LNREL
TOPIK
MORED MOPR REDRT FTM
TWAMP Parameters
RNW UFFIM
Parameters
5 © Nokia Siemens Networks
Parameter Configuration
Parameter configuration can be divided into:

• Site specific parameters: Those that need to be planned/allocated separately for
each site
• ‘Site template’ parameters: Those that can be assigned a value that is pre-defined
in a template as they don’t vary across the sites of a network. They can be:
• Operator specific: E.g. mnc, mcc, plmnId
• ‘Default’ parameters
• References for parameter configuration are:

• PDDB: http://pddb.inside.nokiasiemensnetworks.com/pddb/
• PKDB: http://pkdb1.emea.nsn-net.net:8080/pkdbWebToolLTE/
• SCF: System Configuration File
• Configuration Management IMS Folder:
• https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/436539771
• As part of PKDB (link above) scenarios

System Configuration Files (SCF) MOC: Managed Object
Overview Classes
• Golden System Configuration Files (SCF) are xml files containing the basic MOCs
and related parameters to create a commissioning file or a template for a site
• Vendor specific (i.e. hidden parameters) are not part of the SCF
• Contents of the SCF vary depending on the LTE variant (FDD or TDD) and on the
different releases
• Even within the same release, there are different versions of SCF with newer
versions containing more features implemented in the meantime
• Once P8 milestone for a Release has been reached the contents of the SCF are
frozen. Recommendation is always to use the latest SCF available

System Configuration Files (SCF)
Structure
SCF can not be used directly as a template file for an eNB
due to:
• MOCs and instances need to be adapted for each case
• Only 1 LNCEL object (normally, 3 LNCEL objects are
required)
• Only ANTL-1 to ANTL-6 are defined (normally, up to ANTL-
12 is required)
• Some parameters, operator specific, haven’t got any

value assigned:
• They may not contain all MOCs required or MOCs that

are not required (LNADJG, IRFIM…)
MOCs defined in SCF for RL30

System Configuration Files
Parameter values (SCF vs. PDDB)
• Most default parameter values in PDDB should be aligned with SCF values after
P8 milestone
• Reasons why parameter values can be different:
• SCF is focused on lab testing, low loaded trials and customer networks whereas PDDB
values should be more generic. E.g. cell load dependent parameters
• Other parameter values in SCF are the result of a workaround for some issue (network or
UE) that may be removed in future release/SW-version
• All cases of differences between PDDB default values and Golden SCF should be
documented in the corresponding GMC scenario within the Parameter Knowledge
Database (PKDB):
RL20
RL25
RL30

Site Configuration
RMOD and SMOD MOCs
An starting point when creating a template or configuring a site is to define how
many and which type of RF modules (RMOD) and System Modules (SMOD)
will be used
• RMOD object:
• Type of RF module is specific to the frequency used
• Amount of RF modules per site depends on the site configuration. E.g. 3 cells
site with 2Tx MIMO 2
• Distributed case : 3 RF modules (1 RF module per cell)
• ‘Normal configuration’: 2 RF modules ( to cover for the 3 cells)
• SMOD object:
• To define the type of system module (FSME) and the technology used (EUTRA)

Site Configuration
Cells configuration and ANTL MOC
• After RF module definition is necessary to define the cells per site:
– How many cells
– RF modules and antenna Lines used per cell
– MIMO settings
– Power of the RF module
• Relation between antenna ports used and antenna lines may not be so intuitive
• Parameters involved:
• lcrId: ID of the Local Cell Resource ( i.e. cell/sector ID). Unique value in the eNB
for each cell
• antId: Identifies the specific antenna port in the Radio Module for the antenna
line. Range and step: ANT1 (0), ANT2 (1), ANT3 (2), ANT4 (3), ANT5 (4), ANT6
(5)
• antlId: Identifies the specific antenna line
• rModId: Identifies the Radio Module

ANTL object
3 sector site
• Common configuration where the 2 RF modules are situated next to the
system module
antId=0 (ANT1 in BTS SM)

ANTL object
3 sector site: BTS SM definition
• For each Local cell (lcrId) it is required to define the antId used in each Radio
Module, the MIMO settings and the carrier power

Defining ANTL object
3 sector site: xml file
• In the xml file, there is a total of 12 ANTL objects
• Parameter structure for the ANTL used (i.e. ANTL1,3,5,7,9,11) is the same as
per ANTL-1
• Parameter structure for the ANTL not used (i.e. ANT2,4,6,8,10,12) is the same as
per ANTL-2

Defining ANTL object antId=0 (ANT1 in BTS SM)
3 sector distributed site antId=2 (ANT3 in BTS SM)
• 1RF module required per sector in order to have the 2x2 MIMO

ANTL object
3 sector distributed site: BTS SM definition
• For each Local cell (lcrId) it is required to define the antId used in each Radio
Module, the MIMO settings and the carrier power

Defining ARFCN Frequency
Included in LNCEL MOC
• It is enough to define the DL ARFCN frequency for each cell and the bandwidth.
UL ARFCN is automatically calculated
Downlink
Uplink

Addition of New Objects not in SCF
MHA, RET MOCs
• It is possible to define new objects not in the original SCF like MHA, RET (Remote
Electrical Tilt)… as BTS SM asks for the parameters required

Radio Network Configuration Parameters
MRBTS, LNBTS MOCs
• All radio related parameters are under MRBTS object
Multiradio flexi BTS site

Identifier ( MRBTS-ID)
must be the same as the
LNBTS-ID

Radio Network Configuration Parameters
Errors
• If working directly with SCF, LNBTS parameters give many
errors (indicated by a ‘yellow triangle’)
• Errors indicate missing mandatory parameters or parameters
that cannot be validated as they are not recognised (i.e. those
with ‘e.g.xxxx’ values in SCF)
• 2 ways of solving it:
• Open each MOC with an error and complete the
mandatory parameters indicated by the yellow asterisk
• Go through the list of errors (below). By clicking each of the
errors BTS SM points the user to where the error is

LNBTS and LNCEL children objects
• Which objects to add depend on each operator
case
• LNCEL child objects related to idle mode (cell
reselection): IAFIM, IRFIM, UFFIM, GFIM
• LNCEL child objects related to connected mode
mobility:
LNHOIF,LNHOW,LNHOG,LNREL,REDRT
• LNBTS child objects related to connected mode
mobility: ADIPNO, LNADJ, LNADJG, LNADJW

Idle Mode Mobility Configuration

System Information Blocks (SIBs) More info: TS36.331
• UE reads the system information within Idle mode to acquire parameters needed
to complete cell selection and reselection
• System information is broadcast using a Master Information Block (MIB) and a
series or System Information Blocks(SIB)
• SIB1..3 are mandatory
• SIB 4,5,6,7,8 are optional and are defined within LNCEL

SI: System Information
siXMappingInfo Parameter MOC: Managed Object Class
LNCEL
• LNCEL/siXMappingInfo parameter indicates which System Information Block is
contained in the SI-X message. Values: SIB4(2), SIB5(3), SIB6(4), SIB7(5), SIB8
(6), notUsed (18)
• If ‘SIB4’ is defined in any LNCEL/siXMappingInfo

where X={4,5,6,7,8} then the MOC IAFIM (iafimId)
object must be defined
• If 'SIB5' is defined in LNCEL, then MOC IRFIM (irfimId)
needs to be created
• If 'SIB6' is defined in LNCEL, then MOC UFFIM
(uffimId) needs to be created
• If 'SIB7‘ is defined in LNCEL, then MOC GFIM (gfimId)
needs to be created
• If 'SIB8‘ is defined in LNCEL, them MOC CDFIM
(cdfimId) needs to be created
• Example where only si4MappingInfo is configured
indicating that SI-4 carries the SIB4 information:

SIB3
LNCEL
• SIB3 carries the cell reselection parameters (serving cell information)
• All these
parameters are
part of LNCEL
object

SIB4 and IAFIM (1/2)
• IAFIM parameters are broadcasted in SIB4 (neighbour cell information)
• SIB4 contents are

optional!
• Intra Frequency Neighbours plus offsets

• Intra Frequency Blacklisted Cells
• CSG reserved cells i.e. for Home eNB -> not implemented
CSG: Closed Subscribed Group

SIB4 and IAFIM (2/2)
Theory:
• All parameters in IAFIM are optional i.e.
– No need to define intra-frequency idle
mode neighbours
– UE does not need SIB4 as it evaluates
the available found neighbour cells +
any additional cells defined in SIB4 if
configured
• IAFIM only needs to be created to give some special cell reselection offset (other than 0) to
certain neighbour cells or to blacklist cells
Practice:
• Recommendation is to create a ‘dummy’ SIB4 as it is required for certain terminals e.g.
Huawei LTE-USB sticks otherwise they crash
• If IAFIM object is created them either blacklisted cells OR neighbour cells need to be defined
– It is enough to configure a ‘dummy’ PCI in IAFIM
– SIB4 periodicity in this case can also be longer
•
Intra frequency cell reselection
Practical Experience
• qOffsetCell (the offset for the neighbouring cells) is in the IAFIM object and has to
be defined separately for each neighbour relation (defined by the neighbours’ PCI).
• Issue: It is not convenient to maintain. E.g. If creating a new PCI plan it is also
necessary to change the PCIs in all the IAFIM objects
• Solution: To ”move” all the offset to the qHyst (the offset for the serving cell)
• E.g. instead of defining qHyst = 1dB and qOffsetCell = 2 dB to change qHyst to 3
dB and qOffsetCell to 0 (or don’t define the IAFIM at all)

Practical Experience: Example
• In the Telia Denmark network:

– LNCEL:qHyst was set to 1 dB
– IAFIM:qOffsetCell was set to 2dB, only defined for intra-site neighbours
• This meant:
– when reselecting to intra-site neighbours: total hysteresis was 3 dB (2+1)
– When reselecting to non intra-site neighbours: total hysteresis was 1 dB (as no
qOffsetCell was defined for the other neighbours)
– 1 dB of hysteresis is too little leading to many cell reselections
List only contains

offset for the two intra
site neighbours

Idle mode PCI plot
Before parameter change, cell After parameter change, less
reselections happening too often ping pong between cells

IRFIM object
SIB5: Inter frequency cell reselection
• Idle mode mobility between two different LTE frequency layers, e.g. LTE 2600MHz
for capacity sites and LTE 800MHz for coverage sites
• IRFIM parameters are

broadcasted in the SIB5
IRFIM object

UFFIM object
SIB6: Inter RAT cell reselection
• SIB6 and UFFIM with priorities and reselection thresholds
towards 3 different WCDMA carriers

Inter RAT cell reselection
Settings on WCDMA side (1/2)
• ‘RAN2067 LTE interworking feature’ needs to be activated
• Software needs to be appropriate e.g. WBTS SW BTS WN6.0 PP2.03 and activated on all
WCDMA sites
• ‘LTE Cell Reselection in WCEL needs to be enabled
• RNC setting for SIB19

Inter RAT cell reselection
Settings on WCDMA Side (2/2)
• ADJL configuration

36 36 © Nokia 17 Siemens
May 2016
Networks
GFIM object
LTE to GSM reselection
• SIB7 needs to be activated
• Mandatory parameter: GNFL/bandInd
• It distinguishes between GERAN frequency bands if ARFCN values are associated
with either GSM1800 or GSM1900. Values: gsm1800 (0) or gsm1900 (1)
• If other ARFCN bands then the parameter although mandatory is not relevant
• E.g. GNFL/gerArfcnVal = 1-124 (i.e. GSM900 frequencies) then bandInd can be either 0
or 1

Connected Mode Mobility Configuration

Intra-Frequency Handovers
• All parameters related with

intra-frequency handover are
under the LNCEL object:
– These are the A3 and A5
(offsets, report intervals,
time to trigger)
– Parameters to enable the
A3 and A5 handovers:
enableBetterCellHo and
enableCovHo
– All thresholds referred to
the serving cell:
Threshold1, Threshold2/2a,
Threshold3/3a, Threshold4
• Intra cell reselection
parameters are also under
LNCEL

LNHOIF
Inter-Frequency HO
• LNBTS:actIfHo must be
enabled
• Inter-frequency HO is activated
on site level
• Need to create a LNHOIF
object per cell defining the
parameters that will be used in
the Measurement Configuration
message and all the thresholds
for A3/A5 event
• Need to define the LNCEL
parameters regarding
threshold2/2a to
activate/deactivate inter-
frequency measurements
• Inter-frequency HO parameters:
Inter-Frequency
Parameters

LNHOW, LNAJDW (RL30)
IRAT HO to WCDMA
• LNADJW [LNBTS]: Defines WCDMA neighboring cell(s)
• LNHOW [LNCEL]: For each predefined EUTRA (utraCarrierFreq) defines event
B2 related parameters
• New parameters in already existing objects LNCEL and LNBTS are introduced

IRAT to WCDMA (RL30)
LNBTS Configuration
• actHOtoWcdma enables
the feature Handover from
LTE to WCDMA
• LNBTS/LNADJW to define
candidate 3G neighbor cell
information for handover
• Identifier 0 originally a bug
• LNCEL/Related LNADJW
instance list needs to be
created with “WCDMA Cell
Index ID” according to 3G
neighbor lists need for that
LTE cell. Create per 3G
neighbor cells
Soc Classification level LNADJW-x = LNADJW: lnAdjWIndex
IRAT to WCDMA
LNCEL
• LNCEL/LNHOW
needs to be created
per 3G neighbor
frequency
• One LNHOW
needed per
frequency
• LNCEL/UFFIM
needs to be
created per 3G
neighbor
frequency for
cell reselection

LNHOG, LNADJG (RL30)
eNACC to GSM
• LNHOG: Information about NACC thresholds and timers for predefined set of
ARFCNs defined by the parameter arfcnValueListGERAN
• LNADJG:GSM cell considered as neighbouring GSM cell by LNCEL when its
lnAdjGId parameter is listed on GSM Neighbouring Cell Information
LNCEL:adjGInf parameter
• New parameters in already existing objects LNBTS, LNCEL are introduced

CS Fallback to UTRAN (1/2)
LNBTS, LNCEL, UFFIM, GFIM
• CS fallback needs to be enabled via LNBTS:actCSFBRedir
• Redirection technologies (WCDMA or GSM) need to be configured: UFFIM for

WCDMA and GFIM for GSM
Screenshots for WCDMA case
• Activation of SIB6 for WCDMA and

SIB7 for GSM (within LNCEL)

CS Fallback to UTRAN (2/2)
REDRT
• Necessary to create the REDRT object indicating the RAT for redirection and the
priority for CS fallback with redirection
• REDRT object also needs to be created for RRC

Connection Release with Redirect (Threshold4)
• One RDRT object is created per RAT frequency/band
indicator
S1 Handover Configuration

Intra-LTE handover via S1
Parameter settings up to RL 20 1/2
• S1 handover doesn’t seem to be enabled in live networks but it is normally tested
to ensure the proper configuration and functioning
• Following MOC have to be adapted/created for setting up S1-based HOs:
1. The S1 handover feature needs to be enabled in LNBTS by:
true
2. If the target eNB is able to perform X2-based handovers the target cell has to
be blacklisted for X2 handover. For functionality testing of S1 HO, the X2
neighbour cell needs to be blacklisted:
LNCEL object:
<list name="blacklistHoL">
<item>
onlyX2
65536
n8
pci
</item>
</list>

Parameter settings up to RL20 2/2
3. LNADLP (Target cell for S1 Handover) needs to be created per S1 neighbour cell
LNBTS object:
<managedObject class="LNADLP" distName="LNBTS-1001/LNADLP-1"
operation="create“
<list name="adjBcPlmnIdOp">
<item>
MCC
MNC
length
<…>
ARFCN
pci
tac
0
</managedObject>
• Note: On RL30, LNADLP object has been removed.

Parameter settings RL30
• In RL30 the object LNADLP is removed
• With feature LTE782 (ANR Fully UE based) in place there is not need for the
object LNADLP:
 A part of the procedure for LTE782 is the configuration of the X2 interface. After
X2 successfully established source and target eNBs exchange configuration
information necessary to fill in MOCs LNADJ and LNADJL
 Until X2 link is successfully setup, cells being already defined in LNADJL can
be regarded as targets for S1 HO (if feature is enabled)
• To configure a pure S1 HO target cell:

– Parameter LNADJ/cPlaneIpAddr must be left empty and…
– LNADJ/cPlaneIpAddrCtrl must be set to: enbControlled
• To prohibit X2 connection establishment, the neighbour eNB needs to be
blacklisted via LNBTS/glbNbEnbIdX2LinkBlacklist

Summary of blacklisting parameters
Connected Mode:
• Blacklisting for (X2 or X2&S1) HO between an LTE cell and intra/inter- frequency
list of cells
• LNCEL: blackListTopo (part of blackListHoL)
• Blacklisting between an LTE cell and a WCDMA/GSM cell
• LNCEL: cellblacklisted (WCDMA/GSM)
• X2 blacklisted eNB Id: related to (RL30) ANR fully UE based
• LNBTS: glbNbEnbIdX2LinkBlacklist
• (RL30) LTE cell blacklisted to be HO target of another LTE cell. Applies in addition
to blackListTopo
• LNREL: handoverAllowed

Neighbours Configuration

Contents
• Neighbours configuration in RL20/RL15TD

• Manual Definition
• SON (ANR)
• Summary
• Neighbours configuration in RL30/RL25TD
• Manual definition
• SON (ANR)
• Summary
• Differences in neighbour definitions between RL20 and RL30

Neighbours configuration in RL20/RL15TD
Manual definition (no ANR)
• Neighbours are manually defined via the
C-plane IP@ of the adjacent eNodeB(s)
• Defined in MOC ADIPNO within the
adjEnbIpAddressMap via parameter
adjEnbCPlaneIpAddress
• Once the source eNB knows the IP@ of
the target eNBs it establishes the X2
connections that allow for:
• Automatic derivation of all necessary
neighbour site (MOC LNADJ) and
neighbour cells (MOC LNADJL)
information
• Automatic creation and population of
neighbour cell information list (in MOC
LNCEL) with all cells of the parent eNB
and all cells for which the parent eNB has
received configuration information from
neighbour eNB

ADIPNO MOC (RL20)
ADjacent IP NOde
• It is enough to define the neighbour IP@ (AdjEnbCPlaneIpAddress)
• Additional parameters in the ADIPNO object and existing values of adjMacroEnbId,
adjMcc, adjMnc and adjMncLenght will be updated once that file is uploaded into
the eNB (i.e. during the X2 setup)
SCF original ADIPNO object…

ADIPNO object after site integration
ADIPNO object (RL20)
Defines the list of neighbours (enough to

configure the AdjEnbCPlaneIpAddress)
After site integration objects LNADJ and LNADJL

are automatically created:

ANR definition
• Feature LTE492: ANR support for LTE with OAM
• No need for manual pre-planning of eNB adjacencies for
X2 connection setup
• NetAct generated PCI/RF/IP@ mapping tables for
neighbour site relations are downloaded to eNB during
auto-configuration
• For each unknown adjacent cell, eNB searches the
PCI/RF/IP@ look up table (stored in MOC LNBTS under
pciIpAdrMap) to determine the IP@ needed for the X2
establishment towards eNB being a parent of unknown
cell
• After X2 connection is successfully established, source
and target eNBs exchange configuration information
necessary to fill in MOCs LNADJ and LNADJL and to
add adjacent cells to neighbour cell information list in
MOC LNCEL (attribute adjCellInfoL) same as in the
previous case
pciIpAdrMap only exists when neighbours are created
with NetAct
Common information
RL20
• MOCs LNADJ and LNADJL as well as parameter adjCellInfoL (in MOC LNCEL)
are not modifiable for operator – that are just read only (in NetAct and BTS SM)
• MOC LNADLP: (ADjacent LTE cell Plan based)
• Contains target cells for S1-based HO that must be created by operator as
they can’t automatically be created by eNB
• A cell may be target cell for S1- and X2-HO. In that case the represented by
two objects:
• one LNADJL object for
the X2-HO target
• one LNADLP object for
the S1-HO target
• parameter lnAdlpInf
provides a reference to
the LNADLP object if the
cell is configured to be a
S1-HO target too

Summary
RL20
• Difference between using SON ANR
features or not only affects how the
neighbour are defined:
• SON (LTE 492:ANR with OAM

extension) neighbours are
defined with NetAct
• Manual: neighbours are defined
as a list of IP addresses
adjEnbCPlaneIpAddress in the
ADIPNO:adjEnbIpAddressMap
• Once the IP@ of the neighbour site

is available the updates in the
involved MOC are automatic
( LNADJ, LNADJL, LNREL) after X2
setup

LTE782: ANR Fully UE based (3GPP)
• No need for pre-defined PCI/RF/IP@ mapping tables (no need for NetAct)
• eNB requests UE to report the ECGI

of unknown cells reported in the
measurement report
• UE must support decoding and delivery
of ECGI on request coming from eNB
• Derived ECGI is used as input to an

IP@ resolution procedure over S1 IF
• eNB retrieves, with the help of MME, the
C-plane IP@ needed to setup X2
connection towards the neighbour eNB
parenting the UE-reported cells
• Once IP@ is known then X2

connection to eNB hosting the
neighbour cell can be established

• When X2 connection is established, source and target eNBs exchange

configuration information necessary to fill in MOCs LNADJ and LNADJL
• Bidirectional neighbour cells configuration data exchange
• eNB knows all cells of the neighbouring eNB by PCI and IP address
• LNADJL is created for all cells belonging to the peer eNB (not only for the
unknown cell that triggered the procedure)
• ANR is not triggered again when UE reports PCI of those not yet discovered
cells
• eNB creates the LNREL for the newly discovered cell (if this LNREL has not
been created manually yet)
• MOC LNREL (neighbour relations) is created by the eNB only for those cells
that have been included in the UE measurement report received in given cell

• ANR feature implies the definition of new parameters in LNBTS and LNCEL MOCs
necessary for the ECGI derivation and for the detection of unknown cells (active
detection)
• Parameters involved an additional information of the feature can be found in:
• https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D437011923

Manual definition (no ANR)
• Neighbours are defined with the parameter cPlanIpAddr (MOC LNADJ)
• As in the ANR case, once the eNB has the IP@ of the eNB’s hosting the neighbour
cells, it automatically attempts the setup of the X2 connection and if successful, it
automatically creates the corresponding LNADJL and complements the
information in LNADJ
• The creation of corresponding LNREL is triggered automatically after reception of

a measurement report from the UE containing that cell

RL30 Summary (1/2)
• In RL30 neighbours can be created manually via LNADJ: cPlanIpAddr or

automatically by the eNB
• Once IP address of neighbour site is detected and X2 connection is successful the

eNB automatically creates the corresponding LNADJL and complements the
information in LNADJ
• LNADJ and LNADJL can be created also manually (in RL20 only automatic creation).
Cases:
• To blacklist cells, configure cells for pure S1 HO (via LNREL)
• If LNADJ, LNADJL are created manually (via plan) the lowest available IDs should be
used ( 0, 1…) to avoid ID conflicts in case with the automatic case as eNB uses the
highest free LNADJ/LNADJL/LNREL instance ID in automatic creation procedure
• LNADJ and LNADJL: can be modified or deleted via plan file

RL30 Summary (2/2)
 LNREL object can also be created manually for blacklisting, define S1-HO or define
cell specific offsets
 LNREL objects are created by eNB if corresponding LNADJL object already exist
and certain PCI is reported by UE as a result of A3 or A5 event
• LNREL objects remain after deleting the LNADJL. The relation becomes invalid for
HO but still is considered for blacklisting
LNBTS
LNADJ LNCEL
LNADJL LNREL
LNREL: Relation between the parent cell

LNCEL and one LNADJL cell

LNADJ, LNADJL and LNREL
Relations
LNREL: LNADJ: neighbour site of parent LNBTS

• New MOC in RL30 mainly • Site identified by cplanIpAddr and adjEnbId
related with ANR and that is the lnBtsId of the neighbour site
Optimization of neigh relations
LNADJL: specifies the cells belonging to
LNADJ site that have a neighbour relationship
• LNREL: cell to cell neighbour with the parent eNB cells (LNCEL-x)
relationship between parent
LNCEL and another LTE cell • Cells identified via:
identified in LNADJL with – ecgiLcrId
ecgiAdjEnbId and ecgiLcrId – ecgiAdjEnbId
– phyCellId (not the EutraCelId)
• LNREL provides additional
information on the neighbour LNBTS
relationship defined in
LNADJL: LNADJ LNCEL
• Definition of cell individual
offsets
• Blacklisting LNADJL LNREL
Differences in neighbour definitions
Between RL20/RL30
• In RL30 neighbour site IP@ are not defined anymore in ADIPNO MOC but in
LNADJ MOC
• LNADPL MOC (to define S1-HO relations) disappears
• Until X2 link is successfully setup, cells being already defined in LNADJL can be
regarded as targets for S1 HO (if feature is enabled)
• New MOC: LNCEL/LNREL for neighbour relations containing information

previously part of LNCEL (adjacent cell info List)
• ANR feature in RL20 supports also intra and inter frequency neighbours. ANR
feature in RL30 only supports intra frequency neighbours

ANR – Intra-LTE, Intra-frequency – Fully UE based (LTE782)
Feature details
Neighbour relations database structure in RL30
LNBTS (1..1) * LTE492 specific
lnBtsId, …, actUeBasedAnrIntraFreqLte,
actUeBasedAnrIntraFreqLte, glbNbEnbIdX2LinkBlacklist,
glbNbEnbIdX2LinkBlacklist pciIpAdrMap (dlEarfcn, ipAdr, pci, eNbId)*,
eNbId)* … …
LNADLP (0..32):
LNCEL: LNADJ (0..64
(0..64):
):
LNADJG (0..32)
 lnAdlpId
LNADJW (0..32)
LNCEL:  lnCelId  lnAdjId  adjPhyCellIdOp
Pr
 lnCelId 1…6
6  adjCelInfoL  adjEnbId  adjEgciOp
 adjCelInfoL
eutraCelId_1
eutraCelId_1
… es  plmnId …
… eutraCelId_130
en 

…
cPlaneIpAddr
ta
eutraCelId_130  phyCellId
 cPlaneIpAddCtrl ADIPNO (1..1):
tio
 phyCellId  eutraCelId  AdIpNoId
 eutraCelId  x2LinkStatus
n
 lcrId  adjEnbIpAddressMap
 lcrId
m
 adjWInfList …
 adjGInfList
od
 adjGInfList
 adjWInfList  anrThresNbCell
 anrThresNbCell  drxProfile101
e
LNADJL (1..6
(1..6):
 drxProfile101  nLTEIntraNeighb  lnAdjlId
on
ly!
 nLTEIntraNeighb ours  lnAdlpInf
ours  phyCellId
!!
…
…  adjEutraCelId
LNREL (0..389): LNREL (0..389):
 ecgiPlmnId
 lnRelId  lnRelId
ecgiAdjEnbId
 ecgiAdjEnbId  ecgiAdjEnbId
ecgiLcrId
 ecgiLcrId  ecgiLcrId
sourceOfData
Soc Classification level  ecgiPlmnId  ecgiPlmnId
validityOfData
…  …
…
Parameters for Blacklisting

Blacklisting: IAFIM
Intra-Frequency cells
• If an operator wants to prohibit UEs to camp on certain cells, these cells can be
blacklisted
• The blacklisted PCIs are defined by the parameters IAFIM:startIntraPci and
IAFIM:rangeIntraPci
• Together, these two parameters define the blacklisted PCIs
– startIntraPci defines the lowest PCI in the range
– rangeIntraPci defines the number of PCIs in the range
• There can be 16 ranges in total
PCI 1-4 are black

listed

Blacklisting: IRFIM
Inter-Frequency Cells
• In the same way as for intra frequency cells , inter frequency cells can be
blacklisted
• The blacklisted PCIs are defined by the parameters IRFIM:startInterPci and
IRFIM:rangeInterPci
• Together, these two parameters define the blacklisted PCIs
– startInterPci defines the lowest PCI in the range
– rangeInterPci defines the number of PCIs in the range
• There can be 16 ranges in total

Blacklisting for X2 or X2 and S1 HO
Intra frequency and inter frequency
• Intra frequency and inter frequency cells can be blacklisted for X2 or X2 and S1 HO under
LNCEL object
• Parameters involved:
– blacklistTopo:
• allEqual means only X2 and S1 HO are forbidden to that cell(s)
• onlyX2 means cells are only blacklisted for X2 HO
– freqEutra: 65536 means same frequency (i.e. intra frequency)
– phyCellIdRange: how many PCIs
– phyCellIdStart: first PCI in range

Blacklisting between an LTE cell and a
WCDMA/GSM cell (RL30)
• It is possible to blacklist a WCDMA neighbour cell (defined under LNADJW ) with
LNCEL parameter cellblacklisted (under Related LNADJW instance list)
• It is possible to blacklist a GSMC neighbour cell (defined under LNADJG) with

LNCEL parameter cellblacklisted (under List of pointer to LNADJG instance)

Blacklisting X2 Handover towards another eNB
RL30
• LNBTS: glbNbEnbIdX2LinkBlacklist is used to blacklist X2 handovers between eNBs in the list
• The eNodeB does not establish or accept X2 connections to/from eNodeBs contained in the list
• It is possible to have 64 lists (i.e. to blacklist relations between 64 eNodeBs from one eNodeB)

Blacklisting for HO between two LTE cells
RL30
• LTE cell blacklisted to be HO target of another LTE cell
• Related to ANR procedure and Optimization of neighbour relations. However operator can also
manually blacklist a cell with LNREL: handoverAllowed if LNREL: nrcontrol is set to manual
• Applies in addition to blackListTopo
• If a cell is blacklisted for HO with blackListTopo (blacklistHoL in MOC LNCEL) then
automatically is blacklisted for ANR procedure (LNREL: handoverAllowed is not considered)
Soc Classification level nrcontrol: neighbour relation control

Summary of blacklisting parameters
Idle Mode:
• Blacklisting from one LTE cell to a list of intra or inter frequency cells
– IAFIM: intrFrBCList (intra frequency)
– IRFIM: intFrBCList (inter frequency)
Connected Mode:
• Blacklisting for (X2 or X2&S1) HO between an LTE cell and intra/inter- frequency list of
cells
– LNCEL: blackListTopo (part of blackListHoL)
• Blacklisting between an LTE cell and a WCDMA/GSM cell
– LNCEL: cellblacklisted (WCDMA/GSM)
• X2 blacklisted eNB Id: related to (RL30) ANR fully UE based
– LNBTS: glbNbEnbIdX2LinkBlacklist
• (RL30) LTE cell blacklisted to be HO target of another LTE cell. Applies in addition to
blackListTopo
– LNREL: handoverAllowed

Exercise It needs to be refined
• Scope: Familiarize with Site Manager, xml files and understand configuration
aspects using real commissioning files:
• In the following example of RL20 commissioning file:
– Indicate to which frequencies /technologies we will have reselection and which one has
the highest priority
RL20_Comm_File
• In the following example of RL30 commissioning file:

– Identify the sector configuration and RF module configuration (ANTL parameters)
– Have neighbours been created manually or with ANR? Why?
– Maybe create some UFFIM or IRFIM for certain frequency (if parameters defined before).
A REDR is easier (parameter wise but file already has some) -> if UFFIM created now it
could be reused (parameter values) for the KISS macro (list object)
RL30_comm_file

Plan Creation Methods
Roll outs

Plan Creation for Rollouts
Introduction
• Configuration Management (CM) deals with the creation of plans/configuration files
(xml) required for the integration of the sites within a network
• There are multiple methods to create such plan/configuration file. Each method is
based on a different tool. Preferred method is base on the project characteristics:
• Method 1: NetAct Configurator

• Method 2: Daisy - LACE
• Method 3: Plan Editor
• Method 4: Databuild Creation Macro (internal macro)
• Three areas need to be configured when creating a plan:

– Radio Network Parameters (RNW)
– Site Configuration Parameters (HW)
– LTE BTS Transport Parameters (FTM)
• Focus within this training is on the RNW and site configuration areas

Method 1: NetAct Configurator
Overview
• Tool: NetAct Configurator
• Inputs:
• Site Data file (XML or CSV input file)
• It contains ‘site specific’ parameters i.e. those that need to planned/allocated separately
for each site
• One site specific parameter per column, parameters for one site per row
• Import Profile (XML)
• Only necessary if Site Data file is in CSV format
• Maps the columns information of the CSV file into XML
• Site Template
• Output:
• Plan to be provisioned to the network
• Benefit:
• Simple and fast
• Drawback:
• It is necessary to have on-line connection to NetAct

Method 1: NetAct OSS and NetAct Configurator
• RL30 and RL25TD are supported from OSS 5.3 CD set 3
NetAct –NE Element Compatibility Matrix

• Plan is created with a combination of CM Operations Manager and CM Editor
• CM Operations Manager: Import site data (start of plan creation), import of site
templates and CM workflow
• CM Editor: Edit site templates and site(s)/plan inputs

Process
1. Import in CM Operations Manager (part of NetAct Configurator) the input file i.e.
the site data file
• Planner decides which parameters to include in the input file. Those
parameters should be the ones that need to be specific for each site and for
which it is not possible to use a template.
• Within the input file it is necessary to include the identifier to the site template
to be used
2. Assign an import profile to the csv input file
• Only required if the input file is in csv format. Not needed if the input file is
already in xml format
• The import profile is needed to create and xml file from the csv input file.
3. Apply a site template to our plan (or input file)
• For those parameters not included in the input file, the values of the site
template are used
4. Validate the plan and provision it. NOTE: Provisioning the plans is not part of
Radio planning

Input File
• Example input file for RL20 (csv) with minimal set of parameters needed:
3cells _s ite_Input
file
• Each column contains one site-specific parameter and each row contains the site-
specific parameters for one site
• User Interface (UI) or Internal parameter values can be used
• A unique Distinguished Name (dn) is needed for every object created in the CSV
file. It uniquely identifies a Managed Object in the database.
– The only site-specific id in the DN is the MRBTS/mrBtsId which must be equal
to LNBTS/lnBtsId
 Example DN for LNCEL of sector #1: PLMN-PLMN/MRBTS-9876/LNBTS-
9876/LNCEL-1
• More information in Plan Creation with NetAct CM.ppt:
– https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D437258745

Method 1: NetAct Configurator MOC: Managed Object Class
Import Profile and Site Template (RL20)
Import Profile
3cells _import profile
• Example import profile for the previous input file example:
• Import profile is created manually in a text editor. It must contain the same inputs
(MOC and site-specific parameters) defined in the site input file
Site Template
• It contains the parameters that don’t need to be planned for every site and can be
assigned a pre-defined value
• Two ways to create the site template:
– Importing an existing template using CMO Manager (NetAct Configurator)
– Create a site template from an existing site in the OSS database using CM Editor (part of
Configurator)
• Site template values can be browsed and modified with any text editor or in CM
Editor
• More information in Plan Creation with NetAct CM.ppt:

Method 2: Daisy-LACE
Overview
• Tool:
– Daisy (NSN internal tool) with HW license (free)
– Plan Editor with SW license (.lf file)
• Inputs:
– CIQ (Customer Information Questionnaire) excel
• Output:
– XML file for each eNB or unique xml containing the actual plan
• Benefit:
– Off-line
• Drawback:
– Not always available in time: It depends on availability of PE database, CIQ
creation/verification
– It doesn’t support SITE object creation (needed for Optimizer and Auto
configuration)

Process (1/4)
Preparation phase:
• Download and install the latest Daisy:

– https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/432861101
– An empty Plan Editor (PE) database and the valid CIQ file for that Daisy version is part of
the package, within folder LACE/Input
E.g. C:\Program Files\NSN\DAISY\Projects\LTE_LACE_RL20\WorkDir\LACE\Input
• Request CIQ HW license by filling the form:

• Fill the required parameters within the CIQ Example CIQ RL20
• RL30 CIQ preparation is ongoing. No CIQ support for LTE TDD

Process (2/4)
Daisy Handling
• As Daisy works for several technologies it is necessary to select the correct one
with the Data Generation button
• Daisy works in three simple steps:
– Data generation: Generation of xml files from the CIQ excel

– Data Upload into Plan Editor: upload of xml files into PE
– Data export (generation of the xml plan): combination of CIQ and PE
parameters

Process (3/4)
Daisy Handling (cont)
•Data Generation : Uploading the CIQ

• Validates the CIQ
• Note: CIQ must be closed (not opened in
excel) when importing it in Daisy
•Data Upload: Import in Plan Editor -> Straight

forward after uploading the CIQ
• Input: xml files generated in the previous
step. It is enough to point to the folder
•Data Export: Export to xml using either Default

LTE LNx.0 or Default OSS

Process (4/4)
Plan Validation
• Once Daisy provides the plan it is recommended to validate it before provisioning
• Two possible DAISY outputs depending on the export profile
– 1) Default LTE LNx.0
– 2) Default OSS
Default LTE LNx.0

• It generates an xml file for each eNB -> validation for each site can be done
individually with BTS site Manager
Default OSS
• It generates one xml for NetAct Configurator containing all sites (i.e. the whole plan)

Method 3: Plan Editor If time add something
Overview else….
• Tool:
– Plan Editor with SW license (.lf file)
• Inputs:
– Site Data file (csv)
– Plan Editor templates
• Output:
– Either a Commissioning file per site (suitable for BTS SM) or OSS plan multiple
sites depending on the export profile selected
• Benefit:
– Off-line tool and official NSN tool
– For some people it is the best method to generate plans and track changes
• Drawback:
• Generation of templates and template sets may not be straight forward

Method 4: KISS Databuild Creation Macro
Overview
• Tool:
– Excel macro
• Inputs:
– Excel with radio and transport parameters
that need to be planned (those different for
each site)
– Template for certain release
– BTS SM for file validation (optional)
• Output:
– Commissioning file to be provisioned
• Benefit:
– Flexibility to adapt the macro for different releases and different inputs
– Mass validation of sites in BTS SM with just one click
• Drawback:
– None so far KISS: Keep it short and simple
Overview
• The off-line excel macro can be used for rollouts (simultaneously creation of
multiple commissioning files)
• It is valid for any release (FDD and TDD) providing the right template is used
• Idea behind the tool:

• Macro works by replacing $parameter tags in the template for parameters
defined in the input sheets
• Tool and instructions can be downloaded from:


Generic Process
• Overall procedure:
1. Template creation: Create a template file using Site Manager (from Golden
SCF), or use an existing site as a template file
2. Template adaptation: In the template file, replace site-specific parameter

with $parameter tags, such as ‘$pci1’
3. KISS handling: Define $parameter tags in the KISS excel and the parameter
values that should replace them, one site per excel row
4. Run macro: KISS replaces tags with the parameter values and produces a
commissioning file per site
5. Run validation

Comparison of plan creation methods (1/2)
Attribute Method 1: NetAct with LTE Method 2: DAISY-LACE
site templates
Input data format CSV or XML Excel: Customer Information
Questionnaire (CIQ)
Output data Site CM data in OSS eNB commissioning files (xml)
database. Can be exported or OSS database (xml)
in XML format using CMO
Manager
SW required NetAct OSS DAISY-LACE + Plan Editor
Licensing Basic NetAct functionality License for DAISY-LACE (hw
dongle), Plan Editor soft license
(.lf file)
On-line / Off-line On-line: connection to NetAct Off-line
required to import data with
CMO Manager and to apply
site template
Optimizer SITE object Yes, allows creation of SITE No, SITE object must be
creation readiness in object in the CSV import created afterwards in NetAct
import
Site template data Yes, site template No, input data is according to
parameter parameters can be freely fixed input data format (CIQ),
customizability customized empty parameters replaced with
PDDB defaults

CIQ = Customer Information Questionnaire
Comparison of plan creation methods (2/2)
Attribute Method 3: Plan Editor Method 4: KISS Databuild
using template sets Creation Macro Tool
Input data format CSV Excel
Output data eNB commissioning files eNB commissioning files (xml)

(xml) or OSS database (xml)
SW required Plan Editor None specific. Excel

Licensing Plan Editor soft license (.lf None.
file)
On-line / Off-line Off-line Off-lines
Optimizer SITE object No, SITE object must be No, SITE object must be
creation readiness in created afterwards in NetAct created afterwards in NetAct
import
Site template data Yes, site template Yes, site template parameters
parameter parameters can be freely can be freely customized
customizability customized using PE
template sets

CIQ = Customer Information Questionnaire
Plan Creation with KISS Macro Still to be refined:
Exercise
INPUTS:
• Excel file provides input data (CIQ) based on real project(s) for 5 sites CIQ_RL30
• Template has been created with BTS Site Manager and modified to work with KISS
• Basic KISS macro:

T_ln30_exercis e_bas ic.xml
https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D437598496
EXERCISE:
Create and validate commissioning files for the sites included in the plan. Consider:
• Site 1 and Site 3 cells must be barred (using the macro, cellbarred parameter)
– Scope: Addition of new parameters in the basic macro
• Commissioning files must contain the neighbours defined in CIQ_RL30 excel
(AdjSites)
– Scope: Addition of List objects in KISS

Plan Creation with KISS Macro Still to be refined:
Exercise
• Current exercise is more about tool handling than configuration (parameter
decision)
• It can complement the other exercises: 1. identifying Configuration details as MOC with BTS site
manager and 2. configuring a bit of idle mode or connected mode parameters (optimization training
exercises)
• Necessary to find a balance between not giving too much processing already done
to the people or too little.
• If too much: exercise can be very simple
• If too little: they can spend hours in ‘manual’ handling (i.e. modifying the template, input data into the
KISS macro)
• Giving CIQ is good in the sense they have an example for real network. On the other hand, it is
unnecessary complicated (if follows Daisy format) and it will be difficult for people to locate
parameters. Probably easier just to provide an excel with some parameters
• Maybe we could add that people create and UFFIM previously defined (maybe in another exercise). ->
Need to check parameter values for that exercise and test it with the tool.

Useful Links

Useful Links (1/2)
• Main Configuration Management (CM) and data fills folder in IMS:

• NetAct Plan Editor can be downloaded from IMS (software folder) together with
additional documentation (documentation folder):
– https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/390002169
• BTS SM can be downloaded:

• NOLS: https://online.portal.nokiasiemensnetworks.com/nolshome/homepage ( access
required to NOLS and to download software) : Radio Network -> Base Stations -> Flexi
Multiradio BTS LTE and Flexi Multiradio BTS TD-LTE
• IMS: https://sharenet-ims.inside.nokiasiemensnetworks.com/Open/433488673

Useful Links (2/2)
• Commissioning parameters and parameter changes per different releases from

NOLS:
• https://online.portal.nokiasiemensnetworks.com/pic/com/nsn/extranet/pic/controller/productinf
oview/pivdocumentation.do?productId=urn:nsn.com:mxpdm:133-047488
• Useful for ‘troubleshooting’ errors in the plan validation due to parameter relations that can
be found in that excel

Terminology and Databuild types
Golden System Configuration File (SCF):
• xml file with all parameters necessary to configure the system
• Excluding the parameters that are ’vendor’ specific
Vendor File:
• NSN specific parameters: The ones that can not be modified/ hardcoded. E.g ulSeqHop
Commissioning File:
• File containing all the parameters in the SCF. It doesn’t show the vendor file parameters
Databuilds (types):
• CIQ: Customer Information Questionaire
– Theoretically, minimum set of information, easy to fill by/with customer
– Input for Daisy ( LACE Tool)
– It can be used as the excel databuild
• Excel databuild: Similar to RNC/MSS/MGW data builds
– Should include all parameters that may require planning intervention (i.e. default value
might need to be changed under certain circumstances)
• Plan Editor full databuild: the full PE database, including all eNB parameters

Configuration Management: Radio Network Design For Roll Outs

Uploaded by

Document Information

Original Title

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

Configuration Management: Radio Network Design For Roll Outs

Uploaded by

Copyright:

Available Formats

Configuration Management

Radio Network Design for Roll Outs

Soc Classification level

• Parameter structure (MOC) and Site Configuration

Soc Classification level

Soc Classification level

• This section is about configuring different MOCs based on the network

Soc Classification level

Parameter configuration can be divided into:

• References for parameter configuration are:

Soc Classification level

Soc Classification level

• Some parameters, operator specific, haven’t got any

• They may not contain all MOCs required or MOCs that

MOCs defined in SCF for RL30

Soc Classification level

Soc Classification level

Soc Classification level

antId=0 (ANT1 in BTS SM)

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Multiradio flexi BTS site

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

• If ‘SIB4’ is defined in any LNCEL/siXMappingInfo

Soc Classification level

Soc Classification level

• SIB4 contents are

• Intra Frequency Neighbours plus offsets

Soc Classification level

Soc Classification level

• In the Telia Denmark network:

List only contains

Soc Classification level

Soc Classification level

• IRFIM parameters are

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

• All parameters related with

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

Soc Classification level

• Redirection technologies (WCDMA or GSM) need to be configured: UFFIM for

• Activation of SIB6 for WCDMA and

Soc Classification level

• REDRT object also needs to be created for RRC

Soc Classification level

Soc Classification level

Soc Classification level

• To configure a pure S1 HO target cell: