Low Energy Controller——Air interface packets（3）

DATA PHYSICAL CHANNEL PDU 

数据物理信道PDU结构规范

1. 基础构成
   数据物理信道PDU包含以下部分：

   • 头部：16位或24位

   • 有效载荷：可变长度

   • 可选字段：消息完整性校验（MIC）字段

2. 结构图示
   具体数据结构详见图2.24

数据物理信道PDU的Header字段如图2.25所示

头部字段规范

1. 结构组成
   16位或24位头部字段由以下字段构成：

   • 16位头部：包含6个字段

   • 24位头部：包含7个字段
     （具体字段定义详见表2.19）

2. 消息完整性校验（MIC）字段约束

   • 禁止场景：

     • 未加密的ACL连接

     • 加密ACL连接中零长度载荷的数据信道PDU

数据物理信道PDU技术规范

1. 消息完整性校验（MIC）字段

   • 强制条件：

     • 加密的ACL连接

     • 数据信道PDU具有非零长度载荷

   • 计算标准：按照[卷6]E部分第1节规定执行

2. 有效载荷格式规则

   • LLID=0b01/0b10：载荷包含LL数据PDU（定义见第2.4.1节）

   • LLID=0b11：载荷包含LL控制PDU（定义见第2.4.2节）

3. 头部控制字段定义

   • NESN/SN位：参见第4.5.9节

   • MD位：参见第4.5.6节

   • CP（CTEInfo存在）位：

     • 0：头部无CTEInfo字段，数据包无恒定频率扩展

     • 1：头部含CTEInfo字段，数据包包含恒定频率扩展

4. 长度字段规范

   • 计量范围：0-255个八位组

   • 载荷限制：≤251个八位组

   • MIC长度：固定4个八位组

5. CTEInfo字段传输约束

   • 存在条件：由CP字段指示

   • 功能定义：参见第2.5.2节

   • 传输前提：确认对端设备支持"接收恒定频率扩展"功能（第4.6.22节）

技术说明：

• 支持发送含CTEInfo字段PDU的控制器，不一定能接收此类PDU，反之亦然

• 在这个版本的规范中，请求远程设备发送包含CTEInfo字段的数据包的唯一方法是通过恒定音调扩展请求过程。

LL Data PDU 

LL数据PDU技术规范

1. 基础定义
   LL数据PDU是用于传输L2CAP数据的数据信道PDU，其头部LLID字段必须设置为：

   • 0b01

   • 或 0b10

2. 空PDU特殊定义

   • 识别特征：

     • LLID=0b01

     • Length=0b00000000

   • 应用场景：
     中心设备（Central）链路层可发送空PDU至外围设备（Peripheral），以触发其响应任意类型的数据物理信道PDU（包括空PDU）

3. 非空PDU约束

   • 禁止条件：
     LLID=0b10时：

     • 长度字段不得为0

     • 建议不小于4

4. HCI数据包处理规则

   • 特殊场景：
     当链路层收到以下HCI ACL数据包时：

     • Data_Total_Length=0b00000000

     • Packet_Boundary_Flag=0b00（起始分片）

   • 处理要求：
     必须与后续分片组合为：

     • LLID=0b10

     • 非零长度的PDU
       （注：禁止直接透传该分片）

LL Control PDU

LL控制PDU是用于控制链路层连接的数据物理信道PDU。

LL控制PDU的有效载荷字段如图2.26所示。

LL控制PDU（链路层控制协议数据单元）规范解析：

1. 长度字段限制

   • 禁止空载荷：LL控制PDU的Length字段（长度字段）不得设置为全零（0b00000000），即必须包含有效载荷。

2. 载荷结构

   • 固定组成：载荷由两部分组成：

     • Opcode（操作码）：标识PDU类型（具体定义参见表2.20）。

     • CtrData（控制数据）：内容与长度由Opcode决定，同一Opcode对应的CtrData长度固定。

3. 字段取值范围规则

   • 明示范围优先：若CtrData内某字段定义了有效值范围或约束（如“字段X必须小于字段Y”），则超出范围的值均保留供未来扩展。

   • 间接引用：取值范围可直接在对应PDU章节中定义，或通过引用其他章节间接确定（例如2.4.2.1节的WinSize字段范围取决于4.5.3节的transmitWindowSize）。

   • 未定义即全有效：若字段未指定范围，则所有取值均合法。

4. 数据类型默认规则

   • 无符号整数：除非特殊声明，CtrData中所有整数字段均按无符号数解析。

LL控制PDU（链路层控制协议数据单元）接收处理规则

1. 收到不支持或保留的PDU

   • 响应要求：若收到不被支持或保留供未来使用的LL控制PDU，链路层必须回复LL_UNKNOWN_RSP PDU。

   • 字段匹配：该响应的UnknownType字段需设置为原PDU中的Opcode值。

2. 收到长度或字段无效的PDU

   • 容错处理：若PDU的长度错误或CtrData字段值无效，链路层可选择以下两种行为：

     • 继续执行流程：按实现自定义方式处理（例如：忽略超长部分的额外数据，或将越界字段调整为最近的有效值）。

     • 终止并响应：若不继续流程，必须回复以下之一：

       • LL_UNKNOWN_RSP PDU（UnknownType字段设为原Opcode值）。

       • LL_REJECT_IND或LL_REJECT_EXT_IND PDU（若流程允许，且后者需将RejectOpcode字段设为原Opcode值）。

LL_CONNECTION_UPDATE_IND

CtrData字段的格式如图2.27所示。

LL_CONNECTION_UPDATE_IND 控制数据（CtrData）字段说明

该PDU的CtrData包含以下六个字段，各字段定义及计算规则如下：

1. WinSize（窗口大小）

   • 作用：表示transmitWindowSize（传输窗口大小），定义见第4.5.3节。

   • 计算方式：transmitWindowSize = WinSize × 1.25 ms。

2. WinOffset（窗口偏移）

   • 作用：表示transmitWindowOffset（传输窗口偏移量），定义见第4.5.3节。

   • 计算方式：transmitWindowOffset = WinOffset × 1.25 ms。

3. Interval（连接间隔）

   • 作用：表示connInterval（连接间隔），定义见第4.5.1节。

   • 计算方式：connInterval = Interval × 1.25 ms。

4. Latency（从设备延迟）

   • 作用：表示connPeripheralLatency（外围设备延迟），定义见第4.5.1节。

   • 计算方式：connPeripheralLatency = Latency（直接取值，无单位转换）。

5. Timeout（监督超时）

   • 作用：表示connSupervisionTimeout（连接监督超时），定义见第4.5.2节。

   • 计算方式：connSupervisionTimeout = Timeout × 10 ms。

6. Instant（生效时刻）

   • 作用：表示连接参数更新的生效时间点，具体定义见第5.1.1节。

   • 说明：该字段直接引用协议规定的时刻值，无单位转换。

 LL_CHANNEL_MAP_IND

CtrData字段的格式如图2.28所示。

LL_CHANNEL_MAP_IND 控制数据（CtrData）字段说明

该PDU的CtrData包含以下两个字段：

1. ChM（信道映射）字段

   • 作用：标识已使用和未使用的数据信道。

   • 编码规则：

     • 每个数据信道对应一个比特位，比特位置由数据信道索引决定（索引定义见第1.4.1节）。

     • 比特值为1表示信道可用，0表示不可用。

   • 格式一致性：与CONNECT_IND PDU中的ChM字段格式完全一致（参见第2.3.3.1节）。

2. Instant（生效时刻）字段

   • 作用：指定信道映射更新的生效时间点，具体规则见第5.1.2节。

   • 说明：该字段为绝对时间参考值，无单位转换要求。

关键点解析

• 信道映射原理：

  • 信道索引从0开始，例如最低有效位（LSB）对应索引0的信道，依次类推。

  • 例如：ChM = 0x00000007（二进制...00000111）表示索引0、1、2的信道可用，其余不可用。

