Eden Net Operator Inputs Network Policy

EdenNet 21
EdenNet Operator Inputs and Network Policy

DN09247523
Issue: 1-0
EdenNet Operator Inputs and Network Policy DN09247523 1-0 Disclaimer
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.
EdenNet Operator Inputs and Network DN09247523 1-0 Table of Contents
Policy
Contents
1 Summary of changes...................................................................................................................................... 4
2 Introduction to operator inputs and network policy................................................................................... 6
3 Connectivity information................................................................................................................................ 7
4 Site information............................................................................................................................................. 11
5 Site, sector, and cell naming convention................................................................................................... 16
6 Layer Management Strategy (LMS)............................................................................................................. 18

6.1 Permissible neighbors............................................................................................................................. 18
6.2 Handover parameters (LMS templates)..................................................................................................20
6.2.1 Nokia............................................................................................................................................... 21
6.2.2 Ericsson...........................................................................................................................................22
6.2.3 Huawei............................................................................................................................................ 23
6.2.4 Alcatel-Lucent..................................................................................................................................24
6.2.5 ZTE..................................................................................................................................................25
6.3 Inter- PLMN policies................................................................................................................................26
7 Neighbor list sizes and neighbor list types............................................................................................... 27

7.1 GSM.........................................................................................................................................................27
7.2 UMTS.......................................................................................................................................................27
8 Operator policies for code reuse................................................................................................................ 29

8.1 Reusing code.......................................................................................................................................... 29
8.2 Reusing PCI codes................................................................................................................................. 29
9 Cell-antenna association convention.......................................................................................................... 30
10 Data flow for planning and deploying new cells..................................................................................... 31
11 GFO (GSM Frequency Optimization)......................................................................................................... 33
EdenNet 21 © 2021 Nokia 3

EdenNet Operator Inputs and Network DN09247523 1-0 Summary of changes
Policy
1 Summary of changes
Release Change description
EdenNet 21 No change.
EdenNet 20 FP 2011 No change.
EdenNet 19A FP 2004 No change.
EdenNet 19A No change.
EdenNet 18 SP1 1812 No change.
EdenNet 18 SP1 1811 No change.
EdenNet 18 SP1 No change.
EdenNet 17 SP1 FP1 Updated sections:
• Connectivity information section is updated.

• Operator policies for code reuse section is updated.

EdenNet Operator Inputs and Network DN09247523 1-0 Summary of changes
Policy
Release Change description
• 2G BCCH frequency planning section is changed to GFO (GSM Fre-

quency Optimization).
EdenNet 17 SP1 No change.
EdenNet 17 FP1 Updated sections:
• Site information section is updated with the table Site information .csv
file.
• A note is added for the Cell_ID field of Site information .csv file table,
which provides information on SAC customization.
• Site, sector, and cell naming convention section is updated with infor-
mation about co-site/co-sector service.
• Cell-antenna association convention section is updated.
EdenNet 16 SP4 This is a new document that provides information about inputs the operator
needs to provide.
Table 1: Summary of changes

EdenNet Operator Inputs and Network DN09247523 1-0 Introduction to operator inputs and
Policy network policy
2 Introduction to operator inputs and network policy

EdenNet is the most flexible and extensible C-SON solution within the industry. EdenNet enables the
SON modules or use cases to optimally address the real world operator network conditions, which is
specific to each network operator.
To optimize an operator network, EdenNet requires data and information regarding the network. Ma-
jority of data used by EdenNet is directly retrieved from Radio Access Network (RAN). This includes
Configuration Management data, Performance Management data, and Layer 3 event data also known
as Call Trace data.
However, EdenNet requires additional data and information about the operator networks which is usu-
ally not available in RAN. This data and information has to be provided in a specified format by the op-
erator to the Nokia EdenNet support team, so that they can configure it in EdenNet.
Additional data and information includes the following:
• Site information
– Includes site latitude and longitude, antenna information, cell type and so on.
– This information is normally available from a network planning tool.
• Operator policy and convention information
– Each operator has their own policies regarding how their specific RAN is configured and
managed. EdenNet provides a rich and flexible set of configuration capabilities to support
these operator specific policies and conventions.
– In order to facilitate rapid deployment of EdenNet in an operator network, as a trial, the
operator supplies policy and convention information to the Nokia support team. Nokia support
team then configures EdenNet to comply with the operator specified policies.
– Policy information includes layer management strategy, site, sector, and cell naming
conventions, neighbor list sizes, handover parameter policies and settings, reuse code, for
example, Physical cell Identifier (PCI), Physical Scrambling Code (PSC), and Base Station
Identity Code (BSIC) policies, process flows for deploying and planning new cells, Broadcast
Control CHannel (BCCH) frequency planning conventions and policies, Inter-PLMN policies.
This document describes about the inputs required from an operator to configure EdenNet for the
operator's network.

