如果你在无线通信这行待过一阵子，一定对“帧”这个词不陌生：语音一帧20毫秒，LTE一个无线帧10毫秒，GSM一个TDMA帧4.615毫秒。可要是突然有人问“GSM的hyperframe周期是多少？为什么是3小时28分53.76秒？”，估计不少人会卡壳。这个数字看起来毫无美感，背后的设计逻辑却相当自洽，而且它直接参与加密、跳频、寻呼这些日常业务。
这篇文章就是想把hyperframes这个冷门但关键的概念讲透：它怎么从帧、复帧、超帧一层层套出来的，22位帧号为什么需要这么长的周期，A5加密和GPRS计数怎么用它，LTE/5G里又是怎么变着法子延续这套思路的。适合正在看空口协议栈的工程师、做网络优化的朋友、做终端协议栈的同行，以及准备面试无线协议岗位的开发者。看完你至少能明白一件事：hyperframe不是某种高深的“超级帧”，而是一张把整张蜂窝网对齐到同一个时钟上的“年表”。
1. 一条时隙的“年表”：从TDMA帧到hyperframe的四层嵌套
1.1 为什么蜂窝系统非要把时间切成帧
GSM采用时分多址（TDMA），一个200kHz载频在时间轴上被切成8个等长的时隙，8个时隙合在一起叫一个TDMA帧。每个时隙承载一个突发脉冲（burst），也就是一串156.25比特的物理波形。这个设计保证了8个用户可以共享同一个载频而不互相干扰——每个人轮着用1/8的时间。
关键问题是：这4.615毫秒是怎么来的？
GSM全速率语音编码器每20毫秒输出一个语音块，经过信道编码、交织之后变成456比特，分到4个突发里发送。4个突发占用4个TDMA帧。20毫秒除以4，就是5毫秒左右；再加上一个业务复帧里要预留SACCH和空闲帧，最终把TDMA帧定为120毫秒除以26，也就是约4.615毫秒。换句话说，这个数字是“语音周期20毫秒”和“复帧结构26帧”共同逼出来的。这里的260个比特对应到4个突发也基本能跟20毫秒的语音块对上，所以从物理层到编解码器，整套系统的节拍是咬合的。
TDMA帧再往上，就进入复帧、超帧这一层层的“日历”体系。你每听到一声“帧号是多少”，其实都是在问这台设备目前走到了这段日历里的哪一格。
1.2 复帧与超帧：两种“复帧”的最小公倍数
GSM里复帧有两种，各有各的用途，这点特别容易混淆：
- 业务复帧：由26个TDMA帧组成，时长120毫秒。其中24帧分配给TCH话音/数据突发、1帧给SACCH慢速随路控制、1帧空闲。因为SACCH每120毫秒才出现一次，所以功率控制、测量上报这些慢速控制消息都以这个周期为基准。
- 控制复帧：由51个TDMA帧组成，时长约235.385毫秒。BCCH、CCCH、SDCCH、PCH这些控制信道都在这个结构里排布。51帧的设计目的是让控制信道的位置跟业务信道错开，并且给寻呼组留下足够多的子信道位置。
问题来了：一个是26帧的周期，一个是51帧的周期，两者什么时候才能对齐？
26和51互质，最小公倍数是1326。于是GSM定义“超帧”（superframe）为1326个TDMA帧，等于51个业务复帧，也等于26个控制复帧，时长恰好6.12秒。超帧不是为了某个具体业务，而是一个让两种复帧之间能够换算和调度的公共时间基准。比如协议里某个测量报告要打上“当前处于第几个超帧”，这样基站和手机无需额外协商就能知道对方说的是哪个时刻的窗口。
网上很多文章把superframe和hyperframe混着写，这是不对的：超帧只有6.12秒，站在它上面还有一级叫hyperframe。
1.3 hyperframe的尺寸：2048个超帧与22位帧号
hyperframe的定义很硬核：1个hyperframe = 2048个超帧 = 2,715,648个TDMA帧，时长3小时28分53.76秒。
为什么偏偏是2048？因为GSM的TDMA帧号（Frame Number，FN）设计成22位。注意这里的22位不是满打满算到4,194,304，而是只用了0到2,715,647，也就是2,715,648个取值，正好对应一个hyperframe。也就是说，FN数完整个hyperframe后才归零重新计数。用11位表示超帧序号（0到2047），再用剩下的位表示超帧内部的帧偏移，整个编号体系就完整了。
取2048这个2的幂，除了编号方便，更重要的是后续所有基于FN的运算，比如跳频序列、加密计数、扰码序号，都可以用模2的算术实现，硬件实现和算法验证都省事。如果没有这个幂次对齐，频率跳变和加密状态机里会出现大量除法和取模，这在当年DSP性能有限的时代是不可接受的。
这一层的完整结构可以汇总成一张表：
| 层级 | 构成 | 时长 | 主要用途 |
|---|---|---|---|
| TDMA帧 | 8个时隙 | 4.615ms | 一个突发脉冲的传输单元 |
| 业务复帧 | 26个TDMA帧 | 120ms | TCH突发 + SACCH + 空闲帧 |
| 控制复帧 | 51个TDMA帧 | 235.385ms | BCCH/CCCH/SDCCH/PCH等控制信道 |
| 超帧 | 51个业务复帧 / 26个控制复帧 | 6.12s | 业务与控制结构对齐的公共周期 |
| hyperframe | 2048个超帧 | 3h28m53.76s | FN的完整编号周期 |
有了这张“年表”，GSM网络里的任何设备只要知道FN的绝对位置，就知道自己处在3.5小时大循环里的哪一毫秒。这个全局一致的时间坐标，后面加密和跳频全靠它。
2. 帧号不只是序号：加密、密钥流与防重放的COUNT
2.1 A5算法为什么需要一个不重复的帧号
GSM的话音加密用的是A5系列流密码，最经典的是A5/1。流密码的加密方式是“密钥流异或明文”：每个比特的密文等于明文和密钥流里的对应比特做异或。A5/1的输入是64比特的会话密钥Kc和22比特的帧号FN，输出是一段密钥流，加密突发里两个57比特的数据块。
这里有个致命约束：如果两个人用同样的Kc和同样的FN，就会产生完全相同的密钥流。攻击者在不知道密钥的情况下，只要拿到两段用相同密钥流加密的密文，再把它们异或，明文之间的关联就会暴露出来。所以FN绝对不能在一个连接的生命周期里重复。
22位FN带来的不重复周期是2,715,648个帧，也就是3小时28分。对一次普通通话来说，这个周期足够长——几乎不会有哪通电话能连续打3.5小时还不换一次密钥。A5/1每帧生成228比特密钥流，上下行各114比特，两个方向的突发都靠同一个FN区分。这也是为什么BTS和手机两边的FN必须完全同步：哪怕差一帧，解密出来的就是噪声。
顺带说一句，A5/3（KASUMI）虽然算法结构完全不同，但输入参数里同样带着FN。所以“帧号参与加密”不是A5/1的独有设计，而是GSM三代加密体系共同的前提。
2.2 GPRS的COUNT=HFN‖FN：超帧号第一次有了“正式编制”
到了GPRS，情况变得更复杂。GPRS是分组业务，一个终端可能持续在网络里收发数据块，而且横跨多个小区、多个RLC/MAC块，理论上一个加密上下文要存活很久。如果还只用22位FN做种子，那每隔3.5小时密钥流就会重复一次，这对类似“传感器每隔几分钟发一个小包”的长在线终端是无法接受的。
于是规范引入COUNT值：把22位FN放在低22位，再把hyperframe number（HFN）放在高位，拼成一个32位的计数器。HFN每经过一个完整hyperframe就加1；因为是10位左右的高位计数，整体重复周期能拉到上百天级别，密钥流复用问题在工程上可以被彻底忽略。
这里值得强调的是，HFN并不是纸上谈兵的概念。SGSN和MS在维护LLC/RLC加密状态时要各自维护这个COUNT，并且通过协议交互确保两边一致。如果中间发生小区更新、路由区更新，CONTEXT里的COUNT没有正确同步，后续数据块解密就会失败。我在实际排查中见过不少“GPRS数据忽通忽断”的案例，最后定位到就是COUNT没对齐，而不是射频问题。
2.3 帧号失步在实践中长什么样
这个问题在纯话音时代最典型。手机在空闲模式下会做DRX休眠，它靠本地时钟自己数帧号，而不是每帧都去解SCH。正常情况下这个本地计数非常准。但如果有硬件晶振漂移，或者手机在弱信号区反复搜网导致时序状态丢失，休眠醒来后再加密通话，就会出现两种典型故障：一是起呼失败，二是通话建立后只有单向声音甚至双方都听不见。
从网络侧看，基站上报的测量、A接口信令里的加密参数都不会有异常，因为BTS认为自己和MS同步。真正的根因往往要靠终端侧日志里“FN mismatch”或者“ciphering failure”这类关键字才能定位。这类问题不好复现，因为3.5小时的周期意味着只有恰好跨过FN翻转点附近才容易出岔子。
所以我的建议是：遇到加密通话失败，先排查“帧号同步状态”，再查Kc和密钥流转发，顺序不要反。很多新手一上来就怀疑加密算法本身，其实A5算法在真实的商用网络里出错的概率极低，反而是帧号不同步这种“低级但隐蔽”的问题最耗时间。
3. 每秒217跳的节拍器：FN参与跳频的方式与工程含义
3.1 慢跳频的数学表达：MA、MAIO、HSN与FN
GSM采用慢跳频，跳频速率等于TDMA帧速率，也就是每秒约217跳——每到一个新TDMA帧，载频就换一次。这看起来是个物理层细节，但它完全绕不开FN。
跳频序列的生成需要四个输入：跳频集合MA（一组可用频点）、MAIO（移动分配索引偏移）、HSN（跳频序列号），以及当前帧号FN。HSN决定跳频的“伪随机模式”，MAIO决定同一小区内不同用户在同一个跳频模式下怎么错开频点。而FN是这个公式里不断变化的自变量：FN每加1，下一次跳到的频点就沿着MA序列往前走一步。
当两个小区使用相同的HSN时，如果它们的FN完全同步（比如都从GPS或参考时钟对齐），那么同一条频点序列的相位就能被精确控制，这是MRP（多小区复用规划）的理论基础。反过来，如果两个小区没有同步，即使HSN相同，也会因为FN偏移而产生不可预测的频率碰撞。
hyperframe在这里的作用是保证完整的跳频模式在一个超长周期里才完全重复一次。换句话说，任何一次呼叫的跳频轨迹，在整个通话过程中都不会跟另一个历史时段的轨迹产生短周期相关性，干扰统计上被彻底平均化了。
3.2 手机如何知道当前帧号：SCH突发与T1/T2/T3
手机开机后要从BCCH载频上找FCCH，再找SCH，然后才能知道网络侧的帧号。SCH突发里携带的不是完整的22位FN，而是压缩后的三个参数：T1、T2、T3。
- T1对应FN除以1326的商，范围0到2047，用11位表示；
- T2对应FN mod 26，范围0到25；
- T3对应FN mod 51，范围0到50。
接收端拿到这三个数，通过它们之间的模关系，利用中国剩余定理就能恢复出完整的22位FN。这样设计的好处是：空中接口上只需要传更少的比特，同时还能自带校验——因为T2和T3之间必须满足FN对13取模的约束关系，解出来的帧号如果不满足这个约束，直接判定SCH解码失败，也算是一种可靠性机制。
手机解出SCH后，就相当于拿到“北京时间”，之后每个TDMA帧本地+1，不需要每4.6毫秒重新去读一次。这也是DRX能省电的前提：手机就算睡上几百个帧，醒来时仍然知道当前FN，可以直接去对应的寻呼组监听PCH。
3.3 跳频规划里“帧号”相关的坑
我在做无线优化时踩过这样一个坑：某簇基站配置了相同的HSN做MRP，理论上频点碰撞应该被严格控制，但路测里周期性出现质量差。最后逐个基站核对FN偏移才发现，其中几个BTS的传输链路时延补偿参数设错，导致空中接口的帧号起点跟相邻基站差了若干个TDMA帧。原本设计好的“同一时刻占用不同频点”被打破，变成了周期性同频干扰。
这类问题用传统路测很难看到，因为手机侧报告的是质量差，不会直接告诉你“FN offset”。正确的排查方法是先确认基站之间是否启用同步帧号，再逐站核对时间同步源和帧偏移补偿。不要把锅甩给跳频算法——算法没问题，往往是时间基准没对齐。
还有一个小提醒：处理跳频干扰问题时，先分清楚“同一个HSN但不同MAIO”和“不同HSN”两种场景。前者是频率分离，后者是干扰随机化。别指望不同HSN能像MRP那样精确避让，它只能把碰撞打散成统计噪声。
4. 从GSM到LTE/5G：hyperframe思想如何换了马甲
4.1 LTE：SFN的10.24秒循环与eDRX的H-SFN
LTE的系统帧号SFN只有10位，编号0到1023，一个无线帧10毫秒，所以SFN的翻转周期只有10.24秒。这个长度对正常的话音和寻呼完全够用，因为终端醒来后重新接收MIB/SIB的成本很低，10秒级的周期并不会带来什么问题。
但到了物联网时代，NB-IoT和eMTC要支持超低功耗的终端，这些设备可能几分钟、几十分钟甚至几个小时才醒一次。如果只有10位SFN，班会根本算不清该在哪个时刻醒来。于是3GPP在Release 13引入eDRX机制，其中核心概念就是Hyper SFN（H-SFN），用另外10位和SFN拼成一个20位的帧计数器。20位乘以10毫秒，完整周期约为10485.76秒，也就是2.91小时。
是不是很像？GSM的hyperframe是3小时28分，LTE的eDRX超帧周期约2.9小时，两者都落在“三小时上下”这个量级。这不是巧合，而是设计约束的自然收敛：帧号位数取2的幂，帧长又是固定的，算出来的周期自然就是这个数量级。更重要的是，这个周期足够让物联网设备睡个安稳觉，同时在醒来后仍能准确对上寻呼窗口。
4.2 一脉相承的“短帧号+超长计数”设计范式
把GSM和LTE的帧号体系放在一起看，会发现一个反复出现的工程模式：
- 物理层每次传输需要的帧号都很短（GSM的FN虽然22位，但实际参与空口同步时也是拆成T1/T2/T3的小块；LTE的SFN只有10位）。
- 安全、寻呼、协调这类“高层需求”需要的是超长计数，所以要在短帧号上再叠加一层长周期计数器（GSM的HFN、LTE的H-SFN）。
为什么这么设计？因为物理层同步希望帧号短、更新快、获取成本低；而加密和长休眠希望序列久不重复、跨周期可预测。把这两个需求拆到不同层级各有分工，是蜂窝系统很经典的做法。UMTS里的CFN也是类似，8位的连接帧号每256帧就要翻转一次，所以跨小区协调时要借助SFN和CFN的对应关系。NR沿用了LTE的SFN结构，10毫秒的帧长和10位的SFN保持不变，eDRX的超帧思想也延续了Rel-13的家底。
下次你再看到某个系统里出现第二层帧号计数器，不用觉得陌生，它的本质就是GSM hyperframe思想在现代系统里的变体。把这张表存下来，面试和文档解读都很好用：
| 系统 | 物理帧长 | 基础帧号 | 基础周期 | 扩展计数 | 扩展周期 |
|---|---|---|---|---|---|
| GSM | TDMA帧4.615ms | FN（22位，0～2715647） | 3h28m53.76s | HFN拼入COUNT | 上百天量级 |
| LTE | 无线帧10ms | SFN（10位） | 10.24s | H-SFN 10位 | 约2.91小时 |
| NR | 无线帧10ms（15kHz SCS） | SFN（10位） | 10.24s | eDRX沿用H-SFN思想 | 取决于网络配置 |
5. 实操：亲手把FN从空口里抓出来
5.1 用SDR捕获GSM并还原完整帧号
如果你手头有RTL-SDR或者HackRF，又有一个符合当地法规的实验室环境，可以自己把GSM的BCCH抓下来，亲眼看一下FN是怎么传的。工具链一般是gr-gsm加Wireshark的GSMTAP插件。
大致流程是：
- 用扫频工具找到目标小区的BCCH载频（ARFCN）；
- SDR调谐到该频点，先解FCCH找到频率校正突发，再找到SCH；
- gr-gsm会解出SCH携带的T1/T2/T3，并把还原出来的帧号封进GSMTAP消息，交给Wireshark显示；
- 在Wireshark里过滤GSMTAP的TDMA frame number字段，就能看到FN随每帧递增。
GSMTAP通常把帧号放在一个字段里，可以直接用命令行工具提取：
# 从抓包文件里提取GSMTAP帧号（示例） tshark -r gsm_bcch.pcap -Y gsmtap.chan_type == 0x00 \ -T fields -e gsmtap.tdma_frame | head -20你会看到一列连续递增的数字。因为hyperframe周期长达3.5小时，实时观察几乎不可能等到FN翻转，但这恰恰说明问题：正是为了让FN不重复到“日常操作肉眼可见”的程度，设计者才把周期拉得这么长。真要验证翻转，只能人为构造帧号或者用仿真脚本把计数器直接拨到边界值附近。
必须强调：空口抓包的合法性因地区而异，务必只在获得授权的测试网络、或者自己搭建的实验室基站环境下操作，不要对商用网络做被动采集之外的操作。
5.2 从终端日志和仪表观察H-SFN与eDRX周期
在LTE侧，想观察“超帧”级别的计数，最直接的办法是看终端日志里的系统消息。支持eDRX的小区会在SIB1里携带H-SFN相关指示，终端的小区搜索和寻呼计算逻辑就是基于Hyper SFN加SFN来算PTW（寻呼时间窗口）的。
实际调测时，可以用终端日志过滤带H-SFN关键字的信令，再验证一个具体的eDRX周期：比如网络配置eDRX周期为10.24秒以上时，UE的寻呼occasion落在哪个Hyper SFN区间。算的时候注意，eDRX周期是以H-SFN和SFN组合为前提的，不能只拿SFN的10.24秒小周期来计算，否则会把长时间的睡眠窗口算到错误的位置。
很多刚接触NB-IoT的同事第一次看到“H-SFN=1，SFN=200”这样的日志会懵一下，其实拆开就是一个20位计数器的高10位和低10位，跟GSM里“HFN‖FN”的拼法毫无区别。理解了这一点，跨制式看日志会顺畅很多。
5.3 现场优化中真正需要关心hyperframe的三种场景
第一，加密语音通话失败，尤其是长通话掉话重接以后。优先核对网络侧和终端侧的帧号是否对齐，再怀疑密钥。
第二，跳频质量异常。确认所有参与MRP的基站是否处于同步帧号模式，逐个检查GPS/传输时延补偿，不要一上来就调HSN/MAIO。
第三，物联网终端功耗和寻呼时延。查看网络侧eDRX参数配置和终端日志里的H-SFN/SFN组合，确认终端计算寻呼窗口的算法是否按规范实现。这三点是我在项目里实际碰到过的场景，前两个都在“帧号同步”上翻过车。
还有一条非常实用的经验：读3GPP规范时千万别把“superframe”和“hyperframe”混着搜。TS 45.002里两者是严格区分的，检索词差一个层级，查到的表格和公式完全不同。我自己就曾把超帧6.12秒的值当成hyperframe去核对需求，结果整个周期计算全错，汇报时被追问得很难堪。规范的细节就是这样，看着不起眼，错了就是错了。
要记住的核心就一句话：hyperframe是GSM为帧号FN定义的一个超长完整周期，它让加密不重、跳频不乱、跨设备可同步。理解它不需要背住3小时28分这个数字，而是要理解蜂窝系统为什么要把时间切得这么细、又为什么要留一个这么长的兜底周期。这套思路从GSM一路传到LTE再到NR，到今天依然是终端省电和网络安全的地基。
