当前位置：首页 > news >正文

(五)图文结合-详解BLE连接原理及过程

news 2025/10/27 11:21:29

BLE连接

1、BLE设备角色定义
2、连接生命周期：从广播到链路建立
- 2.1 通用访问配置文件与设备角色
- 2.2 发现过程：广播与扫描机制
- 2.3 建立连接：连接请求
3、连接的核心：参数与规则
- 3.1 什么是连接事件？
- 3.2 连接间隔：通信的心跳
- 3.3 从机延迟：一种功耗节约策略
- 3.4 监控超时：维持链路完整性
- 3.5 连接请求协议分析
- - 3.5.1 示例连接请求包（嗅探器捕获）
  - 3.5.2 连接后的操作
- 3.6 BLE的三难困境：平衡吞吐量、延迟和功耗
- - 3.6.1 蓝牙基带
  - 3.6.2 最大链路层数据有效负载吞吐量(V4.0)
  - 3.6.3 LE数据包扩展（V4.2)
  - 3.6.4 LE 2M PHY（蓝牙 v5.0）
  - 3.6.5 吞吐和功耗的平衡
4、总结
5、相关参考

1、BLE设备角色定义

为了更好地理解如何优化 BLE，首先要对BLE角色一个基本的了解。BLE设备角色主要分为两种角色，主机（Master或Central）和从机（Slave或Peripheral），当主机和从机建立连接之后才能相互收发数据。

主机：主机可以发起对从机的扫描连接。例如手机，通常作为BLE的主机设备
从机：从机只能广播并等待主机的连接。例如智能手环，是作为BLE的从机设备

另外还有观察者（Observer）和广播者（Broadcaster），这两种角色不常使用，但也十分有用，例如iBeacon，就可以使用广播者角色来做，只需要广播特定内容即可。

观察者，观察者角色监听空中的广播事件，和主机唯一的区别是不能发起连接，只能持续扫描从机。
广播者，广播者可以持续广播信息，和从机的唯一区别是不能被主机连接，只能广播数据

此外还同一个蓝牙设备在不同层级，也不尽相同。比如和人的角色差不多：你可以一位打工者、也可是老板，只是不同发展阶段叫法罢了。
在这里插入图片描述

蓝牙协议栈没有限制设备的角色范围，同一个BLE设备，可以作为主机，也可以作为从机，我们称之为主从一体（Master-Slave Integration），主从一体的好处是，每个BLE设备都是对等的，可以发起连接，也可以被别人连接，更加实用。

2、连接生命周期：从广播到链路建立

本节将详细拆解由通用访问配置文件（General Access Profile, GAP）所管理的连接前阶段。它描述了设备之间相互发现并从无连接状态过渡到面向连接状态的概率性机制。

2.1 通用访问配置文件与设备角色

建立BLE连接需要两种不对称的角色。

外围设备 (Peripheral / Advertiser): 通过广播“广播报文”（Advertising Packets）来宣告自身存在的设备。通常，这是功耗受限的设备，如传感器，被动等待连接。

中心设备 (Central / Scanner/Initiator): 主动扫描这些广播报文并发起连接的设备。通常，这是拥有更强电源的设备，如智能手机或网关。

一个关键规则是，不同角色才能能建立连接：即连接只能在中心设备和外围设备之间建立。两个中心设备无法直接连接，两个外围设备也同样无法直接连接。

2.2 发现过程：广播与扫描机制

广播 (Advertising): 外围设备在三个特定的“主广播信道”（37、38、39）上周期性地发送广播报文。这是设备可发现性的基础；没有广播，就无法建立连接。

广播间隔 (Advertising Interval): 指两次广播事件之间的时间间隔，这是一个关键参数，范围从20毫秒到10.24秒不等。系统会额外增加一个0-10毫秒的随机延迟，以防止设备间的持续冲突。

扫描 (Scanning): 中心设备在每个“扫描间隔”（Scan Interval）内，会打开一个“扫描窗口”（Scan Window）来监听广播信道。只有当扫描窗口与广播事件发生重叠时，发现过程才能成功。扫描有分为两种：主动扫描与被动扫描。

被动扫描 (Passive Scan): 中心设备仅监听广播报文，不发送任何响应。
主动扫描 (Active Scan): 中心设备在收到广播报文后，会发送一个SCAN_REQ（扫描请求）报文以获取更多信息。外围设备则会回复一个SCAN_RSP（扫描响应）报文，这使得外围设备在建立连接前就能传输额外的数据。

在这里插入图片描述

