企业官网建设流程全解析

简介：面向5G网络优化人员的VoNR DRX与智能预调度参数规范说明，聚焦语音业务在NR网络中的节电与调度协同配置。内容涵盖语音BWP切换条件（如VonrExitBwp2UserNumThld=0）、长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什么时候听PDCCH

VoNR语音承载走的是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周期拖累

语音帧周期是20ms，C-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个值先定下来

这6个值里最容易被忽略的是LongCycle的offset。很多人默认offset=0，以为只要周期对上就行。实际上语音包到达时刻有一个固定的时间分布（通常与核心网的包处理时刻相关），offset设得不好，on duration窗口和语音包到达错开，前面讲的“运气差”就会出现。所以我在外场调VoNR时，会先拉话统里的VoNR上行SR请求次数或RTP包到达时间分布，把offset对准到达密度的峰值。

3.2 智能预调度参数与DRX周期的绑定关系

这里有一个容易犯的错：把预调度周期配成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, encoding="utf-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) # 规则1：DRX开了，预调度必须同步开 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的约数") # 规则3：on 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 开了DRX，MOS反而从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改回20ms，MCS不要固定锁在低阶，让链路自适应正常工作。

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长周期160ms，on duration设为8ms，offset对准上行RTP包到达峰值前2ms；预调度周期20ms，授权下发位置落在on duration窗口内，第一个授权从窗口起点后0~2ms发出，后续授权每20ms一次，始终与语音包节奏重合。这样每个语音包到达时UE都已清醒，且拿到的授权刚刚好够用。

只靠long cycle 160ms加一个8ms的on duration，其实没法保证20ms包阵都落在监听窗口内。所以商用配置里的另一个进阶技巧，是把C-DRX的short cycle用起来：short cycle=40ms、shortCycleTimer=16。语音包到达后InactivityTimer触发，UE会用短周期继续监听；没有后续包进入后，UE从短周期迁回长周期，既保证突发密集期的包能被监听到，又能在语音间隙把睡眠占比拉回来。这类参数在V1.5的表格里通常作为可选段，我一般只在on duration和long cycle无法完全对齐时启用。

现在的基站调度器越来越智能，有些厂家已经支持按BSR包到达特征自动调整预调度起始点。我在实际项目里还是习惯先用固定参数跑通，再做一轮基于统计的偏移校正。因为自适应逻辑在不同版本的表现差异很大，调试时要同时看终端功耗和时延分布，否则很容易把“智能化”调成“随机化”。

这也是我这几年代VoNR参数优化项目里最值钱的一条经验：先相信规范给的固定组合，再拿实测数据去触碰边界，最后用参数巡检脚本兜住回退。希望帮到你。

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