VoLTE外場測試分析案例

1、【問題描述】在集團測試LOG中，存在PreconditionFailure導致的失敗事件，表現(xiàn)為呼叫過程中，終端主動上發(fā)或收到網(wǎng)絡(luò)側(cè)下發(fā)的580PreconditionFailure消息，隨后呼叫中止，出現(xiàn)未接通事件。【問題分析】1、2、呼叫過程中，被叫發(fā)送被釋放，被叫隨后上報580消息，呼叫接續(xù)中止，導致未接通。從信令中可以看到，被叫回復Ringing180且主叫也已經(jīng)收到Ringing180,被叫隨后收到網(wǎng)絡(luò)側(cè)下發(fā)的RRO配，攜帶有QCI1被釋放的信息，被叫去激活專有承載。由于專載已被釋放，業(yè)務(wù)資源已不存在，所以被叫上發(fā)580PreconditionFailure失敗消息。主叫收到網(wǎng)絡(luò)側(cè)下

2、發(fā)的580,接續(xù)被中止，導致了會話未接通。Ringing180后，收到網(wǎng)絡(luò)下發(fā)的專載去激活命令，QCI1580PreconditionFailure,主叫同樣收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的3、4、從MME發(fā)到NodeB的E-RABRELEASEOMMAND因上看是Nas層nomal_release,導致專載QCI1被釋放。專載QCI1被釋放，去激活后，被叫發(fā)送INVITE580,主叫收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的INVITE580,會話流程中斷，導致未接通【問題定位】在正常的會話流程中，由于MME發(fā)E-RABRELEASECOMMAND得QCI1被釋放，導致未接通。【解決措施】需要核心網(wǎng)查看MM圈什么情況下會下發(fā)E-RA

3、BRELEASECOMMAND【測試驗證】案例2:ServerInternalError500導致【問題描述】在集團測試LOG中，存在ServerInternalError導致的失敗事件，表現(xiàn)為呼叫過程中，終端主動收到網(wǎng)絡(luò)側(cè)下發(fā)的ServerInternalError500消息，隨后呼叫中止，出現(xiàn)未接通事件?！締栴}分析】1、主叫發(fā)出UPDATED，被叫收到UPDAT臥回復UPDATE。，隨后被叫發(fā)送Ringing180,主叫同時收到UPDATE200和Ringing180。按照正常的信令流程應該是先收到UPDATE200，再收到Ringing180。2、然后主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITESe

4、rverInternalError500.主叫專載被釋放，去激活，導致會話未接通?！締栴}定位】主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE500,然后網(wǎng)絡(luò)側(cè)又下發(fā)RRC配，釋放掉QCI1,然后去激活，會話流程終止，導致未接通【解決措施】需要核心網(wǎng)確認，為什么會下發(fā)INVITE500，什么情況下會導致網(wǎng)絡(luò)側(cè)下發(fā)INVITE500,隨后的專載釋放是否由INVITE500導致的【測試驗證】案例3:軟件對失敗事件的誤判導致統(tǒng)計錯誤【問題描述】在集團測試LOG中，存在軟件的誤判而錯誤統(tǒng)計的失敗事件。如在某個特定時間點上，信令顯示主被叫正常通話，軟件卻統(tǒng)計出掉話或未接通事件?！締栴}分析】1、主叫從09:42:41主叫

5、開始呼叫到09:45:47掛機成功，在通話過程中信令流程正常，中間出現(xiàn)一次RRC建被拒，導致RRCW放，事件表現(xiàn)為掉話，軟件統(tǒng)計為掉話。2、在09:44:主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的RRO建被拒，主叫隨后發(fā)起RRCM立請求，在09:44：15:004,然后因為TAU在09:44：15:128RRCConnectionRelease了，軟件統(tǒng)計為掉話。隨后主叫又發(fā)起RRC連接，且在09:44:重建完成，從RRC重建被拒到RR如接成功不到1s,且默認承載和專有承載均保持，未被釋放，證明會話保持正常。3、到最后結(jié)束通話正常掛機都沒有出現(xiàn)失敗事件【問題定位】主叫接通后，在沒有收到通話結(jié)束的情況下，中間出現(xiàn)RR

6、CConnectionRelease,軟件判斷為掉線，此次是在會話建立后出現(xiàn)，軟件統(tǒng)計為掉話【解決措施】需要鼎利修改判斷事件失敗的機制【測試驗證】案例4:軟件對失敗事件的重復統(tǒng)計【問題描述】軟件對于失敗事件存在重復統(tǒng)計的問題，在集團測試問題統(tǒng)計表中，多次出現(xiàn)同一次失敗事件，軟件卻作了多次統(tǒng)計，導致失敗事件的增多?！締栴}分析】1、主叫在10:04:發(fā)出INVITE會話請求，被叫在10:04:收到網(wǎng)絡(luò)側(cè)下發(fā)的BYERequest,軟件統(tǒng)計為掉話。查看BYERequest中的CALL-ID，發(fā)現(xiàn)是上次會話的BYERequest2、被叫在10：04：08:230收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITEReques

