LTE Self Organizing Networks (SON)

RA41129EN05GLA0 1
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 2
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 3
LTE Self Organizing Networks (SON)

OSS for SON is aligned with NGMN operations requirements

RA41129EN05GLA0 4
LTE Self Organizing Networks (SON)

A Self-configuration Subsystem will be created in OAM to be responsible for the

self configuration of eNB. For self-optimization functions, they can be located in
OAM or eNB or both of them. So according to the location of optimization
algorithms, SON can be divided into three classes: Centralized SON, Distributed
SON and Hybrid SON.
• Centralized SON :In Centralized SON, optimization algorithms are executed in
the OAM System. In such solutions SON functionality resides in a small number
of locations, at a high level in the architecture. In Centralized SON, all SON
functions are located in OAM systems, so it is easy to deploy them. But since
different vendors have their own OAM systems, there is low support for
optimization cases among different vendors. And it also does not support those
simple and quick optimization implement Centralized SON, existing Itf-N
interface needs to be extended.
Distributed SON: In Distributed SON, optimization algorithms are executed in
eNB. In such solutions SON functionality resides in many locations at a relatively
low level in the architecture. In Distributed SON, all SON functions relocated in
eNB, so it causes a lot of deployment work. And it is also difficult to support
complex optimization schemes, which require the coordination of lots of eNBs.
But in Distributed SON it is easy to support those cases, which only concern one
or two eNBs and require quick optimization responses. For Distributed SON, X2
interface needs to be extended.

RA41129EN05GLA0 5
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 6
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 7
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 8
LTE Self Organizing Networks (SON)

NOTE:
Central ANR and Automated Neighbor Relation (using PCI / IP mapping table) are NSN
proprietary solutions based on NSN configuration management and NetAct.

3GPP Automated Neighbor Relation is a standardized solution that does not rely on vendor
OAM, but does require UE and MME to assist eNB in identifying X2 interface of target eNB.

RL20 and RL30 ANR features may coexist and any or all may be used to discover adjacent
eNB X2 interfaces if UE reports a PCI that is not found in the eNB adjacencies.

RA41129EN05GLA0 9
LTE Self Organizing Networks (SON)

NOTE:
Central ANR and Automated Neighbor Relation (using PCI / IP mapping table) are NSN
proprietary solutions based on NSN configuration management and NetAct.

3GPP Automated Neighbor Relation is a standardized solution that does not rely on vendor
OAM, but does require UE and MME to assist eNB in identifying X2 interface of target eNB.

RL20 and RL30 ANR features may coexist and any or all may be used to discover adjacent
eNB X2 interfaces if UE reports a PCI that is not found in the eNB adjacencies.

RA41129EN05GLA0 10
LTE Self Organizing Networks (SON)

NOTE:
Central ANR and Automated Neighbor Relation (using PCI / IP mapping table) are NSN
proprietary solutions based on NSN configuration management and NetAct.

3GPP Automated Neighbor Relation is a standardized solution that does not rely on vendor
OAM, but does require UE and MME to assist eNB in identifying X2 interface of target eNB.

RL20 and RL30 ANR features may coexist and any or all may be used to discover adjacent
eNB X2 interfaces if UE reports a PCI that is not found in the eNB adjacencies.

RA41129EN05GLA0 11
LTE Self Organizing Networks (SON)

NOTE:
Central ANR and Automated Neighbor Relation (using PCI / IP mapping table) are NSN
proprietary solutions based on NSN configuration management and NetAct.

3GPP Automated Neighbor Relation is a standardized solution that does not rely on vendor
OAM, but does require UE and MME to assist eNB in identifying X2 interface of target eNB.

RL20 and RL30 ANR features may coexist and any or all may be used to discover adjacent
eNB X2 interfaces if UE reports a PCI that is not found in the eNB adjacencies.

RA41129EN05GLA0 12
LTE Self Organizing Networks (SON)

Cell Outage Detection:

The following failure scenarios are taken into account:

failed RACH access
failed RRC connection setup
failed DRB setup
no RACH access
no RRC connection setup
no DRB setup
no traffic

Cell Outage Triggered Reset:

Only those conditions are evaluated, which indicate a problem with nearly absolute certainty:
•“Failed RACH Access”
•“Failed RRC Connection Setup”
•“Failed DRB Setup”

The related alarms are raised only if we have, during one PM data upload interval, a 100%
failure rate of the associated telecom procedures. A BTS reset is attempted to correct the
condition. As long as the alarm stays active, no further resets are initiated.
The operator can get information about the currently performed recoveries by viewing a log file.

RA41129EN05GLA0 13
LTE Self Organizing Networks (SON)

SON Reports (LTE1019) records changes related to following SON features:

LTE724: LTE Automatic Neighbor Cell Configuration

