VoNR语音优化：DRX与智能预调度参数配置及排障实践

简介面向5G网络优化工程师的VoNR DRX与智能预调度参数规范说明V1.5系统梳理VoNR语音场景下非连续接收机制的关键参数配置与节能优化思路并结合预调度开关协同降低呼叫建立时延。压缩包内为1个pptx演示文稿大小1.46MB已有335人学习下载。内容涵盖语音BWP的DCI切换及BWP2关闭门限、长DRX周期、2.6G与700M频段下On Duration Timer和Inactivity Timer、Re-Transmission Timer等参数配置值并以MML命令示例演示如何为QCI1/QCI2绑定DRX参数组。同时给出DRX配置生效原则任一承载的参数组ID为255则该用户DRX不生效否则优先按QCI1专载参数组执行其次依据承载PriorityLevel最高者选定。另涉及DRX黑名单配置与关闭DRX的去绑定操作示例可帮助网优人员对照现网核查并处理个别终端不兼容问题同时说明智能预调度与DRX的协同关系在保障VoNR语音质量的同时改善终端省电效果。 对 VoNR 语音优化而言最难的不是把呼叫打通而是让通话全程的时延、丢包、终端功耗都保持在一个稳定区间。VoNR DRX和智能预调度开启参数规范说明V1.5.pptx 这类文档核心就是回答一件事怎么把 DRX 的省电节奏和智能预调度的资源下发节奏咬合在一起。DRX 负责让 UE 在语音通话中按周期醒来监听控制信道智能预调度负责把上行授权提前送到 UE 手上两者在参数上稍有错位语音质量就会直接从“平滑”变成“一顿一顿”。这篇笔记面向 5G 网优、VoNR 语音质量保障和无线参数配置工程师目标是把这份参数规范背后的机制拆开并给出一套可以直接落到网管上的配置方法和排障路径。2. VoNR 里的 DRX 到底在调什么唤醒周期与 20ms 语音包的相位对齐2.1 语音包在空口上的节奏20ms 规律与 VoNR 协议栈里的确定性VoNR 语音业务和普通数据业务有一个本质差异语音包的到达具有强周期性。AMR-WB、EVS 等主流语音编解码器的帧长都是 20ms也就是说主叫用户说话时编码器每 20ms 产出一个语音帧经过 RTP、UDP/IP 封装后进入 IMS 网络再经由 gNB 的 VoNR 协议栈——PDCP、RLC、MAC——映射到空口上。整个过程网络侧 MAC 调度器大约每 20ms 就会收到一个新的下行语音包同时期待 UE 在下一个 20ms 边界交回上行语音包。这种 20ms 刻度带来的确定性是 DRX 和智能预调度能够生效的前提。普通上网业务的流量是突发性的数据包到达 gNB 的时刻很难预测DRX 只能靠较长的监听窗口去罩住不确定的到达时刻预调度更是无从谈起。而语音业务不一样包间隔固定、包大小相对稳定、编解码速率可控调度器可以在时间轴上预先排布授权和唤醒窗口这就是 VoNR 场景里 DRX 参数可以和语音包到达节奏严格对齐的根本原因。但这里有一个容易忽略的细节静音期。VoNR 通话并不是全程都在传语音帧当用户停止说话时编码器进入静音抑制模式不再发送正常的 20ms 语音帧而是按约 160ms 的间隔发送 SID 帧用于对端生成舒适噪声。SID 帧比语音帧稀疏得多尺寸也更小。这意味着空口上的语音业务在时间轴上并不是绝对均匀的 20ms 节奏而是“活跃期密集、静音期稀疏”的双模形态。DRX 和预调度参数如果只按活跃期的 20ms 节奏设计到了静音期就可能出现唤醒窗口和 SID 帧到达相位错配的问题。后面避坑章节会专门展开这条现场经验。2.2 DRX 参数族拆解周期长度、onDurationTimer、InactivityTimer 的联动连接态 DRXC-DRX的 MAC 层配置由 RRC 信令下发相关参数在 3GPP 规范里有明确的定义VoNR 场景里最需要调的就是下面几个。drx-LongCycle 是 UE 以多长时间为周期醒来一次常见取值有 20ms、40ms、80ms、160ms 等。在语音活跃期长周期必须与 20ms 的语音帧间隔形成整数倍关系否则 UE 醒来的时刻和语音包到达的时刻会周期性错位。比如周期设为 30ms语音包每 20ms 到达一次两者的相位会不断漂移UE 会时不时漏掉一个包产生偶发性丢包。drx-onDurationTimer 代表 UE 每次醒来后保持监听 PDCCH 的时间长度。这个值决定了唤醒窗口能覆盖多大的调度不确定度。语音场景里常见配置是 6ms 到 10ms。如果设得太短比如 3ms那么下行语音包到达 gNB 后调度器可能还没来得及在 PDCCH 上分配资源UE 就已经停止监听了。如果设得太长比如 20ms 以上UE 几乎全程处于监听状态DRX 的省电效果就名存实亡。drx-InactivityTimer 是 UE 在收到一次初传调度后继续保持唤醒状态的时间。它的作用是把“刚收到数据后的短暂窗口”延长以应对紧随其后的重传或连续调度。语音场景里由于语音包是周期到达的InactivityTimer 通常设得较短常见 1ms 到 8ms。设成 0ms 的极端情况意味着 UE 收完一个子帧的数据后立刻可以进入睡眠这样最省电但如果有 HARQ 重传UE 需要在重传时刻醒来接收这时 InactivityTimer 太短反而会增加重传监听失败的概率。drx-SlotOffset 是从 DRX 周期起点到 UE 真正开始监听 PDCCH 之间的偏移量以 slot 为单位。这个参数是解决相位对齐问题的关键语音包到达 gNB 的时刻并不一定是 SFN 周期内的 slot 0而是在某个固定相位比如 slot 5。如果不设置 SlotOffsetUE 在 slot 0 就醒来监听等到语音包真正到达时on-duration 窗口已经过去一半白白浪费了监听资源。反之把 SlotOffset 设在语音包到达的前 1 到 2 个 slotUE 醒来的第一时间就能等到下行调度。drx-RetransmissionTimer 和 drx-HARQ-RTT-Timer 用于处理 HARQ 重传的监听窗口在 VoNR 语音场景里一般不是主要调节对象但需要在配置时确认它们的取值不会与长周期产生冲突。比如 HARQ RTT 定时器设得比语音帧间隔还长就可能出现 UE 已经睡着、重传包到达时无人监听的情况。2.3 长周期还是短周期VoNR 场景中为何常选 20ms/40ms工程上做 VoNR DRX 周期选择时最纠结的问题往往是长周期设 20ms 还是 40ms。这两个值对 VoNR 语音质量的影响差异很大需要看终端功耗收益和语音时延容忍度之间的平衡。如果长周期设 20msUE 每 20ms 醒来一次与语音包到达节奏完全同步。onDuration 即使只有 6ms也能覆盖绝大多数下行调度。这种配置下语音质量最稳时延抖动最小但 UE 在一个小时的 VoNR 通话里需要醒来约 18 万次基带处理功耗几乎没降下去终端发热和电池消耗都比较明显。如果长周期设 40msUE 每 40ms 才醒一次唤醒次数减半省电收益显著。但代价是下行语音包到达时UE 可能处于睡眠窗口内必须等下一个 DRX 周期的 on-duration 到来才能接收这会给语音包引入最多 20ms 的额外等待。对于 AMR-WB 这类编码速率较高的语音20ms 的额外时延会反映在端到端时延和抖动上MOS 分可能从 4.2 掉到 3.8 左右。如果是 EVS 的低速率档位对时延的容忍度相对好一些40ms 周期的风险相应降低。还有一种常见做法是长短周期组合活跃期用短周期静音期用长周期。但我在实际项目里较少在 VoNR 语音承载上启用短周期因为语音包在活跃期是连续到达的短周期和省电之间很难权衡而静音期本来就是以 160ms 为间隔的稀疏业务直接把长周期拉长让 UE 大段时间休眠即可。所以 VoNR 语音承载的配置实践基本就落在 20ms 和 40ms 两档真正的调节空间在于 SlotOffset 和预调度周期的联动下一章展开。3. 智能预调度补位DRX 睡眠期里谁把上行授权送到 UE 手上3.1 预调度的本质免 SR 过程的上行授权与终端功耗的天平VoNR 上行语音包的传输如果走标准流程UE 需要先发 SR 告诉基站“我有数据要发”gNB 收到 SR 后再分配上行授权通过 DCI 下发UE 最后才在授权资源上发送数据。这个流程在普通数据业务上没有问题但在语音通话中会带来两个明显的痛点一是 SR 要占用 PUCCH 资源大量终端并发语音时PUCCH 可能成为瓶颈二是 SR 到 UL Grant 的调度往返需要时间通常在 8ms 到 16ms而语音帧的间隔只有 20ms每一次上行语音包传输都要经历这么一轮调度交互端到端时延会明显拉高。预调度的思路就是打破这个过程既然语音包每 20ms 到达一次、包大小基本恒定gNB 完全可以在语音包还没有到达 UE 缓冲区之前就提前下发出一个上行授权。UE 收到授权后如果缓冲区里有数据就发送如果没有就忽略授权或发一个 padding。这样上行语音包无需等 SR 过程直接就可以在预分配的 PUSCH 资源上传输上行时延得以大幅压缩。这也是“预调度”这个名称的含义——把需要交互的授权流程前置到数据真正到达之前。但预调度在 DRX 开启的背景下有一个天然矛盾UE 只有在 DRX 的 on-duration 窗口内才会监听 PDCCH而预调度授权必须通过 PDCCH 下发。如果授权下发的时刻落在 UE 的睡眠窗口里UE 根本不会接收到这个授权预调度就完全失效。所以DRX 和预调度不能当作两个独立的功能分别配置它们必须在一个时间轴上对齐。开启 DRX 后必须要重新审视预调度周期、预调度授权下发时刻与 on-duration 窗口的配合关系。3.2 智能预调度比固定预调度聪明在哪固定预调度的实现方式比较简单gNB 按一个固定周期比如 20ms持续给 UE 分配上行授权不管 UE 当前有没有数据要发。这种方式的优点是时延低、实现简单但缺点也很明显语音静音期里UE 本来没有上行语音包固定预调度仍然持续下发授权PDCCH 和 PUSCH 资源被无谓占用而且如果只按固定周期调度不知道 UE 缓冲区里到底有多少数据下发的授权大小经常与实际净荷不匹配——授权给大了浪费资源给小了 UE 还是得靠 SR 补充。智能预调度在固定预调度的基础上增加了一层业务感知能力。它会结合 UE 的历史调度记录、上行缓存状态上报、DRX 唤醒相位、语音编解码速率以及当前小区资源负荷动态决定下一次预调度授权何时下发、下发多大。在语音活跃期智能预调度维持 20ms 的节奏和紧凑的授权大小当检测到 UE 进入静音期后自动把预调度间隔拉长到 160ms 甚至更长与 SID 帧的到达节奏匹配如果 UE 连续多个周期没有利用预调度授权调度器会进一步降低预调度频率把省下来的资源让给其他用户。参数层面智能预调度需要关注的配置项一般包括预调度总开关、上行/下行预调度的独立开关、预调度周期、授权大小或资源块上限、最小 MCS 门限、静音期调度间隔等。其中最核心的是预调度周期和 DRX 周期的配合关系。我在实践中常用的准则是预调度周期不应短于 DRX 长周期也不应超过语音帧间隔的整数倍更具体的取值要看 UE 的 DRX 唤醒相位落在哪里下一小节细讲。3.3 DRX on-duration 与预调度授权的时间窗对齐这句话在参数规范里往往只写“需要对齐”但实际做起对齐来很多工程师会栽跟头。假设 DRX 长周期配置为 40msonDurationTimer 为 6msSlotOffset 为 2 个 slot那么 UE 的监听窗口就是每个 40ms 周期内从 slot 2 到 slot 8 这一段。如果预调度周期也设为 40ms但授权下发时刻落在 slot 20那 UE 还在睡眠状态这个授权就相当于发给了空气。正确做法是先把 DRX 的时间轴画出来再把预调度周期和授权下发时刻往这个时间轴上投影。具体来说建议先通过空口信令跟踪或调度日志观察语音包实际到达 gNB 的相位。比如在小区级统计里能看到上行语音包集中在 SFN 的某个 slot 附近到达这时把 DRX 的 SlotOffset 设置在这个相位之前的 1 到 2 个 slot确保 UE 醒来时语音包刚好到。然后再把预调度授权下发的时刻设计在 on-duration 窗口的前半段让 UE 醒来的第一时间就能收到后续若干个语音帧的上行授权。另一种工程上常见的做法是让预调度周期小于 DRX 周期比如 DRX 40ms、预调度 20ms这样在一个 DRX 周期内会有两个预调度授权时刻。此时第二个授权如果落在 on-duration 之外UE 就收不到需要 UE 具备跨周期监听或授权缓存能力。如果终端平台不支持这种能力参数规范里就必须明确规定“预调度授权只允许在 on-duration 窗口内下发”否则就会出现授权发了、UE 没感知、上行包堆积的隐性丢包。这个坑我在现网里踩过不止一次后面避坑章节会单独讲。4. 开启参数落地最小改动打开 DRX 与智能预调度的配置步骤4.1 开启前先确认三件事UE 能力、QoS 流映射和生效范围很多工程师拿参数规范直接照抄结果大批终端不生效回头查才发现是前置条件没满足。VoNR 场景里DRX 和智能预调度都不是小区级通用开关而是按 UE 或按承载生效的配置。动手改参数之前有三件事必须先确认。第一是 UE 能力。打开 C-DRX 前必须确认终端是否在能力上报中包含 DRX 相关能力位。绝大多数 VoNR 商用终端默认支持但个别低端终端在语音呼叫过程中可能不支持 C-DRX或者只支持 20ms、40ms 等特定周期长度。如果终端不支持网络侧下发带 DRX-Config 的 RRC 重配置后UE 可能回复 RRCReconfigurationFailure触发回退流程语音质量反而受损。第二是 VoNR 承载映射。VoNR 语音走 5QI1 的 QoS flow通常映射到专用 DRB。DRX 配置在 RRC 连接级下发但智能预调度可能会按承载或按 QoS flow 的优先级来区分调度策略。如果参数配置对象选错了承载比如配到了默认承载而不是语音 DRB 上那预调度就不会对语音包生效。第三是生效范围。DRX 配置在连接态由 RRC 层控制切换时随 RRC 重配置消息重新下发所以它的作用域是“每个 RRC 连接”。智能预调度由 MAC 调度器执行可能是小区级开关叠加承载级策略作用域要复杂得多。确认清楚这两个层级后面排障时才能快速定位问题是在无线侧还是配置侧。4.2 推荐参数表DRX 周期、唤醒窗口、非激活计时器与预调度周期在不考虑特殊场景的前提下我通常按下面的表做基础配置然后按现场实测结果微调。参数值基于 3GPP 的常见取值集合和工程经验不同设备厂商网管上的参数名可能有差异但含义是一致的。配置对象参数项推荐值设置理由DRX长周期20ms 或 40ms与语音帧间隔整数倍吻合20ms 时延更稳40ms 功耗收益更高DRXonDurationTimer6ms ~ 10ms覆盖至少半个语音帧周期避免唤醒即漏包DRXInactivityTimer0ms ~ 8ms语音包接完立即休眠不宜超过语音帧间隔DRXSlotOffset按实际相位 1~4 slot通过调度日志确定语音包到达相位后设置DRXShortCycle不启用或与长周期一致语音业务没有数据突发间隙短周期意义有限智能预调度预调度周期等于 DRX 长周期保证授权落在唤醒窗口内不短于 DRX 周期智能预调度授权大小按编解码速率估算EVS 23.85kbps 约 100~120 字节AMR-WB 12.65kbps 约 60~80 字节智能预调度静音期调度间隔160ms 或 200ms匹配 SID 帧到达节奏避免资源浪费智能预调度最小 MCS按覆盖调整弱覆盖时防止授权过大但 MCS 过低导致效率下降这套组合的默认意图是让 UE 在语音活跃期以 20ms 或 40ms 的节奏唤醒每次唤醒只监听 6ms 到 10ms 的 PDCCH然后迅速睡回去同时 gNB 在唤醒窗口内预下发上行授权UE 醒着的时候就能收到授权不需要额外走 SR。这样既能保证上下行语音包的低时延传输又能把 UE 在语音通话中的功耗压下来。需要特别提醒的是上表中的 SlotOffset 不是一个可以拍脑袋定的值。我见过不少人把它设为 0 就上线结果语音包到达时刻在 slot 5UE 从 slot 0 开始监听等到语音包真正到达时on-duration 窗口已经烧掉一多半。正确做法是先抓一段空口日志统计语音包到达 gNB 的 slot 分布再把 SlotOffset 设到峰值到达 slot 的前 1 到 2 个 slot。4.3 分场景调整密集城区、高速移动与边缘弱覆盖同一套参数不可能走天下。现场开参数时我一般会按三类典型场景做差异化调整。密集城区场景的特点是用户密度高、基站负荷大、终端移动速度不快。此时语音质量优先建议 DRX 长周期设 20msonDuration 设 8msInactivityTimer 设 4ms 左右。预调度周期保持 20ms但要注意 PDCCH 负荷如果小区内 VoNR 用户数很多所有用户的预调度授权叠加起来会占大量 PDCCH 空间。这种情况下可以适当把预调度周期拉到 40ms并通过智能预调度在静音期自动降频来缓解负荷。高速移动场景的特点是频繁切换、多普勒频偏大。此时 DRX 周期不宜太长否则切换后新小区的语音包到达相位还没对齐旧 DRX 配置又让 UE 大部分时间在睡觉容易造成切换后语音中断。建议长周期设 20msonDuration 设 10ms并将 SlotOffset 调整到切换目标小区语音包到达的相位上。预调度周期维持 20ms但授权大小需要适当放宽因为高速场景下 MCS 可能被外环调整实际净荷大小波动比低速场景大。边缘弱覆盖场景的特点是 UE 接收信号差、PDCCH 解码成功率低。这时 onDuration 需要适当延长比如 10ms 以上给 UE 更多解码机会DRX 周期可以放到 40ms 甚至 80ms因为弱覆盖环境下终端发射功率本来就高省电收益对 UE 热耗散的影响更明显。但要注意周期越长语音包等待的时间越长如果 RTP 时延指标恶化需要先把周期收回 20ms 再排查其他因素。弱覆盖下的智能预调度重点在于 MCS 下限如果预调度授权总是按满 MCS 下发UE 解码失败后重传概率大增反而恶化上行质量。5. 开启 VoNR DRX 与智能预调度避坑五个翻车现场与排查路径5.1 开了 DRX 之后 MOS 不升反降周期相位没对上现象在某个 VoNR 小区开启 C-DRX 后语音 MOS 分不升反降下行丢包率从 0.2% 上升到 1.5% 左右用户反馈通话中出现“咯噔”一下的短暂中断。原因DRX 长周期虽然设成了 20ms但语音包到达 gNB 的相位和 DRX 的唤醒相位没有对齐。具体查下来DRX 的 SlotOffset 设为 0而该小区上下行语音包周期性到达 gNB 的时刻集中在 slot 6 附近。UE 从 slot 0 开始监听等到 slot 6 语音包到达时onDuration 的监听窗口已经快结束了调度器来不及在 PDCCH 上完成资源分配UE 就睡过去了这个包只能等下一个周期形成偶发性的半个周期额外时延。解决抓取空口日志统计语音包到达 gNB 的 slot 分布把 SlotOffset 调整到峰值到达 slot 前 1 个 slot 的位置。调整后下行丢包率恢复到 0.3% 以内MOS 回升 0.3 左右。这次之后我再也没有建议过把 SlotOffset 直接留 0 的做法。5.2 预调度授权白白下发UE 在睡眠窗口没收到现象小区开启智能预调度后从基站侧统计看 PDCCH 授权次数明显增加但上行 PUSCH 利用率没有同步上升VoNR 上行丢包率反而升高。进一步查看 UE 侧调度记录发现大量预调度授权 UE 根本没有接收到。原因预调度周期和 DRX 周期设成了不同节奏。该站点 DRX 长周期为 40ms唤醒窗口在 slot 2 到 slot 8但智能预调度周期被配成 20ms其中第二个授权下发时刻落在 slot 20 附近正好处于 UE 的睡眠窗口内。UE 没有跨周期监听或授权缓存功能因此第二个预调度授权永远收不到。更糟的是调度器以为授权已经下发就把这个 UE 的调度优先级降了下来导致真正需要资源时反而没有及时授权。解决把预调度周期改为与 DRX 长周期一致并限制授权只能在下发窗口内产生。具体操作是在智能预调度参数里增加“授权窗口限制”这一类约束或者直接把预调度周期从 20ms 改成 40ms让两个周期形成对偶关系。这之后上行丢包率恢复正常。5.3 切换后语音“打嗝”目标小区 DRX 配置不一致现象VoNR 用户在两个小区间切换后语音质量出现周期性“打嗝”每次持续约 20ms切换完成后的前几秒尤为明显。从话统看切换后的上行丢包率明显高于切换前。原因源小区和目标小区的 DRX 参数配置不一致。源小区长周期是 20ms、SlotOffset 为 2目标小区长周期是 40ms、SlotOffset 为 0。切换后目标小区通过 RRC 重配置下发新的 DRX 参数UE 按新参数醒来但此时上行语音包的到达相位还是延续源小区的节奏两者需要重新经历一个对齐过程。在这个过程中部分上行语音包到达 UE 缓冲区时UE 刚好处于睡眠窗口包只能在缓冲区等下一个唤醒周期形成 20ms 到 40ms 的额外时延听起来就像打嗝。解决在做 VoNR 连续覆盖优化时将同一条连续覆盖带上的邻区 DRX 参数统一。参数一致性检查要纳入切换一致性核查包括长周期、onDuration、SlotOffset 三项。如果条件允许还可以在切换重配置消息中携带目标小区的 DRX 配置让 UE 在切换完成前就按新参数建立唤醒节奏。5.4 静音期 SID 帧丢失通话出现空洞感现象VoNR 通话中用户不说话时对端仍能听到规律的“沙沙”声中断表现为舒适噪声时断时续。上行 SID 帧丢包率统计显示静音期出现周期性丢失。原因DRX 长周期设为 20ms智能预调度在静音期把预调度间隔放宽到了 200ms但 SID 帧的到达间隔约为 160ms。由于 SID 帧实际到达时刻和 DRX 唤醒窗口的相位偏移没有重新对齐部分 SID 帧到达时UE 正处于长睡眠中无法立即上报上行数据预调度授权又不在这个时刻下发SID 帧只能等下一个唤醒窗口等到的时候已经超出了 RTP 的播放时延容忍范围被接收端丢弃。解决把静音期的智能预调度间隔调整为 SID 帧间隔的整数倍并设置一个独立的 SlotOffset 对齐 SID 帧到达相位。更稳妥的做法是在 DRX 配置里同时启用一个较短的静音期唤醒周期或者在智能预调度策略里增加“SID 预测”功能根据上一帧 SID 到达时间推算下一帧相位。调整后 SID 丢包率归零。5.5 批量配置版本错位参数名全对但网元不认现象在一次 VoNR 参数批量下发中脚本执行结果显示部分小区成功、部分小区失败失败原因提示“参数校验错误”。工程师核对参数名发现和规范文档完全一致。原因设备厂商不同版本之间的参数命名或取值单位有差异。比如同一参数在旧版本里叫“drx_long_cycle”新版本里叫“drxLongCycle”单位从 ms 改成了 slot或者某版本不支持短周期但批量脚本里仍然带上了短周期字段网元在校验阶段直接拒绝。这类问题最隐蔽因为失败提示不一定能指出具体是哪个字段。解决批量下发前先做参数版本兼容性检查。建议做法是在实验网元上先执行一遍单小区参数修改抓取返回信息确认所有字段都被接受再批量执行。规范文档里的参数表要标注适用版本升级后重新核对一次。这次之后我养成了一个习惯任何批量参数变更都要先在一个“不重要的”小区上试跑一遍确认无误后才放量。6. 开启后的验证与调优三个指标确认参数真的吃进去了参数改完之后第一件事不是看 MOS而是验证配置是否真的生效。三个指标最直观上下行 RTP 丢包率、RTP 时延与抖动、DRX 休眠占比。RTP 丢包率从网管话统或核心网侧抓包都能拿到。开启 DRX 和智能预调度后如果配置正确上下行丢包率应该保持开启前的水平或略有下降。如果丢包率上升优先检查 SlotOffset 和预调度授权窗口的对齐情况。RTP 时延和抖动则要看 PDD 和 Jitter 统计正常情况下 20ms 周期的配置下端到端时延不应出现周期性的 20ms 或 40ms 跳变。DRX 休眠占比可以从无线侧话统里看到 UE 处于休眠状态的时间比例这个值能直接反映省电效果——如果休眠占比很低说明 DRX 没有真正让 UE 睡下去需要检查 InactivityTimer 是不是设得过长了。我自己的调优习惯是先保存一份基线话统再逐参数调整一次只动一个参数。比如先调 DRX 长周期跑 10 分钟 VoNR 语音业务看指标稳定后再调 SlotOffset再跑一轮最后才动智能预调度。每次调整后抓一份空口信令解析 RRC 重配置消息里的 drx-Config 字段确认 UE 实际收到的参数和网管配置一致。这一步很关键能排除网管上参数改了但没下发、或者下发被 UE 拒绝等黑匣子问题。参数规范只是起点真正可靠的规范是你自己记录下来、验证通过的那一组。希望这份拆解能帮到你。本文还有配套的精品资源点击获取