13 · 蓝牙协议栈分层详解(小白第二课)

适用范围:纯协议科普,不依赖本仓代码。承接 10-蓝牙协议速成 的「三层状态」心智模型,往下挖一层——这些协议到底是怎么摞起来的,数据从应用到无线电波走了哪些层。 关联:缩写全称查 14-缩写词源手册;各 profile 干嘛、靠什么传输查 15-Profile与传输协议图解。 已核实基准:_已核实事实基准

0. 为什么要分层

新人看到 HFP、A2DP、L2CAP、ACL 一堆词会懵,根因是不知道它们处在不同高度。蓝牙协议栈和 TCP/IP 一样是分层的,分层只有一个目的:让每一层只管一件事,下层给上层当基础设施复用

打比方:寄快递。你(应用层)只管写好信塞进信封;快递公司(传输层)只管按单号分拣;卡车(链路层)只管在路上跑;公路(物理层)只管铺好。你不用关心卡车走哪条高速。蓝牙分层同理——A2DP(放歌)和 HFP(打电话)都复用同一条 L2CAP 管道,L2CAP 不关心上面传的是音乐还是电话。

⚠️ 一句话核心:蓝牙 = 两套并行的栈(BR/EDR 经典栈 + BLE 低功耗栈),共享部分中间层(L2CAP/HCI 概念一致),但底层物理和服务发现完全不同。车机连手机走 BR/EDR 栈;车机连蓝牙钥匙/胎压走 BLE 栈。

1. 一张总图:从无线电波到应用

flowchart LR
    subgraph APP["应用 / Profile 层<br/>(你用的功能)"]
        direction LR
        HFP[HFP 电话]
        A2DP[A2DP 音频]
        PBAP[PBAP 通讯录]
        GATT[GATT 传感器/钥匙]
    end
    subgraph MID["中间件层<br/>(传输 + 服务发现)"]
        direction LR
        AVDTP[AVDTP/RFCOMM/OBEX<br/>传输协议]
        SDP[SDP 经典]
        ATT[GATT/ATT BLE]
        L2CAP["L2CAP<br/>(多路复用管道)"]
    end
    subgraph CTRL["控制器层(蓝牙芯片里)"]
        direction LR
        HCI[HCI 主机-控制器接口]
        LM[LMP/LL 链路管理]
        BB[Baseband 基带]
    end
    subgraph PHY["物理层(射频)"]
        direction LR
        BR["BR/EDR<br/>79 信道"]
        LE["BLE<br/>40 信道"]
    end
    HFP --> AVDTP
    A2DP --> AVDTP
    PBAP --> AVDTP
    GATT --> ATT
    AVDTP --> L2CAP
    SDP --> L2CAP
    ATT --> L2CAP
    L2CAP --> HCI
    HCI --> LM
    LM --> BB
    BB --> BR
    BB --> LE

读法(自上而下 = 数据发出的方向):应用把数据交给传输协议 → 传输协议塞进 L2CAP 管道 → L2CAP 经 HCI 交给芯片 → 芯片里链路管理 + 基带打包 → 基带控制射频发射。接收端反过来逐层拆包。

2. 逐层拆解(自底向上)

自底向上读,因为上层依赖下层,先有路才能跑车。

2.1 物理层 PHY ——「铺公路」

只管一件事:把 0/1 比特调制成无线电波发出去。工作在 2.4 GHz ISM 频段(全球免费工业/科学/医疗频段,微波炉、WiFi 也在这儿,所以很挤)。

BR/EDR(经典)BLE(低功耗)
信道数79 个,每信道宽 1 MHz40 个,每信道宽 2 MHz
信道编号0–78,中心频率 2402 + n MHz0–39,中心频率 2402 + 2n MHz
调制GFSK(1M)/ π/4-DQPSK(2M)/ 8DPSK(3M)GFSK(1M,可选 2M/编码 PHY)
抗干扰跳频(AFH),79 信道里每秒跳 1600 次广播用 3 个固定信道(37/38/39),数据 37 个信道慢跳

小白疑问:为什么 BLE 只有 40 个信道还更省电? 因为 BLE 不像经典蓝牙那样「一直保持连接不停地跳」,而是「睡 → 定时醒一下收发 → 再睡」。40 个信道里有 3 个专门做广播(设备互相发现用),其余 37 个传数据。信道宽 2 MHz 是为了和 WiFi(1/6/11 信道各占 22 MHz)错开减少互踩。

「79ch / 40ch」就指这里的信道数。日志里看到 channel 23 就是当前跳频停在第 23 号信道。

2.2 基带 / 链路控制器 Baseband ——「组队 + 打包」

