蓝牙架构（6）—— 3 数据传输架构（3.1 核心传输载体）

2024-05-09 04:38:21

Vol 1 架构和术语概述

Part A 3 数据传输架构

3.1. 核心传输载体.

3.1.1. 帧化数据传输.

3.1.2 非帧化数据传输.

3.1.3 通信量载体的可靠性.

Part A 3 数据传输架构

（190页）Bluetooth 数据传输系统采用分层架构。此Bluetooth 系统说明描述了Bluetooth 核心传输层以上各层，包括 L2CAP 信道。所有Bluetooth 运作模式都依据相同的通用传输架构。

出于效率和遗留原因，Bluetooth 传输架构包括一个细分逻辑层，用于区别逻辑链路和逻辑传输。此细分规定了在两个或多个设备间提供独立传输的逻辑链路的一般常用概念。逻辑传输子层说明部分逻辑链路类型主要出于遗留行为的原因而形成的相互依赖性。

Bluetooth 1.1 规格将 ACL 和 SCO 作为物理链路进行了描述。而增加了扩展的 SCO (eSCO) 后以及考虑到未来扩展，最好将它们视为逻辑传输类型，以便更精确地概述其目的。但是，由于它们共享使用资源，如 LT_ADDR 和确认/重复请求 (ARQ) 机制，它们并不像期望的那样独立。因此，架构无法通过单一的传输层表现这些逻辑传输。其它逻辑传输层对阐明此行为起到了一定的作用。

3.1. 核心传输载体

（191页）Bluetooth核心系统提供若干标准传输载体来传输服务协议和应用数据。如图，为了便于表示，左侧和下层的较高层显示为右侧。

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

逻辑链路使用相关逻辑传输和表示传输数据类型的后缀命名：

C表示承载 LMP 消息的控制链路
U表示承载用户数据(L2CAP PDU)的L2CAP链路
S表示承载无格式同步或等时数据的流链路

通常，只要不会造成指代不明，逻辑链路的后缀将被删除，因此，对默认ACL逻辑传输的引用在讨论 LMP 协议时表示ACL-C逻辑链路，在讨论L2CAP层时则表示ACL-U逻辑链路。

（192页）应用通信类型到Bluetooth核心传输载体的映射基于传输特征与载体特征的匹配。建议使用这些映射，因为它们是相关特征数据的最普通但最有效的传输方法。

Bluetooth核心系统的应用或实施可以选择使用不同的传输载体或不同的映射以获得类似结果。例如，在一个只有一个从设备的微微网中，主设备可能选择通过 ACL-U 逻辑链路传输 L2CAP 广播，而不是通过 ASB-U 或 PSB-U 逻辑链路。如果物理信道质量不是太差，这可能在带宽方面会更有效率优势。只有在能保持应用传输类型特征的情况下，才能使用备选传输路径。

应用传输类型可用于对提交至Bluetooth 核心系统的数据类型进行归类。如果介入流程修改了数据传输类型，则提交至Bluetooth 核心系统的数据传输类型可能和原始类型不一致。例如，视频数据是以恒定速率生成的，但中间编码过程可能将此更改为可变速率，如通过 MPEG4 解码过程。但Bluetooth 核心系统只对已提交数据的特征感兴趣。

3.1.1. 帧化数据传输

L2CAP 层服务对异步和等时用户数据提供按帧传输（frame-oriented）功能。应用过程以各种大小的帧为单位（最大可达信道协商最大值）将数据提交至此服务，然后，这些帧又被以同样的形式传送至远程设备上的相关应用过程。应用过程不必在数据中插入其它帧信息，除非确有必要。（这些帧对Bluetooth 核心系统可见。）

可以创建以连接为目的的 L2CAP 信道以在两个Bluetooth 设备间传输单播（点到点）数据。单播 L2CAP 信道既可以是单向传输，也可以是双向传输。
无连接L2CAP 信道用于播送数据。在微微网拓扑中，主设备永远是广播数据的来源，从设备永远是接收方。广播 L2CAP 信道的传输为单向传输。

（193页）L2CAP 信道关联了一个 QoS 设置，后者定义数据帧传输的约束条件。这些 QoS 设置可用于指明下列情况，例如，数据为等时类型，因此在有限的使用期限后将无效；数据应在指定期限内传输；数据是可靠安全的，不管用多少时间，都会成功传输而不会发生错误。

