Iphone6和Iphone6plusCSFB被叫失败问题分析说明.doc

Iphone6和Iphone6plus CSFB被叫失败问题分析说明 问题 Iphone6和Iphone6plus手机进行CSFB业务时偶尔。经验证其他手机例如GrandS2、NoteIII、华为P7正常。 问题分析Iphone6和Iphone6plus手机被叫CSFB失败问题规律如下： 1、手机在RRC connect态且无业务状态保持37秒的情况下，手机概率性发生无线链路失败，此后被叫进行CSFB则手机收不到网络下发的CsServiceNotification消息，被叫失败； 2、手机在业务态下进行被叫CSFB测试正常； 3、手机在空闲态下进行被叫CSFB测试正常； 通过以上测试发现只连接态的CSFB存在问题。被叫连接态CSFB正常如下： 被叫连接态异常如下： 1、现场确认网络正常下发CS Service Notification2、空口的信道质量3、UE内部存在异常打印4、eNB打印和UElog对比分析网络下发CS Service Notification 从上面信令可以看eNB已透传CS Service 消息，但随后UE上下文被释放，ERROR。 用户面上报ERROR主要原因下行发送失败或下行没有调度导致。DLInformationTransfer （CsServiceNotification）消息发送失败或者下行没有调度。需要确认下行CMAC是否有调度 空口信道质量 从UElog确定空口的信道质量是否异常 从UE测量的RSRP、SINR，RLM report中看到BLER=0以及PDCCH的解码正常，说明信道质量好。 UE内部异常打印 分析UE内部打印，确定上次被呼流程结束和下次CSFB开始之间是否有异常打印 通过分析发现在上次被呼流程结束和下次CSFB开始之间，UE发生RLF。 从UE的event上报中确认发生了RLF 从UE的debug信息中确认发生了RLF 从UE上报的信息确定发生RLF eNB打印和UElog对比分析 基站下行CMAC调度打印、UElog、以及后台信令对比分析CMAC打印分析从23-16:24:15接入（CSFB流程结束，回落到LTE），此时下行mac对UE的调度，反馈正常。23-16:24:52，判断反馈为dtx，。为37。 从UElog中，上次被叫结束（16:25:43）到event上报RLF（16:26:20）的时间也为37s。 而从后台信令，上次被叫结束（16:24:07）到DLInformationTransfer（CsServiceNotification）（16:24:51）的时间为44s。 由此可得，eNB在透传CsServiceNotification消息时，UE已经发生RLF，UE无法接收到CS服务通知被叫失败。，Iphone6和Iphone6plus手机连接态下CSFB被叫不通的原因UE处于RRC连接态且无业务的情况下概率性的发生异常RLF，在RRC连接后37秒左右发生RLF。 为进一步定位异常为终端导致，现场将UserInactive定时器的时间为elog如下： 3.2华为eNB下的UE异常RLF导致被叫CSFB失败 UE在17：01:18上次被呼流程结束，UE在17:01:55分左右发生RLF，间隔时间是37s，log如下： 问题结论 通过对问题的分析和排查，Iphone6手机连接态下CSFB被叫不通的原因UE处于RRC连接态且无业务的情况下概率性的发生异常RLF，在RRC连接后37秒左右发生RLF。UE发生RLF之后再被呼叫时，UE将收不到网络下发的CsServiceNotification消息，被叫失败。了RLF，已发给高通进一步进行定位分析。 UserInactive的时间为20sIphone6和Iphone6plus接入网络，00次，出现呼叫失败；Iphone6和Iphone6plus接入网络，进行视频下载，即一直保持connect，等待1后，被呼0次，出现呼叫失败。user-inactive定时器表示UE活动定时器，例如：设置成20秒表示UE在没有业务的情况达到20秒则RRC释放，释放后UE处于空闲状态，如需做业务则需重新接入网络，进行RRC连接。 为保障三方测试，大连将user-inactive定时器设置为1分钟，增大user-inactive定时器时间，使得终端尽量处于连接状态，目的在于： 1、无论是进行数据业务还是CSFB语音业务都减少了RRC接入过程，节省了RRC建立过程产生的时延； 2、减少了RRC接入次数，也就相应的减小了RRC连接失败的概率。 通过以上，在connected后37秒左右，UE概率性出现RLF有业务的状态下，不存在。 错误！文档中没有指定样式的文字。