BLE 技术（四）--- 链路层广播通讯与链接通讯 (Core_v5.2)

时间  2020-09-19 标签 ble 技术 链路层 广播 通讯 链接 core v5.2

文章目录

前言

前篇博文LE States and Packets 已经介绍了LE 设备在不一样通讯模式下承担不一样的角色，为了方便管理蓝牙设备在多个角色间的切换，链路层使用了状态机来管理蓝牙当前的状态及该状态下支持的通讯模式。同时，也介绍了BLE 链路层的两种基本报文格式，以及在不一样物理信道上传输时PDU (Protocol Data Unit) 结构的差别。
LE Link Layer States and transport architecture
BLE 设备链路层的报文是上层应用数据的载体，也是通讯双方实现无线传输的基础，了解了这些基本报文结构，接下来看通讯双方如何传输这些报文。web

1、Broadcast communication

从BLE 链路层状态迁移图可知，LE 设备可支持三种广播通讯模式：算法

  • Advertising State — Scanning State：使用广播信道进行一对多单向通讯，广播报文间相互独立，只能传输不超过255 字节的数据；
  • Synchronization State — Isochronous Broadcasting State：使用广播信道进行一对多单向通讯，能够传输同步数据流BIS（好比音频数据流），这两个状态是在Bluetooth 5.2 中新增的；
  • Advertising State — Initiating State：使用广播信道向目标设备发起链接，并传递链接参数，双方成功创建链接后都将进入Connection State，两个处于链接状态的设备使用数据信道进行一对一双向通讯。

下面只简单介绍Primary Advertising 的短报文广播通讯过程，Secondary Advertising 与 Periodic 的广播通讯过程有所不一样，读者能够参阅Bluetooth Core Specification_v5.2。安全

Primary Advertising PDUs

1.1 Advertiser — Scanner

先看短报文的广播通讯模式，比较基本的广播通讯是广播者在3 个固定广播信道上轮流发送广播报文，扫描者在 3 个固定广播信道上依次扫描附近空间中是否有Scannable 广播报文（好比ADV_IND、ADV_SCAN_IND等），若是附近有可扫描广播报文且广播时间在扫描窗口范围内，扫描者就能够接收到广播者发出的广播报文。app

下图给出了基本的广播通讯过程示意图，扫描者须要在相同的广播信道才能接收到广播报文，所以扫描窗口的时间通常大于一次广播事件（广播者在全部被使用的广播信道上依次发送广播报文的过程，右图给出了广播事件开始与结束的标识，ADV_IND 是一个广播报文）的时间：
Advertising and scanning
两个广播事件之间的间隔时间称为Advertising interval，广播间隔advInterval 支持的范围是 20ms — 10485.76 s 且为0.625 ms 的整数倍（本文展现的是Bluetooth 5.2 的标准，跟Bluetooth 4.x 的标准有所不一样）。扫描窗口scanWindow 与扫描间隔scanInterval 时间设置应小于40.96 s，且scanWindow 的值不能大于scanInterval 的值，建议scanWindow 的值不小于advInterval。
Advertising events perturbed in time using advDelay
为了不多个广播者可能在很长一段时间同时广播形成干扰，两个广播事件之间的时间间隔T_advEvent 会在广播间隔advInterval 的基础上再加上一个0 — 10ms 的随机延时advDelay。这样，即便两个广播者的advInterval 相同，并在相同的信道和时间点上同时发送形成干扰，也会在下一个广播事件因随机延时advDelay 的不一样而避开相互干扰。dom

扫描者支持主动扫描和被动扫描两种模式，前面介绍的扫描者仅侦听并接收广播报文属于被动扫描，主动扫描则是指扫描者能够向特定广播者发送扫描请求报文，广播者收到扫描请求报文后在相同的广播信道上向其回复扫描响应报文（扫描请求与响应过程也会计算在一个Advertising Event 中），扫描者就能够从广播者得到更多的附加信息。主动扫描与被动扫描过程图示以下（右图中的T_IFS 指的是相同信道上两个连续报文之间的时间间隔，值为 150 us）：
Active and passive scanning异步

