2. 蓝牙基础回顾：经典蓝牙与BLE区别、蓝牙协议栈架构、RFCOMM与SDP协议
在车载蓝牙电话免提（HFP）集成开发中，蓝牙协议栈是通信的基石。本章将系统回顾经典蓝牙（BR/EDR）与低功耗蓝牙（BLE）的核心差异、蓝牙协议栈的分层架构，以及RFCOMM和SDP这两个对HFP至关重要的协议。理解这些基础，是后续调用Car API实现电话功能的前提。
2.1 经典蓝牙（BR/EDR）与低功耗蓝牙（BLE）的区别
蓝牙技术主要分为两种模式：经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）。车载免提电话（HFP）基于经典蓝牙，而BLE常用于设备配对、低功耗数据传输等场景。下表从关键维度对比两者的差异：
| 对比维度 | 经典蓝牙（BR/EDR） | 低功耗蓝牙（BLE） |
|---|---|---|
| 核心用途 | 连续数据流传输（音频、文件） | 低功耗、间歇性数据传输（传感器、信标） |
| 功耗 | 较高（数mA ~ 数十mA） | 极低（μA ~ 数mA） |
| 数据传输速率 | 最高约 3 Mbps（EDR） | 最高约 2 Mbps（LE 2M PHY） |
| 连接建立时间 | 较慢（约 100ms ~ 数秒） | 极快（约 3ms ~ 6ms） |
| 音频传输 | 原生支持（SCO/eSCO 链路） | 需通过 LE Audio（LC3 编码） |
| 协议栈复杂度 | 较高（多层协议） | 相对简单（GATT 为核心） |
| 车载免提应用 | HFP 协议运行于此 | 用于低功耗配对、钥匙、传感器 |
开发要点：车载电话免提（HFP）必须使用经典蓝牙（BR/EDR）的 SCO/eSCO 链路传输同步音频。BLE 不直接支持 HFP，但可用于蓝牙配对（如 SSP 中的 OOB 方式）或车载低功耗传感器（如胎压监测）。
2.2 蓝牙协议栈架构
蓝牙协议栈采用分层设计，每一层封装特定的功能，并为上层提供服务。对于车载HFP开发，我们主要关注主机协议栈（Host Stack）部分。下图展示了经典蓝牙协议栈的完整架构：
协议栈从上到下分为四层：
- 应用层（Profiles）：定义具体应用场景的行为，如HFP（免提）、A2DP（立体声音频）、PBAP（电话簿访问）。
- 主机协议层：包括SDP（服务发现）、RFCOMM（串口仿真）、L2CAP（逻辑链路控制与适配）等核心协议。
- HCI（主机控制器接口）：主机与蓝牙控制器之间的通信接口，通常通过UART或USB传输。
- 控制器层：负责物理层操作，包括链路管理、基带和射频。
车载集成提示：在Android Automotive或Linux车载系统中，蓝牙协议栈通常由BlueZ（Linux）或Fluoride（Android）实现。HFP的音频通道（SCO/eSCO）由控制器层直接管理，而AT命令和SDP查询则由主机协议层处理。
2.3 RFCOMM协议：串口仿真与HFP数据通道
RFCOMM（Radio Frequency Communication）是经典蓝牙协议栈中的一个重要协议，它仿真RS-232串行端口，为上层应用提供可靠的数据流传输。在HFP中，RFCOMM承载了AT命令的收发。
RFCOMM的核心特性
- 串口仿真：模拟物理串口，支持波特率、数据位、停止位等参数配置。
- 多路复用：通过逻辑信道（DLCI）支持多个并发连接。
- 可靠传输：基于L2CAP的可靠数据包传输，确保AT命令不丢失。
- 流控机制：支持软件流控（XON/XOFF）和硬件流控（RTS/CTS）。
HFP中的RFCOMM连接流程
- 服务发现：HF（免提设备）通过SDP查询AG（音频网关）的HFP服务通道号。
- L2CAP连接：建立L2CAP信道，为RFCOMM提供底层传输。
- RFCOMM会话建立：在L2CAP信道上建立RFCOMM连接，协商参数。
- AT命令交互：通过RFCOMM数据通道发送AT命令（如AT+CHUP挂断电话）。
- 连接释放：通话结束或设备断开时，关闭RFCOMM和L2CAP连接。
常见问题：RFCOMM的DLCI（数据链路连接标识符）在HFP中通常固定为1。如果车载系统同时运行多个蓝牙Profile（如HFP + MAP），需要确保RFCOMM多路复用不冲突。部分低端蓝牙芯片对RFCOMM并发支持有限，可能导致AT命令响应延迟。
2.4 SDP协议：服务发现与HFP角色协商
SDP（Service Discovery Protocol，服务发现协议）是蓝牙协议栈中用于发现设备上可用服务的核心协议。在HFP连接建立之前，HF必须通过SDP查询AG是否支持HFP，并获取必要的服务参数。
SDP的核心概念
- 服务记录（Service Record）：描述一个服务的属性集合，每个服务记录由唯一的服务记录句柄（Service Record Handle）标识。
- 服务类ID（Service Class ID）：标识服务类型，HFP的服务类ID为
0x111E（Hands-Free Audio Gateway）。 - 协议描述符（Protocol Descriptor List）：描述服务使用的协议栈，HFP的协议栈为 L2CAP → RFCOMM → HFP。
- 属性（Attributes）：服务的具体参数，如RFCOMM通道号、支持的HFP版本、支持的特性（如三路呼叫、语音识别）。
HFP服务发现的关键属性
| 属性ID | 属性名称 | 说明 | HFP典型值 |
|---|---|---|---|
0x0001 |
Service Class ID List | 服务类标识 | 0x111E (Hands-Free Audio Gateway) |
0x0004 |
Protocol Descriptor List | 协议栈描述 | L2CAP (PSM=3) → RFCOMM (Channel=X) |
0x0009 |
Bluetooth Profile Descriptor List | Profile版本与特性 | HFP 1.8, Features=0x020F |
0x0100 |
Service Name | 服务名称 | "Hands-Free Audio Gateway" |
下图展示了SDP服务发现与RFCOMM连接建立的时序关系：
SDP查询的代码示例（基于BlueZ D-Bus API）
# 使用 bluetoothctl 进行 SDP 服务发现
bluetoothctl > scan on
bluetoothctl > devices
bluetoothctl > info <设备MAC地址>
# 使用 sdptool 查询 HFP 服务
sdptool browse <设备MAC地址>
# 典型输出片段（HFP服务记录）：
# Service RecHandle: 0x10005
# Service Class ID List:
# "Hands-Free Audio Gateway" (0x111E)
# Protocol Descriptor List:
# "L2CAP" (0x0100)
# "RFCOMM" (0x0003)
# Channel: 5
# Bluetooth Profile Descriptor List:
# "Hands-Free" (0x111E)
# Version: 0x0108
开发要点：在车载HFP集成中，SDP查询结果中的RFCOMM通道号是关键参数。如果AG设备动态分配通道号（非固定值），HF必须每次连接前重新查询。部分车载系统会缓存SDP记录，但建议在每次建立HFP连接前执行一次SDP查询，以确保通道号有效。
2.5 本章小结
- 经典蓝牙 vs BLE：HFP必须使用经典蓝牙（BR/EDR）的SCO/eSCO链路传输音频，BLE用于低功耗辅助功能。
- 协议栈架构：HFP位于应用层，依赖RFCOMM（数据通道）、SDP（服务发现）和L2CAP（底层传输）。
- RFCOMM：仿真串口，承载AT命令，支持多路复用和流控。
- SDP：服务发现协议，用于查询AG的HFP服务记录，获取RFCOMM通道号、Profile版本和特性。