SMALL CELL FORUM

RELEASE 7.0 scf.io

17:25

URBAN

RISE

RURAL
ENTERP
HOME

& REMO
TE
VIRTUAL
IZATIO
N

DOCUMENT

077.07.01
SON use cases

February 2014

Solving the HetNet puzzle

www.scf.io/ www.smallcellforum.org
SMALL CELL FORUM

RELEASE 7.0 scf.io

Small Cell Forum accelerates small cell adoption to drive the

wide-scale adoption of small cells and accelerate the delivery of
integrated HetNets.

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.

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.

Today our members are driving solutions that include small cell/Wi-Fi
integration, SON evolution, virtualization of the small cell layer, driving mass
adoption via multi-operator neutral host, ensuring a common approach to
service APIs to drive commercialisation and the integration of small cells into
5G standards evolution.

The Small Cell Forum Release Program has now established business cases and
market drivers for all the main use cases. This document is part of
Release 7: HetNet and SON.

Small Cell Forum defines HetNet as a ‘multi-x environment – multi-technology,

multi-domain, multi-spectrum, multi-operator and multi-vendor. It must
be able to automate the reconfiguration of its operation to deliver assured
service quality across the entire network, and flexible enough to accommodate
changing user needs, business goals and subscriber behaviors.’

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

Scope
The Urban self-organizing networks (SON) use cases document is an informative
document. Its scope is to capture the use cases that illustrate, in a comprehensive
build upon the enterprise femto deployment guidelines document [ 1] and the
Enterprise SON use cases document [ 2], how the self-organizing network function
(SON function for short) helps in the configuration, optimization and maintenance of
urban small cell networks with very low or no manual intervention. The informative
use cases are targeted towards the two predominant radio access technologies (RAT)
— UTRAN and EUTRAN. In this context, the 3GPP-specified functions such as self-
configuration, automatic neighbor relations (ANR), physical cell identity (PCI)/primary
scrambling code (PSC) assignments, resource management and load balancing, robust
handoff and RACH optimization are addressed.

The target audience for this document is systems and network deployment engineers
as well as designers working on SON solution architectures and SON algorithms.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01
Executive summary
Small cells are low-power cellular base stations typically deployed in residential,
enterprise, urban hotspot, and rural & remote settings. Small cells provide excellent
user experience through better coverage for voice and very high data throughputs.
Small cells can also offload traffic from macrocell network benefiting the small cell
user as well as other users on the macro network. In addition, Small cells can enable
new applications such as location-based services

Urban small cells are used both as a capacity layer and for overcoming coverage
holes. They are deployed either outdoors or indoors and, if indoors, in both open and
closed subscriber group modes depending upon the need for the deployment, the
subscription of the end user and other factors. They tend to differ from enterprise
deployments in that they are less planned and offer less opportunity for human
intervention and optimization. They also have a broader charter than strictly
residential small cells and are likely to see a much wider variation in deployment
scenarios (and thus different radio conditions, coverage areas, modes and other
features). This means that the need for a SON function is even more acute.

The background documents [1] and [2] provide recommendations for deployment,
configuration and operation of enterprise small cells and the SON use cases in the
enterprise context. This document covers the SON function as it pertains to urban
small cell networks. The document aims to highlight, in as much detail as possible,
without infringing or architecture or algorithm choices, use cases for the SON function.
The broad goal of SON is to enable the configuration, deployment, optimization,
operation, maintenance and healing of dense networks across multiple scales with
very low or no manual input or feedback; this goal is an underlying theme throughout
the document.

Specifically, the following topics are addressed:

1. Urban SON use cases addressing the two predominant radio access
technologies — UTRAN and EUTRAN
2. SON use cases addressing the full life cycle of the network — from initial
deployment and configuration through self-optimization as well as
maintenance aspects
3. SON functionality specifically addressing the 3GPP-identified areas such as
self-configuration, self-optimization (neighbor discovery, parameters
(PCI/PSC) optimization, resource sharing for interference management and
capacity optimization as final goals, load balancing, robust handoff and
random access channel (RACH) parameter optimization) and self-healing.

In addition some attempt is made to address maintenance aspects of SON.

The goal of this informative document is to be useful to system architects and

algorithm designers working on architectures and SON functions at the front end of
the design process as well as network designers at the back end. Naturally, the goal is
to illustrate that if the front-end designers cover the use cases in the design stage,
then in the back end the network engineer will benefit significantly.

The real benefit is, of course, to both the network operators and users in terms of
reduced capex and opex for the same or better level of service.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01
Contents
1. Introduction .....................................................................1
1.1 Glossary of terms ................................................................ 2
2. Architecture choices .........................................................3
2.1 Centralized SON .................................................................. 3
2.2 Distributed SON .................................................................. 4
2.3 Localized SON ..................................................................... 5
2.4 Hybrid SON ........................................................................ 6
3. SON and SON function ......................................................9
3.1 SON function ...................................................................... 9
3.2 SON features ...................................................................... 9
4. Urban SON use cases ......................................................11
4.1 Configuration .................................................................... 12
4.1.1 Activation of a small cell ..................................................... 12
4.2 Planning, deployment and operation .................................... 13
4.2.1 Addition of a new small cell ................................................ 13
4.2.2 Addition of a group of small cells ......................................... 14
4.2.3 Decommissioning of a small cell .......................................... 15
4.2.4 Administrative locking of a small cell .................................... 15
4.2.5 Reactivation of a small cell ................................................. 16
4.2.6 Autonomous reactivation of a small cell ................................ 16
4.2.7 New neighbor discovery ..................................................... 17
4.2.8 Neighbor deletion .............................................................. 18
4.3 Optimization ..................................................................... 18
4.3.1 PCI conflict detection and resolution .................................... 18
4.3.2 Transmit power optimization ............................................... 19
4.3.3 Cross-layer load balancing and interference management....... 19
4.3.4 Intra-RAT load balancing .................................................... 20
4.3.5 Mobility robustness optimization .......................................... 21
4.3.6 RACH optimization ............................................................. 22
4.3.7 Inter-RAT mobility robustness optimization ........................... 22
4.3.8 Inter-RAT load balancing .................................................... 23
4.3.9 Energy savings .................................................................. 23
4.4 Maintenance ..................................................................... 24
4.4.1 SON metrics and analytics management ............................... 24
5. Summary ........................................................................25
References ................................................................................26

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01
Tables
Table 1–1 Glossary of terms ........................................................................... 2
Table 2–1 Summary of various SON architectures.............................................. 8
Table 4–1 Comparison of urban and enterprise use cases ..................................12
Table 4–2 Small cell activation .......................................................................13
Table 4–3 Adding a new small cell ..................................................................13
Table 4–4 Adding many new small cells ...........................................................15
Table 4–5 Decommissioning a small cell from a network ....................................15
Table 4–6 Administrative locking of a small cell ................................................16
Table 4–7 Reactivating a small cell .................................................................16
Table 4–8 Small cell returning autonomously to normal service (self-healing) ......17
Table 4–9 Discovering a new neighbor in an LTE network ..................................18
Table 4–10 Deleting a neighbor in LTE and UMTS ...............................................18
Table 4–11 PCI conflict detection and resolution .................................................19
Table 4–12 Optimization of small cell transmit power ..........................................19
Table 4–13 Load and co-channel interference management with macro network ....20
Table 4–14 Intra-RAT load balancing ................................................................21
Table 4–15 Mobility robustness optimization ......................................................21
Table 4–16 RACH optimization .........................................................................22
Table 4–17 SON mobility robustness optimization between LTE and UMTS .............23
Table 4–18 Inter-RAT load balancing ................................................................23
Table 4–19 Energy saving by centralized, distributed or local SON function ...........24
Table 4–20 Dissemination of SON metrics .........................................................24

