Multi-Target RRC ConnectionRe-establishment

USER DESCRIPTION

133/1553-HSC 105 50/1-V1 Uen C

Copyright

© Ericsson AB 2012–2014. All rights reserved. No part of this document may bereproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due tocontinued progress in methodology, design and manufacturing. Ericsson shallhave no liability for any error or damage of any kind resulting from the useof this document.

Trademark List

All trademarks mentioned herein are the property of their respective owners.These are shown in the document Trademark Information.

133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Contents

Contents

1 Introduction 1

1.1 Basic Characteristics 3

1.2 Benefits 3

1.3 Additional Information 4

2 Feature Operation 5

2.1 Network Requirements 5

2.2 Feature Operation Sequence Diagram 5

3 Parameters 9

3.1 Feature Configuration Parameters 9

3.2 Affected Parameters 9

3.3 Parameters Affecting the Feature 9

4 Network Impact 11

5 Associated Features and Affected Functions 13

5.1 Prerequisite Features 13

5.2 Affected Features 13

5.3 Related Features 13

5.4 Affected System Functions 14

6 Performance 15

6.1 KPIs 15

6.2 Counters 15

6.3 Events 16

7 O&M Information 17

7.1 Feature Activation 17

133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Introduction

1 Introduction

This document describes the Multi-Target RRC Connection Re-establishmentfeature and its main benefits and impacts in the LTE RAN.

The Multi-Target RRC Connection Re-establishment feature enables aneNodeB to extend its functionality regarding UE connection re-establishmentrequests handling for a vaster range of cases than the already existing basicfeature RRC Connection Re-establishment. For more details on the basicfeature, see Radio Bearer Service.

The feature RRC Connection Re-establishment provides the basic functionalityfor reinstating a UE context earlier associated with a UE that lost connection tothe serving cell.

In broad terms, this is how connection re-establishment works:

• If radio link failure or handover failure is detected, the UE attempts aconnection re-establishment in a cell located after a cell search. This cellcan be any cell in any eNodeB, if it was configured by the serving cell in itscell re-selection neighbor list shown in the system information.

• When the UE attempts connection re-establishment, it sends identificationinformation such as Cell Radio Network Temporary Identifier (C-RNTI)used in the cell where the failure occurred, the Physical Cell Identity (PCI)of the cell where the failure occurred and a Message Authentication Code(shortMAC-I).

• If the given cell/eNodeB finds the UE’s context and can successfullyreinstate it, the eNodeB will accept the re-establishment and the UEreconnects to the RAN. See Figure 1).

• If resource shortage is detected and the eNodeB cannot handle the UEre-establishment request, the re-establishment is rejected. See Figure 2.For more details on connection re-establishment can be found in the 3GPPTS 36.331.

1133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

UE LTE Cell

L0000629A

RRCConnectionReestablishmentComplete

RRCConnectionReconfiguration

RRCConnectionReestablishmentRequest

RRCConnectionReconfigurationComplete

RRCConnectionReestablishment

Figure 1 Successful RRC Connection Re-establishment

UE LTE Cell

L0000636A

RRCConnectionReestablishmentRequest

RRCConnectionReestablishmentReject

Figure 2 Failed RRC Connection Re-establishment

This basic functionality does not handle the situation when a UE attemptsre-establishment during an ongoing handover, or during other UE procedures.No cells apart from the one that is the UE’s serving cell are enabled to handlethe UE’s re-establishment request. In all the latter mentioned cases, theeNodeB will respond with an RRC Connection Re-establishment Rejectmessage to the UE’s RRC Connection Re-establishment Request.

The optional feature Multi-target RRC Connection re-establishmentIntroduces RRC connection re-establishment in other cells than serving cell.The basic feature, RRC Connection Re-establishment, supports only RRCConnection Reestablishment in serving cell.

The additional cases where re-establishment is supported by this feature arethe following:

• Re-establishment in another cell of the Serving eNodeB

