VoLTE外場測試分析案例

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

2、的580，接續(xù)被中止，導(dǎo)致了會話未接通。3、從 MMEF 發(fā)到 Node B 的 E-RABRELEASECOMMAN 原因上看是 Nas 層 nomal_release ，導(dǎo)致專載 QCI 1 被釋放。4、專載 QCI 1 被釋放，去激活后，被叫發(fā)送 INVITE 580,主叫收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的 INVITE580,會話流程中斷，導(dǎo)致未接通【問題定位】在正常的會話流程中，由于 MMEF 發(fā) E-RAB RELEASE COMMAN 使得 QCI 1 被釋放，導(dǎo)致未 接通?！窘鉀Q措施】需要核心網(wǎng)查看 MM 莊什么情況下會下發(fā) E-RAB RELEASE COMMAND測試驗(yàn)證】1、呼叫過程中，被

3、叫發(fā)送Ringing 180 后，收到網(wǎng)絡(luò)下發(fā)的專載去激活命令,QCI 1被釋放，被叫隨后上報(bào)580 Prec on diti on Failure，主叫同樣收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的案例2：Server Internal Error 500導(dǎo)致的未接通【問題描述】在集團(tuán)測試 LOG 中，存在 Server Internal Error導(dǎo)致的失敗事件，表現(xiàn)為呼叫過程中，終端主動(dòng)收到網(wǎng)絡(luò)側(cè)下發(fā)的 Server Internal Error 500 消息，隨后呼叫中止，出現(xiàn)未接通 事件?！締栴}分析】1、 主叫發(fā)出 UPDATED，被叫收到 UPDATED 回復(fù) UPDATOO,隨后被叫發(fā)送 Ringing

4、180，主叫同時(shí)收到UPDATE 200 和 Ringing 180 。按照正常的信令流程應(yīng)該是先收到 UPDATE 200,再收到 Ringing 180。2、 然后主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE Server Internal Error 5OO.主叫專載被釋放,去激活,導(dǎo)致會話未接通。【問題定位】主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE 500,然后網(wǎng)絡(luò)側(cè)又下發(fā) RRC 重配，釋放掉 QCI 1，然后去激 活,會話流程終止,導(dǎo)致未接通【解決措施】需要核心網(wǎng)確認(rèn),為什么會下發(fā) INVITE 500 ,什么情況下會導(dǎo)致網(wǎng)絡(luò)側(cè)下發(fā) INVITE 500, 隨后的專載釋放是否由 INVITE 50

5、0 導(dǎo)致的測試驗(yàn)證】案例3：軟件對失敗事件的誤判導(dǎo)致統(tǒng)計(jì)錯(cuò) 誤【問題描述】在集團(tuán)測試 LOG 中，存在軟件的誤判而錯(cuò)誤統(tǒng)計(jì)的失敗事件。如在某個(gè)特定時(shí)間點(diǎn)上，信令顯示主被叫正常通話，軟件卻統(tǒng)計(jì)出掉話或未接通事件?！締栴}分析】1、 主叫從 09:42:41 主叫開始呼叫到 09:45:47 掛機(jī)成功，在通話過程中信令流程正常，中 間出現(xiàn)一次 RRC 重建被拒，導(dǎo)致 RRC 釋放，事件表現(xiàn)為掉話，軟件統(tǒng)計(jì)為掉話。2、在 09: 44:主叫收到網(wǎng)絡(luò)側(cè)下發(fā)的 RRC 重建被拒， 主叫隨后發(fā)起 RRC 建立請求， 在 09: 44：15：004,然后因?yàn)?TAU 在 09: 44： 15： 128 RRC

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

