4. 无线协议栈与认证范围界定

在nRF平台上做无线产品，协议栈选择不是“选一个能连上的协议”这么简单。它同时决定了三件事：芯片型号与射频前端能否支撑、软件SDK与协议栈组合是否可用、以及最终需要走哪一套认证路径。很多项目在样机阶段才发现选错了协议栈，导致认证范围无法覆盖，或者需要更换芯片重新设计。因此，在硬件设计启动之前，先把“协议栈—芯片—认证”三者的对应关系界定清楚，是工程交付中最省成本的一步。

一、六种协议栈在nRF平台上的定位差异

BLE、Thread、Zigbee、Matter、NB-IoT、LTE-M虽然都叫“无线协议”，但它们在nRF平台上的实现层级完全不同。BLE、Thread、Zigbee属于短距离2.4 GHz协议，运行在nRF52/nRF53/nRF54系列上，协议栈以库或SDK形式与用户应用共存于同一颗MCU。Matter不是射频协议，而是应用层规范，它必须运行在Thread或Wi-Fi之上，在nRF平台上通常表现为“Matter over Thread”，底层仍依赖802.15.4射频。NB-IoT和LTE-M属于蜂窝LPWAN，nRF平台通过nRF9160/nRF9161这类带LTE-M/NB-IoT调制解调器的SiP实现，协议栈由调制解调器固件承担，应用运行在Cortex-M33上。

这个层级差异直接决定了认证对象。短距离协议认证的是“芯片+协议栈+天线”组成的射频子系统；蜂窝协议认证的是“模组/SiP+运营商网络”的入网能力；Matter认证的是应用层互操作性与安全模型，与射频认证并行但独立。

二、协议栈选择的三条判断线

第一条线是数据速率与距离。BLE适合点对点或星型、低速率、短距离场景，典型应用是穿戴设备、遥控器、传感器。Thread和Zigbee适合多节点Mesh、中等速率、室内覆盖，典型应用是智能照明、楼宇传感。NB-IoT和LTE-M适合广域、低速率、低功耗、由运营商网络覆盖的场景，典型应用是远程抄表、资产追踪、环境监测。Matter则是在Thread或Wi-Fi之上提供统一应用层，解决“不同品牌设备互通”的问题。

第二条线是芯片资源与协议栈共存。nRF52840可以同时运行BLE和Thread，但需要合理分配RAM和Flash。nRF5340采用双核架构，网络核运行协议栈，应用核运行用户逻辑，适合Matter over Thread这类协议栈较重的场景。nRF9160将LTE-M/NB-IoT调制解调器与Cortex-M33应用核集成，协议栈由调制解调器固件承担，应用侧通过AT命令或nRF Connect SDK中的LTE链路控制接口交互。

第三条线是认证路径与市场准入。如果产品面向美国市场，短距离协议需要FCC Part 15.247，蜂窝需要GCF/PTCRB加运营商入网。如果面向欧盟，短距离协议需要ETSI EN 300 328，蜂窝需要CE/RED加运营商测试。如果产品声称支持Matter，则必须通过CSA的Matter认证，且底层Thread或Wi-Fi的射频认证不能省略。认证范围界定不清，最常见的结果是“射频过了但协议认证没过”，或者“协议认证过了但运营商不认”。

三、认证范围界定的实操方法

在实际项目中，建议用一张“协议栈—芯片—认证”对照表来锁定范围。下面给出一个可填写的示例结构，字段按项目实际需要增减。

填写这张表时，有三个容易出错的点。第一，Matter的射频认证不能单独做，它必须依附于Thread或Wi-Fi的射频认证结果，因此Thread的射频测试必须提前完成。第二，NB-IoT和LTE-M的运营商入网测试通常要求使用运营商指定的频段和功率等级，nRF9160支持多频段，但具体频段组合需要与目标运营商确认。第三，蓝牙SIG的Declaration ID需要基于合格的蓝牙射频测试报告，如果射频测试未覆盖所有蓝牙信道，Declaration ID可能被驳回。

四、协议栈共存与认证范围的边界

nRF52840和nRF5340支持多协议共存，例如BLE和Thread同时运行。这种情况下，认证范围需要明确“共存模式”是否在测试覆盖内。FCC和ETSI对多协议共存的测试要求不同：FCC通常要求分别测试每种协议的射频参数，并评估共存时的功率和杂散；ETSI EN 300 328则要求评估自适应跳频和占用时间。如果产品在共存模式下工作，认证测试必须覆盖共存场景，否则认证范围不完整。

另一个边界问题是协议栈版本与认证版本的对应。Thread 1.3和1.4的认证测试项不同，Matter 1.2和1.3的设备类型和集群要求也不同。如果产品在认证后升级协议栈版本，可能需要重新认证或做变更声明。因此，在项目计划中应锁定协议栈版本，并在认证前完成版本冻结。

最后，认证范围界定不是一次性的工作。当产品增加新协议、更换芯片、修改天线或调整功率等级时，都需要重新评估认证范围。建议在工程交付中维护一份“认证范围清单”，记录每个协议栈对应的认证状态、测试报告编号、有效期和变更记录，作为后续维护和迭代的依据。