大唐E-RAB建立时延大-

问题描述：

日常监控VoLTE相关KPI，发现大唐E-RAB建立时延偏大约70ms，其他厂家30ms左右。

问题定位：

ERAB建立时延分为初始ERAB建立时延与附加ERAB建立时延。

初始ERAB建立时延统计起始信令节点为EPC给ENB下发Initial Context Setup Request，结束信令节点为ENB给EPC回复Initial Context Setup Response。初始ERAB建立过程中可能会有SMC过程、UE能力查询过程、第一次RRC重配过程。附加ERAB建立时延统计起始信令节点为EPC给ENB下发Erab Setup Request，结束信令节点为Erab Setup Respone，过程中会有一次RRC重配过程。

从KPI统计来看，初始ERAB建立时延较大，且初始ERAB建立次数相对附加ERAB建立次数要多，所以ERAB建立时延偏大问题的原因在于初始ERAB建立时延。

从以下4个方面进行ERAB建立时延根本原因分析：1）KPI统计是否准确；2）分析是否基站内部处理时延引起；3）是否终端处理时延引起；4）是否空口处理时延引起。

选取上街环岛1个用户数时段偏少的15分钟的CDL统计，按信令节点过滤手动计算ERAB时延建立，与KPI统计对比，基本一致，因此可以排除KPI统计不准确的原因。

继续分析CDL，以一次完整的ERAB建立过程为例。

从ENB收到初始ERAB建立请求（Initial Context Setup Request），到ENB给UE下发SMC或UECapabilityEnquiry，这段时延为基站内部处理时延，从15分钟CDL的手工计算可以看出，此部分时延主要集中在5/10ms，及30/35ms，个别异常情况下处理时延会更长。且统计出的ERAB时延分布情况和基站处理时延相关性较大，因此基站内部处理时延是ERAB建立时延偏大的其中一个原因。

结合路测终端与CDL进行联合分析，从终端log看，在收到SMC和RRC重配均在1~5ms内回复了SMC完成和RRC重配完成，但是在基站侧看RRC重配完成下发后到收到RRC重配完成用了5个半帧（即约25ms），怀疑为空口过程引入时延，因此修改预调度参数

修改预调度参数后，ERAB时延有所改善，但是仍然偏大。经过研发深入分析，最终确定当前版本的预调度算法不太完善，还需要进一步优化。

问题原因：从分析来看，当前大唐610ENB版本ERAB建立时延偏大的原因为基站内部处理时延，以及空口时延引起，需要分别优化基站内部处理时延及空口时延才能解决。针对基站内部处理时延，在实验室用优化后测试版本进行测试，基站处理时延相对当前版本至少可以改善10~15ms，经过细致的测试后，该方案已合并入620版本。空口时延优化方案需要较长周期，规划在650版本进行合并。