4. 经典蓝牙（BR/EDR）面试：配对、连接、SCO/eSCO、A2DP/HFP

本章聚焦经典蓝牙核心链路与Profile，覆盖配对连接流程、同步连接（SCO/eSCO）质量保障、以及A2DP/HFP两大主流应用。面试高频考点包括：SSP配对阶段、ACL链路角色、SCO参数协商、以及A2DP编解码策略。以下框架图梳理配对连接的典型回答路径，帮助你在面试中快速组织语言。

配对发起 IO能力交换 密钥生成(SSP) ACL连接 角色切换 回答加分点：区分 Legacy Pairing 与 SSP，强调 MITM 保护 角色切换场景：Phone ↔ Headset 的 Master/Slave 协商
💡 面试策略提示： 面试官常从“配对流程是否安全”切入，逐步深入至 eSCO 参数、A2DP 的编解码延迟。建议先用框架图示范整体结构，再通过卡片细节展现深度。

卡片1：经典蓝牙配对流程与安全模型

❓ 面试问题

请简述经典蓝牙（BR/EDR）的配对流程，并说明 SSP（Secure Simple Pairing）相比传统 Pin Code 的优势。

🎯 面试官考察点

  • 是否理解配对过程的四个核心步骤（IO能力交换、密钥生成、链路密钥派生、认证）
  • 是否了解 SSP 的四种关联模型（Numeric Comparison, Just Works, Passkey Entry, OOB）及其适用场景
  • 能否指出 Legacy Pairing 的安全漏洞（固定 PIN、中间人攻击）

📐 回答框架

  1. 总述：经典蓝牙配对是建立信任关系的过程，SSP 是当前主流方案。
  2. 分步：①双方交换 IO Capabilities → ②根据模型选择密钥生成方式 → ③使用 ECDH 临时公钥派生链路密钥 → ④通过 Link Key 认证完成连接。
  3. 对比：SSP 每次使用随机临时密钥，Legacy Pairing 固定 PIN 易被暴力破解。

✏️ 简短示例回答

“经典蓝牙配对传统使用固定 PIN，容易被嗅探。SSP 通过 IO 能力交换选择 Numeric Comparison 等模型，利用 ECDH 每次生成临时密钥，有效防止 MITM。例如耳机与手机配对时，用户比对显示屏上六位数确认，大幅提升安全性。”

🔁 可能追问

  • "SSP 的 Just Works 模型安全吗？为什么？（不安全，无用户验证，易被 MITM）"
  • "OOB 模型如何在经典蓝牙中实现？（通过 NFC 交换临时密钥）"
  • "Legacy Pairing 在什么场景下仍被使用？（低功耗、无显示设备且兼容旧版）"
⚠️ 避坑提醒：不要只说“SSP 更安全”而不解释具体机制。面试官期望你提到 ECDH、MITM 保护、关联模型选择依据。不要混淆 BR/EDR 的 SSP 与 LE 的 Secure Connections。

卡片2：SCO / eSCO 链路与语音质量保障

❓ 面试问题

SCO 和 eSCO 有什么区别？在 HFP 应用场景中如何选择参数以保证语音质量？

🎯 面试官考察点

  • 是否理解 SCO 固定间隔（每两个时隙预留）与 eSCO 可协商间隔/重传
  • 能否说出典型 eSCO 参数（如 T_esco=12, W=4, N=2）的含义
  • 是否知道丢包、干扰对语音质量的影响以及 eSCO 重传的代价

📐 回答框架

  1. 定义：SCO 使用固定时隙，无重传；eSCO 可协商间隔、窗口和重传次数。
  2. 参数：eSCO 通过 T_esco（间隔）、W（窗口）、N（重传数）控制带宽和鲁棒性。
  3. 调优：高干扰环境增加 N 和 W 但牺牲吞吐；对延迟敏感则减小 T_esco。

✏️ 简短示例回答

“SCO 固定每两个时隙传输 64kb/s CVSD 语音，无重传；eSCO 允许协商参数，例如 T_esco=12、W=4、N=2 表示每 12 个时隙预留 4 个时隙窗口，最多重传 2 次。在车载环境中，我会增大重传次数以对抗蓝牙干扰。”

🔁 可能追问

  • "eSCO 重传会影响其他 ACL 链路吗？（会占用额外时隙，需合理规划 Piconet）"
  • "CVSD 和 mSBC 编解码在 eSCO 下的区别？（mSBC 用于宽带语音，吞吐更高）"
  • "如何测量 eSCO 的丢包率？（通过 HCI 层统计 Link Quality 或 HCI_Ethosync_Link）"