EdenNet Operator Inputs and Network DN09247523 1-0 Connectivity information
Policy
3 Connectivity information
Table 2: Connectivity information describes the connectivity information items collected from the oper-
ator. Operators have to provide their inputs for each item specified in the connectivity information ta-
ble.
Operator
Item Description
Response
EdenNet Operator assigns IP addresses for each of the EdenNet

servers. A typical EdenNet installation requires 3 IP ad-
IP Addresses
dresses (1 Ethernet port).
RAN Vendor Vendor of the Radio Access Network (RAN) equipment.
For example: Ericsson, Nokia, Alcatel-Lucent and so on
OSS Version Version number of the OSS software. Nokia recom-

mends to install the EdenNet server physically close to
Ericsson, Nokia, and Huawei OSS, and connect them
via a high speed switch.
OSS IP Addresses IP Addresses of OSS servers from where the RAN con-
(Configuration Man- figuration information is pushed or pulled. If different
agement data) OSSs are used for different technologies, provide all the
relevant OSS IP addresses.
OSS IP Address (Per- IP Address of OSS server from where the PM data is
formance Metric data) pulled. If different OSSs are used for 2G and 3G data,
provide all the relevant OSS IP addresses and file paths.
OSS Login information Username and password used by the EdenNet soft-
ware application to connect to OSSs. Specify, if only
one username and password is used to connect to each
OSS. If different usernames and passwords are required
for each OSS, provide the username and password for
each OSS.
Note: The RSA key pair has to be provided by

the operator, if any particular security feature
is applied in the network.

Policy
Table 2: Connectivity information
Table 3: Email integration describes the email integration requirements from the operator.
Operator
Item Description
Response
EMAIL_HOST Email server host address (For example: smtp.

office365.com)
EMAIL_PORT
EMAIL_PORT = 587 (Default value)
EMAIL_HOST_USER Username and password to connect to the host
EMAIL_HOST_PASS-
WORD
EMAIL_USE_TLS Use transport layer security
EMAIL_USE_TLS = True (Default value)
SERVER_EMAIL Server email address
DEFAULT_FROM_ Mail sender email ID

EMAIL
EMAIL_BACKEND Email backend
For example,
enetlib.mail.backends.console: EmailBackend
which write the email content on console.
enetlib.mail.backends.smtp: EmailBackend for

smtp backend.
Table 3: Email integration
Table 4: Operator inputs lists the inputs required from the network operators.
Operator input NOKIA ERICSSON HUAWEI ALU ZTE Note
EMS version Y Y Y Y Y
Network element type Y Y Y Y Y

and version
Multi Operator Radio Ac- Y Y Y Y Y

cess Network (MORAN),
Multi Operator Core
Network (MOCN), or

Policy
Intra Circle Roaming

(ICR) availability
Security restriction, if any Y Y Y Y Y
RNC pooling availability NA NA Y NA NA
Unique Cell Identifier Y Y Y Y Y

(CELLID) or SAC
HetNet feature availability Y Y Y Y Y
EdenNet Infra requirement
For CM Data - OSS
OSS IP Y Y Y Y Y
EdenNet Y Y Y SYSOP, SSH, SFTP,

Username and password SCP permissions re-
quired
Path to CM export or im- Y Y

port directory
OEMS export directory Y Y
Metadata IP address Y
MML username and Y

password
MML Telnet username Y Y

and password
Telnet IP Y
MML Port 23 Y Y
SSH username and pass- Y Y

word
SSH IP Y
FTP username and pass- Y

word
FTP IP Y
Omcr username and Y

password

Policy
nsp_username and pass- Y

word
Dependency licenses in Y LWM1GBSS10,

EMS (Huawei) LWM1WRAN10,
LWM1FEICD,
LWM1GBSS08,
LWM1GBSS09,
LWM1WRAN08,
LWM1WRAN09,
LWM1FIWNC,
LWM1FIDTD
Bidirectional traffic access Y Y Y Y Y
For PM Data - OSS
OSS IP Y Y Y Y Y
EdenNet username and Y Y Y Y Y SYSOP, SSH, SFTP,

password and SCP permis-
sions required
Path to PM export or im- Y Y Y Y Y

port directory
15minute, 30minute, Y Y Y Y Y
1hour interval
GPEH NA Y NA NA NA
SFTP default port Y
SFPT username and Y Y

password
SFTP IP Y
Number of PM collection Y Y Y Y Y
nodes
Table 4: Operator inputs

EdenNet Operator Inputs and Network DN09247523 1-0 Site information
Policy
4 Site information
EdenNet requires the site information of each cell in the RAN. Site information includes location
information (latitude, longitude), antenna information (azimuth, beamwidth, mechanical tilt, and
antenna_id), market information, cell type (macro, micro, and pico), coverage type (indoor, outdoor)
and so on.
This information is used by EdenNet in many ways:
• It is used to display cells at the correct location in EdenNet GUI.

