VoLTE端到端业务详解 | 语音质量问题

Posted COCOgsta

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了VoLTE端到端业务详解 | 语音质量问题相关的知识,希望对你有一定的参考价值。

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

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

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


10.4.1 基本知识

我们可以看到控制面的协议栈是SIP/TCP或UDP/IP、用户面的协议栈是净荷/RTP或+RTCP/UDP/IP,VoLTE业务的语音质量问题更加需要通过信令监测平台来处理。对于语音质量问题,我们一般会采取两步法,先查询用户的语音质量单据来定界,再查询用户的语音RTP/RTCP包来最终定位问题原因。

那语音RTP/RTCP包长得是什么样子,和信令控制面又有什么关系呢?

由于VoLTE业务的SIP信令在IMS网络的各个接口都能采集,信令面和控制面的对应关系存在于一个接口上,为了更好地理解用户面和信令面之间的对应关系,我们本次列举的是被叫Gm口的用户面和控制面的抓包样例。

采集接口:被叫SBC—被叫UE之间的Gm口。

1.用户面

(1)RTP包示例如图10-93所示。

(2)RTCP包示例如图10-94所示。

2.控制面

用户面与控制面需要一对一进行关联分析,抓取与用户面对应的控制面需要进行比对分析。

(1)典型呼叫流程。如图10-95所示,VoLTE用户发起语音呼叫时,前提条件是用户已注册到IMS网络并驻留在LTE网络,通过SIP消息携带SDP信息,完成会话承载的协商,主要包括承载的IP地址、端口号、编解码类型、打包时长等信息。

(2)主叫发给被叫的Invite消息中的SDP,携带的是主叫侧的媒体相关属性,包含媒体类型、端口号和媒体格式,如图10-96所示。

(3)被叫发给主叫的183消息的SDP,携带的是被叫侧的媒体相关属性(由被叫侧选择的主、被叫侧共同支持),包含媒体类型、端口号和媒体格式,如图10-97所示。

107编解码的含义:Media Attribute (a): rtpmap: 107 AMR-WB/16000/1。

101编解码的含义:Media Attribute (a): rtpmap: 101 telephone-event/16000。

由上面的信息,我们可以看出被叫侧优选的是AMR-WB的编解码。

我们从控制面可以看到RTP协议的端口号,针对VoLTE语音包的RTCP端口号=RTP端口号+1,即主叫发给被叫语音包的RTCP端口号为15641,被叫发给主叫语音包的RTCP端口号为31037。

根据RTP包的序列号可以看出是否有丢包,没有丢包的时候序列号是连续的,如图10-98所示。

同时,在RTCP包里我们也可看到无丢包的字段,如图10-99所示。

10.4.2 关键信息

对于VoLTE语音质量问题的定界,信令监测平台至少要保证S1-U、Mw或Gm接口中至少有一个接口具有VoLTE语音呼叫媒体面测量能力。对于VoLTE与VoLTE互通场景、VoLTE与2G/3G、PSTN互通场景,信令监测系统中的采集节点和语音质量指标所表示的测量范围如图10-100所示。

(1)对于VoLTE与VoLTE互通场景,端到端的MOS是根据RTCP消息统计的,RTCP消息也是UE<->UE的E2E透传。分段的IPMOS是根据RTP消息统计的,表示的范围为UE到RTP消息的采集节点。

(2)对于VoLTE与2G/3G、CSFB或者PSTN互通场景,端到端的MOS是根据RTCP消息统计的,具有发送RTCP的报文的网元包括VoLTE侧的UE和CS域的MGW,端到端范围实际为VoLTE的UE到CS域的MGW。分段的IPMOS是根据RTP消息统计的,表示的范围为UE或者CS域的MGW到RTP消息的采集节点。

