LTE Layer 3 Analysis (part2)

Consulting | Training | ResearchCompany Confidential - Pinnacle Learning Center

MobileComm Professionals, Inc

4.LTE Layer 3 Analysis (Part 2)

MobileComm Professionals, Inc Author : Ray KhasturTitle : LTE Optimization Consultant

Company Confidential - Pinnacle Learning Center

4.1 LTE MOBILE TERMINATED CSFB CALL



Based on the capabilities of UEs and networks, five fallback mechanisms are available for an eNodeB to perform CSFB to

GERAN:

• R8 PS Redirection

• R9 PS Redirection (Flash CSFB)

• CCO

After receiving a CS Fallback Indicator, the eNodeB sends a MobilityFromEUTRACommand message containing information

about a target GERAN cell to the UE, and instructs the UE to access the target cell. The UE needs to be synchronized to the

specified cell, obtains system information about the target cell, and accesses the cell to initiate CS services.

• CCO with NACC

When the LTE-to-GSM RIM procedure is enabled, which indicates that NACC is enabled, the eNodeB delivers system

information about the target cell when triggering CCO. The UE directly initiates access and a CS service to the target cell and

does not need to read system information about the target cell, shortening delays.

• PS Handover

Mobile Terminating CSFB -> GERAN




1 to 3. An UE in an LTE cell receives a paging message.

Upon detecting that the UE is in idle mode, the eNodeB sends a Paging request

message carrying an SAE-temporary mobile subscriber identity (S-TMSI) or

international mobile subscriber identity (IMSI), to the UE.

Upon detecting that the UE is in connected mode, the eNodeB sends a CS Paging

Notification message to the UE.

4. The UE sets up a radio resource control (RRC) connection and sends an

Extended Service Request message that carries the "CS Fallback Indicator" IE to

inform the MME to initiate CSFB.

5. The MME sends an SGs Service Request message to stop the MSC from

resending paging messages over the SGs interface.

6. The MME sends an Initial UE Context Setup message carrying the CS Fallback

Indicator IE to instruct the eNodeB to migrate the UE to a GSM cell.

7. The eNodeB selects a target GSM cell for the UE based on the measurement

result or LTE network configuration.

8. (Optional) If both the GSM and LTE networks support the RIM procedure, the

eNodeB starts the RIM procedure.

9. The eNodeB instructs the UE to access the target GSM cell as follows:

9a. If both the UE and the network support PS handovers, the eNodeB initiates an

LTE-to-GSM PS handover.

9b. If both the UE and the network support LTE-to-GSM CCO instead of PS

handovers, the eNodeB sends a MobilityFromEUTRACommand message to the

UE. The MobilityFromEUTRACommand message indicates that the purpose is

cellChangeOrder. If the LTE-to-GSM eNACC procedure is used, the

MobilityFromEUTRACommand message carries the GSM cell ID and the SI

(including SIB1, SIB3, and SIB13). If this procedure is not used, the message

carries only the GSM cell ID.

9c. If the UE or the network supports neither LTE-to-GSM CCO nor PS handovers,

the eNodeB sends an RRC connection release message to redirect the UE to a

GSM cell.

10. The eNodeB releases the S1 UE Context.




11. The UE sends a Channel Request message to the BSC.

If the LA changes, the BSC proceeds with step 13.

If the LA remains unchanged and CSFBIDENTIFYMTSW(BSC6900,BSC6910) is

set to ON(On), the BSC identifies the CSFB MTC based on the cause value

contained in the Channel Request message.

NOTE :

This process is referred to as CSFB MTC identification. According to 3GPP TS

44.018 v8.9.0, depending on the Paging Indication value contained in the paging

message from the GSM network, the called UE contains any cause value (except

the value corresponding to "Any channel") in the Channel Request message. On

the LTE network, however, the paging message from the eNodeB does not

contain the Paging Indication IE, and a UE that falls back to the GSM network

contains the cause value corresponding to "Any channel" in the Channel Request

message

12. (Optional) If the CSFBIMMASSENSW parameter involved in the GBFD-

160203 CSFB QoS feature is set to ON(On), the BSC starts the TCH immediate

assignment procedure. For details about the CSFB QoS, seeCSFB QoS Feature

Parameter Description.

13. (Optional) If the LA changes after the UE accesses the GSM cell, the UE

performs an LAU procedure or combined RAU/LAU procedure.

The BSC determines whether the call is a CSFB call based on the value of circuit

switched fallback mobile terminated call (CSMT) in the "Additional update

parameters" IE contained in the RAU or LAU message.

If the call is not a CSFB call, the BSC processes the call following the common call

access procedure.

If the call is a CSFB call and SUPPORTCSFB(BSC6900,BSC6910) has been set

to SUPPORT(Support), the BSC proceeds with subsequent steps.

If the call is a CSFB call but SUPPORTCSFB(BSC6900,BSC6910) has been set

to UNSUPPORT(Not Support), the BSC rejects the call.

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsoft_csfbidentifymtsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellsoft_csfbidentifymtsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/en-us_bookmap_0003832715.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsoft_supportcsfb.html







If a UE cannot report the "Additional update parameters" IE, it uses the paging-

based CSFB call identification function to identify a CSFB MTC.

When CSFBPagingIdentifySw(BSC6900,BSC6910) is set to ON(On), if the BSC

receives a paging message from the MSC:

The BSC buffers the paging message carrying the temporary mobile subscriber

identity (TMSI).Upon receiving a paging response message from the UE, the BSC

will match the paging response message and the buffered paging message.

Based on the matching result, the BSC determines whether the MTC is a CSFB

MTC.

If the paging response message and the buffered paging message match,

the BSC determines that the MTC is not a CSFB MTC.

If the paging response message and the buffered paging message do not

match, the BSC determines that the MTC is a CSFB MTC. This is

because the paging message of a CSFB call is not included in buffered

paging messages but delivered from the LTE network.

If the LA changes, the UE performs an LAU or combined RAU/LAU

procedure before initiating a call. In this case, the BSC needs to determine

whether the UE initiates an MTC based on the subsequent call procedure.

If the UE initiates an MTC, and the paging response message and the

buffered paging message match, the BSC determines that the call is not a

CSFB MTC. Otherwise, the BSC determines that the call is a CSFB MTC.

The BSC does not buffer the paging message carrying the IMSI.If such a call

cannot be identified based on the CSMT or using the very early identification

mode, the BSC determines that the call is not a CSFB MTC.

When CSFBPagingIdentifySw(BSC6900,BSC6910) is set to OFF(Off), the BSC

processes the call following the common call access procedure.

• 14 to 17. (Optional) If the UE is processing PS services before initiating a

call, and neither the UE nor the network supports Dual Transfer Mode

(DTM), the UE suspends the PS services.

• 18 and 19. The UE sends a paging response message to the MSC through

the BSS.

• The BSC determines whether the call is a CSFB call based on the value of

CSMT in the "Additional update parameters" IE carried in the paging

response message. The determination process is the same as that

described in step 13.

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/bscexsoftpara_csfbpagingidentifysw.html







In MSC pool networking mode, after receiving a message in response to the

CSFB paging message from a UE accessing a GSM cell, the BSC performs either

of the following operations:

If the CSFB paging response message delivered by the eNodeB carries the

Temporary Mobile Subscriber Identity (TMSI), the BSC obtains the DSP of the

MSC according to the NRI in the TMSI information and sends a paging response

message to the MSC.

If the CSFB paging response message delivered by the eNodeB carries the IMSI

(International Mobile Subscriber Identity): When

the CSFBPAGRSPBCSWITCH(BSC6900,BSC6910) parameter is set

to YES(namely, the MSC supports Roaming Retry), the BSC randomly selects an

MSC from the MSC pool and sends the paging response message to the MSC.

When theCSFBPAGRSPBCSWITCH(BSC6900,BSC6910) parameter is set

to NO (namely, the MSC does not support Roaming Retry), the BSC discards the

CSFB paging response message.

20 to 22. (Optional) If the UE does not register with the MSC or the UE is not

allowed to access the LA, the MSC rejects the paging response and releases the

A interface links. The BSC then releases the signaling channel over the Um

interface. After the signaling channel over the Um interface is released, the UE

obtains the location area identity (LAI) and performs an LAU procedure.

23. The MSC initiates a CS call setup procedure.

If a UMTS network is available,

set SendUtranECSCFlag(BSC6900,BSC6910) to YES(Yes) to allow UEs to

proactively report 3G classmarks to the BSC. However, Classmark reporting

increases the call setup delay. To shorten this delay,

set UTRANCMDELAYFORCSFBSW(BSC6900,BSC6910) to ON(On) for CSFB

calls. This setting prohibits UEs from reporting 3G classmarks to the BSC. If an

early assignment procedure is used, the BSC proactively queries 3G classmarks

after the alerting procedure. If a late assignment procedure is used, the BSC

proactively queries 3G classmarks after assignment is complete.

24. (Optional) The UE performs an LAU or combined RAU/LAU procedure.

If the GBFD-511312 Fast LTE Reselection at 2G CS Call Release feature is

enabled, the UE quickly returns to an LTE cell. If there are suspended PS

services, the UE restores the PS services in the LTE cell.

If the GBFD-511312 Fast LTE Reselection at 2G CS Call Release feature is

disabled, the UE continues to camp on the GSM cell. If there are suspended PS

services, the UE initiates an RAU in the GSM cell to restore the PS services.

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsoft_csfbpagrspbcswitch.html




http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/othsoftpara_sendutranecscflag.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/othsoftpara_sendutranecscflag.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsoft_utrancmdelayforcsfbsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellsoft_utrancmdelayforcsfbsw.html




Paging Notification




EMM Extended Service Request




RRCConnectionReconfiguration





Offset Event A3

Hysterisis Event A3





A1 Thd

A2 Thd

B1 Thd




Measurement Report

Current RSRP bigger than A1 Thd




RRCConnectionRelease

List of Registered GSM ARFCN




U2000 Configuration to add GERAN BCCH target only to DCS1800 or PCS1900




Location Update Request




Channel Request with Paging Response

BSC buffer TMSI

The TMSI was not match from LTE and GSM. So If the

paging response message and the buffered paging message do not match, the BSC determines that the MTC is a CSFB MTC. This is because the paging message of a CSFB call is not included in buffered paging messages but delivered from the LTE network.




Immediate Assignment




Immediate Assignment Extended




System Information Type 6 (Redirection Info)




Location Update Accept




CS Call Establishment Procedure

Call Process





Call Process





Call Process





Call Process




CSFB Call Setup Complete

CSFB to GERAN has time stamp from Extended Service Request on LTE Network until CS Call of target ringing




CSFB to GERAN Call Setup Duration

Extended SR : 23:14.844CC Alerting : 23.21.544Duration =6.700ms




In this signaling flow explain detail MTC Ultra-Flash CSFB 2G

• 1a to 3a. A UE initiates voice services in an LTE cell. The

eNodeB triggers an LTE-to-GSM SRVCC handover for the

UE.

NOTE:

In the MTC Ultra-Flash CSFB procedure, the MSC sends the

Paging request or CS Paging Notification message to the UE

before the UE sends the Extend Service Request message to the

MME.

• 3b. After receiving the SRVCC handover request from the

MSC, the BSC identifies the Ultra-Flash CSFB call and

prepares CS resources for the call.

• The BSC checks whether the configurations of MCC, MNC,

LAC, and SAC in the service area identifier (SAI) for a call

are consistent with those configured on the MSC server. If

they are, the BSC determines the call is an Ultra Flash

CSFB call. If they are not, the BSC determines that the UE

performed a UMTS-to-GSM inter-RAT handover.

• The MCC, MNC, LAC, and SAC can be configured using

parameters in

the GCELLCSFBPARA or GSAIFORLTE MO. The details

are as follows:

• MCC: UltraFlashCSFBSAIMCC(BSC6900,BSC6910) (GCE

LLCSFBPARA MO)

or SAIMCC(BSC6900,BSC6910) (GSAIFORLTE MO)

• MNC: UltraFlashCSFBSAIMNC(BSC6900,BSC6910) (GCE

LLCSFBPARA MO)

or SAIMNC(BSC6900,BSC6910) (GSAIFORLTE MO)

• LAC: UltraFlashCSFBSAILAC(BSC6900,BSC6910) (GCEL

LCSFBPARA MO)

or SAILAC(BSC6900,BSC6910) (GSAIFORLTE MO)

• SAC: UltraFlashCSFBSAISAC(BSC6900,BSC6910) (GCE

LLCSFBPARA MO)

or SAISAC(BSC6900,BSC6910) (GSAIFORLTE MO)

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaimcc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaimcc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saimcc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saimcc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaimnc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaimnc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saimnc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saimnc.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsailac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsailac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gsaiforlte_sailac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gsaiforlte_sailac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaisac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_ultraflashcsfbsaisac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saisac.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gsaiforlte_saisac.html





• In the MME pool or MOCN scenarios, if a BSC is connected

to multiple MSC servers, which are configured with different

SAI values, the BSC also needs to be configured with

multiple SAI values. The GCELLCSFBPARAMO can only

be used to configure one set of SAI parameters. To add

more SAI values, the GSAIFORLTE MO can be used. The

MCC, MNC, LAC, and SAC on the BSC are the combination

of the GCELLCSFBPARA MO and GSAIFORLTE MO.

NOTE:

When no SAI parameter has been configured through

the GCELLCSFBPARA MO, the GSAIFORLTE MO can also be

used to configure multiple sets of SAI parameters

• 4. The CN sends the Handover Command message to the

eNodeB, and the eNodeB sends the message to the UE.

• 5. The UE is handed over to the GSM network.

• 6 to 9. The UE establishes CS services on the GSM

network.

• Signaling is carried by traffic channels (TCHs), accelerating

signaling transmission.

• In the MOC Ultra-Flash CSFB and MTC Ultra-Flash CSFB

procedures, before sending or receiving the Alerting

message, the MSC sends the UE a Disconnect message,

instructing the UE to release a default session generated

during the SRVCC handover. This mechanism helps prevent

interference on subsequent session establishment. After the

UE is handed over to a GSM cell, if the UE sends the

Disconnect message to the MSC to release the default

session, the MSC does not send the Disconnect message to

the UE before sending or receiving the Alerting message





• Ultra-Flash CSFB eliminates the dimmed signaling

procedures shown in Figure 3-3 and Figure 3-4. The