• Re-establishment in another cell of another eNodeB, provided that there isan X2 connection and that both eNodeBs are Ericsson eNodeBs

• Re-establishment during ongoing intra-eNodeB handover (according to theconstraints of the previous bullets as well as in Serving cell)

2 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Introduction

• Re-establishment during X2 inter-eNodeB handover (according to theconstraints of the previous bullets as well as in Serving cell)

• Re-establishment between different frequencies (according to theconstraints of the previous bullets)

1.1 Basic Characteristics

This section describes the basic characteristics of the feature.

Feature name: Multi-Target RRC Connection Re-Establishment

Product identity:See Feature Overview

Replaces: N/A

Dependencies

This feature requires the basic feature RRC Connection Re-establishment.

This feature affects the following RAN features:

• Coverage-Triggered Inter-Frequency Handover

• Intra-LTE Handover

1.2 Benefits

This section describes the benefits of this feature.

Some of the most important benefits of the feature Multi-Target RRCConnection Re-establishment are:

• It is beneficial for a UE with a voice call set up, because it increases thechances for the UE to stay connected and ensure it does not lose the voiceconnection.

• From an eNodeB perspective, the Key Performance Indicators (KPIs)related to UE/bearer retainability are improved as the UE stays connected,so no abnormal releases occur.

• Reduced signaling between CN and RAN since the UE is not releasedand set up again.

• Reduced signaling between UE and RAN since the UE is not releasedand set up again

3133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

1.3 Additional Information

For more information about this feature and related topics, see the followingdocumentation:

• 3GPP TS 36.331; Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access (E-UTRA); Radio ResourceControl (RRC); Protocol specification

• 3GPP TS 36.413; Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access Network (E-UTRAN);S1Application Protocol (S1AP)

• 3GPP TS 36.423; Technical Specification Group Radio Access Network;Evolved Universal Terrestrial Radio Access Network (E-UTRAN);X2Application Protocol (X2AP)

4 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Feature Operation

2 Feature Operation

This section describes the Multi-Target RRC Connection Re-establishmentfeature in more detail, including network configuration requirements andoperation flows.

2.1 Network Requirements

The following must be fulfilled at feature activation:

• The license key must be activated to operate the Multi-Target RRCConnection Re-establishment feature. How to activate the feature isdescribed in Section 7.1 on page 17.

In order to have support for any kind of Connection Re-establishment inan eNodeB (that is, even for the basic case where re-establishment isattempted in the serving cell with no ongoing procedure) the MOM attributerrcConnReestActive must be set to the value true. For more details onthe MOM attribute rrcConnReestActive see Radio Bearer Service.

In addition, when performing re-establishment involving more than one eNodeB,the two eNodeBs must have exchanged information that they are EricssoneNodeBs. If that is not the case no attempt to fetch context information isperformed.

2.2 Feature Operation Sequence Diagram

This feature's operation can be divided in three main flows:

• RRC connection re-establishment in unprepared cell.

• RRC connection re-establishment during incoming handover.

• RRC connection re-establishment during outgoing handover.

From an implementation view there is no differentiation made between thethree cases above. All cases are implemented according to the patternof RRC connection re-establishment in unprepared cell. Also, the basicre-establishment feature will follow this design pattern

Similarly, seen from a UE point of view, the flow of a re-establishmentprocedure is always the same. The UE does not distinguish between thedifferent situations when a re-establishment is handled; that is, the UE willnot see any difference between the situation where the eNodeB handlesre-establishment using the basic re-establishment feature or when the eNodeBhandles the re-establishment using the feature Multi-Target RRC ConnectionRe-establishment. The eNodeB uses the feature Multi-Target RRC Connection

5133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

Re-establishment, for example, when the UE attempts re-establishment duringan ongoing handover. For more details on the flow of re-establishment seenfrom a UE point of view, see Radio Bearer Service.

2.2.1 Re-establishment in Unprepared Cell

