2023年底,我们项目组接了一个SA组网下的5G高清视频通话试点工作,客户很明确地要求支持VoNR业务。由于之前一直是NSA组网,语音业务靠的是VoLTE,VoNR算是我们第一次真正落地。
刚开始建完站以后,UE挂上SA,NR信号满格,数据业务也能跑起来。但在做语音拨打测试时,我们发现一个严重问题:多数终端根本无法注册VoNR,拨号直接报错,偶尔能拨通也是几秒后掉线。
这种现象说大不大,说小也不小。一开始大家都觉得可能是IMS参数配置不一致,毕竟不同厂家的IMS对接接口细节多,有个别字段没填对也可能导致注册失败。于是我们先从最常见的配置着手排查:
检查UE侧IMS设置,确认Profile已启用;
确认APN配置正确,DNN为ims,S-NSSAI匹配默认;
核查AMF是否成功触发IMS注册流程,SIP消息是否已转发。
这一步我们发现AMF确实收到了Initial Registration消息,并已下发PDU Session Establishment,终端也返回了PDU accept。日志上看,PDU建立流程没问题,IMS Profile也被推送到UE了。
但奇怪的是,SIP REGISTER请求没发出来。
我们用信令工具跟踪UE行为,发现问题卡在了SMF到PCF之间的接口。SMF在处理DNN=ims的PDU Session时,请求PCF返回策略,但PCF返回的policy中根本没有语音业务相关的QoS rule。
说白了,UE想注册IMS,但从核心网视角看,根本没把这次Session当成“语音会话”来处理。
这个时候我开始往SBA架构深挖,想办法验证整条链路。我们去查看PCF配置,才发现当时运营侧误将IMS业务的DNN归类为普通数据业务,策略模板里根本没有放入IMS的QCI=1、5QI=1规则。导致SMF无法判断它是VoNR业务,自然也不会触发IMS注册流程。
改完策略模板,再次发起注册流程,这次SIP REGISTER果然顺利走通,后续INVITE、180 RING、200 OK也都正常返回,IMS注册完成,VoNR首次通话成功。
我们原以为这就搞定了,结果新的问题又来了——通话过程中对方听不见声音,单向音频问题。
这又是一个棘手问题。我们用抓包工具分析了RTP流,发现UE->UPF->IMS SBC方向的音频是通的,而从IMS侧返回的RTP流在UPF就没出去了。再查发现,UPF的转发策略只配置了上行PDR,下行RTP端口范围没有放开,被默认丢弃了。
也就是说,IMS那边回音回来了,但UPF根本没让它转给终端。
这时候我已经彻底服了,也更深刻地意识到,VoNR作为全IP语音方案,它不但对核心网中各模块要求严格,而且端到端都要保证路由可达、策略匹配和QoS保障统一。
最终我们补上了UPF策略,下行RTP口段正常开放,VoNR通话质量也恢复正常。
整个过程用了整整两天,除了我和同事,厂家也派了两个人协助分析SMF日志和IMS参数。事后我总结了这次排障的几个关键教训:
不要以为IMS注册失败都是SIP问题,SMF+PCF策略分配也是核心环节;
VoNR依赖的QoS Flow必须有策略保障,否则即便建立成功也会出现业务不通;
UPF不是“配置好就行”,要明确每一个流方向的PDR/FAR是否到位;
SIP注册只是起点,语音流是否能回到UE,往往要靠策略工程师去兜底。
这次经历让我真正理解了VoNR落地的难点,也彻底打消了“5G核心网是拼配置”的想法。
它的每一步,几乎都要人脑对全链路进行完整理解,才可能搞得清楚。
目前我们已整理出一个VoNR部署Checklist,从DNN、S-NSSAI、PCF策略、IMS参数到UPF转发配置,一项项验证,避免踩坑。如果有同行在做VoNR试点,建议你提前规划好端到端流程,不要等到出问题再补。
下篇我准备写写我们在VoNR下做SRVCC退回4G失败的一次大型“翻车现场”,那一次的故障居然是因为回退路径里某个参数厂商默认禁用了。
有兴趣的朋友可以留言,我继续整理实战过程分享。
牛
您即将访问的地址是其它网站的内容,MSCBSC将不再对其安全性和可靠性负责,请自行判断是否继续前往
继续访问 取消访问,关闭