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

张 栋

摘 要 选取了

TD-LTE 规模试验中的一个测试用例“单用户

P i ng

包时延”的实际测试情况，

对测试过程中遇到的问题以及调查分析的经过进行了完整全面的论述，为今后 TD-LTE 测试以及

相关领域出现类似问题时能够快速定位和解决提供了参考和借鉴。

关键词 TD-LTE P i ng 包 时延

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 测试目的

考察单用户在好 / 中 / 差点的 P i ng 包时延 （包括 小包 / 大包）。 芯片厂商共同开展 TD-LTE 规模技术试验 大专项“TD-LTE 规模试验”）测试工作。

（即国家重 试验总体上分为两个阶段：第一阶段主要针对基

测试条件

2.2 TD-LTE 测试中 Ping 包时延问

题调查分析

系统带宽：20M H z。

帧结构：上行/ 下行配置 1 （子帧配置：D S UUDD S UUD），常规长度CP，特殊子帧配置7（Dw P TS:G P:U p P TS=10:2:2）。

天线配置为上行SIMO 模式；下行MIMO 模式为自适应。

调度：动态调度。

测试区域：选择一个主测小区，在该小区内进行测试。

2.3 测试步骤

步骤1：初始，邻小区开启，但不加载加扰。

步骤2：测试终端处于主测小区内覆盖“好”点。发送P i ng包的上行授权（UL grant）。因此，空口传输时延中包含了UE 发起调度请求（S R）获取上行授权（U L g r a n t）的时间损耗。该时间损耗的平均长度直接取决于调度请求（S R）的配置周期，并与调度请求（S R）的配置周期长度成正比。当前测试中，调度请求（S R）的配置周期为5m s。

(2) 随着测试点的空口信道质量逐渐变差（极好→好→中→差），最大P i ng时延和平均P i ng时延应表现出逐步递增趋势。具体说明如下：

对于空口传输而言，信道质量越差，则发生数据包重传的可能性越高。而数据包在空口的重传会对端到端传输时延造成显著的影响。因此，随着测试点的空口信道质量逐渐变差（极好→好→中→差），最大时延和平均时延应表现出逐步递增趋势。

(3) 随着测试点的空口信道质量逐渐变差（极好→好→中→差），最小P i ng时延无明显变化趋势。具体说明如下：

测试统计结果中的最小P i ng时延取值一般对应于某次没有发生重传的测试例。因此，随着测试点的空口信道质量逐渐变差（极好→好→中→差），最小P i ng时延不应有明显的变化趋势。注：极差点除外，因为在极差点可能不存在无重传的测试例。

(4) 在相同条件（无线信道条件和SR 配置周期

步骤测试终端接入系统，分别发起3：

32B y t e s，1500B y t e s P i ng包，连续P i ng100 次。

步骤4：测试终端处于覆盖“中”点、“差”点重复步骤3。

步骤5：采用上下行干扰级别二加扰，重复步骤2～4。

2.4 理论预期分析

(1) 在SR 配置周期为5ms 且传输网无明显传输抖动情况下，32B y t e s包的平均P i ng时延（包括极好、好、中、差测试点）为24ms 左右（见图2）。

如图2 所示，P i ng包的端到端时延由UE 内部处理时延（平均6ms 左右）、空口传输时延（平均12ms 左右），e N od e B内部处理时延（4m s左右）、传输网传输时

延（1ms 左右）和服务器内部处理时延（1m s左右）组成。

由于在该测试过程中未在空口采用上行预调度模式，故UE 需要首先发起调度请求（S R）以获取用于等）下，1500B y t e s包的P i ng时延比32Bytes 包的P i ng 时延平均延长10～20ms 左右。具体说明如下：基于资源利用效率的考虑，由发起SR 而获得的上行授权（UL grant）只能承载较小的数据包（如32Bytes 数据包）。因此，1500B y t e s数据包需要在空口

图2 Ping 包时延端到端示意图

分段传输，进而增大了1500Bytes 包的P i ng时延。

如图3 所示，为了发送1500Bytes 大包，U E在发送1500Bytes 包的部分数据的同时，向eNodeB 发送了用从PTN CE1 经PTN 网络环回到PTN CE2 的网络传输时延。经过一个周期即2 个小时的测试得到的结果为时延在2ms 左右。连续挂表测试24h，时延最大为3m s，说明PTN 承载网和P TN CE 没有问题。

为什么之前P C P i ng包就会出现明显的时延？经过分析，我们怀疑可能是之前用于测试的PC 本身硬件或者软件问题引起的。为了排除测试PC 本身的问题，我们找来两台全新的笔记本电脑，除了预装W i ndo w s X P 操作系统没有安装其他任何应用软件，为了确保测试工具和测试方法绝没有问题，我们把两台笔记本电脑用网线对接进行了12h 的互P i ng测试，结果P i ng包时延全部是0m s（小于1ms）。接下来，我们用这两台验证没有问题的笔记本电脑连入PTN 网络进行了P i ng包测试，经过12h 测试结果如下：“数据包：已发送= 73203，已接收=73201，丢失=2 (0%丢失)，往返行程的估计时间（以ms 为单位）：最短=1m s，最长=192m s，平均=11m s”。

为了更加直观地反映测试结果，我们对数据做了处理（由于时间太长分成3 段），如图5 所示，可以清楚地看到P C P i ng包测试过程中的时延抖动非常明显。

因此，需要分析PC P i ng包测试和挂表测试到底

于请求后续上行授权（UL grant）的

s t a t u s r e po r t）。

BSR （B u ff e r

3 单用户Ping 包时延测试中的问题与调查

分析

3.1 问题现象及排查经过

在进行单用户P i ng包时延实际测试中发现在某

些时段会发生时延较长，有时甚至会出现超过100m s

的情况，与理论预期不符。

经过逐级排查，当我们在eNodeB 站点上通过P C

连接ODF 架对PTN CE 进行P i ng包试验，如图4 所

示，完全隔离eNodeB 和EPC 设备，发现在某些时段

时延很大，P i ng包时延几十毫秒不等，甚至有超过

100ms 的情况，说明超长时延的产生和PTN 承载网络

或者P TN CE 相关。

我们立即联系了PTN 厂家协助排查，P TN厂家

通过挂表测试了PTN 传输时延：即通过测试仪表测试

图3 Ping 包上下行调度时隙示意图