• It is used by EdenNet to identify the topological relationship between cells, which is required by
SON modules such as ANR, CCO, MLB, RCO and so on.
This information is normally available from operator Radio Frequency (RF) planning tools. EdenNet
imports this information via a Comma Separated Variable (CSV) formatted text file. This file can be
generated by exporting the relevant information from the operator planning tool. It is recommended
that an export from the planning tool containing the required site information has to be given to the
Nokia support team for the initial configuration of EdenNet.
The fields required in the site information CSV file are listed in Table 5: Site information.csv file.
Mandatory Technology
Field Name Description
(Yes/No) Identifiers
SiteID Yes All Operator specific scheme (alphanu-

meric)
Range: 1 to 25 characters length
Example: site3007
Longitude_Sector Yes All Coordinate system: WGS84
Values must be in signed decimal de-

grees format (DDD.dddd)
Range: -180 to 180
Example: 24.756646
Latitude_Sector Yes All Coordinate system: WGS84
Values must be in signed decimal de-

grees format (DDD.dddd)
Range: -90 to 90
Example: 60.224649

Policy
Azimuth Yes All Horizontal angular measurement of

the antenna.
It must be a numeric value.
Range: 0 to 360
Example: 90.0
[4]
HorizBeamwidth No All Horizontal beam width of the antenna
measured in degrees.
This parameter is optional, but it is re-

quired by some specific modules like
Cell Outage Compensation (COC)
and Energy Savings Management
(ESM).
Range: 0 to 360
Example: 60
RF_Solution No All Value can be one of following prede-

fined values:
das, macro, enter_small_cell_ran,

micro, pico, repeater, special, split_
sector, temporary. If the value is not
from predefined set, it will be stored
in database as it is.
Example: macro
[4]
Coverage Type No All Value can be one of the predefined
values such as: indoor, outdoor,
mixed_ special.
If the value is not from the predefined

set, it will be stored in the database
as it is.
Example: outdoor
CellName No All Name of the cell

Policy

[1][2] [1]
Cell_ID Yes UMTS, GSM, Cell ID, for unique identification of the
LTE, 4G- cell
NBIoT
LTE and 4G-NBIoT (0-255)
Nokia: lcrId (Local Resource Cell ID)
Ericsson: CellId
Huawei: CellId
Alcatel-Lucent: Cell_ID and ENEB

ID are combined in EUTRAN Cell ID
(ECI) attribute cellIdentity
ZTE: cellLocalId, eNBId
Technology Yes All Radio Technology of the cell
Valid values:
GSM, UMTS, LTE, and 4G-NBIoT
2G, 3G, 4G, and 4G-NBIoT
Example: 4G
[2] [1]
LAC Yes GSM, UMTS Not applicable for LTE and 4G-NBIoT
[2] [1]
eNodeB ID Yes LTE, 4G- eNBId of eNodeB
NBIoT
[3]
expected_cell_range No LTE The expected cell range for the cell in
km.
Note: This parame-
ter is mandatory, if
PRACH module is
licensed. (Applica-
ble only for Nokia)
mcc Yes Mobile Country Code
3 digits
Data Type: Integer (0...999)
mnc Yes Mobile Network Code
2 or 3 digits

Policy
Data Type: Integer (0...999)
antenna_id No All This column is applicable for a cell

with multiple antennas. Antenna iden-
tifier should be unique within the giv-
en parent LNBTS.
If antenna_id is not present in the

cell plan for a multi-antenna site,
any running number from one to
maximum number of antennas under
one parent LNBTS will be generated
within EdenNet.
Range: 0 - 99999999999
ret_dn No All Distinguished Name (DN) value of a

RET object associated with the cell.
RET DN is different for different ven-
dor-technology combinations.
Applicable only for 3G and 4G CCO

module.
For example:
Nokia: PLMN-PLMN/MRBTS-544834/
RET-3
Ericsson: SubNetwork = ONRM_

ROOT_MO_R,
SubNetwork = Beltsville,MeContext
= L1SU3631C,
= L1SU3631C,
= L1SU3631C,
ManagedElement =1, Equipment =1,
AntennaUnitGroup = 1,
AntennaNearUnit =1,
RetSubUnit =1

Policy
Huawei: H4GN-1/eNodeB-190006/
ENODEB-1/TRANSPORT-1/RET-0
Table 5: Site information.csv file
Note:
• [1] - For unique identification between UCELL and GEXT3GCELL (3G external
cells in GSM network), the customer has an option to use SAC instead of
Cell_ID. Such customization in OSS can be enabled by setting the parameter
use_sac_for_gext3g_cell = True in the region file.
• [2] - These fields are not stored in the database, only the resulting IDN of the cell.
• [3] - These fields are used by HetNet functionality of eNodeB Auto Planning module
which is used by Automated Site Creation LTE functionality.
• [4] - HorizBeamwidth and Coverage Type must be added as mandatory fields for
modules with tier count.
• GSM and UMTS cells are identified in the cell plan by LAC and Cell_ID. LTE cells are
identified by eNodeB ID and Cell_ID. LAC is not required for LTE cells and eNodeB
ID is not required for GSM and UMTS cells.
• RF_Solution and Coverage Type must be added as mandatory for HetNet
configuration.
• Information about current methodology used in cell broadcast service should be captured
(whether cell is identified based on Cell_ID or SAC).
• RET Information should be captured (Whether Single or Shared RET).
For deployments, EdenNet has a mechanism to retrieve the site information file from any remote
server via Secure Shell File Transfer Protocol (SFTP) or (File Transfer Protocol) FTP periodically, if the
site or cell information is made available in the CSV file format. Nokia support engineer can configure
the upload period (default check every 15 minutes), remote server access details (user credentials,
file location and so on) for automatic import of site information. This confirms that the site information
is always up to date. The site or cell information must be latest, and in sync with OSS to get the best
optimization results.
In case the cell plan.csv file cannot be automatically created and stored in SFTP share, then a
customization project is required to integrate the cell plan update. During the trial, this information can
be manually imported into EdenNet, if SFTP share is not available.

