专栏首页摸鱼范式【三】Bluetooth 技术||链路层七种状态与空口报文设计(Core_v5.2)

【三】Bluetooth 技术||链路层七种状态与空口报文设计(Core_v5.2)

不想错过我的推送,记得右上角-查看公众号-设为星标,摘下星星送给我

欢迎大家加入2022届数字IC交流群,QQ群号 1060380138

版权声明:本文为CSDN博主「流云IoT」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。 原文链接:https://blog.csdn.net/m0_37621078/article/details/107697019

LE 链路层定义了两个设备如何利用无线电传输信息,包括报文、广播信道、数据信道等的详细定义,也规定了发现其它设备的流程、广播通信、连接的建立与管理、连接通信等。

一、LE Link Layer States

广播通信中发出广播报文的一方称为Advertiser,接收广播报文的一方称为Scanner,连接通信中发起连接的一方称为Mater,接受连接的一方称为Slave,这些设备角色并不是固定的,一个蓝牙设备可以根据需要在多个角色之间切换,也可以同时身兼多个角色。为了方便管理蓝牙设备的角色,在链路层使用状态机来标识蓝牙设备当前的状态,蓝牙设备角色的切换也就相当于状态机中状态的迁移,Bluetooth 5.2 链路层状态机如下:

LE Link layer state machine

  • Standby State:上电后,链路层进入并保持待机态,即不收发数据的非活动状态。根据上层的命令可由其它任何一种状态进入,也可以切换到除Connection状态外的任意一种状态;
  • Advertising State:可以通过广播通道发送数据的状态,由Standby状态进入。想向一定区域内其它设备广播数据的设备、可被发现或可被连接的设备需要处于Advertising状态,它广播的数据可以由处于Scanning或者Initiating状态的实体接收,也可以回应Scanning状态的实体发来的扫描请求。广播态的设备可以回到Standby状态,连接成功后也可切换为Connection状态;
  • Scanning State:可以通过广播通道接收数据的状态,由Standby状态进入。Scanning状态可用于侦听一定区域内的广播数据,有被动扫描和主动扫描两个子状态,被动扫描仅接收广播报文,主动扫描则发送扫描请求给广播态设备,并获取附加的扫描响应数据。Scanning状态的设备只能进入Standby状态,状态迁移条件是停止扫描;
  • Initiating State:为了发起连接,链路层需要处于Initiating状态,侦听自己试图连接的设备,如果收到了来自该设备的connectable广播报文,链路层会向其发送连接请求并进入Connection状态,当连接成功后对端的广播设备也会进入Connection状态。Initiating状态由Standby状态进入,如果不再发起连接或连接失败则返回Standby状态,如果连接成功则建立连接的双方都进入Connection状态;
  • Connection State:和某个实体建立了单独通道的状态,在通道建立之后,由Initiating或者Advertising自动切换而来(由Initiating状态进入Connection状态的设备称为Master / Center,由Advertising状态进入Connection状态的设备称为Slave / Peripheral),通道断开后会重新回到Standby状态;
  • 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 链路层各种通信模式拓扑结构

从BLE 链路层支持的状态功能及其状态迁移过程可以看出,链路层通信主要有三个模式:

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

上面介绍的每种通信模式都可以在链路层找到对应的Logical Link,下面给出承载每种通信模式的Logical Link、Physical Link、Physical Channels 架构层级图:

LE 物理层与链路层架构

二、Link Layer Packet format

如果了解TCP/IP 协议栈,不难发现网络协议每层都有自己的数据报文结构,上层的报文相当于下一层的数据,每一层都会添加便于本层处理数据的报文字段。数据报文或者数据帧在分层协议中应用非常普遍,BLE 的链路层状态管理、状态迁移、链路数据传输都靠数据报文来实现。

BLE 链路层的报文可以看作是带标签的数据,由一个设备发送、一个或多个设备接收,标签指明了数据由谁发出,以及应该由哪些设备接收。Bluetooth 5.2 中的LE 链路层定义了两种基本的数据报文(对应LE Physical Layer[1] 中介绍的四种调制方式):

  • LE Uncoded PHYs:未使用纠错码可以有比较高的通信速率(可以支持比如音频数据流这种高速率近距离的应用),从Bluetooth 5.x 开始提供两种调制码率也即LE 1M PHY 和LE 2M PHY,后者的通信速率是前者的两倍;
  • LE Coded PHY:使用纠错码可以有比较远的传输距离(可以支持比如传感器这种低速率远距离的应用),从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生成/校验、数据白化与反白化(LE Physical Layer 中介绍过,为了解决GFSK 调制/解调连续相同比特能力差的问题)和可选的加密/解密过程即可。使用FEC 前向纠错码的LE Coded PHY 则需要新增FEC 编码/解码(纠错码原理可参考文章:二维码的秘密[2])、Pattern mapper(用于s = 2 或 s = 8 的模式映射),使用FEC 纠错码可以在数据丢失一部分的情况下恢复出原数据,因此可以接收并处理更小的信号(也即接收灵敏度更小),允许的最大损耗功率更大了,传播距离也就更远了。

