LTE First SON Features (PCI allocation, Autoconfig, ANR, MRO)

OPEX GAIN
First Tests performed with Huawei eRAN 2.1

Author:

Yann Farmine

Approval:

Benoît Badard, Alain Wyns

With project contributions from:

Huawei (Marie-Pierre Guibert, Martin Bakhuizen, Wangxuecheng, Revaz Berozashvili, Andy Zhang Qingtao, Marius Top)

Orange Luxembourg (Gunnar Schreiner, Gregory Gaspard )

Mobistar (Yael Loperena, Laurent Durand)

OLN (Yu Bao, Mamdouh El Tabach, Clélia Bichon-Daire).

Executive Summary
The first SON features (Autoconfig and Automatic Neighbour Relationships) should be adopted as early as possible by all major
affiliates for several reasons:
1. Reduce Opex: estimate is around 1- 2% total OPEX reduction. The gain is coming from saved resources (operational time)
which is proportional to number of sites deployed (roll-out phase and optimization phase) and cost of engineering. The
countries with high engineering cost and high number of sites deployed will benefit from OPEX gain. However, the gain is
pretty marginal.
2. Maintain Opex: GSM, UMTS and LTE have to be maintained by the same operational teams. SON features take care of
time consuming and easy tasks and focus operational teams on the difficult tasks (performance improvements tasks) or new
maintenance (new system such as LTE).
3. Reach good performance very quickly: In 3G at roll-out the optimization phase to reach good performance brings delays
whereas in LTE using SON the performance converges within a couple of days or as the traffic grows. It is difficult to quantify
the gain due to this delay. New sites or site removed for maintenance should converge more quickly to a very good
performance and their availability will be quicker to the clients.
4. Operational change: early adoption is key to the success of SON features because it is an operational process change and
architectural change. It has impacts beyond a typical feature: architecture choices have to be done prior to roll-out, process
changes for operational teams beyond Radio Access (OMC, I&C, local teams).
The conditions to success of Son features:
1. Earl adoption of all affiliates.
2. Architecture changes: outside the scope of this report however it is fundamental to have support from the architecture for:
a. DHCP servers for complete automation of Auto configuration process with minimum human intervention.
i. Setting up centralized or regional DHCP servers: DHCP servers could be a common requirement for fixed
services, LTE and new solutions (such as small cells).
 ii. IP addressing range for DHCP temporary request usage.
b. IPsec: security considerations when interacting with different servers.
3. Close development with Vendors: features require technical improvements (PCI allocation), evolution (Mobile Robustness
Optimisation) and new tools.
4. External tool development: Physical Cell Identity (PCI) allocation requires a more sophisticated tool than the ones provided
by vendors. Other features such as MDT will require processing, analysis and visualization that are not available today.
Recommendations after testing Huawei LTE eRAN2.1:
1. Autoconfig is error free and fully automated process:
a. It is so quick that the testing phase represent 90% of the time. It is possible to accelerate roll-out by having a different
process than typical 2G or 3G roll-out.
b. The BTS configurations have an impact preparation phase if the configuration is not standard.
c. Architecture choices in place for SON: DHCP, IPsec etc.
2. ANR works very well:
a. No need for initial neighbor list.
b. Fast ANR is recommended.
3. PCI allocation requires improvements: ability to allocate optimal PCI with the ability to set rules such as PCI within PCI
group.
4. MRO has not been validated for eRAN2.1 but has no performance impact.
Future work to be performed:
1. PCI Batch allocation: it has not been possible to test this.
2. Autoconfig with RET antennas. eRAN3.0 should solve bug from eRAN2.1 where non RET sites could not be configured.
3. IPsec and DHCP architecture recommendation required to fully automate autoconfig process.
4. Minimisation of Drive Tests feature to be tested.
5. MRO validation.
6. New release improvements validation.
7. Single SON.
Introduction

The features considered for this evaluation of SON OPEX gain and trials are the first SON features available namely: PCI (Physical
Cell ID) allocation, AUTOCONFIG, ANR (Automatic Neighbour Relationship) and MRO (Mobile Robustness). MDT (Minimisation of
Drive Tests) has not been tested but only evaluated based on current processes and knowledge.

Opex Gain

The main aim of this evaluation is to estimate advantage of CAPEX investment and early adoption of Son features to reduce or
maintain OPEX. As operational teams will have to deploy and maintain a third system (LTE), SON features should allow a better
focus from teams on performance rather than time consuming tasks such as: Installation and Commissioning of sites at roll out
phase and configuration of sites to make sites available (neighbouring etc.).

The CAPEX investment of SON is determined by two aspects:

1. Licence fee is based on active users: the cost is much lower when the LTE system does not have many active users on the
system. Early adoption of SON features reduce the CAPEX requirements.

2. CAPEX capping: the purchase of new systems and features are typically capped, which means all possible features should
be adopted as soon as CAPEX is spent for a new system. Therefore, only the OPEX will be considered in our study.
However, those features should work properly and implementation evolution should be continued with vendors.
The OPEX gain calculation is based on saved time due to automated process that was done manually before. The biggest two
parameters are:

1. Engineering cost.

2. Number of sites deployed.

Countries with highest number of sites deployed with the highest engineering cost will benefit from OPEX savings.

Countries with low engineering cost but with high number of sites deployed should still benefit operationally to have a good
performance quickly available to customers.

Other countries should adopt SON features to at least maintain OPEX with equivalent number of resources.

The gain for Autoconfig comes at roll-out phase and ANR brings gain at roll-out as you can reach good performance much faster
and at the optimization phase.

