test specification for multi-vendor son deployment ... specification for multi-vendor x2 son...

Commercial Address: Registered Office:

ngmn Ltd., ngmn Ltd.,

Großer Hasenpfad 30 • 60598 Frankfurt • Germany Reading Bridge House • George Street • Reading • Berkshire RG1 8LS • UK

Phone +49 69/9 07 49 98-04 • Fax +49 69/9 07 49 98-41 Company registered in England and Wales n. 5932387, VAT Number: GB 918713901

Test Specification for Multi-Vendor SON Deployment

Deliverable D4

by NGMN Alliance

Version: VERSION 1.3

Date: 29-Sep-2015

Document Type: Final Deliverable (approved)

Confidentiality Class: P - Public

Authorised Recipients: (for CR documents only)

Project: P-SmallCell Editor / Submitter: Nader Zein (NEC) & Philippe Sehier (ALU) / Ivano Collotta (TI)

Contributors: Jonathan Lewis, Yoshinori Watanabe, Robert Paterson, Julia Mitchell, Philippe Sehier, Nader Zein, Sebastien Duchesne, Swami Anantha, Jake Yun

Approved by / Date: NGMN Board, 20th October 2015

For all Confidential documents (CN, CL, CR):

This document contains information that is confidential and proprietary to NGMN Ltd. The information may not be used, disclosed or reproduced without the prior written authorisation of NGMN Ltd., and those so authorised may only use this information for the purpose consistent with the authorisation.

For Public documents (P):

© 2015 Next Generation Mobile Networks Ltd. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written permission from NGMN Ltd.

The information contained in this document represents the current view held by NGMN Ltd. on the issues discussed as of the date of publication. This document is provided “as is” with no warranties whatsoever including any warranty of merchantability, non-infringement, or fitness for any particular purpose. All liability (including liability for infringement of any property rights) relating to the use of information in this document is disclaimed. No license, express or implied, to any intellectual property rights are granted herein. This document is distributed for informational purposes only and is subject to change without notice. Readers should not design products based on this document.

(96) Test Specification for Multi-Vendor X2 SON Deployment,

Deliverable D4 Version 1.3, 29-Sep-2015

Contents Page 1 INTRODUCTION ............................................................................................................................................... 4

1.1 Revision History ......................................................................................................................................... 4

1.2 References ................................................................................................................................................. 5

1.3 Abbreviations, Definitions and Terminology ............................................................................................ 5

1.3.1 Abbreviations ................................................................................................................................. 5

1.3.2 Terminology ................................................................................................................................... 6

2 OVERVIEW ........................................................................................................................................................ 7

2.1 Scope .......................................................................................................................................................... 7

2.2 Methodology for SON IOT ........................................................................................................................ 7

2.2.1 Distributed SON ............................................................................................................................ 7

2.2.2 Centralized SON ........................................................................................................................... 8

2.3 IOT Architecture and Environment ......................................................................................................... 10

3 TESTs SPECIFICATION ................................................................................................................................. 11

3.1 Architecture Option 1: Distributed SON for Small Cell and Macro Cell ............................................... 11

3.1.1 PCI Optimisation ......................................................................................................................... 11

3.1.1.1 Test Group: PCI Initialization .......................................................................................... 11 3.1.1.2 Test Group: PCI Conflict / Confusion Detection ............................................................. 11

3.1.2 Automatic Neighbour Relation (ANR) ........................................................................................ 17

3.1.2.1 Test group Automatic Neighbour Relation (ANR) .......................................................... 17

3.1.3 Mobility Robustness Optimisation (MRO) ................................................................................. 24

3.1.3.1 MRO IOT Environment Common Parameters ............................................................... 25 3.1.3.2 Test Group: Too Late Handover (HetNet: Small Cell <-> Macro Cell) ........................... 27 3.1.3.3 Test Group: Too Early Handover (HetNet: Small Cell <-> Macro Cell) .......................... 37 3.1.3.4 Test Group: Ping-Pong Handover (HetNet: Small Cell <-> Macro Cell) ........................ 43 3.1.3.5 Test Group: Handover to wrong Cell (HetNet: Small Cell(s) <-> Macro Cell) ................ 49 3.1.3.6 Combined Test Group: Multiple Too Late Handovers triggering a SON Parameter change (HetNet: Small Cell <-> Macro Cell) ................................................................................. 55

3.1.4 Mobility Load Balancing (MLB) .................................................................................................. 59

3.1.4.1 Test Group MLB ............................................................................................................. 59

3.1.5 Coverage and Capacity Optimisation (CCO) ............................................................................ 66

3.1.5.1 CCO IOT Environment Common Parameters ................................................................ 67 3.1.5.2 Test Group: X2AP Resource Status Reporting (HetNet: Small Cell <-> Macro Cell) .... 68 3.1.5.3 Combined Test Group: Static UE Distribution: CCO SON Parameter update (HetNet: Small Cell <-> Macro Cell) ............................................................................................................. 72

3.2 Architecture Option 2: Macro Cell Centralized SON and Small Cell Distributed SON ....................... 75



3.2.1 PCI Optimisation ......................................................................................................................... 75

3.2.1.1 PCI Optimisation IOT Environment Common Parameters ............................................. 75 3.2.1.2 Test Group: PCI Initialization .......................................................................................... 75 3.2.1.3 Test Group: PCI Conflict / Confusion Detection ............................................................. 79 3.2.1.4 Test Group: PCI Conflict / Confusion Resolution ........................................................... 82

3.2.2 Mobility Robustness Optimisation .............................................................................................. 85

3.2.2.1 MRO IOT Environment Common Parameters ............................................................... 85 3.2.2.2 Test Group: Too Early Handover (HetNet: Small Cell <-> Macro Cell) .......................... 85 3.2.2.3 Test Group: Too Late Handover (HetNet: Small Cell <-> Macro Cell) ........................... 85 3.2.2.4 Test Group: Ping-Pong Handover (HetNet: Small Cell <-> Macro Cell) ........................ 85 3.2.2.5 Test Group: Handover to wrong Cell (HetNet: Small Cell(s) <-> Macro Cell) ................ 85 3.2.2.6 Test Group: Multiple Too Late Handovers triggering a SON Parameter change (HetNet: Small Cell <-> Macro Cell) ............................................................................................................. 85

3.2.3 Coverage and Capacity Optimisation ........................................................................................ 86

3.2.3.1 CCO IOT Environment Common Parameters ................................................................ 86 3.2.3.2 Test Group: X2AP Resource Status Reporting (HetNet: Small Cell <-> Macro Cell) .... 86 3.2.3.3 Test Group: Static UE Distribution: CCO SON Parameter update (HetNet: Small Cell <-> Macro Cell) ................................................................................................................................. 86

3.3 Centralized-NM-based SON for Small Cell and Macro Cell ................................................................. 87

3.3.1 Basic Tests .................................................................................................................................. 87

3.3.1.1 Test Group: Basic Tests (EMS <-> Centralized SON) ................................................... 87

3.3.2 PCI (Physical Cell ID) Optimization Test ................................................................................... 90

3.3.2.1 Test Group: PCI Confusion (Small Cell <-> Macro Cell) ................................................ 90

3.3.3 Automatic Neighbour Relations ................................................................................................. 92

3.3.3.1 Test Group: ANR (Small Cell <-> Macro Cell) ............................................................... 92

3.3.4 Coverage and Capacity Optimization Test ............................................................................... 94

3.3.4.1 Test Group: CCO (Small Cell <-> Macro Cell) ............................................................... 94

3 CONCLUSION AND FUTURE WORK .......................................................................................................... 96



1 INTRODUCTION

1.1 Revision History

Date Version Author Changes

19/12/2013 ToC NEC Initial Draft, Table of Contents only

22/01/2014 0.1 NEC IOT methodology moved to Section 2.

Section 3.1.3; Test Case format added

10/03/2014 0.2 NEC NEC contribution: Test cases for MRO and CCO for Architecture Option 1 and Option 2.

24/03/2014 NEC Additional text relating to the timing of the Handover Command added in the Test Case Overview for MRO-1 and MRO-2.

MRO-3 and MRO-4 Test Procedure updated to state that the UE may send a RRC Measurement Report.

10/04/2014 Updates according to comments received 27/03/2014

11/04/2014 ALU All contributions merged in a single document

16/04/2014 ALU ALU: Updates according to comments received on 11/04/2014.Addition of clarification on Small Cell maximum transmit power for dCCO

Cisco: Updates according to received comments.

NEC: Updates according to received comments.

07/05/2014 1.0 NEC

NEC: Addition of a note in sections 3.1.3.2.1 and 3.1.3.2.2 (comments 12 and 13).

ALU Document version updated to 1.0

16/05/2014 1.1 NEC Final clean up including editorial and formatting fixes

04/06/2014 1.2 NEC Conclusion paragraph

29/09/2015 1.3 NGMN Updates following Position Statement Process



1.2 References

[1] NGMN Recommended Practices for Multi-Vendor SON Deployment, October 2013

[2] 3GPP TS 36.300: E-UTRA Overall description; Stage 2

[3] 3GPP TS 36.423: E-UTRAN X2 application protocol (X2AP)

[4] 3GPP TS 36.523-1: E-UTRAN and EPC; User Equipment (UE) conformance specification; Part 1: Protocol conformance specification

[5] 3GPP TS 32.762: E-UTRAN Network Resource Model (NRM) Integration Reference Point (IRP); Information Service (IS)

[6] 3GPP TR 36.839: E-UTRA; Mobility Enhancements in heterogeneous networks

[7] 3GPP TS 36.523-1: E-UTRAN and EPC; User Equipment (UE) conformance specification; Part 1: Protocol conformance specification

[8] 3GPP TS 36.314: E-UTRA; Layer 2 – Measurements (Release 11)

1.3 Abbreviations, Definitions and Terminology

1.3.1 Abbreviations

3GPP The 3rd Generation Partnership Project

ANR Automatic Neighbour Relation

CCO Coverage and Capacity Optimisation

CIO Cell Individual Offset

EARFCN eUTRA Absolute Radio Frequency Channel Number

ECGI eUTRAN Cell Global Identifier

eNB Enhanced Node B

EMS Element Management Sub-system

HetNet Heterogeneous Network

HOF Handover Failure

IOC Information Object Class

LTE Long Term Evolution

MLB Mobility Load Balancing

MME Mobility Management Entity



MRO Mobility Robustness Optimisation

MTS Minimum Time of Stay

NMS Network Management Subsystem

NR Neighbour Relation

OAM Operations and Maintenance

PCI Physical Cell Identity

RLF Radio Link Failure

RAT Radio Access Technology

SON Self Organising Network

TNL Transport Network Layer

UE User Equipment

1.3.2 Terminology

See P-Small_Cells_WS2_Multivendor_Recommended_Practices_v1_0.pdf

http://www.ngmn.org/uploads/media/P-Small_Cells_WS2_Multivendor_Recommended_Practices_v1_0.pdf



2 OVERVIEW This document is the deliverable D4 of the Small Cell project. It describes the interoperability tests that part of the test programme of second joint SCF and MGMN Plugfest. The initial target is to include these tests in the program of the second joint SCF and NGMN Plugfest. The tests, however, have a broader purpose and can be used in other future events.

Detailed background on the project objectives and perimeters can be found in [1], and is not recalled in this document.

2.1 Scope

The document describes detailed descriptions of the IOT. For most SON features, the test methodology depends on the SON implementation. The project takes into account different kinds of implementations: centralized, hybrid and distributed, and interoperability between these implementations. Specific test procedures are defined for interoperability between:

• Distributed to distributed implementation • Macro cell centralized, small cell distributed implementation • Centralized NM based SON for small cell and macro cell

Since our work is contribution driven, some tests descriptions are missing for some configurations. Table 2.2-1 provides the list of covered in the document and the company that produced it.

Table 2.1-1: Contributors and SON tests

SON features Dist -Dist Dist-Cent NM-based Cent

ANR Cisco

PCI-O Cisco Cisco Eden-Rock

MLB ALU

MRO NEC

CCO NEC Eden-Rock

Further extensions including other configurations could be the subject of future projects in NGMN.

The document is subdivided in four major sections: Methodology and general considerations followed by tests descriptions for the 3 configurations listed above.

2.2 Methodology for SON IOT

2.2.1 Distributed SON

It is considered that there are two testing steps that are relevant within this document each requiring their own testing approach.



The following Methodology is considered to be applicable for both SON Architecture Option 1 and Architecture Option 2.

Table 2.2-1: Methodology for SON IOT

Testing Step Test Case Purpose Test Case Outcome / Output

Description

Step 1 (Basic Test Cases)

To verify that SON related X2 parameters are exchanged correctly in a multi-vendor environment.

Pass / Fail Define a number of ‘basic’ test cases e.g. for MRO; Successful HO, Too Early, Too Late, Wrong Cell etc. The purpose of these test cases is to generate the necessary SON related X2 signalling

Step 2 (Combined Test Cases)

To allow the applicable SON algorithm(s) to update the relevant parameter(s) demonstrating the effectiveness of the SON feature in a multi-vendor environment

SON feature KPI(s) Combine a number of ‘basic’ test cases and run them in an agreed sequence over a period of time (e.g. multiple handover procedures executed over a number of minutes).

In addition, it is considered necessary to introduce a degree of statistical variation, i.e. randomness, into the ‘basic’ test cases (in order to emulate a more representative mobile network scenario)

2.2.2 Centralized SON

Different eNodeB vendors may have different northbound interfaces between EMS and NMS. Hence, it is required for centralized SON at NMS to implement separate adaptors for pulling and pushing CM and PM data from EMSs of different vendors. Participating eNodeB vendors shall provide northbound interface specifications for retrieving and pushing CM data and retrieving PM data to centralized SON vendors so that centralized SON vendors can do the preparation (step 0) prior to the on-site SON IOT. Each Centralized SON vendor is responsible for developing an adapter for their Centralized SON solution to translate between the RAN Vendor EMS interface format and the Centralized SON internal format. If a RAN vendor supports the Itf-N interface, then the Centralized SON vendors may already have an adapter and would not need to develop a separate adapter for the interoperability testing. It is recognized that an alignment of vendor implementations on a common specification of the northbound interface would simplify the testing tasks.

Table 2.2-2: Methodology for Centralized SON IOT