following details the reasons why these signaling procedures

are eliminated:

• AuthenticationThe UE has been authenticated on the LTE

side before it is handed over from an LTE cell to a GSM cell.

• EncryptionThe UE has performed encryption as instructed

during the SRVCC handover.

• IMEI queryThe MME has sent the IMEI to the MSC during

the preparation for the SRVCC handover.

• CS resource establishmentThe GSM network has prepared

CS resources during the SRVCC handover procedure and

the UE does not need to reestablish CS resources after the

SRVCC handover.

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/en-us_bookmap_0019100827.html#fig21959103162925

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/en-us_bookmap_0019100827.html#fig46341296162938



Mobile Originating CSFB -> UTRAN

Based on the capabilities of UEs and networks, three fallback mechanisms are available for an eNodeB to perform CSFB to

UTRAN:

•R8 PS Redirection

After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing frequency

information about the target UTRAN to the UE. Based on the received frequency information, the UE searches for a UTRAN cell,

obtains the system information of the UTRAN cell, and initiates initial access and CS services.

•R9 PS Redirection (Flash CSFB)

After receiving a CS Fallback Indicator, the eNodeB sends an RRC Connection Release message containing information about a

target UTRAN frequency as well as system information about multiple target cells to the UE. Based on the received frequency

information, the UE searches for a UTRAN cell. As the UE obtains system information about the target cell, the UE initiates initial

access and CS services in the target cell, thereby reducing voice delay.

•PS Handover

The UE is handed over to the UMTS network through the PS handover procedure between the eNodeB and the UMTS network.

After the handover, the UE initiates CS services in the target cell.



Mobile Terminating CSFB -> UTRAN

In this signaling flow explain detail on LTE side




DL Information Transfer




EMM CS Service Notification




EMM Extended Service Request




RRC Conn Rcfg (B1)

Target 3G CellFreq & SC




RRC Conn RcfgCMP




Measurement Report




RRC Connection Release

In this information, UE was redirection to 3G Network with Scrambling Code 252 with 3G Freq 10612




Master Information Block 3G

SIB1

SIB3

SIB5

SIB7

SIB11




SB 1 3G

SIB19 optional

The RNC sends SIB19 messages to UEs if the cell to be enabled with this feature is configured with information about the frequencies of neighboring LTE cells and the SIB19 check box under the SIB Switchparameter is selected. The SIB19 message contains the neighboring LTE cell list and LTE cell reselection parameters




SIB Type 1 3G




SIB Type 3 3G




SIB Type 5 3G




SIB Type 5 3G



Mobile Originating CSFB -> UTRANSIB Type 7 3G

•The UL interference IE in SIB7 is one of the factors that determine the UE initial access level. The value of this IE

frequently changes with the network traffic conditions. To prevent a large amount of system information update

procedures caused by uplink interference, the RNC always sends the eNodeB the value of -105 dBm as the value of

the UL interference IE. It is worth noting that this may decrease the RRC connection setup success rate when the

UMTS uplink load is heavy.

•For details about definition on the UMTS cell identity, see section 9.2.1.61 "Source Cell Identifier" in 3GPP TS 25.413

V10.3.0. For details about the types of RAN system information contained in the RIM Application Identity IE, see section

10.2.48a "System Information Container" in 3GPP TS 25.331 V11.3.0.




SIB Type 11 3G

It’s containIntraFreqNeighbor List




SIB Type 12 3G




RRC Connection Procedure












UL Direct Transfer (Paging Response)




Authentication, Security, LAU, RAU Procedure




DL Direct Transfer (CC Setup)




DL Direct Transfer (CC Call Confirm)




RAB Assignment Procedure




RAB Assignment Procedure

CSFB to UTRAN has time stamp from Extended Service Request on LTE Network until CS Call of target ringing




UL Direct Transfer ( CC Alerting)




CSFB to UTRAN Call Setup Duration

Extended SR : 25:14.545CC Alerting : 25.20.430Duration : 5.8 s




In this signaling flow explain detail on 3G side (CSFB with R9 “Ultra Flash CSFB”)

• Step 1 through step 4: A UE in the LTE network initiates or

receives a voice service request. Therefore, the eNodeB

initiates an LTE-to-UMTS handover of combined services

through SRVCC. Using a mechanism, the MME and MSC

ensure the successful LTE-to-UMTS handover.

• Step 5: When ULTRA_FLASH_CSFB_SWITCH under

the PROCESSSWITCH2(BSC6900,BSC6910) parameter in

the MML command SET URRCTRLSWITCH is selected, the

RNC identifies the Ultra-Flash CSFB process based on the

CSFB information IE in the CS domain's relocation request

message that is sent as a response to the SRVCC-based

handover request. To ensure quick transfer of NAS

messages during admission after the UE is handed over to a

UMTS cell, the SRB rate of the UE can be specified by

the UltraFlashCSFBSRBRate(BSC6900,BSC6910) parame

ter in the MML command SET UFRC.

• Step 6: The CN sends a handover command to the eNodeB,

and the eNodeB delivers the handover command to the UE.

• Step 7: The UE is handed over to a UMTS cell.

• Step 8 through step 9: The RNC and UE implement the

security mode and processes such as UTRAN mobility

information.

• Step 10 through step 13: The UE and MSC exchanges NAS

messages with each other to set up a CS service.

• Step 14: The SRB rate is reconfigured to 3.4 kbit/s after the

CS service is set up to save UMTS resources.

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/urrctrlswitch_processswitch2.html


http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ufrc_ultraflashcsfbsrbrate.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ufrc_ultraflashcsfbsrbrate.html




In this signaling flow explain detail on 3G side (CSFB with R9 “Ultra Flash CSFB”)

• AuthenticationThis procedure is not required because the

UE has been authenticated on the LTE side before it is

handed over from an LTE cell to a UMTS cell.

• EncryptionThis procedure is not required after a CSFB

because the UE has implemented encryption according to

the handover command during the SRVCC handover.

• IMEI queryThis procedure is not required after a handover

is complete because the MME has sent the IMEI to the

MSC during the SRVCC handover preparation.

• CS resource establishmentThis procedure is not required

after a handover is complete because CS resources have

been prepared on the UMTS side during the SRVCC

procedure. This section only describes how Ultra-Flash

CSFB is implemented on the RAN side.


4.2 Mobile Initiated Termination CSFB from GERAN

(Cell Reselection)



The System Information 2quater (SI2quater) is sent on the Broadcast Control Channel (BCCH) to all MSs in a cell. SI2quater

contains the parameters related to the measurement of neighboring GSM and LTE cells and the measured results.

There are 504 Physical Layer Cell Identities (PCIDs) in an LTE network. The SI2quater contains the LTE frequencies and the

prohibited PCIDs if any corresponding to each frequency. All these frequencies and PCIDs are recorded in the LTE Cell

Reselection List, which contains a maximum of eight frequencies.

Priorities of neighboring cells are also broadcast to MSs through the SI2quater. The priority information is used for the priority-

based GSM or LTE cell reselection. The priority of neighboring GSM cells is determined

by NCELLPRI(BSC6900,BSC6910) for neighboring GSM cells in the neighboring cell relationship; the priority of neighboring

LTE cells is determined byNCELLPRI(BSC6900,BSC6910) for neighboring LTE cells in the neighboring cell relationship. The

priority of neighboring GSM cells must be different from that of neighboring LTE cells

The information about neighboring LTE cells can be split and transmitted through multiple consecutive SI2quaters. A start flag

is marked in the first SI2quater containing the neighboring LTE cell information, and an end flag is marked in the last SI2quater

containing the neighboring LTE cell information. In this way, the MS can decode these consecutive SI2quaters together to

obtain the complete information about neighboring LTE cells. This accelerates the cell reselection.

The information about neighboring LTE cells and network priorities is carried in the SI2quater when the

parameter LTECELLRESELEN(BSC6900,BSC6910) is set to YES(Yes).

When SI2QUATEROPTFORLTESW(BSC6900,BSC6910) is set to ON(On), the BSC sends MSs the neighboring LTE cell list

in SI2Quater and Measurement Information using a dense coding scheme. This decreases the number of delivered SI2quater

messages and shortens the PS service interruption duration.

Related Concept : SI2 Quarter

NOTE:

As specified in 3GPP protocols, the BSC can send external neighboring cell information to MSs by using a maximum of 16 SI2Quatermessages. If the number of external neighboring cells configured for a cell exceeds the maximum number of neighboring cells that can be contained in SI2Quater, the BSC will not send SI2Quater to MSs. Therefore, it is recommended that SI2QUATEROPTFORLTESW(BSC6900,BSC6910) be set to ON(On) to allow SI2Quater to contain information about more external neighboring cells

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/g2gncell_ncellpri.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/g2gncell_ncellpri.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gltencell_ncellpri.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellhobasic_ltecellreselen.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_si2quateroptforltesw.html






The purpose of measuring neighboring LTE cells is to obtain the signal quality of neighboring LTE cells, ensuring that the MS

can select a proper cell for cell reselection and handover.

To facilitate MS performing GSM/LTE inter-RAT cell reselection and handover, related system information (SI) is required. It

contains a list of neighboring LTE cells and parameters related to LTE cell reselection and handover, based on which the MS

measures the signal quality of neighboring cells and performs cell reselection and handover. The SI is the SI2quater sent on

the BCCH.

The MSs in a GSM cell measure the signal quality of both neighboring GSM cells and neighboring inter-RAT cells. Neighboring

inter-RAT cells include neighboring UMTS and LTE cells. In this document, however, only neighboring LTE cells are described.

To reduce unnecessary measurements and power consumption of MSs, the BSS controls the neighboring cell measurement

using the parameter THRPRISEARCH(BSC6900,BSC6910).

The MS determines whether to measure neighboring LTE cells based on THRPRISEARCH(BSC6900,BSC6910) and receive

level of the serving cell. The condition for triggering the measurement differs with the value

of THRPRISEARCH(BSC6900,BSC6910).

• If THRPRISEARCH(BSC6900,BSC6910) is set to a value ranging from 0 to 14, the measurement is triggered when the

receive level of the serving cell is lower thanTHRPRISEARCH(BSC6900,BSC6910).

• If THRPRISEARCH(BSC6900,BSC6910) is set to 15, MSs always measure the neighboring LTE cell information.

Related Concept : Measurement of Neighboring LTE Cells

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_thrprisearch.html














An MS reports the measured neighboring LTE cell information to the BSC. The BSC then appropriate neighboring LTE cell

frequencies to the MS for cell reselection or handover.

As specified in 10.5.2.20 Measurement Results in 3GPP TS 44.018 V10.8.0:

When a cell is configured with neighboring LTE cells, the cell can be configured with a maximum of (31 – Number of

neighboring LTE cell frequencies) neighboring GSM cell frequencies. If the number of configured neighboring GSM cell

frequencies exceeds the preceding specifications, the MS will fail to report neighboring LTE cell information.

To refrain the number of neighboring GSM cell frequencies from exceeding the protocol specifications,

set CELL2GBA1OPTSW(BSC6900,BSC6910) andCELL2GBA2OPTSW(BSC6900,BSC6910) to ON(On) to allow the BSC to

check the number of neighboring GSM cell frequencies. Table 3-1 lists the specifications of the number of neighboring GSM

cell frequencies.

Table Specifications of the number of neighboring GSM cell frequencies

Related Concept : Reporting of Neighboring LTE Cells

Information

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcell2gba1_cell2gba1optsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcell2gba1_cell2gba1optsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellho2gba2_cell2gba2optsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellho2gba2_cell2gba2optsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/en-us_bookmap_0001793237.html?ft=0&fe=10&hib=3.5.5&id=EN-US_BOOKMAP_0001793237#table1905218121423



• GSM/LTE cell reselection involves the cell reselection from GSM to LTE and the cell reselection from LTE to GSM. Cell

reselection is mainly performed by MSs.

• For an MS in idle mode, if the MS camps on a GSM cell, it can reselect an LTE cell; if the MS camps on an LTE cell, it

can reselect a GSM cell. The MS measures the information about neighboring LTE cells, and then decides whether to

reselect an LTE cell according to cell reselection parameters.

• For MSs in packet transfer mode, cell reselection modes include network-controlled mode 0 (NC0), network-controlled

mode 1 (NC1), and external network-controlled mode 2 (eNC2). The MS can reselect an LTE cell for PS services. NC0

cell reselection and NC1 cell reselection are performed by MSs without the intervention of the BSS. In eNC2 cell

reselection, the BSS sends signaling to steer MSs towards desired camping cells.

• The LTECELLRESELEN(BSC6900,BSC6910) parameter specifies whether to enable GSM/LTE inter-RAT cell

reselection. WhenLTECELLRESELEN(BSC6900,BSC6910) is set to NO(No), the BSS does not send the neighboring

LTE cell list and the parameters related to GSM/LTE cell reselection. In this case, MSs in a GSM cell cannot reselect an

LTE cell.

• When the GBFD-171210 Flexible Camp Strategy Based on SPID feature is enabled, the BSS categorizes MSs by their

characteristics based on subscriber profile IDs (SPIDs) and customizes GSM/LTE cell reselection policies based on MS

categories. For details, see Flexible User Steering Feature Parameter Description.

• When the GBFD-171209 IMSI-based Mobility Management for Multiple Operators feature is enabled, the BSS

categorizes MSs by their operators based on international mobile subscriber identities (IMSIs) and customizes GSM/LTE

cell reselection policies based on MS categories.

IRAT Cell Reselection Between GSM & LTE







LTE to GSM Cell Reselection

• When a UE in idle or connected mode moves from an LTE coverage area to a GSM coverage area, it may reselect a

GSM cell.

• After reselecting a GSM cell, the UE initiates the location update and route area update in the GSM network. The GSM

network handles the location update and route area update regardless of whether the UE is from an LTE cell or a GSM

cell.

GSM to LTE Cell Reselection

This section describes the feature GBFD-511301 Cell Reselection Between GSM and LTE.

This feature is introduced in 3GPP Release 8

1. The BSC is configured with the following priority information for the cell reselection based on cell

priority:LTE frequency priority, involving the

parameter EUTRANPRI(BSC6900,BSC6910) or NCELLPRI(BSC6900,BSC6910).

LTE frequency thresholds, involving

parameters THRPRISEARCH(BSC6900,BSC6910),EUTRANQRXLEVMIN(BSC6900,BSC6910), T

