ble系统知识介绍(较为完整,持续更新中)

这篇具有很好参考价值的文章主要介绍了ble系统知识介绍(较为完整,持续更新中)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

BLE学习

现在网上关于BLE系统的学习资料实在是太少了,因此本文希望能够聚集一些资料能够系统的入门BLE,本文翻译自Bluetooth_LE_Primer_Paper,还有一些网上的一些资料,如果侵害到了某些作者的权益请及时联系我

参考资料和链接

https://blog.csdn.net/XiaoXiaoPengBo/article/details/115475793

https://www.youtube.com/watch?v=eZGixQzBo7Y&list=PLYj4Cw17Aw7ypuXt7mDFWAyy6P661TD48&ab_channel=Ellisys(油管系列视频)

https://www.bilibili.com/video/BV1ad4y1d7AM/?spm_id_from=333.337.search-card.all.click&vd_source=106bffd01f342df90cb3b639ce6bede7(b站系列视频)

https://www.youtube.com/watch?v=JSQhRyTKnW4&ab_channel=NovelBits(ble 十分钟介绍)

https://www.youtube.com/watch?v=_KtmeH7Tte8&list=PLIhKsUwB2-ex0dxe9E-Qyifk7UdtcgIMA&index=1&ab_channel=BinaBhatt(ble 油管系列视频)

https://www.youtube.com/watch?v=sHJ2_cyi_yc&ab_channel=NPTEL-IndianInstituteofScience%2CBengaluru(mesh介绍)

https://www.youtube.com/watch?v=4N6qyaWSne0&ab_channel=AllSystemsGo%21(mesh介绍)

https://www.youtube.com/watch?v=7mkTBgVfg3w&t=38s&ab_channel=%E6%9E%97%E6%B8%85%E6%98%80(蓝牙协议介绍 中文)

1. 蓝牙介绍

蓝牙技术自2000年以来就一直存在。最初是为了让两个设备在无需任何中间网络设备的情况下进行无线数据交换,很快就被应用于产品,如无线鼠标和汽车免提套件。 后者是音频产品,而音频证明了这种原始版本的蓝牙技术的成功应用。多年来一直如此。

这种第一版蓝牙技术,在最早的蓝牙产品中使用,正式称为蓝牙BR(基本速率)。 它在物理层上提供了1百万比特每秒(1 mb/s)的原始数据速率。

后来,定义了更快的蓝牙技术版本,称为蓝牙BR / EDR(增强型数据速率)。 它提供了2 MB / s的原始数据速率,但仍设计用于涉及两个设备之间直接交换数据的用例。

蓝牙低功耗(LE)首次出现在蓝牙核心规格1的4.0 版本中。 这是一种新版本的蓝牙技术,它不是取代其前身——蓝牙BR / EDR,而是作为替代方案与之相伴而存,并具备能够满足新一代产品和新的挑战性技术和功能要求的能力和优势。

BLE支持除两个设备之间的点对点通信以外的其他拓扑结构,其广播模式允许一个设备同时向无限接收器传输数据。 它也是蓝牙网状网络的基础,使得可以创建数万个设备的网络,每个设备都能够与网络中的任何其他设备进行通信。

连接定向通信和无连接通信都支持两个设备之间的一对一通信。无连接广播支持一对多通信。

这种新型蓝牙技术的原始设计目标之一就是高效利用电源。 设想设备可以在小巧(如硬币大小),可以持续运行数天或数周的电池上运行,并且这种对能量效率的追求解释了Bluetooth LE的许多定义特征。 特别地,该设计将不对称的能力和责任交给设备,以确保相对于纽扣电池等能源相对丰富的设备,如大型智能手机电池,承担更多重负。这个设计决策及类似的决策使得Bluetooth LE成为低功耗无线通信技术,并使其位于随后几年众多类型产品的广泛采用地位。

1.1 蓝牙版本发展介绍

蓝牙版本发布时间、传输速度、传输距离列表

蓝牙版本 发布时间 最大传输速度 传输距离
v1.0 1998 723.1Kbit/s 10m
v1.1 2002 810Kbit/s 10m
v1.2 2003 1Mbit/s 10m
v2.0+EDR 2004 2.1Mbit/s 10m
v2.1+EDR 2007 3Mbit/s 10m
v3.0+HS 2009 24Mbit/s 10m
v4.0 2010 24Mbit/s 50m
v4.1 2013 24Mbit/s 50m
v4.2 2014 24Mbit/s 50m
v5.0 2016 48Mbit/s 300m
v5.1 2019 48Mbit/s 300m
v5.2 2020 48Mbit/s 300m

1.2 两种蓝牙协议

1.2.1 Basic Rate(BR)和Low Energy(LE)

蓝牙协议包括两种技术:Basic Rate(简称BR)和Low Energy(简称LE)。这两种技术,都包括搜索(discovery)管理、连接(connection)管理等机制,但它们是不能互通的!这也是蜗蜗抱怨蓝牙协议不优雅的原因之一。

厂商要么实现这两种技术中的一种,这时就只能和同样实现了这个技术的设备互通,而不能和实现另外一种技术的设备互通。如果厂商要确保能和所有的蓝牙设备互通,那么就只能同时实现两种技术,而不去管是否真的需要,这样就能碰到什么人说什么话了!

1.2.2 Basic Rate(BR)

Basic Rate是正宗的蓝牙技术,可以包括**可选(optional)的EDR(Enhanced Data Rate)技术,以及交替使用的(Alternate)**的MAC(Media Access Control)层和PHY层扩展(简称AMP)。说着真拗口,不过通过背后的应用场景,就好理解了:

蓝牙诞生之初,使用的是BR技术,此时蓝牙的理论传输速率,只能达到721.2Kbps。在那个年代,56Kbps的Modem就是高大上了,这个速度可以说是惊为天人了啊!但是科技变化太快了,BR技术转眼就过时了。那怎么办呢?缝缝补补一下,增强速度呗,Enhanced Data Rate就出现了。

使用EDR技术的蓝牙,理论速率可以达到2.1Mbps。这一次的升级换代,还算优雅,因为没有改变任何的硬件架构、软件架构和使用方式上的改变。

也许你也猜到了,EDR又落伍了,看看人家WIFI(WLAN),几十Mbps,上百Mbps,咱们才2.1Mbps,也太寒酸了吧!那怎么办呢?蓝牙组织想了个坏主意:哎,WIFI!把你的物理层和MAC层借我用用呗!这就是AMP(Alternate MAC and PHY layer extension)。艾玛,终于松口气了,我们可以达到54Mbps了。

不过呢,由于蓝牙自身的物理层和AMP技术差异太明显了,这次扩展只能是交替使用(Alternate)的,也就是说,有我(BR/EDR)没你(AMP)。嗯!不优雅!

1.2.3 BLE

上面所讲的BR技术的进化路线,就是传输速率的加快、加快、再加快。但能量是守恒的,你想传的更快,代价就是消耗更多的能量。而有很多的应用场景,并不关心传输速率,反而非常关心功耗。这就是Bluetooth LE(称作蓝牙低功耗)产生的背景。

LE技术相比BR技术,差异非常大,或者说就是两种不同的技术,凑巧都加一个“蓝牙”的前缀而已。后面我们会详细的解释这种差异,以及LE的行为特征。

1.3 蓝牙系统组成

蓝牙系统的组成,涉及到Bluetooth Application、Bluetooth Core、Bluetooth Host、Bluetooth Controller等词汇,不知道是因为对英文理解的歧义,还是因为蓝牙规范本身定义的歧义,蜗蜗理解这些词汇时感觉有点别扭。因此特意在这个章节中,对相关概念及其背后的意义进行说明。

ble系统知识介绍(较为完整,持续更新中)

  • 图中所描述的蓝牙系统的组成部分,如Bluetooth Core和Bluetooth Application,如Host和Controller,都是指“逻辑实体”。所谓的“逻辑实体”,需要和日常生活中的“物理实体”区隔开。如在做电路设计时,一个蓝牙芯片、一个主控CPU,就是指物理实体。而蓝牙协议所描述的这些“逻辑实体”,不一定会和物理实体一一对应,如在实际应用中,Host和Bluetooth Application可能会位于同一个物理实体中(主控CPU),而Controller单独位于另一个物理实体中(蓝牙芯片)。

  • 蓝牙协议规定了两个层次的协议,分别为蓝牙核心协议(Bluetooth Core)和蓝牙应用层协议(Bluetooth Application)。蓝牙核心协议关注对蓝牙核心技术的描述和规范,它只提供基础的机制,并不关心如何使用这些机制;蓝牙应用层协议,是在蓝牙核心协议的基础上,根据具体的应用需求,百花齐放,定义出各种各样的策略,如FTP、文件传输、局域网等等。

  • Bluetooth Core由两部分组成,Host和Controller。这两部分在不同的蓝牙技术中(BR/EDR、AMP、LE),承担角色略有不同,但大致的功能是相同的。Controller负责定义RF、Baseband等偏硬件的规范,并在这之上抽象出用于通信的逻辑链路(Logical Link);Host负责在逻辑链路的基础上,进行更为友好的封装,这样就可以屏蔽掉蓝牙技术的细节,让Bluetooth Application更为方便的使用。

  • 在一个系统中,Host只有一个,但Controller可以一个,也可以有多个。如:单独的LE Controller;单独的BR/EDR Controller;单独的LE+BR/EDR Controller;在单独的BR/EDR Controller或LE+BR/EDR Controller基础上,增加一个或多个额外的AMP Controller。

1.4 什么是蓝牙双模

蓝牙双模是指同时支持两种蓝牙技术的设备,即同时支持Classic Bluetooth和BLE(低功耗蓝牙)。这样的设备可以兼容传统的Classic Bluetooth协议,同时也能支持使用低功耗蓝牙进行通信,从而增强设备的互操作性和灵活度。一些需要在不同场景下进行数据传输的设备,例如智能手表、智能家居等,通常会支持蓝牙双模功能。

2. BLE规范

深入全面地理解BLE需要对适用规范非常熟悉。 BLE的架构、过程和协议由一种关键规范完全定义,这种规范称为蓝牙核心规范。 产品如何使用蓝牙使它们之间互操作性的问题则由两种特殊类型的规范集合-配置文件和服务来涵盖。 下图说明了BLE规范类型及其关系。

ble系统知识介绍(较为完整,持续更新中)

  • profiles:对于特定的产品或应用类型,定义使用蓝牙技术的规则。

  • Services:包含与设备的某些方面相关的状态数据,并支持对该数据进行指定操作。

  • Bluetooth Core Specification:定义了协议栈层、协议和过程,定义了蓝牙协议栈的所有行为和能力。

2.1 蓝牙核心规范(The Bluetooth Core Specification)

蓝牙核心规范是BLE和蓝牙经典的主要规范。它定义了技术和其层次结构的架构,描述和定义了其关键特性,并定义了支撑重要操作和在给定协议栈层中设备可以通信的正式程序。这是一个必要的大规范。

蓝牙核心规范定义了蓝牙技术的工作方式,以及开发人员在实现蓝牙堆栈或其一个或多个功能时的要求。

2.2 概要规范(Profile Specifications)

用于通信的两台BLE设备通常形成客户端/服务器关系。服务器包含表示状态的数据,客户端以某种方式使用这些数据。Profile规范定义了相关设备(如智能手表和钥匙扣)所扮演的角色,特别是定义了客户端设备的行为以及其应该使用连接的服务器上的数据。

2.3 Service Specifications

服务器上的状态数据存储在正式定义的数据项中,称为characteristics和descriptors。这些characteristics和descriptors组合在一起形成service。Service提供了一个上下文环境,为其中包含的characteristics和descriptors分配了意义和行为。 每个Service规范定义一个单独的service,以及其中包含的characteristics和descriptors。在service规范中定义了托管服务的设备在响应各种条件和状态数据值时所展现的行为。 Service规范可以被视为定义了服务器设备行为的一个方面。

2.4 Assigned Numbers

BLE的各个方面都使用唯一标识符。例如,所有services、characteristics和descriptors都具有唯一的通用标识符(UUID),用于标识与其相关的service、characteristic或descriptor类型,而不是特定设备上的实例。某些profile需要公司被识别为具有唯一公司标识符。 由Bluetooth SIG分配的标识符称为分配号码,可以在Bluetooth SIG网站的分配编号页面上获取完整列表。

3.BLE堆栈

3.1 高层次体系结构

BLE堆栈由许多层和功能模块组成,其中一些是必需的,而另一些是可选的。这些堆栈的部分分布在两个主要的架构块——主机和控制器上,并且标准逻辑接口定义了两个组件之间可以进行通信的方式。 主机通常类似于操作系统。控制器通常是一个片上系统。

