做 NB-IoT/LTE-M 终端功耗优化绕不开一个概念hyperframe。中文常叫“超帧”协议里更精确的写法是 Hyper SFNH-SFN。我第一次真正搞懂它是在给一款智能燃气表调 eDRX 参数的时候。当时按模组 AT 指令手册把扩展寻呼周期填到了“最大档”实测电流却还是十几毫安折腾两天才发现问题根本不在指令填法而是网络侧压根没有把 hyperframe 这套时间刻度广播给终端。这篇文章把我后来踩过的坑、推导过程和现场排障经验一起整理出来。它适合两类人一类是正在写 NB-IoT/eMTC 模组代码、做终端整机功耗设计的嵌入式工程师另一类是负责接入网参数、物联网平台对接的网络工程师。理解了 hyperframe/H-SFN你才算真正看懂了 eDRX 为什么能把设备休眠时间从“秒”拉到“小时”。1. 为什么 IoT 设备不能用手机那套寻呼节奏1.1 手机能撑一天IoT 要撑十年寻呼是谁在敲设备在 LTE/NB-IoT 网络里基站想给一个空闲态的设备发下行数据不可能直接“打过去”因为设备的射频早就关了。网络能做的是在一个固定时刻、固定无线帧上广播一条寻呼消息Paging设备按约定时间醒来监听。这个机制叫 DRXDiscontinuous Reception非连续接收。手机时代为了平衡来电时延和功耗网络把寻呼周期配置成 0.32 秒、0.64 秒、1.28 秒、2.56 秒这几档。手机每 1.28 秒醒一次听起来不算频繁但每次醒来射频收发、基带处理的瞬间电流能到 30~50mA日均耗电就被拉上去了。手机无所谓反正天天充电。物联网设备完全是另一套账。一块 2400mAh 的锂亚电池装在燃气表里目标是 8~10 年不换电池。如果按 1.28 秒一次的寻呼节奏长期监听光这一项就能吃掉几百毫安时后续业务还怎么跑不能频繁监听就必须拉长“监听间隔”。可问题在于终端和网络必须在设备睡下去之前就约定好“下次在哪个时刻醒来”这个时刻的计算要精确到帧而帧编号就是 SFN。这里有个很关键的工程约束设备沉睡期间不可能一直保持和基站同步它醒来后必须能独立算出自己该在哪个无线帧听寻呼。这个算法必须简单到设备用本地晶振就能推进不能依赖任何实时网络状态。换句话说时间轴本身必须够长长到能覆盖设备最长的睡眠周期。1.2 10 比特 SFN 的天然边界10.24 秒一个轮回LTE/NB-IoT 的 System Frame Number系统帧号SFN在 MIB/SIB 里占用 10 个比特取值范围 0~1023。每个无线帧 10 毫秒所以 SFN 走完一圈需要 1024×10ms 10.24 秒然后从 0 重新开始。10.24 秒这个周期对手机寻呼完全够用——2.56 秒的 DRX 周期怎么都落在 SFN 范围内。但对物联网设备来说10.24 秒太短了。假设我想让设备每 40 分钟醒来听一次寻呼也就是 2400 秒一次这时 SFN 已经转了两百多圈。设备醒来后怎么知道“这是第几圈的第几帧”只靠 10 比特 SFN根本无法表达“圈数”。这就像一块只有秒针的钟秒针转了几百圈你根本分不清现在是哪一分钟。1.3 秒级觉醒 vs 小时级睡眠的矛盾于是问题变成了需要一个更大的时间坐标系让终端和网络在设备长睡之前就约定好“下一个 SFN 周期里的哪个帧”去监听。这就是引入 hyperframe 的直接动机。我见过不少同行第一次接触 eDRX 时把注意力全放在参数表上却忽略了背后的计数问题。其实只要你理解了“SFN 只管一圈之内、hyperframe 管圈数”后面所有公式都是顺势推出来的。时间轴的扩展不是另起炉灶而是在原有 SFN 之上加一层更高位的计数底层 10ms 无线帧结构、帧级调度算法统统不用动。2. Hyperframe 到底是什么H-SFN 的设计思路2.1 H-SFN给时间轴再加一个“高位进位”把 SFN 想象成秒表上的“秒位”它每 10.24 秒归零一次。H-SFN 就是秒表上新增的“分位”每当时间走过一个完整的 SFN 周期H-SFN 就加 1。H-SFN 同样是 10 个比特取值范围 0~1023于是1 个 H-SFN 步进 1 个 SFN 周期 10.24 秒H-SFN 完整周期 1024 × 10.24 秒 10485.76 秒 ≈ 2.91 小时。两个 10 比特合在一起就是一套 20 比特的时间戳既能精确到 10 毫秒的无线帧又能表达最长约 2.91 小时的绝对时间。这个“秒位 分位”的设计妙在不动底层帧号还是 10 比特所有现存的帧级算法原封不动只是在更高层叠了一个超帧坐标。对网络和终端来说它们讨论“第几个超帧的第几个 SFN 周期里的第几帧”就像讨论“第几小时第几分钟第几秒”一样自然。顺带说一句5G NR 也保留了同样的思路。TS 38.304 里对 eDRX、H-SFN 的定义和 LTE 一脉相承RedCap 这类中低速物联网终端将来同样靠这套时间刻度做深度休眠。今天在 NB-IoT/LTE-M 上学到的知识切到 5G 物联网场景依然有效。2.2 H-SFN 从哪里来SIB1-NB 里的 4 个比特终端怎么知道当前 H-SFN 是多少网络侧不会像广播 SFN 那样每帧都广播完整 10 比特 H-SFN——开销太大。实际做法是LTE-M 的 SIB1 或 NB-IoT 的 SIB1-NB 里携带 H-SFN 的低 4 个比特协议字段叫 hyperSFN-LSB。终端在开机、小区重选、每次从长睡中醒来时读取这 4 个比特配合自己在本地维护的高 6 位计数还原出完整 H-SFN。这有点像野外作业的电台对时平时靠本地晶振自己数圈等到了约定时刻醒来读一次 SIB1把表和对方校准一下。由于 H-SFN 低 4 位就覆盖 16 个超帧也就是 163.84 秒的范围终端只要不是失步超过这个时间就能借助本地计数把高 6 位补出来。我在实际日志里观察过设备在 eDRX 周期结束前不久被应用层唤醒先读一次 SIB1-NB 完成 H-SFN 校准再进入 PTW 监听整个流程非常干净。2.3 为什么 NB-IoT 最大 eDRX 周期刚好是 10485.76 秒这是个很多人问过我的问题为什么 NB-IoT 的 eDRX 周期最大只到 10485.76 秒答案就在 H-SFN 的位数上。eDRX 的定位是让终端在两次寻呼之间深度睡眠这个周期必须能用一个完整的 H-SFN 周期表达超过 2.91 小时10 比特 H-SFN 就不够编号了。如果你需要更长时间不联网那就不归 eDRX 管得用 PSMPower Saving Mode让设备在更长时间内完全不可达。这两类省电机制的本质区别我在第 5 节会专门对比。另外要注意LTE-M 的 eDRX 最大值是 2621.44 秒而 NB-IoT 能到 10485.76 秒。这是因为 NB-IoT 的信道带宽更窄、调度更慢允许更长的寻呼周期来换功耗。选平台的时候如果下行时延容忍度很高NB-IoT 的长 eDRX 是一个不小的优势。3. 核心计算与参数实操eDRX 周期、寻呼超帧与功耗估算3.1 eDRX 周期在超帧坐标系里的换算eDRX 周期T_eDRX不能任意设定只能从 3GPP 规定的离散值里选。NB-IoT 从 5.12 秒一直到 10485.76 秒LTE-M 最大到 2621.44 秒。计算寻呼超帧时要把 T_eDRX 换算成“以超帧为单位”的周期T_eDRX_H T_eDRX / 10.24几个常用档位我整理成了表T_eDRX秒T_eDRX_H超帧数典型业务20.482路灯控制、对实时性要求较高的传感327.6832智能烟感分钟级告警可接受2621.44256资产追踪小时级心跳10485.761024极低频抄表/环境监测上报3.2 寻呼超帧 PH 的计算公式与实例eDRX 的核心计算是“寻呼超帧”Paging HyperframePH的确定。协议公式是H-SFN mod T_eDRX_H UE_ID mod T_eDRX_H其中 UE_ID 由设备的 IMSI 取模而来具体算法在 3GPP TS 36.304 里定义。这个公式的作用是把设备 ID 散列到超帧时间轴上的某个相位让不同设备“错峰”醒来避免所有终端挤在同一个超帧被寻呼把寻呼信道打爆。举一个真实项目里的计算。某 NB-IoT 终端按 IMSI 算出 UE_ID 500业务希望大约 43.69 分钟听一次寻呼选择 T_eDRX 2621.44 秒即 T_eDRX_H 256。那么H-SFN mod 256 500 mod 256 244。终端就在所有满足“H-SFN mod 256 244”的超帧里醒来检查寻呼也就是每 256 个超帧约 43.69 分钟一次。如果某台设备 UE_ID 恰好小于 256等号右边就是 UE_ID 本身相位更“整”计算也更直观。我建议刚上手的团队把 UE_ID 计算脚本化不要人工口算因为批量出货时每块卡 IMSI 不同算错一个相位设备就会在网络认为“它应该醒着”的时候睡着表现就是“偶尔收不到下行重启又好了”。这类问题最难排查因为不是每次都复现。3.3 PTW 起点与长度设备真正“醒来”的窗口确定了 PH 还不够。终端在 PH 对应的那个超帧里如果整个 10.24 秒都保持清醒那和没省电差不多。所以协议又定义了“寻呼时间窗口”Paging Time WindowPTW只有在这个窗口内终端才按普通 DRX 节奏去监听寻呼窗口之外继续睡。PTW 的起点在协议里对齐到 PH 内满足“SFN mod 256 0”的无线帧也就是 2.56 秒的整数倍位置。PTW 长度由网络通过系统消息下发是可配置的现场常见配置是 2.56 秒、5.12 秒、10.24 秒这几档。窗口越长错过寻呼的概率越低但平均电流越高。我在项目里通常建议从 5.12 秒调起先跑一段业务观察时延和电流再决定要不要缩短。在 PTW 内部终端用的是传统 DRX 那套寻呼时机算法也就是按照 SIB2 下发的默认寻呼周期去监听 P-RNTI。所以 PTW 长度本质上决定了“这个超帧里监听多少次”PTW 越长唤醒次数越多但每次唤醒都很短不会出现持续高电流。这也是 eDRX 能做到小时级周期而平均电流仍然很低的原因。3.4 一版可直接套用的功耗估算模型我自己习惯用最简单的“三段式”估算睡眠电流、PTW 内监听电流、每次监听持续时间。假设深度睡眠电流 I_sleep 3μA每次寻呼监听含射频和基带平均 20mA持续 200msPTW 10.24 秒内部按普通 DRX 周期 1.28 秒一次寻呼一个 PTW 内监听 8 次合计 1.6 秒eDRX 周期 T_eDRX 2621.44 秒。一个周期的耗电睡眠部分0.003mA ×2621.44 - 1.6s ≈ 7.86 mA·s监听部分20mA × 1.6s 32 mA·s合计约 39.86 mA·s平均电流 ≈ 15.2μA。2400mAh 的电池仅看寻呼部分理论寿命约 2400 / 0.0152 ≈ 15.8 万小时超过 18 年。当然这是理想值还没算周期性 TAU、业务上报、RRC 重激活、SIB 重读以及电池自放电。你把这套模型抄进 Excel把 PTW、DRX 周期、峰值电流换成自己实测的数很快就能判断功耗瓶颈到底在监听、上报还是网络行为上。4. 落地配置NB-IoT 模组 AT 指令与网络侧验证4.1 NB-IoT 模组 eDRX 配置ATCEDRXS 指令详解理论讲完落到模组上。以主流 NB-IoT 模组移远 BC95/BC35、中移 M5311 等为例eDRX 通过 AT 指令开启ATCEDRXS1,4,1011第一个参数 1启用 eDRX第二个参数 4请求模式 4含义是“使用终端上报的 eDRX 周期值”第三个参数 1011eDRX 周期的四比特编码对应 NB-IoT 的 10485.76 秒。四比特编码和周期的对应关系是按协议表来的NB-IoT 常用档位摘录如下位串T_eDRX秒001020.480101163.840110327.6810012621.44101110485.76如果只需要开启 eDRX、周期完全交给网络决定可以只填前两个参数。查询当前配置和网络协商结果用 ATCEDRXP?返回里会同时给出请求值和网络实际下发的值。注意网络不一定会全盘接受请求所以上线后一定要看 CEDRXP? 的返回值而不是只相信自己填了多少。4.2 PSM 定时器配置的注意点如果需要比 2.91 小时更长的休眠要用 PSM。典型指令是ATCPSMS1,,,T3412,T3324其中 T3412 是周期 TAU 定时器T3324 是 RRC 释放后的 Active Time。两者都是 3GPP 的定时器位串编码不是十进制秒数填错要么被网络拒绝要么休眠时长完全不符合预期。我强烈建议用模组厂商提供的定时器换算工具或 AT 手册里的对照表不要凭印象拼位串。这里有个容易被忽略的坑T3324 设得过长设备在 RRC 释放后会长时间保持“可监听”状态电池电流一直压不下来设得过短网络还没来得及下发下行数据设备就睡着了。我对绝大多数“按需上报”场景的建议是T3324 先按 60~120 秒起步跑通业务再往下压。4.3 网络侧开关与签约数据检查模组只是提出请求真正决定 eDRX 能不能生效的是网络。基站侧要在系统消息里正确广播 eDRX 参数MME 侧要在 Attach/TAU Accept 里把 eDRX 周期“回放”给终端。很多物联网卡默认签约模板没有开启 eDRX 相关能力终端就算发了请求MME 也会静默忽略结果回落成普通 DRX。所以排查顺序应该是先查卡和签约再查核心网日志里 Attach 是否携带 eDRX 参数最后才怀疑模组配置。我遇到不止一次“模组设了 eDRX 没用”最后发现是测试卡走的旧签约模板压根没开 eDRX 能力。尤其是跨运营商测试时同一张卡在不同网络下的行为可能完全不同千万不能用一套配置套所有网络。4.4 用日志验证 H-SFN 对齐的实操方法这台设备到底有没有在正确的超帧醒来最可靠的办法是抓模组日志。NB-IoT 模组一般支持打开 trace 口输出协议日志你能看到终端在什么时刻读取了 SIB1-NB、读到 hyperSFN-LSB 的值以及在哪个 PH 进入了 PTW。把日志时间戳和理论计算的 PH 对照可以非常直观地确认对齐关系。没有专用抓包工具也有土办法在模组供电引脚串一个电流采样电阻用示波器或记录仪抓电流波形。eDRX 生效时你会看到周期性的电流“突起”突起间隔应该严格等于配置的 T_eDRX如果间隔变成几秒一次说明网络没有下发 eDRX设备回落普通 DRX 了。这个波形判断法我一直在用比看任何协议日志都直观。5. 现场排查经验eDRX/Hyperframe 最常见的坑5.1 常见问题速查表现象可能原因处理建议配置了 10485.76s实测电流仍高网络未回放 eDRX回落普通 DRX查 CEDRXP? 返回值配合签约和 MME 日志设备多日离线服务器无法唤醒PTW 太短错过寻呼或 TAU 周期到期后 eDRX 被重新协商适当加长 PTW核对 T3412 与业务的匹配唤醒时刻飘移和理论 PH 对不上本地晶振漂移导致 H-SFN 计数偏差加提前量醒来先读 SIB1-NB 校准跨小区重选后休眠异常新小区 eDRX 配置不同或未广播检测小区变更重新同步 H-SFN设备“叫不醒”误解为 eDRX实际设备进了 PSM 不可达态确认业务是否允许延迟否则改用 eDRXT3324 设长后电流居高不下设备长时间处于可监听态压缩 Active Time按需配置5.2 现场排查思路与工具推荐我的排查三板斧先 ATCEDRXP? 和 ATCPSMS? 看协商结果再抓电流波形看实际唤醒周期这是最不会骗人的指标最后看协议日志确认 H-SFN 和 PTW 的实际对齐。工具方面电流曲线用 Joulescope、Nordic PPK 这类高精度功耗分析仪最好没有的话串联一个精度还行的采样电阻加示波器也够用采样率要足够快到能看清 200ms 级别的电流脉冲。另外现场的网络参数可能随时被运维调整。我一般会在交付文档里写清楚“设备请求的 eDRX 值、网络必须回放的值、PTW 长度、T3412/T3324 期望值”让现场同事照着核对。这个习惯救过我很多次因为设备端往往没有改动但网络侧一次参数变更就能让整批终端的功耗回到解放前。5.3 eDRX 与 PSM 选型建议别把两个机制混着用最后给个选型建议。eDRX 适合“下行可达时延有要求、但可以容忍秒级到小时级延迟”的业务PSM 适合纯粹上行上报、下行基本不找它的业务。两者可以同时配置但要想清楚优先级。我的做法是下行要“尽量快”用短 eDRX 周期比如 20.48~327.68 秒下行可以等几分钟到几小时用长 eDRX比如 2621.44 秒以上完全不需要下行主动推送上 PSM把 T3412 拉到业务允许的最大值。还要提醒一点eDRX 周期越长下行数据从服务器发出到设备收到的最长等待就越久这个时延上限直接影响应用层协议设计。比如服务器端如果 5 秒收不到设备响应就判定离线那把 eDRX 配成 2621.44 秒就必然误报。时延预算和功耗预算必须一起算不能只盯着电流。我在实际项目里最大的体会是hyperframe 不是那种“知道概念就行”的协议知识点它是实打实决定电池寿命的计算基础。第一次把某款表计的平均工作电流从 40μA 压到 15μA就是靠把 eDRX 周期从 327.68 秒顶到 10485.76 秒同时把 PTW 从 10.24 秒压到 5.12 秒。整个过程所有调整都围绕同一件事——让设备在正确的超帧醒来其余时间彻底闭嘴。最后再分享一个小技巧改完参数不要立刻统计平均电流先放一个完整的 eDRX 周期最长可能 2.91 小时再取数否则会被启动阶段和首次注册的波动带偏。摸清这套节奏之后你再看 eDRX 和 H-SFN就不会觉得它们是什么抽象名词了。