从高标清的指标和资源对比来看，本身AMR-NB和AMR-WB对于网络资源的利用程度来看差距不大（PRB上占用差不多），但AMR-WB对于网络资源的利用率会相对高些（高清的码率更高），且AMR-WB的用户体验更好（MOS值高于AMR-NB一截），且抗干扰性上并没有明显差别，因此在VoLTE将来部署中，更推荐采用AMR-WB编码制式。

问题5：终端正确设置下仍无法进行高清语音通话的原因？

答：TAS License过期使得VoLTE高清不支持，用户无法进行高清语音通话。以现网测试案例为例，外场测试发现设置为23.85k的速率，看到PDCP速率只有12.2kbps左右，与23.85kbps预期24kbps的速率不一致。

AMR和AMR-WB是终端和网络侧协商的结果。需要从终端和网络侧两侧分析解决。

1）需要先排查终端侧设置是否正确。在主叫的invite消息里发现主叫是支持AMR和AMR-WB。说明NV参数设置正确且已生效。

2）从被叫测试查看invite消息发现，网络侧未下发AMR-WB速率。基本上确认是网络侧把AMR-WB丢弃。

3）通过IMS核心抓包分析得知，经过TAS后，AMR-WB被丢弃。确认为TAS的问题。经确认9月初TAS版本升级，AMR-WB LICENSE 没有及时打上。

TAS 添加license后，外场验证，高清电话可以正常拨通：

问题6：手机通话中出现FAST BOOT的可能原因是什么？

答：基站侧zuc算法打开后可能会导致手机通话出现FAST BOOT问题。以现网测试案例为例，用HTC M8对在目前LTE弱覆盖或信号质量差的网络环境下的通话质量进行MOS评估时，发现通话拨打8S左右通话中断，手机进入FAST BOOT工程模式。更换站点后恢复，再回到问题站点拨打电话，分析EMIL包后发现该基站ZUC加密算法开关打开，且ZUC算法优先级为最高，让后台修改为现网站点基本设置后恢复正常。

更改站点后手机通话恢复正常，可以判断为站点问题。在后台检查后发现该基站并无告警，排除由硬件故障造成的通话问题。由EMIL包中ATTACH REQUEST里UE CAPBILITY列出终端支持使用ZUC算法。（注意EEA3与EIA3的值都为1）

为确定M8在该站下是否使用ZUC算法，通话先在其他站点建立后再切换进问题站点，从切换请求中可以看出切换后进入问题站点选择的加密算法为EEA3、EIA3，且切换完成6S后手机进入FAST BOOT模式。确定问题为ZUC算法的启用导致。（下图为切换入问题站点后选择的加密算法，基站R10以前的版本是spare5， R11后改成了eea3和eia3）

通过后台关闭ZUC算法，问题解决。

由于ZUC是3GPP R9才加入的算法，故R9之前的终端并不支持ZUC算法。同时R9的终端如HTC M8也并不完全支持在使用ZUC算法的前提下进行所有业务。

问题7：专用承载MAX GBR值对通话质量有什么影响？

答：专用承载MAX GBR太小将导致的通话质量差。以现网测试案例为例，用CDS 48KMOS盒对在目前LTE网络下的通话质量进行MOS评估时，发现当通话建立在专用承载（GBR）下时CDS MOS打分值偏低。偶然间发现建立在默认承载上的通话MOS值正常可以达到4分。估计为专用承载问题，再用8K语

音文件进行MOS打分又恢复正常，确定为速率问题，调整QCI1 MAXGBR参数后恢复正常。

VOLTE通话评估软件反映通话质量分值低，经监控基站无告警，接入指标正常，更换站点并重新导入参数后仍存在问题。曾尝试在默认承载下进行语音通话发现质量评估并无问题。初步判定为专用承载问题。如下图所示（左图为QCI1下，右图为QCI9下）。

选用8K采样的语音文件再次进行MOS打分时发现QCI1下的MOS值恢复正常

采样率不同的区别在于传输时速率不同定位问题点于QCI1专用承载的最高速率没有达到48K语音的传输要求。在对比查看QCI1与QCI9的MAX GBR后确定了问题原因。下图是QCI1修改前的参数（图中MAX GBR数值为换算后结果，下同）