EdenNet Operator Inputs and Network DN09247523 1-0 Site, sector, and cell naming convention
Policy
5 Site, sector, and cell naming convention

Operators typically have a naming convention for sites, sectors, and cells in the network. EdenNet
processes generally do not depend on the knowledge of naming conventions. However, configuration
of these naming conventions in EdenNet enables a layer of parameter auditing and checking, which is
otherwise not possible. The naming convention helps to identify cells with incorrect latitude and longi-
tude information (for example, co-sited cells based on naming convention have different latitude and
longitude). For some operators, the naming convention is used to identify the site a cell belongs to,
which sector the cell belongs to, and which layer the cell represents.
Figure 1: Site naming convention example shows how a site naming convention can be provided.
Figure 1: Site naming convention example
The operator must provide the cell naming convention for the network, so that, EdenNet audits and
checks can make use of this information. The naming convention can be used as an input to the Layer
Management Strategy. Similarly, the input for RET cell naming convention used by the operator is also
required.
EdenNet identifies co-site cells and co-sector cells in the network for the optimization of modules. By
default, for a given cell the co-sector cells are cells that have the same SiteID and an azimuth- differ-
ence of +/- 20 degree to that cell. However, it is possible that some operator network policies differ
from these definitions. For example, an operator may want to restrict Azimuth variation to +/- 10 de-
gree, or wants to use cell naming convention to identify co-sector cells and so on. In such cases, the
operator can opt to override the default behavior. This could be achieved by creating customized plug-
in for co-sector service. It is crucial to collect inputs from the operator about their definition of co-site
and co-sector cells, to check if customization is required.
The following questions can help for co-sector service:
• What is the operator network policy to identify the co-site and co-sector cells?
• Do all co-site cells have the same Site ID? Do all co-sector cells have the same Site ID?
• Is the difference in azimuth values between two co-sector cells <= 20 degrees?
• Is there a specific naming convention that indicates to which sector a cell belongs?

EdenNet Operator Inputs and Network DN09247523 1-0 Site, sector, and cell naming convention
Policy
• Is there a specific naming convention that indicates to which sector type (main sector, split sector
and so on) a cell belongs?
• Is there a scenario where co-site cells have different latitude or longitude?

EdenNet Operator Inputs and Network DN09247523 1-0 Layer Management Strategy (LMS)
Policy
6 Layer Management Strategy (LMS)

EdenNet supports operator specified Layer Management Strategy (LMS) policies via a configuration
file. The LMS configuration file defines the permissible or allowed neighbor relation rules per site type.
In addition, the LMS defines specific handover parameter values, which must be set for permissible
relations through a set of templates. EdenNet ANR modules use the LMS configuration for neighbor
additions, to check which detected missing neighbors are permissible, and to set the correct parame-
ter values for the neighbor relation managed objects that are created. The EdenNet LMS Enforcement
module can automatically delete the non-permissible neighbor relations and modify the existing para-
meter values to meet the specified ones.
6.1 Permissible neighbors

Figure 2: Four layer site LMS policies shows the LMS configuration for a four layer site with LMS poli-
cies.
Figure 2: Four layer site LMS policies
The LMS system can be extended to support different rules for different site types and conditions. Fig-
ure 3: Co-sector and non co-sector LMS policies shows the different rules for sites with different num-
ber of layers for co-sector cells and non co-sector cells.

Policy
Figure 3: Co-sector and non co-sector LMS policies
In order to configure LMS within EdenNet, the LMS polices used by the operator is required. The op-
erator should provide a description of LMS policies used within the operator network. The description
might be provided as a text document, spreadsheet, or other human-readable format, so that, a Nokia
support engineer may configure the LMS policies within EdenNet.
Allowed frequency relations (typically used for idle mode control) and parameter values can also be
defined in the LMS configuration.
Neighbor list types and neighbor list sizes can also be optionally specified per layer transition. This is
done through the LMS configuration (using the max neighbor size and neighbor RRC list type key-
words). An example is listed in Table 6: Neighbor list sizes and list types, where neighbor list types and
neighbor list sizes are specified for different layer transitions.
Some of the specifications in this LMS configuration are:
• For an F1 source cell, co-sector intra neighbors should be allocated only to Sib11and Dch list.
For a source cell that belongs to the F1 layer, the maximum number of relations to F2 layer is
specified to be 10.
A maximum of 2 Femto F2 neighbors are allowed.
The Femto F2 neighbors should be accommodated in the DchOnly neighbor list (this list should be
available for the vendor to which the source cell belongs).
• F2 source cell can only have F1 neighbors, if they are co-sited.
A maximum of two co-sited neighbors are allowed.
Neighbor size constraints and neighbor list types in LMS will be enforced by ANR, in addition to the
size limits and non-SIB11 list configured in ANR (using ANR configuration file).