• 与CONNECT_IND的关联：确保信道映射格式在连接建立（CONNECT_IND）和动态更新（CHANNEL_MAP_IND）时保持一致。

• 时间控制：Instant字段确保信道切换在两端设备同步的时间点执行，避免通信中断

LL_TERMINATE_IND

CtrData字段的格式如图2.28所示。

该PDU的CtrData仅包含一个字段：

1. ErrorCode（错误码）字段

   • 作用：向对端设备通知连接即将终止的原因。

   • 编码规则：

     • 错误码的具体定义需参考蓝牙核心规范 [Vol 1] Part F（控制器错误码） 部分。

     • 每个错误码对应特定的连接终止原因（例如超时、资源不足等）。

关键点解析

• 单字段结构：此PDU为极简设计，仅通过ErrorCode传递终止原因，无附加参数。

• 错误码权威性：必须严格遵循蓝牙官方错误码表（如0x08表示连接超时，0x13表示远程用户终止等）。

• 行为触发：发送此PDU后，链路层应立即终止连接，无需等待确认。

示例场景

• 若因检测到重复ACK超时（错误码0x22），设备会发送：

  LL_TERMINATE_IND(ErrorCode = 0x22)  

LL_ENC_REQ

CtrData字段的格式如图2.28所示。

LL_ENC_REQ 控制数据（CtrData）包含以下四个字段：

• Rand（随机数）：

  • 应由 主机（Host） 提供，并与 EDIV 配合使用（参见[卷3] H部第2.4.4节）。

  • 该字段包含一个随机数。

• EDIV（加密分散因子）：

  • 该字段包含 加密分散因子（Encrypted Diversifier）。

• SKD_C（中央设备会话密钥分散因子）：

  • 该字段包含 中央设备（Central） 生成的 会话密钥分散因子 部分。

• IV_C（中央设备初始化向量）：

  • 该字段包含 中央设备（Central） 生成的 初始化向量（Initialization Vector） 部分。

LL_ENC_REQ 是 Bluetooth Low Energy (BLE) 链路层（Link Layer）的一个控制命令，用于在加密连接建立过程中启动加密。它的主要作用是请求对通信链路进行加密，并传递加密所需的参数。

LL_ENC_REQ 的作用

1. 发起加密请求

   • 由中央设备（Central，如手机）发送给外围设备（Peripheral，如蓝牙耳机），请求对当前BLE连接进行加密。

   • 该命令携带加密所需的参数，供外围设备计算会话密钥（Session Key）。

2. 传递加密参数

   • Rand：随机数，用于生成长期密钥（LTK）的派生。

   • EDIV（Encrypted Diversifier）：加密多样化因子，用于识别不同的加密会话。

   • SKD_C（Session Key Diversifier - Central）：中央设备提供的会话密钥多样化因子，用于生成临时会话密钥。

   • IV_C（Initialization Vector - Central）：中央设备提供的初始化向量，用于加密算法的初始状态设置。

3. 触发加密流程

   • 外围设备收到 LL_ENC_REQ 后，会使用这些参数结合自己的 LTK（Long Term Key） 计算会话密钥，并回复 LL_ENC_RSP（加密响应）。

   • 随后，双方会进行 LL_START_ENC 流程，正式启用加密通信。

典型应用场景

• BLE 配对后的加密通信（如数据传输、身份认证）。

• 重新连接时的快速加密恢复（利用 EDIV 和 Rand 快速重建会话密钥）。

LL_ENC_RSP

CtrData字段的格式如图2.28所示。

L_ENC_RSP控制数据（CtrData）包含两个字段：

1. SKD_P字段

   • 应包含外围设备（Peripheral）部分的会话密钥多样化因子（session key diversifier）

   • 用于与中央设备（Central）的SKD_C共同生成最终的会话加密密钥

2. IV_P字段

   • 应包含外围设备（Peripheral）部分的初始化向量（initialization vector）

   • 用于与中央设备的IV_C组合，为加密算法提供初始状态参数

LL_ENC_RSP 的作用

1. 响应加密请求

   • 由外围设备（Peripheral）发送给中央设备（Central），作为对 LL_ENC_REQ 的响应。

   • 该命令携带外围设备计算的加密参数，供双方最终确定会话密钥。

2. 传递加密参数

   • SKD_P（Session Key Diversifier - Peripheral）：外围设备提供的会话密钥多样化因子，与 SKD_C 共同用于生成临时会话密钥。

   • IV_P（Initialization Vector - Peripheral）：外围设备提供的初始化向量，与 IV_C 结合用于加密算法的初始状态设置。

3. 完成加密协商

   • 中央设备收到 LL_ENC_RSP 后，会结合 SKD_C、IV_C 和 SKD_P、IV_P 计算最终的会话密钥。

   • 随后，双方通过 LL_START_ENC 命令正式启用加密通信。

LL_START_ENC_REQ

LL_START_ENC_REQ PDU没有CtrData字段

LL_START_ENC_RSP

LL_START_ENC_RSP PDU没有CtrData字段。

LL_UNKNOWN_RSP

CtrData字段的格式如图2.32所示。

LL_UNKNOWN_RSP CtrData由一个字段组成：

•UnknownType应包含接收到的LL控制PDU的操作码字段值。

LL_FEATURE_REQ

CtrData字段的格式如图2.33所示。

LL_FEATURE_REQ 控制数据（CtrData）包含一个字段：

1. FeatureSet（功能集）字段

   • 应包含中央设备（Central）链路层（Link Layer）支持的功能集合

   • 具体功能定义遵循蓝牙核心规范第4.6节的描述

LL_FEATURE_RSP

CtrData字段的格式如图2.34所示。

LL_FEATURE_RSP控制数据（CtrData）结构解析：

1. 核心字段说明

   • FeatureSet[0]

     • 应包含中央设备与外围设备链路层共同支持的功能集合

     • 表示双方协商后最终可使用的功能子集

   • FeatureSet[1-7]

     • 应包含当前发送方（中央/外围设备）链路层独立支持的功能集合

     • 用于扩展能力通告（超出双方共同支持的范围）

2. 技术实现要点

   • 功能协商机制（基于第4.6节规范）：

     • 生效功能集 = 请求方(LL_FEATURE_REQ) ∩ 响应方(LL_FEATURE_RSP)

     • FeatureSet[0]即为该交集结果

   • 位域编码规则：

     • 每个FeatureSet字段为8字节（64bit）位图

     • 各bit对应具体功能（如bit0=LE加密支持，bit1=连接参数请求等）

3. 典型应用场景

   • 连接建立时的能力协商（确定可用PHY/数据长度等）

   • 动态功能更新（通过后续LL_FEATURE_REQ/RSP交换）

   • 兼容性保障（确保只启用双方支持的功能）

 LL_PAUSE_ENC_REQ

LL_PAUSE_ENC_REQ数据包没有CtrData字段。

LL_PAUSE_ENC_RSP

LL_PAUSE_ENC_RSP数据包没有CtrData字段。

LL_VERSION_IND

CtrData字段的格式如图2.35所示。

LL_VERSION_IND 控制数据（CtrData）结构解析：

字段说明

1. Version（版本号）字段

   • 表示蓝牙控制器（Controller）所支持的链路层规范版本

   • 具体版本号需参照《Assigned Numbers》文档中的编码规则

   • 注意：该字段仅表示硬件支持的协议基础版本，不代表支持该版本的全部功能

2. Company_Identifier（厂商标识）字段

   • 包含蓝牙控制器制造商的唯一公司标识码

   • 标准编码见《Assigned Numbers》中的"Company ID"列表

   • 例如：0x000D（德州仪器）、0x000A（Nordic Semiconductor）

