简介：面向5G网络优化人员的VoNR DRX与智能预调度参数配置参考资料，解决语音业务场景下终端功耗与网络性能平衡问题。内容涵盖VoNR DRX参数配置汇总、开启与关闭DRX的MML命令示例、QCI承载绑定规则及DRX生效判定原则，并涉及BWP切换、长DRX周期、On Duration Timer等关键参数说明，适合从事VoNR优化及参数策略制定的工程师参考。资源包共1个文件，为pptx格式演示文稿，大小约1.46MB。目前已有335人学习下载，可作为5G语音优化方向的实操配置依据，帮助理解参数组绑定逻辑与不同频段下的差异设置。

1. VoNR DRX与智能预调度：一份把参数落到MML的现场操作单

VoNR是5G网络优化里对调度连续性要求最高的业务，DRX和智能预调度这两组参数直接决定语音质量与终端功耗之间的平衡。这份V1.5参数规范说明，把华为设备侧VoNR的DRX参数组、MML下发步骤、终端黑名单、CA配合约束和智能预调度开关全部收拢成一套可执行动作，核心目标是让QCI1语音承载在40ms长周期DRX下仍然稳定调度，同时满足集团对5QI1 C-DRX全网开启、关闭5ms预调度的要求。适合VoNR专项优化、参数审核和指标劣化排查的工程师，版本锚点在18.1SPC210。参数表和MML可以直接抄，真正需要动脑的是CA场景和黑名单这两块，后面逐条拆。

2. DRX参数组设计：BWP切换和生效原则决定MML怎么写

2.1 语音BWP的DCI切换：先让VoNR用户留在BWP1

规范一上来就把BWP的事说清楚了：语音业务默认在BWP1_100M上，BWP2是20M/51RB的节能带宽，VoNR场景要求关闭BWP2，做法是把NRDUCellUePwrSaving.VonrExitBwp2UserNumThld设为0。这个参数的含义是“BWP2内用户数门限”，配0表示只要BWP2上没人就直接关掉，语音用户始终留在BWP1，不做BWP切换。

为什么不把语音用户切到20M去省电？因为BWP切换要经历RRC重配和DCI切换，边界处理不好就出现几十毫秒的调度空窗，在VoNR里直接表现为断续。51RB是20M带宽下的可用RB数，100M大带宽留给VoNR和高速数据共用，DCI始终在BWP1上给语音用户下发调度，这是后面所有DRX参数生效的前提。我一般会先把这一步核对完再动DRX，省得后面查问题时分不清是BWP切换导致还是DRX导致。

BWP关闭的另一个作用是省电。VoNR用户始终留在100M BWP上，意味着UE的射频带宽一直开着100M，功耗理论上比20M高。但和BWP切换带来的调度中断比，这点功耗换来的是语音稳定性。集团规范在这里选了稳定性优先，现场做节能方案时不要在这条上自作主张。

2.2 两组DRX定时器：L3管周期，DU管监听窗口

DRX参数被拆成两组，GNBDRXPARAMGROUP管L3侧的长周期，GNBDUDRXPARAMGROUP管DU侧的监听执行。规范里的值是集团基线，列出来对照：

从VoNR协议栈角度看，这不是定时器堆叠：OnDuration决定终端醒来后能监听到多少PDCCH机会，Inactivity决定语音包突发后监听窗口是否继续保留，Retrans决定HARQ重传时终端是否醒来。40ms长周期里终端按这几个窗口醒来听调度，听不到就继续睡，时延和功耗的平衡全落在这组数字上。ShortCycleTimer配0意味着不走短周期状态机，避免长短周期切换带来额外调度抖动。

两组参数要一起生效，L3的LongCycle和DU的OnDuration并不是简单相加。以40/10/10为例：语音半帧调度周期20ms，DRX长周期40ms覆盖两个无线帧；OnDuration 10ms保证终端至少能监听到一个语音半帧的PDCCH；Inactivity 10ms把监听窗口向后延伸，覆盖语音包的抖动和重传。700M频段OnDuration只有4ms、Inactivity 5ms，是因为低频覆盖下信道变化慢、调度机会相对集中，窗口短一点也能保证听到调度。这个频段差异经常被当成bug，其实是规范针对不同传播环境的刻意区分。