Testing Step Test Case Purpose Test Case Outcome / Output

Description

Step 0

(off-site)

Preparation Step: 3rd party SON vendor will develop adaptors for each participating eNodeB vendor’s EMS northbound interface



Step 1 To verify that SON related CM/PM files are pulled/pushed correctly in multi-vendor environment.

Pass / Fail Define a number test cases to verify:

- Retrieval of CM data - Retrieval of PM data - Verify that CM and PM pulled at

centralized SON match with those at each EMS.

- Pushing of CM data - Verify that after the centralized

SON tool has set CM data values, the values reported by the EMS match the set values.

Step 2 To allow the applicable SON algorithm(s) to update the relevant parameter(s) demonstrating the effectiveness of the SON feature in a multi-vendor environment

SON feature KPI(s) Combine a number of ‘basic’ test cases and run them in an agreed sequence over a period of time (e.g. multiple handover procedures executed over a number of minutes).

In addition, it is considered necessary to introduce a degree of statistical variation, i.e. randomness, into the ‘basic’ test cases (in order to emulate a more representative mobile network scenario)



2.3 IOT Architecture and Environment

The following diagram provides a high level simplified testing environment overview.

Figure 2.3-1: Testing Environment Overview

UE

...

... ...

Network Equipment

(e.g. Switch(es))

Macro eN.

Digitally Controllable

Path Attenuation

Ethernet / VLAN Network

eN. / UE Uu Interface

Macro CellUu

Attenuator Output

EPC(MME +

S-GWetc.)

Network MonitoringEquipment

Attenuator ControllerSoftware

Application Server

(e.g. FTP)

UE Monitoring Equipment

...

... ...

Vendor’s Control /

Monitoring Equipment

...

... ...

Small Cell Vendor’s

eN.

...

... ...SmallCell(s)

Uu

Network Equipment(e.g. VPN

access, Firewall etc.)

On-Site

Off-Site Public VPN Access

...

...

...

Small Cell Equipment

Vendor Remote Access

EPC(MME +

S-GW etc.)



3 TESTS SPECIFICATION

3.1 Architecture Option 1: Distributed SON for Small Cell and Macro Cell

3.1.1 PCI Optimisation

3.1.1.1 Test Group: PCI Initialization

3.1.1.1.1 Test Case: DSON-PCI-03: Initialization in existing network

Void

3.1.1.2 Test Group: PCI Conflict / Confusion Detection

3.1.1.2.1 Test Case: DSON-PCI-04: Detect PCI Conflict with Neighbour Cell

Void



3.1.1.2.2 Test Case: DSON-PCI-05: Detect PCI Confusion

Table 3.1-1: DSON-PCI-05: Test Case Overview Test Case Identifier DSON-PCI-05

Test Group PCI Conflict / Confusion Detection

References Note: e.g. NGMN, 3GPP

Equipment • LTE UE • 3 LTE Cells with at least one LTE Small Cell and one LTE Macro cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS

Pre-Requisites • One LTE Small Cell with overlapping coverage with two non-overlapping LTE Cells with the same PCI value

• The LTE Cells can set up X2 connections with each other • OTE: This test case can be run with one LTE Small Cell and Two Macro Cells or Two

Small Cells and one Macro Cell.

Test Case Overview When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then at least one LTE Cells should detect that there is a PCI confusion

Test Case Objective When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then at least one LTE Cells should detect that there is a PCI confusion

3.1.1.2.2.1 Test Procedure

Figure 3.1-1: PcI-05 Test Case Configuration Example

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 101



Figure 3.1-2: PCI-05 Test Case Sequence

The test procedure is described below:

1. Verify that coverage of the two LTE Small Cells & one LTE Macro Cells is similar to the figure above. SmallCell-2 is the new LTE Small Cell added to the existing network.

2. Note down the PCIs of the LTE Small Cells & Macro Cells in the vicinity. 3. Power up the new LTE Small Cell and run the required activation procedure (if applicable) 4. Initialize the LTE Small Cell. 5. A UE moves in the area covered by the LTE Small Cell & Macro Cell as well as the overlapping

areas between the LTE Small & Macro Cells. a. The UE is configured to provide measurement reports

6. The new LTE Small Cell (SmallCell-2) & the Macro Cell populate their neighbour lists 7. The LTE Small Cell & LTE Macro Cell use the eNB, MME Configuration Transfer messages to

obtain each other’s IP Address. 8. The LTE Small Cell & LTE Macro Cell set up X2 links with each other using X2 Setup messages.

a. The LTE Macro Cell’s neighbour list information is provided as part of the X2 Setup Response message

9. The LTE Macro Cell sends a X2 eNodeB Configuration Update message to the existing Small Cell SmallCell-1 with the updated neighbour list information.

10. SmallCell-1 detects that there is a PCI Confusion with SmallCell-2 by looking at the neighbour list of the Macro Cell.

a. Note: SmallCell-2 may detect PCI Confusion prior to SmallCell-1 and report it

3.1.1.2.2.2 Expected Output 1. At least one of the LTE Small / Macro Cells should detect and log the PCI confusion.



3.1.1.2.3 Test Case: DSON-PCI-08: PCI Confusion Resolution

Table 3.1-2: DSON-PCI-08: Test Case Overview Test Case Identifier DSON-PCI-08

Test Group PCI Conflict / Confusion Resolution


Equipment • LTE UE • 3 LTE Cells with at least one LTE Small Cell and one LTE Macro cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • NOTE: This test case can be run with one LTE Small Cell and Two Macro Cells or Two

Small Cells and one Macro Cell.

Pre-Requisites • One LTE Small Cell with overlapping coverage with two non-overlapping LTE Cells with the same PCI value

• The LTE Cells can set up X2 connections with each other

Test Case Overview When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then at least one LTE Cells should detect that there is a PCI confusion and resolve the PCI confusion

Test Case Objective When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then at least one LTE Cells should detect that there is a PCI confusion and resolve the PCI confusion


Figure 3.1-3: PCI-08 Test Case Configuration Example

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 101



Figure 3.1-4: PCI: PCI-08 Test Case Sequence



2. Note down the PCIs of the LTE Small Cells & Macro Cells in the vicinity. 3. Power up the new LTE Small Cell and run the required activation procedure (if applicable)



4. Initialize the LTE Small Cell. 5. A UE moves in the area covered by the LTE Small Cell & Macro Cell as well as the overlapping






10. SmallCell-1 detects that there is a PCI Confusion with SmallCell-2 by looking at the neighbour list of the Macro Cell.

11. SmallCell-1 changes its PCI and resets itself a. Note: SmallCell-2 may detect PCI Confusion prior to SmallCell-1 and change its PCI value

prior to SmallCell-1

3.1.1.2.3.2 Expected Output 1. At least one of the LTE Cells should detect and log the PCI confusion 2. The LTE Cell that resolves the PCI conflict logs its new PCI value



3.1.2 Automatic Neighbour Relation (ANR)

3.1.2.1 Test group Automatic Neighbour Relation (ANR)

3.1.2.1.1 Test Case: DSON-ANR-01: ANR in existing network with one LTE Macro Cell

Table 3.1-3: DSON-ANR-01: Test Case Overview Test Case Identifier DSON-ANR-01

Test Group Automatic Neighbour Relations


Equipment • One LTE Small Cell • One LTE Macro Cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS

Pre-Requisites • One LTE Macro Cell up and running in the vicinity of the LTE Small Cell in question

Test Case Overview The LTE Small & Macro Cells automatically detect the new neighbour(s) when a new LTE Small Cell is powered up in the vicinity of an existing LTE macro cell network

Test Case Objective Test if a new LTE Small Cell automatically determines its neighbour list and if the LTE Macro Cell adds the new LTE Small Cell to its neighbour list


Figure 3.1-5: ANR-01 Test Configuration Example

SmallCell-1 PCI 101

Macro-1 PCI 100



Figure 3.1-6: ANR: ANR-01 Test case Sequence



1. Verify that coverage of the LTE Small & Macro Cells is similar to the figure above. SmallCell-1 is the new LTE Small Cell added to the existing network.

2. Note down the PCI of the LTE Macro Cell in the vicinity. 3. Power up the new LTE Small Cell and run the required activation procedure (if applicable) 4. Initialize the LTE Small Cell. 5. A UE moves in the area covered by the LTE Small Cell & Macro Cell as well as the overlapping


6. The LTE Small & Macro Cells populate their neighbour lists 7. The LTE Small Cell & LTE Macro Cell use the eNB, MME Configuration Transfer messages to

obtain each other’s IP Address. 8. The new neighbours set up X2 links with each other using X2 Setup messages.

3.1.2.1.1.2 Expected Output 1. The new LTE Small Cell adds the LTE Macro Cell to its neighbour list 2. The LTE Macro Cell adds the LTE Small Cell to its neighbour list 3. The LTE Small & Macro Cells log their new / updated neighbour lists 4. New X2 links are set up between the LTE neighbours.



3.1.2.1.2 Test Case: DSON-ANR-02: ANR in existing network with non-overlapping Small Cells

Table 3.1-4: DSON-ANR-02: Test Case Overview Test Case Identifier DSON-ANR-02

Test Group Automatic Neighbour Relations


Equipment • 2 LTE Small Cells with non-overlapping coverage • One LTE Macro Cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS

Pre-Requisites • One LTE Small Cell & one LTE Macro Cells up and running in the vicinity of the LTE Small Cell in question

Test Case Overview The LTE Macro Cell automatically detects the new neighbour(s) when the new LTE Small Cell is powered up in the vicinity of an existing LTE small cell & macro cell network

Test Case Objective Test if a new LTE Small Cell automatically determines its neighbour list, if the LTE Macro Cells adds the new LTE Small Cell to its neighbour list and shares the updated neighbour list with the existing LTE Small Cell


Figure 3.1-7: Test Case ANR-02 Configuration Example

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 102



Figure 3.1-8: ANR: ANR-02 Test Case Sequence



2. Note down the PCIs of the LTE Small Cells & Macro Cells in the vicinity. 3. Power up the new LTE Small Cell and run the required activation procedure (if applicable) 4. Initialize the LTE Small Cell. 5. A UE moves in the area covered by the LTE Small Cell & Macro Cell as well as the overlapping








3.1.2.1.2.2 Expected Output 1. The new LTE Small Cell (SmallCell-2) adds the LTE Macro Cell to its neighbour list 2. The LTE Macro Cell adds the new LTE Small Cell (SmallCell-2) to its neighbour list 3. The new LTE Small Cell (SmallCell-2) & the LTE Macro Cell log their new / updated neighbour lists 4. New X2 link is set up between SmallCell-2 and MacroCell-1. 5. The existing Small Cell SmallCell-1 logs the reception of the updated neighbour list from the Macro

Cell.



3.1.3 Mobility Robustness Optimisation (MRO)

MRO IOT Methodology Discussion: According to section 3 in NGMN [1] the performance aim of MRO is to improve the Quality of Experience in terms of reducing call drops and avoiding unnecessary Handovers (Ping-Pongs). In addition a further aim is to reduce the amount of human intervention.

In order to fully assess the relative MRO performance variation (SON feature activated versus deactivated) in a multi-vendor environment the following procedure would be involved:

Single Vendor Environment: Firstly, run a number of different Handover scenarios in a single-vendor, multiple cell environment, with each vendor recording an expected performance improvement (relative to MRO deactivated),

Multi-Vendor Environment: Run a similar test in a multi-vendor environment and compare the results to the single-vendor environment

At a basic level each test case aims to test the multi-vendor alignment where the X2 interface is involved, i.e. the expected information is correctly exchanged over X2.

In order to simulate a too early or too late handover, see section 22.4.2 [2] for definitions, the Cell 1 and/or Cell 2 power received at the UE should be dynamically modified in order to:

Cause the UE to trigger the sending of a Measurement Report, or

Cause a Radio link failure

In order to test the SON feature performance a combination of basic test cases should be executed continuously for at least the amount of time specified by the MRO timescale of operation, i.e. to allow the SON feature to trigger an update of the Handover configuration. There should be a degree of variation when running some of the test cases, such that each time a test case is run either a Handover attempt is successful or a Radio Link Failure occurs, etc. This may be achieved by changing the UE received power at a given time, or over a period of time, to one of several pre-configured values. These are randomly selected each time the Test Case is executed. After the combined Test Case period the overall handover performance, via KPI measurements, can be compared to the situation where MRO was not active.

For Combined Test cases as described in section 2.2 (Step 2), it is necessary to define the test case outcome in terms of the applicable SON feature KPI(s).

For MRO the following diagram example defines 3 time periods (A, B and C). In the combined test case expected outcome sections below, the expected behaviour of each applicable KPI is described according to the 3 time periods.



Figure 3.1-9: MRO: KPI time Periods

Time

Combined Test Case overall duration/run time

KPI: Handover

Failure Ratio

Period A Period B Period C

(Initial State,Pre-MRO)

(Transient State,

MRO Running)

(Converged State,

Post MRO)

MRO Definitions:

For Too Late/Early Handover and Handover to Wrong Cell definitions see section 22.4.2 in [2].

Handover Failure Ratio is defined as:

Handover Failure Ratio = (Number of Handover Failures) / (Number of Successful Handovers + Number of Handover Failures)

Ping-Pong Handover Ratio is defined as:

Ping-Pong Handover Ratio = (Number of Ping-Pong Handovers) / (Number of Successful Handovers)

For the definition of a Ping-Pong Handover see section 5.2.2 in [6].

3.1.3.1 MRO IOT Environment Common Parameters

Table 3.1-5: MRO IOT Parameter Alignment

SON Parameter Ref. Description Alignment Necessary Recommendation Tstore_UE_cntxt

(Seconds)

Section 22.4.2 [2]

For MRO, in order for an eNB to designate a Too Early/Late/Wrong Cell Handover this timer is used

It is necessary for each of the vendors involved to align the value.

The setting of T310 plus other applicable delays should be considered when determining a suitable value for Tstore_UE_cntxt

Minimum Time-Of-Stay (MTS)

[1][3][6] For Ping-Pong Modelling, see section 5.2.2 in [6] the Minimum Time-Of-Stay

It is necessary for each of the vendors involved to align the value.

The recommended MTS value in [6] is 1 second



