CSFB测试中无TAU问题分析.ppt

* CSFB测试-由TAU引发的call block问题分析 单位：网络部 郑康 日期：2014-1-28 通过对比苏州本次CSFB语音测试结果，发现CSFB呼叫接通率比较低：主叫呼叫接通率是84.86%，远低于被叫呼叫接通率（97.50%）。 苏州问题发现-接通率低 序号 日志名称 接通率 接通率 MO呼叫建立成功率 Paging接收成功率 MT呼叫建立成功率 汇总结果 苏州all 84.86% 98.83% 88.83% 97.44% 1东区西区log合并 84.86% 98.83% 88.83% 97.44% 问题点： Paging接收成功率低 呼叫接通成功率低。被叫的掉线次数是都0次；造成接通率低的原因是call block次数太多，共154次 指标说明： 不同城市间的数据 不同城市数据： 使用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% 三个城市都存在由寻呼不到引发的呼叫接通率低的问题，说明这是个共性的问题 其中，苏州问题的最严重，后面针对苏州的测试log进一步分析原因；苏州与无锡的情况基本类似 南京与另外2个城市有差别，主要体现在南京的返回成功率比较低，但是paging成功率比较高，这点在后面也要单独分析 被叫没有收到paging消息情况有几种： LTE弱覆盖 跨POOL位置更新未接通 终端返回LTE时，没有发起TAU流程，导致接收不到paging消息 其他… 其中，无TAU流程造成的block共80次，占全部paging消息未收到情况的的97.5%，占全部call block原因的52%，是造成呼叫接通率低的主要原因 注：通过查看数据发现，若出现无TAU流程时，比较容易出现主叫连续出现call block的情况，对接通率指标影响比较大 呼叫接通率低原因：Call block次数较多（154次） 造成Call block原因主要有几种： 主叫建立异常导致超时 被叫建立异常导致超时 被叫没有接收到paging消息，导致主叫超时 手动停止测试等其他人工干预情况 主叫原因导致的block共7次，占比5% 由于被叫原因导致的block比较多，占比95%。其中，由被叫没有收到paging消息引起的block共有82次，占比56% 苏州接通率低问题分析-寻呼不到被叫导致的block占主因 容易出现主叫连续阻塞的情况 正常呼叫结束后的TAU信令流程 CDS界面显示的正常TAU流程 正常流程 被叫在GSM网络完成呼叫后，尝试返回LTE小区 在接收到LTE系统消息后，发起TAU request 并完成return LTE流程 完成呼叫后，终端发起TAU流程 从实践图标上可以看出，每次呼叫完成后，正常都会有一次TAU流程 Call block原因-终端返回LTE过程没有发起TAU 目前问题 被叫在GSM网络完成呼叫后，尝试返回LTE小区 在接收到LTE系统消息后，终端并未发起TAU request导致没有完成TAU流程，进而导致后面连续一段时间没有收到网络寻呼消息 返回时无TAU的异常流程 主叫 被叫 带来的疑问 为什么苏州的返回LTE成功率比南京高，但是呼叫成功率低？ 未发起TAU流程的现象有何规律，是哪些原因造成的？ 这些问题是终端个体的原因，还是与使用的芯片有关？ 无TAU流程导致的call block：不同城市间的对比 苏州、无锡、南京的log对比，均存在呼叫完成后无TAU的场景出现 苏州、无锡的现象一致，会出现连续呼叫阻塞的现象；南京是第一次呼叫阻塞了，但是后面的流程会正常 苏州 无锡 南京 现象类似，主叫连续block 现象不同，第一次block，后面流程正常 南京问题分析 南京与苏州有差异 ： 被叫在上次呼叫完成后没有TAU流程的场景出现后，会尝试发起service request，再被拒绝后会再尝试attach，会导致主叫一次call block，而接下来的流程就恢复了正常 本次呼叫结束后没有发起TAU流程 终端在收到paging 消息后,但Service request会被拒绝（隐式分离），之后终端会重新Attach 主叫block 恢复正常 苏州问题分析 苏州情况：在出现没有TAU的流程场景下，