3. Subversion（子版本号）字段

   • 提供蓝牙控制器实现的唯一版本标识

   • 由厂商自定义，用于区分不同硬件版本或固件修订

关键注意事项

• 版本号≠完整功能支持

  • 即使版本号显示支持某蓝牙标准（如5.3），仍需通过LL_FEATURE_REQ/RSP确认具体功能（如2M PHY是否真正启用）

• 版本号数值非线性

  • 更高的数值不直接代表更新的蓝牙标准（需查表映射真实版本）

协议作用

• 设备兼容性检查：识别对端设备的协议基础版本

• 故障排查：通过厂商ID和子版本号定位硬件来源

• 功能协商基础：需结合LL_FEATURE_REQ/RSP确定实际可用功能

LL_REJECT_IND 

CtrData字段的格式如图2.36所示。

ErrorCode应包含拒绝请求的原因；参见[第1卷]第F部分，控制器错误代码

LL_PERIPHERAL_FEATURE_REQ

CtrData字段的格式如图2.37所示。

L_PERIPHERAL_FEATURE_REQ 控制数据（CtrData）结构解析

字段说明

1. FeatureSet（功能集）字段

   • 包含外围设备（Peripheral）链路层（Link Layer）支持的功能集合

   • 具体功能定义遵循蓝牙核心规范第4.6节的位掩码编码规则

协议功能与作用

• 功能通告：外围设备主动向中央设备声明自身支持的高级功能（如LE Coded PHY、信道选择算法#2等）

• 协商基础：中央设备收到后，通过对比双方FeatureSet确定最终可用的功能交集

• 扩展应用：支持蓝牙5.0+的扩展功能协商（如周期广播、高精度距离测量等）

技术要点说明

1. 位域编码规则

   • 每个功能对应1个bit位（例如bit5=2M PHY支持）

   • 字段长度为8字节（64bit），未定义位保留为0

2. 与LL_FEATURE_REQ的区别

   命令	发起方	典型应用场景
   LL_FEATURE_REQ	Central	连接建立时中央设备发起功能协商
   LL_PERIPHERAL_FEATURE_REQ	Peripheral	外围设备主动更新或补充功能声明

3. 兼容性处理

   • 若中央设备不支持此命令，外围设备应回退到标准LL_FEATURE_RSP流程

LL_CONNECTION_PARAM_REQ

CtrData字段的格式如图2.38所示。

LL_CONNECTION_PARAM_REQ

控制数据（CtrData）字段详解

该命令用于外围设备（Peripheral）向中央设备（Central）请求更新连接参数，包含12个字段，用于协商连接间隔（Connection Interval）、延迟（Latency）、超时（Supervision Timeout）等关键参数。

1.核心连接参数字段

(1) Interval_Min（最小连接间隔）

• 定义：最小可接受的连接间隔（单位：1.25 ms）

• 计算方式：connInterval = Interval_Min × 1.25 ms

• 取值范围：6 (7.5ms) ~ 3200 (4000ms)

• 作用：确保设备不会因连接间隔过短而耗电过快

(2) Interval_Max（最大连接间隔）

• 定义：最大可接受的连接间隔（单位：1.25 ms）

• 计算方式：connInterval = Interval_Max × 1.25 ms

• 约束：必须 ≥ Interval_Min

• 作用：避免连接间隔过长导致数据延迟

(3) Latency（外设延迟）

• 定义：外围设备可跳过的连接事件次数（connPeripheralLatency）

• 计算方式：connPeripheralLatency = Latency

• 典型值：0（每次连接事件都响应）~ 499

• 作用：优化功耗（允许Peripheral在某些连接事件不唤醒）

(4) Timeout（监控超时）

• 定义：连接超时时间（单位：10 ms）

• 计算方式：connSupervisionTimeout = Timeout × 10 ms

• 约束：必须满足：

  Timeout × 10 ms > (1 + Latency) × Interval_Max × 1.25 ms × 2

• 作用：检测连接是否丢失（超时未通信则断开）

2. 高级调度优化字段

(5) PreferredPeriodicity（偏好周期）

• 定义：建议连接间隔为某个值的倍数（单位：1.25 ms）

• 示例：

  • PreferredPeriodicity = 100 → 建议 connInterval 是 125ms (100×1.25ms) 的倍数

  • = 0 表示无偏好

• 约束：必须 ≤ Interval_Max

(6) ReferenceConnEventCount（参考连接事件计数）

• 定义：用于计算 Offset0~Offset5 的基准连接事件计数器（connEventCounter）

• 注意：与 LL_CONNECTION_UPDATE_IND 的 Instant 字段无关

(7) Offset0 ~ Offset5（锚点偏移建议值）

• 定义：建议的连接锚点（Anchor Point）偏移（单位：1.25 ms）

• 规则：

  • 按优先级降序排列（Offset0 最优，Offset5 最次）

  • 必须 < Interval_Max

  • 0xFFFF 表示无效

  • 有效值必须唯一且连续（无效值必须排在最后）

• 作用：优化连接事件调度，减少冲突

3. 典型应用场景

1. 低功耗优化

   • Peripheral 请求更长的 Interval_Max 和更高的 Latency 以节省电量

2. 低延迟通信

   • 设置较短的 Interval_Min 和 Latency=0 确保快速响应

3. 多设备共存

   • 通过 Offset0~Offset5 避免与其它BLE设备的连接事件冲突

4. 协议交互流程

1. Peripheral 发送 LL_CONNECTION_PARAM_REQ 提出参数建议

2. Central 回复 LL_CONNECTION_PARAM_RSP 接受或拒绝

3. 若接受，Central 通过 LL_CONNECTION_UPDATE_IND 生效新参数

5. 参数计算示例

Interval_Min = 16 (20ms)  
Interval_Max = 32 (40ms)  
Latency = 4  
Timeout = 100 (1000ms)  
PreferredPeriodicity = 8 (10ms倍数)  
Offset0 = 0 (首选无偏移)  
Offset1 = 16 (20ms偏移)  

生效条件：

• 实际 connInterval 会在 20~40ms 之间，且尽量是 10ms 的倍数

• Peripheral 最多可跳过 4 个连接事件

• 若 1s 内无通信，连接断开

LL_CONNECTION_PARAM_RSP

LL_CONNECTIONPARAM_RSP PDU的格式与LL_CONNECION_PARAM_REQ PDU的格式相同（见第2.4.2.16节）。

LL_REJECT_EXT_IND

CtrData字段的格式如图2.39所示。

LL_REJECT_EXT_IND 控制数据（CtrData）包含两个字段：

1. RejectOpcode（拒绝操作码）

   • 应包含被拒绝的 LL Control PDU（链路层控制协议数据单元）的操作码（Opcode）字段值。

   • 即指明具体拒绝的是哪个控制指令。

2. ErrorCode（错误代码）

   • 应包含 拒绝该 LL Control PDU 的原因。

   • 具体错误代码及描述可参考 [Vol 1] Part F（蓝牙核心规范卷1，F部分）的“Controller Error Codes（控制器错误代码）”列表。

该 PDU 的发送条件：

• 仅当对端链路层（Link Layer）支持“Extended Reject Indication（扩展拒绝指示）”功能（见第4.6节）时，才使用 LL_REJECT_EXT_IND。

• 如果对端不支持此功能，则应改用 LL_REJECT_IND PDU（见第2.4.2.14节）。

关键点说明：

• LL_REJECT_EXT_IND 提供了更详细的拒绝信息（包括错误码），而 LL_REJECT_IND 仅用于简单拒绝。

• 是否使用该 PDU 取决于对端设备的支持能力，需通过特性协商（Feature Exchange）确认。

LL_PING_REQ

LL_PING_REQ PDU没有CtrData字段。

LL_PING_REQ（Ping 请求） 是蓝牙低功耗（BLE）**链路层（Link Layer）**的一个控制协议数据单元（LL Control PDU），主要用于：

