Paging消息下发延迟导致CSFB问题处理进展
9月15日抓包分析:
主叫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。
IMS在17:17:54.181020收到主叫的INVITE消息,于17:17:54.411631转发给被叫, SBC一起向被叫发了5次INVITE,手机一直没响应;在等待手机响应超过了10S SSS启动域选择功能在CS域去接续用户所在导致用户回落了,需要EPC核查是否及时收到IMS发给被叫的INVITE消息,并及时下发寻呼消息给被叫。
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出现了问题。
EPC传送5次INVITE消息给被叫,被叫UE一直没响应,是由于被叫UE没进入连接态,只有连接态才可以接收并响应SIP消息,但没进入连接态的原因是由于没有收到寻呼消息导致。
根据前台信令分析,10S后终端才收到寻呼消息,应当是由于1次寻呼失败,而收到了后边的寻呼导致,经过与MME侧沟通确认,诺西MME目前的寻呼机制为首先从最近一次的enode B寻呼,寻呼不到就从最近一次TAC下的enodeB寻呼,如果仍旧寻呼不到就从TA-LST下寻呼,诺西MME人员解释最近一次enodeB寻呼是上次寻呼下发时所寻呼到终端的enodeB,但拉网测试时终端很容易离开原先的基站,因此1次寻呼时很容易失败。
将1次寻呼修改为Talist寻呼方式。
您即将访问的地址是其它网站的内容,MSCBSC将不再对其安全性和可靠性负责,请自行判断是否继续前往
继续访问 取消访问,关闭