注：咱们从前篇博文中知道非扩展广播报文的AdvData 最大为31 octets（跟byte 同样都表示8 bits），扩展广播报文的AdvData 最大为254 octets，前面咱们也知道非定向广播事件的间隔时间最小为20 ms + 5 ms（随机时延按平均值5 ms 计），能够大概计算非扩展广播报文的最大通讯速率为 8 * 31 bytes / 25 ms = 9.92 Kbps，扩展广播报文的最大通讯速率为8 * 254 bytes / 25 ms = 81.28 Kbps。若是再算上传输扫描响应报文，最大通讯速率能够double，也即分别为19.84 Kbps 和 162.56 Kbps，通讯速率依然比较低，且由于单向通讯、不加密传输、没有确认应答机制，广播通讯属于不可靠通讯。svg

1.2 Advertiser — Initiator

Initiator 侦听到Connectable 广播报文后会发送链接请求报文（好比ADV_DIRECT_IND、ADV_IND等），以便双方创建链接（Initiator 侦听Connectable 广播报文的过程跟Scanner 侦听Scannable 广播报文的过程相似）。若是要创建链接的双方知道对方的Device Address（或MAC Address），广播者能够发送定向广播报文ADV_DIRECT_IND 实现快速链接，若是是首次链接不知道对方Device Address 发送ADV_IND 广播报文也是支持Connectable 的。
Advertising and Initiating
Connectable directed advertising 除了支持前面介绍的low duty cycle mode 外，还支持更快速的high duty cycle mode，这两种模式区别以下：性能

  • Low duty cycle connectable directed advertising：广播事件间隔较长，广播间隔时间T_advEvent 范围 20ms — 10485.76 s；
  • High duty cycle connectable directed advertising：广播事件间隔较短，广播间隔时间T_advEvent 范围 3.75 ms — 1.28 s；

BLE 低功耗主要是靠大幅下降通讯时间，让LE 设备大部分时间都处于睡眠状态实现的。对于面向链接的LE 设备，只在须要传输数据时才创建链接，数据传输完成立刻关闭链接并进入睡眠状态。对于链接双方已经知道对方Device Address 的状况，尽快创建链接能下降响应延迟同时下降功耗，所以BLE 为connectable directed advertising提供了high duty cycle mode，让通讯双方创建链接的时间能够缩短到3.75 ms 。不过high duty cycle mode 比较耗电，所以该模式持续时间比较短（不超过1.28 秒），若在high duty cycle mode 持续期间未能成功链接，则能够切换到low duty cycle mode 继续尝试链接。
Low duty cycle and High duty cycle mode编码

1.3 Isochronous Broadcaster — Synchronized Receiver

Isochronous Broadcaster 与Synchronized Receiver 之间能够单向传输BIG(Broadcast Isochronous Group，好比音频数据流)，每一个BIG 由一个或多个BIS(Broadcast Isochronous Stream) 组成，同一BIG 中BIS 的最大数目为 31，同一BIS 的多个数据报文之间具备时间上的承继关系。加密

在一个BIG 中，每一个BIS event 的时间间隔 ISO_Interval (取值范围为 5ms — 4 s)是同样的，同一个BIS event 内多个BIS Data PDU 报文传输（也即Subevent）之间的时间间隔 Sub_Interval (取值范围在MPT + T_MSS 到 ISO_Interval 之间)也是同样的。每一个BIG 中通常会包含一个 Control subevent（也即发送BIG Control PDU 报文），主要用来管理BIG 使用的物理信道以及BIG 传输的终止条件。
BIG and BIS events

BIG 的广播参数比较多，Synchronized Receiver 若是想接收BIG 等时同步数据流信息，须要先得到BIGInfo，BIGInfo 包含了BIG 所有的参数信息，格式以下（Fields描述能够参阅Bluetooth Core Specification_v5.2，本文就不展开介绍了）。Synchronized Receiver 能够接收AUX_SYNC_IND 报文中的 ACAD (Additional Controller Advertising Data) field 得到BIGInfo，再根据BIGInfo 在特定的Isochronous 信道上侦听BIG 中的BIS 报文。
Format of BIGInfo
AUX_SYNC_IND 报文是在Periodic 信道中传输的，属于Periodic advertising events，每两个AUX_SYNC_IND 报文发送的周期间隔为Periodic Advertising Interval，取值范围是 7.5 ms — 81.91875 s，且为1.25 ms 的整数倍。
periodic advertising events

