03-Class B

6.3 Class B/C 与多播的进阶实现

本节摘要：Class B 用信标与插槽提供周期性下行，Class C 提供随时下行，多播把同一条指令同时送达一组设备。本节聚焦三类进阶机制的实现要点与开销账。位置：6.2 配齐了区域参数，本节把"随时下行"与"组播下发"落到实现。

Class B：信标与插槽的账

Class B 的节奏由网络服务器主导：每 128 秒广播一个信标（Beacon），设备据信标时刻推算自己的 ping slot（每周期内 1–128 个插槽之一）。实现要点：

1. 设备进入 Class B：接收信标 → 对齐本地时钟 → 计算插槽偏移
2. 每个周期在自己的插槽醒来接收，其余时间休眠
3. 连续丢失信标（如 3 个）→ 降级回 Class A，上报 NS
4. NS 侧：维护设备的插槽分配与下行队列，在插槽内下发
​

时间账：一个插槽的接收窗口约 10–30ms，128 秒周期内设备醒来 1 次，接收时间开销约 0.02%——Class B 的省电优势就在这里：比 Class A 多了下行机会，但接收开销仍可忽略。

Class C：持续监听的实现代价

Class C 除发射瞬间外持续接收，实现上"几乎不需要接收窗口逻辑"，但带来两个工程问题：功耗（接收电流 10mA 级，只能有源供电）与发射与接收的互斥（发射期间无法接收，NS 需避开该时段调度下行）。Class C 设备的典型场景是网关与有源中继——它们自己就是基础设施。

多播：一条指令到一组设备

多播帧用组地址（Class C 的多播地址格式）与多播密钥（组级 NwkSKey/AppSKey）发送，设备按"是否属于该组"决定是否处理。实现要点：

1. NS 创建多播组，分配组地址与密钥，通过下行消息把组成员信息下发
2. 设备保存多播地址与密钥（Flash 持久化，重启不丢）
3. NS 向组地址发送帧，组内设备各自解密、各自处理（如"全部设备切到低功率模式"）
4. 多播只支持 Class B/C 设备（Class A 的接收窗口无法对齐多播调度）
​

多播最大的工程风险是密钥管理：组密钥泄露等于整组设备被接管，更换组密钥需要重新下发并确认全部成员——生产上要有完整的密钥生命周期管理。

多播的一次完整下发流程

多播下发看起来简单，工程上有完整流程：建组（NS 创建组、分配组地址与密钥）→ 下发组成员信息（通过单播下行把组地址与密钥发到设备）→ 设备确认入组（设备持久化并回执）→ 组播发送（NS 向组地址发送，网关广播）→ 组内确认（可选：设备对关键指令回单播确认）。

NS 侧时序（伪代码）：
1. create_multicast_group(addr, key)          # 分配组资源
2. send_membership(dev_a, group_info)         # 单播下发
3. wait_ack(dev_a, JOIN_GROUP)                # 等设备确认
4. send_multicast(group_addr, payload)        # 组播发送
5. 可选：收集组内设备单播回执，统计到达率
​

工程风险集中在第 2–3 步：成员信息下发丢失或设备确认超时，设备"以为不在组里"而 NS"以为已入组"，后续组播对它就失效。实现上要做重发与状态查询，不能一次下发就完事。

Class B 的时间同步细节

Class B 的插槽计算依赖信标时间戳，实现里三个细节最容易错：信标周期的锚点——用 GPS 时间（网关授时）而不是本地时间，设备本地时钟只是外推；插槽偏移换算——从信标帧内的时戳字段换算成"下一个插槽距现在多少秒"，单位与精度都要对齐（规范用 30 秒粒度的时间步）；闰秒与时钟调整——GPS 时间的调整策略要按规范处理，否则插槽整体漂移。

易错点补充

• 多播地址与设备地址冲突：组地址与单播 DevAddr 是同地址空间，规划要预留组地址段，避免设备把自己的地址当组地址；
• Class C 设备忘记关接收：持续监听的设备在休眠时也要切回 Class A 的窗口模式，状态机要支持 A/C 切换且切换后收发正常；
• 组密钥泄露的应急路径缺失：密钥轮换流程要能在不更换设备固件的前提下完成，靠"重新下发新组密钥 + 组内确认"实现。

易错点清单

• 多播帧当单播处理：多播帧的 MIC 用组密钥计算，用 NwkSKey 验会失败，处理路径必须区分；
• Class B 降级后不通知 NS：设备信标丢失降级回 A，NS 还按 B 调度下行，导致下行全部落空，双方都要有状态同步；
• Class C 设备漏配发射屏蔽：发射期间收不到下行，NS 不知道设备的发射时段，冲突只能靠重传兜底；
• 组密钥用设备密钥代替：图省事用设备级密钥加密多播，等于把"组管理"退化成了"点对点下发"，失去多播意义。

要点回顾：Class B 用 128 秒周期与插槽换可预测下行、开销仅 0.02%；Class C 用持续监听换随时下行、只适合有源设备；多播靠组地址与组密钥实现，密钥生命周期要专门管理。网络侧机制齐了，下一章看网关与网络服务器本身怎么把这本账算清。

混合 Class 设备的调度策略

实际设备常是混合 Class：默认 Class A 省电，特定时段（如远程升级窗口）切 Class C 或 B。调度策略的工程要点：切换时机由业务决定（升级窗口、对时窗口）、切换状态要上报 NS（NS 据此调整下行调度）、切换失败要回退（信标丢失降级回 A，升级窗口超时回 A）。

混合调度示例（日周期）：
00:00–23:50  Class A：省电，按事件触发上报
23:50–23:55  Class C：固件升级窗口（业务方手动或定时触发）
23:55–24:00  回 Class A，上报升级结果
​

核心矛盾：NS 不知道设备的"计划切换"，只能在设备上报状态后调整调度——因此设备切换 Class 前必须先上行通知（如用专用端口或 MAC 命令），等 NS 确认后再切，避免下行落在错误窗口。

多播在行业场景的落地

多播最典型的落地是"批量参数下发"：几百台电表同时下发"阶梯电价切换"，单播要几百条下行，多播只要一条组播。工程落地的注意点：组规模与 Ack 风暴——组内设备同时回确认会造成上行拥塞，关键指令要错峰确认或只确认异常设备；组与区域绑定——不同区域（EU868/CN470）的组频率不同，组参数要随区域表；审计日志——多播指令涉及全组设备，下发记录要完整留存，便于追溯"谁在什么时间对哪组下了什么指令"。

易错点补充

• 多播与单播的下行队列混用：两条队列的优先级与调度逻辑不同，混用会导致组播被单播饿死或反之；
• Class B 插槽分配与设备数不匹配：NS 的插槽分配算法要按设备数扩展，设备多了插槽冲突率上升；
• 多播密钥与单播密钥混淆：加解密路径分开，多播帧误用单播密钥解析必然失败且可能触发错误处理逻辑。

本节速查

小结与速查：Class B 用 128 秒信标周期 + 插槽换可预测下行，接收开销约 0.02%；Class C 持续监听只适合有源设备；多播靠组地址与组密钥，成员下发要重发与确认；组密钥生命周期要专门管理；Class B 降级回 A 要通知 NS；多播帧的 MIC 用组密钥。