This OPEX gain should be applied to outsourcing contracts when renegotiating contracts to include LTE.

The hypothesis were based on Mobistar study item and applied to other countries: a simplified approach was taken to have an
average of 212 sites deployed/year. Autoconfig opex gain comes at the roll-out phase and ANR/MDT at the optimization phase.

Other countries have been adjusted based on network size (site numbers) and engineering cost (adjusted by cost of labor figures).
Country Sites/year Years 2012 2013 2014 2015 2016 2017 2018 2019 2020
Belgium Roll-out 212 Cumulative 212 424 636 848 1060 1272 1484 1696 1908
Sites/year 212 212 212 212 212 212 212 212 212
Declaration, I&C Cost/hour 64 64 64 64 64 64 64 64 64
AutoConfig time (hours) /site 3.85 52.24 52.24 52.24 52.24 52.24 52.24 52.24 52.24 52.24
ANR time (hours) /site*sites*cost 1.85 25.10 25.10 25.10 25.10 25.10 25.10 25.10 25.10 25.10
MDT time (hours) /site 0 0 0 0 0 0 0 0 0 0
Optimisation
Days of Drive Testing/year
1071
Drive Testing cost/day 315 315 315 315 315 315 315 315 315
Engineering cost/hour 84 84 84 84 84 84 84 84 84
Autoconfig 0 0 0 0 0 0 0 0 0 0
ANR time (hours) /site Total 3.67 5.26 6.85 8.44 10.03 11.62 13.21 14.80 16.39
Batch (hours/site) 0.03931537 8.33 16.67 25.00 33.34 41.67 50.01 58.34 66.68 75.01
Neighbour new sites (hours/site) 0.17 35.33 35.33 35.33 35.33 35.33 35.33 35.33 35.33 35.33
Neighbour existing sites (hours/site) 0.05 0.00 10.60 21.20 31.80 42.40 53.00 63.60 74.20 84.80
MDT time (hours) /site*sites*cost 0.14970297 0.00 0.00 9.00 16.00 24.99 35.99 48.99 55.98 62.98
Effects of MDT 0 0 30% 40% 50% 60% 70% 70% 70%
SON(Total)
AutoConfig kEuros 52.24 52.24 52.24 52.24 52.24 52.24 52.24 52.24 52.24
ANR kEuros 28.77 30.36 31.95 33.54 35.13 36.72 38.31 39.90 41.49
MDT kEuros 0.00 0.00 9.00 16.00 24.99 35.99 48.99 55.98 62.98
TOTAL kEuros 81.01 82.60 93.18 101.77 112.36 124.95 139.54 148.12 156.71

Rollout phase [kEuros] 77.34 77.34 77.34 77.34 77.34 77.34 77.34 77.34 77.34
Optimisation [kEuros] 3.67 5.26 15.85 24.44 35.02 47.61 62.20 70.79 79.37
Total [kEuros] 81.01 82.60 93.18 101.77 112.36 124.95 139.54 148.12 156.71

Figure 1
The estimation is based on the group values: most of the gains in absolute value comes from biggest countries with high cost of
engineering such as France, Spain, Poland, Belgium.

Figure 2
In relative term, based on Mobistar values the gain is around 2% of total labor opex in the long run. Obviously this figure is probably
not correct for France and is based on average figures. The main drivers for SON is therefore to reduce or maintain OPEX and to
focus on improving performance faster by allocating resources to more difficult tasks and removing tedious tasks from operational
engineers.

Figure 3
The cumulated OPEX gain is not negligible over time. The condition is however that MCOs adopt the features as early as possible
and to work with vendors to improve features to make their impact effective on current processes.
Huawei eRAN 2.1

Software versions

The requirements for the software releases for SON eRAN2.1 are:

Release Product Type Main Version Patch Version Version available on GUI

eNodeB BTS3900/DBS3900 V100R003C00 SPC480 V100R003C00SPC480

M2000 Single V200R011C00 SPC240 V200R011C00SPC240

eRAN2.1
CME CME V200R011C00 SPC250 V200R011C00SPC250

PRS PRS V100R007C01 SPC250 V100R007C01SPC250

Figure 4
The tests were carried out on version V100R003C00SPC480.
PCI allocation

PCI (Physical Cell Identity) is the equivalent to scrambling codes for 3G. It consists of 168 code groups of three PCIs (0,1,2)
providing 504 PCIs in total (see table below). It is the Cell ID physical channels and it requires a global allocation for the network to
ensure optimal reuse distance between sites with same PCI or PCI Code groups (if allocated based on code groups). Similarly as
3G the PCI allocation should be based per PCI groups, therefore all sectors from a site should belong to the same PCI group.

PCI Physical Cell Identity To identify cell at radio level 168 PCI groups of 3 (PCI 0,1,2)= 504 PCIs
To identify a Cell in the network (Globally
Unique) EPC can determine UE location based
ECGI E-UTRAN Cell Global Identifier of ECGI ECGI (not more than 52 bits) = PLMN ID + ECI
ECI E-UTRAN Cell Identifier To identify a Cell within a PLMN ECI (28 Bits) = eNB ID + Cell ID
Global eNB ID Global eNodeB Identifier To identify an eNB (Globally Unique) Global eNB ID (not more than 44 bits) = PLMN ID + eNB ID
eNB ID eNodeB Identifier To identify an eNB within a PLMN 20 bits