Bit stream processing for LE Uncoded/Coded PHYs

  • LE Uncoded PHYs 数据报文格式:

Link Layer packet format for the LE Uncoded PHYs

LE Uncoded PHYs 数据报文中各字段的描述如下:

Packet Field

Description

Preamble

所有链路层数据报文都会有一个前同步码,在接收器中用于执行频率同步、符号时序评估、自动增益控制等,是一个交替显示0 和 1 的固定比特序列。LE 1M PHY报文的前同步码为8位,LE 2M PHY报文的前同步码为16位,前同步码的第一个比特位应与Access Address 的LSB 首位相同。

Access Addredd

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

PDU

Protocol Data Unit,主要有三种类型:一个报文在primary or secondary advertising、periodic physical channel上传输时,为Advertising Physical Channel PDU;一个报文在data physical channel上传输时,为Data Physical Channel PDU;一个报文在isochronous physical channel上传输时,为Isochronous Physical Channel PDUs。这三种类型的PDU 正对应前面介绍的三种链路层通信模式,是链路层报文的核心。

CRC

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

CTE

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

  • LE Coded PHY 数据报文格式:

LE Coded PHY 数据报文每个字段的长度都是根据持续时间Duration 定义的,这是因为物理层支持LE 1M PHY 和LE 2M PHY 两种速率,在不同速率物理信道上传输时,该数据报文各字段比特数不同,故使用Duration 定义各字段长度。LE Coded PHY 数据报文中与LE Uncoded PHYs 报文相同的字段作用差不多,这里不再赘述,下面只给出LE Coded PHY 报文独有的字段描述:

Packet Field

Description

Preamble

长度为80 个symbols,由10个重复的符号模式“ 00111100”(按传输顺序)构成。

CI

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

TERM1 / TERM2

每个FEC Block 末尾都有一个terminator,每个terminator 长度为3 比特。

了解了BLE 链路层两种基本数据报文的整体结构,下面开始介绍数据报文的核心 PDU Field,LE 链路层的三种通信模式分别对应三种类型的PDU,将依次对其进行介绍。

2.1 Advertising physical channel PDU

BLE 为了提高广播通信的效率并尽可能降低功耗,只设计了 3 个固定广播信道,在Bluetooth 5.x 中为了增强广播能力,新增了扩展广播信道,可以将数据信道当作广播信道使用。广播信道PDU 包含Header 和Payload 两部分:

Advertising physical channel PDU

PDU Fields

Description

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 类型及其payload 之前,先简单解释下MAC 地址的类型,一般每个蓝牙设备都有一个唯一且固定的MAC 地址,也就是上表提到的Public Device Address。Public MAC address 需要向IEEE 购买,申请、管理、维护Public MAC 成本较高,且固定的Device Address 有加大信息泄露的安全风险,为了进一步降低成本并提高安全性,BLE 协议新增了Random Device Address,即设备地址不是固定分配的,而是在设备设备启动后随机生成的(可参考博文:BLE地址类型[3])。

Advertising physical channel PDU header’s PDU Type field encoding

上面的广播类型根据使用的Physical Channel 可以分为三种类型:Primary Advertising PDU、Secondary Advertising PUD、Periodic PUD。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)的等时同步。

2.1.1 Primary Advertising PDU

Primary Advertising PDU 类型根据链路层状态也可分为三类:Advertising PDUs、Scanning PDUs、Initiating PDUs。Advertising PDUs 包括ADV_IND、ADV_DIRECT_IND、ADV_NONCONN_IND、ADV_SCAN_IND、ADV_EXT_IND 五种类型,可以分别从是否可连接、是否可扫描、是否定向广播三个维度对比各种Advertising PDUs 的区别,这三种PDU 类型的Payload 如下表所示:

Primary Advertising PDU Type

上表中的AdvA (Advertiser’s Address) 、TargetA (Target’s Address)、ScanA (Scanner’s Address)、InitA (Initiator’s Address)均为BLE MAC Address,可以是public device address 或random device address,应与报文PDU Header 中的TxAdd/RxAdd field 设置类型一致。LLData field 包含跟连接参数相关的字段,介绍连接建立与管理时再谈。

