GAP规范【9.3. Connection modes and procedures】

这部分是 GAP 规范里"连接模式与连接过程"的总说明 ，它不是在讲某一个具体连接流程，而是在告诉你：GAP 层定义了设备如何建立连接、连接后如何更新参数、以及如何终止连接。

一、这部分内容想表达什么？

核心意思可以概括为：

Connection modes and procedures 用来让一个设备和另一个设备建立连接。

设备连接成功后，连接参数还可以通过 Connection Parameter Update procedure 进行更新。

已连接设备也可以通过 Terminate Connection procedure 终止连接。

不同角色的设备，需要支持哪些连接模式和连接过程，会在 Table 9.3 中规定。

也就是说，这一节是一个入口说明，后面会具体展开：

哪些设备可以发起连接；
哪些设备可以被连接；
连接建立后参数如何更新；
连接如何断开；
不同 GAP 角色需要支持哪些能力。

二、关键信息 1：Connection modes and procedures 是用来建立连接的

原文：

The connection modes and procedures allow a device to establish a connection to another device.

意思是：

连接模式和连接过程允许一个设备与另一个设备建立连接。

这里要注意两个词：

1. Connection mode：连接模式

连接模式更偏向"设备是否允许别人连接自己"。

例如在 BLE 里，一个外设广播时，可以表现为：

复制代码

不可连接广播
可连接广播
定向可连接广播

从 GAP 角度看，外设是否处于某种"可连接模式"，决定了其他设备能不能基于它的广播来建立连接。

比如：

复制代码

外设 Peripheral：
我现在正在广播，并且允许中心设备连接我

这就属于一种连接相关的 mode。

2. Connection procedure：连接过程

连接过程更偏向"设备主动去建立连接的行为"。

比如中心设备扫描到某个外设后，决定连接它，这就是一个连接过程。

可以理解为：

复制代码

中心设备 Central：
我扫描到了目标设备，现在我要发起连接

所以二者可以简单区分为：

复制代码

Connection mode：
偏被动，描述设备是否处于可被连接的状态。

Connection procedure：
偏主动，描述设备如何去发起连接。

三、关键信息 2：连接建立后，连接参数可以更新

原文：

When devices are connected, the parameters of the connection can be updated with the Connection Parameter Update procedure.

意思是：

当设备已经连接后，连接参数可以通过连接参数更新过程进行修改。

这里的重点是：BLE 连接不是建立后就一成不变的。

连接建立时会有一组连接参数，例如：

复制代码

Connection Interval：连接间隔
Peripheral Latency：从设备延迟
Supervision Timeout：监督超时时间

连接成功之后，这些参数可以根据业务需要调整。

例如：

场景 1：刚连接时需要快速通信

刚连接成功时，可能需要发现服务、读取特征值、开启 Notify，所以希望连接间隔短一点：

复制代码

连接间隔短
通信响应快
功耗相对高

场景 2：稳定连接后只需要低频通信

如果后面只是偶尔同步一点数据，就可以把连接间隔调大：

复制代码

连接间隔长
通信响应慢一点
功耗更低

所以 Connection Parameter Update procedure 的作用就是：

在连接已经存在的情况下，动态调整连接参数，以平衡通信速度、延迟和功耗。

四、关键信息 3：连接可以被终止

原文：

The connected device may terminate the connection using the Terminate Connection procedure.

意思是：

已连接的设备可以通过终止连接过程来断开连接。

也就是说，BLE 连接不是只能靠超时断开，而是可以主动断开。

例如：

复制代码

中心设备主动断开外设
外设主动断开中心设备

常见原因包括：

复制代码

用户主动断开
设备进入低功耗
业务完成
连接异常
权限不满足
参数协商失败

这里的 Terminate Connection procedure 就是 GAP 层描述的连接终止过程。

五、关键信息 4：不同角色要支持的连接能力不同

原文：

The requirements for a device to support the connection modes and procedures are defined in Table 9.3.

意思是：

设备需要支持哪些连接模式和连接过程，会在 Table 9.3 中定义。

这一句很重要。

