059_X2-Interoperability

www.scf.io/ www.smallcellforum.org

DOCUMENT

X2 InteroperabilityJune 2014

059.04.01

scf.io/

SMALL CELL FORUM

RELEASE Four

If you would like more information about Small Cell Forum or would like to be included on our mailing list, please contact:

Email [email protected]

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

Member Services [email protected]

SMALL CELL FORUM

RELEASE Four

Small Cell Forum supports the wide-scale deployment of small cells. Its mission is to accelerate small cell adoption to change the shape of mobile networks and maximise the potential of mobile services.

‘Small cells’ is an umbrella term for operator-controlled, low-powered radio access nodes, including those that operate in licensed spectrum and unlicensed carrier-grade Wi-Fi. Small cells typically have a range from 10 metres to several hundred metres. These contrast with a typical mobile macrocell that might have a range of up to several tens of kilometres. The term ‘small cells’ covers residential femtocells, picocells, microcells and metrocells.

Small Cell Forum is a not-for-profit, international organisation. Its membership is open to any legally established corporation, individual firm, partnership, academic institution, governmental body or international organisation supporting the promotion and worldwide deployment of small cell technologies. At the time of writing, Small Cell Forum has around 150 members, including 68 operators representing more than 3 billion mobile subscribers – 46 per cent of the global total – as well as telecoms hardware and software vendors, content providers and innovative start-ups.

Small Cell Forum is technology-agnostic and independent. It is not a standards-setting body, but works with standards organisations and regulators worldwide to provide an aggregated view of the small cell market.

This document forms part of Small Cell Forum’s Release Four: Urban. Urban small cells are at an earlier stage in their commercial development than their more mature residential and enterprise counterparts. As such, the present Release focuses on establishing the need, evaluating the business case and identifying key barriers to commercial deployment. It offers shared deployment learnings from leading operators and vendors, further refi nement of our technical works and reporting progress on our activities to strengthen the ecosystem through improved multivendor interoperability.

Release Four also contains works clarifying market needs and addressing barriers to deployment of residential, enterprise and rural small cells.

Small Cell Forum Release website can be found here: www.scf.io and an overview of all the material in Release Four: Urban can be found here: www.scf.io/doc/104

All content in this document including links and references are for informational purposes only and is provided “as is” with no warranties whatsoever including any warranty of merchantability, fi tness for any particular purpose, or any warranty otherwise arising out of any proposal, specifi cation, or sample.

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

©2007-2014 All rights reserved in respect of articles, drawings, photographs etc published in hardcopy form or made available in electronic form by Small Cell Forum Ltd anywhere in the world.

Report title: X2 Interoperability Issue date: 10 June 2014 Version: 059.04.1

Scope

This document identifies procedures and messaging on the LTE X2 interface that are incompletely defined by 3GPP perspectives. As a consequence, different vendor’s implementations may not be guaranteed to successfully interoperate within a multi-vendor environment. This document identifies areas of incomplete specifications and recommends ways to resolve such issues. It is not a complete analysis of the interface, and focuses (at this release) on:

• ICIC • eICIC, • MRO, • MLB (intra- and inter-RAT). • For each X2 procedure, this document steps through: • a brief description of the procedure and its intended use; • any shortcomings in the small cell/HetNet situation; and • recommended workarounds where necessary.


Executive summary

Small Cell Forum sees its broad mission as removing the barriers to small cell adoption, and accelerating the deployment of small cells worldwide. One of the key barriers to both adoption and scale has been identified to be the availability of multi-vendor small cell solutions. Indeed, one of the earliest successes of Small Cell Forum (when it was Femto Forum) was the consensus on the adoption of standardized Iu-h and the HNB-GW as essential elements to the 3G small cell RAN architecture.

A similar situation is evolving today in LTE where, especially in the urban setting, small cells and macro cells must interact and interoperate over the X2 interface. Interoperation between small cells and macro cells across the X2 interface is seen as an essential capability in the scaling-up and performance optimization of multi-vendor HetNet access networks.

This paper focuses on the interoperation of four X2 procedures, with findings as sub-bullets:

• ICIC (frequency domain interference coordination)

• Signalling appears designed for cell-edge to cell-edge interaction, unsuitable in its current form for multi-vendor HetNet use

• eICIC (time domain interference coordination)

• signalling is well designed for multi-vendor HetNet use, but issues exist in coordinating small cell layer transmissions, especially where the small cell layer itself is multi-vendor

• MRO (mobility robustness)

• Broadly multi-vendor interoperable

• MLB (mobility load balancing)

• Almost completely non-interoperable for either intra-RAT or inter-RAT

Recommendations are made within the paper regarding workarounds or standards changes that may be adopted to improve interoperability.

