3rd Generation Partnership Project;

Technical Specification Group Services and System Aspects;

3GPP TR 32.836
Telecommunication management;
V12.0.0 (2014-09)
Study on Network Management (NM) centralized
Technical Report
Coverage and Capacity Optimization (CCO)
Self-Organizing Networks (SON) function
(Release 12)

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Report is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.
Release 12 2 3GPP TR 32.836 V12.0.0 (2014-09)

Keywords
Management, Self-Optimization, SON, Coverage,
Capacity

3GPP

Postal address

3GPP support office address

650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Internet
http://www.3gpp.org

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© 2014, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

3GPP
Release 12 3 3GPP TR 32.836 V12.0.0 (2014-09)

Contents
Foreword...................................................................................................................................................5
Introduction...............................................................................................................................................5
1 Scope..............................................................................................................................................6
2 References.......................................................................................................................................6
3 Abbreviations..................................................................................................................................7
4 NM centralized CCO function........................................................................................................8
4.1A Function cycle and division into stages.................................................................................................8
4.1 Architecture.................................................................................................................................................9
4.2 Examples of CCO use cases........................................................................................................................9
4.2.1 General..................................................................................................................................................9
4.2.2 Downlink coverage map......................................................................................................................10
4.2.3 Use case 1: Cell coverage adapting to traffic demand........................................................................10
4.2.4 Use case 2: Coverage and accessibility...............................................................................................12
4.2.5 Use case 3: LTE coverage holes with underlaid UTRAN/GERAN....................................................12
4.2.6 Use case 4: LTE Connection failure....................................................................................................14
4.2.7 Use case 5: Radio link quality.............................................................................................................15
5 UE and network measurements.....................................................................................................15
5.1 General......................................................................................................................................................15
5.2 E-UTRAN measurements.........................................................................................................................15
5.2.1 UE measurements................................................................................................................................15
5.2.1.1 Connected mode measurements.....................................................................................................15
5.2.1.2 Idle mode measurements...............................................................................................................16
5.2.2 Network measurements.......................................................................................................................17
5.2.2.1 UE specific.....................................................................................................................................17
5.2.2.2 Non-UE specific............................................................................................................................17
5.3 UTRAN measurements.............................................................................................................................17
5.3.1 UE measurements................................................................................................................................17
5.3.1.1 Connected mode measurements.....................................................................................................17
5.3.1.2 Idle mode measurements...............................................................................................................17
5.3.2 Network measurements.......................................................................................................................17
5.3.2.1 UE specific.....................................................................................................................................17
5.3.2.2 Non-UE specific............................................................................................................................17
5.4 Aggregation of measurements...................................................................................................................18
5.4.1 General................................................................................................................................................18
5.4.2 PM measurements...............................................................................................................................18
5.4.3 Method for triggering measurements for PM purposes.......................................................................18
6 User privacy and anonymization...................................................................................................18
6.1 General......................................................................................................................................................18
6.2 Privacy requirements by SA3....................................................................................................................19
6.3 Solution descriptions.................................................................................................................................19
7 Correlation of measurements........................................................................................................19
7.1 Description of functionality......................................................................................................................19
7.2 Solution descriptions.................................................................................................................................20
7.2.1 Correlate RLF/RCEF and MDT data..................................................................................................20
7.2.1.1 Correlation at the eNB Scenarios...................................................................................................20
7.2.1.1.1 Issues with correlation of Immediate MDT and RLF reports..................................................20
7.2.1.1.2 Issues with correlation of Immediate MDT, RLF and RCEF reports......................................23
7.2.1.1.3 Issues with correlation of Logged MDT and RCEF report......................................................25
7.2.1.2 Correlation at the TCE scenarios...................................................................................................26
7.2.1.2.1 Introduction..............................................................................................................................26
7.2.1.2.2 Correlation of Immediate MDT and RLF reports....................................................................27
7.2.1.2.3 Correlation of Logged MDT and RCEF reports......................................................................29

3GPP
Release 12 4 3GPP TR 32.836 V12.0.0 (2014-09)

7.2.1.2.4 Correlation of Immediate MDT and RLF/RCEF reports based on MME mapping mechanism31
7.3 Evaluation of correlation solution.............................................................................................................33
8 Measurement collection mechanism.............................................................................................33
9 Configuration attributes................................................................................................................33
10 Recommendations.........................................................................................................................34
10.1 CCO for GERAN......................................................................................................................................34
10.2 Method for triggering measurements for PM purposes............................................................................34
10.3 Correlation of data.....................................................................................................................................34
10.4 Optimisation cycles...................................................................................................................................34

Annex A: Change history...............................................................................................................35

3GPP
Release 12 5 3GPP TR 32.836 V12.0.0 (2014-09)

Foreword
This Technical Report has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

Introduction
Optimization of the coverage and capacity performance of the network represents an important Self-Organizing
Networks (SON) use case, which requires appropriate support functions in the 3GPP specifications.
The present document studies Network Management (NM) centralized Coverage and Capacity Optimization (CCO)
SON function with the focus on necessary support in the 3GPP specifications.

The NM centralized CCO function would help operators in reducing OPEX related to the maintenance and optimization
of network coverage and capacity by automating these functions.
NM centralized CCO function would observe network coverage and capacity performance, automatically detect
problems and intervene with necessary actions or raise a notification toward the operator, when operator action is
needed.

3GPP
Release 12 6 3GPP TR 32.836 V12.0.0 (2014-09)

1 Scope
The present document summarizes the result of the study on "Enhanced Network Management (NM) centralized
Coverage and Capacity Optimization".

A CCO function that resides outside the NM is out of the scope for this study.

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".

[2] 3GPP TS 37.320: "Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial
Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT);
Overall description; Stage 2".

[3] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRAN); Radio Resource
Control (RRC) Protocol specification".

[4] 3GPP TS 36.213: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer
procedures".

[5] 3GPP TS 36.214: "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer;
Measurements".

[6] 3GPP TS 32.425: "Telecommunication management; Performance Management (PM);

Performance measurements Evolved Universal Terrestrial Radio Access (E-UTRAN)".

[7] 3GPP TS 32.422: "Telecommunication management; Subscriber and equipment trace; Trace
control and configuration management".

[8] 3GPP TS 36.133 "Evolved Universal Terrestrial Radio Access (E-UTRA); Requirements for
support of radio resource management".

[9] 3GPP TS 36.305: "Evolved Universal Terrestrial Radio Access Network

(E-UTRAN); Stage 2 functional specification ofUser Equipment (UE) positioning in E-UTRAN"

[10] 3GPP TS 36.321: "Evolved Universal Terrestrial Radio Access (E-UTRA) Medium Access
Control (MAC) protocol specification".

[11] S3-130559 "LS on Applying user consent for SON use cases"

