EdenNet 21

Layer Management Strategy Configuration

File Guide
DN09257552
Issue: 1-0
Layer Management Strategy Configuration File DN09257552 1-0 Disclaimer
Guide

The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as specified herein.

This document is intended for use by Nokia' customers (“You”) only, and it may not be used except for the purposes defined in the agreement
between You and Nokia (“Agreement”) under which this document is distributed. No part of this document may be used, copied, reproduced,
modified or transmitted in any form or means without the prior written permission of Nokia. If you have not entered into an Agreement
applicable to the Product, or if that Agreement has expired or has been terminated, You may not use this document in any manner and You
are obliged to return it to Nokia and destroy or delete any copies thereof.

The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility when using
it. Nokia welcome Your comments as part of the process of continuous development and improvement of the documentation.

This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability, capacity,
fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document, and Nokia reserves
the right to change any such information and statements without notice. Nokia has made all reasonable efforts to ensure that the content of
this document is adequate and free of material errors and omissions, and Nokia will correct errors that You identify in this document. But,
Nokia' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia does not warrant that the use of
the software in the Product will be uninterrupted or error-free.

N O WA RRA NT Y O F AN Y KI ND , EI T HER EXPR ES S OR I M P L I E D , I N C L U D I N G B U T N O T L I M I T E D TO A N Y

WARR ANT Y OF AVA IL ABI LI T Y, AC CU RAC Y, R EL I A B I L IT Y, T I T L E , N O N - I N F R I N G E M E N T, M E R C H A N TA B I L I TY
OR F IT NE SS FO R A PA RT ICU LAR PU RPO SE, I S M A D E IN R E L AT I O N TO T H E C O N T E N T O F T H I S D O C U M E N T.
IN NO EVEN T WI L L NOK IA B E LI ABLE F OR AN Y DA M A G E S , I N C L U D I N G B U T N O T L I M I T E D TO S P E C I A L ,
D IRE CT, IN D IRECT, I NCI DE NTAL OR C ON SEQ UE N T IA L OR A N Y L O S S E S , S U C H A S B U T N O T L I M I T E D TO LO SS
OF PRO F IT, REVE NU E, B US IN ESS IN T ER RU PT I ON , B U S I NE S S O P P O RT U N I T Y O R D ATA T H AT M AY A R I S E
FRO M T HE USE O F TH IS DO CU M EN T O R T HE IN F OR M AT IO N I N I T, E V E N I N T H E C A S E O F E R R O R S I N O R
OM IS SI O NS FRO M T HI S DOC UM EN T O R IT S CO NT E N T.

This document is Nokia’ proprietary and confidential information, which may not be distributed or disclosed to any third parties without the
prior written consent of Nokia.

Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of their
respective owners, and they are mentioned for identification purposes only.

Copyright © 2021 Nokia. All rights reserved.

Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully read the
safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of this
document or documentation set.

Nokia is continually striving to reduce the adverse environmental effects of its products and services. We would like to encourage you
as our customers and users to join us in working towards a cleaner, safer environment. Please recycle product packaging and follow the
recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us at Nokia for
any additional information.
Layer Management Strategy DN09257552 1-0 Table of Contents
Configuration File Guide

Contents
1 Summary of changes...................................................................................................................................... 4

2 Introduction to Layer Management Strategy (LMS).....................................................................................6

3 Versions............................................................................................................................................................ 9

4 Site or sector based LMS.............................................................................................................................10

5 Filters.............................................................................................................................................................. 13

6 Layers..............................................................................................................................................................15

7 Optional layers...............................................................................................................................................18

8 Templates........................................................................................................................................................19
8.1 Vendor MO templates............................................................................................................................. 19
8.2 Settings templates...................................................................................................................................21
8.2.1 Vendor MO parameters.................................................................................................................. 23

9 Conditions...................................................................................................................................................... 25

10 Rules............................................................................................................................................................. 31
10.1 Frequency row rules............................................................................................................................. 34
10.2 eNodeB rules.........................................................................................................................................34
10.3 Row rules.............................................................................................................................................. 34

11 Appendix: LMS examples........................................................................................................................... 36

EdenNet 21 © 2021 Nokia 3

Layer Management Strategy DN09257552 1-0 Summary of changes
Configuration File Guide

1 Summary of changes

Release Change description

EdenNet 21 No change.

EdenNet 20 FP No change.
2011

EdenNet 20 FP No change.
2010

EdenNet 20 FP No change.
2009

EdenNet 20 FP No change.
2008

EdenNet 20 FP No change.
2007

EdenNet 20 No change.

EdenNet 19A FP No change.

2004

EdenNet 19A FP No change.

2003

EdenNet 19A FP No change.

2002

EdenNet 19A FP No change.

2001

EdenNet 19A FP No change.

1912

EdenNet 19A FP No change.

1911

EdenNet 19A The Appendix: LMS examples section is updated.

EdenNet 19 FP No change.
1907

EdenNet 19 FP No change.
1906

EdenNet 19 FP No change.
1905

EdenNet 21 © 2021 Nokia 4

Layer Management Strategy DN09257552 1-0 Summary of changes
Configuration File Guide

Release Change description

EdenNet 19 FP No change.
1904

EdenNet 19 No change.

EdenNet 18 SP1 No change.

1901

EdenNet 18 SP1 Updated sections to include NR related changes:

1812
• Introduction to Layer Management Strategy (LMS)
• Filters
• Layers
• Optional layers
• Vendor MO templates
• Rules

Added sections:

• Site or sector based LMS

EdenNet 18 SP1 No updates.

1811

EdenNet 18 SP1 No updates.

EdenNet 18 No updates.

EdenNet 17 SP1 No updates.

FP1

EdenNet 17 SP1 No updates.

EdenNet 17 FP1 No updates.

EdenNet 17 This document briefly describes the EdenNet LMS (Layer Management Strate-
gy).

Table 1: Summary of changes

EdenNet 21 © 2021 Nokia 5

Layer Management Strategy DN09257552 1-0 Introduction to Layer Management
Configuration File Guide Strategy (LMS)

2 Introduction to Layer Management Strategy (LMS)

An LMS (Layer Management Strategy) is a description of the relations that are allowed between dif-
ferent layers in an operator's network and the attribute values that should be used for these relations.
Figure 1: Layer Management Strategy shows a simple operator LMS.

Figure 1: Layer Management Strategy