This scope of this paper overlaps partially with the NGMN publication ‘Recommended practices for multi-vendor SON deployment’, NGMN, January 2014 [2]. Noting this overlap, we find broad agreement regarding MLB and MRO. ICIC and eICIC are not addressed in the NGMN paper and the findings of the present paper supplement the NGMN recommendations.

Note that there is no intent either to promote or devalue vendor intellectual property, or force its disclosure via this paper. We recognize the value that individual vendors’ features bring to network performance and that many operators choose a single-vendor RAN solution consciously. The objective of the paper is to give a baseline around which vendors may agree interoperability and that will allow operators to specify and deploy multi-vendor LTE HetNets with confidence.

While there is SCF consensus in these recommendations, they remain largely unproven in wide area deployments. Follow-up releases of this document will capture


operational experience of X2 interoperability and update the content and conclusions accordingly.


Contents

1. Introduction .....................................................................1 2. X2 procedures – Multi-vendor interoperability issues

and their resolution ..........................................................3 2.1 Mobility load balancing (MLB) ................................................ 5 2.1.1 Operation and recommendation: Inter-RAT MLB ...................... 5 2.1.2 Operation of intra-LTE MLB ................................................... 5 2.2 Mobility robustness (MRO) .................................................. 11 2.2.1 Description of the technique ............................................... 11 2.2.2 Summary ......................................................................... 12 2.2.3 Recommendation............................................................... 12 2.3 Inter-cell interference coordination (ICIC) ............................ 13 2.3.1 Description of the technique ............................................... 13 2.3.2 Summary ......................................................................... 15 2.3.3 Recommendations ............................................................. 15 2.4 Enhanced inter-cell interference coordination (eICIC) ............. 15 2.4.1 Description of the technique ............................................... 15 2.4.2 Parameters influencing ABSF information ............................. 16 2.4.3 Comparative behaviour on either side of an IOT boundary ...... 17 2.4.4 Recommendations for multi-vendor eICIC interoperability ...... 18 3. Relationship with NGMN ‘Recommended practices for

multi-vendor SON deployment’ ....................................... 20 4. Conclusions .................................................................... 21 References ................................................................................ 22

Tables

Table 2–1 Bitmap of the resource status reporting initiation (RSRI) message ........ 6 Table 2–2 Resource status update IEs for PRB usage (bit 1 of RSRI) .................... 7 Table 2–3 Resource status update message for TNL Load and HW load (bits 2

and 3 of RSRI) ............................................................................... 8 Table 2–4 Resource status update message IEs for composite available capacity

(bit 4 of RSRI) ................................................................................ 9 Table 2–5 Mobility settings change message IEs ............................................... 10 Table 2–6 Intended semantics of ICIC messaging ............................................. 13

Figures

Figure 2–1 The basic intra-LTE MLB sequence .................................................... 5


Figure 2–2 MRO scenarios (courtesy lte-bullets.com) ......................................... 12 Figure 2–3 Cell edge to cell edge interactions of a single-layer network ................ 14 Figure 2–4 HetNet deployments, with small cells in random, macrocell centre or

cell edge locations ......................................................................... 14 Figure 2–5 Example ABSF pattern with 2 blank subframes with one for data, one

for measurement ........................................................................... 16 Figure 2–6 Two possible ABSF patterns - aggressive macro (upper) or

cooperative macro (lower) .............................................................. 17 Figure 2–7 A macrocell with two small cells from different vendors A and B .......... 18 Figure 2–8 the ABSF pattern signalled by the macro to two small cells ................. 18 Figure 3–1 Inter-relationship between SCF and NGMN X2 interoperability studies .. 20

Report title: X2 Interoperability Issue date: 10 June 2014 Version: 059.04.1 1

1. Introduction

The mission of the Small Cell Forum is to accelerate small cell adoption to change the shape of mobile networks and maximise the potential of mobile services. This is achieved through a range of activities:

• Raising awareness of the benefits of small cell technologies for end users. • Identifying and addressing barriers to deployment for operators. • Fostering technology alignment to ensure equipment from different

suppliers works together for an efficient and competitive marketplace.

In this paper we focus on technology alignment around the interoperability around the X2 interface.

Interoperability is essential ingredient in the development of a healthy technology ecosystem with the following characteristics [1]

1. Choice and competition: Equipment works together so that operators can mix and match between suppliers to ensure a competitive marketplace as well as de-risking their networks against the fortunes of any individual vendor.

2. Economies of scale: Using a common technology platform such as LTE enables common components such as chipsets to be manufactured in large volumes, bringing economies of scale for the benefit of all.

3. Mature standards: Early interoperability testing accelerates maturation of standards and implementations, and thus reduces time to market for new technologies

Without a degree of interoperability in the vendor landscape, small cell solutions would be constrained to be single-vendor, proprietary solutions. The first interface requiring interoperability was the 3G core network interface, and the Iu-h protocol was an early success in the consensus forming abilities of the Forum. With the advent of LTE and the X2 features designed to enable small cell deployments beneath macrocell layers, the need for interoperability has resurfaced.