Figure 3 presents the message flow when the UE is attempting re-establishmentin an unprepared cell, that is a cell that does not have a UE contextcorresponding to the triplet PCI, C-RNTI, shortMAC-I.

This unprepared cell will try to fetch the UE context from all neighbor eNodeBs(including own eNodeB) that have a cell with the PCI received in the RRCRe-establishment Request message from the UE. The context fetch procedureconsists of proprietary X2AP messages sent between the unprepared targetand the serving cell.

When a re-establishment is attempted in an unprepared cell, as soon as theeNodeB receives the re-establishment request and finds no context for therespective UE, a check is made to determine whether the feature/licenseMulti-Target RRC Connection Re-establishment is operable in the eNodeB. Ifthe feature/license is not operable then the re-establishment request is rejected.

In addition, the eNodeB will also check that eNodeBs that serves the cells withmatching PCIs have indicated in the X2 Setup procedure that they are EricssoneNodeBs. No Context fetch request procedure is initiated towards eNodeBsthat are considered to be non-Ericsson.

Figure 3 shows the normal case , that is when the feature/license is operablein the eNodeB of the unprepared target cell and where both eNodeBs areEricsson. In addition, no ongoing procedure is active in the serving cell whenthe Context fetch request message is received.

6 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Feature Operation

UE MMEServing Cell Unprepared Target Cell

L0000628A

RRCConnectionReestablishmentRequest

RRCConnectionReestablishment

Context fetch request

Context fetch response accept

Context fetch response

RRCConnectionReestablishmentComplete

RRCConnectionReconfiguration

RRCConnectionReconfigurationComplete

Path switch request acknowledge

Path switch request

UE context release

Counters stepped:

pmRrcConnReestAttpmRrcConnReestSuccpmCtxtFetchAttpmCtxtFetchSucc

Figure 3 RRC Connection Re-establishment in Unprepared Cell

2.2.1.1 Handling Context Fetch Request during Ongoing Procedure

The Context fetch request message may arrive in the serving cell during anongoing procedure for the UE for which the context is asked for. Depending onwhich procedure that is ongoing the behavior differs. The following behavioris supported:

• If the ongoing procedure is an outgoing (intra-eNodeB or X2) handover,then the handover is aborted and the context information is sent back to theunprepared target in the Context fetch response message.

• If the ongoing procedure is different from an outgoing handover, then nomessage is sent to the unprepared target cell.

Note: When an ongoing handover for the UE that attempted re-establishmentin an unprepared cell is in process, and both the serving and thehandover target cell have the same PCI, the unprepared target cellwill send Context fetch request messages to both the serving and thehandover target cell. The handover target cell does not send anyanswer. Only the serving cell answers with Context fetch response.

2.2.1.2 Handling Context Fetch Request in Serving Cell

For a serving cell to accept an incoming context fetch request the followingconditions must apply:

• An EUtranCellRelation exists towards the target cell.

7133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

• Attribute isHoAllowed is TRUE on the relevant EUtranCellRelation.

• The target Public Land Mobile Network (PLMN) can be matched in theactivePlmnList of the serving cell. More configuration information isfound in Shared LTE RAN.

• Connection restrictions are not set in either the Handover Restriction List orthe Black List. More configuration information is found in Shared LTE RAN.

2.2.2 Re-establishment during Ongoing Handover

This section describes the flow of the feature Multi-Target RRC ConnectionRe-establishment, seen from an eNodeB point of view in either of the followingcases:

• re-establishment is attempted by the UE in the serving cell while theeNodeB is performing an outgoing handover for the respective UE

or

• re-establishment is attempted by the UE in the target cell of an ongoing(incoming) handover for the respective UE.

Common for all the re-establishment during ongoing handover cases is thatwhen the eNodeB receives the re-establishment request and finds that anongoing handover for the respective UE is in process, a check is madeto determine whether the feature/license Multi-Target RRC ConnectionRe-establishment is operable in the eNodeB. If the feature/license is notoperable, the re-establishment request is rejected.