因为 BLE 设备不是所有角色都必须支持所有连接能力。

比如：

复制代码

Peripheral：
通常需要支持被连接相关的模式。

Central：
通常需要支持主动发起连接相关的过程。

也就是说，Table 9.3 会告诉你：

复制代码

如果设备是 Broadcaster，需要支持哪些能力？
如果设备是 Observer，需要支持哪些能力？
如果设备是 Peripheral，需要支持哪些能力？
如果设备是 Central，需要支持哪些能力？

这部分不是从实现细节角度讲，而是从 GAP 角色能力要求角度讲。

六、关键信息 5：设备支持多个角色时，要按当前角色满足对应要求

原文：

These requirements refer to the specific role a device is operating in. Devices supporting multiple roles shall support the specified modes and procedures for a given role while operating in that role.

意思是：

这些要求是针对设备当前正在扮演的具体角色而言的。如果一个设备支持多个角色，那么它在某个角色下运行时，就必须支持该角色要求的模式和过程。

这个点对实际开发很重要。

比如一个手机 App 可能既可以做 Central，也可以做 Peripheral：

复制代码

手机作为 Central：
扫描外设、连接外设、发现服务、读写特征值。

手机作为 Peripheral：
自己广播、等待其他中心设备连接。

那么它不能简单说"我支持 BLE 连接"，而是要看它当前处于什么角色。

如果当前作为 Central，就要满足 Central 对应的 connection procedures。

如果当前作为 Peripheral，就要满足 Peripheral 对应的 connection modes。

七、结合 BLE 实际开发理解

可以把这部分内容理解成下面这张逻辑图：

复制代码

GAP Connection modes and procedures
│
├── 建立连接
│   ├── 设备是否允许被连接：Connection mode
│   └── 设备是否主动发起连接：Connection procedure
│
├── 连接后参数更新
│   └── Connection Parameter Update procedure
│
├── 连接终止
│   └── Terminate Connection procedure
│
└── 角色能力要求
    ├── Broadcaster
    ├── Observer
    ├── Peripheral
    └── Central

对于你现在学习 LE GAP，重点不是马上陷入 Link Layer 的 CONNECT_IND / AUX_CONNECT_REQ 细节，而是先搞清楚：

复制代码

GAP 是从"角色"和"过程"的角度定义连接行为；
Link Layer 才是从"空口包"和"状态机"的角度真正执行连接。

八、这一节学习时最应该抓住的点

这部分可以重点记住这句话：

GAP 的 connection modes and procedures 不是单纯讲"怎么发连接包"，而是定义了不同 GAP 角色在建立连接、更新连接参数、终止连接时应该支持哪些能力。

更直白地说：

复制代码

Peripheral 重点看：我什么时候允许别人连接我。
Central 重点看：我怎么主动去连接别人。
连接成功后重点看：参数怎么更新，连接怎么断开。

这就是 9.3 Connection modes and procedures 这一节的主线。

这个表先不用理解，这里定义了很多连接模式，先把这些连接模式做一个基本了解后，再看这个表。

9.3.2 Non-connectable mode

9.3.2.1 Description

Non-connectable mode 表示不可连接模式。

规范原文的核心意思是：

复制代码

A device in the non-connectable mode shall not allow a connection to be established.

也就是：

复制代码

处于 non-connectable mode 的设备，不允许建立连接。

这里的重点是 shall not allow 。在规范语境中，shall not 表示强制性要求，不是"不建议"，而是不允许 / 必须不能。

所以，Non-connectable mode 的本质可以理解为：

复制代码

设备可以广播自己；
其他设备可以扫描到它；
其他设备可以解析它的广播数据；
但是不能基于这个广播直接建立 BLE 连接。

也就是说，Non-connectable 不等于不可见，而是不可连接。

9.3.2.2 Conditions

这一部分描述的是：当一个 Peripheral 处于 non-connectable mode 时，它可以发送什么类型的广播，以及 Host 应该如何配置 Controller。

规范原文提到：

复制代码

A Peripheral in the non-connectable mode may send non-connectable advertising events.

意思是：

复制代码