(3)对于VoLTE与VoBB互通场景,与2G/3G互通场景类似。具有发送RTCP报文的网元为VoBB侧的SBC。端到端测量指标表示的范围为UE到VoBB侧的SBC,分段测量指标表示的范围为UE或者VoBB侧的SBC到RTP消息的采集节点。

(4)VoLTE业务语音呼叫的关键测量点有三个,包括振铃、应答和释放,以Gm接口为例,如图10-101所示。

① 测量点1:呼叫的承载建立,用户面开始周期测量,包括RTP包数、抖动、时延和编解码信息,基于这些信息可以计算语音的MOS值和单通情况,并记录语音开始的时间。

② 测量点2:呼叫应答,此时对振铃阶段的用户面的测量进行重置,重新开始进行周期测量,包括RTP包数、抖动、时延和编解码信息,以及基于这些信息计算的MOS值和单通情况,记录语音流的开始时间。

③ 测量点3:呼叫的承载释放,用户面停止测量,记录语音流结束时间。

呼叫结束后,对周期测量的MOS、单通记录做汇总,填写到呼叫单据CDR里,并且将整条语音流的RTP包数填写到呼叫单据CDR中。

(5)语音流的周期化概念。对于VoLTE语音呼叫,根据RTCP报文的周期上报时间,把语音流做周期化处理。RTCP消息一般默认每5秒上报一个(依赖终端的发送机制),网络带宽状况不同会得到不同的RTCP周期时长。信令监测平台根据RTCP的周期性规律测量,原理如图10-102所示。

① 对于呼叫过程中没有RTCP报文的呼叫,无法做RTCP的周期测量,语音流的CDR的MOS和根据RTCP得到的单通记录为0。

② 对于不满足最小测量周期的呼叫(短呼),无法做周期性测量,语音流的CDR的MOS和根据RTCP得到的单通记录为0。

语音质量关键测量信息如表10-5所示。

10.4.3 定界思路

本节讨论的是两种话务场景的VoLTE呼叫侧语音质量问题的定界,包含VoLTE与VoLTE互通、VoLTE和CS/PSTN/VoBB互通。

对于语音MOS质差问题的定界思路是对单接口不同节点的MOS进行有效地识别和差值计算,然后根据不同接口的MOS差值和MOS所表示的测量范围,确定质差MOS的引入范围。

对于单通问题的定界思路核心是对单通结果进行有效性识别,根据不同接口是否发生单通指标的差异与单通指标代表的测量范围,确定单通问题的引入范围。

10.4.3.1 上行质差问题

单接口上行质差MOS定界流程如图10-103所示。

① 第一步:判断上行MOS和上行IPMOS的有效性。

当上行MOS大于0时,则上行MOS有效,否则上行MOS无效;当上行IPMOS大于0,则上行IPMOS有效,否则上行IPMOS无效。

② 第二步:判断上行MOS或者上行IPMOS是否质差。

使用上行MOS判断质差,当上行MOS无效时,使用上行IPMOS判断。方法:当上行MOS有效,并且上行MOS小于质差阈值(注释1)时,则上行MOS质差,否则上行MOS非质差;当上行MOS无效,并且上行IPMOS有效,上行IPMOS小于质差阈值(注释1)时,则上行IPMOS质差,否则上行IPMOS非质差。对于非质差的上行MOS和上行IPMOS,不需要定界分析。

③ 第三步:对质差呼叫单据做分段MOS损失计算。

采集接口以上MOS损失:当上行MOS并且上行IPMOS有效时,计算为上行IPMOS分-上行MOS分;否则为0。

采集接口以下MOS损失:当上行IPMOS有效时,计算为编解码或者上行编解码平均速率对应的MOS(注释2)分-上行IPMOS分;否则为0。

上行编解码协商MOS损失:当编解码类型为AMR或者AMR-WB时,计算为编解码起始MOS(注释3)分-编解码或者上行编解码平均速率对应MOS(注释2)分;否则为0。

