4、L2CAP层与信道管理：L2CAP连接建立流程、信道ID分配、MTU协商、分段重组机制、MTK平台L2CAP配置参数调优
各位同学，今天我们聊聊L2CAP层。说实话，很多做蓝牙应用层的朋友，对L2CAP的理解就停留在“一个传输层”上。但真正做到底层协议栈开发，你会发现L2CAP才是整个蓝牙通信的“交通枢纽”。
我在MTK平台上调试车载蓝牙电话时，遇到过好几次通话断续、电话本同步失败的问题。查到最后，根因都在L2CAP层——要么是MTU没协商好，要么是信道ID冲突了。所以这一章，我带你从实战角度，把L2CAP吃透。
4.1 L2CAP连接建立流程
L2CAP的连接建立，说白了就是两个设备之间开一条“专用通道”。这个通道不是凭空出现的，它要经过几个明确的步骤。
我个人习惯把L2CAP连接建立分为三个阶段：
- 信道请求阶段：上层协议（比如RFCOMM、AVDTP）告诉L2CAP层：“我要跟对端通信，给我开个信道。”
- 连接参数协商阶段：双方交换MTU、超时时间等参数。这一步很关键，很多兼容性问题就出在这里。
- 信道建立完成阶段：双方确认参数，分配信道ID，连接建立成功。
在MTK平台上，L2CAP连接建立的API调用顺序大概是这样的：
// 伪代码示例 - MTK平台L2CAP连接建立
// 1. 注册L2CAP回调
L2C_RegisterCallback(l2cap_callback);
// 2. 发起连接请求
L2C_ConnectReq(remote_bd_addr, psm, &channel_id);
// 3. 等待对端响应
// 回调函数中处理连接确认
void l2cap_callback(L2C_CBACK_EVENT event, void *data) {
switch(event) {
case L2C_CONNECT_CFM:
// 连接确认，拿到信道ID
channel_id = data->channel_id;
break;
case L2C_CONNECT_IND:
// 对端发起连接，需要响应
L2C_ConnectRsp(remote_bd_addr, channel_id, result);
break;
}
}
实战小贴士：我在项目中遇到过一个问题——车载主机发起连接请求后，手机端迟迟不响应。后来发现是PSM（协议服务复用器）值没对上。车载端用的是0x1003，手机端注册的是0x1001。你想想看，这能连上才怪。所以一定要确认两端的PSM一致。
4.2 信道ID分配
信道ID（CID）是L2CAP层用来标识不同信道的唯一标识符。每个L2CAP连接都有一个独立的CID。
CID的分配规则其实很简单：
- 0x0001：信令信道（固定）
- 0x0002-0x003F：保留给固定信道
- 0x0040-0xFFFF：动态分配，用于数据信道
在MTK平台上，CID是由协议栈自动分配的。但有一点要注意——CID的分配是单向的。什么意思呢？就是发起端和对端各自维护自己的CID映射表。
我记得有一次调试，发现车载端和手机端的CID对不上。车载端认为信道ID是0x0042，手机端却认为是0x0045。后来查了协议栈源码才发现，MTK平台在CID分配时，会先检查这个CID是否已经被占用。如果被占用了，就往后顺延。
注意：CID的分配不能超过0xFFFF。如果动态分配的范围用完了，新的连接请求会被拒绝。在车载场景下，如果同时连接多台手机（比如主驾和副驾），CID可能会耗尽。我建议你在设计时预留足够的CID池。
4.3 MTU协商
MTU（最大传输单元）是L2CAP层最重要的参数之一。它决定了每个L2CAP数据包能承载的最大数据量。
MTU协商的过程是这样的：
- 发起端发送连接请求时，会带上自己的MTU值。
- 对端收到后，比较自己的MTU和发起端的MTU，取较小值作为最终MTU。
- 双方确认后，后续的数据传输都按这个MTU来。
在车载蓝牙电话场景中，MTU的协商直接影响通话质量和电话本同步速度。我举个例子：
| 场景 | MTU值 | 影响 |
|---|---|---|
| HFP（免提协议） | 48-64字节 | 通话控制指令小，MTU小也没问题 |
| PBAP（电话本同步） | 512-1024字节 | MTU越大，同步越快 |
| AVDTP（音频流） | 672-1004字节 | MTU影响音频延迟 |
在MTK平台上，MTU的配置是通过L2C_Config接口实现的：
// MTK平台MTU配置示例
L2C_Config config;
config.mtu = 672; // 设置MTU为672字节
config.flush_timeout = 0xFFFF; // 超时时间
L2C_Config(channel_id, &config);
核心观点：MTU不是越大越好。MTU太大，底层HCI包会被拆成多个ACL包，反而增加重传概率。我个人建议车载场景下，MTU设置在512-672字节之间，兼顾效率和稳定性。
4.4 分段重组机制
分段重组（SAR）是L2CAP层解决“上层数据太大，底层传不了”的问题。说白了，就是大包拆小包，到了对端再拼回去。
L2CAP的分段重组分为两种：
- 基本模式：每个L2CAP包直接映射到一个ACL包。如果L2CAP包大于ACL包，就分段。
- 增强模式：支持重传和流控，分段重组更复杂。
在MTK平台上，分段重组是协议栈自动完成的。但有一个坑——重组超时。如果某个分段丢了，对端会一直等，直到超时。超时后整个L2CAP包都会被丢弃。
我曾经在调试电话本同步时，发现同步到一半就卡住了。抓包一看，有个分段丢了，对端等了5秒还没等到，直接超时断开连接。后来我调整了重组超时时间，从默认的5秒改成10秒，问题就解决了。
避坑指南：我曾经在MTK平台上遇到一个奇葩问题——分段重组时，数据包顺序乱了。后来发现是底层ACL包的序列号出了问题。解决方案是开启L2CAP层的“按序递交”功能，强制保证数据包顺序。
4.5 MTK平台L2CAP配置参数调优
好了，前面讲了理论，现在说说实战。MTK平台的L2CAP层有很多可配置参数，调好了能显著提升性能。
我整理了一份常用的调优参数表：
| 参数名 | 默认值 | 推荐值（车载场景） | 说明 |
|---|---|---|---|
| MTU | 672 | 512-672 | 电话本同步建议用1024 |
| Flush Timeout | 0xFFFF | 0x7FFF | 减少超时等待 |
| Max Transmission | 3 | 5 | 增加重传次数，提高可靠性 |
| Retransmission Timeout | 200ms | 100ms | 加快重传响应 |
| Monitor Timeout | 12s | 6s | 快速检测连接断开 |
在MTK平台上，这些参数通常在bt_config.c或l2c_config.c中配置。我建议你这样做：
// MTK平台L2CAP参数调优示例
// 文件路径：vendor/mediatek/proprietary/bluetooth/stack/l2c/l2c_config.c
// 调整MTU
#define L2C_MTU_SIZE 672
// 调整重传超时
#define L2C_RETRANS_TIMEOUT 100 // 单位：ms
// 调整最大重传次数
#define L2C_MAX_TRANSMISSION 5
// 调整监控超时
#define L2C_MONITOR_TIMEOUT 6 // 单位：秒
重要提醒：参数调优不是万能的。如果你发现L2CAP层频繁断开连接，先检查底层射频环境，再检查HCI层，最后才是L2CAP参数。我曾经见过一个项目，工程师调了三天L2CAP参数，结果发现是天线匹配有问题。嗯，这个教训挺深刻的。
最后，我想说一句：L2CAP层是蓝牙协议栈的“腰部”，承上启下。你把它调好了，上层协议（HFP、PBAP、AVRCP）跑起来就顺畅。你把它忽略了，上层再优化也没用。
下一章，我们会讲RFCOMM层，也就是蓝牙串口仿真协议。到时候我会结合车载蓝牙电话的AT指令交互，给你讲讲RFCOMM的实战经验。咱们下节课见。