CONNECT_IND Payload and LLData fields

2.1.2 Extended Advertising PUD

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

回顾前面列表中的8个Primary Advertising PDU 只介绍了7个,还有一个比较特殊的ADV_EXT_IND,这个报文就承载着后续Secondary Advertising PUD 将要在哪个信道什么时间点传输的信息,而且每次发送Secondary Advertising PUD 之前都要先在三个广播信道上发送ADV_EXT_IND,扫描者接收到ADV_EXT_IND 报文信息后,才知道要在什么时间去哪个数据信道接收后面的Secondary Advertising PUD。

前面介绍链路层广播事件类型可以从是否可连接、是否可扫描、是否定向广播三个维度进行分类,三个维度可组合出8种类别,除了可连接可扫描且定向广播事件自身存在矛盾外,其余7 种广播事件类型对应的广播报文如下表所示:

Advertising event types and Secondary Advertising PUD Type

从上表可以看出,在广播Secondary Advertising PUD 前都需要先广播ADV_EXT_IND 报文,且Secondary Advertising PUD 都是以AUX_ADV_IND 开头的,后面可以跟链式报文AUX_CHAIN_IND(每种广播事件都可以在AUX_ADV_IND 后面跟该报文),方便承载更多的广播数据。值得一提的是,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)。

还有一个比较特殊的Periodic PDU,在广播AUX_SYNC_IND 之前也需要先广播ADV_EXT_IND 报文和AUX_ADV_IND 报文,周期同步报文最大的特点就是广播报文AUX_SYNC_IND 按固定间隔周期性广播(每个AUX_SYNC_IND 后面也可以跟AUX_CHAIN_IND 报文),主要用来传输周期性数据或同步信息,比如BIGInfo 等。

Secondary Advertising PUD 包括ADV_EXT_IND PDU 都使用Common Extended Advertising Payload Format(包括PDU Type 为0b0111 和 0b1000 共六种类型),这种格式包含变长的Extended Header 及其Length field,最大可达254 字节的AdvData field,还有一个AdvMode 用于表示其是否可连接、是否可扫描等广播模式,各fields 图示如下:

Common Extended Advertising Payload Format

PDU Fields

Description

Extended Header Flags

每一位表示后续的每个field 是否存在,0 表示对应的field 不存在,1 则表示其存在

AdvA

Advertiser 的设备地址,可以是public / random device address,与PDU Header 中的TxAdd/RxAdd field 一致即可

TargetA

目标Scanner 或Initiator 的设备地址,可以是public / random device address,与PDU Header 中的TxAdd/RxAdd field 一致即可

CTEInfo

用于室内定位计算到达角AoA 或出发角AoD 的信息

AdvDataInfo

包含同一广播对不同报文的编号信息Advertising Data ID 和同一设备不同广播的编号信息Advertising Set ID

AuxPtr

包含下一个Secondary Advertising PUD 使用的信道Channel Index、距离收到该包后的时间点AUX Offset/Offset Units、使用的PHY 类型AUX PHY、广播者的时钟精度CA 等信息,可以看作是指向下一个Secondary Advertising PUD 的指针

SyncInfo

包含AUX_SYNC_IND报文的同步信息,比如周期间隔Interval、信道映射ChM、睡眠时钟精度SCA、广播事件计数器Event Counter 等信息

TxPower

广播者的发射功率

ACAD

Additional Controller Advertising Data,主要用于承载BIGInfo 信息

Secondary Advertising PUD、Periodic PDU 和ADV_EXT_IND PDU 根据不同的事件类型可能只包含上述的部分Extended Header Fields,且扩展报文基本都是以“ADV_EXT_IND(Primary) + AUX_ADV_IND(Secondary)” 形式组织的(可参考博文:广播态数据包组成[4])。

2.2 Data Physical Channel PDU

BLE 提供了37 个数据信道,数据信道PDU 除了包含Header 和Payload 两个固定部分外,还包括一个可选的MIC (Messages Integrity Check)消息完整性检查部分:

Data Physical Channel PDU

数据信道PDU 中的MIC 字段包含在加密的ACL (Asynchronous Connection-oriented) 连接中,且其有效载荷Payload 长度不能为零,在未加密的ACL 连接中或Payload 长度为零的连接中不得包含MIC 字段。

数据信道PDU 中Header 部分各字段的描述如下(CTEInfo 为可选字段,故Header 有两种长度):

Data Physical Channel PDU header field

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

NESN 和SN 两个字段用于报文的确认重传,为了尽可能减少Header 长度,只分别使用 1 个比特来实现确认重传功能。