7、出現(xiàn)同一次失敗事 件，軟件卻作了多次統(tǒng)計(jì)，導(dǎo)致失敗事件的增多?！締栴}分析】1、 主叫在 10：04：發(fā)出 INVITE 會話請求， 被叫在 10：04：收到網(wǎng)絡(luò)側(cè)下發(fā)的 BYERequest ， 軟件統(tǒng)計(jì)為掉話。查看 BYE Request 中的 CALL-ID，發(fā)現(xiàn)是上次會話的BYE Request2、 被叫在 10：04： 08：230 收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE Request 同時(shí)發(fā)送 Trying 100 ，又 在 10：04：收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE Request 同時(shí)發(fā)送 Trying 100，并在同時(shí)發(fā)送 INVITE 486，軟件統(tǒng)計(jì)為未接通。3、 主叫在收到網(wǎng)絡(luò)

8、側(cè)下發(fā)的 UPDATE200 后，在 10：04：上報(bào) Cancel ，主叫的整個(gè)會話流 程到這里被終止，事件上表現(xiàn)為未接通。且承載都存在【問題定位】通話期間， 被叫收到網(wǎng)絡(luò)下發(fā)的 BYERequest 會被軟件統(tǒng)計(jì)為掉話。 被叫連續(xù)兩次收到網(wǎng)絡(luò) 下發(fā)的 INVITERequest，回復(fù)INVITE 486 Busy Here，由于第一次 INVITE Request 未釋放, 故第二次 INVITE Request 網(wǎng)絡(luò)側(cè)才會下發(fā) INVITE 486 ，流程停止，軟件統(tǒng)計(jì)為未接通。此 時(shí)主叫在進(jìn)行正常的會話接續(xù)，信令流程正常，事件中未出現(xiàn)失敗事件。直到主叫上報(bào) Cancel ，主叫會話流程

9、停止，事件表現(xiàn)為未接通，之前的兩次失敗事件統(tǒng)計(jì)是重復(fù)統(tǒng)計(jì)?！窘鉀Q措施】需要鼎利確認(rèn)對失敗事件的統(tǒng)計(jì)機(jī)制。測試驗(yàn)證】案例5:LTE到2G eSRVCC切換失敗導(dǎo)致的掉話【問題描述】呼叫會話建立后，由于到達(dá)異系統(tǒng)B2 門限，終端上報(bào) B2 事件，網(wǎng)絡(luò)下發(fā) eSRVCC 切換配置命令，但在 2G 側(cè)切入失敗，導(dǎo)致掉話?！締栴}分析】1、被叫上報(bào) B2 事件， 滿足切換門限系統(tǒng)下發(fā) mobility 切換命令， 此時(shí) 4G 的流程已完成，接下來切入 2G網(wǎng)絡(luò)，2G 網(wǎng)絡(luò)下發(fā) TMSI Reallocati on Comma nd 被叫回復(fù) TMSI Reallocati on Complete，此后流程

10、中斷，eSRVC（切換失敗。3、信令上看，4G 流程正常走完且建立會話，被叫切換到2G,但是網(wǎng)絡(luò)下發(fā)TMSIReallocatio n Comma n（導(dǎo)致流程終止，eSRVC（切換失敗，會話流程結(jié)束，懷疑是 2G 問 題。問題定位】4G 流程正常且已正常建立會話，由于 2G 網(wǎng)絡(luò)側(cè)下發(fā) TMSIReallocation Comman 導(dǎo)致切換失敗，會話流程結(jié)束，導(dǎo)致掉話，懷疑是2G 的問題。解決措施】 【測試驗(yàn)證】案例6:TAU過程中RRCConnection Release導(dǎo)致的未接通【問題描述】eSRVCC在越秀區(qū)網(wǎng)格 10 的測試 LOG 中，出現(xiàn)如下的未接通事件：主叫起呼發(fā)出 Inv