然而,这并不是必然的,蓝牙规范没有规定任何这样的实现细节。重要的是,在架构中,主机和控制器作为相互独立的逻辑容器来运行,可以通过一种标准界面进行通信,这允许蓝牙系统由来自不同制造商的主机和控制器组件组成。

图2说明了BLE堆栈、其层以及它们在主机和控制器组件中的分布情况。 主机控制器接口(HCI)表示它们之间的逻辑接口,但本身不是物理组件。HCI可以通过底层物理传输的多种不同方式进行实现,但逻辑或者功能接口总是相同的。 LC3是低复杂度通信编解码器,是与BLE音频一起使用的默认音频编解码器。它并不是标准BLE堆栈的一部分,但在LE音频产品中始终会找到LC3组件,如图所示,LC3组件可以在主机或控制器中实现。

图3说明了通信系统的标准OSI参考模型。应该注意的是,与许多只跨越物理和数据链路层等OSI层子集的其他无线系统相比,BLE堆栈跨越了OSI参考模型的所有层(在这看到了计算机网络七层协议好亲切哈哈哈哈)。蓝牙作为一个完整的堆栈通信系统拥有的一个优势是,它没有什么对其他标准机构的外部依赖。这样的依赖可能会限制技术的发展。

ble系统知识介绍(较为完整,持续更新中)

蓝牙Mesh使用BLE控制器与链接层和物理层,而主机部分包含一组实现蓝牙Mesh协议和程序的可选层。本资源不再深入介绍蓝牙Mesh,对于了解此主题的教育资源,读者可以参考下面的第16节“其他资源”。

3.2 BLE层级

见figure2,各层的主要职责如下

  • 物理层:定义与无线电(RF)有关的所有蓝牙技术方面,包括调制方案、频段、信道使用、发射器和接收器特性等。定义了几种不同的物理层参数组合,并称为PHY。

  • 链接层:定义空中接口数据包格式、比特流处理过程(如检错)、状态机和用于无线通信和链路控制的协议等。定义使用底层无线电进行无连接、连接导向和等时通信的几种不同方式,称为逻辑传输。

  • 等时自适应层(ISOAL):允许使用等时通信的设备使用不同的帧持续时间。执行成帧PDU的分段和重组,或未成帧PDU的分割和重新组合。

  • 主机控制接口(HCI):为主机组件和控制器之间的命令和数据双向通信提供明确定义的功能接口。由数种物理传输实现之一提供支持。

  • 逻辑链路控制和适应协议(L2CAP):在主机内充当协议复用器,确保协议由适当的主机组件服务。在下层和上层L2CAP之间执行PDU/SDU的分割和重组。

  • 安全管理协议(SMP):用于执行诸如配对等安全过程期间的协议。

  • 属性协议(ATT):由ATT客户端和ATT服务器使用的协议,允许在服务器的属性表中发现和使用数据。

  • 通用属性配置文件(GATT):根据属性表中的底层属性定义高级数据类型,称为服务、特征和描述符。定义了使用ATT与属性表进行交互的更高级别程序。

  • 通用接入配置文件(GAP):定义了非连接状态下可使用的操作模式和过程,例如如何使用广告进行无连接通信以及如何执行设备发现。定义了安全级别和模式。定义了一些用户界面标准。
    如图2所示,BLE堆栈中的每一层现在将逐一进行更详细的研究

ble系统知识介绍(较为完整,持续更新中)

4.物理层(The Physical Layer)

BLE的物理层定义了如何使用无线电发射器/接收器对数字数据进行编码和解码,以及其他适用的无线电相关参数和属性。

4.1 频段

BLE在2400 MHz至2483.5 MHz范围内的2.4 GHz不受许可频段中运行,该频段被划分为40个信道,每个信道间距为2 MHz。信道的使用方式由链接层和数据传输架构定义。

ble系统知识介绍(较为完整,持续更新中)

4.2 调制方案(Modulation Scheme)

为了在传输前对栈中较高层的数字数据进行编码,并对接收到的无线电信号进行解码,BLE使用一种叫做高斯频移键控(GFSK)的调制方案。 GFSK通过将所选信道(载波)的中心频率的信号向上或向下移动特定量来表示数字值1或二进制值0。对信号应用高斯滤波以减少可能伴随着突然频率变化的噪声。
图6说明了基本的频移键控过程。请注意,频率偏移量称为频率偏差,并且至少为+/-185 kHz或至少370 kHz,具体取决于所使用的PHY变体(PHY在第6.3节中有说明)。

ble系统知识介绍(较为完整,持续更新中)

4.3 物理层变体

定义了三种调制方案变体。每个变体都称为PHY,并有一个名称。在物理层,传输速度是以符号每秒而不是位每秒来测量的,因为物理层只涉及模拟无线电工件,而不涉及数字概念。但蓝牙低功耗(Bluetooth LE)使用二进制调制方案,这意味着单个模拟符号表示堆栈顶部的单个数字位。

定义的三种PHY类型总结如下:

  • LE 1M PHY使用1 Msym/s的符号速率,至少需要185kHz的频率偏移,并且不使用特殊编码。所有设备必须支持LE 1M PHY。

  • LE 2M PHY类似于LE 1M,但使用2 Msym/s的符号速率,并且至少需要370 kHz的频率偏移。对LE 2M PHY的支持是可选的。

  • LE编PHY使用1 Msym/s的符号速率,但数据包要经过一种称为前向纠错(FEC)的编码。该编码在链路层中定义。FEC可以增加传输的有效范围,但会降低应用程序的数据速率。对LE编码PHY的支持是可选的。

下表为三种类型的对比表格:

ble系统知识介绍(较为完整,持续更新中)

一些名词的定义

  • 符号速率:物理层传输模拟符号的速率。

  • 协议数据速率:指和Bluetooth协议数据单元(PDUs)相关的比特率,包括其应用程序数据负载,但不包括在使用LE编码PHY时包含在数据包中的FEC数据。

  • 近似最大应用数据速率:应用程序数据之间可以通信的近似最高速率,在已连接设备上由各种PDU的有效负载部分进行传输,其他部分的协议数据速率被蓝牙协议数据占用。

  • CRC:循环冗余校验。用于检测传输错误的字段。该字段及其使用在链路层中定义

4.4 时分复用

BLE收发机是一种半双工设备,可以进行发送和/或接收,但不能同时进行。但是,所有PHY都使用时间分割双工(TDD)方案,以表现出全双工收发机的外观。

4.5 发射功率和接收灵敏度

物理层定义了发射机的特性,包括输出功率要求,规范规定:

  • 在最大功率设置下的输出功率水平应在0.01 mW (-20 dBm) 和100 mW (+20 dBm)之间。

世界各地的监管机构可能会覆盖这些要求,并确保实现者的设备符合适用的本地法规。

接收灵敏度被定义为体验特定误比特率(BER)输入级别的接收器。所指定的BER因接收的数据包长度而异,因为链路层将单个循环冗余校验(CRC)字段附加到每个数据包中,并将其用作在解码数据包中检测位错的机制。由于数据包长度不同,且每个数据包有一个CRC,因此数据包的长度影响计算的误比特率。通常,在关于BLE接收灵敏度的讨论中引用的误比特率为0.1%,对于长度不超过37个八位组的数据包,这是最大的错误率。

物理层定义的其他接收机特性包括抗干扰性能、带外阻塞、交调特性、最大可用输入电平以及如果支持则需要的接收信号强度指示(RSSI)的要求精度。

4.6 天线切换

BLE支持两种计算接收信号来源方向的方法。第一种称为到达角(AoA),第二种称为离开角(AoD)。这两种方法都涉及到一个设备拥有一个天线阵列,并在传输定向查找信号(AoD方法)或接收信号时从一个天线切换到另一个天线的过程。定向查找信号是包括常量音扩展(CTE)字段的标准蓝牙数据包。

天线阵列有许多不同的设计,从一个天线切换到下一个可以遵循各种不同的切换模式。这由主机控制,但物理层也定义了一些通用的关于天线切换过程、相关接收器要求和一些有用的定义的规则。

《蓝牙核心规范》在第6卷A部分第5章中更详细地涵盖了该主题。有关AoA和AoD定向查找功能的更多信息可在《蓝牙核心规范》版本5.1功能概述文件中找到。

[Core_v5.3.pdf](BLE学习+4dbbd55a-b55e-462f-9f76-b8d89f5897ed/Core_v5.3 1.pdf)

5. 链路层(The Link Layer)

5.1 链路层概述

链路层规范是蓝牙核心规范中几乎最大的部分,仅次于主机控制器接口功能规范。然而,可以说它是最复杂的。 链路层具有许多职责。它定义了通过空气传输的几种数据包类型和相关的空气接口协议。其操作受到明确定义的状态机的影响。根据状态,链路层可能会以许多不同的方式运作,由多种类型的事件驱动。定义了许多控制过程,这些过程会影响链接或链接使用参数的状态。无线电信道选择和分类在链路层规范中得到定义。 链路层支持连接和无连接通信、确定性和(轻微)随机化事件定时。它既支持两个设备之间的点对点通信,也支持从一个设备并发地向不限数量的接收设备发送单向通信。 BLE的许多灵活性都源于链路层的复杂性。

5.2 数据包

链路层定义了两种数据包类型。第一种是由未编码的物理层(参见图7),即LE 1M和LE 2M使用的,第二种是由LE编码物理层(参见图8)使用的。

ble系统知识介绍(较为完整,持续更新中)

两种数据包类型都包括前导码、接入地址和CRC三个字段。表1解释了这些通用字段的含义。

链路层数据包字段 描述
前导码 前导码使接收器能够精确同步于信号的频率,执行自动增益控制,并估计符号定时。
接入地址 接入地址被接收器用来区分信号和背景噪音,并确定数据包对接收设备的相关性。例如,一对连接设备使用相同的随机分配的接入地址交换数据包。未参与连接的设备将忽略此类数据包,因为接入地址不适用于它们。同样,所有传统广播数据包都使用值为0x8E89BED6的相同接入地址,表示这些数据包可能被所有设备接收。
CRC 循环冗余校验(CRC)用于误差检测。发射器使用数据包中的其他比特的值计算它的值。当接收到一个数据包时,接收设备也会根据收到的数据包中除了CRC字段之外的比特值计算出一个CRC值。然后将接收方计算得出的CRC值与数据包中的CRC值进行比较。如果两个CRC值相匹配,则数据包被正确接收。如果不匹配,则被认为它包含一个或多个比特错误。

5.3 状态机

链路层由状态机管理,见下图

ble系统知识介绍(较为完整,持续更新中)

请参考链路层规范以获取每个状态的详细信息。呈现了一个概要。请注意,一些术语将在本节后面解释

  • 待机(Standby):设备既不发送也不接收数据包。

  • 初始化(Initiating):响应特定设备的广告数据包以请求连接。

  • 广告传输(Advertising):传输广告数据包并可能处理其他设备对广告数据包的响应数据包。

  • 连接状态(Connection):与另一个设备建立连接。

  • 扫描(Scanning):监听其他设备发出的广告数据包。

  • 等时广播(Isochronous Broadcast):广播等时数据包。

  • 同步(Synchronization):侦听由特定设备传输的特定广告序列属于的周期性广告。

当处于连接状态时,定义了两个重要的设备角色:集中器角色和外围器角色。当一个设备发起连接并从初始化状态转移到连接状态时,它承担了集中器角色;当一个设备接受一个连接请求,并从广告状态转换到连接状态时,则承担外围器角色。例如,智能手机包括音乐播放应用和便携式BLE扬声器,通常智能手机会扮演集中器角色,扬声器扮演外围器角色。智能手机通过扫描其广告数据包来发现扬声器,然后通常需要用户参与,启动对扬声器的连接。一旦连接成功,遵循相关LE Audio规范中定义的额外过程,就可以建立一个音频流。

并非所有的设备角色和状态组合都被允许。蓝牙核心规范中有更多详细信息

5.4 通道选择

正如第4.1节频段所述,BLE将2.4 GHz频段划分为40个通道。链路层控制这些通道的使用方式,而其使用方式取决于BLE正在用于通信的整体方式(更正式地说,这在第7.6节数据传输架构中已经涵盖)。

BLE使用不同的扩频技术,在一段时间内通过多个通道传输数据。这降低了碰撞的机会,使通信更加可靠。

BLE中一个众所周知的扩频技术的例子是自适应频率跳变。这涉及到用于包通信的无线电信道在固定时间间隔内发生改变。通过一个频道选择算法和一个称为频道映射的数据表来选择通道,该表将每个通道分类为已用或未用。实现可以监测每个通道上的通信质量,如果发现有通道性能不佳,可能由于其他来源干扰引起,频道映射可以更新以将该通道的分类设置为未使用,从而确保此通道不再被算法选定。通过这种方式,通道选择算法可以适应所遇到的条件并优化为最可靠的性能。

