故障分析
1.核心网下发语音专载建立更新流程,如下图所示。
2.基站回复语音专载更新失败,如下图所示。
3.基站在回复语音专载更新失败的同时,发起UE Context Release Request消息,原因为radio_conectiont_with_ue_lost,如下图所示。
4.AMF向SMF连续发送两条Nsmf_PDUSession_UpdateSMContext Request 消息,第一条为通知基站返回语音专载更新失败,第二条为无线发起的UE Context Release Request触发,AMF需要指示SMF将会话进入idle状态,如下图所示。
5.AMF向SMF发送Nsmf_PDUSession_UpdateSMContext Request 消息为连续发送,时间几乎一样,经过传输后顺序稍有差异,SMF先接收到的是将IMS会话进入idle态的Nsmf_PDUSession_UpdateSMContext Request消息,基站回复专载更新响应,如下图所示。
6.当前运营商的SMF在收到基站语音专载建立或更新流程的机制是:判断基站回复的失败态原因值为radio_conectiont_with_ue_lost,归入语音专载失败处理,继而给PCF发送Npcf _SMPolicyControl_Update Request消息,指示RES_ALLO_FAIL。后续PCF通知IMS,IMS会触发SIP 503 Service Unavailable。本次语音呼叫失败,如下图所示。
7.综上分析:中兴通讯SMF在上述语音专载建立/更新流程,根据AMF指示的基站专载建立失败原因值,可以有2种处理:
a.归入语音专载失败处理,呼叫直接失败。
b.挂起语音专载处理,等待延时弹出缓存定时器(默认200ms)和流程冲突定时器(默认3s)两个定时器超时后,可重新尝试语音专载。即在IMS定时器超时前,SMF可能再尝试2次语音专载建立/更新,如果UE在此之前恢复了与基站的连接,呼叫可继续接续。
8.上述原因值可在网管中进行配置,未配置的原因值默认为1)类处理。为了保持与之前版本处理一致,当前所有局点的工程配置中,并未配置radio_conectiont_with_ue_lost。因此当前呼叫必定失败。
9.必须要说明的是,即使SMF将radio_conectiont_with_ue_lost原因值配置为2)类处理,核心网也只能尝试。在极端场景下,SMF的2次语音专载建立/更新重试也不能保证呼叫一定成功。例如:如果UE没有重新与基站恢复空口链接,核心网无法寻呼到UE,或者重新接入到其他核心网网元,呼叫仍然失败。
故障处理
在SMF增加配置,将radio_conectiont_with_ue_lost原因值归为b类处理,并进一步观察。配置命令如下:
ADD N2ONGOINGCFG: RADIO_CONNECTION_WITH_UE_LOST
审核编辑:汤梓红
-
定时器
+关注
关注
23文章
3246浏览量
114713 -
中兴通讯
+关注
关注
7文章
1993浏览量
55111 -
移动网络
+关注
关注
2文章
444浏览量
32849 -
AMF
+关注
关注
0文章
15浏览量
7047
原文标题:VoNR维护案例——VoNR呼叫失败问题处理
文章出处:【微信号:ztedoc,微信公众号:中兴文档】欢迎添加关注!文章转载请注明出处。
发布评论请先 登录
相关推荐
评论