5.4 Inter-RAT mobility

36.3313GPPEvolved Universal Terrestrial Radio Access (E-UTRA)Protocol specificationRadio Resource Control (RRC)Release 15TS

5.4.1 Introduction

The general principles of connected mode mobility are described in 5.3.1.3. The general principles of the security handling upon connected mode mobility are described in 5.3.1.2.

For the (network controlled) inter RAT mobility from E-UTRA for a UE in RRC_CONNECTED, a single procedure is defined that supports both handover, cell change order with optional network assistance (NACC) and enhanced CS fallback to CDMA2000 1xRTT. The same procedure also supports inter-system handover between E-UTRA/EPC and E-UTRA/5GC. In case of mobility to CDMA2000, the eNB decides when to move to the other RAT while the target RAT determines to which cell the UE shall move.

5.4.2 Handover to E-UTRA

5.4.2.1 General

Figure 5.4.2.1-1: Handover to E-UTRA, successful

The purpose of this procedure is to, under the control of the network, transfer a connection between the UE and another Radio Access Network (e.g. GERAN, UTRAN or NR) to E-UTRAN, or transfer a connection between the UE and the E-UTRAN with one type of CN to the E-UTRAN with a different type of CN.

The handover to E-UTRA procedure applies when SRBs, possibly in combination with DRBs, are established in another RAT or in E-UTRA connected to another type of CN. Handover from UTRAN to E-UTRAN applies only after integrity has been activated in UTRAN. Handover to E-UTRA connected to a different type of CN applies only after integrity has been activated in E-UTRAN. Handover from NR to E-UTRAN applies only after integrity has been activated in NR.

5.4.2.2 Initiation

The RAN using another RAT or the E-UTRA connected to a different type of CN initiates the handover to E-UTRA procedure, in accordance with the specifications applicable for the other RAT or for the E-UTRA connected to a different type of CN, by sending the RRCConnectionReconfiguration message via the radio access technology from which the inter-RAT handover is performed.

E-UTRAN applies the procedure as follows:

– to activate ciphering, possibly using NULL algorithm, if not yet activated in the other RAT or in the E-UTRA connected to a different type of CN;

– to establish SRB1, SRB2 and one or more DRBs, i.e. at least the DRB associated with the default EPS bearer is established if the target CN is EPC and at least one DRB is established if the target CN is 5GC.

5.4.2.3 Reception of the RRCConnectionReconfiguration by the UE

If the UE is able to comply with the configuration included in the RRCConnectionReconfiguration message, the UE shall:

1> if the RRCConnectionReconfiguration message does not include the fullConfig and the UE is connected to 5GC (i.e., delta signalling during intra 5GC handover):

2> re-use the source SDAP and PDCP configurations (i.e., current SDAP/PDCP configurations for all RBs from source RAT prior to the reception of the inter-RAT handover RRCConnectionReconfiguration message);

1> if the RRCConnectionReconfiguration message includes the fullConfig and the source RAT was E-UTRA (i.e., intra-RAT inter-system handover):

2> except the MCG C-RNTI, release/ clear all current dedicated radio resources and configurations, including all SDAP (if configured), PDCP, RLC, logical channel configurations for the DRBs and the logged measurement configuration (if configured);

2> release/ clear all current common radio configurations;

2> for each srb-Identity value included in the srb-ToAddModList (SRB reconfiguration):

3> apply the specified configuration defined in 9.1.2 for the corresponding SRB;

3> apply the corresponding default RLC configuration for the SRB specified in 9.2.1.1 for SRB1 or in 9.2.1.2 for SRB2;

3> apply the corresponding default logical channel configuration for the SRB as specified in 9.2.1.1 for SRB1 or in 9.2.1.2 for SRB2;

3> if the handoverType in securityConfigHO is set to fivegc-ToEPC (i.e, the UE is connecting to EPC):

4> release the PDCP entity and establish it with an E-UTRA PDCP entity;

3> else if the handoverType in securityConfigHO is set to epc-To5GC (i.e., the UE is connecting to 5GC):

4> release the PDCP entity and establish it with an NR PDCP and apply the corresponding default PDCP configuration for the SRB as specified in TS 38.331 [82], clause 9.2.1;

3> associate the RLC bearer of this SRB with the established PDCP entity;

1> apply the default physical channel configuration as specified in 9.2.4;

