某区域CSFB用户无法做被叫寻呼问题分析

举报
Qgtdre 发表于 2019/01/28 07:49:19 2019/01/28
【摘要】 某区域CSFB用户无法做被叫寻呼问题分析的案例

某区域CSFB用户无法做被叫寻呼问题分析

故障现象:

18m型号手机终端被叫CSFB测试中发现,在某区域路测被叫接通率只有30%,现场技术人员马上组织对问题进行跟踪和定位。

组网情况:

目前TDD-LTE组网图入下:

无标题1.jpg

其中EnodeBA厂商设备,MMEB厂商设备,MSCserverC厂商设备。

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

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

故障现象分析:

在现场测试发现除m型号手机终端外,n型号手机终端,p型号手机终端,q型号手机终端都存在70%以上的未接通概率,从测试的情况上基本上可以排除是终端问题,或是终端设备与A厂商网络设备的配合问题。在终端不能做被叫时发现主叫CSFB是正常的,并且手机终端可以正常上网。通过数据核查和主叫CSFB正常的现象我们初步排除enode测数据配置问题。

19日,A厂商组织人员联合运营商公司技术支持人员在该区域再次进行测试并跟踪信令分析。现场情况发现如果TAU正常时被叫能正常接通并CSFBGSM网络,TAU失败被叫就无法正常接通。正常时信令截图如下:

无标题2.jpg

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

无标题3.jpg

在故障时我们在enodeb测也会发现UE释放请求,S1 Application ProtocolS1ap里面显示接口建立步骤失败。无标题4.jpg


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

20日,要求MME技术支持人员帮助抓取信令分析,目前B厂商的MME组网方式如下图:

无标题5.jpg


共有3MME设备组成一个MME pool,每个MME有主被2IP地址。A厂商EnodeMME对接SCTP偶联共有3条,分别如下:

POOL

MME

IP地址1

IP地址2

POOL1

MME01

100.78.244.1/32

100.78.244.2/32

MME02

100.78.244.8/32

100.78.244.9/32

MME03

100.78.244.16/32

100.78.244.17/32

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

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

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

故障解决情况:

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

问题总结和思考:

根据3GPP TS 23.272-a21规定,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.



无标题6.jpg

1. TAU过程只涉及到了UEMME,后续如果在出现TAU相关问题,故障排查的方向应该在UEMME上,enode只是透传。

   2. 本次故障体现了enodeb 测故障排查手段的匮乏,如果能认真分析msc发给mmelocation update accept消息,问题将能更快的定位。





【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。