X2口MTU设置为1800导致切换中断时延大问题案例

admin

X2口MTU设置为1800导致切换中断时延大问题案例【案例描述】

V局点测试人员反映，在X2用户面切换时延测试中，发现部分切换时延达到80~100ms,远远超过40ms左右的预期值。

【关键字】切换，时延，参数配置【版本信息】

DBS 3900 LTE V100R001C01SPC120

【定位思路分析】

切换用户面中断时延较大的话，可以按照如下思路分析：

1.       信令面时延是否异常，这个由于有跟踪是最好判断的。

2.       切换时用户面是否有较大的重传误码。

3.       排查随机接入时延是否异常。

4.       UE是否反馈了PDCP状态报告

5.       数据转发链路是否有异常

6.       发包工具是否异常

另外，如果观察的时延点是端到端的，还需要重点排查传输网络。

【定位信息】

eNb版本：DBS3900 LTE V100R001C01SPC120

Web LMT，Local Maintenance Terminal（LMT），Probe

【定位过程】

4月23日，后方人员按照前方提供的测试数据，进行分析：包含在日志内发生切换的小区有两个，PCI分别为5，133，其中PCI为5的小区在eNB1中，而PCI为133的小区在eNB2中，发生大时延现象的全部都是在UE从PCI5小区往PCI133小区切换时发生的PCI133往PCI5切换是正常的。

鉴于这种现象，比较可能的是参数配置问题。首先我们针对切换中的几个时间戳分析，经过与正常值的比较，发现UE在DRB建立完成后，收到的第一个数据包较晚, 正常情况下应该立即收到数据包，但日志显示却多花了40~60ms。这说明UE在发送切换响应至目标小区之后，eNB迟迟没有下发数据包，或者在这当中发生了多次重传。

按照这个思路，我们在比对了现场的两个基站配置后，给出了提高PUCCH的P0以及降低切换时数据信道的MCS的方法，期望减少信道质量的影响。但是在前方实际配置后，没有起到任何效果。

在参数修改后，我们认为应该不是重传引起的时延增大，在与性能专家讨论后，怀疑是不是X2口在转发切换数据包时出现较大延迟。因此我们在目标小区和源小区分别查看数据包的接收发送情况，前方很快反馈回来，当出现时延增大现象时，目的侧收到的转发包只有源侧发送的1/10，有时候甚至完全没有收到转发包。

这样直接就定位到交换机可能存在切换时丢包的现象。检查基站的MTU配置,发现当前配置值为1800，而交换机的MTU仅为1500。后方分析，切换时，会在当前数据包上再增加包头，组的包太大，超过交换机的MTU后但是并没有超过基站的MTU大小，基站发出转发包没有发生分片，但是却超过了交换机的MTU大小，交换机直接丢弃处理。而小区133的X2口MTU为1500，所以交换机不会丢弃小区133往小区5转发的数据包。这就出现了正反向切换时，切换时延差别如此之大的原因。

修改了小区5的X2端口MTU也为1500后，切换数据面大时延的问题立即得到了解决。

【问题根因】

X2口MTU配置不合理，无法与交换机匹配，造成切换时，X2口的转发包大部分都被交换机丢弃，引起了较大时延。

【建议与总结】

经过确认，在现场使用的这个V100R001C01SPC120版本，以太网口MTU为1800是默认配置，鉴于这次事件以及平常的经验，我们认为1800是不合理的，因为大部分数通产品默认设置的MTU都在1500左右，还是设置为1500比较好。开发人员接受了这个意见，并表示在V100R001C01SPC120之后的版本，MTU1500已经作为默认配置合入。

MTU是不在网络中协商的，一线在组网规划时，一定要将MTU列入严格清查项。网元中任何一个数通设备的MTU设置不合理，都会造成问题的发生。