1. 从一次帧号翻转开始的排查Hyperframe到底是什么我先讲一个真实发生过的调试现场。某次我在处理一个2G数传模块与自研协议栈对接的问题现象很诡异模块刚上电时一切正常数据上报稳定大概过了三个半小时左右整条链路突然出现连续的加密同步失败终端反复发起随机接入基站侧上报“MAC层完整性校验失败”后台一查发现手机和网络侧对当前TDMA帧号Frame NumberFN的认知差了整整一轮。三个半小时这个数字让我一下子警觉起来——这不就是GSM协议里面Hyperframe的完整周期吗GSM的帧号计数器就是在一个约3小时28分53秒的周期内循环行走走到尽头之后清零重来。如果终端或模块在帧号翻转的瞬间没有正确复位或者软件里用了有限位数存帧号但忽略了回绕场景就会发生这种“两边各说各话”的同步失效。这才是Hyperframe这个术语值得被搞明白的原因。很多工程师天天写AT指令、调网络注册却很少关心空中接口的时间维度是怎么组织的。但实际上从GSM、LTE到5G无线通信的同步、加密、跳频、寻呼、测量调度全部挂在一套精心设计的帧号体系上。Hyperframe是这套体系中周期最长、最容易在实现时踩坑、也最能体现协议设计思想的一环。这篇文章会沿着一条线展开先拆GSM里的时间层级结构搞清Hyperframe是怎么从底层帧一阶一阶叠出来的然后讲它驱动的三大关键机制——加密、跳频、寻呼接着给出一套从实际日志中还原和验证帧号的操作方法最后对比LTE和5G的类似设计看看这套老古董思路为什么到现在依然不过时。适合做协议栈开发、嵌入式通信模组调试、侧信道分析或者单纯想搞懂空中接口时序的人阅读读完你能自己计算出帧号、知道在边界条件上该注意什么。2. GSM时间体系拆解从时隙到Hyperframe是怎么一层层叠出来的2.1 最底层时隙Time Slot与TDMA帧GSM几乎所有物理信道都在同一个载频上按时间轮流使用这种多用户共享方式叫时分多址TDMA。一个TDMA帧的时间长度是固定的约4.615毫秒由8个时隙Time Slot组成每个时隙约0.577毫秒。手机只在自己被分配的时隙上收发其余时间可以关闭射频来省电。这4.615毫秒不是拍脑袋定的。它要容纳一个突发burst的发送时间还要留出保护间隔防止不同手机因距离不同、信号传播延迟不同而相互叠加。0.577毫秒内要传输156.25个bit这些bit里既有用户信息也有训练序列和尾比特物理层用这套固定的节奏把空中接口的时间切成一段段等长的“格子”。每一段格子都需要有编号。物理层、数据链路层、上层信令在交互时需要引用“我在第几帧、第几个时隙上收发过什么”这个编号就是TDMA帧号。帧号是GSM中一切时间调度的锚点。2.2 两个多帧周期26帧多帧与51帧多帧单个TDMA帧的粒度太细调度逻辑如果直接对着4.6ms一帧来管理开销会非常离谱。所以协议在帧之上又引入“多帧Multiframe”这一层。GSM里有两个多帧周期并存26帧多帧26个TDMA帧组成一个多帧周期约120毫秒。用于承载业务信道TCH以及随路的慢速关联控制信道SACCH。51帧多帧51个TDMA帧组成一个多帧周期约235毫秒。用于承载广播信道BCCH、公共控制信道CCCH、独立专用控制信道SDCCH等等。为什么偏偏是26和51这两个数字因为它们和逻辑信道的映射需求直接相关。业务信道需要承担语音编解码帧的周期传输SACCH要在固定位置插入测量报告和功率控制命令26帧的时长刚好能和20ms语音帧对齐控制信道涉及的逻辑信道种类多51帧提供了足够多的时隙位置来排列各类广播和寻呼消息而且51帧的时长刚好适合移动台周期性做邻区测量。两个多帧周期并存带来的一个直接问题是如果业务信道按26帧循环、控制信道按51帧循环这两套循环错开之后需要多久才能回到完全对齐的起点答案是1326个TDMA帧。因为26和51互质它们的最小公倍数就是26×511326于是协议把这1326帧定义成一个更大的单位——超帧Superframe周期约6.12秒。2.3 超帧Superframe的互质设计逻辑1326帧这个数的妙处在于它既包含整数个26帧多帧也包含整数个51帧多帧。无论一个逻辑信道是跟着26帧节奏走还是跟着51帧节奏走它在超帧边界上都能重新对齐。这就好比钟表上的时针和分针走的周期不同但每到12点整它们又会重合一次。从数学上看26和51互质所以它们的最小公倍数是1326。如果两个多帧周期不是互质的比如一个是26、另一个是52那最小公倍数就只是52超帧的周期反而会缩短编号空间会更小。协议设计者刻意选择互质的两个多帧长度让超帧成为一个足够长且自洽的公共对齐单位。这种思路在协议工程里反复出现用互质的子周期构造一个长周期使多种不同步长的调度能够在这个长周期内达到同步。2.4 从超帧到Hyperframe为什么偏偏是2048有了1326帧的超帧按理说已经可以正常调度了。但GSM还需要一个更大的时间单位来管理加密状态和部分慢速调度。协议在超帧之上又叠了一层把2048个超帧组成一个Hyperframe。单个Hyperframe包含的TDMA帧数1326×20482715648帧每个TDMA帧约4.615毫秒一个Hyperframe的周期就是2715648×4.615ms算下来约3小时28分53秒。2048这个数怎么来的因为GSM的帧号FN用22比特表示最大值是2^22−14194303吗不对注意这里的计算2715648小于41943042^22实际GSM帧号范围是0到2715647刚好对应一个Hyperframe内全部的TDMA帧。也就是说Hyperframe的引入本质上是为了让FN能在一定范围内连续递增而不是很快回绕。FN在0至2715647之间循环一个循环周期就是约3.48小时。选择2048而不是其他数本质上是在平衡两件事一方面帧号范围够大加密算法在同一个密钥周期内能拿到的帧号样本足够多另一方面计数器位数又不能无限膨胀22位的帧号在很多信令字段中正好可以拆分传输。所以Hyperframe不是一个功能实体而是一个“让计数器转得慢一点”的顶层结构。3. 挂载在Hyperframe上的三大机制加密、跳频与寻呼调度3.1 加密状态的核心输入帧号FN是怎么绕不开的GSM语音和数据的加密依靠A5算法族其中A5/1是早期广泛使用的流密码A5/3基于KASUMI分组密码构造。无论哪种算法输入都包含三部分加密密钥Kc、下行或上行方向标识、以及当前帧号FN。为什么加密要拿帧号当输入因为流密码是逐帧生成密钥流的每一帧都需要一个不同的密钥流。如果两帧用完全相同的密钥和完全相同的输入就会产生完全相同的密钥流攻击者一旦拿到其中一帧的明文密文对就可以推算出另一帧的密钥流整个加密体系就崩了。帧号随时间单调递增等价于给每个帧提供了唯一的时间坐标保证密钥流不重复。这里有个关键细节FN本身是一个有限计数器到Hyperframe边界会回绕到0。那回绕后会不会出现“同一密钥同一帧号”的情况理论上会但GSM在设计时默认Kc不会长期不变每次呼叫、每次位置更新都会协商新的Kc因此即使FN回绕Kc也已经变了。实际协议栈里还会做额外保护比如在某些实现中如果检测到帧号回绕而密钥没换直接触发异常处理。这也是我在文章开头提到那个故障的原因——模块在Hyperframe边界没有正确复位帧号状态加密同步对不上MAC层校验直接失败。3.2 慢跳频Slow Frequency Hopping如何依赖FNGSM支持慢跳频每帧跳一次频点跳频的目的有两个频率分集和干扰分集。它的核心是一套伪随机序列输入包括帧号FN、跳频序列号HSN0到63、移动分配指数偏置MAIO以及一组参与跳频的频点列表MA。跳频公式并不复杂但FN是其中必不可少的随机源。协议栈在每一帧到来时需要立刻根据当前FN算出这一帧该用哪个频点这就要求手机和基站对FN的认知高度一致。只要有一帧的FN错位后面所有跳频点全错接收端锁定不到信号。所以你去看GSM空口测试规范跳频配置下发后网络侧要求终端在特定帧号开始切换频点这个“特定帧号”通常就来自网络下发的起始帧号。Hyperframe在这里的作用是提供足够大的编号空间让跳频序列可以在一个很长的时间尺度内不重复避免干扰模式快速循环。3.3 寻呼组与DRX让终端安心睡三个半小时的设备逻辑移动台为了省电不需要每帧都去监听网络下发的消息。GSM引入了非连续接收DRX把终端分组每组只在特定帧号附近监听寻呼信道PCH。寻呼组由终端的IMSI算出来网络侧也在同一时刻发送寻呼消息双方在时间轴上对齐。一个Hyperframe周期内属于某个寻呼组的监听时机非常多但终端的射频电路只需要在这些时间点醒来。如果协议栈对Hyperframe周期的计算不准确寻呼时机就会飘移终端要么频繁误唤醒要么错过真正的寻呼。LTE的寻呼周期、5G的eDRX加深了这一思路把“睡觉时间”进一步拉长而帧号体系始终是让双方保持同步的那根线。4. 实操手册从协议日志中解析并验证帧号4.1 帧号在信令中的拆分字段T1、T2、T3GSM空中接口里帧号FN通常不是作为一个完整22位整数传输的而是拆成T1、T2、T3三个分量分别放进信令字段。3GPP协议里定义得很明确T1 FN div (26×51) FN div 1326取值范围0到2047正好对应Hyperframe内第几个超帧T2 FN mod 26取值范围0到25T3 FN mod 51取值范围0到50这样拆的好处是每个字段的比特数都不大适合放进紧凑的信令结构里。收到T1、T2、T3之后还原完整FN用这个公式FN T1×1326 26×T3 T2纠错一下更严谨的还原公式是FN T1×1326 T2×51 T3验证T2是FN除以26的余数T3是FN除以51的余数。设FN100000则T175T24T344。代入还原75×1326 4×51 44 99450 204 44 99698并不等于100000。所以这个公式不对。实际GSM里FN还原用的是中国剩余定理的思路完整表述是先算T1、T2、T3然后找一个0到1325之间的整数T’满足T’ mod 26 T2T’ mod 51 T3。由于26和51互质这个T’存在且唯一。然后FN T1×1326 T’。具体算T’可以这样因为T’必须形如T3 51k代入mod 26的条件(T351k) mod 26 T2。51 mod 26 25等价于(T325k) mod 26 T2即25k ≡ (T2−T3) mod 26。25的逆元是25(因为25×25625625 mod 26 1)所以k ≡ 25×(T2−T3) mod 26。取0≤k≤25后代入即可。这个还原过程在侧信道分析、信令解密、干扰定位时非常有用。我自己写过一个很小的解析函数输入T1、T2、T3输出完整FN顺手还能算出当前帧落在一个Hyperframe周期里的百分比位置。4.2 用Wireshark过滤和交叉验证帧号如果你手上有一份GSM空口抓包通常通过USRP配合gr-gsm或者商业协议分析仪抓取Wireshark里可以在GSM层看到“GSM TDMA frame number”字段。不同软件显示的字段名略有差异但核心都是那22位FN。实际抓包中FN是逐帧递增的。一个简单的验证方式是看同一物理信道、连续时间戳之间的FN差值如果跳变不是1说明中间有帧没抓到或者抓包工具的时间戳本身有丢帧。还有一种情况如果跳变值是负数基本就是FN发生了Hyperframe回绕。回绕时不用慌对比一下当前信道的加密参数和跳频配置确认终端和网络侧没有发生实质性的失步即可。另外当你在处理RLC/MAC层的分段重组时FN可以作为排序的辅助参照。有些协议分析仪会基于FN自动校正乱序但如果分析仪配置不对它会把跨Hyperframe的回绕当成乱序导致重组失败。这种问题在长时抓包中很常见处理办法是把FN转成无符号单调递增的64位计数碰到回绕就加上2715648而不是直接强制排序。4.3 手写一个帧号边界测试用例工程上最容易忽视的是边界测试。我强烈建议在协议栈联调前先跑一遍帧号回绕用例把FN锁定在2715647Hyperframe最后一个帧号触发一帧新的收发包观察代码里FN是否回绕到0检查回绕瞬间加密模块是否把FN作为输入重新生成密钥流检查跳频频点的计算是否在回绕瞬间跳变异常检查上位机日志里打印的FN字段是否有符号位问题。很多模块在回绕之前的正常功能测试都通过但恰恰是在这最后一帧上翻了车。原因多半是用有符号整数存了FN2715647加1之后变成负数再进行mod运算就完全错了。这种bug一旦进到现网就是那种“运行三小时四十分钟必掉线”的经典故障。5. 从GSM Hyperframe到LTE/5G时间维度的继承与演进5.1 LTE的SFN与H-SFNLTE没有沿用GSM的多帧、超帧、Hyperframe三级结构而是把它简化成了更直接的两级系统帧号SFNSystem Frame Number和超系统帧号H-SFNHyper System Frame Number。LTE一个无线帧10毫秒SFN用10比特表示范围0到1023也就是说SFN每10.24秒循环一次。10.24秒这个周期对一般的数据调度来说够用但对某些省电场景比如NB-IoT的水表气表上报就太短了。终端如果想睡得更久就需要一个更长的编号来对齐寻呼窗口于是H-SFN出现了。H-SFN同样是10比特范围0到1023。一个H-SFN周期包含1024个SFN周期所以完整循环周期是1024×1024×10ms约10485.76秒差不多2小时54分45秒。和GSM约3小时28分的Hyperframe周期相比长度相近思路一脉相承用更大的计数单位覆盖更长的绝对时间让同步双方在长时间尺度上有唯一的“时间坐标”。5.2 5G NR的帧结构和eDRX5G NR的无线帧仍是10毫秒SFN用10比特表示范围和LTE一致。为了支持更长的DRX周期5G在RRC空闲态和非激活态引入了eDRX寻呼超帧号PHPaging Hyperframe和寻呼时机参数配合使用。在eDRX场景下网络侧和终端先约定一个超帧号作为寻呼起点再结合小区SFN计算出具体的寻呼帧和寻呼时机。如果终端和网络对当前Hyperframe级别的时间认知不一致就会出现“网络在某个超帧发了寻呼终端还在睡觉”的情况。所以5G的核心网和基站里对时间的同步要求更高常见部署是核心网通过时间同步协议把绝对时间下发到基站基站再通过系统消息把帧级时间偏移告诉终端。从GSM到5G帧结构在简化但核心思想没变用互质的子周期构造长周期用一个长周期计数器作为同步锚点让终端可以安全地“离线”更久同时保证随时能被唤醒。5.3 一张横向对比表格维度GSM HyperframeLTE H-SFN5G NR eDRX基础单位TDMA帧约4.615ms无线帧10ms无线帧10ms中层结构多帧26/51→超帧1326帧SFN0-1023周期10.24sSFN0-1023顶层周期2048个超帧≈3h28m53s1024个SFN≈2h54m45seDRX周期可配置到数十分钟甚至更长计数器位数FN共22比特实际范围0-2715647H-SFN 10比特 SFN 10比特SFN 10比特 PH超帧参数主要用途加密、跳频、DRX、调度eDRX、寻呼、测量eDRX、寻呼、测量6. 工程的启示长周期计数器的调试经验与避坑清单6.1 长周期计数器最常见的三类坑第一类是有符号数溢出。帧号的数值范围超过了32位有符号整数完全没问题但因为帧号本身就是递增的很多人拿int32直接存到了Hyperframe边界附近回绕逻辑写得不对就会变成负数。排查方法是打印帧号时输出十六进制在一轮周期前后各取一个值对照看符号位有没有异常跳变。第二类是跨周期排序错乱。在做协议分析或者日志回放时两段日志如果跨越了Hyperframe边界按FN排序时会把后面周期的大编号排到前面或者反过来。正确做法是把FN展开成64位单调递增计数展开规则是如果当前FN小于上一个值说明跨过了回绕点当前值加上2715648。第三类是加密状态机没有在回绕点复位。A5算法按帧号生成密钥流但协议栈的实现里通常会在某处缓存“上一帧的密钥流片段”。如果帧号回绕后没有正确触发状态机更新硬件加速器拿到的初始向量就不对整个加密链路全乱。这个问题的隐蔽性很强因为单看某一帧的错误无法判断根因必须结合时间差来判断是不是回绕点。6.2 可落地的自检流程我在自己的调试流程里固定了一套自检动作单测帧号拆分还原函数至少覆盖FN0、FN1325、FN1326、FN2715647四个边界值构造一个长度为2715648的虚拟T1/T2/T3序列用脚本验证还原函数不丢不重模拟回绕场景把FN从2715647推到0检查加密模块、跳频模块、调度模块各自的状态输出在真实设备上长跑4小时观察是否在3小时28分前后出现任何异常事件日志抓包后验在回绕点前后各取一个下行帧确认FN差异为1或回绕后的0而不是中间跳变几百。这套流程看起来笨但能在上量之前干掉绝大多数“周期性掉线”问题。结尾我在实际项目中跑过一次很典型的案例设备上报周期5分钟每次上报约200字节两个半月后用户反馈“每天某个固定时间段必掉线”。排查过程冗长到让人崩溃最后怀疑到时间维度上一查发现模块内部把FN存在一个16位字段里根本没有完整支持22位帧号。换成32位变量并处理好回绕逻辑之后问题当天消失。这个经历让我对帧号体系有了极深的敬畏——无线协议里没有“无关紧要的计数变量”因为每个计数器背后都挂着一串看不见的同步依赖。如果你也是做通信协议相关工作的建议从今天开始每次打开抓包工具时多留意观察一下帧号字段把它当成和RSSI、时间戳同级别的关键线索。很多时候周期性故障的真正答案就藏在那个你一直觉得“不用看”的大计数器里。