DU侧DrxRetransTimer的8slot和16slot差异也要说明：8slot适合时延敏感的小包语音，16slot覆盖更多重传机会但增加唤醒时间。规范给的是区间不是固定值，现网统一走16slot时延余量更足。参数组ID的规划单独说一句，DrxParamGroupId和DuDrxParamGroupId是两套编号空间，绑定到NRCELLQCIBEARER和NRDUCELLQCIBEARER时要一一对应，实际中常见的问题是L3和DU用了同一套ID但含义不同，或者两个小区共用一个ID却绑了不同QCI，导致生效参数组查出来不是预期。我会在参数规划表里把L3组号和DU组号分开列，备注映射关系。

2.3 生效原则：QCI1优先，255即关闭

真正决定现场行为的是生效原则，我先把原文逻辑拆成三条：

• 用户多个承载中任何一个DrxParamGroupId或DuDrxParamGroupId为255，该用户DRX不生效；
• 全部非255时，如果存在QCI1专载，按QCI1参数组生效；
• 不存在QCI1时，按每个承载gNBQciBearer.PriorityLevel中最小的生效，也就是优先级最高的承载说了算。

举个例子：终端同时有QCI1语音专载和QCI5默认承载，QCI1绑组A、QCI5绑组B，最终按组A执行。如果反过来QCI5绑了高优先级而QCI1没绑，就要检查参数组规划是不是弄反了。这也是规范里QCI1和QCI2必须绑同一个参数组的原因——不是图省事，是防止同一个终端同时带QCI1和QCI2时因优先级跳变导致DRX行为不稳定。现场如果发现QCI1和QCI2绑了不同组，请对照这条原则重新规划，别等指标掉了再查。

255这个保留值特别重要，它不只是“不生效”，还承担了回退开关的角色。后面第3章关DRX的命令全部是“把参数组改回255”，而不是删除参数组，就是因为生效原则里“任何一个255即全局不生效”的机制设计。理解了这条，MML里的回退操作就不用死记。

3. VoNR DRX开启与关闭MML：五条命令覆盖全部操作路径

3.1 开启小区级DRX开关

操作的第一步是确认小区DRX算法开关是打开的，命令如下：

MOD NRDUCELLUEPWRSAVING: NrDuCellId=0, NrDuCellDrxAlgoSwitch=BASIC_DRX_SW-1;

NrDuCellId按小区实际编号填，0只是示例。NrDuCellDrxAlgoSwitch选BASIC_DRX_SW-1表示打开基础DRX开关。规范里专门加了一句：仅未开启基础DRX的小区需要执行，如果现网存在2B站点未开启基础DRX，按2B站点要求处理，不强行打开。批量给全网小区下发时最容易在这句上翻车，脚本里把所有小区都刷一遍，结果把2B站点不该开的也开了。我一般会先把小区清单按站点类型过滤一次，再执行命令。

3.2 添加L3与DU参数组

小区开关打开后，需要把DRX参数组建出来。参数组分L3和DU两层：

ADD GNBDRXPARAMGROUP: DrxParamGroupId=xxx, LongCycle=MS40, ShortCycleTimer=0; ADD GNBDUDRXPARAMGROUP: DuDrxParamGroupId=xxx, OnDurationTimer=MS10, DrxInactivityTimer=MS10, DrxRetransTimer=SL16;

DrxParamGroupId和DuDrxParamGroupId的xxx按现网编号规划，建议和小区绑定关系做成表格，别顺手填一个。LongCycle=MS40是集团规范值，ShortCycleTimer=0关闭短周期。DU侧的OnDurationTimer、DrxInactivityTimer按频段取：2.6G配MS10/MS10，700M配MS4/MS5。如果700M小区抄了2.6G的10ms也没问题，但和规范不一致，后续对标集团基线会被卡。参数组如果已经存在，ADD会执行失败，这时改用MOD带上完整参数值覆盖即可，命令格式一致，只是操作码不同。