3GPP
Release 12 7 3GPP TR 32.836 V12.0.0 (2014-09)

3 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply.
An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any,
in TR 21.905 [1].

C-RNTI Cell Radio Network Temporary Identity

CCO Coverage and Capacity Optimization
E-DCH Enhanced Dedicated Channel
GNSS Global Navigation Satellite Systems
HOF Handover Failure
OPEX Operating Expenditures
SINR Signal to Interference and Noise Ratio
RCEF RRC Connection Establishment Failure
RLF Radio Link Failure
TAC Type Allocation Code
TCE Trace Collection Entity
TR Trace Reference
TRSR Trace Recording Session Reference

3GPP
Release 12 8 3GPP TR 32.836 V12.0.0 (2014-09)

4 NM centralized CCO function

4.1A Function cycle and division into stages
NM centralised SON function like CCO needs to be divided into 3 different stages:

1. Monitoring the network

2. Detailed improvement analysis

3. Improvement action

Detailed
Monitoring improvement
analysis

Improvement
action

Figure 4.1A-1: NM Centralized CCO function stages

Monitoring is constantly active and monitors the whole network all the time to find potential improvements. This is
done by using performance monitoring. For the monitoring step to detect improvement possibilities there is no need to
continuously report fine granular detailed information, since at this stage it is wanted to detect the existence of the
improvement opportunity and not necessarily the exact location and reason of the improvement opportunity. This
allows aggregations in PM measurements (e.g., in space and time), which makes the continuous monitoring scalable for
the whole network without losing the detection capability.

Detailed improvement analysis may be activated for the area where monitoring has detected an improvement
opportunity in order to do a more fine grained assessment of the improvement possibility and its localisation. This is
done by using a fine grained detection function/tool, e.g. MDT with periodic measurements.

Improvement action will determine and apply specific improvement action(s). The action may be to reconfigure some
cell parameters, e.g. output power. To reconfigure any attribute, the existing CM operations over Itf-N are reused. When
no automated corrective action can be applied, the CCO function may provide information to the operator that a new
base station site may be installed in the area where an improvement is needed.

3GPP
Release 12 9 3GPP TR 32.836 V12.0.0 (2014-09)

4.1 Architecture
The logical architecture that applies in case of NM centralized CCO SON function is shown in Figure 4.1-1.

Figure 4.1-1: NM Centralized CCO function logical architecture

The NM centralized CCO function needs to monitor the network and collect UE and network measurements.
Based on the analysis of received data the CCO algorithm may identify potential coverage or capacity problems or
improvement possibilities and may execute change of network configuration accordingly.
The CCO function may also provide information to the operator about the executed changes, performance
improvements or indications where some operator interaction is needed.

4.2 Examples of CCO use cases

4.2.1 General
Coverage and capacity are two closely related characteristics of a cellular network, which largely determine the network
capabilities in terms of providing a certain grade of service for a given number of customers in a given geographical
area and on a given set of radio spectrum. In order to utilize cell resources in the most efficient way and to serve as
many customers as possible with the required level of service, there is a need to configure cell resources according to
the actual radio conditions, propagation environment and traffic needs.

Such an optimization process should be automated with no or minimal manual intervention and has to be based upon
actual network conditions, i.e. measured data obtained from UEs and from the network.
Looking for coverage holes or finding capacity improvement potentials manually is particularly time consuming, costly
and requires expert knowledge. Therefore, an automated CCO function can significantly contribute to OPEX reductions
and at the same time respond to coverage or capacity problems faster and with better solutions than any human based
manual method may provide.

As all use cases in this document are NM centralised, they are only able to address long optimisation cycles (5 minutes
or longer). This means that optimisation in or near real time is excluded.

3GPP
Release 12 10 3GPP TR 32.836 V12.0.0 (2014-09)

4.2.2 Downlink coverage map

To do the detection of coverage and capacity problems, the geographical area could be divided into bins.
One of possible creation ways of bins is that the bins could be created by dividing the geographical area using lines of
longitude and latitude, this does not imply that the performance measurements and MDT data have to be reported
directly with the information of longitude and latitude. Using MDT measurements (RSRP for E-UTRA, UE location
information, etc., see 3GPP TS 37.320 [2]) and some network performance measurements related to the bins, the CCO
function could know the coverage situation of the target region by coverage map and do the optimization later.
The accuracy of coverage problem detection and effectiveness of optimization depend on several factors, such as the
size and number of bins, the accuracy of MDT and network measurement data, and the number of MDT UEs.

A downlink coverage map example is shown in figure 4.2.2-1:

Target CCO optimization region (the cells area covered by eNB a and b) is divided into many bins and marked by
different colours that show the corresponding signal strength (e.g. cell downlink RSRP).

Figure 4.2.2-1 Target CCO optimization region divided into bins with different colours
that show corresponding cell downlink signal

If a downlink or uplink coverage map (signal strength and/or signal quality e.g. RSRP and/or RSRQ) using bins is to be
created, UE measurements and the UE locations must be activated in all cells in the area where the map is wanted. If it
is used for monitoring, the map needs to show the whole network. The creation of the bins and measurements can be
made either in the NM CCO function or in the RAN nodes (RNC or eNB). The bins can also be created in the DM/EM
fully or partially (e.g. via data pre-processing below Itf-N).

To create the bins in the NM CCO function means that the UE measurements and the location information are
forwarded to a TCE that is used by the NM CCO function, using the MDT mechanism.

To create the bins in the RAN nodes means that the UE measurements and the location information retrieved from one
or more MDT session(s) are kept in the RAN node, where they are converted to performance measurements that are
transferred to NM CCO function.

4.2.3 Use case 1: Cell coverage adapting to traffic demand

Cell coverage is typically decided at time of network planning, where exact distribution of users is hard to take into
account. However, the service performance as seen by the user will depend among others on the traffic load in the
particular cell, e.g. on the number of users that has to share the cell resources at a particular location. Therefore, there
may be a need to adapt cell sizes to the typical distribution of traffic demand from time to time when the distribution of
users or the environmental situation are changing (e.g. rush hours).

3GPP
Release 12 11 3GPP TR 32.836 V12.0.0 (2014-09)

The NM centralized CCO function needs to detect such service performance problems caused by load imbalances, for
which it may need to collect for example, information about number of active UEs, IP Throughput, Packet Delay, Drop,
Loss Rate, Data Volume measurements and environmental information (e.g. the location of freeway, stadiums). The
NM centralized CCO function may also collect information of the used / available capacity estimated by the eNB itself,
based on resource management algorithms implemented in the eNB. Such estimation can be expressed for example in
percent of total cell capacity over certain time interval.

It is FFS how capacity information can improve this use case and whether existing measurements can be reused.

