Bluetooth 蓝牙介绍(二):低功耗蓝牙BLE协议栈

蓝牙低功耗(Bluetooth Low Energy,或称Bluetooth LE、BLE,旧商标Bluetooth Smart)也称蓝牙低能耗、低功耗蓝牙,是蓝牙技术联盟设计和销售的一种个人局域网技术,旨在用于医疗保健、运动健身、信标、安防、家庭娱乐等领域的新兴应用。其适配经典蓝牙功能,但相较经典蓝牙,低功耗蓝牙旨在保持同等通信范围的同时显著降低功耗和成本。
在这里插入图片描述

Physical LAYER

“蓝牙低功耗”技术采用与“经典蓝牙”技术相同的工作频率(2.400 GHz-2.4835 GHz - ISM频带),但使用另一组信道。不同于经典蓝牙的79 1-MHz信道,蓝牙低功耗使用40 2-MHz信道。在一个信道内,数据使用高斯频移调制传输,类似经典蓝牙的基本速率方案;比特率1Mbit/s,最大发射功率10 mW。

中国境内遵守工业和信息技术部MIIT文件:MIIT regulation [2002]353规定, LE系统在2400-2483.5 MHz的2.4 GHz ISM频段中运行。这LE系统使用40个RF通道。这些RF通道中心频率为 2402 + k * 2 MHz,其中k = 0,...,3

详情参考手册:《 CORE_V5.2 - vol6.A: PHYSICAL LAYER SPECIFICATION》

Link LAYER

Link Layer可以在Physical Channel基础上收发数据,但Physical Layer仅仅提供了有限的40个Physical Channel,而BLE中参与通信的实体的数量,肯定不是这个数量级,Link Layer又如何解决Physical Channel的共享问题呢。

角色

首先我们先来看下LINK LAYER 的六种 STATES:

  • Standby State:待机状态中的链路层不发送或接收任何数据包,可以从任何其他状态输入待机状态。
  • Advertising State:广播态的链路层将传输物理通道广播数据包,并可能侦听和响应由这些物理通道广播数据包触发的响应。
  • Scanning State:处于扫描态的链路层将侦听来自正在广播的设备的物理通道广播数据包。
  • Initiating State:处于启动状态的链路层将侦听来自特定设备的物理通道广播数据包,并响应这些数据包以启动与另一个设备的连接。 Initiating状态和Scanning状态类似,不过是一种特殊的接收状态,由Standby状态进入,只能接收Advertiser广播的connectable的数据,并在接收到数据后,发送连接请求,以便和Advertiser建立连接。当连接成功后,Initiater和对应的Advertiser都会切换到Connection状态。
  • Connection State:可以从Initiating State或者Advertising State进入连接态。
    进入连接态后,将定义两个角色——Master Role 和 Slave Role。由Initiating State进入连接态的角色被称为Master Role,由Advertising State进入连接态的角色被称为Slave Role。
  • Isochronous Broadcasting State:可以通过广播通道发送BIS(Broadcast Isochronous Stream) 数据报文,由Standby状态进入。想向一定区域内其它设备广播同步数据流(比如音频数据流)的设备需要处于Isochronous Broadcasting状态,处于该状态的设备称为Isochronous Broadcaster。处于Isochronous Broadcasting状态的链路层状态机应发送由一个或多个BIS 组成的BIG(Broadcast Isochronous Group),每个BIG最多包含31个BIS,每个BIS承载一个单独的同步数据流。传输第一个BIS 数据报文后链路层应通知主机,若停止同步广播则回到Standby状态;
  • Synchronization State:可以通过广播通道接收BIS同步数据流,由Standby状态进入。Synchronization状态可用于侦听一定区域内的BIS广播同步数据流(比如音频数据流),处于Synchronization状态并且正在接收同步数据包的设备称为Synchronized Receiver,只能单向接收BIG,如果在主机指定时间内未侦听到任何有效BIG,处于该状态的设备将回到Standby状态并通知主机。
    在这里插入图片描述