11、ite 消息后，在收到網(wǎng)絡(luò)效應(yīng) Trying 100 之前，先收到了網(wǎng)絡(luò)下發(fā)的 RRCConn ection Release 消息，RRC 連接釋放后，接續(xù)被終止，出現(xiàn)了Blocked Call 事件?！締栴}分析】1、通過信令詳細(xì)分析主叫起呼的過程， 可以發(fā)現(xiàn)， 起呼前， 主叫剛完成重選過程， 從 PCI216 小區(qū)重選至 PCI103 小區(qū)，由于源小區(qū)與目標(biāo)小區(qū)處在不同的TAC 主叫發(fā)起了 TAU 請求：2、 在主叫上發(fā) TAU 請求后，未等網(wǎng)絡(luò)回復(fù)ATU Accept，主叫已開始了起呼，上發(fā)Invite消息。然而 Invite 上發(fā)后，主叫同時(shí)收到了網(wǎng)絡(luò)下發(fā)的 ATU Accept 和 R

12、RC ConnectionRelease 消息（因此時(shí)主叫處在非業(yè)務(wù)態(tài)，ATU 更新會伴隨 RRC 連接的釋放），主叫被叫釋放，從而導(dǎo)致了 Blocked Call 事件的發(fā)生：3、 進(jìn)一步分析信令可以發(fā)現(xiàn)，主叫在該測試路段內(nèi)連續(xù)在3 個(gè) TAC（9437、10315、10014） 間進(jìn)行 TAU 更新，其中從 11:42:53 至 11:43:04 就發(fā)生了 4 次，可能在存在 TAC 規(guī)劃不合 理的問題?！締栴}定位】TAC 規(guī)劃不合理。【解決措施】規(guī)劃 TAC案例7:Alerting中eSRVCC失敗導(dǎo)致未接通【問題描述】主叫起呼后，流程正常，達(dá)到eSRVCC 切換門限后收到 eSRVCC

13、 切換命令且?guī)缀跬瑫r(shí)收到Ringing 180 ，主叫未摘機(jī)，由于切換失敗導(dǎo)致未接通?！締栴}分析】1、 主叫在 11：25：起呼， 到 11：25：收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的 Ringing 180，整個(gè)信令流程正常。2、 在主叫幾乎收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的Ringing 180 的同時(shí)，主叫達(dá)到 eSRVCC 切換門限，網(wǎng)絡(luò) 側(cè)在 11：25:下發(fā) eSRVC（切換命令，在切換過程中主叫處于振鈴中，并未摘話，而切 換失敗，導(dǎo)致了未接通。【問題定位】主叫已經(jīng)收到 Ringing 180，處于振鈴狀態(tài)還未摘話，由于在 Alerting 中發(fā)生了 eSRVCC 切 換失敗導(dǎo)致了未接通?！窘鉀Q措施】需要核心網(wǎng)方面幫忙

14、定位?！緶y試驗(yàn)證】案例&CSFB失敗導(dǎo)致未接通【問題描述】主叫起呼后，被叫 CSFB 失敗，主叫直接 Cancel 導(dǎo)致未接通。問題分析】1、 主叫于 15:42:22 發(fā)起 invite ，被叫未收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的 INVITE Request ，但是主叫能 一直收到網(wǎng)絡(luò)側(cè)下發(fā)的INVITE 183、PRACK UPDAT 曰肖息，這些消息被叫并沒有收到也沒有回復(fù)。被叫在 15:42:24 收到網(wǎng)絡(luò)側(cè)下發(fā)的 CSFB request，但 CSFB 到 2G 后從信 令看沒有呼叫相關(guān)的信令交互過程。2、直到 15:42:35 CSFB 失敗，由于收不到被叫的響應(yīng)，主叫主動(dòng)于15:42:53 發(fā)起