注：咱们从前篇博文中知道Broadcast Isochronous PDU的Payload 最大为251 octets，前面咱们也知道Sub_Interval 的间隔时间最小为MPT + T_MSS，其中MPT 是传输最大BIS 报文花费的时间，从前篇博文能够计算获得MPT = 8 * (2 + 4 + 258 + 3) / 2 + 160 = 1228 us，T_MSS 指的是Minimum Subevent Space 值为 150 us，由此能够大概计算 Isochronous Broadcast 的最大通讯速率为 8 * 251 bytes / (1228 + 150) = 1.457 Mbps，彻底能够知足音频传输的速率需求，但由于单向通讯、没有确认应答机制，等时同步广播通讯也属于不可靠通讯。

1.4 Filter Policy and White List

若是周围空间中广播者的数量过多，扫描者可能会扫描到不少数据，但扫描者可能只关心其中的一小部分广播数据（好比只关心来自某些广播者的数据），其它不关心的数据对于扫描者来讲至关于垃圾信息。若是扫描者接收并处理全部的数据，到上层再处理甄别这些数据，显然效率较低，不只平白增长了功耗，还可能增大响应时延，所以有必要在底层链路层就提供必定的报文过滤策略。

BLE 链路层如何实现报文过滤呢？本文开头介绍多种Advertising PDU 能够经过Connectable、Scannable、Directed 三个属性的组合来区分，这些属性实际上也是一种报文过滤机制。其中Directed PDU 主要是经过Device Address field 实现报文过滤的，链路层提供的White List 过滤策略实际上也是经过Device Address field 实现报文过滤的。

White List 是链路层用于报文筛选过滤的Device Address List，其中包含设备地址和设备地址类型（public or random address）。白名单由上层Host 配置，链路层会根据白名单中的条目匹配报文中的设备地址及设备类型字段，若是链路层应用了白名单且设备地址匹配经过才接收并处理相应的报文，设备重置后白名单将清空。

基于白名单，链路层可实现的设备过滤策略以下（下面的过滤策略将忽略定向广播报文）：

  • Advertising filter policy

Advertising filter policy 决定了Advertiser 的链路层怎么处理扫描请求和链接请求，包括以下过滤策略（由Host 根据需求配置，同一时刻只能配置一种）：

  1. 链路层应处理全部设备的扫描和链接请求（即未使用白名单），这是重置时的默认设置；
  2. 链路层应处理来自全部设备的链接请求，但仅处理来自白名单中设备的扫描请求；
  3. 链路层应处理来自全部设备的扫描请求，但仅处理来自白名单中设备的链接请求；
  4. 链路层应仅处理来自白名单中设备的扫描和链接请求。
  • Scanner filter policy

Scanner filter policy 决定了 Scanner 的链路层怎么处理广播报文或扫描响应报文，包括以下过滤策略（由Host 根据需求配置，同一时刻只能配置一种）：

  1. 链路层应处理全部广播和扫描响应报文（即未使用白名单），这是重置时的默认设置；
  2. 链路层应仅处理白名单中设备的广播和扫描响应报文。
  • Initiator filter policy

Initiator filter policy 决定了Initiator 的链路层怎么处理广播报文，包括以下过滤策略（由Host 根据需求配置，同一时刻只能配置一种）：

  1. 链路层应忽略白名单，并处理Host 指定的特定单个设备中的可链接广播报文；
  2. 链路层应处理白名单中全部设备的可链接广播报文。
  • Periodic sync establishment filter policy

Periodic sync establishment filter policy 决定了 Scanner 的链路层在尝试与periodic advertising train 同步时怎么处理广播报文，包括以下过滤策略（由Host 根据需求配置，同一时刻只能配置一种）：

  1. 链路层应忽略Periodic Advertiser List，并处理Host 指定的特定单个设备的广播报文；
  2. 链路层应处理来自Periodic Advertiser List 中全部设备的广播报文。

2、Connection communication

