LTE测试中Ping包时延问题调查分析

1、TD-LTE 测试中 Ping 包时延问题调查分析张 栋摘要选取了 TD-LTE 规模试验中的一个测试用例“单用户 Ping 包时延”的实际测试情况，对测试过程中遇到的问题以及调查分析的经过进行了完整全面的论述，为今后 TD-LTE 测试以及相关领域出现类似问题时能够快速定位和解决提供了参考和借鉴。关键词 TD-LTE Ping 包 时延TD-LTE 规模试验于 3GPP R8 标准的系统设备和 TD-LTE 单 模 终 端 开展测试，从 2010 年底开始到 2011 年第 3 季度结束；第 二阶段主要针 对 基 于 3GPP R9 标准的系统设备和包 含 TD-SCDMA 在内的多模终端开

2、展测试， 从 2011 年 底开始到 2012 年 5 月结束。TD-LTE 规 模试验组网拓扑图如图 1 所 示 ，eNodeB 回传承载采用 PTN+CE 方案。1为了进一步验证 TD-LTE 关键技术、 优化设备性能，促进产品成熟；验证 TD-LTE 系统组网能力、 网络 性能以及业务应用，促进产业链各环节研发和产业化 进展； 推动 TD-LTE 全球部署， 吸引国外运营商采用TD-LTE 技术，同时促进全球有实力的设备制造企业积极参与 TD-LTE 产业， 在工业和信息化部的统一领导 下， 中国移动任组长 、 工业和信息化部电 信 研 究 院 任副组长，中国电信、中国联通及相关系统设备

3、、终端2单用户 Ping 包时延测试总体介绍2.1 测试目的考察单用户在好 / 中 / 差点的 Ping 包时延 （包括 小包 / 大包）。芯片厂商共同开展 TD-LTE 规模技术试验大专项“TD-LTE 规模试验”）测试工作。（即国家重试验总体上分为两个阶段：第一阶段主要针对基测试条件2.2图 2 Ping 包时延端到端示意图系统带宽：20MHz。帧 结 构 ： 上 行 / 下 行 配 置 1 （ 子 帧 配 置 ：DSUUDDSUUD）， 常 规 长 度 CP， 特 殊 子 帧 配 置 7（DwPTS:GP:UpPTS=10:2:2）。天线配置为上行 SIMO 模式；下行 MIMO 模式为

4、 自适应。调度：动态调度。测试区域： 选择一个主测小区 ， 在该小区内进行 测试。2.3 测试步骤步骤 1：初始，邻小区开启，但不加载加扰。步骤 2：测试终端处于主测小区内覆盖“好”点。发送 Ping 包的上行授权（UL grant）。 因此，空口传输时延中包含了 UE 发起调度请求（SR）获取上行授权（UL grant）的时间损耗。 该时间损耗的平均长度直接取决 于 调 度 请 求 （SR） 的 配 置 周 期 ， 并 与 调 度 请 求 （SR） 的 配置周期长度成正比。 当前测试中，调度请求（SR）的 配置周期为 5ms。(2) 随着测试点的空口信道 质 量 逐 渐 变 差 （ 极 好

5、好中差），最大 Ping 时延和平均 Ping 时延应 表现出逐步递增趋势。 具体说明如下：对于空口传输而言 ， 信道质量 越 差 ， 则 发 生 数 据 包重传的可能性越高。 而数据包在空口的重传会对端 到端传输时延造成显著的影响。 因此，随着测试点的 空口信道质量逐渐变差（极好好中差），最大时 延和平均时延应表现出逐步递增趋势。(3) 随着测试点的空口信道 质 量 逐 渐 变 差 （ 极 好好中差），最小 Ping 时延无明显变化趋势。 具 体说明如下：测试统计结果中的最小 Ping 时延取值一般对应 于某次没有发生重传的测试例。 因此，随着测试点的 空口信道质量逐渐变差 （极好好中 差）

6、， 最小 Ping 时延不应有明显的变化趋势。 注：极差点除外，因 为在极差点可能不存在无重传的测试例。(4) 在相同条件 （ 无线信道 条 件 和 SR 配 置 周 期步 骤测试终端接入系统 ， 分 别 发 起3：32Bytes，1500Bytes Ping 包，连续 Ping 100 次。步骤 4：测试终端处于覆盖“中”点、“差”点重复步 骤 3。步骤 5： 采用上下行干扰级别二加扰， 重复步骤24。2.4 理论预期分析(1) 在 SR 配置周期为 5ms 且传输网无明显传输 抖动情况下，32Bytes 包的平均 Ping 时延 （包括极好、 好、中、差测试点）为 24ms 左右（见图 2

