案例-VoLTE无线参数优化案例

VoLTE无线参数优化案例

1 概述

VoLTE作为LTE网络的语音解决方案，在商用初期，VoLTE的优化仍处于摸索阶段。为打造精品网络，创建综合网络优势，确保后期VoLTE业务的顺利商用，本文通过对 E-UTRAN重要无线参数设置进行梳理，结合现网试验网的优化经验，给出了包括切换，接入，预调度，寻呼，RRC重建，上行CoMP与功控，VoLTE增强特性开启等无线参数设置建议，及某些特定场景下的优化建议，同时对相关参数进行了试验验证。

2 接入时延专题

2.1 连接态DRX（QCI 1、5）

2.1.1 概述

DRX（Discontinuous Reception）即非连续接收，是指UE 仅在必要的时间段打开接收机以接收下行数据和信令，而在其他时间段关闭接收机停止接收下行数据和信令的一种节省UE 电量的工作模式。

2.1.2 优化建议

设置建议：关闭QCI1、5的DRX功能。由于DRX功能主要用于终端节电功能，而语音业务相对LTE整体业务时长占比不大，根据CDMA语音业务模型，人均话务量在0.017Erl，建议对于QCI1、5，建议关闭DRX功能，改善接通时延与语音质量。

2.1.3 验证方案与评估

针对不同的QCI，厂家支持设置不同的DRX策略（中兴支持区分GBR与Non-GBR）。通过CQT定点进行中远点各测试40次验证开启和关闭DRX （NGBR&GBR）开关对语音质量影响。

DRX功能关闭后，对VOLTE时延及MOS均有提升。

2.2 空闲态DRX（寻呼周期）

2.2.1 概述

寻呼周期设置过大，对VOLTELTE时延影响较大。基站当前寻呼周期设置是rf128，即128个无线帧。如果终端寻呼周期刚过，SGW收到SIP Invite消息，在基站侧要等1.28S才能寻呼终端，呼叫时延最大增加1.28S，平均增加0.64S。因此可以将寻呼周期修改rf64，验证是否对呼叫建立时延有所改善。

2.2.2 优化建议

设置建议：寻呼周期修改rf64。通过参数调整前后的现场测试，修改寻呼周期后，VoLTE呼叫建立时延平均缩短0.6s左右，与理论预计相符。寻呼周期周期改小主要影响以下性能：

1.寻呼信道容量。减少寻呼周期，则可容纳的寻呼用户数相应减少，在

高负荷区域需要配合寻呼因子一起调整。

2.终端在空闲态的待机电量消耗出现增加，待机时间缩短。需要后续评

估电量消耗影响。

2.2.3 验证方案与评估

本次测试选取中点、远点两个位置测试验证，其中中点测试选择监金通_3小区，RSRP在-95dbm左右，远点测试选择测试基站丰翔_7,RSRP=-105dbm左右；测试站点位置以及测试位置如下图：

测试方法：在每个站点下分别对寻呼周期rf64和rf128进行短呼（业务时长20s）20次，业务间隔10s，记录每次呼叫建立时延。

测试数据如下

从中可以看出当寻呼周期修改为rf64后，无论中点还是远点都对VOLTE 的呼叫建立时延有较大提升。

2.3 接入参数

2.3.1 概述

无线侧接入可分为两个阶段：

一．RACH阶段／冲突解决/RRC建立完成阶段。二．Post PRACH阶段

第二阶段中上下文及默认承载QCI9和QCI5的建立，在无线部分的关注点与RRC建立相同，例如业务信道的功控、HARQ等保证成功率的因素。但总体对时延的影响非常小，就不重复叙述。而Volte的专用承载建立的过程与IMS Call的呼建控制过程(以SIP消息为时间参考点)并行。也无法单独优化以加快呼叫进程。所以这一部分，对应之前分段得T2和T3，更多涉及IMS业务的呼叫控制优化，包括IMS及EPC的部分，不是这次研究的内容。

对于接入的无线参数来说，优化的意图是加快RACH和RRC建立的过程。但是同时要考虑到不能牺牲成功率，加快接入速度和保证成功率需要统一考虑，找到好的平衡设置。

RACH阶段／冲突解决/RRC建立完成阶段。

2.3.2 优化建议

设置建议：建议按照各地对于时延需求进行调整，本次对于RRC连接时延优化参数调整方案如下：

