【原】LTE网络时延优化案例

daju1000 2023-02-04 发布于河北

展开全文

【摘要】LTE系统相比其它通讯系统，结构更加精简。从协议已发布一些指标来看，时延相比其它系统有较大改善。比如协议要求控制面时延小于100ms，用户面(小包)时延小于10ms。用户也比较关注时延，用户面ping包时延指标往往作为单站验收的KPI指标之一。

【关键字】LTE系统 ping包时延

【业务类别】移动网

一、问题描述

西南区五四路国家电网基站H-0开通后，单站测试验收，ping包时延超过30ms不达标，通过在基站网管侧ping传输网关和核心网XGW，发现ping传输网关平均时延为0ms，但是ping核心网XGW平均时延为11ms，比正常值1ms多了10ms。

二、分析过程

1、基本原理

做ping时延测试，一般是在连接终端UE的笔记本电脑上面进行ping包，为了排除外网时延的影响，一般采用pingFTP内网服务器IP地址的方式。

完整的ping包流程见下面流程图如下：

上面的流程分步骤介绍如下:

1.在连接终端UE的笔记本电脑上面进行ping包，ping包命令从高层应用软件到UE底层过程中，典型时延为2~3ms，不同终端不同笔记本电脑的性能是不同的。

2.当终端UE发生上行数据的时候，需要首先发送SR(Scheduling Request)申请上行资源。但是SR发送是有周期性要求的。例如当SR周期默认配置为10ms时，SR发送等待时延可能是1-10ms，平均时延5ms。

3.UE发起PUCCH Tx Report消息Fomat=1 携带调度请求SR消息给eNodeB；下面是一个信令样例(系统帧号SFN:915，子帧号SF:2)：

4. eNodeB 回复PDCCH DCI0消息进行，上行授权；下面是一个信令样例(子帧号系统帧号: 915，子帧号: 5) ：

5. UE发起PUSCH Tx Report消息，携带PING包请求，在加上包头等信息后实际包大小PUSCH TB Size(bytes)= 1692；在MAC层也可以看到发送了一个64bytes的UL Transport Block。注意这里的流程省略了BSR申请过程，是因为ping包默认调度方式采用基于收到SR置大的模拟BSR模式(1)，详细介绍见4.2.1.1章节。下面是信令样例(系统帧号SFN:915,子帧号SF:9)。

6.基站内部处理总时延是6ms，包括接收ping包2ms和发送ping包4ms；

7.从eNodeB到EPC的S1口时延以及EPC到FT P server的时延，典型值小于1ms。但是有些商用局eNodeB与EPC的距离非常远，会导致S1口时延偏大。

8.eNodeB回复PDCCHDCI1A消息携带PING包结果。在MAC层也可以看到发送了一个64bytes的DL Transport Block。LTE PDSCH Stat Indication是高通终端UE自己内部消息，不发给eNodeB，CRC Result=Pass表示ping包正常。

下面是信令样例(系统帧号SFN:917，子帧号SF:5，注意这个例子中S1口时延为10ms)

9.ping包响应从UE底层到高层应用软件过程中，典型时延为2~3ms，不同终端不同笔记本电脑的性能是不同的。

从上面流程图中可以看到，一个典型的ping时延为19~30ms。

2、ping测试问题的分析思路

由于ping包测试电脑和测试终端UE的影响不可控，排除这这个因素后，需要重点分析PING环回时延的空口时延和传输时延两部分。当测试得到的环回时延较大时，甚至不能病足局方的PING包测试指标要求时，需要将ping时延分解成下面两部分单独进行分析:

无线空口时延，即UE和eNodeB间的交互时延(第2章ping包流程图中除第7步外的2-8步)，传输侧交互时延(第2章ping包流程图中的第7步)。

分解为两部分统计环回时延的8的是判断上时延较大的原因是由空口造成还是传输引起的。如果空口时延较大，则需要从调度算法上考虑优化，这块由版本和无线参数来保证若化输时延较长，那就是非接入层的原因，可以从基站侧ping EPC 或PINGFTP服务器来确认是否受到传输网络的影响，确认是传输的问题，需要请传输侧工程师协调解决。

①无线空口时延分析方法

无线空口时延，即UE和eNodeB间的交互时延对应第2章ping包流程图中除第7步外的2~8步，这部分的时延主要受基站无线参数设置及无线环境的影响。主要分析方法是通过QXDM或者其他测试工具在终端UE侧进行抓log分析，与第2章ping包流程图中每--步的标准时延进行对比，如果有时延差异的话就需要对相关信令

②流程和无线参数进行分析定位。

影响ping时延的无线参数影响ping时延的无线参数主要有3类，分别介绍如下。