1. 主要功能

• 检测链路连接是否存活（Keep-Alive 机制）：

  • 发送方（Master/Slave）通过 LL_PING_REQ 询问对端设备是否仍在线并响应。

  • 对端设备收到后，必须回复 LL_PING_RSP，以确认链路正常。

2. 典型应用场景

• 防止连接超时断开：

  • 当链路长时间无数据交互时，蓝牙控制器可能因超时（Supervision Timeout）断开连接。

  • 通过定期发送 LL_PING_REQ，可保持连接活跃，避免意外断开。

• 诊断链路质量：

  • 若未收到 LL_PING_RSP，可能表明链路中断或对端设备无响应。

3. 数据格式

• LL_PING_REQ 是一个空 PDU（不包含额外数据），仅通过 Opcode（操作码） 标识其类型。

• 对应的响应 PDU 是 LL_PING_RSP（同样为空 PDU）。

4. 与其他 PDU 的区别

• LL_PING_REQ vs LL_REJECT_IND/LL_REJECT_EXT_IND：

  • LL_PING_REQ 用于链路保活，而 LL_REJECT_IND用于拒绝非法/不支持的 LL Control PDU。

• 与 L2CAP Ping 的区别：

  • LL_PING_REQ 是链路层的 Ping，而 L2CAP Ping（如 L2CAP_Echo_Req）是更高层的检测机制。

5. 规范要求

• 蓝牙核心规范（Bluetooth Core Specification）强制要求所有 BLE 设备必须支持 LL_PING_REQ/RSP。

• 如果设备收到 LL_PING_REQ 但未响应 LL_PING_RSP，可能被视为连接失效，触发超时断开。

LL_PING_RSP

LL_PING_RSP PDU没有CtrData字段

LL_LENGTH_REQ and LL_LENGTH_RSP

LL_LENGTH_REQ和LL_LENGTH_RSP PDU的CtrData字段格式如图2.40所示。

LL_LENGTH_REQ（长度请求） 和 LL_LENGTH_RSP（长度响应） 是蓝牙低功耗（BLE）链路层（Link Layer）的控制协议数据单元（LL Control PDU），用于动态协商数据包长度和传输时间，以提高通信效率。

1. 数据字段说明

LL_LENGTH_REQ 和 LL_LENGTH_RSP 的 CtrData 包含 4 个字段，分别表示 接收 和 发送 方向的最大数据长度和传输时间：

字段	说明	最小值
MaxRxOctets	发送方支持的 最大接收数据长度（字节）（对应 connMaxRxOctets）	≥ 27 字节
MaxRxTime	发送方支持的 最大接收时间（μs）（对应 connMaxRxTime）	≥ 328 μs
MaxTxOctets	发送方支持的 最大发送数据长度（字节）（对应 connMaxTxOctets）	≥ 27 字节
MaxTxTime	发送方支持的 最大发送时间（μs）（对应 connMaxTxTime）	≥ 328 μs

2. 功能作用

• 动态调整数据包长度（Data Length Extension, DLE）：

  • 允许设备在连接过程中协商更大的数据包长度（BLE 4.2+ 支持），提高吞吐量。

  • 例如，默认 BLE 数据包长度是 27 字节，但可以协商为 251 字节（BLE 5.0 最大支持）。

• 优化传输时间：

  • 调整 MaxRxTime 和 MaxTxTime 以适应更长的数据包传输时间。

3. 交互流程

1. Master/Slave 发送 LL_LENGTH_REQ

   • 携带自己的 MaxRxOctets、MaxRxTime、MaxTxOctets、MaxTxTime 参数。

2. 对端设备回复 LL_LENGTH_RSP

   • 同样携带自己的参数，双方协商最终使用的数据长度和时间。

3. 生效新参数

   • 协商成功后，双方采用 较小的 MaxRxOctets/MaxTxOctets 和 较小的 MaxRxTime/MaxTxTime 作为实际通信参数。

4. 最小值限制

• BLE 规范强制要求：

  • MaxRxOctets 和 MaxTxOctets 不得小于 27 字节（默认 BLE 数据包长度）。

  • MaxRxTime 和 MaxTxTime 不得小于 328 μs（对应 27 字节的传输时间）。

5. 典型应用场景

• BLE 4.2+ 数据长度扩展（DLE）：

  • 提高传输效率，减少协议开销（更少的分包）。

• BLE 高速模式（如 2M PHY、Coded PHY）：

  • 配合更大的数据包长度，提升吞吐量。

6. 与其他 PDU 的关系

• 与 LL_PING_REQ/RSP 的区别：

  • LL_PING_REQ/RSP 用于链路保活，而 LL_LENGTH_REQ/RSP 用于优化数据包长度。

• 与 LL_PHY_REQ/RSP 的关系：

  • LL_PHY_REQ/RSP 协商物理层参数（如 1M/2M PHY），而 LL_LENGTH_REQ/RSP 协商数据包长度。

LL_PHY_REQ and LL_PHY_RSP

LL_PHY_REQ和LL_PHY_RSP PDU的CtrData字段格式如图2.41所示。

LL_PHY_REQ 和 LL_PHY_RSP 控制数据（CtrData）解析

LL_PHY_REQ（物理层请求） 和 LL_PHY_RSP（物理层响应） 是蓝牙低功耗（BLE）链路层（Link Layer）的控制协议数据单元（LL Control PDU），用于动态协商通信的物理层（PHY）模式，以优化传输速率、功耗或抗干扰能力。

1. 数据字段说明

LL_PHY_REQ 和 LL_PHY_RSP 的 CtrData 包含 2 个字段，分别表示 发送（TX）和接收（RX） 方向支持的物理层模式：

字段	说明	位掩码（8 bits）	支持的 PHY 模式
TX_PHYS	发送方希望使用的 发送物理层模式（支持的 PHY 类型）	Bit 0 = 1	LE 1M PHY（传统 1 Mbps 模式）
		Bit 1 = 1	LE 2M PHY（高速 2 Mbps 模式）
		Bit 2 = 1	LE Coded PHY（长距离编码模式，S=2 或 S=8）
RX_PHYS	发送方希望使用的 接收物理层模式（支持的 PHY 类型）	同上	同上

规范要求：

• 至少设置 1 个 bit（不能全为 0），表示至少支持一种 PHY 模式。

• 如果设备支持多种 PHY，可以同时设置多个 bit（如 0x03 = 支持 1M 和 2M PHY）。

2. 功能作用

• 动态切换 PHY 模式（BLE 5.0+ 功能）：

  • 允许设备在连接过程中协商更高速率（2M PHY）或更长距离（Coded PHY）。

  • 例如：

    • 1M PHY（默认）：1 Mbps，兼容所有 BLE 设备。

    • 2M PHY（BLE 5.0+）：2 Mbps，提高传输速度，但距离较短。

    • Coded PHY（BLE 5.0+）：125 Kbps 或 500 Kbps（S=8 或 S=2），增强抗干扰能力，适合长距离通信。

• 优化功耗与性能：

  • 高速模式（2M）适合大数据传输，而 Coded PHY 适合低信噪比环境。

3. 交互流程

1. Master/Slave 发送 LL_PHY_REQ

   • 携带自己的 TX_PHYS 和 RX_PHYS 参数，表示支持的 PHY 模式。

2. 对端设备回复 LL_PHY_RSP

   • 同样携带自己的 TX_PHYS 和 RX_PHYS 参数。

3. 协商生效

   • 双方选择 共同支持的 PHY 模式（取交集）：

     • 例如：

       • 设备 A 支持 1M + 2M（TX_PHYS = 0x03），设备 B 支持 1M + Coded（TX_PHYS = 0x05）。

       • 最终协商结果为 1M PHY（0x01，唯一共同支持的 bit）。

