中国移动LTEVOLTE案例分析汇总

1、广东移动4GTD-LTE详细案例分析案例 1: 580 Precondition Failure 导致的未接通。【问题描述】在集团测试LOG中，存在Precondition Failure导致的失败事件，表现为呼叫过程中，终端主 动上发或收到网络侧下发的580 Precondition Failure消息，随后呼叫中止，出现未接通事件。Log文件名：_UE1.lte_UE2.lteMO UE:MT UE:时间：10 : 16 : 14.320【问题分析】1、 呼叫过程中，被叫发送 Ringing 180后，收到网络下发的专载去激活命令，QCI 1被 释放，被叫随后上报580 Precondit

2、ion Failure，主叫同样收到网络侧转发的 580消息， 呼叫接续中止，导致未接通。2、 从信令中可以看到，被叫回复Ringing 180且主叫也已经收到 Ringing 180，被叫随后 收到网络侧下发的 RRC重配，携带有 QCI 1被释放的信息，被叫去激活专有承载。由于专载已被释放，业务资源已不存在，所以被叫上发580 Precondition Failure失败消息。主叫收到网络侧下发的580，接续被中止，导致了会话未接通。3、从MME下发到 Node B的E-RAB RELEASE COMMAND原因上看是 Nas层 nomal_release，导致专载 QCI 1被释放。4、

3、 专载QCI 1被释放，去激活后，被叫发送INVITE 580,主叫收到网络侧转发的INVITE 580,会话流程中断，导致未接通【问题定位】在正常的会话流程中，由于MME下发E-RAB RELEASE COMMAND使得QCI 1被释放，导致未接通。【解决措施】需要核心网查看 MME在什么情况下会下发E-RAB RELEASE COMMAND【测试验证】案例2： Server Internal Error 500导致的未接通【问题描述】在集团测试LOG中，存在Server Internal Error导致的失败事件，表现为呼叫过程中，终端 主动收到网络侧下发的Server Internal

4、Error 500消息，随后呼叫中止，出现未接通事件。Log文件名：.lte95000612.lteMO UE:MT UE:时间：10 : 19 : 29.051【问题分析】1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE 20Q随后被叫发送 Ringing 180, 主叫同时收到 UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE200,再收到 Ringing 180。2、然后主叫收到网络侧下发的INVITE Server Internal Error 500.主叫专载被释放，去激活，导致会话未接通。【问题定位】主叫收到网络侧下发的IN

5、VITE 500,然后网络侧又下发 RRC重配，释放掉 QCI 1然后去激 活，会话流程终止，导致未接通【解决措施】需要核心网确认,为什么会下发INVITE 500,什么情况下会导致网络侧下发INVITE 500,随后的专载释放是否由 INVITE 500导致的【测试验证】案例 3：软件对失败事件的误判导致统计错误【问题描述】在集团测试LOG中，存在软件的误判而错误统计的失败事件。如在某个特定时间点上，信 令显示主被叫正常通话,软件却统计出掉话或未接通事件。Log 文件名：95000606MO UE:MT UE:时间： 09 ：44 ： 14.0【问题分析】1、主叫从 09:42:41主叫开始

6、呼叫到 09:45:47 挂机成功, 在通话过程中信令流程正常, 中间 出现一次RRC重建被拒，导致 RRC释放，事件表现为掉话，软件统计为掉话。2、 在09: 44： 14.910主叫收到网络侧下发的 RRC重建被拒，主叫随后发起 RRC建立请求， 在 09: 44： 15 : 004，然后因为 TAU,在 09： 44： 15 : 128 RRC Conn ection Release了， 软件统计为掉话。随后主叫又发起RRC连接，且在09: 44： 15.659重建完成，从 RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。3、到最后结束通话