BLE中的连接建立本质上是一个概率性而非确定性的过程。发现的成功率和延迟取决于广播间隔与扫描窗口/间隔在时间上的统计性重叠。由于广播方和扫描方并不同步，开发者无法保证连接在特定时间内一定能建立。他们只能通过调整参数来影响快速连接的概率。例如，使用较短的广播间隔和连续扫描（即扫描窗口等于扫描间隔）可以最大化连接概率，但这会显著增加中心设备的功耗。这种概率性特征是设计用户体验时必须考虑的关键因素。

2.3 建立连接：连接请求

发起: 当中心设备决定连接一个正在广播的外围设备时，它会发送一个CONNECT_REQ（连接请求）报文。

连接窗口：为了接收这个请求，处于可连接模式的外围设备必须在每次发送广播报文后，立即打开一个短暂的接收（RX）窗口。

强制接受: 通常情况下，以可连接模式广播的外围设备不能拒绝连接请求，必须接受。

状态转换: 一旦成功接收到CONNECT_REQ，两个设备便进入连接状态。它们的通信将从广播信道转移到37个数据信道（0-36），并采用跳频算法来减轻干扰。如下图示意图所示。

在这里插入图片描述

广播报文本身不仅仅是一个简单的“宣告存在”的信号，它是一个兼具功耗管理和应用设计功能的关键资源。广播报文自身可以携带用户数据，例如，信标（Beacons）几乎完全在这种无连接模式下工作 。这允许中心设备（此时称为观察者）从外围设备（此时称为广播者）接收数据，而无需承担建立完整连接所需的时间和功耗开销。因此，开发者面临一个重要的架构决策：应用是否需要一个完整的双向连接，还是可以通过在广播中嵌入数据来满足需求。这个决策对于外围设备的电池寿命有着深远的影响。

3、连接的核心：参数与规则

一旦连接建立，链路的行为将由一组协商好的参数来控制。本节将分析这些参数:连接间隔、从机延迟、监控超时，并将它们视为管理性能与功耗之间基本权衡的主要调节杠杆。

3.1 什么是连接事件？

连接事件定义：连接事件 (Connection Event) 是蓝牙低功耗 (BLE) 链路层 (Link Layer) 的一个核心机制。它是指在两个已连接的设备（主机 Master 和从机 Slave）之间，为了交换数据而进行的一系列短暂的数据包收发（Packet Exchange）过程。

通俗理解：连接事件就是手机和手环约定好的、那个极其短暂的“数据收发窗口”。它们只在这个窗口时间点醒来，光速交换完数据，然后马上回去睡觉，等待下一个窗口的到来。这就是 BLE 既能保持连接，又极其省电的秘诀。
在这里插入图片描述

3.2 连接间隔：通信的心跳

连接间隔定义: 指两次连续的“连接事件”之间的时间间隔，在连接事件中，中心设备和外围设备交换数据包。该间隔以1.25毫秒为单位递增，范围从7.5毫秒到4秒。

机制: 在每个连接事件期间，设备唤醒其射频单元，交换数据，然后返回低功耗休眠状态，直到下一个事件的到来。这是BLE在连接状态下实现能效的核心机制。

控制权: 中心设备在CONNECT_REQ报文中指定初始连接间隔，但外围设备后续可以请求更改。然而，最终决定权始终在中心设备手中。

3.3 从机延迟：一种功耗节约策略

从机延迟（Slave latency）定义: 允许外围设备在没有数据要发送给中心设备时，跳过预定数量的连续连接事件。该值范围从0到499 。

目的: 在无需重新协商更长连接间隔的情况下，降低外围设备在空闲期间的功耗。

重要细节: 如果外围设备确实有数据要发送，它可以忽略延迟设置，在下一个连接事件中立即传输。但是，如果中心设备有数据要发送给外围设备，它必须等到外围设备的延迟周期结束后才能发送。

3.4 监控超时：维持链路完整性

监控超时定义: 指在两次成功接收到数据包之间所允许的最长时间，超过该时间则认为连接已丢失。该值以10毫秒为单位递增，范围从100毫秒到32秒。

规则: 为防止在使用从机延迟时发生过早的断开，超时值必须大于 $\text{Slave Latency}) \times \text{Connection Interval} \times 2$ 。

3.5 连接请求协议分析

我们可以让进一步学习连接请求包的内容（截取蓝牙官方规范文档）。
在这里插入图片描述
相关参数解释如下：

