Sie sind auf Seite 1von 36

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 1
LTE Self Organizing Network (SON) RA41129EN07GLA0 1

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 2
LTE Self Organizing Network (SON) RA41129EN07GLA0 2

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 4
LTE Self Organizing Network (SON) RA41129EN07GLA0 4

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 5
LTE Self Organizing Network (SON) RA41129EN07GLA0 5

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) OSS for SON is aligned with NGMN operations requirements RA41129EN07GLA0 6
LTE Self Organizing Network (SON) OSS for SON is aligned with NGMN operations requirements RA41129EN07GLA0 6

OSS for SON is aligned with NGMN operations requirements

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) A Self-configuration Subsystem will be created in OAM to be responsible
LTE Self Organizing Network (SON) A Self-configuration Subsystem will be created in OAM to be responsible

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 8
LTE Self Organizing Network (SON) RA41129EN07GLA0 8

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 9
LTE Self Organizing Network (SON) RA41129EN07GLA0 9

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 10
LTE Self Organizing Network (SON) RA41129EN07GLA0 10

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP
LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP
LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP
LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP
LTE Self Organizing Network (SON) NOTE: Central ANR and Automated Neighbor Relation (using PCI / IP

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) Cell Outage Detection: The following failure scenarios are taken into account:
LTE Self Organizing Network (SON) Cell Outage Detection: The following failure scenarios are taken into account:

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) SON Reports (LTE1019) records changes related to following SON features: LTE724:
LTE Self Organizing Network (SON) SON Reports (LTE1019) records changes related to following SON features: LTE724:

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

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) SON Reports (LTE1019) records changes related to following SON features: LTE724:
LTE Self Organizing Network (SON) SON Reports (LTE1019) records changes related to following SON features: LTE724:

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

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 18
LTE Self Organizing Network (SON) RA41129EN07GLA0 18

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) • In NSN SON Plug and Play SON Plug and Play
LTE Self Organizing Network (SON) • In NSN SON Plug and Play SON Plug and Play

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

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 20
LTE Self Organizing Network (SON) RA41129EN07GLA0 20

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) SON Plug’n’Play divided into two features: auto connection and auto configuration
LTE Self Organizing Network (SON) SON Plug’n’Play divided into two features: auto connection and auto configuration

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

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 22
LTE Self Organizing Network (SON) RA41129EN07GLA0 22

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) At least one dedicated iOMS is required, this is the node
LTE Self Organizing Network (SON) At least one dedicated iOMS is required, this is the node

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. iOMS.

eNB identification during auto connection

Final iOMS may be the same as the dedicated

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) At least one dedicated iOMS is required, this is the node
LTE Self Organizing Network (SON) At least one dedicated iOMS is required, this is the node

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. iOMS.

Final iOMS may be the same as the dedicated

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) Optimizer function (optional): This will use Optimizer to analyze sites adjacent
LTE Self Organizing Network (SON) Optimizer function (optional): This will use Optimizer to analyze sites adjacent

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 26
LTE Self Organizing Network (SON) RA41129EN07GLA0 26

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 27
LTE Self Organizing Network (SON) RA41129EN07GLA0 27

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) SITEs can be mass created into NetAct by importing XML RAML
LTE Self Organizing Network (SON) SITEs can be mass created into NetAct by importing XML RAML

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 29
LTE Self Organizing Network (SON) RA41129EN07GLA0 29

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 30
LTE Self Organizing Network (SON) RA41129EN07GLA0 30

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) Operational eNB is managed and mediated via one iOMS – this
LTE Self Organizing Network (SON) Operational eNB is managed and mediated via one iOMS – this

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) The Workflow Engine is part of the CM Operations Manager tool.
LTE Self Organizing Network (SON) The Workflow Engine is part of the CM Operations Manager tool.

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.

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 33
LTE Self Organizing Network (SON) RA41129EN07GLA0 33

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 34
LTE Self Organizing Network (SON) RA41129EN07GLA0 34

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 35
LTE Self Organizing Network (SON) RA41129EN07GLA0 35

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) RA41129EN07GLA0 36
LTE Self Organizing Network (SON) RA41129EN07GLA0 36

LTE Self Organizing Network (SON)

LTE Self Organizing Network (SON) 1) Observe the auto connection phases. These phases consist of IP
LTE Self Organizing Network (SON) 1) Observe the auto connection phases. These phases consist of IP

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.

RA41129EN07GLA0

37