广州中兴VoLTE优化案例精要.docxVIP

案例1：异频重定向掉话案例 【问题描述】 主叫占用广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）小区通话时，信号强度为-101dbm左右，出现一次RRC Connection Release，导致承载拆除，引起一次主叫掉话。 【问题分析】 分析测试数据，发现UE占用服务小区广州天河区鱼珠木材市场D-ZLH-3（EARFCN=38100 PCI=83CELLID=135693）在通话的过程中信号越来越差，之后上报测量报告A2事件，eNODEB收到报告后发起异频重定向判决，下发RRC Connection Release，由异频重定向后，eNodeB向MME发送ue context release request，mme释放专用承载。当UE被重定向后在新的小区发起RRC连接，网络只建立了默认承载，UE发送BYE消息，导致掉话。 从地理环境上看，服务小区与UE重定向目标小区相距较远，不需配邻区关系，UE在该路段仅是偶尔测量到目标小区的信号，这种环境极容易触发异频重定向。 【解决方案】 关闭异频重定向，复测问题解决，服务小区后台统计指标无异常。 【问题总结】 根据拉网统计，目前该类掉话占总掉话次数的80%以上，对测试指标影响非常严重。 异频重定向触发原理：小区间没定义邻区关系，当邻区满足切换条件时，主服务小区无法切换到邻区，基站会给UE下发系统内重定向。 优化办法：通过关闭异频重定向的功能来规避该事件，除此之外，异频邻区的完善需要加大优化力度。 后续解决办法：除了做好邻区优化外，中兴将在下个版本加入基于QCI的异频重定向功能，禁止专用承载的业务发生异频重定向。 。 案例2：异系统重定向掉话案例 【问题描述】 VoLTE测试eSRVCC过程中，发现eSRVCC执行的是CCO，而不是PS切换。而CCO对于VoLTE语音来说，必然导致掉话。 【问题分析】 具体如下图所示。 1. 对于PSHO、CCO、重定向，优先级为PSHOCCO重定向。那么现在的问题就是eSRVCC过程执行的为什么是CCO而不是PSHO。 2. 重点排查的就是eSRVCC相关配置： （1）eSRVCC功能开关：未发现问题。 （2）系统间邻区配置： a. GSM邻区配置：重点查看“PS切换能力”配置的是否为：“是[1]”。PS切换能力表示GSM邻区的PS?HO能力。当GSM邻区支持PS?HO能力，服务小区可以向该邻区发起PS切换。未发现错误。 b. GSM邻区关系: ???点查看“支持切换”配置的是否为“支持[1]”。是否“支持切换”代表服务小区是否支持向GERAN邻区发起切换的指示。发现配置的是“不支持”。问题就在这里。如下图所示。 【解决方案】 修改GSM邻区关系中，支持切换为“支持[1]”后，在进行eSRVCC切换，eSRVCC切换成功，VoLTE未出现掉话。 【问题总结】 对于VoLTE语音来说，无论是系统内还是系统间eSRVCC，只要执行的不是“切换”都会导致语音的掉话，包括重定向和CCO。因此，需要开通的时候，保持GSM邻区配置和GSM邻区关系配置正确，严格按照中兴的VoLTE开通指导书来执行。 案例3：切换过程中专载被MME释放 【问题描述】 主被叫在呼叫建立的过程中，专载建立与切换几乎同时发生，专载刚刚建立完成又在切换过程中被释放，终端回复invite580，呼叫未接通。 【问题分析】 1、主叫收到invite183消息并建立专载，但在专载建立前主叫已上报A3测报，所以几乎在主叫上发承载建立成功的NAS消息的同时（10:19:29.959），主叫收到了基站下发的切换重配消息，消息中包含释放QCI1的信息： 2、再看基站侧信令，基站收到终端上报的A3测报后，从源小区发给MME的HandoverRequired里面，有三条承载，分别是QCI9/QCI5/QCI1： 3、从MME发给目标小区的HandoverRequest消息里面e_RABInformationList有三条承载，但是e_RABToBeSetupListHOReq里面只有两条，少了QCI1的： 4、由于HandoverRequest消息的e_RABToBeSetupListHOReq里面只有两条承载，所以目标小区回给MME的HandoverRequestAcknowledge消息里面，也只有两条承载： 5、那么，在MME回给源小区的HandoverCommand里面ToAdd两条承载QCI9和QCI5， Release了QCI1的承载，这就导致专载被释放并导致未接通： 终端专载建立成功后上发NAS消息给MME，但由于切换流程在前，MME收到NAS消息之前，MME已经发给目标小区的HandoverRequest消息，里面e_RABToBeS