在下面讨论BLE逻辑传输及其关联的物理通道时,将进一步描述如何使用无线电信道。

5.5 设备地址

BLE设备具有地址,该地址在一些链路层空中接口数据包中用作设备标识符。设备地址长度为48位,并定义了几种类型。

完整的细节可以在《蓝牙核心规范》第6卷第B部分1.3节中找到。

5.5.1 公共设备地址

公共设备地址由电气和电子工程师学会(IEEE)分配。

5.5.2 随机设备地址

随机设备地址是随机分配的,但其值必须满足《蓝牙核心规范》中规定的规则。有三个子类型的随机设备地址,即静态地址私有可解决地址私有不可解决地址。 随机设备地址的子类型可以通过检查其地址的两个最高有效位来确定。

0b00:不可解析的私有地址 (Non-resolvable private address)

不可解析的私有地址是随机生成的,并且通常在每次重新连接时更改。它可以用于提供隐私保护,但无需处理可解析的私有地址以检查是否包含在过滤器接受列表中等成本。请参见7.5.3过滤器接受列表。 例如:2C:C1:EE:7B:71:96是一个不可解析的私有地址。通过将最高位字节值(0x2C)转换为二进制,可得到0b00101100。最高的两位bit位的值为0b00,这表明它是一个不可解析的私有地址,根据7.5.2随机设备地址中的表格。

0b01:可解析的私有地址 (Resolvable private address)

RPA(可解析私有地址)是周期性变化的。蓝牙核心规范建议间隔大约15分钟,但最终控制RPA更改的时间是一个实现决策。

示例4C:C1:EE:7B:71:96为可解析的私网地址。这可以通过将最高字节值(0x4C)转换为二进制来验证,得到0b01001100。根据随机设备地址表,最高两位的值为0b01,表示这是一个可解析的私有地址。

生成RPA的过程涉及一个称为身份解析密钥(IRK)的安全密钥,该密钥在绑定设备和应用哈希函数时在设备之间交换。绑定的对等设备可以对接收到的数据包中的每个IRK值应用相同的哈希函数来解析RPA,每次一个。当进程与接收到的RPA匹配时,对等端就知道它已经解析了远程设备的地址和真实身份。未与发送设备绑定的设备无法解析RPA。

示例5A:C1:EE:7B:71:96为可解析私网地址。可以通过转换最高有效字节值(0x5A)转换为二进制,得到0b010111010。最高两位值为0b01,表示这是一个可解析的私有地址,

0b11:静态设备地址(Static device address)

静态设备地址是随机生成的,但并没有以任何方式加密,以保护设备的隐私。使用静态地址的设备允许在每次重启时重新生成地址,但不需要这样做。它不允许在其他任何时候更改其地址。

例如:CC:C1:EE:7B:71:96是一个静态地址。通过将最高位字节值(0xCC)转换为二进制,可得到0b11001100。最高的两位bit位的值为0b11,这表明它是一个静态设备地址。

0b10:保留以备将来使用 (Reserved for future use)

5.5.3 过滤接受列表

蓝牙链路层具有一种称为“过滤器接受列表”的功能。此列表可以填充主机感兴趣的设备地址以接收数据包。在蓝牙核心规范中定义了一系列不同的过滤器策略,描述了如何处理设备地址在此列表中的存在或不存在。

过滤器接受列表的一个好处是,它允许控制器有效地选择需要传递到主机上的数据包,并丢弃不需要的数据包。

可解析私有地址可以添加到过滤器接受列表中,但由控制器处理会产生一定成本。由于可解析的私有地址会定期更改,因此必要时在过滤器接受列表中存储已解析的地址,并且为了检查列表中是否存在可解析的私有地址,控制器必须首先解析接收到的可解析私有地址。

5.6 数据传输架构

蓝牙核心规范的架构部分定义了许多概念,共同构成蓝牙数据传输架构。其中关键的概念包括物理信道物理链路逻辑链路逻辑传输。特定的组合被定义用于支持不同应用程序类型,每种类型都具有关于拓扑结构时间可靠性信道使用等问题的特定要求。

物理信道定义了使用蓝牙进行通信的几种不同方式之一。例如,可以使用LE Piconet物理信道在两个已连接设备之间进行通信,该通信涉及37个信道上的自适应频率跳跃。另外,LE广告物理信道可用于向无限数量的其他设备进行广播式、无连接通信。LE周期物理信道也可用于广播数据,但以确定的时间表定期进行。观察器(接收者)设备能够确定该时间表并使用它来同步它们的扫描计划。

物理链路基于单个具体的物理信道,并指定了该链路的某些特征,如功率控制的使用或否。

逻辑链路和传输具有各种参数,旨在提供一种适当的手段,在使用特定的物理信道类型上支持特定的数据通信要求。

例如,BLE中可靠的双向点对点通信使用LE异步连接导向逻辑(ACL)传输,并使用基于LE Piconet物理信道的物理链路控制数据或用户数据的LE-C链路或LE-U链路。

ble系统知识介绍(较为完整,持续更新中)

另一方面,在BLE中不可靠的单向广播通信使用LE广告广播(ADVB)逻辑传输,并使用基于LE广告物理信道的物理链路控制数据或用户数据的ADVB-C链路或ADVB-U链路。

ble系统知识介绍(较为完整,持续更新中)

5.7 逻辑传输(The Logical Transports)

5.7.1 LE ACL - LE异步面向连接的逻辑传输(LE ACL - LE Asynchronous Connection-Oriented Logical Transport)

5.7.1.1 基础知识(Basics)

当两个Bluetooth LE设备连接时,它们使用异步连接导向逻辑传输(LE-ACL或简称ACL)。LE-ACL是提供面向连接数据通信的最常用的BLE逻辑传输类型之一。实际上,ACL连接通常简称为连接。设备可以通过响应接收到的广告数据包并发送请求连接PDU与广告设备建立连接。请求中指定了许多参数,其中包括接入地址连接间隔外围器件延迟监管超时信道映射等。

发起连接的设备从待命状态转换到初始状态,然后进入连接状态并承担中心角色。另一个设备从广告转变为连接,并承担外围角色。连接间隔参数定义了用于服务此连接的无线电每隔多长时间(以毫秒为单位)可以使用一次。每当连接间隔到期时,就会开始一次连接事件,并在此时点中央设备可以传输数据包。给定连接的连接事件都有一个16位标识符,它是一个计数器值,在每个事件中递增。在每个连接事件开始时,将使用适用的信道选择算法来选择要使用的无线电信道。

监管超时参数指定了在接收到两个链路层数据包之间经过的最长时间,超过这个时间则认为链路已经丢失。外围设备拥有与中心设备相同的约定连接参数,因此知道何时从中心设备预期传输的数据包以及用于接收数据包的信道,可以在同一时间精确地侦听该信道,从而接收来自中心的数据包。外围设备可能会在接收到中央设备的最后一个比特之后在150微秒内(+/- 2μs)回复中央设备。中央和外围设备交替发送和接收数据包,并且在连接事件期间可以交换实现定义数量的数据包。请注意,非零的外围延迟参数值可能会修改外围设备的行为。

下图显示了在两个连接事件期间数据包的基本交换情况,C>P表示中央设备的数据包传输,P>C则表示外围设备的数据包传输。

ble系统知识介绍(较为完整,持续更新中)

在LE ACL连接上交换的数据包包含LL数据PDU或LL控制PDU,它们与链路层控制过程相关联。

5.7.1.2 订阅和确认(Ordering and Acknowledgements)

LE-ACL包括一个系统来确保按正确顺序处理数据并可以确认接收到的数据包,从而决定是继续下一个数据包还是重新传输上一个数据包。数据包包含三个重要字段,它们有助于通信变得可靠,称为序列号(SN)下一期望的序列号(NESN)更多数据字段。这三个字段都是单位比特字段,它们的使用提供了一种确认机制和检查接收到的数据包是否按正确顺序排列的方法。

通信始于主设备(设备A)发送带有SN和NESN均设置为零的链路层数据包。从这一点开始,在进行的每次数据包交换中,如果一切正常,由设备A设置的SN字段的值将在0和1之间交替变化。因此,次要设备(设备B)总是知道下一个要收到的数据包的SN值,并对此进行检查。

如果设备B从设备A收到具有预期SN值的数据包,则会发送一个链路层数据包,其中NESN设置为逻辑值NOT(SN)。例如,如果接收到的SN值为1,则响应中的NESN将为0。

当设备A从设备B收到一个响应,其中NESN设置为设备A在其下一个数据包中要使用的SN值时,设备A认为这是来自设备B的确认,确认它已正确接收到最后传输的数据包。具体可以见下图

ble系统知识介绍(较为完整,持续更新中)

如果设备B收到具有错误SN值的数据包,则认为该数据包是上次接收的数据包的重新传输,对其进行确认但不将其上传给更高层进行进一步处理。

如果设备A从设备B的响应中收到意外的NESN值或根本没有收到响应,则使用与最初使用的相同的SN值重新发送数据包。不同控制器实现可以自行实现有关多少次重发后才得出通信失败结论的算法。请参考下图

ble系统知识介绍(较为完整,持续更新中)

每个数据包都包含一个CRC字段,加密的数据包还包括一个MIC字段。收到数据包后,链路层会检查CRC和(如果存在)MIC。如果其中任何一个检查失败,则不会确认该数据包,并且这通常会导致数据包的发起者重新发送它。请参见下图

ble系统知识介绍(较为完整,持续更新中)

5.7.1.3 外设延迟(Peripheral Latency)

在每个连接事件期间,外设不必始终监听来自中央设备的数据包。外设延迟参数定义了连续多少个连接事件期间外设不必监听。这使得外设可以节省电力。

下图展示了外设使用外设延迟=1时的行为,因此仅在交替的连接事件中进行监听。中央设备可以在外设未监听的那些事件中进行传输,但是这些数据包将不会被接收,因此也不会被确认,从而结束连接事件。

ble系统知识介绍(较为完整,持续更新中)

5.7.1.4 通道使用(channel use)

LE-ACL采用一种称为自适应跳频的方案。在每个连接事件开始时,进行跳频,使用一个信道选择算法从可用信道集合中确定性地选择一个无线电信道。然后,连接中的每个设备都将切换到所选信道,并随着时间和一系列连接事件的发生,使用一系列不断变化的不同信道进行通信,分布于2.4 GHz频带上,从而大大降低了碰撞发生的概率。

在Bluetooth LE定义的40个信道中,有37个信道(称为通用广告信道)被用于设备之间的链路建立以及在连接之前进行的广告传输。在特定环境中,某些蓝牙无线电信道可能效果不佳,可能因为干扰影响它们,而其他信道则运行得更加可靠。随着环境中其他无线通信设备出现和消失,可靠信道和不可靠信道的列表也可能随着时间发生变化。

连接中的中央设备维护一个通道映射,将每个良好工作的通道分类为已使用或未使用。使用一个链路层过程,此通道映射与外设共享,以便它们都具有关于将使用哪些信道和避免哪些信道的相同信息。外设可能会维护自己的通道映射及其内容,并与中央设备共享。通过这种方式,中央设备可以做出有关信道使用的决策,考虑到自己的无线电条件以及远程外设设备所经历的条件。

设备使用特定于实现的技术来监视每个通道运行情况的好坏。如果确定一个或多个之前工作良好的信道现在已经不能工作得足够好,则更新通道映射。反之,“坏”的信道当前表现良好,也将在通道映射中更新其状态。通道映射更新然后需要与另一个设备进行共享。通过这种方式,Bluetooth LE确保仅使用已知的良好信道,避免问题信道并保持通道映射最新,以便始终使用最优子集的信道。这就是蓝牙自适应跳频系统的自适应性方面。

下图展示了两个连接设备在测试期间使用信道的方式,并说明了无线电使用如何分布于ISM 2.4 GHz频谱上。在图表底部,您可以看到通道索引和频率(以MHz为单位)。通道索引是指无线电信道的间接引用方式。

ble系统知识介绍(较为完整,持续更新中)

5.7.1.5 链路层控制

链接层规范指定了许多控制过程,下表列出了一些示例。

控制过程 描述
连接更新 允许中心或外设设备请求更改连接参数连接间隔、外设延迟和监视超时
信道映射更新 允许中央设备向已连接的外设传输其最新的通道映射数据
加密 允许中心或外设启用数据包加密
特征交换 允许中心或外设作为一个比特图字段发起Link Layer功能交换
周期性广告同步传输 允许中央设备或外设通过LE ACL连接将与已发现的周期性广告列车相关的同步信息传输到另一个设备
CIS创建过程 CIS创建过程
功率控制请求 允许其中一个对等方请求另一个对等方调整其发射功率水平
信道分类报告 允许外设向已连接的中央设备报告信道分类数据。

