eSRVCC_Failure重建掉话的分析.docxVIP

eSRVCC Failure后重建掉话的案例分析 本文通过eSRVCC Failure后重建的2个案例来讨论eSRVCC Failure的信令流程，log分析的方法和注意点。 eSRVCC Failure后重建失败的分析 10月29日泉州网格7的ATU测试中，在G324安吉路口附近，主叫正常，被叫出现eSRVCC Failure后RRC重建成功，但是却最终导致了被叫掉话。 被叫终端占用泉州丰泽颖新衣架SSD-ZLH-2，触发B2事件，并上报； eNB收到UE上报的B2事件测量报告后下发mobilityFromEUTRACommand消息给UE，在Handover Command 中Handover Reference Value为-99，最终导致了这次的eSRVCC Failure； UE返回LTE网络，再次发送SIP Invite消息，该消息中含有 Reason： SIP ;cause=487 ;text=failure to transition to CS domain。 UE上发RRC重建请求，并开始恢复承载，由下图可以看到已经恢复了SRB-2、QCI=9、QCI=5、QCI=1的承载；从ATU上可以看到该UE已经在泉州丰泽吉源小区-MSD-ZLH-1上已经重建完成，等待IMS下发响应100消息，恢复呼叫； 但是网络先给被叫下发了IMS_SIP_BYE-Request消息。 查Q.850手册，可知 Cause No. 41 – Temporary failure This cause indicates that the network is not functioning correctly and that the condition is not likelyto last a long period of time; e.g. the user may wish to try another call attempt almost immediately. 初步判断为网络侧问题。 网络侧给被叫下发了IMS_SIP_INVITE-Server Internal Error。提示内部服务器错误。被叫终端开始释放已经恢复的承载。 同时，网络给主叫终端也下发了IMS_SIP_BYE-Request消息。Cause值还是41； 接下来主叫也开始释放承载。该次通话记录为一次被叫的掉话。 eSRVCC Failure 后的重建失败往往伴随着部分承载重建失败，本案例中，承载的重建正常，由于网络侧问题依然导致了重建失败掉话。 eSRVCC Failure后重建的流程分析 eSRVCC切换失败后重建的流程 下面我们由另外一个案例中来看看eSRVCC Failure之后重建成功的信令过程。来分析eSRVCC Failure后重建失败的原因。 10月31日对泉州网格1的ATU测试中，在博东路邮校附近由于覆盖原因触发B2，做eSRVCC切换失败后回到LTE网络，并成功恢复VoLTE语音业务。 UE触发B2门限，上报B2消息；eNB收到UE上报的B2事件测量报告后下发mobilityFromEUTRACommand消息给UE；UE根据Handover Command消息做eSRVCC切换。 在2G侧切换失败，事件提示：eSRVCC Failure 。UE返回LTE网络，再次发送SIP Invite消息，该消息中含有 Reason： SIP ;cause=487 ;text=failure to transition to CS domain UE返回LTE网络并做RRC重建请求，网络侧回复“rrc Connection Reestablishment Reject”。 UE在重建被拒之后终端发起Service Request补救。 UE恢复承载，在这里可以看到，恢复SRB-2的信令承载和QCI=9，QCI=5。QCI=1的承载。 * EBI由MME进行分配，不同厂家MME的EBI分配策略可能不一样，据华为MME人员介绍，EBI非固定分配，各承载先建先分配，在重新附着的情况下EBI-DRBI对应关系：并不绝对，要从RLC类型、优先级等来区别 这里QCI=5和QCI=1的承载恢复尤其重要。 网络侧下发Notification指示。表明IMS会话重建请求； 网络侧回复100 Trying，对UE INVITE的100响应； 网络侧响应UE的INVITE的200响应，UE回复ACK，至此VoLTE业务恢复成功。 在本例中，可以看到完整的VoLTE重建过程包括了， UE返回LTE后发送的IMS_SIP_INVITE-Request； QCI=9、QCI=5、QCI=1的承载重建； 网络侧下发Notification； 网络侧下发IM