在这里插入图片描述
在这里插入图片描述
从BLE 链路层支持的状态功能及其状态迁移过程可以看出,链路层通信主要有三个模式:

  1. Advertiser/Broadcaster — Scanner/Observer:广播者与扫描者之间通过广播信道传输数据,广播通信是一种一对多的通信方式,只要广播者发送的是可被发现报文,扫描者在信号接收范围内就可以接收到广播报文,扫描者的数量不受限制。广播通信只能进行单方向通信,由于不支持数据包分割重组而无法传输较大的数据包,广播者并不知道有谁接收了数据因此通信并不可靠;
  2. Isochronous Broadcaster — Synchronized Receiver:等时广播者与同步接收者之间通过广播信道传输同步数据流BIS(比如音频数据流),等时同步广播通信也是一种一对多的通信方式,是在Bluetooth 5.2 中新增的,同样只能进行单方向通信,比如可以让听讲座的众多观众借助支持该通信模式的蓝牙耳机同步听到一个演讲者等时广播的音频数据流;
  3. Master/Central — Slave/Peripheral:主从设备通过数据信道传输数据,连接通信是一种一对一的通信方式(一个主设备可以与多个从设备建立连接,每对儿主从设备构成一个独立的piconet),LE 的连接通信一般用于传输异步数据,在Bluetooth 5.2 中新增了传输CIS(Connected Isochronous Stream)等时同步数据流的能力,每个CIS 承载一个单独的等时同步数据流,一个或多个CIS 可组成CIG(Connected Isochronous Group),每个CIG 最多包含31个CIS。

在这里插入图片描述

CIS 是称为连接同步群組(Connected Isochronous Groups CIG)的群組的成員,每个群組都可以包含多个 CIS 实例。在一个群組內,对于每个 CIS,都有一个发送和接收时隙的时间表,称为事件(Event)和子事件(Subevent)。

同一 CIG 中的 CIS 实例具有公共的定時参考数据,这些数据用于接收者跨群組中所有串流的同步数据处理(通常是音頻渲染)同步。每個事件均以称为 ISO 间隔的规则间隔发生,該间隔可以在 5ms 至 4s 的范围內,以 1.25ms 的倍數为单位。每個事件分為一個或多個子事件。在連接的同步流中,在子事件期間,主机(M)發送一次,而从机(S)進行回应。请注意,通道在每個子事件上都会更改。主设备可以创建多個CIG。

无连接同步通信使用广播同步流(Broadcast Isochronous Streams ,BIS),并且仅支持单向通信。 LE等时物理通道上的 LE-S 或 LE-F 逻辑链路用于用户数据,而新的 LEB-C 广播控制链路用于控制要求,例如通道映射更新的通信。单个 BIS 可以將相同的资料分流传输到多个接收器设备。使用广播等時串流(BIS)時,设备在每個子事件中广播等時数据封包或广播控制信息。接收广播的设备无法回应。


地址

两个设备互相识别通过使用设备地址。设备地址可以是 public device address 或者 random device address。其中 random device address又分为Static addressPrivate address。Public MAC address 需要向IEEE 购买,申请、管理、维护,Public MAC 成本较高且固定,有加大信息泄露的安全风险,为了进一步降低成本并提高安全性,BLE 协议新增了 Random Device Address,即设备地址不是固定分配的,而是在设备设备启动后随机生成的

按照安全性分类又可以分为Identity AddressResolvable Private Addresses。其中设备的Identity Address是它在传输的数据包中使用的 Public Device AddressRandom Static Device Address 。 即使设备使用Resolvable Private Addresses,它也有一个Identity Address
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

物理信道

如 [Vol 6] Part A 第 2 节中所述,在 2.4GHz ISM 频段中定义了 40 个 RF 通道。这些 RF 信道被分成三个 LE 物理信道:advertising, periodic,data

广播物理信道使用全部 40 个射频信道来发现设备、发起连接和广播数据。这些射频频道其中分出 3 个射频频道,称为primary advertising physical channel,主要用于initial advertisingall legacy advertising activities,这里的广播就像UDP一样,是不管收发的。剩下的37 个射频频道,称为secondary advertising physical channel,用于大多数所涉及的数据交换所涉及的通讯。二级广播频道用作“辅助”频道,这意味着在发送辅助通道上的广告数据包之前,设备必须首先在主广播频道上发布。

secondary advertising physical channel / data physical channel使用多达37 个RF通道(参见第 4.5.8 节)用于连接设备之间的通信。这些射频信道中的每一个都分配了一个唯一的信道索引(参见第 1.4.1 节)。The periodic physical channel在广播物理信道上使用与次要广播物理信道相同的射频信道。若希望通信的两个设备使用共享的物理信道。为了实现这一点,他们的收发器必须同时调谐到相同的 RF 频道。

在这里插入图片描述

这里需要注意3个primary advertising physical channel并不是相邻的。
在这里插入图片描述
在这里插入图片描述

鉴于 RF 通道的数量有限,并且许多蓝牙设备可能在同一空间和时间区域内独立运行,两个独立的蓝牙设备很可能将其收发器调谐到同一 RF 通道,从而导致物理信道冲突。为了减轻这种冲突的有害影响,物理信道上的每次传输都以一个Access-Address开始,使用该地址作为一个设备的correlation code,通知双方调频到新的channel,该访问地址是物理信道的属性,出现在每个传输的数据包的开头。其意图是任何两个设备之间的每个链路层连接和每个周期性广播序列都具有不同的访问地址。