The EdenNet LMS enables the translation of the visual rules shown in Figure 1: Layer Management
Strategy into a machine-readable format to be used in the EdenNet modules. It is a JSON syntax file
that contains a description of the layers, rules, attributes, and parameter setting templates which de-
fine an operator's LMS. When the LMS is configured with a module like ANR which adds neighbor re-
lations, the module uses the LMS to determine:

• if two cells are permitted to be neighbors

• the attribute values to use for the relation object that will be created

When the LMS is configured with the LMS Enforcement module, the existing relations and attribute
values are audited against this LMS.

EdenNet 21 © 2021 Nokia 6

Layer Management Strategy DN09257552 1-0 Introduction to Layer Management
Configuration File Guide Strategy (LMS)

Table 2: LMS sections describes the main sections of the LMS.

LMS section Overview

Layers The Layers section identifies the layers in the

network. This section is the basis for defining
which relations are allowed between different lay-
ers. In Figure 1: Layer Management Strategy,
frequency bands are used to identify the layers.
However, specific frequencies and cell names
can also be used (useful in networks where fre-
quencies vary from county to county).

Rules The Rules section translates the arrows in LMS

diagrams into the allowed or permissible transi-
tions between layers. Omission from the Rules
section means that the transition is not allowed.
Therefore, for LMS Enforcement, it is important to
define all the allowed relations. When a transition
is defined in the LMS, a Template is also speci-
fied.

Templates A Template is a set of attribute values to be used

when a relation is created (by the ANR modules)
or audited (by the LMS Enforcement module). In
Figure 1: Layer Management Strategy, the opera-
tor could apply a +ve dB offset for relations from
the U900 layer and a -ve dB offset for relations to
the U900 layer for traffic offload reasons. This off-
set is achievable through separate template defi-
nitions.

Node Configurations Within each Rules section, several different node

configurations are defined (each with its own set
of rules) to be applied to the different site types.
Figure 1: Layer Management Strategy shows on-
ly one node configuration. Another node config-
uration could be defined, for example, where the
site has no GSM cells and direct relations be-
tween FDD2 and U900 are allowed.

Conditions The Conditions section defines logical tests

which can be evaluated against potential rela-
tions. These conditions are generally used with-
in the Rules section to select which relations are
allowed and also which attribute value template

EdenNet 21 © 2021 Nokia 7

Layer Management Strategy DN09257552 1-0 Introduction to Layer Management
Configuration File Guide Strategy (LMS)

LMS section Overview

should be used for the allowed relations. Com-

mon examples of conditions are co-site only or
co-sector only rules with specific attribute value
templates to be used for those relations. Condi-
tions are evaluated in order until one is found to
be true.

Filters Filters are evaluated only against a specific

source cell or target cell – not against a relation.
Filters are used as building blocks for conditions
which apply to the source or target cell. For ex-
ample, to define a relation test only where the tar-
get cell has a specific cell level attribute value, or
where the source cell is of a specific vendor type.

Table 2: LMS sections

Additional capabilities include:

• the ability to specify Max Neighbor Size conditions to limit the number of relations that are al-
lowed for a specific transition.
• the use of neighbor RRC list type (for UMTS) to force the use of specific connected or idle
mode policies (for example, DCH Only or SIB11Bis and DCH).

Frequency relation rules are also available to define the allowed frequency objects in cells, for ex-
ample, to define the LTE frequencies which should be measured for cell reselection when a user is
camped in a UMTS cell.

The LMS is complex but also extremely powerful, having been applied successfully in many operator
networks to cover a wide range of different scenarios.

The following chapters describe the sections of the LMS, the allowed keywords in each section and
the overall structure that should be followed.

Note: To create an LMS file, contact the Nokia technical support team.

EdenNet 21 © 2021 Nokia 8

Layer Management Strategy DN09257552 1-0 Versions
Configuration File Guide

3 Versions

The LMS is versioned to support the new structure by using the version attribute. An unversioned LMS
is considered as version 1.0, which is the older format.

Version 2.0 has to be explicitly specified in the LMS, and this version will support the new frequency
relations.

For example:

"version": "2.0"

EdenNet 21 © 2021 Nokia 9

Layer Management Strategy DN09257552 1-0 Site or sector based LMS
Configuration File Guide

4 Site or sector based LMS

The LMS is configured either for site based or sector based per OSS.

Node configurations are basically defined by:

• a set of source layers present in each site or sector

• the rules for allowed target layers that should be applied

Each site or sector in the network must match against only one node configuration as defined in the
LMS. This is important for sector based LMS since the number of node configurations can be poten-
tially much larger.

To configure sector based, use the key word sector based and set the value to True. By default,
the LMS configuration is site based. For example:

