MSC未发指配请求导致呼叫失败
问题类型：呼叫建立成功率较低
问题原因：某型号手机软件版本在是否需要鉴权上存在问题 排查人员：
地 点：广东联通汕头业务区BSC2 时 间：2003年10月25日 提交人员：洪建武 审核人员：
1. 问题描述
汕头业务区BSC2的呼叫建立成功率相对其他业务区来说比较低，在96％～97％之间徘徊，为了查明是什么原因导致呼叫建立成功率较低，在业务观察中进行全用户呼叫失败观察，发现“MSC未发指配请求—4112”（S_ERR_T303Expire）导致的呼叫失败很多，而且均为被叫，在10月25日15：25～17：25的2个小时观察中，共有81次此类失败，占总失败次数的8.1％。
在后台性能管理的语音呼叫失败原因统计中，10月25日全天的“MSC未发指配请求”失败次数为763次，占总失败次数的8.38％。由于此类失败原因在其他业务区很少，而在汕头业务区所占比重较大，因此需要对这类失败进行定位解决。
2. 问题分析
2.1. T303定时器检查
由于此类失败原因为S_ERR_T303Expire，也就是T303定时器超时，T303是呼叫信令流程中BSSAP收到移动台回的寻呼响应消息后，向MSC发送寻呼响应消息，等待MSC指配消息的定时器，具体的移动台被呼流程见附录。T303定时器默认设置为6s，如果T303设置小于6s，有可能BSSAP还未收到MSC的指配消息，T303就已超时，呼叫当然不能成功建立。
根据上面分析，检查了BSC侧CPM单板上的T303定时器，发现T303定时器设置为默认值6s，根据开发部的研究结果和其他业务区商用情况，T303定时器设置为6s是合理的，因此原因不是T303定时器的问题。
2.2. MSC侧信令跟踪
为了弄清在流程上是在哪一步出现了问题，在MSC侧对出现此类问题的手机进行了信令跟踪，下面即为发生此类失败的信令一例：
上述流程可以分析得到：
在12：05：38，VLR指示手机进行鉴权；
在12：05：44，手机不知何故，主动发出ClearReq，请求MSC拆线，接着MSC A口接收后向VLR报告鉴权失败；
然后MSC通过A口向BSC发出ClearCmd； 因此本次终呼流程结束。
从上面的流程发现的问题是，手机不知什么原因，主动发出ClearReq，要求拆线，为了找到这个原因，在BSC侧对这类失败进行了信令跟踪。
2.3. BSC侧信令跟踪
为了查明手机为什么主动发出ClearReq，从发生过此类问题的手机中找出一个，在BSC侧进行了信令跟踪：
。
分析信令流程发现，手机收到基站的寻呼消息后，在反向发送的寻呼响应消息PageResponse中将是否需要鉴权的字段添成false，而目前基站下发的开销消息中，是提示手机需要鉴权的，这就导致手机发送MSRejectOrder移动台拒绝指令，请求MSC拆线，呼叫
失败。
上图显示手机发出的寻呼响应消息中将bAUTHRExist字段设置为false，即不需要进行鉴权，而基站在寻呼信道上下发的接入参数开销信息中要求手机需要鉴权的，并且其他的各款商用手机都能够正确的进行鉴权处理：
2.4. 问题定位
至此，MSC未发指配请求导致呼叫失败的原因已经找到，那就是手机和基站在关于是否需要鉴权的设置上不一致，基站要求鉴权，而手机却不接受基站的指示，不进行鉴权，这样在等待鉴权的过程中T303超时，呼叫建立失败。
为了最终确认是手机的软件有问题，对发生过此类失败的手机进行了用户回访，以确认是否为同一型号的手机。分别在汕头和汕尾对这类呼叫失败进行了用户回访，结果如下：
汕尾：确认在当地跟踪到的8个出现该问题的用户有7人是使用的TCL1898手机（另一用户无数据），并且这批用户反映经常不能接到打进的电话，经事后询问，主叫方听到的提示音为“被叫暂时无法接通”。
汕头：回访了10个出现该问题的用户，8个用户使用的是TCL手机（其中5个确认是TCL1898，另3个不能确定具体型号），还有2 