3.3 绑定QCI1和QCI2

参数组建好后，要和QCI绑定。QCI1和QCI2绑到同一个组：

MOD NRCELLQCIBEARER: NrCellId=0, Qci=1, DrxParamGroupId=xxx; MOD NRDUCELLQCIBEARER: NrDuCellId=0, Qci=1, DuDrxParamGroupId=xxx; MOD NRCELLQCIBEARER: NrCellId=0, Qci=2, DrxParamGroupId=xxx; MOD NRDUCELLQCIBEARER: NrDuCellId=0, Qci=2, DuDrxParamGroupId=xxx;

L3和DU两侧都要绑，NRCELLQCIBEARER对应L3参数组，NRDUCELLQCIBEARER对应DU参数组。常见错误是只绑了L3，DU侧没绑，结果DRX周期看起来配上了，实际终端并没有按预期进入休眠。QCI2是IMS信令承载，和QCI1绑同一组是为了让语音和信令在DRX行为上保持一致，避免用户同时建立QCI1和QCI2承载时按2.3节的生效原则取到不同参数。绑定后可以用查询命令拉QCI承载表，确认绑定的参数组ID不是255。

3.4 关闭DRX：把参数组解绑回255

关闭DRX不需要删参数组，把绑定关系改成255即可：

MOD NRCELLQCIBEARER: NrCellId=0, Qci=1, DrxParamGroupId=255; MOD NRDUCELLQCIBEARER: NrDuCellId=0, Qci=1, DuDrxParamGroupId=255; MOD NRCELLQCIBEARER: NrCellId=0, Qci=2, DrxParamGroupId=255; MOD NRDUCELLQCIBEARER: NrDuCellId=0, Qci=2, DuDrxParamGroupId=255;

255在参数组ID里是“未绑定/不生效”的保留值，对应2.3节的生效原则：只要有一个承载的ID是255，该用户DRX就不生效。现场回退时经常用这套命令做后悔药，优点是不影响参数组定义，下次开启直接再绑回去。要注意的是解绑顺序：先把涉及QCI1/QCI2的四个承载全部改回255，再关小区开关，否则小区开关关闭但参数组仍被引用，后续重新开启时容易忘记哪组绑着。

3.5 生效验证与常见翻车点

配置完成后我习惯用查询命令核对三处：NRDUCELLUEPWRSAVING里的小区开关状态、NRCELLQCIBEARER/NRDUCELLQCIBEARER里的参数组绑定、GNBDRXPARAMGROUP/GNBDUDRXPARAMGROUP里的定时器值。三处一致，DRX才真正对用户生效。

提示：查询命令用LST NRCELLQCIBEARER、LST GNBDUDRXPARAMGROUP，三张表对照着看，比单看一张表更不容易漏。

现场高发翻车点有三个：一是没确认现网版本是否支持承载级DRX绑定就执行，18.1SPC210及以后版本没问题，老版本部分命令会执行失败；二是参数组ID跨小区复用但定时器值不一致，导致小区级别行为错乱；三是把QCI1和QCI2绑到不同组，和2.3节生效原则冲突。调完如果发现终端行为不对，先用查询命令把三处拉出来比对，不要急着改参数。

4. 终端黑名单与CA场景避坑：DRX不生效的五个现场

4.1 黑名单为什么存在：终端兼容性把指标打穿

VoNR开DRX后，部分终端的兼容性问题会暴露出来：掉话率恶化、上下行丢包率恶化。现象是用户通话中出现断续、掉话，KPI里体现为掉话率和丢包率抬升。原因是这些终端的DRX唤醒实现有问题，在40ms周期里醒不过来或者漏检PDCCH，基站侧看到的就是调度没响应。规范给出的解决办法是黑名单：把问题终端识别出来，单独关闭它们的DRX，牺牲这部分终端的功耗换语音质量。