④ 第四步:对质差呼叫单据做质差范围定界。当上行MOS质差,上行IPMOS无效时,无法准确定界质差引入范围。对采集接口以上MOS损失、采集接口以下MOS损失、上行编解码协商MOS损失取最大值,得到与最大值相应的主要质差引入范围。

注:注释1,参考质差MOS配置说明;注释2,参考编解码或者编解码平均速率对应的MOS分计算说明;注释3,编解码起始MOS计算说明。

10.4.3.2 下行质差问题

单接口下行质差MOS定界流程如图10-104所示。

① 第一步:判断下行MOS和下行IPMOS的有效性。

当下行MOS大于0时,下行MOS有效,否则下行MOS无效;当下行IPMOS大于0时,下行IPMOS有效,否则下行IPMOS无效。

② 第二步:判断下行MOS或者下行IPMOS是否质差。

使用下行MOS判断质差,当下行MOS无效时,使用下行IPMOS判断。方法:当下行MOS有效,并且下行MOS小于质差阈值(注释1)时,下行MOS质差,否则下行MOS非质差;当下行MOS无效,并且下行IPMOS有效,下行IPMOS小于质差阈值(注释1)时,则下行IPMOS质差,否则下行IPMOS非质差。对于非质差的下行MOS和下行IPMOS,不需要定界分析。

③ 第三步:对质差呼叫单据做分段MOS损失计算。

采集接口以下MOS损失:当下行MOS并且下行IPMOS有效时,计算为下行IPMOS分-下行MOS分;否则为0。

采集接口以上MOS损失:当下行IPMOS有效时,计算为编解码或者下行编解码平均速率对应的MOS(注释2)分-下行IPMOS分;否则为0。

下行编解码协商MOS损失:当编解码类型为AMR或者AMR-WB时,计算为编解码起始MOS(注释3)分-编解码或者下行平均编解码速率对应MOS(注释2)分;否则为0。

④ 第四步:对质差呼叫单据做质差范围定界。

当下行MOS质差,下行IPMOS无效时,无法准确定界质差引入范围。

对采集接口以下MOS损失、采集接口以上MOS损失、下行编解码协商MOS损失取最大值,得到与最大值相应的主要质差引入范围。

10.4.3.3 上行单通问题

单接口上行单通定界流程如图10-105所示。

· 第一步:判断是否发生过上行单通:当单通标记为上行单通或者双向不通时,则说明发生过上行单通;否则,不需要定界分析,结束。

· 第二步:判断是否发生上行单通(RTP):当上行单通(RTP)时长>0,则发生上行单通(RTP),定界结果为采集接口以下原因,结束;否则,定界结果为采集接口以上原因,结束。

10.4.3.4 下行单通问题

单接口下行单通定界流程如图10-106所示。

① 第一步:判断是否发生过下行单通:当单通标记为下行单通或者双向不通时,则发生过下行单通;否则,不需要定界分析,结束。

② 第二步:判断是否发生下行单通(RTP):当下行单通(RTP)时长>0,则发生下行单通(RTP),定界结果为采集接口以上原因,结束;否则,定界结果为采集接口以下原因,结束。

10.4.3.5 定界计算参考信息

因为计算MOS的算法模型可使用P.862.1和P.863 SWB两种计算模式,默认使用P.863 SWB模式,需要提前获取MOS的评分模式。

① 质差MOS阈值说明:当使用P.863 SWB时,质差阈值使用2.0;当使用P.862.1时,质差阈值使用2.8。

② 编解码或者编解码平均速率对应的MOS分计算说明,如表10-6所示。

x表示平均速率,y表示某平均速率对应的MOS分值。

③ 编解码起始MOS计算说明:当使用P.863 SWB模式时,对于AMR-WB编解码起始分为4.349,对于AMR编解码起始分为3.219;当使用P.862.1模式时,对于AMR-WB编解码起始分为4.2,对于AMR编解码起始分为4.134。

10.4.4 分析示例