HREUTRANHIGH(BSC6900,BSC6910),THREUTRANLOW(BSC6900,BSC6910), HPRIO(BSC690

0,BSC6910), and TRESEL(BSC6900,BSC6910).

GSM serving cell priority, involving the GERANPRI(BSC6900,BSC6910) parameter.

GSM serving cell threshold, involving the THRGSMLOW(BSC6900,BSC6910) parameter.

where

EUTRANPRI(BSC6900,BSC6910)is the common priority of LTE cells.

NCELLPRI(BSC6900,BSC6910) is the common priority of LTE cells in neighboring relationship data.

THRPRISEARCH(BSC6900,BSC6910) is the threshold for priority-based inter-RAT cell search. If the receive level of

the serving cell is higher than this threshold, MSs do not search for neighboring LTE cells whose priority is lower than

that of the GSM serving cell.


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_eutranpri.html






http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_eutranqrxlevmin.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_threutranhigh.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_threutranlow.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_hprio.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_tresel.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_geranpri.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_thrgsmlow.html










EUTRANQRXLEVMIN(BSC6900,BSC6910) is used to calculate the RSRP of the target cell during a GSM-

to-LTE cell reselection decision:

RSRP = Measured RSRP – EUTRANQRXLEVMIN(BSC6900,BSC6910)

THREUTRANHIGH(BSC6900,BSC6910) is the upper threshold for priority-based GSM-to-LTE cell

reselections. MSs can reselect a neighboring LTE cell whose EUTRANPRI(BSC6900,BSC6910) is greater

than GERANPRI(BSC6900,BSC6910) and whose RSRP is greater

than THREUTRANHIGH(BSC6900,BSC6910).

THREUTRANLOW(BSC6900,BSC6910) is the lower threshold for priority-based GSM-to-LTE cell

reselections. If the receive levels of the serving cell and its neighboring GSM cells are lower

than THRGSMLOW(BSC6900,BSC6910), MSs can reselect a neighboring LTE cell

whose EUTRANPRI(BSC6900,BSC6910) is smaller than GERANPRI(BSC6900,BSC6910) and whose

RSRP is greater than THREUTRANLOW(BSC6900,BSC6910).

HPRIO(BSC6900,BSC6910) is the level hysteresis for priority-based cell reselections. The MS is allowed to

reselect a neighboring cell in UTRAN or EUTRAN whose priority is lower than the GERAN priority when all

the following conditions are met:

• The receive levels of the serving cell and all neighboring GSM cells are lower than THRGSMLOW(BSC6900,BSC6910).

• The measured RSCP value of no neighboring UTRAN cell is higher than THRUTRANHIGH(BSC6900,BSC6910), and

the measured RSRP value of no neighboring EUTRAN cell is higher than THREUTRANHIGH(BSC6900,BSC6910).

• The measured RSCP (or RSRP) value of one or more neighboring UTRAN (or EUTRAN) cells exceeds the measured

receive level of the serving cell by at least the decibel value corresponding to the value of HPRIO(BSC6900,BSC6910).




























http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_thrutranhigh.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_thrutranhigh.html







2. The MS has obtained the priority information for inter-RAT cell reselection.MSs in a GSM cell obtain the

neighboring LTE cell list and cell reselection priorities from SI2quater, and then measure neighboring

LTE cells according to the list and priorities. MSs in idle and packet transfer modes use the same GSM-

to-LTE NC0/NC1 cell reselection mechanism.

3. The MS supports priority-based GSM-to-LTE cell reselection.GSM/LTE dual-mode MSs always support

priority-based GSM-to-LTE cell reselection.

The target cell in a priority-based GSM-to-LTE cell reselection is selected as follows:

• If within the period specified by TRESEL(BSC6900,BSC6910), multiple neighboring LTE cells meet the condition

ofEUTRANPRI(BSC6900,BSC6910) > GERANPRI(BSC6900,BSC6910) and RSRP

>THREUTRANHIGH(BSC6900,BSC6910), the MS selects the neighboring LTE cell with the highest priority. If

multiple cells have the highest priority, the MS selects the cell with the highest RSRP from these cells.

• If within the period specified by TRESEL(BSC6900,BSC6910), the serving GSM cell is lower

thanTHRGSMLOW(BSC6900,BSC6910) of the serving GSM cell and all measured neighboring GSM cells, the

MS reselects an LTE cell according to the following rules:If multiple neighboring LTE cells meet the conditions

of EUTRANPRI(BSC6900,BSC6910) <GERANPRI(BSC6900,BSC6910) and RSRP

> THREUTRANLOW(BSC6900,BSC6910) for the period specified byTRESEL(BSC6900,BSC6910), the MS

selects the neighboring LTE cell with the highest priority. If multiple cells have the highest priority, the MS selects

the cell with the highest RSRP from these cells.

• If no neighboring cells meet the preceding condition, the MS selects the neighboring LTE cell whose RSRP is

greater than the receive level of the serving GSM cell plus HPRIO(BSC6900,BSC6910). If there are multiple cells

whose RSRP is greater than the receive level of the serving GSM cell plus HPRIO(BSC6900,BSC6910), the MS


When EUTRANPRI(BSC6900,BSC6910) is greater than GERANPRI(BSC6900,BSC6910), and THREUTRANHIGH(BSC6900,BSC6910) is small, the condition for priority-based GSM-to-LTE cell reselection is easy to meet. This decreases the number of MSs that camp on GSM cells

































ActivationOn the BSC LMT, perform the following steps:

• Run the ADD GEXTLTECELL command to add an external LTE cell. In this step, set EUTRAN Cell Type according to

onsite requirements.

• Run the SET GCELLHOBASIC command with LTE Cell Reselection Allowed set to YES(Yes) for the target GSM cell.

• Run the SET GCELLPRIEUTRANSYS command with GERAN Priority set to a value less than that of EUTRAN

Priority.

• Run the ADD GLTENCELL command to add a neighboring LTE cell. In this step, set the parameters as follows:

– Set Source Cell Index to the index of the cell to be verified.

– Set Neighbor Cell Index to the index of the added LTE cell.

– Set Support Cell Reselection to SUPPORT(SUPPORT).

• Run the SET OTHSOFTPARA command with Support Sent 2QUATER set to YES(Yes).

MML Command Examples

//Adding an external LTE cell

• ADD GEXTLTECELL: EXTLTECELLID=8048, EXTLTECELLNAME="cell", MCC="460", MNC="188",

ENODEBTYPE=HOME, CI=0, TAC=1, FREQ=2, PCID=3, EUTRANTYPE=FDD;

//Enabling LTE cell reselection

• SET GCELLHOBASIC: IDTYPE=BYID, CELLID=0, LTECELLRESELEN=YES;

//Setting the cell priority and the parameters about E-UTRAN system information

• SET GCELLPRIEUTRANSYS: IDTYPE=BYID, CELLID=0, GERANPRI=1, EUTRANPRI=7, THREUTRANHIGH=2,

EUTRANQRXLEVMIN=10;

//Enabling cell reselection from a GSM cell to a specific neighboring LTE cell

• ADD GLTENCELL: IDTYPE=BYID, SRCLTENCELLID=0, NBRLTENCELLID=8048, SPTRESEL=SUPPORT;

//Enabling the sending of System Information 2Quater

• SET OTHSOFTPARA: Send2QuterFlag=YES;




Case 1 : SI2Quarter appear after CC Disconnect

CC Alerting



CC Connect Acknowledge

No 3G Cell Reselection

LTE Cell Reselection Criteria




CC Disconnect

No 3G Cell Reselection





CC Release




CC Release





RR Measurement Information




RR Channel Release - IDLE

After Channel Release, there is no redirection info to EUTRAN or UTRAN (with no RWR/Fast Return)




SI2 Quarter-Index 0UTRAN Reselection Criteria




UTRAN Reselection Criteria SI2 Quarter-Index 1




EUTRAN & UTRAN Reselection Criteria

SI2 Quarter-Index 2




EUTRAN Reselection Criteria SI2 Quarter-Index 3




EUTRAN Reselection Process LTE SIB Type 1




EUTRAN TAU Process LTE Reselection



Case 2 : SI2Quarter appear before CC

Disconnect & with Fast Return

SI2Quarter Index 1


UTRAN Reselection Criteria





SI2Quarter Index 1


EUTRAN Reselection Criteria





CC Setup






CC Alerting






CC Disconnect






CC Release






CC Release Complete






CC Channel Release






SI Type 6






LTE SIB Type 1






UE Cap Enquiry



4.3 Mobile Initiated Termination CSFB from GERAN (Fast Return)



When GSM and LTE networks cover the same area, a UE terminating a call on the GSM network will camp on a GSM cell.

When the conditions for reselection to a neighboring LTE cell are met, the UE reselects to an LTE cell. This process takes a

long time because the UE initiates GSM-to-LTE cell reselection only after receiving certain system messages and performing

cell reselection calculations.

Definition : Fast LTE Reselection at 2G CS Call Release allows a UE terminating a call on a GSM network to camp on an

LTE network based on the "cell selection indicator after release" information element (IE) in the Channel Release message.

This feature provides the following benefits:

• Improves user experience.UEs camp on an LTE cell without performing cell reselection calculation, accelerating cell

reselection. The GSM-to-LTE cell reselection delay decreases to 1s to 2s.

• Increases operator revenues.UEs can camp on an LTE cell for a long period, increasing operator revenues from LTE

networks.

With Fast LTE Reselection at GSM CS Call Release (referred to as Fast Return in this document), the BSC uses a Channel

Release message to send a proper neighboring LTE frequency to a UE upon a call release, and the UE reselects the

neighboring LTE cell working on the frequency.

This feature is used for circuit switched fallback (CSFB) and single radio voice call continuity (SRVCC) calls. They follow

similar Fast Return procedures.

CSFB calls If an LTE network cannot provide voice services in voice over IP (VoIP) mode, UEs initiating voice call services are

handed over from the LTE network to a GSM network using the CSFB procedure. CSFB calls include common CSFB calls and

Ultra-Flash CSFB calls.

SRVCC calls If an LTE network can provide voice services in VoIP mode, at the LTE coverage edge or in heavily-loaded LTE

coverage areas, VoIP calls are handed over to the GSM network using the SRVCC procedure.

Overview



Measurement-based Fast Return requires that UEs support LTE frequency measurement, and that both of the following

switches be set to ON(On):

• FASTRETURNMEASSPT(BSC6900,BSC6910) for CSFB calls

• SRVCCRapidSelSw(BSC6900,BSC6910) and SRVCCRapidSelMeasOptSw(BSC6900,BSC6910) for SRVCC calls

4.3.1 Measurement Based Fast Return

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_fastreturnmeasspt.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselmeasoptsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselmeasoptsw.html



1. The BSC reports frequencies and measurement parameters of a neighboring LTE cell, to the UE.After a traffic channel

(TCH) is established, the BSC sends a Measurement Information (MI) message to a UE. This message contains the

frequencies and measurement parameters of a neighboring LTE cell with SPTRAPIDSEL(BSC6900,BSC6910) set

toSUPPORT(SUPPORT).


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gltencell_sptrapidsel.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gltencell_sptrapidsel.html



2. The UE measures LTE frequencies and identifies appropriate LTE cells.The UE measures all the neighboring cells that

work on the received LTE frequencies reported. Based on measurement parameters, the UE identifies Mproper

neighboring LTE cells and uses a Measurement Report message to send information about the identified cells to the BSC.

The value of M is specified by EUTRANFREQCNUM(BSC6900,BSC6910).

The UE identifies proper neighboring LTE cells as follows:

The UE identifies neighboring LTE cells whose signal strength is stronger than the reference signal received power (RSRP)

threshold for triggering a fast reselection to an LTE cell. Based on the calculated signal strength, the UE sequences the

neighboring LTE cells in descending order, selects the first M cells, and reports them to the BSC.

Calculated signal strength = Signal strength measured by UEs + LTE FDD Report Offset

For details about the configuration, see the following table

3. After a call is complete, the UE releases the call.The UE sends a Disconnect message on the fast associated control

channel (FACCH). The MSC sends a Clear Command Message to the BSC, instructing the BSC to release the call.

4. If a CSFB call is performed, the BSC identifies whether to perform a common CSFB call or an Ultra-Flash CSFB call.

Common CSFB calls

If DecodeCSFBInd(BSC6900,BSC6910) has been set to ON(On), the BSC determines if the current call is a common

CSFB call based on the "CSFB indication" IE in the Clear Command message, and allows only CSFB calls to quickly

return to an LTE cell upon a call release.

If this parameter is set to OFF(Off), the BSC allows all dual-mode UEs supporting GSM and LTE networks to quickly return

to LTE cells upon a call release, without determining whether the current call is a common CSFB call.

Ultra-flash CSFB calls

The BSC checks whether configurations of the mobile country code (MCC), mobile network code (MNC), location area

code (LAC), and service area code (SAC) in the service area identifier (SAI) for an Ultra-Flash CSFB handover are

consistent with those of the MSC server. If they are, the BSC identifies the call as an Ultra-Flash CSFB call.


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_eutranfreqcnum.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellprieutransys_eutranfreqcnum.html



5. The BSC delivers a Channel Release message to the UE. This message contains frequencies of neighboring LTE cells.

The UE selects a suitable LTE cell based on the contents of this message.The sources of neighboring cell frequencies in a

Channel Release message are as follows:

• If LTEFastReturnFrqSendOptSw(BSC6900,BSC6910) has been set to ON(On), the BSC filters received MRs,

sequences MRs by frequency priority, filters out frequencies with a lower priority than the GSM frequency priority. Then,

the BSC delivers LTE frequencies in multiple MRs to the UE. Number of Frequencies Carried in a Channel Release

Message describes the number of LTE frequencies that can be sent.To prevent the UE from selecting a frequency that

has not been reported in an MR for some period (for example, if the UEs are far away from the frequency coverage

range and cannot access the network), the LTEFastResMaxMRMissCount parameter is used to specify whether to

send such a frequency. If the number of times this neighboring LTE cell frequency is not reported in an MR is greater

than the value ofLTEFastResMaxMRMissCount, this frequency will not be included in a Channel Release message to

be delivered to the UE. TheLTEFastResMaxMRMissCount parameter takes effect only when MrIntrplOptSwitch is set

to NO(No).