L2CAP 信道管理器负责依据适当的基带逻辑链路安排传输 theL2CAP 信道数据帧，有可能会将其在具有其它具类似特征的 L2CAP 信道的基带逻辑链路上进行链路复用传送。

3.1.2 非帧化数据传输

如果应用过程不要求按帧传输数据（可能因为包含流帧，或者数据为纯流形式），则可以避免使用L2CAP 信道而直接使用基带逻辑链路。

Bluetooth 核心系统支持使用SCO-S或eSCO-S逻辑链路直接传输等时且速度恒定（预帧化数据的比特率或帧率）的应用数据。（194页）这些逻辑链路保留了物理信道带宽，并提供根据微微网时钟而锁定的恒速传输。数据在固定间隔以固定大小的数据包（这些参数在建立信道期间协商好）形式传输。eSCO链路通过在错误情况下使用限制转播，提供了多种比特率选择及高度的可靠性。eSCO支持增强数据速率操作，但 SCO 逻辑传输不支持。SCO和eSCO逻辑传输在Bluetooth 核心系统中不支持复用逻辑链路或深入分层。如果提交的流是或像是恒速流，应用过程可以选择在提交的SCO/eSCO流内将流细分为多层。

应用过程可以从基带的可用逻辑链路中选择最适当的类型，创建并配置链路以传输数据流，并在完成后释放。（应用过程通常还会使用以帧为单位的L2CAP单播信道将控制平面 (C-plane) 信息传输给远程设备上的对等应用过程。）

如果应用过程数据为等时变速类型，则仅可通过 L2CAP 单播信道承载，并因此被视为以帧为单位的数据。

3.1.3 通信量载体的可靠性

3.1.3.1 BR/EDR的可靠性

Bluetooth 技术是一种无线通信系统。在不好的射频环境中，此系统应被视为内在不可靠。为抵消此劣势，系统在每层都提供了不同级别的保护。基带包头采用前向纠错 (FEC) 编码支持接收方进行错误纠正，并采用头部错误检验 (HEC) 检测纠正后是否还有遗留错误。某些基带数据包类型包括适用于净荷的 FEC。此外，一些基带数据包类型还包括循环冗余错误检查 (CRC)。

在 ACL 逻辑传输上，错误检测算法的结果被用来推动简单的 ARQ 协议。这可以重新传输未通过接收方错误检测算法的数据包，增强了可靠性。此方案还可以修改，如果数据包的使用期限已过，则放弃发送方未成功传输的数据包，以支持延迟敏感型数据包。eSCO 链路使用此方案的修订版，允许有限数量的重新传输，增强了可靠性。

此 ARQ 方案的可靠性与 HEC 及 CRC 代码检测错误的能力一样，并不是完全值得信赖。在多数情况下这足够可靠，但对于较长的数据包类型，发生检测不出的错误的可能性太大，难以支持普通应用，尤其是传输大量数据的应用。

L2CAP 层提供有附加错误控制级别，旨在检测偶尔在基带层中未检测到的错误，并请求重新传输受影响数据。这就保证了普通Bluetooth 应用所必须的可靠性。

（195页）广播链路不具有反馈路由，无法使用 ARQ 方案（尽管接收方仍可以检测收到的数据包中的错误）。但它会多次传输每个数据包，以期接收方至少能成功收到其中一份。尽管如此，还是不能保证对方能成功接收，因此这些链路被视为不可靠。

总而言之，如果链路或信道表现可靠，则说明接收方可以检测收到的数据包中的错误，并请求重新传输直到排除错误。由于使用的错误检测系统的原因，仍可能有一些残留（未检测到）错误保留在收到的数据中。对于 L2CAP 信道，这种风险等级与其它通信系统不相上下，但对于逻辑链路而言，残留错误等级则偏高。

发送方可能从传输队列中删除数据包，因此接收方无法接收序列中的所有数据包。如果发生此种情况，L2CAP 层将负责检测丢失的数据包。

在不可靠的链路上，接收方可以检测所接收数据中的错误，但无法请求重新传输。接收方传递的数据包可能没有错误，但并不能保证接收到序列中的所有数据包。因此，从根本上来说，应将链路视为不可靠。对这些链路应当限制使用，且在使用时通常应视高层数据有效时的连续重复性而定。

流链路的可靠性特征介于可靠和不可靠链路之间，具体视其当前的运行条件而定。

3.1.3.2 LE可靠性