(Seconds) (MTS) timer is used to determine whether a Ping-Pong Handover has taken place.



3.1.3.2 Test Group: Too Late Handover (HetNet: Small Cell <-> Macro Cell)

3.1.3.2.1 Basic Too Late Handover Test Case: Vendor A is a Small Cell eNB: Radio Link Failure occurs in Small Cell eNB (Cell 1)

Table 3.1-6: MRO: MRO-1 Test Case Overview

Test Case Identifier

MRO-1

Test Group Too Late Handover

References [2][3]

Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment, see Figure 2.3-1.

Pre-Requisites

A neighbour relation is configured between Cell 1 and Cell 2,

UE is in RRC-CONNECTED state using Cell 1 under the control of a Small Cell eNB (Vendor A),

At least Intra Frequency RRC measurements are active in the UE

Test Case Overview

A Radio Link Failure is detected by the UE in the Small Cell eNB (Cell 1) as a result of the decrease in UE received power. This results in the UE performing a RRC Re-Establishment Request towards the Macro Cell eNB (Cell 2) and X2AP message RLF Indication being sent from the Macro Cell eNB (Cell 2) to the Small Cell eNB (Cell 1). In the case where a Handover procedure is triggered, in order to ensure that the UE does not receive the RRC CONNECTION RECONFIGURATION message, containing the mobility information, as part of the Handover Execution phase, it may be necessary to switch off Cell 1 between time T1 and T2, e.g. between the time when the Measurement Event triggering inequality is initially fulfilled and the time when the HO Command is sent. The diagram below shows the expiry of T310 as the event that causes the UE to detect a Radio Link Failure. This example is only one of several events that can lead to the UE detecting a RLF.

Radio Link Failure

Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

UE T310 Timer started (upon detecting physical layer problems)

UE Re-Establishment Attempt in Cell 2

Time

UERx

Power

Radio Link Failure detected by UE

Test Case Objective

To verify that each eNB involved correctly exchanges the applicable handover information over the X2 interface in X2AP messages RLF INDICATION

If any further details are required regarding the running and/or configuration of this test they should be provided by the individual vendor’s test team know-how.

Table 3.1-7: Time Instances of UE received power Time Remark

T0 Initial values T1-T2 UE received power from Cell 1 is decrease between time T1 and T2. During this period a Handover may be triggered.

T2 UE received power from Cell 1 is zero




Figure 3.1-10: MRO: MRO-1 Test Case Sequence

Cell 2

Cell 2

UE

UE

6. RRC Connection Re-Establishment

Cell 1

Cell 1

Vendor A,Small Cell eNB Macro Cell eNB

2. RRC: Measurement Report

4. Handover Preparation

3. Handover Decision

5. Radio Link Failure Occurs in Cell 1

1. UE is in RRC_CONNECTED State,Intra-LTE RRC Ax Event(s) are active in

the UE

7. X2AP: RLF INDICATION

Failure cell PCI = Cell 1,Re-establishment cell ECGI = Cell 2,C-RNTI, ShortMAC-I,UE RLF Report Container

Time = T0

Time = T1

Time = T2

Opt

1. Time = T0 – UE received power from Cell 1 and 2 are set to initial values, see Table 3.1-7,

Time = T1 – UE received power from Cell 1 is decreased (emulating UE mobility), see Table 3.1-7. Whether a Handover is triggered before Radio Link Failure is dependent on the test configuration.

2. Optional: If the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Small Cell eNB.

3. Optional: The Small Cell eNB initiates a Handover procedure towards the Macro Cell eNB,

4. Optional: The Small Cell eNB sends X2AP message HANDOVER REQUEST to the Macro Cell eNB including the Target Cell ID of Cell 2. The Macro Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE.

Time = T2 – UE received power from Cell 1 is “Off”, see Table 3.1-7,

5. A Radio Link Failure occurs in Cell 1,

6. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Macro Cell eNB,

7. The Macro Cell eNB sends X2AP message RLF INDICATION to the Small Cell eNB. The Failure Cell PCI is indicated as Cell 1



3.1.3.2.1.2 Expected Outcome The UE attempts to re-establish the call on the Macro Cell eNB. The Macro Cell eNB then sends X2AP message RLF INDICATION to the Small Cell eNB.



3.1.3.2.2 Basic Too Late Handover Test Case: Radio Link Failure occurs in Macro Cell eNB (Cell 2)

Table 3.1-8: MRO: MRO-2 Test Case Overview Test Case Identifier

MRO-2

Test Group Too Late Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment,

see Figure 2.3-1. Pre-Requisites


UE is in RRC-CONNECTED state using Cell 2 under the control of a Macro Cell eNB,


Test Case Overview

A Radio Link Failure is detected by the UE in the Macro Cell eNB (Cell 2) as a result of the decrease in UE received power. This results in the UE performing a RRC Re-Establishment Request towards the Small Cell eNB (Cell 1) and X2AP message RLF Indication being sent from the Small Cell eNB (Cell 1) to the Macro Cell eNB (Cell 2). In the case where a Handover procedure is triggered, in order to ensure that the UE does not receive the RRC CONNECTION RECONFIGURATION message, containing the mobility information, as part of the Handover Execution phase, it may be necessary to switch off Cell 2 between time T1 and T2, e.g. between the time when the Measurement Event triggering inequality is initially fulfilled and the time when the HO Command is sent. The diagram below shows the expiry of T310 as the event that causes the UE to detect a Radio Link Failure. This example is only one of several events that can lead to the UE detecting a RLF.

Radio Link Failure

Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

Time

UERx

Power

UE T310 Timer started (upon detecting physical layer problems)


Radio Link Failure detected by UE

Test Case Objective

To verify that each eNB involved correctly exchanges the applicable handover information over the X2 interface in X2AP messages RLF INDICATION


Table 3.1-9: Time Instances of UE received power

Time Remark T0 Initial values

T1-T2 UE received power from Cell 2 is decrease between time T1 and T2. During this period a Handover may be triggered. T2 UE received power from Cell 2 is zero




Figure3.1-11: MRO: MRO-2 Test Case Sequence

UE

UE

Cell 1

Cell 1

6. RRC Connection Re-Establishment



Cell 2

Cell 2






1. UE is in RRC_CONNECTED State,Intra-LTE RRC Ax Event(s) are active in the UE

Time = T0

Time = T1

Time = T2

Opt


Time = T1 – UE received power from Cell 2 is decreased (emulating UE mobility), see Table 3.1-9. Whether a Handover is triggered before Radio Link Failure is dependent on the test configuration.

2. Optional: If the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Macro Cell eNB.

3. Optional: The Macro Cell eNB initiates a Handover procedure towards the Small Cell eNB,

4. Optional: The Macro Cell eNB sends X2AP message HANDOVER REQUEST to the Small Cell eNB including the Target Cell ID of Cell 1. The Small Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE.

Time = T2 – UE received power from Cell 2 is “Off”, see Table 3.1-9,


6. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Small Cell eNB,

7. The Small Cell eNB sends X2AP message RLF INDICATION to the Macro Cell eNB. The Failure Cell PCI is indicated as Cell 2

3.1.3.2.2.2 Expected Outcome



The UE attempts to re-establish the call on the Small Cell eNB. The Small Cell eNB then sends X2AP message RLF INDICATION to the Source eNB.



3.1.3.2.3 Basic Too Late Handover Test Case: As MRO-1 but with a varying rate of power decrease, as received by the UE, from Cell 1


MRO-3

Test Group Too Late Handover

References [2][3]

Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment, see Figure 2.3-1.

Pre-Requisites A neighbour relation is configured between Cell 1 and Cell 2,

UE is in RRC-CONNECTED state using Cell 1 under the control of a Small Cell eNB,


Test Case Overview

The basis of the Test case is as MRO-1 with the difference that each time the test is ran the outcome of the test should vary according to the randomly selected configuration for the time between T1 & T2 (changing the rate of UE received power decrease). The possible outcomes of the test case are detailed in section 3.1.3.2.3.1.

Radio Link Failure

Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

A, B Radio Link Failure is detected by UE

Rate of UE Rx Power decrease is configured to have 3 possible rates

Time

C. Handover is completed before T2

UERx

Power


Test Case Objective

To verify that each time the test case is ran the outcome of the test case is either A, B or C.


Table 3.1-11: Time Instances of UE received power Time Remark

T0 Initial values T1-T2 The rate, at which the UE received power from Cell 1 decreases, i.e. the time between T1 and T2, is dependent on the

randomly selected configuration. A Handover may be triggered depending on whether the UE generates a RRC MEASUREMENT REPORT before the UE received power from Cell 1 drops below the point at which a Radio Link Failure occurs.

T2 UE received power from Cell 1 is zero



3.1.3.2.3.1 Test Procedure Figure3.1-12: MRO: MRO-3 Test Case Sequence

Cell 2

Cell 2

UE

UE

Cell 1

Cell 1


Alt

A. RLF occurs, a Measurement Report may be sent to Cell 1

B. Measurement Report sent to Cell 1, RLF occurs after the completion of Handover Preparation, see MRO-3

C. Handover triggered and completed to Cell 2

Time = T1

Time = T2

See section 3.1.3.2.1.1 for the general test procedure. Each time the test case is executed, one of three possible Cell 1 rates of decrease for the UE received power is randomly selected, leading to the following outcomes:

A. Radio Link Failure in Cell 1 – A RRC MEASUREMENT REPORT may be sent,

B. Radio Link Failure in Cell 1 – RLF occurs after the completion of Handover Preparation, see section 3.1.3.2.1.1,

C. Handover successfully completed Cell 1 -> Cell 2, see [2]

3.1.3.2.3.2 Expected Outcome See section 3.1.3.2.3.1 for the possible outcomes.



3.1.3.2.4 Basic Too Late Handover Test Case: As MRO-2 but with a varying rate of power decrease, as received by the UE, from Cell 2


MRO-4

Test Group Too Late Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing

Environment, see Figure 2.3-1. Pre-Requisites A neighbour relation is configured between Cell 1 and Cell 2,



Test Case Overview

The basis of the Test case is as MRO-2 with the difference that each time the test is ran the outcome of the test should vary according to the randomly selected configuration for the time between T1 & T2 (changing the rate of UE received power decrease). The possible outcomes of the test case are detailed in section 3.1.3.2.4.1

Radio Link Failure

Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

Rate of UE Rx Power decrease is configured to have 3 possible rates

Time

C. Handover is completed before T2

UERx

Power

A, B Radio Link Failure is detected by UE


Test Case Objective

To verify that each time the test case is ran the outcome of the test case is either A, B or C.



Time Remark T0 Initial values

T1-T2 The rate, at which the UE received power from Cell 2 decreases, i.e. the time between T1 and T2, is dependent on the randomly selected configuration. A Handover may be triggered depending on whether the UE generates a RRC MEASUREMENT REPORT before the UE received power from Cell 1 drops below the point at which a Radio Link Failure occurs.

T2 UE received power from Cell 2 is zero.




Cell 2

Cell 2

UE

UE

Cell 1

Cell 1


Alt

A. RLF occurs, a Measurement Report may be sent to Cell 2

B. Measurement Report sent to Cell 2, RLF occurs after the completion of Handover Preparation, see MRO-4

C. Handover triggered and completed to Cell 1

Time = T1

Time = T2

See section 3.1.3.2.2.1 for the general test procedure. Each time the test case is executed, one of three possible Cell 2 rates of decrease for the UE received power is randomly selected, leading to the following outcomes:

A. Radio Link Failure in Cell 2 – A RRC MEASUREMENT REPORT may be sent,

B. Radio Link Failure in Cell 2 – RLF occurs after the completion of Handover Preparation, see section 3.1.3.2.2.1,

C. Handover successfully completed Cell 2 -> Cell 1, see [2]

3.1.3.2.4.2 Expected Outcome See section 3.1.3.2.4.1 for the possible outcomes.



3.1.3.3 Test Group: Too Early Handover (HetNet: Small Cell <-> Macro Cell)

3.1.3.3.1 Basic Too Early Handover Test Case: Vendor A is a Small Cell eNB: Radio Link Failure in Small Cell (Cell 1) occurs after Handover Execution


MRO-6

Test Group Too Early Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing

Environment, see Figure 2.3-1. Pre-Requisites




Test Case Overview

A Handover procedure is attempted from a Small Cell eNB (Cell 1) to a cell in the Macro eNB (Cell 2) using X2 messages. Shortly after the completion of the Handover procedure a Radio Link Failure occurs, leading to the UE attempting a RRC Connection Re-Establishment procedure in Cell 1.

Radio Link Failure

Too Early HO Triggered

Cell 1(Small Cell)

Cell 2(Macro)

Radio Link Failure in Cell 2

Handover procedure successfully completed


Time required to complete Handover Procedure

T0 T1 T2

UERx

Power

Time

Test Case Objective

To verify that each eNB involved correctly exchanges the applicable handover information over the X2 interface in X2AP messages RLF INDICATION and HANDOVER REPORT



Time Remark T0 Initial values T1 UE received power from Cell 2 is modified to trigger a Handover from Cell 1 to Cell 2 T2 UE received power from Cell 2 is reduced to zero to trigger a Radio Link Failure





UE

UE

Cell 1

Cell 1

Cell 2

Cell 2




5. Handover Execution


10. X2AP: HANDOVER REPORT



7. RRC: RRC Connection ReEstablishment

Request

8. RRC: RRC Connection ReEstablishment Reject

1. UE is in RRC_CONNECTED State,EUTRA measurements are configured in

the UE

Timer Tstore_UE_cntxt started in the Macro Cell


Handover Report Type = HO too earlyHandover Cause,Source cell ECGI = Cell 1 (Small Cell eNB),Failure cell ECGI = Cell 2 (Macro Cell eNB)

Time = T0

Time = T1

Time = T2

1. Time = T0 – UE received power from Cell 1 and 2 are set to initial values, see Table 3.1-15.

2. Time = T1 – UE received power from Cell 2 is increased (emulating UE mobility) to trigger a Handover, see Table 3.1-15.

When the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Small Cell eNB.

3. The Small Cell eNB initiates a Handover procedure towards the Macro Cell eNB,

4. The Small Cell eNB sends X2AP message HANDOVER REQUEST to the Macro Cell eNB including the Target Cell ID of Cell 2. The Macro Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,

