CSFB配置和流程分析.docx

CSFB配置和流程分析.docx

《CSFB配置和流程分析.docx》由会员分享，可在线阅读，更多相关《CSFB配置和流程分析.docx（17页珍藏版）》请在冰豆网上搜索。

1基于盲重定向的CSFB配置（HWLTE侧）

基于重定向方式的CSFB是eNodeB收到CSFB指示后，通过RRCRelease消息直接释放UE，并在释放消息中指示UE一个目标系统UTRAN的频点信息，减少UE搜索目标的时间。

UE搜索网络成功后，读取UTRAN小区系统消息，发起初始接入过程，并进行CS业务的申请。

对UTRAN而言，此UE相当于初始接入的用户。

基于测量的重定向和盲重定向差异较小，由于引入测量，基于测量的重定向时延会增加400-800ms左右。

因此，在初期建网时，选用了配合难度最小，参数配置最简单，风险也相对较小的R8盲重定向策略。

基于盲重定向的CSFB，在华为LTE侧需要做如下几步配置：

1）配置L2U重选系统消息

ADDCELLRESELUTRAN:

LocalCellId=0,TReselUtran=1,SpeedStateSfCfgInd=NOT_CFG;

2）配置LTE异系统小区重选优先级及门限

MODCELLRESEL:

LocalCellId=0,SNonIntraSearchCfgInd=CFG,SNonIntraSearch=4,ThrshServLow=4,CellReselPriority=6,QRxLevMin=-64;

3）配置UMTSF1邻频点信息

ADDUTRANNFREQ:

LocalCellId=0,UtranDlArfcn=10713,UtranVersion=HSPA,UtranFddTddType=UTRAN_FDD,UtranUlArfcnCfgInd=NOT_CFG,CellReselPriorityCfgInd=CFG,CellReselPriority=4,ThreshXLow=3;

4）配置UMTSF1外部虚拟小区（该小区为虚拟配置，可以与现网实际不同）

ADDUTRANEXTERNALCELL:

Mcc="460",Mnc="01",RncId=0,CellId=0,UtranDlArfcn=10713,UtranUlArfcnCfgInd=NOT_CFG,UtranFddTddType=UTRAN_FDD,RacCfgInd=NOT_CFG,PScrambCode=0,Lac=0;

5）配置UMTSF1虚拟小区为邻区（盲优先级必须非0）

ADDUTRANNCELL:

LocalCellId=0,Mcc="460",Mnc="01",RncId=0,CellId=0,BlindHoPriority=1;

6）配置UMTS盲重定向开关（CDMA的CSFB开关必须为0）

MODENODEBALGOSWITCH:

HoAlgoSwitch=UtranCsfbSwitch-1&Cdma1xRttCsfbSwitch-0,HoModeSwitch=UtranPsHoSwitch-0&GeranPsHoSwitch-0&UtranRedirectSwitch-1&BlindHoSwitch-1;

7）配置CSFB策略为Redirection

MODCSFALLBACKPOLICYCFG:

CsfbHoPolicyCfg=REDIRECTION-1;

之前对BlindHoSwitch参数理解有误，需要注意，该参数只对CSFB有效，用来控制CSFB中盲切换的打开和关闭。

若盲切换开关关闭，且UE支持对该RAT测量，启动对该RAT的测量，向UE下发该RAT的异系统测量配置。

具体流程参见附注1。

2基于盲重定向的CSFB信令解析

2.1CSFB语音通话正常信令流程

一次完整的CSFB业务的信令流程如下图所示：

2.2关键信令点

2.2.1ExtendedServiceRequest（LTE）

在servicetype中标识此次通话是主叫还是被叫

2.2.2RRCConnectionRelease（LTE）

在RRC连接释放中携带3G频点，让UE回落到3G网络

2.2.3RRCConnectionRelease（UMTS）

通话结束后，在RRC连接释放中携带4G频点，让UE快速返回4G网络

2.2.4TrackingAreaUpdateRequest/Accept（LTE）

2.2.4.1TAC更新请求

从3GFastreturn回4G时，UE会发起TAC更新，注明更新类型为联合TAC/LAC更新，并携带之前驻留的4GTAC和3GLAC

2.2.4.2TAC更新接受

如果联合TAC/LAC更新成功，在TrackingAreaUpdateAccept中会注明更新结果为CombinedTA，同时分配给UE新的GUTI（4G）和TMSI（3G）

2.3时延统计

2.3.1主叫时延

UE侧观察，在LTE发起ExtendServiceRequest消息开始，到UE在UMTS接收ALERTING消息，时延为5.791s。