子速率连接是指为LE ACL连接分配了其他属性,并在某些方面表现不同的连接。这些额外的属性被称为子速率因数,子速率基础事件和连续号码。

子速率连接属性提供了一种机制,用于指示所连接设备只能主动使用特定子集的连接事件,不在其他连接事件中使用无线电信道。因此,子速率连接可以具有较短的ACL连接间隔,但仍表现出低占空比。

图下图说明了与子速率连接相关的基本概念。

ble系统知识介绍(较为完整,持续更新中)

在这里,我们可以看到仅使用五个连接事件中的一个。其他四个被跳过,因此在这些连接事件期间没有无线电活动。使用与跳过连接事件的比率由子速率因数参数确定,在此示例中设置为5。

用于传输和接收链路层数据包的连接事件称为子速率连接事件。考虑到底层ACL连接参数和控制连接子速率的参数之间的关系,可以将子速率连接视为具有两个连接间隔:控制ACL连接事件发生频率的连接间隔,并且处理子速率参数后实际使用这些ACL连接事件的有效连接间隔。

子速率连接使用不同的Link层控制过程,特别是更新子速率连接参数的过程与一般的控制更新过程不同。重要的是,子速率连接参数的更改几乎可以立即应用,而一般参数更改需要很长时间才能生效。因此,子速率连接的优点在于可以建立具有低占空比和消耗少量功率的持久连接,并可以在没有任何用户感知延迟的情况下切换到高占空比、高带宽连接。这种能力在某些LE Audio场景中特别适用,例如涉及助听器和智能手机的场景。

Bluetooth Core Specification Version 5.3 Feature Enhancements文献有一个专门讨论子速率连接的章节,并建议作为更多信息的来源。

5.7.2 ADVB-ble广播

5.7.2.1 基础概念

低功耗蓝牙(LE)广播(或简称广播)提供无连接通信模式。它可以用于传输数据或指示可连接的外设设备的可用性。通常,广告包旨在被范围内的任何扫描设备接收。因此,广播可用于在一对多拓扑中向多个扫描设备同时传输数据。然而,还定义了一种称为定向广播的特殊广告形式,这样就允许从一个广告设备到一个特定的扫描设备之间进行单向数据通信,由其Bluetooth设备地址识别。

广告本身只支持单向数据通信,从广告设备到扫描设备,但这些设备可能会通过请求进一步信息或建立连接的PDU来回复广告数据包。当扫描设备回复以获取更多信息时,它被认为正在执行主动扫描。当它不回复时,则被认为是执行被动扫描。

广播通常被称为不可靠的传输方式(这怎么和计算机传输层的UDP协议有点像?),因为接收者不发送任何确认

蓝牙核心规范定义了两种广告过程的类别,分别被称为传统广告扩展广告

5.7.2.2 传统广告

传统广告的信道使用和包大小

使用ADP_IND PDU类型(请参见5.7.2.2.3传统广告和相关PDU类型)的传统广告数据包长度为37个八位字节,其中头部为6个八位字节,负载最多为31个八位字节。广告数据包的完全相同副本被传输到三个专用信道上,这些信道被标记为主广告信道,依次在某些序列中的一个通道上进行传输。这些信道的编号分别为37、38和39。

ble系统知识介绍(较为完整,持续更新中)

调度

广告数据包的传输发生在每次广告事件发生时。广告事件的调度由时间参数控制,在基本情况下,这种调度被故意设置为稍微不规则,以避免与其他广告设备发生持续冲突。

advDelay是一个在每个广告事件中被分配一个伪随机值的数值,它的范围为0-10ms,并且会加到常规的广告间隔(advInterval)中,从而使广告事件在时间上受到干扰。图18复制自蓝牙核心规范第6卷B部分的图4.5,并说明了advDelay参数的影响。

ble系统知识介绍(较为完整,持续更新中)

以这种方式调度广告事件可以避免冲突,但是这使得接收器更难以高效地接收广告数据包,并且需要更高的接收用时循环来适应不可预测的广告事件时间安排。

传统广告和相关PDU类型

有几种 PDU 类型被定义为传统广告使用。不同类型的 PDU 用于无定向广告,数据包适用于任何扫描设备和有定向性广告(directed advertising),其中数据包寻址到特定设备。PDU 类型还指示是否允许主动扫描,并且接收器将回复请求进一步的数据以及广告设备是否可连接。所有传统广告都在主通道37、38和39中的一个或多个通道上进行,并且只能使用LE 1M PHY。

传统广告和相关PDU类型指的是早期 BLE 规范版本定义的广告方式和广告数据单元类型。传统广告采用不完整的蓝牙地址作为设备标识符,并且广告数据包长度有限,最多只能传输31个八位字节的数据。与之关联的 PDU 数据类型包括 Connectable Undirected Advertising (ADV_IND)、Scannable Undirected Advertising(ADV_SCAN_IND)、Non-Connectable Undirected Advertising(ADV_NONCONN_IND)和 Scan Response(SCAN_RSP)。在较新版本的 BLE 规范(如 5.0 和 5.1)中增加了更多的广告方式和数据包类型,并引入了扩展广告方式和通知广告方式等新特性。

下表列举了传统广告额PDU类型

PDU Name Description Channels PHY(s) Transmitted By Scannable Connectable
ADV_IND Undirected
advertising primary LE 1M Peripheral Y Y
ADV_DIRECT_IND Directed
advertising primary LE 1M Peripheral N Y
ADV_
NONCONN_IND Undirected,
non-connectable,
non-scannable
advertising primary LE 1M Peripheral N N
ADV_SCAN_IND Undirected,
scannable
advertising primary LE 1M Peripheral Y
SCAN_REQ Scan request primary LE 1M central N/A N/A
SCAN_RSP Scan response primary LE 1M Peripheral N/A N/A
CONNECT_IND Connect request primary LE 1M central N/A N/A

《蓝牙核心规范》中的《链路层规范》第4.4节列出了所有广告 PDU 类型的详细信息。

5.7.2.3 扩展广告

蓝牙核心规范版本5对广告的执行方式进行了重大改变。增加了八个与广告、扫描和连接相关的新PDU,并定义了新的程序。总体而言,这组新的广告功能被称为扩展广告。 扩展广告允许广播更大量的数据,按确定性时间表执行广告,并传输受不同配置控制的多个不同集合的广告数据。它也在争用和占空比方面提供了显着的改进。 扩展广告由ADV PB和PADVB逻辑传输都使用。

信道使用和数据包大小

在执行传统广告时,射频信道的使用方式与扩展广告中有所不同,主要广告信道37、38和39传输的数据较少,而通用信道0-36则传输大部分数据。在扩展广告的背景下,通用信道也称为次级广告信道。 如5.7.2.2所述的传统广告将相同的负载最多三次传输至三个不同的主广告通道上。扩展广告只传输有效负载数据一次,并通过小的标头引用来自主广告通道的数据。因此,传输的数据总量比使用传统广告等效情况下要小,因此有效占空比减少了。

ble系统知识介绍(较为完整,持续更新中)

ble系统知识介绍(较为完整,持续更新中)

扩展广告允许数据包长达255个八位组。其中一部分是通过将有效负载卸载到0-36通道号范围内的某个次级信道来实现。 在执行扩展广告时,只有主要37、38和39编号信道上传输标头数据。这包括一个名为AuxPtr的字段。

AuxPtr字段参照了一个关联的辅助数据包,其中包含要从0-36通道集合中的次级信道之一传输的有效负载。 AuxPtr包括通用信道索引,指示辅助数据包将被传输到哪个通道,以便接收器知道在哪里找到它。从主要信道上的一个数据包引用的在次级信道上传输的数据包称为下属数据包,而引用数据包则称为上级数据包。

AuxPtr中的通道索引值选择是实施特定的,蓝牙核心规范仅建议“使用足够的信道多样性以避免冲突”。

数据包链接

对于那些需要广播更多数据(高达1650字节)的应用程序的用例,控制器可以分段数据并将数据包链接在一起,每个数据包包含该数据的子集。每个链接数据包都可以在不同的通道上传输,AuxPtr标头字段引用链中的下一个数据包。图21说明了这种情况。

ble系统知识介绍(较为完整,持续更新中)

广告集

传统广告没有为广告有效负载和参数提供形式上的变化机制。 扩展广告包括用于具有多个不同广告数据集的标准机制。 广告集具有ID,用于指示给定数据包属于哪个集,并且每个集都具有其自己的广告参数,例如其广告间隔和要使用的PDU类型。 调度和传输不同数据集的任务由链路层在控制器中完成,而不是由主机驱动,这将更节能。主机只需要最初通知控制器广告集及其各自的参数,之后链路层将接管任务。

周期性广告

扩展广告包括使用确定性调度的广告方法,其细节可以通过扫描设备发现并同步。这称为周期性广告。周期性广告被定义为独立的逻辑传输,因此在第7.7.3节PADVB-LE周期性广播中进行了描述。

扩展广告和相关PDU类型

定义了许多PDU类型可用于扩展广告。表5列出了扩展广告PDU。

ble系统知识介绍(较为完整,持续更新中)

ADV_EXT_IND、AUX_ADV_IND、AUX_SCAN_RSP、AUX_SYNC_IND、AUX_CHAIN_IND和AUX_CONNECT_RSP类型的PDU有效负载均采用通用扩展广告有效负载格式。这包括AuxPtr字段和AdvMode等字段。 AdvMode使用两个比特来指示广告模式的可连接和可扫描属性,而不是明确的PDU类型。 Bluetooth核心规范中的链路层规范章节的第4.4节详细介绍了所有广告PDU类型。

调度

扩展广告在扩展广告事件中进行。扩展广告事件与广告事件同时开始,并包括带有AuxPtr字段的上级数据包及其相关的从属数据包。

5.7.2.4 传统广告和扩展广告的对比

下表为传统广告和扩展广告的对比示意表

对比项 传统广告 扩展广告 扩展广告的优势
最大主机广告数据大小 31字节 1650字节 扩展广告支持分片,使得最大主机广告数据大小可以增加50倍
每个包的最大主机广告数据 31字节 254字节 扩展广告PDU使用通用扩展广告有效负载格式,支持8倍更大的广告数据字段
TX通道 37、38、39 0-39 扩展广告使用37个通用信道作为次要广告信道。但ADV_EXT_IND PDU类型只能在主广告信道(37、38、39)上发送
PHY支持 LE1M LE 1M
LE 2M(除ADV_EXT_IND PDU外)
LE Coded 所有扩展广告PDU(除ADV_EXT_IND)都可以使用3个LE PHY中的任何一个发送,而ADV_EXT_IND PDU则可以使用LE 1M或LE Coded PHY发送
最大活动广告配置 1 16 扩展广告包括广告集,使广告设备可同时支持最多16个不同的广告配置,并根据集合中定义的时间间隔交织每个广告集的广告
通信类型 异步 异步
同步 扩展广告包括周期性广告,实现发送器和接收器之间以同步的方式通信广告数据。

对应于Bluetooth_LE_Primer_Paper.pdf第38页

5.7.3 PADVB - LE 周期性广播

5.7.3.1 基础知识

在ADVB逻辑传输中实施的广告(参见5.7.2 ADVB - LE 广告广播)在广告包传输的时间方面包含一定程度的随机性。0至10毫秒之间的随机延迟被故意插入到广告事件的安排中,以帮助避免持续广告包冲突。在执行传统广告时,这是广告正常工作的唯一的方法。

周期性广告涉及按照确定性时间表传输数据包,并提供了一种机制,使其他设备可以与广告设备的时间表同步扫描数据包。周期性广告始终是不可扫描和不可连接的。

周期性广告可以通过提供更节能的扫描方式来使观察者设备受益,并是LE音频广播解决方案的关键组成部分。 广告在称为周期性广告间隔的固定时间间隔内进行,广告数据有效负载可能会发生变化。一系列AUX_SYNC_IND和相关的AUX_CHAIN_IND PDU被称为形成一个周期性广告训练。 每次周期性广告事件发生时,都会发送一个单独的AUX_SYNC_IND PDU,然后根据主机提供的有效负载是否需要分段而发送零个或多个AUX_CHAIN_IND PDU。 AUX_ADV_IND PDU包括一个名为SyncInfo的字段,它是公共扩展广告有效负载格式的一部分,包含通道和时间偏移信息。

7.7.3.2 通道使用

周期性广告使用37个辅助广告通道。在每个周期性广告事件开始时,使用称为paEventCounter的事件计数器字段作为输入,使用第2个通道选择算法选择通道。该计数器在每个周期性广告事件中递增。与AUX_SYNC_IND PDU相关的任何辅助AUX_CHAIN_IND PDU都使用特定于实现的算法选定其通道,并在AuxPtr字段中指定。请参见Figure 22。

