SON API Small Cells

SMALL CELL FORUM
RELEASE Five scf.io/
RURAL & REMOTE

DOCUMENT
083.05.01
SON API for small cells
March 2015
www.scf.io/ www.smallcellforum.org
SMALL CELL FORUM
RELEASE Five
Four
Small Cell Forum works to accelerate small cell adoption to change

the shape of mobile networks and maximize the potential of mobile
services.
We are not a standards organization but partner with organizations that inform
and determine standards development. We are a carrier-led organization. This
means our operator members establish requirements that drive the activities
and outputs of our technical groups.
Our track record speaks for itself: we have driven the standardization of key
elements of small cell technology including Iuh,FAPI/SCAPI, SON, the small cell
services API,TR‑069 evolution and the enhancement of the X2 interface.
At the time of writing, Small Cell Forum has more than 140 members, including
68 operators representing more than 3 billion mobile subscribers – 46 per
cent of the global total – as well as telecoms hardware and software vendors,
content providers and innovative start-ups.
This document forms part of Small Cell Forum’s Release Five: Rural &
Remote that considers the opportunities and perceived barriers associated
with the deployment of small cells in rural and remote scenarios, including
disaster recovery, military installations, as well as verticals such as oil and gas,
maritime, aviation and automotive.
The Small Cell Forum Release Program has now established business cases
and market drivers for all the main use cases, clarifying market needs and
addressing barriers to deployment for residential, enterprise and urban small
cells.
Small Cell Forum Release website can be found here: www.scf.io
All content in this document including links and references are for informational
purposes only and is provided “as is” with no warranties whatsoever including
any warranty of merchantability, fitness for any particular purpose, or any
warranty otherwise arising out of any proposal, specification, or sample.
No license, express or implied, to any intellectual property rights is granted or

intended hereby.
If you would like more information about Small Cell Forum or would
like to be included on our mailing list, please contact:
Email info@smallcellforum.org
Post Small Cell Forum, PO Box 23, GL11 5WA UK
Member Services memberservices@smallcellforum.org

Executive summary
This document defines an API between the distributed SON (dSON – implemented and
residing in the small cell) and centralized SON (cSON – implemented and residing
outside the small cell, e.g., in the management system) functionalities (or functional
elements) for SON-enabled LTE small cells, in various deployment scenarios.
The document intent is to define the SON API as an enabler of SON functionalities for
small cells, based on high-level requirements that are independent of the particular
SON architecture. The definition of the SON functions and implementation thereof is
not part of the scope of this document.
The SON API is based on high-level procedures for exchange of information between
cSON and dSON, which are grouped into global procedures (general character) and
function specific procedures (for a particular SON function). For each procedure, the
detailed definition of exchanged information is an integral part of the SON API and
covers in general parameters, performance statistics and notifications.
Finally, guidelines for adopting the SON API and its integration it into the existing
management interfaces for small cells are provided.
Report title: SON API for small cells

Issue date: 02 March 2015
Version: 083.5.1
Contents
1. Introduction .....................................................................1
1.1 Relevant standards .............................................................. 1
2. Generic hybrid SON architecture ......................................3
2.1 Hybrid SON architecture – deployment scenarios ..................... 3
2.2 Hybrid SON architecture – operations .................................... 5
3. SON API procedures .........................................................8
3.1 Global procedures................................................................ 8
3.2 Function specific procedures ............................................... 13
4. SON API content.............................................................19
4.1 Content of global procedure messages ................................. 19
4.2 Content of function specific procedure messages ................... 36
4.3 Error Description ............................................................... 54
5. Guidelines for SON API ...................................................55
5.1 Considerations for SON API mapping on Type-1 interface ....... 55
5.2 Considerations for SON API mapping on type-2 interface ........ 56
Appendix A - SON Functions and SON API requirements
(informative) ..................................................................58
A.1 SON functions overview ..................................................... 58
A.2 SON functions – use cases .................................................. 59
A.3 SON requirement definition................................................. 59
A.4 SON functions requirements ............................................... 60
References ................................................................................80
Tables
Table 4-1 dSONParameter.request content ......................................................19
Table 4-2 dSONParameter.response content ....................................................20
Table 4-3 Information included in ‘Info’ field of dSONParameter.response ...........20
Table 4-4 dSONParameter.response errors ......................................................20
Table 4-5 PMConfig.update content ................................................................25
Table 4-6 PMConfig.ack content .....................................................................25
Table 4-7 PMConfig.ack errors .......................................................................25
Table 4-8 PMReport.notify content .................................................................30
Table 4-9 REMConfig.update content addressing REM measurements .................31
Table 4-10 REMConfig.ack content ...................................................................32
Table 4-11 REMConfig.ack errors .....................................................................32
Table 4-12 REMReport.notify content ...............................................................34
Table 4-13 EventConfig.update content ............................................................34
Table 4-14 EventConfig.ack content .................................................................35
Table 4-15 EventConfig.ack errors ...................................................................35
Table 4-16 EventReport.notify errors ................................................................35
Table 4-17 dSONActivate.request content .........................................................36
Table 4-18 dSONActivate.ack content ...............................................................36
Table 4-19 dSONActivate.ack errors .................................................................36
Table 4-20 dSONDeactivate.request content .....................................................36
Table 4-21 dSONDeactivate.ack content ...........................................................37
Table 4-22 dSONDeactivate.ack errors .............................................................37
Table 4-23 dSONConfig.update content ............................................................37
Table 4-24 MRO Configuration parameters ........................................................38
Table 4-25 MRO Mobility Parameters for Connected Mode ...................................39
Table 4-26 MRO mobility parameters for idle mode ............................................40
Table 4-27 FHM configuration parameters .........................................................40
Table 4-28 RO Configuration parameters ..........................................................42
Table 4-29 CHS configuration parameters .........................................................44
Table 4-30 TPM configuration parameters .........................................................45
Table 4-31 ES configuration parameters ...........................................................46
Table 4-32 BHM configuration parameters .........................................................46
Table 4-33 PCI optimization configuration parameters ........................................47
Table 4-34 ANR configuration parameters .........................................................48
Table 4-35 MLB configuration parameters .........................................................49
Table 4-36 IM configuration parameters ...........................................................50
Table 4-37 dSONConfig.ack content .................................................................50
Table 4-38 dSONConfig.ack errors ...................................................................50
Table 4-39 dSONParameter.notify content ........................................................51
Table 4-40 CHSParameter.notify content ..........................................................51
Table 4-41 TPMParameter.notify content ..........................................................51
Table 4-42 ESParameter.notify content .............................................................51
Table 4-43 BHMParameter.notify content ..........................................................52
Table 4-44 PCIParameter.notify content ...........................................................52
Table 4-45 ANRParameter.notify content ..........................................................53
Table 4-46: IMParameter.notify content ..............................................................53
Table 4-47 dSONParameter.ack content ...........................................................53
Table 4-48 dSONParameter.ack errors ..............................................................54
Table 4-49 SON API Errors description ..............................................................54
Table 5-1 SON API procedures: mapping to TR-069 for Type-1 interface .............55
Table A-1 SON functions ...............................................................................59
Table A-2 Procedures used for PCI optimization to meet the requirements...........62
Table A-3 Procedures used for ANR management to meet the requirements ........63
Table A-4 Multi-vendor scenarios for channel selection ......................................64
Table A-5 Procedures used for Channel selection to meet the given
requirements.................................................................................65
Table A-6 Multi-vendor scenarios for RACH Optimization ...................................67
Table A-7 Procedures used for RO to meet the requirements .............................68
Table A-8 Multi-vendor scenarios for MRO .......................................................69
Table A-9 Procedures used for MRO to meet the requirements ...........................69
Table A-10 Multi-vendor scenarios for FHM ........................................................70
Table A-11 Procedures used for FHM to meet the requirements ...........................71
Table A-12 Multi-vendor scenarios for MLB ........................................................72
Table A-13 Procedures used for MLB to meet the requirements ............................73
Table A-14 Multi-vendor scenarios for transmit power management. ....................73
Table A-15 Procedures used for transmit power management to meet the given
requirements.................................................................................74
Table A-16 Multi-vendor scenarios for interference management. ........................76
Table A-17 Procedures used for IM to meet the requirements. .............................77
Table A-18 Multi-vendor scenarios for ES ..........................................................77
Table A-19 Procedures used for ES to meet the requirements ..............................78
Table A-20 Procedures used for BHM to meet the requirements ...........................79
Figures
Figure 2-1 Generic hybrid SON architecture ....................................................... 3
Figure 2-2 SON API architecture in case of NM layer cSON .................................. 4
Figure 2-3 SON API architecture in case of EM layer cSON ................................... 5
Figure 2-4 Hybrid SON operations .................................................................... 6
Figure 2-5 Example of message exchange for hybrid SON operations .................... 7
Figure 3-1 dSON parameter retrieve procedure flow ........................................... 9
Figure 3-2 Performance counter configuration procedure flow .............................10
Figure 3-3 Performance counter reporting procedure flow...................................10
Figure 3-4 REM measurement configuration procedure flow ................................11
Figure 3-5 REM measurement reporting procedure flow .....................................12
Figure 3-6 Event configuration procedure flow ..................................................12
Figure 3-7 Event Notification reporting procedure flow .......................................13
Figure 3-8 SON algorithm state transitions and procedures for SON API ...............14
Figure 3-9 dSON function activation procedure flow ...........................................15
Figure 3-10 dSON function deactivation procedure flow .......................................16
Figure 3-11 dSON function configuration procedure flow ......................................17
Figure 3-12 dSON function parameter change notification procedure flow ..............18
Figure 5-1 Mapping of SON API operations onto Type 1 and Type 2 interfaces
(example: PCI selection).................................................................57
Figure 5-2 Example of interference management helping cell edge user
performance .................................................................................75
Figure 5-3 An illustration of (H)eNB connectivity to operator’s network. The S1
interface share Internet connection with other devices over the
shared backhaul. ...........................................................................79
1. Introduction
Small cell deployments are foreseen to occur in different scenarios, like enterprise,
dense urban residential and business areas, as well as venues. These scenarios
include both uncoordinated and coordinated deployments, with potential site planning
by the operator, or coordination enabled by small cell vendors or corporate customers.
In addition to the variety of deployments, there are further challenges that an
operator may face, such as a multi-vendor heterogeneous environment, with expected
seamless operations.
The self-organizing networks (SON) concept includes a combination of different

network self-configuration and self-optimization functions. Parts of some SON
functions will be executed locally at the individual small cell (i.e., 3GPP (H)eNBs),
interacting with the immediate neighborhood, while other parts will process network
wide information and configuration (e.g. OAM), and will reside in a central server. A
unified cross-vendor interface between the distributed (dSON) and centralized (cSON)
functional elements is required for SON function operation in a heterogeneous SON
deployment.
The SON API defined in this document is targeted to contribute to a harmonized

approach to the partitioning of distributed and centralized SON functions. It is
recognized that a wide adoption of SON for small cells will simplify operations and
reduce costs in heterogeneous networks involving multiple vendors.
The document is structured as follows:
• Chapter 2 includes information about SON architecture assumptions relevant

for the SON API and related operations for a hybrid SON solution, combining
distributed SON with centralized SON
• Chapter 3 includes a high level description of SON API procedures
• Chapter 4 defines the content of the SON API, derived from architecture, use
cases and requirements
• Chapter 5 collects guidelines and recommendations to enable SON API
adoption
An informative Annex captures requirements for the SON API, separately for each SON
functions. For SON use cases, existing documentation from the Small Cell Forum is
referred to [1], [2] and [3].
1.1 Relevant standards
Relevant documents and applicable standards for the SON API are listed here below,
with a brief description, grouped according to the responsible organization.
Small Cell Forum (SCF)

• Small Cell Forum 066.03.01- Enterprise SON use cases [1]: Description of
SON use cases identified for enterprise deployment scenarios
• Small Cell Forum 077.03.01- Urban SON use cases [2]: Description of SON
use cases identified for urban deployment scenarios – builds on top of
enterprise document and includes side-by-side list of cases
• Small Cell Forum 059.04.01 - X2 interoperability in multi-vendor X2 HetNets
[4]: Description of challenges and recommendations for small cells multi-
vendor X2 message exchanges, including various SON functions

Version: 083.5.1 1
• Small Cell Forum 088.04.02 - Urban small cell network architectures [3]:
White paper addressing various architectural and functional aspects for urban
small cell networks, including some SON-related parts.
NGMN Alliance
• NGMN - Recommended practices for multivendor SON deployment [5]:
Description of challenges and recommendations for multi-vendor X2 message
exchanges, including various SON functions
Broad Band Forum (BBF)

• BBF TR-069 - CPE WAN management protocol [6]: Specification of the
protocol used to exchange information between management system and
device, e.g. to carry the data model described in TR-196.
• BBF TR-196 – Femto access point service data Model [7]: Specification of
data model for data exchange (e.g. configuration parameters) between
element manager (HeMS in case of LTE) and femto access point device
(HeNB for LTE)
3GPP
• 3GPP TS 36.300 – E-UTRAN overall description, Stage-2 [8]: Specification of
the LTE radio access network functionalities and behaviour, including a
chapter for SON and for X2 procedures
• 3GPP TS 36.423 – X2 application protocol (X2AP) [9]: Specification of X2
interface application protocol – includes detailed procedures, messages and
information elements for distributed SON support
• 3GPP TS 32.453 – Performance measurements Home enhanced Node B
(HeNB) Subsystem (HeNS) [10]: Specification of performance measurements
for HeNB
• 3GPP TS 32.425 – Performance measurements E-UTRAN [11]: Specification
of performance measurements for E-UTRAN
• 3GPP TS 32.522 – SON policy network resource model (NRM) Integration
reference point (IRP); Information service (IS) [12]: Specification regarding
the protocol for management of neutral SON policies – contains descriptions
for the Self-optimization OAM, SON coordination and energy saving
management.
• 3GPP TS 32.762 – EUTRAN network resource model (NRM) Integration
reference point (IRP); Information service (IS) [13]: Specification regarding
configuration management information concerning E-UTRAN resources.
• 3GPP TS 32.592 – HeNB OAM&P - Information model for Type 1 interface
HeNB to HeNB management system (HeMS) [14]: Specification for interface
model/mapping of interface towards the element manager, related to HeNBs
– links into BBF TR-196 data model.
• 3GPP TS 32.571 HNB and HeNB management; Type 2 interface concepts and
requirements [15]: Specification for management concepts of interface
towards the network manager (Itf-N), related to HeNBs.
• 3GPP TS 32.572 HNB and HeNB management; Type 2 interface models and
mapping functions [16]: Specification for interface model/mapping of
interface towards the network manager (Itf-N), related to HeNBs.
• 3GPP TS 32.101 Telecommunication management; Principles and high level
requirements [17]: Specification for general principles of managing a
wireless telecommunication network
• 3GPP TS 32.593 HeNB OAM Procedure flows for Type-1 Interface HeNB to
HeMS [18]: Specification for Type-1 interface procedures for HeNB, including
configuration, fault and performance management.

Version: 083.5.1 2
2. Generic hybrid SON architecture
The LTE SON architecture has a split of functionalities between the small cells
(distributed SON) and a central SON Server (centralized SON). Generally speaking,
algorithms requiring fast response, UE specific information and rich input data sets are
easier implemented locally by dSON. On the other hand, algorithms requiring wide
area visibility and parameter settings, without the need for fast response times, are
easier implemented by cSON.
Therefore, a hybrid architecture for SON combines the best of the two approaches,
with interacting cSON and dSON components. The cSON entity could be seen as a part
of the network manager (NM) and/or of the element manager (EM) and provides
guidelines and parameter ranges to dSON functions, being itself regularly updated
with information retrieved from the small cell (e.g., performance counters). The local
dSON entities adjust local parameter settings within the provided framework,
autonomously in each eNB, or interacting over X2 with neighbor eNBs.
Figure 2-1 illustrates the high-level concept of the generic hybrid SON architecture.
EM/NM
cSON
Performance
Counters, Parameters,
Alarms, Guidelines
Notifications
dSON dSON
X2
eNB eNB
LTE Access with dSON
Figure 2-1 Generic hybrid SON architecture
2.1 Hybrid SON architecture – deployment scenarios
The SON API, defined in this document, allows exchanges of information between
dSON and cSON in a hybrid SON architecture within a multi-vendor small cell
deployment.
Different scenarios can be required with small cell deployments and the SON API shall
be designed such that all the relevant cases are covered properly for correct
operations. In this regard, various discriminators should be taken into account:
• Coexistence of SCs from different vendors, with or without X2 interface – in

the case that the X2 interface is not present, cSON can potentially secure
harmonization across various SON components, exchanging relevant
information via the SON API.
• Coexistence of different SON implementations – the SON API should not limit
the individual SON functions to particular implementations or methods, rather
enable coexistence of different SON implementations aiming to deliver
harmonized behaviour and performance.

Version: 083.5.1 3
• Overlay macro cells, with or without X2 interface to SCs – SON procedures
can differ significantly for the cases that a macro layer is available or not
(and, potentially, if an X2 interface is in place between SC (H)eNBs and the
macro eNBs). The SON API needs to cover relevant deployment and
configuration options.
Two main flavours of cSON are described in the next sections, NM layer and EM layer.
Note: Solutions in which cSON is present at both NM and EM layers are possible, but
the interaction between those cSON entities is not in scope of this document.
2.1.1 SON API architecture for NM layer cSON
This section is based on the 3GPP management reference model (see [17]).
The SON API architecture in case of NM layer cSON is outlined in Figure 2-2, where
the SON API is operating towards the HeNBs only. Connection between the NM layer
cSON and the HeNB requires two components of the SON API interface to be
implemented. These components are mapped on to type 1 and type 2 interfaces
correspondingly and it is assumed that the EM layer is represented by a functional
entity responsible for translation between the type 1 and type 2 components (‘SON
API agent’ in the figure). In general, NM layer cSON, EM/HeMS and network element
(NE) HeNB may all be manufactured by different vendors, with various coexistence
cases under NM layer cSON coordination.
Figure 2-2 SON API architecture in case of NM layer cSON
2.1.2 SON API Architecture for EM layer cSON
The SON API architecture in the case of an EM layer cSON is outlined in Figure 3, with
SON API interfacing the HeNB with the EM/HeMS, with possible presence of a network
manager (NM). Connection between the EM layer cSON and the HeNB requires one

Version: 083.5.1 4
component of the SON API interface to be implemented and mapped onto Type 1
interface – no translating ‘SON API agent’ is needed. In general, the NM layer,
EM/HeMS and HeNB may all be manufactured by different vendors, with possible cSON
coordination at the EM layer.
Figure 2-3 SON API architecture in case of EM layer cSON
2.2 Hybrid SON architecture – operations
The integration of cSON with dSON can follow two general interaction approaches,
depending on the particular function (see Figure 2-4).
• Autonomous operation: The central SON server signals to the (H)eNBs

parameter ranges valid for the distributed SON algorithms – parameter value
decisions are then taken autonomously at (H)eNB within the configured
ranges and are informed back to the central SON server via OAM
• Controlled operation: The central SON server takes a decision and signals
the final parameter value to the (H)eNB – (H)eNBs assist the central server
with performance counters, alarms, etc.
Note: cSON can also exercise an intermediate level of control by means of

authorization of parameter settings. This can be achieved by narrowing the
autonomous range to exclude the value proposed by dSON, thus denying the
authorization.

Version: 083.5.1 5
cSON Server
Range Range Setting/ Central

Setting Authorization Operation
Notification
New Range
Performance
Setting
Range
Range
Parameter
Counters, Ranges, Guidance
Notifications
Autonomous Authorized Controlled

