<tfoot id="ouu4w"><rt id="ouu4w"></rt></tfoot>
  • 
    
  • <bdo id="ouu4w"></bdo>
        <cite id="ouu4w"><table id="ouu4w"></table></cite>
      • 您當(dāng)前的位置: 首頁-IT-詳情

        某外場反饋FDDLTEVoLTE被叫語音不通 熱消息

        2023-06-24 18:30:06來源:面包芯語

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


        【資料圖】

        組網(wǎng)環(huán)境

        設(shè)備型號(hào):CCC+BPN0_b/BPN0/+R8862AS1800/R8862AS1800/R8862AS1800/R8862A S2100/ R8862A S2100/R8862A S2100/

        4G軟件版本號(hào):V3.80.30.20

        4G組網(wǎng)配置:111

        基站和UE側(cè)信令分析(控制面)

        主叫20:52:57發(fā)起呼叫,在20:53:26沒有收到被叫的應(yīng)答后掛機(jī)取消本次通話,如圖1所示。

        圖1 未收到被叫應(yīng)答

        被叫在上一次正常通話后20:52:51釋放RRC連接,在下一次正常通話之間沒有正確解析出對(duì)本終端的尋呼消息,如圖2所示。

        圖2 被叫未正確解析尋呼消息

        被叫UE側(cè)分析(用戶面)

        被叫被呼叫期間尋呼終端側(cè)解析尋呼CRC情況,如圖3所示。

        圖3 尋呼CRC情況

        復(fù)現(xiàn)過程中,被叫尋呼CRC Fail概率124/(124 + 171) = 42.0%。

        調(diào)度分析CRC錯(cuò)的規(guī)律(MAC)

        尋呼對(duì)于基站側(cè)調(diào)度都是透傳調(diào)度,并且用的最保守調(diào)度。下行尋呼終端是不做解析結(jié)果反饋的,所以從基站無法感知終端解析尋呼結(jié)果。如圖4所示,終端解析尋呼正確DCI,在191幀的9號(hào)子幀收到RNTI類型為P(尋呼)。通過協(xié)議格式解析RB是從低頻0開始分配。

        圖4 191幀的9號(hào)子幀的解析結(jié)果

        191幀的9號(hào)子幀DCI碼流如圖5所示。

        圖5 191幀的9號(hào)子幀 DCI碼流

        查看尋呼錯(cuò)時(shí)終端DCI碼流,通過解析協(xié)議格式,發(fā)現(xiàn)下行RB都是從高頻97開始分配出現(xiàn)錯(cuò)誤,所以推測下行高頻存在干擾導(dǎo)致終端突發(fā)概率性接錯(cuò)。

        下面為找出測試終端尋呼錯(cuò)DCI格式。

        第一組:在255幀的9號(hào)子幀,終端解析尋呼結(jié)果為FAIL,如圖6所示。

        圖6 255幀的9號(hào)子幀的解析結(jié)果

        對(duì)應(yīng)255幀的9號(hào)子幀的DCI碼流如圖7所示。

        圖7 255幀的9號(hào)子幀的DCI碼流

        第二組:在383幀的9號(hào)子幀,終端解析尋呼結(jié)果為FAIL,如圖8所示。

        圖8 383幀的9號(hào)子幀的解析結(jié)果

        對(duì)應(yīng)383幀的9號(hào)子幀的DCI碼流如圖9所示。

        圖9 383幀的9號(hào)子幀的DCI碼流

        第三組:在639幀的9號(hào)子幀,終端解析尋呼結(jié)果為FAIL,如圖10所示。

        圖10 639幀的9號(hào)子幀的解析結(jié)果

        對(duì)應(yīng)639幀的9號(hào)子幀的DCI碼流如圖11所示。

        圖11 639幀的9號(hào)子幀的DCI碼流

        綜上尋呼錯(cuò)誤規(guī)律,錯(cuò)誤時(shí)碼流都為0x8252110000000000,所以推測出尋呼終端解析錯(cuò)誤碼流一致,并通過協(xié)議解析出RB位置都是在高頻。

        現(xiàn)場驗(yàn)證

        尋呼分RB從兩邊頻帶開始分,現(xiàn)場按照如下步驟復(fù)測:

        將低頻30RB禁掉,測試93組復(fù)現(xiàn)問題。

        將低頻30+高頻10RB禁掉,測試600組不復(fù)現(xiàn)。

        將低頻30RB解開測試300組不復(fù)現(xiàn),不復(fù)現(xiàn)時(shí)查看CRC全部正確。

        將高頻10RB解開測試50組出現(xiàn)2次,UE被呼叫期間尋呼終端側(cè)解析尋呼CRC情況,測試結(jié)果如圖12所示。

        圖12 測試CRC結(jié)果

        綜上驗(yàn)證和正向分析證實(shí)高頻10RB存在下行問題,進(jìn)而導(dǎo)致CRC fail。

        現(xiàn)場在關(guān)閉周邊1.8G LTE基站的情況下掃頻,沒有發(fā)現(xiàn)外部干擾,如圖13所示。

        圖13 未發(fā)現(xiàn)外部干擾

        打開問題小區(qū)情況下的掃頻可以發(fā)現(xiàn)后5 M波形明顯異常,如圖14所示。

        圖14 5 M波形異常

        現(xiàn)場核查發(fā)現(xiàn)該站點(diǎn)裝有濾波器,在撤除濾波器后波形恢復(fù)正常,如圖15所示。

        圖15 波形恢復(fù)正常

        拆除后分析測試數(shù)據(jù)發(fā)現(xiàn)PDSCH CRC解錯(cuò)率恢復(fù)正常水平。被叫也沒有未接通的現(xiàn)象,如圖16所示。

        圖16 PDSCH CRC解錯(cuò)率恢復(fù)正常水平

        被叫終端測試時(shí)駐留在50/51小區(qū)(頻點(diǎn)1850, PCI34/35),推測下行后10個(gè)RB(第90-100RB)存在下行問題,從而造成解析Paging消息 PDSCH CRC錯(cuò),造成概率性的無法解對(duì)Paging消息,最終導(dǎo)致被叫終端無法收到尋呼造成呼叫失敗。

        掃頻發(fā)現(xiàn)下行后5 M波段異常,核查發(fā)現(xiàn)該站點(diǎn)安裝了濾波器,現(xiàn)場拆了濾波器后復(fù)測,問題不再復(fù)現(xiàn)。

        臨時(shí)規(guī)避方案:修改圖17所示的參數(shù),禁掉后10個(gè)RB。

        圖17 修改參數(shù)

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

        標(biāo)簽:

        上一篇:莫斯科等地進(jìn)入反恐狀態(tài)!普京發(fā)表講話:將為保衛(wèi)國家竭盡全力 今日最新
        下一篇:最后一頁