7.7.3.3 调度

周期性广告间隔确定给定广告集的周期性广告可以发生的频率。它从AUX_SYNC_IND PDU的发送开始,并继续通过一系列零个或多个AUX_CHAIN_IND PDUs,如Figure 22所示。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-I3BlXpCB-1685853238013)(BLE学习+4dbbd55a-b55e-462f-9f76-b8d89f5897ed/image 18.png)]

请注意,图22已经简化了,在不同主广告通道上可能有多个ADV_EXT_IND PDU,用单个框表示。 7.7.3.4 同步建立 扫描设备可以通过两种方式之一与周期性广告训练进行同步。它可以扫描AUX_ADV_IND PDU,并使用SyncInfo字段的内容来建立要使用的周期性广告间隔、时间偏移和通道信息,或者它可以通过LE-ACL连接从另一个设备接收到这些信息,该设备本身已从AUX_ADV_IND PDU确定了这些信息。该方法称为周期广告同步传输过程。

5.7.4 LE BIS和LE CIS - 等时通信

本节重点介绍等时通信的关键方面。有关更多信息,建议阅读Nick Hunn所著的Introducing Bluetooth LE Audio。该书以电子形式免费下载,网址为https://www.bluetooth.com/bluetooth-resources/le-audio-book/。Bluetooth核心规范包含完整的详细信息。

5.7.4.1 基础知识

等时通信提供了一种使用Bluetooth LE在设备之间传输定期数据的方法。它提供了一种机制,允许多个接收来自同一源的数据的接收器设备在不同时间同步处理该数据。LE音频使用等时通信。

在使用等时通信时,数据具有有限的有效期,在该期限结束时会过期。尚未传输的已过期数据将被丢弃。这意味着设备只接收符合有关其年龄和可接受延迟规则的数据,某个配置文件可能表达这些规则。

数据以等时流的形式传输,流属于等时组。设备等待一段时间,使得所有是同一组成员的流都有机会在同时传递相关数据包之前,以相同的时间处理接收到的数据包。例如,立体声音乐可以使用两个流进行传递,一个流用于左立体声通道,另一个流用于右立体声通道。这两个流将成为同一组的成员,因此从两个流接收到的数据包的渲染将在同一时间进行,因此用户将以预期的方式听到立体声音乐。

定义了两种使用LE等时物理通道的逻辑传输。连接等时流(LE CIS或简称CIS)使用面向连接的通信,并支持双向数据传输。广播等时流(LE BIS或简称BIS)使用无连接的广播通信,并提供单向数据通信。

5.7.4.2 连接等时流

5.7.4.2.1 CIS概述

单个CIS流在两个连接设备之间提供点对点等时通信,并在称为CIS PDU的链路层PDU中传输数据。LE-CIS(CIS)逻辑传输在图23中表示了整体数据传输架构。

ble系统知识介绍(较为完整,持续更新中)

定义了两个逻辑连接:LE-S和LE-F,可以支持非帧格式(LE-S)和帧格式(LE-F)的数据。LE-S和LE-F的使用是等时适配层的问题。

CIS流使用LE等时物理通道,并可以使用任何BLE PHY。

CIS支持双向通信,并使用确认协议。

CIS流是称为Connected Isochronous Groups(CIGs)的组的成员,每个CIG可包含1个或多个CIS。请参见图24。

每个CIG最多可以有31个CIS。中央设备可以创建多个CIG。然而,可用的空间时间和其他实现细节经常会降低这些限制到较低值。

ble系统知识介绍(较为完整,持续更新中)

5.7.4.2.2 频道使用

连接等时流使用自适应跳频,采用频道选择算法#2。

5.7.4.2.3 调度

CIG及其成员CIS的调度由一组CIG事件、CIS事件和子事件控制。

CIG事件在第一个CIS的锚点处发生,表明开始对属于该CIG的所有CIS进行活动调度。CIG事件在ISO_Interval参数中指定的间隔内发生。

每个CIS事件分为一个或多个子事件。在流参数NSE中指示正在使用的子事件数量。在已连接的等时流中,在子事件进行期间,中央会发出一次传输(T),从设备会以图25所示的方式进行响应®。 子事件之间的间隔由CIS参数Sub_Interval中指定的持续时间隔开。 如果每个CIS事件只有一个子事件,则将Sub_Interval始终设置为零;否则,它至少为400微秒,但小于ISO Interval。

请注意,通道在每个子事件中更改。

每个CIS可以在CIG事件期间按顺序服务,也可以交错处理不同CIS的子事件。图25显示了包含三个CIS的CIG的示例,每个CIS都按顺序服务。
ble系统知识介绍(较为完整,持续更新中)

除子事件数(NSE)之外,每个CIS还有一些重要参数,包括Flush Timeout(FT)和Burst Number(BN)。

每个有效载荷(例如,音频编解码器(如LC3 6)输出的数据块)被指定一个最大的CIS事件数量,以便成功传输(即获得确认),这在FT参数中指定。可以在该类每个CIS事件的每个子事件中尝试,并且如果未能在FT个事件内成功,则将丢弃该数据包。有时候,多个包含不同数据(即有效载荷)的PDU可能同时可用,并且CIS允许在同一CIS事件中传输多个不同的PDU。每个CIS事件可服务的不同PDU数量在Burst Number(BN)参数中进行了说明。 5.7.4.2.4 处理同步

CIG具有一个关联的时间参数,称为CIG_Sync_Delay。同一CIG中的CIS具有名为CIS_Sync_Delay的定时参数,并且这用于通过组内所有流的接收器对等时数据处理的同步(通常是音频渲染)。接收器在呈现接收到的数据之前等待此参数中指定的时间。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6rkVhGG0-1685853238015)(BLE学习+4dbbd55a-b55e-462f-9f76-b8d89f5897ed/image 22.png)]

如图26所示,每个流具有不同的CIS_Sync_Delay值。对于CIG中第一个CIS流,它被设置为组级参数CIG_Sync_Delay。对于组内其他流中的每个流,CIS_Sync_Delay设置为逐渐较低的值。这意味着从早期在该组中服务的流接收数据的设备必须等待更长时间才能呈现接收到的数据包内容,而比其晚传输的设备则可以更快地进行呈现。更高层面的规范(例如配置文件)可能会规定使用进一步的演示延迟计算数据呈现的时间,以允许考虑本地处理延迟。这种分层延迟系统的结果是,每个接收设备将同时处理接收到的数据。

5.7.4.2.5 CIS流创建

建立连接的等时流首先需要创建一个ACL连接。此连接有两个目的。首先,它允许交换链路层控制PDU。其次,一旦建立了流,它提供了一个计划CIS事件的时间参考点。 中央设备始终发起创建CIS的过程。它通过发送称为LL_CIS_REQ PDU的链路层控制PDU来执行此操作。如果一切正常,表示外围回复LL_CIS_RSP PDU,则在中央随后发送LL_CIS_IND PDU时,该流被认为已建立。该PDU包含确定CIS事件时间和呈现前要应用的延迟的重要参数。具体而言,CIS_Offset提供ACL锚点(连接事件中发送第一个数据包的时间)与流的第一个CIS事件之间的微秒偏移量。CIG_Sync_Delay包含以微秒为单位的总体CIG同步延迟值,而CIS_Sync_Delay包含此流要使用的同步延迟值。 流创建后,它可以独立于用于创建它的ACL连接运行,并且并行运行。但是,如果关闭ACL连接,则必须终止相关的CIS。

5.7.4.2.6 CIS加密

如果两个对等设备已配对,则CIS使用的链路可能会加密。

5.7.4.3 广播等时流

5.7.4.3.1 BIS概述

BIS流提供单个发射器(源)和许多接收器(汇)设备之间的广播等时通信。数据以称为BIS数据PDU的链路层PDU传输。控制信息在BIS控制PDU中传输。 图27显示了整个数据传输架构中的LE-BIS(BIS)逻辑传输。
ble系统知识介绍(较为完整,持续更新中)

BIS上广播的数据可以被动或非动进行帧化,逻辑链路类型LE-S和LE-F相应地进行定义。LEB-C逻辑链路承载控制信息。 BIS流使用LE等时物理通道,可以使用任何Bluetooth LE PHY中的PHY。 BIS流是称为广播等时组(BIG)的群组的成员,每个群组可能包含一个或多个BIS。请参见图28。

ble系统知识介绍(较为完整,持续更新中)

每个BIG最多可以有31个BIS。中央设备可以创建多个BIG。然而,可用的空气时间和其他实现细节通常会将这些限制减小到更低的值。

BIS仅支持单向通信

与CIS相比,BIS不包含确认协议。这使得BIS传输本质上是不可靠的。然而,为了解决这个问题,使用了无条件数据包重传系统。由于BIS是单向通信,因此无需为外围回复保留时隙(如CIS所需),因此在一定数量的空气时间内可以安排两倍于CIS的子事件进行传输,因此存在更大的机会进行这些增强可靠性的重传。此外,由于重传是在独立的子事件上发送的,它们会在不同的频道上传输。所选的频道必须距离上次传输至少6 MHz,这有助于缓解特定频道干扰导致的潜在数据包丢失。

5.7.4.3.2 通道使用(Channel Use)

广播等时流使用自适应频率跳跃和通道选择算法#2。

5.7.4.3.3 调度(Scheduling)

BIG及其成员BIS的调度由BIG事件、BIS事件和子事件系统控制。此外,还定义了一个专门的控制子事件,用于传输与整个BIG相关的控制PDU。

BIG事件信号标志着在属于BIG的BIS之间调度活动的开始。 BIS事件从BIG锚点(称为BIG anchor point)开始,其时间间隔是BIG参数BIS_Spacing的倍数。

每个BIS事件被分成一个或多个子事件。正在使用的子事件数量在称为NSE的流参数中指示。在子事件期间,广播者传输单个数据包。通信是单向的,无需接收数据包。子事件之间的间隔由BIG参数Sub_Interval指定。

对于连接的等时组,BIG中BIS事件的调度可能是顺序的或交错的。

BIG事件可能包含一个控制子事件,该子事件始终安排为BIG的最后一个子事件。

请注意,在每个子事件中都会更改通道。

图28展示了BIG和BIS事件以及按顺序调度的子事件的示例。请注意,在BIG事件#1的末尾传输了一个BIG控制子事件(标记为Tc)。

ble系统知识介绍(较为完整,持续更新中)

5.7.4.3.4 处理同步(Processing Synchronization)

在BIG中,跨广播等时流数据的同步处理以类似于连接等时通信所使用的方法实现。接收器具有关于BIG及其总体参数的信息,并知道他们选择了哪个或哪些流来接收。 BIG的定时参数适用于所有流。使用整个BIG_Sync_Delay值和BIS_Spacing参数,接收器能够计算在处理接收到的数据之前需要等多长时间,使其与其他流同步。

5.7.4.3.5 BIS流创建(BIS Stream Creation)

为了能够接收广播在BIS中的数据包并同时呈现或处理这些数据包的内容(例如音频、图像、视频),设备必须首先发现定义BIG的参数,例如它包含的流数量、各个流之间的事件和子事件之间的时间间隔以及协商计算定时锚点所需的时间偏移信息。为支持此功能,广播者使用定期广告以传达所需的参数。称为BIGInfo的复合字段在ACAD(附加控制器广告数据)字段内广播在AUX_SYNC_IND PDU中,并包含所需的数据。

接收BIGInfo的方式有两种:一是通过定义的过程直接与定期广告列车同步(请参见5.7.3.1基础知识),接收AUX_SYNC_IND PDU并从其中提取BIGInfo。二是将扫描和与定期广告列车同步的行为委托给另一个设备,通常是具有更大功率资源的设备。在获取BIGInfo之后,被委托进行扫描的设备随后使用称为周期广告同步转移(PAST)的过程,通过更高效的ACL连接将此信息传递给希望接收广播等时流的设备。

5.7.4.3.6 BIG加密(BIG Encryption)

BIG可以加密,这不需要接收其BISes的设备与发射设备配对。相反,必须分发用于导出加密密钥的Broadcast Code参数。可以通过带外方式或按照更高级别配置文件中描述的过程来执行此操作。

5.7.4.4 重传和可靠性(Retransmissions and Reliability)

可以通过在BIS或CIS流的子事件连续序列中重传相同数据包来增强可靠性。对于BIS,重传是无条件的,而对于CIS,则发生在Peripheral未确认传输后。

因为在BIS的情况下,不需要预留插槽以供Peripheral响应(就像在CIS的情况下一样),所以在给定数量的空中时间内安排两倍于CIS的子事件进行传输,因此存在更大机会进行增强可靠性的重传。