In summary, the vision of multi-vendor RAN and multi-vendor HetNet in particular is to improve opex and capex, and increase network performance through access to global scale innovations in a truly competitive multivendor marketplace.

While the X2 interface has been subject to 3GPP standardisation as a necessary step towards multi-vendor interoperability, it has become clear that there are sufficient gaps and semantic uncertainties in the current procedures, signalling messages and information elements to make this study worthwhile.

Why are we interested?

• For vendors: Our customers want it • For operators: To ensure continued technical and competitive innovation in a

diversified ecosystem

Objective

• To allow (‘remove the barriers to’) small cells from one vendor to connect to macro cells from another vendor, and for all the X2 functions to ‘work as intended’


Method:

• Analyse the X2 interface as defined in the standards documents • Identify interoperability issues • Confirm the reality of the issues • Brainstorm and identify measures of addressing the issues, including

• Recommendations as to the use of existing standards • Standards changes

• Publish these findings (this document)

Note the partial overlap with the NGMN publication [2] that focuses on • PCI optimization • ANR • MRO and MLB • CCO

The relationship between the NGMN document and the present document are discussed in Section 3.


2. X2 procedures – Multi-vendor interoperability issues and their resolution

The general problem of self-configuration and self-optimisation (SON) in mobile networks has been treated by 3GPP, which has defined a set of use cases in 3GPP 36.902 [3] as follows

• Coverage and capacity optimisation

• A rather general statement of a wish that coverage and capacity of a network deployment are ‘optimised’

• Energy saving and interference reduction

• These two use cases are envisaged to be implemented by turning off carriers within a cell and to turn off the cell itself

• Both methods achieve both ends, but this is not the Interference Coordination use case (ICIC) which is treated below

• Physical cell ID (PCI) selection

• To ensure that neighbour cells do not share the same PCI (PCI conflict) and that individual cells do not see different neighbours with the same PCI (PCI confusion)

• Mobility robustness optimisation (MRO)

• To detect and rectify handover misconfigurations mainly in terms of handover thresholds.

• Incorrect neighbours are expected to be managed by the ANR function (below) though these features clearly shade into one another.

• Mobility load balancing (MLB)

• To balance load between cells using handover to move load from heavily loaded cells to lightly loaded ones

• RACH optimisation

• A complex but valuable feature to minimise the overhead of the random access channel, whilst maintaining adequate call setup performance, and to avoid RACH preamble collisions in neighbouring cells.

• Automatic neighbour relation function (ANR)

• Configuration and maintenance of neighbour relationships between cells using unspecified means

• Inter-cell interference coordination (ICIC)

• 3GPP 36.902 [3] discusses this is a single function and acknowledges that it is incomplete at R9 (the latest published version at the time of writing)

• There is a frequency domain version and time domain version (the latter termed enhanced ICIC or eICIC) both discussed below


Whilst some of these use cases are achievable within the cell itself without reference to neighbours, others anticipate the use of inter-cell communications of some sort which for LTE is defined as the ‘application part’ of the X2 interface, defined in 3GPP 36.423 [4] In this document, we have selected the following subset of SON features, based on a Small Cell Forum consensus of importance.

• MLB

• Key to the whole concept of the converged RAN requires the multiple layers of the single- or multi-RAT multi-vendor HetNet to work effectively together. Methods of sharing load information between them must be standardised and load balancing must be interoperable

• MRO

• Automatically maintaining the effectiveness of mobility between layers and between cell on the same layer is key to reducing the operational expense associated with a large numbers of small cells in a multi-vendor HetNet

• ICIC and eICIC

• Interference coordination between the layers of a HetNet is key to the optimized management of the whole network. Ensuring these procedures are interoperable between the vendors in a HetNet is key to effective interference coordination

The X2 application part (X2-AP) [4] defines a range of structured procedures, of which the following are of relevance to this document:

• Load indication

• Used to pass load and interference coordination information between intra-frequency neighbours

• Load information is used in ICIC and eICIC

• Resource status reporting/initiation

• Reports resource loading from one cell to another • Resource reports are used in MLB • Also used in eICIC to give feedback on ABS status

• Mobility settings change

• Requests update to handover settings • Used in MRO

• Radio link failure indication

• Reports radio link failure causes • Used in MRO

• Handover report

• Reports handover failures causes • Used in MRO


2.1 Mobility load balancing (MLB)

The capacity and performance of the RAN is maximised when the load is balanced as evenly as possible across the available resources. The underlying problem to be solved is that given incoming stochastic demand, either in terms of calls or data, the likelihood of the network running out of any resource required to service that demand wherever it arises must be minimised. MLB, as the name implies, seeks to achieve this by adjusting the mobility settings between cells so that the normal handover mechanisms move load between cells towards a state of balance.

