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

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

广东移动4GTD-LTE详细案例分析

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

【问题描述】

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

Log文件名:

MO UE:

MT UE:

时间:10:16:

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消息,随后呼叫中止,出现未接通事件。

Log文件名:

MO UE:

MT UE:

时间:10:19:

【问题分析】

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中,存在软件的误判而错误统计的失败事件。如在某个特定时间点上,信

令显示主被叫正常通话,软件却统计出掉话或未接通事件。

Log文件名:

MO UE:

MT UE:

时间:09:44:

【问题分析】

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:软件对失败事件的重复统计

【问题描述】

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

Log文件名:

MO UE:

MT UE:

时间:10:04:

【问题分析】

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,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计。

相关文档
最新文档