由于它们占据不同的子事件,所以重传会在不同的通道上传输,并且所选的通道必须至少与上一个传输距离6 MHz,以缓解因特定通道干扰而可能导致数据包丢失的问题。

5.7.4.5 LE音频

LE同步通信主要是为音频产品和系统设计的。它提供了从源传递到多个接收器的音频以进行适当同步回放的方式。

6. 等时适应层

6.1基本知识

等时适应层(ISOAL)的目的主要是解决一个潜在的问题,这个问题可能会影响涉及音频设备的连接和广播等时通信。它可以在等时通信的其他用途中找到应用。Nick Hunn的书介绍蓝牙LE音频的第5.2章很好地涵盖了这个主题,建议阅读。

6.1.1音频采样

数字音频的工作原理是对模拟音频信号进行采样,并对采样的音频应用编解码器来压缩和处理数字采样数据,然后存储或在蓝牙LE音频的情况下传输它。在读取或接收编码的数字音频数据时,该过程与用于解码数据的编解码器相反,产生一系列数字样本,然后用于(近似)重建原始模拟音频。图30说明了采样、编码和传输音频信号所涉及的步骤,以及接收编码音频数据、解码并最终呈现音频数据所涉及的相反步骤。

6. 等时适应层

6.1基本知识

等时适应层(ISOAL)的目的主要是解决一个潜在的问题,这个问题可能会影响涉及音频设备的连接和广播等时通信。它可以在等时通信的其他用途中找到应用。Nick Hunn的书介绍蓝牙LE音频的第5.2章很好地涵盖了这个主题,建议阅读。

6.1.1音频采样

数字音频的工作原理是对模拟音频信号进行采样,并对采样的音频应用编解码器来压缩和处理数字采样数据,然后存储或在蓝牙LE音频的情况下传输它。在读取或接收编码的数字音频数据时,该过程与用于解码数据的编解码器相反,产生一系列数字样本,然后用于(近似)重建原始模拟音频。图30说明了采样、编码和传输音频信号所涉及的步骤,以及接收编码音频数据、解码并最终呈现音频数据所涉及的相反步骤。

ble系统知识介绍(较为完整,持续更新中)

音频编解码器的关键目标之一是减少音频数据的大小,以便它可以有效地通过有限(和宝贵的!)带宽的链接传输。采样包括以一定的间隔测量和记录信号的幅度。记录样本的频率称为采样率。图31中的竖线表示连续可变音频信号的样本,用曲线表示。这一系列的采样产生了原始模拟信号的近似表示。采样频率越高

(例如,采样率越高)近似值越接近原始音频,在反向过程中重新创建原始音频,结果和感知质量就越好。

采样的另一个维度是位深度。采样时信号的幅度需要用整数值表示。一种方法是将可能的幅度值范围划分为256个离散的幅度带,并用0到255之间的数字表示每个幅度带。在该方案中,单个采样只需要一个字节(8位)来记录采样幅度值所在的频带,因此位深度称为8位。将可能的振幅范围划分为更离散的频带,为表示样本提供了更细粒度的系统价值和潜在的更高质量的结果。例如,24位的位深允许用0到16,777,215范围内的整数表示可能的幅度值范围。然而,每个采样需要3个字节,因此通过增加位深度进行采样产生的数据量是原来的三倍。

数字采样可以产生大量的数据。考虑一首三分钟的歌曲,以44.1 kHz (CD质量)采样,位深度为24。如果我们做数学计算,我们发现以数字形式近似表示整首歌所需的原始采样数据量接近24兆字节。如果我们想要做的只是将数据存储在计算机的4tb硬盘驱动器上,这不是我们担心的问题,但当通过有限带宽的通信链路传输数据时,这是一个问题。这就是编解码器的用武之地。

ble系统知识介绍(较为完整,持续更新中)

6.1.2 Codecs and Frames(编解码器和帧)

蓝牙LE音频使用的LC3这样的编解码器可能会将原始数字样本数据压缩到原始大小的25%以下(但请注意,实际结果严重依赖于原始音频内容)。这是一笔可观的节省。

编解码器通常通过识别和利用在一系列连续样本中发现的模式来工作。举一个非常简单的例子来说明这一原则,如果数据集包含连续的100个样本值序列,这些样本值都具有相同的值,比如50,那么假设位深度为8位,编解码器可能将其表示为包含[100,50]的两个字节,而不是原始的包含单个样本列表的100个字节序列[50,50,50…,50]。显然,要使编解码器工作,它需要分析和编码整个系列的样本,而不是一次处理一个样本(在单个样本中找不到很多模式!)。编解码器一次分析的样本集合称为帧。帧有固定的持续时间,通常以毫秒为单位测量,并包含由采样率决定的采样数。

例如,如果采样率为44.1 KHz,则10ms帧包含4410个采样。不同的音频产品可能使用不同的帧持续时间。10ms和7.5ms是常见的。当一个设备产生具有一帧持续时间的音频(源),而另一个设备消耗它(接收器),但使用不同的帧持续时间,那么就需要解决一个问题。这就是ISOAL的用武之地。

6.2 Framed vs Unframed(框架与非框架)

当设备使用等时通信时,发送设备使用的帧持续时间与接收装置不需要相同。这会导致两种可能的情况:

  1. 第一个设备使用的帧持续时间是第二个设备使用的帧持续时间的精确倍数另一个装置。

  2. 第一个设备使用的帧持续时间不是另一个设备使用的帧持续时间的精确倍数。

在第一种情况下,大帧持续时间和小帧持续时间之间的关系很简单,两者之间的数据转换是一个简单的操作。在一个或多个所需的链路层pdu的有效负载中发送的数据被称为非帧,并且不包括额外的数据来支持两种需求之间的帧持续时间的适应。

在第二种情况下,链路层pdu可能包含较大负载的部分以及短报头字段,这些字段指示该部分是帧的开始、延续还是帧的结束。这样格式化的数据被称为有框架的。

连接同步pdu和广播同步pdu(由链路层定义)都包含一个名为LLID的字段。LLID表示链路层PDU的有效载荷包含帧或非帧数据。ISOAL对从链路层接收到的数据应用不同的处理,这取决于数据是否成帧。同样,是否需要分帧也会影响数据的ISOAL处理,它在上层sdu中接收数据,并将数据传递到链路层,在链路层ISO pdu中传输。

6.3 Fragmentation and Recombination(破碎与重组)

如果数据是非帧的,那么重组将从包含在一个或多个链路层pdu负载中的一系列一个或多个片段中创建单个业务数据单元(SDU)。然后,ISOAL将SDU传递给上层。如图32所示。

ble系统知识介绍(较为完整,持续更新中)

当需要将上层pdu拆分为更小的负载在链路层pdu中传输,且不需要分帧时,这个过程称为分片。如图33所示。

ble系统知识介绍(较为完整,持续更新中)

非帧pdu有一个报头,其中包括一些字段,这些字段表明它后面的数据是一个SDU的开始,前一个SDU的延续或这个SDU的结束。pdu仅包含未帧SDU的单个片段。

6.4 分段和重装(Segmentation and Reassembly)

如果数据是框架的,那么重组将从包含在一个或多个链路层pdu的有效负载中的一系列一个或多个段中创建单个业务数据单元(SDU)。然后,ISOAL将SDU传递给上层。如图34所示。

ble系统知识介绍(较为完整,持续更新中)

当需要将上层pdu分成更小的有效负载在链路层pdu中传输,并且需要分帧时,这个过程称为分段。如图35所示。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ORXG12it-1686570583328)(null)]

帧pdu中的段有一个报头,其中包含字段,指示其后的数据是SDU的开始,前一个SDU的延续或该SDU的结束,以及定时偏移信息。pdu可能包含一个帧SDU的多个片段。

7. 主机控制器接口层(The Host Controller Interface)

7.1基本知识

主机控制器接口(HCI)定义了一个标准化的接口,通过该接口,主机可以向控制器发出命令,控制器可以与主机通信。该规范分为几个部分,第一部分仅从功能方面定义接口,不考虑具体的实现机制,其他部分定义在使用四种可能的物理传输方式之一时如何实现HCl。蓝牙LE和蓝牙BR/EDR都使用HCl。

7.2 HCI功能规格

功能接口是根据命令和事件定义的。这些本质上是可以在主机和控制器之间交换的消息。命令由主机发送到控制器和从控制器到主机的事件。事件可以是对命令的响应,也可以是由未请求的消息发送的。参见图36。

ble系统知识介绍(较为完整,持续更新中)

7.3 HCI 传输

四种HCI传输类型是:

  1. UART

  2. USB

3.安全数码(SD)

  1. 三线UART

7.3.1 UART传输

当主机和控制器在同一印刷电路板上使用UART连接时,HCI UART传输可用于使用UART实现HCl通信。定义了基于5种报文类型的协议。这些是HCI命令数据包,HCI ACL数据包,HCI同步数据包,HCI事件数据包和HCI ISO数据包。明确RS232配置要求。总之,UART传输使用8个数据位,无奇偶校验,1个停止位和RTS/CTS流控制。

7.3.2 USB传输

USB可以作为HCI传输的两种方式使用。蓝牙控制器可以内置在USB dongle中。另一种方式是将USB集成在产品内部,以连接主机和控制器实现。

USB标准定义了可以发送或接收数据的称为端点的缓冲区。HCI USB传输规范指定了预期存在的端点及其所需或建议的属性。

7.3.3 安全数字

HCI SD传输的一种协议由安全数字协会(SDA)定义和拥有。蓝牙核心规范关于HCI SD传输的部分主要由SDA拥有的外部规范的引用以及通信架构的概述组成。

7.3.4 三线UART

三线UART HCI传输规范描述了一种在两个三线连接的UART之间通信HCI命令和事件的架构和协议。它涉及可靠性、数据完整性、链路建立、电源管理和硬件配置。

当然,我可以帮助您进行翻译。请提供您想要翻译的文本和目标语言。

7.4 HCI示例

以下是HCI功能接口在实际应用中的一些示例。

7.4.1 无连接AoA/AoD

图37展示了主机通过HCI命令和事件交换,为使用AoA或AoD技术的包传输准备控制器配置的过程中,HCI功能接口的应用。

ble系统知识介绍(较为完整,持续更新中)

7.4.2 BLE路径丢失监控

LE路径损耗监测是LE功率控制功能的一部分。希望管理连接的对等设备使用的传输功率以使其保持在接收器的最佳功率范围内的设备可以使用此功能。

图38显示了主机发送配置和启用LE路径丢失监视所需的HCI命令。开启监控后,控制器会向主机发送包含路径丢失数据的LE Path Loss Threshold事件。

ble系统知识介绍(较为完整,持续更新中)

7.4.3主动扫描

外围设备支持主动扫描,这些外设利用传统广告,需要通信的数据比单个广告包中包含的数据更多。有关此主题的更多信息,请参见13.3 Discovery小节。图39显示了设备(设备a)中的主机组件配置其控制器执行活动扫描,然后在单独的命令中,通过启用扫描来启动扫描。当设备A的链路层从另一台设备接收到可扫描的广告报文(如ADV_IND)时,由于设备A已经配置为主动扫描,所以它会发送一个scan_req PDU并从另一台设备接收一个SCAN_RSP PDU作为响应。原始广告包的内容和扫描响应然后通过一系列HCI LE广告报告事件传递到设备A的主机。

ble系统知识介绍(较为完整,持续更新中)

8. 逻辑链路控制与适配协议

8.1基本知识

逻辑链路控制与自适应协议(L2CAP)负责协议多路复用、流量控制、业务数据单元(sdu)的分段和重组。L2CAP使用通道的概念来分离在栈层之间传递的数据包序列。固定频道不需要设置,立即可用,并与特定的更高层协议。通道也可以动态创建并与协议相关联通过指定的PSM (Protocol Service Multiplexer)值。图40展示了主要的L2CAP函数。

ble系统知识介绍(较为完整,持续更新中)

8.2 L2CAP和协议复用

在L2CAP之上的层使用不同的协议,如属性协议(ATT)和安全管理协议(SMP)。L2CAP协议多路复用确保将sdu从堆栈向上传递到适当的层进行处理。当L2CAP通道处理属性协议时,它要么使用为ATT保留的固定通道(在这种情况下称为充当未增强的ATT承载者),要么使用一系列一个或多个动态通道(每个通道充当增强的ATT承载者)。未增强的ATT承载器支持按顺序执行的ATT事务,每次执行一个。增强的ATT承载器支持并行的ATT事务,这些事务在并行的L2CAP通道中按顺序执行。

有关这方面的详细信息,请参阅第11章节属性协议。

8.3 L2CAP和流控

