3. 协议栈并发架构总览

在 nRF52/nRF53 系列上谈“多协议并发”，首先要破除一个常见误解：并不是所有协议都能在同一时刻、同一射频通道上真正并行收发。nRF 的物理层只有一套 2.4 GHz 射频前端（外加 NFC 的 13.56 MHz 独立接口），所谓并发，本质上是射频资源的时分复用 + 协议栈之间的调度仲裁。理解这一点，才能理解 SoftDevice、S140/S132、802.15.4、Thread、Zigbee、蓝牙 Mesh、ESB、NFC 与 Matter 在 nRF 上究竟以什么形态共存。

一、先分清三类“共存”

把 nRF 上的协议共存拆成三个层次，思路会立刻清晰：

• 同芯片分时共存：BLE 与 802.15.4（Thread/Zigbee）共享同一个 2.4 GHz 射频，由 Nordic 的 Multiprotocol 机制按时间片切换。典型形态是 S140 + 802.15.4 组合，用于 Thread 边界路由器或 Zigbee + BLE 配网设备。
• 同芯片并行共存：BLE 与 ESB 可以真正同时工作，因为 ESB 使用 Nordic 私有 2.4 GHz 模式，且 S140 提供了 ble_radio_notification 与 ESB 的 timeslot API，让 ESB 在 BLE 空闲窗口内收发。这是 nRF 上最经典的“真并发”组合。
• 逻辑层共存：Thread、Zigbee、蓝牙 Mesh、Matter 都是应用层/网络层协议，它们并不直接驱动射频，而是跑在 802.15.4 或 BLE 之上。Matter 尤其特殊——它同时支持 Thread（over 802.15.4）和 Wi-Fi/以太网，在 nRF 上通常以 Thread + BLE 配网的形式出现。

二、协议栈在 nRF 上的分层位置

下图给出本节最核心的共存模型：从应用层到射频前端，各协议栈分别落在哪一层、通过什么接口与 SoftDevice 或 802.15.4 驱动交互。

三、S140/S132 与 802.15.4 的分时切换机制

S140 是 nRF52 系列上支持 BLE 5 的 SoftDevice，S132 是较早的 BLE 4.2/5 版本。两者都提供 sd_radio_notification_cfg_set() 接口，允许应用在射频活动前后获得回调。802.15.4 驱动（如 nrf_802154）正是利用这个回调，在 BLE 连接事件之间的空闲窗口内发起 802.15.4 收发。

实际工程中，这个切换不是“想切就切”，而是由 BLE 的连接间隔（Connection Interval）决定可用窗口。例如 BLE 连接间隔设为 100 ms，每个连接事件占用约 1–3 ms，那么剩余约 97 ms 可以分配给 802.15.4。若 Thread 需要维持 Mesh 路由，通常建议 BLE 连接间隔不小于 50 ms，否则 802.15.4 的可用时隙过碎，会导致 Thread 丢包率上升。

// 1. 配置 BLE 连接参数，留出足够空闲窗口
ble_gap_conn_params_t conn_params = {
    .min_conn_interval = MSEC_TO_UNITS(100, UNIT_1_25_MS),
    .max_conn_interval = MSEC_TO_UNITS(120, UNIT_1_25_MS),
    .slave_latency     = 0,
    .conn_sup_timeout  = MSEC_TO_UNITS(4000, UNIT_10_MS)
};

// 2. 注册射频通知回调，802.15.4 驱动据此判断何时可抢占射频
sd_radio_notification_cfg_set(NRF_RADIO_NOTIFICATION_TYPE_INT_ON_INACTIVE,
                              NRF_RADIO_NOTIFICATION_DISTANCE_800US);

// 3. 802.15.4 驱动初始化时传入 radio 仲裁回调
nrf_802154_init();
nrf_802154_radio_arbitration_set(radio_arbitration_cb);

这里的关键参数是 NRF_RADIO_NOTIFICATION_DISTANCE_800US——它表示在 BLE 射频活动结束前 800 μs 触发通知，给 802.15.4 驱动留出准备时间。如果这个值设得太小，802.15.4 可能来不及在窗口内完成收发；设得太大，又会压缩 BLE 自身的处理余量。

四、ESB 与 BLE 的并行共存

ESB（Enhanced ShockBurst）是 Nordic 的私有 2.4 GHz 协议，常用于低延迟遥控、鼠标、键盘等场景。它与 BLE 的共存方式与 802.15.4 不同：ESB 不依赖 BLE 的空闲窗口，而是通过 timeslot API 向 SoftDevice 申请一段确定性的射频时间片。在这段时间片内，BLE 会主动避让，ESB 独占射频。

这种机制的优势是 ESB 的收发时序完全可控，延迟稳定；代价是时间片需要提前申请，且不能与 BLE 连接事件重叠。实际项目中，若 ESB 用于遥控器，通常把时间片周期设为 5–10 ms，每次持续 1–2 ms，这样既能保证遥控响应，又不会明显影响 BLE 吞吐。

五、Thread、Zigbee、蓝牙 Mesh 与 Matter 的定位

这四者常被并列讨论，但它们在 nRF 上的实现层次完全不同：

• Thread：基于 802.15.4，需要 802.15.4 驱动 + Thread 协议栈（如 OpenThread）。在 nRF 上通常与 S140 分时共存，用于 Matter over Thread 设备。
• Zigbee：同样基于 802.15.4，使用 Zigbee 协议栈（如 ZBOSS）。与 Thread 互斥，同一时刻只能选一个运行在 802.15.4 之上。
• 蓝牙 Mesh：基于 BLE 广播，不占用连接态。它跑在 S140/S132 之上，与 BLE 连接可以共存，但会占用广播信道时间。
• Matter：应用层标准，底层可跑 Thread 或 Wi-Fi。在 nRF 上以 Thread + BLE 配网为主，Matter 本身不直接操作射频。

六、NFC 的特殊位置

NFC 在 nRF 上使用 13.56 MHz 频段，与 2.4 GHz 射频完全独立。这意味着 NFC 可以与 BLE、Thread、ESB 同时工作，互不干扰。nRF52 系列内置 NFC Tag 接口，常用于蓝牙配对时的“碰一碰”配网：手机靠近时读取 NFC 标签中的 BLE 配对信息，然后发起 BLE 连接。这个过程中 NFC 和 BLE 是并行工作的，不需要分时。

七、并发架构的选型判断

面对具体项目，可以按以下顺序判断：

1. 先确定主协议：是 BLE 连接、Thread Mesh，还是 ESB 低延迟？
2. 再确定是否需要第二协议：如果需要手机配网，加 BLE；如果需要 IP Mesh，加 Thread；如果需要遥控，加 ESB。
3. 检查射频冲突：两个协议是否都用 2.4 GHz？如果是，必须分时或 timeslot；如果一个是 NFC，则无冲突。
4. 核算时间预算：BLE 连接间隔、Thread 轮询周期、ESB 时间片周期是否能在同一时间轴上排开。
5. 验证：用 nRF Sniffer 或 Power Profiler Kit 观察实际射频占用和功耗，确认没有丢包或连接断开。