中國移動LTE-VOLTE案例分析匯總

1、中國移動 l te- vol te案例分析匯總-作者 : _-日期 : _廣東移動 4gtd-lte詳細案例分析案例 1：580 precondition failure 導致的未接通?！締栴}描述】在集團測試 log 中，存在 precondition failure 導致的失敗事件，表現(xiàn)為呼叫過程中，終端主動上發(fā)或收到網(wǎng)絡側(cè)下發(fā)的 580 precondition failure消息，隨后呼叫中止，出現(xiàn)未接通事件。log 文件名：_ue1.lte_ue2.ltemo ue:mt ue:時間： 10 ： 16 ：14.320【問題分析】1、 呼叫過程中，被叫發(fā)送ringing 180 后，收到

2、網(wǎng)絡下發(fā)的專載去激活命令，釋放，被叫隨后上報580 preconditionfailure，主叫同樣收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的息，呼叫接續(xù)中止，導致未接通。qci 1 被580 消2、 從信令中可以看到，被叫回復ringing 180 且主叫也已經(jīng)收到ringing 180，被叫隨后收到網(wǎng)絡側(cè)下發(fā)的rrc 重配，攜帶有qci 1 被釋放的信息，被叫去激活專有承載。由于專載已被釋放，業(yè)務資源已不存在，所以被叫上發(fā)580preconditionfailure 失敗消息。主叫收到網(wǎng)絡側(cè)下發(fā)的580，接續(xù)被中止，導致了會話未接通。3、 從 mme下發(fā)到node b 的e-rab releasecommand ，

3、原因上看是nomal_release ，導致專載qci 1 被釋放。nas層4、 專載qci 1 被釋放，去激活后，被叫發(fā)送invite 580，主叫收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的invite 580，會話流程中斷，導致未接通【問題定位】在正常的會話流程中，由于 mme 下發(fā) e-rab release command ，使得 qci 1 被釋放，導致未接通?！窘鉀Q措施】需要核心網(wǎng)查看mme 在什么情況下會下發(fā)e-rab release command ?！緶y試驗證】案例 2：server internal error 500 導致的未接通【問題描述】在集團測試 log 中，存在 server intern

4、al error 導致的失敗事件，表現(xiàn)為呼叫過程中，終端主動收到網(wǎng)絡側(cè)下發(fā)的 server internal error 500消息，隨后呼叫中止，出現(xiàn)未接通事件。log 文件名：.lte95000612.ltemo ue:mt ue:時間： 10 ： 19 ：29.051【問題分析】1、 主叫發(fā)出update 后，被叫收到180，主叫同時收到update 200update 并回復update 200，隨后被叫發(fā)送ringing和 ringing 180。按照正常的信令流程應該是先收到update 200，再收到ringing 180。2、 然后主叫收到網(wǎng)絡側(cè)下發(fā)的 invite serve

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

6、log 文件名：95000606mo ue:mt ue:時間： 09 ： 44 ：14.0【問題分析】1、 主叫從 09:42:41 主叫開始呼叫到 09:45:47 掛機成功，在通話過程中信令流程正常，中間出現(xiàn)一次 rrc重建被拒，導致 rrc釋放，事件表現(xiàn)為掉話，軟件統(tǒng)計為掉話。2、 在 09：44： 14.910 主叫收到網(wǎng)絡側(cè)下發(fā)的rrc 重建被拒，主叫隨后發(fā)起rrc建立請求，在 09： 44：15： 004，然后因為了，軟件統(tǒng)計為掉話。隨后主叫又發(fā)起 rrc 重建被拒到 rrc 連接成功不到明會話保持正常。tau，在 09：44： 15： 128 rrc connection rel

7、easerrc連接，且在09： 44： 15.659 重建完成，從1s，且默認承載和專有承載均保持，未被釋放，證3、 到最后結(jié)束通話正常掛機都沒有出現(xiàn)失敗事件【問題定位】主叫接通后，在沒有收到通話結(jié)束的情況下，中間出現(xiàn) rrc connection release，軟件判斷為掉線，此次是在會話建立后出現(xiàn)，軟件統(tǒng)計為掉話【解決措施】需要鼎利修改判斷事件失敗的機制【測試驗證】案例 4：軟件對失敗事件的重復統(tǒng)計【問題描述】軟件對于失敗事件存在重復統(tǒng)計的問題，在集團測試問題統(tǒng)計表中，多次出現(xiàn)同一次失敗事件，軟件卻作了多次統(tǒng)計，導致失敗事件的增多。log 文件名：95000606mo ue:mt ue:

8、時間： 10 ： 04 ：08.0【問題分析】1、 主叫在10： 04： 04.642 發(fā)出 invite發(fā)的 bye request，軟件統(tǒng)計為掉話。會話請求，被叫在10： 04： 08.261收到網(wǎng)絡側(cè)下查看 bye request 中的 call-id ，發(fā)現(xiàn)是上次會話的bye request2、 被叫在 10： 04：08： 230 收到網(wǎng)絡側(cè)下發(fā)的invite request 同時發(fā)送trying 100，又在10： 04： 08.261 收到網(wǎng)絡側(cè)下發(fā)的 invite request 同時發(fā)送 trying 100，并在同時發(fā)送 invite 486，軟件統(tǒng)計為未接通。3、 主叫在

9、收到網(wǎng)絡側(cè)下發(fā)的 update 200后，在 10： 04： 24.845 上報 cancel，主叫的整個會話流程到這里被終止，事件上表現(xiàn)為未接通。且承載都存在【問題定位】通話期間，被叫收到網(wǎng)絡下發(fā)的 bye request會被軟件統(tǒng)計為掉話。被叫連續(xù)兩次收到網(wǎng)絡下發(fā)的 invite request，回復 invite 486 busy here ，由于第一次 invite request 未釋放，故第二次 invite request 網(wǎng)絡側(cè)才會下發(fā) invite486，流程停止，軟件統(tǒng)計為未接通。此時主叫在進行正常的會話接續(xù)，信令流程正常，事件中未出現(xiàn)失敗事件。直到主叫上報 cancel，

10、主叫會話流程停止，事件表現(xiàn)為未接通，之前的兩次失敗事件統(tǒng)計是重復統(tǒng)計?！窘鉀Q措施】需要鼎利確認對失敗事件的統(tǒng)計機制。【測試驗證】案例 5：lte到 2g esrvcc切換失敗導致的掉話【問題描述】呼叫會話建立后，由于到達異系統(tǒng) b2 門限，終端上報 b2 事件，網(wǎng)絡下發(fā) esrvcc 切換配置命令，但在 2g 側(cè)切入失敗，導致掉話。log 文件名：95000605.lte.ltemo ue:mt ue:時間： 11 ： 16 ：42 ： 311【問題分析】1、 被叫上報 b2 事件，滿足切換門限系統(tǒng)下發(fā)mobility 切換命令，此時4g 的流程已完成，接下來切入 2g 網(wǎng)絡， 2g 網(wǎng)絡下發(fā)

11、 tmsi reallocation command，被叫回復 tmsi reallocation complete，此后流程中斷， esrvcc 切換失敗。3、 信令上看，4g 流程正常走完且建立會話，被叫切換到2g，但是網(wǎng)絡下發(fā)reallocation command 導致流程終止，esrvcc切換失敗，會話流程結(jié)束，懷疑是tmsi2g 問題?！締栴}定位】4g 流程正常且已正常建立會話，由于2g 網(wǎng)絡側(cè)下發(fā) tmsi reallocationcommand導致 esrvcc 切換失敗，會話流程結(jié)束，導致掉話，懷疑是2g 的問題?！窘鉀Q措施】下周準備復側(cè)，準備定位。【測試驗證】案 例6 ：t

12、au 過 程 中rrc connectionrelease導致的未接通【問題描述】在越秀區(qū)網(wǎng)格 10 的測試 log 中，出現(xiàn)如下的未接通事件：主叫起呼發(fā)出 invite 消息后，在收到網(wǎng)絡效應 trying 100 之前，先收到了網(wǎng)絡下發(fā)的 rrc connection release消息， rrc 連接釋放后，接續(xù)被終止，出現(xiàn)了 blocked call 事件。【問題分析】1、通過信令詳細分析主叫起呼的過程，可以發(fā)現(xiàn)，起呼前，主叫剛完成重選過程，從 pci216 小區(qū)重選至 pci103 小區(qū)，由于源小區(qū)與目標小區(qū)處在不同的 tac ，主叫發(fā)起了 tau 請求：2、在主叫上發(fā) tau 請求

13、后，未等網(wǎng)絡回復 atu accept ，主叫已開始了起呼，上發(fā) invite 消息。然而 invite 上發(fā) 0.172s后，主叫同時收到了網(wǎng)絡下發(fā)的atu accept 和 rrc connection release消息（因此時主叫處在非業(yè)務態(tài)，atu 更新會伴隨 rrc 連接的釋放），主叫被叫釋放，從而導致了 blocked call 事件的發(fā)生：3、進一步分析信令可以發(fā)現(xiàn)，主叫在該測試路段內(nèi)連續(xù)在3 個 tac （ 9437、10315、10014）間進行 tau 更新，其中從 11:42:53 至 11:43:04 就發(fā)生了 4 次，可能在存在 tac 規(guī)劃不合理的問題?！締栴}定位

14、】【解決措施】【測試驗證】案例 7： alerting 中 esrvcc失敗導致未接通【問題描述】主叫起呼后，流程正常，達到 esrvcc 切換門限后收到 esrvcc 切換命令且?guī)缀跬瑫r收到 ringing 180，主叫未摘機，由于切換失敗導致未接通。log 文件名：95000605.lte.ltemo ue:mt ue:時間： 11 ： 25 ：28 ： 189【問題分析】1、 主叫在 11： 25： 26.130起呼，到11： 25： 28.204收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的ringing 180，整個信令流程正常2、 在主叫幾乎收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的ringing 180 的同時，主叫達到esrvcc切