A secondary objective of the feature is to minimise the number of load balancing related handovers.

The feature is divided into two parts. Firstly, the balance is achieved by adjusting intra-LTE mobility settings so that load is balanced solely within the LTE layer(s). Secondly, the balance may be achieved by adjusting inter-RAT settings to balance load between LTE and another layer (probably 3G).

2.1.1 Operation and recommendation: Inter-RAT MLB

The inter-RAT MLB feature is very lightly specified, and essentially uses the RAN information management (RIM) feature to implement a proprietary mechanism for load balancing between technologies. As such, inter-RAT MLB is non-interoperable as specified today.

2.1.2 Operation of intra-LTE MLB

Intra-LTE MLB operates by requesting periodic status updates of particular resource classes, and then updating the mobility settings, as follows.

Figure 2–1 The basic intra-LTE MLB sequence

Mobility setting change

Resource status reporting

Resource status reporting initiation

Start/stop the resource status reporting from one eNB to another eNB

Specify load measurement metrics

Report the results of load measurements

Negotiate handover trigger settings with a peer eNB controlling neighboring cells


2.1.2.1 Resource status reporting

The resource status reporting is initiated, the reports, when received, are used to adjust the mobility settings, and then the process repeats according to the periodicity of the resource status reports.

Examining the steps in turn, the process is initiated by the resource status reporting initiation message, which contains the following items as illustrated in Table 2–1.

Position in the bitmap Measurement object requested

First bit PRB periodic

Second bit TNL (transport network load) load indicator periodic

Third bit HW load indicator periodic

Fourth bit Composite available capacity periodic

Fifth bit ABS status periodic (not used in MLB)

Other bits Not used

Table 2–1 Bitmap of the resource status reporting initiation (RSRI) message

So by sending this message to an X2 neighbour, a cell requests reports from that cell of the resource usage for the particular resource class,

• The physical resource blocks (PRBs) • Transport network layer (TNL) resources • The HW load indication (a measure of the capacity of the physical platform

hardware resources, compute cycles, memory, etc.) • Composite available capacity (a notional measure of the total capacity of the

cell, mashed up into a single number)


2.1.2.2 Resource status update for PRB usage

The report that the cell receives (the resource status update) carries the requested resource status updates as shown in the Table 2–2.

IE name Definition IE type Multi-vendor X2 IOT gaps

GBR PRB usage (M)

Percentage of PRBs used, averaged during a time period An aggregate for all UEs in a cell, applicable to dedicated traffic channels (DTCH). The reference point is the service access point between MAC and L1

Value range: 0-100%

It is up to the eNB implementation how to calculate the total number of PRBs available during a time period with respect to PRBs that may be considered not available, e.g. MBSFN subframes and subframes subject to restrictions due to TDM eICIC

Non-GBR PRB usage (M)

Total PRB usage (M)

Percentage of PRBs used, averaged during a time period Calculated in the time-frequency domain only. The reference point is the service access point between MAC and L1

Table 2–2 Resource status update IEs for PRB usage (bit 1 of RSRI)

The total PRB usage value is defined in 3GPP 36.314 [5], as follows (a paraphrase of 36.314 §4.1.1.1),

For a time period T,

M(T) = M1(T)/P(T) * 100

Where

M(T) is the total PRB usage – 0-100%, calculated separately for uplink and downlink,

M1(T) is the number of used PRBs in the downlink, or allocated PRBs in the uplink,

P(T) is the total number of available PRBs, where it is implementation dependent which PRBs are counted as available for use/allocation, and which are already allocated for MBSFN, eICIC or other use.

2.1.2.3 Summary of intra-LTE MLB IOT gaps for PRB status reports

Different eNB implementation may differ regarding how they calculate the total available PRBs. This may result in the following:

• Lead to different PRB usage value and cause confusion in multi-vendor HetNet

• Impact load balancing performance

Note that the specification itself admits to leaving it to the vendor to decide how to treat PRBs that are not available for regular traffic.


2.1.2.4 Resource status update for TNL and HW load

The report that the cell receives (the resource status update) carries the requested resource status updates as shown in the Table 2–3.

IE name Definition IE type Multi-vendor X2 IOT gaps

HW load indicator (M)

Indicates the status of the HW load experienced by the cell Enumerated

(lowload, mediumload, highload, overload, …)

No detail definition about HW load No detail definition about TNL load No definition about how to categorize HW/TNL load: low, medium, high, overload (link to percentage range may be used as a start)

S1 TNL load indicator (M)

Indicates the status of the S1 transport network load experienced by the cell

Table 2–3 Resource status update message for TNL Load and HW load (bits 2 and 3 of RSRI)

2.1.2.5 Summary of intra-LTE MLB IOT gaps for TNL and HW load status reports

There is no definition of how HW load or TNL load should be calculated or categorised into the load enumeration (low, medium, high, overload), or of the significance of these calculations for network performance and the significance of the reported enumeration in terms of expected action or response.