Policy
Source Layer/
F1 F2 F3
Destination Layer
F1 always always always
condition: co-sector max neighbor size = 10 template3
• template0 condition: femto

• neighbor RRC list • template2
type = Sib11and
• max neighbor size
Dch
=2
condition: always • neighbor RRC list
• template1 type = DchOnly
condition: always
• template1
F2 co-site always always
template0 condition: co-sector: template2
max neighbor size = 2 • template0

• neighbor RRC list
type = Sib11And
Dch
condition: always
template1
Table 6: Neighbor list sizes and list types
6.2 Handover parameters (LMS templates)

The configuration of handover parameter values for neighbor relations and frequency relation man-
aged objects is a key factor in the mobility performance of a network. In addition to defining the per-
missible relations, the LMS configuration can also define the specific parameter values to be used for
these relations, when added by EdenNet ANR modules. This is done through a set of templates de-
fined in the LMS configuration file. When a permissible neighbor condition is defined in LMS, a defined
handover parameter template to be used for such relations is also selected. Any number of templates
can be defined depending on site types and the conditions for permissible relations from those site
types.
For example, blind handovers are enabled or disabled as follows:
• Enabled for co-sector cells between two specific frequency layers

Policy
• Disabled for non co-sector cells between the same frequency layers
Two separate templates are defined within the LMS to support this configuration.
6.2.1 Nokia
Examples of parameters whose values can be configured through the LMS are listed in Table 7: Cell
relations.
Note: These are examples provided for reference, they are not the complete parameter set
that can be set through LMS.
Target
Source GSM WCDMA LTE
GSM ADCE ADJW Currently not supported

(ADJL)
• hoMarginPbgt • minEcnoThreshold
• hoPriorityLevel
• hoMarginQual
• hoTargetArea
WCD- ADJG ADJS (Intra-frequency) Currently not supported

MA (ADJE)
• NRTHopgIdentifier • HSDPAHopsIdentifi-
• RTHopgIdentifier er Currently, only ADJL for fre-
• NRTHopsIdentifier quency relations.
• RTWithHSDPAHop-
sIdentifier
• RTHopsIdentifier
ADJI (Inter-frequency)
• NRTHopiIdentifier
RTHopiIdentifier
LTE LNRELG (Cell Relations) LNRELW (Cell Relations) Currently not supported
(LNREL)
• eNACCAllowed • csfbPsHoAllowed
• redirWithSysInfoAl- • psHoAllowed LTE to LTE relations not
lowed • srvccAllowed added by EdenNet
• srvccAllowed
LNADJW (External Cells)
LNADJG (External Cells)
• srvccHoInd
• dtm
• networkControlOrder

Policy
Target
• systemInfoType
Table 7: Cell relations
Target
GSM Not applicable Not applicable Currently not supported

(ADJL)
Idle mode handled GSM to WCDMA fre-
through cell to cell rela- quency relations not
tions available in Nokia RAN
Idle mode handled

through cell to cell rela-
tions
WCDMA Not applicable Not applicable ADJL
Idle mode handled Idle mode handled • HopLIdentifier

through cell to cell rela- through cell to cell rela-
tions tions
LTE LNHOG LNHOW (Handovers) LNHOIF (Handovers)
• b2Threshold1 • b1ThresholdCSFB • a3OffsetRsrpInterFreq
GERAN UtraEcn0 • a3OffsetRsrqInterFreq
• b2Threshold2Rssi • b2Threshold2 IRFIM (Idle mode)
GERAN UtraEcn0 • eutCelResPrio
GFIM UFFIM (Idle Mode) • interTResEut
• tResGer • uCelResPrio
• gerResTiFHM • utraFrqQThrHighR9
REDRT
• redirRAT
• csFallBPrio
• redirectPrio
Table 8: Frequency Relations

Policy
6.2.2 Ericsson
Examples of parameters whose values can be configured through LMS are listed in Table 9: Cell Rela-
tions .
Target
GSM NREL UTRAN_NREL Not applicable
• AWOFFSET Normally no attribute set- Currently no connected

• BQOFFSET table through LMS mode handovers for
• KOFFSET GSM to LTE
WCDMA GSMRelation UtranRelation Not applicable
• qOffset1sn • qOffset1sn Currently no connected

• qOffset2sn mode handovers for
• loadSharingCandidate WCDMA to LTE
LTE GERANCellRela- UtranCellRelation Not currently supported