前面介绍的广播通讯都是单向的，因为单向通讯没法得到接收者的确认信息，不能保证广播报文的可靠传输。若是通讯双方要进行安全可靠的双向通讯，就要创建链接，在数据信道上基于链接进行通讯。

前面介绍的Advertiser — Initiator 通讯模式，当Initiator 侦听到Connectable 广播报文就会向目标设备发起链接请求，Advertiser 正确响应链接请求后，双方成功创建链接，均进入Connection State。创建链接的双方Master — Slave 就能够在数据信道上进行一对一安全可靠的双向通讯。

从LE 链路层支持的报文种类能够看出，LE 设备支持两种链接通讯模式：

  • Asynchronous Connection communication：使用数据信道进行一对一双向通讯，主要用来传输异步数据（好比传感器监测数据或控制数据等），对数据的安全可靠、传输距离更敏感，对数据的传输速率要求不高；
  • Isochronous Connection communication：使用数据信道进行一对一双向通讯，主要用来传输等时同步数据（好比音频数据流），对数据的等时同步、传输速率更敏感。

2.1 Asynchronous Connection communication

创建链接的双方长时间维持链接也须要耗电，这与LE 低功耗的目标不符。若是通讯双方知道对方的Device Address，可使用High duty cycle connectable directed advertising 在最短3.75 ms 内快速创建链接。

2.1.1 Connection event

若是创建链接的时间足够短（也即响应时延足够小），天然不须要长时间维持链接，在双方须要通讯时快速创建链接，数据传输完成后及时关闭链接以节省功耗，在下次须要通讯时再快速创建链接。像这种每次创建链接后完成一次双向报文传输的过程称为Connection event，两次链接事件之间的时间间隔称为Connection Interval。
Connection events

上图中链接间隔Connection_Interval 的取值范围是7.5 ms — 4 s，且为1.25 ms 的整数倍。链接间隔的设置也有要求，若是链接间隔设置太小会增长功耗，若是链接间隔设置过大会增大响应时延，所以链接间隔支持的最大值只有 4 秒。

但有些设备好比传感器须要的通讯频率可能很低，也即须要的链接间隔比较大好比以分钟甚至小时计，若是设置远小于需求的链接间隔将会平白增长功耗、下降续航时间。为了让LE 设备尽量下降功耗，同时保证将响应时延控制在可接受范围内，BLE 协议容许LE 从设备在没有数据传输需求的状况下跳过必定数目的链接事件，继续保持睡眠以下降功耗，这是LE 从设备一个重要的低功耗设计；在有数据传输需求的状况下不跳过链接事件，以保证及时响应。

LE 从设备跳过必定数目链接事件的过程称为从机延迟Slave Latency，Slave_Latency 的值表示在没有数据传输需求时能够跳过的链接事件的数目，取值范围在0 — 499 之间。当LE 从设备有数据传输需求时，能够不受Slave Latency 的限制，尝试在下一个链接事件到来时创建链接并传输数据，以尽量下降响应时延。
Slave Latency
因为Slave Latency 可让LE 从设备跳过必定数目的链接事件，在LE 从设备没有数据传输需求的状况下，真实有效的链接间隔将再也不是Connection Interval，而是Effective Connection Interval = Connection_Interval × (1 + Slave_Latency)。

双方维持的链接可能会因为各类缘由而中断，好比设备超出范围、受到严重干扰、电源故障等，并且这些多是在没有任何事先通知的状况下发生的，所以有必要监测链接状态。咱们知道TCP 链接保活功能就是经过周期性发送保活探测报文来监测链接双方是否仍处于活动状态，若是其中一方因为某些缘由处于非活动状态，另外一方将关闭该链接并释放相应的资源。

BLE 也采用了相似的机制，经过一个TLLconnSupervision计时器来监测双方的链接状态，当发生有效链接事件时（也即双方成功创建链接并有报文传输）将该计时器复位。在创建链接以前，若是TLLconnSupervision 达到 6 * Connection_Interval（或者TCISconnSupervision 达到 6 * ISO_Interval）则判断链接创建失败，中止继续尝试创建链接。

