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

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

欢迎大家加入2022届数字IC交流群，QQ群号 1060380138
版权声明：本文为CSDN博主「流云IoT」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。原文链接：https://blog.csdn.net/m0_37621078/article/details/107724799

前言

前篇博文LE States and Packets[1] 已经介绍了LE 设备在不同通信模式下承担不同的角色，为了方便管理蓝牙设备在多个角色间的切换，链路层使用了状态机来管理蓝牙当前的状态及该状态下支持的通信模式。同时，也介绍了BLE 链路层的两种基本报文格式，以及在不同物理信道上传输时PDU (Protocol Data Unit) 结构的差异。

LE Link Layer States and transport architecture

BLE 设备链路层的报文是上层应用数据的载体，也是通信双方实现无线传输的基础，了解了这些基本报文结构，接下来看通信双方如何传输这些报文。

一、Broadcast communication

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

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

Advertising event types, PDUs used, and allowable response PDUs

1.1 Advertiser — Scanner

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

下图给出了基本的广播通信过程示意图，扫描者需要在相同的广播信道才能接收到广播报文，因此扫描窗口的时间一般大于一次广播事件（广播者在所有被使用的广播信道上依次发送广播报文的过程，右图给出了广播事件开始与结束的标识，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 的不同而避开相互干扰。

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

Active and passive scanning for Legacy Advertising PDU

前篇博客介绍过，Legacy Advertising PDU 可以承载的广播数据最长为31 字节，如果想承载更多的广播数据，可以使用Extended Advertising PDU，不仅单个报文可承载最大254 字节广播数据，还可借助AUX_CHAIN_IND 报文在后面链接更多广播数据。Secondary Advertising PDU 都靠ADV_EXT_IND 报文引导，使用扩展广播报文的主动扫描与被动扫描过程图示如下：

Active and passive scanning for Extended Advertising PDU

注：我们从前篇博文中知道非扩展广播报文的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，通信速率依然比较低，且因为单向通信、不加密传输、没有确认应答机制，广播通信属于不可靠通信。

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

前篇博客介绍过，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），Initiator 向目标设备发送AUX_CONNECT_REQ 并接收响应的过程图示如下：

