VoLTE測(cè)試案例分析

1、案例1：580 Precondition Failure導(dǎo)致的未接通?！締?wèn)題描述】在集團(tuán)測(cè)試LOG中，存在Precondition Failure導(dǎo)致的失敗事件，表現(xiàn)為呼叫過(guò)程中，終端主動(dòng)上發(fā)或收到網(wǎng)絡(luò)側(cè)下發(fā)的580 Precondition Failure消息，隨后呼叫中止，出現(xiàn)未接通事件。Log文件名：9100060920150322101533MS2_UE1.lte9100060920150322101533MS2_UE2.lteMO UE:T UE:間：10：16：14.320【問(wèn)題分析】1、 呼叫過(guò)程中，被叫發(fā)送Ringing 18

2、0后，收到網(wǎng)絡(luò)下發(fā)的專(zhuān)載去激活命令，QCI 1被釋放，被叫隨后上報(bào)580 Precondition Failure，主叫同樣收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的580消息，呼叫接續(xù)中止，導(dǎo)致未接通。 2、 從信令中可以看到，被叫回復(fù)Ringing 180且主叫也已經(jīng)收到Ringing 180，被叫隨后收到網(wǎng)絡(luò)側(cè)下發(fā)的RRC重配，攜帶有QCI 1被釋放的信息，被叫去激活專(zhuān)有承載。由于專(zhuān)載已被釋放，業(yè)務(wù)資源已不存在，所以被叫上發(fā)580 Precondition Failure失敗消息。主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的580，接續(xù)被中止，導(dǎo)致了會(huì)話未接通。3、 從MME下發(fā)到Node B的E-RAB RELEASE COMMAND

3、，原因上看是Nas層nomal_release，導(dǎo)致專(zhuān)載QCI 1被釋放。4、 專(zhuān)載QCI 1被釋放，去激活后，被叫發(fā)送INVITE 580，主叫收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的INVITE 580，會(huì)話流程中斷，導(dǎo)致未接通【問(wèn)題定位】在正常的會(huì)話流程中，由于MME下發(fā)E-RAB RELEASE COMMAND，使得QCI 1被釋放，導(dǎo)致未接通。【解決措施】需要核心網(wǎng)查看MME在什么情況下會(huì)下發(fā)E-RAB RELEASE COMMAND?！緶y(cè)試驗(yàn)證】案例2：Server Internal Error 500導(dǎo)致的未接通【問(wèn)題描述】在集團(tuán)測(cè)試LOG中，存在Server Internal Error 導(dǎo)致的失敗事

4、件，表現(xiàn)為呼叫過(guò)程中，終端主動(dòng)收到網(wǎng)絡(luò)側(cè)下發(fā)的Server Internal Error 500消息，隨后呼叫中止，出現(xiàn)未接通事件。Log文件名：9500061120150322092042ms1.lte9500061220150322092042ms1.lteMO UE:T UE:間：10：19：29.051【問(wèn)題分析】1、 主叫發(fā)出UPDATE后，被叫收到UPDATE并回復(fù)UPDATE 200，隨后被叫發(fā)送Ringing 180，主叫同時(shí)收到UPDATE 200和Ringing 180。按照正常的信令流程應(yīng)該是先收到UPDATE 200，

5、再收到Ringing 180。2、 然后主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE Server Internal Error 500.主叫專(zhuān)載被釋放，去激活，導(dǎo)致會(huì)話未接通?！締?wèn)題定位】主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE 500，然后網(wǎng)絡(luò)側(cè)又下發(fā)RRC重配，釋放掉QCI 1，然后去激活，會(huì)話流程終止，導(dǎo)致未接通【解決措施】需要核心網(wǎng)確認(rèn)，為什么會(huì)下發(fā)INVITE 500，什么情況下會(huì)導(dǎo)致網(wǎng)絡(luò)側(cè)下發(fā)INVITE 500，隨后的專(zhuān)載釋放是否由INVITE 500導(dǎo)致的【測(cè)試驗(yàn)證】案例3：軟件對(duì)失敗事件的誤判導(dǎo)致統(tǒng)計(jì)錯(cuò)誤【問(wèn)題描述】在集團(tuán)測(cè)試LOG中，存在軟件的誤判而錯(cuò)誤統(tǒng)計(jì)的失敗事件。如在某個(gè)特定時(shí)間點(diǎn)上

6、，信令顯示主被叫正常通話，軟件卻統(tǒng)計(jì)出掉話或未接通事件。Log文件名：9500060520150320091421ms1.lte9500060620150320091421ms1.lteMO UE:T UE:間：09：44：14.0【問(wèn)題分析】1、 主叫從09:42:41主叫開(kāi)始呼叫到09:45:47掛機(jī)成功，在通話過(guò)程中信令流程正常，中間出現(xiàn)一次RRC重建被拒，導(dǎo)致RRC釋放，事件表現(xiàn)為掉話，軟件統(tǒng)計(jì)為掉話。2、 在09：44：14.910主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的RRC重建被拒，主叫隨后發(fā)起RRC建立請(qǐng)求，在09：44：15：004，然后因?yàn)門(mén)