4.2 黑名单MML：三个特征值加三次绑定

黑名单配置分两步，先加终端特征，再绑定关闭开关。原文给出的三个问题终端特征值如下：

ADD GNBUEINFO: UeInfoIndex=1, UeInfoType=UE_FEATUREVALUE, UeFeatureValueContent="ec7fee769ff7e0fff0", UeFeatureValueMask="ffffffffffffffffffffffffffffffff", UeTypeDesc="drx drop&packetloss 1"; ADD GNBUEINFO: UeInfoIndex=2, UeInfoType=UE_FEATUREVALUE, UeFeatureValueContent="ec7fce769ff7e0fff0", UeFeatureValueMask="ffffffffffffffffffffffffffffffff", UeTypeDesc="drx drop&packetloss 2"; ADD GNBUEINFO: UeInfoIndex=3, UeInfoType=UE_FEATUREVALUE, UeFeatureValueContent="8209e0650321e0c238", UeFeatureValueMask="ffffffffffffffffffffffffffffffff", UeTypeDesc="drx drop&packetloss 3";

UeInfoIndex按现网统一分配，不要和已有索引冲突；UeFeatureValueContent是终端特征值，Mask配全F表示精确匹配；UeTypeDesc是备注，方便现网识别这批终端。三个特征值对应三种问题终端型号，如果后续发现新的问题终端，按同样格式追加。特征值字符串里不要带多余空格，尤其是从PPT或邮件复制时容易带上前导空格，匹配失败是最常见的低级坑。

录入特征后，把黑名单绑定到DRX关闭开关：

MOD GNBUECOMPAT: UeInfoIndex=1, BlacklistCtrlSwitch=BASIC_DRX_SW_OFF-1, ParamCtrlType=TYPE_ALL; MOD GNBUECOMPAT: UeInfoIndex=2, BlacklistCtrlSwitch=BASIC_DRX_SW_OFF-1, ParamCtrlType=TYPE_ALL; MOD GNBUECOMPAT: UeInfoIndex=3, BlacklistCtrlSwitch=BASIC_DRX_SW_OFF-1, ParamCtrlType=TYPE_ALL;

BlacklistCtrlSwitch配BASIC_DRX_SW_OFF-1表示对这些终端关闭基础DRX，ParamCtrlType=TYPE_ALL表示全量参数生效。两个命令里的UeInfoIndex必须一一对应，GNBUEINFO建了特征但GNBUECOMPAT没绑开关，等于白配。我一般会在脚本里把ADD和MOD写在同一段，执行完再用查询命令核对两个表的索引一致性。

4.3 避坑记录一：黑名单加了但指标没恢复

现象：黑名单配置完成后，掉话率和丢包率没有明显回落。原因：UeFeatureValueContent复制时带了多余空格或不可见字符，特征值没有精确匹配上终端；另一个可能是GNBUEINFO和GNBUECOMPAT的UeInfoIndex不对应。解决：先用查询命令拉出GNBUEINFO里的特征值，与终端日志里的IMEI/TAC特征比对，确认字符完全一致；再把GNBUECOMPAT的绑定关系重新执行一遍，用UeTypeDesc定位是哪个索引出了问题。

4.4 避坑记录二：一个CC开DRX另一个不开，DRX直接不生效

现象：CA用户开了DRX，但用户面调度显示终端根本没休眠。原因：CA场景下两个CC的DRX配置不一致，一个CC开了另一个没开，DRX状态机无法进入休眠。解决：要么两个CC都开，要么都关，不能只处理PCC。规范原文写得很直接：如果一个CC开、一个CC不开，则DRX不生效。配置CA小区时先检查所有成员载波的小区开关，确保一致。

4.5 避坑记录三：两个CC参数不一致，按PCC生效，调SCC白费功夫