PCI allocations should calculate optimal allocation of PCI codes taking into account other rules: code groups, reserved code
groups, reduced synchronization issues for some of the sub-optimal code allocations (see “mo”, “m1” description 3GPP TS 36.211
V8.9.0 (2009-12) in annex).

Batch allocation of PCI for the whole network (PCI planning phase).
Similarly to a 3G network, a global plan for code groups should be calculated and some code groups reserved for future sites to
avoid re-planning of PCI codes. However, it is expected in the long run with introduction of small cells type of products and more
sites being rolled out that a global plan to be applied to optimize code allocations. This can be seen as a global scrambling code
planning for 3G or frequency plan for 2G. The actual plan could be computed in an external tool, however the global re-plan should
be implemented in the network overnight in a batch allocation process which should be error free and with minimal outage.
This test was not performed by Huawei. Huawei was reluctant to perform this test as there was a risk on the Orange Luxembourg
network. This does not bring confidence on the automation of such process. This feature is key in big networks where the PCI
allocation should be managed globally where manual approach is not sufficient.

The optimal plans which take into account finer PCI allocations would require global planning and global implementation fo such
plans.

PCI conflict : two cells with same PCI

The conflict was created by manually assigning the same PCI to sectors pointing at each other from L412_Contern_WTO_old and
L437_Moutfort_EPT_Tower.
 Figure 5
In terms of conflict this is the worst interference scenario when two cells facing each other have the same PCI. It is the easiest case
to avoid through proper PCI allocation through engineering guidelines and processes. However, it is the only case that the
network cannot detect. The issue is that the UE will report the same PCI and therefore is not able to detect two different cells
unless requested by the network to check the ECGI. This test has been carried out to experience how the UE behaves, how the
performance is impacted. As expected the system did not detect this conflict and no HO happened between the two cells in
Mobility. The data session managed to survive even if the throughput was probably not optimal.
 Figure 6
The throughput reduces but the session survives. No handover detected on X2 links.
 Figure 7

PCI conflict: two neighbors from a cell have the same PCI

A global review of the Handover is necessary to analyze the different sequences of handover involving different new interfaces. The
following diagram provides the global sequence and then a call flow procedure is presented.
 1. Before Handover 2. Handover Preparation 3. Handover Execution 4. Handover Completion 5. After Handover

- Source eNB takes HO - UE establishes - S1 and X2 release from

decision connection to Target eNB. source eNB.
- X2 Direct Tunnel Setup - DL Packet forwarding - MME mobility update.
from source eNB through
X2.
- UL transfer from target
eNB.

Figure 8
The HO decision is taken directly by the eNodeB and the X2 interface is used to initiate signaling as well as packet forwarding in
Downlink while the S1 interface is set-up in Uplink. The mobility procedure is signaled to the MME entity.
A detailed call flow is provided in ANNEX to be able to follow the different messages in sequence between the different interfaces
involved: Uu, X2 and S1.

Figure 9
A simplified call flow process is presented above to assess the HO execution time and messages based on the interfaces logged
during the trial. The different colors are the different interfaces logged: 437 Uu (red), 437 X2 (blue), 412 Uu (pink), 412 S1 (green).
 Figure 10
From the drive testing data the average value is 15ms for the HO execution. However, from the logs the HO protocol analysis gives
in the order of 500 ms. The UE measures for the RRCConnectionReconfiguration and RRCConnectionReconfigurationComplete for
Attempt and Success. There is an unexplained mismatch between the values measure during drive testing and the actual protocol.

The HO success rate was 99% (with only one failure).

 Figure 11

The system detects a reporting that indicates two neighbours with the same PCI (alarm) and propose a PCI optimsation.
 Figure 12
The suggested PCI to resolve the PCI conflict is PCI= 10. This will solve the issue but a better optmisation would be to take into
account the PCI group constraint and allocate a PCI from a given PCI group. The implementation can be improved to suggest a
PCI with PCI rules such PCI group or other operator constraints (avoid some reserved PCI groups for new sites, microcells, etc.).

Figure 13
 Figure 14
There was only one HO failure with visible effect on throughput. The throughput goes to zero for 8 seconds.
 Figure 15
The comparison between the direct PCI conflict and the second test with Handovers clearly demonstrate the impact of higher
interference on throughput.

PCI conflict : two cells with PCI with same “mo”, “m1”, modulo 3, modulo 30
The PCI codes are defined in 3GPP 36.211 6.11.2 (extract in ANNEX) where the sequences are defined based on indexes mo and
m1. Moreover, the sequences have cyclic shifts modulo 3, modulo 30 and Modulo 8. The uplink channel estimation is impacted by
the modulo 30 cyclic shift.
 The consequence is that two cells with the same indexes or cyclic shift could have PCI confusion. It is not so clear from vendors
what the impact of these different confusion is on the network performance. It is not possible to measure network performance
impact in the field as the potential impact is on the synchronization phase of the UE. None of the tool available could measure such
an impact and therefore one could think it’s not so important. The event of synchronization should not happen often enough to have
a big impact (at UE power up). But some vendors have raised concerns about and have clearly indicated it should be optimized.

Based on lab results from Huawei, the following table was provided on the first synchronization attempt success rate. This indicates
that the second attempt probability will increase and that only the first attempt has low performance resulting in synchronization
delays. This delay is not measurable as such, but remains the question of why some vendors estimate this as suboptimal. The
second impact could be battery consumption.

Lab results: Serving cell PCI is 0. The test consist of UE synchronization successful rate at the first attempt. According to Huawei,
the UE downlink synchronization performance is affected by PCI mod 3 collision more obviously than by m0 or m1 collision. Huawei
also claims that there is no obvious impact with or without m0 collision.