2.2.2.1 Re-establishment during Outgoing Handover

For outgoing handover, not all types of handovers are supported . That is,re-establishment is handled by an eNodeB both when the UE returns to theserving cell during intra-eNodeB handover and X2 handover. S1 Handover(Intra LTE, IRAT and SRVCC handover) are not supported.

Regardless of in which cell the re-establishment occurs, the outgoing handoverwill be aborted at reception of the Context fetch request.

2.2.2.2 Re-establishment during Incoming Handover

Re-establishment during incoming handover is supported but there is no specifichandling for this. The solution is instead such that no re-establishment info isstored in the target cell until the handover is completed. If a re-establishmentoccurs prior to the storing of the re-establishment info no matching context willbe found in that cell. It will instead be handled as a re-establishment in anunprepared cell.

8 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Parameters

3 Parameters

This section describes parameters introduced by the Multi-Target RRCConnection Re-establishment feature.

3.1 Feature Configuration Parameters

Table 1 describes the feature parameters contained in the Rrc MO.

Table 1 Feature Parameters in MO Rrc

Parameter Description

t301 UE timer to supervise a response to RRC Connection Request3GPP TS 36.331.

Note: The parameter takes effect in the UE when SystemInformation is updated.

t304 UE timer to supervise successful handover completion accordingto 3GPP TS 36.331.

t311 UE timer triggered at radio link failure to supervise the periodwhere the UE tries to re-establish the radio connection, eitherby performing RRC Connection Reestablishment in LTE 3GPPTS 36.331, or by finding a suitable cell on another RAT. The UEreturns to Idle and optionally starts to reconnect over NAS whenthe timer expires.

Note: The parameter takes effect in the UE when SystemInformation is updated.

Table 2 describes the feature parameters contained in the ENodeBFunctionMO.

Table 2 Feature Parameters in MO ENodeBFunction

Parameter Description

tRelocOverallValue Supervision timer of the outgoing S1/X2/intra-eNodeB handoverexecution procedure according to 3GPP TS 36.413 and TS 36.423.If the feature Multi-Target RRC Connection Re-establishment isactive this timer also supervises the Context Fetch procedure.

3.2 Affected Parameters

The implementation of this feature affects no parameters.

3.3 Parameters Affecting the Feature

Table 3 describes parameters that affect the feature.

9133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

Table 3 Parameters affecting the feature

Parameter Description

rrcConnReestActive Indicates if the basic RRC Connection Re-establishmentfunctionality is ACTIVATED or DEACTIVATED.

10 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Network Impact

4 Network Impact

The implementation of this feature has no impact on the network.

11133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

12 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Associated Features and Affected Functions

5 Associated Features and AffectedFunctions

This section describes how the Multi-Target RRC Connection Re-establishmentfeature affects other features and functions.

5.1 Prerequisite Features

This feature has no prerequisite licensed features. However, the functionality inthe basic feature RRC Connection Re-establishment must be activated beforeactivating the Multi-Target RRC Connection Re-establishment feature. Moredetails on the RRC Connection Re-establishment feature can be found in RadioBearer Service.

5.2 Affected Features

Table 4 lists features that are affected by the Multi-Target RRC ConnectionRe-establishment feature.

Table 4 Affected Features

Feature Description

Coverage-Triggered Inter-FrequencyHandover

This feature may be affected by the Multi-Target RRCConnection Re-establishment feature because a UE canattempt a re-establishment procedure while the eNodeB ispreparing or executing an outgoing or incoming intra-LTEinter-frequency handover using the Coverage-TriggeredInter-Frequency Handover feature. When the eNodeB handlesthe re-establishment then an outgoing handover is canceled.

