VoLTE外场测试分析案例.docx
《VoLTE外场测试分析案例.docx》由会员分享，可在线阅读，更多相关《VoLTE外场测试分析案例.docx（9页珍藏版）》请在冰点文库上搜索。
VoLTE外场测试分析案例
【问题描述】
在集团测试LOG中，存在PreconditionFailure导致的失败事件，表现为呼叫过程中，终
端主动上发或收到网络侧下发的580PreconditionFailure消息，随后呼叫中止，出现未
接通事件。
【问题分析】
1、呼叫过程中，被叫发送
Ringing180后，收到网络下发的专载去激活命令,
QCI1
，主叫同样收到网络侧转发的
被释放，被叫随后上报
580PreconditionFailure
580消息，呼叫接续中止，导致未接通。
2、从信令中可以看到，被叫回复Ringing180且主叫也已经收到Ringing180，被叫
随后收到网络侧下发的RRC重配，携带有QCI1被释放的信息，被叫去激活专有承
载。
由于专载已被释放，业务资源已不存在，所以被叫上发580Precondition
Failure失败消息。
主叫收到网络侧下发的580，接续被中止，导致了会话未接通。
3、从MMEF发到NodeB的E-RABRELEASECOMMAN原因上看是Nas层nomal_release，
导致专载QCI1被释放。
4、专载QCI1被释放，去激活后，被叫发送INVITE580,主叫收到网络侧转发的INVITE
580,会话流程中断，导致未接通
【问题定位】
在正常的会话流程中，由于MMEF发E-RABRELEASECOMMAN使得QCI1被释放，导致未接通。
【解决措施】
需要核心网查看MM莊什么情况下会下发E-RABRELEASECOMMAND
案例2：
ServerInternalError500导致
的未接通
【问题描述】
在集团测试LOG中，存在ServerInternalError导致的失败事件，表现为呼叫过程中，
终端主动收到网络侧下发的ServerInternalError500消息，随后呼叫中止，出现未接通事件。
【问题分析】
1、主叫发出UPDATED，被叫收到UPDATED回复UPDAT^OO,随后被叫发送Ringing180，主叫同时收到UPDATE200和Ringing180。
按照正常的信令流程应该是先收到UPDATE200,再收到Ringing180。
2、然后主叫收到网络侧下发的INVITEServerInternalError5OO.主叫专载被释放,去
激活,导致会话未接通。
【问题定位】
主叫收到网络侧下发的INVITE500,然后网络侧又下发RRC重配，释放掉QCI1，然后去激活,会话流程终止,导致未接通
【解决措施】
需要核心网确认,为什么会下发INVITE500,什么情况下会导致网络侧下发INVITE500,随后的专载释放是否由INVITE500导致的
案例3：
软件对失败事件的误判导致统计错误
【问题描述】
在集团测试LOG中，存在软件的误判而错误统计的失败事件。
如在某个特定时间点上，信令
显示主被叫正常通话，软件却统计出掉话或未接通事件。
【问题分析】
1、主叫从09:
42:
41主叫开始呼叫到09:
45:
47挂机成功，在通话过程中信令流程正常，中间出现一次RRC重建被拒，导致RRC释放，事件表现为掉话，软件统计为掉话。
2、在09:
44:
主叫收到网络侧下发的RRC重建被拒，主叫随后发起RRC建立请求，在09:
44：
15：
004,然后因为TAU在09:
44：
15：
128RRCConnectionRelease了，软件统计为掉话。
随后主叫又发起RRC连接，且在09:
44：
重建完成，从RRC重建被拒到RRC连接成功不到1s，且默认承载和专有承载均保持，未被释放，证明会话保持正常。
3、到最后结束通话正常挂机都没有出现失败事件
【问题定位】
RRCConnectionRelease，软件判
主叫接通后，在没有收到通话结束的情况下，中间出现断为掉线，此次是在会话建立后出现，软件统计为掉话
解决措施】
需要鼎利修改判断事件失败的机制
案例4：
软件对失败事件的重复统计
【问题描述】
软件对于失败事件存在重复统计的问题，在集团测试问题统计表中，多次出现同一次失败事件，软件却作了多次统计，导致失败事件的增多。
【问题分析】
1、主叫在10：
04：
发出INVITE会话请求，被叫在10：
04：
收到网络侧下发的BYERequest，软件统计为掉话。
查看BYERequest中的CALL-ID，发现是上次会话的BYERequest
2、被叫在10：
04：
08：
230收到网络侧下发的INVITERequest同时发送Trying100，又在10：
04：
收到网络侧下发的INVITERequest同时发送Trying100，并在同时发送INVITE486，软件统计为未接通。
3、主叫在收到网络侧下发的UPDATE200后，在10：
04：
上报Cancel，主叫的整个会话流程到这里被终止，事件上表现为未接通。
且承载都存在
【问题定位】
通话期间，被叫收到网络下发的BYERequest会被软件统计为掉话。
被叫连续两次收到网络下发的INVITERequest，回复INVITE486BusyHere，由于第一次INVITERequest未释放,故第二次INVITERequest网络侧才会下发INVITE486，流程停止，软件统计为未接通。
此时主叫在进行正常的会话接续，信令流程正常，事件中未出现失败事件。
直到主叫上报Cancel，主叫会话流程停止，事件表现为未接通，之前的两次失败事件统计是重复统计。
【解决措施】
需要鼎利确认对失败事件的统计机制。
案例5:
LTE到2GeSRVCC切换失败导致的
掉话
【问题描述】
呼叫会话建立后，由于到达异系统B2门限，终端上报B2事件，网络下发eSRVCC切换配置
命令，但在2G侧切入失败，导致掉话。
【问题分析】
1、被叫上报B2事件，满足切换门限系统下发mobility切换命令，此时4G的流程已完成，接下来切入2G网络，2G网络下发TMSIReallocationCommand被叫回复TMSIReallocationComplete，此后流程中断，eSRVC（切换失败。
3、信令上看，4G流程正常走完且建立会话，被叫切换到2G,但是网络下发TMSI
ReallocationComman（导致流程终止，eSRVC（切换失败，会话流程结束，怀疑是2G问题。
问题定位】
eSRVCC
4G流程正常且已正常建立会话，由于2G网络侧下发TMSIReallocationComman导致
切换失败，会话流程结束，导致掉话，怀疑是2G的问题。
解决措施】
【测试验证】
案例6:
TAU过程中RRCConnectionRelease
导致的未接通
【问题描述】
在越秀区网格10的测试LOG中，出现如下的未接通事件：
主叫起呼发出Invite消息后，在收到网络效应Trying100之前，先收到了网络下发的RRC
ConnectionRelease消息，RRC连接释放后，接续被终止，出现了BlockedCall事件。
【问题分析】
1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC主叫发起了TAU请求：
2、在主叫上发TAU请求后，未等网络回复ATUAccept，主叫已开始了起呼，上发Invite
消息。
然而Invite上发后，主叫同时收到了网络下发的ATUAccept和RRCConnection
Release消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫
释放，从而导致了BlockedCall事件的发生：
3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:
42:
53至11:
43:
04就发生了4次，可能在存在TAC规划不合理的问题。
【问题定位】
TAC规划不合理。
【解决措施】
规划TAC
案例7:
Alerting中eSRVCC失败导致未接
通
【问题描述】
主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到
Ringing180，主叫未摘机，由于切换失败导致未接通。
【问题分析】
1、主叫在11：
25：
起呼，到11：
25：
收到网络侧转发的Ringing180，整个信令流程正常。
2、在主叫几乎收到网络侧转发的Ringing180的同时，主叫达到eSRVCC切换门限，网络侧在11：
25:
下发eSRVC（切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。
【问题定位】
主叫已经收到Ringing180，处于振铃状态还未摘话，由于在Alerting中发生了eSRVCC切换失败导致了未接通。
【解决措施】
需要核心网方面帮忙定位。
【测试验证】
案例&CSFB失败导致未接通
【问题描述】
主叫起呼后，被叫CSFB失败，主叫直接Cancel导致未接通。
问题分析】
1、主叫于15:
42:
22发起invite，被叫未收到网络侧转发的INVITERequest，但是主叫能一直收到网络侧下发的INVITE183、PRACKUPDAT曰肖息，这些消息被叫并没有收到
也没有回复。
被叫在15:
42:
24收到网络侧下发的CSFBrequest，但CSFB到2G后从信令看没有呼叫相关的信令交互过程。
2、直到15:
42:
35CSFB失败，由于收不到被叫的响应，主叫主动于15:
42:
53发起CANCLE
导致会话未接通。
【问题定位】
主叫发起会话后，被叫没有收到会话请求，直接CSFBCSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。
【解决措施】
需要核心网查看为什么被叫没有收到主叫的会话请求，且主叫能收到网络侧下发的INVITE180、UPDATEPRACK肖息。
【测试验证】
案例9：
被叫Detach导致会话未接通
【问题描述】
主叫发起会话，被叫驻留在2G未返回4G,没有响应主叫的会话请求，主叫收不到被叫相应，直接Cancel导致未接通。
【问题分析】
1、主叫在15:
43:
起呼，此时被叫任然驻留在2G,由于上一次会话中CSFB失败，并没有返回4G。
2、起呼后，被叫一直无响应，没有与主叫进行信令交互，然而主叫能一直收到网络侧下发的PRACKUPDATE肖息。
3、主叫一直收不到被叫的回复，被叫在15:
43:
被叫上发DetachRequest，主叫在15：
43：
上发Cancel，取肖会话，导致未接通。
【问题定位】
被叫停留在2G未返回4G,然后上发DetachRequest，主叫收不到被叫的回复，直接Cancel,导致未接通。
【解决措施】
需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请求。
同时查看2G无线侧，为什么被叫会上发DetachRequest。
【测试验证】
案例10：
承载未建立导致未接通
【问题描述】
主叫收到100Trying后未建立承载，使得RRC直接释放，导致未接通。
【问题分析】
1、主叫在15：
46：
发起会话,收到网络侧下发的100Trying后,专有承载一直未建立,10s后RRC释放，主叫在15：
46：
上发Cancel，导致会话未接通。
问题定位】
专有承载未建立，10s后RRC释放，导致未接通。
解决措施】
需要核心网查看为什么没有建立专有承载。
【测试验证】
案例11：
承载异常释放导致掉话
【问题描述】
被叫重建立成功后，专有承载突然被释放，导致掉话。
【问题分析】
1、主叫在10：
28：
起呼，流程正常，收到网络侧转发的Ringing180，UPDATE200，主被叫会话正常建立。
2、被叫在10：
35：
发送重建立，重建立成功，且流程正常，但是在10：
35：
承载被释放，
导致掉话。
【问题定位】
会话建立后，被叫重建立完成，但是专有承载被释放，导致掉话。
【解决措施】
需要核心网确认承载释放的原因。
测试验证】
案例12：
信令转发失败导致未接通
【问题描述】
主叫发起会话请求，网络侧未转发，被叫未收到，主叫Cancel，导致未接通。
【问题分析】
主叫在10：
03：
发起会话，被叫未收到，直到10：
03：
主叫Cancel，会话接续无法继续，导致未接通。
整个过程无线环境良好，网络侧未转发信令。
【问题定位】
网络侧未转发主叫会话请求，使得会话接续无法继续，主叫Cancel，导致未接通。
【解决措施】
需要核心网确认会话信令是否成功转发。
【测试验证】
案例13：
终端上报Cancel导致会话未接通
【问题描述】
会话流程正常接续，终端上报Cancel，导致会话未接通。
【问题分析】
1、主叫在14：
53：
起呼，信令流程正常，且被叫上发Ringing180，主叫收到网络侧转发
的Ringing180，主被叫都已经振铃。
但是主叫突然在14：
53：
上发Cancel，被叫也收到
网络侧转发的Cancel，会话接续停止，导致未接通。
【问题定位】
主被叫会话流程正常，无线环境良好，信令转发正常。
主叫上报Cancel，导致会话未接通，
定位为终端问题。
【解决措施】
需要终端确认或者更换终端测试再查看结果。
升级会员 