RSRP (dBm) UE synchronization

Neighbor Cell
Serving Neighbor successful ratio in Collision status
PCI
Cell Cell first trying

3 -83 -82 75% PCI mod 3

PCI mod 3
24 -83 -82 68%
m0 mod 8

4 -82 -84 91% No

25 -82 -84 98% m0 mod 8

91 -82 -84 80% m0 mod 8

When analyzing this data we can note the following potential confusion based on the description of potential cyclic shifts:

PCI Group mo m1 Synchronisation success rate comment

Serving 0 0 0 1
Neighbours 3 1 1 2 75% modulo 3
4 1 1 2 91%
24 8 8 9 68% modulo 3
25 8 8 9 98%
91 30 0 2 80% modulo 30/same mo

It is quite clear that modulo 3 has bad performance as well as same mo. No case of similar m1 had been tested.

More assessment is required to be able to specify the algorithms for the PCI allocation whether it is a vendor or in-house tool.
Autoconfig
The auto configuration process can three possibilities tagged in Huawei as A (GPS at eNodeB), B (typical scenario of calling OMC
engineer to identify eNodeB) and C (scanning EAN bar code).

Figure 16
The best option is the one with scanning of the bar code. On the tested sites this part was already done. So only the automated
process was tested.
Figure 17
The process can be done automatically provided that:

1. DHCP server is put in place for eNodeB to request IP address. Implied sub requirements for DHCP:

a. VLAN planning for the routing of the DHCP request.

b. IP addressing range: reserving temp IP addresses for DHCP requests.

2. IPsec has been considered in the architecture.

The architecture aspects are well beyond the scope of our trials. Work arounds were put in place so that the process works in a
fully automated way. But the architecture aspects are essential for the fully automated autoconfig feature. A recommendation on
the subject is urgent for the group. Many other aspects could drive the need for DHCP servers such as small cells, fixed line,
etc. if a DHCP server is not put in place now then it will be difficult to justify the cost in the future once the LTE roll-out is over.

The Autoconfig process run smoothly and very quickly the sites were on air and active. An example is provide with site
L437_Moutfort_EPT_Tower where we can see the start of the autoconfig process starting at 13:50:42 for autodiscovery and
finishing at 15:53:38 including testing. The typical autconfig duration from power-up was around 3 minutes.
 Figure 18
The sector testing: the major difference between LTE and 3G/GSM comes from the duration and simplicity of the testing phase.
The GSM I&C was impacted a lot by the transmission establishment. In 3G it was not the case.

The time for I&C is mainly driven by the tests in each sector. The manual process is estimated at around 10-15 minutes which is
equivalent to the 3G case. For 2G the time is varying from 10 minutes to 30 minutes depending on transmission.

The biggest gain is coming from the tests to be performed in each sector:

1. For 2G and 3G: voice call, SMS, HO, cross sector tests etc…which could take up to 1H30 minutes alone.
 2. For LTE the speed test and file transfer test take 20 minutes in total (up to 1 hour depending on how difficult it is to be
connected to the right sector).

Figure 19
Conversion from Hexadecimal (1B5) to Decimal provides the right site number (437).
 Figure 20
A simple speedtest provides data throughput to the internet: ping 35 ms, 28.7 Mbps Downlink and 18.65 Mbps Uplink.

A second test consist of FTP in parallel to check stability in time of throughput::

 Figure 21
Note: One of the surprising result was that for sectors in Line Of Site with other sites the throughput was half for a test right below
the sector. We have not found an explanation of this result.
So in LTE the total time is between 30min to 1 hour per site. Gives 6 sites per day.

In 3G the time is longer due to the testing. Gives 3-4 sites per day.

In 2G between 2h00 to 2H30 to I&C a site. Gives 2 sites/day.

Note: It is even possible to envisage a roll-out where the power-up of the site is decoupled from the testing phase. This way sites
are radiating very quickly in the roll-out phase and a percentage of these sites will fail but would be detected and solved.
Statistically at the start of the roll-out the percentage of these sites can be high (because mainly of transmission issues) and then
the percentage of sites having issues reduces drastically. SO it’s possible to have a two phase approach: start with first clusters
deployment which includes the tests systematically until a good probability of mistakes is removed (learning phase) and then a fast
roll-out phase with test not done systematically.

The other learning from those tests:

- Complex BTS configurations require more preparation time. Therefore a standard configuration makes the choice of template
much easier.

- The autoconfig advantage is also coming with the fact that no human error is involved in the process, except for the preparation
phase.

RET antenna configuration test

In eRAN2.1 there is a bug for networks with no RET antennas configured. The explanation was not clear but the test should be
performed whenever possible. Mobistar did not performed this test as an alternative to Orange Luxembourg network. From Huawei
clarification this bug is resolved now and it should work with a patch or with eRAN3.0.

Automated X2 set-up
The purpose of this test is to validate that the X2 link could be set-up through S1 link when a HO has to happen. It requires ANR to
be activated . Therefore the test was carried out after ANR feature testing.
The procedure for X2 interface self-setup varies depending on whether the neighboring eNodeB (X2eNodeB) has been manually
configured.

1. l If the neighboring eNodeB has been configured, the eNodeB directly sets up the X2 interface based on the configuration.
This setup mode is also referred to as the direct setup mode.

