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

. . . TD-LTE测试中Ping包时延问题调查分析张 栋摘 要选取了 TD-LTE 规模试验中的一个测试用例“单用户 Ping 包时延”的实际测试情况，对测试过程中遇到的问题以及调查分析的经过进行了完整全面的论述，为今后 TD-LTE 测试以及相关领域出现类似问题时能够快速定位和解决提供了参考和借鉴关键词 TD-LTE Ping 包 时延TD-LTE 规模试验于 3GPP R8 标准的系统设备和 TD-LTE 单 模 终 端 开展测试，从 2010 年底开始到 2011 年第 3 季度结束；第 二阶段主要针 对 基 于 3GPP R9 标准的系统设备和包 含 TD-SCDMA 在内的多模终端开展测试， 从 2011 年 底开始到 2012 年 5 月结束TD-LTE 规 模试验组网拓扑图如图 1 所 示 ，eNodeB 回传承载采用 PTN+CE 方案1为了进一步验证 TD-LTE 关键技术、 优化设备性能，促进产品成熟；验证 TD-LTE 系统组网能力、 网络 性能以及业务应用，促进产业链各环节研发和产业化 进展； 推动 TD-LTE 全球部署， 吸引国外运营商采用TD-LTE 技术，同时促进全球有实力的设备制造企业积极参与 TD-LTE 产业， 在工业和信息化部的统一领导 下， 中国移动任组长 、 工业和信息化部电 信 研 究 院 任副组长，中国电信、中国联通及相关系统设备、终端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 模式为 自适应调度：动态调度测试区域： 选择一个主测小区 ， 在该小区内进行 测试2.3 测试步骤步骤 1：初始，邻小区开启，但不加载加扰步骤 2：测试终端处于主测小区内覆盖“好”点发送 Ping 包的上行授权（UL grant） 因此，空口传输时延中包含了 UE 发起调度请求（SR）获取上行授权（UL grant）的时间损耗 该时间损耗的平均长度直接取决 于 调 度 请 求 （SR） 的 配 置 周 期 ， 并 与 调 度 请 求 （SR） 的 配置周期长度成正比 当前测试中，调度请求（SR）的 配置周期为 5ms2) 随着测试点的空口信道 质 量 逐 渐 变 差 （ 极 好→ 好→中→差），最大 Ping 时延和平均 Ping 时延应 表现出逐步递增趋势。

具体说明如下：对于空口传输而言 ， 信道质量 越 差 ， 则 发 生 数 据 包重传的可能性越高 而数据包在空口的重传会对端 到端传输时延造成显著的影响 因此，随着测试点的 空口信道质量逐渐变差（极好→好→中→差），最大时 延和平均时延应表现出逐步递增趋势3) 随着测试点的空口信道 质 量 逐 渐 变 差 （ 极 好→好→中→差），最小 Ping 时延无明显变化趋势 具 体说明如下：测试统计结果中的最小 Ping 时延取值一般对应 于某次没有发生重传的测试例 因此，随着测试点的 空口信道质量逐渐变差 （极好→好→中→ 差）， 最小 Ping 时延不应有明显的变化趋势 注：极差点除外，因 为在极差点可能不存在无重传的测试例4) 在相同条件 （ 无线信道 条 件 和 SR 配 置 周 期步 骤测试终端接入系统 ， 分 别 发 起3：32Bytes，1500Bytes Ping 包，连续 Ping 100 次步骤 4：测试终端处于覆盖“中”点、“差”点重复步 骤 3步骤 5： 采用上下行干扰级别二加扰， 重复步骤2～42.4 理论预期分析(1) 在 SR 配置周期为 5ms 且传输网无明显传输 抖动情况下，32Bytes 包的平均 Ping 时延 （包括极好、 好、中、差测试点）为 24ms 左右（见图 2）。

如图 2 所示，Ping 包的端到端时延由 UE 内部处 理时延（平均 6ms 左右）、空口传输时延（平均 12ms 左 右），eNodeB 内部处理时延（4ms 左右）、传输网传输时 延（1ms 左右）和服务器内部处理时延（1ms 左右）组成 由于在该测试过程中未在空口采用上行预 调 度模式，故 UE 需要首先发起调度请求（SR）以获取用于等）下，1500Bytes 包的 Ping 时延比 32Bytes 包的 Ping时延平均延长 10～20ms 左右具体说明如下：基于资源利用效率的考虑， 由发起 SR 而获得的上 行 授 权 （UL grant） 只 能 承 载 较 小 的 数 据 包 （ 如32Bytes 数据包） 因此，1500Bytes 数据包需要在空口图 3 Ping 包上下行调度时隙示意图分段传输，进而增大了 1500Bytes 包的 Ping 时延如图 3 所示，为了发送 1500Bytes 大包，UE 在发送1500Bytes 包的部分数据的同时， 向 eNodeB 发送了用从 PTN CE1 经 PTN 网络环回到 PTN CE2 的网络传输时延 经过一个周期即 2 个小时的测试得到的结果为 时 延 在 2ms 左 右 。