4. 典型应用场景

• 高速数据传输（如固件升级、音频流）：使用 2M PHY 提高速率。

• 长距离通信（如智能家居设备）：使用 Coded PHY（S=8） 增强信号覆盖。

• 动态适应环境：在干扰较强时切换到 Coded PHY，在稳定环境下切回 1M/2M PHY

LL_PHY_UPDATE_IND

CtrData字段的格式如图2.42所示。

LL_PHY_UPDATE_IND（物理层更新指示） 是蓝牙低功耗（BLE）链路层（Link Layer）的控制协议数据单元（LL Control PDU），用于正式通知对端设备物理层（PHY）模式的切换。它通常在 LL_PHY_REQ/RSP 协商后发送，以确认最终的 PHY 切换时间和方式。

1. 数据字段说明

LL_PHY_UPDATE_IND 的 CtrData 包含 3 个字段：

字段	说明	位掩码（8 bits）	支持的 PHY 模式
PHY_C_TO_P	中心设备（Central）到外围设备（Peripheral）的 发送 PHY 模式	Bit 0 = 1	LE 1M PHY（1 Mbps）
		Bit 1 = 1	LE 2M PHY（2 Mbps）
		Bit 2 = 1	LE Coded PHY（S=2 或 S=8）
PHY_P_TO_C	外围设备（Peripheral）到中心设备（Central）的 发送 PHY 模式	同上	同上
Instant	PHY 切换的生效时刻（连接事件编号，见 Section 5.1.10）	16-bit 值	无位掩码

关键规则：

1. PHY 切换规则：

   • 如果 PHY 需要切换，则对应 bit 设为 1，其余 bit 设为 0（例如，切换到 2M PHY 则 PHY_C_TO_P = 0x02）。

   • 如果 PHY 保持不变，则对应字段设为 0。

   • 如果 PHY_C_TO_P 和 PHY_P_TO_C 均为 0，则表示 不切换 PHY，此时 Instant 字段保留（Reserved for Future Use）。

2. Instant（生效时刻）：

   • 表示 PHY 切换的具体连接事件编号（Connection Event Number），由 Instant 字段指定。

   • 设备必须在 Instant 指定的连接事件之后 立即应用新 PHY。

2. 功能作用

• 正式确认 PHY 切换：

  • 在 LL_PHY_REQ/RSP 协商后，由 Master（Central） 发送 LL_PHY_UPDATE_IND，通知 Slave（Peripheral）切换 PHY 的具体时间。

• 支持动态 PHY 调整：

  • 允许设备在连接过程中 动态切换 1M/2M/Coded PHY，以适应不同的传输需求（如速度 vs 距离）。

3. 交互流程示例

1. Master 发送 LL_PHY_REQ（请求切换到 2M PHY）。

2. Slave 回复 LL_PHY_RSP（同意切换到 2M PHY）。

3. Master 发送 LL_PHY_UPDATE_IND：

   • PHY_C_TO_P = 0x02（Central → Peripheral 使用 2M PHY）。

   • PHY_P_TO_C = 0x02（Peripheral → Central 使用 2M PHY）。

   • Instant = N（在连接事件 N 之后生效）。

4. 在 Instant 指定的连接事件后，双方开始使用 2M PHY 通信。

4. 注意事项

• BLE 5.0+ 功能：1M PHY 是必选的，但 2M/Coded PHY 需要双方支持 BLE 5.0。

• PHY 切换不可逆：一旦切换，除非再次协商，否则不会自动回退。

• 错误处理：

  • 如果 Instant 已过，设备应忽略该 PDU。

  • 如果 PHY 切换失败，可能触发 LL_UNKNOWN_RSP 或超时重传。

LL_MIN_USED_CHANNELS_IND

CtrData字段的格式如图2.43所示。

LL_MIN_USED_CHANNELS_IND（最小使用信道数指示） 是蓝牙低功耗（BLE）链路层（Link Layer）的控制协议数据单元（LL Control PDU），用于外围设备（Peripheral）向中心设备（Central）声明其在特定物理层（PHY）模式下要求的最小可用信道数。该机制主要用于优化 自适应跳频（AFH） 策略，确保通信可靠性。

1. 数据字段说明

LL_MIN_USED_CHANNELS_IND 的 CtrData 包含 2 个字段：

字段	说明	位掩码/取值范围	规范要求
PHYS	需要最小信道数限制的 PHY 模式（8-bit 掩码）	Bit 0 = LE 1M PHY	至少设置 1 个 bit（不能全为 0）
		Bit 1 = LE 2M PHY
		Bit 2 = LE Coded PHY
MinUsedChannels	指定 PHY 模式下要求的最小可用信道数（影响跳频算法）	2 ~ 37（含）	必须满足 2 ≤ N ≤ 37

2. 功能作用

（1）自适应跳频（AFH）的约束条件

• BLE 使用 37 个数据信道（Channel 0~36），通过跳频减少干扰。

• 外围设备可能因硬件限制（如射频性能）或法规要求（如日本无线电法），需要限制最小可用信道数，以确保通信稳定性。

• 中心设备收到该指示后，必须保证跳频信道数 ≥ MinUsedChannels，否则可能触发重协商或连接中断。

（2）多 PHY 模式的独立配置

• 外围设备可为不同 PHY 模式（如 1M/2M/Coded PHY）指定不同的最小信道数。

  • 示例：

    • 1M PHY 要求至少 20 个信道（PHYS=0x01, MinUsedChannels=20）。

    • 2M PHY 要求至少 10 个信道（PHYS=0x02, MinUsedChannels=10）。

3. 交互流程

1. 外围设备发送 LL_MIN_USED_CHANNELS_IND：

   • 声明其对特定 PHY 的最小信道数需求。

   • 示例数据

     PHYS = 0x01,           // 仅针对 1M PHY
     MinUsedChannels = 20   // 至少使用 20 个信道

2. 中心设备响应：

   • 调整跳频算法，确保可用信道数 ≥ MinUsedChannels。

   • 若无法满足（如信道干扰严重），可能触发 信道映射更新（LL_CHANNEL_MAP_IND） 或连接参数更新。

4. 注意事项

（1）取值范围限制

• MinUsedChannels 必须为 2~37：

  • 最小值 2：跳频至少需要 2 个信道才能避免单点故障。

  • 最大值 37：BLE 数据信道总数。

• 若设备要求 MinUsedChannels=37，表示 禁用跳频（固定使用全部信道），通常不符合规范。

（2）PHY 模式兼容性

• BLE 5.0+ 功能：2M/Coded PHY 的最小信道数需求仅适用于支持 BLE 5.0 的设备。

• 1M PHY 是所有设备的必选项。

（3）与信道映射的关系

• 中心设备通过 LL_CHANNEL_MAP_IND 通知外围设备实际使用的信道映射，该映射必须满足 MinUsedChannels 要求。

5. 典型应用场景

• 高干扰环境：外围设备要求更多信道以分散干扰风险。

• 法规合规：某些地区规定蓝牙设备必须使用至少 N 个信道（如日本要求 ≥ 15）。

• 硬件优化：射频性能较差的设备可能减少信道数以降低功耗。

LL_CTE_REQ

CtrData字段的格式如图2.44所示。

LL_CTE_REQ 是蓝牙5.1+引入的链路层控制协议数据单元（LLCPDU），用于主设备（Central）或从设备（Peripheral）向对端请求发送恒定时延扩展（Constant Tone Extension, CTE），以支持蓝牙测向（Direction Finding）功能（如AoA/AoD定位）。

1. 数据字段说明

字段	说明	取值范围/类型	单位/备注
MinCTELenReq	请求的CTE最小持续时间（长度）	2 ~ 20	以 8 µs 为单位（即实际时长=值×8 µs）
CTETypeReq	请求的CTE类型（决定CTE的发射方式和用途）	见表2.22（通常为1~3）