下图中tSqNo 表示本地设备已发送的 transmitSeqNum, Packet 中的NESN 表示对端设备期望接收的Next Expected Sequence Number。如果二者相同表示对端设备期望接收的下一个Packet 和本地设备已发送的Packet 相同,判断为NAK 信号也即对端设备要求重发之前的old data;如果二者不同则表示对端设备期望接收的下一个Packet 和本地设备已发送的Packet 不同,判断为ACK 信号也即对端设备已成功接收前一个packet,要求本地设备发送new data,同时tSqNo 自增 1。 nExSqNo 表示本地设备期望接收的nextExpectedSeqNum,Packet 中的SN 表示对端设备发送过来的Sequence Number。如果二者不同则表示对端设备发送来的packet 不是本地设备下一个期望接收的packet,判断对端设备发送来的packet 是重传的old data,直接忽略;如果二者相同则表示对端设备发来的packet 正是本地设备下一个期望接收的packet,判断对端设备发来的packet 是new data,本地设备接收该packet,同时nExSqNo 自增 1。 如果一个设备可能因为某些原因(比如RX buffer已满)无法接受并处理新的packet,可以选择不增加nExSqNo 发送NAK 信号,这样对端设备就会重发old data,本地设备忽略这些包含old data 的packet,就在链路层实现了流量控制机制(Flow control)。

Transmit and receive SN and NESN flow diagram

MD 用来通知对端设备自己是否还有其它数据准备发送,如果MD 被设为 1 则应在当前连接事件中继续与对端设备通信;若MD 被设为 0 则设备可以快速结束当前连接事件以节省能量。

CP 用来标识Header 是否包含CTEInfo 字段信息,如果CP 设置为 1 则后面包含CTEInfo 字段信息,否则不包含CTEInfo 字段信息。

Length 则为有效载荷Payload 和 MIC 的长度之和,范围是0 到 255 octets,由于MIC 占用 4 octets 长度,Payload 的长度范围是 0 到 251 octets。

LL Data PDU 主要用来安全可靠高效的传输上层应用数据,LL Control PDU 则用来传输控制报文,LL Control PDU 目前支持38 个,下面仅给出连接参数更新报文LL_CONNECTION_UPDATE_IND 作为示例:

LL Control PDU Payload: LL_CONNECTION_UPDATE_IND

LL_CONNECTION_UPDATE_IND PDU 的CtrData fields 跟前面介绍的CONNECT_IND PDU 的LLData fields 有不少相同的参数,从这里也可以看出LL_CONNECTION_UPDATE_IND 主要是用来更新连接参数的,这几个参数的含义放到后面介绍连接建立与管理时再谈。

2.3 Isochronous Physical Channel PDU

等时同步信道是Bluetooth 5.2 新增的,主要用来传输等时同步数据流(比如音频数据流)。由于等时同步数据流前后有承接关系,等时同步报文并不是相互独立的,看起来跟前面介绍的数据信道报文有点类似(前面介绍的广播报文都是相互独立的),也是由固定的 Header 和Payload 再加上可选的 MIC(Messages Integrity Check) 三部分构成(等时同步信道PDU 的Header 部分并没有CTEInfo 字段)。

等时同步数据流既可以通过广播方式单向传输,也可以通过连接方式双向传输,对应的Isochronous Physical Channel PDU 也分为Connected Isochronous PDU 和 Broadcast Isochronous PDU 两种,下面分别介绍。

2.3.1 Connected Isochronous PDU

Connected Isochronous Physical Channel PDU

Connected Isochronous PDU Header 各field 描述如下:

Connected Isochronous PDU header field

等时信道是支持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。

2.3.2 Broadcast Isochronous PDU

Broadcast Isochronous Physical Channel PDU

Broadcast Isochronous PDU Header 各 field 描述如下:

Broadcast Isochronous PDU header field

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。

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 结构如下:

Format of the Payload of a BIG Control PDU

更多文章:

  • 《Bluetooth Core Specification_v5.2》[5]
  • 《BLE技术揭秘》[6]
  • 《蓝牙协议分析》[7]
  • 《细说BLE 数据包》[8]

参考资料

[1]

LE Physical Layer: https://blog.csdn.net/m0_37621078/article/details/107411324

[2]

二维码的秘密: https://zhuanlan.zhihu.com/p/140052146

[3]

BLE地址类型: http://www.wowotech.net/bluetooth/ble_address_type.html

[4]

广播态数据包组成: https://blog.csdn.net/zhoutaopower/article/details/95104632

[5]

《Bluetooth Core Specification_v5.2》: https://www.bluetooth.com/specifications/bluetooth-core-specification/

[6]

《BLE技术揭秘》: http://doc.iotxx.com/BLE技术揭秘