15、 CANCLE導(dǎo)致會話未接通?！締栴}定位】主叫發(fā)起會話后，被叫沒有收到會話請求，直接 CSFB CSFB 失敗，主叫一直未收到被叫的 響應(yīng)，直接Cancel ，導(dǎo)致會話未接通?！窘鉀Q措施】需要核心網(wǎng) 查看為什么被叫沒有收到主叫的會話請求，且主叫能收到網(wǎng)絡(luò)側(cè)下發(fā)的 INVITE 180、UPDATEPRACK 肖息。【測試驗(yàn)證】案例9：被叫Detach導(dǎo)致會話未接通【問題描述】主叫發(fā)起會話， 被叫駐留在 2G 未返回 4G,沒有響應(yīng)主叫的會話請求，主叫收不到被叫相應(yīng)，直接 Cancel導(dǎo)致未接通?！締栴}分析】1、主叫在 15: 43:起呼，此時(shí)被叫任然駐留在 2G,由于上一次會話中 CSFB 失

16、敗，并沒有 返回 4G。2、 起呼后，被叫一直無響應(yīng)，沒有與主叫進(jìn)行信令交互，然而主叫能一直收到網(wǎng)絡(luò)側(cè)下發(fā) 的 PRACKUPDATE 肖息。3、 主叫一直收不到被叫的回復(fù)， 被叫在 15:43: 被叫上發(fā) Detach Request ，主叫在 15：43： 上發(fā)Cancel ，取肖會話，導(dǎo)致未接通。【問題定位】被叫停留在 2G 未返回 4G,然后上發(fā) Detach Request ，主叫收不到被叫的回復(fù)， 直接 Can cel , 導(dǎo)致未接通?！窘鉀Q措施】需要核心網(wǎng)查看為什么主叫會話信令流程正常, 被叫卻無法收到主叫的會話請求。 同時(shí)查看 2G 無線側(cè)，為什么被叫會上發(fā) Detach Re

17、quest?！緶y試驗(yàn)證】案例10：承載未建立導(dǎo)致未接通【問題描述】主叫收到 100 Tryi ng 后未建立承載，使得 RRC 直接釋放，導(dǎo)致未接通?！締栴}分析】1、 主叫在 15：46：發(fā)起會話,收到網(wǎng)絡(luò)側(cè)下發(fā)的 100 Trying 后,專有承載一直未建立, 10s 后 RRC 釋放，主叫在 15： 46：上發(fā) Cancel，導(dǎo)致會話未接通。問題定位】專有承載未建立，10s 后 RRC 釋放，導(dǎo)致未接通。解決措施】需要核心網(wǎng)查看為什么沒有建立專有承載?！緶y試驗(yàn)證】案例11：承載異常釋放導(dǎo)致掉話【問題描述】被叫重建立成功后，專有承載突然被釋放，導(dǎo)致掉話。【問題分析】1、 主叫在 10：28：

18、起呼，流程正常，收到網(wǎng)絡(luò)側(cè)轉(zhuǎn)發(fā)的 Ringing 180 ， UPDATE 200，主被 叫會話正常建立。2、 被叫在 10： 35：發(fā)送重建立，重建立成功，且流程正常，但是在10：35：承載被釋放，導(dǎo)致掉話。【問題定位】會話建立后，被叫重建立完成，但是專有承載被釋放，導(dǎo)致掉話?！窘鉀Q措施】需要核心網(wǎng)確認(rèn)承載釋放的原因。測試驗(yàn)證】案例12：信令轉(zhuǎn)發(fā)失敗導(dǎo)致未接通【問題描述】主叫發(fā)起會話請求，網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)，被叫未收到，主叫 Cancel ，導(dǎo)致未接通?！締栴}分析】主叫在 10：03：發(fā)起會話，被叫未收到，直到 10：03：主叫 Cancel ，會話接續(xù)無法繼續(xù)，導(dǎo)致未接通。整個(gè)過程無線環(huán)境良好，網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)信令。【問題定位】網(wǎng)絡(luò)側(cè)未轉(zhuǎn)發(fā)主叫會話請求，使得會話接續(xù)無法繼續(xù)，主叫Cancel ，導(dǎo)致未接通。【解決措施】需要核心網(wǎng)確認(rèn)會話信令是否成