5. The Small Cell eNB sends RRC message RRC CONNECTION RECONFIGURATION including the Mobility Control Information to the UE. After the UE synchronises and successfully accesses the Macro Cell eNB the UE sends RRC message RRC CONNECTION RECONFIGURATION



COMPLETE. Upon completion of the Handover procedure the Macro Cell eNB starts Timer Tstore_UE_cntxt,

Time = T2 – UE received power from Cell 2 is decreased to zero causing a Radio Link Failure, see Table 3.1-15,

6. A Radio Link Failure occurs in Cell 2.

7. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Small Cell eNB.

8. As there is no UE context in the Small Cell eNB the RRC message RRC CONNECTION REESTABLISHMENT REJECT is sent to the UE,

9. Using the Physical Cell Identity received in the RRC CONNECTION REESTABLISHMENT REQUEST the Small Cell eNB sends X2AP message RLF INDICATION to the Macro Cell eNB,

10. Providing Tstore_UE_cntxt is still running, in the Macro Cell eNB, and the Source cell ECGI is the Small Cell eNB (Cell 1) then the Macro Cell eNB (Cell 2) sends X2AP message HANDOVER REPORT, with the Handover Report Type set to ‘HO too early’ to the Small Cell eNB (Cell 1)

3.1.3.3.1.2 Expected Outcome The Macro Cell eNB indicates a Too Early Handover in X2AP message HANDOVER REPORT.



3.1.3.3.2 Basic Too Early Handover Test Case: Radio Link Failure in a Macro Cell eNB (Cell 2) occurs after Handover Execution


MRO-7

Test Group Too Early Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment,



UE is in RRC-CONNECTED state using Cell 2 under the control of Macro Cell eNB,


Test Case Overview

A Handover procedure is attempted from a Cell in the Macro Cell eNB (Cell 2) to a cell in the Small Cell eNB (Cell 1) using X2 messages. Shortly after the completion of the Handover procedure a Radio Link Failure occurs, leading to the UE attempting a RRC Connection Re-Establishment procedure in Cell 2.

Radio Link Failure

Too Early HO Triggered

Cell 1(Small Cell)

Cell 2(Macro)

Radio Link Failure in Cell 2

Handover procedure successfully completed


Time required to complete Handover Procedure

T0 T1 T2

Time

UERx

Power

Test Case Objective




Time Remark T0 Initial values T1 UE received power from Cell 1 is modified to trigger a Handover from Cell 2 to Cell 1 T2 UE received power from Cell 1 is reduced to zero to trigger a Radio Link Failure





UE

UE

Cell 1

Cell 1

Cell 2

Cell 2









7. RRC: RRC Connection ReEstablishment Request


1. UE is in RRC_CONNECTED State,Intra-LTE RRC Ax Event(s) are active in the UE

Timer Tstore_UE_cntxt

started in the Small Cell


Handover Report Type = HO too earlyHandover Cause,Source cell ECGI = Cell 2 (Macro Cell eNB),Failure cell ECGI = Cell 1 (Small Cell eNB)

Time = T0

Time = T1

Time = T2


2. Time = T1 – UE received power from Cell 1 is increased (emulating UE mobility) to trigger a Handover, see Table 3.1-17.

When the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Macro Cell eNB.

3. The Macro Cell eNB initiates a Handover procedure towards the Small Cell eNB,

4. The Macro Cell eNB sends X2AP message HANDOVER REQUEST to the Small Cell eNB including the Target Cell ID of Cell 1. The Small Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,

5. The Macro Cell eNB sends RRC message RRC CONNECTION RECONFIGURATION including the Mobility Control Information to the UE. After the UE synchronises and successfully accesses the Small Cell eNB the UE sends RRC message RRC CONNECTION RECONFIGURATION COMPLETE. Upon completion of the Handover procedure the Small Cell eNB starts Timer Tstore_UE_cntxt,



Time = T2 – UE received power from Cell 1 is decreased to zero causing a Radio Link Failure, see Table 3.1-17,


7. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Source eNB.

8. As there is no UE context in the Macro Cell eNB the RRC message RRC CONNECTION REESTABLISHMENT REJECT is sent to the UE,

9. Using the Physical Cell Identity received in the RRC CONNECTION REESTABLISHMENT REQUEST the Macro Cell eNB sends X2AP message RLF INDICATION to the Small Cell eNB,

10. Providing Tstore_UE_cntxt is still running, in the Small Cell eNB, and the Source cell ECGI is the Macro Cell eNB (Cell 2) then the Small Cell eNB (Cell 1) sends X2AP message HANDOVER REPORT, with the Handover Report Type set to ‘HO too early’ to the Macro Cell eNB (Cell 2)

3.1.3.3.2.2 Expected Outcome The Small Cell eNB indicates a Too Early Handover in X2AP message HANDOVER REPORT.



3.1.3.4 Test Group: Ping-Pong Handover (HetNet: Small Cell <-> Macro Cell)

3.1.3.4.1 Basic Ping-Pong Handover Test Case: Ping-Pong detected by the Small Cell

Table 3.1-18: MRO: MRO-10: Test Case Overview Test Case Identifier

MRO-10

Test Group Ping-Pong Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment,





Test Case Overview

A Handover procedure is attempted and completed from a Macro Cell eNB (Cell 2) to a cell in the Small Cell eNB (Cell 1) using X2 messages. Shortly after the completion of the Handover procedure a secondary Handover procedure is attempted and completed from the Small Cell eNB (Cell 1) back to the Macro Cell eNB (Cell 2). In order for the sequential handovers to be registered as a Ping-Pong the time the UE stays in the Small Cell eNB (Cell 1), as indicated in the X2AP IE Time UE Stayed in Cell, should be less than or equal to the Minimum Time of Stay (MTS), see Table 3.1-5.

HO Triggered (Cell 2->Cell 1)

Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

UERx

Power

Time


Test Case Objective

To verify that the eNBs involved correctly exchange the X2AP IE UE History Information>Last Visited Cell Information within the HANDOVER REQUEST message.



Time Remark T0 Initial values T1 UE received power from Cell 1 is modified to trigger a Handover from Cell 2 to Cell 1 T2 UE received power from Cell 1 is modified to trigger a Handover from Cell 1 to Cell 2

The time between T1 & T2 should be less than the Minimum Time Of Stay (MTS) in order to register a Ping-Pong Handover, see Table 3.1-5.



3.1.3.4.1.1 Test Procedure Figure 3.1-16: MRO: MRO-10 Test Case Sequence

1. UE is in RRC_CONNECTED State,EUTRA measurements are configured in the UE

UE

UE

Cell 1

Cell 1

Cell 2

Cell 2





4. X2AP: HANDOVER REQUEST


ACKNOWLEDGE

7. Handover Completion






ACKNOWLEDGE


Time = T0

Time = T1

Time = T2

Last Visited Cell List:>1st Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 2)>>Cell Type = large>>Time UE stayed in Cell = test case dependent>...

Last Visited Cell List:>1st Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 1)>>Cell Type = small>>Time UE stayed in Cell = test case dependent>2nd Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 2)>>Cell Type = large>>Time UE stayed in Cell = test case dependent>...

1. Time = T0 – UE received power from Cell 1 and 2 are set to initial values, see Table 3.1-19

2. Time = T1 – UE received power from Cell 1 is increased (emulating UE mobility) to trigger a Handover, see Table 3.1-19



4. The Macro Cell eNB sends X2AP message HANDOVER REQUEST to the Small Cell eNB including the Target Cell ID of Cell 1. The 1st Item in the Last Visited Cell List should be the details of Cell 2.

5. The Small Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,

6. The Handover Execution procedure takes place, see section 10.1.2.1 [2],

7. The Handover Completion procedure takes place, see section 10.1.2.1 [2],

8. Time = T2 – UE received power from Cell 1 is reduced (emulating UE mobility) to trigger a Handover, see Table 3.1-19





10. The Small Cell eNB sends X2AP message HANDOVER REQUEST to the Macro Cell eNB including the Target Cell ID of Cell 2. The 1st Item in the Last Visited Cell List should be the details of Cell 1 with the Time UE stayed in Cell being set to approximately the time between T1 and T2. The 2nd Item in the Last Visited Cell List should be the details of Cell 2.

11. The Macro Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,


13. The Handover Completion procedure takes place, see section 10.1.2.1 [2]

3.1.3.4.1.2 Expected Outcome Both eNBs correctly include the X2AP IE UE History Information>Last Visited Cell Information with the Time UE stayed in Cell for approximately the time between T1 and T2.



3.1.3.4.2 Basic Ping-Pong Handover Test Case: Ping-Pong detected in the Macro Cell


MRO-11

Test Group Ping-Pong Handover References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing Environment,





Test Case Overview

A Handover procedure is attempted and completed from a Small Cell eNB (Cell 1) to a cell in the Macro eNB (Cell 2) using X2 messages. Shortly after the completion of the Handover procedure a secondary Handover procedure is attempted and completed from the Macro Cell eNB (Cell 2) back to the Small Cell eNB (Cell 1). In order for the sequential handovers to be registered as a Ping-Pong the time the UE stays in the Macro Cell eNB (Cell 2), as indicated in the X2AP IE Time UE Stayed in Cell, should be less than or equal to the Minimum Time of Stay (MTS), see Table 3.1-5.


Cell 1(Small Cell)

Cell 2(Macro)

T0 T1 T2

UERx

Power

Time


Test Case Objective

To verify that the eNBs involved correctly exchange the X2AP IE UE History Information>Last Visited Cell Information within the HANDOVER REQUEST message.



Time Remark T0 Initial values T1 UE received power from Cell 2 is modified to trigger a Handover from Cell 1 to Cell 2 T2 UE received power from Cell 2 is modified to trigger a Handover from Cell 2 to Cell 1

Note: The time between T1 & T2 should be less than the Minimum Time Of Stay (MTS) in order to register a Ping-Pong Handover, see Table 3.1-5




UE

UE

Cell 1

Cell 1

Cell 2

Cell 2






the UE

Last Visited Cell List:>1st Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 1)>>Cell Type = small>>Time UE stayed in Cell = test case dependent>...



ACKNOWLEDGE







ACKNOWLEDGE


Time = T0

Time = T1

Time = T2

Last Visited Cell List:>1st Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 2)>>Cell Type = large>>Time UE stayed in Cell = test case dependent>2nd Item>Last Visited Cell Information>E-UTRAN Cell>Last Visited E-UTRAN Cell Information:>>Global Cell Id = ECGI (PLMN Identity + Cell 1)>>Cell Type = small>>Time UE stayed in Cell = test case dependent

1. Time = T0 – UE received power from Cell 1 and 2 are set to initial values, see Table 3.1-19




4. The Small Cell eNB sends X2AP message HANDOVER REQUEST to the Macro Cell eNB including the Target Cell ID of Cell 2. The 1st Item in the Last Visited Cell List should be the details of Cell 1.

5. The Macro Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,


7. The Handover Completion procedure takes place, see section 10.1.2.1 [2],

8. Time = T2 – UE received power from Cell 2 is reduced (emulating UE mobility) to trigger a Handover, see Table 3.1-19





10. The Macro Cell eNB sends X2AP message HANDOVER REQUEST to the Small Cell eNB including the Target Cell ID of Cell 1. The 1st Item in the Last Visited Cell List should be the details of Cell 2 with the Time UE stayed in Cell being set to approximately the time between T1 and T2. The 2nd Item in the Last Visited Cell List should be the details of Cell 1.

11. The Small Cell eNB responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,


13. The Handover Completion procedure takes place, see section 10.1.2.1 [2]

3.1.3.4.2.2 Expected Outcome Both eNBs correctly include the X2AP IE UE History Information>Last Visited Cell Information with the Time UE stayed in Cell for approximately the time between T1 and T2.



3.1.3.5 Test Group: Handover to wrong Cell (HetNet: Small Cell(s) <-> Macro Cell)

3.1.3.5.1 Basic Handover to Wrong Cell Test Case: Small Cell eNB Handed over to Macro Cell eNB, then Re-Establishment attempt in a different Small Cell eNB


MRO-12

Test Group Handover to Wrong Cell References [2][3] Equipment 3 cell configuration; 2 Small Cell eNBs + 1 Macro Cell eNBs, single UE, additional equipment as IOT Testing

Environment, see Figure 2.3-1. Pre-Requisites

A neighbour relation is configured between Cells 1,2 and 3,

UE is in RRC-CONNECTED state using Cell 1 under the control of a Small Cell eNB,


Test Case Overview

A Handover procedure is attempted from a Small Cell eNB (Cell 1) to a cell in the Macro eNB (Cell 2) using X2 messages. Shortly after the completion of the Handover procedure a Radio Link Failure occurs, leading to the UE attempting a RRC Connection Re-Establishment procedure in a different Small Cell eNB (Cell 3).


Radio Link Failure

HO Triggered (Cell 1 to Cell 2)

Cell 1(Small Cell)

Cell 2(Macro)

Radio Link Failure in Cell 2T0 T1 T2

Time

UERx

Power

Cell 3(Small)

HO Completed (Cell 1 to Cell 2)

Test Case Objective




Time Remark T0 Initial values T1 UE received power from Cell 2 is modified to trigger a Handover from Cell 1 to Cell 2 T2 UE received power from Cell 2 is reduced to zero to trigger a Radio Link Failure.

UE received power from Cell 3 is modified to trigger the UE to attempt a RRC Re-Establishment in Cell 3





UE

UE

Cell 1

Cell 1

Cell 2

Cell 2

Vendor A,Small Cell eNB

Vendor B,Macro Cell eNB











the UE

Timer Tstore_UE_cntxt started in the Macro Cell


Handover Report Type = HO to wrong cellHandover Cause,Source cell ECGI = Cell 1 (Small Cell eNB),Failure cell ECGI = Cell 2 (Macro Cell eNB),Re-establishment cell ECGI = Cell 3 (Small Cell eNB)

Time = T0

Time = T1

Time = T2

Cell 3

Cell 3


1. Time = T0 – UE received power from Cell 1, 2 and 3 are set to initial values, see Table 3.1-23


When the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Small Cell eNB (Cell 1).

3. The Small Cell eNB (Cell 1) initiates a Handover procedure towards the Macro Cell eNB (Cell 2),