Figures
Figure 2-1 Example of a centralized (canonical) NM-based SON architecture for
multi-vendor, multi-RAT networks..................................................... 4
Figure 2-2 Example of a distributed SON architecture ......................................... 5
Figure 2-3 Example of a localized SON architecture ............................................ 6
Figure 2-4 Generic hybrid SON architecture ....................................................... 7
Figure 3-1 SON features.................................................................................10

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01
1. Introduction

The concepts of small cell networks and enterprise small cell networks are covered in
[1].

The need for and the functionality of SON functions are extensively covered in
literature (see for example LTE Self-Organizing Networks [ 3] and references therein).
Specifically, from an LTE perspective, SON function scope and coverage within the
3GPP context are addressed in Self-Organizing Networks: Concepts and requirements
[ 4] (and references therein).

The SON function is not a specific node or element in the network. Rather, as the
name implies, it is a functional entity, or set of functional entities, that addresses the
specific needs discussed in the references pointed above. In an architecture and
algorithm instantiation sense the function lends itself to a large number of
implementation options.

Further, since heterogeneous networks are a significant feature of deployment, the

SON functions vary according to the scale in which they are deployed (macro versus
small cells etc.) and multiple SON functions may co-exist in a given operator’s
network, together fulfilling the overall business needs of the operator. These SON
functions therefore need to behave co-operatively and in the interest of the overall
cost functions and policies.

The various architectures and how they apply to each layer are expanded on in
Chapter 2.

This document draws heavily upon its predecessor, which addresses enterprise SON
use cases [2]. There is a significant amount of similarity and overlap. However, some
of the differences are:

1. Urban deployments are characterized by the heterogeneity in layers in terms

of macro, pico, or femto. These cells also differ in their physical layer
capabilities, which need to be communicated and managed by the SON
system.
2. Urban environments may also be characterized by intense interference
between layers — for example, when common spectral resource is re-used in
the different layers, which may shorten the optimization timescales for co-
ordination.
3. The number of SON vendors and their features and capabilities within the
same network, especially in the small cell layer, will be varied.
Interoperability between the different SON solutions will be necessary.
4. Modes in which cells are deployed will be varied. For example in-home small
cells could be closed subscriber group (CSG) because the homeowner pays
for broadband while pole-mounted outdoor small cells will likely be open
subscriber group (OSG).
5. SON functions that were performed by an (IT) technician in an enterprise
environment will still occur in urban settings (see use case 4-4) but will be
heavily aided by MDT (minimization of drive tests) functions.
6. Since there is no well-defined boundary between cells in an urban
environment, SON will need to identify subsets of cells that see high
interaction. These subsets of cells could benefit from proper coordination in
the SON function.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 1
The use cases in the urban context are modified as necessary to take note of these
differences.

The scope of this document is narrowly to focus upon the SON function addressing the
urban deployments and even more specifically illustrate the SON function through
properly designed use cases, whether they be single RAT (intra and inter-frequency)
or inter-RAT (LTE and UMTS).

1.1 Glossary of terms

Since the document and specifically sections to follow are heavy on acronyms, the
following glossary is added for convenience to the reader.

Term Description
ACS Auto-configuration server
ANR Automatic neighbor relation
CN Core network
DL Downlink (from the base station to the user equipment)
eNB e Node B (3GPP standard name for LTE base stations)
EMS Element management system
EPC Enhanced packet core
IP Internet protocol
IT Information technology
LTE Long term evolution
MME Mobility management entity
MSC Mobile-network switching center
NB Node B (3GPP Standard name for UMTS base stations)
NLM Network listen module (sometimes called a sniffer). this may be located in the
urban small cell and/or in the LTE UE.
NMS Network management system
NRT Neighbour relations table
PCI Physical cell identifier (PCI in LTE)
PLMNID Public land-mobile network identifier
PSC Primary scrambling code (in UMTS)
RSI Root sequence index
S1 An LTE standards defined interface between eNB and EPC. It has two ‘planes’ —
a user plane and an MME plane.
SC Small cell
SGSN Serving GPRS support node
TNL Transport network layer
TX Transmit or transmitter
UL Uplink (from the user equipment to the base station)
UMTS Universal mobile transmission system
X2 An LTE standards-defined interface between eNBs.
Table 1–1 Glossary of terms

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 2
2. Architecture choices

Several possible architectures with different grades of integration can be considered

for SON functionality in a multi-RAT, multi-vendor, multi-operator and multi-layer
heterogeneous network (HetNet).

In general, the following four different architectures can be identified for SON
functionality: centralized, distributed, localized and hybrid.

2.1 Centralized SON

In a centralized architecture, son algorithms typically reside in a small number of

locations on the network or domain management nodes such as such as OAM, NMS,
EMS, GW, controllers or separate SON servers that manage various types of small
cells. Figure 2-1 shows a centralized NM-based SON architecture. This architecture
enables operators to have more control over the entire network operation. A
centralized approach allows for a more manageable implementation of the SON
algorithms across multi-RATs and multi-vendors. This architecture can address
scalability issues by reducing the requirement to signal a large amount of information
to the centralized SON servers by using a condensed collection of SON parameter
information that is uploaded to the network/domain management nodes [3].

In centralized SON, availability of KPIs and UE measurement information at the SON

servers may be delayed due to forwarding to a centralized point; this approach may
have a slower reaction to the network dynamics. These delays are typically
constrained by an individual vendor’s network element and/or element manager
design. Consequently, for certain SON use cases, depending upon NE/EM reporting
capabilities, the performance of a centralized SON architecture may be impacted due
to the misalignment of different RAN vendors’ reported information and statistics and
the time constraints of the particular SON algorithm.

In order to minimize the impact of slow updates to SON parameters, depending on the
use cases, the interactions between SON algorithms can be allowed through an
intelligent management entity prior to active modification of SON parameters.
Additionally, operators often greatly over-provision the centralized SON servers for
enhanced processing and greater network capabilities. An accurate analysis of
cost/performance issues — as well as a high tolerance to failures — needs to be
adequately addressed to avoid overloading of the centralized SON controller.

In multi-layer/multi-vendor networks, due to coordination difficulties between

macrocells and small cells as well as lack of IOT between different vendors, a
centralized SON architecture is often preferred.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 3
Figure 2-1 Example of a centralized (canonical) NM-based SON architecture for multi-vendor,
multi-RAT networks

2.2 Distributed SON