Based on the collected information, the CCO function may decide to adjust capacity or coverage areas of the related
cells.

Figure 4.2.3-1 shows a possible way to indicate that the UE distribution can be monitored periodically by two
dimensional bins measurements, which are created by TADV and AOA measurements reported by connected mode UE
(see clause 10.2 and 10.3 of TS 36.133 [8]).

Figure 4.2.3-1 Two dimensional bin measurements

The UE distribution in a cell can be obtained from the 2D bin measurements shown below:

Measurement description:
This measurement provides two dimensional bins to monitor the UE distribution across geographical area (e.g. in a
cell). The two dimensional bins are formed from Timing Advance (TADV) and Angle of Arrival (AOA) (See Ref.
3GPP TS 36.133 [8]),
where TADV = 1) NTA – for UEs that are uplink timing aligned (TS 36.213 [4])
2) 11 bits Timing Advance value – for UEs that are not uplink timing aligned (TS 36.321 [10])
AOA (TS 36.133 [8]) = measured on any part of the uplink transmission, such as user data frame or
PRACH, or via Sounding Reference Signals

Collection method:
Cumulative counter triggered by the occurrence of the measured event

Condition:
The bin counter identified by TADV and AOA is incremented by 1. The 2D bins are identified by index x
(representing TADV) and y (representing AOA).
When (in any order):

3GPP
Release 12 12 3GPP TR 32.836 V12.0.0 (2014-09)

a) eNB sends11 bits or 6 bits Timing Advance value to an UE, the TADV of such UE is obtained.
and
b) eNB estimates its AOA via the uplink transmission of the UE.

Note:
1. A sectorized cell will only use a subset of index y. For example, for 3-sector cells, the index y can be (0..3),
(4..7), or (8..11), corresponding to each sector.
2. This measurement is only valid for eNodeB capable of estimating the AOA.

Measurement result:
Each measurement (as defined in x-y) is an integer value.

Measurement type:
MR.UeDistribution.xy, where, x and y are integers within implementation specific ranges

Table illustrating an example implementation with x and y ranges [0..10]:

Index x – TADV Index y – AOA (Unit Degree °)

(Unit Ts) 0 1 2 3 4 5 6 7 8 9 10 11
0°- 30°- 60°- 90°- 120°- 150°- 180°- 210°- 240°- 270°- 300°- 330°-
30° 60° 90° 120° 150° 180° 210° 240° 270° 300° 330° 360°
0 0 TADV< 48
1 48 TADV< 96
2 96 TADV< 144
3 144 TADV< 192
4 192 TADV< 288
5 288 TADV< 384
6 384 TADV< 576
7 576 TADV< 768
8 768 TADV< 960
9 960 TADV< 2048
10 2048 TADV

4.2.4 Use case 2: Coverage and accessibility

Typically, the network has to provide basic coverage that ensures accessibility and connectivity. Basic coverage could
mean, for example, that a certain level of signal strength should be reached in the cell area and accessibility attempts,
i.e. RRC connection attempts and random access attempts must reach certain level of success rate.
The NM centralized CCO function may collect RSRP/RSRQ measurements (with or without location information
included), RLF events, RRC setup failure reports and random access performance measurements, which could be
indications of bad coverage. To further separate uplink and downlink related coverage problems, uplink interference,
signal quality and power measurements may be used. The different types of reports related to the same incident and user
should be possible to be correlated so the CCO function can identify the source of the problem and can take the right
corrective action. A potential way is the correlation of uplink and/or downlink MDT data (e.g., M2, M3, etc.) and RLF
report data (e.g., RSRP/RSRQ, etc.) may be used to analyze whether the RLF is caused by uplink coverage problem.

4.2.5 Use case 3: LTE coverage holes with underlaid UTRAN/GERAN

LTE is typically deployed in areas with dense population in an attempt to mitigate traffic congestion during the peak
hours. Therefore, initial LTE deployment may be patchy with underlaid UTRAN/GERAN networks that provide basic
coverage. Figure 4.2.5-1 shows that there may be coverage holes between LTE cells.

3GPP
Release 12 13 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 4.2.5-1: LTE coverage holes with underlaid UTRAN/GERAN

The LTE coverage holes may be detected by the Inter-RAT measurements. The network can capture measurements (e.g.
RSRP, RSRQ, cell ID, location, time stamp at the time of Inter-RAT handover), which can be collected for the CCO
function and used to identify coverage holes in the LTE network.

The LTE coverage holes may be detected also using measurements performed by UEs in the idle mode.
When an UE is in "any cell selection" or "camped on any cell" state, the periodic logging stops.
When the UE re-enters "camped normally" state and the duration timer has not expired, the periodic logging is restarted
(clause 5.1.1.2 of 3GPP TS 37.320 [2]).
Figure 4.2.5-2 is an example to show that an LTE coverage hole can be detected when an UE stops and resumes logging
MDT measurements.

Figure 4.2.5-2: LTE coverage holes detected by logged MDT

3GPP
Release 12 14 3GPP TR 32.836 V12.0.0 (2014-09)

4.2.6 Use case 4: LTE Connection failure

While in idle mode UE enters an area of coverage problems (such as weak coverage, overshoot coverage, pilot pollution
and DL and UL channel coverage mismatch etc.), the UE attempts to establish the RRC connection but fails (RCEF
report is logged).

Figure 4.2.6-1 Correlation of RCEF with MDT data

Another case is when the UE is in connected mode, loses the connection and then tries to reconnect to the network but it
fails.

Figure 4.2.6-2 Correlation of RLF and RCEF with MDT data

In both cases the CCO function would need to identify the reason of failure, for which it may need to combine the
logged RCEF report with other measurement data, potentially including also measurements made by the RAN or with
other incidents and measurements reported by the UE (e.g. RLF report, RSRP/RSRQ reports, etc.).

3GPP
Release 12 15 3GPP TR 32.836 V12.0.0 (2014-09)

For detailed analysis of connection failures and Coverage and Capacity Optimization, all the different pieces of
information connected to the occurrence of the same incident need to be combined, and the combined data will be used
by the CCO function.

For detailed analysis of connection failures and CCO, information may be required about the radio conditions of the
network prior to and at the moment when the connection failure occurs. In E-UTRAN this data may be collected e.g. by
utilizing the potentially enhanced Logged MDT and/or immediate MDT procedures depending on the specific failure
scenario.

4.2.7 Use case 5: Radio link quality

The service performance (e.g. throughput) as seen by the user is largely dependent on the quality of the radio link (e.g.
CQI 3GPP TS 36.213 [4]), which is influenced by signal strength, interference, and other conditions.
It should be possible for the NM centralized CCO function to collect information about the radio quality combined with
user performance (e.g. IP throughput, CQI, UL SINR) and determine whether the radio link is a bottleneck in service
performance. The CCO function may decide to change the signal strength of the investigated cell or that of an
interfering nearby cell e.g. by modifying antenna tilt or power settings in order to improve radio link quality.