从统计结果来看，近点和远点均有提升在随机接入阶段的时延对比调整前略有提升，大约在0.01s左右，整体对于VoLTE起呼端到端时延影响不大。

3 切换与预调度专题

3.1 切换方案评估

3.1.1 概述

切换执行过程中语音包是无法发送的，等到切换完成后语音包才会在目标小区发送。因此过多的切换会导致VoLTE业务MOS值变差，具体统计如上所示。出了通过射频优化之外，在系统配置方面，可以启用 MRO（Mobility Robustness Optimization）功能，通过网络自动对切换过早、切换过晚、切换到错误小区及乒乓切换故障进行检测和自优化，本次通过SON的MRO功能来验证对MOS的影响。

3.1.2 优化建议

设置建议：开启MRO功能。通过MRO功能开启前后DT测试数据，在MOS优良占比，RTP的丢包率以及抖动均出现小幅度改善。从网管侧统计的LTE业务数据来看，切换成功率改善明显，切换请求次数在MRO功能开启后，逐步收敛减少。

对于高铁，高架等高速特殊场景不建议开启。因为切换关于与普通用户不同，提供给MRO的数据无法区分，暂不建议开启。

3.1.3 切换与MOS关联评估

汇总网格DT测试数据，由于8s内切换次数有限，最多为4次，未见MOS 值随切换频率明显变化趋势，为进一步对语音MOS值进行分析，探究切换频率对MOS值变化影响，找出其拐点，选取切换带，改变8s内切换次数进行测试，探究MOS值变化情况，最终获取测试数据如下：

1.将87482个测试点根据MOS值采样汇总为456组MOS值数据；

2.将MOS值采样数据根据切换次数汇总为如下表格：

3.将以上表格整理成直观图像：

由上图可知：随切换频率增加，MOS均值逐渐下降，RSRP稳定在-80dBm左右，SINR值稳定在15dB左右，RTP丢包在1%左右，该测试区域基站传输正常，下行无线环境良好；当切换频率大于0.5/s时MOS均值下降幅度增大，切换频率大于0.625/s时，MOS值降到3以下。由此可见，排除其余因素的影响，MOS值随着切换频率的增加成下降趋势。

根据以上数据，无线环境好点高频率切换对MOS均值仍有较大影响，为保证良好的用户感知，建议切换频率低于0.625/s，故网格测试中避免短时间内高频率切换是必要的，且切换频率需低于0.625/s。

切换执行过程中语音包是无法发送的，等到切换完成后语音包才会在目标小区发送。因此过多的切换会导致VoLTE业务MOS值变差，具体统计如上所示。出了通过射频优化之外，在系统配置方面，可以启用 MRO（Mobility Robustness Optimization）功能，通过网络自动对切换过早、切换过晚、切换到错误小区及乒乓切换故障进行检测和自优化，本次通过SON的MRO功能来验证对MOS的影响。

MRO (Mobility Robustness Optimization，移动鲁棒性优化) 是LTE系统自优化网络（SON）的一个重要组成部分。切换参数配置不合理，会严重的影响用户感受、浪费系统资源。一般不是因为无线链路失败（RLF）导致的切换失败用户都是可以迅速恢复的，而RLF导致的移动性问题不仅会影响用户的使用感受，还会影响网络资源。因此MRO的主要目标就是要减小由于移动性参数设置不合理导致的切换相关RLF，动态的改进网络中的切换性能，从而在提高终端用户感受的同时提高网络容量。MRO主要是会根据网络性能指示反馈来动态的调整小区参数来修订切换边界。采用这样的方法可以减小网络优化和管理过程中人工的干预程度，节省人力资源。

MRO优化的总体过程大致包括4个阶段：切换故障检测和统计、切换参数优化、优化效果评估、优化参数执行或参数回退。

故障检测和统计阶段，eNodeB能够检测以下故障类型：切换过早、切换过晚、切换到错误小区以及乒乓切换。

通过调整切换相关参数，降低由于切换失败导致的无线链路失败。MRO切换参数优化是在检测到切换故障的前提下，通过步进式的调整切换相关的参数来提高切换成功率，获取更优的切换性能。当前版本支持调整的切换相关参数：邻区偏移值。

