VoNR语音优化实战：DRX与智能预调度参数配置详解

简介：VoNR（新空口语音）场景下的DRX（非连续接收）与智能预调度参数配置规范，面向5G网络优化工程师，主要解决VoNR用户终端功耗与网络性能的平衡问题。文中汇总语音带宽部分切换、关闭第二带宽部分触发门限等关键参数，并给出典型参数组配置：长非连续接收周期设置为40毫秒，各频段持续时间定时器（2.6G为10毫秒、700M为4毫秒）、不活动定时器（2.6G为10毫秒、700M为5毫秒）及重传定时器（8或16个时隙）等。同时以网管命令形式展示开启和关闭非连续接收、将业务等级标识1和2绑定到同一参数组的具体操作，并详解生效规则：用户任一承载的参数组编号为255则功能不生效；若全部配置有效，则优先按业务等级标识1专载的参数组执行，否则选择承载中优先级最高者。文档还附带黑名单配置示例，用于规避特定终端非连续接收异常，并涉及智能预调度开关调整原则。资源为1个pptx文件，大小约1.46MB，已有335人学习，适合需要落地华为设备VoNR非连续接收参数配置的网优及研发人员参考。

1. VoNR DRX和智能预调度，为什么值得为一个PPTX较真

如果你调过VoNR语音质量，大概率遇到过这种局面：手机功耗指标难看得要命，但把DRX周期一拉长，MOS分又往下掉；把上行调度改成最保守的每次等BSR再发，时延又冒上来。VoNR DRX和智能预调度开启参数规范说明V1.5这个标题，说的就是怎么同时把这两套机制拧到同一根轴上——DRX负责让UE在语音间歇期睡过去，智能预调度负责在UE醒来之前把上行资源准备好，让语音包不用排队等调度。这个文档不是给人“了解”的，是给人照着配参数的：周期设多少、唤醒窗口开几个毫秒、偏移怎么对齐、预调度MCS上限卡在哪一档。如果你正在做语音参数规划、功耗专题优化，或者被VoNR语音质量投诉搞得焦头烂额，这篇笔记会把这套参数背后的账算清楚。

2. 理解DRX在VoNR里的行为：从睡眠周期到RTP时延的账

2.1 先分清DRX周期和语音帧周期这两条时间线

DRX的基础概念很直白：UE不需要一直监听PDCCH，基站和UE约定好什么时间醒来、醒多久，其余时间射频前端可以歇着。但VoNR里真正麻烦的是，系统里有两条独立的时间线在跑。一条是DRX的周期，长周期常见40ms到160ms，短周期可以到20ms甚至16ms；另一条是语音RTP包的节奏，AMR-NB和AMR-WB的典型话音帧是20ms一个包，静默期会切换到SID帧，大约160ms一个。

这两条时间线如果不对齐，就会出问题。比如你配了64ms的DRX周期而RTP还是20ms一拍，语音包落点会在DRX周期里慢慢滑动，每隔几个周期就会有一个RTP包落在睡眠区，UE没醒着就收不到下行数据，下行丢包或时延抖动就会起来。所以语音场景下配DRX，第一件事不是选周期长短，而是确认周期和语音帧节奏能不能稳定对齐。我一般会先看现网帧结构，确认时隙配比是2.5ms单周期还是5ms双周期，再反推DRX周期能不能整除语音帧间隔。

另一个容易被带偏的点是onDurationTimer。它决定UE每次醒来持续监听多久，单位通常是毫秒级，常见取值范围1ms到10ms。有人觉得语音对时延敏感，就把onDuration拉到10ms，让UE多醒一会儿，结果功耗反而上去了，语音质量并没有收益。原因是一个20ms的RTP话音包实际有效载荷很小，一个slot就能传完，真正需要的是“在正确的时间醒来”，而不是“醒很久”。这也是为什么VoNR语音场景里，onDuration典型配置只在4ms到6ms，甚至更短。

2.2 语音场景为什么不适合把onDuration拉长

