VoLTE外场测试分析案例

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

【问题描述】

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

【问题分析】

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

被释放，被叫随后上报580 Precondition 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、专载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 Error 500消息，随后呼叫中止，出现未接通事件。

【问题分析】

1、主叫发出UPDATE后，被叫收到UPDATE并回复UPDATE 200，随后被叫发送Ringing 180，

主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200，再收到Ringing 180。

2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放，去

激活，导致会话未接通。

【问题定位】

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

【解决措施】

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

【测试验证】

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

【问题描述】

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

【问题分析】

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

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

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

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

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

【问题定位】

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

【解决措施】

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

【测试验证】

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

【问题描述】

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

【问题分析】

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

软件统计为掉话。

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

2、被叫在10：04：08：230收到网络侧下发的INVITE Request同时发送Trying 100，又

在10：04：收到网络侧下发的INVITE Request同时发送Trying 100，并在同时发送INVITE 486，软件统计为未接通。

3、主叫在收到网络侧下发的UPDATE 200后，在10：04：上报Cancel，主叫的整个会话流

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

【问题定位】

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

【解决措施】

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

【测试验证】

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

【问题描述】

呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置