ImageVerifierCode 换一换
格式:DOCX , 页数:11 ,大小:19.93KB ,
资源ID:17353545      下载积分:3 金币
快捷下载
登录下载
邮箱/手机:
温馨提示:
快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。 如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝    微信支付   
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【https://www.bdocx.com/down/17353545.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录   QQ登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(移动LTEVOLTE案例分析汇总Word格式文档下载.docx)为本站会员(b****5)主动上传,冰豆网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知冰豆网(发送邮件至service@bdocx.com或直接QQ联系客服),我们立即给予删除!

移动LTEVOLTE案例分析汇总Word格式文档下载.docx

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

2、在什么情况下会下发E-RAB RELEASE COMMAND。【测试验证】案例2:Server Internal Error 500导致的未接通在集团测试LOG中,存在Server Internal Error 导致的失败事件,表现为呼叫过程中,终端主动收到网络侧下发的Server Internal Error 500消息,随后呼叫中止,出现未接通事件。.lte19:1、主叫发出UPDATE后,被叫收到UPDATE并回复UPDATE 200,随后被叫发送Ringing 180,主叫同时收到UPDATE 200和Ringing 180。按照正常的信令流程应该是先收到UPDATE 200,再收到R

3、inging 180。2、然后主叫收到网络侧下发的 INVITE Server Internal Error 500.主叫专载被释放,去激活,导致会话未接通。主叫收到网络侧下发的INVITE 500,然后网络侧又下发RRC重配,释放掉QCI 1,然后去激活,会话流程终止,导致未接通需要核心网确认,为什么会下发INVITE 500,什么情况下会导致网络侧下发INVITE 500,随后的专载释放是否由INVITE 500导致的案例3:软件对失败事件的误判导致统计错误在集团测试LOG中,存在软件的误判而错误统计的失败事件。如在某个特定时间点上,信令显示主被叫正常通话,软件却统计出掉话或未接通事件。0

4、9:44:1、主叫从09:42:41主叫开始呼叫到09:45:47挂机成功,在通话过程中信令流程正常,中间出现一次RRC重建被拒,导致RRC释放,事件表现为掉话,软件统计为掉话。2、在09:主叫收到网络侧下发的RRC重建被拒,主叫随后发起RRC建立请求,在09:15:004,然后因为TAU,在09:128 RRC Connection Release了,软件统计为掉话。随后主叫又发起RRC连接,且在09:重建完成,从RRC重建被拒到RRC连接成功不到1s,且默认承载和专有承载均保持,未被释放,证明会话保持正常。3、到最后结束通话正常挂机都没有出现失败事件主叫接通后,在没有收到通话结束的情况下,

5、中间出现RRC Connection Release,软件判断为掉线,此次是在会话建立后出现,软件统计为掉话【解决措施 】需要鼎利修改判断事件失败的机制案例4:软件对失败事件的重复统计软件对于失败事件存在重复统计的问题,在集团测试问题统计表中,多次出现同一次失败事件,软件却作了多次统计,导致失败事件的增多。04:1、主叫在10:发出INVITE会话请求,被叫在10:收到网络侧下发的BYE Request,软件统计为掉话。查看BYE Request中的CALL-ID,发现是上次会话的BYE Request2、被叫在10:08:230收到网络侧下发的INVITE Request同时发送Trying

6、 100,又在10:收到网络侧下发的INVITE Request同时发送Trying 100,并在同时发送INVITE 486,软件统计为未接通。3、主叫在收到网络侧下发的UPDATE 200后,在10:上报Cancel,主叫的整个会话流程到这里被终止,事件上表现为未接通。且承载都存在通话期间,被叫收到网络下发的BYE Request会被软件统计为掉话。被叫连续两次收到网络下发的INVITE Request,回复INVITE 486 Busy Here,由于第一次INVITE Request未释放,故第二次INVITE Request网络侧才会下发INVITE 486,流程停止,软件统计为未接

7、通。此时主叫在进行正常的会话接续,信令流程正常,事件中未出现失败事件。直到主叫上报Cancel,主叫会话流程停止,事件表现为未接通,之前的两次失败事件统计是重复统计。需要鼎利确认对失败事件的统计机制。案例5:LTE到2G eSRVCC切换失败导致的掉话呼叫会话建立后,由于到达异系统B2门限,终端上报B2事件,网络下发eSRVCC切换配置命令,但在2G侧切入失败,导致掉话。11:42:3111、被叫上报B2事件,满足切换门限系统下发mobility切换命令,此时4G的流程已完成,接下来切入2G网络,2G网络下发TMSI Reallocation Command,被叫回复TMSI Realloca

8、tion Complete,此后流程中断,eSRVCC切换失败。3、信令上看,4G流程正常走完且建立会话,被叫切换到2G,但是网络下发TMSI Reallocation Command导致流程终止,eSRVCC切换失败,会话流程结束,怀疑是2G问题。4G流程正常且已正常建立会话,由于2G网络侧下发TMSI Reallocation Command导致eSRVCC切换失败,会话流程结束,导致掉话,怀疑是2G的问题。下周准备复侧,准备定位。案例6: TAU过程中RRC Connection Release导致的未接通在越秀区网格10的测试LOG中,出现如下的未接通事件:主叫起呼发出Invite消息