1> apply the default semi-persistent scheduling configuration as specified in 9.2.3;

1> apply the default MAC main configuration as specified in 9.2.2;

1> start timer T304 with the timer value set to t304, as included in the mobilityControlInfo;

1> consider the target PCell to be one on the frequency indicated by the carrierFreq with a physical cell identity indicated by the targetPhysCellId;

1> start synchronising to the DL of the target PCell;

1> set the C-RNTI to the value of the newUE-Identity;

1> for the target PCell, apply the downlink bandwidth indicated by the dl-Bandwidth;

1> for the target PCell, apply the uplink bandwidth indicated by (the absence or presence of) the ul-Bandwidth;

1> configure lower layers in accordance with the received radioResourceConfigCommon;

1> configure lower layers in accordance with any additional fields, not covered in the previous, if included in the received mobilityControlInfo;

1> perform the radio resource configuration procedure as specified in 5.3.10;

1> if the handoverType in securityConfigHO is set to fivegc-ToEPC:

2> indicate to higher layer that the CN has changed from 5GC to EPC;

2> derive the key KeNB based on the mapped KASME key as specified for interworking between EPS and 5GS in TS 33.501 [86];

2> store the nextHopChainingCount-r15 value;

1> else if the handoverType in securityConfigHO is set to intra5GC:

2> if the keyChangeIndicator-r15 received in the securityConfigHO is set to TRUE:

3> forward nas-Container to the upper layers, if included;

3> update the KeNB key based on the KAMF key, as specified in TS 33.501 [86];

2> else:

3> update the KeNB key based on the current KgNB or the NH, using the nextHopChainingCount-r15 value indicated in the SecurityConfigHO, as specified in TS 33.501 [86];

2> store the nextHopChainingCount-r15 value;

1> else if the handoverType in securityConfigHO is set to epc-To5GC:

2> forward the nas-Container to the upper layers

2> derive the KeNB key, as specified in TS 33.501 [86];

1> else:

2> forward the nas-SecurityParamToEUTRA to the upper layers;

2> derive the KeNB key, as specified in TS 33.401 [32];

1> derive the KRRCint key associated with the integrityProtAlgorithm, as specified in TS 33.401 [32];

1> derive the KRRCenc key and the KUPenc key associated with the cipheringAlgorithm, as specified in TS 33.401 [32];

1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfig1:

2> perform radio bearer configuration as specified in TS 38.331 [82], clause 5.3.5.6;

1> if the received RRCConnectionReconfiguration includes the nr-RadioBearerConfig2:

2> perform radio bearer configuration as specified in TS 38.331 [82], clause 5.3.5.6.

1> if the handoverType in securityConfigHO is set to fivegc-ToEPC or if the handoverType-v1530 is not present:

2> configure lower layers to apply the indicated integrity protection algorithm and the KRRCint key immediately, i.e. the indicated integrity protection configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

2> configure lower layers to apply the indicated ciphering algorithm, the KRRCenc key and the KUPenc key immediately, i.e. the indicated ciphering configuration shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate the successful completion of the procedure;

1> if the received RRCConnectionReconfiguration includes the sCellToAddModList:

2> perform SCell addition as specified in 5.3.10.3b;

1> if the RRCConnectionReconfiguration message includes the measConfig:

2> perform the measurement configuration procedure as specified in 5.5.2;

1> perform the measurement identity autonomous removal as specified in 5.5.2.2a;

1> if the RRCConnectionReconfiguration message includes the otherConfig:

2> perform the other configuration procedure as specified in 5.3.10.9;

1> if the RRCConnectionReconfiguration message includes wlan-OffloadInfo:

2> perform the dedicated WLAN offload configuration procedure as specified in 5.6.12.2;

1> if the RRCConnectionReconfiguration message includes rclwi-Configuration:

2> perform the WLAN traffic steering command procedure as specified in 5.6.16.2;

1> if the RRCConnectionReconfiguration message includes lwa-Configuration:

2> perform the LWA configuration procedure as specified in 5.6.14.2;

1> if the RRCConnectionReconfiguration message includes lwip-Configuration:

2> perform the LWIP reconfiguration procedure as specified in 5.6.17.2;

1> set the content of RRCConnectionReconfigurationComplete message as follows:

2> if the UE has radio link failure or handover failure information available in VarRLF-Report and if the RPLMN is included in plmn-IdentityList stored in VarRLF-Report:

