VoLTE测试案例分析.docx

VoLTE测试案例分析.docx

《VoLTE测试案例分析.docx》由会员分享，可在线阅读，更多相关《VoLTE测试案例分析.docx（26页珍藏版）》请在冰点文库上搜索。

案例1：

580PreconditionFailure导致的未接通。

【问题描述】

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

Log文件名：

9100060920150322101533MS2_UE1.lte

9100060920150322101533MS2_UE2.lte

MOUE:

17820500404

MTUE:

17820500400

时间：

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文件名：

9500061120150322092042ms1.lte

9500061220150322092042ms1.lte

MOUE:

17820500405

MTUE:

17820500403

时间：

10：

19：

29.051

【问题分析】

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

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

2、然后主叫收到网络侧下发的INVITEServerInternalError500.主叫专载被释放，去激活，导致会话未接通。

【问题定位】

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

【解决措施】

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

【测试验证】

案例3：

软件对失败事件的误判导致统计错误

【问题描述】

在集团测试LOG中，存在软件的误判而错误统计的失败事件。

如在某个特定时间点上，信令显示主被叫正常通话，软件却统计出掉话或未接通事件。

Log文件名：

9500060520150320091421ms1.lte

9500060620150320091421ms1.lte

MOUE:

17820500402

MTUE:

17820500396

时间：

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文件名：

9500060520150320091421ms1.lte

9500060620150320091421ms1.lte

MOUE:

17820500402

MTUE:

17820500396

时间：

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文件名：

9500060520150320110855ms1.lte

9500060620150320110855ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

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导致的未接通

【问题描述】

在越秀区网格10的测试LOG中，出现如下的未接通事件：

主叫起呼发出Invite消息后，在收到网络效应Trying100之前，先收到了网络下发的RRCConnectionRelease消息，RRC连接释放后，接续被终止，出现了BlockedCall事件。

【问题分析】

1、通过信令详细分析主叫起呼的过程，可以发现，起呼前，主叫刚完成重选过程，从PCI216小区重选至PCI103小区，由于源小区与目标小区处在不同的TAC，主叫发起了TAU请求：

2、在主叫上发TAU请求后，未等网络回复ATUAccept，主叫已开始了起呼，上发Invite消息。

然而Invite上发0.172s后，主叫同时收到了网络下发的ATUAccept和RRCConnectionRelease消息（因此时主叫处在非业务态，ATU更新会伴随RRC连接的释放），主叫被叫释放，从而导致了BlockedCall事件的发生：

3、进一步分析信令可以发现，主叫在该测试路段内连续在3个TAC（9437、10315、10014）间进行TAU更新，其中从11:

42:

53至11:

43:

04就发生了4次，可能在存在TAC规划不合理的问题。

【问题定位】

【解决措施】

【测试验证】

案例7：

Alerting中eSRVCC失败导致未接通

【问题描述】

主叫起呼后，流程正常，达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing180，主叫未摘机，由于切换失败导致未接通。

Log文件名：

9500060520150320110855ms1.lte

9500060620150320110855ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

11：

25：

28：

189

【问题分析】

1、主叫在11：

25：

26.130起呼，到11：

25：

28.204收到网络侧转发的Ringing180，整个信令流程正常

2、在主叫几乎收到网络侧转发的Ringing180的同时，主叫达到eSRVCC切换门限，网络侧在11：

25：

28.189下发eSRVCC切换命令，在切换过程中主叫处于振铃中，并未摘话，而切换失败，导致了未接通。

【问题定位】

主叫已经收到Ringing180，处于振铃状态还未摘话，由于在Alerting中发生了eSRVCC切换失败导致了未接通

【解决措施】

需要核心网方面帮忙定位

【测试验证】

案例8：

CSFB失败导致未接通

【问题描述】

主叫起呼后，被叫CSFB失败，主叫直接Cancel导致未接通

Log文件名：

9500060520150321151616ms1.lte

9500060620150321151616ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

15：

42：

53：

063

【问题分析】

1、主叫于15:

42:

22发起invite，被叫未收到网络侧转发的INVITERequest，但是主叫能一直收到网络侧下发的INVITE183、PRACK、UPDATE消息，这些消息被叫并没有收到也没有回复。

被叫在15:

42:

24收到网络侧下发的CSFBrequest，但CSFB到2G后从信令看没有呼叫相关的信令交互过程

2、直到15:

42:

35CSFB失败，由于收不到被叫的响应，主叫主动于15:

42:

53发起CANCLE。

导致会话未接通。

【问题定位】

