出于效率和遗留原因，蓝牙传输架构包括一个细分逻辑层，用于区别逻辑链路和逻辑传输。此细分规定了在两个或多个设备间提供独立传输的逻辑链路的一般常用概念。逻辑传输子层说明部分逻辑链路类型主要出于遗留行为的原因而形成的相互依赖性。
蓝牙1.1 规格将 ACL 和 SCO 作为物理链路进行了描述。而增加了扩展的 SCO (eSCO) 后以及考虑到未来扩展，最好将它们视为逻辑传输类型，以便更精确地概述其目的。但是，由于它们共享使用资源，如 LT_ADDR 和确认/重复请求 (ARQ) 机制，它们并不像期望的那样独立。因此，架构无法通过单一的传输层表现这些逻辑传输。其它逻辑传输层对阐明此行为起到了一定的作用。
核心通信量载体
蓝牙核心系统提供若干标准通信量载体来传输服务协议和应用数据。
逻辑链路使用相关逻辑传输和表示传输数据类型的后缀命名：C 表示承载 LMP 消息的控制链路，U 表示承载用户数据 (L2CAP PDU) 的 L2CAP 链路，S 表示承载无格式同步或等时数据的流链路。通常，只要不会造成指代不明，逻辑链路的后缀将被删除，因此，对默认 ACL 逻辑传输的引用在讨论 LMP 协议时表示 ACL-C 逻辑链路，在讨论 L2CAP 层时则表示 ACL-U 逻辑链路。
应用通信类型到蓝牙核心通信量载体的映射基于通信量特征与载体特征的匹配。建议使用这些映射，因为它们是相关特征数据的最普通但最有效的传输方法。
蓝牙核心系统的应用或实施可以选择使用不同的通信量载体或不同的映射以获得类似结果。例如，在一个只有一个从设备的微微网中，主设备可能选择通过 ACL-U 逻辑链路传输 L2CAP 广播，而不是通过 ASB-U 或 PSB-U 逻辑链路。如果物理信道质量不是太差，这可能在带宽方面会更有效率优势。只有在能保持应用通信量类型特征的情况下，才能使用备选传输路径。
应用通信量类型可用于对提交至蓝牙核心系统的数据类型进行归类。如果介入流程修改了数据通信量类型，则提交至蓝牙核心系统的数据通信量类型可能和原始类型不一致。例如，视频数据是以恒定速率生成的，但中间编码程序可能将此更改为可变速率，如通过 MPEG4 解码程序。但蓝牙核心系统只对已提交数据的特征感兴趣。
帧化数据通信量
L2CAP 层服务对异步和等时用户数据提供按帧传输功能。应用程序以各种大小的帧为单位（最大可达信道协商最大值）将数据提交至此服务，然后，这些帧又被以同样的形式传送至远程设备上的相关应用程序。应用程序不必在数据中插入其它帧信息，除非确有必要。（这些帧对蓝牙核心系统可见。）
可以创建以连接为目的的 L2CAP 信道以在两个蓝牙设备间传输单播（点到点）数据。无连接 L2CAP 信道用于播送数据。在微微网拓扑中，主设备永远是广播数据的来源，从设备永远是接收方。广播 L2CAP 信道的通信量为单向传输。单播 L2CAP 信道既可以是单向传输，也可以是双向传输。
L2CAP 信道关联了一个 QoS 设置，后者定义数据帧传输的约束条件。这些 QoS 设置可用于指明下列情况，例如，数据为等时类型，因此在有限的使用期限后将无效；数据应在指定期限内传输；数据是可靠安全的，不管用多少时间，都会成功传输而不会发生错误。
L2CAP 信道管理器负责依据适当的基带逻辑链路安排传输 theL2CAP 信道数据帧，有可能会将其在具有其它具类似特征的 L2CAP 信道的基带逻辑链路上进行链路复用传送。
非帧化数据通信量
如果应用程序不要求按帧传输数据（可能因为包含流帧，或者数据为纯流形式），则可以避免使用 L2CAP 信道而直接使用基带逻辑链路。
蓝牙核心系统支持使用 SCO-S 或 eSCO-S 逻辑链路直接传输等时且速度恒定（预帧化数据的比特率或帧率）的应用数据。这些逻辑链路保留了物理信道带宽，并提供根据微微网时钟而锁定的恒速传输。数据在固定间隔以固定大小的数据包（这些参数在建立信道期间协商好）形式传输。eSCO 链路通过在错误情况下使用限制转播，提供了多种比特率选择及高度的可靠性。eSCO 支持增强数据速率操作，但 SCO 逻辑传输不支持。SCO 和 eSCO 逻辑传输在蓝牙核心系统中不支持复用逻辑链路或深入分层。如果提交的流是或像是恒速流，应用程序可以选择在提交的 SCO/eSCO 流内将流细分为多层。
应用程序可以从基带的可用逻辑链路中选择最适当的类型，创建并配置链路以传输数据流，并在完成后释放。（应用程序通常还会使用以帧为单位的 L2CAP 单播信道将控制平面 (C-plane) 信息传输给远程设备上的对等应用程序。）
如果应用程序数据为等时变速类型，则仅可通过 L2CAP 单播信道承载，并因此被视为以帧为单位的数据。
通信量载体的可靠性
蓝牙技术是一种无线通信系统。在不好的射频环境中，此系统应被视为内在不可靠。为抵消此劣势，系统在每层都提供了不同级别的保护。基带包头采用前向纠错 (FEC) 编码支持接收方进行错误纠正，并采用头部错误检验 (HEC) 检测纠正后是否还有遗留错误。某些基带数据包类型包括适用于净荷的 FEC。此外，一些基带数据包类型还包括循环冗余错误检查 (CRC)。
在 ACL 逻辑传输上，错误检测算法的结果被用来推动简单的 ARQ 协议。这可以重新传输未通过接收方错误检测算法的数据包，增强了可靠性。此方案还可以修改，如果数据包的使用期限已过，则放弃发送方未成功传输的数据包，以支持延迟敏感型数据包。eSCO 链路使用此方案的修订版，允许有限数量的重新传输，增强了可靠性。
此 ARQ 方案的可靠性与 HEC 及 CRC 代码检测错误的能力一样，并不是完全值得信赖。在多数情况下这足够可靠，但对于较长的数据包类型，发生检测不出的错误的可能性太大，难以支持普通应用，尤其是传输大量数据的应用。
L2CAP 层提供有附加错误控制级别，旨在检测偶尔在基带层中未检测到的错误，并请求重新传输受影响数据。这就保证了普通蓝牙应用所必须的可靠性。
广播链路不具有反馈路由，无法使用 ARQ 方案（尽管接收方仍可以检测收到的数据包中的错误）。但它会多次传输每个数据包，以期接收方至少能成功收到其中一份。尽管如此，还是不能保证对方能成功接收，因此这些链路被视为不可靠。
总而言之，如果链路或信道表现可靠，则说明接收方可以检测收到的数据包中的错误，并请求重新传输直到排除错误。由于使用的错误检测系统的原因，仍可能有一些残留（未检测到）错误保留在收到的数据中。对于 L2CAP 信道，这种风险等级与其它通信系统不相上下，但对于逻辑链路而言，残留错误等级则偏高。
发送方可能从传输队列中删除数据包，因此接收方无法接收序列中的所有数据包。如果发生此种情况，L2CAP 层将负责检测丢失的数据包。
在不可靠的链路上，接收方可以检测所接收数据中的错误，但无法请求重新传输。接收方传递的数据包可能没有错误，但并不能保证接收到序列中的所有数据包。因此，从根本上来说，应将链路视为不可靠。对这些链路应当限制使用，且在使用时通常应视高层数据有效时的连续重复性而定。
流链路的可靠性特征介于可靠和不可靠链路之间，具体视其当前的运行条件而定。
传输架构实体
蓝牙通用数据包结构
通用数据包结构反映了蓝牙系统中的结构层。数据包的设计旨在获得正常操作的最佳使用效果。
数据包通常仅包括代表事务所必须的层的必要字段。因此，通过查询扫描物理信道发出的简单查询请求不会创建或要求逻辑链路或较高层，因而仅包含信道访问码（与物理信道相关联）。因为微微网中的普通通信使用到了所有架构层，所以使用包含所有字段的数据包。
所有数据包均包括信道访问码。它可用于确定特定物理信道上的通信，并排除或忽略在物理邻近区碰巧使用相同射频载波的其它物理信道上的数据包。
蓝牙数据包结构中没有代表或包含与物理链路相关的信息的直接字段。此信息暗含在数据包头负载的逻辑传输地址 (LT_ADDR) 中。
大多数数据包包括包头。在支持物理链路、逻辑传输和逻辑链路的物理信道上传输的数据包始终包含包头。包头负载了 LT_ADDR，各个接收设备可使用它来确定数据包是否是传送给该设备的，或者用以在内部路由数据包。
包头还负载有按照逻辑传输运行的 LC 协议部分（运行负载在逻辑传输上的共享 LC 协议的 ACL 或 SCO 传输除外）。
EDR 数据包在净荷之前具有保护时间和同步序列。这是一个用于调制方案物理层变更的字段。
在支持多个逻辑链路的逻辑传输上的所有数据包都包含净荷包头。净荷包头包括一个用于路由净荷的逻辑链路标识符字段，和一个指明净荷长度的字段。某些类型的数据包还在数据包净荷之后包含一个 CRC，以用于检测接收到的数据包中的大部分错误。EDR 数据包在 CRC 后有一个包尾。
数据包净荷用于传输用户数据。此类数据的翻译取决于逻辑传输和逻辑链路标识符。对于 ACL 逻辑传输，LMP 消息和 L2CAP 信令同应用的普通用户数据一起，负载于数据包的净荷中传输。对于 SCO 和 eSCO 逻辑传输，净荷包含逻辑链路的用户数据。
物理信道
蓝牙无线技术系统架构中的最低层是物理信道。架构定义了多种类型的物理信道。所有蓝牙物理信道都具有以下特征：RF 频率与时间参数相结合，并受空间因素的限制。对于基础和适应型微微网物理信道，跳频可用于周期性地改变频率，以减少干扰或达到管制目的。
两个蓝牙设备使用一个共享物理信道进行通信。为了实现此目的，其收发器需要同时调至相同的 RF 频率，且需要彼此位于额定的范围内。
假设射频载波的数量有限，且许多蓝牙设备可能都在同一空间和时间区独立地运行，则很有可能两个独立的蓝牙设备都将其收发器调至同一射频载波，以致物理信道冲突。为了减小这种冲突引发的不必要影响，物理信道上的每个传输开头都附带有访问码，作为设备用于调至物理信道的相关码。此信道访问码是物理信道的一个属性。访问码总是出现在每个传输数据包的开头。
共定义了四个蓝牙物理信道。每个信道都经过优化，用于不同用途。其中两个物理信道（基础微微网信道及适应型微微网信道）用于在连接设备间进行通信，且与特定微微网相关。其余的物理信道用于发现蓝牙设备（查询扫描信道）和连接蓝牙设备（寻呼扫描信道）。
蓝牙设备在指定时间只可以使用这些物理信道中的一个。为了支持多个并发操作，设备在信道间采用时分复用。通过这种方式，蓝牙设备可以出现并同时运行在多个微微网中，且可以被发现并连接。
无论何时蓝牙设备符合物理信道的时间、频率及访问码，即可认为是“连接”至此信道（不管它是否积极参与此信道的通信）。蓝牙规范假定设备在任意时间内只能连接至一个物理信道。高级设备可能同时连接至多个物理信道，但规范并不假定这种可能成立。
基础微微网信道
概览
基础微微网信道可用于在正常操作过程中在连接的设备间通信。
特征
基础微微网信道的主要特征是在无线射频信道间进行伪随机序列跳频。微微网的跳频序列是唯一的，由主设备的蓝牙设备地址确定。跳频序列的相位由主设备的蓝牙时钟决定。所有加入微微网的蓝牙设备都在时间和跳频上与信道同步。
信道被分为若干时隙，每个时隙对应一个射频跳频。连续跳频对应不同的射频跳频频率。时隙根据微微网主设备的蓝牙时钟进行编号。数据包由加入微微网且对齐在时隙边界起始处的蓝牙设备传输。每个数据包开头都负载有信道访问码，该代码来源于微微网的蓝牙设备地址。
在基础微微网信道上，主设备控制着对信道的访问。主设备仅在双号时隙内启动传输。主设备传输的数据包将与时隙起始处对齐，并决定着微微网的定时。主设备传输的数据包最多可以占用五个时隙，具体情况视数据包类型而定。
主设备传输指其中一个逻辑传输上附带有信息的数据包。从设备可以在物理信道上传输信息以与之响应。响应的特性由寻址到的逻辑传输决定。
例如，在面向连接的异步逻辑传输上，寻址到的从设备通过传送一个包含额定与下一时隙（单号）起始处对齐的同一逻辑传输相关信息的数据包进行响应。此类数据包最多可以占用五个时隙，具体情况视数据包类型而定。在广播逻辑传输上，不允许从设备响应。
基础微微网的一个特殊特征是使用一些保留时隙传输信标列。只有当微微网物理信道连接有休眠从设备时，才可以使用信标列。在这种情况下，主设备可以在保留的信标列时隙中传输一个数据包（从设备可以使用这些数据包重新与微微网物理信道同步）。倘若各个时隙都有传输从中发出，则主设备可以从任意逻辑传输向这些时隙传输数据包。如果休眠从设备广播 (PSB) 逻辑传输中有信息要传送，则将在信标列时隙中传输，且享有高于其它任何逻辑传输的优先级。
拓扑
一个基础微微网可由任意数量的蓝牙设备共享，唯一的限制在于微微网主设备上的可用资源。只有一个设备可以作为微微网的主设备，所有其它设备均为从设备。所有通信均发生在主设备和从设备之间。微微网信道上不存在从设备之间的直接通信。
但是，微微网中支持的逻辑传输数有一定限制。这意味着尽管理论上对共享某个信道的蓝牙设备数量没有限制，但对可与主设备有效交换数据的设备数量却存在限制。
支持的层
基础微微网信道支持许多用于一般用途通信的物理链路、逻辑传输、逻辑链路及 L2CAP 信道。
适应型微微网信道
概览
适应型微微网信道与基础微微网信道在两方面存在差异。第一点不同，其从设备传输所用的频率与前面的主设备传输设备频率相同。换而言之，将不会在主设备数据包和随后的从设备数据包之间重新计算频率。适应型微微网信道与基础微微网信道的第二点不同在于适应型微微网可以基于少于全部 79 个频率。可以将许多频率标记为“不使用”将其排除在跳频图之外，而 79 个频率中的其余部分将被包括在内。除基础伪随机跳频序列可能选择不使用的频率（此时可以从使用过的频率组中选择备用选项替代它）外，两种序列是相同的。
由于适应型微微网信道使用和基础微微网信道相同的时段和访问码，所以两个信道经常会重合。这一点使得基础微微网信道或适应型微微网信道中的从设备都可以调整其与主设备的同步，因此带来了实在的好处。
适应型微微网物理信道的拓扑和支持的层与基础微微网物理信道相同。
查询扫描信道
概览
查询扫描信道用于发现设备。处于可发现模式的设备监听其查询扫描信道上的查询请求，并对这些请作出响应。某个设备为发现其它设备，将以伪随机方式在所有可能的查询扫描信道频率间进行迭代（跳频），向各个频率发出查询请求并监听响应。
特征
查询扫描信道采用较慢的跳频图，并使用访问码区分使用不同物理信道、但碰巧占用了相同射频的两个并存设备。
查询扫描信道上使用的访问码是从供所有蓝牙设备共享的一组保留查询访问码中挑选出的。其中一个访问码用于常用查询，其余多个访问码则保留作为限制查询。每个设备可以访问多个不同的查询扫描信道。由于所有这些信道共享一个跳频图，所以如果设备可以同时关联多个访问码，则它可以同时占用多个查询扫描信道。
使用其某个查询扫描信道的设备将保持被动，直到它在此信道上接收到从其它蓝牙设备发出的查询消息。查询通过相应的查询访问码标识。然后，查询扫描设备将根据查询响应步骤向查询设备返回响应。
某个设备为了发现其它蓝牙设备，将使用这些设备的查询扫描信道来发送查询请求。由于该设备对要发现的设备一无所知，所以无法了解查询扫描信道的确切特征。
但是设备完全可以利用这一点：即查询扫描信道的跳频数较少且跳频速度慢。查询设备在各查询扫描跳频上传送查询请求并监听查询响应。这将以较快的速度完成，使查询设备能够在适当短的时间段内覆盖所有的查询扫描频率。
拓扑
查询设备和可发现设备使用简单的数据包交换方式执行查询功能。在此事务中形成的拓扑结构为简单的暂时点对点连接。
支持的层
在查询设备和可发现设备之间交换数据包的过程中，不妨认为这些设备之间存在临时的物理链路。但是，由于没有物理表达形式，而只是通过设备间的简短事务来暗示，这种概念并无太大意义。除此之外，再没有其它可视为受支持的架构层。
寻呼扫描信道
概览
可连接的设备（即准备好接受连接的设备）会彻查寻呼扫描信道。可连接设备监听其寻呼扫描信道上的寻呼请求，然后与请求设备进行一系列交换。某个设备为连接其它设备，将以伪随机方式在所有寻呼扫描信道频率间进行迭代（跳频），向各个频率发出寻呼请求并监听响应。
特征
寻呼扫描信道使用从扫描设备的蓝牙设备地址衍生的访问码来识别信道上的通信。寻呼扫描信道使用的跳频速度比基础或适应型微微网的跳频速度稍慢。跳频选择算法使用扫描设备的蓝牙设备时钟作为输出。
使用寻呼扫描信道的设备将保持被动，直到接收到从其它蓝牙设备发出的寻呼请求。寻呼通过寻呼扫描信道访问码标识。然后，两个设备将按照寻呼步骤建立链接。寻呼步骤成功结束后，两个设备均将切换至基础微微网信道，此类信道的特征是以寻呼设备作为主设备。
某个设备为能连接至其它蓝牙设备，需使用目标设备的寻呼扫描信道来发送寻呼请求。如果寻呼设备不知道目标设备的寻呼扫描信道相位，就无法知道目标设备目前的跳频。寻呼设备在每个寻呼扫描跳频上传输寻呼请求，并监听寻呼响应。这将以较快的速度完成，使寻呼设备能够在适当短的时间段内覆盖所有的寻呼扫描频率。
寻呼设备可能知道一些有关目标设备蓝牙时钟的知识（通过两个设备间的之前查询事务获知，或因之前在微微网中与该设备接触过），在这种情况下，设备可以预测到目标设备寻呼扫描信道的相位。它可以使用此信息来优化寻呼和寻呼扫描进程的同步，从而加速形成连接。
拓扑
寻呼设备和可连接设备使用简单的数据包交换方式执行寻呼功能。在此事务中形成的拓扑结构为简单的暂时点对点连接。
支持的层
在寻呼设备和可连接设备之间交换数据包的过程中，不妨认为这些设备之间存在临时的物理链路。但是，由于没有物理表达形式，而只是通过设备间的简短事务来暗示，这种概念并无太大意义。除此之外，再没有其它可视为受支持的架构层。
物理链路
物理链路代表蓝牙设备间的基带连接。物理链路总是正好与一个物理信道相关联（尽管物理信道可能支持多个物理链路）。
在蓝牙拓扑系统内，物理链路只是一个虚拟概念，在传输的数据包内并没有直接的表达形式。访问码数据包字段及主蓝牙设备的时钟和地址可用于确定物理信道。但是，并没有直接标识物理链路的后续数据包部分。相反，物理链路可以通过与逻辑传输相关联来确定，因为每个逻辑传输只能在一个物理链路上接收。
某些类型的物理链路拥有可以修改的属性。例如，链路的传输功率。其它类型的物理链路不具有此属性。对于具有可修改属性的物理链路，可以使用 LM 协议修改这些属性。由于 LM 协议受较高层（逻辑链路）支持，因此相应的物理链路可通过传输 LM 信令的逻辑链路发出的暗示来确定。
如果传输通过多个不同的物理链路播送，则应选择传输参数以适合所有物理链路。
基础微微网和适应型微微网物理信道支持的链路
基础或适应型微微网物理信道支持活动或休眠的物理链路。物理链路是主设备和从设备之间的点对点链路。当从设备在微微网中同步时，物理链路永远存在。
活动物理链路
如果设备间存在默认 ACL 逻辑传输，则主设备和从设备间的物理链路为活动状态。活动的物理链路没有直接的身份标识，但可通过与默认 ACL 逻辑传输 ID 的一一对应关联关系来确定。
活动的物理链路在各个方向上都具有与之关联的无线电传输功率属性。从设备的传输总是通过活动的物理链路定向至主设备，并使用作为此链路属性的从设备到主设备方向上的传输功率。主设备的传输可能通过单个活动物理链路（至特定从设备）或多个物理链路（至微微网中的一组从设备）定向。在点对点传输时，主设备使用适用于涉及物理链路的适当传输功率。（在点对多点传输时，主设备使用适用于一组寻址到的设备的传输功率。）
活动的物理链路可以被置于保持或监听模式。这些模式可用于修改物理链路处于活动状态和可负载通信量的时间段。已定义了调度特性的逻辑传输将不受这些模式的影响，根据其预定义的调度行为继续。默认的 ACL 逻辑传输及其它未定义调度特征的链路将跟从活动的物理链路模式。
休眠的物理链路
如果从设备仍保持与微微网同步，但没有默认的 ACL 逻辑传输，则主设备和从设备间的物理链路将处于休眠状态。此类从设备也被视为休眠。信标列可用于为所有连接至微微网物理信道的休眠从设备提供定期同步。休眠从设备广播（PSB）逻辑传输可用于支持 LMP 信令子集通信并向休眠从设备播送 L2CAP。PSB 逻辑传输与信标列密切相关。
从设备使用休眠步骤进入休眠状态（其活动链路将变为休眠链路）。主设备不可以休眠拥有受物理链路支持的用户创建逻辑传输的从设备。这些逻辑传输将首先被删除，任何在这些逻辑传输上建立的 L2CAP 信道也将被删除。广播逻辑传输和默认 ACL 逻辑传输不被视为用户创建类型，因此不会被显式删除。当活动链路被休眠链路替代后，默认的 ACL 逻辑传输将被隐式删除。受支持的逻辑链路和 L2CAP 信道仍会存在，但将变为挂起状态。缺少活动链路时，不可能使用这些链路和 L2CAP 信道传输信令或数据。
休眠的从设备可以使用唤醒步骤激活。此步骤由从设备在访问窗口中请求，并通过主设备启动。完成唤醒步骤后，休眠物理链路将变为活动物理链路，默认 ACL 逻辑传输也将得到重建。在最近一次休眠过程中挂起的 L2CAP 信道将被关联至新的默认 ACL 逻辑传输，并再次激活。
休眠链路不支持无线电功率控制，因为没有从休眠从设备到微微网主设备的反馈路径，也就无法就从设备处收到的信号强度发出信令，主设备也无法测量来自从设备的信号强度。传输将以休眠链路上的额定功率进行。
体眠链路使用与所关联活动链路相同的物理信道。如果主设备管理着包括使用基础微微网物理信道和使用适应型微微网物理信道的休眠从设备的微微网，则它必须为这些物理信道中的每一个创建一个休眠从设备广播逻辑传输（及关联传输）。
休眠从设备可以利用休眠从设备广播逻辑传输的非活动期来节省功率，或在与其休眠所在微微网不相关的其它物理信道上展开活动。
扫描物理信道支持的链路
在查询扫描和寻呼扫描信道中，物理链路存在的时间相当短，故无法以任何方式进行控制或修改。对于这些类型的物理链路，将不再作深入描述。
逻辑链路和逻辑传输
有多种逻辑链路可以支持不同应用数据传输要求。每个逻辑链路与一个具有多种特征的逻辑传输相关联。这些特征包括流控制、确认/重复机制、序列编号及调度行为。逻辑传输可以负载不同类型的逻辑链路（具体视逻辑传输的类型而定）。某些蓝牙1.1 版的逻辑链路将在同一逻辑传输上进行多路复用。逻辑传输可以负载于基础或适应型微微网物理信道上的活动物理链路上。
逻辑传输标识和实时（链路控制）信令可以负载于数据包头，对于某些逻辑链路，标识负载于净荷包头。不要求单时隙响应时间的控制信令使用 LMP 协议传送。
下表列出了所有的逻辑传输类型、支持的逻辑链路类型、哪种类型的物理链路及物理信道可以支持它们，以及逻辑传输用途的简要描述。
|
逻辑传输
|
支持的链路
|
支持者
|
概述
|
|
|---|---|---|---|---|
|
异步面向连接 (ACL) |
控制 (LMP) ACL-C 用户 (L2CAP) ACL-U |
活动物理链路，基础或适应型物理信道 |
|
|
|
同步面向连接 (SCO) |
流（非帧化） SCO-S |
活动物理链路，基础或适应型物理信道 |
双向，对称，点对点，AV 信道。适用于 64Kb/s 恒速数据。 | |
| 扩展同步面向连接 (eSCO) |
流（非帧化） eSCO-S |
活动物理链路，基础或适应型物理信道 |
双向，对称或不对称，点对点，通用规则数据，受限重新传输。适用于与主蓝牙 设备时钟同步的恒速数据。 |
|
| 活动从设备广播 (ASB) | 用户 (L2CAP) ASB-U |
活动物理链路，基础或适应型物理信道 |
不可靠，单向广播到与物理信道同步的任意设备。适用于广播 L2CAP 组。 |
|
|
休眠从设备广播 (PSB) |
控制 (LMP) PSB- C，用户 (L2CAP) PSB-U |
休眠物理链路，基础或适应型物理信道 |
不可靠，单向广播至所有微微网设备。适用于至休眠设备的 LMP 和 L2CAP 通信量，及从休眠设备发出的访问请求。 |
逻辑链路和逻辑传输的指定名称反映了蓝牙1.1 版中使用的部分名称，以保证一定程度的熟悉性和连续性。但这些名称并不反映一致方案，如下所述。
每种链路类型的分类可依据三种类别中的选择步骤。
播送
第一类为播送。可以是单播或广播。蓝牙1.2. 版中未定义组播链路。
- 单播链路。单播链路存在于两个端点之间。在单播链路上，可以在任意一个方向上发送通信量。所有单播链路都是面向连接的，即在使用链路之前进行连接。如果是默认的 ACL 链路，则连接步骤是形成专用微微网的一般寻呼步骤中的一个隐式步骤。
- 广播链路。广播链路存在于一个源设备和零个或更多接收设备之间。通信量为单向传送，即只从源设备发送至接收设备。广播链路无需连接，即不存在这些链路的创建步骤，而可以随时通过它们发送数据。广播链路并不可靠，无法保证数据能被接收到。
调度和确认方案
第二类与链路的调度和确认方案有关，暗指链路支持的通信类型。这些可以是同步、等时或异步链路。蓝牙1.2 版中没有定义特定的等时链路，但是可以配置默认的 ACL 链路以此方式操作。
- 同步链路。同步链路提供了将蓝牙微微网时钟与所传输数据相关联的方法。这可以通过在物理信道上保留定期时隙，并通过这些定期时隙传输固定大小的数据包来实现。此类链路适用于恒速的等时数据。
- 异步链路。异步链路提供了传输不具备时间相关特征的数据的方法。通常，数据会多次传输直至成功接收，每个数据实体均可以在接收后于任意时间处理，而不必参考流中任何先前或后续实体的接收时间（假设数据实体顺序不变）。
- 等时链路。等时链路提供了传输具备时间相关特征的数据的方法。数据可以多次传输，直至接收到或失效。此链路上的数据速率不必保持恒定（这是与同步链路的主要区别所在）。
数据种类
最后一类与链路负载的数据种类相关。数据分控制 (LMP) 数据和用户数据两种。用户数据类别又细分为 L2CAP（即帧化）数据和流（即未帧化）数据。
- 控制链路。控制链路仅用于在两个链路管理器间传输 LMP 消息。这些链路在基带层以上均不可见，除了通过连接或断开连接服务隐式达到效果外，应用程序要直接例示、配置或释放这些链路别无它法。控制链路总是与对等 L2CAP 链路在一个 ACL 逻辑传输上进行多路复用。依据定义 ARQ 方案的规则，控制链路通信量总是优先于 L2CAP 链路通信量。
- L2CAP 链路。L2CAP 链路可用于传输 L2CAP PDU，L2CAP PDU 可以负载 L2CAP 信令信道（位于默认的 ACL-U 逻辑链路上）或提交至用户例示 L2CAP 信道的帧化用户数据。提交至基带的 L2CAP 帧可能要比可用基带数据包稍大。如果帧以多段形式传送至接收方，则内嵌于 LLID 字段的链路控制协议可以保持帧起始和帧延续的语义。
- 流链路。流链路用于传输不具有在传送数据时应当保留的固有帧的用户数据。丢失的数据可以通过在接收方进行填充替代。
异步面向连接 (ACL)
异步面向连接 (ACL) 逻辑传输可用于负载 LMP 和 L2CAP 控制信令及尽力而为型 (best effort) 异步用户数据。ACL 逻辑传输使用简单的 1 比特 ARQN/SEQN 方案以提供简单的信道可靠性。微微网中的每个活动从设备都有一个连至微微网主设备的 ACL 逻辑传输，称为默认 ACL。
设备加入微微网时（连接至基础微微网物理信道），主设备和从设备间将创建默认 ACL。微微网主设备将为默认 ACL 分配一个逻辑传输地址 (LT_ADDR)。此 LT_ADDR 还可用于在需要时标识活动物理链路（或作为微微网活动成员标识符，用于相同目的）。
默认 ACL 的 LT_ADDR 将被重新用于相同主设备和从设备间的同步面向连接逻辑传输。（这是出于同早期蓝牙规格兼容的原因。）因此，LT_ADDR 自身并不足以标识默认的 ACL。但是，由于 ACL 上使用的数据包类型不同于同步面向连接逻辑传输上的数据包类型， 因此，可以通过数据包头中的 LT_ADDR 字段，并结合数据包类型字段来标识 ACL 逻辑传输。
通过将默认 ACL 配置为在数据包失效后自动清除数据包，可将其用于等时数据传输。
如果将默认 ACL 从活动物理链路中删除，则主设备和从设备间存在的所有其它逻辑传输也将被删除。如果至微微网物理信道的同步意外丢失，则物理链路及所有逻辑传输和逻辑链路将在检测到此同步丢失时消失。
设备可以删除其默认 ACL（通过其活动物理链路的暗示），但仍将保持与微微网同步。此过程称为休眠，与微微网同步但不存在活动物理链路的设备即在该微微网内处于休眠状态。
当设备过渡至休眠状态时，在默认 ACL 逻辑传输上传输的默认 ACL 逻辑链路仍保持存在，但是处于挂起状态。没有数据可以通过挂起的逻辑链路进行传输。当设备从休眠状态过渡回活动状态时，将会创建新的默认 ACL 逻辑传输（它的 LT_ADDR 可能与之前的不同），挂起的逻辑链路将被附加至此新的默认 ACL 并重新变为活动状态。
同步面向连接 (SCO)
同步面向连接 (SCO) 逻辑传输是主设备和特定从设备之间的对称点对点信道。SCO 逻辑传输在物理信道上保留有时隙，因此可被看作主设备和从设备之间的电路交换连接。SCO 逻辑传输可以负载按微微网时钟同步的 64 kb/s 的信息。通常，此信息为编码语音流。共存在三种不同的 SCO 配置，在稳键性、延迟和带宽消耗之间保持平衡。
每个 SCO-S 逻辑链路都由单个 SCO 逻辑传输支持，SCO 逻辑传输分配有相同的 LT_ADDR，作为设备间默认的 ACL 逻辑传输。因此，LT_ADDR 字段并不足以标识接收到的数据包的目的地。由于 SCO 链路使用保留的时隙，所以设备可以结合使用 LT_ADDR、时隙编号（物理信道的属性）及数据包类型来标识 SCO 链路上的传输。
之所以为 SCO 逻辑传输重新使用默认 ACL 的 LT_ADDR，是出于对蓝牙1.1 版规格中的遗留行为的考虑。在早期的蓝牙规格版本中，LT_ADDR（那时被称为活动成员地址）被用于标识与每个传输相关联的微微网成员。这并不易于扩展以支持更多逻辑链路，因此此字段的目的被重新定义以支持新的功能。但是，部分蓝牙1.1 版的功能无法完全适合正规描述的架构。
尽管为 SCO 保留了时隙，但仍允许将保留时隙用于其它拥有更高优先级信道的通信。这可能是 QoS 承诺要求的结果，也可能是为了在物理信道带宽完全被 SCO 占用时，在默认 ACL 上发送 LMP 信令。由于 SCO 可以负载不同的数据包类型至 ACL，所以数据包类型可用于标识 SCO 通信（结合时隙编号和 LT_ADDR）。蓝牙核心规格未再定义更多通过 SCO 链路传输的架构层。传输的 64 kb/s 流定义了多种标准格式，对于应用程序负责翻译流编码的情况，还允许未格式化的流。
3.5.6 扩展同步面向连接 (eSCO)
扩展同步面向连接 (eSCO) 逻辑传输是主设备和特定从设备间的对称或不对称点对点链路。eSCO 在物理信道上保留有时隙，因此可被看作主设备和从设备之间的电路交换连接。eSCO 链路在标准 SCO 链路上提供了许多扩展，这主要表现在：它们支持更灵活的数据包类型组合，支持选择数据包内容和选择时隙时段，从而支持多种同步比特率。
eSCO 链路还可以提供有限的数据包重新传送（SCO 链路不存在重新传送）。如果要求重新传送，则重新传送将发生在跟随保留时隙的时隙内，否则时隙将用于其它通信。
每个 eSCO-S 逻辑链路都由单个 eSCO 逻辑传输支持，并通过 eSCO 期间在微微网中唯一的 LT_ADDR 标识。eSCO-S 链路使用 LM 信令创建，并遵循与 SCO-S 链路类似的调度规则。
蓝牙核心规格未再定义通过 eSCO-S 链路传输的更多架构层。相反，应用程序可以出于任何要求的目的使用数据流，只要流的传输特征适用于被传输的数据。
活动从设备广播 (ASB)
活动从设备广播逻辑传输可用于向当前连接至 ASB 所用物理信道的微微网中的所有设备传输 L2CAP 用户通信。不存在确认协议，且从微微网主设备到从设备的通信为单向传输。ASB 信道可用于 L2CAP 组通信（1.1 版规格的遗留），但从不用于面向连接的 L2CAP 信道、L2CAP 控制信令或 LMP 控制信令。
但由于不进行确认，ASB 逻辑传输从本质上来说并不可靠。为了提高可靠性，每个数据包将进行多次传输。将使用相同的序列号在从设备上协助筛选重新传输。
ASB 逻辑传输通过保留的 LT_ADDR 标识。（保留的 LT_ADDR 地址还可供 PSB 逻辑传输使用。）活动从设备将在两个逻辑传输上接收通信，但无法轻易区分二者。ASB 逻辑传输不负载 LMP 通信，因此活动的从设备可以忽略通过 ASB 逻辑传输上的 LMP 逻辑链路接收到的数据包。但是，ASB 逻辑传输上的活动从设备也接收通过 PSB 逻辑传输传送的 L2CAP 通信，且无法与 ASB 传输上发送的 L2CAP 通信相区别。
不论何时存在微微网，都将隐式创建一个 ASB，且总有一个 ASB 与微微网中存在的每个基础或适应型微微网物理信道相关联。由于基础和适应型微微网物理信道几乎一致，从设备无法区分哪个 ASB 信道用于传输数据包。这进一步加深了 ASB 信道的不可靠性。（不过，它再不可靠最多也就是丢失数据包。）
主设备可以确定使用两个可能存在的 ASB 信道中的哪一个（当同时拥有一个基础和一个适应型微微网物理信道时），因为如果进行充分的重新传输，就可以在同一 ASB 信道上定向至两组从设备。
ASB 信道从不用于负载 LMP 或 L2CAP 控制信令。
休眠从设备广播 (PSB)
休眠从设备广播逻辑传输可用于在主设备和休眠的从设备（已放弃其默认 ACL 逻辑传输）之间通信。休眠从设备广播链路是微微网主设备和休眠从设备间存在的唯一逻辑传输。
PSB 逻辑传输比其它逻辑传输更为复杂，因为它包括多个相位，而每个相位都有不同的用途。这些相位包括控制信息相位（用于负载 LMP 逻辑链路）、用户信息相位（用于负载 L2CAP 逻辑链路）以及接入相位（负载基带信令）。控制信息和广播信息相位通常不能同时使用，因为在单个信标间隔中只能支持两者中的一个。（即使没有控制器用户信息相位，仍要求主设备在信标时隙中传输数据包，以便休眠从设备可以重新同步。）接入相位通常都会存在，除非在控制信息消息中取消。
控制信息相位用于供主设备发送信息至包含以下项的休眠从设备：对 PSB 传输特性的修改、对信标列特性的修改或休眠从设备要求在微微网中变为活动状态的请求（称为唤醒）。此控制信息负载于 LMP 逻辑链路上的 LMP 消息中。（当用户信息要求多个基带数据包时，控制信息相位还会与用户信息相位一同出现。）
控制信息相位中的数据包总是在物理信道信标列时隙中传输，而无法在其它任意时隙中传输。控制信息占用了一个单 DM1 数据包，并在单个信标间隔内的每个信标列时隙中重复。（如果没有控制信息，则可能有用户信息相位使用信标时隙。如果两个相位均未使用，则信标时隙可用于其它逻辑传输通信或 NULL 数据包。）
用户信息相位用于供主设备发送要送至所有微微网从设备的 L2CAP 数据包。用户信息可以占用一个或多个基带数据包。如果用户信息占用了单个数据包，则用户信息数据包将在每个微微网信道信标列时隙中重复。
如果用户信息占用了多个基带数据包，则它将在信标列（广播扫描窗口）后的时隙中传输，信标时隙可用于传输包含此广播扫描窗口定时特性的控制信息相位消息。这样要求是为了使休眠从设备保持连接至微微网物理信道，以接收用户信息。
接入相位将正常显示，除非临时由控制信息广播相位中负载的控制消息取消。接入窗口中包含了紧跟信标列的一连串时隙。为了使微微网中的休眠从设备变为活动状态，必须通过接入窗口向微微网主设备发送接入请求。每个休眠从设备都分配有一个请求接入地址（不必是唯一的），该地址控制从设备在接入窗口持续时间内何时请求接入。
PSB 逻辑传输由值为 0 的保留 LT_ADDR 标识。此保留的 LT_ADDR 地址还可供 ASB 逻辑传输使用。休眠从设备在一般情况下并不会由于重复使用 LT_ADDR 而被混淆，因为它们仅在使用 PSB 传输时连接到微微网物理信道。
逻辑链路
部分逻辑传输可以支持不同的逻辑链路，这些链路可以同时被多路复用，也可以作为待选项。在这些逻辑传输内，逻辑链路由负载数据净荷的基带数据包净荷包头中的逻辑链路标识符 (LLID) 位来标识。逻辑链路可以区分有限的一组核心协议，这些协议能在逻辑传输上传输和接收数据。并非所有的逻辑传输都能够负载全部的逻辑链路。尤其是 SCO 和 eSCO 逻辑传输仅可以负载恒定数据率的流，它们由 LT_ADDR 唯一标识。此类逻辑传输仅使用不包含净荷包头的数据包，因为这些数据包的长度已事先知道，不需要 LLID。
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 逻辑链路。如果在处理可靠用户数据时同时支持变速等时数据，蓝牙技术会有一些限制。
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 运行基于令牌的流控制步骤，并只在允许时将片段提交至基带。这可能会影响调度算法。
Copyright 2007