苏州联通VPN智能用户局间CSFB主叫失败案例DOC.doc

苏州联通VPN智能用户局间CSFB主叫失败案例

苏州联通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
Cellname
Cellid
1555
5521
三元大厦基站机房_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
LAI
TAC
RNC Name
RNC ID
Servering Cell
MGW1
SZMSS1A
D118(53528)
20768
RNC1
1552

20780
RNC2
1553

MGW2
SZMSS3A
D119(53529)
20770
RNC3
1554

20771
RNC4
1555
三元大厦-C-1
20772
RNC5
1556

D127(53543)
20779
RNC12
1563

MGW3
SZMSS2A
D11A(53530)
20773
RNC6
1557

MGW4
SZMSS2A
D11B(53531)
20774
RNC7
1558

MGW5
SZMSS2A
D11C(53532)
20775
RNC8
1559

MGW6
SZMSS1A
D11D(53533)
20776
RNC9
1560

20778
RNC11
1562

MGW7
SZMSS3A
D11F(53535)
20783
RNC10
1561

RNC15
1566

MGW8
SZMSS4A
D121(53537)
20784
RNC16
1567

MGW9
SZMSS4A
D120(53536)
20781
RNC14
1565
XQ_U_S新区管委会B1F弱电间-A-1
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。

下图为安卓手机和iPhone手机在核心网收到Setup消息后的消息对比，iPhone手机在向VLR获取OCS数据时返回unknown subscriber。

查看iPhone手机Camel用户信息失败,提示未知用户,安卓手机未发现类似情况。下图为呼叫不通的时查询失败的消息。

呼叫不通的信令,从这里开始拆线。

考虑安卓手机和iPhone手机的不同，该问题可能在iPhone用户中表现较为突出，为校验SIM卡和手机的问题，将用来测试的安卓手机和iPhone手机中的SIM卡做交换后继续测试，现场测试发现iPhone中的SIM换到安卓手机中问题再现，而iPhone手机则不能再复制问题，因此可排除iPhone的问题，主要的问题则可能是SIM卡。
下图为iPhone中的SIM卡插入安卓手机后测试的无线侧信心截图，依然发生在Setup消息后的直接释放。

下图是交换侧信令截图：

3 问题根因
原理说明：与LAU相关的TMSI重分配流程（3GPP TS 24.008）。
Flow of TMSI relocation:

Usually the TMSI reallocation is performed at least at each change of a location area. (Such choices are left to the network operator).
The reallocation of a TMSI can be performed either by a unique procedure defined in this subclause or implicitly by a location updating procedure using the TMSI. The implicit reallocation of a TMSI is described together with that procedure.
TMSI reallocation initiation by the network. The network initiates the TMSI reallocation procedure by sending a TMSI REALLOCATION COMMAND message to the mobile station and starts the timer T3250.
The TMSI REALLOCATION COMMAND message contains a new combination of TMSI and LAI allocated by the network or a LAI and the IMSI if the used TMSI shall be deleted. Usually the TMSI-REALLOCATION COMMAND message is sent to the mobile station using a RR connection in ciphered mode. Upon receipt of the TMSI REALLOCATION COMMAND message the mobile station stores the Location Area Identifier (LAI) in the SIM/USIM. If the received identity is the IMSI of the relevant mobile station, the mobile station deletes any TMSI. If the received identity is a TMSI the mobile station stores the TMSI in the SIM/USIM. In both cases the mobile station sends a TMSI REALLOCATION COMPLETE message to the network. Upon receipt of the TMSI REALLOCATION COMPLETE message, the network stops the timer T3250 and either considers the new TMSI as valid or, if an IMSI was sent to the mobile station, considers the old TMSI as deleted.
以上是3GPP关于TMSI重分配流程的描述，其中说明用户每次跨LAC后都要进行由网络发起的TMSI RELOCATION。iPhone的流程是MSC通过LOCATION UPDATE ACCEPT消息下发给UE新的LAC和TMSI，但从信令看，UE没有回复TMSI RELOCATION COMPLETE消息给MSC，说明UE并未将核心网下发的LAI和TMSI保存在USIM中，此时USIM中应是老的LAI和TMSI，随后UE发起 CC_Setup，由于新的LA属于新的MSC Server，因此在新的VLR中无法查询到该用户，进而呼叫被新的MSC拒绝。而安卓手机则可完成TMSI RELOCATION，并回复给MSC TMSI RELOCATION COMPLETE消息，所以安卓手机可以顺利建立呼叫，MSC回call proceeding给UE。

由以上分析判断，该主叫失败的问题应与SIM卡相关，分析投诉客户群发现，主要是带有集团短号功能的VPN智能号卡，说明VPN智能号卡无法完成局间LAU携带的TMSI重分配流程，普通号卡则可以顺利完成TMSI重分配流程，成功完成呼叫。
随后对比 Location update complete消息的具体内容，发现对VPN用户，MSC并未下发新的TMSI，而对普通用户则下发了TMSI，所有普通用户的手机可以完成相应TMSI重分配流程，并回复MSC完成消息，但VPN用户则无法完成TMSI的重分配，导致呼叫失败。下图为VPN用户和非VPN用户的信令对比截图。

基于以上分析，核查核心网参数发现P677Bit13软参未开启
P677Bit13(**X* **** **** ****)：用于控制打开CSFB时延优化功能并且关闭TMSI重分配时是否关闭局间位置更新流程中的TMSI重分配（0：是，1：否，默认值：0）。
应用场景：打开CSFB时延优化功能并且关闭TMSI重分配时，如果不需要关闭局间位置更新流程中的TMSI重分配，则将该软参置为1。
系统影响：无。
关联软参：与软参P1103Bit2和P676Bit3配合使用，当软参P1103Bit2和P676Bit3都为0时本软参有效。
从该参数的解释分析可能与本案相关，因此尝试修改参数，并观察效果。
4 效果验证
开启核心网软参P677Bit13后，进行交叉验证。手机iPhone和安卓手机各一台，VPN SIM卡和普通SIM各一张，从测试结果来看，两个SIM卡交叉测试，呼叫均可成功建立，VPN SIM卡无论在iPhone中还是在安卓手机中，表现正常，LOCATION UPDATING ACCEPT消息中包含TMSI信息，随后TMSI RELOCATION重新分配TMSI成功，呼叫成功建立。说明修改该参数对本案有效。下面是核心网和无线网的呼叫流程截图。

5 总结与问题
从本案的追踪与分析，与CSFB相关的隐形问题在网路中依然存在，而语音呼叫对客户感知影响较大，因此在随后的持续性优化工作中，对客户的投诉或是路测发现的问题需要细致的分析，使网路的配置更加合理。
另外，本案中修改的核心网软参，与不同种类的SIM卡并无关联（普通用户在该参数没有修改的情况下MSC也下发新的TMSI，而VPN用户则不下发）。但从实际的效果来看，的确可以解决MSC针对智能号卡不下发TMSI的问题，此问题还需要核心网工程师继续探究，看是否还有其他没有考虑到潜在问题，使本案解决的更加完美。

2024-7-11

第17页, 共17页