9、后,在收到网络效应Trying 100之前,先收到了网络下发的RRC Connection Release消息,RRC连接释放后,接续被终止,出现了Blocked Call事件。1、通过信令详细分析主叫起呼的过程,可以发现,起呼前,主叫刚完成重选过程,从PCI216小区重选至PCI103小区,由于源小区与目标小区处在不同的TAC,主叫发起了TAU请求:2、在主叫上发TAU请求后,未等网络回复ATU Accept,主叫已开始了起呼,上发Invite消息。然而Invite上发后,主叫同时收到了网络下发的ATU Accept和RRC Connection Release消息(因此时主叫处在非业务态,

10、ATU更新会伴随RRC连接的释放),主叫被叫释放,从而导致了Blocked Call事件的发生:3、进一步分析信令可以发现,主叫在该测试路段内连续在3个TAC(9437、10315、10014)间进行TAU更新,其中从11:53至11:43:04就发生了4次,可能在存在TAC规划不合理的问题。案例7:Alerting中eSRVCC失败导致未接通主叫起呼后,流程正常,达到eSRVCC切换门限后收到eSRVCC切换命令且几乎同时收到Ringing 180,主叫未摘机,由于切换失败导致未接通。25:28:1891、主叫在11:起呼,到11:收到网络侧转发的Ringing 180,整个信令流程正常2、

11、在主叫几乎收到网络侧转发的Ringing 180的同时,主叫达到eSRVCC切换门限,网络侧在11:下发eSRVCC切换命令,在切换过程中主叫处于振铃中,并未摘话,而切换失败,导致了未接通。主叫已经收到Ringing 180,处于振铃状态还未摘话,由于在Alerting中发生了eSRVCC 切换失败导致了未接通需要核心网方面帮忙定位案例8:CSFB失败导致未接通主叫起呼后,被叫CSFB失败,主叫直接Cancel导致未接通53:0631、主叫于15:22发起invite,被叫未收到网络侧转发的INVITE Request,但是主叫能一直收到网络侧下发的INVITE 183 、PRACK、UPDA

12、TE消息,这些消息被叫并没有收到也没有回复。被叫在15:24收到网络侧下发的CSFB request,但CSFB到2G后从信令看没有呼叫相关的信令交互过程2、直到15:35 CSFB失败,由于收不到被叫的响应,主叫主动于15:53发起CANCLE。导致会话未接通。主叫发起会话后,被叫没有收到会话请求,直接CSFB,CSFB失败,主叫一直未收到被叫的响应,直接Cancel,导致会话未接通。需要核心网 查看为什么被叫没有收到主叫的会话请求,且主叫能收到网络侧下发的INVITE 180、UPDATE、PRACK消息。案例9:被叫Detach导致会话未接通主叫发起会话,被叫驻留在2G未返回4G,没有响

13、应主叫的会话请求,主叫收不到被叫相应,直接Cancel导致未接通。43:37:9991、主叫在15:起呼,此时被叫任然驻留在2G,由于上一次会话中CSFB失败,并没有返回4G。2、起呼后,被叫一直无响应,没有与主叫进行信令交互,然而主叫能一直收到网络侧下发的PRACK、UPDATE消息。3、主叫一直收不到被叫的回复,被叫在15:被叫上发Detach Request,主叫在15:上发Cancel,取消会话,导致未接通被叫停留在2G未返回4G,然后上发Detach Request,主叫收不到被叫的回复,直接Cancel,导致未接通需要核心网查看为什么主叫会话信令流程正常,被叫却无法收到主叫的会话请

14、求。同时查看2G无线侧,为什么被叫会上发Detach Request。案例10:承载未建立导致未接通主叫收到100 Trying 后未建立承载,使得 RRC直接释放,导致未接通46:36:271发起会话,收到网络侧下发的100 Trying后,专有承载一直未建立,10s后RRC释放,主叫在15:上发Cancel,导致会话未接通专有承载未建立,10s后RRC释放,导致未接通需要核心网查看为什么没有建立专有承载案例11:承载异常释放导致掉话被叫重建立成功后,专有承载突然被释放,导致掉话35:41:981起呼,流程正常,收到网络侧转发的Ringing 180,UPDATE 200,主被叫会话正常建立

15、。发送重建立,重建立成功,且流程正常,但是在10:承载被释放,导致掉话会话建立后,被叫重建立完成,但是专有承载被释放,导致掉话需要核心网确认承载释放的原因案例12:信令转发失败导致未接通主叫发起会话请求,网络侧未转发,被叫未收到,主叫Cancel,导致未接通03:48:952主叫在10:发起会话,被叫未收到,直到10:主叫Cancel,会话接续无法继续,导致未接通。整个过程无线环境良好,网络侧未转发信令。网络侧未转发主叫会话请求,使得会话接续无法继续,主叫Cancel,导致未接通。需要核心网确认会话信令是否成功转发案例13:终端上报Cancel导致会话未接通 会话流程正常接续,终端上报Cancel,导致会话未接通.lte 14:06:5101、主叫在14:起呼,信令流程正常,且被叫上发Ringing 180,主叫收到网络侧转发的Ringing 180,主被叫都已经振铃。但是主叫突然在14:上发Cancel,被叫也收到网络侧转发的Cancel,会话接续停止,导致未接通。主被叫会话流程正常,无线环境良好,信令转发正常。主叫上报Cancel,导致会话未接通,定位为终端问题需要终端确认或者更换终端测试再查看结果

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1