AA：访问地址
CRCInit ：包含 CRC 计算的初始化。
WinSize 和 WinOffset：均用于设置 transmitWindowSize （WinSize * 1.25 ms）和 transmitWindowOffset （WinOffset * 1.25 ms），这使得中央在传输第一个连接事件锚点的时间上具有一定的灵活性。
Interval：用于计算连接间隔（Interval * 1.25 ms），即 Central 和 Peripheral 交换数据的频率。
Latency：用于设置 connSlaveLatency （= 延迟），允许从设备/外设跳过一些连接事件以节省电量并保持更长时间的睡眠状态：
- connSlaveLatency= 0 –> 不允许从属设备跳过任何连接事件。
- connSlaveLatency= n –> 允许从站跳过 n 个连接事件。
Timeout：用于设置 connSupervisionTimeout （Timeout*10ms）的值。
ChM：包含通道映射，指示哪些射频数据通道用于数据传输。LSB 表示数据通道索引 0，位置 36 的位表示数据通道索引 36。0 表示未使用，1 表示已使用。
Hop：用于设置 hopIncrement 值（5-16 范围内的随机值）。
SCA：用于设置 masterSCA 值，该值用于确定最坏情况下 Master 的睡眠时钟精度。

3.5.1 示例连接请求包（嗅探器捕获）

以下是 Ellisys Bluetooth Tracker 嗅探器捕获的连接请求数据包的示例：
在这里插入图片描述
让我们看一下原始数据并看看它如何映射到这些细节：

现在，让我们看一下 LLData 字段：

请记住，此处显示的数据是从 LSB 到 MSB（接收器接收的数据，从左到右）。

3.5.2 连接后的操作

在这里插入图片描述
Version Exchange 版本交换

每个设备都会发送此数据包，以通知对方所使用的蓝牙版本和芯片组的制造商。
在这里插入图片描述
数据包从每个设备发送。每个数据包包含四个字段：

操作码(Opcode) ：LL_VERSION_IND，定义 PDU 类型
蓝牙版本(Bluetooth version) ：表示正在使用的蓝牙规范的版本
公司 ID(Company ID) ：包含蓝牙控制器制造商的公司标识符
实施修订 (Implementation revision)：指定蓝牙控制器实施的修订

Feature Exchange 功能交换

由于蓝牙规范版本中的并非所有功能都是强制性的（有些是可选的），因此设备之间需要相互沟通确实支持哪些特定功能。其中一个设备发送 LL_FEATURE_REQ 列出其支持的所有功能，另一个设备则以 LL_FEATURE_RSP 响应，列出其支持的功能。从蓝牙规范 5.1 版开始，有 28 个定义位来指示是否支持某项功能。下面是Nordic的蓝牙设备功能展示：
在这里插入图片描述

Exchange MTU 交换 MTU

MTU 代表最大传输单元，它定义了发送器和接收器可以处理的最大数据量以及它们可以在缓冲区中保存的数据量。规范对 MTU 值的高度没有限制，但所使用的特定堆栈可能有其自身的限制。有效 MTU 由客户端和服务器支持的 ATT MTU 最小值决定。

例如，如果客户端支持 100 字节的 ATT MTU，而服务器响应它支持 150 字节的 ATT MTU，则客户端将决定从此以后用于连接的 ATT MTU 为 100 字节。

iPhone 发送的 Exchange MTU 数据包，MTU 值为 293 字节：
在这里插入图片描述

Attribute Discovery 属性发现

每当两个设备第一次相互连接时，就会发生属性发现过程。此后，客户端可能会缓存所有属性（包括服务、特性、描述符等），以避免在下次两个设备连接时执行发现过程。如果客户端没有缓存属性，那么它每次连接到服务器时都必须执行发现过程（但这个会增加每层连接的耗时）。

属性列表将包含每个属性的键值对，其中属性句柄为键，属性类型（UUID）为值。

发现过程如下：这通常需要多个数据包，特别是如果服务器端有许多定义的服务和特性。客户端不断请求读取属性，直到收到“Attribute Not Found”错误消息，表示发现过程结束：
在这里插入图片描述
读取设备名称
客户端通常发送的另一个请求（特别是在具有 UI 元素的应用程序中）是读取设备名称。

3.6 BLE的三难困境：平衡吞吐量、延迟和功耗

3.6.1 蓝牙基带

对于蓝牙 4.0，BLE 无线电能够以每微秒 1 个符号的速度传输数据，每个符号可以编码 1 位数据。这使得原始无线电比特率为每秒 1 兆比特 ( Mbps )。但由于以下三个原因，实际的吞吐量可能达不到这个水平：