目前,信令监测平台一般支持导出RTP/RTCP原始包,利用Wireshark来解析RTP/RTCP原始语音包可以验证质量单据的查询结果以及分析单通等语音质量问题。

比如,信令监测平台打开界面如图10-107所示。

如果导出来的RTP/RTCP原始包界面显示为UDP,则需要先做RTP协议栈解析,如图10-108所示。

1.RTP包总包数和丢包数的计算方法

总包数=RTP头中最大SN号-RTP头中最小SN号

丢包数=RTP报文中丢包数(后一个RTP SN-前一个RTP SN+1)

2.上下行方向的确定方法

在分析语音包之前需要确定主叫用户的上、下行包的源和目标端口号。主叫UE在给主叫SBC发送的Invite消息中获取主叫用户上行RTP包的源端口号,查询媒体端口、协议RTP(RTCP的对应端口号是RTP包的端口号+1)。从图10-109中我们可以看到主叫用户上行RTP包的源端口号是49120,同时可以计算出发出的主叫UE上行RTCP包的源端口号是49121。

同时,随机点击一个RTCP包可以看到源端口号是32193,目标端口号是49121,RTCP包是被叫UE发给主叫UE的,可以计算出被叫用户上行RTP包的源端口号=32192(32193-1),即主叫用户的上行RTP包的目标端口号=32192,如图10-110所示。

从前面分析可以看到主叫用户上行方向RTP包的源端口号是49120、目标端口号是32192;RTCP包的源端口号是49121、目标端口号是32193。

说明:

(1)RTP端口号与RTCP端口号之间的关系为RTCP=RTP+1;

(2)RTP报文使用的UDP层的端口号通常是偶数,RTCP报文使用的UDP层的端口号通常是奇数;

(3)上行方向的RTCP获取的是下行方向RTP的测量结果,下行方向的RTCP可获取的是上行方向的RTP的测量结果。

3.RTP丢包的分析方法

以主叫用户为例进行介绍,上面的示例中使用udp.srcport==49120为过滤条件,筛选主叫侧的发包,即上行包;反之,使用udp.dstport==49120为过滤条件,筛选主叫侧的收包,即下行包。本

次我们仅分析上行方向,下行方向的分析方法与上行方向的分析方法一样。

(1)如图10-111所示,过滤udp.srcport==49120,最大Seq=2173,最小Seq=0,共2174个包,RTP上行包数为2174个。

(2)如图10-112所示,导出CSV统计结果,分析发现SN=465这个包丢了,实际收到2173个包,丢了一个包。

通过以上分析,上行RTP包总共2174个,实际收到2173个包,丢了一个RTP包(SN=465),如图10-113所示。

4.RTCP丢包的分析方法

(1)RTCP总包数=后一个RTCP报文中的HSN-前一个RTCP报文的HSN,其中第一个RTCP计算方式为减去第一个RTP的SN。

(2)丢包数=RTCP报文中丢包数。

为分析主叫用户的上行方向RTCP丢包情况,我们需要分析被叫UE给主叫UE发送的RTCP包,这个方向才是表征主叫UE给被叫UE发送的包的整体情况。

被叫UE给主叫UE发送的RTCP包的源端口=32913,目标端口=49121,筛选出的上行RTCP包如图10-114所示。根据最大HSN来计算,计算结果如图10-115和图10-116所示,终端总共收到2094个包,丢了一个包,一共2095个包。

从图10-117可以看到,基于RTP、RTCP,包的分析与信令监测平台的质量单据一致。

以上是关于VoLTE端到端业务详解 | 语音质量问题的主要内容,如果未能解决你的问题,请参考以下文章

VoLTE端到端业务详解 | 高清语音的概念

VoLTE端到端业务详解 | 编解码基础知识

VoLTE端到端业务详解 | 应用实例二

VoLTE端到端业务详解 | 基本概念

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

VoLTE端到端业务详解 | 掉话问题