7、正常挂机都没有出现失败事件【问题定位】主叫接通后，在没有收到通话结束的情况下，中间出现RRC Connection Release软件判断为掉线，此次是在会话建立后出现，软件统计为掉话【解决措施 】需要鼎利修改判断事件失败的机制【测试验证】案例 4：软件对失败事件的重复统计【问题描述】软件对于失败事件存在重复统计的问题， 在集团测试问题统计表中， 多次出现同一次失败事 件，软件却作了多次统计，导致失败事件的增多。Log 文件名：95000606MO UE:MT UE:时间： 10 ：04 ： 08.0【问题分析】1、主叫在10: 04: 04.642发出INVITE会话请求，被叫在 10: 0

8、4: 08.261收到网络侧下发的 BYE Reques，t 软件统计为掉话。查看BYE Request中的CALL-ID 发现是上次会话的 BYE Request2、 被叫在10： 04 : 08： 230收到网络侧下发的INVITE Request同时发送Trying 100，又在 10： 04： 08.261收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送 INVITE 486，软件统计为未接通。3、 主叫在收到网络侧下发的UPDATE 200后，在10: 04: 24.845上报Can cel,主叫的整个 会话流程到这里被终止，事件上表现为未接通。

9、且承载都存在【问题定位】通话期间，被叫收到网络下发的BYE Request会被软件统计为掉话。被叫连续两次收到网络下发的 INVITE Request 回复 INVITE 486 Busy Here，由于第一次 INVITE Request未释放，故 第二次INVITE Request网络侧才会下发INVITE 486,流程停止，软件统计为未接通。此时主 叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。【解决措施】 需要鼎利确认对失败事件的统计机制。【测试验证】案例5: LTE到2G e

10、SRVCC切换失败导致的掉话【问题描述】呼叫会话建立后，由于到达异系统B2门限，终端上报 B2事件，网络下发eSRVCC切换配置命令，但在 2G 侧切入失败，导致掉话。Log 文件名:95000605.lte.lteMO UE:MT UE:时间: 11:16:42:311【问题分析】1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入 2G网络，2G网络下发 TMSI Reallocatio n Comma nd,被叫回复 TMSI Reallocati on Complete，此后流程中断，eSRVCC切换失败。3、信令上看，4G流程正常走完且

11、建立会话， 被叫切换到2G,但是网络下发 TMSI Reallocation Comma nd导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是 2G问题。【问题定位】4G流程正常且已正常建立会话，由于2G网络侧下发TMSI Reallocatio n Comma nd导致eSRVCC切换失败，会话流程结束，导致掉话，怀疑是 2G的问题。【解决措施】 下周准备复侧,准备定位。【测试验证】案例6: TAU过程中RRC Conn ection Release#致的未接通【问题描述】在越秀区网格10的测试LOG中，出现如下的未接通事件：主叫起呼发出 Invite 消息后,在收到网络效应 Try

12、ing 100之前,先收到了网络下发的 RRCConn ection Release消息，RRC连接释放后，接续被终止，出现了Blocked Call事件。【问题分析】1、通过信令详细分析主叫起呼的过程，可以发现， 起呼前， 主叫刚完成重选过程， 从 PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC,主叫发起了 TAU请求：2、 在主叫上发TAU请求后，未等网络回复ATU Accept,主叫已开始了起呼，上发 Invite消息。然而In vite上发0.172s后，主叫同时收到了网络下发的ATU Accept和RRC Conn ectionRelease消息（因此时

13、主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了 Blocked Call事件的发生：3、 进一步分析信令可以发现,主叫在该测试路段内连续在3个 TAC（9437、 10315、 10014） 间进行TAU更新，其中从11:42:53至11:43:04就发生了 4次，可能在存在 TAC规划不合 理的问题。【问题定位】 【解决措施】【测试验证】案例7： Alerting中eSRVCC失败导致未接通【问题描述】主叫起呼后，流程正常，达到eSRVCC切换门限后收到 eSRVCC切换命令且几乎同时收到Ringing 180,主叫未摘机,由于切换失败导致未接通。Log 文件