7、AU，在09：44：15：128 RRC Connection Release了，軟件統(tǒng)計(jì)為掉話。隨后主叫又發(fā)起RRC連接，且在09：44：15.659重建完成，從RRC重建被拒到RRC連接成功不到1s，且默認(rèn)承載和專(zhuān)有承載均保持，未被釋放，證明會(huì)話保持正常。3、 到最后結(jié)束通話正常掛機(jī)都沒(méi)有出現(xiàn)失敗事件【問(wèn)題定位】主叫接通后，在沒(méi)有收到通話結(jié)束的情況下，中間出現(xiàn)RRC Connection Release，軟件判斷為掉線，此次是在會(huì)話建立后出現(xiàn)，軟件統(tǒng)計(jì)為掉話【解決措施】需要鼎利修改判斷事件失敗的機(jī)制【測(cè)試驗(yàn)證】案例4：軟件對(duì)失敗事件的重復(fù)統(tǒng)計(jì)【問(wèn)題描述】軟件對(duì)于失敗事件存在重復(fù)統(tǒng)計(jì)的問(wèn)題，

8、在集團(tuán)測(cè)試問(wèn)題統(tǒng)計(jì)表中，多次出現(xiàn)同一次失敗事件，軟件卻作了多次統(tǒng)計(jì)，導(dǎo)致失敗事件的增多。Log文件名：9500060520150320091421ms1.lte9500060620150320091421ms1.lteMO UE:T UE:間：10：04：08.0【問(wèn)題分析】1、 主叫在10：04：04.642發(fā)出INVITE會(huì)話請(qǐng)求，被叫在10：04：08.261收到網(wǎng)絡(luò)側(cè)下發(fā)的BYE Request，軟件統(tǒng)計(jì)為掉話。 查看BYE Request中的CALL-ID，發(fā)現(xiàn)是上次會(huì)話的BYE Request2、 被叫在10：04：08：230收

9、到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE Request同時(shí)發(fā)送Trying 100，又在10：04：08.261收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE Request同時(shí)發(fā)送Trying 100，并在同時(shí)發(fā)送INVITE 486，軟件統(tǒng)計(jì)為未接通。3、 主叫在收到網(wǎng)絡(luò)側(cè)下發(fā)的UPDATE 200后，在10：04：24.845上報(bào)Cancel，主叫的整個(gè)會(huì)話流程到這里被終止，事件上表現(xiàn)為未接通。且承載都存在【問(wèn)題定位】通話期間，被叫收到網(wǎng)絡(luò)下發(fā)的BYE Request會(huì)被軟件統(tǒng)計(jì)為掉話。被叫連續(xù)兩次收到網(wǎng)絡(luò)下發(fā)的INVITE Request，回復(fù)INVITE 486 Busy Here，由于第一次INVITE Req

10、uest未釋放，故第二次INVITE Request網(wǎng)絡(luò)側(cè)才會(huì)下發(fā)INVITE 486，流程停止，軟件統(tǒng)計(jì)為未接通。此時(shí)主叫在進(jìn)行正常的會(huì)話接續(xù)，信令流程正常，事件中未出現(xiàn)失敗事件。直到主叫上報(bào)Cancel，主叫會(huì)話流程停止，事件表現(xiàn)為未接通，之前的兩次失敗事件統(tǒng)計(jì)是重復(fù)統(tǒng)計(jì)?！窘鉀Q措施】需要鼎利確認(rèn)對(duì)失敗事件的統(tǒng)計(jì)機(jī)制?！緶y(cè)試驗(yàn)證】案例5：LTE到2G eSRVCC切換失敗導(dǎo)致的掉話【問(wèn)題描述】呼叫會(huì)話建立后，由于到達(dá)異系統(tǒng)B2門(mén)限，終端上報(bào)B2事件，網(wǎng)絡(luò)下發(fā)eSRVCC切換配置命令，但在2G側(cè)切入失敗，導(dǎo)致掉話。Log文件名：9500060520150320110855ms1.lte950

11、0060620150320110855ms1.lteMO UE:T UE:間：11：16：42：311【問(wèn)題分析】1、被叫上報(bào)B2事件，滿足切換門(mén)限系統(tǒng)下發(fā)mobility切換命令，此時(shí)4G的流程已完成，接下來(lái)切入2G網(wǎng)絡(luò)，2G網(wǎng)絡(luò)下發(fā)TMSI Reallocation Command，被叫回復(fù)TMSI Reallocation Complete，此后流程中斷，eSRVCC切換失敗。3、 信令上看，4G流程正常走完且建立會(huì)話，被叫切換到2G，但是網(wǎng)絡(luò)下發(fā)TMSI Reallocation Command導(dǎo)致流程終止，eSRVCC切換失敗，會(huì)話