tion
• coverageIndicator LTE to LTE relations
coverageIndicator • loadBalancing not added by EdenNet
• lbBnrAllowed
Table 9: Cell Relations
Frequency Relations
Currently, the only frequency relation supported for Ericsson are LTE frequency definitions within
WCDMA cells.
• Managed Object: EutranFreqRelation

• Example parameters: cellReselectionPriority, qQualMin, qRxLevMin
6.2.3 Huawei
Examples of parameters whose values can be configured via the LMS are listed in Table 10: Cell Rela-
tions.

Policy
Target
GSM G2GNCELL G3GNCELL Currently not supported

(GLTENCELL)
• ADJHOOF- • ECNOOFF
FSET • HOSTAT3G
• BQLASTTIME
WCDMA U2GNCELL UINTRAFREQNCELL Currently not supported

(ULTENCELL)
• BlindHoFlag • TempOffset1
• Qrxlevmin • NPrioFlag
UINTERFREQNCELL
• BlindHoFlag
• ConnQoffset2sn
LTE GERANNCELL UTRANNCELL Currently not supported
• BlindHoPriority • BlindHoPriority LTE to LTE relations

• NoHoFlag • NoHoFlag not added by EdenNet
Frequency Relations
Currently the only frequency relation supported for Huawei are LTE frequency definitions within WCD-
MA cells.
Managed Object: UCELLNFREQPRIOINFO
Example parameters: NPriority, ThdToHigh
6.2.4 Alcatel-Lucent
Examples of parameters whose values can be configured via the LMS are listed in Table 11: Cell Rela-
tions.
Target

Policy
Target
GSM adjacency adjacency2gTo3g Currently not

supported
• hoMarginLevel Normally no attributes
(adjacency2gToLte)
• hoMarginQual settable through LMS
WCDMA GSMNeighboringCell UMTSFddNeighbor- Not applicable

ingCell
• qRxLevMin Currently no connect-
• qOffset1sn • minimum- ed mode handovers
CpichEcNoValue- for WCDMA to LTE
ForHoOffset
• minimum-
CpichRscpValue-
ForHoOffset
LTE GeranNeighboring- UtraFddNeighboring- Currently not support-

CellRelation CellRelation ed
• networkCon- • umtsNeighRela- LTE to LTE relations

trolOrder tionId not added by Eden-
• dtmCapability • voiceOverIpCapa- Net
bility
• isCellIncluded-
ForRedirectionAs-
sistance
Frequency Relations
Currently the only frequency relation supported for Alcatel-Lucent is LTE frequency definitions within
WCDMA cells.
Managed Object: EUtranFrequencyAndPriorityInfoList
Example parameter: eUtraTargetFrequencyThreshxHigh.
6.2.5 ZTE
Examples of parameters whose values can be configured using the LMS are listed in Table 12: Para-
meters configured via LMS.

Policy
Target
GSM GsmRelation Not implemented Not applicable
• HoPriority Currently, no connect-

• RxLevMin ed mode handovers for
• HoMarginPbgt GSM to LTE
• HoMargin-
RxLev
• HoMarginRx-
Qual
WCDMA GsmRelation UtranRelation Not applicable
• ncToSelf- • shareCover Currently, no connect-

PhyRnc • measPrio ed mode handovers for
• gsmShareCov- • stateMode WCDMA to LTE
er • useOfHCS
• measPrio
• useOfHCS
LTE Currently not support-

ed
LTE to LTE relations

not added by EdenNet
Table 12: Parameters configured via LMS
6.3 Inter- PLMN policies

EdenNet supports automated SON operations across multiple Public Land Mobile Networks (PLMNs)
within an operator network. An operator with multiple PLMNs typically arises from merger, or acquisi-
tion activities with combination of operator networks.
When multiple PLMNs exist within a network, the Layer Management Strategy includes operator poli-
cies that an operator prefers to follow, while creating neighbors between cells of different PLMNs.
These policies may vary from market to market, or region to region.
Examples of such policies are:
• All 3G Intra-frequency neighbors permitted between all PLMNs in Market X

• Intra-site 3G Intra-frequency neighbors permitted between PLMN A and PLMN B in market Y

EdenNet Operator Inputs and Network DN09247523 1-0 Neighbor list sizes and neighbor list types
Policy
7 Neighbor list sizes and neighbor list types