{
"my_oss1": {
"version": "2.0",
"sector based": "True",
entire Sector Based LMS for "my_oss1" contained here
}
{
"my_oss2": {
"version": "2.0",
entire Site Based LMS of "my_oss2" contained here
}

Figure 2: Site based node configuration matching (default) is an example for site based configuration.
Entire site is considered for matching to node configurations with source layers: GSM900, GSM1800,
FDD1, FDD2, FDD3, UMTS900

EdenNet 21 © 2021 Nokia 10

Layer Management Strategy DN09257552 1-0 Site or sector based LMS
Configuration File Guide

Figure 2: Site based node configuration matching (default)

Figure 3: Sector based node configuration matching is an example for sector based configuration.
Each sector is considered for matching to node configurations.

Sector A matches node configuration with source layers: GSM900, GSM1800, FDD1, FDD2, FDD3,
UMTS900.

Sector B matches node configuration with source layers: GSM900, GSM1800, FDD1, FDD2,
UMTS900.

EdenNet 21 © 2021 Nokia 11

Layer Management Strategy DN09257552 1-0 Site or sector based LMS
Configuration File Guide

Figure 3: Sector based node configuration matching

EdenNet 21 © 2021 Nokia 12

Layer Management Strategy DN09257552 1-0 Filters
Configuration File Guide

5 Filters

Filters act as a subset of conditions. Filters evaluate individual cells, while conditions evaluate a rela-
tion between two cells. Filters also act as building blocks for conditions.

The first level key is the name of a filter. The filter name is arbitrary, but should reflect the operator's
terminology.

The second level (first level value) key specifies an attribute of a cell which does not imply a frequency
or a set of frequencies. The second level value is the value of the attribute that must be matched for a
cell to pass this filter.

Valid keys are: {brand, vendor, coverage_type, rf_solution, name, site_id, dn,
rnc_name, rac, lac, tac, ura, enodeb_id, external, filter, or, and, not,
controller_mo_attribute, bts_mo_attribute, cell_mo_attribute}

Table 3: Filter keys describes the valid filter keys.

Name Description

brand matches the vendor of the cell. Possible val-

ues are {"nsn", "ericsson", "huawei",
"alu", "zte"}.

vendor matches the vendor of the cell. Possible val-

ues are {"nsn", "ericsson", "huawei",
"alu", "zte"}.

coverage_type matches the coverage type of the cell.

rf_solution matches the RF solution of the cell.

name matches the cell name.

site_id matches the site ID of the cell.

dn matches the DN of the cell.

rnc_name matches the RNC name of the cell.

rac matches the routing area code.

lac matches the location area code.

tac matches the tracking area code.

ura matches the UTRAN registration area.

nr_cell_type NR cell type. Currently, NSA is supported.

enodeb_id matches the eNodeB ID for LTE BTS.

gnodeb_id matches the gNodeB ID for 5G BTS

EdenNet 21 © 2021 Nokia 13

Layer Management Strategy DN09257552 1-0 Filters
Configuration File Guide

Name Description

external has a value of 1 or 0.

• 1 indicates that the cell is not managed by a

parent.
• 0 indicates that the cell is unmanaged.

filter reuses the already defined filter.

controller_mo_attribute matches the cell's controller MO attribute with the

specified name and value. Values are key value
pairs containing MO attributes, where valid keys
are: {mo_type, name, value, operator}.

bts_mo_attribute matches the cell's parent BTS MO attribute with

the specified name and value. Values are key val-
ue pairs containing MO attributes, where valid
keys are: {mo_type, name, value, opera-
tor}.

cell_mo_attribute . matches the cell MO attribute with the specified

name and value. Values are key value pairs con-
taining MO attributes, where valid keys are: {mo_
type, name, value, operator}.

Table 3: Filter keys

A value composed of multiple key-value pairs implies an AND. For example:

"and_filter": { "site_id": "1", "rnc_name": "rnc1" } is a short form for

"and_filter": { "and": [{"site_id": "1"}, {"rnc_name": "rnc1"} ] }

An array specified as the value part of a key-value pair is ORed. For example:

{ "earfcn": [ 10712, 10762, 10737 ] }

defines a filter which matches a cell with earfcn = 10712, 10762 or 10737.

MO attributes:

Valid keys are: {mo_type, name, value, operator}

name: name of the MO attribute.

value: value that the attribute's value should match.

operator is optional. It is used to indicate the type of relationship. Must be one of {"eq", "lt",
"le", "gt", "ge", "in"}

mo_type is optional. It is needed if the attribute is to be looked up on a child MO.

EdenNet 21 © 2021 Nokia 14

Layer Management Strategy DN09257552 1-0 Layers
Configuration File Guide

6 Layers
The LMS configuration provides the frequency layer details in each technology (LTE, UMTS, GSM),
and the rules for the allowed neighbor definitions from each source frequency layer to the target fre-
quency layer.

Layers define the allowed relations. A layer is a filter which has either exactly one frequency attribute,
or an OR relation on a set of frequencies. If a cell matches all the attributes specified by that layer,
then the cell is said to belong to that layer. A layer does not necessarily have a unique frequency at-
tribute. For example:

"layers": {
"NR": { "technology": "NR"},
"LTE": { "technology": "LTE" },
"UMTS": { "technology": "UMTS" },
"GSM": { "technology": "GSM" },
"P1_Zone": {"and": [{ "name": "^P.*1$" }, {"lac": [123, 124, 125]}]},
"GSM1900": { "band_name": "GSM1900" },
"PCS1900": { "band_name": "PCS1900" },
"UMTS_internal_cells": {"and": [{ "technology": "UMTS" },
{"external": 0}]},
"NR_2": { "nrarfcn": "422220"}
},

Note: The frequency attribute may not be explicit. This means that there need not be a one-
to-one relationship between the layer and the frequency.

The first level key is the name of a layer. The layer name is arbitrary, but it should reflect the operator's
terminology.

The second level key specifies an attribute of a cell which implies a frequency or a set of frequencies.
The second level value is the value of the attribute that must be matched for a cell to belong to this
layer.

Valid keys are: {technology, name, band_name, band, operating_band, earfcn,

nrarfcn, uarfcn, arfcn, layer, or, and, not}. These can be composed with any filter
key.

Table 4: Layer keys describes the valid layer keys.

Name Description

technology matches the layer based on the technology of the

cell. The possible values are NR, LTE, UMTS,
and GSM.

name matches the layer based on the name of the cell.

EdenNet 21 © 2021 Nokia 15

Layer Management Strategy DN09257552 1-0 Layers
Configuration File Guide

Name Description

band_name matches the layer based on the 3GPP band

name of the cell.

Valid values are:

• For GSM: 'GSM900', 'GSM850',

'GSM500', 'GSM700', 'GSM1900',
'PCS1900', 'DCS1800', 'GSM1800'
• For UMTS: 'IMT', 'PCS', 'DCS',
'AWS', 'CLR', 'IMT-E', 'E-GSM',
'EAWS', 'LPDC', 'LSMH', 'USMH C',
'USMH D', 'EUDD', 'UPDC', 'EPCS',
'ECLR'
• For LTE: not valid
• For NR: not valid

band matches the layer based on the 3GPP band of

the cell.

For example: "1900". Normally, this is combined

with technology. Valid values are 2100, 1900,
1800, 1700, 850, 2600, 900, 1500, 700, 800, 850.

Generally, for LTE, the EARFCN is used directly

and for NR, the NRARFCN is used directly.

operating_band matches the layer based on the 3GPP operating

band of the cell.

For example: "1". Normally, this is combined with

the technology. Valid values are 1-5, 7, 8, 10-14,
20, 21, 25, 26.

earfcn matches the layer based on the operating fre-

quency for LTE cells.

nrarfcn matches the layer based on the operating fre-

quency channel number for NR cells. For FDD, it
matches the downlink operating frequency as de-
fined in the 3GPP standard 38.104.

uarfcn matches the layer based on the operating fre-

quency for WCDMA cells.

arfcn matches the layer based on the operating fre-

quency for GSM cells.

EdenNet 21 © 2021 Nokia 16

Layer Management Strategy DN09257552 1-0 Layers
Configuration File Guide

Name Description

layer matches the layer with an already defined layer

definition.

Table 4: Layer keys

A value composed of multiple key-value pairs implies an AND. For example:

"and_layer": { "filter": "femtos", "layer": "F1" } is a short form for "and_layer":

{ "and": [ {"filter": "femtos"}, {"layer": "F1"} ] }

An array specified as the value part of a key-value pair implies an OR. For example:

{ "layer": [ "F1", "F2", "F3" ] }' defines a layer which is composed of layer "F1" or layer
"F2" or layer "F3".

Note:

• Do not refer to a brand or vendor within a layer definition. It is better to distinguish be-
tween brands or vendors in a condition.
• Nokia recommends that you do not use brand or vendor in filters which are used in lay-
ers.

EdenNet 21 © 2021 Nokia 17

Layer Management Strategy DN09257552 1-0 Optional layers
Configuration File Guide

7 Optional layers

An optional layer is a layer in a node configuration for which there need not be a matching cell belong-
ing to that node in order for the node configuration to match. For example:

"optional layers": {
"optional_LTE": {"layer": "LTE"},
"optional_GSM": {"layer": "GSM"},
"optional_NR": {"layer": "NR_2"}
},

EdenNet 21 © 2021 Nokia 18

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

8 Templates

Templates are a set of relation object parameters and their values.

The first level key is the name of a hand-over parameter template. The template name is arbitrary, but
should reflect the operator's terminology. The first level value is a dictionary. It can be the empty set.

The second level key specifies the attributes of a managed object that are recognized by the OSS.
The second level value is the value of the attribute that will be used when creating or updating the cor-
responding managed object.

8.1 Vendor MO templates

Vendor MO templates are an optional structure which define vendor-specific MO parameters.

The first level key is the name of a vendor MO template. The template name is arbitrary, but should re-
flect the operator's terminology. The first level value is a set of key-value pairs. It is mandatory to spec-
ify the handover parameters.

Valid keys are: {condition, metadata, template, parameters}

Table 5: Vendor MO template keys describes the vendor MO template keys.

Name Description

condition refers to a previously defined condition.

metadata is an optional field that specifies the metada-

ta that can used for verification of the MO. The
metadata specifies the following fields:

• vendor: The vendor for which the MO is de-

fined. For example: Nokia, ZTE.
• technology: The technology for which the MO
is defined. For example: 2G, 3G, 4G.
• version: The OSS version number.
• type: Different types of MOs such as adja-
cency, frequency, external cell, and so on,
can be modified using the template. This field
indicates the specific MO being modified. If
this field is not specified, the appropriate ad-
jacency MO is modified.

template refers to a previously defined parameter tem-

plate.

EdenNet 21 © 2021 Nokia 19

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

Name Description

parameters specifies a key-value pair of handover parame-

ters.

Table 5: Vendor MO template keys

The below code snippet provides an example of a vendor MO template:

"vendor mo templates": {
"vtemplate0": {
"metadata": {
"vendor": "ericsson",
"technology": "UMTS"
},
"template": "intra_hops"
},
"vdefault": {
"metadata":{
},
"parameters":{}
}

Example of template definition for Nokia:

"templates": {
"defaults": {},
"lte_gsm": {
"nrControl": "automatic",
"srvccAllowed": "allowed"
},
"lte_umts": {
"csfbPsHoAllowed": "forbidden",
"nrControl": "automatic",
"psHoAllowed": "allowed",
"srvccAllowed": "allowed"
},
"gsm_intra": {
"hoMarginPbgt": 4
},
"gsm_intra_Extended": {
"hoMarginPbgt": 4,
"hoTargetArea": 2
},
"umts_gsm": {
"NrtHopgIdentifier": 1,
"RtHopgIdentifier": 2
},
"umts_intra": {

EdenNet 21 © 2021 Nokia 20

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

"HSDPAHopsIdentifier": 7,
"NrtHopsIdentifier": 1,
"RTWithHSDPAHopsIdentifier": 8,
"RtHopsIdentifier": 2
},
"umts_inter": {
"NrtHopiIdentifier": 1,
"RtHopiIdentifier": 2
},
"nr_nr_intra": {
"cellIndividualSsbRsrpOffset": "2dB",
"cellIndividualSsbRsrqOffset": "10dB"
},
"lte_nr_freq": {
"b1TriggerQuantity": "RSRP",
"quantityConfigId": "0",
"b1ThresholdNrRsrp": "-120" ,
"hysB1ThresholdRsrp": "2",
"b1TimeToTriggerRsrp": "100ms" ,
"ssbDuration": "sf3",
"ssbOffset":"0",
"ssbPeriodicity":"sf20-r15",
"ssbSubcarrierSpacing":"120kHz"

}
}

8.2 Settings templates

A settings template is an optional structure which specifies settings related to neighbors.

The first level key is the name of a settings template. The template name is arbitrary, but should reflect
the operator's terminology. The first level value is a set of key-value pairs. You must specify the han-
dover parameters.

Valid keys for version 1 are: {hop, max neighbor size, desired neighbor size,
neighbor RRC list type, neighbor permission type , priority}

Valid keys for version 2 are: {vendor mo parameters, max neighbor size, desired
neighbor size, neighbor RRC list type, neighbor permission type , priority}

Table 6: Settings template properties describes the settings template properties.

Name Description

hop defines the handover parameters. The value is

a key-value pair containing one of {template,

EdenNet 21 © 2021 Nokia 21

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

Name Description

oss template, parameters}, and optionally

condition.

template refers to a previously defined parameter tem-

plate.

oss template specifies the name of a set of handover parame-

ters which is known to the OSS and is referred to
by this name.

parameters specifies a key-value pair of handover parame-

ters.

condition refers to a previously defined condition.

max neighbor size This optional parameter specifies the maximum

number of neighbors that satisfy the specified
conditions which can be added.

Note: The max neighbor size

specified within Settings should al-
ways be less than the max neighbor
size specified for the layer-transition.

desired neighbor size This optional parameter specifies the number of

spaces reserved in the neighbor list for candi-
date neighbor cells that satisfy the specified con-
ditions.

Note: The desired neighbor size spec-

ified within Settings should always be
less than or equal to the max neigh-
bor size specified for the layer-tran-
sition.

neighbor RRC list type This optional parameter specifies the type
of neighbor list. Valid values are DchOn-
ly, Sib11AndDch, Sib11BisAndDch,
Sib11Only, Sib11BisOnly.

neighbor permission type This optional parameter can have two values
- WhiteList and BlackList. It is used to specify
if the specific relation should be whitelisted or
blacklisted.

priority It is a way of indicating that some neighbors can-

not be added until all the permitted neighbors of

EdenNet 21 © 2021 Nokia 22

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

Name Description

another (higher priority) class have been added.

It is optional.

vendor MO parameters This is an optional field that can be used to spec-

ify the vendor-specific MO parameters to be
used for a specific layer relation. The parame-
ters are specified in the form of a template un-
der Vendor MO templates. The Vendor MO tem-
plates have the following fields:

• Metadata: This is an optional field that spec-

ifies the metadata that can be used for verifi-
cation of the MO.
• Parameters: This field specifies the parame-
ters for the MO. Parameters specified here
are not interpreted by the LMS, and are di-
rectly applied to the OSS.

Table 6: Settings template properties

8.2.1 Vendor MO parameters

Vendor MO parameters either consist of a dictionary of key value pairs with a single entry, or a list of
dictionaries with 2 entries.

The first form (dictionary) is always applied if the condition for the corresponding rule passes. It is a
shortcut for the second form.

The second form (list) consists of tuples of key-value pairs which are evaluated in top-down order. The
first one in which the condition is satisfied will be applied.

Valid keys are: {condition, template, oss template, parameters}

Table 7: Vendor MO parameter keys describes the vendor MO parameter keys.

Name Description

condition refers to a previously defined condition.

template specifies the name of a previously defined set of

handover parameters in the Templates section.

oss template specifies the name of a set of handover parame-

ters which is known to the OSS and is referred to
by this name.

EdenNet 21 © 2021 Nokia 23

Layer Management Strategy DN09257552 1-0 Templates
Configuration File Guide

Name Description

parameters specifies a dictionary of key-value pairs. The key

specifies the name of an attribute of a managed
object that is recognized by the OSS. The value
is the value of the attribute that will be used when
creating or updating the corresponding managed
object.

Table 7: Vendor MO parameter keys

Note:

• Intra-frequency rules must be explicitly specified.

The only exception is in the case of cell objects which do not have any OSS defined due
to which there is no way to determine which LMS to use, and only Intra-frequency han-
dovers are allowed.

The HOP (Handover Parameter) defaults to an empty dictionary.

• The HOP can use OSS templates as well.

EdenNet 21 © 2021 Nokia 24

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

9 Conditions

A condition is a predicate that is evaluated on the specified source and target cell for a proposed
neighbor. These predicates can also be applied to existing neighbor relations.

It is optional and is used to define a node configuration for use via the configuration keyword.

The first level key is the name of a predicate. The condition name is arbitrary, but should reflect the
operator's terminology.

The second level key specifies a relationship type between two cells, or a property of the source or tar-
get cell. The second level value indicates the constraints that the relationship must meet for the condi-
tion to pass (return TRUE).

Valid keys are: {always, relation, relation-function, name, target, source, and,
or, not, target_configuration_not_exists }

For example:

{ "condition" : { "target": { "configuration": "triple2100" } }

name refers to a previously defined condition.

The valid values for relation are {co-site, co-sector, intra, irat, intra-RNC,
intra-LAC, intra-RAC, intra-URA, unknown_RAC, unknown_URA, first_tier, tier,
max_tier}

Table 8: Relation values describes the valid values for the relation key.

Name Description

co-site indicates that the source and target must belong

to the same site based on the operator definition.

co-sector indicates that the source and target must belong

to the same sector based on the operator defini-
tion.

intra indicates that the source and target must have

the same frequency.

irat indicates that the source and target must belong

to different technologies.

intra-RNC indicates that the source and target must have

the same radio network controller.

intra-LAC indicates that the source and target must have

the same location area code.

EdenNet 21 © 2021 Nokia 25

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

Name Description

intra-RAC indicates that the source and target must have

the same routing area code.

intra-URA indicates that the source and target must have

the same UTRAN registration area.

unknown_URA is used when it cannot be determined if the

source and target have the same UTRAN regis-
tration area.

unknown_RAC is used when it cannot be determined if the

source and target have the same routing area
code.

first_tier indicates that the target must be a first tier neigh-

bor for the source.

tier indicates that the target must have a specified

tier count from the source.

max_tier indicates that the target must have a tier count

less than or equal to the specified tier count from
the source.

Note: Specifying inter-frequency re-

lations for RNC, LAC, RAC, and URA
must be done by using not and or.

For example: { "not": { "or":

[ { "relation": "intra-
URA" }, { "relation":
"unknown_URA" } ] } }

Table 8: Relation values

Relation-function specifies a customized, operator specific, and defined function. Table 9: Rela-
tion-function values describes the relation-function values.

Name Description

majority true if the target's frequency matches that of the

majority of the first tier neighbors of the source
cell which are on the target's layer.

local true if the target's frequency matches that of a

cell on the same layer which is in the same node
as the source cell.

EdenNet 21 © 2021 Nokia 26

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

Name Description

majority_for_layer true if the target's frequency matches that of the

majority of the first tier neighbors of the source
cell which are in the specified layer.

local_for_layer true if the target's frequency matches that of a

cell in the same node as the source cell and is al-
so in the specified layer.

Table 9: Relation-function values

Source properties specify a condition which applies to the source cell. The value can be one of
{source, target, configuration} as well as any of the valid keys for filter or layer. Table 10:
Source properties describes the source properties.

Name Description

source specifies that the source value must act as the

source in an existing neighbor relation which has
the same source value as the source cell. The
value is any valid condition expression, or the
name of a previously defined condition. It should
support using relation.

target specifies that the source value must act as the

target in an existing neighbor relation which has
the same source value as the target cell. The val-
ue is any valid condition expression, or the name
of a previously defined condition.

configuration specifies that the source must have the specified

node configuration. The value is the node config-
uration name, which must be previously defined.

filter specifies the name of a previously defined filter to

be applied to the source.

layer specifies the name of a previously defined layer

to which the source must belong.

Table 10: Source properties

For example, the below code snippet provides an example of a condition which applies to the source
cell:

"no2100":
{ "not":

EdenNet 21 © 2021 Nokia 27

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

{
"relation": "co-site",
"target": { "layer": "2100" }
}
},
"co-site_and_close_900_w_o_2100":
{ "or":
[
{ "relation": "co-site" },
{
"name": "close",
"target": { "source": "no2100" }
}
]
}

Table 11: Target values describes the target values.

Name Description

target specifies a condition which applies to the target

cell. The value can be one of {source, tar-
get, configuration} as well as any of the
valid keys for filter or layer.

source specifies that the target must act as the source in

an existing neighbor relation which has the same
target as the source cell. The value is any valid
condition expression, or the name of a previously
defined condition.

target specifies that the target value must act as the tar-
get in an existing neighbor relation which has the
same target value as the target cell. The value is
any valid condition expression, or the name of a
previously defined condition.

configuration specifies that the target must have the specified

node configuration. The value is the node config-
uration name, which must be previously defined.

filter specifies the name of a filter to be applied to the

target.

layer specifies the name of a layer to which the target

must belong.

target_configuration_not_exists indicates that there is no node configuration

matching the target.

EdenNet 21 © 2021 Nokia 28

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

Table 11: Target values

OR relationships are specified by the or key.

For example:

"or_example":

{ "or": [ { "arfcn": 3011}, { "arfcn": 3032} ] }

AND relationships are specified by an explicit and key.

For example:

{ "and":
[
{ "relation": "co-site" },
{ "target": { "layer": "F2" } }
]
}

All elements inside {} braces are ANDed together. The following is a short form for the above:

"and_example2":
{
"relation": "co-site",
"target": { "layer": "F2" }
}

There cannot be duplicate keywords inside the {} braces because it might result in an empty set. For
example, the following content is not permitted:

"and_example3":
{
"earfcn": "5035",
"earfcn": "2275"
}

Instead, an explicit and must be used:

"and_example4":
{ "and":
[
{ "name": "A" },
{ "name": "B" }
]
}

EdenNet 21 © 2021 Nokia 29

Layer Management Strategy DN09257552 1-0 Conditions
Configuration File Guide

NOT relationships are specified by the not key. For example:

"not_example:"
{ "not": { "technology": "LTE" } }

Metadata syntax

Valid keys are: {vendor, type, technology, version}.

The vendor value must be one of {"nsn", "ericsson", "huawei", "alu", "zte"}, and refers
to the vendor of the source cell.

The technology value must be one of {"GSM", "UMTS", "LTE"}, and refers to the technology of the
source cell.

Raise keyword

Use the raise keyword in the place of hop or settings if a relation has to be skipped upon
encountering a certain condition.

For example:

For Layer F1 to F3 transition, if the node configuration of the target cannot be determined, add a new
condition as shown below using the raise syntax after the target node configuration check.

“F1”:{
"F3":
[{"condition”: {“target":{ "configuration": "B/0"}},"hop":
{"template": "ADJI_41_42"}},
{“condition”:”target_configuration_not_exists”, “raise”:”
NoNodeConfigurationError”}
]
}

If the configuration of the target cell cannot be determined, the new condition ensures that the relation
is skipped from deletion.

EdenNet 21 © 2021 Nokia 30

Layer Management Strategy DN09257552 1-0 Rules
Configuration File Guide

10 Rules

A rulebook is a map of the node configuration to layer strategy set. The node configuration has a
name which is not used but is a way of linking the strategy to an operator's policy or documentation.
The map is implicit in that the node configuration is defined by the set of source layers in the layer
strategy. Each layer strategy must be unique.

A rule specifies a set of conditions on the proposed relation, source, and/or target that must be met
and defines under what conditions a handover from a source cell to a neighboring target cell is permit-
ted. If no rule applies, then the handover is not allowed.

The rule to be applied is determined by:

1. finding the node configuration for the source cell.

2. finding the layer to which the source cell belongs.
3. finding the layer to which the target cell belongs.

There must be at most one rule which can apply. The rulebook also defines the return HOP (Handover
Parameter) value if the corresponding rule evaluates to true.

Note: If there is no rule which is true for a relation, then the relation is not permitted. You
must explicitly specify a rule for a relation to be permitted.

The first level key is the name of a node configuration, or an asterisk. The node configuration name is
arbitrary, but should reflect the operator's terminology. The first level value is a dictionary.

The asterisk ("*") matches all configurations.

For example:

{
"*":
{
"gsm":
{
"any": { "condition" : "always", "hop" : {"template": "default"}
}
},
"lte":
{
"any": { "condition" : "always", "hop" : {"template": "default"}
}
},
"umts":
{
"gsm": { "condition" : "always", "hop" : {"template": "default"}
},

EdenNet 21 © 2021 Nokia 31

Layer Management Strategy DN09257552 1-0 Rules
Configuration File Guide

"lte": { "condition" : "always", "hop" : {"template": "default"}

},
"umts": { "condition" : "always", "hop" : {"template":
"default"} }
}
}
}

The second level key is the name of a source layer, previously defined in the layers section.

Version 1:

The third level key is the name of a target layer, previously defined in the layers section.

Note: Cells can belong to more than one layer.

Version 2:

The third level key specifies the type of rule. Valid values are cell_relations, and
frequency_relations.

The fourth level key is the name of a target layer, previously defined in the layers section.

Note: Cells can belong to more than one layer.

A node configuration is a set of layers that must be an exact match to the layers defined by the set of
cells present on a node.

No layer can be a superset of another layer within a node configuration.

Each cell must belong to exactly one layer within a node configuration.

Example for rules block consisting of LTE to NR relations for two node configurations.

Note: The permitted LTE cell to NR frequency relations (for B1 measurement configuration
per NRARFCN) is matching the permitted LTE cell to NR cell relations.

"rules": {
"NodeConfig_1": {
"LTE_3650": {
"cell_relations": {
"NR_2058332": {
"condition": "always",
"vendor mo parameters": {
"template": "lte_nr_irat"
}
}
},
"frequency_relations": {

EdenNet 21 © 2021 Nokia 32

Layer Management Strategy DN09257552 1-0 Rules
Configuration File Guide

"NR_2058332": {
"condition": "always",
"vendor mo parameters": {
"template": "lte_nr_freq"
}
}
}
},
"NR_2058332": {
"cell_relations": {
"NR_2058332": {
"condition": "always",
"vendor mo parameters": {
"template": "nr_nr_intra"
}
}
}
}
},
"NodeConfig_2": {
"LTE_2222": {
"cell_relations": {
"NR_628333": {
"condition": "always",
"vendor mo parameters": {
"template": "lte_nr_irat"
}
}
},
"frequency_relations": {
"NR_628333": {
"condition": "always",
"vendor mo parameters": {
"template": "lte_nr_freq"
}
}
}
},
"NR_628333": {
"cell_relations": {
"NR_628333": {
"condition": "always",
"vendor mo parameters": {
"template": "nr_nr_intra"
}
}
}
}
}
}

EdenNet 21 © 2021 Nokia 33

Layer Management Strategy DN09257552 1-0 Rules
Configuration File Guide

10.1 Frequency row rules

It is similar to row rules, but the targets are frequency objects.

10.2 eNodeB rules

eNodeB rules are used to:

• set the parameters for external cells.

• define which attribute value templates to use for LNADJW and LNRELW objects at the eNodeB
level (for Nokia).

The first level key is the name of a filter, previously defined in the filters section. The first level value is
a dictionary.

The second level key is the name of a target layer, previously defined in the layers section.

10.3 Row rules

The first level key is the name of a layer strategy. The name is arbitrary, but should reflect the
operator's terminology.

The second level key is the name of a layer previously defined in the layers section. The second level
value is a set of key-value pairs.

Valid keys for version 1 are: {condition, domain, mode, direction, hop, priority}

Valid keys for version 2 are: {condition, domain, mode, direction, vendor mo
parameters, priority max neighbor size, desired neighbor size, neighbor RRC
list type, neighbor permission type}

Table 12: Row rules keys describes the row rules keys.

Name Description

Condition is an expression that is evaluated to determine if

the relation type is permitted. It is required.

Domain is optional. The domain value must be one of

{data, voice}. If it is omitted, then the rule ap-
plies to both data and voice domains.

Voice refers to Circuit-Switched (CS).

Data refers to Packet-Switched (PS).

EdenNet 21 © 2021 Nokia 34

Layer Management Strategy DN09257552 1-0 Rules
Configuration File Guide

Name Description

Mode is optional. The mode value must be one of

{idle, connected}. If it is omitted, then the
rule applies to both idle and connected modes.

Hop defines the hand-over parameters, and is re-

quired. The value is a dictionary containing one
of {template, oss template, parame-
ters}, and optionally condition.

Template must refer to a previously defined parameter tem-

plate.

oss template specifies the name of a set of handover parame-

ters which is known to the OSS and is referred to
by this name.

parameters specifies a dictionary of handover parameters.

condition refers to a previously defined condition.

priority is optional. It is a way of indicating that some

neighbors cannot be added until all the permitted
neighbors of another (higher priority) class have
been added.

Table 12: Row rules keys

EdenNet 21 © 2021 Nokia 35

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

11 Appendix: LMS examples

The following are examples of the LMS configuration file:

Example 1 (version 1.0):

{
"*": {
"layers": {
"2100_F1": {
"uarfcn": 10612
},
"2100_F2": {
"uarfcn": 10588
},
"2100_F3": {
"uarfcn": 10563
},
"GSM": {
"technology": "GSM"
}
},
"optional layers": {
"optional_GSM": {
"layer": "GSM"
}
},
"filters": {
"femto_lac": {
"lac": 65530
}
},
"conditions": {
"cosite": {
"relation": "co-site"
},
"cosector": {
"relation": "co-sector"
},
"first_tier": {
"relation": "first_tier"
},
"target_femto": {
"target": {
"filter": "femto_lac"
}
}
},

EdenNet 21 © 2021 Nokia 36

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"templates": {
"ADJS": {
"HSDPAHopsIdentifier": 12,
"NrtHopsIdentifier": 12,
"RTWithHSDPAHopsIdentifier": 12,
"RtHopsIdentifier": 12
},
"ADJG": {
"RtHopgIdentifier": 2
},
"2100_NOT_INTERFERED": {
"RtHopiIdentifier": 95,
"NrtHopiIdentifier": 96
},
"default": {}
},
"rules": {
"*": {
"2100_F1": {
"2100_F1": {
"condition": "always",
"hop": [{
"template": "ADJS",
"condition": "always"
}]
},
"2100_F2": {
"condition": {
"name": "cosite"
},
"hop": [{
"template": "2100_NOT_INTERFERED",
"condition": "always"
}]
},
"GSM": {
"condition": "always",
"hop": [{
"template": "ADJG",
"condition": "always"
}]
}
},
"2100_F2": {
"2100_F1": {
"condition": {
"name": "cosite"
},
"hop": [{
"template": "2100_NOT_INTERFERED",

EdenNet 21 © 2021 Nokia 37

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"condition": "always"
}]
},
"2100_F2": {
"condition": "always",
"hop": [{
"template": "ADJS",
"condition": "always"
}]
},
"GSM": {
"condition": "always",
"hop": [{
"template": "ADJG",
"condition": "always"
}]
}
},
"2100_F3": {
"2100_F1": {
"condition": "always",
"hop": [{
"template": "2100_NOT_INTERFERED",
"condition": "always"
}]
},
"2100_F3": {
"condition": "always",
"hop": [{
"template": "ADJS",
"condition": "always"
}]
},
"GSM": {
"condition": "always",
"hop": [{
"template": "ADJG",
"condition": "always"
}]
}
},
"GSM": {
"2100_F1": {
"condition": "always",
"hop": [{
"template": "default",
"condition": "always"
}]
},
"GSM": {

EdenNet 21 © 2021 Nokia 38

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"condition": "always",
"hop": [{
"template": "default",
"condition": "always"
}]
}
}
}
}
}
}

Example 2 (version 2.0):

Table 13: Scenario for LMS version 2.0 defines the scenario for example 2.

Source/Target GSM LTE u1 u2 p1

GSM always always always always always

always:default always:default always:default always:default always:default

LTE always always always always always

always:default always:default always:default
always:default always:default

u1 always always always always never

always:default always:default always:settings_ always:settings_

template0 template1

u2 never never never never never

p1 always always always never always

always:default always:default always:default always:settings_

template0

Table 13: Scenario for LMS version 2.0

{
"*": {
"version": "2.0",
"filters": {
"enodeB": {
"dn": ".+/LNBTS-([0-9]+)$"
}
},
"layers": {
"F1": {
"and": [

EdenNet 21 © 2021 Nokia 39

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

{
"uarfcn": 10570
},
{
"not": {
"name": "^femto.*"
}
},
{
"not": {
"name": "^pico.*"
}
}
]
},
"F2": {
"uarfcn": 10571
},
"GSM": {
"technology": "GSM"
},
"LTE": {
"technology": "LTE"
},
"UMTS": {
"technology": "UMTS"
}
},
"optional layers": {
"optional_GSM": {
"layer": "GSM"
},
"optional_LTE": {
"layer": "LTE"
}
},
"conditions": {
"cosite": {
"relation": "co-site"
},
"cosector": {
"relation": "co-sector"
},
"intraLAC-RAC-URA": {
"and": [
{
"relation": "intra-LAC"
},
{
"relation": "intra-RAC"

EdenNet 21 © 2021 Nokia 40

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

},
{
"relation": "intra-URA"
}
]
},
"interLAC-RAC-URA": {
"not": {
"name": "intraLAC-RAC-URA"
}
},
"cosite_or_F1Only": {
"or": [
{
"relation": "co-site"
},
{
"target": {
"configuration": "F1Only"
}
}
]
}
},
"templates": {
"default": {},
"ADJS_a": {
"RtHopsIdentifier": 1,
"NrtHopsIdentifier": 2,
"HSDPAHopsIdentifier": 3,
"RTWithHSDPAHopsIdentifier": 4
},
"ADJS_b": {
"RtHopsIdentifier": 11,
"NrtHopsIdentifier": 12,
"HSDPAHopsIdentifier": 13,
"RTWithHSDPAHopsIdentifier": 14
},
"ADJI_a": {
"RtHopiIdentifier": 1,
"NrtHopiIdentifier": 2
},
"ADJI_b": {
"RtHopiIdentifier": 41,
"NrtHopiIdentifier": 42
},
"ADJI_b_DCHOnly": {
"RtHopiIdentifier": 41,
"NrtHopiIdentifier": 42,
"AdjiSIB": "For CELL DCH meas only"

EdenNet 21 © 2021 Nokia 41

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

},
"LTE": {},
"UMTS_GSM": {
"RtHopgIdentifier": 1,
"NrtHopgIdentifier": 2
},
"GSM_GSM": {
"hoMarginPbgt": 6
}
},
"vendor mo templates": {
"vt_ADJS_a": {
"metadata": {
"vendor": "nsn",
"technology": "UMTS",
"type": "AdjIntraFreq"
},
"template": "ADJS_a"
},
"vt_ADJS_b": {
"metadata": {
"vendor": "nsn",
"technology": "UMTS",
"type": "AdjIntraFreq"
},
"template": "ADJS_b"
},
"vt_ADJI_a": {
"metadata": {
"vendor": "nsn",
"technology": "UMTS",
"type": "AdjInterFreq"
},
"template": "ADJI_a"
},
"vt_ADJI_b": {
"metadata": {
"vendor": "nsn",
"technology": "UMTS",
"type": "AdjInterFreq"
},
"template": "ADJI_b"
},
"vt_ADJI_b_DCHOnly": {
"metadata": {
"vendor": "nsn",
"technology": "UMTS",
"type": "AdjInterFreq"
},
"template": "ADJI_b_DCHOnly"

EdenNet 21 © 2021 Nokia 42

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

},
"vt_UMTS_GSM": {
"metadata": {
"vendor": "nsn",
"type": "AdjIratGSM"
},
"template": "UMTS_GSM"
}
},
"settings templates": {
"st_ADJS_a": {
"neighbor RRC list type": "Sib11AndDch",
"vendor mo parameters": {
"names": [
"vt_ADJS_a"
]
}
},
"st_ADJS_b": {
"neighbor RRC list type": "Sib11AndDch",
"vendor mo parameters": {
"names": [
"vt_ADJS_b"
]
}
},
"st_ADJI_a": {
"neighbor RRC list type": "Sib11AndDch",
"vendor mo parameters": {
"names": [
"vt_ADJI_a"
]
}
},
"st_ADJI_b": {
"neighbor RRC list type": "Sib11AndDch",
"vendor mo parameters": {
"names": [
"vt_ADJI_b"
]
}
},
"st_ADJI_b_DCHOnly": {
"neighbor RRC list type": "DchOnly",
"max neighbor size": 10,
"vendor mo parameters": {
"names": [
"vt_ADJI_b_DCHOnly"
]
}

EdenNet 21 © 2021 Nokia 43

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

},
"st_GSM": {
"neighbor RRC list type": "Sib11AndDch",
"vendor mo parameters": {
"names": [
"vt_UMTS_GSM"
]
}
}
},
"row rules": {
"rr_optional_GSM": {
"GSM": {
"condition": "always",
"vendor mo parameters": {
"template": "GSM_GSM"
}
}
}
}
},
"rules": {
"F1F2": {
"F1": {
"cell_relations": {
"F1": {
"condition": "always",
"settings": [
{
"condition": {
"name": "interLAC-RAC-URA"
},
"settings template": "st_ADJS_b"
},
{
"condition": "always",
"settings template": "st_ADJS_a"
}
]
},
"F2": [
{
"condition": {
"name": "cosite"
},
"settings": [
{
"condition": {
"name": "interLAC-RAC-URA"
},

EdenNet 21 © 2021 Nokia 44

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"settings template": "st_ADJI_b"

},
{
"condition": "always",
"settings template": "st_ADJI_a"
}
]
}
],
"GSM": {
"condition": "always",
"settings": [
{
"condition": "always",
"settings template": "st_GSM"
}
]
}
}
},
"F2": {
"cell_relations": {
"F1": [
{
"condition": "target_configuration_not_exists",
"raise": "NoNodeConfigurationError"
},
{
"condition": {
"name": "cosite_or_F1Only"
},
"settings": [
{
"condition": {
"name": "interLAC-RAC-URA"
},
"settings template": "st_ADJI_b_DCHOnly"
},
{
"condition": "always",
"settings template": "st_ADJI_a"
}
]
}
],
"F2": {
"condition": "always",
"settings": [
{
"condition": {

EdenNet 21 © 2021 Nokia 45

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"name": "interLAC-RAC-URA"
},
"settings template": "st_ADJS_b"
},
{
"condition": "always",
"settings template": "st_ADJS_a"
}
]
},
"GSM": {
"condition": "always",
"settings": [
{
"condition": "always",
"settings template": "st_GSM"
}
]
}
}
},
"optional_GSM": {
"GSM": {
"cell_relations": "rr_optional_GSM"
}
}
},
"F1Only": {
"F1": {
"cell_relations": {
"F1": {
"condition": "always",
"settings": [
{
"condition": {
"name": "interLAC-RAC-URA"
},
"settings template": "st_ADJS_b"
},
{
"condition": "always",
"settings template": "st_ADJS_a"
}
]
},
"F2": {
"condition": "always",
"settings template": "st_ADJI_a"
},
"GSM": {

EdenNet 21 © 2021 Nokia 46

Layer Management Strategy DN09257552 1-0 Appendix: LMS examples
Configuration File Guide

"condition": "always",
"settings": [
{
"condition": "always",
"settings template": "st_GSM"
}
]
}
}
},
"optional_GSM": {
"GSM": {
"cell_relations": "rr_optional_GSM"
}
}
}
}
}

EdenNet 21 © 2021 Nokia 47