2. nRF蓝牙协议栈与互操作测试关系
做nRF蓝牙互操作测试，第一件容易踩坑的事，是把“协议栈”当成一个整体。实际上，Nordic的蓝牙实现横跨多个层次：底层是蓝牙控制器（Controller），中间是SoftDevice或nRF Connect SDK中的主机（Host）与协议栈组件，上层是应用（Application）。互操作测试失败时，问题可能出在射频链路、控制器状态机、主机协议逻辑、GATT数据库，也可能出在应用对API的误用。只有先厘清分层边界，才能把“和谁互操作、在哪一层观察、用什么证据判断”说清楚。
一、四层结构：从射频到应用
以nRF52系列为例，典型的蓝牙协议栈可以拆成四层。最底层是Controller，负责物理层与链路层：调制解调、跳频、CRC、白化、链路层状态机（Advertising、Scanning、Initiating、Connection）、加密与LL控制流程。它通过HCI接口向上提供命令、事件与ACL数据。第二层是Host，包含L2CAP、ATT、GATT、SM（安全管理）、GAP等。第三层是协议栈的“承载形态”：在传统nRF5 SDK中，Controller与Host被封装为SoftDevice，以二进制固件形式运行，应用通过SVC调用；在nRF Connect SDK中，Controller通常来自Zephyr的蓝牙Controller（如hci_rpmsg或片上Controller），Host由Zephyr Bluetooth Host提供，应用直接调用Zephyr API。第四层是Application，实现具体服务、连接管理、配对策略与业务逻辑。
二、SoftDevice与nRF Connect SDK的边界差异
SoftDevice是预编译的二进制协议栈，Controller与Host被固化在一起，应用通过SVC中断进入协议栈。它的边界非常清晰：应用不能直接访问Controller寄存器，也不能修改Host内部状态，只能通过SoftDevice API（如sd_ble_gap_adv_start、sd_ble_gatts_hvx）交互。这意味着互操作测试中，如果问题出在Host内部（例如ATT MTU协商逻辑），应用层无法直接修补，只能通过配置或规避策略处理。SoftDevice的版本与协议栈版本强绑定，测试前必须确认对端设备所支持的蓝牙核心规范版本与SoftDevice版本是否匹配。
nRF Connect SDK则把Controller和Host都作为Zephyr的组件开放出来。Controller可以是片上Controller，也可以是通过hci_rpmsg运行的独立核Controller；Host是Zephyr Bluetooth Host，源码可查、可配置。应用调用的是Zephyr的bt_* API。这种开放性带来两个测试优势：一是可以在Host层插入日志或修改行为，二是可以单独替换Controller或Host进行交叉验证。但边界也更复杂：Kconfig配置项决定了哪些协议栈功能被编译进来，例如CONFIG_BT_GATT_CLIENT、CONFIG_BT_SMP、CONFIG_BT_CTLR_DATA_LENGTH_MAX等。互操作测试前，必须核对双方的配置是否覆盖了待测特性。
三、各层互操作测试的关注点
在Controller层，互操作测试主要看链路层行为是否与对端兼容。典型场景包括：连接建立时双方对连接间隔、从机延迟、监督超时的接受范围；加密启动时LL_ENC_REQ/LL_ENC_RSP的时序；数据长度扩展（DLE）和2M PHY的协商。这些行为在空口上表现为特定的LL控制PDU序列，用nRF Sniffer抓包后可以逐条比对。如果对端设备在某个LL流程上超时或拒绝，问题通常不在应用层，而在Controller的兼容性配置。
在Host层，关注点转向协议逻辑。ATT MTU交换是最常见的互操作测试项：双方各自提出MTU，取较小值生效。如果对端设备在MTU交换后仍发送超过协商值的PDU，或者GATT客户端在服务发现时未正确处理“服务变更”指示，就会导致读写失败。SM配对流程也是高频问题区：不同厂商对配对请求中的IO能力、密钥分发字段、绑定标志的处理存在差异，测试时需要覆盖Just Works、Passkey、OOB等不同配对方式，并观察配对失败后的重试与超时行为。
在应用层，互操作测试更贴近业务。例如自定义GATT服务的特征属性（读、写、通知、指示）是否与对端客户端的预期一致；通知的发送频率是否触发对端流控；多连接场景下连接参数更新请求是否被对端接受。这些问题的根因往往不在协议栈本身，而在应用对API的调用时机和参数选择。
四、用分层思维定位互操作问题
实际测试中，一个典型的互操作故障是“手机能发现设备但连接后立即断开”。按分层排查：先用nRF Sniffer看空口，确认连接请求（CONNECT_IND）是否发出、对端是否回应；如果连接建立后很快收到LL_TERMINATE_IND，说明Controller层已建立链路但被主动断开，需要看断开原因码。如果空口正常，再看HCI日志，确认Host是否发出了正确的GAP连接参数更新请求。最后看应用日志，确认是否有业务逻辑触发了主动断开。这种“从射频到应用”的逐层定位，比盲目修改代码更有效。
五、边界划分的实践意义
明确分层边界，最终是为了回答三个问题：这个测试项应该在哪一层观察？失败时应该在哪一层找原因？修复应该在哪一层动手？对于SoftDevice方案，Host和Controller是黑盒，测试重点放在应用层配置和空口行为验证；对于nRF Connect SDK方案，Host和Controller可配置、可插桩，测试可以深入到协议栈内部。两种方案的互操作测试用例可以复用，但观察手段和修复路径不同。把这张分层图放在测试计划的第一页，能显著减少“改错地方”的时间浪费。