中国移动LTE VOLTE案例分析汇总文档格式.docx
《中国移动LTE VOLTE案例分析汇总文档格式.docx》由会员分享,可在线阅读,更多相关《中国移动LTE VOLTE案例分析汇总文档格式.docx(11页珍藏版)》请在冰豆网上搜索。
由于专载已被释放,业务资源已不存在,所以被叫上发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消息,随后呼叫中止,出现未接通事件。
.lte
95000612.lte
19:
29.051
1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE200,随后被叫发送Ringing180,主叫同时收到UPDATE200和Ringing180。
按照正常的信令流程应该是先收到UPDATE200,再收到Ringing180。
2、然后主叫收到网络侧下发的INVITEServerInternalError500.主叫专载被释放,去激活,导致会话未接通。
主叫收到网络侧下发的INVITE500,然后网络侧又下发RRC重配,释放掉QCI1,然后去激活,会话流程终止,导致未接通
需要核心网确认,为什么会下发INVITE500,什么情况下会导致网络侧下发INVITE500,随后的专载释放是否由INVITE500导致的
案例3:
软件对失败事件的误判导致统计错误
在集团测试LOG中,存在软件的误判而错误统计的失败事件。
如在某个特定时间点上,信令显示主被叫正常通话,软件却统计出掉话或未接通事件。
95000606
09:
44:
14.0
1、主叫从09:
42:
41主叫开始呼叫到09:
45:
47挂机成功,在通话过程中信令流程正常,中间出现一次RRC重建被拒,导致RRC释放,事件表现为掉话,软件统计为掉话。
2、在09:
14.910主叫收到网络侧下发的RRC重建被拒,主叫随后发起RRC建立请求,在09:
15:
004,然后因为TAU,在09:
128RRCConnectionRelease了,软件统计为掉话。
随后主叫又发起RRC连接,且在09:
15.659重建完成,从RRC重建被拒到RRC连接成功不到1s,且默认承载和专有承载均保持,未被释放,证明会话保持正常。
3、到最后结束通话正常挂机都没有出现失败事件
主叫接通后,在没有收到通话结束的情况下,中间出现RRCConnectionRelease,软件判断为掉线,此次是在会话建立后出现,软件统计为掉话
【解决措施】
需要鼎利修改判断事件失败的机制
案例4:
软件对失败事件的重复统计
软件对于失败事件存在重复统计的问题,在集团测试问题统计表中,多次出现同一次失败事件,软件却作了多次统计,导致失败事件的增多。
04:
08.0
1、主叫在10:
04.642发出INVITE会话请求,被叫在10:
08.261收到网络侧下发的BYERequest,软件统计为掉话。
查看BYERequest中的CALL-ID,发现是上次会话的BYERequest
2、被叫在10:
08:
230收到网络侧下发的INVITERequest同时发送Trying100,又在10:
08.261收到网络侧下发的INVITERequest同时发送Trying100,并在同时发送INVITE486,软件统计为未接通。
3、主叫在收到网络侧下发的UPDATE200后,在10:
24.845上报Cancel,主叫的整个会话流程到这里被终止,事件上表现为未接通。
且承载都存在
通话期间,被叫收到网络下发的BYERequest会被软件统计为掉话。
被叫连续两次收到网络下发的INVITERequest,回复INVITE486BusyHere,由于第一次INVITERequest未释放,故第二次INVITERequest网络侧才会下发INVITE486,流程停止,软件统计为未接通。
此时主叫在进行正常的会话接续,信令流程正常,事件中未出现失败事件。
直到主叫上报Cancel,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计。
需要鼎利确认对失败事件的统计机制。
案例5:
LTE到2GeSRVCC切换失败导致的掉话
呼叫会话建立后,由于到达异系统B2门限,终端上报B2事件,网络下发eSRVCC切换配置命令,但在2G侧切入失败,导致掉话。
95000605.lte
11:
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:
53至11:
43:
04就发生了4次,可能在存在TAC规划不合理的问题。
案例7:
Alerting中eSRVCC失败导致未接通
主叫起呼后,流程正常,达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing180,主叫未摘机,由于切换失败导致未接通。
25:
28:
189
1、主叫在11:
26.130起呼,到11:
28.204收到网络侧转发的Ringing180,整个信令流程正常
2、在主叫几乎收到网络侧转发的Ringing180的同时,主叫达到eSRVCC切换门限,网络侧在11:
28.189下发eSRVCC切换命令,在切换过程中主叫处于振铃中,并未摘话,而切换失败,导致了未接通。
主叫已经收到Ringing180,处于振铃状态还未摘话,由于在Alerting中发生了eSRVCC切换失败导致了未接通
需要核心网方面帮忙定位
案例8:
CSFB失败导致未接通
主叫起呼后,被叫CSFB失败,主叫直接Cancel导致未接通
95000606.lte
53:
063
1、主叫于15:
22发起invite,被叫未收到网络侧转发的INVITERequest,但是主叫能一直收到网络侧下发的INVITE183、PRACK、UPDATE消息,这些消息被叫并没有收到也没有回复。
被叫在15:
24收到网络侧下发的CSFBrequest,但CSFB到2G后从信令看没有呼叫相关的信令交互过程
2、直到15:
35CSFB失败,由于收不到被叫的响应,主叫主动于15:
53发起CANCLE。
导致会话未接通。
主叫发起会话后,被叫没有收到会话请求,直接CSFB,CSFB失败,主叫一直未收到被叫的响应,直接Cancel,导致会话未接通。
需要核心网查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE180、UPDATE、PRACK消息。
案例9:
被叫Detach导致会话未接通
主叫发起会话,被叫驻留在2G未返回4G,没有响应主叫的会话请求,主叫收不到被叫相应,直接Cancel导致未接通。
43:
37:
999
1、主叫在15:
08.657起呼,此时被叫任然驻留在2G,由于上一次会话中CSFB失败,并没有返回4G。
2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发的PRACK、UPDATE消息。
3、主叫一直收不到被叫的回复,被叫在15:
30.449被叫上发DetachRequest,主叫在15:
37.999上发Cancel,取消会话,导致未接通
被叫停留在2G未返回4G,然后上发DetachRequest,主叫收不到被叫的回复,直接Cancel,导致未接通
需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请求。
同时查看2G无线侧,为什么被叫会上发DetachRequest。
案例10:
承载未建立导致未接通
主叫收到100Trying后未建立承载,使得RRC直接释放,导致未接通
46:
36:
271
19.079发起会话,收到网络侧下发的100Trying后,专有承载一直未建立,10s后RRC释放,主叫在15:
36.271上发Cancel,导致会话未接通
专有承载未建立,10s后RRC释放,导致未接通
需要核心网查看为什么没有建立专有承载
案例11:
承载异常释放导致掉话
被叫重建立成功后,专有承载突然被释放,导致掉话
35:
41:
981
06.903起呼,流程正常,收到网络侧转发的Ringing180,UPDATE200,主被叫会话正常建立。
38.253发送重建立,重建立成功,且流程正常,但是在10:
41.981承载被释放,导致掉话
会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话
需要核心网确认承载释放的原因
案例12:
信令转发失败导致未接通
主叫发起会话请求,网络侧未转发,被叫未收到,主叫Cancel,导致未接通
03:
48:
952
主叫在10:
32.741发起会话,被叫未收到,直到10:
48.952主叫Cancel,会话接续无法继续,导致未接通。
整个过程无线环境良好,网络侧未转发信令。
网络侧未转发主叫会话请求,使得会话接续无法继续,主叫Cancel,导致未接通。
需要核心网确认会话信令是否成功转发
案例13:
终端上报Cancel导致会话未接通
会话流程正常接续,终端上报Cancel,导致会话未接通
95000605.lte
14:
06:
510
1、主叫在14:
03.998起呼,信令流程正常,且被叫上发Ringing180,主叫收到网络侧转发的Ringing180,主被叫都已经振铃。
但是主叫突然在14:
06.510上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通。
主被叫会话流程正常,无线环境良好,信令转发正常。
主叫上报Cancel,导致会话未接通,定位为终端问题
需要终端确认或者更换终端测试再查看结果