Paging消息下发延迟导致CSFB问题处理进展

9月15日抓包分析：

1       问题现象：

主叫17:17:54.378上报INVITE消息，17:17:54.709收到IMS的回应trying100，10S后，被叫于17:18:04.492收到MME下发的paging消息，并响应寻呼。被叫于17:18:05.172网络侧直接下发CANCEL取消本次呼叫，终端回落至CS域发起CSFB。

2       问题分析：

2.1 IMS侧分析：

IMS在17:17:54.181020收到主叫的INVITE消息，于17:17:54.411631转发给被叫， SBC一起向被叫发了5次INVITE，手机一直没响应；在等待手机响应超过了10S SSS启动域选择功能在CS域去接续用户所在导致用户回落了，需要EPC核查是否及时收到IMS发给被叫的INVITE消息，并及时下发寻呼消息给被叫。

2.2 EPC侧分析：

Volte流程都是走的用户面的专用承载。从下面截图看：主叫17:17:53秒起呼，17:17:53 回100 TRYING消息。但被叫183响应时间是17:18:04。

INVITE消息是从被叫侧P-CSCF发送给UE的IPv6地址。这些信令走的都是专用承载，EPC不存在SIP消息延迟现象。从下面截图能看到，17:17:54开始P-CSCF向被叫UE反复发送INVITE消息，但被叫UE一直没响应，直到10秒后才响应，应该UE出现了问题。

2.3无线侧分析

EPC传送5次INVITE消息给被叫，被叫UE一直没响应，是由于被叫UE没进入连接态，只有连接态才可以接收并响应SIP消息，但没进入连接态的原因是由于没有收到寻呼消息导致。

根据前台信令分析，10S后终端才收到寻呼消息，应当是由于1次寻呼失败，而收到了后边的寻呼导致，经过与MME侧沟通确认，诺西MME目前的寻呼机制为首先从最近一次的enode B寻呼，寻呼不到就从最近一次TAC下的enodeB寻呼，如果仍旧寻呼不到就从TA-LST下寻呼，诺西MME人员解释最近一次enodeB寻呼是上次寻呼下发时所寻呼到终端的enodeB，但拉网测试时终端很容易离开原先的基站，因此1次寻呼时很容易失败。

3       解决方法

将1次寻呼修改为Talist寻呼方式。