3> include rlf-InfoAvailable;

2> if the UE has MBSFN logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport and if T330 is not running:

3> include logMeasAvailableMBSFN;

2> else if the UE has logged measurements available for E-UTRA and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

3> include the logMeasAvailable;

3> if Bluetooth measurement results are included in the logged measurements the UE has available and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

4> include the logMeasAvailableBT;

3> if WLAN measurement results are included in the logged measurements the UE has available and if the RPLMN is included in plmn-IdentityList stored in VarLogMeasReport:

4> include the logMeasAvailableWLAN;

2> if the UE has connection establishment failure information available in VarConnEstFailReport and if the RPLMN is equal to plmn-Identity stored in VarConnEstFailReport:

3> include connEstFailInfoAvailable;

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new configuration;

1> if the RRCConnectionReconfiguration message does not include rlf-TimersAndConstants set to setup:

2> use the default values specified in 9.2.5 for timer T310, T311 and constant N310, N311;

1> if MAC successfully completes the random access procedure:

2> stop timer T304;

2> apply the parts of the CQI reporting configuration, the scheduling request configuration and the sounding RS configuration that do not require the UE to know the SFN of the target PCell, if any;

2> apply the parts of the measurement and the radio resource configuration that require the UE to know the SFN of the target PCell (e.g. measurement gaps, periodic CQI reporting, scheduling request configuration, sounding RS configuration), if any, upon acquiring the SFN of the target PCell;

NOTE 1: Whenever the UE shall setup or reconfigure a configuration in accordance with a field that is received it applies the new configuration, except for the cases addressed by the above statements.

2> enter E-UTRA RRC_CONNECTED, upon which the procedure ends;

NOTE 2: The UE is not required to determine the SFN of the target PCell by acquiring system information from that cell before performing RACH access in the target PCell.

NOTE 3: If the handover is from NR and target CN is 5GC, the delta configuration on PDCP and SDAP can be used for intra-system inter-RAT handover. For other cases, source RAT configuration is not considered when the UE applies the reconfiguration message of target RAT.

5.4.2.4 Reconfiguration failure

The UE shall:

1> if the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration message:

2> if the source RAT is E-UTRA:

3> perform the actions as specified in 5.3.5.5;

2> else:

3> perform the actions defined for this failure case as defined in the specifications applicable for the other RAT;

NOTE 1: The UE may apply above failure handling also in case the RRCConnectionReconfiguration message causes a protocol error for which the generic error handling as defined in 5.7 specifies that the UE shall ignore the message.

NOTE 2: If the UE is unable to comply with part of the configuration, it does not apply any part of the configuration, i.e. there is no partial success/ failure.

5.4.2.5 T304 expiry (handover to E-UTRA failure)

The UE shall:

1> upon T304 expiry (handover to E-UTRA failure):

2> if the source RAT is E-UTRA:

3> perform the actions as specified in 5.3.5.6;

2> else:

3> reset MAC;

3> perform the actions defined for this failure case as defined in the specifications applicable for the other RAT;

5.4.3 Mobility from E-UTRA

5.4.3.1 General

Figure 5.4.3.1-1: Mobility from E-UTRA, successful

Figure 5.4.3.1-2: Mobility from E-UTRA, failure

The purpose of this procedure is to move a UE in RRC_CONNECTED to a cell using another Radio Access Technology (RAT), e.g. GERAN, UTRA, CDMA2000 systems, NR, or handover a UE to an E-UTRA cell connected to another type of CN. The mobility from E-UTRA procedure covers the following type of mobility:

– handover, i.e. the MobilityFromEUTRACommand message includes radio resources that have been allocated for the UE in the target cell;

– cell change order, i.e. the MobilityFromEUTRACommand message may include information facilitating access of and/ or connection establishment in the target cell, e.g. system information. Cell change order is applicable only to GERAN; and

– enhanced CS fallback to CDMA2000 1xRTT, i.e. the MobilityFromEUTRACommand message includes radio resources that have been allocated for the UE in the target cell. The enhanced CS fallback to CDMA2000 1xRTT may be combined with concurrent handover or redirection to CDMA2000 HRPD.

NOTE: For the case of dual receiver/transmitter enhanced CS fallback to CDMA2000 1xRTT, the DLInformationTransfer message is used instead of the MobilityFromEUTRACommand message (see TS 36.300 [9]).

