VoNR语音质量优化：DRX与智能预调度为何必须成对配置

简介面向5G网络优化人员的VoNR DRX与智能预调度参数规范说明聚焦语音业务在NR网络中的节电与调度协同配置。内容涵盖语音BWP切换条件如VonrExitBwp2UserNumThld0、长DRX周期40ms、不同频段下OnDuration/Inactivity/重传定时器取值以及QCI1/QCI2参数组绑定、MML配置示例与生效判断原则并对DRX黑名单等异常处理场景给出说明便于一线优化工程师直接对照实施。压缩包为1个pptx文件大小1.46MB以图表和命令片段呈现重点突出2.6G与700M差异配置适合具备一定5G参数优化基础、需要快速掌握VoNR节电参数落地方法的工程师参考。已有335人学习。1. 为什么VoNR里DRX和智能预调度必须成对开启VoNR DRX和智能预调度开启参数规范说明V1.5.pptx这名字放到网优工程师桌上乍看又是一套“按表抄参数”的任务书。但真按它下过一次数据的人都清楚只开DRX终端功耗能降语音时延立刻露馅只开智能预调度功耗没省下来上行干扰还可能先爆表。我的结论是这两套开关就是一对必须在同一版VoNR参数规范里绑定下发并且把DRX周期、监听窗口、预调度周期三者的时序对齐VoNR的语音质量才算真正“过检”。这份V1.5要解决的核心问题不是“要不要省电”而是在VoNR语音承载上如何用DRX的睡眠窗口换终端省电同时用智能预调度把上行授权提前塞进UE醒着的窗口把端到端时延控制在通话可接受的范围里。适合VoNR参数规划、外场优化、基站L2调测和终端协议栈测试的同学参考。2. 从Vonr协议栈看DRX与智能预调度为什么是一对省电与时延的账要理解这个标题先看VoNR里一路语音报文怎么走。终端侧20ms生成一个语音帧经RTP/UDP/IP进PDCP/RLC/MAC/PHY网络侧基站MAC调度器决定每个TTI给谁发下行数据、给谁发上行授权。DRX改的是UE监听PDCCH的时间表智能预调度改的是MAC调度器下发上行授权的方式。两者都在Vonr协议栈的调度路径上一个管“听不看”一个管“发不发”。2.1 连接态DRX在VoNR协议栈里谁决定UE什么时候听PDCCHVoNR语音承载走的是RRC_CONNECTED状态这里用的DRX是C-DRX不是空闲态DRX。C-DRX配置在RRC重配置消息里核心字段包括drx-onDurationTimer、drx-InactivityTimer、drx-HARQ-RTT-TimerDL、drx-RetransmissionTimerDL、drx-LongCycleStartOffset。这些计时器的配合逻辑是UE在长周期比如160ms内只在一个“on duration”窗口里监听PDCCH窗口内如果收到调度或初传消息InactivityTimer延长监听时间如果收到HARQ下行重传重传定时器让UE在预期重传时刻继续监听。这套机制在gNB侧由MAC调度器感知在UE侧由RRC状态机驱动两侧的计时器必须理解一致。在Vonr协议栈里DRX参数不是全局常量而是承载级的。规范里通常要求把它绑定到QCI1/VoNR专用承载普通数据承载不要跟着开。因为数据业务对时延不敏感开DRX反而降低峰值速率语音业务必须优先保证周期性和低抖动。注意连接态DRX不影响移动性测量和系统消息接收只影响PDCCH监听。真到切换时DRX的监听窗口会造成测量上报延迟这是另一个调参维度。2.2 只开DRX不碰预调度20ms语音包如何被160ms周期拖累语音帧周期是20msC-DRX长周期常见配置是160ms。也就是说语音帧每来8个UE只醒一次窗口比如8ms。问题是语音帧到达时刻不会因为DRX配置而改变。先看上行的时序。UE要发上行语音包正常情况下要么被调度器授了权要么先发调度请求SR/BSR等基站回来再发。没有预调度时如果语音包在UE睡眠期间到达上行缓存UE必须等到下一个on duration醒来才能发SR基站处理后授权发下来已经是几个毫秒之后。如果SR周期为2ms这里加上排队时间上行初传时延轻松到40ms以上。DRX周期越大这个等待越明显。下行方向更“憨”一点。基站有下行语音包要发但UE在睡眠gNB发了UE也听不到于是只能等下一个DRX周期。20ms间隔的语音包在一个160ms周期内会积压多个到达间隔在去抖动缓冲里被拉长用户听到的就是吞字、断续。所以“只开DRX”的后果不是理论上的时延劣化而是语音包到达相位的运气。运气好语音包落在监听窗口里没问题运气差连续几个包都落在睡眠区间MOS分直接下滑。这就是为什么规范里要先算“DRX周期必须是20ms的整数倍”以及“需要预调度兜底”。2.3 智能预调度的两类实现固定周期授权与缓存触发授权智能预调度一句话说就是不让UE先喊调度请求基站主动把上行授权发给它。语音上行是20ms周期而且每个语音包大小相对稳定基站完全可以预测授权的下发时机。常见实现有两类。一类是固定周期预调度gNB每20ms固定下发一次UL grant不管UE上行有没有数据。实现简单时延最优但UE没语音数据时也不间断空发授权PDCCH开销和上行功率都浪费。另一类是缓存触发式预调度判断BSR或者SR后启动UE首次上报BSR后gNB在后续多个周期内自动跟上周期性授权直到缓存清空。这类方式更贴近“智能”两个字省掉了空授权代价是第一个语音包仍要等一次SR流程。关键就在预调度授权和DRX窗口的配合。预调度授权必须落在UE的DRX on duration窗口内否则UE收不到DCI。V1.5里常见做法是把预调度周期设为DRX长周期的1/8也就是160ms配20ms同时把预调度授权下发时刻对齐到on duration窗口内使每个语音包在UE清醒期间到达。这里就解释清楚了标题里“开启参数规范”为什么要把DRX和智能预调度放在同一张表里单开DRX省电但时延靠运气单开预调度时延好但省不了电还增加干扰两个一起开并做周期绑定才是一组有约束的完整参数。3. 按V1.5配置DRX与智能预调度参数清单和下发顺序这一章先给参数清单。注意我写的是“常见基线值”不是抄某厂家某版本默认值在实际网管上不同厂家的参数名称和单位会略有差异但逻辑相同。3.1 QCI1承载上的DRX参数清单这6个值先定下来参数常见取值边界参考配置说明DRX开关ONOFF为回退绑定到QCI1专用承载不要全局开启drx-onDurationTimersf88mssf6~sf10监听窗口太短会漏DCI太长费电drx-InactivityTimersf20sf20~sf40收到初传后延长监听时间语音场景不建议超40msdrx-HARQ-RTT-TimerDLsf8sf8~sf16下行HARQ重传前抑制监听通常不用动drx-RetransmissionTimerDLsf8sf8~sf16期望下行重传时监听与HARQ RTT配合drx-LongCycleStartOffset160ms, offset080/160/320ms长周期必须是20ms整数倍offset用于对齐语音包到达时刻这6个值里最容易被忽略的是LongCycle的offset。很多人默认offset0以为只要周期对上就行。实际上语音包到达时刻有一个固定的时间分布通常与核心网的包处理时刻相关offset设得不好on duration窗口和语音包到达错开前面讲的“运气差”就会出现。所以我在外场调VoNR时会先拉话统里的VoNR上行SR请求次数或RTP包到达时间分布把offset对准到达密度的峰值。3.2 智能预调度参数与DRX周期的绑定关系参数常见取值边界参考配置说明智能预调度开关ON仅QCI1OFF为回退不可全局打开只对VoNR语音承载生效预调度周期20ms20/40/80ms必须能被DRX长周期整除常见配对是160ms配20ms预调度授权偏移0ms或2ms0~4ms相对DRX on duration起点调整保证UE醒来后再收到授权预调度窗口长度8~10ms不超过on duration窗口大于监听窗口时授权会落入睡眠期预调度触发门限4~8字节视上行包大小缓存超过门限才启动预测避免空发授权预调度MCS限制动态/固定MCS视干扰水平固定低MCS对干扰敏感上行干扰偏高时限制步进这里有一个容易犯的错把预调度周期配成5ms。从时延看5ms确实比20ms更激进但VoNR语音包本身就是20ms一个更密的预调度不会让语音质量更好只会让UE每5ms醒来一次DRX省电效果被抵消同时整网所有VoNR终端都保持高频报文解码PDCCH盲检次数暴涨。我在现场见过这种配置指标看起来“时延很低”但终端耗电投诉接踵而来。3.3 配置下发顺序先DRX后预调度还是反着来先下DRX再开智能预调度不要反过来。原因是预调度参数里的周期、偏移、窗口长度都要参考DRX的周期与on duration窗口来确定。顺序搞反预调度授权下发窗口和DRX窗口对不上参数配置本身没错空口行为却错位。实际操作时我习惯分四步走。第一步在网管上为QCI1/语音承载创建DRX策略确定LongCycle与offset先不下发到现网。第二步用离线参数校验工具检查预设值与现网其他参数的兼容性比如是否与SR周期冲突、是否在终端支持的DRX范围内。第三步下发DRX并同步打开智能预调度把预调度周期设为DRX周期的约数、授权偏移对on duration起点。第四步用一部测试终端发起VoNR呼叫抓RRCReconfiguration和基站L2调度日志确认时序图符合预期后再批量推全网。提示批量推送前一定要先在一两个站点灰度。VoNR语音质量与无线环境强相关边缘用户与近点用户在DRX窗口内的调度成功率不一样单站点验证不代表全网结果。4. 验证配置真实生效信令检查、调度日志与批量参数扫描参数下发了不等于空口生效。我见过太多“网管显示ON但空口就是没有”的情况所以验证必须落到信令和调度日志上。4.1 RRCReconfiguration里找DRX-Config比相信网管状态更可靠最直接的验证方式是抓VoNR呼叫建立过程中的RRCReconfiguration消息。展开其中的radioBearerConfig或者mac-CellGroupConfig能看到DRX配置是否携带、各计时器值是否与规范一致。具体做法用路测软件或基站信令跟踪呼叫建立后过滤RRC Reconfiguration查看drx-Config字段。若UE侧返回RRCReconfigurationComplete说明终端已经接受如果消息里没有drx-Config说明配置根本没挂到这条承载上后面不用再查别的指标先回网管改绑定。这一步要提醒自己的是看值不看开关。有些网管界面“DRX开关ON”但onDurationTimer、InactivityTimer还是默认数据业务的参数比如80ms那相当于没配。4.2 基站调度日志确认预调度授权落在了On Duration窗口VoNR的MAC调度行为在基站侧L2 trace里看最直接。拉出来的调度日志里重点看上行授权授权时刻、周期、有无BSR/SR触发。判断方法很简单。在一个DRX长周期比如160ms内把授权的时域位置画出来如果授权集中在on duration窗口内且以20ms为间隔出现并且部分授权的数据缓存为0说明预调度生效如果授权零散分布或在on duration之外频繁出现说明DRX与预调度时序没有对齐。不要盲目相信日志里的“预调度开关ON”。很多基站的开关只决定调度器是否触发预调度不保证授权位置一定落在DRX窗口这两个逻辑在MAC实现上往往是独立模块。真要做精确定位就用时隙层面的授权时域分布去和DRX窗口比对把调度器当黑匣子来验证反而更快。4.3 一个Python脚本扫全网参数DRX与预调度不匹配就报错站点多了以后人工核对不现实。我通常会把网管导出的全网站点参数CSV喂给一个小脚本自动检查三件事DRX开了预调度是否开、预调度周期能否整除DRX周期、on duration是否太短。脚本如下。import csv import sys # 参数扫描脚本检查VoNR DRX与智能预调度配置的一致性 def scan_vonr_drx_pre_sched(path): EXPECT_PRESCHED_PERIOD_MS 20 EXPECT_MIN_ON_DURATION_MS 8 problems [] with open(path, encodingutf-8-sig) as f: reader csv.DictReader(f) for row in reader: cell row.get(cellName) or row.get(CELL_ID, ) drx_switch row.get(DRX_SWITCH, ).strip().upper() pre_sched_switch row.get(PRE_SCHED_SWITCH, ).strip().upper() drx_cycle int(row.get(DRX_LONG_CYCLE_MS, 0) or 0) on_duration int(row.get(DRX_ON_DURATION_TIMER_MS, 0) or 0) pre_period int(row.get(PRE_SCHED_PERIOD_MS, 0) or 0) # 规则1DRX开了预调度必须同步开 if drx_switch ON and pre_sched_switch ! ON: problems.append(f{cell}: DRX已开但智能预调度未开) # 规则2预调度周期必须能整除DRX周期保证授权对齐 if drx_switch ON and drx_cycle % pre_period ! 0: problems.append(f{cell}: 预调度周期{pre_period}ms不是DRX周期{drx_cycle}ms的约数) # 规则3on duration不够长建议至少8ms if drx_switch ON and on_duration EXPECT_MIN_ON_DURATION_MS: problems.append(f{cell}: OnDuration {on_duration}ms偏短建议不小于{EXPECT_MIN_ON_DURATION_MS}ms) if not problems: print(OK: 所有检查通过) else: print(存在问题:) print(\n.join(problems)) return problems if __name__ __main__: scan_vonr_drx_pre_sched(sys.argv[1] if len(sys.argv) 1 else gnb_params.csv)这段脚本的逻辑不复杂关键在列名映射。上面的示例列名是我常用的导出模板不同网管导出的CSV可能叫DRX_ENABLED、ON_DURATION_TIMER_SF等实际用之前先把导出一列在Excel里打开改成一个字典做别名映射即可。脚本输出的三类告警正好对应最常见的三种错误漏开预调度、预调度周期不与DRX周期对齐、on duration太短。把脚本挂到每周的参数巡检任务里新开站、新版本上线后自动跑一遍能省掉不少人工复查的时间。5. 常见问题排查VoNR DRX和智能预调度开启后最常翻车的5个点5.1 开了DRXMOS反而从4.0掉到3.3现象整站开启DRX后的第二天VoNR MOS均值下滑上行语音丢包率微涨用户反馈“偶尔断断续续”。原因这一类情况绝大多数不是DRX本身有问题而是只开了DRX没开预调度或者DRX的LongCycle offset没对齐。语音包到达时刻和on duration窗口错位UE经常在睡眠期收到DL数据调度排队时间变大去抖动缓冲溢出。解决回退DRX开关恢复语音质量后再重新配置。先统计VoNR RTP包到达时间分布把LongCycle offset对准到达峰值再打开智能预调度预调度周期配20ms确保授权落在on duration窗口内。这样调整后MOS基本能回到基线。5.2 智能预调度一开上行干扰抬升3dB现象开通预调度后VoNR上行干扰噪声RSSI/IOT在全网普遍抬升功率控制发送功率分布上移但业务量并没有明显增长。原因固定周期预调度下UE即使没有上行数据也持续收到授权并按授权做PUSCH突发或保持同步大量VoNR终端同时空发干扰就被“刷”上来了。另外预调度授权里的MCS如果过低还会进一步放大干扰。解决把固定周期预调度改成缓存触发式或者设置4~8字节的BSR门限只有UE上行有实际语音数据时才触发持续授权。同时预调度周期从5ms改回20msMCS不要固定锁在低阶让链路自适应正常工作。5.3 同一批终端部分型号掉话率偏高现象全网参数统一但某个品牌旧型号终端的VoNR掉话率高出其他型号一倍呼叫日志终端侧显示一直没有进入DRX Active Time。原因老终端对C-DRX周期的兼容性差或者对预调度授权处理不及时。on duration窗口最后几个符号下发的授权终端来不及解出DCI和准备PUSCH数据发送被延后RTP超时后触发RLF恢复流程表现就是掉话偏多。解决按终端能力白名单差异化配置。受影响的机型把on duration从8ms拉到10ms预调度授权偏移往后挪让UE在窗口内提前2ms醒过来。如果终端确实不支持160ms长周期就退回320ms或关闭该机型的DRX用功耗换质量。5.4 参数下发了RRC重配里却没有DRX现象网管侧DRX开关已经置ON但从空口信令看VoNR呼叫建立过程中RRCReconfiguration消息里没有携带drx-Config。原因配置绑错了承载。DRX策略挂在了默认承载或非GBR承载上而VoNR语音走的是QCI1专用承载RRC重配时专用承载没有引用该DRX策略终端自然拿不到。这个问题在参数规范表里最容易踩只管在“DRX开关”上打勾不去核对配置的引用对象。解决检查DRX策略绑定的承载对象是不是QCI1的专用承载核心网侧同时确认该QoS Flow映射是否正确。改完绑定后重新发起VoNR呼叫再抓一次RRCReconfiguration验证drx-Config出现与否。5.5 DRX和预调度都开了手机还是费电现象开启DRX与预调度后终端在通话中的耗电没有明显改善MDC终端日志显示Active Time占比超过60%。原因InactivityTimer的值没有调。如果沿用默认的80ms甚至更长语音通话时每个语音包到达都会触发InactivityTimer重启UE几乎一直在监听PDCCH。再加上预调度周期过密UE每个TTI都要起来解码授权省电效果就被对冲了。解决把InactivityTimer压到20ms让UE在语音包批次之间尽快回到睡眠预调度周期保持20ms窗口长度控制在on duration内用MDC日志复核Active Time占比降到20%以下再推全网。6. 把DRX周期与预调度窗口对齐的进阶调法从固定参数到自适应到这一步如果站点已经按V1.5基线配好、验证通过接下来还能做的一件事是从“固定值”走向“按话务模型自适应”这是我把这个方案从及格拉到好用的关键一步。具体做法是在交互优化期间从网管统计每个扇区VoNR上行SR请求次数在毫秒级时间窗口内的分布算出语音包到达密度最高的相位再把DRX LongCycle offset的中心对准这个相位预调度授权下发时刻跟随偏移。也就是说160ms周期配20ms预调度周期不再是一成不变而是让DRX的“睡眠起点”随业务分布移动。一个标准的对齐时序可以这样描述DRX长周期160mson duration设为8msoffset对准上行RTP包到达峰值前2ms预调度周期20ms授权下发位置落在on duration窗口内第一个授权从窗口起点后0~2ms发出后续授权每20ms一次始终与语音包节奏重合。这样每个语音包到达时UE都已清醒且拿到的授权刚刚好够用。只靠long cycle 160ms加一个8ms的on duration其实没法保证20ms包阵都落在监听窗口内。所以商用配置里的另一个进阶技巧是把C-DRX的short cycle用起来short cycle40ms、shortCycleTimer16。语音包到达后InactivityTimer触发UE会用短周期继续监听没有后续包进入后UE从短周期迁回长周期既保证突发密集期的包能被监听到又能在语音间隙把睡眠占比拉回来。这类参数在V1.5的表格里通常作为可选段我一般只在on duration和long cycle无法完全对齐时启用。现在的基站调度器越来越智能有些厂家已经支持按BSR包到达特征自动调整预调度起始点。我在实际项目里还是习惯先用固定参数跑通再做一轮基于统计的偏移校正。因为自适应逻辑在不同版本的表现差异很大调试时要同时看终端功耗和时延分布否则很容易把“智能化”调成“随机化”。这也是我这几年代VoNR参数优化项目里最值钱的一条经验先相信规范给的固定组合再拿实测数据去触碰边界最后用参数巡检脚本兜住回退。希望帮到你。本文还有配套的精品资源点击获取