基于 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 由发起态随机生成
首先看看连接态的数据包的 PDU 组成格式：
对于 Connection 的包组成，主要关注的 PDU 域，依然是由 Header + Payload 组成，不一样的是，后面跟了一个可选的 MIC，这个只有在加密传送的时候才会有这个尾巴。
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，对端才会开窗继续来收数据。
当 Connection 的包体中 LLID 是 01'b 或者 10'b 的时候，说明这个是个数据包（L2CAP的）。那么此刻，Payload 域的内容，对于 Link Layer 来说，就是裸数据了，数据长度由 Header 的 Length 决定（8 bits）。这种包比较简单。
控制 PDU （也成为 LLCP）主要用于建立连接后的一些参数设置，流程交互等等：
当 Connection 的包体中 LLID 是 11'b 的时候，说明这个是个控制包（LL Control PDU）。
那么此刻的 Payload 的含义便与数据包不同，有 Opcode 和 CtrData 构成。
不同的 Opcode 代表了不同的控制包：
OpcodeControl PDU NameDescription0x00 LL_CONNECTION_UPDATE_IND更新链接参数0x01LL_CHANNEL_MAP_IND更新链接的 Channel Map0x02LL_TERMINATE_IND断开连接请求0x03 LL_ENC_REQ加密流程相关交互0x04 LL_ENC_RSP0x05 LL_START_ENC_REQ0x06 LL_START_ENC_RSP0x07 LL_UNKNOWN_RSP收到未知的 LLCP 后的回复0x08 LL_FEATURE_REQ请求交换 Feature 的交互0x09 LL_FEATURE_RSP0x0A LL_PAUSE_ENC_REQ重启加密流程相关交互0x0B LL_PAUSE_ENC_RSP0x0C LL_VERSION_IND交互 Version0x0DLL_REJECT_IND拒绝请求0x0E LL_SLAVE_FEATURE_REQSlave 请求 Feature0x0F LL_CONNECTION_PARAM_REQ更新链接参数0x10 LL_CONNECTION_PARAM_RSP0x11 LL_REJECT_EXT_IND扩展类型的拒绝请求0x12LL_PING_REQ加密后的 PING 流程交互0x13 LL_PING_RSP0x14 LL_LENGTH_REQ更新空口数据长度0x15 LL_LENGTH_RSP0x16 LL_PHY_REQPHY 更新相关交互0x17 LL_PHY_RSP0x18 LL_PHY_UPDATE_IND0x19 LL_MIN_USED_CHANNELS_INDChannels 相关的配置All other values Reserved for Future Use预留不同的 Opcode 指定了不同的 包体，包体中包含的 CtrData 也不尽相同，这里分析几个，其他的留给各位看官自行分析：
这个 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 先睹为快。