每个数据包发送之间必须有 150μs 的强制延迟，这被称为帧间间隔 ( T_IFS )。
BLE 链路层协议是可靠的，这意味着一端发送的每个数据包都必须得到另一端的确认 (ACK)。ACK 数据包大小为 80 位，因此传输时间需要 80μs 。
BLE 协议对于发送的每个数据有效载荷都有开销，因此需要花费一些时间来发送数据有效载荷的标头等。

3.6.2 最大链路层数据有效负载吞吐量(V4.0)

考虑到我们提到的有关蓝牙无线电传输的三个规则，让我们看一下传输最大尺寸 LL 数据包的过程。

A 方发送最大尺寸的 LL 数据包（ 41 字节有效负载中包含 27 字节数据），传输需要 328μs （ 41 bytes * 8 bits / byte * 1Mbps ）
B 方接收数据包并等待 T_IFS （ 150μs ）
方在 80μs 内确认收到的 LL 数据包（ 0 字节数据）
A 方等待 T_IFS 后再发送更多数据

在此时间段内，可以传输 27 个字节的实际数据，耗时 216μs 。
$(27/41)∗328μs=216μs\begin{aligned} (27/41)*328μs =216μs \end{aligned}$

这产生了以下原始数据吞吐量：

(216μs / 708μs) * 1Mbps = 305,084 bits/second = ~0.381 Mbps

3.6.3 LE数据包扩展（V4.2)

作为蓝牙核心规范 4.2 修订版的一部分，添加了一项名为 “低功耗数据包长度扩展” 的新功能 4 。这项可选功能允许设备将链路层数据包中数据有效负载的长度从 27 字节扩展到 251 字节！这意味着，现在设备可以在 265 字节的有效负载中发送 251 字节的数据，而不是在 41 字节的有效负载中发送 27 字节的数据。此外，我们可以在更少的 T_IFS 间隔内发送更多数据。让我们来看看交换最大尺寸数据包的过程：
在这里插入图片描述可以计算原始数据吞吐量，并发现这种修改使可实现的最大原始数据吞吐量提高了 2 倍以上！

251 bytes / 2500μs = 100.4 kBytes/sec = ~0.803 Mbps

3.6.4 LE 2M PHY（蓝牙 v5.0）

作为蓝牙核心规范 5.0 修订版的一部分，一项名为“LE 2M PHY” 5 的新功能被添加。您可能还记得，在上一节中，我们讨论了 BLE 无线电如何能够以 1Mbps 的比特率每微秒传输 1 个符号。此次对低功耗蓝牙物理层 (PHY) 的修订允许 2Mbps 的符号率。这意味着我们可以在一半的时间内传输每个单独的比特。但是，两次传输之间仍然需要 150μs 的 IFS。让我们来看看，在使用数据包长度扩展功能发送数据包时，这会如何影响吞吐量：
在这里插入图片描述可以计算这个吞吐量，并发现修改后的数据速度比 BLE 4.0 所能实现的原始最大数据速度提高了近 4 倍 ：

251 bytes / 1400μs = 179.3 kBytes/sec = ~1.434 Mbps

3.6.5 吞吐和功耗的平衡

这三个核心参数共同构成了一个基本的三难选择。优化其中一个指标通常会牺牲其他指标。

高吞吐量/低延迟: 需要短的连接间隔和零从机延迟。这最大化了通信机会，但也导致了最高的功耗，因为射频单元被频繁激活。
低功耗: 通过长连接间隔和/或高从机延迟实现。这最小化了射频开启时间，但增加了延迟并降低了最大吞吐量。
有效连接间隔: 当使用从机延迟时，外围设备实际的唤醒间隔可以通过公式： $Latency)\text{Connection Interval} \times (1 + \text{Slave Latency})$ 来计算。这个公式是理解从机延迟实际影响的关键。

从机延迟是一个精细的工具，主要用于在非对称数据流场景下降低外围设备的功耗，它并非一个普适的节能机制。从机延迟允许外围设备（从机）跳过连接事件以节省自身功耗。然而，中心设备（主机）仍然必须在每个连接事件中唤醒，以监听来自外围设备的潜在传输。因此，从机延迟对中心设备没有任何节能效果。此外，如果中心设备需要向外围设备发送数据，传输将被延迟，直到外围设备的休眠周期结束。综上所述，从机延迟最适用于那些外围设备不常发送数据，但一旦需要发送就必须保证低延迟（如按钮按下），同时中心设备很少向外围设备发送数据的场景。