处于 non-connectable mode 的 Peripheral，可以发送 non-connectable advertising events。

这里的 non-connectable advertising events 可以理解为"不可连接广播事件"。

它的特点是：

复制代码

只用于广播信息；
不用于建立连接。

典型场景包括：

复制代码

Beacon 广播；
传感器周期性广播数据；
设备状态广播；
附近设备发现；
只需要被扫描，不需要建立 GATT 连接的场景。

例如，一个温湿度传感器只想周期性广播当前数据：

复制代码

设备名
电池电量
温度
湿度
厂商自定义数据

手机 App 只需要扫描并解析广播内容，不需要连接设备。这类场景就适合使用 non-connectable advertising。

Non-connectable mode 中的 Peripheral

这里虽然使用了 Peripheral 这个词，但不能简单理解成"已经连接后的从设备"。

在 GAP 语境中，Peripheral 是一种角色。它通常表示：

复制代码

设备通过广播让 Central 发现自己；
并在可连接模式下等待 Central 发起连接。

但是当 Peripheral 处于 non-connectable mode 时，它虽然仍然可以广播，但不接受连接。

可以理解为：

复制代码

Peripheral 角色
+
Non-connectable mode
=
可以广播，但不能被连接

所以，Peripheral 并不一定总是可连接的。它能不能被连接，要看当前处于什么连接模式，以及广播事件类型是否支持连接。

Advertising Filter Policy

规范中还提到，Host 应该设置 advertising filter policy。

原文大意是：

复制代码

Host 应该将 advertising filter policy 设置为以下两种之一：

1. 只处理来自 Filter Accept List 中设备的 scan request 和 connection request；
2. 处理所有设备的 scan request 和 connection request。

这里容易产生一个疑问：

既然当前是 non-connectable mode，设备不允许建立连接，为什么还要提到 connection request 的过滤策略？

原因是：advertising filter policy 是 Controller 广播配置中的通用策略，它定义的是 Controller 如何处理扫描请求和连接请求。

即使当前广播是不可连接广播，规范仍然要求 Host 在配置 Controller 时把相关过滤策略配置清楚，避免行为不明确。

这里的 Filter Accept List 可以理解为 BLE 规范里的"允许列表"。

它的作用类似于：

复制代码

只有列表中的设备，才允许和我进行指定类型的交互。

不过在 non-connectable mode 下，重点仍然是：

复制代码

设备不允许建立连接。

过滤策略更多是为了约束 Controller 对 scan request / connection request 的处理行为。

Scan Request 和 Connection Request 的区别

这一节中同时出现了两个容易混淆的概念：

复制代码

scan request
connection request

这两个不是一回事。

1. scan request

scan request 是扫描方发出的请求，目的是向广播设备请求更多广播信息。

典型流程是：

复制代码

广播设备发送可扫描广播
扫描设备发送 SCAN_REQ
广播设备返回 SCAN_RSP

也就是说，scan request 的目的不是建立连接，而是：

复制代码

我扫描到了你；
我想拿到更多广播数据；
请你返回 scan response data。

但是需要注意：

Non-connectable 不一定等于 scannable。

例如在 Legacy Advertising 中：

复制代码

ADV_NONCONN_IND

表示：

复制代码

不可连接；
不可扫描。

而：

复制代码

ADV_SCAN_IND

表示：

复制代码

不可连接；
可扫描。

所以，non-connectable 只说明不能建立连接，至于能不能响应 scan request，还要看具体广播类型是不是 scannable。

2. connection request

connection request 是连接发起方发出的连接请求，目的是建立 BLE 连接。

如果设备处于 non-connectable mode，那么它不能接受 connection request。

可以简单对比：

复制代码

scan request：
我想获取更多广播数据。

connection request：
我想和你建立 BLE 连接。

Non-connectable mode 限制的核心是后者：

复制代码

不允许建立连接。

Advertising Interval

规范中还提到：

复制代码

The Host should set the advertising intervals as defined in Section 9.3.11.

意思是：

复制代码

Host 应该按照 9.3.11 中定义的要求设置广播间隔。

