BLE（8）—— 连接态数据包组成（ Connection Packets PDUs）

基于 BLE 5.1 协议 Core Spec。

 

目录

0、DATA CHANNEL PDU

0.1、Header

1、LL DATA PDU

2、LL Control PDU

2.1、LL_CHANNEL_MAP_IND

---

连接态的数据包我们统称为  Data Channel PDU ，与  Advertising Channel PDU 不同，Data Channel PDU 允许数据在除了 37、38、39信道上的其他的 37 个信道上进行数据传输，根据用途，又将其分为两种：

1、LL Data PDU：纯数据包

2、LL Control PDU：控制包

纯数据包的意义在于，连接的双方进行数据发送，包中承载的是 raw data。

控制包的含义在于，在连接建立后，用于控制和交互有诸多的连接态的因素。比如，启动加密，连接参数更新，数据包长度更新，收发数据的 PHY 更新，发送数据的 Channel Map 的更新，等等。

 

注：这里只讨论 PDU 域的内容，AA 由发起态随机生成

 

 

0、DATA CHANNEL PDU

首先看看连接态的数据包的 PDU 组成格式：

 

对于 Connection 的包组成，主要关注的 PDU 域，依然是由 Header + Payload 组成，不一样的是，后面跟了一个可选的 MIC，这个只有在加密传送的时候才会有这个尾巴。

 

0.1、Header

Connection 的这个 Header 与 Advertising 的 Header 是不一样的，AA 用于区分了这个是 Advertising 还是 Connection 的包。

接下来分析这个 Header 吧：

LLID ： 用于区分这个 Connection 的包是普通的数据包（L2CAP 的起始/连续/空包），还是 Control PDU

NESN：下一个期望的对端包的 Sequence Number

SN：当前包的 Sequence Number

MD：是否有 More Data

RFU：预留

Length：Playload （含 MIC） 的数据长度，单位是字节

NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传，后面详解。

MD 决定了后面是否跟有更多的数据。有了这个 MD，对端才会开窗继续来收数据。

 

1、LL DATA PDU

当 Connection 的包体中 LLID 是 01'b 或者 10'b 的时候，说明这个是个数据包（L2CAP的）。那么此刻，Payload 域的内容，对于 Link Layer 来说，就是裸数据了，数据长度由 Header 的 Length 决定（8 bits）。这种包比较简单。

 

2、LL Control PDU

控制 PDU （也成为 LLCP）主要用于建立连接后的一些参数设置，流程交互等等：

当 Connection 的包体中 LLID 是 11'b 的时候，说明这个是个控制包（LL Control PDU）。

那么此刻的 Payload 的含义便与数据包不同，有 Opcode 和 CtrData 构成。

不同的 Opcode 代表了不同的控制包：

Opcode	Control PDU Name	Description
0x00	LL_CONNECTION_UPDATE_IND	更新链接参数
0x01	LL_CHANNEL_MAP_IND	更新链接的 Channel Map
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	收到未知的 LLCP 后的回复
0x08	LL_FEATURE_REQ	请求交换 Feature 的交互
0x09	LL_FEATURE_RSP
0x0A	LL_PAUSE_ENC_REQ	重启加密流程相关交互
0x0B	LL_PAUSE_ENC_RSP
0x0C	LL_VERSION_IND	交互 Version
0x0D	LL_REJECT_IND	拒绝请求
0x0E	LL_SLAVE_FEATURE_REQ	Slave 请求 Feature
0x0F	LL_CONNECTION_PARAM_REQ	更新链接参数
0x10	LL_CONNECTION_PARAM_RSP
0x11	LL_REJECT_EXT_IND	扩展类型的拒绝请求
0x12	LL_PING_REQ	加密后的 PING 流程交互
0x13	LL_PING_RSP
0x14	LL_LENGTH_REQ	更新空口数据长度
0x15	LL_LENGTH_RSP
0x16	LL_PHY_REQ	PHY 更新相关交互
0x17	LL_PHY_RSP
0x18	LL_PHY_UPDATE_IND
0x19	LL_MIN_USED_CHANNELS_IND	Channels 相关的配置
All other values	Reserved for Future Use	预留

不同的 Opcode 指定了不同的 包体，包体中包含的 CtrData 也不尽相同，这里分析几个，其他的留给各位看官自行分析：

 

2.1、LL_CHANNEL_MAP_IND

这个 LLCP 代表了咱们链接双方需要更新通信信道的 MAP 了（默认的，一共有 37 个 Channels），他的 CtrData 为：

包含了两个玩意：

ChM：5个字节，40 个 bits，代表了 40 个 channels，更新的时候，要用的信道写 1'b 不要的写 0'b；

Instant：代表在多少个 Event 的时候，大家一起更新这个 Channels；

Instant 这个参数，在很多的  LLCP 都有，在建立连接后，双方都统计一个变量，叫 Event Counter，代表当前经历了多少个 Connection Event（CE），由于空中的连接，具有不确定性，所以在更新的时候，并不是立马进行更新，而是协商好一个固定的时刻（以 Event Counter 来算），大家一起到那个时刻进行更新。比如，当前的 Event Counter 是 245，则发送这个 LLCP 的时候，可能填充的 Instant 就是 280，总之，是一个未来的时间点。（Core Spec 规定，这个 Instant 最小是未来的第 6 个 Event Counter，如果太小，在一个密集的时间内，如果出现了链路质量不好，很多重传，那么很可能在预期的时间点，对端还没有接收到包，等接收到了后，Event Counter 都错过了，导致双方有些参数不一样，所以如果出现这情况，收到过期的 LLCP 后，会上报 Instant Passed，直接断联）

好了，其他的 Control PDU 呢，在今后的交互分析中在仔细分析了，有兴趣的看官可以官网下载 Core Spec 先睹为快。