12、流程結(jié)束，懷疑是2G問(wèn)題。【問(wèn)題定位】4G流程正常且已正常建立會(huì)話，由于2G網(wǎng)絡(luò)側(cè)下發(fā)TMSI Reallocation Command導(dǎo)致eSRVCC切換失敗，會(huì)話流程結(jié)束，導(dǎo)致掉話，懷疑是2G的問(wèn)題?！窘鉀Q措施】下周準(zhǔn)備復(fù)側(cè)，準(zhǔn)備定位?！緶y(cè)試驗(yàn)證】案例6： TAU過(guò)程中RRC Connection Release導(dǎo)致的未接通【問(wèn)題描述】在越秀區(qū)網(wǎng)格10的測(cè)試LOG中，出現(xiàn)如下的未接通事件：主叫起呼發(fā)出Invite消息后，在收到網(wǎng)絡(luò)效應(yīng)Trying 100之前，先收到了網(wǎng)絡(luò)下發(fā)的RRC Connection Release消息，RRC連接釋放后，接續(xù)被終止，出現(xiàn)了Blocked Call事件

13、?！締?wèn)題分析】1、通過(guò)信令詳細(xì)分析主叫起呼的過(guò)程，可以發(fā)現(xiàn)，起呼前，主叫剛完成重選過(guò)程，從PCI216小區(qū)重選至PCI103小區(qū)，由于源小區(qū)與目標(biāo)小區(qū)處在不同的TAC，主叫發(fā)起了TAU請(qǐng)求：2、在主叫上發(fā)TAU請(qǐng)求后，未等網(wǎng)絡(luò)回復(fù)ATU Accept，主叫已開(kāi)始了起呼，上發(fā)Invite消息。然而Invite上發(fā)0.172s后，主叫同時(shí)收到了網(wǎng)絡(luò)下發(fā)的ATU Accept和RRC Connection Release消息（因此時(shí)主叫處在非業(yè)務(wù)態(tài)，ATU更新會(huì)伴隨RRC連接的釋放），主叫被叫釋放，從而導(dǎo)致了Blocked Call事件的發(fā)生：3、進(jìn)一步分析信令可以發(fā)現(xiàn)，主叫在該測(cè)試路段內(nèi)連續(xù)在3個(gè)

14、TAC（9437、10315、10014）間進(jìn)行TAU更新，其中從11:42:53至11:43:04就發(fā)生了4次，可能在存在TAC規(guī)劃不合理的問(wèn)題?！締?wèn)題定位】【解決措施】【測(cè)試驗(yàn)證】案例7：Alerting中eSRVCC失敗導(dǎo)致未接通【問(wèn)題描述】主叫起呼后，流程正常，達(dá)到eSRVCC切換門(mén)限后收到eSRVCC切換命令且?guī)缀跬瑫r(shí)收到Ringing 180，主叫未摘機(jī)，由于切換失敗導(dǎo)致未接通。Log文件名：9500060520150320110855ms1.lte9500060620150320110855ms1.lteMO UE:T UE:間

15、：11：25：28：189【問(wèn)題分析】1、 主叫在11：25：26.130起呼，到11：25：28.204收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing 180，整個(gè)信令流程正常2、 在主叫幾乎收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing 180的同時(shí)，主叫達(dá)到eSRVCC切換門(mén)限，網(wǎng)絡(luò)側(cè)在11：25：28.189下發(fā)eSRVCC切換命令，在切換過(guò)程中主叫處于振鈴中，并未摘話，而切換失敗，導(dǎo)致了未接通?！締?wèn)題定位】主叫已經(jīng)收到Ringing 180，處于振鈴狀態(tài)還未摘話，由于在Alerting中發(fā)生了eSRVCC 切換失敗導(dǎo)致了未接通【解決措施】需要核心網(wǎng)方面幫忙定位【測(cè)試驗(yàn)證】案例8：CSFB失敗導(dǎo)致未接通【問(wèn)題描述】主

16、叫起呼后，被叫CSFB失敗，主叫直接Cancel導(dǎo)致未接通Log文件名：9500060520150321151616ms1.lte9500060620150321151616ms1.lteMO UE:T UE:間：15：42：53：063【問(wèn)題分析】1、 主叫于15:42:22發(fā)起invite，被叫未收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的INVITE Request，但是主叫能一直收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE 183 、PRACK、UPDATE消息，這些消息被叫并沒(méi)有收到也沒(méi)有回復(fù)。被叫在15:42:24收到網(wǎng)絡(luò)側(cè)下發(fā)的CSFB request，但CSFB到2G后

