ACL 控制逻辑链路 (ACL-C)

ACL 控制逻辑链路 (ACL-C) 可用于在微微网中的设备之间负载 LMP 信令。控制链路仅负载于默认的 ACL 逻辑传输和 PSB 逻辑传输上（位于控制信息相位）。当负载于同一逻辑传输上时，ACL-C 链路总是优先于 ACL-U（见下）链路。

用户异步/等时逻辑链路 (ACL-U)

用户异步/等时逻辑链路 (ACL-U) 可用于负载所有异步和等时帧化用户数据。ACL-U 链路可负载于同步逻辑传输以外的所有逻辑传输上。ACL-U 链路上的数据包由两个保留 LLID 值中的其中一个值标识。一个值用于指明基带数据包是否含有 L2CAP 帧头，另一个用于表示前一帧的继续。这确保了跟随所删除数据包的 L2CAP 重组装器正确同步。使用此技术排除了在所有基带数据包中包括更加复杂的 L2CAP 包头的需要（包头只需存在于 L2CAP 起始数据包中），但要求在传输完一个完整的 L2CAP 帧后才能开始新传输。（此规则也有例外，即可以删除传输了一部分的 L2CAP 帧以便开始传输另一 L2CAP 帧。）

用户同步/扩展同步逻辑链路 (SCO-S/eSCO-S)

同步 (SCO-S) 和扩展同步 (eSCO-S) 逻辑链路用于支持在无帧流中传输的等时数据。这些链路与一个逻辑传输相关联，在这个逻辑传输上，数据按固定大小和固定速率传输。在这些传输上，由于只支持单个逻辑链路，数据长度和调度期已预定义并在链路存在周期内保持固定，所以数据包中没有 LLID。

SCO-S 或 eSCO-S 逻辑链路无法负载变速等时数据。在这种情况下，数据必须负载于使用带净荷包头的数据包的 ACL-U 逻辑链路。如果在处理可靠用户数据时同时支持变速等时数据，Bluetooth 技术会有一些限制。

L2CAP 信道

L2CAP 充当多路复用的角色以允许多个不同的应用程序在两个设备之间共享 ACL-U 逻辑链路的资源。应用程序和服务协议使用面向信道的接口与 L2CAP 相接以创建至其它设备上对等实体的连接。

L2CAP 信道端点通过信道标识符 (CID) 为其客户端所识别。此标识符由 L2CAP 分配，任何设备上的 L2CAP 信道端点都有一个不同的 CID。

可以配置 L2CAP 信道以为应用程序提供相应的 QoS 服务。L2CAP 将信道映射至 ACL-U 逻辑链路。

L2CAP 支持面向连接的信道及其它面向组的信道。面向组的信道可以映射至 ASB-U 逻辑链路，或实施为通过 ACL-U 链路向每个成员依次迭代传输。

除了创建、配置和分解信道以外，L2CAP 的主要角色是从信道客户端到 ACL-U 逻辑链路多路传输服务数据单元 (SDU)，以及按相应的优先级选择 SDU 以实施简单的调度。

L2CAP 可以通过对等 L2CAP 层提供单信道流控制。信道建立时，应用程序将选择此选项。L2CAP 还可以提供增强错误检测及重新传输功能，以 (a) 降低将未检测到的错误传输至应用程序的可能性； (b) 当基带层在 ACL-U 逻辑链路上执行清除操作时恢复丢失的用户数据。

如果存在 HCI，L2CAP 还需要将 L2CAP SDU 分割为适合基带缓冲器的片段，通过 HCI 运行基于令牌的流控制步骤，并只在允许时将片段提交至基带。这可能会影响调度算法。

--

原文链接: http://chinese.bluetooth.com/Bluetooth/Learn/Works/Data_Transport_Architecture.htm