(九）一文吃透 BLE：从低功耗原理到协议栈与实战概念

文章目录

激励自己学习的话
1、什么是BLE？
2、为什么BLE这么省电？
[3、 BLE的协议栈分层](#3、 BLE的协议栈分层)
- [3.1 控制器部分 (Controller)](#3.1 控制器部分 (Controller))
- - [3.1.1. 物理层 (Physical Layer, PHY)](#3.1.1. 物理层 (Physical Layer, PHY))
- [3.1.2. 链路层 (Link Layer, LL)](#3.1.2. 链路层 (Link Layer, LL))
- [3.2 主机部分 (Host)](#3.2 主机部分 (Host))
- - [3.2.1 主机控制接口 (Host Controller Interface, HCI)](#3.2.1 主机控制接口 (Host Controller Interface, HCI))
  - [3.2.2 逻辑链路控制与适配协议 (L2CAP)](#3.2.2 逻辑链路控制与适配协议 (L2CAP))
  - [3.2.3 安全管理器 (Security Manager, SM)](#3.2.3 安全管理器 (Security Manager, SM))
  - [3.2.4 属性协议 (Attribute Protocol, ATT)](#3.2.4 属性协议 (Attribute Protocol, ATT))
- [3.3 配置文件与应用层 (Profiles & App)](#3.3 配置文件与应用层 (Profiles & App))
- - [3.3.1 通用属性配置文件 (Generic Attribute Profile, GATT)](#3.3.1 通用属性配置文件 (Generic Attribute Profile, GATT))
  - [3.3.2 通用访问配置文件 (Generic Access Profile, GAP)](#3.3.2 通用访问配置文件 (Generic Access Profile, GAP))
[4、 BLE设备的状态和角色](#4、 BLE设备的状态和角色)
- [4.1 五种主要状态](#4.1 五种主要状态)
- [4.2 BLE设备的角色](#4.2 BLE设备的角色)
- [4.3 为什么这样设计？](#4.3 为什么这样设计？)
5、BLE连接流程的关键概念
- [5.1 广播包和扫描响应](#5.1 广播包和扫描响应)
- [5.2 扫描间隔和扫描窗口](#5.2 扫描间隔和扫描窗口)
- [5.3 连接参数](#5.3 连接参数)
- [5.4 GATT（通用属性配置文件）结构](#5.4 GATT（通用属性配置文件）结构)
- - [5.4.1 服务（Service）](#5.4.1 服务（Service）)
  - [5.4.2 特征（Characteristic）](#5.4.2 特征（Characteristic）)
  - [5.4.4 Notification vs Indication（通知 vs 指示）](#5.4.4 Notification vs Indication（通知 vs 指示）)
  - [5.4.5 描述符（Descriptor）](#5.4.5 描述符（Descriptor）)
- [5.5 MTU（最大传输单元）](#5.5 MTU（最大传输单元）)
- - [5.5.1 为什么默认只有20字节有效数据？](#5.5.1 为什么默认只有20字节有效数据？)
  - [5.5.2 MTU协商](#5.5.2 MTU协商)
- [5.6 配对与绑定](#5.6 配对与绑定)
- - [5.6.1 配对（Pairing）](#5.6.1 配对（Pairing）)
  - [5.6.2 绑定（Bonding）](#5.6.2 绑定（Bonding）)
[6、 BLE的低功耗工作机制总结](#6、 BLE的低功耗工作机制总结)
[7、实际应用场景](#7、实际应用场景)
8、为了系统学习BLE可阅读下面文章

激励自己学习的话

真正掌握 BLE，不在于记住多少术语，而在于你是否理解了每一次"唤醒"和"睡眠"背后的设计取舍。

1、什么是BLE？

BLE （Bluetooth Low Energy，低功耗蓝牙 ）是由蓝牙技术联盟（Bluetooth SIG）在蓝牙 4.0 规范中引入的一种短距离、低功耗无线通信协议 。它与传统的"经典蓝牙"（Bluetooth Classic）虽然都是在通用的2.4 GHz ISM频段，但通过精妙的功耗管理设计：在物理层、连接机制和应用场景上有本质区别。使得BLE搭载小型电池的设备可以连续工作数月甚至数年。BLE广泛应用于智能手环、健康监测设备、信标（iBeacon）、医疗仪器等物联网领域。

2、为什么BLE这么省电？

BLE实现超低功耗的核心原理包括：

频谱利用的优化：减少广播信道：经典蓝牙在 Inquiry / Paging 过程中需要在大量跳频信道上完成发现与同步，而BLE只使用3个广播信道（37、38、39）
- BLE 的做法：将 40 个 RF 信道中的 37、38、39 定为专用广播信道。这三个信道巧妙地避开了 Wi-Fi 最常用的信道中心频率，减少了干扰造成的重传。
- 节能原理：相比经典蓝牙在多跳频信道上反复同步，BLE 通过将设备发现限定在 3 个固定广播信道，并结合可配置的扫描窗口与广播间隔，显著减少了设备发现阶段的射频活跃时间与扫描复杂度。
报文结构的精简：缩短射频开启时间：射频（RF）开启瞬间的电流通常在 5mA~15mA 之间，是功耗的核心大头。
- 数据对比：相比经典蓝牙较长的同步与数据交互过程，BLE 报文结构更精简，在短数据交互场景下，单次射频活动时间可控制在 1 ms 量级。
- 节能原理 ：能量消耗 E = P ⋅ t E = P \cdot t E=P⋅t。在功率 P P P 相当的情况下，时间 t t t 射频开启时间显著缩短，使得单次通信任务的能耗成数量级下降。
极低的占空比：深度睡眠机制 ：BLE采用Duty-Cycle（占空比）设计，设备大部分时间处于睡眠状态，只在需要时才打开射频；BLE 的设计哲学是"非必要不工作"。
- Duty-Cycle 设计 ：设备在两次通信活动（Event）之间，会进入深度睡眠模式（Deep Sleep），此时电流仅为 μ A \mu A μA（微安）级别。
- 节能原理：通过精确的时钟同步，设备只在预定的几毫秒内"惊醒"处理数据，其余绝大部分时间处于睡眠状态。。
灵活的连接参数：优化保持频率：BLE 通过 Slave Latency 与 Connection Interval 等连接参数机制，允许设备在无数据时跳过多个连接事件，从而降低维持连接的功耗。
- 机制：在没有数据传输时，从机可以跳过一定次数的连接事件而不掉线。比如，手机每 10ms 问一次"在吗？"，设备可以每 500ms 才回一次。
- 节能原理：这种"减速呼吸"模式极大降低了维持链路活跃所需的空闲通信次数。
毫秒级状态转换：快速连接：经典蓝牙（BR/EDR）的 Inquiry 与 Paging 过程依赖复杂的跳频同步与时钟捕获，建立连接时延通常在数百毫秒甚至秒级
- BLE 优势： BLE 采用面向广播的发现机制，在参数优化条件下，从扫描命中广播到完成连接建立，最快可在数十毫秒级完成，显著快于经典蓝牙。
- 节能原理： BLE 通过短时广播、快速建链与连接事件调度，实现"按需唤醒、快速传输、立即休眠"的低占空比工作模式，从而显著降低待机功耗。

3、 BLE的协议栈分层

蓝牙低功耗（Bluetooth Low Energy, BLE）的设计哲学可以概括为：分层解耦、极简高效、按需唤醒。为了实现极低的功耗和广泛的兼容性，BLE 采用了类似 OSI 模型的层次化结构。这种设计使得开发者可以只关注应用逻辑，而不必担心底层的无线电波是如何跳频的。

将 BLE 协议栈分为三个核心部分：控制器（Controller）、主机（Host）以及应用层（App）。

3.1 控制器部分 (Controller)

底层硬件相关，负责把比特流通过无线电发射出去。

3.1.1. 物理层 (Physical Layer, PHY)

设计目标 ：将数字信号转化为 2.4GHz 的射频信号。
核心功能 ：定义了频段（40个信道）、调制方式（GFSK）以及发射功率。
通俗解释 ："修路"。它规定了路有多宽，车（信号）要在什么样的频率上跑，是无线通信的物理基石。

3.1.2. 链路层 (Link Layer, LL)

设计目标 ：管理射频状态，确保数据包准确到达。
核心功能 ：控制设备处于扫描、广播、连接或待机状态；负责数据包的确认、重传及校验（CRC）；管理跳频逻辑以避开干扰。
通俗解释 ："交通警察"。它决定了什么时候可以发车（广播），什么时候该收车（进入睡眠省电），并确保货物（数据）没有在路上丢包。

3.2 主机部分 (Host)

逻辑处理的核心，通常运行在微控制器（MCU）的软件协议栈中。

3.2.1 主机控制接口 (Host Controller Interface, HCI)

设计目标 ：实现主机与控制器之间的标准化通信。
核心功能 ：这是 Host 和 Controller 之间的桥梁。它允许不同厂家生产的蓝牙芯片（Controller）与不同的软件堆栈（Host）进行互通。
通俗解释 ："标准翻译官"。不管底层硬件是哪家的，只要通过 HCI 接口，上层软件就能发号施令。

3.2.2 逻辑链路控制与适配协议 (L2CAP)

设计目标 ：数据分片与多路复用。
核心功能 ：将上层的大块数据"切碎"成适合底层传输的小包，或者将接收到的小包"组装"起来。
通俗解释 ："快递打包员"。大件物品塞不进信箱，L2CAP 负责把它拆散装进小盒子，到了目的地再拼好。

3.2.3 安全管理器 (Security Manager, SM)

设计目标 ：提供配对、鉴权和加密功能。
核心功能 ：生成和分配密钥，确保数据传输不被窃听。
通俗解释 ："保镖/锁匠"。负责给数据加锁，并确认对方是不是"自己人"，防止黑客中途拦截信息。

3.2.4 属性协议 (Attribute Protocol, ATT)

设计目标 ：定义了数据交互的小型单元（Attribute）。
核心功能 ：采用客户端/服务器（Client/Server）结构。它规定了如何读、写、通知某个特定的数据值。
通俗解释 ："填表单"。它规定了每一个数据都有一个唯一的"编号"（Handle），你想看某个数据，就报上它的编号。

3.3 配置文件与应用层 (Profiles & App)

3.3.1 通用属性配置文件 (Generic Attribute Profile, GATT)

设计目标 ：将数据结构化，方便应用层调用。
核心功能 ：这是开发者最常接触的一层。它将 ATT 的属性组合成"服务（Service）"和"特征（Characteristic）"。比如，"心率服务"里包含了"心率测量值"这个特征。
通俗解释 ："图书馆目录"。它把零散的数据整理成一本本书（服务）和章节（特征），让你一眼就能找到想要的信息。

3.3.2 通用访问配置文件 (Generic Access Profile, GAP)

设计目标 ：定义设备的外部行为。
核心功能 ：决定设备是广播者（Beacon）、扫描者，还是处于连接状态的从机或主机。它负责设备如何被"发现"以及如何"连接"。
通俗解释 ："身份名片"。它决定了设备在空气中如何介绍自己（"我是一个心率计"），以及是否允许别人来连接。

4、 BLE设备的状态和角色

4.1 五种主要状态

从链路层（Link Layer）的角度看，BLE 设备在任意时刻通常处于以下五个状态之一：
1. 广播态（Advertising State）

设备周期性地发送广告包，宣告自己的存在。外围设备处于此状态时，能被中心设备发现。通俗解释：大喇叭喊话："我在这里，谁要连我？"
2. 扫描态（Scanning State）

设备监听广播信道，接收其他设备发出的广告包，用于发现附近的BLE设备。通俗解释：收音机听广播，寻找附近感兴趣的设备。
3. 发起态（Initiating State）

设备准备主动向特定设备发起连接。当收到匹配的广告包时，发起态设备会发送连接请求。通俗解释：看准了某个目标，准备出手"表白"（建立连接）。
4. 连接态（Connection State）

两个设备成功建立连接后进入此状态，可以进行有连接的数据交互。通俗解释：通话中，双方保持定期的心跳包交换。
5. 待机态（Standby State）

设备不发送也不接收任何数据，处于休眠或关机边缘，最省电的状态。

4.2 BLE设备的角色

BLE定义了两种对立的设备角色，分别在链路层和应用层体现：

Master/Slave（链路层角色）

Master（主设备）：发起连接、控制连接参数、确定通信时序，可同时连接多个从设备
Slave（从设备）：被动接受连接，响应主设备指令

在 Bluetooth Core Spec 5.x 中已逐步推荐使用：Central / Peripheral或 Initiator / Advertiser / Scanner。

Central/Peripheral（GAP层角色）

Central（中心设备）：主动扫描寻找外围设备，发起连接请求，通常是手机、平板等
Peripheral（外围设备）：广播自身存在，等待中心设备连接，通常是可穿戴设备、传感器等

Broadcaster/Observer（广播相关角色）

Broadcaster（广播者）：周期性广播数据，无需建立连接，适用于iBeacon场景
Observer（观察者）：监听广播数据，被动接收不建立连接

Server/Client（GATT应用层角色）

Server（服务器）：存储和提供服务与特征，响应客户端请求并主动发送通知
Client（客户端）：发现服务，读取或写入特征值，订阅通知和指示

通常，外围设备充当GATT服务器 ，提供数据服务；中心设备充当GATT客户端，使用这些服务。

提示：在最新的蓝牙规范中，一个物理设备可以同时扮演多个角色（Multi-role）。例如，一个手机既可以是连接手表的 Central，也可以同时作为 Broadcaster 告诉其他设备它的存在。

4.3 为什么这样设计？

这种"状态"与"角色"分离的设计，核心目的在于解决功耗与资源的不对称性。

功耗非对称性 (Power Asymmetry)

外设（Peripheral）负责省电：外设通常是电池供电。通过被动等待（广播状态），它可以大部分时间处于深度睡眠。只有在主机发起连接请求时，它才需要醒来。
- 主机（Central）负责出力：手机或网关通常电量充足。主机需要频繁地扫描（开启接收机，非常耗电）来发现外设。
- 目的：让最脆弱的设备（外设）尽可能长寿。
复杂度非对称性 (Complexity Asymmetry)

外设逻辑简单：它只需要按照固定的间隔发包（广播）和收包（连接事件）。
- 主机逻辑复杂：主机需要维护扫描列表、处理多个连接、协调不同外设的通信时序。
- 目的：降低传感器终端的硬件成本和软件开发难度。
连接的确定性

通过将状态划分为"广播 -> 发起 -> 连接"，BLE 确保了两个原本互不相识的设备能够在噪声纷纭的 2.4GHz 频段中，通过跳频（Frequency Hopping）和时间同步，建立起一个抗干扰能力极强的确定性连接

也可以这样理解，状态是微观的 ：描述射频芯片当前的电信号行为。角色是宏观的：描述设备在业务逻辑中的定位。在实际开发 Nordic 项目时，你会发现 bt_le_adv_start() 是在切换到广播状态，而将设备配置为 BT_GAP_ROLE_PERIPHERAL 则是定义了它的身份。

5、BLE连接流程的关键概念

5.1 广播包和扫描响应

BLE设备通过广告包向外宣布。广告包主要包含两个部分：
广告包（Advertising Data）

设备必须发送的基础广告包，包含设备地址（6字节）和广告数据（0～31字节）。广告数据由多个AD Structure（广告数据结构） 组成，每个AD结构包括：

Length：后续数据长度
AD Type：数据类型标识符（如Flags、Local Name等）
AD Data：具体数据内容[7]

扫描响应（Scan Response）

设备可选的补充广告包。当扫描设备发送扫描请求（SCAN_REQ）时，广播设备会回复扫描响应，提供更多信息（如设备名称）。

5.2 扫描间隔和扫描窗口

这两个参数控制中心设备发现外围设备的效率：
扫描窗口（Scan Window）

设备一次扫描持续的时间宽度，在此期间设备保持接收器开启。单位为0.625ms。

扫描间隔（Scan Interval）

两个连续扫描窗口起始时间之间的间隔，包括扫描进行的时间和扫描休息的时间。单位为0.625ms。

占空比概念

如果设置扫描间隔为100ms，扫描窗口为10ms，则占空比为10%（10÷100）。占空比越高，发现设备速度越快，但功耗越大；占空比越低，节能效果越好，但发现设备的延迟越长。

5.3 连接参数

两个BLE设备建立连接后，通过以下参数控制通信行为：
连接间隔（Connection Interval, CI）

Master周期性向Slave发送数据的时间间隔，单位为1.25ms。范围为6～3200（即7.5ms～4.0s）。

连接建立后，Master和Slave都严格按照CI定时同步：Master在定时发送数据包后，150微秒后Slave会切换到发送状态，回复自己的数据；Master则切换到接收状态。

从机延迟（Slave Latency）

允许Slave在没有待发送数据时，跳过多个连接间隔而不回复Master。范围为0～499，值越大节能效果越好。

例如，若Slave Latency = 9，Slave可以每9个连接间隔才回复一次Master，在前8个间隔期间保持睡眠状态。

监督超时（Supervision Timeout）

两个成功连接事件之间的最大允许时间间隔（单位10ms）。若超过此时间未发生连接事件，设备自动断开连接。

5.4 GATT（通用属性配置文件）结构

GATT是BLE应用层最重要的协议，定义了数据的组织和交互方式：

5.4.1 服务（Service）

服务是一组相关功能的集合，代表设备提供的具体能力。例如，心率监测设备可能提供"心率服务"。

每个服务由一个128位的UUID（通用唯一识别符） 唯一标识。蓝牙标准组织预定义了许多标准服务（如心率服务UUID为0000180D），企业也可定义自定义服务使用128位UUID。

5.4.2 特征（Characteristic）

特征是服务中的具体数据项，包含一个数值和多个描述符。例如，心率服务内包含"心率值"特征。

每个特征有以下关键属性：
数据类型与值：定义传输的数据类型（如字节、整数、字符串）和长度

属性（Properties）：定义对特征的操作权限，主要包括：

Read（读）：客户端可读取特征值
Write（写）：客户端可修改特征值
Notify（通知）：服务器主动向客户端推送数据（无确认机制）
Indicate（指示）：服务器主动向客户端推送数据（需客户端确认）
Write Without Response（写不需响应） ：客户端写入数据但不等待服务器响应

5.4.4 Notification vs Indication（通知 vs 指示）

这是BLE中容易混淆的两个概念：

特性	Notification（通知）	Indication（指示）
确认机制	无，不需要回复	有，客户端必须回复确认
可靠性	不可靠，可能丢失	可靠，确保送达
速度	快速，立即发送	较慢，需等待确认
使用场景	对数据实时性要求高，允许丢失（如加速度计数据）	对数据可靠性要求高（如警报、关键状态变化）
发送限制	无特殊限制	Server一次只能发送一条Indication，必须等到确认后才能发送下一条

5.4.5 描述符（Descriptor）

描述符 是特征的附加信息，为特征提供元数据和配置选项。最常见的描述符是CCCD（Client Characteristic Configuration Descriptor，客户端特征配置描述符） ，用于客户端启用/禁用Notification或Indication功能。

5.5 MTU（最大传输单元）

MTU（Maximum Transmission Unit） 指单次数据传输中允许的最大字节数。

5.5.1 为什么默认只有20字节有效数据？

BLE规范定义默认MTU为23字节，这23字节包含：

ATT opcode：1字节（协议操作码）
Handle：2字节（属性句柄）
实际数据：剩余20字节

之所以设定为23字节，是为了兼容功能较弱的BLE设备，防止内存占用过大。

5.5.2 MTU协商

两个设备连接后，可通过MTU交换机制协商更大的MTU值。MTU 交换采用请求/响应流程，最终通信 MTU 由双方支持的最小值决定，属于隐式协商：

中心设备向外围设备发送MTU请求（例如150字节）
外围设备回复自己支持的MTU（例如23字节）
双方选择较小的值（23字节）作为后续通信的MTU

在Android 5.1及以上版本，应用可通过requestMtu()方法请求修改MTU，突破20字节的限制。

5.6 配对与绑定

5.6.1 配对（Pairing）

配对是两个BLE设备首次建立信任关系的过程，包括：

交换配对能力和安全需求
设备身份认证
生成长期密钥（LTK）
建立加密连接

5.6.2 绑定（Bonding）

绑定是配对的延伸，指设备将配对产生的密钥永久保存到本地存储器。

设备下次重新连接时，可跳过耗时的配对流程，直接使用保存的密钥进行加密，大幅提高连接速度。例如手机与蓝牙耳机配对后再次连接时，只需几秒就能自动连接。

6、 BLE的低功耗工作机制总结

BLE的低功耗表现来自多个方面的精巧设计：

方面	BLE	经典蓝牙
功耗	极低，几月续航	较高，数周续航
数据速率	1 Mbps（LE 1M），2 Mbps（LE 2M）	BR(1 Mbps)， EDR(2 Mbps / 3 Mbps )
延迟	≥7.5ms（可调）	几十 ms ～百 ms（与 Profile 相关）
连接范围	10--50m（LE Coded 可更远）	10--30m（Class 1 可更远）
广播信道	3 个专用广播信道（37/38/39）	跳频 Inquiry/Paging

BLE通过周期性开/关射频的设计，在较长时间内只保持短暂的通信窗口，其余时间设备处于深度睡眠。结合灵活的连接参数配置（如从机延迟），设备能够以最低功耗完成必要的数据交互。

BLE 与经典蓝牙的差异，本质不在"谁更快"，而在于一个为低占空比省电通信而生，一个为持续高吞吐连接而设计。

7、实际应用场景

Health Thermometer（健康体温计）：定期读取温度值，使用Notify推送变化

Fitness Tracker（健身追踪器）：连续监测步数和心率，通过Indicate发送警报

BLE Beacon（信标）：持续广播位置信息，用于室内导航和资产定位

Smart Home（智能家居）：通过写入特征值控制灯光、温度等，利用长连接间隔和从机延迟降低功耗

BLE的多样化应用正是源于其灵活的协议设计和极低的功耗需求，使其成为物联网领域的标准通信协议。

8、为了系统学习BLE可阅读下面文章

(一）蓝牙的发展历史
 (二）蓝牙架构概述-通俗易懂
 (三）BLE协议栈协议分层架构设计详解
 (四）BLE的广播及连接-通俗易懂
 (五）图文结合-详解BLE连接原理及过程
 (六）BLE安全指南：别让"配对降级"和硬件I/O毁了安全等级（BLE SMP）
(七) 深入探讨BLE MAC 地址的隐私博弈
 (八）BLE MTU 全栈解析：从 20 字节瓶颈到 160KB/s
(九）Nordic实战--保姆级教程：nRF Connect SDK 开发环境搭建全指南