14、名：95000605.lte .lteMO UE:MT UE:时间： 11：25：28：189 【问题分析】1、 主叫在 11： 25： 26.130 起呼,到 11： 25： 28.204 收到网络侧转发的Ringing 180,整个 信令流程正常2、 在主叫几乎收到网络侧转发的Ringing 180的同时，主叫达到 eSRVCC切换门限，网络侧 在11： 25： 28.189下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话， 而切换失败,导致了未接通。【问题定位】主叫已经收到 Ringing 180，处于振铃状态还未摘话，由于在Alerting中发生了 eSRVCC切换失败导

15、致了未接通【解决措施】 需要核心网方面帮忙定位【测试验证】案例& CSFB失败导致未接通【问题描述】主叫起呼后，被叫 CSFB失败，主叫直接 Cancel导致未接通 Log 文件名：.lte 95000606.lte MO UE:MT UE:时间： 15：42：53：063【问题分析】1、 主叫于15:42:22发起invite，被叫未收到网络侧转发的INVITE Request,但是主叫能一直 收到网络侧下发的INVITE 183、PRACK UPDATE消息，这些消息被叫并没有收到也没 有回复。被叫在15:42:24收到网络侧下发的 CSFB request,但CSFB到2G后从信令看没

16、有呼叫相关的信令交互过程2、 直到15:42:35 CSFB失败，由于收不到被叫的响应，主叫主动于15:42:53发起CANCLE 导致会话未接通。【问题定位】主叫发起会话后，被叫没有收到会话请求，直接CSFB CSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。【解决措施】需要核心网 查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE180、UPDATE PRACK消息。【测试验证】案例 9：被叫 Detach 导致会话未接通【问题描述】主叫发起会话，被叫驻留在2G未返回4G,没有响应主叫的会话请求，主叫收不到被叫相应， 直接 Cancel 导致

17、未接通。Log 文件名：.lte95000606.lteMO UE:MT UE:时间： 15：43 ：37：999【问题分析】1、主叫在15： 43 : 08.657起呼，此时被叫任然驻留在 2G，由于上一次会话中 CSFB失败， 并没有返回 4G。2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发 的 PRACK UPDATE消息。3、 主叫一直收不到被叫的回复，被叫在15:43:30.449被叫上发 Detach Request,主叫在 15： 43： 37.999上发Can cel,取消会话，导致未接通【问题定位】被叫停留在2G未返回4G,然后上发Detac

18、h Request，主叫收不到被叫的回复， 直接Cancel, 导致未接通【解决措施】需要核心网查看为什么主叫会话信令流程正常, 被叫却无法收到主叫的会话请求。 同时查看2G 无线侧,为什么被叫会上发 Detach Request。【测试验证】案例 10：承载未建立导致未接通【问题描述】主叫收到100 Trying后未建立承载，使得RRC直接释放，导致未接通Log 文件名：95000605.lte .lteMO UE:MT UE:时间： 15：46 ：36：271【问题分析】1、主叫在15: 46: 19.079发起会话，收到网络侧下发的100 Trying后，专有承载一直未建立，10s后RR

19、C释放，主叫在15： 46 : 36.271上发Can cel,导致会话未接通【问题定位】专有承载未建立，10s后RRC释放，导致未接通【解决措施】需要核心网查看为什么没有建立专有承载【测试验证】案例 11:承载异常释放导致掉话【问题描述】被叫重建立成功后,专有承载突然被释放,导致掉话Log 文件名:95000605.lte.lteMO UE:MT UE:时间: 10:35 :41:981【问题分析】1、主叫在 10: 28: 06.903 起呼,流程正常,收到网络侧转发的 Ringing 180, UPDATE 200, 主被叫会话正常建立。2、 被叫在 10: 35: 38.253 发送重建立,重建立成功,且流程正常,但是在10: 35: 41.981 承载被释放,导致掉话【问题定位】会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话【解决措施】需要核心网确认承载释放的原因【测试验证】案例 1