在链接成功后，若是TLLconnSupervision 达到Connection supervision timeout（可由Host 配置该值），则判断当前链接已丢失，通讯双方终止该链接并释放相应资源。Connection_supervision_timeout 的取值范围是 100 ms — 32 s（应为10 ms 的整数倍），表示两个成功链接事件之间容许的最长时间间隔，该值建议设置为大于 2 * Connection_Interval × (1 + Slave_Latency)。根据Connection_supervision_timeout 的配置值，能够缩小Slave_Latency 的取值范围，也即上限为 (Connection_supervision_timeout / (2 * Connection_Interval)) - 1 和 500 中较小的的整数。

2.1.2 Connection setup

当Master 发出/Slave 收到链接请求报文后，双方就自动进入Connection State，开始在数据信道上收发报文，双方链接创建过程的时序以下：
Master and Slave Connection setup
Master 发出链接请求报文CONNECT_IND 后，会在(transmitWindowDelay + transmitWindowOffset) 到 (transmitWindowDelay + transmitWindowOffset + transmitWindowSize) 这个发送时间窗口transmit window 内向Slave 发送第一个Packet (M->S)。同理，Slave 接收到链接请求报文CONNECT_IND 后，也会在相应的时间窗口transmit window 内尝试接收第一个Packet (M->S)。

  • transmitWindowDelay：等待链接创建成功的通知， 使用CONNECT_IND 报文时该值为 1.25 ms；
  • transmitWindowOffset：能够控制LL Connection使用哪一段时间进行通讯，从而保证同一Master 和多个Slave 之间的多个链接互不影响的通讯，也即时分复用数据信道，transmitWindowOffset的取值范围是 0 — Connection_Interval，且为1.25 ms 的整数倍；
  • transmitWindowSize：发送报文的时间窗口，最小值是 1.25 ms，最大值是 (Connection_Interval - 1.25 ms) 与 10 ms 中的较小者，且为1.25 ms 的整数倍；

Master 发出第一个Packet (M->S) 后，将以此为起点Anchor point，以Connection_Interval 为周期，接着发送后续的Packet (M->S) 并接收来自Slave 的Packet (S->M)，收发一个或多个Packet 的过程称为Connection event。同理，Slave 接收到第一个Packet (M->S)后（若是没有收到在下一个链接周期继续尝试接收），也以此为起点Anchor point，以Connection_Interval 为周期，接收后续的Packet (M->S) 并向Master 发送本身的Packet (S->M)。

了解了Master 与Slave 创建链接通讯的过程，再回顾前篇博文谈到的链接参数，就比较容易理解了。
CONNECT_IND Payload and LLData fields

LLData Fields Description
AA ACL connection’s Access Address，不一样的链接有不一样的值，能够经过接入地址来区分不一样的链接。
CRCInit 用于CRC 计算的一个初始值，由Link Layer随机生成。
WinSize 也即transmitWindowSize，最小值是 1.25 ms，最大值是 (Connection_Interval - 1.25 ms) 与 10 ms 中的较小者，且为1.25 ms 的整数倍。
WinOffset 也即transmitWindowOffset，取值范围是 0 — Connection_Interval，且为1.25 ms 的整数倍。
Interval 也即Connection_Interval，取值范围是7.5 ms — 4 s，且为1.25 ms 的整数倍。
Latency 也即Slave_Latency，最小值为0，最大值为(Connection_supervision_timeout / (2 * Connection_Interval)) - 1 和 500 中较小的的整数。
Timeout 也即Connection_supervision_timeout，取值范围在 100 ms — 32 s之间，且为10 ms 的整数倍，建议大于 2 * Connection_Interval × (1 + Slave_Latency)。
ChM Channel Map，用于标识当前使用和未使用的Physical Channel。
Hop HopIncrement，和ChM一块儿决定了数据传输过程当中的跳频算法，该值为 5 — 16 之间的一个随机值。
SCA master’s Sleep Clock Accuracy，用于定义最差的Master睡眠时钟精度，更高精度的时钟能够提升通讯的稳定性和响应及时性。