7、t同時發(fā)送Trying100,又在10:04：收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITERequest同時發(fā)送Trying100,并在同時發(fā)送INVITE486,軟件統(tǒng)計為未接通。3、主叫在收到網(wǎng)絡(luò)側(cè)下發(fā)的UPDATE。后，在10：04：上報Cancel,主叫的整個會話流程到這里被終止，事件上表現(xiàn)為未接通。且承載都存在【問題定位】通話期間，被叫收到網(wǎng)絡(luò)下發(fā)的BYERequest會被軟件統(tǒng)計為掉話。被叫連續(xù)兩次收到網(wǎng)絡(luò)下發(fā)的INVITERequest，回復INVITE486BusyHere，由于第一次INVITERequest未釋放,故第二次INVITERequest網(wǎng)絡(luò)側(cè)才會下發(fā)INVITE486,流程停止

8、，軟件統(tǒng)計為未接通。此時主叫在進行正常的會話接續(xù)，信令流程正常，事件中未出現(xiàn)失敗事件。直到主叫上報Cancel,主叫會話流程停止，事件表現(xiàn)為未接通，之前的兩次失敗事件統(tǒng)計是重復統(tǒng)計。【解決措施】需要鼎利確認對失敗事件的統(tǒng)計機制?！緶y試驗證】案例5:LTE到2GeSRVCC®換失敗導致的掉話【問題描述】呼叫會話建立后，由于到達異系統(tǒng)B2門限，終端上報B2事件，網(wǎng)絡(luò)下發(fā)eSRVCCU換配置命令，但在2G側(cè)切入失敗，導致掉話?！締栴}分析】1、被叫上報B2事件，滿足切換門限系統(tǒng)下發(fā)mobility切換命令，此時4G的流程已完成，接下來切入2G網(wǎng)絡(luò)，2G網(wǎng)絡(luò)下發(fā)TMSIReallocation

9、Command被叫回復TMSIReallocationComplete，此后流程中斷，eSRVCCU換失敗。3、信令上看，4G流程正常走完且建立會話，被叫切換到2G,但是網(wǎng)絡(luò)下發(fā)TMSIReallocationCommand致流程終止，eSRVC為換失敗，會話流程結(jié)束，懷疑是2G問題。【問題定位】4G流程正常且已正常建立會話，由于2G網(wǎng)絡(luò)側(cè)下發(fā)TMSIReallocationComman號致eSRVCC切換失敗，會話流程結(jié)束，導致掉話，懷疑是2G的問題。【解決措施】【測試驗證】案例6:TAUM程中RRCConnectionRelease導致的未接通【問題描述】在越秀區(qū)網(wǎng)格10的測試LOG中，出

10、現(xiàn)如下的未接通事件：主叫起呼發(fā)出Invite消息后，在收到網(wǎng)絡(luò)效應Trying100之前，先收到了網(wǎng)絡(luò)下發(fā)的RRCConnectionRelease消息，RRCM接釋放后，接續(xù)被終止，出現(xiàn)了BlockedCall事件?！締栴}分析】1、通過信令詳細分析主叫起呼的過程，可以發(fā)現(xiàn)，起呼前，主叫剛完成重選過程，從PCI216小區(qū)重選至PCI103小區(qū)，由于源小區(qū)與目標小區(qū)處在不同的TAC主叫發(fā)起了TAU請求：2、在主叫上發(fā)TAU請求后，未等網(wǎng)絡(luò)回復ATUAccept，主叫已開始了起呼，上發(fā)Invite消息。然而Invite上發(fā)后，主叫同時收到了網(wǎng)絡(luò)下發(fā)的ATUAccept和RRCConnectionR

11、elease消息（因此時主叫處在非業(yè)務(wù)態(tài)，ATU更新會伴隨RR如接的釋放），主叫被叫釋放，從而導致了BlockedCall事件的發(fā)生：3、進一步分析信令可以發(fā)現(xiàn)，主叫在該測試路段內(nèi)連續(xù)在3個TAC（9437、10315、10014）間進行TAU更新，其中從11:42:53至11:43:04就發(fā)生了4次，可能在存在TAC規(guī)劃不合理的問題。【問題定位】TAC規(guī)劃不合理。【解決措施】規(guī)戈ijTAC案例7:Alerting中eSRVC佚敗導致未接通【問題描述】主叫起呼后，流程正常，達到eSRVCC切換門限后收到eSRVCC切換命令且?guī)缀跬瑫r收到Ringing180,主叫未摘機，由于切換失敗導致未接通。

