CSFB测试中无TAU问题分析

1、CSFB测试-由TAU引发的call block问题分析单位：网络部郑康期：2014-1-282通过对比苏州本次CSFB语音测试结果，发现CSFB呼叫接通率比较低：主叫呼叫接通率是84.86%，远低于被叫呼叫接通率（97.50%）。苏州问题发现-接通率低序号日志名称接通率接通率MO呼叫建立成功率Paging接收成功率MT呼叫建立成功率汇总结果苏州all84.86%98.83%88.83%97.44%120140116-东区&西区log合并84.86%98.83%88.83%97.44%问题点：Paging接收成功率低呼叫接通成功率低。被叫的掉线次数是都0次；造

2、成接通率低的原因是call block次数太多，共154次指标说明：指标说明：3不同城市间的数据 不同城市数据：使用Sony M35T手机在3个城市进行部分网格测试，结果对比如下日志名称接通率LTE返回成功率接通率MO呼叫建立成功率Paging接收成功率MT呼叫建立成功率总体情况86.80%98.95%89.14%87.02%96.99%南京88.57%100.00%98.00%89.62%88.64%无锡93.22%99.32%68.60%61.69%99.22%苏州84.77%98.73%88.92%97.44%97.50%三个城市都存在由寻呼不到引发的呼叫接通率低的问题，说明这是个共性的

3、问题其中，苏州问题的最严重，后面针对苏州的测试log进一步分析原因；苏州与无锡的情况基本类似南京与另外2个城市有差别，主要体现在南京的返回成功率比较低，但是paging成功率比较高，这点在后面也要单独分析4被叫没有收到paging消息情况有几种：LTE弱覆盖跨POOL位置更新未接通终端返回LTE时，没有发起TAU流程，导致接收不到paging消息其他其中，无TAU流程造成的block共80次，占全部paging消息未收到情况的的97.5%，占全部call block原因的52%，是造成呼叫接通率低的主要原因注：通过查看数据发现，若出现无TAU流程时，比较容易出现主叫连续出现call block

4、的情况，对接通率指标影响比较大呼叫接通率低原因：Call block次数较多（154次）造成Call block原因主要有几种：主叫建立异常导致超时被叫建立异常导致超时被叫没有接收到paging消息，导致主叫超时手动停止测试等其他人工干预情况主叫原因导致的block共7次，占比5%由于被叫原因导致的block比较多，占比95%。其中，由被叫没有收到paging消息引起的block共有82次，占比56%苏州接通率低问题分析-寻呼不到被叫导致的block占主因容易出现主叫连续阻塞的情况5正常呼叫结束后的TAU信令流程6CDS界面显示的正常TAU流程正常流程被叫在GSM网络完成呼叫后，尝试返回LTE

5、小区在接收到LTE系统消息后，发起TAU request 并完成return LTE流程完成呼叫后，终端完成呼叫后，终端发起发起TAU流程流程从实践图标上可以从实践图标上可以看出，每次呼叫完看出，每次呼叫完成后，正常都会有成后，正常都会有一次一次TAU流程流程7Call block原因-终端返回LTE过程没有发起TAU目前问题被叫在GSM网络完成呼叫后，尝试返回LTE小区在接收到LTE系统消息后，终端并未发起TAU request导致没有完成TAU流程，进而导致后面连续一段时间没有收到网络寻呼消息返回时无返回时无TAU的异常流程的异常流程主叫主叫被叫被叫8带来的疑问 为什么苏州的返回LTE成功

6、率比南京高，但是呼叫成功率低？ 未发起TAU流程的现象有何规律，是哪些原因造成的？ 这些问题是终端个体的原因，还是与使用的芯片有关？9无TAU流程导致的call block：不同城市间的对比 苏州、无锡、南京的log对比，均存在呼叫完成后无TAU的场景出现 苏州、无锡的现象一致，会出现连续呼叫阻塞的现象；南京是第一次呼叫阻塞了，但是后面的流程会正常苏州苏州无锡无锡南京南京现象类似，主叫连续现象类似，主叫连续block现象不同，第一次现象不同，第一次block，后面流程正常，后面流程正常10南京问题分析 南京与苏州有差异 ： 被叫在上次呼叫完成后没有TAU流程的场景出现后，会尝试发起servic