CONNECT_IND PDU 中的ChM 与Hop field都与BLE 的跳频算法或者信道选择算法相关，BLE 链路层为connection events提供的信道选择方法以下（BLE 还为 periodic advertising events 提供了第二种信道选择算法，本文不作介绍了）：
Block diagram of Channel Selection algorithm #1
上面的信道选择算法主要分为两个步骤：

  1. Basic algorithm：在上一个链接事件的未映射信道lastUnmappedChannel 基础上，再加上一个跳频增量hopIncrement，获得当前链接事件的未映射信道索引unmappedChannel（加法结果对37 取模，以避免超出数据信道索引范围），若是unmappedChannel 是一个可用信道，则直接做为当前链接事件的信道索引（这即是BLE 的跳频算法），不然进行下一步的重映射计算；
  2. Re-map algorithm：若是上一步计算获得的unmappedChannel 不是一个可用信道，则借助可用信道重映射表remapping table(used channels in ascending order)，将unmappedChannel 重映射到一个可用信道remappingIndex（这即是BLE 的自适应跳频算法），这就是当前链接事件的信道索引。

前篇博文Data Physical Channel PDU 部分已经介绍了链接成功创建后的报文传输过程，如何经过NESN 和SN field 实现应答确认与流控机制，如何经过MD field 主动结束当前链接事件，本文就再也不赘述了。值得一提的是，LL Data PDU 在一般状况下支持的最大载荷只有27 octets，跟前面介绍的广播报文相似，只有在启用扩展特性后LL Data PDU 的最大载荷才会达到251 octets。
Valid ranges for data PDU length management parameters

注：从上面的链接通讯过程可知，BLE 面向链接的通讯速率是由Connection_Interval 和每一个Connection Event 中传输的数据量决定的。不少平台为了保证Master 的性能，会限制Connection_Interval 的最小值，好比IOS 限制Connection_Interval_Min >= 20ms，这里取Connection_Interval = 25 ms 做为通讯速率估算参数。每一个Connection Event 发送报文的时间窗口大小为transmitWindowSize，这里取最大值 10 ms，看在该时间窗口内能发送多少有效数据，非扩展LE Data Packet 最大载荷为27 octets，扩展LE Data Packet 最大载荷为251 octets，采用默认的LE 1M PHY 报文格式，在10 ms 内能够传输的非扩展数据报文数目为 10 * 1000 / (336 + 160 + 150) = 15，在10 ms 内能够传输的扩展数据报文数目为10 * 1000 / (2128 + 160 + 150) = 4，考虑到在transmitWindowSize 内不仅是发送报文，还要为接收报文留出时间，所以将上面的数据都减半。由此可计算出ACL 传输非扩展数据报文的最大速率为 8 * 8 pcs * 27 bytes / 25 ms = 69.12 Kbps，ACL 传输扩展数据报文的最大速率为 8 * 2 pcs * 251 bytes / 25 ms = 160.64 Kbps，若是采用LE Coded PHY 报文格式传输速率更低。

2.2 Isochronous Connection communication

Connected Isochronous 通讯跟前面介绍的Broadcast Isochronous 通讯有点相似，不一样的是Connected Isochronous 是面向链接的双向通讯，在Master 与 Slave 之间能够双向传输CIG(Connected Isochronous Group，好比音频数据流)。每一个CIG 由一个或多个CIS(Connected Isochronous Stream) 组成，同一CIG 中CIS 的最大数目为 31，同一CIS 的多个数据报文之间具备时间上的承继关系。

CIG 在建立其第一个CIS 时就存在了，其全部组成CIS 都应具备相同的Master。Host 为每一个CIG 分配一个标识符CIG_ID，同时为其每一个CIS 分配一个标识符CIS_ID，不一样的CIS 必须具备不一样的CIS_ID，若是某个CIS 被终止其CIS_ID 能够被复用。

在一个CIG 中，每一个CIS event 的时间间隔 ISO_Interval (取值范围为 5ms — 4 s)是同样的，但每一个CIS anchor point 相对CIG synchronization point 的 CIS_Sync_Delay 可能不一样。CIS_Sync_Delay和CIG_Sync_Delay 是Master 链路层向Slave 链路层提供的时序参数，用于上层应用层实现等时数据流的同步。

