VoLTE优化实战手册簿.docx

VoLTE优化实战手册簿.docx

《VoLTE优化实战手册簿.docx》由会员分享，可在线阅读，更多相关《VoLTE优化实战手册簿.docx（55页珍藏版）》请在冰点文库上搜索。

VoLTE优化实战手册簿

VoLTE优化实战手册

1参数与定时器配置（建议）

1.1VoLTE互操作类参数

1.2VoLTE功能类参数

1.3定时器参数

1.3.1接入类定时器

参数英文名：

T300

功能描述：

该参数表示UE侧控制RRCconnectionestablishment过程的定时器。

在UE发送RRCConnectionRequest后启动。

在超时前如果：

1.UE收到RRCConnectionSetup或RRCConnectionReject；2.触发Cell-reselection过程；3.NAS层终止RRCconnectionestablishment过程。

则定时器停止。

如定时器超时，则UE重置MAC层、释放MAC层配置、重置所有已建立RBs（RadioBears）的RLC实体。

并通知NAS层RRCconnectionestablishment失败

对网络质量的影响：

增加该参数的取值，可以提高UE的RRCconnectionestablishment过程中随机接入的成功率。

但是，当UE选择的小区信道质量较差或负载较大时，可能增加UE的无谓随机接入尝试次数。

减少该参数的取值，当UE选择的小区信道质量较差或负载较大时，可能减少UE的无谓随机接入尝试次数。

但是，可能降低UE的RRCconnectionestablishment过程中随机接入的成功率

1.3.2切换类定时器

参数英文名：

T304ForIntra-Lte

功能描述：

在“E-UTRAN内切换”和“切换入E-UTRAN的系统间切换”的情况下，UE在收到带有“mobilityControlInfo”的RRC连接重配置消息时启动定时器，在完成新小区的随机接入后停止定时器；定时器超时后UE需恢复原小区配置并发起RRC重建请求

对网络质量的影响：

用于系统内切换，该值设置过大会导致切换失败无法及时回退并发起RRC连接重建过程

1.3.3重建类定时器

1）参数英文名：

T311

功能描述：

T311用于UE的RRC连接重建过程，T311控制UE开始RRC连接重建到UE选择一个小区过程所需的时间，期间UE执行cell-selection过程。

对网络质量的影响：

设置值越大，UE进行小区选择过程中所被允许的时间越长，RRCConnectionReestablishment过程越滞后；如果该参数设置过小，可能在某些链路可以被挽救的情况下，却由于定时器设置不合理而进入IDLE状态，引起掉话，严重影响用户感知。

2）参数英文名：

T301

功能描述：

在UE上传RRCConnectionReestabilshmentRequest后启动。

在超时前如果收到UE收到RRCConnectionReestablishment或RRCConnectionReestablishmentReject，则定时器停止。

定时器超时，则UE变为RRC_IDLE状态

对网络质量的影响：

增加该参数的取值，可以提高UE的RRCconnectionre-establishment过程中随机接入的成功率。

但是，当UE选择的小区信道质量较差或负载较大时，可能增加UE的无谓随机接入尝试次数。

减少该参数的取值，当UE选择的小区信道质量较差或负载较大时，可能减少UE的无谓随机接入尝试次数。

但是，可能降低UE的RRCconnectionre-establishment过程中随机接入的成功率

1.4互操作邻区配置

VoLTE商用后，由于语音业务需求或由于4G覆盖原因，终端需要通过SRVCC方式互操作至2G系统。

因此，制定4G至2G邻区配置方法如下：

可先继承CSFB邻区配置原则。

具体如下：

4G至2G邻区配置原则（用于VoLTE业务）

1）如果4G与2G小区共站，4G首先需要配置所有共站的2G小区;同时需要继承配置其中同方向角的2G共站小区（系统实现时可考虑一定的角度放宽,暂定60度内）的2G邻区。