The CQI can be used as a direct indicator of the Signal to Interference and Noise Ratio (SINR) conditions seen by the
UE at actual data transmissions, for which neither RSRP nor RSRQ (see 3GPP TS 36.214 [5]) would be suitable. Note
that RSRP is indicative only to the signal strength of the Reference Symbol (RS), while RSRQ is derived from RSRP as
the ratio of RSRP versus RSSI (i.e. total received signal power in the RSSI measurement bandwidth), which is not equal
to SINR. Moreover RSRP and RSRQ are measured separately from actual user plane transmissions, while CQI is
measured and reported when data is actually transmitted.

For example, by observing the UE reported CQI values during a collection period (similarly to the collection period as
used in case of existing MDT measurements) it is possible to determine whether the UE was in a poor radio condition at
that time. Although the instantaneous CQI value is influenced by fast link variations (e.g. by fast fading), the fast
fluctuations are typically around some centre value, which is characteristic to the particular radio environment and can
be used by the CCO function to evaluate radio link quality.

Collecting the UE reported Rank Indicator (RI) in a similar way could be used to evaluate radio link quality from spatial
multiplexing point of view. The RI reports give information about whether the UE has found the radio link quality good
enough to use spatial multiplexing.

5 UE and network measurements

5.1 General
The NM centralized CCO function needs to collect various measurements for its operation.
The set of necessary measurements contains already standardized measurements, as well as, new measurements.
The measurements can be statistical measurements such as PM measures or UE and network measurements or events,
for example, MDT measurements. Existing measurements are indicated with names and references to specifications
where they are specified.

5.2 E-UTRAN measurements

5.2.1 UE measurements

5.2.1.1 Connected mode measurements

- Signal strength and quality measurements: RSRP/RSRQ measurements by UE, same as used also for MDT, see
3GPP TS 37.320 [2] and references therein.

- Accessibility measurements: including the accessibility measurements by UE, as defined for MDT, see
3GPP TS 37.320 [2] and references therein.

3GPP
Release 12 16 3GPP TR 32.836 V12.0.0 (2014-09)

- Radio link failure reports: as defined in 3GPP TS 36.331 [3].

- Location information – GNSS reports: including GNSS coordinates when reported by the UE in MDT
measurements, see 3GPP TS 32.422 [7] and 3GPP 37.320 [2].

- Location information – Timing reports: including UE rx-tx time difference when reported by the UE in MDT
measurements, see 3GPP TS 32.422 [7] and 3GPP 37.320 [2].

- UE reported CQI: The distribution of UE reported CQI values, as defined in 3GPP TS 36.213 [4], to be collected
per collection period. The CQI samples reported for single stream transmission (i.e. CQI for single codeword)
and for spatial multiplexing transmission (i.e. CQI for multiple codewords) shall be collected separately, in
separate distributions.

- UE reported RI (Rank Indicator): The distribution of the UE reported Rank Indicator, as defined in
3GPP TS 36.213 [4], to be collected per collection period.

5.2.1.2 Idle mode measurements

- Logged measurements for the serving cell as well as the Intra-frequency, Inter-frequency and Inter-RAT
neighbouring cells (see clause 5.1.1.3.3 of 3GPP TS 37.320 [2]).

3GPP
Release 12 17 3GPP TR 32.836 V12.0.0 (2014-09)

5.2.2 Network measurements

5.2.2.1 UE specific
- Power headroom measurement: as defined for LTE M2 MDT measurement, see 3GPP TS 37.320 [2] and
references therein.

- Scheduled IP throughput measurements (UL/DL): same as measurements used for MDT,

see 3GPP TS 37.320 [2] and references therein.

- Location information – Timing reports: eNB rx-tx time difference measurements, when available in the network,
see 3GPP TS 32.422 [7] and 3GPP TS 37.320 [2].

- Measurements related to LTE Inter-RAT handover: existing Immediate MDT UE measurements (i.e. RSRP,
RSRQ, with corresponding cell ID and location when available) of the serving LTE cell with a new trigger
related to the Inter-RAT HO event (the availability/feasibility of the new trigger is FFS).

Editor's note: Discussion with RAN2 is needed.

5.2.2.2 Non-UE specific

- Uplink received interference power measurement: as defined for LTE M3 MDT measurement,
see 3GPP TS 37.320 [2] and references therein.

5.3 UTRAN measurements

5.3.1 UE measurements

5.3.1.1 Connected mode measurements

- Signal strength and quality measurements: RSCP and Ec/No (carrier energy per noise) measurements as
supported by immediate MDT, see 3GPP TS 37.320 [2], clause 5.3.1.

- Location information – GNSS reports: including GNSS coordinates, when available in the UE MDT
measurements, see 3GPP TS 32.422 [7] and 3GPP TS 37.320 [2].

5.3.1.2 Idle mode measurements

- Logged measurements for the serving cell as well as the Intra-frequency, Inter-frequency and Inter-RAT
neighbouring cells (see clause 5.1.1.3.3 in 3GPP TS 37.320 [2]).

5.3.2 Network measurements

5.3.2.1 UE specific
- Uplink SIR measurement: as defined for UMTS M3 MDT measurement,
see 3GPP TS 37.320 [2] and references therein.

- Power headroom measurement (for E-DCH only): as defined for UMTS M4 measurement,
see 3GPP TS 37.320 [2] and references therein.

5.3.2.2 Non-UE specific

- Received Total Wideband Power (RTWP): as defined for UMTS M5 MDT measurement,
see 3GPP TS 37.320 [2] and references therein.

3GPP
Release 12 18 3GPP TR 32.836 V12.0.0 (2014-09)

5.4 Aggregation of measurements

5.4.1 General
In cases when it is sufficient for the CCO function to observe the cell performance via PM measurements, e.g. before
making a detailed analysis based on MDT data, it is useful to support the aggregation of some selected MDT
measurements into PM measurements. The necessary standard support shall include the definition of such PM
measurements in 3GPP TS 32.425 [4] and the mechanisms for triggering and configuring the underlying data collection.
While the data collection is assumed to use MDT collection, clause 5.4.2 discussed the method to trigger this collection.

5.4.2 PM measurements
The following PM measurements, aggregated from corresponding MDT measurements, are useful for CCO function
purposes.

- RSRP distribution measurements: The distribution of the serving cell RSRP values of MDT M1 measurements.
When the eNodeB receives a MeasurementReport message (3GPP TS 36.331 [3]) with MeasId IE corresponding
to the MDT M1 measurement, it shall increase the appropriate subcounter of the RSRP distribution measurement
corresponding to the value of the rsrpResult IE.