（1）MinCTELenReq（最小CTE长度请求）

• 物理意义：
  CTE是数据包末尾追加的一段无调制纯载波信号（频率固定），用于相位差测向。

  • 最小长度：2×8 µs = 16 µs（对应至少2个采样点）。

  • 最大长度：20×8 µs = 160 µs（蓝牙规范上限）。

• 典型值：

  • 定位精度要求高时，需更长的CTE（如160 µs）。

（2）CTETypeReq（CTE类型请求）

蓝牙规范（Table 2.22）定义的CTE类型：

Value	含义	技术细节
0	AoA (Angle of Arrival) 恒定时延扩展	- 接收端使用天线阵列测量信号到达角。 - 发射端发送连续CTE（无天线切换）。
1	AoD (Angle of Departure) 恒定时延扩展，1 µs时隙天线切换	- 发射端每 1 µs 切换一次天线，形成方向性辐射模式。 - 接收端通过相位差计算出发角。
2	AoD (Angle of Departure) 恒定时延扩展，2 µs时隙天线切换	- 发射端每 2 µs 切换一次天线（降低硬件要求）。 - 定位精度略低于1 µs模式。
3	保留（未来使用）	蓝牙规范未定义具体用途，禁止当前设备使用。

LL_CTE_RSP

LL_CTE_RSP PDU没有CtrData字段

LL_PERIODIC_SYNC_IND

CtrData字段的格式如图2.45所示。

LL_PERIODIC_SYNC_IND 是蓝牙5.0+中用于同步周期性广播（Periodic Advertising）与连接事件的链路层控制协议数据单元（LLCPDU），其核心功能是在已建立的连接中，将周期性广播的时间锚点与连接事件的锚点对齐，从而实现低功耗同步。以下是其字段和功能的详细解析：

1. 数据字段说明

字段	说明	取值范围/规则
ID	主机（Host）提供的标识符，供上层协议使用，蓝牙规范未定义具体含义。	任意值（由应用层决定）
SyncInfo	同步信息，格式与 AUX_SYNC_IND 相同（见Section 2.3.4.6），但时间偏移参考点为连接事件的锚点。	syncPacketWindowOffset 的零偏移无特殊意义。
connEventCount	连接事件计数器值，用于定位同步参考点。	需满足：currEvent - 2^14 < connEventCount < currEvent + 2^14 (mod 65536)
lastPaEventCounter	最近一次 AUX_SYNC_IND 的 paEventCounter 值。	必须与 SyncInfo 中的 PeriodicEventCounter 相等或相差1（模65536），或时间差≤5秒。
SID	指向周期性广播的广告集ID（Advertising SID）。	0x00~0x0F
AType	地址类型：0=公共地址，1=随机地址。	0 或 1
SCA	发送设备的睡眠时钟精度（Sleep Clock Accuracy），格式同 CONNECT_IND。	0~7（值越小精度越高，如0=±20 ppm）
PHY	周期性广播使用的PHY模式（1 bit掩码）。	Bit 0=LE 1M, Bit 1=LE 2M, Bit 2=LE Coded（见表2.21）
AdvA	广告者地址（若为可解析私有地址，需使用相同IRK生成的地址）。	公共地址或随机地址
syncConnEventCount	发送设备用于确定本PDU内容的连接事件计数器值。	必须是一个已接收对端数据包的连接事件（若为Peripheral，需用于同步锚点）。

2. 核心功能

（1）周期性广播与连接事件同步

• 问题背景：
  设备在连接状态下可能同时发送周期性广播（如Beacon），但两者时钟独立，导致功耗增加。

• 解决方案：
  LL_PERIODIC_SYNC_IND 将周期性广播的时序锚点（SyncInfo）与连接事件的锚点对齐，避免频繁唤醒。

（2）关键交互流程

1. 主从设备建立连接（必需前提）。

2. 主/从设备发送 LL_PERIODIC_SYNC_IND：

   • 通过 connEventCount 和 SyncInfo 关联周期性广播与连接事件。

   • 例如：主设备通知从设备，周期性广播的窗口偏移量基于连接事件N的锚点。

3. 接收方调整监听策略：

   • 根据同步信息，仅在预测的时间窗口内唤醒以接收周期性广播，降低功耗。

3. 字段约束与注意事项

（1）时间同步要求

• connEventCount 范围：
  必须与当前连接事件计数（currEvent）的差值在 ±214 范围内（模65536），确保时序可预测。

• lastPaEventCounter 一致性：
  必须与 SyncInfo.PeriodicEventCounter 严格匹配（或时间差≤5秒），避免同步失效。

（2）地址处理

• 可解析私有地址（RPA）：
  若广告地址为RPA，AdvA 字段必须使用 相同IRK生成的新RPA，以保护隐私。

（3）PHY模式限制

• 仅支持已启用的PHY模式（如设备不支持2M PHY，则对应bit必须为0）。

4. 典型应用场景

（1）低功耗传感器网络

• 传感器在连接状态下同步周期性广播（如温度数据），主机仅在同步后的时间窗口监听，节省电量。

（2）多设备广播同步

• 多个Beacon通过 LL_PERIODIC_SYNC_IND 将其广播时序对齐到同一连接事件，避免信道冲突。

5. 错误处理

• 无效 connEventCount：
  若超出 currEvent ± 2^14 范围，接收方应忽略该PDU。

• 不支持的PHY：
  接收方可回复 LL_REJECT_EXT_IND 或直接丢弃。

 LL_CLOCK_ACCURACY_REQ and LL_CLOCK_ACCURACY_RSP

CtrData字段的格式如图2.46所示

SCA 字段详解（Sleep Clock Accuracy，睡眠时钟精度）

SCA（Sleep Clock Accuracy） 是蓝牙低功耗（BLE）协议中用于 量化设备休眠时钟漂移程度 的关键参数，直接影响连接事件的时间容错计算。在 LL_PERIODIC_SYNC_IND PDU 中，该字段用于标识发送设备（Central 或 Peripheral）的当前时钟精度，以便对端设备调整同步策略。

1. SCA 字段的定义

（1）字段作用

• 标识时钟漂移范围：
  SCA 表示设备休眠时 内部低功耗时钟（LF Clock）的最大可能偏差，单位为 ppm（百万分之一）。

• 决定监听窗口扩展：
  对端设备需根据 SCA 扩展监听窗口（winOffset），以补偿时钟漂移导致的时序误差。

2. SCA 字段的协议行为

（1）发送方角色决定字段含义

• Central 发送时：
  SCA = centralSCA（中心设备的当前时钟精度）。

• Peripheral 发送时：
  SCA = peripheralSCA（外围设备的当前时钟精度）。

（2）与连接事件的关系

• 连接建立时：
  SCA 首次在 CONNECT_IND PDU 中声明（见 Section 2.3.3.1），后续可通过 LL_PERIODIC_SYNC_IND 更新。

• 同步策略调整：
  对端设备根据 SCA 值扩展监听窗口（winOffset），计算公式为

  窗口扩展时间 = （SCA对应的ppm值） × （连接间隔 Connection Interval）

LL_POWER_CONTROL_REQ

CtrData字段的格式如图2.51所示。

1. PHY 字段

• 功能：
  用于指定请求所针对的物理层（PHY）。PHY 决定了无线信号的调制方式、编码方式等特性。
• 编码规则：
  PHY 字段是一个位掩码（bitmask），通过设置一个比特位为 1 来选择特定的 PHY。例如：
  • 若支持 PHY_1M、PHY_2M、PHY_CODED，则 PHY 字段可能为 0b001（选择 PHY_1M）。
• 依据：
  具体支持的 PHY 类型需参考协议定义的表 2.23（如蓝牙核心规范中的表格）。
• 

2. Delta 字段