VoNR语音包有两个特点：包小、周期固定。小到什么程度？AMR-WB 12.65kbps的编码速率下，一个20ms话音帧折算到MAC层也就三十多个字节，一个普通时隙完全够传。固定到什么程度？除非发生丢包重传，否则RTP包就是稳定按20ms往外出。

这两个特点决定了DRX参数不能照搬enhanced Mobile Broadband的思路。eMBB场景拉长唤醒窗口，能蹭到更多调度机会去抢吞吐量；语音场景拉长唤醒窗口，绝大多数时间是UE醒着但PDCCH上根本没它的调度信息，白白耗电。而且inactivityTimer这个参数在语音场景也要压得很低。它是说UE收到一个调度后继续醒多久，默认值给大了，一个TCP ACK或者测量报告就能把UE多留出好几毫秒。VoNR里的建议做法是inactivityTimer配到1ms到4ms，让它只覆盖HARQ反馈和可能马上到来的重传。

这里还要注意HARQ RTT Timer和重传定时器。语音业务对时延极敏感，HARQ重传大概率走的是快速重传路径，如果重传定时器设得和DRX睡眠期重叠，一次首传失败可能要多等一个DRX周期才能收到重传，语音MOS会直接感知到。所以语音场景下我习惯把HARQ RTT Timer配成保守值，宁可在激活期内留出重传窗口，也不让重传滚到睡眠期里。

2.3 VoNR语音推荐DRX参数范围

下面这组参数范围是从多个商用语音优化项目里沉淀出来的，逻辑是“周期对齐语音帧、唤醒窗口压缩、非激活快速关断”。不同厂商网管参数名有差异，但对应的语义基本都能对上。

这组参数的总体目标是：UE每个语音周期只醒一次，每次醒5ms左右，干完活立刻睡。这样DRX激活占比通常能压到30%以下，而RTP单向时延仍然能维持在30ms以内，MOS不受明显影响。

2.4 参数生效后的观察点：DRX激活比例和RTP丢包

参数下发之后别急着看MOS，MOS是综合结果，一出问题你分不清是传输抖动、编解码还是无线侧引起的。我会优先看两个更底层的指标：DRX激活时间占比和RTP丢包率。

DRX激活占比可以从UE上报的统计数据里取，也可以看基站侧统计的激活期PDCCH监听次数。如果配置合理，语音业务下激活占比应该在20%到35%之间。如果这个数字超过50%，说明onDuration或者inactivityTimer给大了，UE名义上在省电，实际射频一直在工作。另一个指标是RTP丢包率和抖动，这个在核心网侧或者基站侧的语音质量统计里能看到。配置完DRX后如果抖动突然从5ms涨到15ms以上，大概率是周期偏移没算对，RTP包开始周期性滑出激活窗口。

3. 智能预调度：让基站提前把资源摆上桌

3.1 先看没有预调度的上行语音要等多久

上行语音包想发出去，在标准动态调度流程里要经过一个完整的“举手—批准—发送”流程。UE先有了数据，然后在SR资源上发调度请求，基站收到SR后分配UL grant，UE拿到授权才能在上行共享信道上发数据。这个流程如果SR周期是20ms，UE恰好刚错过一个SR时机，那光等SR就要小20ms，再加基站处理时延、发送时延、HARQ反馈，一个语音包从MAC层产生到发出去，最坏能到40ms以上。

40ms是什么概念？语音端到端时延预算通常按150ms来规划，你一算，半条预算全没了。而且这个时延是波动的，SR等待时间取决于语音包到达时刻和SR资源位置的相位关系，这种抖动直接影响语音质量的主观感受。VoNR里语音质量差，很多时候不是覆盖问题，而是上行调度时延不可控。

3.2 智能预调度的核心：预测下一个语音包

智能预调度和普通预调度的区别就在“智能”两个字上。普通预调度听着很激进，就是基站每个TTI都给某些UE发UL grant，不管UE有没有数据，优点是UE永远不用等SR，缺点是一堆空授权占着PDCCH和PUSCH资源，小区用户一多就扛不住。