• If LTEFastReturnFrqSendOptSw(BSC6900,BSC6910) has been set to OFF(Off), the BSC does not filter received

MRs. Instead, it delivers the LTE frequency of the best-quality cell to the UE.


signaling messages for Fast LTE Reselection at GSM CS Call Release

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellothbasic_ltefastreturnfrqsendoptsw.html


http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/en-us_bookmap_0018850589.html?ft=0&fe=10&hib=3.5.11&id=EN-US_BOOKMAP_0018850589#section5347410516830





A CSFB call performs configuration-based Fast Return to a frequency if either of the following conditions is met:

FASTRETURNMEASSPT(BSC6900,BSC6910) is set to ON(On), and a UE does not support LTE frequency

measurement.CSFBFastReturnBaseCfgSw(BSC6900,BSC6910) is set to ON(On).

FASTRETURNMEASSPT(BSC6900,BSC6910) is set to OFF(Off).

An SRVCC call performs configuration-based Fast Return to a frequency only when both of the following conditions are met:

Conditions of measurement-based Fast Return are not met. For example, a UE does not support neighboring LTE cell

measurement.

SRVCCRapidSelBaseCfgSw(BSC6900,BSC6910) is set to ON(On).

4.3.2 Configuration Based Fast Return

Configuration-based Fast Return process



http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_csfbfastreturnbasecfgsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellcsfbpara_csfbfastreturnbasecfgsw.html



http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6900/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselbasecfgsw.html

http://localhost:7890/pages/GEE1231L/01/GEE1231L/01/resources/EN/GSM/BSC6910/m-bsc-mml-go/mbsc/m-para/gcellsrvcc_srvccrapidselbasecfgsw.html



4.3.2 Configuration Based Fast Return



Fast Return Configuration Based

CC Disconnect




CC Release, contain call duration




CC Release Complete




SI 5 : Optional




RR Measurement Report,

There is no LTE measurement report here, so the BSC was configure with ConfigBase Fast Return




RR Channel Release,

We can see that BSC send EUTRAN target freq as target Redirection to LTE Network




SIB Type 1 LTEAs the indication of entering LTE Radio Network


4.4 Mobile Initiated Termination CSFB from UTRAN

4.4.1 (Cell Reselection)



• Cell reselections between UMTS and LTE include LTE-to-UMTS cell reselections, UMTS-to-LTE cell reselections, and UMTS-to-

LTE quick cell reselections.

• When the LTE network is initially deployed, LTE coverage is weak or unavailable in some spots, but UMTS coverage is already

complete. The LTE network needs to support LTE-to-UMTS cell reselection so that UEs can reselect UMTS cells after finishing

services on the LTE network. LTE-to-UMTS cell reselection enables UEs to make full use of the existing UMTS network and reduce

load on the LTE network.

• After finishing services on the UMTS network, UEs are transitioned to the CELL_PCH/URA_PCH state or idle mode within the

period specified by a timer. In this case, the UMTS-to-LTE cell reselection function enables UEs to reselect and camp on LTE cells

with better signal quality. UMTS-to-LTE cell reselections enable UEs to better experience high-speed services on the LTE network

and reduce load on the UMTS network.

• To improve user experience, the UMTS-to-LTE fast cell reselection function can be enabled so that UEs can be quickly transitioned

to the CELL_PCH/URA_PCH state or idle mode and initiate UMTS-to-LTE cell reselections.

• RAN17.1 introduced the function of UMTS-to-LTE cell reselection for UEs in the CELL_FACH state. That is, after performing a state

transition from CELL_PCH/CELL_DCH/IDLE to CELL_FACH, a UE can perform a cell reselection to the LTE network based on the

absolute priority of frequencies.

• When a UE finishes its services and stays in the CELL_PCH, URA_PCH state, or idle mode on the UMTS network, it performs cell

reselections to the LTE network based on information element SIB19. Information element SIB19 carries the absolute priorities of

the serving UMTS cell and EARFCNs. After receiving SIB19, the UE will trigger measurements if measurement triggering conditions

are met. Based on the measurement results, the UE uses reselection to camp on a suitable cell.

• To use the UMTS-to-LTE cell reselection function in a cell, SIB19 must be broadcast in the cell. To enable SIB19 broadcasting in a

cell, select SIB19 under theSibCfgBitMap(BSC6900,BSC6910) parameter in the ADD UCELLSIBSWITCH or MOD

UCELLSIBSWITCH command. SIB19 only contains the neighboring LTE frequencies

withFreqUsePolicyInd(BSC6900,BSC6910) set to Idle_Only or Both.

• To enable absolute priority-based cell reselection to LTE for UEs in the CELL_FACH state, which is introduced in RAN17.1,

set CellFachPrioReselSwitch(BSC6900,BSC6910) to ON.

• If the CN sends an Iu Release Command message containing an "Out Of Utran" IE to the RNC after the UE in the

CELL_PCH/CELL_FACH state performs UMTS-to-LTE cell reselection, the RNC directly releases internal resources without

sending a RADIO BEARER RELEASE message or RRC CONNECTION RELEASE message to the UE. This function is supported

when OPTI_REL_UE_AFTER_IRAT_RESEL_SWITCH under OptimizationSwitch6(BSC6900,BSC6910) is selected.

Overview

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellsibswitch_sibcfgbitmap.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellsibswitch_sibcfgbitmap.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellnfreqprioinfo_frequsepolicyind.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellnfreqprioinfo_frequsepolicyind.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_cellfachprioreselswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellselresel_cellfachprioreselswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/urrctrlswitch_optimizationswitch6.html




• In LTE-preferred camping scenarios, the RNC of RAN18.0 sends MLB-based dedicated priorities to UEs that have performed LTE-

to-UMTS MLB handovers to prevent these UEs from reselecting to LTE cells again within a short period, ensuring proper load

balancing between LTE and UMTS. The implementation is as follows: After identifying a UE as being handed over from an LTE cell

to a UMTS cell due to the load reason, the RNC carries an MLB-based dedicated priority and an effective timer

(T322ForLoadBalance(BSC6900,BSC6910)) in the Utran Mobility Information message to the UE.

• To support this mechanism, the SIB19 must be broadcast in the UMTS cell and the MLB-based dedicated priorities are sequenced

based on the absolute priority in the SIB19 so that the priorities of LTE frequencies are always lower than the priorities of UMTS

frequencies. If a LTE cell reselection is triggered for a UE before the effective timer expires, the UE cannot reselect to any LTE cell

because the MLB-based dedicated priority is effective. After the timer expires, UMTS-to-LTE cell reselections can be performed

based on the absolute priority.

• This mechanism takes effect when L2U_MLB_HO_IN_DED_PRIO_SWITCH under HoSwitch2(BSC6900,BSC6910) is selected.

Overview

NOTE:When the SPID-based or IMSI-based dedicated priority takes effect, the SPID-based or IMSI-based dedicated priority takes precedence over the MLB-based dedicated priority and is preferentially carried in the Utran Mobility Information message.

As specified in 3GPP TS 25.331, frequencies of different RATs cannot be configured with the same priority. If frequencies of different RATs are configured with the same priority, MLB-based dedicated priorities will not be delivered.Frequencies supported by a UE are sequenced in descending order of MLB-based dedicated priority as follows: frequencies of the UMTS serving cell > frequencies of other UMTS cells > LTE frequencies > GSM frequencies. Meanwhile, frequencies of non-UMTS serving cells (frequencies of other UMTS cells, LTE frequencies, and GSM frequencies) are separately sequenced in descending order of absolute priority

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/uhocomm_t322forloadbalance.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/uhocomm_t322forloadbalance.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucorrmalgoswitch_hoswitch2.html




• Information element SIB19 carries the absolute priority SPriority(BSC6900,BSC6910) of the serving UMTS cell, the absolute

priorities NPriority(BSC6900,BSC6910) of EARFCNs, and cell reselection thresholds. Different radio access technologies (RATs)

must have different priorities. Upon receipt of information element SIB19, the UE performs inter-RAT measurement according to

specific criteria, as shown in the following figure:

Criteria for Starting Measurement

Parameters and variable involved in the preceding measurement criteria are as follows:• ThdPrioritySearch1(BSC6900,BSC6910)• Qrxlevmin(BSC6900,BSC6910)• ThdPrioritySearch2(BSC6900,BSC6910)• Qqualmin(BSC6900,BSC6910)• Thigher_priority_search: According to section 4.2.2

"Requirements" in 3GPP TS 25.133 (V11.5.0), the value of Thigher_priority_search (measured in seconds) equals the number of frequencies multiplied by 60.

When absolute priority-based cell reselection to LTE is enabled for UEs in the CELL_FACH state, which is introduced in RAN17.1, SIB19 carries the CELL_FACH state measurement indication. The measurement indicator is specified by the CellFachMeasLayer(BSC6900,BSC6910) parameter:• When this parameter is set to HIGH_PRIO_LAYERS, UEs only

measure frequencies that have higher absolute priorities than the frequency of the serving cell. Therefore, only the LTE frequencies that meet the preceding criteria and have higher absolute priorities than the frequency of the serving cell are measured.

• When this parameter is set to ALL_LAYERS, UEs measure all frequencies. Therefore, all LTE frequencies that meet the preceding criteria are measured.

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_spriority.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellselresel_spriority.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellnfreqprioinfo_npriority.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellnfreqprioinfo_npriority.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_thdprioritysearch1.html


http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_qrxlevmin.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellselresel_qrxlevmin.html



http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_qqualmin.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellselresel_qqualmin.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellselresel_cellfachmeaslayer.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellselresel_cellfachmeaslayer.html



SIB19 carries the absolute priority of the serving UMTS cell, the absolute priorities of the LTE frequencies, and the cell reselection

thresholds. The UE performs cell reselection based on the absolute priorities.

"Absolute priority based criteria for inter-frequency and inter-RAT cell reselection" in 3GPP TS 25.304 V11.3.0 specifies five sets of

criteria for cell reselection based on the absolute priorities. Criteria set 2 applies to intra-RAT inter-frequency cell reselections.

Criteria sets 1, 3, 4, and 5 apply to UMTS-to-LTE reselections. Criteria sets 1 and 3 use the reference signal received power (RSRP) to

evaluate signal quality, while criteria sets 4 and 5 use the reference signal received quality (RSRQ).

The RSRQSwitch(BSC6900,BSC6910) parameter in the ADD UCELLNFREQPRIOINFO or MOD UCELLNFREQPRIOINFO command

controls whether the UE performs cell reselection based on the RSRQ of the LTE frequency. When RSRQSwitch is set to TRUE and the

UE supports the RSRQ-based measurement, the UE performs cell reselection based on the RSRQ. Otherwise, the UE performs cell

reselection based on the RSRP.

Criteria for Triggering Cell Reselection

RSRP

RSRQ

NOTE:If RSRQSwitch is set to the same value for different LTE frequencies, you can set NPriorityto the same value for these LTE frequencies. If RSRQSwitch is set to different values for different LTE frequencies, NPriority cannot be set to the same value for these LTE frequencies.

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellnfreqprioinfo_rsrqswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellnfreqprioinfo_rsrqswitch.html












To summarize:

• If the criteria in criteria set 1 or 4 are met, the UE performs reselection to a cell working at an LTE frequency with a higher absolute

priority.

• If the criteria in criteria set 3 or 5 are met, the UE performs reselection to a cell working at an LTE frequency with a lower absolute

priority.

• If the criteria in neither criteria set are met, the UE remains on the UMTS network.

If multiple cells fulfill a set of criteria, the UE performs reselection to the cell with the greatest SrxlevnonServingCell value.


RSRP

RSRQ

NOTE:If RSRQSwitch is set to the same value for different LTE frequencies, you can set NPriorityto the same value for these LTE frequencies. If RSRQSwitch is set to different values for different LTE frequencies, NPriority cannot be set to the same value for these LTE frequencies.



4.4.2 (Quick Cell Reselection)



A UMTS/LTE multimode UE camping on the UMTS network can initiate UMTS-to-LTE cell reselection after finishing service processing.

In RAN14.0 and earlier versions, state transitions to the CELL_PCH or idle state are slow because the state transitions are triggered only

when the UE has not transmitted or received service data for a period of time specified by an inactivity timer.

To accelerate the UMTS-to-LTE cell reselection, you need to enable the UMTS-to-LTE quick cell reselection function by

selecting FAST_RETURN_LTE_BY_CELL_SELECT_SWITCH under PROCESSSWITCH4 in the SET URRCTRLSWITCH command.

• When the UMTS-to-LTE quick cell reselection function is enabled, whether a UE transits from the CELL_DCH state to the

CELL_PCH state or idle mode is specified

by UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH under PROCESSSWITCH4(BSC6900,BSC6910) in the SET

URRCTRLSWITCH command. When UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH is deselected, the UE transits from the

CELL_DCH state to the CELL_PCH state. When this switch is selected, the UE transits from the CELL_DCH state to idle mode.

• UL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH under PROCESSSWITCH4(BSC6900,BSC6910) is deselected by default.

SelectUL_DUAL_MODE_UE_D2P_OR_D2I_SWITCH if some UEs in the network do not support CELL_DCH-to-CELL_PCH state

transitions.

• Changing the value

of PsInactTmrForFstDrmDch(BSC6900,BSC6910) or PsInactTmrForFstDrmFach(BSC6900,BSC6910) affects this function and

the Enhanced Fast Dormancy feature.

Overview





http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/upsinacttimer_psinacttmrforfstdrmdch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/upsinacttimer_psinacttmrforfstdrmdch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/upsinacttimer_psinacttmrforfstdrmfach.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/upsinacttimer_psinacttmrforfstdrmfach.html



The following table lists the inactivity timers that are used and state transitions that are triggered before and after the UMTS-to-LTE quick

cell reselection function is enabled.

Overview



4.4.3 (MFBI based Cell Reselection)



• A multi-band LTE cell refers to an LTE cell whose working frequencies belong to multiple frequency bands. For example, if a cell

operating on a 10 MHz bandwidth in Band 17 is reconfigured as a multi-band cell working in Band 17 and Band 12, UEs supporting

Band 17 and Band 12 can access the multi-band cell. The mapping between LTE frequencies and frequency band is defined in 5.5

Operating Bands of 3GPP TS 36.101.

• When the LTE cell works on multiple frequency bands, UEs camping on the UMTS network and can reselect the multi-band LTE cell