Also, depending on the absolute values of these items on either side of an IOT barrier, undesirable effects may be encountered. For example,

eNB1 – with very high absolute capacity may be under highLoad, e.g., a macro cell

eNB2 – with low absolute capacity may be under lowLoad, e.g., a small cell

It seems reasonable, given the semantics of the message, to attempt to move load from the High Load device to the Low Load device. However, since the absolute capacities differ, the load required to be shed from eNB1 to move it from HighLoad to MediumLoad may completely swamp eNB2, driving it immediately into overload. To have effective load balancing in this case may requires more information than is available in the messaging.

2.1.2.6 Recommendation for next steps to resolve TNL and HW load status reporting across multi-vendor boundaries

In order to address the highlighted multivendor X2 interoperability issues, it is recommended that the ecosystem defines:

• The components and weights for HW load and TNL load calculation • The load value (low, medium, high, overload) by linking it with percentage

such as Low load – 0~25%, etc. • The load in both cases in terms of an absolute lowest common denominator

unit of remaining available resource – for instance packets per second per bearer or Mbps per bearer - so that the sender of the message can tell the receiver exactly what it can accept as the result of a mobility event.


2.1.2.7 Resource status update for composite available capacity

The report that the cell receives (the resource status update), carries the requested resource status updates as shown in the Table 2–4.

IE name Definition Semantics description Multi-vendor X2 IOT gaps

Cell capacity class value (O)

Indicates the value that classifies the cell capacity with regards to the other cells Only indicates resources that are configured for traffic purposes

(1..100), value 1 indicates the minimum cell capacity and 100 indicates the maximum cell capacity, on a linear scale

No consideration for HetNet Not specified how to obtain relative cell capacity No definition about the components and weights to calculate the composite capacity

Capacity value (M)

Indicates the amount of resources that are available relative to the total E-UTRAN resources Can be weighted according to the ratio of cell capacity class values, if available

(0..100), value 0 indicates no available capacity and 100 indicates maximum available capacity, on a linear scale

No definition about the components and weights to calculate the composite capacity

Table 2–4 Resource status update message IEs for composite available capacity (bit 4 of RSRI)

2.1.2.8 Summary of intra-LTE MLB IOT gaps for composite available capacity status reports

The main issue with this message is the lack of definition of the IEs and how to calculate them, which the recommendations seek to resolve. In particular, the abstract quantity cell capacity class IE above is inadequate to the purpose of load balancing between layers of the HetNet where the actual absolute value of cell capacity may be widely different between the small cell and the macro layers.

2.1.2.9 Recommendation for next steps to resolve composite available capacity status reporting across multi-vendor boundaries

In order to address the highlighted multivendor X2 interoperability issues, it is recommended that the ecosystem:

• Consider cell capacity estimation in HetNet environment where there are both macro cells and small cells

• Clarify how to define ‘cell capacity class value’ w.r.t. other cells in HetNet environment

• Define the components and weights for capacity calculation, such as PRB, number of users, etc.

• Add cell user occupancy indicator IE


• The same capacity usage value can map to different absolute capacity for macrocell and small cell. For example, moving 5% of macrocell capacity may fill up more than 50% small cell capacity and cause oscillation

• With cell user occupancy indicator, the source cell can take it into consideration and make better decision on load balancing

• Add rate of congestion indicator IE

• Current load is a good indication of the current amount of resources left in a cell to accommodate more traffic, but during heavy traffic conditions (i.e. event traffic, busy hour traffic), rate of congestion on target cell will directly influence mobility to that cell

• Defining rate of congestion indicator IE allows for better load balancing strategy and performance

2.1.2.10 The mobility settings change message

The mobility settings change is an elementary procedure supported over X2. The initiating entity triggers the procedure by sending a mobility change request message that is responded to with the mobility change acknowledge message.

Table 2–5 indicates the key Information elements from the mobility change request message.

IE name Definition Semantics description

Multi-vendor X2 IOT gaps

Handover trigger change (M)

Indicates the change of the handover trigger as compared to its current value Positive value of the change means the handover is proposed to take place later (-20..20), the

actual value is IE value *0.5dB

There are multiple handover parameters to control the handover trigger, such as A3 offset, hysteresisA3, time to trigger, filter CoeffRSRP, etc. Not all parameters can be adjusted in the same direction and at the same scale Need to specify handover trigger change for several key handover parameters separately.

Handover trigger change lower/upper limit (M)

Indicates the range of the handover trigger change values permitted

Table 2–5 Mobility settings change message IEs

2.1.2.11 Summary of intra-LTE MLB IOT gaps for mobility settings change message

The major issue in supporting multi-vendor intra-LTE MLB using the mobility settings change elementary procedure is the handover trigger change parameter limitation

• This parameter indicates the change of the Handover trigger as compared to its current value