每一个CIS event 内多个Subevent（也即CIS Data PDU 报文传输）之间的时间间隔Sub_Interval (取值范围在SE_Length 到 ISO_Interval 之间，SE_Length 值为MPTM + T_IFS + MPTS + T_MSS，其中T_IFS 和T_MSS 的值均为150 us)也是同样的。经过适当的设置Sub_Interval 的值和不一样CIS anchor point 之间的间距，CIG 中的CIS 能够顺序排列或交错排列，排列关系以下图示：
CIG event and CIS event
CIG 的链接参数比较多，如何为建立CIG 及其组成的CIS 配置参数呢？回顾BIG 的广播参数BIGInfo 是借助Periodic advertising 中的AUX_SYNC_IND 报文传输的，接收者得到BIGInfo 信息后就能够与广播者同步BIG广播参数，而后接收BIG 中的BIS 等时同步数据流了。CIG 借助什么报文传输相关的链接参数呢？

Connected Isochronous 通讯须要链接双方同步CIG 链接参数，前面咱们已经创建了Master 与Slave 之间的链接，彻底能够借助前面介绍的Asynchronous Connection 传输CIG 链接参数，待链接双方完成CIG 链接参数同步后，就能够开始传输CIG 等时同步数据流了。所以，每一个CIG 都跟一个ACL 是相关联的，CIG 中链接参数的同步与更新须要借助ACL 完成传输，具体来讲就是借助LL Control PDU 报文完成链接双方CIG 参数同步的。LL Control PDU 中跟CIG/CIS 相关的控制报文总类展现以下，能够看到这些控制报文中包含了前面介绍的CIG和CIS 相关的全部参数：
LL Control PDU about CIG/CIS

注：咱们从前篇博文中知道Connected Isochronous PDU的Payload 最大为251 octets，前面咱们也知道Sub_Interval 的间隔时间最小为SE_Length = MPTM + T_IFS + MPTS + T_MSS = 2 * 1228 + 150 + 150 = 2756 us，由此能够大概计算Isochronous Connection 的最大通讯速率为 8 * 251 bytes / 2756 us = 728.6 Kbps，再借助LC3 音频编码方案，也能够传输清晰的音频流，若是只是单向听歌，还能够进一步提升Isochronous Connection 的最大通讯速率。

2.3 Connection management