if they support these frequency bands. This function is enabled by selecting HO_U2L_SUPPORT_MULTI_BAND_SWITCH under

theHoSwitch2(BSC6900,BSC6910) parameter. The master and slave frequency bands of the multi-band LTE cell configured by the

RNC must be consistent with those on the LTE network.

• When SlaveBandIndicator(BSC6900,BSC6910) is set to D0, the neighboring frequency is not used by any multi-band cells. The

RNC sends the master frequency and slave frequency band list in SIB19 or Utran Mobility Information messages. If the master

frequency or slave frequency band list are supported by the UE, the UE can initiate a cell reselection procedure. If the UE does not

support the primary frequency but supports the slave frequency band, the RNC sends the first frequency in the slave frequency

band to the UE.

• For frequencies configured with SPID/IMSI/ML-specific cell-reselection priorities, if the UE transits to the idle mode before the timer

expires, cell reselections are performed based on the frequencies and related reselection parameters in SIB19 and the priorities in

Utran Mobility Information.

Overview



http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/uratfreqpriogroup_slavebandindicator.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/uratfreqpriogroup_slavebandindicator.html


4.5 Mobile Initiated Termination CSFB from UTRAN(Fast Return)



In an area jointly covered by UMTS and LTE networks, a UE accesses a UMTS cell due to CSFB. When the UE finishes all services in

the UMTS cell, it releases the RRC connection. In versions earlier than RAN14.0, if the absolute priority of a neighboring LTE cell's

frequency is higher than that of the UMTS cell's frequency, the RRC CONNECTION RELEASE message does not contain the frequency

information about neighboring LTE cells. As a result, the UE camps on a UMTS cell. If a neighboring LTE cell fulfills the cell reselection

conditions, the UE reselects the neighboring LTE cell. Before initiating UMTS-to-LTE cell reselection, a UE needs to perform the following

operations, which consume much time:

• Receiving system information (MIB/SIB1/SIB3/SIB5/SIB7/SIB19) of the UMTS cell

• Performing decision on cell reselection based on certain criteria

The Fast Return from UMTS to LTE feature is introduced to reduce the time and improve user experience.

This feature applies to the areas that are jointly covered by UMTS and LTE networks and where the LTE network signal quality is

satisfactory.

If the LTE network signal quality is poor, for example, when an RRC CONNECTION RELEASE message contains information about n (a

positive integer) LTE frequencies whose signal quality is poor:

• UEs complying with a version earlier than 3GPP Release 10 select a suitable LTE cell from the LTE cells using n LTE frequencies.

The selection lasts for at most 10 seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells

using frequencies supported by these UEs. If a suitable LTE cell is still not found, these UEs randomly camp on a suitable cell. For

details, see section 8.5.2 Actions when entering idle mode from connected mode in 3GPP TS 25.331 V10.8.0.

• UEs complying with 3GPP Release 10 or later select a suitable LTE cell from the LTE cells using n LTE frequencies. The selection

lasts for at most n seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells using

frequencies supported by these UEs. The selection lasts for 4 seconds. If a suitable LTE cell is still not found, these UEs randomly

camp on a suitable cell. For details, see section 8.5.2 "Actions when entering idle mode from connected mode" in 3GPP TS 25.331

V10.9.0

Overview

Note that the UE cannot process CS or PS services or CS+PS combined services while searching for a suitable LTE cell.When PERFENH_FAST_RETURN_OPT_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) is selected, a fast return to the LTE network can be triggered by the first AMR release of a UE that has been handed over to the UMTS network through CSFB. If this switch is turned off, a fast return can be triggered by any AMR release of the CSFB UE as long as an RRC connection is live for the UE. In continuous LTE coverage scenarios, it is recommended that this switch be turned off. In discontinuous LTE coverage scenarios, it is recommended that this switch be turned on to avoid invalid measurement.The Fast Return from UMTS to LTE feature enables a UE that moves from an LTE cell to a UMTS cell through CSFB to quickly return to the LTE network after the CS service is finished.

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucorrmpara_perfenhanceswitch7.html




In an area jointly covered by UMTS and LTE networks, a UE accesses a UMTS cell due to CSFB. When the UE finishes all services in

the UMTS cell, it releases the RRC connection. In versions earlier than RAN14.0, if the absolute priority of a neighboring LTE cell's

frequency is higher than that of the UMTS cell's frequency, the RRC CONNECTION RELEASE message does not contain the frequency

information about neighboring LTE cells. As a result, the UE camps on a UMTS cell. If a neighboring LTE cell fulfills the cell reselection

conditions, the UE reselects the neighboring LTE cell. Before initiating UMTS-to-LTE cell reselection, a UE needs to perform the following

operations, which consume much time:

• Receiving system information (MIB/SIB1/SIB3/SIB5/SIB7/SIB19) of the UMTS cell

• Performing decision on cell reselection based on certain criteria

The Fast Return from UMTS to LTE feature is introduced to reduce the time and improve user experience.

This feature applies to the areas that are jointly covered by UMTS and LTE networks and where the LTE network signal quality is

satisfactory.

If the LTE network signal quality is poor, for example, when an RRC CONNECTION RELEASE message contains information about n (a

positive integer) LTE frequencies whose signal quality is poor:

• UEs complying with a version earlier than 3GPP Release 10 select a suitable LTE cell from the LTE cells using n LTE frequencies.

The selection lasts for at most 10 seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells

using frequencies supported by these UEs. If a suitable LTE cell is still not found, these UEs randomly camp on a suitable cell. For

details, see section 8.5.2 Actions when entering idle mode from connected mode in 3GPP TS 25.331 V10.8.0.

• UEs complying with 3GPP Release 10 or later select a suitable LTE cell from the LTE cells using n LTE frequencies. The selection

lasts for at most n seconds. If no suitable LTE cell is found, these UEs select a suitable LTE cell from the LTE cells using

frequencies supported by these UEs. The selection lasts for 4 seconds. If a suitable LTE cell is still not found, these UEs randomly

camp on a suitable cell. For details, see section 8.5.2 "Actions when entering idle mode from connected mode" in 3GPP TS 25.331

V10.9.0

Overview

Note that the UE cannot process CS or PS services or CS+PS combined services while searching for a suitable LTE cell.When PERFENH_FAST_RETURN_OPT_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) is selected, a fast return to the LTE network can be triggered by the first AMR release of a UE that has been handed over to the UMTS network through CSFB. If this switch is turned off, a fast return can be triggered by any AMR release of the CSFB UE as long as an RRC connection is live for the UE. In continuous LTE coverage scenarios, it is recommended that this switch be turned off. In discontinuous LTE coverage scenarios, it is recommended that this switch be turned on to avoid invalid measurement.The Fast Return from UMTS to LTE feature enables a UE that moves from an LTE cell to a UMTS cell through CSFB to quickly return to the LTE network after the CS service is finished.





This feature incorporates the following functions:

• UMTS-to-LTE Fast Return

• Enhanced UMTS-to-LTE Fast Return

• LTE Measurement-Based Fast Return

• RSCP Measurement-Based Fast Return

• Virtual Grid-Based Fast Return

• The UMTS-to-LTE Fast Return function and Enhanced UMTS-to-LTE Fast Return function are both based on blind redirection. That

is, neither UMTS-to-LTE Fast Return nor Enhanced UMTS-to-LTE Fast Return requires measurement. After the UE finishes the CS

service, the RNC immediately sends an RRC release message to redirect the UE to the LTE network. Before enabling the

Enhanced UMTS-to-LTE Fast Return function, you must enable the UMTS-to-LTE Fast Return function. However, before enabling

the UMTS-to-LTE Fast Return function, you do not need to enable the Enhanced UMTS-to-LTE Fast Return function.

• RAN17.1 introduces two types of measurement-based fast return: LTE measurement-based fast return and RSCP measurement-

based fast return.

• When LTE measurement-based fast return is enabled, the RNC triggers inter-RAT measurement of LTE after a CS service is

finished and delivers an RRC release message or handover command to redirect or hand over the UE to LTE only if the measured

LTE signal quality meets the handover threshold. Compared with blind redirection-based fast return, this type of fast return prevents

the out-of-service problem of UEs due to LTE coverage holes.

• The RSCP measurement-based fast return function is applicable where UMTS and LTE networks share a site. This function starts

RSCP measurement of the UMTS serving cell during the CS service of a CSFB UE. If the measured RSCP value reaches a specific

threshold, blind redirection-based fast return can be performed after the CS service is complete, which improves the success rate of

blind redirections and reduces the impact of LTE measurement in compressed mode.

• When virtual grid-based fast return is enabled, the RNC checks the LTE coverage in the grid based on the success rate of grid-level

UMTS-to-LTE handovers and redirections, and determines whether to perform fast return. In grids with good LTE coverage, blind

redirection-based fast return is performed. In grids with poor LTE coverage, fast return is not performed, which increases the

success rate of blind redirections and reduces the impact of LTE measurement in compressed mode.

Function and Selection Procedure










In the preceding figure, optimization of the UMTS-to-LTE fast return process and enhanced UMTS-to-LTE fast return process refers to that the RNC delivers the RRC CONNECTION RELEASE message immediately after receiving an IU RELEASE COMMAND message from the CS domain.



At the cell level, this function is controlled by the HO_UMTS_TO_LTE_FAST_RETURN_SWITCH under

theFastReturnToLTESwitch(BSC6900,BSC6910) parameter in the MOD UCELLHOCOMM command.

At the RNC level, this function is controlled by the HO_UMTS_TO_LTE_FAST_RETURN_SWITCH under

the HoSwitch(BSC6900,BSC6910)parameter in the SET UCORRMALGOSWITCH command. When this function is configured at both

the RNC and cell levels, the cell-level configuration takes effect.

This function works as follows:

1. The RNC first determines that a UMTS/LTE UE is a CSFB UE if the UE meets either of the following conditions:

– When the UE is moving from an LTE cell to a UMTS cell through a PS handover, the RELOCATION REQUEST

message contains a "cause" information element (IE) whose value is "CS Fallback triggered (268)" or a "CSFB

Information" IE whose value is "CSFB" or "CSFB High Priority."

– When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST

message does not contain the "Pre-redirection info" IE. (For details, see section 8.1.3.3 "RRC CONNECTION

REQUEST message contents to set" in 3GPP TS 25.331 V9.4.0.) The first service that the UE processes after

accessing the UMTS cell is a CS service.

2. If the UE is identified as a CSFB UE and the UE does not perform a PS service after finishing the CS service in the

UMTS cell, the RNC triggers the RRC connection release procedure.

3. The RNC includes the information about LTE frequencies in an RRC CONNECTION RELEASE message. For the

method of selecting LTE frequencies contained in the message, see 5.2.6 Selecting Frequencies to Be Carried in the

RRC CONNECTION RELEASE Message. Upon receiving the message, the UE selects a target cell based on the

information and attempts to camp on this cell. (For details about suitable LTE cell selection, see section 8.5.2 Actions

when entering idle mode from connected mode in 3GPP TS 25.331 V9.4.0.

UMTS to LTE Fast Return

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellhocomm_fastreturntolteswitch.html


http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucorrmalgoswitch_hoswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucorrmalgoswitch_hoswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/en-us_bookmap_0001792437.html#EN-US_TOPIC_0009795100



Fast Return

CC Alerting



Fast Return

CC Connect



Fast Return

CC Connect Acknowledge



Fast Return

CC Release



Fast Return

CC Release Complete



Fast Return




Fast Return

RRC Connection Release Complete



Fast Return




Fast Return

RRC Connection Release Complete



Fast Return




Fast Return

SIB Type 1



Fast Return

LTE Cell Reselection



Fast Return

LTE TAU Request



Fast Return

RRC Connection Request



Fast Return

RRC Connection Setup



Fast Return

RRC Connection Setup Complete



At the cell level, this function is controlled by PERFENH_PS_FAST_RETURN_LTE_SWITCH under

theFastReturnToLTESwitch(BSC6900,BSC6910) parameter in the ADD UCELLHOCOMM command. At the RNC level, this function is

controlled by PERFENH_PS_FAST_RETURN_LTE_SWITCH under the PerfEnhanceSwitch3(BSC6900,BSC6910) parameter in

the SET UCORRMPARAcommand. When this function is configured at both the RNC and cell levels, the cell-level configuration takes

effect.

The RNC first determines that a UMTS/LTE UE is a CSFB UE if the UE meets any of the following conditions:

• When the UE is moving from an LTE cell to a UMTS cell through a PS handover, the RELOCATION REQUEST message contains a

"cause" IE whose value is "CS Fallback triggered (268)" or a "CSFB Information" IE whose value is "CSFB" or "CSFB High Priority."

• When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST message does

not contain a "Pre-redirection info" IE. (For details, see section 8.1.3.3 "RRC CONNECTION REQUEST message contents to set" in

3GPP TS 25.331 V9.4.0.) After the RNC receives an RRC Connection Setup Complete message, the UE successfully sets up a CS

service within 10 seconds.

• When the UE is moving from an LTE cell to a UMTS cell through a redirection, the RRC CONNECTION REQUEST message

contains a "CSFB Indication" IE. (For details, see section 8.1.3.3 "RRC CONNECTION REQUEST message contents to set" in

3GPP TS 25.331 V9.10.0.)

• After the UE finishes its CS service in a UMTS cell, an IU RELEASE COMMAND message from the CN to the RNC contains an

"End Of CSFB" IE. (For details, see section 8.5.2 "Successful Operation" in 3GPP TS 25.413 V10.4.0.)

After the UE is identified as a CSFB UE and the UE finishes its CS service in the UMTS cell, the RNC triggers the RRC connection

release procedure regardless of whether or not the UE has a PS service ongoing. The RNC includes the information about LTE

frequencies in an RRC CONNECTION RELEASE message. For the method of selecting LTE frequencies to be carried in the RRC

CONNECTION RELEASE message, see 5.2.6 Selecting Frequencies to Be Carried in the RRC CONNECTION RELEASE Message.

Upon receiving the message, the UE selects a suitable LTE cell based on the carried LTE frequency information and attempts to camp on

this cell.

Enhanced UMTS to LTE Fast Return

In most cases, if there is a PS service ongoing when the UE finishes its CS service, the RNC does not deliver the RRC Connection Release message until the CS RAB is released. To shorten the time taken by the fast return of a CSFB UE to LTE, a mechanism is introduced so that the RNC delivers the RRC Connection Release message immediately after receiving an IU RELEASE COMMAND message from the CS domain. This mechanism takes effect when U2L_CSFB_FAST_RETURN_PROC_OPTI_SWITCH under the OptimizationSwitch6(BSC6900,BSC6910)parameter is selected.





http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/en-us_bookmap_0001792437.html#EN-US_TOPIC_0009795100





Overview

The following figure shows the principle of LTE measurement-based fast return.

1. Trigger phase: The RNC decides whether to trigger an LTE measurement-based fast return.

2. Measurement phase: The RNC decides whether to start an LTE measurement. If an LTE measurement is needed, it delivers the

measurement control message and handles the measurement result.

3. Execution phase: The RNC decides which procedure to trigger to implement the fast return, measurement-based redirection or

handover.

LTE Measurement Based Fast Return



Triggering

If a CSFB UE still has a PS service ongoing after it finishes a CS service, the RNC triggers an LTE measurement-based fast return when

the following conditions are met:

• The UE is identified as a CSFB UE on the UMTS side.

• The UMTS-to-LTE Fast Return feature is enabled.

• Measurement-based fast return after a CSFB UE finishes its voice service is enabled.

To ensure that an LTE measurement-based fast return to the LTE network can be triggered for a CSFB UE that has no PS service

ongoing after it finishes a CS

service, PERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under PerfEnhanceSwitch7(BSC6900,BSC6910) must be set

to ON in addition to the preceding conditions.

For a cell enabled with the MOCN feature, when PERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under

thePerfEnhanceSwitch7(BSC6900,BSC6910) parameter is selected, each operator can independently

deselectPERFENH_CS_ONLY_MEAS_FAST_RETURN_SWITCH under U2LAlgoSwitch(BSC6900,BSC6910) corresponding to

theirCnOpIndex(BSC6900,BSC6910)so that CSFB UEs that are not performing PS services after finishing their voice services will not

perform measurement-based fast return to LTE, without affecting UEs of other operators.

A UE is considered as a CSFB UE by the following mechanism only when it meets any of conditions 1 to 3

For the measurement-based fast return of a CSFB UE after releasing a voice service, there is an RNC-level switch and a cell-level switch.

The RNC-level switch is HO_CSFB_BASED_MEAS_FAST_RETURN_SWITCH under HoSwitch1(BSC6900,BSC6910). The cell-level

switch isHO_CSFB_BASED_MEAS_FAST_RETURN_SWITCH under FastReturnToLTESwitch(BSC6900,BSC6910). When both the

RNC-level and cell-level switches are configured, the setting of the cell-level switch takes precedence.






http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucelloperalgoswitch_u2lalgoswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucelloperalgoswitch_u2lalgoswitch.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucelloperalgoswitch_cnopindex.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucelloperalgoswitch_cnopindex.html







Measurement

If the UE supports LTE measurement in connected mode, LTE measurement is triggered in this phase. If the UE does not support LTE

measurement in connected mode, the process is terminated.

The measurement control message sent by the RNC contains the following LTE-specific information:

• Reporting mode of measurement reportsSimilar to service-based UMTS-to-LTE PS redirection or handover, the measurement

report is sent using event 3C.

• Information about the neighboring cell or frequency to be measured.

• Measured itemSame as service-based UMTS-to-LTE PS redirection or handover.

• Measurement event-related parameters:

• If no PS service is ongoing after the voice service is complete:The RSRP- or RSRQ-based decision threshold is specified

by SigTargetRatThdRSRP(BSC6900,BSC6910) or SigTargetRatThdRSRQ(BSC6900,BSC6910). Other parameters

related to measurement events are the same as those used for service-based UMTS-to-LTE PS redirection or handover. If

there is a PS service ongoing after the voice service is complete:All measurement event related parameters are the same

as those used for service-based UMTS-to-LTE PS redirection or handover.

If no PS service is ongoing after the voice service is complete, the LTE measurement duration is specified

by U2LTESigMeasTime(BSC6900,BSC6910). If there is a PS service ongoing after the voice service is complete, the LTE measurement

duration is specified by U2LTEMeasTime(BSC6900,BSC6910).

The method of processing the measurement result is the same as that used for service-based UMTS-to-LTE PS redirection or handover.


http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/uu2ltehoncov_sigtargetratthdrsrp.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/uu2ltehoncov_sigtargetratthdrsrp.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/uu2ltehoncov_sigtargetratthdrsrq.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/uu2ltehoncov_sigtargetratthdrsrq.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/uu2ltehoncov_u2ltesigmeastime.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/uu2ltehoncov_u2ltesigmeastime.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6900/MML/mbsc/m-para/ucellu2ltehoncov_u2ltemeastime.html

http://localhost:7890/pages/GEE1230E/01/GEE1230E/01/resources/EN/UMTS/BSC6910/MML/mbsc/m-para/ucellu2ltehoncov_u2ltemeastime.html



Execution

After receiving a 3C measurement report, the RNC determines whether to perform a redirection or handover according to the following

rules:

• If there is no PS service after the voice service is complete or the non-neighboring-cell frequency-based redirection switch

(HO_U2L_REDIR_BASED_ABSOLUTE_FREQ_SWITCH under theHoSwitch1(BSC6900,BSC6910) parameter) is turned on, the

RNC performs a redirection.If the measurement report contains multiple cells and the UMTS-to-LTE connected mode priority switch

(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1(BSC6900,BSC6910) parameter) is turned on, frequencies are sequenced

in a descending order of priority. If two frequencies have the same priority, they are sequenced in a descending order of signal

quality. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order of signal

quality. When the UL Unified Overload Control feature is enabled, the RNC filters out LTE frequencies carrying heavy traffic. Finally,

a maximum of four FDD LTE frequencies and four TDD LTE frequencies ranking at the top of the list are selected.

• If the switch for triggering non-neighboring-cell frequency-based redirection when there is a PS service ongoing after completion of a

voice service is turned off, the RNC checks whether

HO_HANDOVER_FAST_RETURN_TO_LTE_SWITCH under HoSwitch1(BSC6900,BSC6910) is selected:

• If this switch is turned on and the UE supports UMTS-to-LTE handover, the RNC performs a handover.If the measurement

report contains multiple cells and the UMTS-to-LTE connected mode priority switch

(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1(BSC6910,BSC6900) parameter) is turned on, frequencies are

sequenced in a descending order of priority. If two frequencies have the same priority, they are sequenced in a descending

order of signal quality. When the UL Unified Overload Control feature is enabled, the RNC filters out cells carrying heavy

traffic. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order of

signal quality. The cell corresponding to the frequency that is ranked at the top of the list is selected as the target cell of

handover.


Note:During a cross-Iur UMTS-to-LTE handover:When selecting target cells, if the switch for considering connected-mode priorities during UMTS-to-LTE handovers or redirections is turned on, frequencies of the neighboring LTE cells on the DRNC side are considered to have the lowest priorities.If the SRNC does not obtain the PCI and TAC information of a neighboring LTE cell under the DRNC, it will not initiate a handover to the cell











Execution

• If this switch is turned off or the UE does not support UMTS-to-LTE handover, the RNC performs a redirection. If the

measurement report contains multiple cells and the UMTS-to-LTE connected mode priority switch

(HO_U2L_CONN_PRIO_SWITCH under the HoSwitch1 parameter) is turned on, frequencies are sequenced in a

descending order of priority. If two frequencies have the same priority, they are sequenced in a descending order of signal

quality. If the UMTS-to-LTE connected mode priority switch is turned off, frequencies are sequenced in a descending order

of signal quality. When the UL Unified Overload Control feature is enabled, the RNC filters out cells carrying heavy traffic.

Finally, a maximum of four FDD LTE frequencies and four TDD LTE frequencies ranked at the top of the list are selected.


Note:After LTE measurement is triggered by fast return, the RNC directly releases the RRC connection if the PS service is released before the RNC receives an LTE measurement report from the UE.An SRVCC UE's fast return to the LTE network requires a measurement report. Therefore, a 3C measurement report of an LTE cell may be sent during the location area update (LAU) procedure. After receiving the 3C measurement report, the RNC terminates the LAU procedure and triggers a UMTS-to-LTE fast return. After being handed over or redirected to an LTE cell, the UE performs combined attach. Hence, the LAU success rate on the CN side is not affected by SRVCC UEs' fast return to the LTE network.


4.6 LTE S1 Handover



Overview

S1 Protocol Stacks

UE connections between eNB and EPC are as follows: In the control plane, each user’s signaling between eNB and MME is provided through S1 Application Protocol (S1AP) signaling connection1, and identified by {eNB UE S1AP ID, MME UE S1AP ID}. In the user plane, each user’s S1 bearer between eNB and S-GW is provided through GTP (GPRS Tunneling Protocol) tunnel, and identified by {DL S1 TEID (S1 eNB TEID), UL S1 TEID (S1 S-GW TEID)}.



Overview

S1AP Procedures and Messages Relating to Handover

Handover Required message: This message is used during the handover preparation phase. It is sent by the source eNB to MME, and includes information about the target eNB and the radio resources at the source cell.Handover Request message: This message is used during the handover preparation phase. It is sent by MME to the target eNB, and includes the user’s UE context.Handover Request Acknowledge message: This message is used during the handover preparation phase. It is sent by the target eNB to MME when the resource allocation for the UE is successfully completed at the target eNB. The target eNB allocates DL S1 TEID for S1 bearer to be used after the handover, and DL S1 TEID for S1 bearer (indirect tunnel) to be used for DL packet delivery during the handover, and then forwards them as included in the message.Handover Command message: This message is used during the handover preparation phase, and is sent by MME to the source eNB. It includes the information required when the UE accesses the target eNB (e.g. Target C-RNTI, Target eNB AS Security algorithm, DRB ID, etc.), and UL S1 TEID for S1 bearer (indirect tunnel) to be used by S-GW for DL packet delivery during the handover.eNB Status Transfer message: This message is used during the handover execution phase, and is sent by the source eNB to MME. It indicates from which packet the target eNB should receive or send.MME Status Transfer message: This message is used during the handover execution phase, and is sent by MME to the target eNB. It indicates from which packet the target eNB should receive or send.Handover Notify message: This message is used during the handover completion phase, and is sent by the target eNB to MME. It indicates that the UE has completed the handover to the target eNB.UE Context Release Command message: This message is used during the handover completion phase, and is sent by MME to the source eNB to request release of the UE context.UE Context Release Complete message: This message is used during the handover completion phase, and is sent by the source eNB to MME to inform that the UE context has been released.



S1 Handover Procedure

Before S1 HandoverIn the figure above, the UE is being served through eNB A (a serving cell in eNB A, to be more exact) that it has connected to. When the UE detects a measurement event, it sends a Measurement Reportmessage to eNB A.

S1 Handover PreparationThe source eNB (i.e. eNB A in the figure) chooses a target eNB (i.e. eNB B in the figure) to handover to, based on the neighbor cell list information it has kept and the information on the signal strength of the neighbor cells included in the Measurement Report message. Next, it, realizing a handover to the target eNB through the X2 connection is not possible, decides to perform a S1 handover instead, and prepares to perform one through MME. Both eNBs communicate with the MME through S1AP signaling. At this time, the target eNB allocates radio resource in advance to ensure the same services currently provided by the source eNB are also available at the target eNB. The MME also provides the source eNB with the information required for the UE to access the target cell.




S1 Handover PreparationIn the meantime, the target eNB and S-GW allocate resources needed to create an indirect tunnel through which DL packets arriving at the source eNB are forwarded to the S-GW and finally to the target eNB while a handover is being performed, as follows:The source eNB sends the information about the target eNB, as included in a Handover Requiredmessage, to the MME (❶).The MME then sends a Handover Request message that includes AS security information required for the target eNB to create the AS security base key along with the UE Context to the target eNB (❷).Target eNB▪ establishes an UL S1 bearer through which to forward UL packets after the handover by using the S1 S-GW TEID obtained from the MME, and allocates S1 target eNB TEID for a DL S1 bearer (❸).▪ allocates S1 target eNB TEID for the tunnel connecting the S-GW and the target eNB (this tunnel is a part of the indirect tunnel2 connecting all the way from the source eNB, S-GW and the target eNB) to be used for forwarding DL packets while the UE attempts to access (i.e. perform a handover to) the target eNB.▪ configures a Handover Command message that includes information needed for the UE to access the target cell (e.g. Target C-RNTI, Target DRB ID, etc.).▪ and sends the information to the MME by including it in a Handover Request Ack message (❹).




S1 Handover PreparationThe MME, upon receiving the message, includes the S1 target eNB TEID that the target eNB has allocated for the indirect tunnel in a Create Indirect Data Forwarding Tunnel Request message, and sends the message to the S-GW (❺).S-GW▪ Creates an indirect tunnel connecting the target eNB (❻).▪ allocates S1 S-GW TEID for the tunnel connecting the source eNB and the S-GW (this tunnel is a part of the indirect tunnel connecting all the way from the source eNB, S-GW and the target eNB), and sends it to the MME through a Create Indirect Data Forwarding Tunnel Response message.The MME includes i) the S1 S-GW TEID that the S-GW has allocated for the indirect tunnel, and ii) the information required for the UE to access the target cell, in a Handover Command message, and sends the message to the source eNB (❼).Then, the source eNB creates an indirect tunnel connecting to the S-GW (❽).

Through Steps ❽ and ❻, the entire indirect tunnel connecting all the three entities, the source eNB, S-GW and target eNB, is created.




S1 Handover ExecutionNow the two eNBs are ready to perform a handover, it is time to command the UE to perform one.Source eNB▪ commands the UE to perform a handover to the target cell by sending a Handover Commandmessage that includes all the information needed for the UE’s access to the target cell (❶).▪ informs the MME about from which UL/DL packet it should receive/send from/to the UE by sending an eNB Status Transfer message (❷).▪ sends the DL packets received from the S-GW on to the target eNB through the indirect tunnel connected to the target eNB via the S-GW (❹).The MME informs the target eNB about from which UL/DL packet it should send/receive to/from the UE by sending an MME Status Transfer message (❸).The UE disconnects from the source eNB, and connects to the target eNB (❺).Once the UE is successfully accessed to the target eNB, it becomes immediately capable of sending or receiving packets (❻).