优化参数后，要对优化参数效果进行评估。评估期为提交优化参数后的下一个故障统计周期，在评估期内不进行新的参数优化。前台对参数进行优化并上报EMS后，EMS下发优化后的参数至前台，前台会启动优化评估定时器进行效果评估。

效果评估结束后，OMC向用户显示优化前后的KPI信息，如果参数优化未达到预期目标，系统执行参数回退。

3.1.4 验证方案

选择曲阳簇，在MRO开通前后分别进行DT测试，验证MRO功能开通前后MOS指标前后变化。同时跟踪5天网管性能指标开通前后变化。地理位置信息如下：

具体参数设置如下：

3.1.5

MRO开通前后，路测指标对比如下：

从路测指标的前后对比来看，开通MRO后MOS均值略微有提升，MOS大于3.5占比也有提升。每MOS采样点切换次数略有下降，RTP抖动和丢包提升比较大，切换成功率也有所提升。

从网管指标统计看，无线连接成功率、RRC连接重建比率、UE上下行掉线率，均在正常波动范围内，系统内切换成功率总体有提升。系统总体切换请求次数有所下降。

MRO开通前后，网管指标对比如下：（黄色底线标注为开启日期）

为了进一步验证MRO功能对网管指标的影响，后续（12月26日）挑选切换成功率稍差的外高桥北开启MRO功能，从功能开启前后的指标来看，MRO功能能有效的提升系统内切换成功率。切换次数有所下降。

3.2 预调度评估

传统上行调度

如果终端有上行数传，首先要在PUCCH信道上发送SR（调度请求），然后基站再给终端上行授权，最后终端根据基站上行授权指示的位置发送上行数据，整个过程为：

基站终端

上行预调度

传统的上行调度，终端的SR只能根据配置周期性发送，如下图SR周期根据协议最大可高达80ms，在最坏的情况下，终端如果有上行数据发送，需要等待80ms才能发送SR，此时会增加上行时延：

为了降低上行时延，引入了上行预调度功能，此时基站对终端进行主动授权，不需要等待终端发送SR，整个过程为：

基站终端

智能预调度(华为)

上行预调度有一个缺点：即使终端没有上行数据发送，基站也会主动给终端上行授权，这样会造成上行资源的浪费，并且引入上行干扰，为了解决这一问题，引入了智能预调度，该功能由下行业务触发：一旦基站给终端发送下行数据之后，考虑到终端有相应回复，会有上行数传，此时基站才持续在一定时间内主动给终端上行授权，整个过程为：

基站终端

3.2.1 优化建议

设置建议：同时启用预调度与智能预调度。根据现场测试结论，智能预调度可以有效改善VoLTE语音情况，同时因为该功能对于用户感知中的首包时延改善有一定效果，建议在1.8G/2.1G启用智能预调度。在L800小带宽场景下，根据上行PRB利用率情况，选择性开启。

3.2.2 验证方案

本次选取远点进行测试，测试基站选取嘉蓝天_5，RSRP=-105dbm左右；测试位置以及测试基站位置如下：分别在预调度/智能预调度都关闭，只开预调度

以及预调度/智能预调度都打开情况下，观测定点VOLTE业务MOS

以及时延的变

化

在远点时，当预调度与智能预调度都关闭时，MOS最低，时延最高，当预调度开，智能预调度关时，MOS基本无变化，时延略有改善。当预调度与智能预调度都开时，MOS值最好，时延最低，说明预调度对于改善远点用户的MOS值以及时延有正向增益。

4 寻呼优化专题

4.1 概述

寻呼问题在Volte业务中会影响到接通时延甚至接通率。拟通过对寻呼容量的分析，量化TAC规划时的寻呼容量的理论依据。同时研究无线侧参数的设置与寻呼性能，例如寻呼删除的关系，实际寻呼发送量和理论寻呼发送量的安全比例。本次考虑通过调整重选测试，验证其对于寻呼成功率影响。

4.2 优化建议

设置建议：Qhyst调整为2dB，同时提高寻呼信道功率偏置以及降低寻呼信道码率，从而提高寻呼成功率。具体设置如下：

4.3 测试方案与评估

根据TAC的寻呼成功率统计，选择TAC范围作为重选参数验证。通过修改系统内重选触发时长和小区重选迟滞两个寻呼参数，观察修改后的TAC （23073）的寻呼成功率，作为参数修改效果评估依据。调整参数如下所示：对比TAC23073修改前后相同非工作日时段的寻呼成功率指标，寻呼成功率增加了0.28%，提升效果明显；统计与TAC23073相邻的5个TAC，修改前后寻呼成功率有增有减，整体来看略有提升。