- RSRQ distribution measurements: The distribution of the serving cell RSRQ values of MDT M1 measurements.
When the eNodeB receives a MeasurementReport message (3GPP TS 36.331 [3]) with MeasId IE corresponding
to the MDT M1 measurement, it shall increase the appropriate subcounter of the RSRQ distribution
measurement corresponding to the value of the rsrqResult IE.

5.4.3 Method for triggering measurements for PM purposes

In order for the above RSRP and RSRQ distribution PM measurements to receive input samples, there is a need to
activate (and deactivate) the collections over Itf-N. There are several possible alternatives.

One possibility is to reuse an existing mechanism. Candidates are: Trace IRP or PM IRP.

A second possibility is to invent a new mechanism. Candidates are: inventing a new IRP or extending an existing IRP.

A third possibility is to use not standardised mechanisms.

6 User privacy and anonymization

6.1 General
The following specific aspects of user privacy handling need to be considered when the data is collected for the NM
centralized CCO function purposes.

- User identification:
There is no need to identify specific users in the UE and network measurements collected for CCO SON
function purposes at any time. The CCO SON function is concerned with the optimization of network and user
performance but not for specifically selected customers. Therefore, it is important that the collected data can
reveal per user performance, as well as, network level performance but it is not needed to identify specific
subscribers (e.g. based on IMSI or IMEI).

- User consent:
For the efficient operation of the CCO SON function it is important that sufficient amount of UE and network
measurements is collected. Therefore, it should be possible to collect UE and network performance
measurements for CCO SON function purposes without limitation of user consent, provided that proper
anonymization is employed, i.e. the function is to be designed so that at no point in time it is possible to pinpoint
a specific user. Specifically, for users which have no proper user consent for MDT, these UEs could still be
selected for MDT for NM CCO purpose with the condition that no specific user can be identified from the data

3GPP
Release 12 19 3GPP TR 32.836 V12.0.0 (2014-09)

reported and collected from these UEs for NM centralized CCO function. This is helpful for selecting sufficient
amount UE measurements while keeping user privacy.

- Data handling:
When the data is collected for an automated SON function, like CCO, the data is used for the regular operation
of the network.

6.2 Privacy requirements by SA3

The privacy protection requirement is related to the service that the user has signed up to in a contract with the operator.
The operator can collect and process data needed to be able to deliver the service ordered by the user i.e. data related
directly to the service delivery. However, user consent is needed for the collection of location data for the purpose of
MDT and SON, even if it is for direct service delivery.
Note: The following sentence is copied from the LS S3-130559 [x] and it is the only definition that is found for "direct
service delivery": "The operator can collect and process data needed to be able to deliver the service ordered by the user
i.e. data related directly to the service delivery."

Even if the user has given consent for collection and processing of its data for the purpose of SON / MDT, then data
collection should still be restricted to the minimal data set needed to perform SON / MDT.

The following information comes from the LS S3-130559 [11], and should be taken into consideration:

If SON / MDT data groups need to be mapped to each other (e.g. for handover tracing or for some SON function, e.g.
CCO), a generic protection mechanism like introduction of using specific identifiers, e.g. pseudonym or temporary
identity to anonymize the user data may be considered.
Note that the data group mapping is not yet addressed.

6.3 Solution descriptions

If CCO related data of the same UE need to be correlated, then a generic mechanism to anonymize the user data like
using specific identifiers, e.g. pseudonym or temporary identity can be used.
This kind of method is good for privacy protection but does not replace user consent.

7 Correlation of measurements

7.1 Description of functionality

The correlation functionality is to be used for associating various UE and network measurements that are reported
separate (e.g. in different cells) but belong to the same user session occurrence. The correlation enables the CCO
function to perform a more detailed analysis to identify sources of potential problems and to take the appropriate
corrective actions. The data collection method used for CCO needs to have the necessary support function such that the
correlation can be performed later in NM layer.

3GPP
Release 12 20 3GPP TR 32.836 V12.0.0 (2014-09)

7.2 Solution descriptions

7.2.1 Correlate RLF/RCEF and MDT data

Figure 7.2.1-1 Correlation the RCEF/ RLF and MDT data

Correlation at eNB: the RLF and MDT data may be correlated at eNB.

Correlation in TCE: the RLF/RCEF and MDT data may be correlated in TCE.

The NM CCO function can then use the correlated data for further analysis.

7.2.1.1 Correlation at the eNB Scenarios

7.2.1.1.1 Issues with correlation of Immediate MDT and RLF reports

RLF (Radio Link Failure) reports contain information related to the latest connection failure experienced by the UE.
The connection failure can be Radio Link Failure (RLF) or Handover Failure (HOF). The content of the RLF reports,
the procedures for report creation and retrieving by the eNB are described in [2] and [3]. The important detail about
RLF is that the UE was in RRC Connected state prior to the failure and the MDT measurements preceding the failure
are connected mode measurements (Immediate MDT). This clause analyzes the correlation of Immediate MDT data and
RLF report.

3GPP
Release 12 21 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.1.1-1: RLF during an active Immediate MDT session

(re-establishment to a different eNB)

Figure 7.2.1.1.1-1 illustrates a scenario where a connected mode UE participates in an Immediate MDT session with
eNB1 and experiences a Radio Link Failure.
The UE creates a RLF report and attempts to re-establish the connection to a different eNB2.
The UE indicates to eNB2 that it has a RLF report available.
The eNB2 retrieves the RLF report from the UE and after examining it forwards the RLF report in X2 RLF_Indication
procedure to the eNB1 where the Radio Link Failure has occurred.
The eNB1 may have the RLF collection Trace Job active, therefore it packs the RLF report received from the UE in a
Trace File and forwards it to the TCE.

As clause 7.2.1 states, the RLF report and MDT data may be correlated at the eNB. However, a couple of potential
problems exist. The LTE Connection failure Use Case (documented in clause 4.2.6) requires correlating the RLF report
not with just any MDT data, but with MDT measurements from a very specific interval immediately preceding the
Radio Link Failure. In an active Immediate MDT session, the eNB would periodically (specific details are not
standardized and are implementation specific) pack the collected measurements received from the UE into Trace Data
Files and send them to the TCE. Also, after experiencing the Radio Link Failure, UE may not be able to re-establish the
connection immediately (it may take some time e.g. to get out of the coverage hole, etc.) and it is not guaranteed that
the RLF report will be retrieved immediately after the first successful connection reestablishment.

There are following potential issues which can't make the correlation at the eNB based on existing mechanism:

Issue A: There is a possibility that eNB1 may pack and send Immediate MDT data to the TCE before it
receives the RLF report and the Immediate MDT data is not available any more in the eNB1.
In this case the correlation of Immediate MDT data with RLF report at the eNB will not be
possible (no MDT data for the time interval preceding the RLF).

3GPP
Release 12 22 3GPP TR 32.836 V12.0.0 (2014-09)

Issue B: Another potential problem is that the RLF report may arrive to the eNB1 even later and the UE
context (and corresponding MDT session) for this UE may not exist anymore which also makes
the correlation at the eNB impossible.

Issue C: When there is no X2 interface between eNB1 and eNB2, in this case the RLF report will not be
forwarded to the source eNB1, so it is not possible to do the correlation of RLF report and
Immediate MDT at eNB1.

Figure 7.2.1.1.1-2: RLF during an active Immediate MDT session

(re-establishment to the same eNB)

figure 7.2.1.1.1-2 illustrates a similar scenario to the in figure 7.2.1.1.1-1 with one exception – the UE successfully re-
establishes connection to the same eNB.
The eNB re-activates the Immediate MDT session and retrieves the RLF report.
As it was previously mentioned, the UE may not be able to re-establish the connection immediately (it may take some
time e.g. to get out of the coverage hole, etc.) and it is possible that eNB has already packed the MDT data for the
interval immediately preceding the Radio Link Failure and already sent it to the TCE.

3GPP
Release 12 23 3GPP TR 32.836 V12.0.0 (2014-09)

Issue D: The eNB may "correlate" the retrieved RLF report with the new set of MDT data (both pieces of
data came from the same UE), but the correlation will not add any clarity to the RLF investigation
(correlation to the wrong MDT data).

Potential solutions to solve the issues:

Issue A: As the MDT data is not available any more in eNB, in this scenario it's not possible to do
correlation at the eNB. The correlation can only be done in the TCE.

Issue B: In this scenario, the MDT session has expired. If the MDT data have not been sent to TCE, it's still
possible to correlate the RLF and MDT data in eNB.
The combination of C-RNTI and TRSR which is used for the expired MDT session can be used for
correlating the RLF report and MDT data.
A potential method to combine C-RNTI and TRSR is adding C-RNTI into MDT data in eNB, thus
eNB can use the C-RNTI to correlate the RLF report and MDT data.
In this case, the correlation can also be done in the TCE.

Issue C: In this scenario, there is no X2 interface between eNB1 and eNB2, in this case the RLF report will
not be forwarded to the source eNB1, so it is not possible to do the correlation of RLF report and
MDT at eNB.
The correlation of Rel-10 RLF report and MDT can only be done in the TCE

NOTE: Need to add to 3GPP TS 32.422 [7] that if there is no X2 link to source eNB, the Rel-10 and above RLF
reports should be forwarded to the TCE regardless.

Issue D: In this scenario, it's not possible to do correlation at the eNB.

The correlation can only be done in the TCE.
With using the C-RNTI can avoid the problem of correlation to the wrong MDT data mentioned
above.

7.2.1.1.2 Issues with correlation of Immediate MDT, RLF and RCEF reports
RCEF (RRC Connection Establishment Failure) reports also called "accessibility measurements" (see clause 5.1.6 of
3GPP TS 37.320 [2]) are created by the UE when RRC connection establishment procedure fails.
The content of the RCEF reports, the procedures for report creation and retrieving by the eNB are described in
3GPP TS 37.320 [2] and 3GPP TS 36.331 [3].
RCEF reports contain information useful for NM CCO and have already been identified in clause 4.2.6.
Clause 7.2.1 states that RLF/RCEF and MDT data may be correlated at the TCE.

3GPP
Release 12 24 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.1.2-1: RLF followed by RCEF during an active Immediate MDT session

Figure 7.2.1.1.2-1 illustrates a scenario where UE experiences a RLF at eNB1 followed by RCEF to eNB2 and then
successfully re-establishes connection to an eNB3.
It has been agreed by SA5 during online discussions that in such scenarios it is impossible to correlate RLF/RCEF and
MDT data at the eNB. It was also mentioned that if there was a mechanism for RCEF forwarding to the Base Station
(BS) where the problem has occurred (similar to the RLF_Indication over X2), the correlation of RLF/RCEF and MDT
data at the eNB would be possible.

3GPP
Release 12 25 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.1.2-2: RLF followed by RCEF during an active Immediate MDT session
(with RCEF_Indication)

Figure 7.2.1.1.2-2 illustrates a hypothetic scenario (currently impossible due to lack of standardized RCEF_Indication
procedure or something similar like enhancing the RLF_Indication procedure with RCEF information) where RCEF
report retrieved from the UE by the eNB3 is forwarded to the eNB2 where RRC Connection Establishment failed.
As it is shown on figure 7.2.1.1.2-2, even with the new RCEF_Indication procedure in place, it is still impossible to
correlate RLF/RCEF and MDT at the eNB.

7.2.1.1.3 Issues with correlation of Logged MDT and RCEF report

Figure 7.2.1.1.3 illustrates the scenario where UE is configured with Logged MDT by eNB1, goes into Idle Mode and
logs MDT measurements. The UE attempts to establish connection to eNB1 and experiences a RCEF. UE records the
RCEF Report and continues to log the MDT measurements. The UE successfully establishes connection to eNB2 and
indicates the RCEF Report and MDT Log availability. The eNB2 then retrieves the RCEF report and the MDT Log
from the UE after UE sends notifications.

Issues: There is a problem that as the eNB2 doesn't have any information which could be used to make
correlation for the Logged MDT and the RCEF report, it is impossible to do correlation at eNB2.

3GPP
Release 12 26 3GPP TR 32.836 V12.0.0 (2014-09)

Potential Solution:
In order to make it possible to correlate the RCEF report and Logged MDT data, a specific
identifier such as C-RNTI of the UE in eNB2 at the time of retrieving Logged MDT measurement
and RCEF report could be used for the correlation of the Logged MDT measurement data and
RCEF report (either at the eNB or added to the MDT Log and to the RCEF report for correlation at
the TCE).

Figure 7.2.1.1.3: correlation of RCEF report and Logged MDT data at eNB

7.2.1.2 Correlation at the TCE scenarios

7.2.1.2.1 Introduction
Correlation of RLF/RCEF and MDT data at the TCE documented in clause 7.2.1 is a possible solution – it is not
affected by the specific problems outlined in the clause 7.2.1.1 above. However, the strict user privacy and MDT
anonymization requirements make it challenging.
When it is not allowed to store/forward true UE identities (that are directly associated with a user, e.g. IMSI) with
MDT/RLF/RCEF data to the TCE.
In full anonymization mode such UE identities are stripped completely, in partial anonymization only the IMEI-TAC is

3GPP
Release 12 27 3GPP TR 32.836 V12.0.0 (2014-09)