这说明，non-connectable mode 虽然不用于建立连接，但它仍然属于广播行为，因此广播间隔不能随便设置，而是需要符合 GAP 规范中对广播间隔的要求。

广播间隔会直接影响设备的发现速度和功耗。

一般可以这样理解：

复制代码

广播间隔越短：
设备越容易被快速扫描到；
通信体验上更"及时"；
但功耗更高。

广播间隔越长：
设备被扫描到的速度可能变慢；
但更省电。

对于不同业务场景，广播间隔的选择也不同。

例如：

复制代码

Beacon 类设备：
通常希望广播频率比较稳定，方便扫描设备持续感知。

低功耗传感器：
可能更关注省电，可以适当拉长广播间隔。

临时状态广播：
可能只需要在某个时间段内短时间高频广播。

所以，Non-connectable advertising 虽然不需要建立连接，但仍然需要认真配置 advertising interval。

Multiple Advertising Sets

规范最后提到：

复制代码

The device may configure and enable multiple independent advertising sets.
Each advertising set may have an independent advertising filter policy.

意思是：

复制代码

设备可以配置并启用多个独立的 advertising set。
每个 advertising set 都可以有自己独立的 advertising filter policy。

Advertising Set 是扩展广播中的重要概念。

在 Legacy Advertising 中，设备通常更像是配置一组广播参数、广播数据、扫描响应数据，然后启用广播。

而在 Extended Advertising 中，设备可以配置多组相互独立的 advertising set。

每个 advertising set 可以有自己独立的配置，例如：

复制代码

广播数据
广播类型
广播间隔
广播 PHY
广播过滤策略
是否启用

例如，一个设备可以同时配置多组广播：

复制代码

Advertising Set 1：
发送普通设备发现信息，允许所有扫描设备处理。

Advertising Set 2：
发送厂商自定义业务数据，只允许 Filter Accept List 中的设备交互。

Advertising Set 3：
发送不可连接广播，只用于周期性状态通知。

这里强调的是：

复制代码

多个 advertising set 之间可以互相独立；
每个 advertising set 可以拥有自己的 advertising filter policy。

Non-connectable mode 的核心理解

Non-connectable mode 的本质是：

复制代码

设备可以发送广播，但不允许其他设备基于该广播建立连接。

进一步理解：

复制代码

Non-connectable 不代表扫描不到；
Non-connectable 只代表不能建立连接；
是否可以响应 scan request，要看广播类型是否 scannable；
是否处理特定设备的请求，要看 advertising filter policy；
多个 advertising set 可以拥有各自独立的过滤策略。

在实际 BLE App 开发中，如果扫描到了一个设备，但无法连接，原因可能有很多，其中一种情况就是：

复制代码

该设备当前发送的是 non-connectable advertising。

这类设备的典型表现是：

复制代码

App 能扫描到设备；
能拿到广播数据；
能解析 manufacturer data / service data；
但是不能建立 GATT 连接。

所以，在分析 BLE 广播设备时，不能只看设备名、RSSI、MAC 地址、广播数据，还要关注广播事件类型是否 connectable。

对于 BLE 学习来说，Non-connectable mode 需要重点抓住一句话：

复制代码

Non-connectable mode 解决的是"只广播、不连接"的场景。

它适合 Beacon、状态广播、传感器广播等只需要广播数据、不需要建立连接的业务。

9.3.3 Directed Connectable mode

9.3.3.1 Description

Directed Connectable mode 表示定向可连接模式。

规范原文的核心内容是：

复制代码

A device in the directed connectable mode shall accept a connection request from a known peer device performing the auto connection establishment procedure or the general connection establishment procedure.

意思是：

复制代码

处于 directed connectable mode 的设备，应当接受来自已知对端设备的连接请求。
这个已知对端设备可能正在执行 auto connection establishment procedure，
也可能正在执行 general connection establishment procedure。

这里的重点有三个：

复制代码

directed：定向的，有明确目标设备；
connectable：可连接的，允许建立连接；
known peer device：已知的对端设备。

所以，Directed Connectable mode 的本质是：

复制代码