物理层只管发比特,但谁来组织「谁和谁一组、数据怎么切片、错了重传」?基带干这些:

  • 微微网(piconet):1 个主设备(Master/Central)+ 最多 7 个从设备(Slave/Peripheral)组成一队,全员同步跳频(主设备定节奏,从设备跟着跳)。
  • 逻辑链路类型(重点,下面 ACL 会细讲):
    • ACL(异步无连接):传数据,可重传,走 L2CAP,所有 profile 数据都走它
    • SCO/eSCO(同步面向连接):传语音,固定速率、不重传、绕过 L2CAP 直接到基带。打电话的声音走 SCO(详见 15 HFP 节)。
  • 打包:加接入码(识别是哪个微微网的包)+ 包头(地址/类型/重传标志)+ 载荷 + CRC + 前向纠错(FEC)。

BR/EDR ACL vs LE ACL 区别:两者都叫「ACL」,都是异步数据管道,但分属两套物理体系——BR/EDR ACL 跑在 79 信道经典基带上(高吞吐),LE ACL 跑在 40 信道 BLE 链路层上(低功耗,按连接事件 Connection Event 收发)。应用层看到的 ACL 概念一致,底层物理完全不同

2.3 链路管理 LMP / LL ——「管链路本身」

基带把链路建起来了,但「怎么配对换密钥、怎么调功率、怎么管理 QoS」由链路管理层处理。它运行在两个设备的链路管理器之间(不经过上层应用):

  • BR/EDR 侧叫 LMP(Link Manager Protocol)。
  • BLE 侧叫 LL(Link Layer)+ SMP(Security Manager Protocol,专门管 BLE 配对)。

配对(bond)、密钥协商(Link Key / LTK)就发生在这里——这正是 11-配对与SSP 讲的那一层。新人记住:配对是链路管理层的活,不是应用层的事

2.4 HCI ——「主机和芯片的分界线」

HCI(Host Controller Interface) 不是一层功能,而是一条标准接口:把「主机(手机/车机的蓝牙协议栈软件)」和「控制器(蓝牙芯片硬件)」隔开。

  • 主机通过 HCI 给芯片发命令(如「连接这个 MAC」)、收事件(如「连上了」)、传 ACL/SCO 数据
  • 物理传输常走 UART / USB / SDIO。
  • 排障关键:HCI snoop log(btsnoop_hci.log)就是抓这条接口上所有往来的包,是蓝牙问题的「终极证据」。蓝牙问题查到 HCI 层基本就到底了。

分层意义:有了标准 HCI,换芯片厂商不用改主机软件(高通/博通/玄戒芯片对上层是透明的)。这正是为什么 Android 蓝牙框架能跨平台。

2.5 L2CAP ——「多路复用管道」

L2CAP(Logical Link Control and Adaptation Protocol) 是中间件层最核心的一层。解决的问题:一条 ACL 物理管道上同时跑好多上层协议,怎么区分谁是谁?

  • 给每个上层连接分配一个信道号 CID(Channel ID),收发时按 CID 分拣,互不干扰——就像一栋楼里每户一个门牌号。
  • 负责分段与重组:上层给的包可能很大(比如几 KB 音频帧),L2CAP 切成基带能装下的小片,对端再拼回去。
  • BR/EDR 用动态 CID(运行时分配),BLE 用固定 CID(如 ATT 永远是 0x0004)。

关键认知:HFP、A2DP、PBAP、SDP、ATT 全都跑在 L2CAP 之上。L2CAP 是 BR/EDR 和 BLE 共享的概念层(虽然细节不同)。新人看到「L2CAP」就知道:这是数据进出芯片前最后一道「分拣+打包」。

2.6 服务发现层 ——「对方支持啥服务」

连上之后怎么知道对端有哪些功能?靠服务发现。两套栈各有一套

BR/EDRBLE
协议SDP(Service Discovery Protocol)ATT + GATT
查询方式用 UUID 查服务,拿回属性列表按「服务→特征值→描述符」树状读
数据组织服务记录 service record属性数据库 attribute database
  • SDP:经典蓝牙用。车机配对后查「你支持 HFP/A2DP 吗」。详见 10 §3ACTION_UUID 广播就是 SDP 完成后发的)。
  • ATT/GATT:BLE 用。ATT(Attribute Protocol)是底层传输,GATT(Generic Attribute Profile)定义「服务/特征值」怎么组织。车机读蓝牙胎压传感器的数值,就是 GATT 读一个 characteristic。

为什么两套:BLE 设计目标是省电+简单,SDP 太重;ATT/GATT 是为 BLE 重新设计的轻量服务模型。但近年 BLE Audio 也把音频搬到了 GATT 体系(见 15 LeAudio 节)。