Operations Operations Operations
eNB dSON
RRM Metrics
UE Reports
X2 Reports
Backhaul
REM
Figure 2-4 Hybrid SON operations
An example of message flow for hybrid SON operations making use of the SON API
procedures (see chapter 3) is depicted in Figure 2-5.
• Initially cSON configures general performance counters and parameters for

particular dSON algorithm operations (e.g. provides a list of possible choices)
• dSON optimizes the parameters during operations, based on received
configuration and locally available information and algorithms (e.g., X2
exchange, UE reports, REM)
• When a new value is selected, notification can be given to cSON
• In addition, performance counters are reported to cSON so that cSON can
extract useful information and possibly update the dSON configuration

Version: 083.5.1 6
cSON Server dSON
(via OAM) (SC eNB)
Performance Counter Configuration
dSON Parameter Configuration

Inputs, e.g.
• X2 exchange
dSON Function • UE Reports
• REM
Parameter Change Notification

New valued
applied @ SC
PerfCounter
computation
Counters Uploaded to OAM/cSON
Configuration
Update
Updated Parameter Configuration

SON API exchanges
Figure 2-5 Example of message exchange for hybrid SON operations

Version: 083.5.1 7
3. SON API procedures
This chapter gives an overview of the SON API procedures that are used to fulfill the
SON requirements defined in the informative Annex. These procedures are split into
two groups, namely, global procedures and function specific procedures. Global
procedures relates to the complete set of available SON functions. Function specific
procedures are procedures that require an individual instantiation on a per SON
function basis.
Procedures are described with the help of abstract message flows, where each
message has a specific purpose, i.e., it fulfills a particular communication function
within the procedure. Messages are introduced in this purely abstract functional
context, without any consideration of existing protocols, solutions, or message sets –
see Chapter 5 for guidelines about integration of SON API into existing interfaces.
3.1 Global procedures
The global procedures supported by the SON API are:
• dSON parameter retrieve

• PM configuration
• PM reporting
• REM configuration
• REM reporting
• Event configuration
• Event notification
These procedures are not specific for a particular SON function, can be executed
independently of the state of a particular SON algorithm (see Figure 3-8 in section
3.2) and do not modify the current state. The dSON parameter retrieve outcome may
vary depending on the state, as illustrated in section 3.1.1.
3.1.1 dSON Parameter Retrieve
This procedure allows the cSON to enquire a (H)eNB about the dSON capability,
configuration and status, for all SON algorithms. The current configuration parameters
are included in the report, together with a list of set up X2 interfaces.
The high-level message flow of this procedure is as follows (see Figure 3-1):
• dSONParameter.request (cSON  dSON): request SON configuration from

(H)eNB
• dSONParameter.response (dSON  cSON): (H)eNB reply with SON
configuration

Version: 083.5.1 8
cSON dSON
dSONParameter.request()
dSONParameter.response(OK)
• Successful response include

capability, status and
parameters of all SON functions
• Error messages are defined in
case of anomalous situation
• A guard time may run in cSON to
track reception of the response
Figure 3-1 dSON parameter retrieve procedure flow
3.1.2 PM configuration
This procedure allows the cSON server to instruct the (H)eNB which sets of
performance counters need to be reported to cSON to ensure the configured SON
function operation. The set of performance counters should cover all active SON
functions and results will be reported via the PM reporting procedure (see section
3.1.3).
The high-level PM configuration procedure message flow is (see Figure 3-2):
• PMConfig.update (cSON  dSON): to indicate an updated set of performance

counters to be reported, including their reporting period
• PMConfig.ack (dSON  cSON): (H)eNB acknowledges (or not) the available
performance counters in the updated set

Version: 083.5.1 9
cSON dSON
PMConfig.update()
PMConfig.ack(OK)
• Response include list of ACK for

performance counters available
• A guard time can run in cSON to
Figure 3-2 Performance counter configuration procedure flow
3.1.3 PM reporting
This procedure allows the eNB (dSON) to report configured performance counters to
the cSON server (see also [18]).
The high-level execution flow of this procedure is as follows (see Figure 3-3):
• (H)eNB reads the requested performance counters from the register

(expected to be available locally at (H)eNB if acknowledged in PM
configuration procedure)
• PMReport.notify (dSON  cSON): (H)eNB sends performance counters, along
with timestamp of collection interval, to cSON server (if performance counter
is not available, empty results are sent)
cSON dSON
PM Counter
Computation
PMReport.notify()
• Configured Performance
Counters are reported to cSON
Figure 3-3 Performance counter reporting procedure flow

Version: 083.5.1 10
For the measurements to be transferred via the standard Type 1 interface to EM
(therefore to EM cSON), the process illustrated in [18] can be used, with possible
extensions to [7] where needed. For the measurements to be transferred via the
standard Type 2 interface from EM to NM (therefore to NM cSON) 3GPP specifications
[10] can be reused, with possible extensions where needed.
3.1.4 REM configuration
This procedure allows the cSON server to instruct the (H)eNB which sets of REM
measurements need to be reported to cSON. The results will be reported via the REM
Reporting procedure (see section 3.1.5).
The high-level REM configuration procedure message flow is (see Figure 3-4):
• REMConfig.update (cSON  dSON): to indicate an updated set of REM

measurements to be reported and including reporting configuration
• REMConfig.ack (dSON  cSON): (H)eNB acknowledges the updated
configuration of REM measurements
cSON dSON
REMConfig.update()
REMConfig.ack(OK)

available REM measurements
Figure 3-4 REM measurement configuration procedure flow
3.1.5 REM reporting
This procedure allows the (H)eNB (dSON) to report configured REM measurements to
the cSON server. The high-level execution flow of this procedure is as in Figure 3-5:
• eNB performs the requested measurements with REM module

• REMReport.notify (dSON  cSON): (H)eNB sends measurement results to
cSON server (if measurements are not available, empty results are sent)

Version: 083.5.1 11
cSON dSON
REM
Measures
REMReport.notify()
• Configured REM Measurements

are reported to cSON
Figure 3-5 REM measurement reporting procedure flow
3.1.6 Event configuration
This procedure allows the cSON server to instruct the (H)eNB which sets of events
need to trigger a notification to cSON, in conjunction with SON functions.
The high-level event configuration message flow is as in Figure 3-6:
• EventConfig.update (cSON  dSON): to indicate a set of events to be notified

by the (H)eNB
• EventConfig.ack (dSON  cSON): (H)eNB acknowledges the updated event
set
cSON dSON
EventConfig.update()
EventConfig.ack(OK)

event notifications available
Figure 3-6 Event configuration procedure flow

Version: 083.5.1 12
3.1.7 Event notification
This procedure allows the (H)eNB (dSON) to report a SON-related event notifications
to cSON, according to its current event configuration.
• EventReport.notify (dSON  cSON): (H)eNB sends SON-related event

notification when a configured event happens
cSON dSON
Notification
Event Occurs
EventReport.notify()
• Configured Events Notifications

are reported to cSON
Figure 3-7 Event Notification reporting procedure flow
3.2 Function specific procedures
The function specific procedures supported by the SON API are:
• dSON activation
• dSON deactivation
• dSON configuration
• dSON parameter change notification
Each individual SON function can be separately configured or (de-)activated. The

individual status can be represented in a state diagram with the following two states
(see Figure 3-8), that each SON function can have independently from each other:
• Inactive: algorithm has not been activated and has either a default, or has
received an updated operational configuration
• Active: dSON algorithm is successfully configured and activated, and is now
operational
Note: It is assumed that upon (H)eNB power up or after an (H)eNB reset all SON
functions will start from the ‘inactive’ state with default configuration.

Version: 083.5.1 13
dSON Configuration Retrieve
dSON Configuration Update
Inactive
dSON Activation
dSON Deactivation
Active
dSON Configuration Retrieve

dSON Configuration Update
dSON Parameter Change Notification
Figure 3-8 SON algorithm state transitions and procedures for SON API
3.2.1 dSON activation
This procedure allows the cSON to activate a particular dSON function and move its
state from ‘inactive’ to ‘active’.
• dSONActivate.request (cSON  dSON): cSON server sends a message to

(H)eNB indicating activation of a particular SON function
• (H)eNB takes appropriate action in activating the addressed SON function
• dSONActivate.ack (dSON  cSON): (H)eNB acknowledges receipt of message
and completion of requested activation

Version: 083.5.1 14
cSON dSON
dSONActivate.request()
dSONActivate.ack(STATUS)
• Response include status of the

SON function after activation
case of anomalous situations
Figure 3-9 dSON function activation procedure flow
3.2.2 dSON deactivation
This procedure allows the cSON to deactivate a particular dSON function and move its
state from ‘active’ to ‘inactive’.
• dSONDeactivate.request (cSON  dSON): cSON server sends a message to

(H)eNB indicating deactivation of a particular SON function
• (H)eNB takes appropriate action in deactivating the addressed SON function
• dSONDeactivate.ack (dSON  cSON): (H)eNB acknowledges receipt of
message and completion of requested deactivation

Version: 083.5.1 15
cSON dSON
dSONDeactivate.request()
dSONDeactivate.ack(STATUS)
• Response include status of the

SON function after deactivation
case of anomalous situations
Figure 3-10 dSON function deactivation procedure flow
3.2.3 dSON configuration
This procedure allows the cSON to configure the dSON function at the (H)eNB to
operate according to a specific guidance, optimization targets, and parameter ranges.
The allowed set of guidance, targets and parameters is specific to each SON function.
• dSONConfigure.update (cSON  dSON): cSON server sends a message to

(H)eNB indicating updated configuration of a particular SON function
• (H)eNB takes appropriate action in configuring the addressed SON function
• dSONConfigure.ack (dSON  cSON): (H)eNB acknowledges completion of
requested configuration with a response message, including the updated
configuration settings for that SON function
Note: A special case is to reconfigure back the SON function to default values
(configuration delete).

Version: 083.5.1 16
cSON dSON
dSONConfigure.update()
dSONConfigure.ack(OK)
• Response include actual

parameter configuration
Figure 3-11 dSON function configuration procedure flow
3.2.4 dSON parameter change notification
This procedure allows a particular dSON algorithm to notify the cSON upon a change
of parameter value as a result on local optimization, while in ‘active’ state.
The high-level message flow of this procedure is as follows (see Figure 3-12):
• dSONParameter.notify (dSON  cSON): dSON notifies cSON of parameter

changes with respect to previous configuration, including updated value
• dSONParameter.ack (cSON  dSON): cSON acknowledges the receipt of the
parameter change notification

Version: 083.5.1 17
cSON dSON
dSONParameter.notify(PARAM)
dSONParameter.ack()
• Notification includes parameter

changed and actual value
• A guard time can run in dSON to
Figure 3-12 dSON function parameter change notification procedure flow

Version: 083.5.1 18
4. SON API content
This chapter provides a description of the SON API abstract message content. It
defines the information (content-wise) in the abstract SON API messages of the
procedures listed in chapter 3 for the SON functions of interest, without assuming any
particular data model or interface realization.
The definition of abstract messages, via their context and contents, does not imply
that in a practical realization, separate messages (or message types) need to be used
for each of the abstract messages. Depending on the selected transmission protocol,
several of the abstract procedures and messages could be mapped – e.g., to one
particular protocol procedure, using the same real messages with different parameters
transmitted in the message.
The information content is described in terms of name and description – References to

existing data models are included where available to capture the outcome of the gap
analysis.
4.1 Content of global procedure messages
4.1.1 dSON parameter retrieve messages
dSONParameter.request
This message is sent from cSON to dSON and it is state-independent. Algorithms will
report capability and the current configuration in the dSONParameter.response
message.
This message includes ECGI[n] to identify the addressed cells.
Name Description Reference

ECGI[n] Specifies target cells. Defined in TS 36.423 [9]
Table 4-1 dSONParameter.request content
dSONParameter.response
The content of the dSONParameter.response message is provided in the Table 4-2. It
contains a list of supported dSON functions, with information about capability, status
and configuration for each of them.

Error Errors that may be returned upon failure –
include also the ‘no error’ case
MRO Info MRO dSON algorithm capability, status and See Table 4-3
configuration
FHM Info FHM dSON algorithm capability, status and See Table 4-3
configuration
RO Info RO dSON algorithm capability, status and See Table 4-3
configuration
CHS Info CHS dSON algorithm capability, status and See Table 4-3
configuration
TPM Info TPM dSON algorithm capability, status and See Table 4-3
configuration
ES Info ES dSON algorithm capability, status and See Table 4-3
configuration
BM Info BM dSON algorithm capability, status and See Table 4-3

Version: 083.5.1 19
configuration
PCI Info PCI Optimization dSON algorithm capability, See Table 4-3
status and configuration
ANR Info ANR dSON algorithm capability, status and See Table 4-3
configuration
MLB Info MLB dSON algorithm capability, status and See Table 4-3
configuration
IM Info IM dSON algorithm capability, status and See Table 4-3
configuration
Table 4-2 dSONParameter.response content
Each of the SON function Info fields consists of the following information sub-fields:

<SON fcn> Identifier Identify the SON function with one of the
following values: ‘MRO’, ‘FHM’, ‘RO’, ‘CHS’,
‘TPM’, ‘ES’, ‘BHM’, ‘PCI’, ‘ANR’, ‘MLB’, ‘IM’
<SON fcn> Indicates if the SC is capable of <SON fcn>
Capability algorithm or not capable
<SON fcn> Status Indicates the status of the <SON fcn> See Section 3.2
algorithm (inactive, active)
<SON fcn> <SON fcn> configuration parameter list and MRO: Table 4-24
Configuration corresponding current values FHM: Table 4-27
RO: Table 4-28
CHS: Table 4-29
TPM: Table 4-30
ES: Table 4-31
BHM: Table 4-32
PCI: Table 4-33
ANR: Table 4-34
MLB: Table 4-35
IM: Table 4-36
Table 4-3 Information included in ‘Info’ field of dSONParameter.response
ERRORs for dSON parameter retrieve procedure

Errors that may be returned in dSONParameter.response are given in Table 4-4.

MSG_OK Successful generation of parameter
information (no error)
ERR_INVALID_ECGI One or more ECGI values requested are
not present in the receiving (H)eNB
ERR_PARAMETER_FAIL (H)eNB cannot provide dSON parameters
to cSON, upon request
Table 4-4 dSONParameter.response errors
4.1.2 PM configuration messages
PMConfig.update
This message indicates an updated set of performance counters to be reported, if
supported, from dSON to cSON, including their reporting frequency. This message
includes ECGI[n] to identify the addressed cells for counters reporting.

Version: 083.5.1 20
The PMConfig.update content is given in Table 4-5 – for each counter the reporting
period is configured (the special value ‘0 = zero’ means disable reporting).
Note: Counters which are specific to certain SON function (e.g. MRO only) shall not be
assumed to be available in case that SON function is not implemented or is disabled.

ECGI[n] Specifies target cells. Defined in TS
36.423 [9]
NumHOIntraFreqAttempt Reporting period for number of Sec 4.2.4.2.1
attempted outgoing LTE intra-frequency in 32.453 [10]
handovers. Includes successful
handovers plus all identified failures.
NumHOInterFreqAttempt Reporting period for number of Sec 4.2.4.2.1
attempted outgoing LTE inter-frequency in 32.453 [10]
handovers. Includes successful
handovers plus all identified failures.
NumHOIntraFreqSucc Reporting period for number of Sec 4.2.4.2.2
successful outgoing LTE intra-frequency in 32.453 [10]
handovers.
NumHOInterFreqSucc Reporting period for number of Sec 4.2.4.2.2
successful outgoing LTE inter-frequency in 32.453 [10]
handovers.
NumHOIntraFreqFailure Reporting period for number of failed Sec 4.2.4.2.3
outbound intra LTE intra frequency in 32.453 [10]
handovers.
NumHOInterFreqFailure Reporting period for number of failed Sec 4.2.4.2.3
outbound LTE inter-frequency in 32.453 [10]
handovers.
NumHOFromIntraFreqAtt Reporting period for number of Sec 4.2.4.2.4
attempted incoming LTE intra- in 32.453 [10]
frequency handovers. Includes
successful handovers plus all identified
failures.
NumHOFromIntraFreqSucc Reporting period for number of Sec 4.2.4.2.5
successful incoming LTE intra-frequency in 32.453 [10]
handovers.
NumHOFromFreqFailure Reporting period for number of failed Sec 4.2.4.2.6
inbound intra LTE intra frequency in 32.453 [10]
handovers.
NumHOTooEarly Reporting period for number of MRO Sec 4.3.5 in
Too Early HO failure cases (ECGI) – 32.522 [12]
MRO only.
NumHOTooLate Reporting period for number of MRO Sec 4.3.5 in
Too late HO failure cases (ECGI) – MRO 32.522 [12]
only.
NumHOWrongCell Reporting period for number of MRO HO Sec 4.3.5 in
failures to a wrong cell, wrong cell 32.522 [12]
(ECGI 1 instead of ECGI 2) – MRO only.
NumHOPingPongClassify Reporting period for number of -
handovers classified as ping pong
handovers.
NumFHMHOInterFreqAttempt Reporting period for number of See Note 1
attempted FHM triggered outgoing LTE below
inter-frequency handovers. Includes
failures – FHM only.