Peripheral 不是随便等待任何 Central 来连接，
而是面向一个已知的目标 Central 发出定向可连接广播，
并接受这个已知设备发起的连接请求。

Directed Connectable mode 的核心含义

Directed Connectable mode 和普通可连接模式最大的区别在于：

复制代码

普通可连接模式：
我广播出来，符合条件的 Central 都可能来连接我。

定向可连接模式：
我广播出来，但我是明确面向某个已知 Central 的。

可以简单理解为：

复制代码

General Connectable：
我可以被别人连接。

Directed Connectable：
我想被某个指定设备重新连接。

典型场景是设备已经和手机配对、绑定或建立过连接关系，之后设备希望手机尽快重新连接。

例如：

复制代码

BLE 手环之前已经和手机绑定；
手环断开后重新开始广播；
手环希望原来的手机尽快连接回来；
这时就可以使用 directed connectable advertising。

这种模式更强调：

复制代码

不是面向所有扫描设备；
而是面向已知的目标设备。

Known Peer Device

原文中特别提到了：

复制代码

known peer device

也就是已知对端设备。

这里的 known peer device 可以理解为：Peripheral 已经知道目标 Central 的身份信息或地址信息，因此可以在广播行为中指向这个目标设备。

它通常不是一个完全陌生的扫描设备，而是之前已经有过某种关系的设备，例如：

复制代码

之前连接过的设备；
已经绑定过的设备；
已经保存过地址信息的设备；
具备可识别身份的对端设备。

Directed Connectable mode 的重点不是"让所有人都能发现并连接我"，而是：

复制代码

我现在主要是想让某个已知设备来连接我。

Auto Connection Establishment Procedure

原文中提到：

复制代码

auto connection establishment procedure

可以理解为自动连接建立过程。

它描述的是 Central 设备自动尝试连接已知设备的过程。

例如手机系统或蓝牙 Host 已经知道某个外设的信息，当这个外设再次出现时，Central 可以自动发起连接，而不一定需要 App 每次都手动扫描、筛选、再连接。

典型理解：

复制代码

Central 保存了目标 Peripheral 的信息；
Central 处于自动连接状态；
当目标 Peripheral 发出合适的广播后；
Central 自动发起连接请求。

这个过程常见于断线重连场景。

例如：

复制代码

手机之前连接过一个 BLE 设备；
设备断开后又重新广播；
手机检测到目标设备出现；
系统或 Host 自动尝试重新建立连接。

在 Directed Connectable mode 下，Peripheral 发送的是定向可连接广播，这种广播本身就带有"我希望某个已知设备连接我"的含义，因此适合和 auto connection establishment procedure 配合使用。

General Connection Establishment Procedure

原文还提到：

复制代码

general connection establishment procedure

可以理解为通用连接建立过程。

它描述的是 Central 通过常规方式发现并连接 Peripheral 的过程。

一般可以理解为：

复制代码

Central 扫描广播；
发现目标 Peripheral；
根据广播信息、地址、过滤条件等判断是否连接；
然后发起连接请求。

和 auto connection establishment procedure 相比，general connection establishment procedure 更像是普通的扫描连接流程。

可以简单对比：

复制代码

Auto Connection Establishment：
更偏自动重连，目标通常是已知设备。

General Connection Establishment：
更偏普通连接，Central 扫描到设备后再决定是否连接。

Directed Connectable mode 允许已知对端设备通过这两类连接过程来发起连接。

9.3.3.2 Conditions

Peripheral 应发送定向可连接广播事件

规范原文：

复制代码

A Peripheral shall send connectable directed advertising events.

意思是：

复制代码

Peripheral 应当发送 connectable directed advertising events。

这里的 shall 表示强制要求。也就是说，如果 Peripheral 处于 directed connectable mode，它就应该发送可连接的定向广播事件。

Connectable directed advertising events 可以拆成三部分理解：

复制代码

connectable：
这个广播允许建立连接。

directed：
这个广播是面向指定目标设备的。

advertising events：
这是广播事件，不是连接后的数据通信。

所以它的含义就是：

复制代码

