【LE Audio】CAP精讲[13]: Central侧LE连接建立全流程解析

在上一篇内容中【LE Audio】CAP精讲 $12$ ：从通告到连接，LE外设连接建立全流程拆解_百度-CSDN博客，我们站在Peripheral外设的视角，拆解了CAP协议下LE传输连接的"邀请函"设计与连接准备逻辑。但完整的连接建立是双向奔赴的过程，外设的通告只是"发出邀约"，真正决定"是否赴约、赴谁的约、如何赴约"的核心，掌握在作为连接发起方的Central设备手中------比如手机、电脑这类音频主设备。

一、角色锚定：Central在CAP生态中的核心定位与职责

二、扫描阶段：Central的雷达探测体系

[2.1 扫描的触发机制：INAP与RAP双模式](#2.1 扫描的触发机制：INAP与RAP双模式)

[2.2 扫描参数的选择](#2.2 扫描参数的选择)

[2.3 通告解析：从原始数据到连接依据](#2.3 通告解析：从原始数据到连接依据)

三、筛选阶段：Central的准入审核逻辑

四、决策阶段：Central的连接优先级排序

五、发起连接：Central的参数化握手执行

六、连接后初始化：从链路建立到服务就绪

[6.1 服务发现：快速定位CAP核心服务](#6.1 服务发现：快速定位CAP核心服务)

[6.2 角色确认：双向角色的最终匹配](#6.2 角色确认：双向角色的最终匹配)

[6.3 参数配置：适配外设的最优参数](#6.3 参数配置：适配外设的最优参数)

七、特殊场景处理：Central侧的异常应对体系

八、开发实战：Central侧的关键实现要点与踩坑指南

九、测试

作为LE Audio生态的中枢指挥官，Central侧的连接建立流程，本质是一套**"扫描探测→筛选准入→优先级决策→参数化握手→服务初始化"**的闭环体系。CAP协议对这一体系做了极其严谨的定义，小到扫描参数的选择、通告字段的解析规则，大到多设备竞争时的决策逻辑、重连场景的参数适配，都直接决定了用户感知到的连接速度、稳定性与功耗表现。

本文站在Central开发者的视角，把这套复杂的协议逻辑拆解为可落地的知识体系。结合协议原文的关键要求以及实际开发中的踩坑点，彻底吃透Central侧连接建立的核心逻辑。

一、角色锚定：Central在CAP生态中的核心定位与职责

在进入流程前，必须先明确CAP角色与GAP角色的强绑定关系------这是Central侧所有操作的前提，就像派对组织者必须先明确自己的组织权限，才能制定邀约规则。

1. 角色映射的强制约束

CAP协议明确规定，Central设备在LE传输层只能承担两类角色，且必须与GAP Central角色严格对应：

Initiator：核心音频会话的发起方，比如手机向耳机发起单播音频流连接，是CAP连接的主要发起者；

Commander：控制类操作的发起方，比如手机作为遥控器，向音箱发送音量调节指令，部分独立控制设备也可承担此角色。

这一映射是强制性的，协议原文明确要求：Initiator和Commander角色的设备，实现时必须采用GAP Central角色的核心行为集，包括主动扫描、发起连接请求、协商连接参数等。反之，若设备仅承担GAP Peripheral角色，则无法执行CAP定义的任何Central侧流程。

2. Central的五大核心职责

CAP协议为Central侧定义了不可替代的五大职责，覆盖连接建立的全生命周期：

扫描探测：按指定参数扫描广播信道，捕获外设的BAP/CAP通告与AD数据；

通告解析：精准解析通告中的CAS UUID、通告类型、SID、可用音频上下文等关键信息；

筛选决策：基于角色匹配、绑定关系、通告优先级，决定是否连接及连接优先级；

连接发起：选择最优连接参数，发送连接请求PDU，完成链路层握手；

服务初始化：连接建立后，快速完成CAS服务发现、角色确认与参数配置，为音频会话铺路。

这五大职责环环相扣，任何一步的实现偏差，都会导致连接失败、音频卡顿或功耗过高的问题。

二、扫描阶段：Central的雷达探测体系

连接建立的第一步，是Central开启"雷达"扫描外设的通告。CAP协议对扫描的触发条件、参数选择、通告解析规则做了精细化定义，核心目标是在发现效率与功耗消耗之间找到最优平衡。

2.1 扫描的触发机制：INAP与RAP双模式

Central的扫描行为，完全由自身的音频需求模式决定，协议将其分为两种核心模式，这是扫描策略的根本依据：

INAP模式：即立即音频模式，指Central有明确的即时音频需求，比如用户点击"连接耳机"按钮、语音助手触发"播放音乐"指令。此时Central会以高性能为优先级，采用激进的扫描参数；

RAP模式：即就绪音频模式，指Central处于待机状态，无即时音频需求，但需要感知周边兼容设备，比如手机后台持续扫描蓝牙设备。此时Central会以低功耗为优先级，采用保守的扫描参数。

协议原文对两种模式的连接触发做了强制规定：

Central devices in INAP mode shall initiate a connection to a Peripheral device that transmits a Targeted Announcement addressed to it。

翻译过来就是，处于INAP模式的Central，必须对定向到自身的外设定向通告发起连接请求------这是保障用户即时体验的核心规则。

2.2 扫描参数的选择

扫描参数的选择直接影响发现速度和功耗，CAP协议中给出了明确的推荐值，开发者需严格遵循，不可随意自定义。我们将核心扫描参数整理为下表，方便快速查阅：

|---------------------|--------------|----------------|---------------------------------------|
| 扫描参数 | INAP模式推荐值 | RAP模式推荐值 | 核心作用 |
| 扫描窗口（Scan Window） | 40ms - 80ms | 10ms - 20ms | 每次扫描时，Central在广播信道上监听的时长 |
| 扫描间隔（Scan Interval） | 80ms - 160ms | 500ms - 1000ms | 两次扫描窗口之间的空闲时长，间隔越短，发现越快但功耗越高 |
| 扫描类型 | 主动扫描 | 被动扫描 | 主动扫描会发送扫描请求，获取外设更多AD数据；被动扫描仅接收通告，功耗更低 |
| 信道集 | 37、38、39全信道 | 37、38、39轮询 | 全信道扫描确保快速发现，轮询扫描降低功耗 |

这里的关键逻辑是：INAP模式下，用户的等待容忍度极低，因此牺牲功耗换取速度；RAP模式下，用户无即时需求，因此牺牲速度换取功耗。比如用户点击连接耳机时，手机会立即切换到INAP模式，采用80ms间隔、80ms窗口的主动扫描，确保1秒内发现目标外设。

2.3 通告解析：从原始数据到连接依据

Central扫描到外设的广播PDU后，必须按CAP协议的规则进行解析，核心是提取三类关键信息，缺失任何一类都可能导致筛选失败。

（1）服务 UUID 解析：确认CAP 兼容性

首先需解析AD数据或服务数据中的UUID，判断外设是否支持CAP协议：

若外设发送CAP通告，必须包含2字节的CAS（Common Audio Service）UUID，这是CAP设备的身份标识；
若外设未发送CAP通告，但支持CAP角色，必须在AD数据的"Service UUIDs"字段中包含CAS UUID；
若同时发现BAP UUID和CAS UUID，说明外设是混合角色设备，需同时按BAP和CAP规则处理。

（2）核心字段解析：提取连接关键信息

对于CAP通告和BAP通告，需重点解析以下核心字段，这些字段是后续筛选和决策的直接依据：

|------------|----------|------------|---------------------|
| 字段名称 | 字段长度 | 核心作用 | 解析要点 |
| 通告类型 | 1字节 | 判断外设连接意图 | 0x00=通用通告，0x01=定向通告 |
| 广播集ID（SID） | 1字节 | 识别绑定设备的广播集 | 绑定设备的SID应固定，用于快速识别 |
| 可用音频上下文 | 变长 | 判断外设音频能力 | 重连场景下全0表示无即时音频需求 |
| 目标地址 | 6字节 | 定向通告的接收方 | 仅定向通告包含，需匹配自身蓝牙地址 |

（3）解析容错：协议的灵活规定

协议对解析过程做了容错设计，体现了实用性：若外设的广播PDU中包含无效字段或长度错误，Central应忽略该字段，而非直接丢弃整个通告；若同时包含BAP和CAP通告，两者的字段应独立解析，互不影响。比如外设的CAP通告中SID字段长度错误，Central可忽略SID，仅按通告类型和UUID进行处理。

三、筛选阶段：Central的准入审核逻辑

扫描并解析完通告后，Central需要对所有符合条件的外设进行准入审核，筛选出具备连接资格的设备。CAP协议定义了四层筛选规则，按优先级从高到低执行，就像派对组织者按"邀请函类型→身份绑定→能力匹配→信号质量"的顺序筛选嘉宾。

1. 第一层筛选：定向通告的地址匹配

这是最高优先级的筛选规则，仅适用于定向通告。Central会将通告中的目标地址与自身的蓝牙地址（包括公共地址和随机地址）进行精确匹配：

若地址匹配，且Central处于INAP模式，直接进入决策阶段，无需后续筛选；

若地址匹配，但Central处于RAP模式，暂存设备信息，等待模式切换为INAP后再处理；

若地址不匹配，直接丢弃该定向通告，不进入后续筛选。

这一规则的设计目的，是避免定向通告被无关设备响应，确保外设的专属邀约能精准触达目标Central。

2. 第二层筛选：角色能力的双向匹配

CAP协议的核心是角色交互，因此Central必须确认自身与外设的角色是否匹配，这是连接的能力基础。筛选逻辑如下：

若Central为Initiator角色，需确认外设是否为Acceptor角色（如耳机、音箱），且支持自身所需的音频服务（如单播音频接收、广播音频代理）；

若Central为Commander角色，需确认外设是否为对应Controller角色的设备（如音量渲染器、麦克风控制器）；

若角色不匹配，即使其他条件都满足，也必须拒绝连接。

比如手机作为Initiator，想要发起单播音频流，就必须筛选出支持BAP Unicast Server角色的Acceptor外设，而仅支持广播音频接收的音箱，就会被这一层筛选淘汰。

3. 第三层筛选：绑定关系的优先级判断

绑定关系是用户使用习惯的核心体现，CAP协议将绑定设备的优先级提升至极高位置，筛选规则如下：

已绑定设备：优先通过，且跳过后续的信号质量筛选（除非信号强度低于连接阈值）；

未绑定设备：需通过后续的信号质量筛选，且优先级低于已绑定设备；

黑名单设备：直接丢弃，无论其他条件如何。

协议原文对绑定设备的处理做了强调：

Central shall prioritize bonded Peripheral devices over unbonded ones in all connection scenarios。

这一规则确保用户的常用设备能被优先连接，符合熟人优先的用户直觉。

4. 第四层筛选：信号质量的阈值校验

对于未绑定设备，或信号强度异常的绑定设备，需进行信号质量筛选，核心是校验接收信号强度指示（RSSI）：

CAP协议推荐的连接RSSI阈值为-80dBm，即RSSI高于-80dBm的设备，才具备连接资格；

若RSSI低于阈值，说明设备距离过远，连接后易出现断连、卡顿，因此直接淘汰；

对于多个符合条件的设备，RSSI越高，后续决策阶段的优先级越高。

这一筛选规则，是保障连接稳定性的最后一道防线。

四、决策阶段：Central的连接优先级排序

经过筛选后，Central会得到一个合格设备列表，此时需要根据CAP协议的规则，对列表中的设备进行优先级排序，决定先连接谁、是否同时连接。这一阶段是Central侧逻辑最复杂的部分，直接决定了多设备场景下的用户体验。

1. 核心决策因子：协议定义的优先级层级

CAP协议将决策因子分为五个层级，按优先级从高到低依次排列，开发者需严格按此层级实现，不可随意调整：

|-----------|----------|-------------------------------|
| 优先级层级 | 决策因子 | 具体规则 |
| 1（最高） | 模式+定向通告 | INAP模式下的定向通告设备，优先于所有其他设备 |
| 2 | 模式+通用通告 | INAP模式下的通用通告设备，优先于RAP模式下的所有设备 |
| 3 | 绑定关系 | 已绑定设备，优先于未绑定设备 |
| 4 | 信号强度 | RSSI越高，优先级越高 |
| 5（最低） | 发现时间 | 先发现的设备，优先级略高于后发现的设备 |

为了让大家更直观地理解，我们举一个实际场景：手机（Central）同时扫描到三个设备------已绑定的耳机（发送定向通告）、未绑定的音箱（发送通用通告）、已绑定的手表（发送通用通告），且手机处于INAP模式。按决策规则，连接优先级为：耳机 > 手表 > 音箱。

2. 多设备竞争的特殊处理规则

在实际使用中，Central可能同时收到多个符合最高优先级的设备请求，比如两部已绑定的耳机同时发送定向通告，此时CAP协议定义了特殊的处理规则：

单连接场景：大多数消费级音频设备仅支持单Central连接，此时Central会按最近使用时间排序，优先连接最近使用过的设备；

多连接场景：支持多连接的Central（如电脑），可同时连接多个外设，但需遵循音频会话优先级规则，比如语音通话设备的优先级高于音乐播放设备；

连接排队：若Central已建立连接，且资源不足，可将高优先级设备加入连接队列，断开当前低优先级连接后，立即发起新连接。

协议原文对资源限制的处理做了规定：

If the Central device has insufficient resources to establish a new connection, it shall disconnect the lowest priority existing connection and then initiate the new connection。

这一规则确保高优先级的音频需求能被优先满足。

3. 空闲连接的决策逻辑

对于RAP模式下的Central，即使无即时音频需求，也可根据决策规则建立空闲连接------即仅建立链路，不传输音频流。决策逻辑如下：

仅对已绑定的高优先级设备建立空闲连接；
空闲连接的数量不超过设备资源限制（通常为2-3个）；
若外设发送的定向通告中，可用音频上下文全为0，优先建立空闲连接。

空闲连接的设计，是为了让用户后续触发音频需求时，能实现秒连，这是提升用户体验的关键设计。

五、发起连接：Central的参数化握手执行

当Central确定要连接的目标外设后，就进入了最关键的握手阶段------发送连接请求PDU，与外设协商连接参数，完成链路层的连接建立。这一阶段的核心是参数选择，CAP协议中给出了明确的参数标准，直接决定了连接的速度、稳定性与功耗。

1. 连接参数的分类与适用场景

CAP协议将LE连接参数分为三类，分别对应不同的连接场景，开发者需根据场景选择最优参数，不可混用。核心连接参数如下表所示：

|---------------|-------------------------|-------------------------|------------------------------------|---------------------|
| 参数类型 | 连接间隔（Conn Interval） | 从机延迟（Slave Latency） | 监督超时（Conn Supervision Timeout） | 适用场景 |
| Quick | 7.5ms - 15ms | 0 | 100ms | 链路丢失重连、INAP模式下的首次连接 |
| Default | 30ms - 50ms | 2 | 200ms | 正常音频播放、空闲连接的维护 |
| Reduced Power | 100ms - 200ms | 5 | 500ms | 低功耗待机、RAP模式下的空闲连接 |

这三类参数的设计逻辑非常清晰：

Quick参数：以速度为核心，连接间隔极短，监督超时极短，确保快速建立连接并检测链路状态，适合用户等待的即时场景；
Default参数：兼顾稳定性与功耗，适合正常的音频传输场景；
Reduced Power参数：以功耗为核心，连接间隔长，从机延迟大，适合无即时数据传输的待机场景。

2. 连接请求的发送与握手流程

Central根据场景选择好连接参数后，会向外设发送CONNECT_REQ PDU，完成链路层的握手。完整流程如下：

Central在扫描窗口中，捕获外设的广播PDU后，选择外设的广播信道，发送CONNECT_REQ PDU；
CONNECT_REQ PDU中包含核心连接参数：连接间隔、从机延迟、监督超时、发起方地址、目标方地址等；
外设收到CONNECT_REQ PDU后，若资源允许，会在指定的连接信道上发送ACK响应；
Central收到ACK后，链路层连接建立，进入连接状态，开始按协商的连接间隔进行数据交互。

协议对连接请求的发送做了严格的时间限制：Central shall send the CONNECT_REQ PDU within 10ms of receiving the Peripheral's announcement PDU in INAP mode。这一限制确保INAP模式下的连接能快速完成，符合用户的即时体验需求。

3. 连接失败的处理策略

连接建立过程中，可能因外设资源不足、信号干扰、参数不兼容等原因导致失败，CAP协议定义了明确的重试策略：

首次失败：立即重试，使用相同的连接参数，重试次数不超过3次；
连续失败3次：切换为下一级优先级的连接参数（如Quick参数切换为Default参数），再重试3次；
仍失败：放弃连接，向应用层返回连接失败通知，并记录失败原因；
重连场景：若链路丢失重连失败，超时后切换为Reduced Power参数，进入低功耗扫描模式。

比如手机向耳机发起重连，使用Quick参数连续失败3次后，会切换为Default参数重试，若仍失败，就会进入低功耗扫描，等待用户手动触发连接。

六、连接后初始化：从链路建立到服务就绪

链路层连接建立，只是完成了物理握手，真正让设备具备音频交互能力的，是连接后的服务初始化阶段。CAP协议要求Central在连接建立后，必须立即执行初始化流程，核心是完成CAS服务发现、角色确认与参数配置，就像派对组织者为嘉宾办理入住，分配活动权限。

6.1 服务发现：快速定位CAP核心服务

服务发现是初始化的第一步，Central需通过GATT协议，快速发现外设中的CAS服务及相关特征。协议对服务发现的流程做了强制规定：Central shall perform service discovery for the Common Audio Service immediately after connection establishment，且发现超时时间不得超过500ms。

（1）CAS服务的发现规则

CAS服务的UUID为16位固定值，Central需按此UUID精准搜索；
若外设同时支持BAP、VCP等音频服务，Central需同时发现这些服务，建立服务映射表；
服务发现过程中，若发现无效的服务或特征，应忽略，继续完成剩余发现流程。

（2）核心特征的提取

CAS服务包含多个核心特征，Central需重点提取以下特征，用于后续的角色确认和参数配置：

角色特征（Role Characteristic）：存储外设的CAP角色信息，如Acceptor、Commander；
配置特征（Configuration Characteristic）：存储外设的连接配置参数，如通告类型、SID；
上下文特征（Context Characteristic）：存储外设的可用音频上下文信息。

6.2 角色确认：双向角色的最终匹配

服务发现完成后，Central需与外设进行角色确认，确保双方的角色匹配无误。流程如下：

Central读取外设的角色特征，获取外设的CAP角色；
Central将自身的角色信息，写入外设的角色特征（若特征支持写操作）；
双方确认角色匹配后，进入参数配置阶段；
若角色不匹配，Central立即断开连接，向应用层返回角色不兼容通知。

这一阶段是连接建立的最后一道校验，避免因角色不匹配导致后续音频会话无法建立。

6.3 参数配置：适配外设的最优参数

角色确认后，Central需根据外设的能力，配置最优的连接参数和服务参数，核心包括：

连接参数更新：若外设支持的连接参数与Central的初始选择不一致，协商后更新为双方都支持的最优参数；
服务参数配置：配置CAS服务的上下文、通告类型等参数，确保与外设的状态同步；
安全参数配置：若为绑定设备，加载之前存储的安全密钥，完成加密连接。

协议对参数配置的超时做了规定：Parameter configuration shall be completed within 2 seconds of connection establishment，超时未完成则断开连接。

七、特殊场景处理：Central侧的异常应对体系

实际使用中，连接建立会面临各种特殊场景，如多外设竞争、链路丢失重连、空闲连接维护等。CAP协议为这些场景定义了专门的处理规则，是开发者必须重点关注的边缘场景。

1. 链路丢失重连：Central的主动召回策略

当与外设的连接因信号干扰、距离过远等原因丢失后，Central会启动重连流程，核心逻辑如下：

立即重连：若丢失的是高优先级连接（如语音通话），立即切换为INAP模式，使用Quick参数扫描外设的定向通告；
延迟重连：若丢失的是低优先级连接（如空闲连接），延迟5-10秒后，使用RAP模式扫描；
参数适配：重连时，若外设的定向通告中可用音频上下文全为0，使用Quick参数建立空闲连接；
重连超时：若重连超过30秒未成功，停止重连，进入正常扫描模式。

2. 多绑定设备的切换逻辑

当用户手动切换连接设备时，Central需按以下规则执行：

主动断开：断开当前的连接，释放资源；
快速扫描：切换为INAP模式，扫描目标设备的通告；
优先连接：目标设备若发送定向通告，立即发起连接；
状态同步：连接建立后，同步当前的音频状态（如播放进度、音量大小）。

3. 空闲连接的维护与断开

对于空闲连接，Central需平衡连接速度与功耗，维护规则如下：

保活机制：按Default参数的连接间隔，定期发送空数据包，维持连接状态；
断开策略：若空闲连接超过设备定义的时限（如5分钟）无活动，或电量低于阈值，主动断开连接；
快速恢复：断开后，若用户触发音频需求，立即按重连流程建立连接。

八、开发实战：Central侧的关键实现要点与踩坑指南

基于CAP协议8.2的要求，结合实际开发经验，我们整理了Central侧连接建立的关键实现要点和常见踩坑点，帮助开发者避开"协议陷阱"。

（1）关键实现要点

模式切换的即时性：用户触发音频需求时，需立即将Central从RAP模式切换为INAP模式，更新扫描参数；
通告解析的完整性：需同时支持BAP和CAP通告的解析，处理混合通告的场景；
参数选择的动态性：根据场景动态切换Quick/Default/Reduced Power参数，不可固定使用某一类参数；
超时机制的严谨性：严格遵循协议定义的扫描超时、连接超时、初始化超时时间，避免无限等待；
日志的精细化：记录扫描、筛选、决策、连接、初始化各阶段的日志，便于问题定位。

（2）常见踩坑点与解决方案

|-------------|-------------------|--------------------------------------|
| 踩坑点 | 问题表现 | 解决方案 |
| 忽略定向通告的地址匹配 | 无关设备响应定向通告，导致连接混乱 | 严格校验定向通告的目标地址，仅匹配自身地址的通告才处理 |
| 固定使用连接参数 | 重连速度慢或功耗过高 | 按场景动态选择Quick/Default/Reduced Power参数 |
| 服务发现超时设置过长 | 连接后长时间无法播放音频 | 将服务发现超时设置为500ms，超时立即断开 |
| 未处理多设备竞争 | 高优先级设备无法优先连接 | 按协议定义的优先级层级，实现多设备排序与排队逻辑 |
| 忽略SID的识别 | 绑定设备被当作未绑定设备处理 | 解析通告中的SID，与存储的绑定设备SID进行匹配 |

九、测试

题目：CAP协议中，Central侧在多设备竞争场景下，连接优先级的决策因子有哪些？按优先级从高到低排列，并简述核心规则。

答案：

决策因子共五个，按优先级从高到低为：模式+定向通告、模式+通用通告、绑定关系、信号强度、发现时间；
核心规则：

①INAP模式下的定向通告设备优先级最高，必须立即发起连接；

②INAP模式下的通用通告设备，优先级高于RAP模式下的所有设备；

③已绑定设备优先级高于未绑定设备；

④信号强度（RSSI）越高，优先级越高；

⑤同等条件下，先发现的设备优先级略高；

⑥若资源不足，断开低优先级连接，优先建立高优先级连接。

题目：CAP协议中定义了哪三类LE连接参数？分别适用于什么场景？核心参数值有何差异？

答案：

三类连接参数：Quick参数、Default参数、Reduced Power参数；
适用场景：

①Quick参数适用于链路丢失重连、INAP模式下的首次连接；

②Default参数适用于正常音频播放、空闲连接的维护；

③Reduced Power参数适用于低功耗待机、RAP模式下的空闲连接；
核心参数差异：

①连接间隔：Quick为7.5ms-15ms，Default为30ms-50ms，Reduced Power为100ms-200ms；

②从机延迟：Quick为0，Default为2，Reduced Power为5；

③监督超时：Quick为100ms，Default为200ms，Reduced Power为500ms。

题目：CAP协议要求Central在链路层连接建立后，必须立即执行的初始化流程包括哪些？各阶段的核心要求是什么？

答案：

初始化流程包括三步：服务发现、角色确认、参数配置；
核心要求：

①服务发现：必须立即执行，超时不得超过500ms，需发现CAS服务及相关核心特征，同时支持BAP、VCP等关联服务的发现；

②角色确认：读取外设的角色特征，写入自身角色信息，确认双方角色匹配，不匹配则立即断开；

③参数配置：协商更新连接参数，配置CAS服务参数和安全参数，需在2秒内完成，超时则断开连接。