链路层在给定时间使用一个物理通道。每当链路层与物理信道的时序、频率和访问地址同步时,就称其在数据物理信道上“连接”或“同步”到周期性物理信道(无论是否主动参与在信道通信中)。

Air Interface Packet

在链路层规范中定义数据包或协议数据单元 (PDU) 中的字段时 bit ordering遵循小端格式。 以下规则适用:
• 最低有效位The Least Significant Bit (LSB) 对应于 b0
• LSB 是通过空口发送的第一个比特
• 在插图中,LSB 显示在左侧

此外,链路层中定义的数据字段,例如 PDU 头字段,应首先使用 LSB 传输。 例如,一个 3 位参数 X=3 被发送为:

b0b1b2 = 110

LE设备应使用以下部分中定义的数据包使用。有两个基本格式:一个用于LE未编码的PHY(PACKET FORMAT FOR THE LE UNCODED PHYS),在手册Vol6.partB.2.1节中描述,一个用于LE编码的PHY(PACKET FORMAT FOR THE LE CODED PHY),在Vol6.partB.2.2节中描述。

  • LE Uncoded PHYs:未使用纠错码可以有比较高的通信速率(可以支持比如音频数据流这种高速率近距离的应用),从Bluetooth 5.x 开始提供两种调制码率也即LE 1M PHYLE 2M PHY,后者的通信速率是前者的两倍
  • LE Coded PHYs:使用纠错码可以有比较远的传输距离(可以支持比如传感器这种低速率远距离的应用),从Bluetooth 5.x 开始也提供两种调制码率即LE Coded PHY with S=2 coding 和LE Coded PHY with S=8 coding,前者的传输距离是LE Uncoded PHYs 的两倍(速率为其1/2),后者的传输距离是LE Uncoded PHYs的四倍(速率为其1/8)
    在这里插入图片描述
    在这里插入图片描述

这两种数据报文有什么区别呢?先从链路层对两种报文的比特流处理过程看起,在发射和接收数据的过程中,未使用FEC(Forward error correction) 前向纠错码的LE Uncoded PHYs 报文只需要增加CRC生成/校验、数据白化与反白化(BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 6, Part B, 3.2 中介绍过,为了解决GFSK 调制/解调连续相同比特能力差的问题)和可选的加密/解密过程即可。

使用FEC 前向纠错码的LE Coded PHY 则需要新增FEC 编码/解码、Pattern mapper(用于s = 2 或 s = 8 的模式映射),使用FEC 纠错码可以在数据丢失一部分的情况下恢复出原数据,因此可以接收并处理更小的信号(也即接收灵敏度更小),允许的最大损耗功率更大了,传播距离也就更远了。
在这里插入图片描述

再简单介绍 PHYs 的 数据格式吧:

  • Preamble:对于在LE 1M PHY上传输的数据包,前导码是8位;为了在LE 2M PHY上传输的数据包,前导码是16位。前导码的第一位(按传输顺序)应与访问地址的 LSB 相同。
    -

  • Access Address: 访问地址应为32位(4字节)值。有广播接入地址和数据接入地址两种类型:广播信道的接入地址是固定值0x8E89BED6,数据信道的接入地址是一个随机值,不同的连接有不同的值,可以通过接入地址来区分不同的连接。需要注意的是,这里的接入地址并非蓝牙的MAC地址,两者比特长度都不相同,接入地址字段是不加密的,采用随机值可以避免被攻击者确定正在通信的是哪个设备(设备的MAC地址在需要的时候放到PDU 中传递)。

    每次它需要新的访问地址,链接层应生成新随机值需满足以下要求:1. 不与现在使用的冲突。2.不是定期广播使用的地址。3.它不得超过六个连续的零或一,四个字节不相等。4.它不应是广告通道数据包的访问地址,且与广告物理信道数据包的访问地址相差大于一位。5.它的最高有效六位应至少有两个转换,总转换次数不得超过24 次。6. 随机数种子来自硬件随机数(真随机)。

  • PDU:当数据包在 the primary or secondary advertising physical channelthe periodic physical channel上传输时,PDU 应为 < BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 6, Part B | 2.3 > (下同)中定义的广播物理信道 PDU。当数据包在the data physical channel上传输时,PDU 应为 2.4 节中定义的数据物理信道 PDU。当数据包在isochronous physical channel上传输时,PDU 应为 2.6 节中定义的数据物理信道 PDU。

  • CRC:Cyclic Redundancy Check,对PDU 计算得到一个24比特的循环冗余校验码,接收机可以通过CRC校验及时发现传输比特错误,还能根据传输比特错误判断通信信道受到干扰,可以协商及时跳频到下一个信道继续通信。

  • Constant Tone Extension:该字段是可选的,主要用于Bluetooth 5.1 新增的AoA 和AoD Direction Finding,支持Bluetooth 5.1 的设备可以通过CTE 信息实现厘米级的室内定位精度。

  • CI:Coding Indicator,用来识别FEC Block 2 使用的是 s=8 或 s=2 哪种纠错码模式。

  • TERM1 / TERM2:每个FEC Block 末尾都有一个terminator,每个terminator 长度为3 比特。

