2、BLE技术基础：协议栈架构、版本演进与核心特性
各位工程师朋友，大家好。这一章我们来啃一啃BLE的“硬核”基础。说实话，很多做物联网方案选型的朋友，往往只盯着芯片型号和功耗参数，却忽略了协议栈本身的设计逻辑。我个人习惯是，先把协议栈的“骨架”摸清楚，再去选型才不会跑偏。
这一章，我会从三个维度展开：协议栈架构（Controller、Host、Application）、版本演进（从4.0到6.0）、以及核心特性（低功耗、广播、连接、GATT/GAP）。嗯，内容不少，但都是干货。
2.1 BLE协议栈架构：三层分工
BLE协议栈，说白了就是一套软件分层规范。它把无线通信的复杂流程拆成了三个层次：Controller（控制器）、Host（主机）、Application（应用）。每一层各司其职，层与层之间通过标准接口通信。
核心要点：Controller负责物理层和链路层，Host负责逻辑链路控制和属性协议，Application就是你的业务逻辑。这三层可以跑在同一个芯片上，也可以分在两个芯片上（比如Host跑在MCU，Controller跑在蓝牙芯片）。
下面这张图，是我在项目中经常用来给团队讲解的架构图。你一看就明白了。
2.1.1 Controller（控制器层）
Controller是离硬件最近的一层。它直接操作射频硬件，负责数据的发送和接收。我个人习惯把Controller理解为“快递员”——它不管包裹里装的是什么，只负责把包裹准时送到。
- PHY（物理层）：定义无线信号的调制方式、频率、功率。BLE工作在2.4GHz ISM频段，有40个信道（37个数据信道 + 3个广播信道）。
- LL（链路层）：负责信道管理、数据包组装/解析、重传、加密。LL层定义了五种状态：Standby、Advertising、Scanning、Initiating、Connection。
我的经验：在调试射频性能时，我建议优先检查Controller层的配置。我曾经遇到一个项目，设备连接后频繁断连，折腾了两天，最后发现是LL层的连接间隔参数设得太短，导致射频来不及处理。嗯，这种坑踩过一次就记住了。
2.1.2 Host（主机层）
Host层是协议栈的“大脑”。它不直接管射频，但负责所有逻辑控制。Host层包含多个子协议，我挑几个重点说。
| 子协议 | 全称 | 核心职责 |
|---|---|---|
| GAP | Generic Access Profile | 设备发现、连接建立、广播模式、安全配对 |
| GATT | Generic Attribute Profile | 数据交互模型（Server/Client）、属性读写 |
| ATT | Attribute Protocol | 属性数据的传输、请求/响应/通知 |
| L2CAP | Logical Link Control and Adaptation Protocol | 数据封装、分段重组、多路复用 |
| SMP | Security Manager Protocol | 配对、密钥生成、加密 |
你想想看，GAP和GATT是不是经常听到？没错，它们就是BLE应用开发的核心。GAP管“怎么找到你”，GATT管“找到你之后怎么交换数据”。
2.1.3 Application（应用层）
应用层就是你的业务代码。比如一个温湿度传感器，应用层负责读取传感器数据，然后通过GATT服务把数据发给手机。说白了，这一层就是“填坑”的——把协议栈的接口和你的产品逻辑粘在一起。
注意：很多工程师在应用层直接操作LL层或L2CAP的细节，这是不推荐的。标准做法是通过GATT Profile来定义数据交互。我曾经见过一个团队，为了“省事”绕过了GATT，结果产品兼容性一塌糊涂，换了手机就连不上。
2.2 BLE版本演进：从4.0到6.0
BLE从2010年发布4.0版本到现在，已经迭代了十几个版本。每次迭代都在解决特定痛点。我个人习惯把版本演进分成三个阶段：奠基期（4.x）、提速期（5.x）、精细化期（6.0）。
| 版本 | 发布时间 | 核心新特性 | 我的评价 |
|---|---|---|---|
| 4.0 | 2010 | BLE首次引入，低功耗模式 | 开山之作，但速率低（1Mbps） |
| 4.2 | 2014 | LE Secure Connections、数据包长度扩展（251字节） | 安全性大幅提升，传输效率改善 |
| 5.0 | 2016 | 2Mbps PHY、LE Advertising Extensions、Mesh支持 | 速率翻倍，广播能力增强 |
| 5.1 | 2019 | 方向性测向（AoA/AoD）、GATT缓存 | 定位精度提升，适合室内定位 |
| 5.2 | 2020 | LE Audio（LC3编码）、同步信道 | 音频传输革命，低功耗音频 |
| 5.3 | 2021 | 连接子速率更新、信道分类增强 | 连接稳定性优化，功耗进一步降低 |
| 5.4 | 2023 | 带响应的周期性广播（PAwR）、加密广播数据 | 适合电子货架标签等大规模广播场景 |
| 6.0 | 2024 | 信道探测（高精度测距）、LL扩展、增强的音频功能 | 厘米级定位，BLE开始挑战UWB |
选型建议：如果你的产品只需要简单的数据传输（如温湿度计），4.2或5.0完全够用。如果你要做音频（如助听器、TWS耳机），至少选5.2。如果你要做高精度室内定位，5.1或6.0是必须的。别盲目追新，够用就好。
2.3 BLE核心特性
BLE之所以能统治物联网，靠的就是这几个核心特性。我一个个拆开讲。
2.3.1 低功耗
低功耗是BLE的“灵魂”。为什么BLE能做到低功耗？说白了，就是“能睡就睡”。BLE设备大部分时间处于睡眠状态，只在需要发送或接收数据时短暂唤醒。
- 连接间隔：设备之间按固定间隔通信（如100ms），其余时间射频关闭。间隔越长，功耗越低，但延迟越大。
- 广播间隔：广播包发送的间隔（如1秒一次），间隔越长越省电。
- 占空比：BLE的占空比极低，典型场景下平均电流只有几微安到几十微安。
我的经验：在调试功耗时，我建议用电流探头抓实时波形。我曾经遇到一个项目，理论计算功耗是10μA，实测却到了50μA。查了半天，发现是广播间隔设得太短，而且广播数据里塞了太多无用字段。嗯，优化后降到了12μA。
2.3.2 广播
广播是BLE设备“刷存在感”的方式。设备在三个广播信道（37/38/39）上周期性发送广播包，告诉周围设备“我在这里”。
- 传统广播：4.0时代的方式，广播包最大31字节。
- 扩展广播：5.0引入，广播包可以更大（最多1650字节），且支持周期性广播。
- 带响应的周期性广播（PAwR）：5.4引入，广播设备可以接收响应，适合电子货架标签等场景。
2.3.3 连接
连接是BLE设备之间建立稳定通信链路的过程。连接由Master（中央设备）发起，Slave（外围设备）响应。
- 连接建立：Master扫描到广播包后，发送连接请求，双方协商连接参数（间隔、延迟、超时等）。
- 连接参数：连接间隔（7.5ms~4s）、从机延迟（0~499）、监督超时（100ms~32s）。
- 连接状态：连接后，设备可以交换数据，也可以随时断开。
避坑指南：我曾经在项目中遇到一个问题：设备连接后，手机端显示已连接，但设备端却收不到数据。后来发现是连接参数协商失败——设备端不支持手机端请求的连接间隔。解决办法是让设备端在广播包中广播自己支持的连接参数范围，或者在连接请求后主动更新参数。
2.3.4 GATT / GAP
这两个协议是BLE应用开发的核心。我再强调一下它们的区别。
| 特性 | GAP | GATT |
|---|---|---|
| 角色 | Broadcaster、Observer、Peripheral、Central | Server、Client |
| 职责 | 设备发现、连接建立、广播配置 | 数据交互、属性读写、通知/指示 |
| 数据模型 | 广播数据、扫描响应 | Service、Characteristic、Descriptor |
| 典型场景 | 设备配对、连接管理 | 读取传感器数据、下发控制指令 |
举个例子：你打开手机蓝牙，扫描到周围设备，这是GAP在干活。你点击连接，然后读取设备的心率值，这是GATT在干活。两者缺一不可。