VoLTE端到端业务详解 | 接通问题

Posted 2022-08-22 COCOgsta

书籍来源：艾怀丽《VoLTE端到端业务详解》

一边学习一边整理书中的笔记，并与大家分享，侵权即删，谢谢支持！

附上汇总贴：VoLTE端到端业务详解 | 汇总_COCOgsta的博客-CSDN博客

---

10.1.1 基本流程

1.VoLTE用户主叫业务

如图10-2所示，VoLTE用户的主叫业务流程可简要描述如下。

流程1-1表示SBC收到UE的Invite消息，需要通过Rx接口建立QCI=1专载，成功之后才会将Invite消息转发出去，即流程1-2。

流程2-1表示SBC收到被叫的183消息，需要通过Rx接口去更新QCI=1专载，成功之后才会将183转发给UE，即流程2-2。

流程3表示SBC收到UE的Prack消息，直接转发出去。

流程4表示SBC收到主叫UE的Update消息，通过Rx接口去更新QCI=1专载，成功之后才会将Update消息转发出去，即流程5-1。

流程5-2表示SBC收到被叫侧200 OK for Update直接转发给主叫UE。流程6表示SBC收到被叫的180消息才认为本次通话接通。

流程6表示SBC收到被叫的180消息才认为本次通话接通。

备注：SBC在2-1和4-1消息阶段是否去修改专载是可选的，本篇是假设设置为需要修改专载。

2.VoLTE用户被叫业务

如图10-3所示，VoLTE用户的被叫业务流程可简要描述如下。

流程1-1表示SBC收到S-CSCF的Invite消息转发到SGW，如果用户处于空闲态，则要经过寻呼过程将用户由空闲态转移为连接态，即用户收到寻呼消息之后会主动建立空口连接，基站和MME配合完成S1-U口的连接。流程1-2表示SGW会通过此连接将Invite消息发给UE。

流程2-1表示被叫用户在收到Invite消息之后，首先返回的是100Trying消息（为了信令流程图清晰，图中省略了此步骤），再返回主叫183消息以对Invite消息进行响应，SBC收到被叫的183消息，需要通过Rx接口去为被叫用户建立QCI=1专载。流程2-2表示成功之后才会将183消息转发给主叫侧。

主叫侧会针对183消息返回Prack，被叫用户针对Prack返回200 OK for Prack消息，主叫侧向被叫用户发出Update消息以更新SDP等信息，被叫UE针对主叫侧Update消息返回200 OK for Update。

流程3-1表示SBC收到被叫UE的200 OK for Update，需要通过Rx接口去更新被叫用户的QCI=1专载。流程3-2表示被叫用户的专载修改成功之后SBC才会将200 OK for Update转发给主叫侧。

被叫用户在空口承载按照200 OK for Update中的相关信息修改成功后，会返回180消息给主叫侧。

10.1.2 关键信息

VoLTE业务的话务模型很复杂，从第6.1节可以看到包含三大类，为更加清晰地陈述接通问题的分析方法，本章节以VoLTE始呼接通率问题为例进行说明。

VoLTE用户在LTE网络做主叫，呼叫被接通的概率怎么统计呢？如图10-4所示。

始呼接通率=始呼接通次数/始呼请求次数，其中：

（1）始呼接通次数：主叫侧SIP 180 Ringing次数，图中位置为②；

（2）始呼请求次数：主叫侧SIP Invite次数，图中位置为①。

数据来源：信令监测平台的S1-U口或Mw口。说明：

说明：

① VoLTE用户的始呼接通率可以区分语音和视频，指标计算时既可以分开也可以合并。

② 始呼区分语音和视频的方法是，判断主叫侧建立专有承载时的QCI，QCI=1代表语音，QCI=2代表视频。

③ 网络接通率：为了排除用户行为的影响，运营商一般会要求把一些非网络原因导致的未接通（根据SIP响应码判断）当作接通，计算网络接通率。如某运营商要求把403、404、405、413、414、415、416、422、423、480、486、487、488、600、603、604、606失败当作接通。

10.1.3 定界思路

1.VoLTE用户主叫业务

如图10-5所示，VoLTE用户主叫业务问题的定界思路简单描述如下。

流程1-1：如果SBC没有收到Invite消息，首先需要核实传送SIP信令的EPS承载是否建立，再联合无线和EPC专业进行消息丢失在哪段的定位。

流程1-2：SBC没有将Invite消息转给S-CSCF，如果是QCI=1专载建立不成功，需要无线和EPC专业进行定位哪段专载建立失败。

流程2-1：SBC如果没有收到被叫183消息，需要IMS、EPC、无线专业核实被叫的信令流程。

流程2-2：SBC没有将183消息转给UE，如果是专载更新失败，需要无线和EPC专业进行定位哪段专载更新失败。

流程3：如果SBC没有收到主叫用户的Prack消息,则要EPC、基站、终端联合定位是主叫用户没有收到183消息，还是主叫用户发送的Prack消息到不了SBC；SBC如果收到了主叫用户的Prack消息但没有转发出去，则需要对SBC进行分析和定位原因。

流程4：如果没有收到主叫用户的Update消息，需要IMS、EPC、无线专业核实主叫的信令流程。

流程5-1：SBC没有将Update消息转给被叫侧，如果是专载更新失败，需要无线和EPC专业进行定位专载是在哪段更新失败。

流程5-2：如果SBC没有收到被叫的200 OK（for Update）消息，则需要IMS域核实被叫侧流程；如果SBC收到了被叫的200 OK for Update消息，但没有转发给主叫用户，则需要SBC进行分析和定位原因。2.VoLTE用户被叫业务

2.VoLTE用户被叫业务