7、e request，再被拒绝后会再尝试attach，会导致主叫一次call block，而接下来的流程就恢复了正常本次呼叫结束后没有发起TAU流程终端在收到paging 消息后,但Service request会被拒绝（隐式分离），之后终端会重新Attach主叫block恢复正常11苏州问题分析 苏州情况：在出现没有TAU的流程场景下，出现了被叫始终没有收到paging消息，而主叫连续呼叫block的情况。无锡情况与这个相同被叫没有收到paging，主叫连续block12 从目前几个城市的日志来看有些是问题发生的充要条件（有一次例外）。不过无锡与南京相比，测试有些区别南京无TAU情况导致的bl

8、ock占全部比例的30%左右，而无锡和苏州的比例超过70%。无锡测试的呼叫保持时间比较长，容易发生夸LAC区切换，所以发生问题概率较高。另外这个问题概率也许会和LAC、TAC区的划分有关系。发生问题后南京的被叫终端仍可以被寻呼，但Service request会被拒绝（隐式分离），终端会重新Attach，这样只影响一次呼叫，而无锡、苏州一旦被叫遇到此问题根本就寻呼不到，会造成连续的呼叫失败。除非是人工干预或触发终端发起业务流程才可恢复城市间的差异分析13造成未发起TAU条件分析：通过反复查看几个城市1000多次呼叫流程对比后发现，若存在以下几种情况，将有极大几率呼叫完成后不发起TAU流程的情况

9、 呼叫前的LTE小区所属TAC区与呼叫后返回的LTE的TAC区相同（但小区可以不一样） 回落后的第一个GSM小区所属LAC区与LTE下联合位置更新的LAC区相同 呼叫过程中发生了跨LAC区的切换，而且电话释放前所属的LAC区与开始不一样14造成未发起TAU条件分析： 经过反复对比数据分析发现，在呼叫过程中发生了跨LAC区的切换后，而且电话释放前所属的LAC区与开始不一样，有极大几率导致后面不发起TAU过程使用信令对比功能使用信令对比功能通过查看通过查看SIB6消息，可以看消息，可以看到呼叫过程中，到呼叫过程中，LAC发生了变发生了变化，电话释放前化，电话释放前LAC与之前不与之前不同，导致终端

10、返回到同，导致终端返回到LTE网络网络时，没有发起时，没有发起TAU流程流程没有发起没有发起TAU发生一发生一次切换次切换15回落后的第一个GSM小区所属LAC区与LTE下联合位置更新的LAC区相同，导致终端在返回LTE时，没有发起TAU流程被叫接收到被叫接收到paging消息后，发起了消息后，发起了CSFB呼叫流程，呼叫流程，正常完成本次呼正常完成本次呼叫后，在返回叫后，在返回LTE时没有再次发起时没有再次发起TAU，原因如右图，原因如右图回落后的回落后的GSM小区小区联合位置更新联合位置更新LAI中的中的LAC与与CSFB回回落后第一个落后第一个GSM小小区所属的区所属的LAC区一区一致致

11、造成未发起TAU条件分析：16 呼叫前的LTE小区所属TAC区与呼叫后返回的LTE的TAC区相同（但小区可以不一样）呼叫前，呼叫前，LTE服务小服务小区的区的PCI与与TAC通话结束后，返回通话结束后，返回到到LTE的服务小区通的服务小区通话前小区同属一个话前小区同属一个TAC。在此种场景下，终在此种场景下，终端也没有发起端也没有发起TAU流流程，而导致接下来程，而导致接下来持续没有收到持续没有收到paging消息消息造成未发起TAU条件分析：17 无锡测试环境，采用同一部手机作为主叫，分别采用了三星S4-9508C、索尼M35T、苹果iphone5S分别当做被叫，进行验证 对比测试结果发现三星S4-9508C、索尼M35T ，均能稳定复现此问题 使用苹果手机当被叫，手动统计结果，未出现此问题索尼索尼M35T三星三星S4不同终端对比：被叫分别为索尼M35T、三星S4、iphone由无由无TAU流程导致的