用戶反饋在撥測語音時，概率性存在被叫不通現象。現場使用不同芯片類型的終端均復現被叫語音概率性無法接通的問題，但復現概率低，平均約1%概率，并且只在問題站點復現了問題，其他站點測試都正常。

組網環境

設備型號：CCC+BPN0_b/BPN0/+R8862AS1800/R8862AS1800/R8862AS1800/R8862A S2100/ R8862A S2100/R8862A S2100/

4G軟件版本號：V3.80.30.20

4G組網配置：111

基站和UE側信令分析（控制面）

主叫2057發起呼叫，在2026沒有收到被叫的應答后掛機取消本次通話，如圖1所示。

圖1 未收到被叫應答

被叫在上一次正常通話后2051釋放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 修改參數

正式解決方案：撤除濾波器。