7、）。如图 2 所示，Ping 包的端到端时延由 UE 内部处 理时延（平均 6ms 左右）、空口传输时延（平均 12ms 左 右），eNodeB 内部处理时延（4ms 左右）、传输网传输时 延（1ms 左右）和服务器内部处理时延（1ms 左右）组成。 由于在该测试过程中未在空口采用上行预 调 度模式，故 UE 需要首先发起调度请求（SR）以获取用于等）下，1500Bytes 包的 Ping 时延比 32Bytes 包的 Ping时延平均延长 1020ms 左右。具体说明如下：基于资源利用效率的考虑， 由发起 SR 而获得的上 行 授 权 （UL grant） 只 能 承 载 较 小 的 数 据

8、 包 （ 如32Bytes 数据包）。 因此，1500Bytes 数据包需要在空口图 3 Ping 包上下行调度时隙示意图分段传输，进而增大了 1500Bytes 包的 Ping 时延。如图 3 所示，为了发送 1500Bytes 大包，UE 在发送1500Bytes 包的部分数据的同时， 向 eNodeB 发送了用从 PTN CE1 经 PTN 网络环回到 PTN CE2 的网络传输时延。 经过一个周期即 2 个小时的测试得到的结果为 时 延 在 2ms 左 右 。 连 续 挂 表 测 试 24h， 时 延 最 大 为3ms，说明 PTN 承载网和 PTN CE 没有问题。为什么之前 PC

9、Ping 包就会出现明显的时延？ 经过 分析，我们怀疑可能是之前用于测试的 PC 本身硬件或 者软件问题引起的。 为了排除测试 PC 本身的问题，我 们找来两台全新的笔记本电脑， 除了预装 WindowsXP 操作系统没有安装其他任何应用软件， 为了确保测试 工具和测试方法绝没有问题， 我们把两台笔记本电脑 用网线对接进行了 12h 的互 Ping 测试，结果 Ping 包时 延全部是 0ms（小于 1ms）。 接下来，我们用这两台验证 没有问题的笔记本电脑连入 PTN 网络进行了 Ping 包 测 试 ， 经 过 12h 测 试 结 果 如 下 ： “ 数 据 包 ： 已 发 送 =7320

10、3，已接收 = 73201，丢失 = 2 (0%丢失)，往返行程的 估计时间（以 ms 为单位）：最短 = 1ms，最长 = 192ms，平 均 = 11ms”。为了更加直观地反映测试结果， 我们对数据做了 处理（由于时间太长分成 3 段），如图 5 所示，可以清楚 地看到 PC Ping 包测试过程中的时延抖动非常明显。因此， 需要分析 PC Ping 包测试和挂表测试到底于 请 求 后 续 上 行 授 权 （UL grant） 的status report）。BSR （Buffer3单用户 Ping 包时延测试中的问题与调查分析3.1 问题现象及排查经过在进行单用户 Ping 包时延实际测

11、试中发现在某 些时段会发生时延较长， 有时甚至会出现超过 100ms 的情况，与理论预期不符。经过逐级排查，当我们在 eNodeB 站点上通过 PC 连接 ODF 架对 PTN CE 进行 Ping 包试验， 如图 4 所 示， 完 全 隔 离 eNodeB 和 EPC 设 备 ， 发现在某些时段 时 延 很 大 ，Ping 包时延几十毫秒不等 ， 甚 至 有 超 过100ms 的情况，说明超长时延的产生和 PTN 承载网络 或者 PTN CE 相关。我们立即联系了 PTN 厂 家 协 助 排 查 ，PTN 厂 家 通过挂表测试了 PTN 传输时延：即通过测试仪表测试图 5 PC Ping 包

12、测试时延分布图有什么不同，会造成两种完全不同的测试结果。 经过仔 细 分析发现挂表测试时有一定的 背 景数据流 ， 而 PC Ping 包测试时是没有背景数据流的，为此我们分别 就有背景数据流和没有背景数据流的情况下分别进 行了挂表测试以及 PC Ping 包测试，如图 6 所示。 测试 结果如下：(1) 仪表发起每秒一个包的业务流， 从 PTN 接入 层到核心层，环回后回到仪表， 时延约为 2ms， 平均抖 动约为 35s。起 10Mbit/s 背景流情况下， 仪表对 Ping 抖动为 13ms左右， 抖动较大，PC 对 Ping 不稳定， 出现几十毫秒大时延。仪表发起 10Mbit/s 背