• 功能：
  表示请求接收方（如外围设备）调整其发送功率级别的变化量，单位为分贝（dB）。
• 取值规则：
  • 正值：请求增加发送功率（如 +3 dB）。
  • 负值：请求减少发送功率（如 -2 dB）。
  • 0：不请求调整功率。
  • 0x7F（127）：特殊值，请求接收方使用最大允许功率。
• 示例：
  • Delta = +2：请求接收方增加 2 dB 发送功率。
  • Delta = 0x7F：请求接收方以最大支持的功率发送。

3. TxPower 字段

• 功能：
  表示发送方（如中央设备）当前使用的发送功率级别，单位为分贝毫瓦（dBm）。
• 取值规则：
  • 有效范围：通常为协议定义的最小/最大发送功率（如 -20 dBm 至 +10 dBm）。
  • 127（0x7F）：特殊值，表示发送方功率级别不可用（如未校准或未测量）。
  • 126（0x7E）：保留值，禁止设置为该值。
• 示例：
  • TxPower = 5：发送方当前以 5 dBm 功率发送。
  • TxPower = 127：发送方功率级别未知或未提供。

协议交互逻辑

1. 发起方（如中央设备）通过 LL_POWER_CONTROL_REQ 发送 CtrData，请求调整接收方（如外围设备）的功率。
2. 接收方根据 Delta 和 TxPower 字段计算目标功率，并返回 LL_POWER_CONTROL_RSP 确认是否支持该调整。
3. 典型场景：
   • 优化连接：根据信道质量动态调整功率，平衡范围和功耗。
   • 合规性：确保设备在监管限制内运行（如某些频段的最大允许功率）。

错误处理

• 非法值：
  • 若 Delta 或 TxPower 超出协议定义范围，接收方应返回错误码（如 0x0C: Invalid Parameter）。
• 不支持的 PHY：
  • 若请求的 PHY 不被支持，接收方应拒绝请求

 LL_POWER_CONTROL_RSP

CtrData字段的格式如图2.52所示。

1. Min 和 Max 字段

• 功能：
  • Min：若发送方当前功率为支持的最低值，则设置此标志。
  • Max：若发送方当前功率为支持的最高值，则设置此标志。
• 特殊规则：
  • 若 Min 和 Max 同时设置，表示发送方仅支持单一固定功率（如某些简单设备）。
  • 若均未设置，则发送方功率处于中间值，可调节。

2. Delta 字段

• 功能：
  表示发送方实际调整的功率变化量（单位：dB）。
• 取值规则：
  • 正值：功率增加（如 +2 dB）。
  • 负值：功率减少（如 -1 dB）。
  • 0：未调整功率。
• 示例：
  • 若请求增加功率，但发送方已达最大值，则 Delta = 0。

3. TxPower 字段

• 功能：
  表示发送方当前使用的功率级别（单位：dBm）。
• 特殊值：
  • 127：功率值不可用（如未校准或未测量）。
  • 126：发送方未管理该 PHY 的功率（如未启用功率控制功能），此时其他字段应被忽略。
• 示例：
  • TxPower = 5：当前功率为 5 dBm。
  • TxPower = 126：响应无效，需重新协商参数。

4. APR（Acceptable Power Reduction）字段

• 功能：
  表示发送方所能接受的对端设备功率最大减少量（单位：dB）。用于协商双方功率调整范围。
• 特殊值：
  • 0xFF：发送方无法确定可接受值（如动态环境或未实现该功能）。
• 示例：
  • APR = 3：对端设备功率可减少最多 3 dB。
  • APR = 0xFF：需通过其他方式协商功率。

协议交互逻辑

1. 发起方发送 LL_POWER_CONTROL_REQ 请求调整功率。
2. 接收方通过 LL_POWER_CONTROL_RSP 响应：
   • 确认是否达到功率极值（Min/Max）。
   • 返回实际功率变化（Delta）和当前值（TxPower）。
   • 告知发起方自身对功率减少的容忍度（APR）。
3. 典型场景：
   • 优化连接：根据信道质量动态调整功率，平衡范围和功耗。
   • 合规性：确保设备在监管限制内运行（如某些频段的最大允许功率）。

错误处理

• 无效响应：
  • 若 TxPower = 126，接收方未管理该 PHY 功率，需终止协商。
  • 若 APR = 0xFF，需通过其他机制（如应用层协议）协商功率。
• 冲突值：
  • 若 Min 和 Max 同时设置但 Delta ≠ 0，应视为协议错误

LL_POWER_CHANGE_IND

CtrData字段的格式如图2.53所示。

1. PHY 字段

• 功能：
  标识功率发生变化的物理层（PHY），采用表 2.23 中的编码值。
• 特殊规则：
  • 多 PHY 标识：若多个 PHY 的功率变化信息相同（如 Min/Max/Delta/TxPower 值一致），可通过位掩码（bitmask）同时标识多个 PHY。
  • 示例：
    PHY = 0b1101 表示功率变化同时适用于 PHY1、PHY3 和 PHY4。

2. Min 和 Max 字段

• 功能：
  • Min：若发送方当前功率为支持的最低值，则设置此标志。
  • Max：若发送方当前功率为支持的最高值，则设置此标志。
• 特殊规则：
  • 若 Min 和 Max 同时设置，表示发送方仅支持单一固定功率。
  • 若均未设置，则功率处于中间值，可调节。

3. Delta 字段

• 功能：
  表示发送方在指定 PHY 上的功率变化量（单位：dB）。
• 取值规则：
  • 正值：功率增加（如 +2 dB）。
  • 负值：功率减少（如 -1 dB）。
  • 0：未调整功率。
• 示例：
  • Delta = 3：功率增加 3 dB。
  • Delta = -1：功率减少 1 dB。

4. TxPower 字段

• 功能：
  表示发送方在指定 PHY 上的当前功率级别（单位：dBm）。
• 特殊值：
  • 127：功率值不可用（如未校准或未测量）。
  • 126：发送方已停止管理该 PHY 的功率（如关闭功率控制功能），此时其他字段应被忽略。
• 示例：
  • TxPower = 5：当前功率为 5 dBm。
  • TxPower = 126：功率控制已禁用，需重新协商参数。

协议交互逻辑

1. 发送方检测到功率变化后，主动发送 LL_POWER_CHANGE_IND。
2. 接收方解析 CtrData：
   • 通过 PHY 字段确定受影响的物理层。
   • 通过 Min/Max 判断是否达到功率极值。
   • 通过 Delta 和 TxPower 获取功率变化及当前值。
3. 典型场景：
   • 动态优化：根据信道质量或距离调整功率，平衡范围和功耗。
   • 异常处理：若 TxPower = 126，需重新初始化功率控制流程。

错误处理

• 无效指示：
  • 若 TxPower = 126，接收方应忽略当前指示，并尝试重新协商功率参数。
  • 若 PHY 字段标识的 PHY 未被支持，需丢弃该指示。
• 冲突值：
  • 若 Min 和 Max 同时设置但 Delta ≠ 0，应视为协议错误。

LL_SUBRATE_REQ PDU

CtrData字段的格式如图2.54所示。

1. SubrateFactorMin / SubrateFactorMax

• 功能：
  • SubrateFactorMin：请求的最小连接子速率因子（connSubrateFactor）。
  • SubrateFactorMax：请求的最大连接子速率因子。
• 取值范围：
  需参考 Section 4.5.1 的定义（通常为 1 到 N，例如 1 表示全速率，N 表示最低速率）。
• 作用：
  子速率因子用于动态调整连接的有效传输速率，值越小表示传输速率越低，但通信范围可能更长。

2. Max_Latency

• 功能：
  表示在子速率事件中允许的最大外围设备延迟（connPeripheralLatency）。
• 约束条件：
  SubrateFactorMax × (Max_Latency + 1) ≤ 500
  此公式确保在最大子速率下，延迟不会超过协议限制（500 个事件间隔）。