In order to configure neighbor lists, EdenNet has to be provisioned with operator policies on neighbor
list sizes.
7.1 GSM
What are the operator policies for GSM neighbor list sizes (2G → 2G, 2G → 3G)?
Does the operator have any additional policies regarding GSM neighbor lists which are not covered in
other sections of this document?
7.2 UMTS
The system allows configuration of size limit and allocation of neighbors to different types of neighbor
list (SIB11, SIB11Bis, DchOnly). Some suggested inputs are:
• The operator should specify the size limit for Intra, Inter, IRAT, and the total neighbor size limit for
SIB11 list.
• The operator can optionally choose the SIB11 size to be dynamically calculated by the system. If
this option is selected, the operator needs to specify the number of bits to be used for Intra, Inter,
and IRAT neighbors. More details can be found in the ANR feature description document.
• If additional neighbors (other than those that can be accommodated in SIB11 list) are required, the
operator should specify the neighbor list (SIB11Bis or DchOnly) in which these additional neigh-
bors are to be accommodated. Additional neighbor list types depend upon the vendor. Not all ven-
dors support all neighbor list types.
• The system also allows the configuration of parameter specific Radio Network Controller (RNC)
and cell level policies for neighbor list sizes. Table 13: Neighbor list sizes defines all the required
neighbor list sizes in ANR, assuming dynamic SIB11 calculation is not enabled. If this is enabled,
the total SIB11 neighbor list size need not be specified.
Neighbor list sizes can be configured based on different levels:
• Global level: Neighbor list sizes defined in this level applies to all cells.
• RNC level: Neighbor list policies will be applied to all cells that are members of RNC.
• Cell level: Neighbor list policies to specific cells can be defined in this level. * can be used to de-
fine multiple cells with a common cell name convention.

EdenNet Operator Inputs and Network DN09247523 1-0 Neighbor list sizes and neighbor list types
Policy
SIB11_ SIB11_ SIB11_ Total_ Total_ Total_ Total_

Configuration Total_
Iaf_ Ief_ IRt_ Iaf_ Ief_ IRt_ SIB11_
Level RsvdSlots
RsvdSlots RsvdSlots RsvdSlots RsvdSlots RsvdSlots RsvdSlots RsvdSlots
Global
RNC RNC-1
Any other
RNC
Cell SE98011P12
SE*
Any other
cell or reg-
ular expres-
sion
Table 13: Neighbor list sizes
A configuration input file is required to allow set layer policy based on handover strategy:
• Number of layers per technology type

• Priority per layer
• Distribution of assigning neighbors per layer
Example – UMTS:
• Number of layers used by UMTS Technology: 3

• UARFCN: [1987, 2062, 9800]
• Priorities: 1:1987, 2:9800, 3:2062
• Neighbor allocation per priority (Total should be 32): 1:20, 2:12, 3:0
Example - GSM:
• Number of layers used by GSM technology: 2

• Bands: [DSC1800, GSM 900]
• Priorities: 1:DCS1800, 2:GSM900
• Neighbor allocation per priority (Total should be 32): 1:22, 2:10

EdenNet Operator Inputs and Network DN09247523 1-0 Operator policies for code reuse
Policy
8 Operator policies for code reuse

There are various operator policies for the allocation of reuse codes within a network. For more infor-
mation see Reusing code and Reusing PCI codes.
8.1 Reusing code

Operators often have policies for the allocation of reuse codes within their network. These policies
are used as inputs for SCReuse, PCIReuse (PCI) and PRACH (RSI) modules. These policies should
specify the rule applied to a specified code or range of codes.
Note: Operators must specify the reservations for site rollouts (pico cells, femto cells, and
macro cells).
8.2 Reusing PCI codes

The operator currently follows specific conventions for assigning PCI codes to cells. For example:
• The PCI codes at a site should be consecutive.

• The PCI mod 3 for sector 0 should be 0. Definition of sector 0 should be provided by customer.
• The PCI codes at a site should be from PCI groups, and the number of PCI groups used per site
should be minimal depending on the number of sectors.
– PCI group definition should be provided by customer. If not provided, 3GPP definition will be
used.
• The same PCI code should be used by all co-sector cells.
– The same PCI code should be used by all co-sector cells of the same frequency band.
• The same PCI should not be reused by intra-frequency neighbors.
• The same PCI should not be reused by intra-frequency co-site cells.
• The same PCI mod 3 values cannot be reused by adjacent sectors.
• The same PCI mod 30 values cannot be reused by intra-frequency neighbors.

EdenNet Operator Inputs and Network DN09247523 1-0 Cell-antenna association convention
Policy
9 Cell-antenna association convention

The cell-antenna association convention defines if and how Remote Electrical Tilt (RET) antennas are
used in an operator network. This is a key input to CCO module.
Operator inputs to cell-antenna association convention includes:
• Does the operator network include RET capabilities?

• If so, which radio access technologies are supported with RET?
• Does equipment from different Radio Access Technology (RAT) share RET antennas?
• Is RET available on a per site basis, or is it found throughout the network?
• Does centralized control of RET exist?
• If centralized control of RET exists, what is used to configure RET (for example, which specific
OSS Managed Objects)?
In case the RET-DN cannot be added to the cell plan as described in section Site Information, then a
customization project is required to integrate the RET cell mapping information into EdenNet. This may
be done using a managed object naming convention, or a file containing the associations for all cells
and controllers within the operator network, or other similar mechanisms.

EdenNet Operator Inputs and Network DN09247523 1-0 Data flow for planning and deploying new
Policy cells
10 Data flow for planning and deploying new cells