2.7 中间件传输协议 ——「Profile 的专用快递」

L2CAP 是通用管道,但很多 profile 有自己的传输需求,于是中间还垫了一层专用协议(这才是「这些缩写到底是干嘛」的关键,详见 15):

传输协议给谁用解决什么
RFCOMMHFP(AT 命令)、SPP、旧版串口应用模拟 RS-232 串口(9 针那种),把「串口数据」搬上蓝牙
AVDTPA2DP(音频流)音视频流的分发传输,带时间戳
AVCTPAVRCP(遥控)音视频控制命令传输
OBEXPBAP(通讯录)、MAP(短信)、OPP对象交换(原本是红外 IrDA 的,搬上蓝牙传文件)

2.8 应用 / Profile 层 ——「你用的功能」

最顶层就是你真正用的功能:HFP(打电话)、A2DP(放歌)、PBAP(读通讯录)、GATT(读传感器)。它们自己不直接碰无线电,而是层层委托给下面的传输协议 → L2CAP → 芯片 → 射频。每个 profile 是什么、车机扮演什么角色,详见 12-Profile体系与车机角色(代码视角)和 15-Profile与传输协议图解(协议视角)。

3. 数据通路:一首歌从手机到车机喇叭

把分层串成一条真实的数据流(强烈建议新人把这条链路背下来):

flowchart TD
    A["📱 手机 App:播放音乐"] -->|音频帧| B["A2DP Source 编码(SBC/AAC)"]
    B --> C["AVDTP 分发传输(带时间戳)"]
    C --> D["L2CAP 分段 + 分配 CID"]
    D --> E["HCI 交给手机蓝牙芯片"]
    E --> F["基带打包 + 跳频发射(79 信道之一)"]
    F -.无线电波.-> G["🚗 车机射频收到"]
    G --> H["车机基带拆包"]
    H --> I["HCI 上报给车机协议栈"]
    I --> J["L2CAP 按 CID 重组"]
    J --> K["AVDTP 还原音频流"]
    K --> L["A2DP Sink 解码"]
    L --> M["🔊 车机喇叭发声"]

记住:每个 profile 的数据都走「Profile → 自己的传输协议 → L2CAP → HCI → 基带 → 射频」这条链,只是中间的「传输协议」不同(HFP 用 RFCOMM+SCO,A2DP 用 AVDTP,PBAP 用 OBEX)。底层 6 层是复用的,这就是分层的价值。

4. BR/EDR 栈 vs BLE 栈 对照

新人最易混的就是「两套栈到底差在哪」。一张表对死:

BR/EDR 经典栈BLE 低功耗栈
物理79 信道,1 MHz 宽,GFSK/π/4-DQPSK/8DPSK40 信道,2 MHz 宽,GFSK(1M/2M/编码)
基带链路微微网主从,AFH 跳 1600 次/s广播信道 + 连接事件,间歇收发
同步语音SCO/eSCO(绕 L2CAP)无(LE Audio 走 ISO 通道,5.2+)
链路管理LMPLL + SMP
中间件L2CAP(动态 CID)L2CAP(固定 CID)
服务发现SDPATT + GATT
典型 profileHFP/PBAP/A2DP/MAP钥匙/胎压/Beacon/LeAudio
车机场景连手机(电话/通讯录/音乐)连传感器(钥匙/胎压/手环)

⚠️ 一个设备可同时跑两套栈(Dual Mode)。车机芯片基本都双模:既能连手机(BR/EDR),又能连蓝牙钥匙(BLE)。日志里 Transport: 1=BR/EDR、Transport: 2=BLE(见 10 2956 实证)。

5. 常见混淆证伪

混淆纠正
「L2CAP 是一种 profile」错。L2CAP 是所有 profile 共用的管道层,不是功能本身。
「SCO 也走 L2CAP」错。SCO/eSCO 是电路交换同步链路,绕过 L2CAP 直达基带,专门传语音。
「BLE 没有 L2CAP」错。BLE 也有 L2CAP,只是用固定 CID、更简单。
「换蓝牙芯片要改 App」错。HCI 标准化,上层协议栈和 App 对芯片透明。
「应用数据直接进射频」错。中间至少经 传输协议→L2CAP→HCI→基带 4 层。

6. 和已有文档的关系

四篇一起构成「新人协议地基」。读完再进 20-Android框架全景 看代码怎么落地。


一句话收尾:蓝牙分层 = 复用 + 解耦。底层(PHY/基带/HCI/L2CAP)给所有 profile 当公共基础设施,上层(profile)只管业务逻辑。看任何蓝牙问题,先定位它卡在哪一层,就知道了该看什么日志、问什么人。