• 示例：
  若 SubrateFactorMax = 2，则 Max_Latency 最大为 249（因为 2 × (249 + 1) = 500）。

3. ContinuationNumber

• 功能：
  表示请求的最小连接继续编号（connContinuationNumber）。
• 作用：
  用于控制数据包的分段和重组，值越小表示允许的分段越少，需结合子速率因子使用。

4. Timeout

• 功能：
  表示请求的连接监督超时（connSupervisionTimeout）值。
• 单位转换：
  connSupervisionTimeout = Timeout × 10 ms
  例如，Timeout = 100 表示超时时间为 1 秒。

协议交互逻辑

1. 请求方（如从机）通过 LL_SUBRATE_REQ 发送参数请求：
   • 指定可接受的子速率范围（SubrateFactorMin 到 SubrateFactorMax）。
   • 定义最大延迟和超时时间，确保通信可靠性。
2. 响应方（如主机）根据请求和自身能力，选择实际参数并通过 LL_SUBRATE_RSP 返回：
   • 若请求参数不可接受，可能返回错误码或协商后的参数。
3. 典型场景：
   • 低功耗优化：从机请求降低子速率（增大 SubrateFactor）以减少功耗。
   • 延迟敏感场景：从机请求较小的 Max_Latency 和 Timeout 以确保实时性。

错误处理

• 参数冲突：
  • 若 SubrateFactorMax × (Max_Latency + 1) > 500，请求应被拒绝。
  • 若 Timeout 值超出协议范围（如 Section 4.5.2 定义），需返回错误。
• 资源限制：
  • 若主机无法支持请求的子速率或延迟，需返回协商后的参数或终止连接。

LL_SUBRATE_IND PDU

CtrData字段的格式如图2.55所示。

1. SubrateFactor

• 功能：
  表示新的连接子速率因子（connSubrateFactor），取值范围需参考 Section 4.5.1（例如 1 表示全速率，值越大表示速率越低）。
• 作用：
  动态调整连接的有效传输速率，值越小传输速率越高，但通信范围可能更短。

2. SubrateBaseEvent

• 功能：
  表示新的连接子速率基事件（connSubrateBaseEvent），取值范围需参考 Section 4.5.1。
• 作用：
  定义子速率事件的基准间隔，影响通信的周期性和实时性。

3. Latency

• 功能：
  表示在子速率事件中新的外围设备延迟（connPeripheralLatency）。
• 作用：
  控制从机在子速率事件中的响应延迟，需结合 SubrateFactor 使用以平衡功耗和实时性。

4. ContinuationNumber

• 功能：
  表示新的连接继续编号（connContinuationNumber）。
• 作用：
  用于控制数据包的分段和重组，值越小表示允许的分段越少，需结合子速率因子使用。

5. Timeout

• 功能：
  表示新的连接监督超时（connSupervisionTimeout）值。
• 单位转换：
  connSupervisionTimeout = Timeout × 10 ms
  例如，Timeout = 100 表示超时时间为 1 秒。

协议交互逻辑

1. 发送方（如主机）通过 LL_SUBRATE_IND 指示参数更新：
   • 根据协商结果（如 LL_SUBRATE_REQ）或自身策略，设置新的子速率参数。
2. 接收方（如从机）需确认参数并调整通信配置：
   • 若参数不可接受，可能触发错误处理或重新协商。
3. 典型场景：
   • 动态功耗管理：主机根据信道条件调整 SubrateFactor 以优化功耗。
   • 实时性优化：主机减小 Latency 和 Timeout 以确保关键数据传输的及时性。

错误处理与约束

• 参数有效性：
  • 所有字段需符合协议规范（如 Section 4.5.1 和 4.5.2）的定义。
  • 若 Timeout 值超出协议范围，需触发错误处理。
• 资源限制：
  • 从机可能因硬件限制无法支持某些参数组合，需返回协商请求或终止连接。

通过 LL_SUBRATE_IND，BLE 设备可实现连接参数的动态调整，灵活适应不同应用场景的需求，例如：

• 低功耗场景：增大 SubrateFactor 和 Latency 以延长电池寿命。
• 实时通信场景：减小 SubrateFactor 和 Timeout 以确保低延迟。

LL_CHANNEL_REPORTING_IND

CtrData字段的格式如图2.56所示。

1. Enable

• 功能：
  启用或禁用通道分类报告功能，具体值需参考 Table 2.24（例如 0x01 启用，0x00 禁用）。
• 作用：
  控制外围设备是否主动发送 LL_CHANNEL_STATUS_IND PDU 以报告通道质量。

2. Min_Spacing

• 功能：
  表示自上次发送 LL_CHANNEL_STATUS_IND PDU 以来，下次发送前所需的最小时间间隔，单位为 200 毫秒。
• 取值范围：
  5（1 秒）到 150（30 秒）。
  例如，Min_Spacing = 10 表示间隔至少 2 秒。
• 作用：
  防止频繁发送报告占用信道资源，平衡实时性与网络负载。

3. Max_Delay

• 功能：
  表示从外围设备检测到通道分类变化到生成 LL_CHANNEL_STATUS_IND PDU 的最大时间间隔，单位为 200 毫秒。
• 取值范围：
  5（1 秒）到 150（30 秒）。
  例如，Max_Delay = 20 表示延迟最多 4 秒。
• 约束条件：
  Max_Delay ≥ Min_Spacing
  确保在最小间隔内检测到变化时，仍能及时发送报告。

协议交互逻辑

1. 主机通过 LL_CHANNEL_REPORTING_IND 配置参数：
   • 设置 Enable 以开启/关闭报告功能。
   • 定义 Min_Spacing 和 Max_Delay 以控制报告频率和延迟。
2. 外围设备根据参数调整行为：
   • 若 Enable = 0x01，在通道状态变化后，等待 Max_Delay 时间内发送报告。
   • 确保两次报告间隔不小于 Min_Spacing。
3. 典型场景：
   • 动态信道优化：主机通过调整参数，要求外围设备及时报告干扰信道，以便主机重新分配信道资源。
   • 功耗管理：增大 Min_Spacing 和 Max_Delay 以减少报告频率，延长设备续航时间。

错误处理与约束

• 参数有效性：
  • Min_Spacing 和 Max_Delay 必须符合取值范围。
  • Max_Delay 必须大于或等于 Min_Spacing，否则配置无效。
• 资源限制：
  • 外围设备可能因硬件限制无法支持过小的时间间隔，需返回错误或协商参数。

通过 LL_CHANNEL_REPORTING_IND，BLE 设备可实现灵活的通道状态报告机制，优化信道利用率和通信可靠性，适用于干扰频繁的无线环境。

 LL_CHANNEL_STATUS_IND

CtrData字段的格式如图2.57所示。

Channel_Classification（信道分类）

• 类型：uint2[37]（37个无符号2位整数的数组）

• 定义：数组的第 n 个元素（从 0 开始编号）对应数据信道索引 n 的分类状态。

• 各状态值含义：

  • 0 = unknown（未知）：该信道的质量状态未知。

  • 1 = good（良好）：该信道质量良好，适合数据传输。

  • 2 = reserved for future use（保留供未来使用）：暂未定义，可能在未来协议版本中使用。

  • 3 = bad（差）：该信道质量较差，应避免使用。

应用场景

该信息通常由BLE设备（主设备或从设备）发送，用于动态调整信道选择算法（CSA），以优化通信可靠性。例如：

• 如果某些信道被标记为 bad（3），设备可避免在这些信道上传输数据。

• unknown（0） 状态可能表示设备尚未对该信道进行充分评估。

• good（1） 状态的信道可优先用于通信。

该机制有助于提高BLE在复杂无线环境（如Wi-Fi、微波炉干扰等）中的抗干扰能力。