EdenNet supports the automatic addition, removal, and replacement of cells within an operator net-
work. In order to perform this effectively, EdenNet must be aware of the operator policies for adding a
new cell.
Figure 4: Planning and deployment of new cells in operator network shows how the operator plans and
deploys new cells in the operator network with the aid of an example flow chart.
Figure 4: Planning and deployment of new cells in operator network
The operator should provide the following information to the Nokia support team, to ensure that the
plug and play mechanisms within EdenNet are configured appropriately:
• When does the operator plan a new cell in the Radio frequency (RF) planning tool
• When is a cell deployed in the network

EdenNet Operator Inputs and Network DN09247523 1-0 Data flow for planning and deploying new
Policy cells
• When are cell managed objects created in OSS

• When are cell MO parameters initialized
• What are the current steps for determining initial parameters (for example, reuse code, neighbor
lists and so on.)

EdenNet Operator Inputs and Network DN09247523 1-0 GFO (GSM Frequency Optimization)
Policy
11 GFO (GSM Frequency Optimization)

EdenNet supports automatic frequency planning for 2G networks. Operators who deploy this capability
have to provide information regarding the configuration of frequency channels in the operator network.
The policies and information required are:
• What is the frequency hopping type that is deployed in the operator network?
– Baseband Hopping (BBH), Synthesized Frequency Hopping (SFH), or No hopping?

• If Synthesized frequency hopping is used, is it cell hopping (1X3) or site hopping (1X1)?
• What is the frequency load used for TCH in the network?
Note: If more frequencies are available, then mobile allocation list length can be double
the number of Traffic Channel Transceivers (TCH TRXs) in the network.
• How many Broadcast Control CHannel (BCCH) and Traffic Channel (TCH) frequencies are used?
• Are there any forbidden channels for specific set of cells in the network?
• What are the separations between co-cell, co-site, adjacent cell, and common adjacent cell sepa-
ration and its corresponding violations?
– What are the separations across BCCH and TCH, or within BCCH and TCH layers?
– What are the violation penalties for violating separation rules?

Eden Net Operator Inputs Network Policy

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Eden Net Operator Inputs Network Policy

Uploaded by

Copyright:

Available Formats

EdenNet 21

EdenNet Operator Inputs and Network Policy

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

Copyright © 2021 Nokia. All rights reserved.

Important Notice on Product Safety

2 Introduction to operator inputs and network policy................................................................................... 6

5 Site, sector, and cell naming convention................................................................................................... 16

6 Layer Management Strategy (LMS)............................................................................................................. 18

7 Neighbor list sizes and neighbor list types............................................................................................... 27

8 Operator policies for code reuse................................................................................................................ 29

9 Cell-antenna association convention.......................................................................................................... 30

10 Data flow for planning and deploying new cells..................................................................................... 31

11 GFO (GSM Frequency Optimization)......................................................................................................... 33

EdenNet 21 © 2021 Nokia 3

Release Change description

EdenNet 20 FP 2011 No change.

EdenNet 20 FP 2010 No change.

EdenNet 20 FP 2009 No change.

EdenNet 20 FP 2008 No change.

EdenNet 20 FP 2007 No change.

EdenNet 19A FP 2004 No change.

EdenNet 19A FP 2003 No change.

EdenNet 19A FP 2002 No change.

EdenNet 19A FP 2001 No change.

EdenNet 19A FP 1912 No change.

EdenNet 19A FP 1911 No change.

EdenNet 19A No change.

EdenNet 19 FP 1907 No change.

EdenNet 19 FP 1906 No change.

EdenNet 19 FP 1905 No change.

EdenNet 19 FP 1904 No change.

EdenNet 18 SP1 1812 No change.

EdenNet 18 SP1 1811 No change.

EdenNet 18 SP1 No change.

EdenNet 17 SP1 FP1 Updated sections:

• Connectivity information section is updated.

EdenNet 21 © 2021 Nokia 4

Release Change description

• 2G BCCH frequency planning section is changed to GFO (GSM Fre-

EdenNet 17 SP1 No change.

EdenNet 17 FP1 Updated sections:

Table 1: Summary of changes

EdenNet 21 © 2021 Nokia 5

2 Introduction to operator inputs and network policy

Additional data and information includes the following:

EdenNet 21 © 2021 Nokia 6

EdenNet Operator assigns IP addresses for each of the EdenNet

RAN Vendor Vendor of the Radio Access Network (RAN) equipment.

For example: Ericsson, Nokia, Alcatel-Lucent and so on

OSS Version Version number of the OSS software. Nokia recom-

Note: The RSA key pair has to be provided by

EdenNet 21 © 2021 Nokia 7

Table 2: Connectivity information

EMAIL_HOST Email server host address (For example: smtp.

EMAIL_HOST_USER Username and password to connect to the host

EMAIL_USE_TLS Use transport layer security

EMAIL_USE_TLS = True (Default value)

SERVER_EMAIL Server email address

DEFAULT_FROM_ Mail sender email ID

EMAIL_BACKEND Email backend

enetlib.mail.backends.smtp: EmailBackend for

Table 3: Email integration

Operator input NOKIA ERICSSON HUAWEI ALU ZTE Note

Network element type Y Y Y Y Y