Connectable directed advertising event

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[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

设备A 向周围广播周期同步报文AUX_SYNC_IND ，并与设备B 建立BIG synchronizes，传输BIS Data Packet 的过程图示如下：

Device B synchronizes with a BIG

注：我们从前篇博文中知道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 根据需求配置，同一时刻只能配置一种）：

链路层应处理所有设备的扫描和连接请求（即未使用白名单），这是重置时的默认设置；
链路层应处理来自所有设备的连接请求，但仅处理来自白名单中设备的扫描请求；
链路层应处理来自所有设备的扫描请求，但仅处理来自白名单中设备的连接请求；
链路层应仅处理来自白名单中设备的扫描和连接请求。

Scanner filter policy

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

链路层应处理所有广播和扫描响应报文（即未使用白名单），这是重置时的默认设置；
链路层应仅处理白名单中设备的广播和扫描响应报文。

Initiator filter policy

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

链路层应忽略白名单，并处理Host 指定的特定单个设备中的可连接广播报文；
链路层应处理白名单中所有设备的可连接广播报文。

Periodic sync establishment filter policy

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

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

二、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 和 isochronous event 提供了Channel Selection algorithm #2，也即ACL 连接事件可以使用两种信道选择算法中的任何一种，周期同步事件和 ISO 等时事件只能使用第二代信道选择算法，CSA #2还可以为每个子事件生成信道索引，整个计算过程比较复杂，本文只介绍CSA #1 的原理，想详细了解CSA #2 可以参考Core_v5.2—page2988）：

Block diagram of Channel Selection algorithm #1 & #2

Channel Selection algorithm #1 主要分为两个步骤：

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

前篇博文Data Physical Channel PDU[3] 部分已经介绍了连接成功建立后的报文传输过程，如何通过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

设备A 与设备B 之间在建立ACL 连接后，创建CIS 并传输CIS Data PDU 的过程图示如下：

Device A establishes a CIS with a slave

注：我们从前篇博文中知道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 Link Layer Control Protocol

连接建立之后，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 update

Connection Parameters Request procedure：Master 或Slave 都可以通过LL_CONNECTION_PARAM_REQ 报文向对端设备发送连接参数更新请求，对端设备返回LL_CONNECTION_PARAM_RSP 通知其请求结果。与前面连接参数更新过程不同的是，这个连接参数请求过程不一定能成功；

Slaver-initiated / Master-initiated Connection Parameters Request procedure

Channel Map Update procedure：Master 通过LL_CHANNEL_MAP_IND 报文向Slave 发送新的Channel map；

Channel map update

ACL Termination procedure：处于连接状态时，Master 或Slave 可通过LL_TERMINATE_IND 报文自愿终止ACL连接；

Disconnect from master / Slave

LE Encryption procedure：对链路进行加密处理，LE 主要采用AES-128-CCM 加密算法，原理可以参考博文TLS 1.2/1.3 加密原理[4]，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 报文完成三次握手后暂停加密过程，然后再次启动新的加密过程即可，暂停加密期间不应以未加密状态继续传输数据；

Start and restart LE Encryption procedure

Feature Exchange procedure：进入连接状态后，Master 或Slave 可以分别通过LL_FEATURE_REQ 或 LL_SLAVE_FEATURE_REQ 报文请求交换当前支持的功能集（FeatureSet）链接层参数，对端设备会通过LL_FEATURE_RSP 报文响应该功能集交换请求；

Master / Slave Feature Exchange procedure

Version Exchange procedure：进入连接状态后，Master 或Slave 可以通过LL_VERSION_IND 报文交换版本信息的链接层参数（比如companyID, subVerNum, linkLayerVer 等）；

Master / Slave Version Exchange procedure

LE Ping procedure：进入连接状态后，Master 或Slave 可以通过LL_PING_REQ 报文强制对端设备发送包含有效MIC 的LE ACL PDU来验证逻辑链路上传输消息的完整性，对端设备通过报文LL_PING_RSP 响应该请求；

Successful LE Ping

Data Length Update procedure：进入连接状态后，Master 或Slave 可以通过LL_LENGTH_REQ 报文请求对端设备更新最大发送、接收的LL Data PDU Payload 长度和时间参数（比如connRemoteMaxTxOctets, connRemoteMaxRxOctets, connRemoteMaxTxTime, connRemoteMaxRxTime 等），对端设备通过报文LL_LENGTH_RSP 响应该请求；

Data length update

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 报文响应；

Master-initiated / Slave-initiated PHY Update procedure

Minimum Number Of Used Channels procedure：进入连接状态后，Slave 可以通过LL_MIN_USED_CHANNELS_IND 报文请求Master 在给定PHY上使用最小通道数，该过程只能由Slave 发起；

Requesting minimum number of used channels

Constant Tone Extension Request procedure：进入连接状态后，Master 或Slave 可以通过LL_CTE_RSP 报文请求对端设备发送包含CTE(Constant Tone Extension)的Packet，以启用室内定位功能，对端设备通过LL_CTE_RSP 报文响应；

Master or slave-initiated Constant Tone Extension Request procedure

Periodic Advertising Sync Transfer procedure：进入连接状态后，Master 或Slave 可以通过LL_PERIODIC_SYNC_IND 报文将同步到periodic advertising train 需要的同步信息传输给对端设备；

Periodic Advertising Sync Transfer by scanner / advertiser

Sleep Clock Accuracy Update procedure：进入连接状态后，Master 或Slave 可以通过LL_CLOCK_ACCURACY_REQ 报文请求查询对端设备的睡眠时钟精度，也可通知对端设备己方的睡眠时钟精度，对端设备使用LL_CLOCK_ACCURACY_RSP 报文响应；

Device A requests SCA from Device B

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；