中国移动LTE VOLTE案例分析汇总

广东移动4G T D-L T E详细案例分析

案例1：580PreconditionFailure导致的未接通。

【问题描述】

在集团测试LOG中，存在PreconditionFailure导致的失败事件，表现为呼叫过程中，终端主动上发或收到网络侧下发的580PreconditionFailure消息，随后呼叫中止，出现未接通事件。Log文件名：

_UE1.lte

_UE2.lte

MOUE:

MTUE:

时间：10：16：14.320

【问题分析】

1、呼叫过程中，被叫发送Ringing180后，收到网络下发的专载去激活命令，QCI1被释

放，被叫随后上报580PreconditionFailure，主叫同样收到网络侧转发的580消息，

呼叫接续中止，导致未接通。

2、从信令中可以看到，被叫回复Ringing180且主叫也已经收到Ringing180，被叫随后

收到网络侧下发的RRC重配，携带有QCI1被释放的信息，被叫去激活专有承载。

由于专载已被释放，业务资源已不存在，所以被叫上发580PreconditionFailure失败

消息。主叫收到网络侧下发的580，接续被中止，导致了会话未接通。

3、从MME下发到NodeB的E-RABRELEASECOMMAND，原因上看是Nas层

nomal_release，导致专载QCI1被释放。

4、专载QCI1被释放，去激活后，被叫发送INVITE580，主叫收到网络侧转发的

INVITE580，会话流程中断，导致未接通

【问题定位】

在正常的会话流程中，由于MME下发E-RABRELEASECOMMAND，使得QCI1被释放，导致未接通。

【解决措施】

需要核心网查看MME在什么情况下会下发E-RABRELEASECOMMAND。

【测试验证】

案例2：ServerInternalError500导致的未接通

【问题描述】

在集团测试LOG中，存在ServerInternalError导致的失败事件，表现为呼叫过程中，终端主动收到网络侧下发的ServerInternalError500消息，随后呼叫中止，出现未接通事件。

Log文件名：

.lte

95000612.lte

MOUE:

MTUE:

时间：10：19：29.051

【问题分析】

1、主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE200，随后被叫发送Ringing180，

主叫同时收到UPDATE200和Ringing180。按照正常的信令流程应该是先收到UPDATE200，再收到Ringing180。

2、然后主叫收到网络侧下发的INVITEServerInternalError500.主叫专载被释放，去激活，导

致会话未接通。

【问题定位】

主叫收到网络侧下发的INVITE500，然后网络侧又下发RRC重配，释放掉QCI1，然后去激活，会话流程终止，导致未接通

【解决措施】

需要核心网确认，为什么会下发INVITE500，什么情况下会导致网络侧下发INVITE500，随后的专载释放是否由INVITE500导致的

【测试验证】

案例3：软件对失败事件的误判导致统计错误

【问题描述】

在集团测试LOG中，存在软件的误判而错误统计的失败事件。如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。

Log文件名：

95000606

MOUE:

MTUE:

时间：09：44：14.0

【问题分析】

1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功，在通话过程中信令流程正常，中间

出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。

2、在09：44：14.910主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，

在09：44：15：004，然后因为TAU，在09：44：15：128RRCConnectionRelease了，软件统计为掉话。随后主叫又发起RRC连接，且在09：44：15.659重建完成，从RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。

3、到最后结束通话正常挂机都没有出现失败事件

【问题定位】

主叫接通后，在没有收到通话结束的情况下，中间出现RRCConnectionRelease，软件判断为掉线，此次是在会话建立后出现，软件统计为掉话

【解决措施】

需要鼎利修改判断事件失败的机制

【测试验证】

案例4：软件对失败事件的重复统计

【问题描述】

软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。

Log文件名：

95000606

MOUE:

MTUE:

时间：10：04：08.0

【问题分析】

1、主叫在10：04：04.642发出INVITE会话请求，被叫在10：04：08.261收到网络侧下发

的BYERequest，软件统计为掉话。

查看BYERequest中的CALL-ID，发现是上次会话的BYERequest

2、被叫在10：04：08：230收到网络侧下发的INVITERequest同时发送Trying100，又在10：

04：08.261收到网络侧下发的INVITERequest同时发送Trying100，并在同时发送

INVITE486，软件统计为未接通。

3、主叫在收到网络侧下发的UPDATE200后，在10：04：24.845上报Cancel，主叫的整个

会话流程到这里被终止，事件上表现为未接通。且承载都存在

【问题定位】

通话期间，被叫收到网络下发的BYERequest会被软件统计为掉话。被叫连续两次收到网络下发的INVITERequest，回复INVITE486BusyHere，由于第一次INVITERequest未释放，故第二次INVITERequest网络侧才会下发INVITE486，流程停止，软件统计为未接通。此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。

【解决措施】

需要鼎利确认对失败事件的统计机制。

【测试验证】

案例5：LTE到2GeSRVCC切换失败导致的掉话

【问题描述】

呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置命令，但在2G侧切入失败，导致掉话。

Log文件名：

95000605.lte

.lte

MOUE:

MTUE:

时间：11：16：42：311

【问题分析】

1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSIReallocationCommand，被叫回复TMSIReallocationComplete，此后流程中断，eSRVCC切换失败。

3、信令上看，4G流程正常走完且建立会话，被叫切换到2G，但是网络下发

TMSIReallocationCommand导致流程终止，eSRVCC切换失败，会话流程结束，怀疑是2G 问题。

【问题定位】

4G流程正常且已正常建立会话，由于2G网络侧下发TMSIReallocationCommand导致eSRVCC 切换失败，会话流程结束，导致掉话，怀疑是2G的问题。

【解决措施】

下周准备复侧，准备定位。

【测试验证】

案例6：TAU过程中RRCConnectionRelease导致的未接通

【问题描述】