LTE492: ANR
LTE782: ANR Fully UE based
LTE783: ANR InterRAT UTRAN
LTE784: ANR InterRAT GERAN
LTE510: Synchronization of InterRAT neighbors
LTE771: Optimization of Intra-LTE neighbor relations
LTE581: PRACH management
LTE533: Mobility Robustness
LTE502 Cell outage triggered reset
LTE468 PCI management

RA41129EN05GLA0 14
LTE Self Organizing Networks (SON)

SON Reports (LTE1019) records changes related to following SON features:

LTE724: LTE Automatic Neighbor Cell Configuration

LTE492: ANR
LTE782: ANR Fully UE based
LTE783: ANR InterRAT UTRAN
LTE784: ANR InterRAT GERAN
LTE510: Synchronization of InterRAT neighbors
LTE771: Optimization of Intra-LTE neighbor relations
LTE581: PRACH management
LTE533: Mobility Robustness
LTE502 Cell outage triggered reset
LTE468 PCI management

RA41129EN05GLA0 15
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 16
LTE Self Organizing Networks (SON)

In NSN SON Plug and Play SON Plug and Play removes the need for on site
Notebook / Site Manager

RA41129EN05GLA0 17
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 18
LTE Self Organizing Networks (SON)

SON Plug’n’Play divided into two features: auto connection and auto configuration

RA41129EN05GLA0 19
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 20
LTE Self Organizing Networks (SON)

At least one dedicated iOMS is required, this is the node that identifies the eNB (based on Site ID, HW ID, or GPS
coordinates) and maps to the eNB object within the Netact Topology DB. Final iOMS may be the same as the
dedicated iOMS.

eNB identification during auto connection

Operator can choose from three different alternative eNB identification mechanisms. All three require that the
temporary eNB identification parameter(s) are beforehand configured by user into dedicated iOMS. When eNB auto
connects the dedicated iOMS and provides the same temporary identification, the dedicated iOMS is then able to
identify the eNB. After this identification using temporary ID, the eNB is linked with its final BTS ID, which is used from
this phase onwards to identify the eNB.

Three alternative eNB identification mechanisms can be choosed from:

1)Site ID based identification. In practice this is a string value defined at planning phase by planner user. That string
value must be made available for installer user who is working at site and he needs to enter this value into eNB using
BTS EM (which should be avoided).
• When operator user wants to use ste ID based identification, he defines value in eNB conf plan for MRBTS:
Auto Connection Site ID (non-nw) parameter. If no value is defined in plan, then this mechanism is not used
2) HW ID based identification. When eNB connects dedicated iOMS it provides the HW ID (installer user at site does
not need to use BTS EM for this). The drawback is that information logistic may be problematic, that how to get eNB
HW ID easily available also for planner user/Configurator user so that he can set HW ID into dedicated iOMS:
• One possibility is that installer user working at site reads the HW ID from the eNB (system module) and
provides it to Configurator user, who can then configure dedicated iOMS. Or this same is done somehow
earlier before taking eNB equipment into site
• When operator user wants to use HW ID based identification, he defines value in eNB conf plan for MRBTS:
Auto Connection Hardware ID (non-nw) parameter. If no value is defined in plan, then this mechanism is not
used
3) GPS location based identification. eNB can have GPS equipment installed (optional). When eNB auto connects to
dedicated iOMS it includes GPS location information and then eNB’s geographical position is used in identification.
Installer user at site does not need to use BTS EM for this.
•Using GPS location based identification is controlled with GPS Tolerance parameter, see Defining eNB AC
functionality in Configurator. In case GPS mechanism is wanted to be used, the GPS Tolerance needs to have value
(in meters).
•In case there are several eNBs at the same site (two eNBs inside tolerance) and the dedicated iOMS can not identify
the eNB, then either site ID or HW ID needs to be used in addition to distinguish eNBs from each other.

Operator user must use at least one identification mechanism. In case he uses more than one mechanism then all
those must match in the dedicated iOMS for succesfull eNB identification during auto connection.

RA41129EN05GLA0 21
LTE Self Organizing Networks (SON)

At least one dedicated iOMS is required, this is the node that identifies the eNB (based on Site ID, HW ID, or GPS
coordinates) and maps to the eNB object within the Netact Topology DB. Final iOMS may be the same as the
dedicated iOMS.

eNB identification during auto connection

Operator can choose from three different alternative eNB identification mechanisms. All three require that the
temporary eNB identification parameter(s) are beforehand configured by user into dedicated iOMS. When eNB auto
connects the dedicated iOMS and provides the same temporary identification, the dedicated iOMS is then able to
identify the eNB. After this identification using temporary ID, the eNB is linked with its final BTS ID, which is used from
this phase onwards to identify the eNB.

Three alternative eNB identification mechanisms can be choosed from:

1)Site ID based identification. In practice this is a string value defined at planning phase by planner user. That string
value must be made available for installer user who is working at site and he needs to enter this value into eNB using
BTS EM (which should be avoided).
• When operator user wants to use ste ID based identification, he defines value in eNB conf plan for MRBTS:
Auto Connection Site ID (non-nw) parameter. If no value is defined in plan, then this mechanism is not used
2) HW ID based identification. When eNB connects dedicated iOMS it provides the HW ID (installer user at site does
not need to use BTS EM for this). The drawback is that information logistic may be problematic, that how to get eNB
HW ID easily available also for planner user/Configurator user so that he can set HW ID into dedicated iOMS:
• One possibility is that installer user working at site reads the HW ID from the eNB (system module) and
provides it to Configurator user, who can then configure dedicated iOMS. Or this same is done somehow
earlier before taking eNB equipment into site
• When operator user wants to use HW ID based identification, he defines value in eNB conf plan for MRBTS:
Auto Connection Hardware ID (non-nw) parameter. If no value is defined in plan, then this mechanism is not
used
3) GPS location based identification. eNB can have GPS equipment installed (optional). When eNB auto connects to
dedicated iOMS it includes GPS location information and then eNB’s geographical position is used in identification.
Installer user at site does not need to use BTS EM for this.
•Using GPS location based identification is controlled with GPS Tolerance parameter, see Defining eNB AC
functionality in Configurator. In case GPS mechanism is wanted to be used, the GPS Tolerance needs to have value
(in meters).
•In case there are several eNBs at the same site (two eNBs inside tolerance) and the dedicated iOMS can not identify
the eNB, then either site ID or HW ID needs to be used in addition to distinguish eNBs from each other.

Operator user must use at least one identification mechanism. In case he uses more than one mechanism then all
those must match in the dedicated iOMS for succesfull eNB identification during auto connection.

RA41129EN05GLA0 22
LTE Self Organizing Networks (SON)

Optimizer function (optional):

This will use Optimizer to analyze sites adjacent to new eNB and choose a Physical Cell ID
(PCI) and create a list of adjencies based on the network plan. If not using Optimizer option
these values will have to be included in the plan file via planning tool.

RA41129EN05GLA0 23
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 24
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 25
LTE Self Organizing Networks (SON)

SITEs can be mass created into NetAct by importing XML RAML plan file (does .CSV file import
support site objects -> should be checked). Customer documentation needs to explain/refer to
instructions that how to populate SITE objects into NetAct if operator does not yet have SITEs
there.

eNB assigning to SITE can be done at when importing new eNB plan file (RAML) into
Configurator, or manually if creating eNB configuration plan in Configurator using CM Editor.

It is possible by using the same RAML plan file import to get the new SITE, new eNB
configuration and eNB assignment with that SITE.

RA41129EN05GLA0 26
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 27
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 28
LTE Self Organizing Networks (SON)

Operational eNB is managed and mediated via one iOMS – this mediating iOMS is said to have
final iOMS role. eNB’s final iOMS is determined as part of eNB configuration plan. However
during new eNB auto connection only certain iOMS is used – this is called dedicated iOMS.
Dedicated iOMS identifies the new eNB during auto connection and tells to eNB that what is the
final iOMS to connect.

Dedicated iOMS identifies the new eNB during auto connection and tells to eNB that what is the
final iOMS to connect. To enable dedicated iOMS to identify eNB, it needs to have configured
the auto identification parameters. There must be at least one dedicated iOMS for AC to work,
but it is not prevented to have more dedicated iOMS under NetAct. In that case Activate auto
identication operation then activates auto identification to all those iOMS similarly.

RA41129EN05GLA0 29
LTE Self Organizing Networks (SON)

The Workflow Engine is part of the CM Operations Manager tool. The purpose is to streamline
the process for preparing NetAct for eNB auto connection and auto configuration.

The configuration planning stage allows the operator to import plan files (which contain the eNB
data fill and identifying information that is used during auto connection), update plans using the
Optimizer ANR feature, and validate plans.

The activate auto identification step creates the PREBTS objects in the dedicated iOMS that will
be used to identify new eNB when they connect to iOMS.

There are additional operations for manual configuration (if auto configuration is not used) and
steps to force auto configuration trigger (rather than waiting for the polling interval) and resetting
the status.

RA41129EN05GLA0 30
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 31
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 32
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 33
LTE Self Organizing Networks (SON)

RA41129EN05GLA0 34
LTE Self Organizing Networks (SON)

1) Observe the auto connection phases.

These phases consist of IP connectivity establishment, DHCP server connection and
connections to dedicated and final O&M mediators.
If auto connection fails, the Auto connection Registration dialog box is opened.

2) Observe the auto configuration phases.

These phases consist of SW download, SW activation and reset, configuration file download
and configuration file activation and reset phases. All are fully automated and no manual
intervention is required.
Auto configuration can be disabled by clicking the Disable button if for example the site needs
to be commissioned manually. Also if auto configuration is not used at all, you can close the
dialog by clicking the Close button. Clicking the Enable button enables the auto configuration.

RA41129EN05GLA0 35