流量控制关注的是确保堆栈中的一层产生数据包的速率不超过同一堆栈中的另一层或远程设备上处理这些数据包的速率。如果没有流量控制,就有出现缓冲区溢出等问题的风险。基于信用的流量控制是众多可能的流量控制方法之一。大体上,它的工作原理如下:

  • 发送设备知道接收设备的容量,它可以在不丢失数据的情况下处理pdu的数量(例如,通过其缓冲区溢出)。它通过配置或在数据传输开始之前通过两个设备之间的交换获取此容量信息。

  • 发射机设置一个计数器来限制接收机的容量。每次发送器发送一个PDU,计数器就减1。当计数器值达到零时,发送方知道接收方已满负荷,因此在接收方处理其积压时暂时停止发送进一步的pdu。

  • 当接收端从它的缓冲区中读取并处理一个或多个pdu后,它将相应数量的积分返回给发送端,发送端使用它来增加它的计数器。当计数器处于非零值时,发送器可以继续发送更多的pdu。

L2CAP定义了几种操作模式,主要与流量控制有关。

例如,在L2CAP未增强的ATT承载上的ATT使用基本L2CAP模式,该模式不提供流量控制。这使得ATT不可靠,应用程序必须适应传输的ATT pdu可能被接收设备丢失的可能性。对于未确认的PDU(如通知),由于链路层确认,发送设备将知道PDU是否被远端设备的堆栈接收,但无法知道PDU是否成功地发送到堆栈顶部的接收应用程序。

L2CAP增强型ATT承载使用增强型基于信用的流量控制模式,该模式提供流量控制。因此,EATT可以被认为是可靠的。

8.4 L2CAP分段和重组

L2CAP以上和以下的层都受最大传输单元(Maximum Transmission Unit, MTU)大小的限制,该大小规定了该层创建的PDU类型所允许的最大大小。例如,ATT_MTU参数定义了ATT PDU的最大大小。

L2CAP本身和它上面或下面的层在堆栈中可能有不同的MTU大小,因此,可能有必要将一些pdu / sdu分成一系列相邻层可以处理的较小的部分,或者相反,将一系列相关的较小的部分重新组装成完整的pdu / sdu。这些由L2CAP应用于上层的过程称为分割和重组,而与L2CAP及其与下层的关系相关的等效过程称为碎片和重组。

9. 属性协议(ATT)

9.1基本知识

属性协议(ATT)由两个设备使用,一个充当客户端角色,另一个充当服务器角色。服务器公开一系列称为属性的复合数据项。属性由服务器组织在称为属性表的索引列表中。

每个属性包含一个句柄、一个通用唯一标识符(UUID)、一个值和一组权限。

  • 句柄是一个唯一的索引值,ATT客户端可以使用它引用属性表中的特定条目。

  • UUID标识属性的类型。

  • 权限字段是一组标志,指示是否允许读、写或两种形式的访问,以及允许访问必须满足的任何其他安全条件。Bluetooth SIG学习指南了解Bluetooth LE中的安全性有关于属性权限的更多信息。

  • 属性值字段是包含属性值的字节数组。从数据类型和语义两方面解释字节数组是栈的高层所关心的问题。

通用属性概要(GATT)定义了属性如何表示称为服务、特征和描述符的高级构造。通常,需要连续句柄值范围中的一组属性来表示诸如此类的更复杂的类型,因此,属性协议支持处理由句柄值范围标识的属性组。参见第12节。有关这方面的更多信息,请参阅通用属性配置文件。

ATT客户端使用ATT来发现ATT服务器中属性表的详细信息,包括感兴趣的属性或属性类型的句柄值。当句柄值已知时,它们可以与某些PDU类型一起使用,以识别表中的特定属性,然后对其进行操作。例如,ATT_READ_BY_GROUP_TYPE_REQ PDU可用于查找作为主服务定义一部分的所有属性的句柄和UUID。一种更简短的表达方式是,att_read_by_group_type_req PDU可以用来查找属性表定义的所有GATT主服务。

当使用支持发现操作的pdu(如ATT_READ_BY_GROUP_TYPE_REQ)时,指定一个句柄范围,并指示要搜索的属性表中条目的子集(这可能是整个表)和要查找的属性类型。图41演示了这个过程,其中搜索了所有主要服务,响应指示了包含与所发现的主要服务相关的属性的句柄值范围。

ble系统知识介绍(较为完整,持续更新中)

ATT是连接的蓝牙LE设备中的应用程序相互交互的主要机制之一,使用协议定义的pdu和更高级别规范(如通用属性配置文件(GATT))中定义的过程。

定义了ATT的两种变体,基本ATT和较新的增强属性协议(EATT)。蓝牙LE或蓝牙BR/EDR都可以使用ATT。本文档只考虑与蓝牙LE一起使用的ATT。

9.2 ATT PDUS

PDU属性协议定义了31个不同的pdu,每个pdu都基于六个广泛方法中的一个。

9.2.1命令

ATT命令PDU由客户端发送到服务器端,被调用的服务器端没有响应。命令的一个示例是图42中所示的ATT_WRITE_CMD。

ble系统知识介绍(较为完整,持续更新中)

9.2.2 请求与返回

ATT请求PDU由客户端发送给服务器。服务器应该在30秒内回复一个相应类型的响应PDU或一个错误响应PDU (ATT_ERROR_RSP)。未能在30秒内响应将构成超时。

请求/响应PDU配对的一个例子是ATT_WRITE_REQ和ATT_WRITE_RSP PDU

ble系统知识介绍(较为完整,持续更新中)

通知是由服务器发送给客户机的类型为ATT_HANDLE_VALUE_NTF的未经请求的pdu。没有定义应答PDU。参见图44。

ble系统知识介绍(较为完整,持续更新中)

9.2.3 指示和确认

ATT指示PDU由服务器发送给客户端。客户端应在30秒内回复一个相应类型的确认PDU或一个错误响应PDU (ATT_ERROR_RSP)。未能在30秒内响应将构成超时。

一个指示/确认PDU配对的例子是如图45所示的ATT_HANDLE_VALUE_IND和att_handle_value_cfm PDU。

ble系统知识介绍(较为完整,持续更新中)

9.2.4 PDU格式

所有ATT PDU都具有相同的结构,由标识PDU类型的操作码、一组参数和可选的认证签名组成。注意,当属性协议在加密链路上运行时,签名字段很少使用,并且是冗余的,因为链路层的所有加密数据包都包含认证数据。

9.2.5 最大传输单元

ATT PDU的最大长度取决于已经建立的MTU (maximum Transmission Unit)值。根据用于ATT的承载设备,可以使用两种机制中的一种来建立MTU。

9.3 交易

ATT定义了事务的概念。从客户端请求PDU,期望服务器在30秒内返回响应PDU。服务器发送的指示需要客户端在30秒内回复一个确认PDU。每个请求/响应对或指示/确认对构成一个事务。如果事务超时,则将其视为失败,并且不能使用当前承载发送任何类型的pdu。ATT使用顺序事务模型。这意味着,如果一个ATT事务已经开始,在当前事务完成之前,同一个承载实例不能再处理ATT pdu。当从远程设备接收到预期的响应或确认PDU,或等待30秒后事务超时,则认为事务已经完成。

9.4持有者

ATT由下面的L2CAP层以两种方式中的一种处理,每一种都被称为承载。两个ATT持票人分别是未增强ATT持票人和增强ATT持票人。使用哪个承载关系到ATT的使用方式,在某些情况下还关系到协议的可靠性。通用属性配置文件处理ATT的使用方式和状态,例如:

未增强的ATT承载

使用固定的L2CAP通道,因此可能只有一个承载实例。

  • 不管应用层有多少客户端在使用ATT,事务都是严格顺序的。这意味着一个应用程序发起的事务可能会延迟另一个应用程序希望启动的事务。

  • 可以交换ATT_EXCHANGE_MTU_REQ和ATT_EXCHANGE_MTU_RSP pdu,以影响要在非增强的ATT承载上使用的ATT MTU的选择。

  • 由于缓冲区溢出等问题而无法处理的客户端收到的任何通知都将被丢弃。因此,ATT_HANDLE_VALUE_NTF PDU在非增强的ATT承载上使用时被认为是不可靠的。

  • 支持一些PDU类型,如ATT_MULTIPLE_HANDLE_VALUE_NTF, att_read_multiple_variable_req和ATT_READ_MULTIPLE_VARIABLE_RSP是可选的未增强的 ATT 持有者。

  • 支持Unenhanced ATT承载的L2CAP通道可以是未加密的,也可以是加密的。

ble系统知识介绍(较为完整,持续更新中)

  • 使用动态L2CAP通道和多个通道,因此允许使用多个承载实例。

  • 交易按顺序处理,但以每个持票人为基础。因此,在堆栈中,并行事务,每个事务由单独的增强型ATT承载实例处理是可能的。这有明显的好处,避免了一个应用程序对ATT的使用被另一个应用程序阻止的可能性。

  • ATT MTU设置为L2CAP层自动使用的MTU值,ATT_EXCHANGE_MTU_REQ和ATT_EXCHANGE_MTU_RSP pdu不允许通过增强的ATT承载。

  • L2CAP流量控制方法称为增强型基于信用的流量控制模式,与增强型ATT承载一起使用。这样做的效果是,在使用非增强的ATT承载时不可靠的pdu在使用增强的ATT承载时可以被视为可靠的。

  • 当使用增强型ATT承载时,必须支持某些pdu,如ATT_MULTIPLE_HANDLE_VALUE_NTF、att_read_multiple_variable_req和ATT_READ_MULTIPLE_VARIABLE_RSP。

  • 支持增强型ATT承载的L2CAP通道必须是加密通道。

9.5 发现对EATT的支持

定义的通用属性配置文件服务允许客户端确定连接的服务器是否支持EATT,反过来,允许客户端通知服务器它支持EATT。

如果服务器支持EATT,则必须将称为服务器支持的特性包含在通用属性配置文件服务中。该特征值的第一个八位的0位为1表示支持EATT。

GATT/ATT客户端可以通过读取该特性来确定服务器是否支持EATT。客户端支持的功能特征值由表示支持或不支持某些功能的位组成。比特1表示客户端是否支持增强型ATT承载。第2位表示是否支持ATT_MULTIPLE_HANDLE_VALUE_NTF PDU。客户端必须为这个特性写一个适当的值,以通知服务器它支持的特性。

ble系统知识介绍(较为完整,持续更新中)

10. 通用属性配置文件(GATT)

10.1 基本知识

通用属性概要文件(GATT)根据属性表中包含的属性定义高级数据类型(参见11)。属性协议)。这些数据类型称为服务、特征和描述符。它还定义了一系列通过属性协议(Attribute Protocol, ATT)使用这些数据类型的过程。应用程序通常使用映射到这些过程的平台api。

服务是一种分组机制,它提供了一个上下文,在这个上下文中可以使用它们包含的、具有已定义类型的特征。服务通常对应于设备的主要特征或功能。

特征是国家数据的单个项目,具有类型、关联值和一组属性,这些属性表明数据如何在关贸总协定相关程序中使用。例如,可以定义连接的对端设备可以读取特定特性的值,但不能写入该值。

特征属于一个服务。相同的特征类型可以是多个服务的成员,并且基于这些服务提供的不同上下文,使用特征的规则可能会有所不同。服务规范将提供这些细节。

描述符属于某些特征,可以包含元数据,如特征的文本描述,或者可以提供控制特征行为的某种方法。特征有零个或多个附加的描述符。例如,GATT定义了一个称为特征值通知的操作,该操作涉及一个设备向连接的对等端异步发送包含特征值的ATT PDU,而不需要另一个设备的响应。如果一个特征支持通知,通常会在特征值变化时或由计时器控制的周期性地发送通知。但是只有当对等设备请求通知时才会发送通知,这是通过在特定类型的描述符中设置一个标记来实现的,该描述符称为客户端特征配置描述符,如果支持通知,则特征必须具有该描述符。

服务、特征和描述符的层次结构如图47所示。

ble系统知识介绍(较为完整,持续更新中)

GATT协定定义了两个角色。GATT客户端向GATT服务器发送ATT命令和请求。GATT服务器接受和处理从GATT客户端收到的命令和请求,并向GATT客户端发送ATT通知、指示和响应。

所有GATT服务器都必须提供两项特殊服务。它们是通用访问服务和通用属性服务。

10.2 蓝牙SIG VS 自定义

一些服务、特征和描述符是由蓝牙SIG定义的,并且具有标识其类型的16位UUID值。每种定义类型的蓝牙SIG列表可从https://www.bluetooth.com/specifications/assigned-numbers获得。实现者可以购买16位uid和其他类型的分配号码,如https://support.bluetooth.com/hc/en-us/ articles/360062030092- requestingassigned - numbers所述。