Intra-LTE Handover This feature may be affected by the Multi-Target RRCConnection Re-establishment feature because a UE can attempta re-establishment procedure while the eNodeB is preparing orexecuting an outgoing or incoming intra-LTE intra-frequencyhandover using the Intra-LTE Handover feature. When theeNodeB handles the re-establishment then an outgoinghandover is canceled.

5.3 Related Features

This feature is not related to any other feature.

13133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

Table 5 Related Features

Feature Description

SGW Relocation at X2Handover

In case this feature is activated S-GWRelocation is supported in case in case ofRRC Connection Re-establishment betweeneNodeBs.

5.4 Affected System Functions

This feature affects no system functions.

14 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Performance

6 Performance

This section describes performance indicators, counters, and events associatedwith the Multi-Target RRC Connection Re-establishment feature.

6.1 KPIs

This feature has no associated Key Performance Indicators (KPIs).

However, existing KPIs are expected to be affected when support for UEConnection Re-establishment is offered in different handover situations and inunprepared cells.

The Retainability KPI is improved because several abnormal UE releases canbe avoided. It is also assumed that releases when bearers have data in bufferswill also decrease as a consequence.

On the other hand, the numerical values of the Accessibility KPIs can be slightlydecreased, due to the support for re-establishment in unprepared cell. Theexplanation for this is: compared with the situation where re-establishment inan unprepared cell is not supported, and the UE would attempt connectionestablishment instead, both the nominator and denominator of the fraction inthe Accessibility KPI formula will be decreased with the same value, leading todecrease in the fraction value.

6.2 Counters

Table 6 lists the counters associated with the Multi-Target RRC ConnectionRe-establishment feature.

Table 6 Counters

Counter Description

pmRrcConnReestAttHo The number of RRC Connection Re-establishments attemptedwhere the cause is "handoverFailure"

pmRrcConnReestSuccHo The number of successful RRC Connection Re-establishmentswhere the cause is "handoverFailure"

pmZtemporary28 The number of attempts of fetching a UE context from a certaincell

pmZtemporary29 The number of successful attempts of fetching a UE context froma certain cell

pmRrcConnReestFailLicMtReest

The number of RRC Connection Re-establishments attemptsthat failed due to feature Multi-Target RRC ConnectionRe-establishment not being OPERABLE

For more information about counters, see Managed Object Model (MOM) RBS.

15133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

Multi-Target RRC Connection Re-establishment

6.3 Events

Table 7 lists the events associated with the Multi-Target RRC ConnectionRe-establishment feature.

Table 7 Events

Event Event Parameter Description

INTERNAL_PROC_RRC_CONNECTION_RE_ESTABLISHMENT

EVENT_PARAM_REESTAB_MULTI_TARGET_TYPE

Indicates the situation where theRRC Connection Re-establishmentattempt occurred .

INTERNAL_PROC_RRC_CONNECTION_RE_ESTABLISHMENT

EVENT_PARAM_HO_SOURCE_OR_TARGET_TYPE

Indicates the RAT of the source (forincoming handover) or target (foroutgoing handover) cell .

INTERNAL_PROC_RRC_CONNECTION_RE_ESTABLISHMENT

EVENT_PARAM_HO_TYPE Indicate the type of handover

X2_CONTEXT_FETCH_REQUEST

This event has no parameters

X2_CONTEXT_FETCH_RESPONSE

This event has no parameters

X2_CONTEXT_FETCH_RESPONSE_ACCEPT

This event has no parameters

For more information about events, see PM Event List.

16 133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26

O&M Information

7 O&M Information

This section provides Operation and Maintenance (O&M) information for theMulti-Target RRC Connection Re-establishment feature.

7.1 Feature Activation

Before activating the feature, ensure the corresponding license isinstalled. An MO instance of the MO class OptionalFeatureLicenseis automatically created. For this feature, the MO instance created isMultiTargetRrcConnReest.

To activate the feature, set the parameter featureState to ACTIVATED.

For more information, see License Management.

17133/1553-HSC 105 50/1-V1 Uen C | 2014-11-26