12、【問題分析】1、主叫在11：25:起呼，到11:25:收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing180,整個信令流程正常。2、在主叫幾乎收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing180的同時，主叫達到eSRVCC換門限，網(wǎng)絡(luò)側(cè)在11:25:下發(fā)eSRVCCU換命令，在切換過程中主叫處于振鈴中，并未摘話，而切換失敗，導致了未接通?！締栴}定位】主叫已經(jīng)收到Ringing180,處于振鈴狀態(tài)還未摘話，由于在Alerting中發(fā)生了eSRVCC切換失敗導致了未接通。【解決措施】需要核心網(wǎng)方面幫忙定位?！緶y試驗證】案例8:CSFB失敗導致未接i【問題描述】主叫起呼后，被叫CSF歐敗，主叫直接Cancel導致未接通?！締栴}分析】

13、1、主叫于15:42:22發(fā)起invite，被叫未收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的INVITERequest,但是主叫能一直收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE183、PRACKUPDATE息，這些消息被叫并沒有收到也沒有回復。被叫在15:42:24收到網(wǎng)絡(luò)側(cè)下發(fā)的CSFBrequest，但CSFEJ2G后從信令看沒有呼叫相關(guān)的信令交互過程。2、直到15:42:35CSF歐敗，由于收不到被叫的響應，主叫主動于15:42:53發(fā)起CANCLE導致會話未接通?！締栴}定位】主叫發(fā)起會話后，被叫沒有收到會話請求，直接CSFBCSFB失敗，主叫一直未收到被叫的響應，直接Cancel,導致會話未接通?！窘鉀Q措施】需要核心網(wǎng)查看為

14、什么被叫沒有收到主叫的會話請求，且主叫能收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE180、UPDATEPRACK肖息。【測試驗證】案例9:被叫Detach導致會話未接通【問題描述】主叫發(fā)起會話，被叫駐留在2G未返回4G,沒有響應主叫的會話請求，主叫收不到被叫相應，直接Cancel導致未接通?！締栴}分析】1、主叫在15:43:起呼，此時被叫任然駐留在2G,由于上一次會話中CSFB失敗，并沒有返回4G2、起呼后，被叫一直無響應，沒有與主叫進行信令交互，然而主叫能一直收到網(wǎng)絡(luò)側(cè)下發(fā)的PRACKUPDATE肖息。3、主叫一直收不到被叫的回復，被叫在15:43:被叫上發(fā)DetachRequest，主叫在15:43:上

15、發(fā)Cancel,取消會話，導致未接通?！締栴}定位】被叫停留在2G未返回4G,然后上發(fā)DetachRequest，主叫收不到被叫的回復，直接Cancel,導致未接通。【解決措施】需要核心網(wǎng)查看為什么主叫會話信令流程正常，被叫卻無法收到主叫的會話請求。同時查看2G無線側(cè)，為什么被叫會上發(fā)DetachRequest。【測試驗證】案例10:承載未建立導致未接通【問題描述】主叫收到100Trying后未建立承載，使得RRC直接釋放，導致未接通?！締栴}分析】1、主叫在15:46:發(fā)起會話，收到網(wǎng)絡(luò)側(cè)下發(fā)的100Trying后，專有承載一直未建立,10s后RRO放，主叫在15:46:上發(fā)Cancel,導致會

16、話未接通?！締栴}定位】【解決措施】需要核心網(wǎng)查看為什么沒有建立專有承載?！緶y試驗證】案例11:承載異常釋放導致掉話【問題描述】被叫重建立成功后，專有承載突然被釋放，導致掉話?！締栴}分析】1、主叫在10:28:起呼，流程正常，收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing180,UPDATE200主被叫會話正常建立。2、被叫在10:35:發(fā)送重建立，重建立成功，且流程正常，但是在10:35:承載被釋放,導致掉話?！締栴}定位】會話建立后，被叫重建立完成，但是專有承載被釋放，導致掉話。【解決措施】需要核心網(wǎng)確認承載釋放的原因?！緶y試驗證】案例12:信令轉(zhuǎn)發(fā)失敗導致未接i【問題描述】主叫發(fā)起會話請求，網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)，被叫未收到，主叫Cancel,導致未接通?！締栴}分析】主叫在10:03:發(fā)起會話，被叫未收到，直到10:03:主叫Cancel,會話接續(xù)無法繼續(xù),導致未接通。整個過程無線環(huán)境良好，網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)信令。【問題定位】網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)主叫會話請求，使得會話接續(xù)無法繼續(xù)，主叫Cancel,導致未接通?！窘鉀Q措施】需要核心網(wǎng)確認會話信令是否成功轉(zhuǎn)發(fā)?！緶y試驗證】案例13