Volte4VoLTE语音高质量优化案例14个.docx
《Volte4VoLTE语音高质量优化案例14个.docx》由会员分享，可在线阅读，更多相关《Volte4VoLTE语音高质量优化案例14个.docx（36页珍藏版）》请在冰点文库上搜索。
Volte4VoLTE语音高质量优化案例14个
VoLTE语音质量优化
案例1：
VoLTE窄带与宽带语音质量对比
【问题现象】
在3GPPLTE中，VoLTE业务编码有AMR-NB窄带和AMR-WB宽带两种编码，两种编码速率具有不同的话音质量，所以又分别称为VoLTE标清语音（或VoLTE12.2kbps）和VoLTE高清语音（或VoLTE23.85kbps）。
【问题分析】
AMR-NB和AMR-WB这2种编码具有如下特点：
●每20ms产生一个语音包，包括了RTP/UDP/RLC-Security压缩头；
●每160ms生成一个SID语音静默包。
●帧长20ms；
AMR-NB编码特点为：
●4.75kbps到12.2kbps共8个码率，分别为：
4.75、5.15、5.9、6.7、7.4、7.95、10.2、12.2kbps；
●采样率为8kHz。
AMR-WB编码特点为：
●6.6kbps到23.85kbps共8个码率，分别为：
6.6、8.85、12.65、14.25、15.85、18.25、19.85、23.05、23.85kbps；
●采样率为16kHz。
可见两者显著的差异是采样速率不一样，窄带一个语音帧是160个点，宽带一个语音帧采样320个点。
AMRNB的语音带宽范围：
300－3400Hz，8KHz采样。
AMRWB的语音带宽范围：
50－7000Hz，16KHz采样。
用户可主观感受到话音比以前更加自然、舒适和易于分辨。
AMRWB与AMRNB不同之处在于AMRWB按16kHz采样，分别按频率带50~6400Hz 和6400~7000Hz进行编码。
用来降低复杂度，AMRWB将位算法集中到更重要的频率区。
低频带使用ACELP算法进行编码。
添加几个特征来达到一个高的主观质量。
线性预测（LP）算法是在每隔20ms的帧要进行一次线性预测算法，每5ms搜索一次自适应码本，这个过程是在12.8Kbs速率下进行。
高频带是在解码器端使用低带和随机激励的参数重建的,目的是调整与在声音基础上的低频有关的高频带.高频带的声频通过使用由低带LP过滤器产生的LP滤波器进行重建。
AMRWB与AMRNB的MUSHRA评分（multi-stimulustestwithhiddenreferenceandanchor，ITU-RrecommendationBS.1534.）参考见下图。
利用传统的MOS值进行AMR-NB和AMR-WB进行对比测试，结果如下图：
由以上分析可见AMR-WB比AMR-NB有更高的话音质量。
【问题解决】
在语音质量上AMR-WB更优于AMR-NB，因此AMR-WB又称为高清语音。
（1）
案例2：
VoLTE与GSM语音质量比较
【问题现象】
杭州现场使用POLQASWB评分标准，评估GSM打GSM，VoLTE（23.85kbps）和VoLTE（12.65kbps）三种长呼语音质量，VoLTEMOS相比GSM有较大改善，MOS评分参见下表。
语音拨打类型
MOS（POLQASWB）
2G打2G
2.64
VoLTE（23.85kbps）
3.98
VoLTE（12.65kbps）
3.84
【问题分析】
2G使用窄带语音AMR-NB12.2k和EFR编码方式，使用POLQASWB评分时会比传统PESQ评分会低，具体映射关系如下：
表从上可以看出：
AMR（12.2k）/EFRPOLQA评分先比PESQ评分低0.5分左右。
按照上表，将2G打2GMOS（POLQASWB）折算为PESQMOS分应为2.64+0.5=3.14分。
分析2GMOS分值，大量2分MOS分值对应的语音编码方式为EFR，AMR12.2k编码MOS分一般在3分左右。
【问题解决】
POLQASWB评分按照64Kbps采样率进行语音质量评分，评分标准比传统PESQ高。
同样的2G语音，POLQA评分先比PESQ评分低0.5分左右。
案例3：
VoLTE与OTT语音质量比较
【问题现象】
微信电话本是腾讯公司在2014年11月11日推出的基于微信的VoIP电话，其具有低接通时延、无通信费用（仅有流量费用）和高清晰音质等特点。
微信电话本对语音业务有很强的替代作用。
对微信电话本和VoLTE电话进行了对比测试，分析其产品差异。
【问题分析】
VoLTE试点区域内共有4G基站400个，主覆盖区域为D频段，覆盖良好。
使用设备为ASCOM公司的TEMS16.1.3，测试手机为HTCM8t。
1、音质对比分析
从现有的PDCP层速率和MoS进行推测，微信电话本采用的编码为skype的SILKCodec。
SILKCodec是一个语音和音频编解码算法,对于音频带宽、网络带宽和算法复杂度都具有很好的弹性，支持4种采样率：
8KHz、12KHz、16KHz、24KHz；三种复杂度：
低、中、高。
编码码率在6~40kbps（不同采样率具有不同的码率范围）以及还支持VAD、DTX、FEC等模块，已经在QQ，AIM，GOOGLETALk上使用，性能在高掉包环境下优于AMR-WB。
为适应其编码方式，这里采用的打分标准使用基于48K采样的POLQA。
微信电话本在好点（-88.33dBm，12.67）下，其MoS可以达到3.78，在坏点为1.93。
在坏点的条件下，其时延，抖动，丢包都在急剧上涨，用户感知急剧降低。
而VoLTE具备QoS保障，其MOS比较稳定，无明显波动，祥见下表。
对比项目
RSRP
SINR
端到端时延（POLQA）
抖动（ms）
丢包率（%）
最大连续丢包数（%）
控制面切换中断时延
MOS
微信电话本
-88.33
12.67
无
7.21
0.33
2.00
35.62
3.78
-116.97
0.94
1151.00
28.44
4.73
无数据
1.93
VoLTE
-89.53
11.72
255.14
8.13
0.09
3.40
31.31
3.86
-114.83
0.53
227.36
5.93
0.25
2.00
3.89
为进一步对其微信电话本的语音MOS值进行分析，找出其能力拐点，优化人员对其RSRP的从-125dBm到-110dBm，SINR从-4到10的范围进行测试，详见下图。
从RSRP走势中可以看出:
在RSRP>-110dBm，SINR>10的在LTE轻载网络环境下，MOS可以保持在3.5以上。
当RSRP>-111dBm的时候，语音质量会出现大幅提升，MoS会大于3.22，已经超过了GSM的MoS，其音质和VoLTEAMR-WB在感知上差异不大。
从SINR走势中可以看出，其在3的时候，其质量会出现大幅提升，MoS会到2.85以上，已经超过GSM的EFR的MoS，当SINR提升到9的时候，其值已经和VoLTE差距不大。
下图4个波形分为标准语料，GSM波形，VoLTE波形和微信波形。
微信语音压缩方法与2G/4G不一样，微信语音对标准语料毛刺部分压缩比较干净，将标准语音样本中的背景噪声被简单给过滤掉了，故MOS峰值较低。
在同样的MOS分下，用户可能会觉得微信声音更加干脆清澈。
测试标准语料GSM语音波形
VoLTE23.85高清语音波形微信电话本语音波形
2、容量对比分析
微信电话本采用SLIK编码，具备VAD、DTX、FEC能力，具备不连续发射，静默期检查，前向纠错能力。
微信电话本传输效率要低于VoLTE。
下表为微信电话本和VoLTE在好点时候的资源占用情况。
微信电话本和VoLTE高清语音的网络好点资源占用对比
类型
SINR
下行
上行
物理层速率（kbps）
PDCP速率（kbps）
平均MCS
RB数
TBsize（bite）
物理层速率（kbps）
PDCP速率（kbps）
MCS
RB数
TBsize（bite）
微信电话本
18.26
58.14
40.27
19.77
3.28
1268.24
52.76
40.33
22.45
2.5
1285.14
VoLTE
20.02
18.2
11.13
15.26
2.8
819.47
21.82
11.21
22.01
1.68
1086.69
微信语音每TTI调度RB数和VoLTE（23.85k）基本近似，微信没有语音静默包，每TTI调度次数明显高于VoLTE，微信语音总调度RB数明显高于VoLTE。
微信电话本和VoLTE高清语音的网络差点资源占用对比（下行）
类型
SINR
物理层速率（下行）
PDCP速率（下行）
传输模式
MCS
每TTIRB数
总调度RB数
TBsize
微信电话本
-0.09
50.48
36.23
2.00
6.31
11.94
910.89
668.44
VoLTE
0.02
15.61
10.44
2.15
4.95
8.78
227.22
590.79
微信语音包走默认承载，没有RoHC功能，语音包大于VoLTE，与不打开RoHC的VoLTE语音包相似）。
RoHC功能开启对VoLTE语音包压缩参见下表。
语音
AMR封装负荷
RTP
UDP
IP
PDCP头
RLC头
MAC头
Total
VoLTE23.85
477+21
96
64
320
8
8
16
1010
VoLTE23.85（RoHC）
477+21
40
8
8
16
570
微信语音没有语音静默包，不具备头压缩功能，导致微信PDCP速率（40k左右）高于VoLTE（10k左右）。
按好点的包大小计算，微信语音每分钟消耗流量为（40.27+40.33）*60/8=600kbyte，其通话一个小时占用流量为35Mbytes。
如按移动的50元1G进行收费，其50元可以通话1700分钟左右，折合3分钱/分钟，且无长途，漫游费用，其资费优势明显。
在差点时，微信语音掉包和时延会恶化，资源占用会加大。
从现网测试情况看：
在-110dBm，SINR=0的情况下，会占用12个RB,资源占用增加了三倍，VoLTE占用9个RB。
在资源紧张时，VoLTE有QoS保障机制，语音各项指标会远好于微信电话本。
从无线环境和微信电话本语音包大小进行走势对比，可以清楚的发现：
当其无线环境好的时候，其语音包较大，语音采样编码方式越高，语音越清晰，用户感知越好。
当无线环境恶化时，语音采样编码方式变差，用户感知不好。
案例4：
小区边缘通话时下行BLER较高导致质差
【问题现象】
统计发现，爱立信VoLTE测试的DLBLER在SINR低于-2dB后严重下降，高于10%。
【问题分析】
其他厂家多在8天线的环境下测试，而爱立信的测试结果都是在2天线的环境下测试得出，少了波束赋形的增益。
【问题解决】
在8天线的环境下，DLBLER有了较大的提高，在SINR=-6左右也没有达到10%。
【问题后续建议】
在8天线的环境下，DLBLER的指标有大幅提升，BLER控制在10%之内。
厂家应针对2天线环境提出相应的算法改进，保证网络质量。
案例5：
ZUC算法开启导致R8终端通话8S自动中断
【问题现象】
用HTCM8对在目前LTE弱覆盖或信号质量差的网络环境下的通话质量进行MOS评估时，发现通话拨打8S左右通话中断，手机进入FASTBOOT工程模式。
更换站点后恢复，再回到问题站点拨打电话，分析基站侧EMIL包（EMIL为诺基亚内部用于分析基站侧log的一个工具）后发现该基站祖冲之ZUC加密算法开关打开，且ZUC算法优先级为最高。
【问题分析】
更改站点后手机通话恢复正常，可以判断为站点问题。
在后台检查后发现该基站并无告警，排除由硬件故障造成的通话问题。
由EMIL包中ATTACHREQUEST里UECAPBILITY列出终端支持使用ZUC算法。
（注意EEA3与EIA3的值都为1）
为确定M8在该站下是否使用ZUC算法，通话先在其他站点建立后再切换进问题站点，从切换请求中可以看出切换后进入问题站点选择的加密算法为EEA3、EIA3，且切换完成6S后手机进入FASTBOOT模式。
确定问题为ZUC算法的启用导致。
（下图为切换入问题站点后选择的加密算法，基站R10以前的版本是spare5， R11后改成了eea3和eia3）
由于ZUC是3GPPR9才加入的算法，故R9之前的终端并不支持ZUC算法。
部分R9的终端（如HTCM8）并不完全支持在ZUC算法开启下进行所有业务。
【问题解决】
通过后台关闭ZUC算法，问题解决。
案例6：
基站不支持VoLTE功能导致切换掉话
【问题现象】
终端无线链路失败后在PCI329上重新建立RRC连接，网络侧没有建立专用承载，5s之后网络侧发送SIPBYE503导致掉话。
【问题分析】
问题出现的过程如下图，当MO/MTUE在PCI343上出现无线链路失败后，在PCI329上进行重建，被拒绝。
之后同时在PCI329上建立RRC连接，但是网络侧并没有建立专用UM承载，RTP在AM承载上传输5s之后，MO/MTUE收到IMS发送的SIPBYE503消息，原因是“Sessionreleased-lossofbearer”。
进一步确定站点的位置，如下图，我们可以发现PCI329在试验区域之外，存在越区覆盖现象。
该站未开启VoLTE功能。
【问题解决】
首先应保证测试过程中终端收到信号的所有基站均支持VoLTE功能。
其次应对网络进行优化，尽量减少越区覆盖。
此外，在VoLTE开通的过程中，应保证成片开通。
案例7：
跨MME定时器超时导致切换失败率高
【问题现象】
丽水VoLTE测试区域采用新建D频段基站区域，为避免对现网影响，核心网侧采用单独的MME进行管理，与现网F频段基站分属不同的MME。
测试中通过网管统计发现F频段与D频段间的S1切换成功率较低，从核心网侧信令看基站侧频繁进行S1切换请求和切换取消，见下图：
【问题分析】
根据核心网信令对应失败的基站ID，分析基站侧的日志文件，发现目标基站每收到一条HOREQUEST都回复了HOREQUESTACK，没有FAILURE的消息，表明目标侧没有处理失败的；而源侧基站发送了HOREQURIED消息后，没有收到MME反馈回来的HoCommand消息，之后S1切换准备定时器超时后，源基站发起了HoCancel，从而导致切换失败，即切换的消息交互需要的时间较长，原因是两个基站处在不同的MME下。
【问题解决】
丽水VoLTE测试基站下挂在杭州MME下，与本地MME不在同一个POOL内，切换需要时间较长。
为了避免定时器切换超时，可以将基站侧的S1切换准备定时器修拉长进行规避解决。
【问题后续建议】
因该类切换为跨MME切换，完成切换需交互时间变长，为了避免定时器切换超时造成切换失败，将基站侧的S1切换准备定时器调整到3s解决。
案例8：
基站版本不同导致站间切换失败
【问题现象】
在进行室内外切换测试中，室外站为Band38（EARFCN37900，PCI48），R10版本，室内站为Band40（EARFCN38950，PCI0），R8版本。
当进行室外站至室内站切换时，出现RLF导致切换失败。
【问题分析】
如下图所示的信令，当UE驻留在PCI48（室外站）站上时，该eNB为UE配置的AntennaInfo参数为AntennaInfo-r10格式。
但是当UE切换至R8版本的PCI0（室内站）的过程中，eNB下发给UE的重配置消息中的AntennaInfo字段为AntennaInfo格式（即r8格式），而不是一个完整的配置，如下图信令：
UE对收到的切换命令进行检查时，发现对antennaInfo参数的配置不正确而导致切换失败，从而触发RLF。
【问题解决】
按照标准要求，在往低版本基站的切换命令中再增加一个内容为空的AntennaInfo-r10字段。
附：
3GPP36.311中如下规定此种情形。
案例9：
跨厂家站点间切换失败
【问题现象】
在跨厂家区域做切换验证，从诺基亚到中兴切换都成功，中兴小区（PCI=29）到诺基亚小区（PCI=264），切换均失败，原因为网路侧配置错误。
【问题分析】
如下图所示的信令，当UE驻留在PCI29小区时，该eNB为UE配置的AntennaInfo参数为AntennaInfo-r10格式。
当UE切换至诺基亚小区PCI=264的时候，eNB下发给UE的重配置消息中的AntennaInfo字段为AntennaInfo格式（即r8格式），而不是一个完整的配置，如下图信令：
UE对收到的切换命令进行检查时，发现对antennaInfo参数的配置不正确而导致切换失败，从而触发RLF。
【问题解决】
9月中旬外场升级了基站版本。
升级后用高通终端验证室内外切换均正常。
案例10：
QoS配置不全导致切换失败
【问题现象】
测试发现爱立信pci440小区与pci89小区之间切换失败。
【问题分析】
复测之后回放log，发现VoLTE掉话频繁出现在pci440与pci89的两个小区切换的时候。
UE在从pci440的小区往pci89的小区切换的时候，专载被释放。
检查了pci89的配置，虽然在同一个MMEpool下，虽打开了VoLTE功能，但基站侧并没有做VoLTE所需的QoS配置（MultipleERABperuser，RoHC，RLCUM等）。
其中如果没有MultipleERABperuser的话，基站侧将不会支持多个ERAB的建立，从而导致专用承载的释放。
在VoLTE站点pci440与非VoLTE站点pci89的切换过程中，由于关键的VoLTEQoS配置的缺失，造成网络侧释放专载。
【问题解决】
该站点做了VoLTE所需的QoS配置后，切换正常。
案例11：
上行链路干扰导致VoLTE呼叫成功率低
【问题现象】
在定点测试所选择的某干扰严重基站，基站所接收到的干扰功率高达-69dBm，导致RRC连接不能正常建立，VoLTE的呼叫建立成功率仅为5%。
【问题分析】
我们分析测试log也可以看出，在此上行干扰严重的场景下，下行物理层重传比例很大，BLER非常高。
同时，由下图可以看出，由于未配置TPCCommand或TPCCommand=0，网络无法快速地提高PUSCH的发射功率。
针对干扰功率高的问题，首先排查该站点天面情况如下图，我们可以发现在移动TD-LTE站点天面的旁边存在电信FDD-LTE站点，两者天线距离较近，隔离度不够，电信Band3FDD-LTE的下行信号（1860-1875MHz）对中国移动Band39TD-LTE的上行信号（1880-1900MHz）存在干扰。
从TD-LTE的eNB侧统计的底噪（见下图）也可以看出，此站点存在明显的杂散干扰，与FDD频段对TDD频段的杂散干扰相吻合。
【问题解决】
建议全面排查Band39基站上行链路的干扰水平。
对于干扰严重的站点，采取相应措施，如调整天线位置，增加隔离度等。
【问题后续建议】
对于异常项目测试，修改配置未能做好记录和管理，导致影响到正常用例测试。
后续将做好配置修改的记录和管理工作。
案例12：
VoLTE终端被叫按CSFB接通
【问题现象】
在高通测试的过程中，被叫经常收到CSpaging，发生CSfallback。
【问题分析】
在VoLTE普通拨测过程中，经常出现被叫CSFB的情况，如信令截图所示，收到CSpaging，然后开始CSFB的流程，并不是预期的VoLTE通话。
复现问题，从IMS节点抓包分析：
可以看到在主叫发起invite之后，被叫回复的SIP信令100trying当中，这个通话并不被认为是VoLTE通话。
再追溯原因，发现IMS在TADS查询的时候失败，继续查CSRN时返回“diameterunabletocomply”，因此TADS回复的是2/3G，这个通话被认为是2/3G的通话
产生这个现象的原因是：
●被叫终端设置为2/3/4G模式，因而在经过某些4G弱信号点时，会暂时重选登上2G网络，回到4G信号好点时会自动返回4G。
●2G回到4G的过程中，4GTAU流程会触发网络侧流程，通过HSS向HLR发起CancelLocation清除用户原本在2G的位置信息。
在GZUDC06的默认配置里，HSS以轮询方式选择HLR13、HLR14执行CancelLocation操作。
由于南沙HSS13（包括HLR13）VoLTE调测并未完成，导致HSS选择HLR13进行CancelLocation时不能完全成功，用户在2G的位置信息会残留在系统中。
●虽然该用户早已经回到4G并成功注册，上述的2G位置信息残留会导致错误的被叫域选，因此出现了被叫CSFB的情况。
【问题解决】
该问题在调整HSS配置后解决，网络CancelLocation功能恢复正常，VoLTE被叫域选正确，不再出现CSFB呼叫。
案例13：
不同速率自适应语音编码
【问题现象】
在RTP包的净荷中包含四个bit表达CMR（codecmoderequest）编码模式请求，由发送者向接受者的请求发送者编码器将来的编码速率模式，保存帧类型索引，如果是AMR，取值范围为0-7，表示8种速率模式，如果为AMR-WB，取值范围为0-8，表示9种速率。
取值15意味着当前是没有指定哪个模式的请求。
【问题分析】
宽带语音编码速率自适应有两种方式：
（1）终端自身触发；
（2）基站侧的ECN（ExplicitCongestionNotification）显示拥塞指示来触发UE修改自己的编码速率。
对于ECN，在IMSSDP协商时，终端需要将其支持ECN机制的能力通知给网络。
通过IP使用包头中的未使用字段来支持ECN。
IP包头中的8位的服务类型域（TOS）原先在RFC791中被定义为表明包的发送优先级，时延，吞吐量，可靠性和消耗等特征。
在RFC2474中被重新定义为包含一个6位的区分服务码点（DSCP）和两个未用的位。
当UEB决定激活ECN时，UEB就在IP头ECN位打上“01”或“10”，当eNBA拥塞时，就会将ECN位设置为“11”。
当UEA收到“11”的IP后，UEA就会在TCP的Ack消息里面设置ECN-echo标识。
当UEB收到ECN-Echo标识的ACK消息后，UEB就会降低速率。
ECN功能用于语音在TS26.114中有描述，当发生大量丢包时，可以采用ECN功能降低包大小，需要通过CMR告知编码端，从而增加覆盖语音的覆盖。
编码速率越高，语音质量越好，但是抗干扰能力越弱，所以根据信道传输状况优化编码类型，可以提供更好的话音质量。
AMR在传输情况较好的情况下，更多的bit用来传送话音。
增加网络容量及提升覆盖：
在弱覆盖区域采用bit数目较少的编码方式可吸收更多话务提高网
升级会员 