智能预调度不会这么蛮干。它会根据UE的历史调度情况，学习这个UE的业务节奏。具体到VoNR语音，基站观察到这个承载过去N个语音包间隔稳定在20ms，就能预测下一个包大概什么时候到，提前一点点时间发出UL grant，同时开始跟踪UE的BSR反馈。如果UE填充BSR为零或者只发了padding，下一次预测窗口就自动收窄；如果BSR有数据，就保持当前的提前量。这样循环下来，预调度授权不再是每个TTI都发，而是在预测窗口内发，PDCCH开销被压住，上行时延还能稳定在很低的水平。

这个预测机制对静默期也很重要。通话不是每一个20ms都有话音帧，中间会穿插静默期和SID帧。智能预调度如果能把静默期识别出来，会自动进入低频探测模式，不会傻乎乎地继续每20ms发一个空授权。这个能力是普通预调度给不了的。

3.3 智能预调度需要拧的四个参数

不同厂商对预调度参数的封装方式不一样，但落地配置时基本绕不开下面这四个维度：

这里重点说一说MCS上限。预调度时UE并没有实际数据在缓冲区，基站是按预测盲发的授权，所以它不知道这个包里到底有多少数据、信道质量到底怎么样。如果MCS放得很高，授权给得很大，UE拿到授权后有可能真按这个高MCS发数据，但事实上它站点的上行信道质量根本撑不住这个阶数，一来一回反而把误块率打上去。语音场景根本不需要高MCS去冲吞吐量，把上限卡在保守档，换来的是更低的盲检错误概率和更稳定的上行发射功率。

3.4 配置命令示意

下面给一个非特定厂商的配置示意，目的是把参数之间的逻辑关系说清楚。实际在网管界面上，参数名和值域会跟你手上这套不一样，但配置顺序和核对思路是通用的。

// 智能预调度参数配置示意（需按现网网管实际参数名调整） // 第一步：打开智能预调度开关，上行独立控制 MOD PRESCHED: SWITCH=ON, DIRECTION=UL_INDEPENDENT; // 第二步：限制预调度授权质量 MOD PRESCHED_CTRL: MAX_MCS=13, MAX_RB=16, SCHED_WINDOW=15;

第一个命令是总开关，这里我习惯把DIRECTION设成上行独立，因为VoNR语音质量主要卡在上行调度时延。下行语音包是基站自己调的，本来就能主动在正确的时隙发出去，下行预调度更多是提前占资源位，收益没有上行明显。第二个命令是预调度质量控制，MAX_MCS建议取保守档，原因是预调度授权是基于预测而非真实BSR，信道质量估计是“猜”的，猜的时候就要给UE留余量。MAX_RB给10到20个RB，够一个AMR-WB话音帧用，又不会因为多占资源引发自己和邻区的干扰抬升。SCHED_WINDOW是预测窗口，我一般从15ms起步，如果丢包率仍然高，再往下调，但低于10ms就基本没意义了。

4. 两套参数放在一起：DRX和预调度不是二选一，而是合谋省电和保质量

4.1 一起开的前提：预调度时机要落在DRX激活期里

DRX和智能预调度单看都不难，放在一起就容易打架。DRX的逻辑是让UE少醒来，智能预调度的逻辑是让UE随时准备接授权并上报数据，一个往“多睡”走，一个往“别睡”走。

能不能一起开，取决于预调度授权在什么时间发出。如果基站算准了UE的DRX激活期，把UL grant放在激活期里发，UE醒着就能收到授权，然后立刻用这份授权发数据，整个过程在onDuration打开的那几毫秒内完成。这样DRX该睡还是睡，预调度把“睡眠周期内的数据搬运”提前做完，两个机制各干各的。反过来，如果预调度授权落在DRX睡眠区，UE根本没在监听PDCCH，授权发了也是白发，PDCCH开销一分没少，UE一个也没收到，上行数据还得等下一个激活期才能被调度。

所以配置顺序有讲究。先定DRX周期和周期偏移，算出UE的激活期窗口；再根据这个窗口位置去配置预调度的预测窗口，让预调度授权时间戳落在激活期附近。一句话总结：DRX定“什么时候醒”，预调度定“醒了之后第一件事干完”。

