Android 蓝牙5.3协议中文版解析（4）数据传输架构（209-216页）

作者：小蓝xlanll | 2024-05-02 10:55:29

踩

3、数据传输架构

蓝牙数据传输系统遵循分层架构。蓝牙系统的此描述描述了蓝牙核心传输层，包括L2CAP通道。所有蓝牙操作模式都遵循相同的通用传输架构，如图3.1 所示。

图3.1：蓝牙通用数据传输架构

出于效率和传统原因，蓝牙传输架构包括逻辑层的细分，以区分逻辑链路和逻辑传输。该细分提供了在两个或多个设备之间提供独立传输的逻辑链路的一般（和普遍理解）概念。逻辑传输子层需要描述一些逻辑链路类型之间的相互依赖关系（主要是由于遗留行为的原因）。

ACL、SCO和eSCO连接被视为逻辑传输，但通常表现为单独的物理链接。但是，由于它们共享使用资源，例如LT_ADDR和确认/重复请求(ARQ)方案，因此它们并不像预期的那样独立。因此，该架构无法用单个传输层来表示这些逻辑传输。附加的逻辑传输层在某种程度上描述了这种行为。

3.1核心流量承载

蓝牙核心系统为服务协议和应用数据的传输提供了许多标准的流量承载。这些显示在

下面的图3.2（为了便于表示，图中左侧为较高层，右侧为较低层）。

图3.2：蓝牙流量承载

可供应用程序使用的核心流量承载在图3.2中显示为带阴影的圆角矩形。为提供这些服务而定义的架构层在第2节中描述。许多数据流量类型显示在图的左侧，链接到通常适合传输该类型数据流量的流量承载。

逻辑链路使用关联逻辑传输的名称和指示传输的数据类型的后缀命名。（C表示携带LMP或LL消息的控制链路，U表示携带用户数据（L2CAPPDU）的L2CAP 链接，S表示携带未格式化同步或等时数据。）从逻辑链路中删除后缀而不引入歧义是很常见的，因此在以下情况下，对默认ACL逻辑传输的引用可以解析为表示ACL-C逻辑链路正在讨论LMP协议，正在讨论LL协议的情况下的LE-C逻辑链路，或ACL -U或LE-U逻辑链路，当 L2CAP层正在讨论中。

应用流量类型到蓝牙核心流量承载的映射

图3.2是基于流量特性与承载特性的匹配。建议使用这些映射，因为它们提供了

传输具有给定特征的数据的最自然和最有效的方法。

但是，应用程序（或蓝牙核心系统的实现）可能会选择使用不同的流量承载或不同的映射来实现类似的结果。例如，在只有一个外设的BR/EDR微微网中，中央可以选择通过ACL-U逻辑链路而不是APB-U逻辑链路传输L2CAP广播。这在带宽方面可能会更有效（如果物理信道质量不太下降）。仅当保留应用流量类型的特征时，才可接受使用替代图3.2中的传输路径。

图3.2显示了多种应用流量类型。这些用于对可能提交给蓝牙核心系统的数据类型进行分类。如果中间过程对其进行修改，原始数据流量类型可能与提交给蓝牙核心系统的类型不同。例如，视频数据以恒定速率生成，但中间编码过程可能会将其更改为可变速率，例如通过MPEG4编码。就蓝牙核心系统而言，仅对提交数据的特征感兴趣。

3.1.1成帧数据流量

L2CAP层服务为异步和同步用户数据提供面向帧的传输。应用程序以可变大小的帧（最多为通道协商的最大值）向该服务提交数据，并且这些帧以相同的形式传送到远程设备上的相应应用程序。应用程序不需要在数据中插入额外的成帧信息，但如果需要，它可能会这样做（这种成帧对蓝牙核心系统是不可见的）。

可以创建面向连接的L2CAP通道，用于在两个蓝牙设备之间传输单播（点对点）数据。面向连接的通道提供了一个上下文，在该上下文中可以将特定属性应用于通道上传输的数据。例如，可以应用服务质量参数或流和差错控制模式。面向连接的L2CAP通道是使用L2CAP连接过程创建的。存在无连接BR/EDRL2CAP信道用于广播数据或传输单播数据。在微微网拓扑的情况下，中央是始终是广播数据的来源，而外设是接收者。无连接L2CAP通道上的广播流量是单向的。在无连接L2CAP信道上发送的单播数据可以是单向的或双向的。在L2CAP无连接通道上发送的单播数据提供了一种替代机制，以与在基本模式下运行的面向L2CAP连接的通道相同的可靠性级别发送数据，但不会因打开L2CAP面向连接的通道而产生额外的延迟。不支持LEL2CAP无连接通道。

BR/EDRL2CAP通道具有相关的QoS设置，该设置定义了对数据帧传送的约束。这些QoS设置可用于指示（例如）数据是同步的，因此具有有限的生命周期，在此之后数据将变为无效，或者数据应该在给定的时间段内传送，或者数据是可靠的并且应该无误地交付，无论这需要多长时间。