13、景流情况下， 仪表对 Ping和 PC 对 Ping 均与 12h，24h 长时间测试结 果一致 ， 均为 1ms 左右时延。 仪表不发起背景流 ， 但 存 在 其 他eNodeB 的背景流量 （4Mbit/s 左右） 的情况下， 时 延 约15ms。以 上 结 果 表 明 Ping 包时延问题出在 PTN CE 设 备上，且是否有背景数据流量对 Ping 包时延有较大影 响，数据流量越大 Ping 报时延越小。(2) 从 PTN 接入层到 PTN CE 设备，在仪表不发图 6 PTN 网络挂表测试示意图图 7 Ethernet II 以太帧报文格式图 8 IEEE802.3 以太帧报文格式问

14、题原因分析(1) 丢弃处理，即识别到此类非法报文， 将其直接丢弃，同时需要保证不引起系统异常。(2) 转发处理，即识别到此类非法报， 依然进行各3.2类 L2/L3/MPLS 等转发操作，异常。同样要保证不引起系统不同设备、 不同芯片由于 自 身 的 特 点 ， 可 能 会 有选择地采用上述中的方式（1）或者方式（2）。PTN CE 设备内部 FPGA 采用方式（2） 处理， 但处 理有问题，具体说明如下：FPGA 可以分成两个大的功能模块：MAC 和逻辑 处理单元。 当 FPGA MAC 收到 Etype/Elength 小于 46但 填充有 pad 的报文时，其将 pad 剥除，而将报文净

15、荷发 送给 FPGA 逻辑。 此时 FPGA 由于无法获知 MAC 是否 对原始报文做过 pad 剥 离 操 作 ， 因 此 统 一 按 照 Etype/Elength 值来计算报文的实际长度。 由于 FPGA 未能正确地对内部产生的 Etype 小于 46 但未填充 pad 的报文进行识别并处理， 导致其在此类内部产生的非经过 PTN 厂家实验室大量模拟以及分析，终于找到了问题的原因。以太网标准分为两类：第一类由 RFC894 定义，通 常称之为 Ethernet II 以太帧，其报文格式见图 7。法报文处理中出现逻辑异常。在这种情况下，FPGA 内部状态机就会处于异常状态， 一种可能的表现

16、形式就是出现压包现象。 当产生此类现象时，FPGA 收到一个 报文时，并不能立即转发出去，而是依赖于下一个（或 下几个）报文进行触发才能转发出去。 此时，报文发送 时延就主要取决报文 之间的时间间隔以及压包的数 量，也即发包速率快则时延就小，而发包速率慢则时延 就大。第二类由 RFC1042 定义， 通常称之为 IEEE802.3以太帧，其报文格式见图 8。单用户 Ping 包时延测试结果4问题找到后 PTN 厂家提供了解决方案： 在 PTNCE 设备的 FPGA 中正确地采用方式（1）对 Etype 小于46 但未填充 pad 的报文进行识别并处理。 之后我们进 行 了 “ 单 用 户 Pi

17、ng 包 时 延 ” 测 试 ， 测试结果符合预期 （见表 1，表 2）。单用户空扰 Ping 32Bytes 包的各测试点平均时延 分别为：极好点 20ms，好点 23.3ms，中点 20.2ms，差点21.9ms，均符合 24ms 的预期。 单用户加扰 Ping 32Bytes包的各测试点平均时延分别为 ： 极好点 18ms， 好点19ms，中点 26.5ms，差点 23.4ms，总体略大于对应的空 扰测试统计结果。从测试结果可以得出以下基本结论：两者最主要的区别在于 ： 前 者 定 义 2 个 字 节 的Etype （ 以 太 报 文 类 型 ）， 而 后 者 则 定 义 2 个 字 节

18、 的 Elength（以太报文长度），当这个 2 字节取值大于 1500 字节时，则表示其为 Etype，也即 Ethernet II 以太帧； 而 小 于 或 等 于 1500 字 节 时 ， 则 代 表 Elength， 也 即 IEEE802.3 以太帧。无论是 Ethernet II 还是 IEEE802.3 均要求以太报 文总帧长不小于 64 字节，因此，若实际传输的有效数 据小于 46 字节，则需要将其补齐到 46 字节。 当 Etype 字 段 或 Elength 字 段 取 值 小 于 46 并且没有将报文填 充至 64 字节时， 此类报文为 非 法 ， 对 于 此 类 报 文 ， 有表 1 空扰单用户 Ping 包测试结果表 2 加扰单用户 Ping 包测试结果(1) 用户面的 Ping 包延迟明显地受到了数据包长度和无线射频状况的影响，UE 远离基站，无线射频状 况变的糟糕，以至于延迟更加的