链接创建以后，Master或Slave能够借助Link Layer Control Protocol (LLCP)，经过LL Control PDU，对链接进行管理控制，LL Control Protocol 支持的控制报文种类以下：
LL Control PDU opcodes
LL Control PDU 支持的控制方法描述以下：

  • Connection Update procedure：Master 向Slave 发送LL_CONNECTION_UPDATE_IND 报文来强制更新链接参数（好比connInterval, connSlaveLatency, connSupervisionTimeout 等），该过程只能由Master 发起。若是链接双方支持下面的链接参数请求过程，则应优先使用之，若是Slave 拒绝请求的链接参数，Master 能够再使用链接参数更新过程；
  • Connection Parameters Request procedure：Master 或Slave 均可以经过LL_CONNECTION_PARAM_REQ 报文向对端设备发送链接参数更新请求，对端设备返回LL_CONNECTION_PARAM_RSP 通知其请求结果。与前面链接参数更新过程不一样的是，这个链接参数请求过程不必定能成功；
  • Channel Map Update procedure：Master 经过LL_CHANNEL_MAP_IND 报文向Slave 发送新的Channel map；
  • ACL Termination procedure：处于链接状态时，Master 或Slave 可经过LL_TERMINATE_IND 报文自愿终止ACL链接；
  • LE Encryption procedure：对链路进行加密处理，LE 主要采用AES-128-CCM 加密算法，原理能够参考博文TLS 1.2/1.3 加密原理，Packet 中的MIC 实际就是CBC-MAC。若是要对链路启动加密，必须交换两个参数IV(Initialization Vector)和SKD(Session Key Diversifier)，以便计算出AES-128-CCM算法须要的随机数nonce和会话密钥SK，Master 和Slave 的IV、SKD 参数经过LL_ENC_REQ 和 LL_ENC_RSP 报文完成交换。计算出nonce 和SK 后，Master 和Slave 能够经过LL_START_ENC_REQ和LL_START_ENC_RSP 报文完成三次握手后启动加密过程。若是要在不断开链接的状况下更新加密密钥，须要先经过LL_PAUSE_ENC_REQ 和LL_PAUSE_ENC_RSP 报文完成三次握手后暂停加密过程，而后再次启动新的加密过程便可，暂停加密期间不该以未加密状态继续传输数据；
  • Feature Exchange procedure：进入链接状态后，Master 或Slave 能够分别经过LL_FEATURE_REQ 或 LL_SLAVE_FEATURE_REQ 报文请求交换当前支持的功能集（FeatureSet）连接层参数，对端设备会经过LL_FEATURE_RSP 报文响应该功能集交换请求；
  • Version Exchange procedure：进入链接状态后，Master 或Slave 能够经过LL_VERSION_IND 报文交换版本信息的连接层参数（好比companyID, subVerNum, linkLayerVer 等）；
  • LE Ping procedure：进入链接状态后，Master 或Slave 能够经过LL_PING_REQ 报文强制对端设备发送包含有效MIC 的LE ACL PDU来验证逻辑链路上传输消息的完整性，对端设备经过报文LL_PING_RSP 响应该请求；
  • Data Length Update procedure：进入链接状态后，Master 或Slave 能够经过LL_LENGTH_REQ 报文请求对端设备更新最大发送、接收的LL Data PDU Payload 长度和时间参数（好比connRemoteMaxTxOctets, connRemoteMaxRxOctets, connRemoteMaxTxTime, connRemoteMaxRxTime 等），对端设备经过报文LL_LENGTH_RSP 响应该请求；
  • PHY Update procedure：进入链接状态后，Master 或Slave 能够经过LL_PHY_REQ 报文请求对端设备更改ACL 链接所使用的PHY（好比更改成LE 1M PHY、LE 2M PHY、LE Coded PHY等）参数（该过程不影响关联的CIG使用的PHY）。若是是Master 发起请求则Slave 使用LL_PHY_RSP 报文响应，若是是Slave 发起请求则Master 使用LL_PHY_UPDATE_IND 报文响应；
  • Minimum Number Of Used Channels procedure：进入链接状态后，Slave 能够经过LL_MIN_USED_CHANNELS_IND 报文请求Master 在给定PHY上使用最小通道数，该过程只能由Slave 发起；
  • Constant Tone Extension Request procedure：进入链接状态后，Master 或Slave 能够经过LL_CTE_RSP 报文请求对端设备发送包含CTE(Constant Tone Extension)的Packet，以启用室内定位功能，对端设备经过LL_CTE_RSP 报文响应；
  • Periodic Advertising Sync Transfer procedure：进入链接状态后，Master 或Slave 能够经过LL_PERIODIC_SYNC_IND 报文将同步到periodic advertising train 须要的同步信息传输给对端设备；
  • Sleep Clock Accuracy Update procedure：进入链接状态后，Master 或Slave 能够经过LL_CLOCK_ACCURACY_REQ 报文请求查询对端设备的睡眠时钟精度，也可通知对端设备己方的睡眠时钟精度，对端设备使用LL_CLOCK_ACCURACY_RSP 报文响应；
  • Connected Isochronous Stream Creation procedure：进入链接状态，且在Master 已经配置包含CIS 的CIG 后，Master 能够经过LL_CIS_REQ 报文请求在Master 与 Slave 之间建立CIS，Slave 若是接收建立CIS 的请求则回复LL_CIS_RSP 报文。Master 接收到来自Slave 的LL_CIS_RSP 回复后，向Slave 回复LL_CIS_IND 报文来建立CIS，并开始发送、接收CIS Packet；
  • Connected Isochronous Stream Termination procedure：处于链接状态时，Master 或Slave 可经过LL_CIS_TERMINATE_IND 报文自愿终止已创建的CIS；
  • Power Control Request procedure：处于链接状态时，Master 或Slave 可经过LL_POWER_CONTROL_REQ 报文请求对端设备将其指定PHY上的Tx power 调整到给定值，对端设备使用LL_POWER_CONTROL_RSP 报文回复该请求（这个功率控制过程只影响当前链接链路，不影响其它已链接连接）；
  • Power Change Indication procedure：处于链接状态时，Master 或Slave 在power level 发生改变时，经过LL_POWER_CHANGE_IND 报文通知对端设备己方的Tx Power 改变了。

更多文章：

联系我们 沪ICP备13005482号-10