某些L2CAP通道是在ACL-U和/或LE时创建的固定通道 U逻辑链路已建立。这些固定通道具有固定的通道标识和固定的配置，并且在创建后不允许进行配置协商。这些固定通道用于BR/ EDR和LEL2CAP信令（ACL-U或LE-U）、无连接通道（ACLU和APB-U）、安全管理器协议(LE-U)和属性协议(ACL U或LE-U）。

L2CAP通道管理器负责安排传输

适当基带逻辑链路上的L2CAP信道数据帧，可能将其复用到具有类似特性的其他L2CAP信道的基带逻辑链路上。

3.1.2非成帧数据流量

如果应用程序不需要以帧的形式传送数据，可能是因为它包括流内帧，或者因为数据是纯流，那么它可以避免使用L2CAP通道并直接使用基带逻辑链路。

蓝牙核心系统支持使用SCO-S或eSCO-S逻辑链路直接传输等时且恒定速率（比特率或帧速率预成帧数据）的应用程序数据。这些逻辑链路保留物理信道带宽并提供锁定到微微网时钟的恒定速率传输。数据以固定间隔以固定大小的数据包传输，这两个参数在信道建立期间协商。eSCO链路提供了更多的比特率选择，并通过在出现错误时使用有限的重传来提供更高的可靠性。

eSCO支持增强数据速率操作，但SCO逻辑传输不支持。SCO和eSCO逻辑传输不支持多路复用逻辑链路或蓝牙核心内的任何进一步分层。应用程序可以选择在提交的SCO/eSCO中对多个流进行分层流，前提是提交的流是或看起来是恒定速率流。

蓝牙核心系统还支持使用配置文件广播数据(PBD)逻辑链路直接传输应用程序数据。该逻辑链路类似于SCO-S和eSCO-S，因为它保留物理信道带宽，提供锁定到微微网时钟的恒定速率传输，并以固定间隔传输数据。它不支持多路复用逻辑链路或蓝牙核心内的任何进一步分层，但与SCO-S和eSCO-S不同，它支持从单个发射器向多个接收器广播数据。

应用程序从基带可用的逻辑链路类型中选择最合适的逻辑链路类型，并创建和配置它以传输数据流，并在完成时释放它。（应用程序通常还会使用成帧的L2CAP单播信道将其C平面信息传输到远程设备上的对等应用程序。）

如果应用数据是同步的并且是可变速率的，那么这只能由L2CAP单播信道承载，因此将被视为成帧数据。 LE系统不支持非成帧数据流量。

3.1.3流量承载的可靠性

3.1.3.1BR/EDR可靠性

蓝牙是一种无线通信系统。在较差的射频环境中，该系统应被视为本质上不可靠。为了解决这个问题，系统在每一层都提供了保护级别。基带数据包报头使用前向纠错(FEC)编码来允许接收器进行纠错，并使用报头错误检查(HEC)来检测纠正后剩余的错误。某些基带数据包类型包括有效载荷的FEC。

此外，一些基带数据包类型包括循环冗余错误校验(CRC)。在ACL逻辑传输上，错误检测算法的结果用于驱动简单的ARQ协议。这通过重新传输未通过接收器错误检查算法的数据包来提供增强的可靠性。如果数据包的使用寿命已过，则可以通过在发送器处丢弃未成功传输的数据包来修改此方案以支持延迟敏感数据包。eSCO链路使用该方案的修改版本，通过允许有限数

量的重传来提高可靠性。

这种ARQ方案所获得的可靠性仅与HEC和CRC代码检测错误的能力一样可靠。在大多数情况下，这已经足够了，但是已经表明，对于较长的数据包类型，未检测到错误的概率太高而无法支持典型应用程序，尤其是那些传输大量数据的应用程序。

L2CAP层提供了额外的错误控制级别，旨在检测基带未检测到的偶然错误并请求重传受影响的数据。这提供了典型蓝牙应用所需的可靠性水平。

广播链路没有反馈路由，无法使用ARQ方案（尽管接收方仍然能够检测接收到的数据包中的错误）。相反，每个数据包都被传输多次，希望接收器能够成功接收至少一个副本。尽管有这种方法，仍然不能保证成功接收，因此这些链接被认为是不可靠的。

总之，如果链路或信道的特征是可靠的，这意味着接收器能够检测接收到的数据包中的错误并请求重新传输，直到错误被消除。由于使用了错误检测系统，接收到的数据中可能仍会保留一些残留（未检测到）错误。对于L2CAP信道，这些级别与其他通信系统相当，但对于逻辑链路，残差级别稍高。

发送器可以从发送队列中移除分组，使得接收器不会接收到序列中的所有分组。如果发生这种情况，则将丢失数据包的检测委托给L2CAP层。在不可靠的链路上，接收器能够检测接收到的数据包中的错误，但不能请求重传。接收方传递的数据包可能没有错误，但不能保证接收到序列中的所有数据包。因此，该链接从根本上被认为是不可靠的。此类链接的用途有限，这些用途通常取决于在数据有效时来自更高层的数据的连续重复。流链路具有介于可靠和不可靠链路之间的可靠性特性，具体取决于当前的操作条件。

3.1.3.2LE可靠性

与BR/EDR一样，在较差的RF环境中，LE系统应被视为本质上不可靠。为了解决这个问题，系统在每一层都提供了保护级别。LL数据包使用24位循环冗余错误校验(CRC)来覆盖数据包有效负载的内容。如果数据包有效载荷的CRC验证失败，则数据包不会被接收方确认，并且数据包会被发送方重新传输。

广播链路没有反馈路由，无法使用确认方案（尽管接收方仍然能够检测接收到的数据包中的错误）。相反，每个数据包都被传输多次，以增加接收器能够成功接收至少一个副本的可能性。尽管有这种方法，仍然不能保证成功接收，因此这些链接被认为是不可靠的。

总之，如果链路或信道的特征是可靠的，这意味着接收器能够检测接收到的数据包中的错误并请求重新传输，直到错误被消除。在不可靠的链路上，接收器能够检测接收到的数据包中的错误，但不能请求重传。接收方传递的数据包可能没有错误，但不能保证接收到序列中的所有数据

包。因此，该链接从根本上被认为是不可靠的。此类链接的用途有限，这些用途通常取决于在数据有效时来自更高层的数据的连续重复。

3.1.3.3【本节不再使用】

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小蓝xlanll/article/detail/523702