1、廣東移動4GTD-LTE詳細案例分析案例 1: 580 Precondition Failure 導致的未接通。【問題描述】在集團測試LOG中，存在Precondition Failure導致的失敗事件，表現為呼叫過程中，終端主 動上發或收到網絡側下發的580 Precondition Failure消息，隨后呼叫中止，出現未接通事件。Log文件名：_UE1.lte_UE2.lteMO UE:MT UE:時間：10 : 16 : 14.320【問題分析】1、 呼叫過程中，被叫發送 Ringing 180后，收到網絡下發的專載去激活命令，QCI 1被 釋放，被叫隨后上報580 Precondit

2、ion Failure，主叫同樣收到網絡側轉發的 580消息， 呼叫接續中止，導致未接通。2、 從信令中可以看到，被叫回復Ringing 180且主叫也已經收到 Ringing 180，被叫隨后 收到網絡側下發的 RRC重配，攜帶有 QCI 1被釋放的信息，被叫去激活專有承載。由于專載已被釋放，業務資源已不存在，所以被叫上發580 Precondition Failure失敗消息。主叫收到網絡側下發的580，接續被中止，導致了會話未接通。3、從MME下發到 Node B的E-RAB RELEASE COMMAND原因上看是 Nas層 nomal_release，導致專載 QCI 1被釋放。4、

3、 專載QCI 1被釋放，去激活后，被叫發送INVITE 580,主叫收到網絡側轉發的INVITE 580,會話流程中斷，導致未接通【問題定位】在正常的會話流程中，由于MME下發E-RAB RELEASE COMMAND使得QCI 1被釋放，導致未接通。【解決措施】需要核心網查看 MME在什么情況下會下發E-RAB RELEASE COMMAND【測試驗證】案例2： Server Internal Error 500導致的未接通【問題描述】在集團測試LOG中，存在Server Internal Error導致的失敗事件，表現為呼叫過程中，終端 主動收到網絡側下發的Server Internal

4、Error 500消息，隨后呼叫中止，出現未接通事件。Log文件名：.lte95000612.lteMO UE:MT UE:時間：10 : 19 : 29.051【問題分析】1、主叫發出UPDATE后,被叫收到UPDATE并回復UPDATE 20Q隨后被叫發送 Ringing 180, 主叫同時收到 UPDATE 200和Ringing 180。按照正常的信令流程應該是先收到UPDATE200,再收到 Ringing 180。2、然后主叫收到網絡側下發的INVITE Server Internal Error 500.主叫專載被釋放，去激活，導致會話未接通。【問題定位】主叫收到網絡側下發的IN

5、VITE 500,然后網絡側又下發 RRC重配，釋放掉 QCI 1然后去激 活，會話流程終止，導致未接通【解決措施】需要核心網確認,為什么會下發INVITE 500,什么情況下會導致網絡側下發INVITE 500,隨后的專載釋放是否由 INVITE 500導致的【測試驗證】案例 3：軟件對失敗事件的誤判導致統計錯誤【問題描述】在集團測試LOG中，存在軟件的誤判而錯誤統計的失敗事件。如在某個特定時間點上，信 令顯示主被叫正常通話,軟件卻統計出掉話或未接通事件。Log 文件名：95000606MO UE:MT UE:時間： 09 ：44 ： 14.0【問題分析】1、主叫從 09:42:41主叫開始

6、呼叫到 09:45:47 掛機成功, 在通話過程中信令流程正常, 中間 出現一次RRC重建被拒，導致 RRC釋放，事件表現為掉話，軟件統計為掉話。2、 在09: 44： 14.910主叫收到網絡側下發的 RRC重建被拒，主叫隨后發起 RRC建立請求， 在 09: 44： 15 : 004，然后因為 TAU,在 09： 44： 15 : 128 RRC Conn ection Release了， 軟件統計為掉話。隨后主叫又發起RRC連接，且在09: 44： 15.659重建完成，從 RRC重建被拒到RRC連接成功不到1s，且默認承載和專有承載均保持，未被釋放，證明會話保持正常。3、到最后結束通話

7、正常掛機都沒有出現失敗事件【問題定位】主叫接通后，在沒有收到通話結束的情況下，中間出現RRC Connection Release軟件判斷為掉線，此次是在會話建立后出現，軟件統計為掉話【解決措施 】需要鼎利修改判斷事件失敗的機制【測試驗證】案例 4：軟件對失敗事件的重復統計【問題描述】軟件對于失敗事件存在重復統計的問題， 在集團測試問題統計表中， 多次出現同一次失敗事 件，軟件卻作了多次統計，導致失敗事件的增多。Log 文件名：95000606MO UE:MT UE:時間： 10 ：04 ： 08.0【問題分析】1、主叫在10: 04: 04.642發出INVITE會話請求，被叫在 10: 0