主叫发起会话后，被叫没有收到会话请求，直接CSFB，CSFB失败，主叫一直未收到被叫的响应，直接Cancel，导致会话未接通。

【解决措施】

需要核心网查看为什么被叫没有收到主叫的会话请求，且主叫能收到网络侧下发的INVITE180、UPDATE、PRACK消息。

【测试验证】

案例9：

被叫Detach导致会话未接通

【问题描述】

主叫发起会话，被叫驻留在2G未返回4G，没有响应主叫的会话请求，主叫收不到被叫相应，直接Cancel导致未接通。

Log文件名：

9500060520150321151616ms1.lte

9500060620150321151616ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

15：

43：

37：

999

【问题分析】

1、主叫在15：

43：

08.657起呼，此时被叫任然驻留在2G，由于上一次会话中CSFB失败，并没有返回4G。

2、起呼后，被叫一直无响应，没有与主叫进行信令交互，然而主叫能一直收到网络侧下发的PRACK、UPDATE消息。

3、主叫一直收不到被叫的回复，被叫在15:

43:

30.449被叫上发DetachRequest，主叫在15：

43：

37.999上发Cancel，取消会话，导致未接通

【问题定位】

被叫停留在2G未返回4G，然后上发DetachRequest，主叫收不到被叫的回复，直接Cancel，导致未接通

【解决措施】

需要核心网查看为什么主叫会话信令流程正常，被叫却无法收到主叫的会话请求。

同时查看2G无线侧，为什么被叫会上发DetachRequest。

【测试验证】

案例10：

承载未建立导致未接通

【问题描述】

主叫收到100Trying后未建立承载，使得RRC直接释放，导致未接通

Log文件名：

9500060520150322145725ms1.lte

9500060620150322145725ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

15：

46：

36：

271

【问题分析】

1、主叫在15：

46：

19.079发起会话，收到网络侧下发的100Trying后，专有承载一直未建立，10s后RRC释放，主叫在15：

46：

36.271上发Cancel，导致会话未接通

【问题定位】

专有承载未建立，10s后RRC释放，导致未接通

【解决措施】

需要核心网查看为什么没有建立专有承载

【测试验证】

案例11：

承载异常释放导致掉话

【问题描述】

被叫重建立成功后，专有承载突然被释放，导致掉话

Log文件名：

9500060520150320102801ms1.lte

9500060620150320102801ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

10：

35：

41：

981

【问题分析】

1、主叫在10：

28：

06.903起呼，流程正常，收到网络侧转发的Ringing180，UPDATE200，主被叫会话正常建立。

2、被叫在10：

35：

38.253发送重建立，重建立成功，且流程正常，但是在10：

35：

41.981承载被释放，导致掉话

【问题定位】

会话建立后，被叫重建立完成，但是专有承载被释放，导致掉话

【解决措施】

需要核心网确认承载释放的原因

【测试验证】

案例12：

信令转发失败导致未接通

【问题描述】

主叫发起会话请求，网络侧未转发，被叫未收到，主叫Cancel，导致未接通

Log文件名：

9500060520150320091421ms1.lte

9500060620150320091421ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

10：

03：

48：

952

【问题分析】

主叫在10：

03：

32.741发起会话，被叫未收到，直到10：

03：

48.952主叫Cancel，会话接续无法继续，导致未接通。

整个过程无线环境良好，网络侧未转发信令。

【问题定位】

网络侧未转发主叫会话请求，使得会话接续无法继续，主叫Cancel，导致未接通。

【解决措施】

需要核心网确认会话信令是否成功转发

【测试验证】

案例13：

终端上报Cancel导致会话未接通

【问题描述】

会话流程正常接续，终端上报Cancel，导致会话未接通

Log文件名：

9500060520150320140555ms1.lte

9500060620150320140555ms1.lte

MOUE:

17820500396

MTUE:

17820500402

时间：

14：

53：

06：

510

【问题分析】

1、主叫在14：

53：

03.998起呼，信令流程正常，且被叫上发Ringing180，主叫收到网络侧转发的Ringing180，主被叫都已经振铃。

但是主叫突然在14：

53：

06.510上发Cancel，被叫也收到网络侧转发的Cancel，会话接续停止，导致未接通。

【问题定位】

主被叫会话流程正常，无线环境良好，信令转发正常。

主叫上报Cancel，导致会话未接通，定位为终端问题

【解决措施】

需要终端确认或者更换终端测试再查看结果

【测试验证】

案例14：

【问题分析】

【问题定位】

【解决措施】

【测试验证】