5.4.3.2 Initiation

E-UTRAN initiates the mobility from E-UTRA procedure to a UE in RRC_CONNECTED, possibly in response to a MeasurementReport message or in response to reception of CS fallback indication for the UE from MME, by sending a MobilityFromEUTRACommand message. E-UTRAN applies the procedure as follows:

– the procedure is initiated only when AS-security has been activated, and SRB2 with at least one DRB are setup and not suspended;

5.4.3.3 Reception of the MobilityFromEUTRACommand by the UE

The UE shall be able to receive a MobilityFromEUTRACommand message and perform a cell change order to GERAN, even if no prior UE measurements have been performed on the target cell.

The UE shall:

1> stop timer T310, if running;

1> stop timer T312, if running;

1> if T309 is running:

2> stop timer T309 for all access categories;

2> perform the actions as specified in 5.3.16.4.

1> if the MobilityFromEUTRACommand message includes the purpose set to handover:

2> if the targetRAT-Type is set to utra or geran:

3> consider inter-RAT mobility as initiated towards the RAT indicated by the targetRAT-Type included in the MobilityFromEUTRACommand message;

3> forward the nas-SecurityParamFromEUTRA to the upper layers;

3> access the target cell indicated in the inter-RAT message in accordance with the specifications of the target RAT;

3> if the targetRAT-Type is set to geran:

4> use the contents of systemInformation, if provided for PS Handover, as the system information to begin access on the target GERAN cell;

NOTE 1: If there are DRBs for which no radio bearers are established in the target RAT as indicated in the targetRAT-MessageContainer in the message, the E-UTRA RRC part of the UE does not indicate the release of the concerned DRBs to the upper layers. Upper layers may derive which bearers are not established from information received from the AS of the target RAT.

NOTE 2: In case of SR-VCC, the DRB to be replaced is specified in TS 23.216 [61].

2> else if the targetRAT-Type is set to eutra:

3> consider inter-system mobility as initiated towards E-UTRA;

3> forward the nas-SecurityParamFromEUTRA to the upper layers, if included;

3> access the target cell indicated in the inter-RAT message in accordance with clause 5.4.2.3;

2> else if the targetRAT-Type is set to nr:

3> consider inter-RAT mobility as initiated towards NR;

3> access the target cell indicated in the inter-RAT message in accordance with the specifications in TS 38.331 [82];

2> else if the targetRAT-Type is set to cdma2000-1XRTT or cdma2000-HRPD:

3> forward the targetRAT-Type and the targetRAT-MessageContainer to the CDMA2000 upper layers for the UE to access the cell(s) indicated in the inter-RAT message in accordance with the specifications of the CDMA2000 target-RAT;

1> else if the MobilityFromEUTRACommand message includes the purpose set to cellChangeOrder:

2> start timer T304 with the timer value set to t304, as included in the MobilityFromEUTRACommand message;

2> if the targetRAT-Type is set to geran:

3> if networkControlOrder is included in the MobilityFromEUTRACommand message:

4> apply the value as specified in TS 44.060 [36];

3> else:

4> acquire networkControlOrder and apply the value as specified in TS 44.060 [36];

3> use the contents of systemInformation, if provided, as the system information to begin access on the target GERAN cell;

2> establish the connection to the target cell indicated in the CellChangeOrder;

NOTE 3: The criteria for success or failure of the cell change order to GERAN are specified in TS 44.060 [36].

1> if the MobilityFromEUTRACommand message includes the purpose set to e-CSFB:

2> if messageContCDMA2000-1XRTT is present:

3> forward the messageContCDMA2000-1XRTT to the CDMA2000 upper layers for the UE to access the cell(s) indicated in the inter-RAT message in accordance with the specification of the target RAT;

2> if mobilityCDMA2000-HRPD is present and is set to handover:

3> forward the messageContCDMA2000-HRPD to the CDMA2000 upper layers for the UE to access the cell(s) indicated in the inter-RAT message in accordance with the specification of the target RAT;

2> if mobilityCDMA2000-HRPD is present and is set to redirection:

3> forward the redirectCarrierCDMA2000-HRPD to the CDMA2000 upper layers;

NOTE 4: When the CDMA2000 upper layers in the UE receive both the messageContCDMA2000-1XRTT and messageContCDMA2000-HRPD the UE performs concurrent access to both CDMA2000 1xRTT and CDMA2000 HRPD RAT.