了解了BLE 链路层两种基本数据报文的整体结构,下面开始介绍数据报文的核心 PDU Field,LE 链路层的三种通信模式分别对应三种类型的PDU,前面已经简要概括,下面我们将详细展开。

详情参考手册:《 CORE_V5.2 - vol6.B: Link LAYER SPECIFICATION》

PDU

广播包的组成呢,也遵循空口数据包的基本组成方式,只不过 AA 变为了特定值(0x8E89BED6),PDU 赋予了它新的生命:
在这里插入图片描述

Advertising physical channel PDU

广播(后面称为 ADV 或者 Adv)也分为,可连接/不可连接 ADV,可扫描/不可扫描 ADV,定向/不定向 ADV,等以及他们的各种组合。根据不同 BLE 的版本,ADV 分为两类:

  1. Legacy ADV:BLE 4.2 版本的 ADV
  2. Extend ADV: BLE 5.x 版本的 ADV
    在这里插入图片描述

BLE 为了提高广播通信的效率并尽可能降低功耗,只设计了 3 个固定广播信道,工作在37,38,39三个信道中。在Bluetooth 5.x 中为了增强广播能力,新增了LE Advertising Extensions channel,可以将数据信道当作广播信道使用。尽管名称如此,但the advertising physical channel PDU 也用于 the periodic physical channel。

在这里插入图片描述
广播物理通道 PDU 由一个 16 位的头和一个可变的大小 payload 组成。其格式如图 2.4 所示,而16 位标头字段如图2.5所示。

包含在报头中的广播物理信道 PDU 的 PDU 类型字段定义在表 2.3 中,它还显示了数据包可能出现在哪个信道和哪个 PHY。
在这里插入图片描述
在这里插入图片描述
在广播物理信道 PDU 中,来自主机的广播数据或扫描响应数据可能包含在某些 PDU 类型的 payload 中。该数据的格式在 [Vol 3] Part C, Section 11 中定义。

一些广播物理通道 PDU 包含一个 AuxPtr 字段(参见第 2.3.4.5 节),它指向包含另一个广播物理通道 PDU 的数据包。在这种情况下,第二个数据包和 PDU 是原始 PDU 的辅助数据包和辅助 PDU,而原始 PDU 又是第二个的上级数据包和上级 PD​​U。

注意:一个 PDU 只能有一个辅助 PDU,但可以有多个上级 PD​​U。给定一个数据包,它的下级集包括它的辅助数据包(如果有的话)和辅助数据包的下级集。没有 AuxPtr 字段的数据包有一个空的从属集。

  • 上面的广播类型根据使用的 Physical Channel 可以分为三种类型:Primary Advertising PDU、Secondary Advertising PUD、Periodic PUD。
  • 根据 链路层状态也可分为三类:Advertising PDUs、Scanning PDUs、Initiating PDUs。
Primary Advertising PDU

Primary Advertising PDU是BLE 4.x 提供的Legacy Advertising PDU,单个报文AdvData 最大只支持31 字节数据,且报文间相互独立。Secondary Advertising PDU和Periodic PDU是BLE 5.x 新增的Extended Advertising PDU,单个报文AdvData 最大可支持254 字节数据,且可借助AUX_CHAIN_IND 以报文链表的形式广播更大的数据包。Periodic PDU 主要是AUX_SYNC_IND,可以传输BIG(Broadcast Isochronous Group) 相关信息,辅助BIG 中多个BIS(Broadcast Isochronous Stream)的等时同步。

  • PDU:Type 广播PDU 的类型,目前支持 9 种类型,每种类型都有不同的payload 格式和行为,下文将会逐个介绍。
  • RFU:RESERVED FOR FUTURE USE,暂时不用,为后续预留。
  • ChSel:广播者是否支持LE Channel Selection Algorithm #2(BLE 5.x 新增的信道选择算法),若支持则该字段设置为 1;若该字段设置为0 则使用传统的LE Channel Selection Algorithm #1。
  • TxAdd:广播报文发送者的MAC 地址类型,若为public address 则该字段设置为 0;若为random address 则该字段设置为 1。
  • RxAdd:广播报文接收者的MAC 地址类型,若为public address 则该字段设置为 0;若为random address 则该字段设置为 1。
  • Length:数据有效载荷 / payload 的长度,有效范围是 1 - 255 个octets。
  • Payload: 广播数据的有效载荷,可以是实际广播传输的服务数据、主动扫描响应的附加数据、建立连接需要的信息等。