2. l If the neighboring eNodeB has not been configured, the eNodeB can set up an X2 interface in two modes: X2 over M2000
and X2 over S1. These two modes both require neighboring cell information, which can be collected by ANR. After a
handover is triggered, the serving eNodeB can obtain the configuration information about the neighboring eNodeB. Based on
this information, the X2 interface between the two eNodeBs is automatically set up. Compared with the direct setup mode,
these two modes require less manual intervention, lower costs of network planning and network optimization, and lower
operating resources.

Setup with X2eNodeB Not Configured (X2 over S1)

In X2 over S1 mode, the MME collects the configuration information about neighboring eNodeBs. This mode is recommended
because it has no restrictions on which operator they belong to and which network management system (NMS) they are managed
by. The X2 interface self-setup procedure in X2 over S1 mode is as follows:

1. The eNodeB uses ANR to collect information about neighboring cells, including the global eNodeB ID of each neighboring cell.

2. The eNodeB reports the global eNodeB ID of the candidate cell to the MME.

3. The eNodeB obtains the configuration information about the neighboring eNodeB from the MME based on the S1 signaling and
the global ID of the neighboring eNodeB.

4. The eNodeB sets up an SCTP link and an IP path to the neighboring eNodeB.

5. The eNodeB sets up an X2 interface to the neighboring eNodeB.

 Figure 22
The X2 self-setup function is first activated on L608 and L400 site, no X2 interface is setup between the two sites.

Then a HO scenario performed between cell 1 of L608 and cell 2 of L400 site, after HO, we can see X2 SCTP and X2 interface in
these two sites.
Figure 23
ANR

Automatic Neighbour Relationship is a feature to establish the neighbor list for all the cells automatically based on measurement
reports from the UE sent to the network. This task removes the tedious drive test requirements and radio engineers analysis to
make the performance converge after roll-out. There is a direct correlation between performance and the neighbor list quality. In the
test performed in the Orange Luxembourg network only the intra-LTE neighbor list creation was tested. The feature works well, the
maturity of the technology is proven and the principles are the same for the other neighbor lists. It is not foreseen that other
neighbour list creation would encounter specific issues at this stage. The statistics might be different due to the support from
terminals for interRAT measurement support but a limited number of measurement reports are sufficient to populate the list
correctly.

There three different mechanism exist for the Neighbour Relation creation:

1.Fast ANR: Select few UEs to report periodically.

2.Event ANR: Event triggered UE measurement report when crossing cell borders.

3.UE History: Incoming HO, UE History Info in HO Request

As the timing did not allow the testing one of after the other of both features, it was decided to use the feature in parallel as they
would populate the NCL and NRT list based on different trigger mechanism.
Figure 24
 Fast ANR and Event ANR

Two groups were set with different FAST ANR parameters which are “FastAnrRprtInterval” and “FastAnrRsrpThd”. For first group,
“FastAnrRprtInterval” value is 2048ms, “FastAnrRsrpThd” value is -102; for second group, “FastAnrRprtInterval” value is 1024ms
and “FastAnrRprtInterval” value is -108;

Figure 25
All NCL(EUTRANEXTERNALCELL) and NRT(EUTRANINTRAFREQNCELL) were deleted.

The analysis is not conclusive in terms of quality of neighbor list for two reasons:

1. The lists before the trial were populated with all possible neighbours, even those which would not be used.

2. The number of neighbour cell additions should have been higher in 2nd group (146 neighbours added in first group versus 79
neighbours in 2nd group) as the reporting interval and thresholds were set such that it would double or more the number of
measurement reports.
 3. Moreover the number of handovers (Event ANR) was higher in the first group than in the second one although the drive time
was equivalent and no change of parameter should have been performed. No log of EventANR was available.

The main conclusion is based on:

1. The Handover success rate which proves that the solution is mature enough to guarantee good performance very quickly.

2. No drop during the drive tests was detected which means that even if the Ho was failing the session was not dropping..

LTEIntraFreqHOAttempt LTEIntraFreqHOSuc LTEIntraFreqHOFail

Absolute Numbers 1703 1691 12

Percentage 100 99.29 0.7

Figure 26
The Handover events geolocation shows the road limitation might be the cause of the differences. Users in indoor scenarios should
improve the algorithm.

Test when a site is down or removed.

This site is not possible in eRAN2.1 only eRAN3.0 will be able to remove from lists the sites not available. The impact is not big but
the measurements accuracy is expected to improve with less neighbors to measure.

Other implementation possibilities are that a site might be removed for maintenance reasons, so the neighbors should be removed
from other cells list to avoid them being measured. But also, the neighbours deifinitions should be kept internally for when the site is
back to avoid having to go through the neighbour list creations for all the links.

It should also be possible to have a neighbour clean-up to remove neighbour relationships that less often used and keep a margin
for new cells that should be added. If the maximum number of neighbours is reached then new candidates cannot be added to be
evaluated. If a better cell candidate is available (new site for example) then an assessment should be made again for all the
neighbors to rank the best neighbours. This is a limitation when the lists are limited to 32 but should be the case once going to 64
neighbour relationship.

eRAN3.0 difference with eRAN2.1

Many improvements are implemented in eRAN3.0:

TempNRT does no longer exist

Maximum NRs in NRT increased to 64

Modified mechanism for adding a cell to NCL and NRT

Deleted AddCellThd parameter. Always add directly after detection.

Modified the mechanism for removing a cell from NCL and NRT

Changed default value of DelCellThd to 0% (from 60%)


Added StatisticPeriodForNRTDel & StatisticNumForNRTDel

FastANR new monitoring state will restart FastANR if new PCI detected

