VoLTE维护优化丛书Word格式文档下载.docx

VoLTE维护优化丛书Word格式文档下载.docx

《VoLTE维护优化丛书Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《VoLTE维护优化丛书Word格式文档下载.docx（37页珍藏版）》请在冰点文库上搜索。

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.org

BSF：

bsf.mnc002.mcc460.pub.3gppnetwork.org

UtapplicationID：

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业务所以速率的大小直接影响了通话的质量，速率太小语音业务就会出现卡顿和失真的现象。

专用承载的最大保证比特率应该先由在不受限条件下的业务最高速率来确定。

问题8：

QCI=1开关不打开或打开但maxGBR配置过低对Volte电话的影响？

当拨打volte电话时，QCI=1开关未打开，没有建立QCI=1的专用承载，电话拨通5S后会自动挂断如图所示：

所以判断必须打开QCI=1的专用承载开关，才能正常拨打电话。

在后台配合下，开启QCI=1的专用承载，并配置maxGBR=20k。

再次拨打volte电话，发现专用承载仍未建立，volte电话依然是5s挂断，如下图所示：

推断无法正常拨打电话的原因是maxGBR=20k不满足核心网配置要求，经确认，核心网要求的minGBR值必须大于40，于是将基站侧maxGBR值改为256；

再次拨打volte电话，专用承载建立成功。

能正常通话；

如图所示：

所以为了保证Volte语音电话能正常拨打，需打开QCI=1的开关，切配置大于核心网要求的maxGBR值。

问题9：

QCI=2下maxGBR配置过小对视频电话有什么影响？

基站侧打开QCI=1及QCI=2的开关，并将qciTab2maxGbrDl及qciTab2maxGbrul均设置为100k，拨打Volte视频电话,QCI=1专载成功建立，但QCI=2的专用承载未建立，视频电话呼叫失败。

怀疑为qciTab2maxGbr配置过低，未能达到视频电话保障最低要求，经查证，核心网要求的maxGBR值需大于512k，通过后台修改qciTab2maxGbr值为2048之后，再进行Volte视频电话拨打，能正常进行视频通话，如图所示：

所以Volte视频电话，需同时打开QCI=1.QCI=2的开关，且maxGBR值需配置大于核心网要求的值方可正常通话。

第3章VoLTE关键功能优化篇

问题10：

终端注册异地MME对eSRVCC会产生什么影响？

手机注册异地MME可能导致不能完成sSRVCC切换。

以福州某测试场景为例，下表为eNB参数配置。

在无线环境满足切换条件情况下，ms只上报测量报告，未发生切换。

MS只上报测量，未发生切换问题，查看基站无相关告警，检查邻区无漏配，参数配置一致情况下，未切换问题还是存在。

后续测试中,通过抓取核心网，eNB侧log分析,核心网侧查看eNB未发送handovercommand，通过多方面分析后，发现MS注册的MMEcode归属地属于厦门,MS注册到厦门MME不能切换原因可能是相应参数未配置完整。

eNB侧删除厦门MME后，测试中切换问题解决。

问题11：

HSS参数设置是否会对eSRVCC产生影响？

HSS参数设置不恰当可能会导致无法执行eSRVCC。

正常的eSRVCC流程如下：

以现网测试发现的某个案例为例，无线环境满足切换条件，UE却并没有执行切换，直至SINR过差发生掉话。

通过分析log发现，UE未触发eSRVCC原因为，eNB没有下发eSRVCC相关测控消息。

更换HTC测试终端发现，SIM卡尾号为19的终端可收到eNB下发的测控消息并正常eSRVCC，而SIM卡尾号为55的终端无法收到eSRVCC测控消息，以此排除终端原因。

正常重配置信令中eSRVCC测控消息如下，SIM卡尾号为55的终端无以下消息。

GSM频点信息

A2事件及B2事件：

对比19、55两部终端能力信息，发现eNB收到的UECapabilityInformation信令完全相同，且FGI第9位、第23位设置为1，表示终端支持eSRVCC（根据3GPP36331B.1Featuregroupindicators规定，比特位9为EUTRARRC_CONNECTEDtoGERANGSM_Dedicatedhandover，比特位23为GERANmeasurements,reportingandmeasurementreportingeventB2inE-UTRAconnectedmode，设置为1表示支持该功能）。

对比EMILlog发现，SIM卡尾号为19的终端附着时，eNB收到MME下发的InitialContextSetupRequest中存在SRVCCOperationPossible:

possible字段，而SIM卡尾号为55的终端确没有该字段，导致eNB认为UE不支持eSRVCC，因此不下发eSRVCC测控消息。

在附着流程中，测控消息下发前，UE会通过上发NAS：

AttachRequest进行信息的交互，其中包含UE能力的相关信息。

对比两部终端上发的AttachRequest信令，结果发现，AttachRequest中除随机个性化参数不同外，其他参数完全相同，且MSNETWORKCAPABILITY（OPTIONAL）中SRVCCtoGERAN/UTRANcapability字段设置为1，表示UE支持eSRVCC。

由上可知，UE无论是与eNB还是与MME交互过程中，不存在终端能力上报的差异，判断应该不是终端的问题，怀疑是否为SIM卡本身的问题。

对调两部终端SIM卡发现，问题会伴随尾号为55的SIM卡，与终端无关。