In a distributed SON architecture, SON functionality can reside in multiple locations.

Algorithms are typically executed within the network elements such as NB, eNB or
HeNB. However, the reporting information based on the UE measurements, other
(e)NBs or external operational policies need to be exchanged through the standard
interfaces (i.e., X2, S1 etc.). In case of inter-RAT multi-technology small cells, either
new (local) interfaces need to be defined between the 3G and LTE small cells or the
communication between the distributed SON functions should be performed through
the core network, using proprietary extensions to various existing interfaces defined in
the 3GPP standards (e.g., S1, Iu, Iuh, Iur-gh, GbTR-196v2). In case of multi-vendor
deployments, due to the lack of well-defined inter-vendor interfaces and the
implementation of non-identical SON algorithms, a distributed architecture with
accurate KPI monitoring capabilities is more desirable. This resulting solution can
minimize the risk of network instability [ 5].

Although a distributed architecture offers less control for operators over SON
parameters, this approach provides better scalability, less latency and reduced load on
NMS. It also allows for ease of deployment in mixed-vendor scenarios. Most EMS
vendors expose their APIs that allow the retrieval and the setting of their information
elements that can propagate the parameters down to the network elements. The
distributed architecture can also make the benefits of self-management functions for
enhanced robustness avoiding single points of failure.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 4
Figure 2-2 Example of a distributed SON architecture

2.3 Localized SON

In localized SON architecture, the algorithms are distributed locally within individual
network elements at a relatively low level in the architecture. In this approach, the
SON functionality is entirely autonomous — that is, the decisions are made
autonomously and operators have (in most cases) no control over SON functionality.
Autonomous SON configuration for local self-optimization loops such as enhanced
plug-and-play functions, hand-over thresholds and energy saving modes can be
executed with low overheads and latency on the devices.

This architecture is the most scalable option among the possible SON architectures.
For frequent local SON functions, tight coupling topologies are required in order to
reduce the delays in communications between levels of hierarchies. Localized SON
provides the fastest response time to short-term (<1ms) functions such as (inner-
loop) power control algorithms. In localized SON architecture, well-defined interfaces
between SON function entities are not required.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 5
Figure 2-3 Example of a localized SON architecture

2.4 Hybrid SON

The most efficient SON realization for an urban HetNet is hybrid architecture.
Scalability and real-time response of SON functions must be supported through a lean
and reliable management framework. This architecture can best exploit the benefits of
SON functions and smoothly integrate with operators’ existing practices. The hybrid
SON can be distributed at small cells, element management systems or core networks.
This architecture is, in effect, a trade-off between the centralized and distributed
topologies.

In a hybrid approach, part of a given SON algorithm can be executed in operation and
maintenance (OAM) servers (or NMS) while another part can be executed in small
cells. The existence and cooperation of SON functions both on the RAN side and on the
backend management side can allow a high degree of automation. For example, the
values of the initial parameters, boundary conditions and operators’ policies could be
configured in a centralized server, and updates and refinement to those parameters in
response to the actual UE measurements could be done in the (e)NBs. Figure 2-4
shows a generic (canonical) hybrid SON architecture for a complete multi-RAT, multi-
vendor and multi-layer HetNet.

Operators can migrate from a centralized to a distributed SON option as they gain
more confidence about multi-vendor IOT. In general, distributed or hybrid SON
approaches are favored in coordinated networks since they enable lower delay, less
signaling, and lower cost, even though they may risk losing some performance gains
compared to their centralized counterparts. Certain SON functions such as mobility
load balancing can have an improved performance in a coordinated and
hybrid/distributed SON architecture. In general, hybrid SON architectures require
more complicated mechanisms for implementing various information elements. Often
in multi-operator/multi-vendor deployment scenarios, bilateral or multilateral
agreements need to be facilitated by operators/vendors.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 6
Figure 2-4 Generic hybrid SON architecture

A summary of various possible SON architectures is shown in Table 2–1.

SON
# Description
architectures
1 Centralized
2 Distributed
Pros Cons
One-to-many More manageable Less scalable
topology implementation Large amount of
Typically, Often preferred in signalling information
resides in multi-layer/multi- needs to be transported
OAMs, vendor networks due to to centralized SON
controllers or coordination difficulties servers
servers between macro-cells Slower
OSS-centric and small cells as well reaction/response time
approach as lack of IOT between to network dynamics
mixed vendors Potentially less accurate
SON servers often need
to be over-provisioned
Need to address
cost/performance and its
tolerance to failure
issues to avoid
overloading of SON
controller
Many-to-many Minimizes risk of In inter-RAT access
topology network instability points, new interfaces
Resides in Increased scalability need to be defined
multiple Less latency Operators have less
locations Reduced load on NMS control over SON
Algorithms are allowing ease of parameters
typically deployment in mixed-
executed within vendor scenarios
coordinated Enhanced robustness

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 7
 SON
# Description Pros Cons
architectures
network avoiding single points
elements as of failure
opposed to
localized/auton
omous schemes
Distributed Most scalable option Most opportunistic
locally within For frequent local SON Operators have (in most
individual functions, it can be cases) no control on
network executed with low SON functionality
elements overheads/latency No global (network)
Autonomous allowing local self- optimization
3 Localized functionality optimization In multi-RAT multi-
Provides the fastest vendor deployments,
response time may result in conflicting
No well-defined SON functionalities and
interfaces between SON race conditions
function entities are Potential stability issues
required
Hierarchal A trade-off between In certain scenarios,
many-to-many centralized/distributed may have fewer
topology topologies — best of performance gains
Can be both worlds compared to a
distributed at Most efficient and centralized option
small cells, scalable architecture Requires a more
element Flexible: operators can complex
management migrate from a control/coordination
systems or core centralized to a mechanism
networks distributed SON option
as they gain more
confidence about multi-
vendor IOT
4 Hybrid Can smoothly integrate
with operators’
practices
Modular: algorithms
can be executed in
different levels of
hierarchy
Allows a high degree of
automation
Lower delay, less
signalling and lower
cost
Favoured in
coordinated networks
Table 2–1 Summary of various SON architectures

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 8
3. SON and SON function

Self-Organising Networks (SON) describes a set of features and capabilities designed

to reduce or remove the need for manual activities in the lifecycle of network
equipment and the services it provides. The SON concepts and terminology described
in the document Enterprise Femtocell Deployment Guidelines [1] are used here to
describe use cases for SON in a small cell urban deployment.

3.1 SON function

This document describes use cases of activities involving SON features, and uses the
term ‘SON function’ to describe the logical entity which provides the algorithms, data
storage and interactions with other nodes to perform SON activities. This term is
deliberately non-specific about where this SON function is located, and thus
encompasses a number of options. That is, this entity could be using the centralized
SON model, the distributed SON model, the hybrid SON model or the localized SON
model, as described in Self-Organizing Networks: Concepts and Requirements [4] and
Section 2. In some of the use cases, it is clear that there must be some distributed
element to the SON function (for example, when SON-related information is to be
exchanged over X2 with other small cells) for the use case to be as described, and in
other use cases it is clear that there must be some centralized SON function (for
example, for holding centralised data and applying central control of multiple small
cells) is inferred.