sent to the TCE. Unfortunately, the IMEI-TAC is not sufficient for per-UE/per-session correlation at the TCE.
The TR/TRSR combination can not be used for RLF/RCEF and MDT correlation at the TCE.

3GPP SA3 has approved the potential use of temporary identities or pseudonyms (not traceable back to the true UE/user
identity).

7.2.1.2.2 Correlation of Immediate MDT and RLF reports

This clause analyzes the possibility to use the C-RNTI as a specific identifier (temporary identity) for correlation of
RLF reports and Immediate MDT data at the TCE:

- The combination of C-RNTI, the Cell ID and a corresponding timestamp (the timestamp is only needed to
roughly identify the timeframe when a particular C-RNTI was in use, the accuracy should be within the UE
context lifetime or C-RNTI re-cycle time) uniquely identifies UE for correlation of RLF reports and Immediate
MDT data;

- The eNB knows the C-RNTI of the UE reporting the Immediate MDT;

- The eNB knows the last C-RNTI before the RLF of the UE reporting a RLF during re-establishment;

- The last C-RNTI before the RLF occurred ("C-RNTI used in the PCell upon detecting radio link failure or the C-
RNTI used in the source PCell upon handover failure" as defined in 3GPP TS 36.331 [3]) is part of the RLF
report – this provides the C-RNTI for all RLF reports, including those retrieved not during re-establishment;

- The RLF timestamp (as "timeSinceFailure field used to indicate the time that elapsed since the connection
establishment failure" as defined in 3GPP TS 36.331 [3]) is part of the RLF report.
The RLF_Indication procedure used for forwarding of the RLF reports to the eNB where failure occurred (and
where it is packed into Trace File) takes time in order of milliseconds and is significantly shorter than C-RNTI
re-cycle time.
RLF-Report-r9 ::= SEQUENCE {
measResultLastServCell-r9 SEQUENCE {
rsrpResult-r9 RSRP-Range,
rsrqResult-r9 RSRQ-Range OPTIONAL
},
measResultNeighCells-r9 SEQUENCE {
measResultListEUTRA-r9 MeasResultList2EUTRA-r9 OPTIONAL,
measResultListUTRA-r9 MeasResultList2UTRA-r9 OPTIONAL,
measResultListGERAN-r9 MeasResultListGERAN OPTIONAL,
measResultsCDMA2000-r9 MeasResultList2CDMA2000-r9 OPTIONAL
} OPTIONAL,
...,
[[ locationInfo-r10 LocationInfo-r10 OPTIONAL,
failedPCellId-r10 CHOICE {
cellGlobalId-r10 CellGlobalIdEUTRA,
pci-arfcn-r10 SEQUENCE {
physCellId-r10 PhysCellId,
carrierFreq-r10 ARFCN-ValueEUTRA
}
} OPTIONAL,
reestablishmentCellId-r10 CellGlobalIdEUTRA OPTIONAL,
timeConnFailure-r10 INTEGER (0..1023) OPTIONAL,
connectionFailureType-r10 ENUMERATED {rlf, hof} OPTIONAL,
previousPCellId-r10 CellGlobalIdEUTRA OPTIONAL
]],
[[ failedPCellId-v1090 SEQUENCE {

3GPP
Release 12 28 3GPP TR 32.836 V12.0.0 (2014-09)

carrierFreq-v1090 ARFCN-ValueEUTRA-v9e0
} OPTIONAL
]],
[[ basicFields-r11 SEQUENCE {
c-RNTI-r11 C-RNTI,
rlf-Cause-r11 ENUMERATED {
t310-Expiry, randomAccessProblem,
rlc-MaxNumRetx, spare1},
timeSinceFailure-r11 TimeSinceFailure-r11
} OPTIONAL,
previousUTRA-CellId-r11 SEQUENCE {
carrierFreq-r11 ARFCN-ValueUTRA,
physCellId-r11 CHOICE {
fdd-r11 PhysCellIdUTRA-FDD,
tdd-r11 PhysCellIdUTRA-TDD
},
cellGlobalId-r11 CellGlobalIdUTRA OPTIONAL
} OPTIONAL,
selectedUTRA-CellId-r11 SEQUENCE {
carrierFreq-r11 ARFCN-ValueUTRA,
physCellId-r11 CHOICE {
fdd-r11 PhysCellIdUTRA-FDD,
tdd-r11 PhysCellIdUTRA-TDD
}
} OPTIONAL
]]
}
Figure 7.2.1.2.2-1: RLF report content as defined in TS 36.331 [3]

Figure 7.2.1.2.2-2 illustrates the scenario where Immediate MDT data and RLF report are correlated at the TCE using
the C-RNTI.

3GPP
Release 12 29 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.2.2-2: Correlation of Immediate MDT and RLF data based on C-RNTI

7.2.1.2.3 Correlation of Logged MDT and RCEF reports

Both the RRC Connection Establishment Failure and Logged MDT happen when UE is in the Idle Mode.
When UE experiences a RCEF and has the Logged MDT active, the data recorded in the Logged MDT session before
and after the RCEF may provide a complete picture and help in the root cause analysis.
Therefore, the correlation of RCEF reports and Logged MDT is important.

One possible way to link the RCEF report to the Logged MDT data and avoid correlation (either at the eNB or at the
TCE) completely is to record the RCEF as an event in the Logged MDT if Logged MDT session was already active at
the UE.

3GPP
Release 12 30 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.2.3-1: Logged MDT and RCEF reporting

Figure 7.2.1.2.3-1 illustrates the scenario where UE is configured for a Logged MDT session by eNB1, goes into Idle
Mode and logs MDT measurements. The UE attempts to establish connection to eNB2 and experiences a RCEF.
It logs the RCEF Report and continues to log the MDT measurements.
The UE successfully establishes connection to eNB3 and indicates the RCEF Report and MDT Log availability.
The eNB3 retrieves the RCEF report and, if the RCEF collection session was activated earlier at the eNB3, creates the
RCEF Trace File and forwards it to the TCE.
The eNB3 also retrieves the MDT Log from the UE and forwards it to the TCE.
Since at the time of RCEF occurrence the UE was in the Idle Mode, there is no C-RNTI (at the time of failure)
associated with it. The RCEF reporting and MDT Log reporting to the TCE happen independently (RCEF reporting
requires an active reporting job at the eNB, MDT Log reporting does not). But it may be possible to logically link
RCEF Report and MDT Log indicating that both were retrieved from the same UE without adding the UE identity and
violating the MDT anonymization requirements by use of a temporary identifier (e.g. by adding the C-RNTI of the UE
at the retrieval time to the MDT log and RCEF report being sent to the TCE as illustrated on Figure 7.2.1.2.3-2).

3GPP
Release 12 31 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.2.3-2: Correlation of Logged MDT and RCEF data based on C-RNTI

7.2.1.2.4 Correlation of Immediate MDT and RLF/RCEF reports based on MME mapping
mechanism

3GPP
Release 12 32 3GPP TR 32.836 V12.0.0 (2014-09)

Figure 7.2.1.2.4-1 Correlation of RLF/RCEF and MDT measurements

based on MME mapping information (one MME scenario)

Figure 7.2.1.2.4-1 exemplifies a situation where MDT measurement collection is active for the UE at eNB1 and the UE
experiences an RLF at eNB1. After UE experiences the RLF, the UE successfully re-establishes connection at eNB2
and sends the RLF report. When eNB1 initially activates the MDT measurement collection for the UE, it sends mapping
request to the MME (by sending the CELL TRAFFIC TRACE message) including the indication for the anonymized
mapping in the message, considering the user consent and anonymization constraints.
The MME sends the mapping of trace reference and trace recording session reference to anonymized UE identity
toward the TCE. The anonymized UE identity can be generated by MME if there is user consent.

When the UE re-establishes connectivity at eNB2 and sends the RLF report, eNB2 allocates a new trace recording
session reference, sends mapping request to MME and creates a trace file.
The eNB2 may also activate immediate MDT measurements to the UE, when an area based immediate MDT trace
session is active at eNB2.
The MME maps the new trace reference and trace recording session reference to anonymized UE identity and forwards
the mapping information to TCE.

3GPP
Release 12 33 3GPP TR 32.836 V12.0.0 (2014-09)

The TCE can correlate MDT measurements and RLF reports based on the anonymized UE identity, including MDT
measurements made before and after the RLF, i.e. reported to eNB1 and eNB2.

The anonymized UE identity can be generated by the MME and may be derived for example, from an existing UE
identity. When it is necessary for privacy reasons, the lifetime of the anonymized UE identity shall be limited.
The other alternative solution for anonymized UE identity is to let HSS generate new unique identity for a UE which
can be shared by all the MMEs, the correlation then can be done with the new unique identity.
This solution needs changes also to the traffic signalling standards.

The user consent is extended to have three values: consent for IMSI, consent for anonymized UE identity and no
consent given. This is to give the subscribers to give user consent without having their permanent identity being visible
in the recorded data.

7.3 Evaluation of correlation solution

There are two different solutions for correlation of UE data used for CCO. The first is using C-RNTI and the second is
using a new anonymised identifier (Anonymised Id) to correlate the data.

Use Case (sub-clause) C-RNTI Anonymised Id

Detecting coverage holes and Solves the use case for LTE and for Solves the use case for LTE and
capacity problems (4.2.2) UTRAN. UTRAN.

Cell coverage adapting to traffic Solves the use case. Solves the use case.
demand (4.2.3)

Coverage and accessibility in LTE Solves the use case. Solves the use case.
(4.2.4)

LTE coverage holes with underlaid Solves the use case for LTE and for Solves the use case for LTE and
UTRAN/GERAN (4.2.5) UTRAN. UTRAN.

LTE connection failure in idle mode Solves the use case. Solves the use case. However, it
(4.2.6) supports also UE measurements being
recorded in idle mode to be correlated
with the connected mode UE
measurements.

LTE connection failure in connected Solves the use case. Solves the use case.
mode (4.2.6)

Radio link quality in LTE and Solves the use case for LTE and for Solves the use case for LTE and
UTRAN (4.2.7) UTRAN. UTRAN.

8 Measurement collection mechanism

The existing measurements collection mechanisms are considered to be sufficient.

9 Configuration attributes
The existing configuration attributes are considered to be sufficient.

3GPP
Release 12 34 3GPP TR 32.836 V12.0.0 (2014-09)

10 Recommendations

10.1 CCO for GERAN

It is recommended that the NM centralised CCO function excludes GERAN.

10.2 Method for triggering measurements for PM purposes

As measurements for RSRP and RSRQ etc. already are specified in the 3GPP TS 32.425 [6], it is recommended to keep
the same method as the existing trigger mechanism for the UE report interval for the RSRP and RSRQ measurements
for the CCO Function.

10.3 Correlation of data

Both solutions are equal from a current use case point of view. While the anonymised Id is more future proof, it has a
dependancy on the core network.

10.4 Optimisation cycles

As all solutions in this document are for NM centralised SON, they are only able to address long optimisation cycles (5
minutes or longer). This means that these solutions are not able to address real time or near real time optimisation
cycles.

3GPP
Release 12 35 3GPP TR 32.836 V12.0.0 (2014-09)

Annex A:
Change history
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Old New
2012-08 First version with document structure created with scope and 0.1.0
introduction.
2012-09 Post-SA5#84 Berlin changes. Based on TR skeleton draft S5- 0.1.0 0.2.0
122169 plus pCRs S5-122140, S5-122170, S5-122174, S5-
122175, S5-122176, and S5-122190.
2012-10 Post-SA5#85 Kyoto changes. pCRs S5-122557, S5-122601, S5- 0.2.0 0.3.0
122565 and S5-122566.
2013-01 Post-SA5#87 Malta changes. pCR S5-130249. 0.3.0 0.4.0
2013-05 Post-SA5#88 Qingdao changes: pCRs S5-130796, S5-130797, S5- 0.4.0 0.5.0
130769, S5-130771
2013-06 Post-SA5#89 Sophia Antipolis changes: pCRs: S5-131076, S5- 0.5.0 0.6.0
131078, S5-131087
2013-09 Editorial updates prior to sending to SA for information 0.6.0 0.7.0
2013-09 SA#61 SP-130451 Presented for information 0.7.0 1.0.0
2013-10 Implemented pCRs agreed in SA5#91: S5-131781, S5-131783, S5- 1.0.0 1.1.0
131784, S5-13185, S5-131820 and S5-131822.
2013-11 Implemented pCRs agreed in SA5#92: S5-132159, S5-132160, S5- 1.1.0 1.2.0
132161, S5-132162, S5-132210 and S5-132221. Also some
corrections were made in the Change history for 2013-10.
2013-12 MCC editorial changes 1.2.0 1.2.1
2014-02 Implemented pCRs agreed in SA5#93: S5-140246, S5-140247, S5- 1.2.1 1.3.0
140248, S5-1402273, S5-140274, and S5-140282.
2014-04 Implemented pCR agreed in SA5#94: S5-140738. 1.3.0 1.4.0
2014-05 Implementing pCRs agreed in SA5#95: S5-143377 and S5-143423. 1.4.0 1.5.0
2014-09 SA#65 SP-140549 Presented for approval 1.5.0 2.0.0
Upgrade to Rel-12 version 2.0.0 12.0.0

3GPP