4.2 两套参数组合推荐

实际落地时我一般把组合分成三档，按用户感知和功耗诉求选：

质量优先档我特别说明一下。短周期20ms确实能把调度等待压到最低，但代价是UE醒来的次数变多，PDCCH盲检功耗上升。它真正适合的是高铁这类切换频繁、时延抖动容忍度低的场景，普通城区用这档有点奢侈。均衡档的40ms周期和20ms语音帧正好是两倍关系，对齐做起来最顺手，是我在拿不准用户群体时的默认选择。

4.3 配置后的回滚和版本管理笔记

参数优化最怕的是改完回不去。我见过不止一次，网优同事改完DRX参数觉得不对想回退，结果不记得原来的值是什么，只能翻聊天记录里的一张截图。V1.5这类规范文档在网优场景里承担的角色之一，就是当参数基线记录本。我的习惯是每次批量修改前，先把当前生效配置整体导出一份存到本地，再在规范文档里更新对应小区的参数变更记录。改完参数不是马上收工，而是要在一个观察周期后回读参数，确认界面上的值和下发的值一致。

还有一个容易忽略的坑：参数规范文档迭代到V1.5，意味着中间至少改过一轮参数取值。拿到这份规范先看变更记录，搞清楚V1.4到V1.5动了哪些参数的默认值，再决定现网要不要跟着调整。如果直接拿新文档往旧版本网管上套，可能遇到值域不兼容，参数被静默截断，表面上配置成功，实际生效值和文档写的根本不是一回事。

5. 避坑：VoNR DRX和预调度参数配置的5个常见问题

5.1 现象：开了DRX之后MOS不升反降

这是最经典也最打击人的问题。明明开了省电功能，功耗也降了，语音MOS掉得比原来还厉害，用户投诉反而增多。

排查后发现原因几乎是一致的：DRX周期和语音帧边界没对齐。比如周期配了64ms，下行RTP包是20ms一个，UE醒来的时间窗口和语音包到达时间对不上，每个周期会有一两个语音包落到睡眠区。语音包在基站侧缓存里多等了一阵子，等到UE醒来才发下来，这个等待时间直接变成抖动和时延，被用户听成“一顿一顿的”。

解决方法是先把帧结构搞清楚。如果是5ms双周期时隙配置，那么DRX周期必须是5的整数倍，同时还要是20ms语音帧节奏的整数倍，40ms、80ms、160ms都属于安全选项。配好周期之后，周期偏移要根据语音包的到达时间反推，让激活期起点落在RTP包到达之前一点。改完这个偏移量，MOS基本就回来了。

5.2 现象：智能预调度开了，小区整体吞吐量掉下来

预调度本意是给语音用户开绿灯，结果配置完以后，周围的数据用户的体验速率掉了一截，小区平均吞吐量也难看。

原因是预调度的资源上限没设限。语音包一般就三四十个字节，如果预调度给UE分配几十个RB、还搭配高阶MCS，UE用不掉那么多资源，这些被占用的RB就白白浪费了。更麻烦的是，空授权产生大量的PDCCH下行控制信令，占用了公共控制资源，其他用户连调度机会都少了。

这个问题的解法就是前面参数表里说的：把MAX_MCS卡到13到15，把MAX_RB限制在10到20个。你会发现语音体验一点不受影响，小区整体吞吐量反倒恢复正常。语音用户不需要豪宅，给个标准间就够住了。

5.3 现象：短周期DRX加预调度，手机耗电反而更厉害

有的优化策略把DRX短周期设到20ms，同时预调度激进一点，理论上时延可以压得很低。结果终端功耗飙升，用户的电池健康度下降。

原因在于短周期让UE醒来的频率翻倍，每次醒来都要做PDCCH盲检。如果预调度又频繁发授权，UE醒来后还得处理这些授权、做信道测量、可能还要发padding，射频工作时间不降反升。DRX的意义在于让射频真正睡过去，而不是名义上周期短开机次数多。