The use of the term ‘SON function’ is also not specific about how much influence the
small cell SON features may have on the operation of the macrocells. The macrocells
may be totally autonomous, taking no account of the small cell network in their
management of load and interference (and possibly including separate autonomous
macrocell SON functions), or there may be SON function that integrates the SON
features of the small cells with SON features of the macrocells — for example,
balancing the load and interference between all the cells within the network. This level
of interaction clearly affects the complexity and ability of the SON function, but does
not really affect the use cases described here, as each small cell interacts with the
SON function. What that SON function does (except in very broad terms) to arrive at
the configuration or commands given to the small cells (and, where applicable,
macrocells) is outside the scope of this document.

3.2 SON features

The overall SON function may be considered as a set of smaller features, some self-
contained, others interacting with each other. This section describes some of those
constituent SON features. The SON features are broadly classified into three groups:
self-configuration, self-optimization and self-healing. The specific set of features that
goes into each group is captured in detail in the use cases section.

Self-configuration features encapsulate actions and steps wherein newly deployed

nodes get, in an automated fashion, the configuration needed for system operation.
These features are deployed in the pre-operational state. Pre-operational state is
understood as the state from when the eNB is powered up and has Ethernet (or other
LAN) connectivity until the RF transmitter is switched on. As described in Figure 3-1,
steps handled in the pre-operational state — like basic setup and initial radio
configuration — are covered by the self configuration features.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 9
An auto-configuration server (ACS) is defined as the functional entity that enables the
self-configuration process.

Self-optimization features encapsulate all the processes, actions and steps wherein UE
and eNB measurements, event reports and performance measurements are used to
auto-tune the network. These features are deployed in the operational state. The
operational state is understood as the state where the RF interface is switched on and
the cell is providing service to users.

As described in Figure 3-1, functions handled in the operational state — like

optimization/adaptation — are covered by the self-optimization features.

Processes, actions and steps wherein the SON function attempts to diagnose/repair
malfunctioning small cells or optimize the network around a failed small cell are
categorized as self-healing features.

Small Cell power on

( or cable connected )

a- 1 : configuration of IP address
(A ) Basic Setup and detection of ACS

a- 2 : authentication of Small Cell

a- 3 : association to Small Cell GW

Self- Configuration
(pre - operational state) a- 4 : downloading of firmware
( and operational parameters )

(B ) Initial Radio b- 1 : neighbour list configuration

Configuration
b- 2 : coverage/ capacity related
parameter configuration

Self- Optimisation
( operational state )
(C ) Optimization/ c- 1 : neighbour list optimisation

Adaptation
c- 2 : coverage and capacity control

c-3 : self healing

Figure 3-1 SON features

The steps in the figure are representative and not exhaustive. The detailed steps are
brought out in the use cases in the next section.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 10
4. Urban SON use cases

In the following sections the use cases are enumerated into specific categories.
Specifically the topics covered are configuration, planning, deployment and operation,
optimization and maintenance. Care is taken to point out whether the use case
specifically applies to UMTS or LTE or both. Where necessary, inter-frequency issues
but within the same RAT are also highlighted.

The urban and enterprise SON use cases have several scenarios in common. Table 4–1
provides a comparison between urban and enterprise SON use cases where the key
differences are noted.

Scenarios Urban use case Enterprise use case

Activation of a small cell
Adding a new small cell
Adding group of small cells
Decommissioning of a small
cell
Administrative locking of a
small cell
Reactivation of a small cell
Autonomous reactivation of a
small cell
New neighbor discovery
Mode of operation is most likely
open
Section 4.1.1, Table 4-2
Same as enterprise use case
(Section 4.2.1, Table 4-3)
Same as enterprise use case
(Section 4.2.2, Table 4-4)
Same as enterprise use case
(Section 4.2.3, Table 4-5)
The small cell may inform MME
(MSC and SGSN) when it is about
to suspend operation
The SON function may optionally
instruct the macro SON function
when the small cell is about to
suspend operation
The SON function may store SON-
specific parameters along with
geographical location and
surrounding RF characteristics. The
SON function may retrieve SON
parameters if the location and RF
characteristics have not changed
Section 4.2.4, Table 4-6
The small cell may inform MME
(MSC and SGSN) about
reactivation of small cell operation
The SON function may optionally
instruct the macro SON function
about reactivation of small cell
operation
The SON function may store SON-
specific parameters along with
geographical location and
surrounding RF characteristics. The
SON function may retrieve SON
parameters if the location and RF
characteristics have not changed
Section 4.2.5, Table 4-7
Section 4.2.6, Table 4-8
Same as enterprise use case
Mode of operation may
be closed, prioritized to
enterprise users, or open
Section 3.2, Table 3-2
[2]
Section 3.3, Table 3-4
[2]
Section 3.3, Table 3-5
[2]
Section 3.3, Table 3-6
[2]
The small cell may
inform MME or enterprise
small cell gateway, and
any other auxiliary
servers (e.g. PBX).
Section 3.3, Table 3-7
[2]
The small cell may
inform MME or enterprise
small cell gateway, and
any other auxiliary
servers (such as the
PBX)
Section 3.3, Table 3-8
[2]
None
Section 3.3, Table 3-9

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 11
Scenarios
Neighbor deletion
PCI conflict detection and
resolution
Transmit power optimization
Cross-layer load balancing and
interference management
Intra-RAT load balancing
Mobility robustness
optimization
RACH optimization
Inter-RAT mobility robustness
optimization
Inter-RAT load balancing
Energy savings
SON metric and analytics
management
Table 4–1 Comparison of urban and enterprise use cases
Urban use case Enterprise use case
(Section 4.2.7, Table 4-9) [2]
Same as enterprise use case Section 3.3, Table 3-10
(Section 4.2.8, Table 4-10) [2]
Same as enterprise use case Section 3.2, Table 3-3
(Section 4.3.1, Table 4-11) [2]
Same as enterprise use case Section 3.4, Table 3-11
(Section 4.3.2, Table 4-12) [2]
Same as enterprise use case Section 3.4, Table 3-12
(Section 4.3.3, Table 4-13) [2]
Same as enterprise use case Section 3.4, Table 3-13
(Section 4.3.4, Table 4-14) [2]
Same as enterprise use case Section 3.4, Table 3-14
(Section 4.3.5, Table 4-15) [2]
Same as enterprise use case Section 3.4, Table 3-15
(Section 4.3.6, Table 4-16) [2]
Same as enterprise use case Section 3.4, Table 3-16
(Section 4.3.7, Table 4-17) [2]
Same as enterprise use case Section 3.4, Table 3-17
(Section 4.3.8, Table 4-18) [2]
Section 4.3.9, Table 4-19 None
Same as enterprise use case Section 3.5, Table 3-18
(Section 4.4.1, Table 4-20) [2]

4.1 Configuration

4.1.1 Activation of a small cell

Overview A small cell is activated

