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 被釋放，導致未接通。【解決措施】需要核心網(wǎng)查看mme 在什么情況下會下發(fā)e-rab release command 。【測試驗證】案例 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)計。【解決措施】需要鼎利確認對失敗事件的統(tǒng)計機制?！緶y試驗證】案例 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 的問題。【解決措施】下周準備復側(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 消息?！緶y試驗證】案例 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ā)失敗導致未接通【問題