其中有几个需要注意的PDU:

Initiator 使用 Primary Physical channel 发送CONNECT_IND 后直接进入Connection State,发起者并不知道对方是否接收到了CONNECT_IND 报文,双方建立连接后在发送CONNECT_IND 报文的LE 1M PHY 上通信(后续可以通过PHY Update procedure 更换到其它PHY);

Initiator 使用Secondary Physical channel 发送AUX_CONNECT_REQ 后,还需要等待对方回复AUX_CONNECT_RSP 报文,接收到对方回复的报文后才进入Connection State,进入连接状态前多了个确认过程,双方建立连接后在发送AUX_CONNECT_REQ 报文的PHY 上通信(可以是LE 1M PHY、LE 2M PHY 或LE Coded PHY)

在这里插入图片描述

  • AA,LL Connection的Access Address,在不同设备组合之间,需要唯一,并遵守一些原则,具体可参考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]”。

  • CRCInit,用于CRC计算的一个初始值,由Link Layer随机生成。

  • WinSize和WinOffset,全称是transmitWindowSize和transmitWindowOffset,用于决定连接双方收发数据的时间窗口(第2章提到的时分的概念)。下面3.4小节会详细介绍。

  • connInterval,全称是connInterval,连接双方收发数据的周期。由于一个Master可能会和多个Slave建立连接,因此蓝牙的信道资源不能被某一个LL Connection所独占,所以一个收发周期中,可能有多个连接进行收发数据(具体的时间窗口,由transmitWindowOffset决定)。下面3.4小节会详细介绍。

  • Latency和Timeout,全称是connSlaveLatency和connSupervisionTimeout,和连接超时、自动断开有关,具体可参考3.4小节的描述。

  • ChM的全称是Channel map,用于标识当前使用和未使用的Physical Channel。Hop的全称是hopIncrement,它和ChM一起决定了数据传输过程中的跳频算法,具体可参考3.6小节的描述。

  • SCA(sleep clock accuracy),用于定义最差的Master睡眠时钟精度,具体可参考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]”,本文不再详细介绍

Extended Advertising PUD

扩展广播用于"承载"超过了广播长度的约定,而原本存在于主要广播频道上的数据——也称为辅助数据包,。“承载”是通过首先在主信道上通告数据值来完成的,这些数据值指向次信道上的辅助数据包。在主信道上发送的广播数据包包含PHY信道和扩展广播数据包开始时间的偏移量。

另一个重要方面是扩展广播可以使用三种 PHY(1M PHY、2M PHY 或编码 PHY)中的任何一个,而主要广播数据包只能使用 1M PHY 或编码 PHY 发送。

extended Advertising PUD 类型是可以在数据信道广播数据的,而且可以广播更大的数据包(最大254字节),甚至可以将多个报文链接起来组成广播报文链表,共同承载更多的广播数据。但广播者通常都在三个广播信道发送报文,扫描者也在这三个广播信道接收报文,如果要在数据信道上传输广播报文,双方需要有个约定,由广播者告诉扫描者应该什么时候去哪个信道上接收 Secondary Advertising PUD,而且这个约定信息也要借助在三个广播信道上传输的一个特殊报文承载。
在这里插入图片描述

Data Physical Channel PDU

BLE 提供了37 个数据信道,数据信道PDU 除了包含Header 和Payload 两个固定部分外,还包括一个可选的MIC (Messages Integrity Check)消息完整性检查部分。数据信道PDU 中的MIC 字段包含在加密的ACL (Asynchronous Connection-oriented) 连接中,且其有效载荷 / Payload 长度不能为零,在未加密的ACL 连接中或Payload 长度为零的连接中不得包含MIC 字段。

L2CAP 会对上层应用数据进行分片重组,LLID 可以识别L2CAP 消息的首个和最后一个分片,方便接收者在一个连接事件内能及时判断被分片后的L2CAP 消息是否还有后续。LLID 也能区分PDU 是Data 类型还是Control 类型。