4. The Small Cell eNB (Cell 1) sends X2AP message HANDOVER REQUEST to the Macro Cell eNB (Cell 2) including the Target Cell ID of Cell 2. The Macro Cell eNB (Cell 2) responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,

5. The Small Cell eNB (Cell 1) sends RRC message RRC CONNECTION RECONFIGURATION including the Mobility Control Information to the UE. After the UE synchronises and successfully accesses the Macro Cell eNB (Cell 2) the UE sends RRC message RRC CONNECTION RECONFIGURATION COMPLETE. Upon completion of the Handover procedure the Macro Cell eNB (Cell 2) starts Timer Tstore_UE_cntxt,

Time = T2 – UE received power from Cell 2 is decreased to zero causing a Radio Link Failure, see Table 3.1-23. UE received power from Cell 3 is increased to enable the UE to choose Cell 3 for the Re-Establishment request,




7. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Small Cell eNB (Cell 3).

8. As there is no UE context in the Small Cell eNB (Cell 3) the RRC message RRC CONNECTION REESTABLISHMENT REJECT is sent to the UE,

9. Using the Physical Cell Identity received in the RRC CONNECTION REESTABLISHMENT REQUEST the Small Cell eNB (Cell 3) sends X2AP message RLF INDICATION to the Macro Cell eNB (Cell 2),

10. Providing Tstore_UE_cntxt is still running, in the Macro Cell eNB (Cell 2), and the Source cell ECGI is the Small Cell eNB (Cell 1) then the Macro Cell eNB (Cell 2) sends X2AP message HANDOVER REPORT, with the Handover Report Type set to ‘HO to wrong cell’ to the Small Cell eNB (Cell 1) providing the X2AP message RLF INDICATION was received from Cell 3.

3.1.3.5.1.2 Expected Outcome The Macro Cell eNB (Cell 2) indicates a HO to wrong cell in X2AP message HANDOVER REPORT.



3.1.3.5.2 Basic Handover to Wrong Cell Test Case: Macro Cell eNB Handed over to Small Cell eNB, then Re-Establishment attempt in a different Macro Cell eNB


MRO-13

Test Group Handover to Wrong Cell References [2][3] Equipment 3 cell configuration; 1 Small Cell eNB + 2 Macro Cell eNBs, single UE, additional equipment as IOT Testing

Environment, see Figure 2.3-1. Pre-Requisites A neighbour relation is configured between Cells 1,2 and 3,



Test Case Overview

A Handover procedure is attempted from a Cell in the Macro Cell eNB (Cell 2) to a cell in the Small Cell eNB (Cell 1) using X2 messages. Shortly after the completion of the Handover procedure a Radio Link Failure occurs, leading to the UE attempting a RRC Connection Re-Establishment procedure in different Macro Cell eNB (Cell 3).


Radio Link Failure

HO Triggered (Cell 2 to Cell 1)

Cell 1(Small Cell)

Cell 2(Macro)

Radio Link Failure in Cell 1T0 T1 T2

Time

UERx

Power

Cell 3(Macro)

HO Completed (Cell 2 to Cell 1)

Test Case Objective




Time Remark T0 Initial values T1 UE received power from Cell 1 is modified to trigger a Handover from Cell 2 to Cell 1 T2 UE received power from Cell 1 is reduced to zero to trigger a Radio Link Failure.

UE received power from Cell 3 is modified to trigger the UE to attempt a RRC Re-Establishment in Cell 3





1. UE is in RRC_CONNECTED State,EUTRA measurements are configured in the UE

UE

UE

Cell 1

Cell 1

Cell 2

Cell 2












Timer Tstore_UE_cntxt started in the Small Cell


Handover Report Type = HO to wrong cellHandover Cause,Source cell ECGI = Cell 2 (Macro Cell eNB),Failure cell ECGI = Cell 1 (Small Cell eNB),Re-establishment cell ECGI = Cell 3 (Macro Cell eNB)

Time = T0

Time = T1

Time = T2

Cell 3

Cell 3


1. Time = T0 – UE received power from Cell 1, 2 and 3 are set to initial values, see Table 3.1-25,

2. Time = T1 – UE received power from Cell 1 is increased (emulating UE mobility) to trigger a Handover, see Table 3.1-25,

When the configured triggering conditions for UE measurements are met the UE sends a Measurement Report to the Macro Cell eNB (Cell 2).

3. The Macro Cell eNB (Cell 2) initiates a Handover procedure towards the Small Cell eNB (Cell 1),

4. The Macro Cell eNB (Cell 2) sends X2AP message HANDOVER REQUEST to the Small Cell eNB (Cell 1) including the Target Cell ID of Cell 1. The Small Cell eNB (Cell 1) responds with X2AP message HANDOVER REQUEST ACKNOWLEDGE,

5. The Macro Cell eNB (Cell 2) sends RRC message RRC CONNECTION RECONFIGURATION including the Mobility Control Information to the UE. After the UE synchronises and successfully accesses the Small Cell eNB (Cell 1) the UE sends RRC message RRC CONNECTION RECONFIGURATION COMPLETE. Upon completion of the Handover procedure the Small Cell eNB (Cell 1) starts Timer Tstore_UE_cntxt,

Time = T2 – UE received power from Cell 1 is decreased to zero causing a Radio Link Failure, see Table 3.1-25. UE received power from Cell 3 is increased to enable the UE to choose Cell 3 for the Re-Establishment request,




7. The UE initiates the RRC Connection Re-establishment procedure by sending RRC message RRC CONNECTION REESTABLISHMENT REQUEST towards the Macro Cell eNB (Cell 3).

8. As there is no UE context in the Macro Cell eNB (Cell 3) the RRC message RRC CONNECTION REESTABLISHMENT REJECT is sent to the UE,

9. Using the Physical Cell Identity received in the RRC CONNECTION REESTABLISHMENT REQUEST the Macro Cell eNB (Cell 3) sends X2AP message RLF INDICATION to the Small Cell eNB (Cell 1),

10. Providing Tstore_UE_cntxt is still running, in the Small Cell eNB (Cell 1), and the Source cell ECGI is the Macro Cell eNB (Cell 2) then the Small Cell eNB (Cell 1) sends X2AP message HANDOVER REPORT, with the Handover Report Type set to ‘HO to wrong cell’ to the Macro Cell eNB (Cell 2) providing the X2AP message RLF INDICATION was received from Cell 3

3.1.3.5.2.2 Expected Outcome The Small Cell eNB (Cell 1) indicates a HO to wrong cell in X2AP message HANDOVER REPORT.



3.1.3.6 Combined Test Group: Multiple Too Late Handovers triggering a SON Parameter change (HetNet: Small Cell <-> Macro Cell)

3.1.3.6.1 Combined Test Case: Multiple Too Late Handovers, Vendor A is Small Cell, Single Direction (Small Cell (Cell 1) -> Macro Cell (Cell 2))

Table 3.1-26: MRO: MRO-20: Test Case Overview Test Case Identifier MRO-20 Test Group Multiple Too Late Handovers References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing


A number of UEs are in RRC-CONNECTED state using Cell 1 under the control of a Small Cell eNB, At least Intra Frequency RRC measurements are active in the UE, In order to make efficient use of the available IOT testing time, the MRO feature parameters should

be configured to enable a SON parameter update as a result of a small number of Handover attempts.

Test Case Overview Run basic test case MRO-3 multiple time for at least the period of time as defined in ‘MRO Timescale of operation’. See section 3.1.3.2.3 for further details.

Test Case Objective To verify Handover parameters are updated by MRO. To observe the MRO impact on Handover performance.





Cell 2

Cell 2

UE

UE

Cell 1

Cell 1


Par

Loop

1. Test Case: MRO-3

3. SON Parameter Update

2. HO Success / Failure Metric

MonitoringTime: At

least MRO Timescale

of operation

1. Execute Test Case MRO-3, see section 3.1.3.2.3,

2. Monitor the success / failure rate of the Handover test cases, see section 2.3 [1],

3. Monitor the SON parameter updates

3.1.3.6.1.2 Expected Outcome Table 3.1-27: Expected Outcome

SON Feature KPI(s) KPI time Periods, see Figure 3.1-9 Period A Period B Period C

Handover Failure Ratio, see section 3.1.3

Constant Decreasing (relative to Period A)

Reduction (relative to Period A)

Ping-Pong Handover Ratio, see section 3.1.3

Should not increase more than an acceptable amount. An acceptable amount of increase is dependent on the individual operator’s policy and/or vendor implementation.





3.1.3.6.2 Combined Test Case: Multiple Too Late Handovers, Single Direction (Macro Cell (Cell 2) -> Small Cell (Cell 1))