2.3.2被叫时延

UE侧观察，UE在LTE发起ExtendServiceRequest消息开始，到UE在UMTS发送ALERTING消息，时延为3.276s

2.3.3FastReturn时延

UE侧观察，UE在UMTS侧收到RRCConnectionRelease消息开始，到UE在LTE发送TrackingAreaUpdateComplete消息，时延为0.537s

3异常案例分析

3.1核心网配置错误导致联合TAC/LAC更新失败

东莞现场早期开启CSFB功能时，测试发现手机无法附着到4G网络，信令流程如下图所示：

在TAURequest中，标注更新原因为CombinedTAupdatingwithIMSIattach,并携带老的4GTAC和3GLAC

虽然随后网络给了响应TAUAccept,但细看其中内容可以看到，联合更新失败了，ePS-update-result结果为TAonly，同时带有eMMcause为networkfailure。

而如果是联合更新成功，信令则是下图所示：

由于联合更新失败，导致手机在LTE网络发起detach而选择接入3G网络。

经检查，发现造成该故障的原因是因为核心网TAC-LAC匹配关系配置错误。

协议上这方面的解释如下所示：

whentheUEthatisattachedforEPSserviceswantstoperformanattachfornon-EPSservices.InthiscasetheEPSupdatetypeIEshallbesetto"combinedTA/LAupdatingwithIMSIattach".

TheUEreceivingtheTRACKINGAREAUPDATEACCEPTmessagetakesoneofthefollowingactionsdependingontheEMMcausevalue:

#17（Networkfailure）

TheUEshallstoptimerT3430ifstillrunning,andshallenterstateMMIDLE.Thetrackingareaupdatingattemptcountershallbeincremented,unlessitwasalreadysetto5.

Ifthetrackingareaupdatingattemptcounterislessthan5:

- theUEshallstarttimerT3411,shallsettheEPSupdatestatustoEU1UPDATEDandshallenterstateEMM-REGISTERED.ATTEMPTING-TO-UPDATE-MM.WhentimerT3411expiresthecombinedtrackingareaupdatingprocedureindicating"combinedTA/LAupdatingwithIMSIattach"istriggeredagain.

Ifthetrackingareaupdatingattemptcounterisequalto5:

aUEoperatinginCS/PSmode1ofoperationwith"IMSvoicenotavailable"shallattempttoselectGERANorUTRANradioaccesstechnologyandproceedwithappropriateMMorGMMspecificproceduresanddisabletheE-UTRAcapability（seesubclause4.5）.

上面的信令中TAU重试并没有5次，而只有两次，不知道是手机行为并未完全遵照协议，还是因为信令没有录制完整。

另外，上文协议中CS/PSmode1为UE'susagesettingis"voicecentric"，具体UE’susagesetting是如何确定的，目前还没查到资料。

3.2LTE侧没有配置CSFB时UE发起语音业务

LTE侧没有配置CSFB，这时候UE在LTE网络发起语音业务，表现出来的信令流程如下所示。

UE上报ExtendedServiceRequest，由于网络侧并没有配置CSFB功能，不会收到RRCConnectionRelease；由于迟迟无法收到网络的响应，UE在等待10s左右，自主选择到3G网络并发起业务请求。

3.3并发数据业务导致CSFB语音业务结束后无法马上从3G返回4G

设备厂家：

LTE:

HW,UMTS:

Ericsson

下图所示信令从回落到UMTS起呼后开始。

在3G起呼，Callpreceeding之后，有servicerequest（data）。

在物理信道重配中带了10688频点：

（这时候手机上就显示“H”，而不是“3G”）

过了5秒后，振铃接通再挂断，这时候数据业务仍在进行，所以只是释放了语音业务，体现为只有NAS层的Release，而没有RRCConnectionRelease。

数据业务结束后，RadioBearerReconfiguration从Cell_DCH转到Cell_FACH。

然后又做了两次小区更新。

但在小区更新后，又过了24秒，系统才下发RRCConnectionRelease，带4G频点。

这应该和用户不活动时间有关，如下图所示，RRC释放中的cause是userInactivity

另外，再看一个例子，如下图所示。

如果数据业务在Disconnect之前完成，那么通话结束后UE还是能快速返回4G的。

由于拨测时基本都是一接通就挂断，所以此时数据业务尚未完成，因此在正常通话中这种现象出现概率应该不大。

附注

基于测量重定向的CSFB流程

基于测量的重定向和盲重定向在流程上的差别在于前者系统会下发测量配置，待UE上报异系统的B1事件后启动重定向。