NESN 和SN 两个字段用于报文的确认重传,为了尽可能减少Header 长度,只分别使用 1 个比特来实现确认重传功能。
在这里插入图片描述
16 或 24 位报头字段由表 2.17 中指定的 6 或 7 个字段组成。
在这里插入图片描述
MIC 字段不应包含在未加密的 ACL 连接中,或包含在具有零长度 payload 的数据通道 PDU 的加密 ACL 连接中。其应包含在加密的 ACL 连接中,带有非零长度 payload 的数据通道 PDU,并应按照 [Vol 6] Part E, Section 1 中的规定进行计算。

payload 格式取决于 Header 的 LLID 字段。如果 LLID 字段是 0b01 或 0b10,则数据物理信道 PDU payload 包含第 2.4.1 节中定义的 LL data PDU。如果 LLID 字段是 0b11,那么数据物理信道 PDU payload 包含一个 LL controller PDU,如第 2.4.2 节中所定义。

  • Header 的 NESN 位在 BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 6, Part B 4.5.9 节中定义。
  • Header 的 SN 位在第 4.5.9 节中定义。
  • Header 的 MD 位在第 4.5.6 节中定义。

报头的 CTEInfo Present (CP) 字段指示数据物理信道 PDU 报头是否具有 CTEInfo 字段,因此数据物理信道分组是否具有恒定音调扩展。

如果 CP 字段为 0,则数据信道 PDU 报头中不存在 CTEInfo 字段并且数据物理信道分组中没有恒定音调扩展。如果 CP 字段为 1,则数据物理信道 PDU 报头中的 CTEInfo 字段存在,并且数据物理信道包包括恒定音调扩展。

Header 的 Length 字段指示 Payload 和 MIC(如果包括)的长度。长度字段的范围是 0 到 255 个八位字节。 payload 的长度应小于或等于 251 个八位字节。MIC 的长度为 4 个八位字节。如果在 CP 字段中指示,则存在报头的 CTEInfo 字段CTEInfo 字段在第 2.5.2 节中定义。CTEInfo 字段可以出现在任何数据物理信道 PDU 的报头中。然而,链路层不应发送包含 CTEInfo 字段的数据物理信道 PDU,除非它已确定对等设备支持接收恒定音调扩展功能(参见第 4.6.22 节)。

注意:发送包含 CTEInfo 字段的 PDU 的控制器不一定能够接收,反之亦然。

在此版本的规范中,请求远程设备发送包含 CTEInfo 字段的数据包的唯一方法是通过恒定音调扩展请求过程。


LL Data PDU

LL data PDU 是用于发送 L2CAP 数据的数据通道 PDU。Header 中的 LLID 字段应设置为 0b01 或 0b10。

  • Header 中的 LLID 字段设置为 0b01,长度字段设置为 0b00000000 的 LL 数据 PDU 被称为空 PDU。主站的链路层可以向从站发送一个空的 PDU,以允许从站响应任何数据物理通道 PDU,包括一个空的 PDU。

这种类型的PDU,要么是一个未传输完成L2CAP message(长度超过255,被拆包,此时不是第一个),要么是一个空包(Header中的Length为0)。

  • Header中的LLID=10b时,Start of an L2CAP message or a complete L2CAP message with no fragmentation。Header 中 LLID 字段设置为 0b10 的 LL 数据 PDU 不应将 Length 字段设置为 0b00000000。

这种类型的PDU,要么是L2CAP message的第一个包,要么是不需要拆包的完整的L2CAP message,无论哪种情况,Header中的Length均不能为0。

注意:如果链路层接收到 Data_Total_Length 等于 0b00000000 且 Packet_Boundary_Flag 设置为 0b00(即开始片段)的 HCI ACL 数据包,则链路层不能简单地通过空中传输片段,而是必须将其与 一个或多个以下连续片段形成一个 PDU,LLID 设置为 0b10 且长度非零。


LL Control PDU

LL Data PDU 主要用来安全可靠高效的传输上层应用数据,LL Control PDU 则用来传输控制报文,LL Control PDU 目前支持38 个。

下面仅给出连接参数更新报文LL_CONNECTION_UPDATE_IND 作为示例:
在这里插入图片描述
Payload 由 Opcode 和 CtrData 字段组成。Opcode 字段标识不同类型的 LL 控制 PDU,如表 2.18 中所定义。LL 控制 PDU 中的 CtrData 字段由操作码字段指定,并在以下小节中定义。

注意:LL 控制 PDU 不应将长度字段设置为 0b00000000。对于给定的操作码,CtrData 字段的长度是固定的。CtrData 字段中的字段描述给出了有效值范围或对值的其他限制(例如如果字段 X 小于字段 Y),则所有其他值都应保留以备将来使用。

该范围可以在 LL 控制 PDU 的相关小节中直接指定,也可以在该小节引用的部分中间接指定(例如第 2.4.2.1 节中 WinSize 字段的范围源自第 4.5.3 节中指定的传输窗口大小值的范围)。

