Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

OSS for SON is aligned with NGMN operations requirements

RA41129EN08GLA0

Self Optimizing 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.

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

Self Optimizing Networks - SON

RA41129EN08GLA0

10

Self Optimizing 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.

RA41129EN08GLA0

11

Self Optimizing 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.

RA41129EN08GLA0

12

Self Optimizing 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.

RA41129EN08GLA0

13

Self Optimizing 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.

RA41129EN08GLA0

14

Self Optimizing 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.
RA41129EN08GLA0

15

Self Optimizing 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

RA41129EN08GLA0

16

Self Optimizing 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

RA41129EN08GLA0

17

Self Optimizing Networks - SON

RA41129EN08GLA0

18

Self Optimizing Networks - SON

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

RA41129EN08GLA0

19

Self Optimizing Networks - SON

RA41129EN08GLA0

20

Self Optimizing Networks - SON

SON PlugnPlay divided into two features: auto connection and auto
configuration

RA41129EN08GLA0

21

Self Optimizing Networks - SON

RA41129EN08GLA0

22

Self Optimizing 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 eNBs 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.

RA41129EN08GLA0

23

Self Optimizing 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 eNBs 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.

RA41129EN08GLA0

24

Self Optimizing 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.

RA41129EN08GLA0

25

Self Optimizing Networks - SON

RA41129EN08GLA0

26

Self Optimizing Networks - SON

RA41129EN08GLA0

27

Self Optimizing 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.

RA41129EN08GLA0

28

Self Optimizing Networks - SON

RA41129EN08GLA0

29

Self Optimizing Networks - SON

RA41129EN08GLA0

30

Self Optimizing Networks - SON

RA41129EN08GLA0

31

Self Optimizing Networks - SON

Operational eNB is managed and mediated via one iOMS this mediating
iOMS is said to have final iOMS role. eNBs 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.

RA41129EN08GLA0

32

Self Optimizing 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.

RA41129EN08GLA0

33

Self Optimizing Networks - SON

RA41129EN08GLA0

34

Self Optimizing Networks - SON

RA41129EN08GLA0

35

Self Optimizing 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.

RA41129EN08GLA0

36

Self Optimizing Networks - SON

RA41129EN08GLA0

37