S1 Handover CompletionAs the MME already knew that the UE was about to perform a handover, the target eNB, unlike in X2 handover, does not request the MME for path modification. Instead, the target eNB sends the MME aHandover Notify message to indicate the UE has completed the handover once the UE is connected to the target eNB.As soon as the UE is connected, the target eNBsends the MME a Handover Notify message to inform about the completed handover (❶).Then, the MME requests the S-GW for S1 bearer modification (❷). The S-GW modifies the DL S1 bearer path to connect to the target eNB, as requested (❸).The S-GW changes the bearer path as follows:▪ It stops DL packet delivery by sending an End Marker (EM) packet through the DL S1 bearer connected to the source eNB.▪ Then it creates a DL S1 bearer that connects to the target eNB, and resumes DL packet delivery to the target eNB.The target eNB sends DL packets to the UE as follows:▪ It sends DL packets arriving through the indirect tunnel to the UE until an EM packet arrives.▪ Once an EM packet arrives, it sends the UE the ones arriving through the new path.The MME:▪ requests the source eNB to release S1 resources related to the source eNB and the UE Context it has by sending an UE Context Release Command message (❹).▪ request the S-GW to release resources associated with the indirect tunnel by sending a Delete Indirect Data Forwarding Tunnel Request message (❺).



UE State and Connection Information

Before and After S1 Handover

Before S1 HandoverThe UE stays in EMM-Registered and ECM/RRC-Connected and keeps all the resources allocated by E-UTRAN and EPC.

• During S1 HandoverEven during the handover phase, the UE’s state on the NAS layer remains unchanged. Both the source and target eNBs are connected to the MME through the S1 signaling connection established over the S1-MME interface. They are also connected to the S-GW through the indirect tunnel created over the S1-U interface for DL packet forwarding. In Figure 3, Step 2) shows the connections and states while the handover is interrupted during the handover execution phase. During this period, no radio link connection is active, but the UE still remains Connected.

• After S1 HandoverThe UE remains in EMM-Registered and ECM/RRC-Connected states. The E-RAB (DRB + S1 bearer) path is switched to connect to a new eNB in the user plane while a new RRC connection is established in the control plane.



S1 Handover Preparation

Before Handover1) [UE → eNB] Measurement Report

As a measurement event is triggered,4 the UE measures the signal strength of neighbor cells, and sends a Measurement Report message to its associated eNB (serving cell).

▪ Handover Preparation2) [Source eNB] Handover Decision

The source eNB selects a target eNB based on the information included in the Measurement Reportmessage sent by the UE, and the neighbor cell list information it has kept. Becoming aware that no X2 connection is available for a handover between two eNBs, the source eNB decides to perform an S1 handover.

3) [Source eNB → MME] Requesting a HandoverThe source eNB sends a Handover Required message to the MME, requesting a handover to the target eNB. The information included in the message is as follows:




4) [MME] Deriving Security Context to Forward to the Target eNBThe MME derives the Security Context {NCC, NH} so that the target eNB can derive the AS security base key5. NCC increases by 1 starting from the initial NCC value (NCC0=0), and NH is derived from the initial NH value (NH0) and KASME.NCC1 = NCC0 + 1 = 1NH1 = KDF(NH0, KASME)

5) [Target eNB ← MME] Requesting the Target eNB for a HandoverThe MME sends a Handover Request message to the target eNB, requesting a handover on behalf of the source eNB. The information included in the message is as follows:




6) [Target eNB] Preparing S1 handoverUpon receiving the Handover Request message, the target eNB begins the handover preparation to ensure seamless service provision for the UE.(i) New S1 bearer resource allocation: The target eNB, based on the E-RAB to be setup information, checks if the same QoS provided by the source eNB is available at the target eNB as well. If available, it establishes an UL S1 bearer connecting to S-GW, by using the UL S1 bearer information (S1 S-GW TEID[A]) stored at the source eNB. Then it allocates S1 Target eNB TEID[B] to prepare a DL S1 bearer to be used after the handover.(ii) Indirect tunnel resource allocation: While the UE is performing a handover (i.e. after it disconnects from the source eNB, until it connects to the target eNB), there should be an indirect tunnel for rerouting DL packets arriving at the source eNB to the target eNBvia the S-GW. For this, the target eNB allocates S1 Target eNB TEID[C] so that the S-GW can establish an indirect tunnel connecting to the target eNB.(iii) Allocation of resource to be used by UE over radio link: Based on the E-RAB QoS information, the target eNB reserves RRC resources to be used by the UE over the radio link (e.g. DRB ID allocation, etc.), and allocates C-RNTI.(iv) KeNB

* derivation: It derives KeNB* by using the security context information (NCC1, NH1)6 it received from the MME for handover, and then obtains AS security keys (KRRCint, KRRCenc, KUpenc). Shortly after, when the UE connects to the target eNB, the two can communicate with each other securely over the radio link by using these key values. Figure 5 shows how KeNB* is derived. We can see that KeNB* is derived from NH1, the target cell’s Physical Cell ID (PCI) and frequency (E-UTRA Absolute Radio Frequency Channel Number-Downlink (EARFCN-DL)).




7) [Target eNB → MME] Notifying the MME of Preparation CompletionThe target eNB sends the MME all the information about the resources prepared in Step 6), as included in a Handover Request Ack7 message. The information in the message is as follows




8) [MME → S-GW] Requesting for Creation of S1 Bearer for DL Packet DeliveryThe MME sends the S-GW a Create Indirect Data Forwarding Tunnel Request message, requesting creation of an indirect tunnel for delivering DL packets while the UE is performing a handover. This message includes GTP TEID (S1 Target eNB TEID[C]) that the target eNB has allocated for the tunnel.

9) [MME ← S-GW] Notifying that S1 Bearer is Created for DL Packet DeliveryThe S-GW, upon receiving the Create Indirect Data Forwarding Tunnel Request message, creates an indirect tunnel connecting to the target eNB. It then allocates S1 S-GW TEID[D], forwards it through the Create Indirect Data Forwarding Tunnel Response message to the MME so that the source eNBcan create an indirect tunnel connecting to the S-GW.

10) [Source eNB ← MME] Notifying of the Completed HandoverThe MME sends the source eNB a Handover Command message that includes i) the S1 S-GW TEID[D]received from the S-GW in Step 9), and ii) the Handover Command information received from the target eNB in Step 7).The source eNB learns from the Handover Command message that the target eNB and EPC are ready for UE handover.



S1 Handover Execution

11) [UE ← Source eNB] Commanding UE to Perform a HandoverOnce the source eNB becomes ready for a handover, it commands the UE to perform a handover by sending a Handover Command message. The Handover Command message is delivered to the UE, as included in an RRC Connection Reconfiguration message.

12) [UE] Executing a HandoverOnce the UE obtains, from the received Handover Command message, C-RNTI and DRB ID to be used at the target cell, and detaches from the source eNB. Now, all packet exchanges between the UE and the source eNB are stopped, and the handover interruption time9 begins.

13) [UE] AS Security SetupThe UE derives AS security keys to be used over the radio link of the target eNB. First it derives KeNB*, the AS base key, (the relevant key derivation functions are as seen in Figure 5), then it derives AS security keys (KRRCint, KRRCenc, KUPenc) by using the AS security algorithms that the target eNB selected.




14) ~ 15) [Source eNB → MME, MME → target eNB] Notifying the No. of the Packet to Send/ReceiveThe source eNB sends an eNB Status Transfer message that includes DL Count and UL Count to the MME, which then forwards the same information through an MME Status Transfer message to the target eNB. This was the target eNBknows from which packet it should send to (or receive from) the UE. Here, the count values are PDCP PDU Counts, and each Count is a 32-bit value consisting of Hyper Frame Number (HFN) and PDCP Sequence Number (SN). The information included in the message is as follows:

After sending the eNB Status Transfer message, the source eNB begins to forward DL packets arriving from S-GW to the target eNB through the indirect tunnel established over the S1 interface. The target eNB buffers the packets and waits for completion of the UE’s access.




16) ~ 18) [UE, Target eNB] UE가 UE’s Access to the Target eNB16) The UE detects the synchronization signal from the target eNB to perform synchronization to the target eNB. Once synchronized, the UE initiates non-contention based random access. 17) The target eNB sends the UE the timing alignment information and UL Grant. 18) The UE sends the target eNB a Handover Confirm message as included in the RRC Connection Reconfiguration Completemessage.

Now, the UE can send/receive packets to/from the target eNB, and the handover interruption time is ended.

19) [UE ~ Target eNB] Secure Communication over the Radio LinkAll RRC signaling messages and user packets sent over the radio link between the UE and the target eNB are now securely delivered using the AS security keys. RRC signaling messages are integrity protected and encrypted while user packets are encrypted before being sent.




20) [Target eNB] Resuming DL Packet Delivery to the UEAs the UE is successfully connected to the target eNB, the target eNB resumes to send the buffered DL packets to the UE through the following path (See [A] in Figure 6):

S5 bearer (P-GW to S-GW) → S1 bearer (S-GW to source eNB) → S1 bearer (source eNB to S-GW) → S1 bearer (S-GW to target eNB) → DRB (target eNB to UE)

In case packets are sent by the UE, the target eNB checks if the UL packets are received in the correct order, and then forwards them to the S-GW through the following path (See [B] in Figure 6):

DRB (UE to target eNB) → S1 bearer (target eNB to S-GW) → S5 bearer (S-GW to P-GW)



S1 Handover Completion

21) [Target eNB → MME] Requesting the EPS Bearer (S1 Bearer) Path SwitchOnce the UE is accessed, the target eNBnotifies EPC (MME) that the UE has successfully finished the S1 handover by sending a Handover Notify message that includes its ECGI and TAI.

22) ~ 27) Modifying the EPS BearerThe MME forwards the S1 Target eNBTEID[B] that was allocated by the target eNB to the S-GW by sending a Modify Bearer Request message. This way it requests the S-GW to modify the bearer path. Then the S-GW establishes a DL S1 bearer connecting to the target eNB, as requested. Some S-GWs, according to the options set during UE’s initial attach, are required to report if the UE’s serving cell is changed. In such case, the S-GW sends a Modify Bearer Request message to P-GW, having the P-GW report to PCRF, according to the EPS session modification procedure, that the UE’s serving cell has been changed.

28) ~ 29) [S-GW] Modifying the EPS Bearer (S1 Bearer) PathThe S-GW switches the DL packet delivery path into the DL S1 bearer that is connected to the target eNB. For this, first it sends End Marker (EM) to indicate the last packet to the DL S1 bearer connected to the source eNB. Then, it sends DL packets to the target eNBthrough the modified DL S1 bearer.



S1 Handover Completion

30) [Target eNB] Packet Re-orderingNow the target eNB receives DL packets forwarded from the source eNB through the indirect tunnel AND those sent from the S-GW through the newly modified path. So, it should be able to deliver them to the UE in the correct order. First, the target eNB forwards the DL packets received through the indirect tunnel to the UE. Then when EM arrives, it knows that the packet was the last one from this path, and thereafter it sends the DL packets received from the new path to the UE.

31) ~ 32) [Source eNB ←→ MME] Releasing the UE Context and S1 Resources Stored at the Source eNBThe MME informs the source eNB that it may release the resources (S1 bearer and indirect tunnel) it has kept over the S1 interface and the UE Context by sending an UE Context Release Commandmessage.The source eNB then releases the UE Context and S1 resources, and informs the MME of such release by sending an UE Context Release Complete message.

33) ~ 34) [MME ←→ S-GW] Releasing the Indirect TunnelThe MME sends the S-GW a Delete Indirect Data Forwarding Tunnel Request message, requesting for release of the indirect tunnel.Upon the request, the S-GW releases the indirect tunnel, and informs the MME of such release by sending a Delete Indirect Data Forwarding Tunnel Response message.



EPS Entity Information: Before/After S1 Handover

• As, in an intra-LTE environment, the information elements stored at EPS entities before and after S1 handover are the same as in

X2 handover, see our previous document [1] for the details (For EPS entities information, see below).

• Information on handover-related AS Security context may vary depending on the types of handover, e.g. X2 or S1. Handover

security is however out of the scope of this document, and hence was not presented here in details.

• Information elements stored at EPS entities during the handover procedure are pretty similar but can be different depending on the

types of handover. Those generated during handover and then deleted were not presented.

Closing

Unlike X2 handover, in S1 handover, EPC already knows about UE’s handover even before an actual handover is performed. Thus, EPC

is involved in the handover procedure from the handover preparation phase. It performs a handover in cooperation with the source eNB

and target eNB, and forwards DL packets arriving at the source eNB during the handover interruption time to the target eNB through the

indirect tunnel that passes the S-GW, preventing packet loss.

End of Section



S1 Handover Signaling Flow

Measurement Report




RRC Connection Reconfiguration







PRACH Config Contention Free




RRC Connection Reconfiguration Complete




MAC RACH Trigger


4.6 LTE X2 Handover



Overview

X2 Protocol Stacks

X2 handover is performed between a source eNB and a target eNB through the X2 interface. In an LTE network, these two eNBs can directly communicate with each other via the X2 interface, which differentiates the network from its precedents (2G and 3G). In a 2G or 3G network, the only way an eNB could learn of the status of its neighboring eNB was through control by packet core nodes. However, now LTE networks allow eNBs to directly exchange status information with each other via the X2 interface, and to independently perform handovers without any intervention by EPC nodes. Figure 1 shows the protocol stacks over the X2 interface in control and user planes.

In the control plane, two eNBs provide multiple users with X2 Application Protocol (X2AP) signaling through a single Stream Control Transmission Protocol (SCTP) connection. In the X2AP layer, users are identified by eNB UE X2AP ID (Old eNB UE X2AP ID, New eNB UE X2AP ID)1. In the data plane, the two eNBs are connected through a GPRS Tunneling Protocol (GTP) tunnel, as in S1/S5 bearer. A unique GTP tunnel is generated for each user2, and each tunnel is identified by its allocated Tunnel Endpoint Identifiers (TEIDs).



Overview

X2AP Function

X2AP signaling information can be roughly classified into two kinds, the one related to load/interference (i.e. Load Management function in the table) and the one related to handover (i.e. Mobility Management, Mobility Parameter Management, Mobility Robustness Optimization functions in the table).