详细统计如下：

为验证华为寻呼码率、IRC算法组合效果，在华为区域选择2个TAC进行效果验证

从中可以看出无线侧参数修改后，无论忙时还是全天寻呼成功率提升0.2%-0.3%

5 RRC重建专题

5.1 概述

当处于RRC连接状态时，如果出现切换失败、无线链路失败、完整性保护失败、RRC重配置失败等情况，将会触发RRC连接重建过程。

在RRCConnectionReestablishmentRequest消息中ReestablishmentCause 为枚举类型，包括以下四个信息元素：

reconfigurationFailure,handoverFailure,other Failure,spare1。

●如果重新建立过程的发起是UE没有办法遵从重配的重配失败，设置reestablishmentCause 为‘reconfigurationFailure’；

●如果重新建立过程的发起是由于LTE内切换失败EUTRA侧不同RAT移动性失败切换失败，设置reestablishmentCause 为‘handoverFailure’；

●否则，设置 reestablishmentCause 为‘otherFailure’；

UE应将RRCConnectionReestablishmentRequest 消息提交给底层传输。

RRC重建立过程旨在重建RRC连接，包括SRB1操作的恢复，以及安全的重新激活。

处于RRC_CONNECTED状态的UE，安全已被激活，可发起该过程继续RRC连接。仅当相关小区是具有UE上下文的小区时，连接重建才会成功。假使E-

UTRAN认可重建，SRB1的操作会恢复，而其它RB将继续保持挂起。如果AS安全没有被激活，UE不会发起该过程，而直接转到RRC_IDLE状态。

站间重建立前提条件：

1）eNB间满足X2切换的限制条件，即建立有X2连接并且同MME。

2）eNB间互配邻区，对于重建立目标eNB，才可能根据重建立请求消息中携带的PCI查找到重建立源侧eNB。对于重建立源侧eNB，才可能发起X2切换过程。

3）开启站间重建立功能。

5.2 优化建议与异厂家验证情况

设置建议：开启各厂家重建增强与异厂家重建功能。本次根据现场测试与后台信令跟踪完成以下厂家组合验证。

5.3 验证情况

5.3.1 中兴-华为RRC重建

中兴与华为侧站点均开启三方重建立功能。通过邻区临时添加黑名单方式进行验证。

测试情况：从中兴eNodeB ID 376263 、cell ID 3，PCI为398【地铁4号线海伦路站1(6-0.1.2)(1.8G-2.1G)(室分)-3】小区移动到华为eNodeB ID 379154、cell ID 4，PCI为349小区，由于不能切换，无线环境恶化后，出现重建立信令流程，并且RRC重建立成功，业务未中断。

在12:09:56.351发起重建立请求，12:09:56.425重建立完成。UE由占用376263-3信号变为占用379154-4信号。

具体信令如下：

信令具体信息如下：

5.3.2 中兴-诺基亚RRC重建

测试情况：从中兴eNodeB ID 376263 、cell ID 51，PCI为419小区移动到诺基亚eNodeB ID 384519、cell ID 6，PCI为206小区，由于不能切换，无线环境恶化后，出现重建立信令流程，并且RRC重建立成功，业务未中断。

UE由占用376263-51（419）信号变为占用384519-6（206）信号。

具体信令如下：

5.3.3 诺基亚-华为RRC重建

现场测试验证

图1图2

当UE在PCI139小区（中春-56小区）发生Radio Link Failure（图1）, 此时UE未收到HO command, UE掉线后重选至PCI10小区（青诸南-49），发起

RRC重建的请求。青诸南-49小区收到请求后，会通过X2接口向UE的原所在小

区中春-56小区（在RRCConnectionReestablishmentRequest中包含中春-56小

区小区的PCI信息，即PCI139（图2），然后UE在青诸南-49小区重建。

6 上行CoMP与功控专题

6.1 概述

对于上行来说，通过多个协作小区对同一用户信号进行联合接收处理，我们称之为基于联合接收（JR，Joint Reception）的UL CoMP，获取分集处理增

益和功率增益，提高接收信号信噪比，增强基站的解调能力。在相同时频资源