现象：SCC的DRX参数调了好几轮，用户行为没变化。原因：两个CC都开了DRX但参数值不一致时，按PCC的DRX参数生效，SCC的参数不参与。解决：先确认PCC归属，调参只动PCC的参数组；SCC保持和PCC一致即可，不需要单独规划一组。这条的血泪经验是，一次VoNR保障里把SCC的OnDuration从4ms调到10ms，指标纹丝不动，查了两天才发现生效的是PCC。

4.6 避坑记录四：FDD配40/4/4在CA场景配置直接失败

现象：按苹果测试要求给FDD配40/4/4，MML执行报错。原因：当NRDUCellAlgoSwitch里的CaAlgoSwitch子开关INTER_GNODEB_CA_SW为ON时，所有gNodeB DU DRX参数组的DrxInactivityTimer必须大于MS4，FDD的4ms配置不满足约束。解决：18.1SPC210版本CA场景下IA至少配5ms，FDD推荐40/10/5或40/5/5，4ms只能留给非CA小区。这里别硬配，命令执行不过去说明版本约束就在那。

4.7 避坑记录五：SCC调度次数下降无法根除

现象：CA场景改完IA后，SCC调度次数明显下降，但DRX本身指标正常。原因：IA扩展期从10ms降到4ms/5ms后，SCC上的调度窗口变短，调度次数随之下降。规范明确写了“无法真正规避SCC调度次数下降问题，只能保证DRX本身没问题”。解决：接受这个约束，不要在SCC调度上反复调参；如果SCC调度影响VoNR质量，考虑把语音用户限制在非CA小区或调整CA门限。这条不算bug，是DRX和CA调度资源之间的固有矛盾。

5. 智能预调度参数：语音20ms优先与差异化开关

5.1 集团要求为什么是“关5ms、开C-DRX”

集团要求很明确：全网开启5QI1的C-DRX，并关掉5ms预调度。背景是苹果终端VoNR测试，周期会持续到新硬件发布。关键动作是两个：开关DRX不是目的，关掉5ms预调度才是配套动作。5ms预调度意味着基站每5ms就给终端一次上行授权，终端根本没有机会进DRX休眠；而DRX长周期是40ms，两个机制方向相反。只开DRX不关5ms预调度，DRX的功耗收益会被高频预调度完全抵消。所以集团的说法是“务必开C-DRX并且关掉5ms预调度”，两个动作必须同时落地。

5.2 差异化预调度：TDD和FDD分别怎么配

预调度不是一刀切关掉，而是按业务差异化：语音业务20ms、数据业务5ms。华为侧通过承载级预调度开关实现，TDD和FDD的参数值不同：

// TDD小区，40slot对应语音20ms调度周期 ADD GNBDUSCHPARAMGROUP: ScheduleParamGroupId=xxx, ScheduleOptSwitch=UL_SMART_PREALLOC_QCI_SW-1, UlPreallocationInterval=40, UlPreallocationDataVolume=100, UlSmartPreallocationDur=50; // FDD小区，20slot对应语音20ms调度周期 ADD GNBDUSCHPARAMGROUP: ScheduleParamGroupId=xxx, ScheduleOptSwitch=UL_SMART_PREALLOC_QCI_SW-1, UlPreallocationInterval=20, UlPreallocationDataVolume=100, UlSmartPreallocationDur=50;

TDD小区UlPreallocationInterval配40，FDD小区配20，单位是slot。Slot数和毫秒的换算随子载波间隔变化，这正是平时容易算错的地方：集团要求的“语音20ms”落到参数上，TDD是40slot、FDD是20slot，不能拿着毫秒值直接填。如果参数组已存在，把ADD换成MOD，其他参数保持一致。UlPreallocationDataVolume是触发预调度的数据量门限，UlSmartPreallocationDur是智能预调度持续时间，这两个一般按现网默认走。

参数组建好后，还要打开业务差异化低时延开关，并把参数组绑定到QCI1：