Among the X2AP functions listed in Table 1, those related to SON are as follows:Load Management: enhances the interception performance among cells by exchanging load and interference information between two eNBseNB Configuration Update: performs automatic eNB configurationMobility Parameters Management: negotiates on handover triggering setting information among peer eNBs and uses the information for handover optimization Mobility Robustness Optimization: provides information on a handover failure eventEnergy Saving: help eNBs to consume less energy by exchanging information on cell activation/deactivation



Overview

X2 Messages Relating to Mobility Management Function

Handover Request message: This message is used during the handover preparation phase. It is delivered by a source eNB to a target eNB, and includes a user’s UE context.Handover Request Acknowledge message: This message is used during the handover preparation phase. It is delivered by the target eNB to the source eNB if resource allocation is successfully completed by the target eNB.Handover Preparation Failure message: This message is used during the handover preparation phase. It is delivered by the target eNB to the source eNB if resource allocation at the target eNB fails.SN Status Transfer message: This message is used during the handover execution phase. The source eNB delivers it to the target eNB to indicate from which packet it should receive or send.UE Context Release message: This message is used during the handover completion phase. The target eNB sends it to the source eNB, to request release of the UE context.Handover Cancel message4: This message is used during the handover preparation phase. The source eNB sends it to the target eNB when it needs to cancel a handover in preparation.



X2 Handover Procedure

Before X2 HandoverIn the figure above, the UE is being served through eNB A (a serving cell in eNB A, to be more exact) that it has accessed to. When the UE detects a measurement event, it sends a Measurement Report message to eNB A.




X2 Handover PreparationThe source eNB (i.e. eNB A in the figure) chooses a target eNB (i.e. eNB B in the figure) to handover to, based on the neighbor cell list information it has kept and the information on the signal strength of the neighbor cells included in the Measurement Report message.5 Next, it prepares an X2 handover with the target eNB through X2 signaling. In the meantime, the target eNB allocates resources in advance so that the same services currently available to the user at the source eNB are readily available at the target eNB as well. Also, to ensure a fast handover, the target eNB sends all the information needed for the user to connect to the target cell (e.g. C-RNTI) to the source eNB, which then forward the same to the UE, initiating the handover execution phase. The target eNBallocates resources as follows: When the source eNB sends the target eNB a Handover Request message that includes the user’s UE context (❶),The target eNB:▪ obtains S1 bearer information (S1 S-GW TEID) to establish an UL S1 bearer through which to transport UL packets (❷).▪ allocates TEID for the X2 transport bearer (GTP-U tunnel) through which to receive DL packets while UE attempts to access the target eNB.▪ allocates DRB resources and C-RNTI to be used by UE in the target cell.▪ sends a Handover Request Ack message to the source eNB (❸).Upon receiving the message, the source eNB establishes an X2 transport bearer through which to send DL packets (❹).




X2 Handover Execution Once handover preparation between the two eNBs is completed, it is time to have the UE perform a handover.The source eNB:▪ instructs the UE to perform a handover to the target cell by sending it a Handover Command message that includes all the information needed to access the target cell (❶).▪ informs from which UL/DL packet the target eNB should receive or send when communicating with the UE by sending the target eNB an SN Status Transfer message (❷).▪ forwards the DL packets received from S-GW to the target eNB through the X2 transport bearer established between itself and the target eNB (❸).The UE detaches from the source eNB and accesses to the target eNB (❹).The target eNB becomes capable of sending and receiving packets once the UE has successfully accessed (❺).




X2 Handover Completion As seen so far, all the procedures performed during the handover execution phase (i.e. after the source eNBdecided to perform a handover, and until the UE finally was connected to the target eNB) were just between the two eNBs, and no information about the handover was reported to EPC (MME). Now that the handover is completed, the target eNB informs EPC as follows:Once the UE has accessed, the target eNB informs EPC and sends a Path Switch Request message to MME so that the EPS bearer path can be modified accordingly (❶).When receiving the message, the MME becomes aware of the UE’s new serving cell. Then, it requests S-GW for S1 bearer modification (❷).Upon the request, the S-GW establishes a DL S1 bearer (S1 Target eNB TEID) that connects to the target eNB. Then it stops sending DL packets to the source eNB, and begins to send them to the target eNB through the newly established DL bearer (❸).The MME informs the target eNB that the DL S1 bearer path has been modified (❹).The target eNB sends the source eNB a UE Context Release message, allowing the source eNB to release the UE context (❺).

After X2 HandoverThe UE is now being served through eNB B (the serving cell at eNB B, to be more exact) that it has accessed.



UE State and Connection Information Before

and After X2 Handover• Before X2 HandoverThe UE stays in EMM-Registered and ECM/RRC-Connected and keeps all the resources allocated by E-UTRAN and EPC.• During X2 HandoverEven during the handover phase, the UE’s state in the NAS layer remains unchanged, and an X2 bearer6 and X2 signaling connection are established over the X2 interface. In Figure 3, Step 2) shows the connections and states while the handover is interrupted during the handover execution phase. During this period, no radio link connection is active, but the UE still remains Connected. • After X2 HandoverThe UE remains in EMM-Registered and ECM/RRC-Connected states. The E-RAB (DRB + S1 bearer) path is switched to access to a new eNB in the user plane while a new RRC connection and S1 signaling connection (eNB(B) S1AP UE ID) are established in the control plane.



X2 Handover Preparation

▪ Before Handover1) [UE → eNB] Measurement

ReportAs a measurement event is triggered,8 the UE measures the signal strength of neighbor cells, and sends a Measurement Report message to its associated eNB (serving cell).

▪ Handover Preparation2) [Source eNB] Handover

DecisionThe source eNB selects a target eNBbased on the information included in the Measurement Report message sent by the UE, and the neighbor cell list information it has kept. In actual handovers, there can be more than one target eNB candidate, or a neighbor cell other than the one(s) reported by UE may be selected as a target cell. However, we will assume that only one eNB where the cell included in the Measurement Report message belongs is selected as a target eNB in this document.




3) [Source eNB] Deriving the AS Security Base Key (KeNB*) to be Used by the Target eNBWhen a handover takes place, the serving eNB of a UE is switched. During this switch, RRC signaling messages and user packets still have to be delivered seamlessly and securely. Over the radio link, it is AS security keys that ensure secured delivery of such data. AS security keys are derived from KeNB, the AS security base key9. KeNB is derived from KASME by MME after user authentication, and sent to eNB10. However, because X2 handover is performed between two eNBswithout any intervention by EPC (MME), the target eNB cannot obtain KeNB

* (KeNB to be used by the target eNB) from MME. So, the source eNB derives it and sends to the target eNB.For this reason, once the source eNBdecides to perform a handover, it derives KeNB

* first, as seen in Figure 5. We can see that KeNB

* is derived from KeNB (the AS security base key of the source eNB), and the target cell’s Physical Cell ID (PCI) and frequency (E-UTRA Absolute Radio Frequency Channel Number-Downlink (EARFCN-DL)).




4) [Source eNB → Target eNB] Requesting X2 HandoverThe source eNB requests a handover by sending a Handover Request message to the target eNB. Through this message, it delivers the UE context information it has stored, and the UE history which shows the cells that the UE has connected to prior to the last handover to the target cell. The information included in the message is as follows:




5) [Target eNB] Preparing X2 HandoverUpon receiving the Handover Request message, the target eNB begins handover preparation to ensure seamless service provision for the UE.(i) First, it derives AS security keys (KRRCint, KRRCenc, KUPenc) from KeNB

* it received from the source eNB. Using these keys, the target eNB can communicate securely with the UE over the radio link when the UE accesses.(ii) Next, the target eNB, based on the E-RAB to be setup information, checks if the same QoS provided by the source eNB is available at the target eNB as well. If available, it establishes an UL S1 bearer connecting to S-GW, by using the UL S1 bearer information (S1 S-GW TEID) stored at the source eNB.(iii) Then, based on the E-RAB QoSinformation, the target eNB reserves RRC resources to be used by the UE over the radio link (e.g. DRB ID allocation, etc.), and allocates C-RNTI.(iv) While the UE is performing a handover (i.e. after it disconnects from the source eNB, until it connects to the target eNB), DL packets arriving at the source eNB need to be forwarded to the target eNB. For this, the target eNBallocates X2 Target eNB TEID (DL TEID of X2 GTP tunnel) so that the source eNBcan establish an X2 transport bearer (GTP tunnel).




6) [Source eNB ← Target eNB] Notifying the Source eNB of Preparation CompletionThe target eNB sends the source eNB all the information about the resources prepared in Step 5), as included in a Handover Request Ack11 message. The included information is as follows:

7) [Source eNB] Establishing X2 Transport Bearer for DL Packets DeliveryUpon receipt of the Handover Request Ack message, the source eNB knows the target eNB can serve the UE. Then, using the X2 Target eNB TEID, it begins to establish an X2 transport bearer so that DL packets can be forwarded to the target eNB during the handover execution phase.



X2 Handover Execution

8) [UE ← Source eNB] Commanding a HandoverOnce the source eNB completes the handover preparation with the target eNB, it orders the UE to perform a handover by sending a Handover Command message.

9) [UE] Executing a HandoverThe UE, from the received Handover Command message, obtains C-RNTI and DRB ID to be used at the target cell, and detaches from the source eNB. Now, all packet delivery between the UE and the source eNB is stopped, and the handover interruption time13 period begins.

10) [UE] AS Security SetupThe UE derives AS security keys to be used over the radio link of the target eNB. First it derives KeNB* (AS base key for the target eNB) from the source eNB’s KeNB, the target cell’s PCI and frequency (the relevant key derivation functions are as seen in Figure 5). Next, it derives AS security keys for the target eNB (KRRCint, KRRCenc, KUPenc) by using the AS security algorithms that the target eNB selected.




11) [Source eNB → Target eNB] Notifying the No. of the Packet to Send/ReceiveThe source eNB informs the target eNBfrom which packet it should send to (or receive from) the UE by sending a SN Status Transfer message that includes DL Count and UL Count. Here, the count values are PDCP PDU Counts, and each Count is a 32-bit value consisting of Hyper Frame Number (HFN) and PDCP Sequence Number (SN). The information included in the message is as follows:

After sending the SN Status Transfer message to the target eNB, the source eNB begins to forward DL packets arriving from S-GW to the target eNB through the X2 transport bearer (GTP tunnel) established over the X2 interface. The target eNB buffers the packets and waits for completion of the UE’s access.




12) ~ 14) [UE, Target eNB] UE’s Access to the Target eNB12) The UE detects the synchronization signal from the target eNB to perform synchronization to the target eNB. Once synchronized, the UE initiates non-contention based random access. 13) The target eNB sends the UE the timing alignment information and UL Grant. 14) The UE sends the target eNB a Handover Confirm message as included in the RRC Connection Reconfiguration Complete message. Now, the UE can send/receive packets to/from the target eNB, and the handover interruption time period is ended.

15) [UE - Target eNB] Secure Communication over the Radio LinkAll RRC signaling messages and user packets sent over the radio link between the UE and the target eNB are now securely delivered using the AS security keys. RRC signaling messages are integrity protected and encrypted while user packets are encrypted before being sent.




16) [Target eNB] Resuming DL Packet Delivery to the UEAs the UE is successfully connected to the target eNB, the target eNB starts to send the buffered DL packets to the UE through the following path (See [A] in Figure 6):S5 bearer → S1 bearer (@source eNB) → X2 bearer → DRB (@target eNB)

In case packets are sent by the UE, the target eNB checks if the UL packets are received in the correct order, and then forwards them to S-GW through the following path (See [B] in Figure behind):DRB (@target eNB) → S1 bearer (@target eNB) → S5 bearer



X2 Handover Completion

17) [Target eNB → MME] Requesting the EPS Bearer (S1 Bearer) Path SwitchThe target eNB notifies EPC (MME) that the UE’s serving cell is switched by sending a Path Switch Request message, and requests for switch of EPS bearer path.

18) ~ 23) Modifying the EPS BearerThe MME forwards the S1 Target eNB TEID that was allocated by the target eNB to the S-GW by sending a Modify Bearer Request message. This way it informs the S-GW that the DL S1 bearer has been switched, and asks to switch the bearer path accordingly. Then the S-GW establishes a DL S1 bearer connecting to the target eNB, as requested. Some S-GWs, according to the options set during UE’s initial attach, are required to report if the UE’s serving cell is changed while an EPS session is created. In such case, the S-GW sends a Modify Bearer Request message to P-GW, having the P-GW report to PCRF, according to the EPS session modification procedure, that the UE’s serving cell has been changed.

24) [S-GW] Modifying the EPS Bearer Path and Sending EM PacketsNow that the DL S1 bearer path is modified, the S-GW switches the DL packet delivery path into the DL S1 bearer that is connected to the target eNB. For this, first it sends End Marker (EM) to indicate the last packet to the DL S1 bearer connected to the source eNB. Then, it sends DL packets to the target eNBthrough the modified DL S1 bearer.



EPS Entity Information: Before X2 Handover



EPS Entity Information: After X2 Handover



End of Section

We have so far discussed the X2 handover procedure performed in an intra-LTE environment where neither MME nor S-GW is changed after the procedure. X2 handovers are performed by source and target eNBs without EPC’s intervention. We also learned that DL packets are forwarded through the X2 transport bearer during the handover interruption time, to prevent packet loss.



X2 Handover Signaling Flow

Measurement Report









C-RNTI




PRACH Config




RRC Connection Reconfiguration Complete




Target C-RNTI



Thank You



Ray Khastur, ST.

Educational Background : Bachelor of Telecommunication Engineer, Telkom Institute of Technology (2006 –2010) JPPA-N Acceleration

Professional Experience : PI.Works, RAN Consultant (2014 ~ Present) China JIESAI, LTE Optimization Consultant (2014) Lintas Media Telekomunikasi, LTE RF Team Leader (2013 ~ 2014) HUAWEI Tech Investment, CWiL RNP/O Engineer (2011 ~ 2013) Transdata Global Network, CDMA RNO Engineer (2010 ~2011)

Achievements : RF Network Design & Planning First Commercial LTE Network in Indonesia (BOLT! Super 4G LTE)-2013 HUAWEI NPI & Post Launch Optimization BOLT! Super 4G LTE - 2014 PI.Works LTE Technical Expert for HUAWEI Environment LTE Planning & Optimization Trainer Floatway Certified-2013 LTE HUAWEI Trainer for Subcont-2016

Author

Engineering

LTE Layer 3 Analysis (part2)