解决方法是不要为了省电盲目上短周期。城区普通场景优先用40ms长周期，确认语音质量确实有问题再考虑降短周期。同时预调度的窗口要收紧，避免UE明明没有上行数据，还频繁收到授权被迫开工。

5.4 现象：智能预调度与上行功控打架，发射功率震荡

开智能预调度之后观察上行指标，发现UE的PUSCH发射功率出现周期性波动，基站侧的上行信噪比也跟着抖。

原因比较隐蔽。上行功控是跟着基站下发的TPC命令走的，TPC命令通常是根据上次传输的质量来调整当前发射功率。而预调度授权是提前盲发的，UE在预调度资源上发数据时，基站侧功控环路的反馈电路还没来得及对上一次传输完成评估，新一轮功率调整已经开始。两个环路的节奏错位，就会形成功率震荡。

解决方法是在预调度参数的功控策略上选择保守模式，或者让预调度授权的MCS和RB数与功控初始值匹配，不要让UE在低MCS授权下用高功率去发。如果产品支持预调度功控独立参数，把预调度场景的初始功率目标值比正常调度压低1到2dB，震荡会明显收敛。

5.5 现象：参数版本升级后，配置“假成功”

Replace操作提示成功，回读出来的参数值却和设定值不一样，有的参数干脆没生效，但网管上显示的是正常状态。

这种情况多出现在规范文档版本和网管版本不一致的时候。V1.5里某个参数的值域可能已经调整过，比如onDurationTimer粒度从1ms变成0.5ms，或者MCS上限值域从原来的全量变成分段枚举，旧配置超界以后被网管静默截断，界面不报错，生效值却变了。

这个问题的排查路径很明确：参数下发后至少半小时，做一次配置回读比对，重点检查有值域约束的参数。如果发现截断，按V1.5文档里的新值域重新下发。另外，升级网管版本后不要直接沿用旧的批量配置脚本，先拿一个小区做验证，确认逐一下发和批量下发的结果一致。

6. 上线后验证：三张图和一条最实用的对齐技巧

6.1 验证期看的三条曲线

参数改完之后，我建议按一周的维度做验证，而不是看一天。第一天看现网指标波动会因为切换、干扰、用户分布各种因素失真，一周数据才能把正常和不正常分开。

第一张图是RTP时延和抖动曲线。重点看时延是否出现周期性尖峰，如果有，说明DRX周期或者偏移还有问题。第二张图是DRX激活占比曲线。忙时激活占比如果爬上50%，说明UE醒得太久，要回去压onDuration和inactivityTimer。第三张图是语音MOS的分布曲线，按小区维度看MOS低于3分和低于3.5分的用户占比变化。三张图结合起来看，基本能判断出参数配置是成功还是翻车。

6.2 最值得先试的一步：把DRX周期偏移和语音帧边界对齐

这是我从多次语音专项优化里提炼出性价比最高的一步操作。不算复杂，但做对了能解决大半的语音抖动投诉。

计算方式不直观的地方在于：周期偏移的单位是毫秒，但“对齐”不是让偏移等于0，而是让激活期窗口覆盖RTP包的实际到达时刻。举个例子，5ms双周期帧结构下，语音帧20ms一个，如果DRX周期配80ms，那RTP包每隔20ms来一个，一个80ms周期里会有4个语音包。你要把激活期窗口放在能覆盖这4个包的位置上，而不是机械地把偏移设为20ms的整数倍。先确定基站侧缓存里语音包到达的平均时隙位置，再反推开机时刻。这个偏移量在网管上可能就是一位数字的调整，带来的改善却比调半天调度参数明显得多。

后来我养成了一个习惯：每到一个新站点优化语音参数，第一件事永远是拉帧结构和RTP包到达时间分布，先把偏移算对再谈其他参数。这个习惯帮我少走了很多弯路。做VoNR优化，参数表背得再熟也没用，真正有用的永远是先把时间轴对齐了，再让两套机制各干各的活。希望这些经验能帮到你。

本文还有配套的精品资源，点击获取