如图10-6所示，VoLTE用户被叫业务问题的定界思路简单描述如下。

流程1-1和流程1-2表示两条消息之间，如果VoLTE用户是处于空闲态，则还有寻呼过程，当消息到达SGW时，SGW会去看用户的S1-U口的E-RAB承载是否存在，如果不存在则会发DDN消息给MME，MME就会去寻呼该用户。

流程2-1：如果SBC没有收到100Trying消息，首先需要SBC和EPC专业进行定位Invite消息是否发送到SGW；对于空闲态的用户MME是否下发寻呼；基站是否下发寻呼；UE是否响应了寻呼；传送SIP信令的EPS承载是否建立成功。

流程2-2：如果SBC收到了183消息但没有将183消息转发给S-CSCF，则需要核实QCI=1专载是否建立成功，需要联合无线和EPC专业进行定位哪段专载建立失败。

流程3-1：SBC没有收到被叫用户的200 OK for Update，则需EPC和eNB联合定位是哪段问题或UE终端问题。

流程3-2：如果SBC没有将200 OK for Update转发给主叫侧，则需要联合无线和EPC专业进行定位哪段专载修改失败。

10.1.4 分析示例

在现网分析中一般用第一拆线原因来描述未接通事件，3XX、4XX、5XX、6XX分别代表重定向原因、用户原因、服务器原因、全局原因。

某地通过信令监测系统统计到的第一拆线原因及占比情况如表10-1所示。

从表10-1可以看到，拆线原因除了用户原因（被叫用户忙、被叫用户缺席等）类型外，503 Service Unavailable的占比最大，再次提取503消息中携带的原因并进行分析，如表10-2所示。

从表10-2可以看出，503各个失败场景占比最大的是资源不足，可以通过扩容、资源均衡等手段合理分配资源。

10.1.5 典型事件

10.1.5.1 503事件

备注：为方便起见，典型未接通各个事件的信令流程描述均省略了VoLTE主叫用户的各个AS业务流程。

如图10-7所示，可以看出本次业务呼叫模型是VoLTE用户呼叫CS域的用户，MGCF网元是在主叫用户的SIP信令传送到针对主叫用户的Update消息返回200 OK之后才发IAM消息给被叫用户侧所在的局。

如图10-8所示，可以看到由于被叫用户所在的局返回了被叫用户未接通的BICC信令REL，拆线原因为Requested Circuit/Channel not Available（44），如图10-9所示。MGCF转给IMS域的拆线信令为SIP信令503，携带了Q.850的拆线原因值44在Reason头域中，如图10-10所示。

10.1.5.2 504事件

同样，如图10-11所示，可以看出本次呼叫的模型是VoLTE用户呼叫CS域用户。

如图10-12所示，本次呼叫未接通的原因是CS域返回了未接通的BICC信令REL消息，拆线原因为定时器超时，如图10-13所示。MGCF转给IMS域的拆线信令为SIP信令504，携带了Q.850的拆线原因值102在Reason头域中，如图10-14所示。

10.1.5.3 500事件

如图10-15所示，可以看到本次呼叫未接通的原因是CS域返回了未接通的BICC信令REL消息，拆线原因为网络故障（38），如图10-16所示。MGCF转给IMS域的拆线信令为SIP信令500，携带了Q.850的拆线原因值38在Reason头域中，如图10-17所示。

10.1.5.4 501

事件如图10-18所示，可以看到被叫用户发生了呼转。BICC的ACM信令携带的相关呼转信令如图10-19所示。NJDS13返回ACM消息之后与NJMGCF5BHW之间交互了三条APM消息，即相互交换彼此的媒体地址信息，为后续通话建立媒体通道，如图10-20所示。

如图10-21所示，我们可以看到本次呼叫未接通的原因是CS域返回了未接通的BICC信令REL消息，拆线原因为业务不可用（63）。MGCF转给IMS域的拆线信令为SIP信令501，携带了Q.850的拆线原因值63在Reason头域中，如图10-22所示。

10.1.5.5 400事件

如图10-23所示，可以看到本次呼叫未接通的原因是CS域返回了未接通的BICC信令REL消息，拆线原因为协议未指定（111），如图10-24所示。MGCF转给IMS域的拆线信令为SIP信令400，携带了Q.850的拆线原因值111在Reason头域中，如图10-25所示。

10.1.5.6 484事件

如图10-26所示，可以看到本次呼叫未接通的原因是CS域返回了未接通的BICC信令REL消息。拆线原因为无效号码格式（28），如图10-27所示。MGCF转给IMS域的拆线信令为SIP信令484，携带了Q.850的拆线原因值28在Reason头域中，如图10-28所示。

10.1.5.7 404事件

如图10-29所示，S-CSCF在分析被叫号码时发现被叫用户不存在，并针对主叫用户的Invite消息返回了404消息，消息里携带了未分配号码的原因值[插图][插图]。

主叫用户所在的MMTel AS针对404的失败场景进行了录音通知播放的处理，可以从MMTel AS返回S-CSCF的Update消息的P-E-M头域字段看到，如图10-30所示，网络侧录音通知播放的地址是**...***、端口号是21438，如图10-31所示。

如图10-32所示，主叫用户在2017-06-02 13:45:07.042000时开始听网络侧录音通知，2秒后于2017-06-02 13:45:09.047000挂机释放了本次呼叫。

如图10-33所示，UE和SBC、SBC和S-CSCF、S-CSCF和SCCAS、S-CSCF和MMTel AS之间均是通过Cancel、200 OK、487、ACK的消息对完成了本次业务呼叫的释放过程。

10.1.6 解决方案

通过上面的未接通时间的信令流程，我们可以总结出各个事件对应的话务场景及后续处理措施建议，如表10-3所示。