17、從信令看沒(méi)有呼叫相關(guān)的信令交互過(guò)程2、 直到15:42:35 CSFB失敗，由于收不到被叫的響應(yīng)，主叫主動(dòng)于15:42:53發(fā)起CANCLE。導(dǎo)致會(huì)話未接通?！締?wèn)題定位】主叫發(fā)起會(huì)話后，被叫沒(méi)有收到會(huì)話請(qǐng)求，直接CSFB，CSFB失敗，主叫一直未收到被叫的響應(yīng)，直接Cancel，導(dǎo)致會(huì)話未接通?！窘鉀Q措施】需要核心網(wǎng) 查看為什么被叫沒(méi)有收到主叫的會(huì)話請(qǐng)求，且主叫能收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE 180、UPDATE、PRACK消息?！緶y(cè)試驗(yàn)證】案例9：被叫Detach導(dǎo)致會(huì)話未接通【問(wèn)題描述】主叫發(fā)起會(huì)話，被叫駐留在2G未返回4G，沒(méi)有響應(yīng)主叫的會(huì)話請(qǐng)求，主叫收不到被叫相應(yīng)，直接Cancel導(dǎo)致

18、未接通。Log文件名：9500060520150321151616ms1.lte9500060620150321151616ms1.lteMO UE:T UE:間：15：43：37：999【問(wèn)題分析】1、 主叫在15：43：08.657起呼，此時(shí)被叫任然駐留在2G，由于上一次會(huì)話中CSFB失敗，并沒(méi)有返回4G。2、 起呼后，被叫一直無(wú)響應(yīng)，沒(méi)有與主叫進(jìn)行信令交互，然而主叫能一直收到網(wǎng)絡(luò)側(cè)下發(fā)的PRACK、UPDATE消息。3、 主叫一直收不到被叫的回復(fù)，被叫在15:43:30.449被叫上發(fā)Detach Request，主叫在15：43：37

19、.999上發(fā)Cancel，取消會(huì)話，導(dǎo)致未接通【問(wèn)題定位】被叫停留在2G未返回4G，然后上發(fā)Detach Request，主叫收不到被叫的回復(fù)，直接Cancel，導(dǎo)致未接通【解決措施】需要核心網(wǎng)查看為什么主叫會(huì)話信令流程正常，被叫卻無(wú)法收到主叫的會(huì)話請(qǐng)求。同時(shí)查看2G無(wú)線側(cè)，為什么被叫會(huì)上發(fā)Detach Request?！緶y(cè)試驗(yàn)證】案例10：承載未建立導(dǎo)致未接通【問(wèn)題描述】主叫收到100 Trying 后未建立承載，使得 RRC直接釋放，導(dǎo)致未接通Log文件名：9500060520150322145725ms1.lte9500060620150322145725ms1.lteMO UE: 17

20、820500396MT UE:間：15：46：36：271【問(wèn)題分析】1、 主叫在15：46：19.079發(fā)起會(huì)話，收到網(wǎng)絡(luò)側(cè)下發(fā)的100 Trying后，專(zhuān)有承載一直未建立，10s后RRC釋放，主叫在15：46：36.271上發(fā)Cancel，導(dǎo)致會(huì)話未接通【問(wèn)題定位】專(zhuān)有承載未建立，10s后RRC釋放，導(dǎo)致未接通【解決措施】需要核心網(wǎng)查看為什么沒(méi)有建立專(zhuān)有承載【測(cè)試驗(yàn)證】案例11：承載異常釋放導(dǎo)致掉話【問(wèn)題描述】被叫重建立成功后，專(zhuān)有承載突然被釋放，導(dǎo)致掉話Log文件名：9500060520150320102801ms1.lte9500060620150320102

21、801ms1.lteMO UE:T UE:間：10：35：41：981【問(wèn)題分析】1、 主叫在10：28：06.903起呼，流程正常，收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing 180，UPDATE 200，主被叫會(huì)話正常建立。2、 被叫在10：35：38.253發(fā)送重建立，重建立成功，且流程正常，但是在10：35：41.981承載被釋放，導(dǎo)致掉話【問(wèn)題定位】會(huì)話建立后，被叫重建立完成，但是專(zhuān)有承載被釋放，導(dǎo)致掉話【解決措施】需要核心網(wǎng)確認(rèn)承載釋放的原因【測(cè)試驗(yàn)證】案例12：信令轉(zhuǎn)發(fā)失敗導(dǎo)致未接通【問(wèn)題描述】主叫發(fā)起會(huì)話請(qǐng)求，網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)，被叫未收到，主叫Cancel，導(dǎo)致未接通Log文件名：9