Actors Small cell, ACS, SON function
Applicability LTE and UMTS
Preconditions An agreed location to site the small cell, power, available backhaul (such as
DSL or P-MP radio), a gateway and ACS/EMS server accessible via the
backhaul. The small cell has been physically mounted and connected to power
and backhaul by an installer or end user. Optionally, the small cell is pre-
configured with the ACS access parameters (an example of which would be IP
address and authentication credentials).
Flow 1. A new small cell is powered on and connected to the IP network
2. If access parameters are not preconfigured then DHCP is used to discover
the ACS
3. The small cell connects to the ACS server; they authenticate each other if
necessary (See Note 2)
4. The ACS server performs initial configurations. Examples of such a
configuration include, but are not limited to, steps such as:
a. New or updated customer-specific firmware download
b. A small cell configuration, which could include network parameters
(such as PLMNID), frequency list, initial transmit power, PSC — or PSC
range — (UMTS) or PCI — or PCI list — (LTE), IP addresses of gateway
or EPC (LTE) etc, initial list of neighbor relations if available, IP or
access details for SON function if necessary, LAC or LAC range (UMTS)
and TAC (LTE) (see note 3)
c. Operating mode. Examples are closed subscriber group (CSG) mode,
open subscriber group (OSG) mode or prioritized OSG mode
5. Starting with the firmware available and using the data given, the small

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 12
Overview A small cell is activated
cell reaches a state where it can set up all the necessary connections and
is authenticated as needed
6. The small cell then proceeds to the startup procedure to start up in an
existing urban network
Uses Adding a new small cell
Notes 1. The initial configuration is within the purview of the ACS server or
(optional) the EMS with only a slight participation from the SON function.
Once in operation state, the SON function may gain control on
many configuration and radio parameters
2. Authentication, if required, should be performed based on
standard specification — for example 3GPP TS 33.310 using
security gateways
3. The proper assignment of LAC/RAC (UMTS) and TAC to a small cell
and how to manage them from a traffic reduction perspective are
discussed extensively in SCF document 088 [6]

Table 4–2 Small cell activation

4.2 Planning, deployment and operation

4.2.1 Addition of a new small cell

Overview A new small cell starts up in an existing urban network

Actors New small cell (NB or eNB), ACS, SON Function, , optional NLM
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated and provisioned small cell in an
operator’s network. A SON function that is provisioned with the proper policies.
Optionally, a functional NLM.
Flow 1. Optionally, NLM is switched on, neighbor network parameters (DL/UL
frequencies, PCI or PSC, existing neighbor PCI/PSC, TX power etc.) are
discovered and NLM data sent to SON function
2. Location verification takes place, using, for example, NLM results and/or
GPS and or technician input geo-location
3. The SON function assigns radio parameters (PCI (list)/PSC (range/list), RSI
etc.) considering any co-channel macro eNodeBs that are visible to the
small cell (taking into consideration any policies provisioned into the SON
function)
4. The small cell connects to the S1u-plane and S1mme-plane elements on
the S1 network (through the enterprise gateway or directly)
5. Optionally, performs TNL address resolution for NLM-discovered and ACS-
provisioned neighbors
6. Optionally, establishes X2 or Iurh links to any neighbors for which it has
TNL addresses (whether discovered or provisioned)
7. The small cell transmitter is turned on and is operational
8. The SON function performs the ‘new neighbor discovery’ sequence for each
cell that it evaluates as a new neighbor
9. The SON function informs any macro SON function, if separate, of the
addition of this small cell to the network
Uses Small cell activation, PCI conflict detection and resolution, new neighbor
discovery
Notes The architectural fit of this small cell within the larger network and how this
(optional) impacts certain provisioning and parameters selections such as RAC/ LAC
(UMTS) and (TAC) LTE are covered in detail in SCF document 088 [6]
Table 4–3 Adding a new small cell

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 13
4.2.2 Addition of a group of small cells

Overview Many new small cells are added to the network at the same time as a
group
Actors New small cells, ACS, SON function, optional small cell gateway, NLM, an IT or
operator technician.
Applicability LTE and UMTS
Preconditions A precise or approximate plan for the deployment of multiple small cells in the
given location. Available power and backhaul for the small cells (such as DSL or
P-MP radio), a gateway and ACS/EMS server accessible via the backhaul. An
installer and/or a technician working for, or under the direction of, the mobile
network operator
Flow 1. The installer/technician places/installs multiple small cells at the positions
identified in the plan for that site
2. The small cells are provisioned with the ACS and SON function details
3. The small cells connect to the ACS and SON function(s), are authenticated,
and obtain their configuration from the ACS
4. As part of configuration, the small cells are configured to belong to a
common cluster and initialized to be in a training mode (see notes 1 and 2)
5. Optionally, NLM is switched on, neighbor network parameters (DL/UL
frequencies, PCI (PSC) etc.) are discovered and NLM data sent to SON
function(s)
6. The SON function(s) can reside in individual small cells, one small cell
and/or an ACS-like server
7. The SON function(s) assigns temporary or permanent radio parameters —
for example, PCI (list) (PSC (range/list)) or RSI, with consideration also to
any co-channel macro (e)NodeBs that are visible to the small cell (taking
into consideration any policies provisioned into the SON function).
8. The small cell connects to the MME (MSC and SGSN) in the EPC (CN)
(through the gateway or directly)
9. Optionally, LTE small cells perform TNL address resolution for NLM-
discovered and ACS-provisioned neighbors or are provided by their SON
functions with neighbor address information
10. Optionally, the small cells establish X2 (Iurh) links to any neighbors for
which TNL addresses are available (whether discovered or provisioned)
11. The small cell transmitters are turned on and small cells begin to operate in
training mode.
12. The installer/technician walks around the site with a UE in connected mode
or with some other tool to collect information about RF environment at the
site (such as signal quality of the small cells or surrounding macros)
13. The collected information is either passed autonomously or with
installer/technician assistance to the SON function(s)
14. At the end of the walk-around, SON function(s) is instructed to determine
transmit power for the small cells
15. The SON function determines TPC parameters using obtained RF
information considering any co-channel macros and UL interference issues
to provide good coverage and capacity at the site
16. The small cells start radiating with the updated Tx power and begin normal
operation
17. Optionally, installer/technician performs additional walk-arounds to verify
coverage and mobility at the site. Based on this second walk-around, SON
function(s) may raise alarms or show error codes suggesting required
changes in the deployment. In such a case, the installer/technician may re-
do the calibration after taking remedial measures
Uses
Notes 1. Training mode is meant to indicate vendor-specific extensions that
(optional) help the equipment (small cell and/or UE) to be put in states that

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 14
Overview Many new small cells are added to the network at the same time as a
group
allow for collection of KPI that can help with deployment decisions
2. Also, as mentioned above, LAC/RAC or TAC lists or parameters
that cannot be auto-configured can be configured at this stage.
See SCF document 088 [6] for more details

Table 4–4 Adding many new small cells

4.2.3 Decommissioning of a small cell

Overview A small cell is decommissioned from an existing network

