简介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参数范围下面这组参数范围是从多个商用语音优化项目里沉淀出来的逻辑是“周期对齐语音帧、唤醒窗口压缩、非激活快速关断”。不同厂商网管参数名有差异但对应的语义基本都能对上。参数含义语音推荐值说明drx长周期长周期长度40ms / 80ms必须与帧结构、语音帧间隔对齐避免RTP落点漂移drx短周期短周期长度20ms可选短周期能降低调度等待但PDCCH盲检功耗上升onDurationTimer每次唤醒持续监听时长4ms ~ 6ms足够覆盖1~2个slot的调度与HARQ反馈inactivityTimer收到调度后额外保持唤醒1ms ~ 4ms不要给大语音包小而固定不需要长时间驻留drx周期偏移激活期起点偏移按语音帧边界计算偏移算错一切白搭下文具体讲怎么算HARQ RTT Timer首传后等待重传的间隔保守值让重传尽量落在激活期内这组参数的总体目标是UE每个语音周期只醒一次每次醒5ms左右干完活立刻睡。这样DRX激活占比通常能压到30%以下而RTP单向时延仍然能维持在30ms以内MOS不受明显影响。2.4 参数生效后的观察点DRX激活比例和RTP丢包参数下发之后别急着看MOSMOS是综合结果一出问题你分不清是传输抖动、编解码还是无线侧引起的。我会优先看两个更底层的指标DRX激活时间占比和RTP丢包率。DRX激活占比可以从UE上报的统计数据里取也可以看基站侧统计的激活期PDCCH监听次数。如果配置合理语音业务下激活占比应该在20%到35%之间。如果这个数字超过50%说明onDuration或者inactivityTimer给大了UE名义上在省电实际射频一直在工作。另一个指标是RTP丢包率和抖动这个在核心网侧或者基站侧的语音质量统计里能看到。配置完DRX后如果抖动突然从5ms涨到15ms以上大概率是周期偏移没算对RTP包开始周期性滑出激活窗口。3. 智能预调度让基站提前把资源摆上桌3.1 先看没有预调度的上行语音要等多久上行语音包想发出去在标准动态调度流程里要经过一个完整的“举手—批准—发送”流程。UE先有了数据然后在SR资源上发调度请求基站收到SR后分配UL grantUE拿到授权才能在上行共享信道上发数据。这个流程如果SR周期是20msUE恰好刚错过一个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限制预调度授权使用的最高调制阶数保守档13~15左右语音包小不需要高阶MCS还能降低空授权色散干扰预调度最大RB数限制单次预调度占用的资源块数量10~20个RB防止一个语音用户吃掉过多PUSCH资源预调度预测窗口在预测到达时刻前多久开始发授权10ms~20ms窗口太大等于普通预调度太小又来不及覆盖调度时延这里重点说一说MCS上限。预调度时UE并没有实际数据在缓冲区基站是按预测盲发的授权所以它不知道这个包里到底有多少数据、信道质量到底怎么样。如果MCS放得很高授权给得很大UE拿到授权后有可能真按这个高MCS发数据但事实上它站点的上行信道质量根本撑不住这个阶数一来一回反而把误块率打上去。语音场景根本不需要高MCS去冲吞吐量把上限卡在保守档换来的是更低的盲检错误概率和更稳定的上行发射功率。3.4 配置命令示意下面给一个非特定厂商的配置示意目的是把参数之间的逻辑关系说清楚。实际在网管界面上参数名和值域会跟你手上这套不一样但配置顺序和核对思路是通用的。// 智能预调度参数配置示意需按现网网管实际参数名调整 // 第一步打开智能预调度开关上行独立控制 MOD PRESCHED: SWITCHON, DIRECTIONUL_INDEPENDENT; // 第二步限制预调度授权质量 MOD PRESCHED_CTRL: MAX_MCS13, MAX_RB16, SCHED_WINDOW15;第一个命令是总开关这里我习惯把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 两套参数组合推荐实际落地时我一般把组合分成三档按用户感知和功耗诉求选组合DRX配置预调度配置适用场景功耗优先长周期80msonDuration 4ms上行开启MCS上限13窗口12ms大电量机型为主、语音业务量低的区域质量优先短周期20msonDuration 6ms上行开启MCS上限15窗口18ms核心城区、投诉敏感区域、高铁沿线均衡档长周期40msonDuration 5ms上行开启MCS上限14窗口15ms默认推荐大多数场景从这档起步质量优先档我特别说明一下。短周期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、还搭配高阶MCSUE用不掉那么多资源这些被占用的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优化参数表背得再熟也没用真正有用的永远是先把时间轴对齐了再让两套机制各干各的活。希望这些经验能帮到你。本文还有配套的精品资源点击获取
