VoLTE维护优化丛书

第1章VoLTE网络配置篇无线测试涉及的网络参数如下表所示：第2章厂家个性VoLTE质量问题篇问题1：IMS无法注册的可能原因？答：手机附着LTE网络并成功建立QCI9承载后PDNconnectivityreject,无法建立QCI5默认承载，将导致无法成功注册IMS。如下图所示：手机attachrequest-attachcomplete过程已经建立QCI=9的信令承载，UE会在PDNConnectivityRequest消息中包含APN信息，从HSS取得的订阅信息中，Service-Selection=wildcard，所以MME接受UE请求的APN。根据新的APN，分配一个BearerID给defaultEPS，并且发送CreateSessionBearerRequest到S-GW。S-GW会在它的EPSBearer表中创建一个新的实体，并且发送CreateSessionRequest到P-GW中。S-GW会为ControlPlane和UserPlane创建新的DLS-GWTEID并且把他们发送到P-GW，创建QCI5默认承载。因此PDNCONECTIVITYREJECT会导致无法建立QCI5的默认承载，直接导致IMS无法注册。1）如果是ESM过程导致的拒绝（比如默认承载建立失败），才会带PDNCONNECTIVITYREJECT消息，EMM层拒绝，只有ATTACHREJECT消息。2）如果拒绝原因值是unknownEPSbearercontext，UE会本地去激活存在的默认承载或专用承载3）常见的拒绝原因有：IMSI中的MNC与核心网配置的不一致。以下为可能的解决方法：1：检查核心网和eNB侧是否存在相关告警并及时处理2：查看拒绝原因，核查相应参数是否配置正确（IMSI中的MNC与核心网配置的不一致,APN的设置不当等问题）3：是否存在SIM问题及核心网对SIM卡实行限制相应功能及接入等级4：SIM卡和核心网HSS记录信息不一致导致无法注册5：PDN请求拒绝大部分是核心网问题，可以通过抓取信令分析问题2:VoLTE中呼叫前转、呼入限制等补充业务由哪个网元提供数据配置？答:UtAS是提供业务逻辑和业务执行的应用服务器，VoLTE中使用其进行UE到业务AS的业务数据管理配置，提供设置、取消业务数据，激活、去激活业务等功能。UE与UtAS间的接口称为Ut接口，使用XCAP协议，提供补充业务数据配置功能。UtAS包含网络应用功能（NAF,NetworkApplicationFunction）与引导服务器功能（BSF,BootStrappingFunction）两项主要功能实体，提供用户鉴权认证与业务鉴权认证，AS选择和路由重定向功能。其接口流程如下图：UE到NAF之间的补充业务配置消息主要是GET或PUT消息，这些消息在经过NAF完成业务认证通过后，转发到相应的AS。GET信息主要用于获取补充业务的信息，PUT消息主要用于设置补充业务(激活/去激活/修改)，其主要携带参数包括：RequestURI、X-3GPP-Asserted-Identity、Host、Authorization、Content-Type。其中，Authorization参数是UE发给NAF中携带用于鉴权，NAF(AP)发给AS(AP)的消息中不需携带此参数。其中Request-Line参数中携带的UtapplicationID信息，以及Host参数与Authorization参数中携带的NAF与BSF域名信息，UE侧配置需与网络侧配置相同。测试中发现呼入限制、呼叫转移等补充业务配置失败时，建议优先核对相关信息。相关信息建议配置如下：NAF：xcap.ims.mnc002.mcc460.pub.3gppnetwork.orgBSF：bsf.mnc002.mcc460.pub.3gppnetwork.orgUtapplicationID：simservs.ngn.etsi.org问题3：为什么HTCM8终端回落至2/3G后强锁4G无法正常进行VoLTE语音业务？答：在现网测试中发现以下案例：HTCm8终端在回落至2/3G后，如果此时进入工程模式强锁至4G网络后再设置回234G自动选择，并与另外一部VoLTE终端进行语音通信，那么此时会触发CSFB流程，而不是VoLTE语音业务。通过抓包分析，HTC终端如果在23G下，通过设置“LTEonly”强制选到LTE，那么终端向MME发送的attachrequest中不带additionalGUTI，那么MME将认为该用户前一次不是在2/3GSGSN附着的（依据中移动规范的方法）。Attachrequest消息如下图：这时候如果MME保存有该用户的信息，就不发ULR给HLR。根据诺基亚的被叫域（TAS）选择，它首先要判断融合HSS中是否有SGSNnumber，如果有，则认为该用户在23G下，就会将被叫指向23GCS域。这个方案在3GPPTS29.328有下列描述：AnnexE(informative):T-ADSrequesthandlingintheHSS,IfbothMMEandSGSNareregisteredbuttheregisteredSGSNisaGn/Gp-SGSN,theHSStreatstheMMEasnotregisteredinthefollowingT-ADSrequesthandling.对于支持LTE的双模终端，从GnGp-SGSN移动到MME下时，即使MME保留有用户数据，按照TS29.272规范要求，MME还是需要发起S6a-ULR，携带SingleRegistrationInd，以触发HSS/HLR删除用户SGSN地址。所以说正常情况下用户进入LTE覆盖时，HLR不会保留SGSN地址。当下次呼叫时MME会认为此时用户还在2/3G下，于是就会触发CSFB。而且开关机通常也无法解决（因为MME已经保存了它的用户信息）问题4：VoLTE语音AMR-NBAMR-WB资源占有情况有何区别？答：AMR全称AdaptiveMulti-Rate，自适应多速率编码，主要用于移动设备的音频，压缩比比较大，但相对其他的压缩格式质量比较差，由于多用于人声，通话。其中AMR分为AMR-NB和AMR-WB两种，对于VoLTE而言，AMR-NB则为12.2k语音编码制式，AMR-WB则为23.85k语音编码制式。AMR-NB和AMR-WB的本质区别在于其语音带宽和抽样频率有所区别，NB的语音带宽范围为：300~3400khz，抽样频率为8khz；而WB的语音带宽为50~7000khz，抽样频率为16khz。以下为相关的AMR-NB的编码方式，共分为16种，其中0~7对应不同编码方式，8~15用于噪音或者保留用，VoLTE里的AMR-NB采用的编码方案7；而AMR-WB的编码方式同样也有16种，其中0~8对应不同编码方式，9~15保留用，当前VoLTE语音的WB编码制式采用的编码方式8。以下为VoLTE相关测试中的高标清占用资源对比情况:从趋势图来看，在SINR大于5的时候，整体MOS值比较平稳，其中高清MOS值稳定在3.5以上，标清语音MOS值稳定在3.2左右，而在SINR值小于5之后，高清和标清语音的MOS值均呈现波动且整体均值下降的趋势。另外由于在SINR差点打点数较少的原因，其MOS均值会出现随着SINR均值下降而抬升的异常情况。在下行PDCP速率里对比中标清语音在7kb左右，在SINR小于0之后开始出现明显的波动情况，直至掉0。高清语音PDCP速率则在15kbps左右，同样在SINR小于0后开始出现剧烈的波动情况。从高清和标清的下行PRB数对比情况来看，整体占用的RB数差距不明显,另外下行PRB个数随着SINR值恶化逐级抬升。从高标清的指标和资源对比来看，本身AMR-NB和AMR-WB对于网络资源的利用程度来看差距不大（PRB上占用差不多），但AMR-WB对于网络资源的利用率会相对高些（高清的码率更高），且AMR-WB的用户体验更好（MOS值高于AMR-NB一截），且抗干扰性上并没有明显差别，因此在VoLTE将来部署中，更推荐采用AMR-WB编码制式。问题5：终端正确设置下仍无法进行高清语音通话的原因？答：TASLicense过期使得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-WBLICENSE没有及时打上。TAS添加license后，外场验证，高清电话可以正常拨通：问题6：手机通话中出现FASTBOOT的可能原因是什么？答：基站侧zuc算法打开后可能会导致手机通话出现FASTBOOT问题。以现网测试案例为例，用HTCM8对在目前LTE弱覆盖或信号质量差的网络环境下的通话质量进行MOS评估时，发现通话拨打8S左右通话中断，手机进入FASTBOOT工程模式。更换站点后恢复，再回到问题站点拨打电话，分析EMIL包后发现该基站ZUC加密算法开关打开，且ZUC算法优先级为最高，让后台修改为现网站点基本设置后恢复正常。更改站点后手机通话恢复正常，可以判断为站点问题。在后台检查后发现该基站并无告警，排除由硬件故障造成的通话问题。由EMIL包中ATTACHREQUEST里UECAPBILITY列出终端支持使用ZUC算法。（注意EEA3与EIA3的值都为1）为确定M8在该站下是否使用ZUC算法，通话先在其他站点建立后再切换进问题站点，从切换请求中可以看出切换后进入问题站点选择的加密算法为EEA3、EIA3，且切换完成6S后手机进入FASTBOOT模式。确定问题为ZUC算法的启用导致。（下图为切换入问题站点后选择的加密算法，基站R10以前的版本是spare5，R11后改成了eea3和eia3）通过后台关闭ZUC算法，问题解决。由于ZUC是3GPPR9才加入的算法，故R9之前的终端并不支持ZUC算法。同时R9的终端如HTCM8也并不完全支持在使用ZUC算法的前提下进行所有业务。问题7：专用承载MAXGBR值对通话质量有什么影响？答：专用承载MAXGBR太小将导致的通话质量差。以现网测试案例为例，用CDS48KMOS盒对在目前LTE网络下的通话质量进行MOS评估时，发现当通话建立在专用承载（GBR）下时CDSMOS打分值偏低。偶然间发现建立在默认承载上的通话MOS值正常可以达到4分。估计为专用承载问题，再用8K语音文件进行MOS打分又恢复正常，确定为速率问题，调整QCI1MAXGBR参数后恢复正常。VOLTE通话评估软件反映通话质量分值低，经监控基站无告警，接入指标正常，更换站点并重新导入参数后仍存在问题。曾尝试在默认承载下进行语音通话发现质量评估并无问题。初步判定为专用承载问题。如下图所示（左图为QCI1下，右图为QCI9下）。选用8K采样的语音文件再次进行MOS打分时发现QCI1下的MOS值恢复正常采样率不同的区别在于传输时速率不同定位问题点于QCI1专用承载的最高速率没有达到48K语音的传输要求。在对比查看QCI1与QCI9的MAXGBR后确定了问题原因。下图是QCI1修改前的参数（图中MAXGBR数值为换算后结果，下同）下图为QCI9的参数：核心网QCI1承载的MAXGBR改为150：修改后QCI1:由于VOLTE是VOIP业务所以速率的大小直接影响了通话的质量，速率太小语音业务就会出现卡顿和失真的现象。专用承载的最大保证比