8、4: 08.261收到網絡側下發的 BYE Reques，t 軟件統計為掉話。查看BYE Request中的CALL-ID 發現是上次會話的 BYE Request2、 被叫在10： 04 : 08： 230收到網絡側下發的INVITE Request同時發送Trying 100，又在 10： 04： 08.261收到網絡側下發的INVITE Request同時發送Trying 100，并在同時發送 INVITE 486，軟件統計為未接通。3、 主叫在收到網絡側下發的UPDATE 200后，在10: 04: 24.845上報Can cel,主叫的整個 會話流程到這里被終止，事件上表現為未接通。

9、且承載都存在【問題定位】通話期間，被叫收到網絡下發的BYE Request會被軟件統計為掉話。被叫連續兩次收到網絡下發的 INVITE Request 回復 INVITE 486 Busy Here，由于第一次 INVITE Request未釋放，故 第二次INVITE Request網絡側才會下發INVITE 486,流程停止，軟件統計為未接通。此時主 叫在進行正常的會話接續，信令流程正常，事件中未出現失敗事件。直到主叫上報Cancel，主叫會話流程停止，事件表現為未接通，之前的兩次失敗事件統計是重復統計。【解決措施】 需要鼎利確認對失敗事件的統計機制。【測試驗證】案例5: LTE到2G e

10、SRVCC切換失敗導致的掉話【問題描述】呼叫會話建立后，由于到達異系統B2門限，終端上報 B2事件，網絡下發eSRVCC切換配置命令，但在 2G 側切入失敗，導致掉話。Log 文件名:95000605.lte.lteMO UE:MT UE:時間: 11:16:42:311【問題分析】1、被叫上報B2事件，滿足切換門限系統下發mobility切換命令，此時4G的流程已完成，接下來切入 2G網絡，2G網絡下發 TMSI Reallocatio n Comma nd,被叫回復 TMSI Reallocati on Complete，此后流程中斷，eSRVCC切換失敗。3、信令上看，4G流程正常走完且

11、建立會話， 被叫切換到2G,但是網絡下發 TMSI Reallocation Comma nd導致流程終止，eSRVCC切換失敗，會話流程結束，懷疑是 2G問題。【問題定位】4G流程正常且已正常建立會話，由于2G網絡側下發TMSI Reallocatio n Comma nd導致eSRVCC切換失敗，會話流程結束，導致掉話，懷疑是 2G的問題。【解決措施】 下周準備復側,準備定位。【測試驗證】案例6: TAU過程中RRC Conn ection Release#致的未接通【問題描述】在越秀區網格10的測試LOG中，出現如下的未接通事件：主叫起呼發出 Invite 消息后,在收到網絡效應 Try

12、ing 100之前,先收到了網絡下發的 RRCConn ection Release消息，RRC連接釋放后，接續被終止，出現了Blocked Call事件。【問題分析】1、通過信令詳細分析主叫起呼的過程，可以發現， 起呼前， 主叫剛完成重選過程， 從 PCI216小區重選至PCI103小區，由于源小區與目標小區處在不同的TAC,主叫發起了 TAU請求：2、 在主叫上發TAU請求后，未等網絡回復ATU Accept,主叫已開始了起呼，上發 Invite消息。然而In vite上發0.172s后，主叫同時收到了網絡下發的ATU Accept和RRC Conn ectionRelease消息（因此時

13、主叫處在非業務態，ATU更新會伴隨RRC連接的釋放），主叫被叫釋放，從而導致了 Blocked Call事件的發生：3、 進一步分析信令可以發現,主叫在該測試路段內連續在3個 TAC（9437、 10315、 10014） 間進行TAU更新，其中從11:42:53至11:43:04就發生了 4次，可能在存在 TAC規劃不合 理的問題。【問題定位】 【解決措施】【測試驗證】案例7： Alerting中eSRVCC失敗導致未接通【問題描述】主叫起呼后，流程正常，達到eSRVCC切換門限后收到 eSRVCC切換命令且幾乎同時收到Ringing 180,主叫未摘機,由于切換失敗導致未接通。Log 文件