Changed default value of FastAnrRprtInterval to 5120ms (from 2048ms)

Maximum X2 links per site increased to 64

X2 blacklisting supported (used where X2 shall not be set up)

Recommendations
No need for manual initial testing.

No need for drive testing to populate the list before commercial launch.

Fast ANR should be used at the launch of the network.

Automated X2 self-setup should be on.

eRAN3.0 is the preferred SON version but eRAN2.1 works if no choice

MRO

The Mobile Robustness Optimisation analyses the Handovers between CellA and CellB in terms of HO too early(RLF in target, re-
est in source cell A) and too late (RLF in source cell, re-est in cell B). Based on the statistics, the algorithm should adjust the Cell
Individual Offset for the relationship between the two cells. As it was not possible to identify a scenario where offsets would be
needed (such as tunnels where imbalance between the two cells is expected and asymmetrical settings of CIO would be required
to improve the Handover success rate. It was decided to create imbalances between the cells by setting big differences of CIO
offset such as 12dB. The expected behavior would be to have the CIO offset converging to CIO=0. Unfortunately, Huawei has
changed the offset in the middle of the test and did not wait for convergence to zero. So it has not been possible to prove that the
algorithm would work correctly of not. Moreover, the analysis shows contradictory adjusments: the CIO should be adjusted in on
direction if the HO are too early and in another direction if too late. In the test the CIO is usually adjusted to a lower CIO which is
what it would be expected but the statistics to scenarios of too earl and too late events are not coherent with results.
 Figure 27
For MRO test sites L028/L029/L400/L608 were chosen to allow rapid test by driving 30 times the motorway.

Note that in the following pictures the PCIs are not correct (previous plan), the analysis was based on logs with cell identity. For the
two CIO settings Huawei decided to apply, the CIO offset between the serving cell (red) and neighbour cells (yellow) is displayed
with adjustments based on number of events and percentage of Late or Early Handovers.
Surprisingly for such offset values the Handover success rate were excellent 99.9% or close.

HOAttempt HOSuccess HOFail

Absolute Number 1278 1277 1

Percentage 100 99.92 0.08

At this stage it is not clear how the MRO algorithm works and the performance might be related to a re-establishment feature.

It is not clear in how many case MRO would apply in a real network. It is not clear that the algorithm would be precise enough for
difficult cases and that it would have any impact the performance globally. At least it is not possible to conclude on a negative
impact of the feature.
ANNEX – OTHER CONSIDERATIONS
PCI Allocation
S1 Signal Strength analysis of PCI conflict
Objective Assess the reuse distance for a PCI conflict or confusion.
Test sequence Assign same PIC at different re-use distance
Measurement Planning tool assessment
Output Recommendation of re-use patterns and minimum distance criteria.

S2 Analyze difference between external tool providing PCI allocation and

automatic PCI allocation.

Objective The objective is to assess vendor PCI planning tool compared to

external tools.
Test sequence Define what is the PCI planning strategy for the algorithm (in case of a
roll-out, new sites, sites removed, etc.).
Assess all the PCI conflict and confusion detected by the algorithm:
Same PCI for neighbor sites
Same PCI for neighbors of one site.
Same PCI within signal strength re-use.
Same mo
Same m1
Measurement Simulations
Output Recommendation about the best solution vendor or external tool
solution.

S3 PCI management with time

Objective Objective is to assess how the PCI management deals with changes
on the network with time (roll-out scenarios, new or removed sites, new
cluster, town expansion, active antennas, six-sectors, small cells, new
pico, femto, etc.).
Test sequence For each scenario describe the allocation strategy.
Measurement For each scenario describe the allocation strategy:
roll-out scenarios
new or removed sites
new cluster
town expansion
active antennas
six-sectors
small cells
new pico
femtos
indoor solutions
Output Recommendation on how to deal with scenarios with no adequate
strategy
Autoconfig
S6 Understand eNodeB synchronization without GPS

Objective Many features in the network require synchronization. For SON it is a

key requirement and GPS is not the preferred solution for an operator
because of the operational burden of such deployment. Other solutions
should be explored.
Test sequence If possible test different solutions.
Measurement Measure synchronization with different synchronization techniques.
Output Recommendation on alternative solutions to GPS for SON
S8 Measure impact of OSS load limitations on Operations: number of BTS
at same time or in total.
Objective Determine load limitations in roll-out scenario.
Test sequence No tests. Calculation of typical number of I&C simultaneously working.
Measurement The number of I&C team working in parallel during roll-out.
Output Recommendation to the vendor if not sufficient.

Answer: M2000 supports to launch 200 eNBs self configuration in parallel.

ANNEX – 3GPP TS 36.211 V8.9.0 (2009-
12)
6.11 Synchronization signals
There are 504 unique physical-layer cell identities. The physical-layer cell identities are grouped into 168 unique physical-layer cell-identity groups, each
group containing three unique identities. The grouping is such that each physical-layer cell identity is part of one and only one physical-layer cell-identity
cell (1) (2) (1)
group. A physical-layer cell identity N ID = 3 N ID + N ID is thus uniquely defined by a number N ID in the range of 0 to 167, representing the physical-layer cell-
(2)
identity group, and a number N ID in the range of 0 to 2, representing the physical-layer identity within the physical-layer cell-identity group.

6.11.1 Primary synchronization signal

6.11.1.1 Sequence generation

The sequence d (n) used for the primary synchronization signal is generated from a frequency-domain Zadoff-Chu sequence according to

 − j πun ( n +1)
 e 63 n = 0,1,...,30
d u (n) =  πu ( n +1)( n + 2)
e − j 63 n = 31,32,...,61


where the Zadoff-Chu root sequence index u is given by Table 6.11.1.1-1.

 Table 6.11.1.1-1: Root indices for the primary synchronization signal.
(2)
N ID Root index u
0 25
1 29
2 34

6.11.1.2 Mapping to resource elements

The mapping of the sequence to resource elements depends on the frame structure. The UE shall not assume that the primary synchronization signal is
transmitted on the same antenna port as any of the downlink reference signals. The UE shall not assume that any transmission instance of the primary
synchronization signal is transmitted on the same antenna port, or ports, used for any other transmission instance of the primary synchronization signal.

The sequence d (n ) shall be mapped to the resource elements according to

a k ,l = d (n ), n = 0,...,61
DL RB
N RB N sc
k = n − 31 +
2

For frame structure type 1, the primary synchronization signal shall be mapped to the last OFDM symbol in slots 0 and 10.

For frame structure type 2, the primary synchronization signal shall be mapped to the third OFDM symbol in subframes 1 and 6. Resource elements (k , l ) in
the OFDM symbols used for transmission of the primary synchronization signal where

DL RB
N RB N sc
k = n − 31 +
2
n = −5,−4,...,−1,62,63,...66

are reserved and not used for transmission of the primary synchronization signal.
6.11.2 Secondary synchronization signal

6.11.2.1 Sequence generation

The sequence d (0),..., d (61) used for the second synchronization signal is an interleaved concatenation of two length-31 binary sequences. The concatenated
sequence is scrambled with a scrambling sequence given by the primary synchronization signal.

The combination of two length-31 sequences defining the secondary synchronization signal differs between subframe 0 and subframe 5 according to

s ( m0 ) (n)c0 (n ) in subframe 0

d (2n) =  0( m )
s1 1 (n)c0 (n ) in subframe 5
s ( m1 ) (n)c1 (n )z1( m0 ) (n ) in subframe 0
d (2n + 1) =  1( m )
s0 0 (n)c1 (n )z1 1 (n ) in subframe 5
(m )

(1)
where 0 ≤ n ≤ 30 . The indices m 0 and m1 are derived from the physical-layer cell-identity group N ID according to

m0 = m′ mod 31
m1 = (m0 + m′ 31 + 1) mod 31
 N (1) + q′(q′ + 1) 2 
(1)
m′ = N ID + q (q + 1) 2 , q =  ID (1)
, q′ = N ID 30  
 30 

where the output of the above expression is listed in Table 6.11.2.1-1.

The two sequences s0( m0 ) (n) and s1( m1 ) (n) are defined as two different cyclic shifts of the m-sequence ~s (n) according to

s0( m0 ) (n) = ~
s ((n + m0 ) mod 31)
~
s (n) = s ((n + m ) mod 31)
( m1 )
1 1

where ~s (i ) = 1 − 2 x(i ) , 0 ≤ i ≤ 30 , is defined by

x(i + 5) = (x(i + 2) + x(i ) )mod 2, 0 ≤ i ≤ 25

with initial conditions x(0) = 0, x(1) = 0, x(2) = 0, x(3) = 0, x(4) = 1 .

The two scrambling sequences c0 (n) and c1 (n) depend on the primary synchronization signal and are defined by two different cyclic shifts of the m-
sequence c~ (n) according to

c0 (n) = c~ ((n + N ID
( 2)
) mod 31)
~ ( 2)
c (n) = c ((n + N + 3) mod 31)
1 ID

( 2)
where N ID ∈ {0,1,2} is the physical-layer identity within the physical-layer cell identity group N ID
(1)
and ~c (i ) = 1 − 2 x(i ) , 0 ≤ i ≤ 30 , is defined by

x(i + 5) = (x(i + 3) + x(i ) )mod 2, 0 ≤ i ≤ 25

with initial conditions x(0) = 0, x(1) = 0, x(2) = 0, x(3) = 0, x(4) = 1 .

The scrambling sequences z1( m0 ) (n) and z1(m1 ) (n) are defined by a cyclic shift of the m-sequence ~z (n) according to

z1( m0 ) (n) = ~
z ((n + (m0 mod 8)) mod 31)

z1( m1 ) (n) = ~
z ((n + (m1 mod 8)) mod 31)

where m 0 and m1 are obtained from Table 6.11.2.1-1 and ~z (i ) = 1 − 2 x(i ) , 0 ≤ i ≤ 30 , is defined by

x(i + 5) = (x(i + 4) + x(i + 2) + x(i + 1) + x(i ) ) mod 2, 0 ≤ i ≤ 25

with initial conditions x(0) = 0, x(1) = 0, x(2) = 0, x(3) = 0, x(4) = 1 .

 (1)
Table 6.11.2.1-1: Mapping between physical-layer cell-identity group N ID and the indices m 0 and m1 .

(1) m0 m1 (1) m0 m1 (1) m0 m1 (1) m0 m1 (1) m0 m1

N ID N ID N ID N ID N ID
0 0 1 34 4 6 68 9 12 102 15 19 136 22 27
1 1 2 35 5 7 69 10 13 103 16 20 137 23 28
2 2 3 36 6 8 70 11 14 104 17 21 138 24 29
3 3 4 37 7 9 71 12 15 105 18 22 139 25 30
4 4 5 38 8 10 72 13 16 106 19 23 140 0 6
5 5 6 39 9 11 73 14 17 107 20 24 141 1 7
6 6 7 40 10 12 74 15 18 108 21 25 142 2 8
7 7 8 41 11 13 75 16 19 109 22 26 143 3 9
8 8 9 42 12 14 76 17 20 110 23 27 144 4 10
9 9 10 43 13 15 77 18 21 111 24 28 145 5 11
10 10 11 44 14 16 78 19 22 112 25 29 146 6 12
11 11 12 45 15 17 79 20 23 113 26 30 147 7 13
12 12 13 46 16 18 80 21 24 114 0 5 148 8 14
13 13 14 47 17 19 81 22 25 115 1 6 149 9 15
14 14 15 48 18 20 82 23 26 116 2 7 150 10 16
15 15 16 49 19 21 83 24 27 117 3 8 151 11 17
16 16 17 50 20 22 84 25 28 118 4 9 152 12 18
17 17 18 51 21 23 85 26 29 119 5 10 153 13 19
18 18 19 52 22 24 86 27 30 120 6 11 154 14 20
19 19 20 53 23 25 87 0 4 121 7 12 155 15 21
20 20 21 54 24 26 88 1 5 122 8 13 156 16 22
21 21 22 55 25 27 89 2 6 123 9 14 157 17 23
22 22 23 56 26 28 90 3 7 124 10 15 158 18 24
23 23 24 57 27 29 91 4 8 125 11 16 159 19 25
24 24 25 58 28 30 92 5 9 126 12 17 160 20 26
25 25 26 59 0 3 93 6 10 127 13 18 161 21 27
26 26 27 60 1 4 94 7 11 128 14 19 162 22 28
27 27 28 61 2 5 95 8 12 129 15 20 163 23 29
28 28 29 62 3 6 96 9 13 130 16 21 164 24 30
29 29 30 63 4 7 97 10 14 131 17 22 165 0 7
30 0 2 64 5 8 98 11 15 132 18 23 166 1 8
31 1 3 65 6 9 99 12 16 133 19 24 167 2 9
32 2 4 66 7 10 100 13 17 134 20 25 - - -
33 3 5 67 8 11 101 14 18 135 21 26 - - -
6.11.2.2 Mapping to resource elements
The mapping of the sequence to resource elements depends on the frame structure. In a subframe for frame structure type 1 and in a half-frame for frame
structure type 2, the same antenna port as for the primary synchronization signal shall be used for the secondary synchronization signal.

The sequence d (n ) shall be mapped to resource elements according to

a k ,l = d (n ), n = 0,...,61
DL RB
N RB N sc
k = n − 31 +
2
 N symb
DL
− 2 in slots 0 and 10 for frame structure type 1
l=  DL
 N symb −1 in slots 1 and 11 for frame structure type 2

Resource elements (k , l ) where

DL RB
N RB N sc
k = n − 31 +
2
 N DL − 2 in slots 0 and 10 for frame structure type 1
l =  symbDL
 N symb − 1 in slots 1 and 11 for frame structure type 2
n = −5,−4,...,−1,62,63,...66

are reserved and not used for transmission of the secondary synchronization signal.
ANNEX – HO through X2 – Call Flow
A detailed callflow is provided below to be able to floow the different messages in sequence between the different interfaces
involved: Uu, X2 and S1.
ANNEX - ANR parameters
N1 Fast ANR test

Objective The objective is to measure the initial neighbor list created by SON at
I&C stage and then when Mobiles report neighbours. Dependign on
terminal capability intra and inter-frequency neighbours will be
analyzed. It is very likely that inter-RAT neighbours will nto be available
at time of testing.
Test sequence Prepare manual list of neighbours. Then I&C, list the neighbours
discovered by the SON feature. Monitor list as more measurement
reports are generated. One UE connected and driving around the
cluster should be enough to make the algorithm converge very quickly.

IntraRatFastAnrSwitch ON

FastAnrRprtInterval 2s then 1s

FastAnrRsrpThd -102dBm then repeat test for -108 dBm to

compare results.

FastAnrIntraRatMeasUeNum 4 (4 handsets for trials)

FastAnrRprtAmount ∞ (infinite)

FastAnrCheckPeriod 7days
 FastAnrIntraRatUeNumThd 10000 (disabled)

Measurement Monitor Neighbour list and number of Measurement Reports received

and compare with manual neighbor list.
Output Recommendation on us of ANR.

N2 Event ANR

Objective The objective is to measure the initial neighbor list created by SON at
I&C stage and then when Mobiles report neighbours. Dependign on
terminal capability intra and inter-frequency neighbours will be
analyzed. It is very likely that inter-RAT neighbours will nto be available
at time of testing.
Test sequence Prepare manual list of neighbours. Then I&C, list the neighbours
discovered by the SON feature. Monitor list as more measurement
reports are generated. One UE connected and driving around the
cluster should be enough to make the algorithm converge very quickly.

IntraRatEventAnrSwitch ON

StatisticPeriod 1day

NCellHOStatNum (40) [ dependent on the number of tests

devices e.g. 40/4 UE= 10 Events going through cell border]

AddCellThd 80% start value (an optimized network should

be 95%

DelCellThd 60% deployment value as it should be higher at

around 90%
 IntraRatAnrAutoDelSwitch (OFF) to start then ON to test
removal: two scenarios (patchy coverage from distant site
or manual change of PCI for a neighbor with an already
used PCI: 100% failure rate of HO.

Measurement Monitor Neighbour list and number of Measurement Reports received

and compare with manual neighbor list.
Output Recommendation on us of ANR.