Actors Small cell, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional or
non-functional small cell in an operator’s network. A SON function that is
provisioned with the proper policies and is in operation
Flow 1. A small cell is taken out of service using the ‘administratively taking a
small cell out of service’ procedure or needs to be decommissioned
because the cell is malfunctioning
2. The SON function is informed by OAM procedure that the small cell is being
permanently decommissioned
3. The SON function adds the reusable resources back to the pool if possible
(such as PCI (PSC), RSI, etc.)
4. Depending upon the mode (OSG/CSG) of the decommissioned cell, the
SON function updates NRT tables appropriately if under its control and
informs the remaining small cells
5. The SON function optionally instructs the remaining small cells to adjust TX
power
6. The SON function optionally instructs the macro SON function if it is
separate (for example, to update its NRT to not include the small cell).
7. The remaining small cells start operating with the updated parameters
Uses Administratively taking a small cell out of service
Notes
(optional)
Table 4–5 Decommissioning a small cell from a network

4.2.4 Administrative locking of a small cell

Overview A small cell in an existing network is suspended from operation by

administratively locking it
Actors Small cell, EMS,SON function,
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional or
dysfunctional small cell in an operator’s network. A SON function that is
provisioned with the proper policies and is in operation
Flow 1. A small cell is instructed to power down by the element management
system (EMS) setting its administrative state to shutting down
2. The small cell shuts down radio functions (not admitting new radio bearers
or waiting for the sessions to end)
3. The small cell may inform the MME (MSC and SGSN)
4. The small cell may inform the (e)NodeB or small cell with which it has X2
(Iurh) connections
5. The small cell informs the SON function, which may store SON-specific
parameters along with geographical location and surrounding RF

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 15
Overview A small cell in an existing network is suspended from operation by
administratively locking it
characteristics for later use (the SON function may retrieve SON specific
parameters if the location and RF characteristics have not changed), and
becomes administratively locked
6. The SON function optionally instructs the macro SON function if it is
separate — for example to remove the SC from the macro NRT
7. The SON function optionally instructs the remaining small cells to adjust TX
power
8. The remaining small cells start operating with the updated parameters
Uses
Notes Geographical location and RF conditions may be obtained by GPS or NLM
(optional) respectively
Table 4–6 Administrative locking of a small cell

4.2.5 Reactivation of a small cell

Overview A small cell is returned to normal operation from an administratively

locked state in an existing network
Actors Small cell, EMS,SON Function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and administratively
locked small cell in an operator’s network. A SON function that is provisioned
with the proper policies and is in operation
Flow 1. A administratively locked small cell is unlocked by the EMS
2. The small cell may inform the (e)NodeB or small cell with which it has X2
(Iurh) connections
3. The small cell may inform the MME (MSC and SGSN) or gateway as
necessary
4. The small cell turns on its transmitters
5. The SON function optionally instructs the remaining small cell to adjust TX
power or does a centralized computation and sends the new powers
6. The SON function optionally instructs the macro SON function if it is
separate
7. The remaining small cell starts operating with the updated parameters
Uses
Notes
(optional)
Table 4–7 Reactivating a small cell

4.2.6 Autonomous reactivation of a small cell

Overview A small cell is returned to normal operation autonomously (self-healing

from an outage) in an existing network
Actors Small cell, Local SON function, optional NLM
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional or
non-functional small cell in an operator’s network. A local SON function that is
provisioned with the proper policies and is in operation. Optionally, a functional
NLM
Flow 1. A small cell is powered down (out of service) due to a mismatched
configuration (such as an outage, unplanned small cell or pervasive
interference).
a. The small cell may issue a reset blindly
b. The small cell is optionally reconfigured with an earlier SW version or

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 16
Overview A small cell is returned to normal operation autonomously (self-healing
from an outage) in an existing network
(backup) configuration loaded in its NE
2. Starting with the firmware available and using the data given, the small cell
reaches a state where it can set up all the necessary connections and is
authenticated as needed
3. The small cell or the SON function may determine if the geographical
location or surrounding RF conditions have changed enough to trigger a
new self-configuration or retrieve previous SON configuration parameters
4. The small cell gathers KPIs/CQI/radio measurements to compute
reconfiguration candidates to compensate for the fault as necessary
5. The small cell may invoke the local SON function to adjust or update any of
the initially (re)configured parameters
Examples of such a configuration include, but are not limited to, steps such
as:
a. Continuously checking if any of the predefined conditions appear that
should trigger the healing process
b. New/updated customer-specific firmware download
c. A small cell configuration, which could include network parameters
(PLMNID etc.), frequency list, initial transmit power, PSC (UMTS) or PCI
(LTE), IP addresses of gateway or EPC (LTE) etc., initial list of neighbor
relations if available, IP or access details for SON function if necessary
6. The small cell may inform the (e)NodeB or small cell with which it has X2
(Iurh) connections
7. The small cell may inform the MME (MSC and SGSN) or gateway as
necessary
8. The small cell adjusts its transmitter and reaches a valid operational state
in which it is able to perform the radio-specific operations for the RAT(s) for
which it is enabled
9. If the fault is not resolved, the self-healing process performs a new local
healing iteration
10. The remaining small cells operate with the updated parameters through
their UEs, NLMs, NEs and/or domain managers (DM)
Uses
Notes Outage can be caused by various anomalies such as mismatched configuration,
(optional) cell out of service, faulty firmware etc.
Geographical location and RF conditions may be obtained by GPS or NLM
respectively
Table 4–8 Small cell returning autonomously to normal service (self-healing)

4.2.7 New neighbor discovery

Overview A small cell in a network discovers a new neighbor

Actors Small cell, SON function, optional NLM, connected UE
Applicability LTE
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Optionally, a functional NLM
Flow 1. A small cell in operation receives from a UE (e.g., A4 even message) it is
serving or from the attached NLM a message containing a PCI value or
from the attached NLM
2. The small cell determines, in comparison to its local NRT, that this is a new
PCI (could be a small cell or a macro cell)
3. The small cell requests the UE to report the ECGI of the newly reported PCI
or recovers this from the NLM
4. The ECGI also confirms a new neighbor
5. The small cell queries provisioning details of this new neighbor from the

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 17
Overview A small cell in a network discovers a new neighbor
EMS/SON server (for example, is handover allowed?)
6. The small cell queries the MME for TNL address resolution
7. The small cell establishes X2 connections as necessary
8. All small cell configurations (NRT) are updated synchronously
9. Any overhead message SIB that might need to be changed due to this new
neighbor is also taken care of by the RRM
Uses
Notes UMTS does not explicitly support automatic neighbor relation discovery.
(optional) Vendor-specific extensions can be used to achieve the same purpose
Table 4–9 Discovering a new neighbor in an LTE network

4.2.8 Neighbor deletion

Overview A small cell in a network along with ACS/SON server determines that
another small cell (or macro) is no longer a neighbor
Actors Small cell, SON function, optional NLM
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Optionally, a functional NLM
Flow 1. A small cell in operation does not receive UE measurements regarding a
PCI (PSC)/(E)CGI for a configurable period of time
2. Alternately the ACS server or SON function decommissions a small cell
3. If it is a measurements/timeout-based determination, then the SON
function determines that another cell is no longer a neighbor
4. The small cell is commanded by the ACS server or SON function to remove
the neighbor
5. The small cell tears down X2 (Iurh) connections if necessary
6. The PCI (PSC) / (E)CGI are removed from the local and global NRT
Uses
Notes As a result of the NRT update, the small cell SIB messages may need to be
(optional) updated by RRM
Table 4–10 Deleting a neighbor in LTE and UMTS