Version: 083.5.1 21
NumFHMHOInterFreqSucc Reporting period for number of FHM See Note 1
triggered outgoing LTE inter-frequency below
handovers successful – FHM only.
NumFHMHOInterFreqFailure Reporting period for number of FHM See Note 1
triggered outgoing LTE inter-frequency below
handover failures – FHM only.
AttemptedRRCConnEst Reporting period for number of RRC Sec. 4.2.2.1 in
connection establishment attempts for 32.453 [10]
each establishment cause.
SuccRRCConnEst Reporting period for number of Sec. 4.2.2.2 in
successful RRC establishments for each 32.453 [10]
establishment cause.
FailedRRCConnEst Reporting period for number of RRC Sec. 4.2.2.3 in
establishment failures for each rejection 32.453 [10]
cause.
DL PRB Usage for traffic Reporting period for the usage (in Sec. 4.5.1 in
percentage) of physical resource blocks 32.425 [11]
(PRBs) on the downlink for DTCH
traffic. The measurement is split into
sub-counters per E-RAB QoS level
(QCI).
UL PRB Usage for traffic Reporting period for the usage (in Sec. 4.5.2 in
(PRBs) on the uplink for DTCH traffic.
DL Total PRB Usage Reporting period for the total usage (in Sec. 4.5.3 in
(PRBs) on the downlink for any
purpose.
UL Total PRB Usage Reporting period for the total usage (in Sec. 4.5.4 in
(PRBs) on the uplink for any purpose.
Cell Unavailable Time Reporting period for the length of time Sec. 4.5.6 in
the cell has been unavailable for each 32.425 [11]
cause. This measurement is obtained
by accumulating the time periods when
the cell is unavailable per cause. The
possible cause could be ‘manual
intervention’, ‘fault’ and ‘energy
saving’.
DL PRB full utilisation Reporting period for the percentage of Sec. 4.5.9.1 in
time during which all available PRBs for 32.425 [11]
traffic on the downlink have been
assigned
UL PRB full utilisation Reporting period for the percentage of Sec. 4.5.9.2 in
time during which all available PRBs for 32.425 [11]
traffic on the uplink have been assigned
Mean processor usage Reporting period for the mean usage of Sec. 4.8.2 in
each key processor. Each equipment 32.425 [11]
may have more than one key
processor, how to identify key
processor is vendor specific.
Peak processor usage Reporting period for the peak usage of Sec. 4.8.1 in
each key processor. Each equipment 32.425 [11]
may have more than one key
processor, how to identify key
processor is vendor specific.

Version: 083.5.1 22
RachPreambleDedMean Reporting period for mean number of Sec. 4.5.5.1
RACH preambles received. 32.425 [11]
This measurement provides the mean
number of RACH preambles received in
a cell in one second. Separate counts
are provided for dedicated preambles,
randomly chosen preambles in group A
(aka ‘low range’) and randomly chosen
preambles in group B (aka ‘high range’)
– RO only.
Reporting period for mean number of Sec. 4.5.5.1
RachPreambleAMean RACH preambles received. 32.425 [11]
– RO only.
Reporting period for mean number of Sec. 4.5.5.1
RachPreambleBMean RACH preambles received. 32.425 [11]
– RO only.
RachPreambleDist Reporting period for distribution of Sec. 4.5.5.2 in
RACH preambles sent. 32.425 [11]
This measurement provides the
distribution of number of RACH
preambles sent by the UE as reported
by the UEs inside the
UEInformationResponse message – RO
only.
RachAccessDelayDist Reporting period for distribution of Sec. 4.5.5.3 in
RACH access delay. 32.425 [11]
distribution of number of the time
before UEs in a cell achieve a successful
attach. The RACH access delay is the
time from when a UE sends its first
Random Access Preamble until the UE
receives the Random Access Response
– RO only.
RachContentionReported Reporting period for percentage of Sec. 4.5.5.4 in
contentious RACH attempts. 32.425 [11]
percentage of UEInformationResponse
messages received within the
measurement granularity interval with
contentionDetected IE set to TRUE – RO
only.
RachReportCount Reporting period for number of UE Sec. 4.5.5.5 in

Version: 083.5.1 23
RACH reports received. 32.425 [11]
This measurement provides the number
of UEInformationResponse messages
received within the measurement
granularity interval containing
rachReport-r9 IE – RO only.
RachDedicatedPreamblesAssigne Reporting period for percentage of time Sec. 4.5.5.6 in
d when all dedicated RACH preambles are 32.425 [11]
used.
percentage of time when all dedicated
RACH preambles are assigned to UEs –
RO only.
DRB.PdcpSduBitrateDl.QCI Reporting period for average DL cell Sec. 4.2.5.1
PDCP SDU bit-rate. in 32.453 [10]
DRB.PdcpSduBitrateUl.QCI Reporting period for average UL cell Sec. 4.2.5.2 in
PDCP SDU bit‐rate. 32.453 [10]
DRB.PdcpSduBitrateDlMax Reporting period for Maximum DL cell Sec. 4.2.5.3 in
PDCP SDU bit‐rate. 32.453 [10]
DRB.PdcpSduBitrateUlMax Reporting period for Maximum UL cell Sec. 4.2.5.4
PDCP SDU bit-rate. in 32.453
[10]
DRB.PdcpSduDelayDl.QCI Reporting period for Average DL Sec. 4.2.6.1
PDCP SDU delay. in 32.453
[10]
DRB.PdcpSduDropRateDl.QCI Reporting period for Average DL PDCP Sec. 4.2.6.2 in

SDU drop. 32.453 [10]
DRB.PdcpSduAirLossRateDl.QCI Reporting period for DL PDCP SDU air Sec. 4.2.7.1 in
interface loss. 32.453 [10]
DRB.PdcpSduLossRateUl.QCI Reporting period for UL PDCP SDU loss Sec. 4.2.7.2,
rate. TS 32.453
[10]
UnknownIntraFrequencyPCI Reporting period for unknown intra- -
frequency PCI.
The counter is updated upon report,

from a UE connected to the eNB, of an
intra-frequency detected PCI that is not
yet added to the NRT (e.g. because too
weak)
DL PRB Usage for protected Reporting period for DL PRB Usage for See Note 2
resources protected resources. below
This measurement provides the usage

(in percentage) of protected physical
resource blocks (PRBs) on the downlink
for DTCH traffic, according to DL mask
– IM only.
UL PRB Usage for protected Reporting period for UL PRB Usage for See Note 2
resources protected resources. below

(in percentage) of protected physical
resource blocks (PRBs) on the uplink for
DTCH traffic, according to UL mask – IM

Version: 083.5.1 24
only.
ABS Usage Reporting period for ABS Usage. See Note 2
below
(in percentage) of ABS according to
ABS pattern – IM only.
Table 4-5 PMConfig.update content
Note 1: The definitions of NumFHMHOInterFreqAttempt, NumFHMHOInterFreqSucc

and NumFHMHOInterFreqFailure are similar to Sec 4.2.4.2.1, Sec 4.2.4.2.2 and Sec
4.2.4.2.3 in 32.453 [10]. These counters are updated only when inter-frequency HOs
are triggered by FHM dSON function.
Note 2: The definition of DLPRBUsageforProtectedResource is similar to Sec. 4.5.1 in

TS 32.425 [11]. The counter is updated only when protected resources are used for
traffic by IM dSON function.
Note 3: Performance Counters with TS 32.453 reference are also defined in TS

32.425. For simplicity only TS 32.453 is given as reference for them in the table.
PMConfig.ack
With this message, the (H)eNB dSON acknowledges the updated performance counter
set of the previously received PMConfig.update message. The PMConfig.ack content
is given in Table 4-6.

PM_ACKed Indicates the accepted reporting period of a See Table 4-5
requested performance counter (same as
requested or larger if not possible to fulfil
finer granularity).
Note: absence of counter or special value ‘0
= zero’ could be used to indicate the counter
is not available.
Table 4-6 PMConfig.ack content
ERRORs for dSON PM configuration procedure

Errors that may be returned in PMConfig.ack are given in Table 4-7.

MSG_OK Successful configuration of performance
counters (no error)
ERR_PM_CONFIG_FAIL The PM Configuration request failed
ERR_PM_MISSED At least one requested counter cannot be
reported as requested
Table 4-7 PMConfig.ack errors

Version: 083.5.1 25
4.1.3 PM reporting messages
PMReport.notify
With this message, the (H)eNB dSON sends (a subset of) requested performance
counters according to their reporting periods to cSON server, along with timestamp of
collection (if counter is not available, empty results may be sent). The
PMReport.notify content is given in Table 4-8.

ECGI[n] Specifies reporting cells. Defined in TS
36.423 [9]
Time Time stamp of counter report, including
start time and end time of collection
NumHOIntraFreqAttempt Number of attempted outgoing LTE intra- Sec 4.2.4.2.1
frequency handovers counted during the in 32.453 [10]
requested reporting period. Includes
failures.
NumHOInterFreqAttempt Number of attempted outgoing LTE inter- Sec 4.2.4.2.1
failures.
NumHOIntraFreqSucc Number of successful outgoing LTE intra- Sec 4.2.4.2.2
requested reporting period.
NumHOInterFreqSucc Number of successful outgoing LTE inter- Sec 4.2.4.2.2
NumHOIntraFreqFailure Number of failed outbound intra LTE intra Sec 4.2.4.2.3
NumHOInterFreqFailure Number of failed outbound LTE inter- Sec 4.2.4.2.3
NumHOFromIntraFreqAtt Number of attempted incoming LTE intra- Sec 4.2.4.2.4
failures.
NumHOFromIntraFreqSucc Number of successful incoming LTE intra- Sec 4.2.4.2.5
NumHOFromFreqFailure Number of failed inbound intra LTE intra Sec 4.2.4.2.6
NumHOTooEarly Number of MRO Too Early HO failure cases Sec 4.3.5 in
counted during the requested reporting 32.522 [12]
period (ECGI) – MRO only.
NumHOTooLate Number of MRO Too late HO failure cases Sec 4.3.5 in
counted during the requested reporting 32.522 [12]
period (ECGI) – MRO only.
NumHOWrongCell Number of MRO HO failures to a wrong Sec 4.3.5 in
cell, wrong cell counted during the 32.522 [12]
requested reporting period (ECGI 1 instead
of ECGI 2) – MRO only.

Version: 083.5.1 26
NumHOPingPongClassify Number of handovers classified as ping -
pong handovers counted during the
NumFHMHOInterFreqAttempt Number of attempted FHM triggered See Note 1
outgoing LTE inter-frequency handovers below
counted during the requested reporting
period. Includes successful handovers plus
all identified failures – FHM only.
NumFHMHOInterFreqSucc Number of FHM triggered outgoing LTE See Note 1
inter-frequency handovers successful below
period – FHM only.
NumFHMHOInterFreqFailure Number of FHM triggered outgoing LTE See Note 1
inter-frequency handover failures counted below
during the requested reporting period –
FHM only.
AttemptedRRCConnEst This measurement provides the number of Sec. 4.2.2.1 in
RRC connection establishment attempts 32.453 [10]
for each establishment cause.
SuccRRCConnEst This measurement provides the number of Sec. 4.2.2.2 in
successful RRC establishments for each 32.453 [10]
establishment cause.
FailedRRCConnEst This measurement provides the number of Sec. 4.2.2.3 in
RRC establishment failures for each 32.453 [10]
rejection cause.
DL PRB Usage for traffic This measurement provides the usage (in Sec. 4.5.1 in
(PRBs) on the downlink for DTCH traffic
during the requested reporting period. The
measurement is split into sub-counters per
E-RAB QoS level (QCI).
UL PRB Usage for traffic This measurement provides the usage (in Sec. 4.5.2 in
(PRBs) on the uplink for DTCH traffic
during the requested reporting period.
DL Total PRB Usage This measurement provides the total Sec. 4.5.3 in
usage (in percentage) of physical resource 32.425 [11]
blocks (PRBs) on the downlink for any
purpose during the requested reporting
period.
UL Total PRB Usage This measurement provides the total Sec. 4.5.4 in
usage (in percentage) of physical resource 32.425 [11]
blocks (PRBs) on the uplink for any
purpose during the requested reporting
period.
Cell Unavailable Time This measurement provides the length of Sec. 4.5.6 in
time the cell has been unavailable for each 32.425 [11]
cause during the requested reporting
period. This measurement is obtained by
accumulating the time periods when the
cell is unavailable per cause. The possible
cause could be ‘manual intervention’,
‘fault’ and ‘energy saving’.
DL PRB full utilization This measurement provides the Sec. 4.5.9.1 in
percentage of time during which all 32.425 [11]
available PRBs for traffic on the downlink
have been assigned, during the requested

Version: 083.5.1 27
reporting period.
UL PRB full utilization This measurement provides the Sec. 4.5.9.2 in
percentage of time during which all 32.425
available PRBs for traffic on the uplink
have been assigned, during the requested
reporting period
Mean processor usage Mean usage of each key processor during Sec. 4.8.2 in
the requested reporting period. Each 32.425 [11]
equipment may have more than one key
processor, how to identify key processor is
vendor specific.
Peak processor usage Peak usage of each key processor during Sec. 4.8.1 in
the requested reporting period. Each 32.425 [11]
equipment may have more than one key
processor, how to identify key processor is
vendor specific.
RachPreambleDedMean Mean number of RACH preambles Sec. 4.5.5.1 in
received: 32.425 [11]
number of RACH preambles received in a
cell in one second. Separate counts are
provided for dedicated preambles,
preambles in group B (aka ‘high range’) –
RO only.
Mean number of RACH preambles Sec. 4.5.5.1 in
RachPreambleAMean received: 32.425 [11]
RO only.
Mean number of RACH preambles Sec. 4.5.5.1 in
RachPreambleBMean received: 32.425 [11]
RO only.
RachPreambleDist Distribution of RACH preambles sent : This Sec. 4.5.5.2 in
measurement provides the distribution of 32.425 [11]
number of RACH preambles sent by the UE
as reported by the UEs inside the
UEInformationResponse message – RO
only.
RachAccessDelayDist Distribution of RACH access delay : Sec. 4.5.5.3 in
This measurement provides the 32.425 [11]
distribution of number of the time before
UEs in a cell achieve a successful attach.
The RACH access delay is the time from

Version: 083.5.1 28
when a UE sends its first Random Access
Preamble until the UE receives the
Random Access Response – RO only.
RachContentionReported Percentage of contentious RACH attempts: Sec. 4.5.5.4 in
This measurement provides the 32.425 [11]
percentage of UEInformationResponse
messages received within the
measurement granularity interval with
contentionDetected IE set to TRUE – RO
only.
RachReportCount Number of UE RACH reports received: This Sec. 4.5.5.5 in
measurement provides the number of 32.425 [11]
UEInformationResponse messages
received within the measurement
granularity interval containing rachReport-
r9 IE – RO only.
RachDedicatedPreamblesAssign Percentage of time when all dedicated Sec. 4.5.5.6 in
ed RACH preambles are used: This 32.425 [11]
measurement provides the percentage of
time when all dedicated RACH preambles
are assigned to UEs – RO only.
DRB.PdcpSduBitrateDl.QCI Average DL cell PDCP SDU bit-rate Sec. 4.2.5.1
during the requested reporting period in 32.453 [10]
DRB.PdcpSduBitrateUl.QCI Average UL cell PDCP SDU bit‐rate Sec. 4.2.5.2
during the requested reporting period in 32.453
[10]
DRB.PdcpSduBitrateDlMax Maximum DL cell PDCP SDU bit‐rate Sec. 4.2.5.3
[10]
DRB.PdcpSduBitrateUlMax Maximum UL cell PDCP SDU bit-rate Sec. 4.2.5.4
[10]
DRB.PdcpSduDelayDl.QCI Average DL PDCP SDU delay during Sec. 4.2.6.1
the requested reporting period in 32.453
[10]
DRB.PdcpSduDropRateDl.QCI Average DL PDCP SDU drop rate during Sec. 4.2.6.2

the requested reporting period in 32.453
[10]
DRB.PdcpSduAirLossRateDl.QCI DL PDCP SDU air interface loss rate Sec. 4.2.7.1
during the requested reporting period in 32.453 [10]
DRB.PdcpSduLossRateUl.QCI UL PDCP SDU loss rate during the Sec. 4.2.7.2
requested reporting period in 32.453
[10]
UnknownIntraFrequencyPCI Number of unknown intra-frequency PCI -
period
The counter is updated upon report, from

a UE connected to the small cell, of an
intra-frequency detected PCI that is not
yet added to the NRT (e.g. because too
weak)
DL PRB Usage for protected This measurement provides the usage (in See Note 2
resources percentage) of protected physical resource below
blocks (PRBs) on the downlink for DTCH

Version: 083.5.1 29
traffic during the requested reporting
period, according to DL mask – IM only.
UL PRB Usage for protected This measurement provides the usage (in See Note 2
resources percentage) of protected physical resource below
blocks (PRBs) on the uplink for DTCH
traffic, according to UL mask – IM only.
ABS Usage This measurement provides the usage (in See Note 2
percentage) of ABS according to ABS below
pattern – IM only.
Table 4-8 PMReport.notify content
Note 1: The definitions for NumFHMHOInterFreqAttempt, NumFHMHOInterFreqSucc

and NumFHMHOInterFreqFailure are similar to Sec 4.2.4.2.1, Sec 4.2.4.2.2 and Sec
4.2.4.2.3 in 32.453 [10]. These counters are updated only when inter-frequency HOs
are triggered by FHM dSON function.
Note 2: The definition of DLPRBUsageforProtectedResource is similar to Sec. 4.5.1 in

TS 32.425 [11]. The counter is updated only when protected resources are used for
traffic by IM dSON function.
Note 3: Performance Counters with TS 32.453 reference are also defined in TS

32.425. For simplicity only TS 32.453 is given as reference for them in the table.
4.1.4 REM configuration messages
REMConfig.update
This message indicates parameters for REM measurements and related reporting from
dSON to cSON. This message includes ECGI[n] to identify the addressed cells for REM
reporting.
The REMConfig.update content is given in Table 4-9.

36.423 [9]
InServiceHandling FAP REM behavior with respect to ongoing TR-196 [7]
active connections. Enumeration of:
Immediate (Immediately perform REM,
even if have active connections or idle
camping UE that MAY be disrupted)
Delayed (Wait to initiate REM until no CS
bearers or PS bearers of streaming or
higher QoS class are assigned)
The factory default value MUST
be Immediate.
ScanOnBoot Enables or disables radio environment TR-196 [7]
measurement during the FAP start up.
ScanPeriodically Enable periodic radio environment TR-196 [7]
Measurement on LTE EUTRAN bands.
PeriodicTime An absolute time reference in UTC to TR-196 [7]
determine when the CPE will initiate the
periodic REM. Each REM MUST occur at (or
as soon as possible after) this reference
time plus or minus an integer multiple of
the PeriodicInterval.

Version: 083.5.1 30
PeriodicInterval When ScanPeriodically is true, this value TR-196 [7]
indicates the interval in seconds which REM
is performed while the FAP service is
enabled.
REMPLMNList Comma-separated list (maximum length TR-196 [7]
32) of strings. Each item is a PLMN ID to
measure. PLMN ID consists of Mobile
Country Code (MCC) and Mobile Network
Code (MNC) [TS 23.003 and 24.008]
REMBandList Comma-separated list of strings (maximum TR-196 [7]
length 64). Each item is a LTE Band to
measure. Corresponds to frequency band
indicator defined in [Table 5.5-1/3GPP-
TS.36.101].
EUTRACarrierARFCNDLList Comma-separated list (maximum length TR-196 [7]
64) of strings. Each entry is a EUTRA
ARFCN in the DL direction to measure.
Corresponds to the parameter NDL in
[Section 5.7.3/3GPP-TS.36.101].
ScanTimeout Specifies the time-out value in seconds, TR-196 [7]
measured from the start of the REM scan,
before the REM scan will time out.
ScanStatus Indicates the current status of this scan. TR-196 [7]
Enumeration of:
Indeterminate (The scan has not been
executed and there are no valid scan
results available)
InProgress,Success,Error,Error_TIMEOUT
ErrorDetails Provides more detail when TR-196 [7]
the ScanStatus is
either Error or Error_TIMEOUT.
LastScanTime The time of the last LTE system radio TR-196 [7]
environment measurement.
MaxCellEntries The maximum number of entries available TR-196 [7]
in the REM.LTE.Cell{i}.table.
CellNumberOfEntries The number of entries in the Cell table. TR-196 [7]
MaxCarrierMeasEntries The maximum number of entries available TR-196 [7]
in the REM.LTE.CarrierMeas{i}.table.
CarrierMeasNumberOfEntries The number of entries in TR-196 [7]
the CarrierMeas table.
Table 4-9 REMConfig.update content addressing REM measurements
REMConfig.ack
With this message, the (H)eNB dSON acknowledges the updated REM measurements
previously received REMConfig.update message. The REMConfig.ack content is given
in Table 4-10.

REM_ACKed ACK/NACK field indicates the general See Table 4-9Error!
REM reporting capability of the SC; Reference source not
The accepted reporting period, as found.
requested by REM configuration

Version: 083.5.1 31
parameter ScanPeriodically.
Table 4-10 REMConfig.ack content
ERRORs for dSON REM configuration procedure
Errors that may be returned in REMConfig.ack are given in Table 4-11.

counters (no error)
ERR_REM REM reporting not available at this
(H)eNB.
Table 4-11 REMConfig.ack errors
4.1.5 REM reporting messages
REMReport.notify
With this message, the (H)eNB dSON reports the requested REM measurement results
to cSON server (if measurement is not available, empty results may be sent). The
REMReport.notify content is given in Table 4-12.

ECGI[n] Specifies reporting cells. Defined in TS
36.423 [9]
EUTRACarrierARFCN Indicates the ARFCN of this carrier frequency. TR-196 [7] and TS
Corresponds to parameter dl-CarrierFreq in 32.592 [14]
SIB5 in [Section 6.3.1/3GPP-TS.36.331], and
parameter NDL in [Section 5.7.3/3GPP-
TS.36.101].
PhyCellID Physical cell ID of the detected EUTRAN cell, TR-196 [7] and TS
as specified in [Section 5.6/3GPP-TS.36.101]. 32.592 [14]
RSRP Received RSRP level of the detected EUTRA TR-196 [7] and TS
cell, specified in dBm, as specified in [Section 32.592 [14]
5.1.1/3GPP-TS.36.214]. The reporting range
is specified in [Section 9.1.4/3GPP-
TS.36.133].
RSRQ Received RSRQ level of the detected EUTRA TR-196 [7] and TS
cell, specified in dB, as specified in [Section 32.592 [14]
5.1.3/3GPP-TS.36.214]. Actual measured
values range between -24.0 dB and 0.0 dB in
steps of 0.5 dB. The value of RSRQ divided
by 10 yields the actual measured value. Only
values in multiple of 5 are valid.
RSSI E-UTRA carrier received signal strength TR-196 [7] and TS
indicator (RSSI), specified in dBm, as 32.592 [14]
specified in [Section 5.1.3/3GPP-TS.36.214].
It comprises the linear average of the total
received power (in [W]) observed only in
OFDM symbols containing reference symbols
for antenna port 0, in the measurement
bandwidth, over N number of resource blocks
by the UE from all sources, including co-
channel serving and non-serving cells,
adjacent channel interference, thermal noise

Version: 083.5.1 32
etc.
DLBandwidth Downlink transmission bandwidth, specified TR-196 [7] and TS
in number of resource blocks. Corresponds to 32.592 [14]
parameter dl_bandwidth in master
information block in [Section 6.2.2/3GPP-
TS.36.331] and to parameter NRB in [Table
5.6-1/3GPP-TS.36.101].
ULBandwidth Uplink transmission bandwidth, specified in TR-196 [7] and TS
number of resource blocks. Corresponds to 32.592 [14]
parameter ul_bandwidth in SIB2 in [Section
6.3.1/3GPP-TS.36.331] and to parameter
NRB in [Table 5.6-1/3GPP-TS.36.101].
RSTxPower The downlink reference-signal transmit TR-196 [7] and TS
power, specified in dBm. Defined as the 32.592 [14]
linear average over the power contributions
(in W) of all resource elements that carry
cell-specific reference signals within the
operating system bandwidth. Corresponds to
parameter referenceSignalPower in SIB4 as a
part of PDSCH-Config IE in [Section
6.3.2/3GPP-TS.36.331].
TAC Tracking area code that is common for all the TR-196 [7] and TS
PLMNs listed. Corresponds to 32.592 [14]
trackingAreaCode as specified in SIB1 in
[Section 6.2.2/3GPP-TS.36.331].
CellID Defines the cell identify, defines as a 28-bit TR-196 [7] and TS
binary number. Corresponds to cellIdentity as 32.592 [14]
specified in SIB1 in [Section 6.2.2 and
Section 6.3.4/3GPP-TS.36.331].
CellBarred Indicates whether the cell is barred or not. If TR-196 [7] and TS
true, the cell is barred. If false, the cell is not 32.592 [14]
barred. Corresponds to cellBarred as
specified in SIB1 in 3GPP-TS.36.331 Section
6.2.2 and 3GPP-TS.36.304.
CSGIndication Indicates whether CSG is used in this cell or TR-196 [7] and TS
not. If true, the UE is only allowed to access 32.592 [14]
the cell if the CSG identity matches an entry
in the allowed CSG list that the UE has
stored. Corresponds to csg-Indication as
specified in SIB1 in [Section 6.2.2/3GPP-
TS.36.331].
CSGIdentity Defines the CSG ID value TR-196 [7] and TS
if CSGIndication parameter indicates that 32.592 [14]
CSG is used in this cell. Corresponds to csg-
Identity as specified in SIB1 in [Section
6.2.2/3GPP-TS.36.331].
PLMNIdentityList Comma-separated list of strings. Each TR-196 [7] and TS
item is a PLMN ID. Corresponds to plmn- 32.592 [14]
IdentityList as specified in SIB1 in 3GPP-
TS.36.331 Section 6.2.2. In case there is
more than one entry in the list, the first
listed PLMN-Identity is the primary
PLMN.
CarrierARFCNDL Lower bound of the EUTRA ARFCN as TR-196 [7] and TS
specified in [Section 5.7.3/3GPP- 32.592 [14]
TS.36.101] in the DL direction that is

Version: 083.5.1 33
requested to measure. Unit in MHz.
CarrierChWidth Number of ARFCN in DL direction, as TR-196 [7] and TS
specified in [Section 5.6/3GPP- 32.592 [14]
TS.36.101], that is requested to
measure. The range bounded by
CarrierARFCNDL as the lower bound and
the value of (CarrierARFCNDL +
CarrierChWidth) as the upper bound
expresses the total carrier frequency
range to be measured.
CarrierRSSI Received Signal Strength Indicator TR-196 [7] and TS
(RSSI) as specified in [Sec 5.1.3/3GPP- 32.592 [14]
TS.36.214] over the carrier frequency
range from CarrierARFCNDL as the lower
bound and the value of (CarrierARFCNDL
+ CarrierChWidth) as the upper bound.
Table 4-12 REMReport.notify content
4.1.6 Event configuration messages
EventConfig.update
This message indicates an updated set of events to be notified, if available, from dSON
to cSON. This message includes ECGI[n] to identify the addressed cells for event
notification reporting.
The EventConfig.update content is given in Table 4-13.
Note: Events which are specific to certain SON function (e.g., PCI only) shall not be
assumed to be available in case that SON function is not implemented or is disabled.

36.423 [9]
PCICollision This event notification is triggered when
the dSON PCI function detect collision –
PCI only.
PCIConfusionFromNeighbor This event notification is triggered when
the dSON PCI function detect confusion
inflicted from neighbors (cell is victim of
the confusion) – PCI only.
PCIConfusionOntoNeighbor This event notification is triggered when
the dSON PCI function detect confusion
inflicted onto neighbors (cell is cause of
the confusion) – PCI only.
PCINoSelection This event notification is triggered when
the dSON PCI function cannot make
any PCI selection from the given list of
PCIs due to e.g. detected conflicts –
PCI only.
Table 4-13 EventConfig.update content

Version: 083.5.1 34
EventConfig.ack
With this message, the (H)eNB dSON acknowledges the updated set of events of the
previously received EventConfig.update message. The EventConfig.ack content is
given in Table 4-14.

EN_ACKed Indicates the accepted reporting of See Table 4-13
requested events notification.
Note: absence of event ACK or special value
‘0 = zero’ could be used to indicate the
event is not available.
Table 4-14 EventConfig.ack content
ERRORs for dSON event configuration procedure

Errors that may be returned in EventConfig.ack are given in Table 4-15.

counters (no error)
ERR_INVALID_ECGI One or more ECGI values requested are not
present in the receiving (H)eNB
ERR_EN_CONFIG_FAIL The EN Configuration request failed
ERR_EN_MISSED At least one requested events cannot be
configured and notified as requested
Table 4-15 EventConfig.ack errors
4.1.7 Event notification messages
EventReport.notify
With this message, the (H)eNB dSON notifies the triggering of a (subset of) events of
requested notifications, along with timestamp of collection (if event is not available,
empty results may be sent). The EventReport.notify content is given in Table 4-16.

ECGI Specifies reporting cell. Defined in TS
36.423 [9]
Time Time stamp of the event
PCICollision Notifies a PCI collision is detected, when
known, includes ECGI of conflicting cell – PCI
only.
PCIConfusionFromNeighb Notifies a PCI function confusion inflicted
or from neighbors is detected (cell is victim of
the confusion) detected, when known,
includes ECGI of conflicting cells – PCI only.
PCIConfusionOntoNeighb Notifies a PCI function confusion inflicted onto
or neighbors is detected (cell is cause of the
confusion), when known, includes ECGI of
conflicting cell – PCI only.
PCINoSelection Notifies no PCI selection can be made from
the given list of PCIs (due to e.g. detected
conflicts) – PCI only.
Table 4-16 EventReport.notify errors

Version: 083.5.1 35
4.2 Content of function specific procedure messages
4.2.1 dSON activation messages
dSONActivate.request
This message is sent from cSON to dSON and it is applicable when the targeted SON
function is in any state. This message includes ECGI[n] to identify the addressed cells.

SON Function Indicates the SON Function to be See Identifiers in Table 4-3
activated.
Table 4-17 dSONActivate.request content
Note: In sec. 5.5.1 of TS 32.522 [12] enable/disable attributes are defined for MRO,
MLB, ES, RO and TPM SON functions. This procedure set the corresponding attribute to
‘ON’.
dSONActivate.ack
This message is sent from dSON to cSON to confirm activation of a SON function. The
dSONActivate.ack content is provided in Table 4-18.

SON Function Indicates the SON Function activated. See Identifiers in Table 4-3
Status Status of the dSON algorithm after activation See Figure 3-8
request (Inactive, Active)
Table 4-18 dSONActivate.ack content
ERRORs for dSON activation procedure

Errors that may be returned in dSONActivate.ack are given in Table 4-19.

MSG_OK Successful activation (no error)
ERR_ INVALID_ECGI One or more ECGI values requested are
ERR_ACTIVATE_FAIL The requested dSON algorithm activation
failed
Table 4-19 dSONActivate.ack errors
4.2.2 dSON deactivation messages
dSONDeactivate.request
This message is sent from cSON to dSON and it is applicable when the addressed SON
function is in any state. This message includes ECGI[n] to identify the addressed cells.

deactivated.
Table 4-20 dSONDeactivate.request content

Version: 083.5.1 36
Note: In sec. 5.5.1 of TS 32.522 [12] enable/disable attributes are defined for MRO,
MLB, ES, RO and TPM SON functions. This procedure set the corresponding attribute to
‘OFF’.
dSONDeactivate.ack
This message is sent from dSON to cSON to confirm SON function deactivation. The
dSONDeactivate.ack content is provided in Table 4-21.

deactivated.
Status Status of the dSON algorithm after See Figure 3-8
deactivation request (Inactive, Active)
Table 4-21 dSONDeactivate.ack content
ERRORs for dSON deactivation procedure

Errors that may be returned in dSONDeactivate.ack are given in Table 4-22.

MSG_OK Successful deactivation (no error)
ERR_DEACTIVATE_FAIL The requested dSON algorithm
deactivation failed
Table 4-22 dSONDeactivate.ack errors
4.2.3 dSON configuration messages
dSONConfig.update
This message is sent from cSON to dSON and it is applicable when the addressed SON
function is in any state and contains the information for dSON configuration. This
message includes ECGI[n] to identify the addressed cells.

configured.
Configuration SON function configuration parameter MRO: Table 4-24
list and corresponding actual values FHM: Table 4-27
RO: Table 4-28
CHS: Table 4-29
TPM: Table 4-30
ES: Table 4-31
BHM: Table 4-32
PCI: Table 4-33
ANR: Table 4-34
MLB: Table 4-35
IM: Table 4-36
Table 4-23 dSONConfig.update content
The MRO Configuration parameter list is provided in Table 4-24.

Version: 083.5.1 37
MROIntraFreqEnable Enable/disable MRO for intra- -
frequency HO optimization
MROInterFreqEnable Enable/disable MRO for inter- -
frequency HO optimization
HOFailureRate Handover optimization target: Sec 4.3.1 in 32.522 [12]
Number of failure events related to
handover divided by the total
number of handover events.
The target is met if the actual rate is
smaller than the target value.
Mobility Connected Mobility parameter values for See Table 4-25

connected mode
Mobility Idle Mobility parameter values for idle See Table 4-26
mode
Table 4-24 MRO Configuration parameters
The MRO mobility parameters for connected mode are listed in Table 4-25.

CIO Used for evaluating triggering See TS 32.592 [14]
conditions for measurement and TR-196 [7]
reporting in connected mode.
See Note below.
A1ThresholdRSRP Corresponds to parameter a1- See TS 32.592 [14]

Threshold for UE measurement and TR-196 [7]
reporting, based on RSRP. See Note below.
A1ThresholdRSRQ Corresponds to parameter a1- See TS 32.592 [14]
reporting, based on RSRQ. See Note below.
A3-Offset Corresponds to parameter a3- See TS 32.592 [14]
Offset specified for UE and TR-196 [7]
measurement reporting.
cSON may provide one or more
values and/or range of values for
the small cell dSON to choose from.
A5Threshold1RSRP Corresponds to parameter a5- See TS 32.592 [14]
Threshold1 for UE measurement and TR-196 [7]
A5Threshold1RSRQ Corresponds to parameter a5- See TS 32.592 [14]

Version: 083.5.1 38
A5Threshold2RSRP Corresponds to parameter a5- See TS 32.592 [14]
A5Threshold2RSRQ Corresponds to parameter a5- See TS 32.592 [14]
A6-Offset Corresponds to parameter a6- -
Offset specified for UE
Hysteresis Corresponds to parameter See TS 32.592 [14]
hysteresis for UE measurement and TR-196 [7]
reporting.
TimeToTrigger Corresponds to parameter See TS 32.592 [14]
timeToTrigger for UE and TR-196 [7]
values and/or range of values
for the small cell dSON to
choose from.
FilterCoefficientRSRP Corresponds to See TS 32.592 [14]
filterCoefficientRSRP parameter for and TR-196 [7]
UE measurement reporting.
FilterCoefficientRSRQ Corresponds to See TS 32.592 [14]
filterCoefficientRSRQ parameter for and TR-196 [7]
UE measurement reporting.
Blacklisted See ANR Parameter in Table 4-34 See TS 32.592 [14]
and TR-196 [7]
Table 4-25 MRO Mobility Parameters for Connected Mode
Note: Current TR-196 [7] specifies this parameter as a single value. It shall also be
extended to provide one or more values (or a range of values) for the small cell dSON
to choose from.
The MRO mobility parameters for idle mode are listed in Table 4-26.

Version: 083.5.1 39
Qhyst Hysteresis value applied to serving See TS 32.592 [14]
cell for evaluating cell ranking and TR-196 [7]
criteria.
Qoffset Cell-specific offset applicable to a See TS 32.592 [14]
specific neighboring cell and used and TR-196 [7]
for cell reselection evaluation.
cSON may provide one or more Note: TR-196 specifies
values and/or range of values for Qoffset as a single
the small cell dSON to choose from. value – it shall be
extended to a range
Table 4-26 MRO mobility parameters for idle mode
The FHM configuration parameter list is provided in Table 4-27.

FHMMitigationLevel Level of mitigation (low, medium,
high) that FHM shall apply when
mitigating ping pong HOs and short
stay HOs.
Note: How the indicated level is
translated into mitigation actions is
left to dSON implementation.
FHMInterFreqHOEnable Enabling FHM-initiated inter-

frequency handover to a cell
connected mode
Table 4-27 FHM configuration parameters
The fields of the RO configuration parameter list is provided in Table 4-28.
Note – As per TS 36.522 [12] section 4.6, For RACH optimization, one of the following
targets shall be used:
• Access probability, AP
• Access delay probability, ADP

Access probability, AP Performance target: The probability that the Section 4.6. and
UE has access after a certain random access 5.5.1 of TS
attempt number. 32.522 [12]
The target is met if the actual access
probability is higher than the target
probability value.
Access delay probability, Performance target: The probability Section 4.6 and
ADP distribution of access delay expected to be 5.5.1 of 3GPP TS
experienced by UEs accessing the RACH 32.522 [12]
channel.
The target is met if the actual access
probability is higher than the target
probability value.
NumberOfRaPreambles Number of non-dedicated random access See TS 32.592

Version: 083.5.1 40
preambles. Corresponds to parameter [14] and TR-196
numberOfRA-Preambles specified in 3GPP TS [7]
36.331. cSON may provide one or more
values and/or range of values for the Small
Cell dSONto choose from.
SizeOfRaGroupA Number of non-dedicated random access See TS 32.592
preambles in Random Access Preambles [14] and TR-196
group A. Corresponds to parameter sizeOfRA- [7]
PreamblesGroupA specified in 3GPP TS
messageSizeGroupA Threshold for preamble selection in 3GPP TS See TS 32.592
36.321.Corresponds to parameter [14] and TR-196
messageSizeGroupA specified in 3GPP TS [7]
messagePowerOffsetGroup Threshold for preamble selection in 3GPP TS See TS 32.592
B 36.321.Corresponds to parameter [14] and TR-196
messagePowerOffsetGroupB specified in 3GPP [7]
TS 36.331. cSON may provide one or more
Cell dSON to choose from.
powerRampingStep Power increase factor between subsequent See TS 32.592
random access preamble transmissions. [14] and TR-196
Value in dB. Corresponds to parameter [7]
powerRampingStep specified in 3GPP TS
values and/or range of values for the
SmallCell to choose from. cSON may provide
one or more values and/or range of values for
the Small Cell dSON to choose from.
preambleInitialReceivedTar This parameter denotes the baseline for See TS 32.592
getPower computation of the transmit power for [14] and TR-196
random access power transmission. [7]
Corresponds to parameter
preambleInitialReceivedTargetPower specified
in 3GPP TS 36.331. cSON may provide one or
more values and/or range of values for the
Small Cell dSON to choose from.
PreambleTransMax Maximum number of random access See TS 32.592
preamble transmissions. Corresponds to [14] and TR-196
parameter preambleTransMax specified in [7]
3GPP TS 36.331. cSON may provide one or
ResponseWindowSize Denotes the duration of the random access See TS 32.592
response window. Corresponds to parameter [14] and TR-196
ra-ResponseWindowSize specified in 3GPP TS [7]
ContentionResolutionTimer Contention resolution timer. Corresponds to See TS 32.592
parameter mac-ContentionResolutionTimer [14] and TR-196
specified in 3GPP TS 36.331. cSON may [7]
provide one or more values and/or range of
values for the Small Cell dSON to choose

Version: 083.5.1 41
from.
maxHARQ-Msg3Tx Maximum number of Msg3 HARQ See TS 32.592
transmissions by RRC. Corresponds to [14] and TR-196
parameter maxHARQ-Msg3Tx specified in [7]
3GPP TS 36.331. cSON may provide one or
Backoff Parameter Refer to TS 36.321.Smallcell/eNB includes it -
in Random Access Response for the UEs
whose RACH attempt is not successful .This
can be used to reduce the RACH collision
probability and hence increase RACH access
probability. However this may also lead to
increase in the RACH access delay for the UEs
whose RACH was not successful in first
attempt. cSON shall provide one or more
rootSequenceIndex Logical root sequence index used to See TS 32.592
determine 64 physical RACH preamble [14] and TR-196
sequences available in the cell. Corresponds [7]
to RACH_ROOT_SEQUENCE parameter
defined in 3GPP TS 36.331. cSON may
from.
ConfigurationIndex Provides index into the table defining PRACH See TS 32.592
resources within the frame. Corresponds to [14] and TR-196
PRACH-Configuration-Index parameter [7]
defined in 3GPP TS 36.331. cSON may
from.
highSpeedFlag Determines whether unrestricted set (FALSE) See TS 32.592
or restricted set (TRUE) of preambles is used. [14] and TR-196
Corresponds to highSpeedFlag parameter [7]
defined in 3GPP TS 36.331.
zeroCorrelationZoneConfig This parameter is used for preamble See TS 32.592
sequence generation. Corresponds to [14] and TR-196
parameter zeroCorrelationZoneConfig [7]
parameter defined in 3GPP TS 36.331. cSON
may provide one or more values and/or range
of values for the Small Cell dSON to choose
from.
FrequencyOffset The first physical resource block available for See TS 32.592
PRACH expressed as a physical resource [14] and TR-196
block number. Corresponds to prach- [7]
FreqOffset parameter defined in 3GPP TS
Table 4-28 RO Configuration parameters

Version: 083.5.1 42
The CHS configuration parameter list is provided in Table 4-29.

OverheadCapacityBalance A real-valued number, 0…1. -
Indicates how the CHS algorithm should
balance between capacity gains and inter-
frequency signalling and measurements
overhead reduction.
Value 0 means target is capacity gain only
Value 1 means target is overhead reduction
only
MacroPCI List of PCIs that belong to the macro layer. -
EARFCNDLToProtect Indicates the [left adjacent channel, RAT] -
and/or [right adjacent channel, RAT] to be
considered by TPM and CHS for adjacent
channel protection, if licensed to a different
operator [3GPP 36.104 sec. 6.2.3].
The following parameters reflect the list of candidate channels.
Comma-separated list of unsigned integers See TS 32.592
(value 0 to 65535). Each item is an E-UTRA [14] and TR-
Absolute Radio Frequency Channel Number in 196 [7]
the downlink direction. In case there is more
EARFCNDL
than one item in the list, the first item contains
the most preferred value. Corresponds to
parameter NDL specified in [Table
5.7.3.1/3GPP-TS.36.104]
(value 0 to 65535). Each item is an E-UTRA [14] and TR-
Absolute Radio Frequency Channel Number in 196 [7]
the uplink direction. In case there is more than
EARFCNUL
one item in the list, the first item contains the
most preferred value. Corresponds to
parameter NUL specified in [Table
5.7.3.1/3GPP-TS.36.104].
(value 6, 15, 25, 50, 75, or 100). Each item is a [14] and TR-
downlink transmission bandwidth, specified in 196 [7]
number of Resource Blocks. In case there is
more than one item in the list, the first item
DLBandwidth
contains the most preferred value. Corresponds
to parameter dl_Bandwidth in MIB (Master
Information Block) in [Section 6.2.2/3GPP-
TS.36.331] and to parameter NRB [Table 5.6-
1/3GPP-TS.36.101].
Comma-separated list (maximum length 32) (at See TS 32.592
least 1 items) of unsigned integers (value 6, 15, [14] and TR-
25, 50, 75, or 100). Each item is an uplink 196 [7]
transmission bandwidth, specified in number of
Resource Blocks. In case there is more than one
ULBandwidth
item in the list, the first item contains the most
preferred value. Corresponds to parameter
ul_Bandwidth in SIB2 [Section 6.3.1/3GPP-
TS.36.331] and to parameter NRB in [Table
5.6-1/3GPP-TS.36.101].
The following parameters reflect Neighbor Cell Information. Multiple sets of these parameters
can be provided by cSON to dSON for CHS configuration.
PLMN ID consists of Mobile Country Code (MCC) See TS 32.592
PLMNID
and Mobile Network Code (MNC). Mobile [14] and TR-

Version: 083.5.1 43
Country Code consists of three digits and 196 [7]
uniquely identifies the country of domicile of the
subscriber. Mobile Network Code consists of two
or three digits and identifies the Home PLMN
within a country.
Cell identity. Combination of PLMNID and CID See TS 32.592
CID constitutes the cell global ID (CGI). See [14] and TR-
[Section 6.3.4/3GPP-TS.36.331] 196 [7]
Indicates the ARFCN of this carrier frequency. See TS 32.592
Corresponds to parameter dl-CarrierFreq in [14] and TR-
SIB5 in [Section 6.3.1/3GPP-TS.36.331] and 196 [7]
parameter NDL in [Section 5.7.3/3GPP-
EUTRACarrierARFCN TS.36.101]. If the value of EUTRACarrierARFCN
is the same with the one currently being used
by the, then it implies that this neighbor cell is
an intra-frequency cell; otherwise, it is an inter-
frequency cell.
See TS 32.592
Physical cell ID – see [Section 6.11/3GPP-
PhyCellID [14] and TR-
TS.36.211]
196 [7]
ReferenceSignalPower The downlink reference-signal transmit power is See TS 32.592
defined as the linear average over the power [14] and TR-
contributions (in W) of all resource elements 196 [7]
that carry cell specific reference signals within
the operating system bandwidth. Value is in
dBm.
Table 4-29 CHS configuration parameters
The TPM configuration parameter list is provided in Table 4-30.

PollutionMitigationLevel Level of mitigation (low, medium, -
high) that TPM shall apply when
mitigating pilot pollution situations.
Note: How the indicated level is
translated into mitigation actions is
left to dSON implementation.
EARFCNDLToProtect Indicates the [left adjacent channel, -

RAT] and/or [right adjacent channel,
RAT] to be considered by TPM for
adjacent channel protection, if
licensed to a different operator. (see
3GPP 36.104 sec. 6.2.3)
ReferenceSignalPower The downlink reference-signal See TS 32.592 [14] and TR-
transmit power is defined as the 196 [7]
linear average over the power
contributions (in W) of all resource
elements that carry cell specific
reference signals within the
operating system bandwidth. Value
is in dBm. Corresponds to parameter
referenceSignalPower in PDSCH-
Config IE in [Section 6.3.2/3GPP-
TS.36.331].
PSCHPowerOffset Power offset of the primary See TS 32.592 [14] and TR-
synchronization channel with respect 196 [7]

Version: 083.5.1 44
to the ReferenceSignalPower.
SSCHPowerOffset Power offset of the secondary See TS 32.592 [14] and TR-
SynchronizationChannel with respect 196 [7]
PBCHPowerOffset Power offset of the physical See TS 32.592 [14] and TR-
broadcast channel with respect to 196 [7]
the ReferenceSignalPower.
Table 4-30 TPM configuration parameters
The ES configuration parameter list is provided in Table 4-31.

ESState Specifies the status regarding the energy saving 3GPP TS 32.592 [14]
in the cell. This parameter is applicable when and TR-196 [7]
esEnable is True. If ES is disabled, this allows
the cSON to control the current ES state.
ESRelatedCells List of (E)CGIs of related cells which can provide -
coverage if this cell is in ES state (NOTE: this
should be implemented as a boolean on each cell
in the Neighbor Relation Table)
esActivationCellOrigin This attribute indicates the traffic load threshold 3GPP TS 32.592 [14]
alLoadParameters and the time duration, which are used by and TR-196 [7]
distributed ES algorithms to allow a cell to enter
the energySaving state. The time duration
indicates how long the load needs to have been
below the threshold.
esActivationCandidate This attributes is relevant if the cell acts as 3GPP TS 32.592 [14]
CellsLoadParameters a candidate cell. and TR-196 [7]
This attribute indicates the traffic load
threshold and the time duration, which are
used by distributed ES algorithms to allow
an ‘original’ cell to enter the energySaving
state. Threshold and duration are applied to
the candidate cell(s) which provide
coverage backup of an original cell when it
is in the energySaving state. The threshold
applies in the same way for a candidate cell
no matter which original cell it will provide
backup coverage.
The time duration indicates how long the traffic
in the candidate cell needs to have been below
the threshold before any original cells which will
be provided backup coverage by the candidate
cell enters energy saving state.
esDeactivationCandid This attributes is relevant, if the cell acts as a 3GPP TS 32.592 [14]
ateCellsLoadParamete candidate cell. and TR-196 [7]
rs This attribute indicates the traffic load threshold
and the time duration which is used by
distributed ES algorithms to allow a cell to leave
the energySaving state. Threshold and time
duration are applied to the candidate cell when it
provides coverage backup for the cell in
energySaving state. The threshold applies in the
same way for a candidate cell, no matter for
which original cell it provides backup coverage.

Version: 083.5.1 45
The time duration indicates how long the traffic
in the candidate cell needs to have been above
the threshold to wake up one or more original
cells which have been provided backup coverage
by the candidate cell.
esNotAllowedTimePeri This attribute can be used to prevent a cell 3GPP TS 32.592 [14]
od entering energySaving state. and TR-196 [7]
This attribute indicates a list of time periods
during which energy saving is not allowed.
Time period is valid on the specified day and

time of every week.
Table 4-31 ES configuration parameters
The BHM configuration parameter list is provided in Table 4-32.

InServiceHandling FAP BHM measurement start behaviour. -
Enumeration of:
• ‘Immediate’ (immediately perform BHM,
even if active connection MAY be
affected)
• ‘Delayed’ (wait to initiate BHM until no
CS bearers or PS bearers of streaming
or higher QoS class are assigned)
• ‘Autonomous’ small cell (H)eNB
determined delay (ignore PeriodicTime)
MeasureOnBoot Enables or disables BHM during the FAP start -

up.
MeasurePeriodically Enabled periodic BHM. If false, measurement -
is only performed once.
PeriodicInterval When MeasurePeriodically is TRUE, this value -
indicates the interval in seconds when BM is
performed
PeriodicTime An absolute time reference in UTC to -
determine when the CPE will initiate the
periodic BM. Each BM must occur at (or as
soon as possible after) this reference time
plus or minus an integer multiple of the
PeriodicInterval.
MeasurementTimeout Specifies the time-out value in seconds, -
measured from the start of the BM
measurement, before the BM measurement
will time out
MeasurementDirection Specifies backhaul monitoring on UL or DL or -
UL/DL. Enumeration of
{UL, DL, ULDL}
Table 4-32 BHM configuration parameters

Version: 083.5.1 46
The PCI optimization configuration parameter list is provided in Table 4-33.

Comma separated list of physical cell See TS 32.592 [14] and
PhyCellID
identity items. TR-196 [7]
Table 4-33 PCI optimization configuration parameters
The ANR configuration parameter list is provided in Table 4-34.

Id Neighbor cell relation index 3GPP TS 32.762
[13]
isRemoveAllowed If set to false dSON is not allowed to 3GPP TS 32.762
exclude this neighbor cell from the NRT [13]
Indicates whether the neighbor cell 3GPP TS 32.762
isHoAllowed shall be used by the (H)eNB for [13]
handover reasons
This indicates if ICIC (inter cell 3GPP TS 32.762
interference coordination) load [13]
information message (see TS 36.423
isICICInformationSendAllowed
[24] Section 9.1.2.1 LOAD IM only
INFORMATION) sending is allowed or
prohibited.
The source cell is prohibited from 3GPP TS 32.762
sending X2 connection request to [13]
target node; forced to tear down
X2BlackList established X2 connection to target
node; not allowed to accept incoming
X2 connection request from target
node.
The source cell is allowed to request 3GPP TS 32.762
the establishment of X2 connection [13]
X2WhiteList with the target node; is not allowed to
initiate the tear down of established X2
connection to target node.
The source cell is prohibited to use X2 3GPP TS 32.762
X2HOBlackList interface for HOs with this NR even if [13]
the X2 interface exists.
This threshold used by the (H)eNB 3GPP TS 32.762
dSON Neighbor List Management [13]
NeighborSelectionThreshold function to determine whether a
detected target cell shall be added to
the NRT
Enable Enables or disables this entry in the BBF TR-196 [7]
NRT.
Alias A non-volatile handle used to reference BBF TR-196 [7]
this instance. Alias provides a
mechanism for an ACS to label this
instance for future reference.
MustInclude Indicates whether this instance of the BBF TR-196 [7]
neighbor shall be included or excluded
in the FAP's neighbor list configuration.
PLMN ID consists of mobile country TS 32.592 [14]
code (MCC) and mobile network code and TR-196 [7]
PLMNID (MNC) - 3GPP-TS.23.003, 3GPP-
TS.24.008. Mobile country code
consists of three digits and uniquely

Version: 083.5.1 47
identifies the country of domicile of the
subscriber. Mobile network code
consists of two or three digits and
identifies the Home PLMN within a
country.
Cell identity. Combination of PLMNID TS 32.592 [14]
CID and CID constitutes the Cell Global ID and TR-196 [7]
(CGI) [Section 6.3.4/3GPP-TS.36.331].
Indicates the ARFCN of this carrier TS 32.592 [14]
frequency. Corresponds to parameter and TR-196 [7]
dl-CarrierFreq in SIB5 in [Section
6.3.1/3GPP-TS.36.331] and parameter
NDL in [Section 5.7.3/3GPP-
EUTRACarrierARFCN TS.36.101]. If the value of
EUTRACarrierARFCN is the same with
the one currently being used by the
served cell, then it implies that this
neighbor cell is an intra-frequency cell;
otherwise, it is an inter-frequency cell.
Physical cell ID - [Section 6.11/3GPP- TS 32.592 [14]
PhyCellID
TS.36.211] and TR-196 [7]
QOffset Indicate a cell-specific offset applicable TS 32.592 [14]
to a specific neighboring cell. It is used and TR-196 [7]
for evaluating the cell as a candidate
for cell re-selection in idle mode.
Corresponds to parameter q-OffsetCell
broadcast in SIB4 for intra-frequency
cells and in SIB5 for inter-frequency
cells, specified in [Section 6.3.1/3GPP-
TS.36.331].
CIO Cell individual offset applicable to a TS 32.592 [14]
specific neighboring cell. It is used for and TR-196 [7]
evaluating triggering conditions for
measurement reporting in connected
mode. Specified by cellIndividualOffset
in MeasObjectEUTRA IE in [Section
6.3.5/3GPP-TS.36.331].
Blacklisted Indicates whether this neighbor cell is TS 32.592 [14]
allowed for UEs as handover target or and TR-196 [7]
not. If true, handover is prohibited
towards this cell. If false, handover is
allowed toward this cell. The
Blacklisted parameter allows this cell to
be prohibited as a handover target,
while still allowing this cell to be
included in the BCCH SIB4 or 5.
Table 4-34 ANR configuration parameters

Version: 083.5.1 48
The MLB configuration parameter list is provided in Table 4-35.

MLBIntraFreqEnable Enable/disable MLB for intra- -
frequency load balancing
MLBInterFreqEnable Enable/disable MLB for inter- -
frequency load balancing
connected mode
Mobility Idle Mobility parameter values for idle See Table 4-26
mode
Table 4-35 MLB configuration parameters
The IM configuration parameters list is provided in Table 4-36

IMFreqEnable Enable/disable IM algorithms using frequency -
domain partitioning (ICIC)
IMTimeEnable Enable/disable IM algorithms using time domain -
partitioning (eICIC)
IMFairnessLevel This indicates the level of fairness (low, -
medium, high) IM shall apply across users.
How the indicated level is translated into
fairness actions is left to dSON implementation.
IMFreqHardFFR Indicates if Hard Fractional Frequency Reuse -
technique is used (TRUE) or not (FALSE) for
frequency domain partition
IMDLProtectedPRB List of masks for protected PRB in DL the dSON -
can choose from. Each item is a RNTP vector (bit
string) whose values indicates whether a
promise to protect a DL PRB is given or not
given [See TS 36.423 [9], section 9.2.19].
IMULProtectedPRB List of masks for protected PRB in UL the dSON -
can chose from. Each item is a vector (bit string)
whose values indicates whether a promise to
protect an UL PRB is given or not given.
IMABSInformation List of patterns for protected resources in the -
time domain the dSON can choose from. Each
item is an ABS Pattern vector (bit string) whose
values indicates which sub-frames are almost
blank subframes and which not [See TS 36.423
[9], section 9.2.54].
IMCreBias Parameter used for increase or decrease the -
(H)eNB cell range expansion – equivalent to CIO
[See TS 32.592 [14] and TR-196 [7]] for that
neighbor to be applied for time domain
partitioning UEs
p-b Equal to Eb/Ea. Is same for all UEs in the cell. See TS 32.592 [14]
Eb = EPRE (energy per resource element) of and TR-196 [7]
PDSCH REs type B i.e. REs in OFDM symbols
that include reference symbols.
cSON may provide one or more values and/or

range of values for the small cell dSON to
choose from.
p-a Equal to Ea/Ers. Ea = EPRE (energy per resource See TS 32.592 [14]
element) of PDSCH REs (resource elements)

Version: 083.5.1 49
type A i.e. REs in OFDM symbols that do not and TR-196 [7]
include reference symbols.

choose from.
p-a-High Value of p-a for high-power PRBs in DL in Soft- -
FFR. The parameter is meaningful when the
IMFreqHardFFR is set to FALSE.

choose from.
Table 4-36 IM configuration parameters
dSONConfig.ack
This message is sent from dSON to cSON to confirm dSON Configuration update, and
it is applicable in any state. The dSONConfig.ack content is provided in Table 4-37.

Status Status of the dSON algorithm after See Figure 3-8
configuration (Inactive, Active)
Table 4-37 dSONConfig.ack content
ERRORs for dSON configuration procedure

Errors that may be returned in dSONConfig.ack are given in Table 4-38.

MSG_OK Successful update of configuration (no
error)
ERR_INVALID_CONFIG The received configuration for the dSON
algorithm is invalid
Table 4-38 dSONConfig.ack errors
4.2.4 dSON parameter change notification messages
dSONParameter.notify
This message is sent from dSON to cSON and it is sent when the SON function is in
‘Active’ state. If received when the SON function is in ‘Inactive’ state, a
MSG_INVALID_STATE error is returned in the dSONParameter.ack message This
message includes ECGI[n] to identify the source cells.

ECGI[n] Specifies source cells. Defined in TS 36.423 [9]
SON Function Indicates the SON Function that See Identifiers in Table 4-3
changes parameter(s)
SON Function New parameter values for the SON MRO: Table 4-24
Parameter set function RO: Table 4-28
CHS: Table 4-40

Version: 083.5.1 50
TPM: Table 4-41
ES: Table 4-42
BHM: Table 4-43
PCI: Table 4-44
ANR: Table 4-45
MLB: Table 4-35
IM: Table 4-46
Table 4-39 dSONParameter.notify content

E-UTRA absolute radio frequency channel See TS 32.592
number in the downlink direction. Corresponds [14] and TR-
EARFCNDL
to parameter NDL specified in [Table 196 [7]
5.7.3.1/3GPP-TS.36.104]
E-UTRA absolute radio frequency channel See TS 32.592
number in the uplink direction. Corresponds to [14] and TR-
EARFCNUL
parameter NUL specified in [Table 196 [7]
5.7.3.1/3GPP-TS.36.104].
Downlink transmission bandwidth, specified in See TS 32.592
number of resource blocks. Corresponds to [14] and TR-
parameter dl_bandwidth in MIB (master 196 [7]
DLBandwidth
information block) in [Section 6.2.2/3GPP-
TS.36.331] and to parameter NRB [Table 5.6-
1/3GPP-TS.36.101].
Uplink transmission bandwidth, specified in See TS 32.592
number of resource blocks. Corresponds to [14] and TR-
ULBandwidth parameter ul_bandwidth in SIB2 [Section 196 [7]
6.3.1/3GPP-TS.36.331] and to parameter NRB
in [Table 5.6-1/3GPP-TS.36.101].
Table 4-40 CHSParameter.notify content

ReferenceSignalPower Downlink reference-signal transmit See TS 32.592 [14] and TR-
power. Value is in dBm 196 [7]
PSCHPowerOffset Power offset of the primary See TS 32.592 [14] and TR-
synchronization channel with respect 196 [7]
SSCHPowerOffset Power offset of the Secondary See TS 32.592 [14] and TR-
SynchronizationChannel with respect 196 [7]
PBCHPowerOffset Power offset of the Physical Broadcast See TS 32.592 [14] and TR-
Channel with respect to the 196 [7]
ReferenceSignalPower.
Table 4-41 TPMParameter.notify content

ESState Status regarding the energy saving in See TS 32.592 [14] and TR-
the cell. 196 [7]
Table 4-42 ESParameter.notify content

Version: 083.5.1 51
MeasurementStatus Indicates the current status of this -
measurement. Enumeration of:
{Indeterminate; inprogress; success;
error; error_timeout}
LastMeasurementTime The time of the last BHM measure -
RTT Round trip time {50percentileRTT, -
90percentileRTT}. Time in
milliseconds as computed by the
(H)eNB. [RFC3550]
Negative value used when the
measurement is N/A
ULBandwidthEstimate Uplink bandwidth estimate. -
ULBandwidth {50percentileBW,
90percentileBW}. Bandwidth in kbps.
measurement is N/A
DLBandwidthEstimate Downlink bandwidth estimate. -
DLBandwidth {50percentileBW,
90percentileBW}. Bandwidth in kbps.
measurement is N/A
PacketErrorEstimate Packet Error estimate. PacketError. -
Packet error is reported in
percentage.
measurement is N/A
BackhaulAvailability Time duration backhaul is available -
over the past 24 hours.
Expressed as a percent value from 0
to 100.
measurement is N/A
Table 4-43 BHMParameter.notify content

TS 32.592 [14] and TR-196
PhyCellID Physical cell ID
[7]
Table 4-44 PCIParameter.notify content

Id Neighbor cell Relation index 3GPP TS 32.762 [13]
Enable Status of this entry in the NRT. BBF TR-196 [7]
PLMN ID consists of Mobile Country TS 32.592 [14] and TR-196
Code (MCC) and Mobile Network Code [7]
(MNC). Mobile Country Code consists
of three digits and uniquely identifies
PLMNID the country of domicile of the
subscriber. Mobile Network Code
consists of two or three digits and
identifies the Home PLMN within a
country.
Cell Identity. Combination of PLMNID TS 32.592 [14] and TR-196
CID and CID constitutes the Cell Global ID [7]
(CGI).
EUTRACarrierARFCN Indicates the ARFCN of this carrier TS 32.592 [14] and TR-196

Version: 083.5.1 52
frequency. Corresponds to parameter [7]
dl-CarrierFreq in SIB5 and parameter
NDL. If the value of
EUTRACarrierARFCN is the same with
the one currently being used by the,
then it implies that this neighbor cell
is an intra-frequency cell; otherwise,
it is an inter-frequency cell.
TS 32.592 [14] and TR-196
PhyCellID Physical cell ID
[7]
X2SetupFlag X2 is set up for this entry of NRT -
Table 4-45 ANRParameter.notify content

IMDLProtectedPRB Mask for protected PRB in DL - RNTP vector -
(bit string) whose values indicates whether a
promise to protect a DL PRB is given or not
given [See TS 36.423 [9], section 9.2.19].
RNTP_Threshold RNTP threshold for IMDLProtectedPRB mask -
[See TS 36.423 [9], section 9.2.19]
IMULProtectedPRB Mask for protected PRB in UL - vector (bit -
string) whose values indicates whether a
promise to protect an UL PRB is given or not
given.
IMABSInformation Pattern for protected resources in the time -
domain - ABS Pattern vector (bit string)
whose values indicates which sub-frames
are almost blank sub-frames and which not
[See TS 36.423 [9], section 9.2.54].
p-b Equal to Eb/Ea. Is same for all UEs in the See TS 32.592 [14]
cell. Eb = EPRE (energy per resource and TR-196 [7]
element) of PDSCH REs type B i.e. REs in
OFDM symbols that include reference
symbols.
p-a Equal to Ea/Ers. Ea = EPRE (energy per See TS 32.592 [14]
resource element) of PDSCH REs (resource and TR-196 [7]
elements) type A i.e. REs in OFDM symbols
that do not include reference symbols.
p-a-High Value of p-a for high-power PRBs in DL in -
Soft-FFR. The parameter is meaninful when
the IMFreqHardFFR is set to FALSE.
Table 4-46: IMParameter.notify content
dSONParameter.ack
This message is sent from cSON to dSON to confirm SON Parameter Change
Notification. The dSONParameter.ack content is provided in Table 4-47.

Table 4-47 dSONParameter.ack content
ERRORs for dSON parameter change notification procedure

Errors that may be returned in dSONParameter.ack are given in Table 4-48.

Version: 083.5.1 53
MSG_OK Successful parameter change notification
(no error)
ERR_ INVALID_ECGI One or more ECGI values listed are not
corresponding to the sender (H)eNB
ERR_INVALID_STATE The received message is not valid in the
current state
ERR_INVALID_CONFIG At least one of the received values is
invalid, dSON is advised to re-check
values and send new
dSONParameter.notify
Table 4-48 dSONParameter.ack errors
4.3 Error Description
The list of possible errors returned in either of the .response messages, .ack
messages or the ERROR.indication message is given in Table 4-49.
Error Description
MSG_OK Message is OK (no error)
ERR_ INVALID_ECGI One or more ECGI values listed are not present in the
related (H)eNB
ERR_PARAMETER_FAIL (H)eNB cannot provide dSON parameters to cSON,
upon request
ERR_INVALID_STATE The received message is not valid in the current state
ERR_ACTIVATE_FAIL The requested dSON algorithm activation failed
ERR_DEACTIVATE_FAIL The requested dSON algorithm deactivation failed
ERR_INVALID_CONFIG The configuration provided in SONConfig.update

message is invalid
ERR_PM_CONFIG_FAIL The PM Configuration request failed
ERR_PM_MISSED At least one requested counter cannot be reported as

requested
ERR_REM REM reporting not available at this (H)eNB
ERR_EN_CONFIG_FAIL The EN Configuration request failed
ERR_EN_MISSED At least one requested events cannot be configured and

notified as requested
Table 4-49 SON API Errors description

Version: 083.5.1 54
5. Guidelines for SON API
As illustrated in Chapter 2, the SON API can support information exchange with both
EM-based and NM-based cSON solutions. In case of EM-based cSON, the information
carried by the SON API needs to be transferred over Type-1 interface (see SON API
components in Figure 2-4), while in case of NM-based cSON they also needs to be
transferred over Type-2 interface (see SON API components in Figure 2-3).
In this chapter we look at both cases and see provide guidelines about how the SON
API information could be integrated in the Type-1 and Type-2 interfaces.
5.1 Considerations for SON API mapping on Type-1 interface
The SON API comprises two basic elements: procedures (listed in chapter 3) and data
model content (listed in chapter 4). In case of Type-1 interface (e.g. for EM based
cSON) procedures can be realized by means of BBF TR-069 protocol [6] while the data
model can be realized with BBF TR-196 specification [7] (mapped to 3GPP TS 32.592
[14].
5.1.1 SON API Procedures guidelines for Type-1 interface
The SON API procedures are detailed in chapter 3 and are divided into Global
Procedures (valid across all SON functions) and Function Specific Procedures (linked to
the particular SON function). All procedures can be possibly be realized by means of
existing procedures in TR-069 protocol [6], as illustrated in Table 5-1 (see [18]).
SON API SON API Messages Mapping to TR-069

Procedure
dSON Parameter dSONParameter.request GetParameterNames/Response
Retrieve dSONParameter.response GetParameterValues/Response
PM Configuration PMConfig.update SetParameterValues/Response
PMConfig.ack (indicating the Upload Period)
PM Reporting PMReport.notify Upload
REM Configuration REMConfig.update SetParameterValues/Response
REMConfig.ack
REM Reporting REMReport.notify GetParameterValues/Response or Upload
Event EventConfig.update SetParameterValues/Response
Configuration EventConfig.ack (indicating the Reporting Mechanism)
Event Reporting EventReport.notify Inform/Response or Upload
dSON Activation dSONActivate.request SetParameterValues/Response
dSONActivate.ack
dSON Deactivation dSONDeactivate.request SetParameterValues/Response
dSONDeactivate.ack
dSON dSONConfigure.update SetParameterValues/Response
Configuration dSONConfigure.ack SetParameterAttributes/Response
dSON Parameter dSONParameter.notify Inform/Response
Change dSONParameter.ack Note: ‘Active Notification’ set in Parameter
Notification Attributes to trigger ‘Inform’
Table 5-1 SON API procedures: mapping to TR-069 for Type-1 interface
Note: For Configuration management purposes, file Download method could also be
used as optional alternative to SetParameterValues method, as specified in [18].

Version: 083.5.1 55
5.1.2 SON API content guidelines for type-1 interface
The SON API content is detailed in chapter 4 where information elements are listed in
corresponding tables for each procedure and SON function. Every table include a
reference to the specification (either 3GPP or BBF) when the corresponding
information is available or no reference in case the information is newly introduced by
the SON API. Based on that information, gaps to existing specifications for Type-1
interface can be easily identified and could be used for preparing contributions to
amend relevant 3GPP and BBF documents in order to cover the SON API. Overall the
gap is limited and can be reasonably addressed for Type-1 interface data model.
Example: MRO SON function parameters are listed in Table 4-24 and further in Table
4-25 and Table 4-26. By looking at Table 4-24, three parameters are listed not being
part of the existing data model in TR-196 [7] and could be considered for addition to
that specification: MROIntraFreqEnable, MROInterFreqEnable and HOFailureRate. The
rest of parameters, listed in in Table 4-25 (Connected Mode) and Table 4-26 (Idle
Mode) are instead already present in the current data model and can be simply reused
apart a small change needed for the Cell Individual Offset (CIO).
5.2 Considerations for SON API mapping on type-2 interface
For the NM layer cSON case, mapping on type 1 information described in section 5.1
also applies and one of important questions is how to map the SON API onto the Itf-N
(Type 2) interface. The proposed SON API is defined in terms of messages to/from
Small Cells that trigger certain actions. On the other hand, the Itf-N is defined in
terms of data model with R/W operations (so called information service part or IS).
The protocol part of Itf-N IRPs is separated out (to so called solution sets or SS) and
can differ between different vendors, can change in time, etc. It is preferable therefore
to define mapping in terms of IS and avoid dependency on the SS.
5.2.1 SON API procedures guidelines for Type-2 interface
One possible solution for basic configuration and notification is as follows
• Messages from cSON to EM/HMS are mapped onto write operations in the
Type 2 interface
• The SON API agent, as illustrated in figure 2, translates this into
corresponding TR-069 message transferred to the (H)eNB (NE). So the
message from EM/HMS to the NE is mapped onto the TR-069 message
• Messages from (H)eNB (NE) to EM/HMS are mapped onto TR-069 messages
• The SON API agent translates these messages into notifications
The following diagram shows an example of SON API operations (PCI assignment)
based on above solution (see [16] and references therein).

Version: 083.5.1 56
Figure 5-1 Mapping of SON API operations onto Type 1 and Type 2 interfaces (example: PCI
selection)
Reference [16] also include a description of configuration via profile definition.
5.2.2 SON API content guidelines for Type-2 interface
For the SON API component within the Type 2 interface, a data model may be derived
from 3GPP management concepts, see for example related specifications in 0 and 0.

Version: 083.5.1 57
Appendix A - SON Functions and SON API requirements
(informative)
This Annex provides an overview of the addressed SON functions, and their
requirements with respect to an information exchange between dSON and cSON
elements over the SON API (if any such exchange is required or optional/useful for
that SON function).
Note: Requirements are intended to be towards the SON API capabilities to support
the information exchange between cSON and dSON, in case the algorithms intends to
make use of such exchange. They are not intended to constrain any implementation in
cSON nor dSON algorithms.
A.1 SON functions overview
The following Table A-1 provides a list of considered SON functions for the scope of
the SON API, with a short description of each. The SON functions provides self-
configuration and self-optimization capabilities and include SON assistance
functionalities as well.
Acronym Function Short description

PCI PCI optimization PCI optimization consists of two functions:
PCI selection: Initial selection of PCI upon reset
or boot-up
PCI conflict detection and resolution: continuous
detection of PCI collision or confusion, and
providing a resolution
ANR ANR/Neighbor ANR/neighbor management can be split into
management several components:
REM-assisted neighbor discovery
UE assisted neighbor discovery
UE assisted neighbor management
X2 assisted neighbor management
CHS Channel selection Channel selection goal is
Selecting the best channel for small cell
operations, e.g. at power-up
RO RACH optimization RACH optimization consists of
Root sequence index planning
Optimal setting of RACH parameters
MRO Mobility robustness Small cells monitor handover failures and identify
optimization causes
Example: ‘too early’, ‘too late’, and ‘wrong cell’
handovers
Message exchange between source and target
cells on failures
SON tracks handover successes/failures
Adjusts handover parameters according to cell-
specific data to reduce handover failures
May exchange information with FHM feature for
UE specific parameter adjustment
FHM Frequent handover Frequent handovers impact user experience and
mitigation increased signalling load. MRO is used for overall
mobility parameter optimization to improve
handover performance, while frequent handover
mitigation is used for per-UE optimization beyond

Version: 083.5.1 58
Acronym Function Short description
MRO:
Classify users as high speed or ping pong users
based on handover history
Adjust handover parameters per UE to prevent
ping-pongs
Handover high mobility users to macro layer
MLB Mobility load balancing Monitoring of small cell traffic load, dynamic
modification of HO parameters/triggers in order
to establish a uniform load per cell across the
network
TPM Transmit power Perform small cell transmit power management to
management eliminate pilot pollution and coverage issues
Improve mobility performance: Minimize number
of handovers with minimal impact on
capacity/coverage
Optimize capacity and coverage
IM Interference Interference management coordinates the use of
management radio resources among cells, to improve link
SINR, in DL and UL
Resource/interference coordination to improve
user SINR building on 3GPP ICIC framework and
evolutions thereof (eICIC, feICIC)
Protected resources in time or frequency domain
for cell edge users to improve distribution tail
throughputs
ES Energy saving Energy saving objective is to reduce power
consumption of the SC when possible
Energy saving consists in turning-off cells when
unloaded and turn them on again when needed to
increase capacity
BHM Backhaul management Small cells leverage existing user backhaul that
may have limited and variable available
bandwidth and varying traffic and loading
conditions
Monitor each user performance and offload users
to a different cell if backhaul is overloaded.
Table A-1 SON functions
A.2 SON functions – use cases
Referring to the SON functions above, several use cases have been identified for SON
in recent work done at Small Cell Forum (see reference [1] and [2]), which has been
considered also for the definition of the SON API.
A.3 SON requirement definition
Requirements are listed with a unique identifier and text, for convenience:
• Requirement tag: SON function acronym (from Table A-1)

• Requirement Category: Performance management (PM_REQ), event
notifications (EN_REQ), Parameter (PAR_REQ), performance guidance
(PG_REQ), others (OTH_REQ)
• Requirement number – with grouped elements
• Requirement text: answering the question what is required

Version: 083.5.1 59
Example:
ANR_PAR_REQ_10: A configuration procedure by which cSON provides dSON

ANR a white list of NRs to be included in the NRT shall be supported.
A.4 SON functions requirements
A.4.1 PCI optimization requirements
The PCI optimization SON function provides mechanisms for small cells to select their
initial operating PCI when they are first added to the network and to detect PCI
collisions with other small cells or with macro cells that may occur when new cells are
added or removed within heterogeneous network deployments. Proper PCI selection
has a direct impact on system performance, especially as it relates with interference
and handovers.
Following the general diagram in Figure 2-5 (see section 2.2), when a small cell is
added to the network it selects its PCI from a list of provisioned PCIs. Small cells may
have built-in capability to sense the radio environment (radio environment monitoring
function), which assists in selecting a PCI from the provisioned range, that is not in
use by close-by neighbors. In addition to radio environment monitoring functionalities,
small cells may rely on UE reporting or X2 messages to further optimize PCI selection
and avoid PCI collisions with neighbor cells. The small cell however may not have full
knowledge about any PCI conflicts in the neighborhood that would impact handover
performance. In that case, cSON can provide assistance with an up-to-date PCI list.
When a change in the network topology occurs (for example re-configuration in the
macro cells, addition or removal of small cells, etc.) there is also a potential for PCI
collision or confusion that can cause performance degradation. Without an interface to
cSON, the small cell may rely only on UE measurement reporting (ECGI to PCI) or X2
messages when that capability exists so it can detect PCI collision issues. Even in that
case however, in multi-vendor deployments the standards do not specify a protocol for
resolving collisions. In that case the cSON function can help resolve collisions (e.g.
based on reestablishment reports) and control and orchestrate PCI changes over
multiple cells.
Performance counters such as handover statistics can be used by the cSON to further
optimize and update PCI ranges so that small cells can adjust to changes in their
environment.
According the PCI optimization use cases in references [1] and [2], the procedures for
PCI assignments during initial small cell configuration and after moving or removing
small cells should include the capability to identify PCI confusion, detect PCI conflicts,
and auto configure the small cells to properly resolve such conflicts in order to
optimize performance.
In the perspective of the SON API these procedures can be summarized in the
following:
• Ability of cSON to configure initial PCI list for dSON

• Ability of dSON to report detected PCIs and collisions to cSON
• Ability of dSON to report handover statistics to cSON
• Ability of cSON to provide an updated PCI list to dSON

Version: 083.5.1 60
To address the above use cases, the PCI optimization requirements for the SON API
are summarized below:
PCI_PAR_REQ_10 cSON shall be able to specify a list or range of PCIs that dSON is
allowed to use
PCI_PAR_REQ_10.1 dSON shall be able to report the selected PCI to cSON (success)
PCI_PM_REQ_20 cSON shall be able to configure radio environment

measurements (REM) at (H)eNB
PCI_PM_REQ_20.1 dSON of (H)eNB supporting REM shall report REM results to

cSON
PCI_PAR_REQ_30 cSON shall be able to retrieve dSON PCI selection capability and
parameters.
PCI_PAR_REQ_40 dSON shall be able to send to cSON a list of PCIs detected by the
(H)eNB, when requested by cSON (see note).
PCI_PM_REQ_50 cSON shall be able to configure and collect performance counters

for handover statistics. Such counters are defined in section
4.2.4.2 in TS 32.453.
PCI_PM_REQ_50.1 cSON shall be able to set configuration parameters for handover

counter collection at (H)eNB
PCI_PM_REQ_50.2 dSON shall be able to report the collected handover counters to

cSON
PCI_OTH_REQ_60 cSON shall enable/disable dSON PCI selection algorithm
PCI_EN_REQ_70 dSON may report detected local PCI conflicts
PCI_EN_REQ_70.1 dSON may report detected PCI collisions to cSON
PCI_EN_REQ_70.2 dSON may report detected PCI confusions inflicted onto neighbor
cells to cSON
PCI_EN_REQ_70.3 dSON may report detected PCI confusions inflicted from neighbor
cells to cSON
PCI_EN_REQ_70.4 dSON shall be able to notify cSON if no PCI can be selected

(failure)
Note: Detected PCIs are not necessarily included into the Neighbor Relation Table e.g.
because the signal from the detected cells is below a certain threshold or the table has
already reached max allowed size.
Table A-2 lists the SON API procedures needed to fulfil the above requirements, with
reference to the general descriptions included in Chapter 3.
Requirement SON API procedure (see Chapter 3) Initiated by

PCI_PAR_REQ_10 dSON configuration cSON
PCI_PAR_REQ_30 dSON parameter retrieve cSON

Version: 083.5.1 61
PCI_PAR_REQ_10.1 dSON parameter notification dSON
PCI_PAR_REQ_40
PCI_PM_REQ_20 Performance measurements configuration cSON

PCI_PM_REQ_20.1 Performance measurements reporting dSON
PCI_PM_REQ_50 Performance counters configuration cSON
PCI_PM_REQ_50.1
I_PM_REQ_50.2 Performance counter reporting dSON
PCI_EN_REQ_70 Event notification: PCI collision and confusion dSON
PCI_EN_REQ_70.1
PCI_EN_REQ_70.2
PCI_EN_REQ_70.3
PCI_EN_REQ_70.4
PCI_OTH_REQ_60 dSON activation/deactivation cSON
Table A-2 Procedures used for PCI optimization to meet the requirements
A.4.2 Automatic neighbor relation
The purpose of the automatic neighbor relations (ANR) function is to relieve operators
from the burden of manually managing neighbor relations (NRs). This is particularly
important in heterogeneous network deployments where there are a large number of
small cells and the network topology may change frequently.
With ANR management, small cells automatically configure and manage their NR
tables so that idle mode and connected mode UE mobility procedures can be
seamlessly supported without any manual intervention.
ANR management can be split into the following components:
• REM-assisted neighbor discovery

• UE assisted neighbor discovery
• UE assisted neighbor management
• Neighbor management via X2 messages
Small cells will typically build initial NR tables based on radio environment monitoring
capabilities to detect neighboring intra-frequency, inter-frequency and optionally inter-
RAT cells. Radio environment monitoring functions can be complemented by cSON-
assisted procedures. For example, the cSON server may provision over the SON API
an initial NR table at a small cell before the small cell goes into operation. The cSON
server may also set the relevant attributes (such as ‘no handover’, ‘no X2’, ‘no
removal’) for detected neighbors, complete the initial tables according to configured
white and black list information available.
During normal operations, additional neighbors will be discovered locally at the small
cell as part of UE assisted measurements and X2 signalling exchange with neighbors.
The cSON server could also provide management of neighbor white lists and black lists
in (H)eNBs according to certain measurements, for example handover statistics or
(H)eNB measurement information, and manage the policy for distributed ANR across
vendors and different types of nodes.
Looking at the ANR aspects in references [1] and [2], the ANR management
procedures shall include the following capabilities:

Version: 083.5.1 62
• Initial neighbor list configuration at small cell (H)eNB
• New neighbor discovery at (H)eNB through UE measurement report and/or
X2 signaling
• Neighbor deletion (triggered by cSON or by (H)eNB)
To address the above use cases, the ANR management requirements for the SON API
are summarized below:
ANR_PAR_REQ_10 cSON shall be able to provide a list of NRs and their relevant
attributes (‘no remove’, ‘no HO’, ‘no X2’) to the (H)eNB NRT
ANR_PAR_REQ_10.1 cSON shall be able to provide a list of NRs to be included in

(H)eNB NRT
ANR_PAR_REQ_10.2 cSON shall be able to provide a list of NRs to be deleted from

(H)eNB NRT
ANR_PAR_REQ_20 dSON shall be able to report to cSON a list of PCIs detected via
REM measurements, UE measurements, or X2 signaling (see
note)
ANR_PAR_REQ_30 dSON shall be able to notify cSON about changes in NRT
ANR_PAR_REQ_30.1 dSON shall be able to inform cSON about added NRs due to local
decision based on e.g. UE report, X2 signaling, etc.
ANR_PAR_REQ_30.2 dSON shall be able inform cSON about deleted NRs due to e.g.,
inactivity timeout (i.e. no measurement reports for PCI/ECGI
pair)
ANR_PG_REQ_40 cSON shall be able to configure thresholds for ANR dSON adding
/ deleting neighbors
ANR_OTH_REQ_50 The cSON shall be able to enable/disable dSON ANR
Note: Detected PCIs are not necessarily included into the neighbor relation table e.g.,
because the signal from the detected cells is below certain threshold or the table has
already reached max allowed size.
reference to the general descriptions included in Chapter 3.
Requirement SON API procedure (see chapter 3) Initiated by

ANR_PAR_REQ_10 dSON function configuration cSON
ANR_PAR_REQ_10.1
ANR_PAR_REQ_10.2
ANR_PG_REQ_40
ANR_PAR_REQ_20 dSON parameter change notification dSON
ANR_PAR_REQ_30
ANR_PAR_REQ_30.1
ANR_PAR_REQ_30.2
ANR_OTH_REQ_50 dSON activation/deactivation cSON
Table A-3 Procedures used for ANR management to meet the requirements

Version: 083.5.1 63
A.4.3 Channel selection requirements
The objective of the SON channel selection function is to select the best operating
transmission channel at the small cell, at start-up and, as an option, periodically. The
suitability of channels has at least two dimensions:
• The selected channel should have a low amount of interference, especially

interference from powerful macro cells, to boost capacity locally where
indicated, and/or
• The selected channel should be the same across all small cells in the
neighborhood to minimize inter-frequency measurements e.g. for handovers
The appropriate channel selection policy in a particular deployment depends on

channel bandwidth and spectrum availability. The policy should reflect a balance
between inter-frequency signalling and potential capacity gains by increasing reuse.
To enable a flexible and dedicated channel selection solution, the cSON-dSON API
should allow cSON and dSON to exchange relevant neighbor information. This
information can include Radio Environment Measurement (REM) reports, such as the
received interference levels and transmit powers, as well as the number of detected
small cells on each channel. The information exchange enables the nodes to perform
an appropriate local channel selection according to the policy.
A centralized channel selection function can be implemented at cSON for small cells
not having a dedicated channel selection algorithm available at the dSON level. cSON
uses as input the radio environment reports from neighboring (H)eNBs and takes a
centralized decision according to the policy, and directly sets the channel at those
small cells.
Table A-4 summarizes channel selection scenarios of interest, in multi-vendor

environment.
Scenario dSON at dSON at cSON input to SC- cSON input to SC-B

SC-A SC-B A
SC-A is CHS Perform measurements on all CHS guidance and list of candidate channels
capable candidate channels provided by
SC-B is CHS cSON.
capable Select channel from the list.
SC-A is CHS Perform Perform CHS guidance and list CHS guidance and list
capable measurements measurements of candidate channels of channels to be
SC-B without on all candidate on all candidate measured (= list of
CHS capability channels channels candidate channels)
provided by provided by Selected channel for
cSON. cSON. operations
Select channel
from the list.
Table A-4 Multi-vendor scenarios for channel selection
The channel Selection requirements for the SON API are listed below.
CHS_PAR_REQ_10: cSON shall be able to retrieve dSON CHS

capability/parameters
CHS_OTH_REQ_20: cSON shall be able to enable/disable dSON CHS algorithm

Version: 083.5.1 64
CHS_PM_REQ_30: cSON shall be able to configure radio environment
CHS_PM_REQ_30.1: dSON of (H)eNB supporting REM shall report REM results

to cSON
CHS_PAR_REQ_50: cSON shall be able to configure relevant dSON CHS

parameters
CHS_PAR_REQ_50.1: cSON shall send list of candidate operational channels for

(H)eNB, the target bandwidth and duplexing mode, in
order of preference
CHS_PAR_REQ_50.2: cSON shall be able to provide current transmit power

settings of neighboring cells to (H)eNB dSON
CHS_PAR_REQ_50.3: cSON shall be able to provide a list of macro PCI to dSON,

for avoiding channels on which macro cells are found to
be operating
CHS_PAR_REQ_50.4: cSON shall be able to provide a list of adjacent channels

(adjacent to any of the candidate channels) that are used
by a different operator, for calculation of transmit power
protection limits on the different candidate channels.
CHS_PAR_REQ_50.5: dSON shall be able to notify the cSON of selected channel

at (H)eNB
CHS_PG_REQ_60: cSON shall be able to provision dSON with CHS guidance
reference to the general description included in Chapter 3.

CHS_PAR_REQ_10 dSON parameter retrieval cSON
CHS_OTH_REQ_20 CHS activation/deactivation cSON
CHS_PM_REQ_30.x dSON performance measurement configuration cSON
FHM_PM_REQ_30.2 dSON performance measurement reporting dSON
CHS_PAR_REQ_50 CHS algorithm configuration (parameters/guidance/ cSON
CHS_PAR_REQ_50. target)
1…4
CHS_PG_REQ_60
CHS_PAR_REQ_50.5 CHS parameter change notification dSON
Table A-5 Procedures used for Channel selection to meet the given requirements
A.4.4 RACH optimization requirements
The objective of the RACH optimization (RO) SON function is to balance RACH capacity
and performance, and PUSCH capacity, across multiple cells. It addresses the
following aspects:
• Provide self-configuration capabilities for (P)RACH parameters (root sequence

index )
• Reduce contention probability to minimize access delays to increase
successful RACH access for all UEs in the system

Version: 083.5.1 65
• Reduce detection miss probability to minimize RACH access delays and to
increase successful RACH access for all UEs in the system
• Minimize inter cell PUSCH-PRACH interference
• Minimize inter cell PRACH-PRACH interference (inter cell preamble sequence
interference )
• Balance RACH density and PUSCH capacity
Any change in network configuration (HO/mobility parameters, Tracking area

planning, transmission power, antenna tilt) can cause change in RACH load. Change in
transmission power, antenna tilt and interference scenario can also result in change in
radius of the cell.
Dynamic change in RACH load or cell radius requires self-optimization of RACH

parameters to change the RACH density and RACH power related parameters
respectively.
Looking at RACH optimization aspects in references [1] and [2], the following actions
are considered as part of (P) RACH resource optimization/management:
• During small cell initialization, cSON configures (P)RACH parameters/ranges

and RACH performance targets to Small cell/dSON.
• Small cells monitor the surrounding radio environment (e.g. using REM and
X2 exchanges) and use these as inputs to dSON-(P)RACH Resource
Management. dSON selects the root sequence index accordingly and updates
it to cSON.
• In operational state small cells use the UE reports and X2 exchanged
information to optimize the RACH parameters within the range provided by
cSON to meet the performance targets. Performance Counters of interest are
collected by small cells and shared with cSON for RACH optimization.
• cSON uses the received statistics/counters to further adjust and distribute
updated (P)RACH parameters/ranges to small cell/dSON.
Reflecting above in the perspective of SON API leads to:
• Ability to configure reporting RO performance counters

• Ability to retrieve RO capability of the dSON/small cell
• Ability to configure RO algorithm at (H)eNB
• Including providing ranges for RO parameters

• Including performance guidance for RO
• Ability to enable/disable the RO feature
Table A-6 summarizes typical scenarios of interest, in a multi-vendor environment
Scenario dSON at SC-A dSON at cSON input to SC-A cSON input to SC-B
SC-B
SC-A is RO 1. Select initial (P)RACH - RACH parameter default values/ranges

capable parameters’ values from the -Guidance for RACH performance
SC-B is RO range provide by cSON. Set - Parameters ranges for P(RACH) based on
capable the (P)RACH parameters. collected counters/statistics
2. Optimize (P)RACH
parameter values within the
range during operations, based
on RACH performance and

Version: 083.5.1 66
performance guidance
provided by cSON.
SC-A is RO Same as above No - RACH parameter - RACH parameters’

capable action. default values/ranges values
SC-B with no -Guidance for RACH - RACH default Values
RO capability performance - Value update based
- Parameters ranges on collected
for P(RACH) based on statistics/counters
collected - Value update based
counters/statistics on changes in neighbor
cells (root sequence
index etc.)
Table A-6 Multi-vendor scenarios for RACH Optimization
The RACH optimization requirements for SON API are summarized below:
RO_PAR_REQ_10: cSON shall be able to retrieve dSON RO capability and settings
RO_OTH_REQ_20: cSON shall be able to enable/disable dSON RO function in the

Small Cell
RO_PAR_REQ_50: cSON shall be able to configure relevant dSON RO parameters
RO_PAR_REQ_50.1: cSON shall be able to provide ranges for dSON RO parameters
RO_PAR_REQ_50.2: dSON shall be able to notify the cSON about the changes in RO
parameters.
RO_PM_REQ_30: cSON shall be able to configure and collect performance counters

for (P)RACH
RO_PM_REQ_30.1: cSON shall be able to set configuration parameters for

performance counter collection at small cell
RO_PM_REQ_30.2: Small cell /dSON shall report collected performance counters to

cSON
RO_PG_REQ_60: cSON shall be able to provision dSON RO with RO guidance
RO_PG_REQ_60.1: cSON shall be able to provide dSON RO with performance targets

for RACH Access Probability and RACH access delay probability

RO_PAR_REQ_10 dSON capability retrieval cSON
RO_OTH_REQ_20 RO activation/deactivation cSON
RO_PM_REQ_30. dSON performance counter configuration cSON
RO_PM_REQ_30.1
RO_PM_REQ_30.2 dSON performance counter reporting dSON
RO_PAR_REQ_50 RO algorithm configuration (parameters/guidance/ cSON

Version: 083.5.1 67
RO_PAR_REQ_50.1 target)
RO_PG_REQ_60
RO_PG_REQ_60.1
RO_PG_REQ_50.2 RO parameter change notification dSON
Table A-7 Procedures used for RO to meet the requirements
A.4.5 Mobility robustness optimization requirements
The mobility robustness optimization (MRO) SON function addresses handover failures
by classifying them and by optimizing mobility parameter settings. For instance:
• Outdoor SC-SC handovers especially for fast moving users

• Outdoor SC-macro handover optimization
• Indoor ‘entrance’ cells have high mobility with outdoor cells
Both intra-frequency and inter-frequency handovers are relevant for MRO and failure
cases are classified into too late HO, too early HO and HO to wrong cell [7].
Performance counters may be provided to distinguish the different kinds of HO related

failures and MRO enables automated adjustments of HO parameters to improve
performance (e.g. time-to-trigger, thresholds, cell individual offset).
Looking at mobility robustness aspects in references [1] and [2], handover specific
performance statistics are collected for mobility (among them, HO failure statistics and
MRO classification are of interest for MRO) and specific action on mobility parameters
are considered for optimization. The NRT at the macro cell and small cell must contain
neighbor entries to track cell specific mobility metrics.
Reflecting those in the perspective of SON API leads to:
• Ability to configure reporting MRO performance counters

• Ability to configure MRO algorithm at (H)eNB
• Including providing ranges for MRO parameters

• Including performance guidance for MRO
• Ability to enable/disable the MRO feature
Table A-8 summarizes typical scenarios of interest, in a multi-vendor environment,

assuming that both SC-A and SC-B reports available handover statistics to cSON.
Scenario dSON at SC-A dSON cSON input to SC- cSON input to SC-
at SC- A B
B
SC-A is Collect information over X2 Mobility parameter default values
MRO regarding RLF events per Mobility optimization guidance for MRO
capable neighbor and allow dSON – Parameters ranges for handover based on
SC-B is to take action per user collected statistics
MRO category and/or per – NRT updates based on collected statistics
capable neighbor cell relation basis (e.g. blacklist a neighbor cell)
SC-A is Same as above No Mobility parameter Mobility parameter
MRO assuming SC-B action. default values default values
capable supports MRO Mobility optimization – Parameters for
SC-B with specific guidance for MRO handover based on
no MRO messages over – Parameters ranges collected statistics

Version: 083.5.1 68
capability X2 for handover based on per cell basis
Note: if SC-B does on collected – NRT updates
not support MRO
statistics based on collected
specific messages
over X2, SC-A – NRT updates statistics
cannot properly based on collected
count the outgoing statistics
HO failures A to B
Table A-8 Multi-vendor scenarios for MRO
The MRO requirements for SON API are summarized below:
MRO_PAR_REQ_10: cSON shall be able to retrieve dSON MRO capability and

settings
MRO_OTH_REQ_20: cSON shall be able to enable/disable dSON MRO
MRO_PM_REQ_30: cSON shall be able to configure and collect performance

counters for MRO handover failures and handover
statistics
MRO_PM_REQ_30.1: cSON shall be able to set configuration parameters for

MRO_PM_REQ_30.2: (H)eNB/dSON shall report the collected counters to cSON
MRO_PAR_REQ_50: cSON shall be able to configure relevant dSON MRO

parameters
MRO_PAR_REQ_50.1: cSON shall be able to provide mobility parameter ranges
MRO_PAR_REQ_50.2: dSON shall be able to notify cSON of mobility parameter

changes
MRO_PG_REQ_60: cSON shall be able to provision dSON MRO with MRO

guidance
MRO_PG_REQ_60.1: cSON shall be able to provide dSON MRO with

performance targets for HO failures
Requirement SON API procedure (see chapter 3) Initiated by

MRO_PAR_REQ_10 dSON parameter retrieval cSON
MRO_OTH_REQ_20 MRO activation/deactivation cSON
MRO_PM_REQ_30 dSON performance counter configuration cSON
MRO_PM_REQ_30.1
MRO_PM_REQ_30.2 dSON performance counter reporting dSON
MRO_PAR_REQ_50 MRO algorithm configuration (parameters/guidance/ cSON
MRO_PAR_REQ_50.1 target)
MRO_PG_REQ_60
MRO_PG_REQ_60.1
MRO_PAR_REQ_50.2 MRO parameter change notification dSON
Table A-9 Procedures used for MRO to meet the requirements

Version: 083.5.1 69
A.4.6 Frequent handover mitigation requirements
The frequent handover mitigation (FHM) SON function addresses frequent connected
mode handovers due to user mobility or channel fading, by optimizing UE specific
mobility settings. For instance:
• a vehicular user on the small cell layer may experience frequent SC-to-SC or
SC-to-macro-to-SC handovers (short stay) due to fast user mobility
• a stationary user in the coverage area of multiple cells may experience
frequent handovers (ping pong) due to channel fading
Looking at mobility robustness aspects in references [1] and [2], handover specific
performance statistics are collected for mobility (among them, ping pong HO statistics
are of interest for FHM) and specific action on mobility parameters are considered for
optimization.
• Ability to configure reporting of FHM performance counters

• Ability to configure FHM algorithm at (H)eNB
• Including providing ranges for FHM parameters

• Including performance guidance for FHM
• Ability to enable/disable the FHM feature
Note: According to TS 32.522, section 4.3.1, the objective of minimizing the number
of unnecessary handovers shall always be pursued in case the other target/s
configured by the operator is/are achieved. This objective may not need configuration
of a target value.
Table A-10 summarizes typical scenarios of interest, in a multi-vendor environment.
Scenario dSON at dSON at cSON input to SC-A cSON input to SC-B

SC-A SC-B
SC-A is FHM Handle FH in real time from Mobility performance guidelines for FH
capable local information on a per Parameters ranges for handover based on
SC-B is FHM user or per cell basis collected performance statistics
capable
SC-A is FHM Handle FH in No action. Mobility performance Parameter ranges for

capable real time guidelines for FH handover based on
SC-B with no from local Parameters ranges for collected performance
FHM information handover based on statistics – for all
capability on a per user collected performance users
or per cell statistics
basis
Table A-10 Multi-vendor scenarios for FHM
The FHM requirements for SON API are summarized below:
FHM_PAR_REQ_10: cSON shall be able to retrieve dSON FHM capability and

settings
FHM_OTH_REQ_20: cSON shall be able to enable/disable dSON FHM

Version: 083.5.1 70
FHM_PM_REQ_30: cSON shall be able to configure and collect performance
counters for ping pong and handover statistics
FHM_PM_REQ_30.1: cSON shall be able to set configuration parameters for

FHM_PM_REQ_30.2: (H)eNB/dSON shall report the collected counters to cSON
FHM_PAR_REQ_50: cSON shall be able to configure relevant dSON FHM

parameters
FHM_PAR_REQ_50.1: cSON shall be able to provide mobility parameter ranges
FHM_PG_REQ_60: cSON shall be able to provision dSON FHM with FHM

guidance

FHM_PAR_REQ_10 dSON parameter retrieval cSON
FHM_OTH_REQ_20 FHM activation/deactivation cSON
FHM_PM_REQ_30. dSON performance counter configuration cSON
FHM_PM_REQ_30.1
FHM_PM_REQ_30.2 dSON performance counter reporting dSON
FHM_PAR_REQ_50 FHM algorithm configuration (parameters/guidance/ cSON
FHM_PAR_REQ_50.1 target)
FHM_PG_REQ_60
Table A-11 Procedures used for FHM to meet the requirements
A.4.7 Mobility load balance requirements
The mobility load balancing (MLB) SON function addresses load imbalance and
congestion situations by assessing (H)eNB loading and adjust user distribution by
mobility setting changes or handovers from one loaded cell to a less loaded cell [7].
Load information can consist of (H)eNB equipment status, over-the-air saturation

level, and backhaul loading. Performance counters may be provided to monitor loading
statistics of various cells and MLB enables automated adjustments of HO parameters
to improve user performance (e.g., time-to-trigger, thresholds, cell individual offset)
[1] and [2].
• Ability to configure reporting loading performance counters

• Ability to configure MLB algorithm at (H)eNB
• Including providing ranges for MLB parameters

• Including performance guidance for MLB
• Ability to enable/disable the MLB feature
Table 12 summarizes typical scenarios of interest, in a multi-vendor environment,

assuming that both SC-A and SC-B reports available handover statistics to cSON.

Version: 083.5.1 71
Scenario dSON at SC-A dSON cSON input to SC- cSON input to SC-
at SC- A B
B
SC-A is Perform load balancing Mobility guidance for MLB
MLB based on available local
capable information (e.g. resource
SC-B is status) and mobility
MLB guidance
capable
SC-A is Perform load No Mobility guidance for Mobility parameter
MLB balancing based action. MLB values
capable on available – Parameters for
SC-B with local handover based on
no MLB information collected load
capability (e.g. resource statistics on per cell
status) and basis
mobility
guidance
Table A-12 Multi-vendor scenarios for MLB
The MLB requirements for SON API are summarized below:
MLB_PAR_REQ_10: cSON shall be able to retrieve dSON MLB

MLB_PM_REQ_20: cSON shall be able to configure and collect LOAD

performance counters to be reported from (H)eNB
MLB_PM_REQ_20.1: cSON shall be able to set configuration parameters for

LOAD performance counters collection at (H)eNB (such as
type, averaging, and reporting)
MLB_PM_REQ_20.2: (H)eNB/dSON shall report the collected LOAD

performance counters to cSON
MLB_PG_REQ_30: cSON shall be able to provision dSON MLB with MLB

guidance
MLB_PG_REQ_30.1: cSON shall be able to provide dSON MLB with guidance

for MLB input usage
MLB_OTH_REQ_40: cSON shall be able to enable/disable dSON MLB algorithm
MLB_PAR_REQ_50: cSON shall be able to configure relevant dSON MLB

parameters
MLB_PAR_REQ_50.1: cSON shall be able to provide mobility parameter ranges
MLB_PAR_REQ_50.2: dSON shall be able to notify cSON of mobility parameter

changes

MLB_PAR_REQ_10 dSON parameter retrieval cSON

Version: 083.5.1 72
MLB_OTH_REQ_40 MLB activation/deactivation cSON
MLB_PM_REQ_20 dSON performance counter configuration cSON
MLB_PM_REQ_20.1
MLB_PM_REQ_20.2 dSON performance counter reporting dSON
MLB_PAR_REQ_50 MLB algorithm configuration (parameters/guidance/ cSON
MLB_PAR_REQ_50.1 target)
MLB_PG_REQ_30
MLB_PG_REQ_30.1
MLB_PAR_REQ_50.2 MLB parameter change notification dSON
Table A-13 Procedures used for MLB to meet the requirements
A.4.8 Transmit power management requirements
Transmit power management function can mitigate pilot pollution and coverage holes
by optimizing DL transmit power of small cells. In addition, this function can also
mitigate impact on quality of experience caused due to small cell coverage bleeding
into macro coverage areas. Such ‘bleeding’ may cause users to perform frequent
handovers as they pass through footprints of multiple small cells.
When a small cell powers up, the power management function at cSON can provide
operator defined policy, parameter ranges, and performance targets. The power
management function at the SC may select a parameter from the provided range and
become operational. Further, it monitors the surrounding RF mobility aspects (e.g.
using REM, UE reports, etc) to fine tune parameters and improve performance, trading
off capacity with mobility issues. Performance measurements are collected over time
and reported to cSON, which can use the combined indicators from multiple SCs to
identify possible actions and will signal updated power ranges to SCs.
Table A-14 summarizes typical power management scenarios of interest in a multi-

vendor environment.
Scenario dSON at dSON at cSON input to cSON input to SC-B

SC-A SC-B SC-A
SC-A is power • Select initial transmit Guidance for power management:
management power level from the Parameter range for transmit power based on
capable range provided by collected performance measurements
SC-B is power cSON. Set the initial
management transmit power.
capable • Optimize transmit
power during
operations, based on
collected X2, UE and
REM reports.
SC-A is power Same as No action Guidance for power Transmit power value:
management above management: Initial transmit power
capable Parameter range Value update based on
SC-B with no for transmit power collected performance
power based on collected measurements
management performance Value update based on
capability measurements changes in neighbor
cells.
Table A-14 Multi-vendor scenarios for transmit power management.
Both SC-A and SC-B reports available performance measurements of interest to cSON
in all cases.

Version: 083.5.1 73
The transmit power management requirements for the SON API are listed below.
TPM_PAR_REQ_10: cSON shall be able to retrieve dSON transmit power

management capability/parameters
TPM_OTH_REQ_20: cSON shall be able to enable/disable dSON transmit

power management algorithm
TPM_OTH_REQ_30: cSON shall be able to configure radio environment

TPM_OTH_REQ_30.1: (H)eNB supporting REM shall report REM results to cSON
TPM_PAR_REQ_40: cSON shall be able to configure ranges for dSON transmit

power management parameters.
TPM_PAR_REQ_40.1 dSON shall be able to notify cSON of selected parameter

value (and any changes thereon).
TPM_PG_REQ_50: cSON shall be able to provision dSON with transmit

power management guidance
TPM_PM_REQ_60: cSON shall be able to configure and collect performance

measurements
TPM_PM_REQ_60.1: (H)eNB/dSON shall report configured performance

measurements/alarms to cSON.

TPM_PAR_REQ_10 dSON parameter retrieval cSON
TPM_OTH_REQ_20 dSON procedure activation/deactivation cSON
TPM_OTH_REQ_30 REM configuration cSON
TPM_OTH_REQ_30.1 REM reporting dSON
TPM_PM_REQ_60 dSON performance measurement configuration cSON
TPM_PM_REQ_60.1 dSON performance measurement reporting dSON
TPM_PAR_REQ_40 Algorithm configuration (parameters/guidance/ cSON
TPM_PG_REQ_50 target)
TPM_PAR_REQ_40.1 Parameter Change Notification dSON
Table A-15 Procedures used for transmit power management to meet the given requirements
A.4.9 Interference management requirements
Interference Management (IM) techniques are highly important for small cell
deployments in heterogeneous networks and in dense networks, where increased
interference results in poor SINR for cell edge users and limits the overall network
capacity.
3GPP studied and defined means for IM in LTE networks in both frequency domain
(ICIC) and time domain (eICIC) [TR 36.814]. Frequency domain techniques protects
resources for cell edge users by reducing (or not transmitting) data in certain resource
blocks so that a cell edge user in a neighboring small cell can be served in the same
resource blocks. Similarly, time-domain mechanism mitigates interference in time

Version: 083.5.1 74
domain relying on almost blank sub-frames (ABS): cells do not transmit data in
certain sub frames, resulting in lower power and interference levels to allow cell edge
users in neighbor cells to be served – this is especially of relevance for heterogeneous
network with macro cells and small cells coexisting in the same frequency channel.
Additional techniques based on cooperative multi-point (CoMP) and enhancements for

inter-eNB coordination with coordinated scheduling have been also recently addressed
by 3GPP [3GPP TR 36.874], where resource are managed jointly in the time and
frequency domain.
Figure 5-2 Example of interference management helping cell edge user performance
The SON API aims to support these IM techniques allowing for various possible
implementations. Depending on the particular algorithm, a higher (e.g. dynamic
interference management and time and/or frequency domain) or lower (e.g. static
resource partitioning, distributed power management) degree of coordination among
small cells may be required.
The SON API allows cSON to provide proper guidance and parameter settings to dSON
(e.g., resource split ranges to use, proper power levels for reduced-power resources,
etc.), for interference management and to cope with cases where coordination via X2
interface may not be possible. In order to maintain a good overview of the
interference situation across cells, performance statistics could be collected by cSON
and be used to update the resource partitioning to adjust to possible changes in the
neighborhood.
Table A-16 summarizes typical interference management scenarios of interest in a

multi-vendor environment.
Scenario dSON at dSON at cSON input to SC- cSON input to SC-

SC-A SC-B A B
SC-A is • Select local resource Guidance for interference management:
interference partitioning scheme • Interference management technique
managemen from the list provided • Possible partitioning of resources,
t capable by cSON based on collected performance
SC-B is • Optimize resource measurements at small cell
interference partitioning, based on
managemen inter-cell information
t capable exchange, UE and
REM reports.
SC-A is Same as Apply the Guidance for Resource

Version: 083.5.1 75
interference above given interference Partitioning:
managemen resource management: • Initial
t capable partitioning • xInterference partitioning
SC-B with management • Value update
no technique based on
interference • xPossible collected
managemen partitioning of performance
t capability resources, measurements
based on • Value update
collected based on
performance changes in
measurements neighbor cells.
at small cell
Table A-16 Multi-vendor scenarios for interference management.
Both SC-A and SC-B reports available performance measurements of interest to cSON
in all cases.
The Interference Management requirements for SON API are listed below:
IM_PAR_REQ_10: cSON shall be able to enable/disable dSON IM algorithms
IM_PAR_REQ_20: cSON shall be able to retrieve dSON IM capability and

parameter settings
IM_PAR_REQ_30: cSON shall be able to configure dSON IM parameters
IM_PAR_REQ_30.1: cSON shall be able to specify a list of usable DL and UL

data RB masks for ICIC techniques
IM_PAR_REQ_30.2: cSON shall be able to specify a list of usable power values

for protected and unprotected data RBs for ICIC
techniques
IM_PAR_REQ_30.3: cSON shall be able to specify a list of ABS patterns to

small cells for eICIC techniques
IM_PAR_REQ_30.4 dSON shall be able to notify cSON of resource partitioning

changes for IM (e.g. RB mask, power, ABS pattern)
IM_PM_REQ_40: cSON shall be able to configure performance counters

relevant for IM
IM_PM_REQ_40.1: cSON shall be able to set configuration parameters for

IM_PM_REQ_40.2: (H)eNB/dSON shall report the collected performance

counters to cSON
IM_PG_REQ_60: cSON shall be able to provision dSON IM with IM guidance
IM_PM_REQ_70: cSON shall be able to configure radio environment

IM_PM_REQ_70.1: (H)eNB supporting REM shall report REM results to cSON

Version: 083.5.1 76

IM_PAR_REQ_20 dSON parameter retrieval cSON
IM_PAR_REQ_10 IM activation/deactivation cSON
IM_PM_REQ_40
dSON performance counter configuration cSON
IM_PM_REQ_40.1
IM_PM_REQ_40.2 dSON performance counter reporting dSON
IM_OTH_REQ_70 REM measurement configuration cSON
IM_OTH_REQ_70.1 REM measurement reporting dSON
IM_PG_REQ_60
IM_PAR_REQ_30
IM algorithm configuration
IM_PAR_REQ_30.1 cSON
(parameters/guidance/target)
IM_PAR_REQ_30.2
IM_PAR_REQ_30.3
IM_PAR_REQ_30.3 IM parameter change notification dSON
Table A-17 Procedures used for IM to meet the requirements.
A.4.10 Energy saving requirements
The energy saving (ES) SON function addresses the desire to save energy by putting
cells into an energy saving state in which they are not providing service to users
during periods of low user demand. The impact on the service coverage and quality
provided to users should be minimal: users within the coverage area of the cells in the
energy saving state must also be within coverage of a cell which has sufficient
capacity to service their needs
• Ability to configure reporting of ES performance counters

• Ability to configure ES algorithm at (H)eNB
• Including providing ranges for ES parameters

• Including performance guidance for ES
• Ability to enable/disable the ES feature
Table A-18 summarizes typical scenarios of interest, in a multi-vendor environment.
Scenario dSON at dSON at cSON input to SC- cSON input to SC-

SC-A SC-B A B
SC-A is ES Determines when to Guidance for ES
capable activate and deactivate ES Parameter ranges for ES activation and de-
SC-B is ES based on own and activation based on collected PM from all
capable neighbor cell resource surrounding cells
usage
SC-A is ES As above N/A. As above cSON can cause ES
capable activation and
SC-B with deactivation based
no ES on PM from SC-B
capability and all surrounding
cells
Table A-18 Multi-vendor scenarios for ES

Version: 083.5.1 77
The ES requirements for SON API are here summarized:
ES_PAR_REQ_10: cSON shall be able to retrieve ES capability and settings
ES_OTH_REQ_20: cSON shall be able to enable/disable dSON ES
ES_PM_REQ_30: cSON shall be able to configure and collect performance counters

for cell load and general cell performance
ES_PM_REQ_30.1: cSON shall be able to set configuration parameters for counter

collection at (H)eNB
ES_PM_REQ_30.2: (H)eNB/dSON shall report the collected counters to cSON
ES_PAR_REQ_40: dSON shall be able to notify cSON about changes of ES state
ES_PAR_REQ_50: cSON shall be able to configure relevant dSON ES parameters
ES_PAR_REQ_50.1: cSON shall be able to provide ES thresholds

ES_PAR_REQ_10 dSON parameter retrieval cSON
ES_OTH_REQ_20 ES activation/deactivation cSON
ES_PM_REQ_30. dSON performance counter configuration cSON
ES_PM_REQ_30.1
ES_PM_REQ_30.2 dSON performance counter reporting dSON
ES_PAR_REQ_40 ES state change notification dSON
ES_PAR_REQ_50 ES algorithm configuration cSON
ES_PAR_REQ_50.1
Table A-19 Procedures used for ES to meet the requirements
A.4.11 Backhaul management requirements
The BHM function at the (H)eNB monitors user’s backhaul at start-up and during
operation to provide measurements of throughput (uplink/ downlink), round trip
delay, backhaul availability and packet error rate. In addition, BHM module may
provide these measurements to other SON features such as mobility load balancing,
transmit power management, etc. Note that both cSON and dSON may request that
the BHM module takes measurements.
The figure below illustrates an architecture where an (H)eNB and other devices are
connected to a home router. Since the S1 interface shares the internet connection
with other devices, it is desirable to measure variation/availability of the shared link
over time. BHM provides a framework to configure measurements and reporting.
Various cSON and dSON features can utilize the measurements provided by the BHM
module.

Version: 083.5.1 78
Figure 5-3 An illustration of (H)eNB connectivity to operator’s network. The S1 interface
share Internet connection with other devices over the shared backhaul.
The backhaul monitoring requirements for the SON API are listed below.
BHM_PAR_REQ_10: cSON shall be able to retrieve backhaul monitoring

BHM_PAR_REQ_20: cSON shall be able to configure relevant backhaul monitoring

parameters.
BHM_PAR_REQ_30: (H)eNB shall be able to report the collected backhaul

measurements to cSON.
BHM_OTH_REQ_40: cSON shall be able to enable/disable dSON BHM

BHM_PAR_REQ_10 BHM parameter retrieval cSON
BHM_PAR_REQ_20 BHM configuration cSON
BHM_PAR_REQ_30 BHM reporting dSON
BHM_OTH_REQ_40 BHM activation/deactivation cSON
Table A-20 Procedures used for BHM to meet the requirements

Version: 083.5.1 79
References
1 Small Cell Forum 066.03.01- Enterprise SON use cases, December 2013,
http://www.scf.io/documents/066
2 Small Cell Forum 077.03.01- Urban SON use cases, February 2014,
3 Small Cell Forum 088.04.02- Urban Small Cell Network Architecture, June 2014,
4 Small Cell Forum 059.04.01- X2 interoperability in multi-vendor X2 HetNets, June
2014, http://www.scf.io/documents/059
5 NGMN Alliance - Recommended Practices for Multi-vendor SON Deployment,
http://www.ngmn.org/nc/downloads/techdownloads.html
6 BBF TR-069 – CPE WAN Management Protocol, http://www.broadband-
forum.org/technical/download/TR-069_Amendment-5.pdf
7 BBF TR-196 – Femto Access Point Service Data Model,
http://www.broadband-forum.org/cwmp/tr-196-2-0-1.html
8 3GPP TS 36.300 – E-UTRAN Overall Description, Stage-2,
http://www.3gpp.org/DynaReport/36300.htm
9 3GPP TS 36.423 – X2 Application Protocol (X2AP),
10 3GPP TS 32.453 – Performance measurements Home enhanced Node B (HeNB)
Subsystem (HeNS), http://www.3gpp.org/DynaReport/32453.htm
11 3GPP TS 32.425 – Performance measurements Evolved Universal Terrestrial Radio
Access Network (E-UTRAN), http://www.3gpp.org/DynaReport/32425.htm
12 3GPP TS 32.522 – SON Policy Network Resource Model (NRM) Integration
Reference Point (IRP); Information Service (IS),
13 3GPP TS 32.762 – E-UTRAN Network Resource Model (NRM) Integration
Reference Point (IRP); Information Service (IS),
14 3GPP TS 32.592 – HeNB OAM&P - Information model for Type 1 interface HeNB to
HeNB Management System (HeMS),
15 TS 32.571 HNB and HeNB management; Type 2 interface concepts and
requirements, http://www.3gpp.org/DynaReport/32571.htm
16 TS 32.572 HNB and HeNB management; Type 2 interface models and mapping
functions, http://www.3gpp.org/DynaReport/32572.htm
17 TS 32.101 Telecommunication management; Principles and high level
requirements, http://www.3gpp.org/DynaReport/32101.htm
18 3GPP TS 32.593 – HeNB OAM Procedure flows for Type-1 Interface HeNB to
HeMS, http://www.3gpp.org/DynaReport/32593.htm

Version: 083.5.1 80

SON API Small Cells

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

SON API Small Cells

Uploaded by

Copyright:

Available Formats

SMALL CELL FORUM

RELEASE Five scf.io/

RURAL & REMOTE

Small Cell Forum works to accelerate small cell adoption to change

Small Cell Forum Release website can be found here: www.scf.io

No license, express or implied, to any intellectual property rights is granted or

Post Small Cell Forum, PO Box 23, GL11 5WA UK

Member Services memberservices@smallcellforum.org

Report title: SON API for small cells

The self-organizing networks (SON) concept includes a combination of different

The SON API defined in this document is targeted to contribute to a harmonized

The document is structured as follows:

• Chapter 2 includes information about SON architecture assumptions relevant

1.1 Relevant standards

Small Cell Forum (SCF)

Report title: SON API for small cells

Broad Band Forum (BBF)

Report title: SON API for small cells

LTE Access with dSON

Figure 2-1 Generic hybrid SON architecture

2.1 Hybrid SON architecture – deployment scenarios

• Coexistence of SCs from different vendors, with or without X2 interface – in

Report title: SON API for small cells

2.1.1 SON API architecture for NM layer cSON

Figure 2-2 SON API architecture in case of NM layer cSON

2.1.2 SON API Architecture for EM layer cSON

Report title: SON API for small cells

Figure 2-3 SON API architecture in case of EM layer cSON

2.2 Hybrid SON architecture – operations

• Autonomous operation: The central SON server signals to the (H)eNBs

Note: cSON can also exercise an intermediate level of control by means of

Report title: SON API for small cells

Range Range Setting/ Central

Autonomous Authorized Controlled

Figure 2-4 Hybrid SON operations

• Initially cSON configures general performance counters and parameters for

Report title: SON API for small cells

Performance Counter Configuration

dSON Parameter Configuration

Parameter Change Notification

Counters Uploaded to OAM/cSON

Updated Parameter Configuration

Figure 2-5 Example of message exchange for hybrid SON operations

Report title: SON API for small cells

3.1 Global procedures

The global procedures supported by the SON API are:

• dSON parameter retrieve

3.1.1 dSON Parameter Retrieve

• dSONParameter.request (cSON  dSON): request SON configuration from

Report title: SON API for small cells

• Successful response include

Figure 3-1 dSON parameter retrieve procedure flow

The high-level PM configuration procedure message flow is (see Figure 3-2):

• PMConfig.update (cSON  dSON): to indicate an updated set of performance

Report title: SON API for small cells

• Response include list of ACK for

Figure 3-2 Performance counter configuration procedure flow

• (H)eNB reads the requested performance counters from the register

Figure 3-3 Performance counter reporting procedure flow

Report title: SON API for small cells

3.1.4 REM configuration

• REMConfig.update (cSON  dSON): to indicate an updated set of REM

• Response include list of ACK for

Figure 3-4 REM measurement configuration procedure flow