如果没有为字段指定范围,则该字段的所有值都有效。除非另有明确说明,LL 控制 PDU 中 CtrData 字段中的所有字段都应被解释为无符号。

// Table 2.18: LL Control PDU opcodes
0x00 LL_CONNECTION_UPDATE_IND
0x01 LL_CHANNEL_MAP_IND
0x02 LL_TERMINATE_IND
0x03 LL_ENC_REQ
0x04 LL_ENC_RSP
0x05 LL_START_ENC_REQ
0x06 LL_START_ENC_RSP
0x07 LL_UNKNOWN_RSP
0x08 LL_FEATURE_REQ
0x09 LL_FEATURE_RSP
0x0A LL_PAUSE_ENC_REQ
0x0B LL_PAUSE_ENC_RSP
0x0C LL_VERSION_IND
0x0D LL_REJECT_IND
0x0E LL_SLAVE_FEATURE_REQ
0x0F LL_CONNECTION_PARAM_REQ
0x10 LL_CONNECTION_PARAM_RSP
0x11 LL_REJECT_EXT_IND
0x12 LL_PING_REQ
0x13 LL_PING_RSP
0x14 LL_LENGTH_REQ
0x15 LL_LENGTH_RSP
0x16 LL_PHY_REQ
0x17 LL_PHY_RSP
0x18 LL_PHY_UPDATE_IND
0x19 LL_MIN_USED_CHANNELS_IND
0x1A LL_CTE_REQ
0x1B LL_CTE_RSP
0x1C LL_PERIODIC_SYNC_IND
0x1D LL_CLOCK_ACCURACY_REQ
0x1E LL_CLOCK_ACCURACY_RSP
0x1F LL_CIS_REQ
0x20 LL_CIS_RSP
0x21 LL_CIS_IND
0x22 LL_CIS_TERMINATE_IND
0x23 LL_POWER_CONTROL_REQ
0x24 LL_POWER_CONTROL_RSP
0x25 LL_POWER_CHANGE_IND
All other values Reserved for future use

Isochronous Physical Channel PDU

等时同步信道是Bluetooth 5.2 新增的,主要用来传输等时同步数据流(比如音频数据流)。由于等时同步数据流前后有承接关系,等时同步报文并不是相互独立的。等时同步数据流既可以通过广播方式单向传输,也可以通过连接方式双向传输,对应的Isochronous Physical Channel PDU 也分为 Broadcast Isochronous PDU 和 Connected Isochronous PDU 两种。

在这里插入图片描述
Header 字段和 payload 的格式取决于正在使用的 Isochronous Physical Channel PDU的类型。

  • 当在 CIS 上使用时, Isochronous Physical Channel PDU 应是第 2.6.1 节中定义的Connected Isochronous PDU。
  • 当在 BIS 上使用时,它应是第 2.6.2 节中定义的广播同步 PDU。

MIC 字段应包含在所有包含非零长度 payload 的 PDU 中,这些 payload 在加密的 CIS 或 BIS 上发送。MIC 应按照 [Vol 6] Part E, Section 1 中的规定计算,其是一个 4 个八位字节的字段。在未加密的 CIS 或 BIS 上发送的或具有零长度 payload 的任何 PDU 中不应包含 MIC 字段。

等时信道是支持Stream 和Frame 两种数据封装方式传送的,LLID 的作用跟数据信道PDU 中的类似,可以识别上层CIS (Connected Isochronous Stream)同步数据流的起始、结束分片,也可以区分Unframed CIS Data 与 Framed CIS Data。NESN 和SN 字段的作用跟数据信道PDU 中的一样,也是用来实现确认重传的。

CIE 字段可以让通信一方提前关闭CIS 事件,即便还有剩余CIS 未传输完成。当传输CIS Null PDU 时,NPI 位应被设置为 1。Length 字段的作用跟数据信道PDU 中的一样,也是用来标识有效载荷Payload 和 MIC 的长度之和,范围是0 到 255 octets。

Connected Isochronous PDU

一个Connected Isochronous PDU(CIS PDU)应该是一个 CIS 数据 PDU 或一个 CIS 空 PDU。CIS 数据 PDU 用于承载同步数据。

当没有数据要发送时使用CIS NullPDU。ConnectedIsochronous PDU 的Isochronous Physical Channel PDU 的Header 字段如图2.59 所示。

