苏州联通VPN智能用户 局间CSFB主叫失败案例
中国联通苏州分公司 朱凯 刘丹丹
2015年12月
1 问题概述
用户投诉打电话总是无法打通，苹果手机还显示呼叫失败，现场测试发现全部是在4G CSFB到3G网络后呼叫失败。投诉用户全部为iPhone用户。现场测试后复现问题，从iPhone的手机上看，呼叫失败后“中国联通”网标后面的3G标志消失，约3-5秒钟后，3G标志出现，根据现象，初步判断手机下到3G后被核心网拒绝，随后重新附着到核心网，成功后3G标志再现。在RNC上跟踪测试手机，信令表现为CSFB到UMTS后建立RRC连接，执行LAU，鉴权、加密，然后发起呼叫建立（CC_Setup），随后直接收到MSC下发的release complete，失败原因均为network out of order。
2 问题分析
现场测试4G占用XQ_U_S新区管委会B1F弱电间-A-1室分小区，回落到3G占用三元大厦-C-1小区。
RNCid Nodebid NodebName 1555 5521 Cellname Cellid 三元大厦基站机房_BBU_W 三元大厦-C-1 55213 PS：上面信令截图可见小区号为55213。
4G回落3G 一般流程上RRC建立原因值为originatingConversationalCall，但是
投诉点现场测试4G回落3G后RRC建立原因值为registration。
随后手机进行了位置区更新。
为保证联合附着4G的TAC与3G LAC是一一对应的，根据投诉点现场测试情况发现4G占用小区归属于SZMSS4A/TAC 20781， 3G占用小区归属于SZMSS3A/LAC 53529，对应关系如下图。即UE在TA20781上联合附着到3G/SZMSS4A，CSFB到
SZMSS3A下的LA 53529下，LA和MSC Server均发生变更，因此回落到UMTS上后立即执行LAU。
网元 MSC Server SZMSS1A LAI D118(53528) TAC 20768 20780 20770 MGW2 SZMSS3A D119(53529) 20771 20772 D127(53543) MGW3 MGW4 MGW5 MGW6 SZMSS2A SZMSS2A SZMSS2A SZMSS1A 20779 RNC Name RNC1 RNC2 RNC3 RNC4 RNC5 RNC12 RNC6 RNC7 RNC8 RNC9 RNC11 RNC10 RNC15 RNC16 RNC14 RNC ID 1552 1553 1554 1555 1556 1563 1557 1558 1559 1560 1562 1561 1566 1567 1565 三元大厦-C-1 XQ_U_S新区管委会B1F弱电间-A-1 Servering Cell MGW1 D11A(53530) 20773 D11B(53531) 20774 D11C(53532) 20775 D11D(53533) 20776 20778 20783 20784 20781 MGW7 MGW8 MGW9 SZMSS3A SZMSS4A SZMSS4A D11F(53535) D121(53537) D120(53536) 20786 CSFB策略采用盲重定向，盲重定向方式的CSFB是eNodeB收到CSFB指示后，通过RRC Connection Release消息直接释放UE，并在释放消息中指示UE一个目标系统UTRAN的频点信息，减少UE搜索目标的时间。UE搜索网络成功后，读取UTRAN小区系统消息，发起初始接入过程，并进行CS业务的申请。对UTRAN而言，此UE相当于初始接入的用户。
在投诉点现场使用安卓手机反复测试，4G回落3G呼叫均能正常呼叫，而使用员工卡在iPhone上测试折发生call failed的概率非常高，若第一发生，则随后等手机回到4G上，只要测试位置不变，再次拨打依然发生，几乎是必然事件（安卓和iPhone的测试时间和地点相同）。基于测试现象，排除无线侧原因，初步定位问题与SIM卡和核心网有关。
对现场安卓手机和iPhone手机进行核心网信令跟踪，从核心网信令上看4G回落3G后两张卡都进行了LOCATION_UPDATING_ACCEPT。
苏州联通VPN智能用户局间CSFB主叫失败案例(DOC)学习资料
