一、 问题描述
近期收到阳光花园小区5G用户投诉，该用户投诉使用5G时玩王者荣耀时延在150ms以上，时延过高导致卡顿明显，感知较差：
2.1 RTT时延
RTT(Round-Trip Time): 往返时延。在网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。
在时延分析中提到过的系统处理时间在时延中所占的分量比较大，而且改善较为不易。这部分时延包括了接收包，获取控制信息，调度信息，解调数据，以及错误检测。在4G LTE中传输的信息分为三部分，导频信息（Pilot），控制信息（control information），以及数据（data）。
4G LTE采用Turbo和Simple code来编解码数据达到无线传输的可靠性。在5G中使用的是LDPC和Polar码来提升数据和控制信道的编解码效率，编解码的性能和计算复杂度的提升对于降低时延也有所帮助。
从更短的时间间隔这点说5G是天然优势一点都不为过，LTE规定的一个子载波(传送信息的最小频域单位)是15KHz，时间域是1ms （正常情况下）。
5G所需要支持的频率范围非常广，中低频从450MHz~6000MHz（FR1），高频从24.25GHz~52.6GHz（FR2）。高频意味着更高的相位噪声，所以需要设计更加宽的子载波间隔来抵御相位噪声的干扰。更宽的子载波间隔，意味着时域上更短的时隙，更短的传输时间间隔，我们在4G LTE时代千方百计想要降低的传输时间间隔在5G时代只需要使用更高的频段，更宽的子载波间隔就轻而易举的降低了。而且根据不同的频段可以选择从15KHz, 30KHz 到120KHz的子载波间隔，可以简单的理解为，5G 子载波间隔相比于LTE 15KHz增加了多少倍，那么在时域上的传输时间间隔就减少相应的倍数。频域子载波间隔成倍增加，时域符号时长相应倍数减少。
微时隙调度继承了LTE中减小传输时间间隔(subslot)的设计理念，将最小的传输时间间隔由子帧拓展到了符号上。第一优先级最小的调度间隔根据情况可以选择2个符号，4个符号，7个符号。
当无线环境出现问题等原因造成传输的数据出错，在MAC层会由HARQ功能来发起重新传输流程，在LTE中，HARQ的时间间隔（从收到数据到发送反馈给发送方是否正确接收信息指令）是固定的（FDD，TDD根据子帧结构变化）。
而在5G中，HARQ的时间间隔是动态指派的，更加的灵活，也符合低时延的设计要求。
5G与4G HARQ流程时间对比：
图 2‑1：5G与4G HARQ流程时间对比
和4G LTE一样，5G可以周期性的给用户分配上行资源（半静态调度）来减少上行的传输时延，而且5G更加进了一步。在4G中半静态调度的资源一般是给每个用户单独分配的，所以当网络中用户较多的时候，造成的浪费是非常大的，因为预留的无线资源终端不一定会使用。
在5G中可以将预留资源分配给一组终端用户，并且设计了当多个用户同时在相同的无线资源上发生冲撞的解决机制。这样在降低时延的同时使宝贵的无线资源的利用率也得到了保证。
图 2‑2:5G上行免调度传输type1和type2
通过这样的方式达到了对时间延迟要求高的用户可以立即传输数据，从而降低了时延。下图是一个示例：
用户A已经在一个时隙上被调度了数据，但是这时用户B被标记为对时延要求高的数据需要传输。
如果这时有空闲的时频域资源可用，用户B会被优先调度空闲的资源
但是如果此时网络负荷较大，没有空闲的资源可用，用户B就会抢占其他用户的（例如用户A）的资源。
这种方式有个弊端就是会影响原本被分配资源的A的用户的数据传输（在被用户B抢占的资源上），当然优秀的5G系统也设计了方案来解决这个问题，方式有：HARQ重传用户A受影响的传输数据，或者是直接通过控制信令（DCI2-1）通知用户A，哪些传输的数据受到了影响。
图 2‑3:预清空调度
RLC层主要负责RLC数据的切分，重复数据去除，RLC重传的工作。
在RLC层中关于低时延的技术考量主要体现在：在4G LTE中RLC层还需要负责保证数据的按顺序传递（In-sequence delivery），即前面的包没有向上层传递之前，排在后面的包需要等待。在5G中去掉了这样的功能要求来保障低时延水平。这样做的好处是，如果之前有某些包因为某些原因（例如无线环境突然变差）丢失了需要重传，在5G中后面的包不需要等到前面的包重传完毕就可以直接向上层传递。
图 2‑4：双向延迟
通过使用30KHz的子载波间隔，上行免调度，以及两个符号的微时隙的5G系统配置方案，可以达到低于双向时延1ms以下的要求。如果采用5G高频通信，使用120KHz的子载波间隔，时延可以更低。
影响时延的无线参数主要有3类，分别介绍如下。
1
2
3
3.1
3.2
3.3
多元域编码的设计动态调度（0）
基于收到SR置大的模拟BSR模式（1）
混合调度模式（2）
增强型混合调度模式（3）
基于预调度模式（4）
VSWc2单板的时延具有3中调度模式，见DV参数表中V2调度参数---优化开关：
基于收到SR置大的模拟BSR模式 Large-TB-based Dynamic Schedule(0)
混合调度 Hybrid Schedule(1)
动态调度 Dynamic Schedule(2)
图 3‑1：时延优化类型
时延5种调度模式具体介绍如下：
第一种 动态调度
对于当前5G系统，动态调度未打开优化开关条件下，过程及各段时延分析。
图 3‑2：调度过程
过程（动态调度）
正常的动态调度模式下，当UE的MAC层收到高层的上行业务请求，会触发一个SR（Schedule Request）请给给基站，基站收到响应后，发送一个小的上行授权，UE用来报告BSR（Buffer Status Report,用来告诉基站有多少数据需要发送）。基站收到BSR之后，根据BSR给UE上行授权，UE 使用该授权发上行的PING的内容， PING的数据就发送到基站侧。
第二种、 基于收到SR置大的模拟BSR模式
这是目前版本默认设置的模式。其基本原理是基于SR上报，根据前一个TTI需要调度的UE个数，基站主动下发一个较大的上行资源，使得UE可以利用该资源发送上行数据，减少了UE发送BSR然后eNB根据BSR进行调度的流程。
第三种、 混合调度模式
混合调度模式是在预调度持续时间内，定时主动向UE发送上行资源，UE利用该资源发送上行数据。由于基站是周期性的对UE分配上行资源，减少了UE发送SR的流程，因此使得的时延缩短。具体为：UE发送SR请求，基站检测到SR后，产生虚拟的BSR进行正常的调度处理，启动预调度周期PingPreSchPeriodTimer和预调度持续时间PingPreSchHoldTimer(默认2048ms)；在PingPreSchHoldTimer超时前，每隔PingPreSchPeriodTimer基站主动产生虚拟BSR并进行调度；UE利用预调度的资源发送的上行数据和可能的BSR。
混合调度模式对所有的SR均做同样的处理，如果商用系统中用户量较大，大量的上行资源预授权将导致基站反向干扰加重，严重影响基站反向解调性能。商用局环境下不建议采用这种模式。
第四种、 增强型混合调度模式
为了避免混合调度模式带来的负面影响，增强型混合调度模式能够对PING的业务进行识别，识别出PING业务的周期和大小之后，仅仅在PING的周期到来时，给一定长度及相应大小的预授权即可。这样能大大减缓预授权带来的带宽损失，可提升上行的有效载荷。
第五种、 基于预调度模式
预调度模式下，UE直接发送，没有SR及BSR预授权协商过程，这种模式只能用于单用户实验室测试，属于极限测试。
测试时，上行传输默认使用Large BSR方式传输。终端首先发起SR（Scheduling Request），在基站进行上行资源授权之后，终端再发起BSR(Buffer Status Request)和ping数据包一起上传。注意当UE高层要求发送SR的时候，并不是在每一个时隙都可以发送，而是需要在SR周期内的某一个时隙才能发送。
图 3‑3：SR传输周期
网管参数在无线参数---上下行物理信道配置表：UE SR传输周期(ms)
如果配置SR周期为10ms，那么SR发送前的等待时间为1~10ms，平均等待时间为5ms。
协议规定的最小SR周期是5ms，SR周期最短只能设置到5ms，目前我司默认配置是10ms，其实有些场景下如果S1传输时延太大导致时延离验收标准只差几ms的时候，可以把SR周期改为5ms，使得SR发送前的平均等待时间缩小到2.5ms。
通过将SR传输周期从10ms修改为5ms，使得时延平均值减少了3ms。
需要注意的是，将SR周期从10ms修改为5ms，将会使得PUCCH SR信道支持的最大用户数减少一倍，我司默认参数是按照每载扇400激活用户配置的，修改后会使得PUCCH信道容量减少。在网络负载比较小的场景下，修改这个参数影响不大。
主要包括码字设计和系统设计。码字设计的目标是设计协作传输的效率更高，与各个分支链路信道条件相匹配的信道编码；系统设计的内容包括用户配对、路由选择和资源调度等。网络编码是与部署场景密切相关的，具体方案需要针对某一种场景进行优化，例如，协作中继和节点双向传输两种场景对空口标准的影响程度就有所不同。
链路DRX功能开启之后，在没有数据传输的时候，终端会进入休眠状态以节省电源，这时候上/下行数据的发送都可能会被延迟，进行ping业务会造成时延变长。
在NGBR DRX打开和关闭前后进行ping对比测试，关闭DRX时ping平均时延减少了3~4ms。
如果无线环境较差，或者无线环境的突然变化，都会造成空口发送的数据包解码错误而产生HARQ重传，重传一次的额外时延是8ms。
下图是通过QXDM抓取的一个测试log数据，利用QCAT进行分析，在系统帧和子帧1099时上行MAC层发了一个数据。
图 3‑4：数据
在系统帧和子帧1123时才收到下行MAC层返回的数据，时延为1123-1099=24ms，这个商用局的S1口传输时延为10ms，即使扣除这个S1口10ms时延后，14ms也明显大于基站内部标准处理时延6ms。在 LTE PDSCH Stat Indication消息中查看，发现在系统帧子帧1115时的CRC Result是fail，导致HARQ重传，在8ms后的系统帧子帧1123重新收到了数据，这时候的CRC Result为pass，正确解码。
从这个例子中可以看出空口解码错误导致的HARQ重传，会增加时延8ms。
S1口时延指Ping Req从基站出去（发往UE需要Ping的服务器）->基站收到服务器返回的Ping Reply的时延，该段时延应该小于1ms，而不是单单指的基站与核心网的传输交互时延。
S1口时延测试有三种方法：
第一种、IP通道质量测试确定S1口时延
这个功能可实现通过在OMC客户端上进行操作，发起以“基站”做为ping操作的起点，对目标IP地址的IP通道质量通道检测。目标IP地址选择核心网MME或者SGW 的IP地址。
正常情况下，从基站ping 核心网MME或者SGW的时延应该在1~2ms，如果偏大的话将会导致UE 时延增大，需要联系传输侧排查S1口时延。
第二种、Wireshark在基站VSWc2板debug口抓包确定传输时延
Telnet 192.254.1.16，并pad MGR.exe，登录到平台管理进程，敲入MirrorToDebug 0,0，在QE进行端口映射，然后开启wireshark，在CC板debug口抓包。详细抓包方法请参考附录A Debug口抓包方法。
在Ping之前，打开Wireshark工具，点击Capture捕获窗口，选择正确的interface,对应的服务器地址，在过滤栏指定IMCP消息，选择Update list of packets in real time。使用完成之后使用BspClearESwitchMirror清除镜像，以免出现其他问题。
图 3‑5：传输时延采集
在Inter Control Message Protocol里：Sequencen number:确定该的序列号，Data里确定一次的大小。传输时延 = Echo (ping) reply的frame 23里的 Arrival time - Echo (ping)request的frame 24里的 Arrival time。
第三种、UE侧log分析确定传输时延
通过Ue侧Log来看，看上行包发出去时间及下行接收到的时间差，将这个时间差减去基站内部处理时延，既可以得到传输时延了。通常基站内部处理时延正常值为6ms。
使用QXDM抓包时注意把所有LTE相关设置都选上，否则可能引起MAC层抓包不全，无法记录下所有上下行数据包的信息。抓包完成后，使用QCAT把记录的LOG打开，并使用以下条件过滤，见下图：是32字节，在加了各个协议层的开销之后，在MAC层看到的就是
图 3‑6：MAC层消息采集
在0xB064 LTE MAC UL Transport Block中找到LC ID为3或者4，长度为64的包，为UE侧数据包发出的时间。在上行数据附近的0xB063 LTE MAC DL Transport Block找到LC ID为3或者4，长度为64的包，对应的帧号子帧号为UE侧收到的ACK的时间，如下：
图 3‑7：MAC层消息采集
故上述在网络侧的时延为5448（DL receive） - 5441（UL send）=7ms。
基站侧内部处理时延正常的情况下，S1口时延为7ms-6ms=1ms。
后台分析该5G站点投诉时段及忙时指标,上下行利用率均不高，负荷正常，RRC激活最大用户数21个。
再次回访投诉用户并现场复测，该站点覆盖区域下投诉时段只有部分用户出现过时延升高现象，测试终端在投诉时段未出现时延过高现象。
投诉时段在该站点下使用10部终端同时玩王者荣耀浮现投诉用户场景进行压力测试，发现手机不定出现时延变大现象，后台跟踪两种卡差异发现测试卡默认承载为QCI6或者QCI8，出现异常卡默认承载为QCI9。
由于QCI等级不同，基站侧默认QCI6的调度优先级高于QCI9，导致同时做业务的场景下QCI9已被抢占资源出现时延过高。
关闭上行预调度开关配置以满足用户公平调度的要求。
表名 | 参数名称 | 字段名 | 默认值 | 推荐值 |
DV | 上行预调度开关 | ULPreSchdlFlag | 1 | 0 |
表3.1：参数修改建议
对于调度类参数配置，建议如下：
位置 | 表名 | 参数名称 | 字段名 | 默认值 | 推荐值 |
5G网管 | endcrlc | 重发POLL位的时间间隔 | pollRetransTimer | 15 | 40 |
5G网管 | SRResource | SR传输周期 | tranPeriod4SR | 10;10;10;10 | 10;10;10;10 |
表3.2：参数修改建议
随着5G用户数不断增长，当前5G网管默认的参数配置存在差异化场景下的不合理问题，尤其用户数增多时，性能下降明显，预调度开启导致的控制信道资源不足：预调度导致CCE资源不够，影响用户感知，且结合下行调度资源分析，很多用户业务需求其实很低，无需一直调度；预调度开启后 反馈慢，时延长，导致数据量下降，影响下载速率，因此关闭预调度开关后，投诉区域未出现 反馈慢时延长现象，用户玩游戏感知正常。
关注楼主