Table 3.1-28: MRO: MRO-21: Test Case Overview Test Case Identifier MRO-21 Test Group Multiple Too Late Handovers References [2][3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing


A number of UEs are in RRC-CONNECTED state using Cell 2 under the control of a Macro Cell eNB,

At least Intra Frequency RRC measurements are active in the UE, In order to make efficient use of the available IOT testing time, the MRO feature parameters should

be configured to enable a SON parameter update as a result of a small number of Handover attempts.

Test Case Overview Run basic test case MRO-4 multiple time for at least the period of time as defined in ‘MRO Timescale of operation’ See section 3.1.3.2.4 for further details.

Test Case Objective To verify Handover parameters are updated by MRO. To observe the MRO impact on Handover performance.



Cell 2

Cell 2

UE

UE

Cell 1

Cell 1


Par

Loop

1. Test Case: MRO-4


2. HO Success / Failure Metric

MonitoringTime: At

least MRO Timescale

of operation



1. Execute Test Case MRO-4, see section 3.1.3.2.4,

2. Monitor the success / failure rate of the Handover test cases, see section 2.3 [1],

3. Monitor the SON parameter updates

3.1.3.6.2.2 Expected Outcome

Table 3.1-29: Expected Outcome SON Feature KPI(s) KPI time Periods, see Figure 3.1-9

Period A Period B Period C Handover Failure Ratio, see section 3.1.3

Constant Decreasing (relative to Period A)

Reduction (relative to Period A)

Ping-Pong Handover Ratio, see section 3.1.3






3.1.4 Mobility Load Balancing (MLB)

Mobility Load Balancing (MLB) SON algorithm relies on X2 interface procedures (i.e. Resource Status Reporting, Mobility Setting Change, etc. – see 3GPP TS 36.423 [3]) to exchange information about loading of neighbour cells, with most of system intelligence being proprietary and vendor specific.

The test case coverage will be limited to X2 message exchange with the purpose to ensure the exchanged messages are correctly interpreted by eNBs.

3.1.4.1 Test Group MLB

3.1.4.1.1 Test Case #1: Load Information Exchange

Table 3.1-30: MLB: MLB-1 Test Case Overview Test Case Identifier MLB-1

Test Group MLB

References 3GPP TS36.423

Equipment 1 Macro & 1 Small Cell from different vendors connected over X2 interface

Pre-Requisites Load balancing activated on both eNBs allowing periodic X2 resource status message exchange

Test Case Overview The purpose of X2 resource status reporting procedure is to exchange the reporting of load measurements between eNBs, via X2 interface.

The procedure uses non UE-associated signalling.

TS36.423 introduces X2 RESOURCE STATUS procedures to support load exchange over X2.

To initiate or stop a load exchange, X2 RESOURCE STATUS REQUEST/RESPONSE is used.

To provide cells load, X2 RESOURCE STATUS UPDATE is used

Test Case Objective To verify that each eNB involved correctly exchanges the messages RESOURCE STATUS REQUEST, RESOURCE STATUS RESPONSE, & RESOURCE STATUS UPDATE

3.1.4.1.2 Test Procedure

Observe X2 messages exchanged between the 2 eNodeB using protocol analyser



Figure 3.1-22: MLB: MLB-1 Test Case Sequence

3.1.4.1.3 Expected Output

RESOURCE STATUS REQUEST, RESPONSE & UPDATE are correctly exchanged & interpreted by both Small Cell from the eNodeB vendors: following a Resource Status Request we have as answer Resource Status Response & periodically Resource Status Update

Resource Status Update needs to include Radio Resource Status

Table 3.1-31: MLB-1 Radio Resource Status

ENB1

RESOURCE STATUS RESPONSEeNB1 Measurement IDeNB2 Measurement IDCriticality Diagnostics

RESOURCE STATUS REQUESTeNB1 measurement IDeNB2 measurement IDRegistration Request (start / stop)Report CharacteristicsCell To Report>Cell tTo Report Item>>Cell IDReporting Periodicity

ENB2

RESOURCE STATUS UPDATEeNB1 Measurement IDeNB2 Measurement ID

Cell Measurement Result>Cell Measurement Result Item

>>Cell ID>>Hardware Load Indicator

>>S1 TNL Load Indicator>>Radio Resource Status

>>Composite Available Capacity GroupRESOURCE STATUS UPDATE

......

......

X2ResourceStatus ResponseTimer

enb1::x2ResourceReportPeriodicity

enb1::x2ResourceReportPeriodicity

enb::x2ResourceStatusMaxOverload

enb::x2ResourceStatusMaxOverload



IE/Group Name IE type and reference

DL GBR PRB usage INTEGER (0..100)

UL GBR PRB usage INTEGER (0..100)

DL non-GBR PRB usage INTEGER (0..100)

UL non-GBR PRB usage INTEGER (0..100)

DL Total PRB usage INTEGER (0..100)

UL Total PRB usage INTEGER (0..100)

In case of IOT issue or parameter issue the following sequence implying Resource Status Failure can be observed:

Figure 3.1-23: MLB: MLB-1 Test Case Sequence for the Resource Status Failure

Message TypeeNB1 Measurement ID filled by enB ceNB2 Measurement ID emptyRegistration Request StartReport Characteristics bit1 (PRB) = considered

bit2 (TNL Load) = consideredbit3 (HW Load) = not consideredbit4 (Composite Available Capacity ) = considered

Cell To Report>Cell To Report Item>>Cell ID CellId1

CellId2CellId...

Reporting Periodicity 1000ms, 2000ms, 5000ms,10000ms, …

eNB Controling

Remote eNB

RESOURCE STATUS Failure

RESOURCE STATUS Request

Message TypeeNB1 Measurement ID filled eNB2 Measurement ID Not filledcause filled>CHOICE Cause Group>> Radio Network Layer = Measurement Temporarily not Available

or = ReportCharacteristicsEmptyor = NoReportPeriodicityor = ExistingMeasurementID

Criticality Diagnostics



3.1.4.1.4 Test Case #2: UE mobility because of loaded serving cell (static)

Table 3.1-32: MLB: MLB-2 Test Case Overview Test Case Identifier MLB-2

Test Group MLB

References 3GPP TS36.423

Equipment 1 or 2 small cell using the same frequency carrier + 1 Macro Cell using a different frequency carrier connected over X2

Pre-Requisites features allowing periodic X2 resource status message exchange & mobility activated on all eNodeBServing small cell loaded, it means CellLoadedThreshold has been reached (relative to vendor implementation)

Macro Cell unload: it means Resource Status Update reports DL Total PRB usage low regarding CellLoadedThreshold

UEs must support inter-frequency handover and event A4.

UEs must support the carrier of at least one configured LTE neighbour

UEs are not in an ongoing procedure, including release, handover, CCO and ANR procedure

UEs must have at least one established eRAB

Test Case Overview

Mobility can be trigged following load evolution; in this case the serving cell becomes too loaded to keep all traffic and need to move some UE to another carrier covering the same area.

Test Case Objective

Due to high loaded situation UE need to move from Serving Cell (small cell based) to inter-freq neighbour as it has been reported as unload through Resource Status update



Radio Resource Status shared by the inter-freq neighbour reports

• DL GBR PRB usage • UL GBR PRB usage • DL non-GBR PRB usage • UL non-GBR PRB usage • DL Total PRB usage • UL Total PRB usage

that the cell is unloaded and can allow to catch serving cell traffic

3.1.4.1.4.1 Test Procedure Observe exchanged messages over X2 using protocol analyser to check

1. Ensure serving cell is loaded to ensure mobility mechanism in inter-frequency is engaged for 1 UE (vendor system dependent: threshold number users, threshold PRB usage, etc.)

2. Ensure inter-frequency cell reports unloaded PRB usage through ResourceStatusUpdate 3. Inter-frequency HO is requested by Serving Cell



Figure 3.1-24: MLB: MLB-2 Test Case Sequence

Message TypeeNB1 Measurement ID filled eNB2 Measurement ID filledCell Measurement Result>Cell Measurement Result Item>>Cell ID>>Hardware Load Indicator not filled

>>S1 TNL Load Indicator>>>DL S1TNL Load Indicator filled [Load Indicator = enum (LowLoad, MediumLoad, HighLoad, Overload, ...)]>>>UL S1TNL Load Indicator filled [Load Indicator =]

>>Radio Resource Status>>>DL GBR PRB usage filled [=INTEGER (0..100)]>>>UL GBR PRB usage filled >>>DL non-GBR PRB usage filled >>>UL non-GBR PRB usage filled >>>DL Total PRB usage filled >>>UL Total PRB usage filled

>>Composite Available Capacity Group>>>Composite Available Capacity Downlink>>>>Cell Capacity Class Value filled [=INTEGER (0..100)]>>>>Capacity Value filled [=INTEGER (0..100)]>>>Composite Available Capacity Uplink>>>>Cell Capacity Class Value filled [=INTEGER (0..100)]>>>>Capacity Value filled [=INTEGER (0..100)]

eNB Controling

Remote eNB

RESOURCE STATUS Update

RESOURCE STATUS Update

Reporting Periodicity

timer



DL Data (End Marker)

DL Data Forwarding (End Marker)

UE Source ENB MME/SGWTarget ENB

DL Data

Han

dove

r Com

plet

ion

Han

dove

r Exe

cutio

nH

ando

ver P

repa

ratio

n

Handover decision

HANDOVER REQUEST

UE Context Information

Setup of UE context and associated resources

HANDOVER REQUEST ACKNOWLEDGESAE Bearers Admitted List

Target eNodeB to Source eNodeB Transparent Container

Start forwarding DL packets to Target eNB

Start buffering packets from Source eNB

DL Data

DL Data Forwarding

SN STATUS TRANSFERSAE Bearers Subject to Status Transfer List

Detach from old cell and synchronize to new cell

Random Access Preamble

Random Access Response

PATH SWITCH REQUESTSAE Bearer To Be Switched in Downlink List

DL Data Forwarding

DL Data

PATH SWITCH REQUEST ACKNOWLEDGE

RELEASE RESOURCE

Continue forwarding DL packets

Release UE context and associated resources Release X2 resources

DL Data

UE Source ENB Target ENB MME/SGW

Path switch

DL Data

Start buffering packets from S1

Transmit all DL X2 packets before S1

MeasurementReport

measIdmeasResultServingneighbouringMeasResults

RRCConnectionReconfigurationMeasurementConfigurationMobilityControlInformation

RadioResourceConfigDedicatedUE-RelatedInformation

RRCConnectionReconfigurationCompleteStart transmitting DL packets

Default SAE Bearer establishment and security activation [A15]RRC measurement configuration for inter-freq [A18]

RRC measurement configuration for intra-freq [A18]

4. Inter-frequency Handover successful

3.1.4.1.4.2 Expected Output Inter-frequency Handover is performed between Small Cell (serving cell) and Macro because of high PRB usage so loaded situation



3.1.5 Coverage and Capacity Optimisation (CCO)

CCO IOT Methodology Discussion: According to section 3 in NGMN [1] the performance aim of CCO is to improve the Quality of Experience in terms of coverage quality and call setup success rate. In addition a further aim is to optimise the throughput distribution.

In terms of SON parameter updates the Small Cell eNB has the option to update the DL transmit power based on optimisation by the CCO SON feature.

The following diagram shows an example scenario where the Small Cell decreases its DL transmit power, based on a SON parameter update for CCO.

In the diagram below the 4 UEs (A/B/C/D) near the cell edge of Cell 1 benefit from the decrease in DL Tx power in Cell 1:

• UEs C & D: Less interference is experienced by the 2 UEs at the Small Cell edge under the control of the macro cell following the decrease in DL Tx power in Cell 1. Initially Cell 1 is unaware of these UEs,

• UE A: Hands over to Cell 2 and should experience less interference, • UE B: Should experience a higher throughput due to the load decreasing in Cell 1.

Figure3.1-25: Small Cell decreases DL Tx Power following CCO

Cell 2(Macro)

Cell 1

Cell 2(Macro)

Cell 1

H

H

M

M

L

L

H

M

M

M

L

L

H

H

M

M

H

M

M

M

M

MM

M

Cell 1Decrease of DL Tx Power

Key:

- UE is under the control of Cell 1


- High User throughput

- Medium User throughput

- Low User throughput

- Change following the Increase/Decrease of DL Tx Power

H

M

L

UE A

UE B

UE C

UE DUE A

UE B

UE C

UE D

During IOT testing in a HetNet environment, the conditions should be created where the X2 reported Load Information is a factor leading to the Small Cell eNB to change its DL Tx power.



For Combined Test cases as described in section 2.2 (Step 2), it is necessary to define the test case outcome in terms of the applicable SON feature KPI(s).

For CCO the following diagram example defines 3 time periods (A, B and C). In the combined test case expected outcome sections below, the expected behaviour of each applicable KPI is described according to the 3 time periods.

Figure3.1-26: CCO: KPI time Periods

Time

Combined Test Case overall duration/run time

KPI: Per User Throughput

Period A Period B Period C

(Initial State,Pre-CCO)

(Transient State,

CCO Running)

(Converged State,

Post CCO)

UE C

UE BUE A

3.1.5.1 CCO IOT Environment Common Parameters

Table 3.1-33: CCO Opt IOT Parameter Alignment SON Parameter Ref. Description Alignment Necessary Recommendation Reporting Periodicity [3] This parameter is used within

the X2AP RESOURCE STATUS REQUEST to defined the time interval between two subsequent RESOURCE STATUS UPDATE reports

Agree on a suitable value 10000ms



3.1.5.2 Test Group: X2AP Resource Status Reporting (HetNet: Small Cell <-> Macro Cell)

3.1.5.2.1 Basic Test Case: Resource Status Reporting Initiated from Small Cell eNB (Cell 1) towards Macro Cell eNB (Cell 2)

Table 3.1-34: CCO: CCO-1: Test Case Overview Test Case Identifier CCO-1 Test Group X2AP Resource Status Reporting References [3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing


Default DL Transmission power level is set for the Small Cell eNB Cell (Cell 1), - NOTE: it is assumed the maximum transmit power of the Small Cell is reasonably high e.g. 4W or 5W,

Default DL Transmission power level is set for the Macro Cell eNB Cell (Cell 2),

A single UE is in RRC-CONNECTED state in Cell 2,

The RRC-CONNECTED UE creates an amount of DL traffic load in the cell e.g. initiate a FTP download

Test Case Overview A Small Cell eNB (Cell 1) initiates the X2 Resource Status Reporting procedure towards the Macro Cell eNB (Cell 2). Upon successful initiation the Macro Cell eNB should provide period Load information for Cell 2.

Test Case Objective To verify that each eNB involved correctly exchanges the applicable Load information over the X2 interface during the Resource Status Reporting procedure.





Figure 3.1-27: CCO: CCO-1: Test Case Sequence

UE

UE

Cell 1

Cell 1

Cell 2

Cell 2


2. X2AP: RESOURCE STATUS REQUEST

eNB1 Measurement ID = Allocated by Small Cell eNB,Registration Request = start,Report Characteristics = PRB Periodic,Cell To Report = Cell 2,Reporting Periodicity = 10000ms

3. X2AP: RESOURCE STATUS RESPONSE

eNB1 Measurement ID = Allocated by Small Cell eNB,eNB2 Measurement ID = Allocated by Macro Cell eNB,Measurement Initiation Result>Measurement Initiation Result Item>Cell ID = Cell 2Loop

4. X2AP: RESOURCE STATUS UPDATE

eNB1 Measurement ID = Allocated by Small Cell eNB,eNB2 Measurement ID = Allocated by Macro Cell eNB,Cell Measurement Results>Cell Measurement Result Item>Cell ID = Cell 2>Radio Resource Status = UL/DL GBR/non-GBR/Total PRB usage

1. Pre-requisites: as defined in Test Case Overview

1. The pre-requisites are set according to the Test Case Overview in Table 3.1-34, 2. The Small Cell eNB (Cell 1) initiates the X2AP Resource Status Reporting via the sending of

X2AP message RESOURCE STATUS REQUEST, 3. The Macro Cell eNB (Cell 2) accepts the Resource Status request via the sending of X2AP

message RESOURCE STATUS RESPONSE, 4. According to the Reporting Periodicity defined in X2AP message RESOURCE STATUS

REQUEST the Macro Cell eNB (Cell 2) sends X2AP message RESOURCE STATUS UPDATE containing the Measurement Results for Cell 2

3.1.5.2.1.2 Expected Outcome The Macro Cell eNB (Cell 2) accepts the Resource Status Reporting Initiation and is able to periodically provide the Small Cell eNB the requested Load Measurement Results.



3.1.5.2.2 Basic Test Case: Resource Status Reporting Initiated from Macro Cell eNB (Cell 2) towards Small Cell eNB (Cell 1)

Table 3.1-35: CCO: CCO-2: Test Case Overview Test Case Identifier CCO-2 Test Group X2AP Resource Status Reporting References [3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, single UE, additional equipment as IOT Testing




A single UE is in RRC-CONNECTED state in Cell 1,

The RRC-CONNECTED UE creates an amount of DL traffic load in the cell e.g. initiate a FTP download

Test Case Overview A Macro Cell eNB (Cell 2) initiates the X2 Resource Status Reporting procedure towards the Small Cell eNB (Cell 1). Upon successful initiation the Small Cell eNB should provide period Load information for Cell 1.

Test Case Objective To verify that each eNB involved correctly exchanges the applicable Load information over the X2 interface during the Resource Status Reporting procedure.


3.1.5.2.2.1 Test Procedure Figure 3.1-28: CCO: CCO-2: Test Case Sequence

UE

UE

Cell 1

Cell 1

Cell 2

Cell 2


x. X2AP: RESOURCE STATUS REQUEST

eNB1 Measurement ID = Allocated by Macro Cell eNB,Registration Request = start,Report Characteristics = PRB Periodic,Cell To Report = Cell 1,Reporting Periodicity = 10000ms

x. X2AP: RESOURCE STATUS RESPONSE

eNB1 Measurement ID = Allocated by Macro Cell eNB,eNB2 Measurement ID = Allocated by Small Cell eNB,Measurement Initiation Result>Measurement Initiation Result Item>Cell ID = Cell 1Loop

x. X2AP: RESOURCE STATUS UPDATE

eNB1 Measurement ID = Allocated by Macro Cell eNB,eNB2 Measurement ID = Allocated by Small Cell eNB,Cell Measurement Results>Cell Measurement Result Item>Cell ID = Cell 1>Radio Resource Status = UL/DL GBR/non-GBR/Total PRB usage


1. The pre-requisites are set according to the Test Case Overview in Table 3.1-35,



2. The Macro Cell eNB (Cell 2) initiates the X2AP Resource Status Reporting via the sending of X2AP message RESOURCE STATUS REQUEST,

3. The Small Cell eNB (Cell 1) accepts the Resource Status request via the sending of X2AP message RESOURCE STATUS RESPONSE,

4. According to the Reporting Periodicity defined in X2AP message RESOURCE STATUS REQUEST the Small Cell eNB (Cell 1) sends X2AP message RESOURCE STATUS UPDATE containing the Measurement Results for Cell 1

3.1.5.2.2.2 Expected Outcome The Small Cell eNB (Cell 1) accepts the Resource Status Reporting Initiation and is able to provide the requested Load Measurement Results to Macro Cell eNB periodically.



3.1.5.3 Combined Test Group: Static UE Distribution: CCO SON Parameter update (HetNet: Small Cell <-> Macro Cell)

3.1.5.3.1 Combined Test Case: Static UE Distribution: Decrease in Small Cell DL Tx Power Table 3.1-36: CCO: CCO-10: Test Case Overview


CCO-10

Test Group CCO SON Parameter change References [3] Equipment 2 cell configuration; Small Cell eNB + Macro Cell eNB, 3 UEs, additional equipment as IOT Testing Environment, see

Figure 2.3-1. Pre-Requisites




UE A: Under the control of Macro Cell eNB (Cell 2), configured to emulate (via attenuation) being near the Small Cell edge i.e. fair radio conditions and a medium user throughput,

UE B: Under the control of Small Cell eNB (Cell 1), configured to emulate (via attenuation) being at the Small Cell edge i.e. poor radio conditions and a low user throughput,

UE C: Under the control of Small Cell eNB (Cell 1), configured to emulate (via attenuation) good radio conditions and hence achieve a high user throughput,

All RRC-CONNECTED UEs creates an amount of DL traffic load in the cell e.g. initiate a FTP download

Following the UE received power settings above for UE’s A/B/C, the UE received power remains static for the duration of the test case i.e. the UE’s are considered to be stationary.

Test Case Overview

As a result of the radio and throughput conditions in the Small Cell (Cell 1) the eNB triggers the SON CCO feature resulting in a decrease in Small Cell DL Tx power. The following diagram illustrates the change in conditions following the CCO SON update.

Cell 2(Macro)

Cell 1

Cell 2(Macro)

Cell 1H

L

H

M

Cell 1Decrease of DL Tx Power

Key:



- High User throughput

- Medium User throughput

- Low User throughput

- Change following the DL Tx Power level update

H

M

L

UE B

UE C

UE B

UE C

MUE A

MUE A

The following simplified diagram illustrates the change in Cell radio conditions and average user throughput over time.



Av. Small Cell DL User Throughput

Small Cell Tx Power

Time

Av. Macro Cell RFQ

Av. Small Cell PRB usage

Av. Small Cell RFQ

Av. Macro Cell DL User Throughput

Macro Cell Tx Power

Time

Av. Macro Cell PRB usage

Total DL User Throughput

Time

Test Case Objective

To verify that the DL Tx power for the Small Cell eNB (Cell 1) is updated by the CCO feature. To observe the CCO impact on the overall user throughput


3.1.5.3.1.1 Test Procedure Figure 3.1-29: CCO: CCO-10: Test Case Sequence

Cell 2

Cell 2

UE

UE

Cell 1

Cell 1



2. Test Case: CCO-1




1. The pre-requisites are set according to the Test Case Overview in Table 3.1-36,

2. Test Case CCO-1 is executed, see section 3.1.5.2.1,

3. The CCO SON feature updates the SON parameters i.e. Cell 1 DL Tx power is reduced,

3.1.5.3.1.2 Expected Outcome Table 3.1-37: Expected Outcome

SON Feature KPI(s) KPI time Periods, see Figure3.1-26 Period A Period B Period C

User Throughput (measured at the UE)

UE A No change Not measured Increase UE B No change Not measured Increase UE C No change Not measured Increase



3.2 Architecture Option 2: Macro Cell Centralized SON and Small Cell Distributed SON

3.2.1 PCI Optimisation

3.2.1.1 PCI Optimisation IOT Environment Common Parameters Table 3.2-1: PCI Opt IOT Parameter Alignment

SON Parameter Ref. Description Alignment Necessary Recommendation

3.2.1.2 Test Group: PCI Initialization

3.2.1.2.1 Test Case: CSON-PCI-01: Initialization in a greenfield network

Table 3.2-2: CSON-PCI01 Test Case Overview Test Case Identifier CSON-PCI-01

Test Group PCI Initialization


Equipment • One LTE Small Cell • One LTE Macro Cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • No LTE Small Cells up and running in the vicinity of the LTE Small Cell in question • LTE Small Cell EARFCN and location information is available to the Centralized SON Server • LTE Macro Cell EARFCN and location information is available to the Centralized SON Server

Test Case Overview A new LTE Small Cell is powered up and the CSON server provides a valid PCI range or valid PCI value for the LTE Small Cell.

Test Case Objective Test if the CSON server provides a valid PCI range or PCI value to the LTE Small Cell




Figure 3.2-1: CSON-PCI-01 Test Case Configuration Example


1. Verify that there are no LTE Small Cells in the close vicinity of the new LTE Small Cell. 2. Note down the PCIs of the LTE Macro Cell in the vicinity. 3. The Centralized SON Server configures the valid PCI range for the LTE Small Cell on the (H)eMS

a. The Centralized SON Server could provide a single PCI value for the LTE Small Cell as well 4. Power up the new LTE Small Cell and run the required activation procedure (if applicable) 5. Configure the PCI range (provided by the Centralized SON Server) on the LTE Small Cell. 6. Initialize the LTE Small Cell.

3.2.1.2.1.2 Expected Output 1. The new LTE Small Cell should log the PCI that it has selected 2. The range of PCIs provided by the Centralized SON Server does not conflict with the LTE Macro

Cells in the vicinity 3. The selected PCI should be from the PCI range that was provided as input 4. The selected PCI should not conflict with the PCIs of the LTE Macro Cells in the vicinity

SmallCell-1 PCI 101

Macro-1 PCI 100



3.2.1.2.2 Test Case: CSON-PCI-02: Initialization in existing network

Table 3.2-3: CSON-PCI-02 Test Case Overview Test Case Identifier CSON-PCI-02

Test Group PCI Initialization


Equipment • Two LTE Small Cells • One LTE Macro Cells • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • One LTE Small Cell & one LTE Macro Cells up and running in the vicinity of the LTE Small Cell in question

• LTE Small Cells EARFCN and location information is available to the Centralized SON Server • LTE Macro Cell EARFCN and location information is available to the Centralized SON Server

NOTE: This test case can be run with one LTE Small Cell and Two Macro Cells or Two Small Cells and one Macro Cell.

Test Case Overview A new LTE Small Cell is powered up in the vicinity of an existing LTE small cell network and the CSON server provides a valid PCI range or valid PCI value for the LTE Small Cell.

Test Case Objective Test if the CSON server provides a valid PCI range or PCI value to the LTE Small Cell taking into account existing LTE Macro and Small Cells

3.2.1.2.2.1 Test Procedure Figure 3.2-2: CSON-PCI-02 Test Case Configuration Example


1. Verify that there are multiple (at least two) LTE Small Cells in the close vicinity of the new LTE Small Cell.

2. Note down the PCIs of the LTE Small Cells & Macro Cells in the vicinity.

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 102



3. The Centralized SON Server configures the valid PCI range for the new LTE Small Cell on the (H)eMS

a. The Centralized SON Server could provide a single PCI value for the new LTE Small Cell as well

4. Power up the new LTE Small Cell and run the required activation procedure (if applicable) 5. Configure the valid PCI range on the LTE Small Cell. 6. Initialize the LTE Small Cell.

3.2.1.2.2.2 Expected Output 1. The new LTE Small Cell should log the PCI that it has selected 2. The range of PCIs provided by the Centralized SON Server does not conflict with the LTE Macro

Cells in the vicinity 3. The selected PCI should be from the PCI range that was provided as input 4. The selected PCI should not conflict with the PCIs of the LTE Small Cells or Macro Cells in the

vicinity



3.2.1.3 Test Group: PCI Conflict / Confusion Detection

3.2.1.3.1 Test Case: CSON-PCI-04: Detect PCI Conflict with Neighbour Cell

Table 3.2-4: PCI-04 Test Case Overview Test Case Identifier CSON-PCI-04



Equipment • LTE UE • 2 LTE Small Cells / Macro cells • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • LTE Small Cells with the same PCI having overlapping coverage • LTE Small Cell EARFCN and location information is available to the Centralized SON Server

Test Case Overview When there are two LTE Small Cells with the same PCI are next to each other, the Centralized SON Server should detect that there is a PCI conflict

Test Case Objective When there are two LTE Small Cells with the same PCI are next to each other, the Centralized SON Server should detect that there is a PCI conflict



1. Verify that there are two LTE Small Cells with the same PCI in close vicinity of each other. 2. The EARFCN and location information of the LTE Small Cells is obtained from the (H)eMS by the

Centralized Server 3. The Centralized SON Server detects that the LTE Small Cells have conflicting PCIs

3.2.1.3.1.2 Expected Output 1. The Centralized SON Server should detect and log the PCI conflict



3.2.1.3.2 Test Case: CSON-PCI-05: Detect PCI Confusion with Neighbour Cells

Table 3.2-5: CSON-PCI-05: Test Case Overview Test Case Identifier CSON-PCI-05



Equipment • LTE UE • 3 LTE Cells with at least one LTE Small Cell and one LTE Macro cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • One LTE Small Cells with overlapping coverage with two non-overlapping LTE Cells with the same PCI value

• LTE Cell EARFCN and location information is available to the Centralized SON Server • LTE Cells report their neighbour lists to the (H)eMS and that neighbour list info is made available

to the Centralized SON Server


Test Case Overview When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then the Centralized SON Server should detect that there is a PCI confusion

Test Case Objective When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then the Centralized SON Server should detect that there is a PCI confusion


Figure 3.2-3: CSON-PCI-05 Test Case Configuration Example


1. Verify that coverage of the 3 LTE Cells is similar to the figure above a. LTE-2 is a Small Cell b. Either LTE-1 and LTE-3 cells are macro cells or one of them could be a macro cell

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 102



2. The EARFCN and location information of the LTE Cells is obtained from the (H)eMS by the Centralized Server

3. A UE moves in the area covered by all the three LTE Cells as well as the overlapping areas between the LTE-1 & LTE-2 and LTE-3 & LTE-2.

a. The UE is configured to provide periodic measurement reports 4. The LTE Cells populate their neighbour lists and upload their neighbour lists to the (H)eMS 5. The Centralized SON Server retrieves the uploaded neighbour lists from the (H)eMS 6. The Centralized SON Server detects that there is PCI confusion between two LTE Small Cells

Note: This test procedure is independent of whether the LTE Small Cells can set up X2 connections between each other.

3.2.1.3.2.2 Expected Output 1. The Centralized SON Server should detect and log the PCI confusion



3.2.1.4 Test Group: PCI Conflict / Confusion Resolution

3.2.1.4.1 Test Case: CSON-PCI-06: PCI Conflict Resolution




Equipment • LTE UE • 2 LTE Small Cells / Macro cells • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • 2 LTE Small Cells with the same PCI having overlapping coverage • LTE Small Cell EARFCN and location information is available to the Centralized SON Server


Test Case Overview When there are two LTE Small Cells with the same PCI are next to each other, the Centralized SON Server should detect that there is a PCI conflict and resolve it

Test Case Objective When there are two LTE Small Cells with the same PCI are next to each other, the Centralized SON Server should detect that there is a PCI conflict and resolve it

3.2.1.4.1.1 Test Procedure The test procedure is described below:

1. Verify that there are two LTE Small Cells with the same PCI in close vicinity of each other. 2. The EARFCN and location information of the LTE Small Cells is obtained from the (H)eMS by the

Centralized Server 3. The Centralized SON Server detects that the LTE Small Cells have conflicting PCIs 4. The Centralized SON Server informs the (H)eMS to change the PCI of one of the conflicting LTE

Small Cells by providing the new PCI value 5. The (H)eMS changes the PCI value of the LTE Small Cell in question

3.2.1.4.1.2 Expected Output 1. The Centralized SON Server should detect and log the PCI conflict 2. The Centralized SON Server should resolve the PCI conflict by selecting one of the conflicting LTE

Small Cells and providing the new PCI to it



3.2.1.4.2 Test Case: CSON-PCI-07: PCI Confusion Resolution




Equipment • LTE UE • 3 LTE Cells with at least one LTE Small Cell and one LTE Macro cell • EPC with MME, SGW, PGW; HeNBGW and SeGW are optional • (H)eMS • Centralized SON Server

Pre-Requisites • One LTE Small Cells with overlapping coverage with two non-overlapping LTE Cells with the same PCI value

• LTE Cell EARFCN and location information is available to the Centralized SON Server • LTE Cells report their neighbour lists to the (H)eMS and that neighbour list info is made available

to the Centralized SON Server

Test Case Overview When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then the Centralized SON Server should detect that there is a PCI confusion and resolve it

Test Case Objective When there is one LTE Small Cell that has two LTE Cell neighbours with the same PCI, then the Centralized SON Server should detect that there is a PCI confusion and resolve it


Figure 3.2-4: CSON PCI-07 Test Case Configuration Exam


1. Verify that coverage of the 3 LTE Cells is similar to the figure above a. LTE-2 is a Small Cell b. Either LTE-1 and LTE-3 cells are macro cells or one of them could be a macro cell

SmallCell-1 PCI 101

Macro-1 PCI 100

SmallCell-2 PCI 102



2. The EARFCN and location information of the LTE Cells is obtained from the (H)eMS by the Centralized Server

3. A UE moves in the area covered by all the three LTE Cells as well as the overlapping areas between the LTE-1 & LTE-2 and LTE-3 & LTE-2.

a. The UE is configured to provide periodic measurement reports 4. The LTE Cells populate their neighbour lists and upload their neighbour lists to the (H)eMS 5. The Centralized SON Server retrieves the uploaded neighbour lists from the (H)eMS 6. The Centralized SON Server detects that there is PCI confusion between two LTE Cells 7. The Centralized SON Server informs the (H)eMS to change the PCI of one of the conflicting

LTE Cells by providing the new PCI value 8. The (H)eMS changes the PCI value of the LTE Cell in question

3.2.1.4.2.2 Expected Output 1. The Centralized SON Server should detect and log the PCI conflict 2. The Centralized SON Server should resolve the PCI conflict by selecting one of the conflicting LTE

Cells and providing the new PCI to it



3.2.2 Mobility Robustness Optimisation

These tests operate under the assumptions that:

(1) the X2 interface between the Small Cell and the Macro Cell is supported together with the applicable SON related X2AP IEs and

(2) the centralised SON for Macro Cells is able to perform based only on information received from Macro cell (i.e. there is no PM collection from SmallCell),

If these assumptions are valid then the test groups/cases for Architecture Option 1 are also applicable to Architecture Option 2.

Note: The above assumptions cannot be validated until more information regarding Macro SON is received.

MRO IOT Methodology Discussion:

See section 3.1.3.

3.2.2.1 MRO IOT Environment Common Parameters See section 3.1.3.1.

3.2.2.2 Test Group: Too Early Handover (HetNet: Small Cell <-> Macro Cell) See section 3.1.3.2,

3.2.2.3 Test Group: Too Late Handover (HetNet: Small Cell <-> Macro Cell) See section 3.1.3.3.

3.2.2.4 Test Group: Ping-Pong Handover (HetNet: Small Cell <-> Macro Cell) See section 3.1.3.4.

3.2.2.5 Test Group: Handover to wrong Cell (HetNet: Small Cell(s) <-> Macro Cell) See section 3.1.3.5.

3.2.2.6 Test Group: Multiple Too Late Handovers triggering a SON Parameter change (HetNet: Small Cell <-> Macro Cell)

See section 3.1.3.6.



3.2.3 Coverage and Capacity Optimisation

These tests operate under the assumptions that:

(1) the X2 interface between the Small Cell and the Macro Cell is supported together with the applicable SON related X2AP IEs and

(2) the centralised SON for Macro Cells is able to perform based only on information received from Macro cell, (i.e. there is no PM collection from SmallCell),

If these assumptions are valid then the test groups/cases for Architecture Option 1 are also applicable to Architecture Option 2.

Note: The above assumptions cannot be validated until more information regarding Macro SON is received.

CCO IOT Methodology Discussion:

See section 3.1.5.

3.2.3.1 CCO IOT Environment Common Parameters See section 3.1.5.1.

3.2.3.2 Test Group: X2AP Resource Status Reporting (HetNet: Small Cell <-> Macro Cell) See section 3.1.5.2.

3.2.3.3 Test Group: Static UE Distribution: CCO SON Parameter update (HetNet: Small Cell <-> Macro Cell)

See section 3.1.5.3.



3.3 Centralized-NM-based SON for Small Cell and Macro Cell

3.3.1 Basic Tests

3.3.1.1 Test Group: Basic Tests (EMS <-> Centralized SON)

3.3.1.1.1 CM Pulling

The test configuration shown in Figure 3.3-1 is used for this test.

Figure 3.3-1: Basic Test Configuration

Table 3.3-1: Basic 1 Test Case Overview Test Case Identifier

Basic-1

Test Group Basic Test

References [2] [5]

Equipment 1 Cell Configuration, to be agreed by NGMN/SCF.

1 eNB and EMS per Vendor.

Pre-Requisites Radio parameters of eNB can be configured by Centralized SON via EMS.

Test Case Overview

To configure radio parameters of eNB via EMS and check if the configured parameters are correctly updated in the CM file pulled by Centralized SON.

- Configure radio parameters of eNB via EMS. - Wait until the Centralized SON pulls the CM file after the CM pulling period. - Compare CM file and the radio configuration of eNB.

Test Case Objective

To verify that EMS is providing correct CM to the Centralized SON

3.3.1.1.1.1 Test Procedures



1. Set CM Pulling period: For example, 15 minute. 2. Configure radio parameters of eNB via EMS.

a. Transmit power b. PCI

3. Wait for the CM Pulling period until the Centralized SON pulls the CM file from EMS. 4. Compare CM file and the radio configuration of eNB. 5. Repeat the test for small cell eNB and macro cell eNB.

3.3.1.1.1.2 Expected Output The test case is considered to have passed if the CM file reflects all the configured radio parameters.

3.3.1.1.2 CM Pushing

The same configuration shown in Figure 3.3-1 is used for this test.

Table 3.3-2: Basic 2 Test Case Overview Test Case Identifier Basic-2


References


1 eNB and EMS per Vendor.


Test Case Overview To configure radio parameters of eNB by Centralized SON .

- Centralized SON pushes the CM file at EMS. - Compare CM file and the configuration of eNB.

Test Case Objective To verify that EMS is receiving and updating eNB based on CM pushed by Centralized SON.

3.3.1.1.2.1 Test Procedures 1. Centralized SON pulls the CM file of eNB via EMS. 2. Centralized SON configures radio parameters of eNB.

a. Transmit power b. PCI

3. Centralized SON pushes the CM file at EMS. 4. Wait for response from EMS indicating success or failure of CM push 5. Compare the pushed CM file and the radio configuration of eNB.

a. The waiting period for EMS to configure eNB depends on vendor’s implementation. 6. Repeat the test for small cell eNB and macro cell eNB.

3.3.1.1.2.2 Expected Output The test case is considered to have passed if all the configured radio parameters at eNB match with the CM file.



3.3.1.1.3 PM Pulling

The same configuration shown in Figure 3.3-1 is used for this test.

Table 3.3-3: Basic 3 Test Case Overview Test Case Identifier

Basic-3


References [2] [5]


One eNB and EMS per Vendor.

Pre-Requisites

UE is in RRC-CONNECTED state under the control of the eNB B.

Radio parameters of eNB can be configured by Centralized SON via EMS.

Pre-configure NRT of eNB A and eNB B so that NRTs have each other as neighbour cells.

Test Case Overview

To generate a handover and check if PM file is showing handover.

- Adjust transmit power of eNB A and eNB B so that HO (B A) can be made. - Check if the pulled PM files by Centralized SON from EMS A and EMS B include handover records. .

Test Case Objective

To verify that EMS is providing correct PM to Centralized SON.

3.3.1.1.3.1 Test Procedures 1. Add eNB B in NRT of eNB A via EMS A. 2. Add eNB A in NRT of eNB B via EMS B. 3. Adjust transmit power of eNB A and eNB B so that UE can be handover to eNB A. 4. Centralized SON pulls the PM data from EMS A and check if HO is recorded. 5. Repeat the test for EMS B by starting the test with UE RRC-connected in eNB A.

3.3.1.1.3.2 Expected Output The test case is considered to have passed if the PM file shows the HO record.



3.3.2 PCI (Physical Cell ID) Optimization Test

3.3.2.1 Test Group: PCI Confusion (Small Cell <-> Macro Cell)

3.3.2.1.1 Basic PCI Confusion Test Case: PCI Confusion occurs when UE tries to handover between Macro Cell eNB from Vendor A and Small Cell eNBs from Vendor B

Figure3.3-2: Test Configuration for PCI Confusion

Table 3.3-4: PCI-3 Test Case Overview Test Case Identifier PCI-1

Test Group PCI Confusion

References [2] [5]


One Macro Cell eNB from Vendor A and two Small Cells eNBs from vendor B.

Vendor A EMS and Vendor B EMS

Pre-Requisites UE is in RRC-CONNECTED state under the control of a Small Cell eNB B1 (Vendor B),

Radio parameters of eNB can be configured by Centralized SON via EMS.

Each eNB is ready to provide CM, PM and KPIs to Centralized SON.

Test Case Overview In the same coverage of a macro cell, there exist two small cells (eNB B1, B2) that have same PCI value with different. ECGIs. One small cell (B1) is in the NRT of macro cell and the other small cell (B2) is not in the NRT.

- Adjust transmit power of eNB A and eNB B1, B2 so that HO occurs from B1 to A - Adjust transmit power of eNB A and eNB B1, B2 so that HO occurs from A to B2. - After decoding PCI of B2, eNB A think B2 as B1, which leads to HO failure due to PCI

confusion. - After HO failures occur, centralized SON identifies HO failure due to PCI confusion from

PM/CM file. - Centralized SON assigns new PCI to the small cell that introduced PCI confusion.

Test Case Objective To verify that the centralized SON identifies the PCI confusion and resolves PCI confusion by assigning



new PCI via the EMS that controls the small cells.

3.3.2.1.1.1 Test Procedures 1. Configure eNB A, B1 and B2 with PCI values of 100, 101 and 101 with different ECGI values. 2. Adjust transmit power of eNB B2 lower than Th1 dBm so that UE will not HO to eNB B2. 3. Adjust transmit power of eNB A and eNB B1 so that UE is triggered to measure PCI of eNB A

for HO. 4. After UE is handover to eNB A, adjust transmit power of eNB B1 lower than Th1 dBm so that UE

will not HO to eNB B1. 5. Adjust transmit power of eNB A and B2 so that UE is triggered to measure PCI of eNB B2 for

HO. 6. Discovering the same PCI, the eNB A will think eNB B2 as eNB B1, which leads to a handover

failure. 7. Handover failure is recorded in PM data in EMS A. 8. Centralized SON pulls the CM and PM data from EMS A and identifies the PCI confusion. 9. Centralized SON pushes the CM data with corrected PCI for eNB B2. 10. Confirm that PCI of eNB B2 has been changed after the CM/PM pulling period has passed. 11. Repeat steps from 1 to 6 to confirm that handovers from A to both B1 and B2 are successful

with the correction of PCI confusion.

3.3.2.1.1.2 Expected Output The test case is considered to have passed if the PCI value of eNB B2 is changed after a handover failure and CM/PM pulling period and following handovers are successful.



3.3.3 Automatic Neighbour Relations

3.3.3.1 Test Group: ANR (Small Cell <-> Macro Cell)

3.3.3.1.1 Basic ANR Test Case: Centralized SON prohibits far away cells to be listed in NRT

Figure 3.3-3: Test Configuration for ANR

Table 3.3-5: ANR-1 Test Case Overview


ANR-1

Test Group ANR

References [2] [5]


One Macro Cell eNBs from Vendor A and One Small Cell eNB from Vendor B.

Vendor A EMS and Vendor B EMS.



Test Case Overview

To check if Centralized SON updates NRT via EMS in multi-vendor environment.

- Set longitude and latitude of eNB A and B so that the distance between two eNBs can be very far.

- Adjust transmit power of eNB A and eNB B so that HO occurs from eNB A to eNB B. - Centralized SON reviews the CM and blacklists eNB B from eNB A’s NRT and also blacklists

eNB A from eNB B’s NRT because they are far away cells even though test UE sees both eNBs.

- After certain time (CM update time), adjust transmit power of eNB A and eNB B so that HO occurs from eNB B to eNB A; HO should fail due to eNB A is blacklisted in eNB B’s NRT.

Test Case Objective

To verify that the centralized SON identifies actual distance of a neighbour cell and removes/blacklists far away cells.



3.3.3.1.1.1 Test Procedures 1. Configure longitude and latitude of eNB A and eNB B so that the distance between two eNBs

can be very far: for example, 50km 2. Increase the transmit power of eNB B and decrease transmit power of eNB A so that UE is

triggered to measure PCI of eNB B for handover. 3. After UE is handover to eNB B, wait for Centralized SON reviews the CM and blacklists eNB A

from eNB B’s NRT and vice versa. 4. After a certain time (CM update time – 15mins), increase the transmit power of A and decrease

transmit power of B so that UE can be handover to eNB A. 5. Handover failure will confirm that eNB A is blacklisted in eNB B’s NRT.

3.3.3.1.1.2 Expected Output The test case is considered to have passed if the triggered handover fails due to missing neighbours eNB A and eNB B, which are blacklisted each other in their NRTs.



3.3.4 Coverage and Capacity Optimization Test

3.3.4.1 Test Group: CCO (Small Cell <-> Macro Cell)

3.3.4.1.1 Basic CCO Test Case: Unbalanced capacity/coverage issue occurs between Vendor A eNB and Vendor B eNBs

Figure 3.3-4: Test Configuration for CCO-1

Table 3.3-6: CCO-1 Test Case Overview Test Case Identifier CCO-1

Test Group CCO

References [2] [5]


One Macro Cell eNBs from Vendor A and One Small Cell eNB from Vendor B.

Vendor A EMS and Vendor B EMS. 4 UEs



Pre-configure NRT of eNB A and eNB B so that NRTs have each other as neighbour cells.

3 UEs are connected to eNB A and 1 UE is connected to eNB B

Test Case Overview To check if Centralized SON identify and resolve unbalanced capacity/coverage issue by updating CMs of eNBs via EMS.

- Set unbalanced traffic levels for UEs in eNB A and UEs in eNB B. - Centralized SON fixes the capacity unbalance issue by changing coverage of each eNB

based on re-configuration of transmission power of each eNB.

Test Case Objective To verify that the centralized SON identifies the unbalanced capacity/coverage issue and resolves it.



3.3.4.1.1.1 Test Procedures 1. Add eNB B in NRT of eNB A via EMS A. 2. Add eNB A in NRT of eNB B via EMS B. 3. Set DL transmission power of eNB B as 10 dB lower than its maximum configurable power. 4. Attach 3 UEs to eNB A with different path attenuation from eNB A.

a. Attenuation to UE1 and UE2 shall be adjusted so that they are not much affected by interference from eNB B, S/I ≥ 20 dB

b. Attenuation to UE3 shall be adjusted so that it is much affected by interference from eNB B: S/I ≤ 2dB.

5. Attach 1 UE to eNB B a. Attenuation to UE4 shall be adjusted so that it is not much affected by interference from

eNB A, S/I ≥ 20 dB 6. Generate downlink traffic for 3 UEs in eNB A and 1 UE in eNB B over a certain period of time.

a. FTP traffic server can be used for downlink traffic b. The time period for this step: T1 c. Measure system throughput and UE throughput

7. Centralized SON pulls PM file of each eNB from its EMS and compare the average UE throughput of each eNB.

8. Centralized SON pulls CM file of each eNB from its EMS and pushes CM with adjusted transmit power values for each eNB.

9. After certain period of time (T2), check if a. The transmission power of each eNB has been adjusted based on CM update from

Centralized SON b. 1 UE at the cell edge of eNB A is handover to eNB B c. The system throughput remains similar but UE throughput is more balanced than step 6,

where

T1 is PM creation period

T2 is PM/CM retrieval and CM update period including CCO algorithm run time

T1 and T2 will be given during the test.

3.3.4.1.1.2 Expected Output The test case is considered to have passed if the transmission power of eNB B is increased based on CM update from Centralized SON and the average UE throughput of each cell is balanced after CCO operation.



3 CONCLUSION AND FUTURE WORK This document presents tests specification for Multi-Vendor SON deployment. The purpose of these test cases is to verify by interoperability testing events the recommended practices described in [2].

Three different implementations are addressed in this document: distributed, centralized, and hybrid SONs, and interoperability between these implementations. Specific test procedures are defined for interoperability between:

• Distributed to distributed implementation • Macro cell centralized, small cell distributed implementation • Centralized NM based SON for small cell and macro cell

SON features covered in this release of this document include PCI, ANR, MLB, MRO and CCO.

Future work may consider additional test cases and SON features depending on further work or release on recommended practice for multi-vendor SON deployment scenarios not currently covered in [1].

test specification for multi-vendor son deployment ... specification for multi-vendor x2 son...

Documents