BLE基础回顾：协议栈、角色、状态机、连接事件与广播事件
在深入探讨nRF连接优化之前，必须先建立一套精确的BLE底层心智模型。连接间隔、MTU、功耗平衡这些参数并非孤立存在，它们全部作用于协议栈的特定层级，并受BLE链路层状态机的严格约束。本章将拆解BLE协议栈的分层架构、设备角色、链路层状态机，以及连接事件与广播事件的微观时序。理解这些基础，是后续进行参数调优和问题排查的必备前提。
协议栈分层架构与数据通路
BLE协议栈采用分层设计，每一层只对上层提供明确的服务接口，同时屏蔽下层实现细节。从nRF开发者的视角看，协议栈通常被划分为三个逻辑区域：应用层（APP）、主机层（Host）和控制器层（Controller）。在nRF52832/52840等芯片上，Controller层由芯片硬件和SoftDevice（如S140）固件共同实现，而Host层则完全由SoftDevice提供。应用层代码通过API调用与SoftDevice交互，典型的调用路径为：应用代码 → SoftDevice API → Host层处理 → HCI命令 → Controller层执行 → 射频发送。
这种分层带来的直接好处是：应用开发者无需关心射频调制、跳频算法、数据包重传等底层细节。但代价是，当我们需要优化连接参数时，必须理解这些参数在协议栈中的传递路径。例如，修改连接间隔并非直接写一个寄存器，而是通过GAP连接参数更新请求（Connection Parameter Update Request）发起，该请求需要经过Host层封装、Controller层发送，最终由对端设备确认。如果对端设备拒绝或忽略该请求，参数更新就会失败。
| 协议栈层级 | 核心职责 | 与连接优化相关的关键点 |
|---|---|---|
| 应用层 (APP) | 业务逻辑、GATT服务定义、用户数据处理 | 决定何时发起连接参数更新、MTU大小协商 |
| 主机层 (Host) | GAP/GATT/L2CAP/SM协议处理 | 连接参数存储、MTU协商逻辑、数据分片与重组 |
| 控制器层 (Controller) | 链路层状态机、射频收发、跳频、加密 | 连接事件调度、广播事件调度、功耗控制 |
设备角色与连接建立流程
BLE定义了四种设备角色：Central（中心设备）、Peripheral（外围设备）、Broadcaster（广播者）和Observer（观察者）。在连接建立之前，Peripheral通过广播信道发送ADV包，Central通过扫描信道发现该设备并主动发起连接请求（CONNECT_REQ）。连接建立后，Central和Peripheral的角色固定，但数据通信是对等的——双方都可以在连接事件中发送和接收数据。
理解角色差异对优化至关重要：Central通常负责管理连接参数，因为它发起连接请求时会在CONNECT_REQ中指定初始连接间隔、从机延迟、超时时间等参数。Peripheral如果希望修改这些参数，必须通过L2CAP层的连接参数更新请求（0x12）或GAP的Peripheral Preferred Connection Parameters（PPCP）特性来协商。在nRF开发中，Peripheral侧可以通过sd_ble_gap_conn_param_update()函数主动发起更新请求，但最终是否生效取决于Central的响应。
链路层状态机与事件调度
BLE链路层（Link Layer）定义了五种状态：Standby（待机）、Advertising（广播）、Scanning（扫描）、Initiating（发起连接）和Connection（连接）。设备在任何时刻只能处于一种状态，状态转换由硬件事件或软件命令触发。在nRF中，SoftDevice负责管理状态机，应用层通过API触发状态转换，例如调用sd_ble_gap_adv_start()进入广播状态，调用sd_ble_gap_connect()进入发起连接状态。
连接事件（Connection Event）是连接状态下最重要的时间窗口。每个连接间隔（Connection Interval）内，Central和Peripheral会在约定的信道（基于跳频算法）上交换数据包。一个连接事件内可以包含多个数据包交换（TX/RX/TX/RX...），直到双方都没有更多数据要发送，或者达到事件最大时长（txWindowSize）。连接间隔的典型范围是7.5ms到4s，而每个连接事件的实际持续时间取决于数据包长度和双方的数据量。
广播事件与扫描窗口
广播事件（Advertising Event）发生在广播状态下，Peripheral在每个广播间隔（Advertising Interval）发送一次ADV包。广播间隔范围从20ms到10.24s，步进为0.625ms。广播事件可以包含多个ADV包（在不同信道上发送），以及可选的SCAN_REQ/SCAN_RSP交互。广播事件是连接建立前的主要通信方式，也是低功耗设计中需要重点优化的对象——广播间隔越长，平均功耗越低，但被发现的时间越长。
扫描窗口（Scan Window）和扫描间隔（Scan Interval）是Central侧的参数，决定了Central在扫描状态下监听广播信道的频率和时长。扫描窗口越长、扫描间隔越短，发现设备越快，但功耗越高。在nRF中，扫描参数通过sd_ble_gap_scan_start()配置，合理的扫描参数需要根据应用场景平衡发现速度和功耗。
案例拆解：从广播到连接的完整时序分析
假设我们设计一个nRF52840心率传感器，作为Peripheral向手机（Central）发送心率数据。初始配置为：广播间隔100ms，连接间隔30ms，从机延迟0，超时时间2s。以下是实际运行中的时序分析：
- 广播阶段：设备上电后进入广播状态，每100ms在37/38/39三个信道上发送ADV包。手机扫描到ADV包后，发送SCAN_REQ，设备回复SCAN_RSP（包含设备名称和服务UUID）。
- 连接建立：手机发送CONNECT_REQ，其中包含初始连接间隔30ms、从机延迟0、超时时间2s。设备收到后进入连接状态，第一个连接事件在CONNECT_REQ发送后的1.25ms开始。
- 连接事件交互：每个30ms连接间隔内，手机和传感器交换数据。传感器在连接事件中发送心率数据（约20字节），手机回复ACK。由于数据量小，每个连接事件仅持续约1-2ms，其余时间传感器进入睡眠。
- 功耗计算：假设传感器在连接事件期间平均电流15mA（射频收发+MCU唤醒），睡眠电流2μA。平均功耗 = (1.5ms/30ms) × 15mA + (28.5ms/30ms) × 2μA ≈ 0.75mA + 1.9μA ≈ 0.75mA。如果增大连接间隔到100ms，平均功耗可降至约0.23mA。
这个案例揭示了连接间隔对功耗的直接影响。但需要注意的是，增大连接间隔会增加数据延迟——如果心率数据需要实时显示，30ms间隔可能更合适；如果是记录模式，100ms甚至200ms间隔完全可以接受。
常见误区与总结复盘
在BLE基础概念中，有几个高频误区需要特别澄清：
- 误区一：广播和连接不能同时进行。实际上，在连接状态下，设备仍然可以配置为同时进行广播（称为"连接+广播"模式），但需要谨慎管理射频调度，nRF的SoftDevice支持这种模式，但会占用额外的射频时间。
- 误区二：MTU越大越好。MTU（Maximum Transmission Unit）决定了单个数据包能承载的有效载荷大小。增大MTU可以减少数据包数量，但会增加每个连接事件的持续时间，从而增加功耗。在nRF中，默认MTU为23字节，最大可协商到247字节（取决于协议栈配置）。
- 误区三：从机延迟越大越好。从机延迟允许Peripheral跳过连接事件，但过大的从机延迟会导致Central发送的数据无法及时被接收，增加数据延迟。如果Central需要频繁下发控制命令，从机延迟应设为0或较小值。