• There are multiple handover parameters to control the handover trigger and different vendors may understand and implement them differently

• If two cells adjust different parameters uncoordinatedly, the mobility setting change procedure may cause handover performance degradation, or impact load balance effectiveness

2.1.2.12 Recommendation for next steps to resolve mobility settings change message reporting across multi-vendor boundaries

In order to address the highlighted multivendor X2 interoperability issues, it is recommended that ecosystem:

• Add the actual handover parameters IE for negotiation between two cells

• Time to trigger • HysteresisA3 • A3 offset • Cell individual offset

• Source cell can pick one or multiple parameters for negotiation (decrease, no change, increase)

• Implement mobility setting change based on the integrated view of both MLB and MRO

2.2 Mobility robustness (MRO)

2.2.1 Description of the technique

The MRO procedure uses radio link failure and handover failure information to identify whether a handover failed due to three main causes, as illustrated in Figure 2-3:

• Too late handover (radio link failed on source cell before handover could complete)

• Too early handover (radio link failed on target cell before handover could complete, or shortly afterwards)

• Wrong cell handover (radio link failed because target cell wasn’t expecting the handover)

Then it closes the loop by updating the handover attribute information using two main methods:

• Real-time or near real-time at the source eNB (D-SON, in other words) • Non-real-time counter based optimisation at the OSS (C-SON)


Figure 2–2 MRO scenarios (courtesy lte-bullets.com)

The scenarios in Figure 2–2 are differentiated according to the subsequent X2:RLF

• Source receives RLF from target – too late handover • RLF information in UE indicates source cell– too early handover • Source receives RLF from different cell – wrong cell handover • X2:HandoverReport used to help differentiate mobility failure from plain old

RLF failures

2.2.2 Summary

There are no identified issues in supporting multi-vendor intra-LTE MRO. The procedure should be able to support:

• Updating of handover attributes, either done at the source cell, or are optimised globally using performance counters

• There is no attempt to (re-)negotiate attributes

• 3GPP 36.902 [3] states:

• ‘The following mobility parameters may be optimized: • Hysteresis, • Time to trigger, • Cell individual offset • Cell reselection parameters • The list of parameters to be optimized is FFS, depending on the solution

adopted.’

2.2.3 Recommendation

There is no specific X2 interoperability impact from this feature, but there is an implied requirement for matching performance counters on which to base the mobility settings change across the whole multi-vendor network.


2.3 Inter-cell interference coordination (ICIC)


ICIC as implemented over X2 consists of three indications carried in the X2:LoadIndication message

• RNTP – Relative narrowband transmit power

• A proactive signal • Sent on X2 from the transmitter to all of its X2 partners • A ‘0’ for a particular sub-carrier indicates that the sender will not

transmit in that sub-carrier above a certain power relative to maximum. • A ‘1’ for the particular sub-carrier makes ‘no promise’, so it might, or it

might not transmit above the threshold • It’s valid until updated by another signal of the same type

• OI – UL interference overload indicator

• A reactive signal • Sent on X2 from a receiver to all of its X2 partners • Can take a low, medium, high value [thresholds/values undefined] • Indicates that the sender has observed such an interference level on the

given PRB • Valid for the period immediately preceding its reception, but not clear

exactly what the measurement period is • Sent with a minimum periodicity of 20ms, maximum ∞.

• HII – High interference indicator

• A proactive signal • Sent on X2 from the receiver to all of its X2 partners • Carries a target cell id and then a bit string to indicate that the source

cell is about to schedule uplink power to a cell-edge user • Valid for the ‘near future’ • Sent with a minimum periodicity 20ms, maximum ∞.

The intended semantics of these primitives are as shown in Table 2–6.

ICIC primitive Intended semantics – macro-to-macro (assumes thresholds and reporting periods are set appropriately)

RNTP Receiver infers ‘clear channel’ from a ‘0’ and therefore ‘safe to schedule DL’

HII Receiver infers likely UL interference to its cell edge users near the sending cell, therefore ‘unsafe to schedule UL’

OI Receiver should act according to policy on unexpected OIs it receives from a sending cell

Table 2–6 Intended semantics of ICIC messaging

The key point about these semantics is that the RNTP threshold, HII threshold and the trigger threshold for OI messages effectively define the cell centre/cell edge boundary.


There is no value in any of these messages for cell centre users. They only have meaning for users in the cell edge area.

Consequently, the key point about ICIC as currently defined over X2 is that it assumes a traditional single-layer, cell-edge to cell-edge deployment, as in Figure 2–3.

Figure 2–3 Cell edge to cell edge interactions of a single-layer network

However, compared with the classical single-layer/single-vendor approach used in the macro network, HetNet deployments will frequently be characterized by ill defined cell edge boundaries. Whereas the majority of small cells may be deployed towards the edge of the macro cell, some deployments may include small cells that are located away from the traditional macro cellular edge, as illustrated in Figure 2–4.