ping包调度模式：FDD LTE V3系列版本BPL1单板的ping包具有5种调度模式，见DV参数表

调度参数--用户面时延优化类型: ( 解要注意的是DV参數属于系统内部参数，在网问题分类定界方法最终定位问题原因等。

●动态调度 (0)

●基于收到SR置大的模拟BSR模式(1)

●混合调度模式(2)

●增强型混合调度模式 (3)

●基于预调度模式(4)

BPL1单板的ping包调度模式参见下面截图：

BPL0单板的ping包时延具有3中调度模式，见DV参数表中V2调度参数- -ping包

优化开关: .

●基于收到SR置大的模拟BSR模式Large-TB-based Dynamic Schedule(0)

●混合调度Hybrid Schedule(1)

●动态调度Dynamic Schedule(2)

BPL0单板的ping包调度模式参见下面截图：

商用局配置策略说明: (下面介绍的时延都是指 ping 32Byte，并且S1口时延小于1ms时的结果)

1.目前V3.10.20系列版本默认DV参数配置为:基于收到SR置大的模拟BSR模式(1)，对于Ping Latency验收标准要求小于30ms的商用局，如果没有与其他厂家的PK要求，可以采用默认参微配置:基于收到SR置大的模拟BSR模式(1)

2. 对于Ping Latency验收标准要求小于20ms的商用局，如果BPL单板类型是BPL1，可以将此参数修改为:增强型混合调度模式(3)

3.由于目前V3.10.20P02系列版本还不支持基于BPL0的增强型混合调度，如果有商用局要求Ping Latency验收标准要求小于20ms或者与对于有KPI PK压力，需要反馈需求到研发进行开发。

4.已经规模放号的商用局，不建议采用混合调度模式(2)

Ping包时延5种调度模式具体介绍如下:

1.动态调度

对于当前LTE FDD 系统，动态调度未打开ping包优化开关条件下，Ping包过

程及各段时延分析如下图所示：

正常的动态调度模式下，当UE的MAC层收到高层的上行业务请求，会触发一个SR ( Schedule Request) 请给给eNodeB, eNodeB收到响应后，发送一个小的上行授权，UE用来报告BSR (Buffer Status Report,用来告诉基站有多少数据需要发送)。eNodeB收到BSR之后，根据BSR给UE.上行授权，UE使用该授权发上行的PING的内容， PING的数据就发送到基站侧。

从流程和系统能力上分析，动态调度未打开ping包优化开关条件下，理论上ping Latency 大概在22.5ms左右，加上SR调度时间长度，假设SR周期配置10ms的条件下，动态调度理论上ping Latency应该在22.5-32.5ms左右。

2.基于收到 SR置大的模拟BSR模式

FDD LTE 日前版本默认设置的模式。其基本原理是基于SR上报，根据前一一个TTI需要调度的UE个数，eNB主动下发- -个较大的上行资源，使得UE可以利用该资源发送上行数据，减少了UE发送BSR然后eNB根据BSR进行调度的流程。假设SR周期配置10ms的条件下，基于收到SR置大的模拟BSR模式理论上ping Latency应该在18.5-28.5ms。

3.混合调度模式

混合调度模式是在预调度持续时间内，定时主动向UE发送上行资源，UE利用该资源发送上行数据。由于基站是周期性的对UE分配上行资源，减少了UE发送SR的流程，因此使得PING包的时延缩矩。具体为: UE 发送SR请求，基站检测到SR后，产生虚拟的BSR进行正常的调度处理，启动预调度周期PingPreSchPeriodTimer (默认5ms)和预调度持续时间PingPreSchHoldTimer(默认2048ms);在PingPreSchHoldTimer超时前，每隔PingPreSchPeriodTimer基站主动产生虚拟BSR并进行调度: UE利用预调度的资源发送PING包的上行数据和可能的BSR。

混合调度模式对所有的SR均做同样的处理，如果商月系统中用户量较大，大量的上行资源预投权将导改基站反向干扰加重，严重影响基站反向解调性能。商用局环境下不建议采用这种模式。混合调度模式ping包时延在15~20ms。

4.增强型混合调度模式

为了避免混合调度模式带米的负面影响，增強型混台调度模式能够PING的业务进行识别，识别出PING业务的周期和大小之后，仅仅在PING的周期到来时，给一定长度及相应大小的预授权即可。这样能大大减缓预授权带米的带宽损失，可提升上行的有效载荷。增强型混合调度模式与混合调度模式相同，ping 包时延在15~ 20ms.

5. 基于预调度模式

预调度模式下，UE直接发送ping包，没有SR及BSR预授权协商过程，这种模式只能用于单用户实验室测试，是无法商用的。预调度模式下的埋论PING时延在9~12ms。