Peripheral 通过广播告诉某个已知 Central：
我现在可以被你连接。

Directed Advertising 和普通 Advertising 的区别

普通广播更像是：

复制代码

我在这里，谁有需要可以来连接我。

定向广播更像是：

复制代码

我在这里，并且我是专门给某个目标设备看的，希望它来连接我。

因此，Directed Connectable mode 常用于快速重连。

例如：

复制代码

设备和手机之前已经连接过；
连接断开；
设备希望尽快恢复连接；
设备发送 directed connectable advertising；
手机作为已知 Central 发起连接请求；
双方重新建立 BLE 连接。

这种场景下，定向广播比普通广播更有针对性。

Directed Connectable mode 与 Non-connectable mode 的区别

前面 Non-connectable mode 的核心是：

复制代码

可以广播，但不能建立连接。

而 Directed Connectable mode 的核心是：

复制代码

可以广播，并且允许指定的已知设备建立连接。

两者区别很明显：

复制代码

Non-connectable mode：
广播只是用来发送信息，不接受连接。

Directed Connectable mode：
广播是为了让已知对端设备发起连接。

可以对比如下：

复制代码

Non-connectable：
我只广播数据，不要连接我。

Directed Connectable：
我正在找某个已知设备，让它来连接我。

Directed Connectable mode 与 General Connectable mode 的区别

Directed Connectable mode 和 General Connectable mode 都是可连接的，但目标范围不同。

复制代码

General Connectable mode：
面向一般 Central 设备；
通常用于设备发现和首次连接；
Central 扫描到后可以根据条件发起连接。

Directed Connectable mode：
面向已知 Central 设备；
通常用于已知设备之间的快速重连；
Peripheral 的广播具有明确目标。

简单理解：

复制代码

General Connectable：
开放式可连接。

Directed Connectable：
定向式可连接。

Multiple Advertising Sets

规范最后提到：

复制代码

The device may configure and enable multiple independent advertising sets.
Each advertising set may have an independent advertising filter policy.

意思是：

复制代码

设备可以配置并启用多个独立的 advertising set。
每个 advertising set 都可以有自己独立的 advertising filter policy。

这说明 directed connectable mode 也可以和多个 advertising set 的机制结合使用。

每个 advertising set 都可以独立配置自己的广播行为，例如：

复制代码

广播类型
广播数据
广播间隔
目标设备
过滤策略
是否启用

例如，一个设备可以有多组广播：

复制代码

Advertising Set 1：
用于普通设备发现，面向所有 Central。

Advertising Set 2：
用于定向重连，面向已经绑定过的手机。

Advertising Set 3：
用于不可连接状态广播，只广播传感器数据。

每个 advertising set 的 advertising filter policy 可以不同。

这意味着：

复制代码

一个 BLE 设备不一定只有一种广播行为；
它可以根据业务需要，同时或分别配置多种广播集；
每个广播集可以服务于不同的连接或广播目的。

Directed Connectable mode 的核心理解

Directed Connectable mode 的本质是：

复制代码

Peripheral 发送定向可连接广播，
目的是让某个已知的 Central 设备发起连接。

它不是单纯"可连接"，而是"定向可连接"。

核心特征可以总结为：

复制代码

它允许建立连接；
它面向 known peer device；
Peripheral 应发送 connectable directed advertising events；
常用于已知设备之间的快速重连；
可以配合 auto connection establishment procedure；
也可以配合 general connection establishment procedure；
多个 advertising set 可以拥有各自独立的 advertising filter policy。

在实际 BLE 开发中，Directed Connectable mode 常见于断线重连、绑定设备重连、目标设备快速恢复连接等场景。

例如：

复制代码

手环与手机已经绑定；
手环断开后重新开始广播；
手环希望原手机尽快连接回来；
手环发送 directed connectable advertising；
手机检测到后发起连接请求；
双方重新建立连接。

所以，Directed Connectable mode 解决的问题不是"让所有设备都能发现我并连接我"，而是：

复制代码

我已经知道我要连接谁，
现在我要通过定向可连接广播，
让这个已知设备尽快重新连接我。