4.3 Optimization

4.3.1 PCI conflict detection and resolution

Overview An existing small cell is assigned a new PCI (PSC) due to discovery of a
PCI (PSC) conflict
Actors Small cell, SON function, optional NLM
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Optionally, a functional NLM
Flow 1. An existing small cell discovers a new neighbor and vice-versa (for
example, through A4 reporting, X2, or NLM)
2. The SON function determines a PCI (PSC) conflict or confusion after these
events
3. Based on the network topology and PCI (PSC) policies (such as the pool of
PCIs (PSCs) available for the small cells), the SON function computes or
selects a new PCI (PSC) value for one or more small cells to avoid the
conflict

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 18
Overview An existing small cell is assigned a new PCI (PSC) due to discovery of a
PCI (PSC) conflict
4. SON function conveys the new PCI (PSC) value(s) to the affected small
cell(s)
5. Each affected small cell performs the procedures needed to have the new
PCI (PSC) take effect
6. The small cell updates its neighbors with the new PCI/PSC value (the SON
function informs the neighbors of the affected small cell with the new
PCI/PSC value)
Uses
Notes
(optional)
Table 4–11 PCI conflict detection and resolution

4.3.2 Transmit power optimization

Overview Small cell transmit power is optimized by SON function

Actors Small cell, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Optionally, a functional NLM
Flow 1. The small cell measures or tracks various L1/L2/L3 metrics (for example
load or handover statistics or RACH attempts, pilot pollution, etc.)
2. The small cell forwards these to the SON function
3. The SON function determines that a change in transmit power is necessary
4. The SON function conveys the new transmit power value to the small cell
5. The small cell configuration is updated and any data synchronization or
procedures that are needed to switch to the new transmit power are
initiated — potentially with involvement from the ACS server or EMS
6. The small cell becomes operational with the new transmit power
Uses
Notes
(optional)
Table 4–12 Optimization of small cell transmit power

4.3.3 Cross-layer load balancing and interference management

This use case addresses load balancing across macro and small cell layers, in
particular using some of the methods available in LTE. Based on the load metrics
available from both layers, the SON function could allow UEs to camp on small cells
preferentially for macro offload. However this needs to be coordinated with
appropriate resource reservation/assignment of protected resources on small cells to
manage interference and enable reliable connections to these UEs. To achieve this, a
SON function can determine several parameters including RSRP bias to small cells,
time domain (ABS) and possibly frequency domain resource partitions.

Overview Small cell and macro partition resources to help balance load and
manage co-channel interference
Actors Small cell, macro, SON function, optional NLM
Applicability LTE
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Optionally, a functional NLM. Small cell(s) is
deployed in the same frequency as macros. For time domain partitioning,

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 19
Overview Small cell and macro partition resources to help balance load and
manage co-channel interference
macros and small cells need to operate synchronously
Flow 1. The SON function determines that the mall cell is co-channel with macro
(for example, via NLM measurements and/or configuration parameters)
2. The SON function determines the resource partitioning pattern between the
small cell and macro, and conveys it to the macro and small cell. The SON
function may also determine configuration and control parameters, (for
example, reporting periods and RSRP thresholds for eICIC/ICIC in the
macro and small cell)
3. Alternatively (to step 2),
a. Small cell(s) establishes X2 link to co-channel macro and
exchanges traffic load information with macro or SON function.
b. Macro or SON function determines the appropriate resource
partitioning pattern and conveys this to the small cell or macro
4. Resource partitioning can be achieved by utilizing standard-defined
procedures in time domain (such as eICIC) and/or frequency domain
(again such as ICIC).
5. Load balancing can be achieved by increasing the coverage of small cells
using cell range expansion (for example, conveying handover offsets)
6. The determination of the partitioning pattern can be based on expected
traffic load on the macro and small cell, past traffic history, or some other
configuration policy
7. The small cell follows the resource partitioning pattern for scheduling its
users
Uses
Notes
(optional)
Table 4–13 Load and co-channel interference management with macro network

4.3.4 Intra-RAT load balancing

Overview Small cells in a network balance load

Actors Small cell, SON function, EMS
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation
Flow 1. The small cells in operation measure their own traffic load level (see note
1) and report to the SON function
2. The SON function reviews the load level of the small cells (note 2) and
determines whether certain small cells are overloaded based on available
air interface or backhaul resources
3. Optionally, the SON function reviews the load level of the overlapping
macrocells
4. The SON function conveys its decision/configuration to the small cells to
perform SON activities. For example,
a. Adjusting the cell selection/ reselection and handover parameters on
the small cells to offload some traffic from busy small cells to less busy
neighboring small cell(s) (mobility load balancing (MLB) (see note 3))
b. Adjusting its coverage through transmit power adjustment
5. Optionally, the SON function conveys updated configuration to the macro-
cell SON function, if it is different
Uses
Notes 1. It is a normal RRM function to handle instantaneous overload by doing one
(optional) or more of the following:

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 20
Overview Small cells in a network balance load
a. Stopping new user admission
b. Reconfiguring existing bearers to reduce their load
c. Termination of low priority user services to serve higher priority users
It is expected that RRM will provide general load information as well as
specific overload information to the SON function to allow it to optimize the
load handling of small cells. The SON function is expected to consider such
a load or loads across many small cells on a timescale that is significantly
longer than that of the instantaneous overloads caused by individual
service requests to individual small cells
2. Small cells may also exchange load information over X2 where a cell can
get to know loading of neighbor cells
3. Although MLB is LTE-specific, the equivalent activity in UMTS could be
achieved by the SON function adjusting the handover parameters of the
small cells through the EMS
4. SCF document 088 [6] discusses the different options for cross-layer load
balancing for both UMTS and LTE and how these may be impacted by idle
mode camping configuration. Opportunities for load balancing using idle
mode, idle-to-active transitions and active-to-active based handover are
discussed
Table 4–14 Intra-RAT load balancing

4.3.5 Mobility robustness optimization

Overview SON function optimizes for mobility robustness

Actors Small cells, EMS, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation
Flow 1. Handover metrics and KPI are made available to the SON function
2. Optionally, instantaneous and averaged radio environment metrics are also
available to the SON function
3. Optionally, instantaneous and averaged load and resource usage metrics
are available to SON functions
4. The SON function decides to increase or decrease the handover footprint
(idle mode and connected mode) of a small cell to other small cells in the
same RAT, other RATs or to the macro through updated parameters (such
as A3 frequency, cell specific offsets or time-to-trigger) as well as increase
or decrease the chance of ping-pong or frequent handovers through
hysteresis parameter controls
5. The small cell configuration is updated if necessary and any data
synchronization or procedures that are needed to switch to the new
parameters are initiated — potentially with involvement from the EMS
6. The small cell becomes operational with the new parameters
Uses
Notes Sufficient handover statistics need to be available to avoid reacting to unusual
(optional) situations. This implies that the collection of the statistics should cover
sufficiently long periods, especially if the population of UEs covered by the
small cell is low [3]
Table 4–15 Mobility robustness optimization

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 21
4.3.6 RACH optimization