连 续 挂 表 测 试 24h， 时 延 最 大 为3ms，说明 PTN 承载网和 PTN CE 没有问题为什么之前 PC Ping 包就会出现明显的时延？ 经过 分析，我们怀疑可能是之前用于测试的 PC 本身硬件或 者软件问题引起的 为了排除测试 PC 本身的问题，我 们找来两台全新的笔记本电脑， 除了预装 WindowsXP 操作系统没有安装其他任何应用软件， 为了确保测试 工具和测试方法绝没有问题， 我们把两台笔记本电脑 用网线对接进行了 12h 的互 Ping 测试，结果 Ping 包时 延全部是 0ms（小于 1ms） 接下来，我们用这两台验证 没有问题的笔记本电脑连入 PTN 网络进行了 Ping 包 测 试 ， 经 过 12h 测 试 结 果 如 下 ： “ 数 据 包 ： 已 发 送 =73203，已接收 = 73201，丢失 = 2 (0%丢失)，往返行程的 估计时间（以 ms 为单位）：最短 = 1ms，最长 = 192ms，平 均 = 11ms”为了更加直观地反映测试结果， 我们对数据做了 处理（由于时间太长分成 3 段），如图 5 所示，可以清楚 地看到 PC Ping 包测试过程中的时延抖动非常明显。

因此， 需要分析 PC Ping 包测试和挂表测试到底于 请 求 后 续 上 行 授 权 （UL grant） 的status report）BSR （Buffer3 单用户 Ping 包时延测试中的问题与调查分析3.1 问题现象及排查经过在进行单用户 Ping 包时延实际测试中发现在某 些时段会发生时延较长， 有时甚至会出现超过 100ms 的情况，与理论预期不符经过逐级排查，当我们在 eNodeB 站点上通过 PC 连接 ODF 架对 PTN CE 进行 Ping 包试验， 如图 4 所 示， 完 全 隔 离 eNodeB 和 EPC 设 备 ， 发现在某些时段 时 延 很 大 ，Ping 包时延几十毫秒不等 ， 甚 至 有 超 过100ms 的情况，说明超长时延的产生和 PTN 承载网络 或者 PTN CE 相关我们立即联系了 PTN 厂 家 协 助 排 查 ，PTN 厂 家 通过挂表测试了 PTN 传输时延：即通过测试仪表测试图 5 PC Ping 包测试时延分布图有什么不同，会造成两种完全不同的测试结果 经过仔 细 分析发现挂表测试时有一定的 背 景数据流 ， 而 PC Ping 包测试时是没有背景数据流的，为此我们分别 就有背景数据流和没有背景数据流的情况下分别进 行了挂表测试以及 PC Ping 包测试，如图 6 所示。

测试 结果如下：(1) 仪表发起每秒一个包的业务流， 从 PTN 接入 层到核心层，环回后回到仪表， 时延约为 2ms， 平均抖 动约为 35μs起 10Mbit/s 背景流情况下， 仪表对 Ping 抖动为 13ms左右， 抖动较大，PC 对 Ping 不稳定， 出现几十毫秒大时延仪表发起 10Mbit/s 背景流情况下， 仪表对 Ping和 PC 对 Ping 均与 12h，24h 长时间测试结 果一致 ， 均为 1ms 左右时延 仪表不发起背景流 ， 但 存 在 其 他eNodeB 的背景流量 （4Mbit/s 左右） 的情况下， 时 延 约1～5ms以 上 结 果 表 明 Ping 包时延问题出在 PTN CE 设 备上，且是否有背景数据流量对 Ping 包时延有较大影 响，数据流量越大 Ping 报时延越小2) 从 PTN 接入层到 PTN CE 设备，在仪表不发图 6 PTN 网络挂表测试示意图图 7 Ethernet II 以太帧报文格式图 8 IEEE802.3 以太帧报文格式问题原因分析(1) 丢弃处理，即识别到此类非法报文， 将其直接丢弃，同时需要保证不引起系统异常。

2) 转发处理，即识别到此类非法报， 依然进行各3.2类 L2/L3/MPLS 等转发操作，异常同样要保证不引起系统不同设备、 不同芯片由于 自 身 的 特 点 ， 可 能 会 有选择地采用上述中的方式（1）或者方式（2）PTN CE 设备内部 FPGA 采用方式（2） 处理， 但处 理有问题，具体说明如下：FPGA 可以分成两个大的功能模块：MAC 和逻辑 处理单元 当 FPGA MAC 收到 Etype/Elength 小于 46但 填充有 pad 的报文时，其将 pad 剥除，而将报文净荷发 送给 FPGA 逻辑 此时 FPGA 由于无法获知 MAC 是否 对原始报文做过 pad 剥 离 操 作 ， 因 此 统 一 按 照 Etype/Elength 值来计算报文的实际长度 由于 FPGA 未能正确地对内部产生的 Etype 小于 46 但未填充 pad 的报文进行识别并处理， 导致其在此类内部产生的非经过 PTN 厂家实验室大量模拟以及分析，终于找。