联系HSS工程师核查SIM卡参数，发现尾号为55的SIM卡SessionTransferNumber参数为空，此字段为eSRVCC切换时核心网的一个标识的初始值。

若字段为空，则表示不支持eSRVCC。

重新设置尾号为55的SIM卡后，问题消失。

问题12：

地下车库-115场景eSRVCC优化参数如何设置？

地下车库-115场景下，参数采用初始配置1，A2判决门限为：

LTE<

-110dBm，B2判决门限为：

-120dBm，GSM>

-85dBm。

UE进入地下车库，当LTE信号低于-120dBm时触发B2事件，但在1秒内RSRP由-120dBm降低至-139dBm以下，SINR由-2dB降低至-14.7dB以下，无法完成eSRVCC流程，导致信号恶化掉话。

UE触发B2时信号截图如下：

UE掉话时信号截图：

调整B2判决门限，将B2LTE门限由-120改为-116，发现成功率有大幅度提升，成功率大于70%。

分析log发现，该场景UE会占用PCI=33、34两个小区，当占用PCI=34的小区时，与邻区PCI=115的小区MOD3冲突，SINR差导致无法及时完成eSRVCC切换。

邻区列表如下：

将三个小区PCI由34/33/35调整为33/35/34，eSRVCC切换成功率达90%以上。

问题13：

RoHC是否应该启用？

RoHC通过压缩IP包头的方式，在VoLTE用户较多时，提高了空口传输效率。

1）RoHC技术

仅对QCI=1的业务有效

包头压缩支持IPv4和IPv6格式

支持以下格式的压缩（3GPPR8）:

●0x0000ROHCuncompressed（RFC4995）

●0x0001ROHCRTP（RFC3095,RFC4815）

●0x0002ROHCUDP（RFC3095,RFC4815）

以上格式需要具备VoLTE能力的终端支持

2）RoHC的实现

高标清理论速率计算

RoHC理论速率计算

3）RoHC外场验证测试

由以上分析可看出，标清AMR压缩比为51.39%，高清AMR压缩比为65.35%，建议全网开启RoCH。

问题14：

VOLTE下的DRX模式与普通LTE下的DRX模式有何不同？

DRX分两种，一种是IDLEDRX，就是当UE处于IDLE状态下的非连续性接收，由于处于IDLE状态时，已经没有RRC连接以及用户的专有资源，因此这个主要是监听呼叫信道与广播信道，只要定义好固定的周期，就可以达到非连续接收的目的。

但是UE要监听用户数据信道，则必须从IDLE状态先进入连接状态。

而另一种就是ACTIVEDRX，也就是UE处在RRC-CONNECTED状态下的DRX，可以优化系统资源配置，更重要的是可以节约手机功率，而不需要通过让手机进入到RRC_IDLE模式来达到这个目的，例如一些非实时应用，像web浏览，即时通信等，总是存在一段时间，手机不需要不停的监听下行数据以及相关处理，那么DRX就可以应用到这样的情况。

ACTIVEDRX的基本机制是为处于RRC_CONNECTED态的UE配置一个DRXcycle。

DRXcycle由“OnDuration”和“OpportunityforDRX”组成：

在“OnDuration”的时间内，UE监听并接收PDCCH（激活期）；

在“OpportunityforDRX”时间内，UE不接收下行信道的数据以节省功耗（休眠期）。

在大多数情况下，当一个UE在某个子帧被调度并接收或发送数据后，很可能在接下来的几个子帧内继续被调度，如果要等到下一个DRXcycle再来接收或发送这些数据将会带来额外的延迟。

为了降低这类延迟，UE在被调度后，会持续位于激活期，即会在配置的激活期内持续监听PDCCH。

其实现方法是：

每当UE被调度时，就会启动一个定时器drx-InactivityTimer，在该时间内不会释放连接。

drx-InactivityTimer指定了当UE成功解码一个指示初传的UL或DL用户数据的PDCCH后，持续位于激活态的连续子帧数。

为了允许UE在HARQRTT期间内休眠，每个DLHARQprocess定义了一个“HARQRTT（RoundTripTime）timer”。

当某个下行HARQprocess的TB解码失败时，UE可以假定至少在“HARQRTT”子帧后才会有重传，因此当HARQRTTtimer正在运行时，UE没必要监听PDCCH。

当HARQRTTtimer超时，且对应HARQprocess接收到的数据没有被成功解码时，UE会为该HARQprocess启动一个drx-RetransmissionTimer。

当该timer运行时，UE会监听用于HARQ重传的PDCCH。

drx-RetransmissionTimer的长度与eNodeB调度器的灵活度要求相关。

如果是要达到最优的电池消耗，就要求eNodeB在HARQRTTtimer超时之后，立即调度HARQ重传，这就也要求eNodeB为此预留无线资源，此时drx-RetransmissionTimer也就可以配得短些。

drx-RetransmissionTimer指定了从UE期待收到DL重传的子帧（HARQRTT之后）开始，连续监听PDCCH的最大子帧数。

诺基亚LTE设备中允许ENodeB对不同的QCI业务设置不同的DRXPROFILE参数集，每一个参数集会包括longDRX-Cycle（ms）、OnDurationTimer（psf）、DRXInactivityTimer（psf）、DRXRetransTimer（psf）4个参数。

UE在进行不同的QCI业务时会执行最高优先级的业务的DRXPROFILE。

而在VOLTE的业务下，QCI=1的