[7]

《蓝牙协议分析》: http://www.wowotech.net/sort/bluetooth

[8]

《细说BLE 数据包》: https://blog.csdn.net/zhoutaopower/category_9083143.html

END

本文分享自微信公众号 - 摸鱼范式(icparadigm)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-08-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 【四】Bluetooth 技术||链路层五种通信模式和空口协议设计 (Core_v5.2)

    前篇博文LE States and Packets[1] 已经介绍了LE 设备在不同通信模式下承担不同的角色,为了方便管理蓝牙设备在多个角色间的切换,链路层使用...

    空白的贝塔
  • 【二】Bluetooth 技术||协议栈架构与物理层设计 (Core_v5.2)

    前篇博文Bluetooth 协议栈设计与演进[1]已经分别介绍了蓝牙协议的四大应用场景及对应的技术解决方案,为满足物联网设备的需求,蓝牙协议新增了室内精准定位技...

    空白的贝塔
  • 蓝牙协议分析(2)_协议架构

    本文是蓝牙协议分析的第二篇文章,在“蓝牙协议分析(1)_基本概念”的基础上,从整体架构的角度,了解蓝牙协议的组成,以便加深对蓝牙的理解。

    233333
  • 蓝牙在工业物联网中扮演着重要角色

    philips-hue-with-bluetooth-100802215-large.jpg

    用户4122690
  • 蓝牙协议分析(1)_基本概念

    自1994年由爱立信推出至今,蓝牙技术已经走过了20个岁月。从最初的Bluetooth V1.0,到Bluetooth V4.0(最新的为V4.1,2013年底...

    233333
  • 通信协议详解

    传统意义上的“通讯”主要指电话、电报、电传。通讯的“讯”指消息(Message),媒体讯息通过通讯网络从一端传递到另外一端。媒体讯息的内容主要是话音、文字、图片...

    PM吃瓜
  • 物联网常见通信协议梳理

    本文将对常用的通信协议进行剖析,重点面向市场上使用率较高的,且又不是诸如TCP/IP之类老生常谈 的。

    木禾wen
  • 嵌入式Linux的网络连接管理

    连接管理器(ConnMan)是一个连接管理守护进程 , 用于管理运行 Linux 操作系统中设备的互联网连接。 它以快速、连贯、同步的方式对不断变化的网络条件提...

    半吊子全栈工匠
  • ibeacon蓝牙技术简介

    概述 在讲解ibeacon技术之前,我们首先来看一下蓝牙实际到现在经历了哪些发展。截止目前,蓝牙共有八个版本 V1.0/1.1/1.2/2.0/2.1/3.0/...

    xiangzhihong
  • 蓝牙技术的前世今生

    世界是蓝色的,而不知不觉这个世界将有 40 亿蓝牙设备了。这篇文章,我们将带你一起回顾蓝牙 1.0 到 5.0 的技术变迁,从音频传输、图文传输、视频传输,再到...

    鲜枣课堂
  • 001.网络TCP/IP工程知识点

    木二
  • 来吧, BlueTooth Mesh

    期待已久的蓝牙网格(BlueTooth Mesh)网络技术终于可以应用了。 蓝牙技术联盟在2017年6月份正式发布, 在现有的蓝牙网络拓扑(点对点、星形和广播)...

    半吊子全栈工匠
  • 深入浅出低功耗蓝牙(BLE)协议栈

    一般而言,我们把某个协议的实现代码称为协议栈(protocol stack),BLE协议栈就是实现低功耗蓝牙协议的代码,理解和掌握BLE协议是实现BLE协议栈的...

    FB客服
  • 四层和七层负载均衡的区别

    ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换...

    后端技术探索
  • 给广大码农分享福利:一个业界良心的github仓库,中文计算机资料

    版权声明:本文为博主汪子熙原创文章,未经博主允许不得转载。 https://jerry.blog....

    Jerry Wang
  • 四层和七层负载均衡的区别

    (一) 简单理解四层和七层负载均衡: ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载...

    小小科
  • 给广大码农分享福利:一个业界良心的github仓库,中文计算机资料

    我今天查资料时无意发现的,https://github.com/CyC2018/CS-Notes

    Jerry Wang
  • Web负载均衡学习笔记之四层和七层负载均衡的区别

      ① 所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换...

    Jetpropelledsnake21
  • 负载均衡原理与技术实现

    负载均衡(Load Balance,简称LB)是一种服务器或网络设备的集群技术。负载均衡将特定的业务(网络服务、网络流量等)分担给多个服务器或网络设备,从而提高...

    菲宇

扫码关注云+社区

领取腾讯云代金券