【android bluetooth 协议分析 03】【蓝牙扫描详解 3】【Bluetooth 中 EIR、IR、BLE 普通广播与扩展广播详解】
Bluetooth 中 EIR、IR、BLE 普通广播与扩展广播详解
本篇文章将详细介绍 Bluetooth 规范中四种关键广播机制：
-
BR/EDR 中的 EIR (Extended Inquiry Response)
-
BR/EDR 中的 IR (Inquiry Response)
-
BLE 中的 普通广播（Legacy Advertising）
-
BLE 中的 扩展广播（Extended Advertising）
文中将结合 Bluetooth Core Specification v5.3 标准内容，解释每种广播的结构、使用场景和各自的优势。
一、BR/EDR 中的 Inquiry Response (IR)
基本定义
IR 是经典蓝牙 BR/EDR 设备在执行 Inquiry 流程时，用于回应探测设备的基础广播消息。
特点
-
最多包含 240 bits（30 bytes）数据
-
由 Controller 自动发送
-
包含设备地址（BD_ADDR）、Class of Device（CoD）
存在的限制
-
可包含的信息类型有限
-
无法承载自定义厂商数据、完整设备名称等信息
使用场景
- 早期 BR/EDR 设备发现阶段（如功能机蓝牙配对）
二、BR/EDR 中的 Extended Inquiry Response (EIR)
基本定义
EIR 是为了解决标准 IR 无法承载丰富信息的问题，从 Core Spec v2.1 引入。
数据结构
EIR 数据通过 HCI 命令或事件传递，其格式为 TLV（Type-Length-Value）：
| Length (1 Byte) | Type (1 Byte) | Value (Length - 1 Bytes) |
常见 EIR Type（参见 Core 5.3 Vol 3, Part C, Section 18.3.2）
| Type Code | 名称 | 内容 |
|---|---|---|
| 0x09 | Complete Local Name | 设备完整名称 |
| 0x08 | Shortened Local Name | 设备简短名称 |
| 0x0A | Tx Power Level | 发送功率 |
| 0x0D~0x11 | Class of Device/Service UUID | 支持的服务 UUID |
| 0xFF | Manufacturer Specific Data | 厂商自定义数据（如小米、华为等定制） |
使用场景
-
车机（head unit）向手机广播更多服务信息（音频、电话、HFP、PBAP 等）
-
蓝牙配对时展示更丰富的信息
优势
-
灵活的数据结构
-
可自定义字段
三、BLE 中的普通广播（Legacy Advertising）
基本定义
BLE 普通广播是 BLE 最初引入的广播方式，用于广播存在、连接请求、数据同步等。
数据结构
-
广播包（Advertising Packet）：最大 31 字节
-
扫描响应包（Scan Response Packet）：额外 31 字节（需要扫描器发送 SCAN_REQ）
广播信道
- 使用 3 个广播信道（37, 38, 39）
常见字段（同样使用 TLV 编码）
-
Complete Local Name
-
Flags（如可连接、可发现等）
-
16-bit/128-bit Service UUIDs
-
Manufacturer Data
使用场景
-
简单的传感器设备（温度计、心率计）
-
低功耗定向广播（如 iBeacon）
限制
-
数据量有限（最多 31 + 31 字节）
-
广播速率固定，且受主广播通道影响
四、BLE 中的扩展广播（Extended Advertising）
引入背景
从 Core Spec 5.0 起，为了解决 BLE 广播数据容量与灵活性不足问题，Bluetooth SIG 引入 扩展广播机制。
特点
-
支持 非广播通道 扩展：扩展广播可以跳出传统 37/38/39 信道，使用数据通道广播
-
单个广播事件最多可传输 255 字节，可通过链式方式进一步扩展（最高可达数 KB）
-
支持 Periodic Advertising 和 Advertising Sets
-
支持 非连接广播 和 长数据传输
广播结构
-
初始包仍在 3 个主广播信道上发送
-
后续数据在指定的扩展通道上广播
使用场景
-
大量广播信息（如完整 GATT 服务信息）
-
升级版 Beacon（如 Apple 的 AirTag 定位）
-
无连接的数据传输设备（如公交车 ETA 广播）
-
蓝牙 Mesh 的 Provisioning 或 Beaconing
对比表
| 特性 | 普通广播 | 扩展广播 |
| 最大数据长度 | 31+31 字节 | 最多 1650 字节（链式） |
| 使用信道 | 37/38/39 | 可用数据通道 |
| 是否支持 Periodic | 否 | 是 |
| 是否支持长广播数据 | 否 | 是 |
| 功耗 | 较低 | 较高（可调节） |
| 硬件支持要求 | 所有 BLE 芯片 | 需要支持 BLE 5.0+ |
总结：场景选择建议
| 应用场景 | 推荐广播类型 |
| 经典设备发现 | IR + EIR |
| 简单 BLE 外设配对 | BLE 普通广播 |
| 支持 BLE 5.0 的 Beacon | BLE 扩展广播 |
| 无连接长数据传输 | BLE 扩展广播 |
| 厂商定制配对识别 | EIR + Manufacturer Data |
附录：为何车机中只有 EIR 没有 IR？
现代车机往往配置较高、支持 Bluetooth 2.1+EDR，因此在蓝牙设备发现阶段直接使用 EIR 结构来包含更丰富的服务和属性数据，而不再使用受限的标准 Inquiry Response（IR）。这也可以减少冗余、提高交互效率。因此在 btsnoop 中常只看到 EIR，而非 IR。
如需进一步深入了解各字段含义与协议交互机制，建议参考 Bluetooth Core Spec v5.3 Vol 3, Part C（Generic Access Profile）以及 Vol 2, Part E（Host Controller Interface）。
🤖 好了，文章结束，逻辑理清，脑细胞也差不多燃尽了。
如果你看到这，说明你是真·有缘人，那就别客气：
👉 点个赞鼓励一下，不然我都怀疑是不是 AI 在看我的文章……
👉 留个言交个朋友，说不定下一个版本更新的坑我们一起踩～
👉 转发分享更不用说，同行之间互通有无、抱团取暖、集体升级打怪才是正道！别做默默潜水的 “系统服务”，上线回应一下，别让我像个 Binder 一样孤独等待调用😭！