Overview SON function optimizes RACH parameters

Actors Small cell, EMS, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation
The small cell is operational and has the ability to admit new users or allow
handovers from other small cells or the macro. Access metrics are available to
the SON function (such as average number of preambles, or average of open
loop power for successful access)
Flow 1. The SON function aggregates access metrics (including parameter
exchange over X2)
2. The SON function determines to change RACH parameters to change RACH
resources — for example, power ramping step and the maximum number
of preamble transmissions. In LTE, the SON function may choose to change
open-loop metrics for contention based access
3. New parameters are sent to the small cell
4. The small cell configuration is updated if necessary and any data
synchronization or procedures that are needed to switch to the new
parameters are initiated — potentially with involvement from the EMS
5. The small cell becomes operational with the new parameters
6. Note that RACH parameter optimization may also be performed when small
cell Tx power is changed (for example, for load balancing or coverage
optimization)
Uses
Notes The SON function may also aggregate metrics from a macro layer and use
(optional) these in the determination step used to change RACH parameters.

Table 4–16 RACH optimization

4.3.7 Inter-RAT mobility robustness optimization

Overview Mobility robustness optimization between LTE and UMTS

Actors Small cell, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation
Multiple overlay deployments of LTE and/or UMTS small cells and/or dual mode
small cells
Flow Small cells in operation detect scenarios of handover failures (early handover
or late handover, for example). These failures may be related to inter-RAT
handovers between UMTS and LTE. These failures are reported to the SON
function.
The SON function reviews the failure information and determines whether
handover parameters need to be modified. Specifically, the SON function
determines whether handover triggers on the small cells need adjustment (and
if so by how much)
The SON function conveys its decision/configuration to small cells to perform
the changes
Uses
Notes Sufficient handover statistics need to be available to avoid reacting to unusual
(optional) situations. This implies that the collection of the statistics should cover
sufficiently long periods, especially if the population of UEs covered by the

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 22
Overview Mobility robustness optimization between LTE and UMTS
small cell is low [3]
Table 4–17 SON mobility robustness optimization between LTE and UMTS

4.3.8 Inter-RAT load balancing

Overview Load balancing between LTE and UMTS

Actors Small cell, SON function

Applicability LTE and UMTS

Preconditions A properly situated, connected, authenticated, provisioned and functional small

cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation. Multiple overlay deployments of LTE and/or
UMTS small cells and/or dual mode small cells

Flow 1. The small cells in operation measure their own traffic load and interference
levels and report to the SON function. The load reports and triggers may be
separately defined for inter-RAT load balancing functionality.
2. The SON function reviews RAT/frequency-specific load information of the
small cells and determines whether certain small cells are overloaded
and/or heavily interfered based on available air interface or backhaul
resources
3. The SON function conveys its decision/configuration to small cells to
perform SON activities
Adjust the related inter-RAT handover parameters on small cells to offload
some traffic from busy small cells to less busy small cell(s) on a different RAT

4. The SON function also determines whether idle-mode load balancing is

required. It sets the appropriate cellReselectionPriorities and idle mode
reselection offsets to direct the idle mode UE to attach to the desired RAT
and layer (See note 2)
Uses

Notes 1. SON function may also aggregate load metrics from a macro layer and use
(optional) these to determine handover parameters for the small cells
2. The architectural and procedural support for inter-RAT connected and idle-
mode load balancing are discussed in detail in sections 3.1.2 and 3.3.1.1 of
SCF document 088 [6]
Table 4–18 Inter-RAT load balancing

4.3.9 Energy savings

Overview Small cell energy saving (ES) by centralized or distributed SON

function
Actors Small cell, ACS, EMS, SON function
Applicability LTE and UMTS
Preconditions A properly situated, connected, authenticated, provisioned and functional small
cell in an operator’s network. A SON function that is provisioned with the
proper policies and is in operation
Flow 1. The small cell optionally reports its power draw to the SON function
2. The small cell measures or tracks various metrics (traffic, handover
statistics, RACH attempts etc.)
3. The small cell forwards the gathered information to the SON function
4. The SON function determines, in a coordinated manner over multiple cells

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 23
Overview Small cell energy saving (ES) by centralized or distributed SON
function
or locally to a single cell, energy saving actions that may be appropriate
5. Based on the coordinated or local optimization, the SON function instructs
either certain cells or the local cell to switch themselves (or itself) off, enter
into a dormant state, initiate a change in TX power, change the number of
antennas (MIMO configuration), change the number of carriers and so on to
minimize power consumption without any fault or compromising user
perception
6. The small cell configuration is updated and any procedures that are needed
to switch to the configuration are initiated
7. KPIs can be used to monitor the performance of the ES actions
8. The changes are optionally communicated to the ACS server, EMS (OAM)
9. The small cell(s) becomes operational with the new energy-saving
efficiency configuration
Uses
Notes
(optional)
Table 4–19 Energy saving by centralized, distributed or local SON function

4.4 Maintenance

4.4.1 SON metrics and analytics management

Overview Registered agents PUSH/PULL SON metrics

Actors Small cell, SON function
Applicability LTE and UMTS
Preconditions Agents are registered with the SON function and the interfaces are well known
Flow 1. The SON function sends instantaneous or aggregated performance metrics
(PM), diagnostic metrics (DM) and configuration metrics (CM) to agents
that are registered to receive them
2. Optionally, the registered agent acknowledges receipt of these
Uses
Notes These agents might be instantiated for dashboarding or for providing real-time
(optional) or near-real-time views to the service provider regarding the optimized
operation and can be used as a basis for operator intervention or policy
updates etc
Table 4–20 Dissemination of SON metrics

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 24
5. Summary

Urban deployments will be a key part of small cell deployments and therefore a key
part of small cell adoption and their success. SON functions are especially important in
making the planning, deployment, optimization and management of these urban
networks streamlined, so that they function the best they can — more so, in fact, than
in the enterprise case. If solutions meet the baseline use cases in this document, this
goal can be met.

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 25
References
1 ‘Enterprise Femtocell Deployment Guidelines, Femto Forum Working Group 2
document’, April 8th 2011, Femto Forum WG2
2 [SCF066] ‘Enterprise SON Use Cases Document’, Small Cell Forum
3 ‘LTE Self-Organizing Networks’, Seppo Hamalainen et al, Wiley
4 ‘3GPP TS 32.500: Self-Organizing Networks: Concepts and Requirements’, 3GPP
5 ‘Self-Optimizing Networks in Release 11: the Benefits of SON in LTE’, 4G
Americas, October 2013
6 [SCF088] ‘Urban Small Cell Network Architectures’, Small Cell Forum

Report title: Urban SON use cases

Issue date: 25 February 2014
Version: 077.07.01 26