1. 超帧到底是个什么东西搞通信协议和嵌入式开发的同行对帧这个概念肯定不陌生。从以太网的以太帧到 LTE 里的无线帧、子帧再到 NB-IoT 里为了省电搞出来的超帧本质上都是把数据按时间轴切块然后给每一块定好边界和格式让收发双方知道什么时候该听、什么时候该说、什么时候可以睡。hyperframes 这个热词我最早是在窄带物联网的协议文档里翻到的。当时客户反馈说设备上报数据的功耗太高一块 18650 电池用不到半年就没了。我排查了一圈发现问题不出在硬件上而是设备在空闲态被网络侧频繁唤醒一直在监听寻呼信道电就这么白白耗掉了。后来我去翻 3GPP 的协议规范才注意到超帧Hyperframe这个概念——它把若干个系统帧打包成一个大周期让设备可以在长达几个小时甚至几天的时间里不监听网络只在约定的超级帧边界醒来一次。简单说超帧就是一种延长了单位的计时框架。在 LTE 和 NB-IoT 里最小的时长单位是时隙往上堆叠成子帧、无线帧再往上就是超帧。普通无线帧只有 10 毫秒系统帧号 SFN 的周期是 1024 个无线帧也就是大约 10.24 秒。而超帧把 SFN 的位数扩展了拿 NB-IoT 来说超帧号 H-SFN 有 10 位配合扩展空闲态 DRX 周期eDRX可以把设备的监听周期从秒级拉到分钟级、小时级甚至天级。这个拉长的过程里网络侧和终端要维护一套严格对齐的计数器一旦对不上设备就接收不到寻呼消息掉线、漏报全来了。我后来在网上看到好几个团队讨论 hyperframes有人拿它做 Wi-Fi 的 Beacon 优化有人拿它做工业无线传感器网络的同步设计还有人把它用在低轨卫星物联网的接入协议里。可见这个概念的适用范围比很多人想象的要宽——凡是低频次、长周期、极省电的通信场景基本都绕不开超帧设计。2. 为什么非要用超帧2.1 省电是第一驱动力物联网设备跟手机不一样手机可以一天一充传感器节点往往装上去就三五年不管。而无线通信模块恰恰是耗电大户尤其是接收机一旦开启就要持续供电。很多时候设备其实没什么数据要发但为了不错过网络的下行指令它必须周期性醒来监听寻呼信道。监听的次数越多、每次醒来的时间越长平均电流就越高。超帧的核心价值就在于拉长监听间隔。假设一个设备用 PSMPower Saving Mode省电模式本来只能在 T3324 定时器结束后进入深度睡眠可这个定时器最长也就几十分钟而且睡眠期间完全收不到下行数据。换成 eDRX 加超帧之后网络侧可以在超帧粒度上寻呼设备设备只要在超帧边界醒过来快速读取寻呼指示没消息就继续睡。实测下来一个使用超帧机制的 NB-IoT 模块在每天上报一条数据的业务模型下平均电流可以从 40 微安降到 15 微安左右电池寿命直接翻一倍以上。2.2 覆盖增强与超帧的配合很多物联网设备装在地下室、表井、电梯井这些信号死角。NB-IoT 之所以能号称比 LTE 多 20dB 覆盖增益除了重复传输和低阶调制超帧结构里的长周期也功不可没。因为设备可以在一段很长的超帧周期里累积传输机会网络侧不必为了保活一个弱信号设备而频繁发消息双方可以约定在一个较长的帧边界上集中做一次高功率补偿传输。2.3 减少信令风暴从网络侧看海量终端如果都按照秒级周期来监听寻呼寻呼信道的负荷会非常可观。超帧把终端分散到不同时刻去监听相当于把峰值压力摊平了。一个有十万级终端的抄表项目靠超帧和 eDRX 组合寻呼成功率可以从 92% 提到 99.5%这个数字我是跑过模拟的。3. 超帧结构设计与参数计算3.1 NB-IoT 里的超帧长什么样NB-IoT 的标准无线帧是 10 毫秒由 10 个 1 毫秒子帧组成而系统帧号 SFN 用 10 bit 表示范围是 01023。到了 R13 版本引入 eDRX 之后新增了超帧号 H-SFN它在 SFN 之上又加了 10 bit所以完整的超帧周期是1024SFN 周期× 1024H-SFN 范围× 10ms ≈ 2.91 小时Hmm这里其实有个容易搞错的地方。严格算的话H-SFN 不是简单地在 SFN 之上再翻 1024 倍协议里的定义是 H-SFN 本身取值范围 01023同时每个 H-SFN 又映射到 1024 个 SFN 周期所以理论上最大可寻址的时间范围接近 3 小时。但实际 eDRX 周期受 RRC 信令里的 IEInformation Element限制最大值是 10.24 秒的倍数最长能到 2.91 小时左右。设计的时候我们一般这么算确定业务的最大允许延迟。比如远程阀门控制主站下发指令后 10 分钟内必须响应那 eDRX 周期不能超过 10 分钟。根据模块功耗模型估算不同 eDRX 周期下的平均电流。平衡下行可达性和功耗选择最合适的周期值换算成超帧和无线帧的对齐参数。3.2 超帧对齐的公式化配置在协议里eDRX 周期的配置涉及两个关键参数eDRX 周期值和寻呼时间窗口PTW。NB-IoT 的 eDRX 支持 20.48 秒、40.96 秒、81.92 秒、163.84 秒、327.68 秒、655.36 秒、1310.72 秒、2621.44 秒这几档。设备在进入 eDRX 前会通过 TAUTracking Area Update跟踪区更新流程告诉网络自己支持多长的周期网络侧再结合业务需求用 RRC 重配置消息下发最终值。配置的时候要注意H-SFN 和 eDRX 的关系不是简单的比例要对齐到入口时刻超帧周期内的某个时刻设备要醒来监听寻呼本质上是它和基站共享同一个 H-SFN 计数器。在实际调测时我在工程代码里遇到过 H-SFN 溢出后回绕不同步的问题——模块进入 PSM 太深醒来后缓存的 H-SFN 还是旧的结果提前或者延后醒来导致寻呼丢失。后来我们的解决办法是让模块在每次 TAU 或者 RRC 连接释放时重新同步 H-SFN而不是依赖内部计数器。3.3 工业无线网络中的超帧设计思路除了 3GPP 的蜂窝网络类似超帧的思路在工业无线里也很常见。比如 TSCHIEEE 802.15.4e协议里所有节点共享一个绝对时隙号 ASNASN 可以理解成一个超长的超帧计数器再按长度分成 slotframe。每个 slotframe 里的时隙分配了不同的功能有的专门用来发信标同步有的用来收数据有的用来做邻居发现。我当时帮一个工厂做无线温振传感器网络用的就是 TSCH 的增强信标方式。设计超帧长度时我按如下思路定参数传感器采集频率每 10 秒一组数据。每节点数据包长度加上 PHY 头大约 127 字节。时隙长度10 毫秒。一个 slotframe 设 100 个时隙即 1 秒一个周期。每个节点在属于自己的两个时隙里收发数据其余时隙全部休眠。整个网络 50 个节点单跳延迟控制在 1 秒以内电池供电的节点待机功耗做到了微安级。像这种用超长帧号把全网节点的时间轴统一起来的做法本质上就和我前面讲 NB-IoT 的 H-SFN 完全一致。4. 超帧相关协议栈的工程实现要点4.1 终端侧的帧号管理与漂移补偿先说终端。终端维护超帧计数器最核心的问题是晶振漂移。普通 32.768kHz 晶振的频偏大概是 20~100ppm如果设备在深度睡眠里待了 2 小时累积的时间误差可能达到 200 毫秒以上。对于 10 毫秒级的帧结构这个误差足以让设备醒来时错过寻呼窗口。工程上的解决办法有三种用温度补偿晶振TCXO把频偏控制在 0.5ppm 以内适合高精度需求。在睡眠前记录当前帧号和时间戳醒来后先根据内部定时器推算粗对齐再通过读取网络广播的 SFN/H-SFN 校准。把寻呼监听窗口做得宽一点比如 40 毫秒用接收窗口来吸收晶振误差。我自己的经验是尽可能用第二种加第三种的组合而不是一上来就换 TCXO。毕竟每块 TCXO 贵好几块钱单片机成本敏感的项目扛不住。而且有些便宜模块的固件对 RTC 校准支持很差外部补偿算法反而容易引入新问题。4.2 网络侧寻呼时机的计算网络侧的寻呼时机Paging OccasionPO不是随便定的。在 NB-IoT 里网络会基于设备的 IDIMSI和 eDRX 周期算出一个寻呼超帧然后在这个超帧的特定子帧上发送寻呼消息。设备侧也要按同样的公式去算两边必须完全一致。公式大致是这样寻呼超帧 (IMSI 整除 1024) 模 (eDRX 周期换算的超帧数)实际调试的时候我经常用信令跟踪软件去核对网络发的寻呼子帧和设备监听的子帧是否重合。如果有偏差常见的原因是核心网下发的 eDRX 周期和基站实际配置的不一致。终端在空闲态做了小区重选H-SFN 的相位变了但网络侧还按原来小区算寻呼时机。RRC 连接释放消息里没有携带 eDRX 参数设备默认退回 DRX。5. 超帧参数调试过程中的坑5.1 小区重选后的超帧失步这个问题在 NB-IoT 里比较常见。设备在空闲态如果从一个小区重选到另一个小区两个小区的 H-SFN 相位不一定对齐设备必须立刻重新同步。但有些模块的实现里重选后不会马上做整帧同步导致寻呼不准。我当时在一个水表项目上连续出现过主站下发指令设备没反应的投诉排查到最后就是小区重选后 H-SFN 失步。后来在模块配置里把小区重选优先级改成禁止重选或者缩短重选评估周期问题就控制住了。代价是网络侧负载不均衡但对于低速上报业务来说可以接受。5.2 超帧查询时间窗口内的重复寻呼部分核心网实现会在一个 eDRX 周期里多次发送寻呼以免终端漏听。如果终端在第一次寻呼后就恢复到了连接态那后面几次重复寻呼就会浪费空口资源。极端情况下一个小区下大量终端同时被寻呼会瞬间拉高 PRB 占用率影响正常数据业务。我在实验室压测时遇到过一个场景某厂商核心网对每个终端固定发 3 次寻呼小区下有 1000 个终端同时做下行控制寻呼信道直接打满。排查时需要检查寻呼重发次数配置以及终端在 RRC 连接建立后是否主动发寻呼响应停止相关信令。部分方案支持配置寻呼尝试次数与寻呼间隔建议按实际业务模型做一版容量评估再定。5.3 终端醒来时间与省电效果冲突超帧设计的初衷是省电但如果在超帧边界醒来的时间做得太长省电效果就大打折扣。我测过一些协议的默认寻呼监听窗口有的实现 PTW 固定设成 10.24 秒设备每次醒来都要连续监听 10 秒平均电流瞬间从 10 微安跳到 5 毫安一天的耗电全部毁在这每次醒来上。正确处理方式是让 PTW 可配置每次醒来只监听一个最短的寻呼时机窗口比如 2.56 秒甚至 20.48 毫秒确认没有自己的寻呼消息就立刻回去睡。这里有个取舍PTW 太短会导致在小区边缘或弱信号环境下错过寻呼因为寻呼消息可能要重传多次。我一般建议初始配置给 5.12 秒等设备在网络里注册稳定后再用 RRC 重配置往下压。5.4 超帧参数与省电状态机的配合3GPP 的省电机制里PSM 和 eDRX 是两套并存的东西。PSM 是彻底关掉接收机eDRX 是周期性醒来监听。很多工程师容易混淆在设计状态机时搞错优先级。我在代码里是这样实现的当 T3324 定时器运行期间设备走 eDRX 模式周期性醒来监听寻呼。T3324 超时后进入 PSM完全不监听。如果业务要求更低的延迟可以延长 T3324让设备在 eDRX 周期内保持可寻呼状态更长。这其中有几个容易踩的坑T3324 配置得太短设备很快就进入 PSM下行指令会延迟到下一次 TAU 之后才送达主站那边可能已经超时重发。eDRX 周期和 T3324 时长的关系协议里要求 eDRX 周期必须小于等于 T3324否则设备还没醒过来就被迫进入 PSM状态逻辑混乱。部分运营商网络实际下发的 T3324 优先级高于终端侧配置测试时不能只依赖本地配置。6. 超帧的容量与覆盖效果实测6.1 覆盖增强的真实收益我在一次 NB-IoT 现网测试里对比过不带 eDRX 和带 eDRX 超帧机制的下行覆盖表现。测试环境是一个地下二层的配电房RSRP 在 -115dBm 左右SINR 只有 -2dB。用默认 DRX周期 1.28 秒时寻呼成功率大约是 78%丢寻呼的主要原因是在弱信号下需要多次重复传输而终端在 1.28 秒周期里每次只能蹲一个子帧很多次醒来拿到的都是解码失败的数据。切换到 eDRX 超帧机制后寻呼时机被拉到更稀疏的超帧边界但每个边界上终端可以连续监听 PTW 窗口内的多个子帧相当于把重传增益吃满了。同样的位置寻呼成功率升到了 96%。代价是下行响应延迟从 1 秒增加到 20 秒左右但抄表业务完全能接受。这个实验给我的启发是超帧优化的收益不只是省电还有覆盖增益。因为它把频繁的小窗口监听改成了稀疏的大窗口监听在弱信号下让解码成功的概率高得多。这一点很多文档不会明说只有实测才能感受到差距。6.2 小区容量计算实例假设一个 NB-IoT 扇区要承载 5000 个水表终端每个终端每天上报 1 条数据同时每月接收一次阀门控制指令。每台终端上报占用 1 个 PRB2 次 HARQ 重传约 50ms 空口时间。每天总空口占用 5000 × 50ms 250 秒。一个扇区的 PRB 总资源按 24 小时算约 86400 秒。即使考虑调度开销和重复传输理论容量也远远够用。问题是下行寻呼。如果每台终端每月接收一次下行指令平均到每天大约 167 条。每条寻呼在 eDRX 周期边界发出按每台终端 3 次重复寻呼算每天新增约 500 次寻呼传输每次约 20ms。总占用约 10 秒依然很小。但如果所有终端都配置成 2.91 小时最长 eDRX 周期那它们只会分散在 2.91 小时内的有限寻呼超帧边界最坏情况下会有接近 2.91 小时内所有终端同时可达的现象相互之间发生寻呼拥塞。负载分摊的原则是把 eDRX 周期设成几个不同的档位或者依赖网络侧基于 IMSI 的哈希分散把终端均匀撒到不同超帧边界上。7. 常见问题排查速查表现象可能原因排查方法解决建议终端收不到下行寻呼H-SFN 失步抓 RRC 信令核对 H-SFN 同步状态触发 TAU 或小区重选后强制重同步省电效果不明显PTW 窗口太长统计每次醒来的监听时长将 PTW 缩短至 1~2 个寻呼时机主站下发指令延迟过高T3324 太短设备进入 PSM查看 T3324 实际下发值延长 T3324 或改用 eDRX弱信号区域寻呼丢失重传次数不足看寻呼的重复传输参数配置增大寻呼重发次数延长 PTW网络拥塞导致寻呼丢包大量终端超帧边界集中统计终端 H-SFN 分布调整 IMSI 哈希参数或分散 eDRX 周期模块频繁掉线超帧周期内晶体漂移过量测量模块睡眠状态下的时钟偏移启动帧号校准或换 TCXO测试时收不到寻呼但网络侧显示已发终端监听子帧与 PO 不对齐核对 PO 计算中的参数IMSI、eDRX 周期修正参数或升级协议栈版本8. 关于协议栈选型的一些建议8.1 协议栈选型不要只看协议支持列表很多 NB-IoT 模组都宣称支持 eDRX、支持超帧但真正用起来差距很大。**为什么**因为协议栈实现细节才是关键。有些模组虽然支持 eDRX 周期值但 H-SFN 同步逻辑有问题在小区重选后不能快速对齐有些模组把 PTW 固定死了不能按业务动态调整还有些模组在睡眠期间 RTC 漂移补偿算法太粗糙导致实际监听时机偏差超过一个子帧。我建议选型时做这样几项实测让终端进入 eDRX 后连续跑 72 小时统计寻呼成功率。人为制造小区重选、无线链路失败检查终端能否快速恢复 H-SFN 同步。抓电流曲线看每次醒来的监听时间和耗电是否匹配 PTW 配置。**看模组厂商的协议栈版本更新频率也有用。**如果一个模组的 eDRX 功能在商用后一年都没更新过多半是模块固件里就有问题全靠网络侧迁就它。8.2 免费开源方案的可玩性如果手头有 SDR 设备比如 USRP也可以自己搭一个简易 NB-IoT 基站配合开源协议栈比如 OpenAirInterface、srsLTE 等来验证超帧行为。这种方式特别适合做协议研究和私有物联网网络的验证能直观看到 H-SFN 广播、寻呼时机的生成过程和超帧参数的物理层映射。我自己搭过一次简易 NB-IoT 测试床有个很有价值的发现在随机接入阶段终端和基站之间的 H-SFN 对齐完全靠系统消息里的调度信息来确定部分终端的实现里会因为解调系统消息失败而一直停留在初始同步状态表现为反复附着、频繁发随机接入前导。这种问题在现网里会被误报为信号不好实际上是对超帧信息解析不完整。9. 超帧在标准协议之外的扩展玩法超帧的思想应用范围远不止蜂窝物联网。LoRa 的 Beacon 周期LoRaWAN 里每个网络有一个 Beacon 周期通常 128 秒设备会在 Beacon 周期边界校准时间。如果设备长时间休眠跨过多个 Beacon 周期时间漂移会累积。可以借鉴超帧思想在协议之上额外维护一个本地超帧计数器周期性对齐网络 Beacon。蓝牙 Mesh 的 Friend 节点Friend 节点为低功耗节点缓存下行消息低功耗节点周期性醒来从 Friend 节点取数据。这个周期醒来取数据的本质也是一个瘦身的超帧机制。设计时可以参照 eDRX 的思路把唤醒间隔、缓存时长、消息优先级做成可配置项。Wi-Fi 的 TWT目标唤醒时间Wi-Fi 6/7 里的 TWT 协议允许设备约定只在特定时间醒来交换数据。TWT 里的目标唤醒时间其实就是超帧粒度的作息表。我在一个智能家居网关项目里用过 TWT 配合 802.15.4 的休眠节点整个系统平均功耗降了 60%延迟只增加了 30ms 左右。**如果你在做一个无线传感器网络遇到既要省电又要能随时被叫醒的矛盾需求超帧设计思路几乎是最优解。**哪怕协议层面没有现成的H-SFN你也可以在链路层甚至应用层自己维护一个逻辑超帧用 Beacons 或心跳包来校准所有节点的帧号再为每个节点分配在一个超帧周期内的专属唤醒槽位。我自己设计一个私有协议时用的就是一个 4096 个时隙的超帧每个时隙 15 毫秒总周期约 61 秒。每个节点根据自身的短地址哈希到一个唤醒时隙在这个时隙内监听 15 毫秒其余时间全部休眠。实测 30 个节点的星型网络每节点平均功耗只有 25 微安而下行响应延迟平均不超过 30 秒。这个方案实现起来只需要一个精确的 32.768kHz RTC 和一个简单的信标同步机制成本几乎为零。10. 最后再分享一个调测小技巧调试超帧相关功能时千万别只盯着示波器和电流计一定要同步抓空口信令。我每次调 eDRX 和超帧参数都是先用 Wireshark 抓取 DIAG 日志或者用模组厂家的 Trace 工具把 RRC 信令里的 eDRX 周期、PTW、H-SFN 参数全打出来跟主站的下行时戳一一核对。有一次排查一台设备为何老是错过寻呼查了三天也没找到原因。后来把信令时间戳拉出来跟 GPS 时间一比发现模块内部维护的 H-SFN 在每次 RRC 连接释放后都慢了一个无线帧的量日积月累就偏移出了监听窗口。最后在代码里加了个逻辑每次 RRC 释放之后都强制重新解码一次系统消息里的 H-SFN 计数值问题立刻消失。所以我的经验就是在超帧这类长周期机制面前不要相信任何终端或基站自己上报的同步状态一切以空口实际解码出来的帧号为准。把帧号的校准动作放在每一次状态切换的入口处省下来的那点功耗远没有丢一次寻呼带来的业务损失大。个人实操下来的感觉是超帧设计最考验人的不是把参数填对而是对长周期这件事背后所有隐藏假设的敏感度——晶振会漂、小区会换、网络会重发、信令会丢把这些因素全部兜住了超帧才会真正变成省电利器。