实现者可以定义自定义服务、特征和描述符。自定义服务、特征和描述符可以由实现者分配的128位UUID值标识,也可以由实现者从蓝牙SIG购买16位UUID值。16位UUID也有一个等价的128位值,格式为0000XXXx-0000-1000-800000805F9B34FB,其中XXXX是16位UUID值。实现者不能在这个范围内使用UUID,除非UUID是从蓝牙SIG购买的。

GATT服务器可以只包含蓝牙SIG定义的服务、特征和描述符(属性),也可以混合包含蓝牙SIG定义的属性和自定义属性。

10.3 程序

GATT程序包括服务发现、特征发现、描述符发现、读写特征值以及通知和指示特征值等。GATT协定规范在其程序和这些程序必须使用的基础ATT协议之间提供了清晰的映射。

10.4 例子

10.4.1 蓝牙SIG仅定义属性

图48显示了一组具有其特征的服务的示例。一个特征有一个相关的描述符。本例中的每个属性都是由Bluetooth SIG定义的。

ble系统知识介绍(较为完整,持续更新中)

显示的服务是实现标准接近配置文件的设备可能具有的服务(立即警报和TX电源服务不是强制性的)。注意警报级别特征是如何出现两次的,一次在链路丢失服务中,一次在立即警报服务中。每种情况下的UUID都是相同的。这就是确定该特征为警戒级别特征的原因。但是,将特征分组在其中的服务提供了不同的上下文,并且与警报级别特征相关的规则和行为在两个服务之间是不同的。

服务更改特征具有关联的客户端特征配置描述符,因为该特征支持通知。任何支持通知或指示的特征都必须有一个客户端特征配置描述符,因为它的值(客户端可以写入的值)控制当前是否启用通知或指示。

10.4.2 蓝牙SIG与自定义属性混合

图49显示了一个GATT服务器,它混合了蓝牙SIG定义的GATT属性和包含单个自定义特性的单个自定义服务。该自定义服务称为接近监控服务,UUID类型标识符值为Ox3E099910-293F-11E4-93BDAFDOFE6D1DFD。它的特性称为Client Proximity特性,它有一个UUID值为0x3E099911-293F-11E4-93BD-AFD0FE6D1DFD。注意这个服务和特性都是在项目工作中用到的,在教育开发者资源中。看到16。有关更多详细信息的其他参考资料。
ble系统知识介绍(较为完整,持续更新中)

11. 通用访问配置文件

11.1 基本知识

蓝牙核心规范的通用访问配置文件(GAP)部分定义了与设备发现和在两个设备之间建立连接有关的过程。如何执行数据的无连接通信,如何使用周期性广告(见7.7.3 PADVB - LE周期性广告广播)以及如何设置同步通信(见7.7.4 LE BIS和LE CIS -同步通信)也是GAP涵盖的主题。

此外,核心规范的这一部分还涵盖了一些关键的用户界面标准和蓝牙LE安全性的某些方面。

广告包(广告)的传输和通过扫描的接收是GAP运作的核心。有许多不同的广告和扫描数据包类型,它们是由链路层定义的。需要注意的是,载荷字段称为AdvData,并不是在所有PDU类型中都存在该字段。当它存在时,它所包含的数据被编码为一系列一个或多个长度/标记/值结构,称为AD类型。AD类型在CSS (Core Specification Supplement)文档中定义,该文档可从bluetooth.com的规格页面获得。

GAP与蓝牙LE和蓝牙BR/EDR都有相关性。在本节的其余部分中,只讨论适用于蓝牙LE的GAP。此外,应该注意的是,虽然像广告和扫描这样的活动与GAP具有中心相关性,但这些过程实际上是由链路层执行的,所涉及的PDU类型也是如此。

11.2 角色

GAP定义了四个设备角色,见表7,其中列举并解释了这四种角色

ble系统知识介绍(较为完整,持续更新中)

11.3 发现

广播器或外围设备要么处于不可发现模式,要么处于GAP定义的两种可发现模式之一。当以非可发现模式发布时,传输的数据包在空中是可见的(这不是一个安全特性),但是执行通用可发现过程或有限可发现过程的扫描设备将忽略这些数据包。

可发现设备可以处于一般可发现模式或有限可发现模式。当处于一般可发现模式时,设备可被发现的时间不确定,而在有限可发现模式下,设备可被发现的时间最多为三分钟。

发现设备能够通过检查AdvData字段中称为Flags的AD类型来识别广告设备所处的可发现模式。有限可发现模式通常用于优先显示用户最近接触过的设备,可能是按下按钮或简单地拿起并移动设备。

当中心设备或观察者设备试图发现其他设备时,它可以使用被动扫描或主动扫描。两者中的哪一种被允许取决于设备是试图以一般可发现模式还是有限可发现模式发现设备。

被动扫描是指接收广告pdu而不发送任何扫描pdu。主动扫描包括接收广告pdu,并通过发送扫描pdu请求更多信息作为响应。各种PDU类型由链路层定义,在7.7.2 ADVB - LE广告广播中进行了总结。

蓝牙核心规范指出,有些设备只使用遗留广告,而其他设备可能使用扩展广告或将两种形式的广告交叉使用。建议执行其中一种发现程序的设备对两种类型的广告进行交错扫描。还建议对设备支持的所有物理设备进行扫描。

图50显示了GAP发现模式以及其他相关变量。

11.4连接方式

广告设备可以通过所使用的PDU(遗留广告)或AdvMode字段的值(扩展广告)来指示自己是否可以被连接。

图50显示了GAP连接模式以及其他相关变量。

一个设备可以通过执行GAP定义的一个连接相关过程来请求与另一个设备的连接。这通常包括发送CONNECT_IND PDU(传统通告)或AUX_CONNEXT_REQ PDU(扩展通告),作为对接收到的允许这种情况的PDU的响应。链路层定义了通告和连接请求PDU类型,以及连接请求可以发送响应的PDU类型的规则。请参见7.7.2.2.3遗留广告和关联PDU类型和7.7.2.3.5扩展广告和关联PDU类型。

11.5 定向 vs 无定向

GAP使用的广告可能是无定向的,这意味着pdu适用于接收它们的任何观察者或中心设备;也可能是定向的,这意味着只有特定设备应该处理此类pdu。定向广告中涉及的pdu包括TargetA字段,其中包含预期接收设备的蓝牙地址。在非定向广告中,TargetA字段不存在。图50显示了GAP发现和连接模式上下文中的定向和非定向广告。

ble系统知识介绍(较为完整,持续更新中)

注意,AD类型标志出现在主广告通道接收的遗留广告数据包中。然而,当使用扩展广告时,主通道上接收到的ADV EXT_IND pdu中不存在AdvData字段。当Flags与扩展广告一起使用时,它出现在辅助通道上的辅助AUX_EXT_IND pdu中。

11.6 可扫描与不可扫描

某些广告PDU类型被称为可扫描的。这意味着允许接收这样的PDU的设备以适当类型的扫描请求PDU响应,以请求更多的广告数据。广告pdu由链路层定义。详细信息请参见7.7.2.2.3遗留广告和关联PDU类型和7.7.2.3.5扩展广告和关联PDU类型。

11.7 GAP与LE安全

GAP规范定义了许多安全术语、模式和过程。一般来说,GAP安全过程涉及堆栈的其他层,如安全管理器协议(SMP)和链路层,但使用这些层完成某些结果的高级过程在蓝牙核心规范的卷3部分C(通用访问配置文件)中定义,详细信息应查阅。

11.8 定期广告

周期性广告由链路层执行(参见7.7.3 PADVB- LE周期性广告广播),但是GAP规定了广播者进入周期性广告模式和观察者与周期性广告列车同步的过程。此外,在GAP中还定义了周期性广告同步传输(PAST)过程,该过程允许观察者从广播者获得周期性广告同步参数,并通过ACL连接将它们传递给另一个设备。

11.9 同步广播

使用广播等时流和连接等时流的等时通信由链路层执行(参见7.7.4 LE BIS和LE CIS—等时通信),但是GAP规定了广播者和观察者必须遵循的过程来参与这种形式的通信。

ble系统知识介绍(较为完整,持续更新中)

12. 蓝牙LE的安全性

安全是一个关键的话题,需要仔细考虑和理解。蓝牙LE提供了一系列安全功能和特性,其中大多数是可选的。您应该将其视为包含安全工具的工具箱,使用这些工具可以解决特定的安全问题并满足特定的安全需求。确定了产品的安全性需求后,满足这些需求是产品团队的责任。在适当的情况下,这应该通过使用选定的蓝牙LE安全功能来实现。

考虑到这个主题的重要性,蓝牙SIG已经创建了一个专门针对这个主题的教育资源,这里不再重复其内容。参考第16节。有关更多信息的其他参考资料。

13. 其他资源

本节列出了支持从不同角度学习蓝牙LE的其他资源。

ble系统知识介绍(较为完整,持续更新中)
ble系统知识介绍(较为完整,持续更新中)
ble系统知识介绍(较为完整,持续更新中)文章来源地址https://www.toymoban.com/news/detail-475008.html

到了这里,关于ble系统知识介绍(较为完整,持续更新中)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • C/C++语言学习路线: 嵌入式开发、底层软件、操作系统方向(持续更新)

    1.1 视频教程点到为止 1.2 炫技视频看看就行 1.3 编程游戏不玩也罢 有些游戏的主题任务就是编程,游戏和实际应用环境有一定差异(工具、操作流程),在初级阶段主要是熟悉实际场景,而且多数是通过前端语言进行游戏,对底层软件学习的帮助不大。 Coding Games: PHP、C、

    2024年04月28日
    浏览(80)
  • 前端知识汇编(持续更新中)

    详请- cookie、Web Storage 同: 保存在浏览器端 都有同源限制(cookie:与特定域绑定,不被其他域访问;sessionStorage:与会话绑定;localStorage:来自相同域,子域不行) 异: 所有cookie都会作为请求头部由浏览器发送给服务器(在浏览器与服务器之间来回传递);webStorage只存在浏

    2024年01月16日
    浏览(41)
  • Android Studio开发基础知识(持续更新中~)

    阅读本文需要有 Java 和 前端 的基础,本文是我学习Android时的笔记。 Info Key 复制行 Ctrl + D 删除行 Ctrl + Y 注释 Ctrl + / 注释2 Ctrl + Shift + / 撤销 Ctrl + Z 恢复 Ctrl + Shift + Z 显示结构 Ctrl + F12 格式化代码 Ctrl + Alt + L 打开设置 Ctrl + Alt + S 自动补全代码 Ctrl + Shift + Space 自动导包 Alt +

    2023年04月08日
    浏览(50)
  • 前端知识点、技巧、webpack、性能优化(持续更新~)

    可以把  图片转换成  base64  放在src里面   减少服务器请求  但是图片会稍微大一点点 以上的方法不需要一个一个自己转化 可以在webpack  进行 性能优化   (官网有详细描述)

    2024年03月10日
    浏览(46)
  • 后端常使用的中间件知识点--持续更新

    类型 难度 mysql mysql中SQL优化:多角度分析 包学包会,sql优化全过程,刨根分析 redis 多角度剖析redis数据结构及底层实现原理、应用场景 MQ 简单大体说明RabbitMQ的使用(简单版) mybatis 使用JDBC的批量插入百万数据要多少秒 一遍就会的,从0开始在springboot上使用Mybatis对数据库进

    2024年02月13日
    浏览(38)
  • 【Stable Diffusion】专栏介绍和文章索引(持续更新中)

    最近开始学习AIGC,对Stable Diffusion比较感兴趣,所以新建了这个专栏,来记录自己在使用和学习Stable Diffusion的一些方法、资料以及实验过程,也和大家一起分享这些经验和心得体会,一起学习进步。 专栏地址:Stable Diffusion 本专栏会分以下几部分介绍。 入门:主要是介绍SD的

    2024年04月11日
    浏览(42)
  • CTF-XXE(持续更新,欢迎分享更多相关知识点的题目)

    进来看到 然后一起看 Write 进来看到 一起看 write 反正是XXE 直接整 write 不整花里胡哨,解题在最下面 write 与博主不同,我通过下面的语句得到了三个地址,其中两个通过c段扫描可以直接出来flag。 flag出来了,输入平台却不对

    2024年02月11日
    浏览(43)
  • pyqt5控件自适应窗口知识点汇总(超详细讲解,持续更新中…)

    本文涉及:Windows操作系统,Python,PyQt5,Qt Designer,PyCharm 目录 一、自适应原理  二、基础布局示例 三、高级布局示例:布局嵌套布局 四、其它特殊控件自适应补充 1. tableWidget  2. 未完待续… 五、结语         自适应其实很简单,只要搞懂原理,你就能随心所欲地去布置你

    2024年02月02日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包