来源：面包芯语
2023-06-24 18:22:27
用户反馈在拨测语音时，概率性存在被叫不通现象。现场使用不同芯片类型的终端均复现被叫语音概率性无法接通的问题，但复现概率低，平均约1%概率，并且只在问题站点复现了问题，其他站点测试都正常。
组网环境
【资料图】
设备型号：CCC+BPN0_b/BPN0/+R8862AS1800/R8862AS1800/R8862AS1800/R8862A S2100/ R8862A S2100/R8862A S2100/
4G软件版本号：V3.80.30.20
4G组网配置：111
基站和UE侧信令分析（控制面）
主叫20:52:57发起呼叫，在20:53:26没有收到被叫的应答后挂机取消本次通话，如图1所示。
图1 未收到被叫应答
被叫在上一次正常通话后20:52:51释放RRC连接，在下一次正常通话之间没有正确解析出对本终端的寻呼消息，如图2所示。
图2 被叫未正确解析寻呼消息
被叫UE侧分析（用户面）
被叫被呼叫期间寻呼终端侧解析寻呼CRC情况，如图3所示。
图3 寻呼CRC情况
复现过程中，被叫寻呼CRC Fail概率124/(124 + 171) = 42.0%。
调度分析CRC错的规律（MAC）
寻呼对于基站侧调度都是透传调度，并且用的最保守调度。下行寻呼终端是不做解析结果反馈的，所以从基站无法感知终端解析寻呼结果。如图4所示，终端解析寻呼正确DCI，在191帧的9号子帧收到RNTI类型为P（寻呼）。通过协议格式解析RB是从低频0开始分配。
图4 191帧的9号子帧的解析结果
191帧的9号子帧DCI码流如图5所示。
图5 191帧的9号子帧 DCI码流
查看寻呼错时终端DCI码流，通过解析协议格式，发现下行RB都是从高频97开始分配出现错误，所以推测下行高频存在干扰导致终端突发概率性接错。
下面为找出测试终端寻呼错DCI格式。
第一组：在255帧的9号子帧，终端解析寻呼结果为FAIL，如图6所示。
图6 255帧的9号子帧的解析结果
对应255帧的9号子帧的DCI码流如图7所示。
图7 255帧的9号子帧的DCI码流
第二组：在383帧的9号子帧，终端解析寻呼结果为FAIL，如图8所示。
图8 383帧的9号子帧的解析结果
对应383帧的9号子帧的DCI码流如图9所示。
图9 383帧的9号子帧的DCI码流
第三组：在639帧的9号子帧，终端解析寻呼结果为FAIL，如图10所示。
图10 639帧的9号子帧的解析结果
对应639帧的9号子帧的DCI码流如图11所示。
图11 639帧的9号子帧的DCI码流
综上寻呼错误规律，错误时码流都为0x8252110000000000，所以推测出寻呼终端解析错误码流一致，并通过协议解析出RB位置都是在高频。
现场验证
寻呼分RB从两边频带开始分，现场按照如下步骤复测：
将低频30RB禁掉，测试93组复现问题。
将低频30+高频10RB禁掉，测试600组不复现。
将低频30RB解开测试300组不复现，不复现时查看CRC全部正确。
将高频10RB解开测试50组出现2次，UE被呼叫期间寻呼终端侧解析寻呼CRC情况，测试结果如图12所示。
图12 测试CRC结果
综上验证和正向分析证实高频10RB存在下行问题，进而导致CRC fail。
现场在关闭周边1.8G LTE基站的情况下扫频，没有发现外部干扰，如图13所示。
图13 未发现外部干扰
打开问题小区情况下的扫频可以发现后5 M波形明显异常，如图14所示。
图14 5 M波形异常
现场核查发现该站点装有滤波器，在撤除滤波器后波形恢复正常，如图15所示。
图15 波形恢复正常
拆除后分析测试数据发现PDSCH CRC解错率恢复正常水平。被叫也没有未接通的现象，如图16所示。
图16 PDSCH CRC解错率恢复正常水平
被叫终端测试时驻留在50/51小区（频点1850， PCI34/35），推测下行后10个RB(第90-100RB)存在下行问题，从而造成解析Paging消息 PDSCH CRC错，造成概率性的无法解对Paging消息，最终导致被叫终端无法收到寻呼造成呼叫失败。
扫频发现下行后5 M波段异常，核查发现该站点安装了滤波器，现场拆了滤波器后复测，问题不再复现。
临时规避方案：修改图17所示的参数，禁掉后10个RB。
图17 修改参数
正式解决方案：撤除滤波器。