⚠️ 避坑提醒：不要认为 eSCO 一定优于 SCO。对于极低延迟场景（如实时对讲），SCO 的固定间隔反而更稳定。面试时需同时给出权衡分析。

卡片3：A2DP / HFP 协议栈与应用层优化

❓ 面试问题

在 A2DP 音频流中，如何选择编解码（SBC / AAC / aptX / LDAC）？HFP 中的 AG（Audio Gateway）和 HF（Hands-Free）如何协调编解码协商？

🎯 面试官考察点

  • 是否熟悉 A2DP 的协议栈：AVDTP、AVDTP_SRC/SINK、Codec Capabilities 交换
  • 能否解释 HFP 的 AT 命令（+BCS、+BRSF）与 Codec Negotiation 流程
  • 是否了解各编解码的比特率、延迟、兼容性限制

📐 回答框架

  1. A2DP：Source 通过 AVDTP 发送 Codec Capabilities，Sink 回复所选 Codec；SBC 必选，其他可选。
  2. HFP：AG 发送 +BCS 列出支持编解码列表，HF 回复选择；之后启动同步连接。
  3. 优化：低延迟场景选择 aptX Low Latency 或 SBC 双通道；高音质选 LDAC。

✏️ 简短示例回答

“A2DP 中 SBC 是强制编解码，音质取决于位池分配；AAC 在 iOS 生态中优化好；aptX 提供接近 CD 音质。HFP 通过 +BCS 命令协商，例如车载耳机支持 mSBC 宽带语音，AG 回复选择后建立 eSCO。”

🔁 可能追问

  • "SBC 的位池（Bitpool）参数如何影响音质？（越大音质越好，但需考虑带宽）"
  • "A2DP 播放延迟主要来自哪里？（缓冲区、编解码处理、蓝牙调度）"
  • "HFP 1.7 引入的 Wide Band Speech 有何改进？（使用 mSBC 编码，采样率 16kHz）"
⚠️ 避坑提醒：不要将 A2DP 和 HFP 的编解码协商混为一谈。A2DP 走 AVDTP，HFP 走 AT 命令。面试中需明确区分 Profile 层级和传输通道。

📁 项目案例：车载蓝牙免提系统（BR/EDR）

项目名称车载蓝牙免提通信模块（基于高通 CSR8675 + Linux）
业务背景某 Tier1 供应商开发车载 IVI 系统的蓝牙免提功能，需支持 HFP 1.7（宽带语音）、A2DP 音频播放、以及同时连接两部手机（HFP Multipoint）。
规模指标单台设备峰值 3 条 ACL 链路（两部手机 + 1部媒体源）；eSCO 链路丢包率 < 1%（测试环境 5m 射频干扰）；A2DP 延迟 < 150ms。
技术栈BlueZ 协议栈、Qualcomm MDE 2.0、HCI Transport（UART）、CVSD/mSBC 编解码、AptX 解码器
核心难点① 双手机同时 HFP 时 Master/Slave 频繁切换导致音频中断；② eSCO 参数与 A2DP 时隙冲突造成断流；③ 宽带语音 mSBC 与普通 eSCO 兼容性。

面试高频追问

  • "如何解决双手机同时 HFP 时的角色切换问题？"（使用 Multipoint 模式，AG 端主动协调 BT Clock 偏移；或限定其中一路为 Slave）
  • "实测 eSCO 丢包率超标时，你如何调整参数？"（先增大重传数 N，若仍不行则延长 T_esco，同时降低 A2DP 位池）
  • "mSBC 编码与普通 eSCO 的链路参数有何不同？"（mSBC 要求 T_esco 更短、W 更大，以支持 16kHz 采样率）
💬 可迁移回答话术：“在车载项目中，我主导了 eSCO 与 A2DP 的时隙复用方案，通过调整 eSCO 的 T_esco=12 并将 A2DP 的媒体调度窗口置于空闲时隙，最终将丢包率降低至 0.3%。面试中强调链路调度算法、参数调优过程，比只描述功能更有说服力。”
📌 章节小结：经典蓝牙面试的核心是“链路层机制”与“应用层 Profile”的结合。配对讲安全模型，SCO/eSCO 讲参数权衡，A2DP/HFP 讲编解码协商。用真实案例说明调度和兼容性问题，远胜于背诵协议细节。
← 上一章 📖 返回目录 下一章 →