15、換門限，網(wǎng)絡側(cè)在 11： 25： 28.189 下發(fā) esrvcc切換命令，在切換過程中主叫處于振鈴中，并未摘話，而切換失敗，導致了未接通?！締栴}定位】主叫已經(jīng)收到 ringing 180，處于振鈴狀態(tài)還未摘話，由于在alerting中發(fā)生了esrvcc 切換失敗導致了未接通【解決措施】需要核心網(wǎng)方面幫忙定位【測試驗證】案例 8：csfb失敗導致未接通【問題描述】主叫起呼后，被叫csfb 失敗，主叫直接 cancel 導致未接通log 文件名：.lte95000606.ltemo ue:mt ue:時間： 15 ： 42 ：53 ： 063【問題分析】1、 主叫于15:42:22 發(fā)起 inv

16、ite ，被叫未收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的invite request，但是主叫能一直收到網(wǎng)絡側(cè)下發(fā)的invite 183 、 prack、 update消息，這些消息被叫并沒有收到也沒有回復。被叫在15:42:24 收到網(wǎng)絡側(cè)下發(fā)的csfb request，但 csfb到 2g 后從信令看沒有呼叫相關的信令交互過程2、 直 到15:42:35csfb 失敗 ，由 于收 不到 被叫 的響 應， 主叫 主動 于15:42:53發(fā)起cancle。導致會話未接通?！締栴}定位】主叫發(fā)起會話后，被叫沒有收到會話請求，直接 csfb， csfb 失敗，主叫一直未收到被叫的響應，直接 cancel，導致會話未接通?！?/p>

17、解決措施】需要核心網(wǎng) 查看為什么被叫沒有收到主叫的會話請求，且主叫能收到網(wǎng)絡側(cè)下發(fā)的 invite 180 、update 、 prack 消息。【測試驗證】案例 9：被叫 detach 導致會話未接通【問題描述】主叫發(fā)起會話，被叫駐留在 2g 未返回 4g，沒有響應主叫的會話請求，主叫收不到被叫相應，直接 cancel 導致未接通。log 文件名：.lte95000606.ltemo ue:mt ue:時間： 15 ： 43 ：37 ： 999【問題分析】1、 主叫在15 ：43：08.657起呼，此時被叫任然駐留在2g，由于上一次會話中csfb 失敗，并沒有返回4g。2、 起呼后，被叫一直

18、無響應，沒有與主叫進行信令交互，然而主叫能一直收到網(wǎng)絡側(cè)下發(fā)的 prack、 update消息。3、 主叫一直收不到被叫的回復，被叫在15:43:30.449 被叫上發(fā)detachrequest，主叫在15： 43： 37.999 上發(fā) cancel，取消會話，導致未接通【問題定位】被叫停留在 2g 未返回 4g，然后上發(fā) detach request，主叫收不到被叫的回復，直接 cancel，導致未接通【解決措施】需要核心網(wǎng)查看為什么主叫會話信令流程正常，被叫卻無法收到主叫的會話請求。同時查看 2g 無線側(cè)，為什么被叫會上發(fā) detach request?！緶y試驗證】案例 10：承載未建立導

19、致未接通【問題描述】主叫收到 100 trying 后未建立承載，使得rrc 直接釋放，導致未接通log 文件名：95000605.lte.ltemo ue:mt ue:時間： 15 ： 46 ：36 ： 271【問題分析】1、 主叫在建立，15：46 ：19.079 發(fā)起會話，收到網(wǎng)絡側(cè)下發(fā)的10s 后 rrc釋放，主叫在15：46： 36.271 上發(fā)100 trying 后，專有承載一直未cancel，導致會話未接通【問題定位】專有承載未建立， 10s后 rrc 釋放，導致未接通【解決措施】需要核心網(wǎng)查看為什么沒有建立專有承載【測試驗證】案例 11：承載異常釋放導致掉話【問題描述】被叫重

20、建立成功后，專有承載突然被釋放，導致掉話log 文件名：95000605.lte.ltemo ue:mt ue:時間： 10 ： 35 ：41 ： 981【問題分析】1、 主叫在10 ： 28： 06.903 起呼，流程正常，收到網(wǎng)絡側(cè)轉(zhuǎn)發(fā)的200，主被叫會話正常建立。ringing 180， update2、 被叫在10 ： 35： 38.253 發(fā)送重建立，重建立成功，且流程正常，但是在10： 35 ：41.981 承載被釋放，導致掉話【問題定位】會話建立后，被叫重建立完成，但是專有承載被釋放，導致掉話【解決措施】需要核心網(wǎng)確認承載釋放的原因【測試驗證】案例 12：信令轉(zhuǎn)發(fā)失敗導致未接通【問題