MOD NRDUCELLALGOSWITCH: NrDuCellId=xxx, LowLatencySwitch=SERV_DIFF_LOW_LATENCY_SW-1&SERV_DIFF_POLICY_SW-1; MOD NRDUCELLQCIBEARER: NrDuCellId=xxx, Qci=1, ScheduleParamGroupId=xxx; MOD NRDUCELLRSVDEXT02: NrDuCellId=xxx, RsvdSwParam1=RSVDSWPARAM1_BIT7-1;

LowLatencySwitch里两个子开关是一起开的，业务差异化低时延和策略开关缺一不可，且依赖基本包LIC，开通前先在网管上确认LIC已加载。RsvdSwParam1的BIT7是这组功能在18.1SPC210上的保留位开关，不打开的话前面绑定了预调度参数组也不会按承载级差异化执行。三个命令执行顺序建议：先建参数组，再开算法开关，最后绑QCI1。顺序反了有可能出现绑定成功但算法开关没生效的中间状态。

参数汇总从规范里抽出来：

5.3 单独关闭承载级预调度：个别小区回退

如果某个小区开了差异化预调度后出现异常，不需要动全局参数，单独关闭承载级预调度即可：

MOD GNBDUSCHPARAMGROUP: ScheduleParamGroupId=xxx, ScheduleOptSwitch=UL_SMART_PREALLOC_QCI_SW-0;

ScheduleOptSwitch改成0，这个参数组下的所有QCI都退回普通预调度。现场做对比验证时也常用这个开关做A/B测试，验证“开与不开”对VoNR指标的差异，比反复改Interval更干净。关闭后绑定的ScheduleParamGroupId还挂在QCI承载上，但开关置0不会再触发智能预调度逻辑。

5.4 激活去激活的指标影响：改前先看风险清单

开关切换不是无损操作，规范明确列出了影响：

激活和去激活都可能有这些影响，也就是说从老版本5ms预调度切到差异化预调度，短期指标可能先恶化再收敛。原因也好理解：调度次数少了，上行功控收敛变慢，下行随路开销减少。

注意：非18.1SPC210版本不能开启UL_SMART_PREALLOC_QCI_SW开关，老版本执行会失败或不生效。大版本升级前先确认版本号，再规划这批参数，别在保障窗口里现场升级。

6. 调完之后的核对清单：验证DRX真实生效与快速回退

参数下发不等于生效，我调完一般按三步走验证。第一步，用查询命令拉出小区开关、QCI承载绑定、参数组定时器三张表，确认BASIC_DRX_SW为开、QCI1/2的DrxParamGroupId和DuDrxParamGroupId非255、定时器值与规划一致。第二步，在保障小区里抽测VoNR用户，看用户面调度间隔是否符合40ms长周期；有跟踪条件的话抓一个完整通话的PDCCH机会分布，确认休眠窗口内有唤醒监听，没有漏调度。第三步，观察72小时的掉话率、上下行丢包率和RTP时延，对比开启前基线，波动在10%以内算正常，超过就要回头查黑名单和CA配置。

// 回退顺序：先解绑，再关开关，最后删参数组 MOD NRDUCELLQCIBEARER: NrDuCellId=0, Qci=1, DuDrxParamGroupId=255; MOD NRCELLQCIBEARER: NrCellId=0, Qci=1, DrxParamGroupId=255; MOD NRDUCELLUEPWRSAVING: NrDuCellId=0, NrDuCellDrxAlgoSwitch=BASIC_DRX_SW-0;

回退要按“先解绑QCI、再关小区开关、最后删参数组”的顺序，顺序反了会出现参数组仍被引用但开关已关的中间态，下次重开时容易漏绑定。黑名单回退同理，先把GNBUECOMPAT的BlacklistCtrlSwitch改回关，再删GNBUEINFO的特征记录。从那以后我每次调完DRX和预调度，都强制走一遍这个核对流程，再补一次回退演练，这套规范文档我当成现场操作单用，不当参考书读。希望帮到你。

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