2）如果4G仅与3G小区共站，4G需要配置所有3G共站小区的2G邻区。

3）如果4G站点为新建站，优先添加第一圈2G邻区。

应重点检查以下两类2G小区：

●距离4G站点最近的N个2G站址中,如果存在室外小区,则选择天线方向指向本小区的2G小区（建议是法线正负60°之内）；如果存在室分小区，则无需考虑方向角，上述室内、外小区共M个（N建议小于9个；建议距离在2km范围内）

●4G小区天线法向方向正面对打小区且两小区天线相对方向角度在60°之内最近的2个候选邻区（该邻区距本小区不超过1000m），如该2小区被包含于前述M个小区，则需配邻区个数为M，否则为M+2个。

4）如果4G与2G共室分，4G需要配置该2G室分小区，及该2G室分小区的邻区。

2终端IMS注册问题

2.1终端开机的IMS注册过程

用户开机以后，首先完成EPC附着过程，建立QCI=9默认承载，附着完成以后，发起IMS注册过程和鉴权。

在IMS注册流程中，先建立QCI=5的SIP信令承载。

然后进行SIP的注册过程，当完成注册过程以后，就可以进行VoLTE呼叫了。

若未建立QCI5就无法完成终端与IMS的SIP注册信令的交互；若QCI5建立成功后，终端与IMS的SIP注册流程异常，也将会导致不能在IMS成功注册。

SIP信令注册

SIP信令注册过程如下图所示。

（点击放大浏览）

以下为QCI5承载建立信令流程：

SIP信令注册失败原因

手机附着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请求拒绝大部分是核心网问题，可以通过抓取信令分析

SIP注册

SIP注册过程：

1）用户首次试呼时，终端向代理服务器发送REGISTER注册请求

2）IMS认证/计费中心获知用户信息不在数据库中，向终端回401Unauthorized质询信息，其中包含安全认证所需的令牌

3）终端将用户标识和密码根据安全认证令牌加密后，再次用REGISTER消息报告给IMS服务器

4）IMS服务器将REGISTER消息中的用户信息解密，认证合法后，将该用户信息登记到数据库中，并向终端返回响应消息200OK。

5）用户订阅注册事件包，

6）服务器应答订阅成功。

7）IMS服务器发送notify消息，由于订阅的用户已经注册，所以IMS服务器回应Notify消息中，状态为active，同事携带XML信息。

8）终端发送Notify200表示接收成功。

QCI5承载建立成功后，此时终端可以与IMS进行SIP信令交互，完成IMS的注册，若注册流程异常，可以从以下方面展开排查：

1.需要确认终端是否发出RegisterSIP信令；

2.若终端已发，确认IMS是否收到；

3.IMS收到后，是否回相应的SIP信令，还是响应注册失败；

4.是否由于终端未开启IPsec导致IMS拒绝注册请求。

一般情况下，终端IMS注册失败问题都与核心网相关，主要在于核心网侧排查解决。

3关键参数设置问题

3.1VoLTE语音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编码制式。

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

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

3.3.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值。

3.4QCI=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.5HSS参数设置是否会对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卡后，问题消失。

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

答：

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

LTE<-110dBm，B2判决门限为：

LTE<-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%以上。

3.7RoHC是否应该启用？

答：

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。

3.8VOLTE下的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的时延不能超过100ms，所以DRXcycle不能设置得过长，不能使用原先QCI=9的longDRX-cycle设置（160ms），又由于UE在进行语音业务时，用户正在通话时会每20ms产生一个采样包，宜为设置longDRX-cycle为40ms，为20ms的整数倍。

同时，由于语音业务都是20ms产生一个采样包进行下发，用户在接受到语音数据包后并不需要连续监听，且由于longdrxcycle更变，DRXinactivityTimer也不宜设置过大（原QCI=9该参数为60/200（psf）），宜为设置为4（psf），以达到节电功能。

故VOLTE推荐的DRXPRO