14、名：95000605.lte .lteMO UE:MT UE:時間： 11：25：28：189 【問題分析】1、 主叫在 11： 25： 26.130 起呼,到 11： 25： 28.204 收到網絡側轉發的Ringing 180,整個 信令流程正常2、 在主叫幾乎收到網絡側轉發的Ringing 180的同時，主叫達到 eSRVCC切換門限，網絡側 在11： 25： 28.189下發eSRVCC切換命令，在切換過程中主叫處于振鈴中，并未摘話， 而切換失敗,導致了未接通。【問題定位】主叫已經收到 Ringing 180，處于振鈴狀態還未摘話，由于在Alerting中發生了 eSRVCC切換失敗導

15、致了未接通【解決措施】 需要核心網方面幫忙定位【測試驗證】案例& CSFB失敗導致未接通【問題描述】主叫起呼后，被叫 CSFB失敗，主叫直接 Cancel導致未接通 Log 文件名：.lte 95000606.lte MO UE:MT UE:時間： 15：42：53：063【問題分析】1、 主叫于15:42:22發起invite，被叫未收到網絡側轉發的INVITE Request,但是主叫能一直 收到網絡側下發的INVITE 183、PRACK UPDATE消息，這些消息被叫并沒有收到也沒 有回復。被叫在15:42:24收到網絡側下發的 CSFB request,但CSFB到2G后從信令看沒

16、有呼叫相關的信令交互過程2、 直到15:42:35 CSFB失敗，由于收不到被叫的響應，主叫主動于15:42:53發起CANCLE 導致會話未接通。【問題定位】主叫發起會話后，被叫沒有收到會話請求，直接CSFB CSFB失敗，主叫一直未收到被叫的響應，直接Cancel，導致會話未接通。【解決措施】需要核心網 查看為什么被叫沒有收到主叫的會話請求,且主叫能收到網絡側下發的INVITE180、UPDATE PRACK消息。【測試驗證】案例 9：被叫 Detach 導致會話未接通【問題描述】主叫發起會話，被叫駐留在2G未返回4G,沒有響應主叫的會話請求，主叫收不到被叫相應， 直接 Cancel 導致

17、未接通。Log 文件名：.lte95000606.lteMO UE:MT UE:時間： 15：43 ：37：999【問題分析】1、主叫在15： 43 : 08.657起呼，此時被叫任然駐留在 2G，由于上一次會話中 CSFB失敗， 并沒有返回 4G。2、起呼后,被叫一直無響應,沒有與主叫進行信令交互,然而主叫能一直收到網絡側下發 的 PRACK UPDATE消息。3、 主叫一直收不到被叫的回復，被叫在15:43:30.449被叫上發 Detach Request,主叫在 15： 43： 37.999上發Can cel,取消會話，導致未接通【問題定位】被叫停留在2G未返回4G,然后上發Detac

18、h Request，主叫收不到被叫的回復， 直接Cancel, 導致未接通【解決措施】需要核心網查看為什么主叫會話信令流程正常, 被叫卻無法收到主叫的會話請求。 同時查看2G 無線側,為什么被叫會上發 Detach Request。【測試驗證】案例 10：承載未建立導致未接通【問題描述】主叫收到100 Trying后未建立承載，使得RRC直接釋放，導致未接通Log 文件名：95000605.lte .lteMO UE:MT UE:時間： 15：46 ：36：271【問題分析】1、主叫在15: 46: 19.079發起會話，收到網絡側下發的100 Trying后，專有承載一直未建立，10s后RR

19、C釋放，主叫在15： 46 : 36.271上發Can cel,導致會話未接通【問題定位】專有承載未建立，10s后RRC釋放，導致未接通【解決措施】需要核心網查看為什么沒有建立專有承載【測試驗證】案例 11:承載異常釋放導致掉話【問題描述】被叫重建立成功后,專有承載突然被釋放,導致掉話Log 文件名:95000605.lte.lteMO UE:MT UE:時間: 10:35 :41:981【問題分析】1、主叫在 10: 28: 06.903 起呼,流程正常,收到網絡側轉發的 Ringing 180, UPDATE 200, 主被叫會話正常建立。2、 被叫在 10: 35: 38.253 發送重建立,重建立成功,且流程正常,但是在10: 35: 41.981 承載被釋放,導致掉話【問題定位】會話建立后,被叫重建立完成,但是專有承載被釋放,導致掉話【解決措施】需要核心網確認承載釋放的原因【測試驗證】案例 1