Small cell centre

Small cell edge

Macro cell centre

Macro cell edge

Figure 2–4 HetNet deployments, with small cells in random, macrocell centre or cell edge locations


2.3.2 Summary

Given the fundamental issue with the deployment topology implied by the signalling, it is hard to conceive of a recommendation to make multi-vendor ICIC interoperable in the HetNet case.

Note, however, that there are several non-HetNet applications scenarios of small cells – such as residential femto with low/zero macro overlay – where ICIC may be a useful technique for managing interference in the small cell layer, using frequency selective scheduling, for instance.

2.3.3 Recommendations

In single-layer (non HetNet) applications, where cell-edge to cell-edge is the dominant interaction, ICIC as defined may be highly interoperable.

In such cases, as well as other corner cases where small cells are only deployed at the edge of traditional macro cells, the RNTP thresholds need to be defined to match on each side of the IOT boundary.

2.4 Enhanced inter-cell interference coordination (eICIC)


In 3GPP Release 8, the schedulers of cells are uncoordinated, and so interference on the shared PRBs in areas of overlap is uncontrolled.

ICIC is an attempt to solve this problem in the frequency domain, by signalling sub-carrier-by-sub-carrier usage and interference information from cell to neighbour cell, but as highlighted above, this may be of limited value in the het-net because of the ill-defined cell-edge.

In 3GPP Release 10, time domain coordination was introduced so that cells can signal to each other how they intend to schedule data onto their respective downlinks

The time domain coordination consists of the introduction of almost blank sub-frames (ABSF), where no shared channel/user data is transmitted. Control channel information is still sent in these timeslots – hence the A in ABSF.

In FDD, the ABS Information IE is shared across the X2 interface and contains two important fields illustrated in Figure 2–5.

• ABS pattern info, a string of 40 bits, that signals which sub-frames, starting at SFN=0. A ‘1’ signifies a blank, a ‘0’ signifies non-blank

• Measurement subset, another string of 40 bits, which indicate which of the blank subframes signalled in ABS pattern info should be used for UE measurement purposes (i.e. not data transmission)


Figure 2–5 Example ABSF pattern with 2 blank subframes with one for data, one for

measurement

Note that:

• there is no concept of cell-edge vs. cell centre user in the definition of ABSF (though the small cell scheduler would normally schedule cell edge users in ABSFs to take the most advantage of them)

• there is no minimum threshold for signalling as there is for ICIC

The ABS status IE allows a neighbour cell to indicate the percentage of available ABSFs it has actually used. As such it is a hint to the ABSF master whether it should increase or decrease the ABSF allowance.

2.4.2 Parameters influencing ABSF information

The ABS information is signalled over the X2 interface and is used to provide information about the almost blank subframes. Key data that may be used in determining how to update the information includes:

Instantaneous demand

• The aggressiveness/conservativeness of the ABSF pattern may be modulated according to the target throughput KPI of the eNB

Interference observed by UEs

• If a UE experiences downlink interference, then one of the entities responsible for the interference needs to react, e.g., by backing off the aggressiveness of their ABSF pattern. Key to successful interoperation is to define who will defer to whom.

Update rate

• ABSF cannot be updated faster than every 40ms, but does there need to be co-ordination as to how often it is updated? What loss of performance is resulted if the patterns are only updated relatively infrequently. Does there need to be co-ordination between neighbouring cells on their update rates?

Ratio of measurement frames to transmit frames

• Related to mobility of traffic relative to throughput.


• Lots of measurement slots allow UEs to find neighbours quickly, but reduce the number of slots available for data transmission.

2.4.3 Comparative behaviour on either side of an IOT boundary

The above section has highlighted the detail that 3GPP has defined in terms of sharing ABS information. However, 3GPP has not defined any eNB procedures for how a cell is supposed to react when it received such ABS information. The eNB may just ignore, or only partially respect the ABSF signalled by its neighbours.

Consider two examples of ABSF operation as illustrated in Figure 2–6.

Figure 2–6 Two possible ABSF patterns - aggressive macro (upper) or cooperative macro

(lower)

In the patterns shown in Figure 2–6 the upper pattern is an example of an aggressive or selfish configuration, where almost all slots are claimed by the macrocell. The lower pattern is an example of a more cooperative configuration where many slots made available for the small cell underlay.

The behaviour of the ABSF configuration selection algorithm on either side of the algorithm is key to the effective management of interference in this technique. The general assumption is that the macro cell will broadcast a pattern and the small cell layer will respond to it, and that any ABSF pattern sent by the small cell layer will be ignored by the macro, since as a fraction of network capacity, each small cell has a very small effect. However, if the ABSF patterns for all small cells in the small cell layer are coordinated, then the cumulative effect of the ABSF patterns will be significant, and should be taken into account by the overlying macro.