NOTE 5: The UE should perform the handover, the cell change order or enhanced 1xRTT CS fallback as soon as possible following the reception of the RRC message MobilityFromEUTRACommand, which could be before confirming successful reception (HARQ and ARQ) of this message.

5.4.3.4 Successful completion of the mobility from E-UTRA

Upon successfully completing the handover, the cell change order or enhanced 1xRTT CS fallback, the UE shall:

1> if the targetRAT-Type in the received MobilityFromEUTRACommand is set to eutra (intra-E-UTRA inter-system HO):

2> indicate to the upper layers associated to the source system the release of the RRC connection together with the release cause ‘other’;

2> the procedure ends;

1> else if the UE was connected to 5GC prior to the reception of the MobilityFromEUTRACommand and the targetRAT-Type in the received MobilityFromEUTRACommand is set to nr:

2> reset MAC;

2> stop all timers that are running except T325 and T330;

2> release ran-NotificationAreaInfo, if stored;

2> release the AS security context including the KRRCenc key, the KRRCint, the KUPint key and the KUPenc key, if stored;

2> release all radio resources, including release of the RLC entity, the MAC configuration and the associated PDCP entity and SDAP entity for all established RBs;

NOTE 1: PDCP and SDAP configured by the source configurations RAT prior to the handover that are reconfigured and re-used by target RAT when delta signalling (i.e., during inter-RAT intra-sytem handover when fullConfig is not present) is used, are not released as part of this procedure.

1> else:

2> perform the actions upon leaving RRC_CONNECTED as specified in 5.3.12, with release cause ‘other’;

NOTE 2: If the UE performs enhanced 1xRTT CS fallback along with concurrent mobility to CDMA2000 HRPD and the connection to either CDMA2000 1xRTT or CDMA2000 HRPD succeeds, then the mobility from E-UTRA is considered successful.

5.4.3.5 Mobility from E-UTRA failure

The UE shall:

1> if T304 configured in the MobilityFromEUTRACommand message expires (mobility from E-UTRA failure); or

1> if the UE does not succeed in establishing the connection to the target radio access technology; or

1> if the UE is unable to comply with (part of) the configuration included in the MobilityFromEUTRACommand message; or

1> if there is a protocol error in the inter RAT information included in the MobilityFromEUTRACommand message, causing the UE to fail the procedure according to the specifications applicable for the target RAT (i.e. according to clause 5.3.5.6 if the targetRAT-Type in the received MobilityFromEUTRACommand is set to eutra):

2> stop T304, if running;

2> if the cs-FallbackIndicator in the MobilityFromEUTRACommand message was set to TRUE or e-CSFB was present:

3> indicate to upper layers that the CS fallback procedure has failed;

2> revert back to the configuration used in the source PCell, excluding the configuration configured by the physicalConfigDedicated, mac-MainConfig and sps-Config;

2> initiate the connection re-establishment procedure as specified in 5.3.7;

NOTE: For enhanced CS fallback to CDMA2000 1xRTT, the above UE behavior applies only when the UE is attempting the enhanced 1xRTT CS fallback and connection to the target radio access technology fails or if the UE is attempting enhanced 1xRTT CS fallback along with concurrent mobility to CDMA2000 HRPD and connection to both the target radio access technologies fails.

5.4.4 Handover from E-UTRA preparation request (CDMA2000)

5.4.4.1 General

Figure 5.4.4.1-1: Handover from E-UTRA preparation request

The purpose of this procedure is to trigger the UE to prepare for handover or enhanced 1xRTT CS fallback to CDMA2000 by requesting a connection with this network. The UE may use this procedure to concurrently prepare for handover to CDMA2000 HRPD along with preparation for enhanced CS fallback to CDMA2000 1xRTT. This procedure applies to CDMA2000 capable UEs only.

This procedure is also used to trigger the UE which supports dual Rx/Tx enhanced 1xCSFB to redirect its second radio to CDMA2000 1xRTT.

The handover from E-UTRA preparation request procedure applies when signalling radio bearers are established.

5.4.4.2 Initiation

E-UTRAN initiates the handover from E-UTRA preparation request procedure to a UE in RRC_CONNECTED, possibly in response to a MeasurementReport message or CS fallback indication for the UE, by sending a HandoverFromEUTRAPreparationRequest message. E-UTRA initiates the procedure only when AS security has been activated.