与BR / EDR一样，在较差的RF环境中，LE系统应被视为固有的不可靠。为了抵消这种情况，系统在每一层提供保护级别。 LL数据包使用24位循环冗余错误检查（CRC）来覆盖数据包有效负载的内容。如果CRC验证在分组有效载荷上失败，则接收器不确认该分组，并且发送方重新发送该分组。

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

总之，如果链路或信道被表征为可靠，则这意味着接收器能够检测所接收分组中的错误并请求发送直到错误被移除。

（196页）发送器可以从发送队列中移除分组，使得接收器不接收序列中的所有分组。如果发生这种情况，则将丢失数据包的检测委托给L2CAP层。

在不可靠的链路上，接收器能够检测接收到的分组中的错误，但不能请求重传。接收器传递的数据包可能没有错误，但不能保证序列中的所有数据包都被接收。因此，该链接被认为是根本不可靠的。这种链接的用途有限，这些用途通常取决于较高层数据的有效连续重复。

3.1.3.3 AMP可靠性

每个AMP的可靠性取决于底层的MAC/PHY技术。某些AMP仅在标记为可刷新时刷新用户流量，而其他AMP可以刷新用户流量。

蓝牙核心通过强制要求对AMP上使用的任何L2CAP信道使用增强型重传模式或流媒体模式，为Core上方的协议和协议保持一定的可靠性。

————————————————————————————————————————

1 BT specification Core 4.2, Bluetooth SIG.

————————————————————————————————————————

作者按：蓝牙从业者，潜心学习BT stack，蓝牙协议奇多无比，概述只是开始，网上资料还比较多，学到后面的各种spec就只剩英文原版可以参考了，遂把自己的笔记发出来，互相交流，互相交流。

蓝牙架构（6）—— 3 数据传输架构（3.1 核心传输载体）相关推荐

分布式应用架构中的数据传输对象（DTO）
分布式应用架构中的数据传输对象(DTO) Written by: Rickie Lee Dec. 1, 2004 在分布式架构中,相关层在物理部署上实现分离,通过网络或跨进程调用远程对象或服务.在这种 ...
企业架构研究总结（39）——TOGAF架构能力框架之架构委员会和架构合规性
3. 架构委员会正如前面所说,一个用来对架构治理策略的实现进行监督的跨组织的架构委员会是架构治理策略成功的主要要素之一.架构委员会应该能够代表所有主要干系人的需求,并且通常还需要对整个架构的审查及维 ...
项目架构之传统三层架构和领域模型三层架构
一.架构之传统三层架构传统三层架构是一种软件架构,是一种典型的.基于贫血模型的.面向过程的JavaWeb分层方式.该架构分为以下三个层次: 数据访问层(DAL - Data Access Layer ...
T系统和应用集成-从SOA架构思想到服务架构规划设计
T系统和应用集成-从SOA架构思想到服务架构规划设计原创人月聊IT 2020-09-23 13:48:20 作者:人月神话,新浪博客同名简介:多年SOA规划建设,私有云PaaS平台架构设计经验, ...
系统架构设计师如何进行架构设计
9.1 软件架构概述 9.1.1 软件架构的定义定义1:软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构有软件元素.元素的外部可见属性及他们之间的关系组成. 定义2:软件架构为软件系统 ...
架构师之路---架构的演变详解
前言:架构的演变流程单体架构 ==> 垂直架构 ==> 前后端分离 ==> EAI架构 ==> SOA架构 ==> 微服务 ==> 微服务2.0 1.单体架构: ...
案例分析架构分析汇总-系统架构师考试
文章目录 2018年下 2017年下 2016年下 2015年下 2018年下试题一阅读以下关于软件系统设计的叙述,在答题纸上回答问题 1 至问题 3. [说明] 某文化产业集团委托软件公司开发一 ...
自动驾驶计算系统的多种计算架构---分布式计算架构、中心式计算架构和混合式计算架构
编者按:在走完5个月漫长的收购流程之后,英特尔公司(Intel)150亿美元收购以色列ADAS技术供应商Mobileye的收购案终于在北京时间8月9日完成.不得不说,半导体产业(包括汽车半导体)的兼并 ...
系统架构：经典三层架构
引言经典三层架构是分层架构中最原始最典型的分层模式,其他分层架构都是其变种或扩展,例如阿里的四层架构模式和DDD领域驱动模型.阿里的四层架构模型在三层基础上增加了 Manager 层,从而形成变种 ...

最新文章

热门文章