Another example where coordination within the small cell layer is important is shown in Figure 2–7.

Figure 2–7 A macrocell with two small cells from different vendors A and B

Consider the two overlapping small cells of Figure 2–7. The macro may signal the same ABSF pattern to both cells, as in Figure 2–8.

Figure 2–8 the ABSF pattern signalled by the macro to two small cells

In such a deployment, each small cell may take the opportunity to transmit in the blank subframes signalled to it by the macro, with the result that interference is observed in the timeslots indicated by the red arrows in Figure 2–8, where both small cells choose, by chance, to transmit.

One obvious solution to this is for both Cell A and Cell B to calculate and send their own ABSF to each other, but again, across an IOT boundary, there is no prior information to allow this to succeed.

2.4.4 Recommendations for multi-vendor eICIC interoperability

Of the issues identified in the discussion above, there are two main themes:

macro

B

A


• Coordination of selected ABSF pattern within the small cell layer between vendors

• Reserve downlink slots to the whole small cell layer (simple to configure), or

• Randomise the small cell layer usage of allowed downlink slots to ensure the interference to macro users appears noise-like (which may require specific features beyond basic configuration)

• The specific ABSF pattern choice and selection policy should be coordinated (probably by O&M) on either side of the IOT boundary

• Adaptive and/or pseudo random transmit slot selection in the small cell layer in response to ABSF patterns received from a common macro neighbour

• To ensure that overlapping multi-vendor small cells respond appropriately and do not continually attempt to reuse the same slots, generating interference where clean slots lie unused.

• This may be as simple as keying the indexing the first used slot in the ABSF pattern using the lowest n-bits of the PCI to give a 1 in 2n chance of a clash.

• Introduction of more detailed feedback (beyond that provided by the ABS Status IE) into the mechanism so that ABSF patterns may be adapted according to interference and excess demand observed in the small cell layer

• This requires standards changes, and will be examined in greater detail in subsequent versions of this document with a view to a 3GPP contribution.

• Introduction of hybrid SON (dynamic X2) leveraging central controller to identify dominant macro interferers, avoid incorrect ABS configurations and leverage delivery of historical data.

• This requires fast ABS adaptation by retrieving real-time metrics from macro/small cells and traffic load conditions at a rate of a few seconds.

• Advanced computation of identifying optimal ABS configuration may include user fairness, bearer types (GBR/non-GBR traffic).

• Since the point of eICIC is to extend the cell edge, then the cell range expansion bias settings in idle and connected mode should be coordinated by the C-SON element of the hybrid SON.


3. Relationship with NGMN ‘Recommended practices for multi-vendor SON deployment’

This document and the NGMN document ‘Recommended practices for multi-vendor SON deployment’ [2] have been developed in parallel. Where the NGMN document covers similar ground to this document, it arrives at similar conclusions. Diagrammatically, the two documents relate as shown in Figure 3–1.

Neither document

NGMN document This document Both Documents

PCI selection

ANR

MRO

MLB

ICIC

eICICCoverage &

Capacity

Energy Saving/

Interference Red’n

RACH optimis’n

Figure 3–1 Inter-relationship between SCF and NGMN X2 interoperability studies


4. Conclusions

Multi-vendor interoperability over X2 is seen as a challenge due to the incomplete specifications by standards. This document has examined a number of X2 interoperability use cases used to support SON functionality. In particular, of the X2 functions addressed in this document cover ICIC, eICIC, MRO and MLB.

Several key areas of interoperability have been highlighted, including:

• ICIC (frequency domain interference coordination)

• Signalling appears designed for cell-edge to cell-edge interaction, unsuitable in its current form for HetNet use

• eICIC (time domain interference coordination)

• signalling is well designed for HetNet use, but issues exist in coordinating small cell layer transmissions, especially where the small cell layer itself is multi-vendor

• but appears interoperable when used in single layer small cell networks

• MRO (mobility robustness)

• Broadly interoperable on X2

• MLB (mobility load balancing)

• Almost completely non-interoperable on X2 for either intra-RAT or inter-RAT

This document has included a set of recommendations for enabling X2 interoperability.

The topic of X2 interoperability as an engine of HetNet growth remains very important, and the firmest conclusion we can reach at this point is that the story is not complete. Further maintenance updates of this document will capture improved recommendations and best practice as it validates those recommendations into guidelines.


References

1 [SCF085] ‘The value of Small Cell Forum Plugfests’ http://scf.io/document/085 2 NGMN, ‘Recommended Practices for Multi-vendor SON Deployment’,,

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

3 36.902, ‘Self-configuring and self-optimizing network (SON) use cases and solutions’

4 3GPP TS 36.423, ‘Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP)’

5 3GPP 36.314 ‘Evolved Universal Terrestrial Radio Access (E-UTRA); Layer 2 – Measurements’

http://scf.io/document/085

