Bluetooth技术学习笔记 ——L2CAP之配置过程

参考：core_v5.0 vol 3. Part A

1. 配置过程分类

（1） 锁步过程： 若L2CAP实体两端都支持Extended Flow Specification（ExtFlowSpec）时，使用该过程。
（2） 标准过程：若非L2CAP实体两端都支持Extended Flow Specification（ExtFlowSpec）时，使用该过程。
 

2. 配置参数

（1）Configuration request配置参数：

• 输入MTU、输入输出流和错误控制信息、输入输出FCS、输入ExtWindow、输入输出帧格式
• 输出Flush TO、输出QoS、输出QoS（ExtFLowSpec选项携带）

（2）Configuration response配置参数：

• 输出MTU（请求者的输入MTU）、输入QoS（请求者的输出QoS）、输入QoS（ExtFLowSpec选项携带）输入输出流和错误控制信息、输入输出FCS、输出ExtWindow

（3）配置选项可参考：Bluetooth技术学习笔记 ——L2CAP之配置选项

 

3. 锁步过程

（1）锁步过程可以分为两个阶段：

• 第一个阶段：1）L2CAP实体收到对端L2CAP实体的ExtFlowSpec选项（非默认值）；2）将对端和本地的ExtFlowSpec参数发送给本地Controller。
• 第二阶段：L2CAP实体将本地Controller的结果上报给对端L2CAP实体。

（2）正常过程

• 对于发起端而言，1）发送携带ExtFlowSpec选项（非默认值）的 Configuration Request消息；2）收到携带任何已修改ExtFlowSpec参数的Configuration Response消息，其结果为“pending”。

• 对于接收端而言，1）收到携带ExtFlowSpec选项（非默认值）的 Configuration Request消息；2）发送携带任何已修改ExtFlowSpec参数的Configuration Response消息，其结果为“pending”。

• 若Configuration Response（pengding）消息中不携带任何参数，表明接收端接收发送端配置的所有参数。

• 若收到Configuration Response（pengding）消息，则启动定时器ERTX。

• 锁步过程中，只能发送一次配置请求（Configuration Request packet）。

（3）异常过程

• 若在收到Configuration Response（pengding）消息之前收到了Configuration Response（success）消息，则断开信道。
• 若发送的Configuration Request消息携带的服务类型（Best Effort or Guaranteed）与接收到的Configuration Request消息携带的服务类型不一致时，断开信道。
• 若Controller不能提供“Guaranteed”的服务，则发送Configuration Response消息，并携带Failure - flow spec rejected。

 

4. 标准过程

（1）标准过程，就是配置参数协商的过程。

• ① 本地设备通过Configuration Request消息告诉对端可接受的参数配置。
• ② 远端设备通过Configuration Response消息告诉远端设备同意或不同意的参数，其中包括默认值。
• 重复上述①②，直到所有参数都协商一致。
• 该流程何时结束，取决于具体的实现，但最长为2分钟。

（2）配置参数包括可协商参数和不可协商参数。

• 若远端设备不接受Configuration Request消息中携带的可协商参数，则在Configuration Response消息中携带结果码Unacceptable Parameters (0x0001)，并提供新的可接受的值。
• 不可协商的参数，只是告知对方。
• 注：MTU是不可协商的参数。若其值小于最小值，则可拒绝。

（3）可协商参数在Request path上的规则：

• 作为配置或重配过程的发起方，L2CAP实体至少发送一次Configuration Request packet。若所有的参数都采用默认值，或者相对于之前的配置没有改变，则Configuration Request packet不携带任何选项。
• 若L2CAP实体收到了肯定的配置响应消息，则认为远端设备接收了所有显式或隐式的配置参数。
• 若L2CAP实体收到了否定的配置响应消息后，再次发送Configuration Request 消息时，对于远端接受的配置选项，需要全部携带且与之前的值相同；对于远端不接受的配置选项，根据Configuration Requese消息，携带一个新的值。
• 若可协商配置选项在否定的Configuration Response消息中未携带，则表明远端设备已接受该配置选项。为了向后兼容，若在否定的Configuration Response消息中未携带了不可协商的配置选项，则认为该Configuration Response消息是肯定的。

（4）可协商参数在Resonse path上的规则：

• 否定的Configuration Response消息需要携带的选项：不接受的可协商配置选项。所有不接受的可协商配置在一个否定的Configuration Response消息中发送。
• 否定的Configuration Response消息不能携带的选项：已接受的可协商配置，不可协商的配置。