企业官网建设流程全解析

做 NB-IoT/LTE-M 终端功耗优化，绕不开一个概念：hyperframe。中文常叫“超帧”，协议里更精确的写法是 Hyper SFN（H-SFN）。我第一次真正搞懂它，是在给一款智能燃气表调 eDRX 参数的时候。当时按模组 AT 指令手册把扩展寻呼周期填到了“最大档”，实测电流却还是十几毫安，折腾两天才发现问题根本不在指令填法，而是网络侧压根没有把 hyperframe 这套时间刻度广播给终端。这篇文章把我后来踩过的坑、推导过程和现场排障经验一起整理出来。它适合两类人：一类是正在写 NB-IoT/eMTC 模组代码、做终端整机功耗设计的嵌入式工程师；另一类是负责接入网参数、物联网平台对接的网络工程师。理解了 hyperframe/H-SFN，你才算真正看懂了 eDRX 为什么能把设备休眠时间从“秒”拉到“小时”。

1. 为什么 IoT 设备不能用手机那套寻呼节奏

1.1 手机能撑一天，IoT 要撑十年：寻呼是谁在敲设备

在 LTE/NB-IoT 网络里，基站想给一个空闲态的设备发下行数据，不可能直接“打过去”，因为设备的射频早就关了。网络能做的，是在一个固定时刻、固定无线帧上广播一条寻呼消息（Paging），设备按约定时间醒来监听。这个机制叫 DRX（Discontinuous 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 管，得用 PSM（Power 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

几个常用档位我整理成了表：

3.2 寻呼超帧 PH 的计算公式与实例

eDRX 的核心计算是“寻呼超帧”（Paging Hyperframe，PH）的确定。协议公式是：

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 Window，PTW）：只有在这个窗口内，终端才按普通 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，持续 200ms；
• PTW = 10.24 秒，内部按普通 DRX 周期 1.28 秒一次寻呼，一个 PTW 内监听 8 次，合计 1.6 秒；
• eDRX 周期 T_eDRX = 2621.44 秒。

一个周期的耗电：

• 睡眠部分：0.003mA ×（2621.44 - 1.6）s ≈ 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 配置：AT+CEDRXS 指令详解

理论讲完，落到模组上。以主流 NB-IoT 模组（移远 BC95/BC35、中移 M5311 等）为例，eDRX 通过 AT 指令开启：

AT+CEDRXS=1,4,"1011"

• 第一个参数 1：启用 eDRX；
• 第二个参数 4：请求模式 4，含义是“使用终端上报的 eDRX 周期值”；
• 第三个参数 "1011"：eDRX 周期的四比特编码，对应 NB-IoT 的 10485.76 秒。

四比特编码和周期的对应关系是按协议表来的，NB-IoT 常用档位摘录如下：

如果只需要开启 eDRX、周期完全交给网络决定，可以只填前两个参数。查询当前配置和网络协商结果用 AT+CEDRXP?，返回里会同时给出请求值和网络实际下发的值。注意：网络不一定会全盘接受请求，所以上线后一定要看 CEDRXP? 的返回值，而不是只相信自己填了多少。

4.2 PSM 定时器配置的注意点

如果需要比 2.91 小时更长的休眠，要用 PSM。典型指令是：

AT+CPSMS=1,,,"<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 常见问题速查表

5.2 现场排查思路与工具推荐

我的排查三板斧：先 AT+CEDRXP? 和 AT+CPSMS? 看协商结果；再抓电流波形看实际唤醒周期，这是最不会骗人的指标；最后看协议日志确认 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，就不会觉得它们是什么抽象名词了。