我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:在线斗牛棋牌 > 故障分析 >

TD全网三种不同特征的位置区更新超长时延故障之分析与解决

归档日期:07-25       文本归类:故障分析      文章编辑:爱尚语录

  (佛山分公司) 摘要:佛山公司在对 4 月省公司第三方 TD 路测文件与全网 CT 文件的分析中,率 先发现三种不同特征的位置区更新故障:1、位置区更新 12-13 秒钟失败;2、位置 区更新 12-13 秒钟成功;位置区更新 8-9 秒钟失败。最终通过 LAU 的信令流程与 核心网定时器的研究,成功定位出这三种故障的原因所在。在此总结成文,以供参 考。 关键词: 位置区更新; T3260; T3270; TIMSECURYTM

  佛山公司在对 4 月省公司第三方 TD 路测文件与全网 CT 文件(全网异常信令文件)的 分析中,率先发现三种不同形式的位置区更新故障: (1) 、位置区更新持续 12-13 秒钟,最终失败; (2) 、位置区更新持续 12-13 秒钟,最终成功; (3) 、位置区更新持续 8-9 秒钟,最终失败。 以 4 月 21 日的佛山 RNC03 的 CT 为例,统计出三种故障出现的频率: (1) 、第一种故障:101 次 (2) 、第二种故障:27 次 (3) 、第三种故障:13 次 注:第二种故障统计的次数可能低估,因为 CT 文件只记录了全网异常信令。可能存在 很多 12-13 秒钟 LAU 成功,但 RNC 认为是正常信令并未计入 CT 文件的流程。 这三种故障表现的形式各不相同,但在全网来讲不是个案,而是普遍、大面积存在, 并且在位置区更新持续时间方面呈现出惊人的规律性和一致性。 以下是三种故障的发现过程 与详细描述。 1.1 12-13 秒钟位置区更新失败 佛山在对 4 月省公司第三方 TD 路测巡检 log 文件进行分析的时候,发现引起拉网测试 的 20 多次未接通,都是由于被叫在做位置区更新时被寻呼所导致的。我们发现每一次的未 接通事件中,被叫的位置区更新都会失败,而且耗时非常长。整个异常流程如下图所示。 LAU Reject 的原因是 Network Failure。

  我们发现一个有趣的规律: UE 发起 LAU Request 到收到网络侧下发 LAU Reject, 从 一 般都是 12-13 秒钟左右。 (请各位读者先记住这个有趣的数字,最后会作解释,为什么都是 12-13 秒钟) 除了路测文件的分析,我们还想到了 CT 文件。CT 文件记录了全网所发生的异常信令, 有助于我们复现已有的故障。另外,路测文件只能提供 Uu 口的消息和空口质量情况,对于 Iu 口的消息是缺失的;而且,路测文件仅仅反映了路测终端的性能,不具备代表性。 我们再抽取了 4 月 21 日佛山 RNC03 的 CT 文件分析, 发现该现象的故障在全网大面积 存在。我们统计该天 RNC03 的 12-13 秒钟位置区更新失败一共出现了 101 次。 1.2 12-13 秒钟位置区更新成功 我们在分析 CT 文件的时候,又发现了另外一个全新的故障:12-13 秒钟位置区更新成 功。这种故障耗时也是 12-13 秒钟,与第一种故障不同的是,其位置区更新成功了,但是也 是耗时 12-13 秒钟(请各位读者也记住这个有趣的数字,稍后会解释为什么是 12-13 秒钟) 。 其 CT 文件中故障点的信令截图如下:

  我们统计 4 月 21 日佛山 RNC03 的 CT 文件,发现总共出现了 27 次“第二种故障” 。 1.3 8-9 秒钟位置区更新失败 在对 CT 文件的分析中,我们还发现一种十分有趣的故障现象,就是存在大量的 8-9 秒 钟位置区更新失败现象,如下图所示:

  我们在针对 4 月 21 日佛山 RNC03 的 CT 文件的分析中,该种故障现象一共出现了 13 次,如下图所示:

  再结合上面的路测 log 文件,也可以看到,UE 并没有接收到 Authentication Request。而 第二次成功的位置区更新则可以清楚地看到 Authentication 的整个过程。

  Authentication Request 是 NAS 层信令,RNC 是应该不做任何处理直接透传给 UE 的, 这两条消息中所包含的信息应该是一致的。而且,这两条信令显示的时间也是应该一样的。 但是我们在上图看到,两条信令之间相差了 113-23=90ms,显然是发生了 RNC 改动 NAS 层消息的动作。这显然是不允许的。 在某次正常的 LAU 流程中,我们可以清楚看到,CN 下发给 RNC 和 RNC 透传给 UE 的 Authentication Request 消息中的 NAS 消息是一样的,而且,两条信令显示的时间也是一 模一样的,如下图所示:

  问题很明显是出在 RNC 身上。我们最终定位“12 秒位置区更新 Reject”故障是由于 RNC 错误修改 NAS 层信令中的所包含的信息造成的。修改过后的 Authentication Request 即 便下发给了 UE,UE 也会因为解码不出来而无法在层三消息中显示,也就是为什么我们在 路测软件的层三消息中无法看到“Authentication Request”信令。 2.2 12-13 秒时延的原因 现在回到上面留给读者的第一个伏笔问题: 为什么从 UE 发起 LAU Request 到收到网络 侧下发 LAU Reject,一般都是 12-13 秒钟左右?我们从 3GPP 24.008 中找到了答案。

  3.1 认证问题 我们在 CT 文件中还发现第二种故障:耗时 12-13 秒钟位置区更新成功。信令截图如下 所示:

  12-13 秒时延的原因 现在回到上面留给读者的第二个伏笔问题: 为什么从 UE 发起 LAU Request 到收到网络 侧下发 LAU Accept, 一般也是 12-13 秒钟左右?我们也是从 3GPP 24.008 中找到了答案。 核 心网中有另一个定时器 T3270。同样,我们在 3GPP24.008 中找到答案,如下图所示:

  4.1 安全模式问题 我们在 CT 文件中还发现了第三种故障:耗时 8-9 秒钟位置区更新失败。异常信令的流 程如下:

  这三种不同特征的位置区更新超长时延故障表现形式相差十分大,但是通过 LAU 正常 信令的对比分析,并结合核心网计数器的研究,基本确定是中兴公司 RNC 的故障。中兴承 认该问题存在并表示尽快升级 RNC 解决。 我们还发现,以上三种故障有一个共同特征,就是在 RRC Connection Request 中的原因 值为:Inter-RAT Cell Reselection。这种原因值根据 3GPP 规范的定义,只会发生在 PS 业务 下的 UE 从 2G 重选回 3G,发起位置区更新的时候。 因此,我们提出一个疑问:为什么以上三种故障情况都发生在 PS 业务下 2G 重选 3G, 发起位置区更新的时候呢?空闲状态下的 2G 重选 3G 是绝不会出现以上三种故障的。这个 问题的研究与解答有待 TD 设备厂家与 2G 核心网厂家一同诊断方能出结果。 这三种不同特征的位置区更新超长时延故障属于全网性的重大问题。此外,我们在其

  它地市(中兴设备)的 CT 文件中,也发现了类似的这三种故障形式,而且发生的比例基本 与佛山发现的相近。这充分证明,这是中兴片区的一个全网性问题,其发现和解决对于提升 中兴片区接通指标与接通感知质量有着不言而喻的重要意义。

本文链接:http://bjj-bg.com/guzhangfenxi/237.html