在这里插入图片描述
在这里插入图片描述

  • LLID 字段是 CIS Null PDU 中的 RFU。
  • The Next Expected Sequence Number / 下一个预期序列号 (NESN) 字段应按照第 4.5.9 节中的定义进行设置。
  • The Next Expected Sequence Number / 序列号 (SN) 字段应按照第 4.5.9 节中的定义在 CIS 数据 PDU 中设置。该字段是 CIS Null PDU 中的 RFU。
  • The Close Isochronous Event / 关闭同步事件 (CIE) 字段应按照第 4.5.13.4 节中的定义进行设置

LLID 的作用跟前面Connected Isochronous PDU 中的类似,不过这里区分的是Unframed BIS Data、Framed BIS Data 和 BIG Control PDU。

CSSN 和CSTF field 是用来标识BIG Control PDU 的,如果在当前BIG (Broadcast Isochronous Group) 中有发送BIG Control PDU 则CSTF 标识位应设置为 1。CSSN 用来标识BIG Control PDU 的序列编号,方便接收者判断接收到的BIG Control PDU 是重传报文还是新报文,由于广播通信是单向传输的,因此没有类似CSNESN 之类的field。

Broadcast Isochronous PDU

Broadcast Isochronous PDU(BIS PDU)应是 BIS Data PDU 或 BIG Control PDU。BIS DataPDU 用于承载同步数据。BIG Control PDU 用于发送 BIG 的控制信息。

用于 BroadcastIsochronous PDU 的 Isochronous Physical Channel PDU 的 Header 字段如图 2.60 所示。
在这里插入图片描述

  • The Control Subevent Sequence Number / 控制子事件序列号 (CSSN) 字段应按照第 4.4.6.7 节中的定义进行设置。
  • The Control Subevent Transmission Flag / 控制子事件传输标志 (CSTF) 字段应按照第 4.4.6.7 节中的定义进行设置。
    在这里插入图片描述
    BIG Control PDU 的Payload 目前支持两种类型:BIG_CHANNEL_MAP_IND 主要用于设置信道映射图channel map;BIG_TERMINATE_IND 主要用于通知Synchronized Receiver 广播同步组BIG 即将终止及其终止原因。BIG Control PDU CtrData 中的Instant 字段用来控制新的设置何时生效,两种BIG Control PDU 的Payload 结构如下:
    在这里插入图片描述
BIG Control PDU

BIG 控制 PDU 将用于在 BIG(Broadcast Isochronous Group) 中发送控制信息(见第 4.4.6.7 节)。BIG Control PDU 中Payload 字段的格式如图2.61 所示。

在这里插入图片描述
Opcode 字段标识不同类型的 BIG Control PDU,如表 2.25 中所定义。
在这里插入图片描述
BIG Control PDU 中的 CtrData 字段由 Opcode 字段指定并在以下小节中定义。对于给定的 Opcode,CtrData 字段的长度是固定的。 BIG 控制 PDU 不应将长度字段(参见第 2.6.2 节)设置为 0b00000000。

如果 CtrData 字段中的字段描述给出了有效值的范围或对值的其他限制(例如 字段 X 小于字段 Y),所有其他值应保留以备将来使用。

该范围可以在 BIG Control PDU 的相关小节中直接指定,也可以在该小节引用的小节中间接指定。除非另有明确说明,BIG 控制 PDU 中的 CtrData 字段中所有包含整数的字段都应解释为无符号数。

BIG_CHANNEL_MAP_IND : CtrData 字段的格式如图 2.62 所示。
在这里插入图片描述
BIG_CHANNEL_MAP_IND CtrData 包含两个字段:

  • ChM 字段应设置为 indicating使用 和 Unused数据通道的通道映射。每个通道都用一个位表示,按照第 1.4.1 节定义的通道索引定位。该字段的格式与 CONNECT_IND PDU 中的 ChM 字段相同(参见第 2.3.3.1 节)。
  • 当通道映射生效时,Instant 字段应设置为 b i g E v e n t C o u n t e r 15 − 0 bigEventCounter_{15-0} bigEventCounter150的值(参见第 4.4.6.3 节)。

BIG_CHANNEL_MAP_IND : CtrData 字段的格式如图 2.63 所示。
在这里插入图片描述
BIG_TERMINATE_IND CtrData 包含两个字段:

  • 应设置原因字段以通知同步接收器 BIG 即将终止的原因。有关错误代码和说明的列表,请参阅 [Vol 1] F 部分,控制器错误代码。
  • 当 BIG 将终止时,Instant 字段应设置为 b i g E v e n t C o u n t e r 15 − 0 bigEventCounter_{15-0} bigEventCounter150的值(参见第 4.4.6.3 节)。

其他

AD type 对应 的 value 标准在 Generic Access Profile.PDF中规定。对应的AD type的解释也可以在后面的Reference中找到、

在这里插入图片描述


参考文章

  • 5
    点赞
  • 46
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值