【LTE实战】CSFB用户无法做被叫寻呼问题分析

河西CSFB用户无法做被叫寻呼问题分析

故障现象：

1月18日iPhone5S被叫CSFB测试中发现，在河西区域路测被叫接通率只有30%,现场技术人员马上组织对问题进行跟踪和定位。

组网情况：

目前TDD-LTE组网图入下：

其中EnodeB为中兴设备，MME为华为设备，MSCserver为诺西设备。

目前采用的CSFB技术原理如下：

TD-LTE/TD-SCDMA/GSM(GPRS)多模单待手持终端在给MME发送的附着请求消息中携带支持CSFB能力的指示。MME在收到用户的联合附着请求后，在进行EPS附着的同时，会推导出其相关CS域的VLR信息，并向这个VLR 发起位置更新请求，VLR收到位置更新请求以后，会将该用户标记为已经进行EPS附着了，并保存用户的MME的IP地址，这样，VLR中就创建了用户的VLR与MME间的SGs关联。随后，MSC Server/VLR会进行CS域位置更新并把用户的TMSI和LAI(位置区标识)传给MME，从而在MME中建立SGs关联。最后，MME把VLR给用户分配的TMSI以及LAI等信息包含在附着请求接受消息中发送给UE，此时就表明用户的联合附着已经成功了。联合附着成功之后，启用CSFB能力的用户在TD-LTE网络中就可以处理电路域业务了。

故障现象分析：

在现场测试发现除iPhone5s外，lg-E785，中兴9810，华为D2手机都存

在70%以上的未接通概率，从测试的情况上基本上可以排除是终端问题，或是终端设备与中兴网络设备的配合问题。在终端不能做被叫时发现主叫CSFB是正常的，并且手机终端可以正常上网。通过数据核查和主叫CSFB正常的现象我们初步排除enode测数据配置问题。

1月19日，中兴组织人员联合移动公司技术支持人员在河西区域再次进行测试并跟踪信令分析。现场情况发现如果TAU正常时被叫能正常接通并CSFB 至GSM网络，TAU失败被叫就无法正常接通。正常时信令截图如下：

我们可以发现UE主动上报RRC请求并且扩展服务请求也成功，但是在TAU 失败时，MME上没有任何信令，如下是TAU请求失败信令：

在故障时我们在enodeb测也会发现UE释放请求，S1 Application Protocol （S1ap）里面显示接口建立步骤失败。

通过上述信息判断，主要问题可能存在于MME或是enodeb与MME之间的对接问题。

1月20日，要求MME技术支持人员帮助抓取信令分析，目前华为的MME 组网方式如下图：

共有3个MME设备组成一个MME pool，每个MME有主被2个IP地址。中兴Enode和MME对接SCTP偶联共有3条，分别如下：

华为核心网技术支持人员核对配置数据和信令跟踪消息反馈都没有问题。

为了验证是否为核心网问题，现场人员决定采用单独挂接MME的方式来验证。

在单独挂接MME01和MME02时被叫CSFB完全不能接通，但是挂接MME03时被叫CSFB完全正常。根据上述故障情况初步判断为MME01、MME02数据制作或是MME与MSC对接问题。之后在MSCserver上信令跟踪分析发现给主叫的寻呼消息错误发送至UE进行TAU之前的GSM网络中，导致被叫无法收到寻呼消息而无法触发CSFB流程。

故障解决情况：

MSCserver上重新配置与MME的对接数据后问题解决。在河西中兴区域进行的CSFB被叫遍历测试中没有出现连续未接通问题。

问题总结和思考：

根据3GPP TS 23.272-a21

规定

23272-a21.docx

，UE的联合注册流程如下:

Combined TA/LA Update Procedure

NOTE: The combined TA/LA Update procedure for the CS fallback and SMS over SGs in EPS is realized based on the combined RA/LA Update procedure specified in TS 23.060 [3] but

with CS domain access restrictions checks in the VLR.

1、 TAU过程只涉及到了UE和MME，后续如果在出现TAU相关问题，故障排

查的方向应该在UE和MME上，enode只是透传。

2、本次故障体现了enodeb测故障排查手段的匮乏，如果能认真分析msc发给

mme的location update accept消息，问题将能更快的定位。