5.4.4.3 Reception of the HandoverFromEUTRAPreparationRequest by the UE

Upon reception of the HandoverFromEUTRAPreparationRequest message, the UE shall:

1> if dualRxTxRedirectIndicator is present in the received message:

2> forward dualRxTxRedirectIndicator to the CDMA2000 upper layers;

2> forward redirectCarrierCDMA2000-1XRTT to the CDMA2000 upper layers, if included;

1> else:

2> indicate the request to prepare handover or enhanced 1xRTT CS fallback and forward the cdma2000-Type to the CDMA2000 upper layers;

2> if cdma2000-Type is set to type1XRTT:

3> forward the rand and the mobilityParameters to the CDMA2000 upper layers;

2> if concurrPrepCDMA2000-HRPD is present in the received message:

3> forward concurrPrepCDMA2000-HRPD to the CDMA2000 upper layers;

2> else:

3> forward concurrPrepCDMA2000-HRPD, with its value set to FALSE, to the CDMA2000 upper layers;

5.4.5 UL handover preparation transfer (CDMA2000)

5.4.5.1 General

Figure 5.4.5.1-1: UL handover preparation transfer

The purpose of this procedure is to tunnel the handover related CDMA2000 dedicated information or enhanced 1xRTT CS fallback related CDMA2000 dedicated information from UE to E-UTRAN when requested by the higher layers. The procedure is triggered by the higher layers on receipt of HandoverFromEUTRAPreparationRequest message. If preparing for enhanced CS fallback to CDMA2000 1xRTT and handover to CDMA2000 HRPD, the UE sends two consecutive ULHandoverPreparationTransfer messages to E-UTRAN, one per addressed CDMA2000 RAT Type. This procedure applies to CDMA2000 capable UEs only.

5.4.5.2 Initiation

A UE in RRC_CONNECTED initiates the UL handover preparation transfer procedure whenever there is a need to transfer handover or enhanced 1xRTT CS fallback related non-3GPP dedicated information. The UE initiates the UL handover preparation transfer procedure by sending the ULHandoverPreparationTransfer message.

5.4.5.3 Actions related to transmission of the ULHandoverPreparationTransfer message

The UE shall set the contents of the ULHandoverPreparationTransfer message as follows:

1> include the cdma2000-Type and the dedicatedInfo;

1> if the cdma2000-Type is set to type1XRTT:

2> include the meid and set it to the value received from the CDMA2000 upper layers;

1> submit the ULHandoverPreparationTransfer message to lower layers for transmission, upon which the procedure ends;

5.4.5.4 Failure to deliver the ULHandoverPreparationTransfer message

The UE shall:

1> if the UE is unable to guarantee successful delivery of ULHandoverPreparationTransfer messages:

2> inform upper layers about the possible failure to deliver the information contained in the concerned ULHandoverPreparationTransfer message;

5.4.6 Inter-RAT cell change order to E-UTRAN

5.4.6.1 General

The purpose of the inter-RAT cell change order to E-UTRAN procedure is to transfer, under the control of the source radio access technology, a connection between the UE and another radio access technology (e.g. GSM/ GPRS) to E-UTRAN.

5.4.6.2 Initiation

The procedure is initiated when a radio access technology other than E-UTRAN, e.g. GSM/GPRS, using procedures specific for that RAT, orders the UE to change to an E-UTRAN cell. In response, upper layers request the establishment of an RRC connection as specified in clause 5.3.3.

NOTE: Within the message used to order the UE to change to an E-UTRAN cell, the source RAT should specify the identity of the target E-UTRAN cell as specified in the specifications for that RAT.

The UE shall:

1> upon receiving an RRCConnectionSetup message:

2> consider the inter-RAT cell change order procedure to have completed successfully;

5.4.6.3 UE fails to complete an inter-RAT cell change order

If the inter-RAT cell change order fails the UE shall return to the other radio access technology and proceed as specified in the appropriate specifications for that RAT.

The UE shall:

1> upon failure to establish the RRC connection as specified in clause 5.3.3:

2> consider the inter-RAT cell change order procedure to have failed;

NOTE: The cell change was network ordered. Therefore, failure to change to the target PCell should not cause the UE to move to UE-controlled cell selection.