6.BLE---数据传输

1. 概述

Ble 数据传输分为两种：

• 连接态数据传输
• 非连接态数据传输

连接态下的 BLE 终端分为 Master 和 Slave，它们之间的数据传输与非连接态时十分类似：

• Connect Interval 中 Master 和 Slave 可做多次数据交互（上图中只画了一次）。
• 由 Master 先发， Slave 在收到数据 T_IFS 时间后进行响应。
• Master 发送数据包的起始时刻必须在 Connect Interval 的起始位置。
• Connect Interval 的长度 connInterval 由 Master 决定，必须为 1.25ms 的整数倍，范围分别在 7.5ms~4000ms。
• 基 于 降 低 功 耗 的 考 虑 ， Master 和 Slave 可 适 当 降 低 数 据 交 互 的 频 率 ， 即 在
  connSlaveLatency 个 Connect Interval 中选择特定一个做数据交互。参数 connSlaveLatency 由
  Master发送个Slave。connSlaveLatency取值范围0~((connSupervisionTimeout / (connInterval*2))
  - 1)*1，并且小于 500，以保证不触发 Master 和 Slave 长期没有收到对方来包而判断 connect
  中断。（参数介绍在第1章与第2章）

T_IFS概念：

数据交互过程中， BLE 终端总是交替发送数据包，数据包之间的时间间隔（本文中记
为 T_IFS），其基准值是 150us，考虑到数据包在空口上的传输时延以及 BLE 终端的处理时
间，协议允许该时间间隔有最大 2us 或 16us 的抖动。需要特别注意的是， BLE 协议不固定
一个数据包的传输时间，即任何 BLE 终端传输一个数据包的时间是可变的。

2.进入链接

2.1 情况1---Slave 收到 Master 发送的第一个 Packet

进入 connect 状态后第一个 Connect Interval 的起始时刻由 Master 发送 CONNECT_REQ
后的第一个 Packet 确定，如下图所示，其使用基于 Transmit Window 的机制。

• CONNECT_REQ后的第一个 Packet，必须在第一个 Transmit Window 内。
• Transmit Window 的长度transmitWindowSize 不 允 许 大 于 10ms 和 （ connInterval-1.25ms ）。
• 其 起 始 位 置 距 离CONNECT_REQ 结束位置的距离为（1.25ms+transmitWindowOffset）， transmitWindowOffset
  是由 Master 确定的参数，取值必须为 1.25ms 的整数倍，范围 0~connInterval。
• 当 Slave 收到该 Pakcet 之后，其默认该 Packet 的起始位置为首个 Connect Interval 的起
  始位置，并以该时间点为基准计算其后的 Connect Interval 和 Connect Event 时间段

2.2 情况2---Slave 没有收到 Master 发送的第一个 Packet

若 Slave 没有收到 Master 发送的第一个 Packet，则其默认第一个 Connect Interval 的起
始位置为第一个 Transmit Window 的起始位置，并且在由此计算得到的第二个 Transmit
Window，并在其中接收 Master 发送的数据，如下图所示，

• 此时Master可以通过没有收到Slave反馈的数据包推断出 Slave 没有收到第一个 Packet。
• 然后预先配置的 transmitWindowSize 和 connInterval 等参数会保证 Master 发送的第二个Packet 时落在第二个 Transmit Window 中。

2.3 误差考虑

考虑到 Master 和 Slave 的时钟精度不同，以及无线信号在空口的传输时延， Slave 在计算 Transmit Window 时需要对其做适量的展宽， 如下式所示，

windowWidening = timeSinceLastAnchor*(masterSCA+slaveSCA)/10^6

• windowWidening 表示展宽的时间宽度。
• timeSinceLastAnchor 表示 Transmit Window起始时刻与上一次Slave收到的Master的Packet结束时刻的时间间隔。
• masterSCA和slaveSCA分别表示 Master 和 Slave 的时钟精度，单位为 ppm。
• windowWidening 必须小于((connInterval/2)-T_IFS)，若 Slave 计算得到的windowWidening 不满足该条件，则判定该 connect 失效，即刻退出

实际上 Slave 需要在(2* windowWidening+transmitWindowSize)的时间间隔内监听 Master 发送的 Packet，

3.维护链接

3.1 时钟同步

• Master 和 Slave 的时间同步基于 Master 发送的 Packet 中的 Preamble 进行。
• 连接存续期间， Slave 已经根据接收到的 Master 的 Packet 中的 Preamble 调整自身时钟以保证 Master 同步。
• 即使 Packet 的 CRC 错误，只要 Preamble 被检测到， Slave 也需要进行该调整。而对于频率同步

3.2 参数更新

 该流程用于 connect 的参数更新，由 Connection Parameter Request Procedure 触发，Master 向 Slave 发送 LL_CONNECTION_UPDATE_REQ PDU， Slave 收到后根据其要求在特定时刻更新相应的 connect 参数。如下图所示：

• 若 接 收 方 不 能 正 确 解 析 LL_CONNECTION_PARAM_REQ PDU ， 则 回 复LL_UNKNOWN_RSP PDU；
• 若接收方不能支持 LL_CONNECTION_PARAM_REQ PDU 中的参数要求，则回复 LL_REJECT_IND_EXT PDU（Error Code 填写为 0x20 和 0x1E，分别对应不能支持和参数非法两种情况）。
• 若 Master 在触发 Connection Parameter Request Procedure 或 Connection Update Procedure 时收到了 Slave 发送的 LL_CONNECTION_PARAM_REQ PDU，则回复 Error Code为 0x23 的 LL_REJECT_IND_EXT PDU；
• 若 Master 在触发 Channel Map Update Procedure 时收到了 Slave 发送的 LL_CONNECTION_PARAM_REQ PDU，则回复 Error Code 为 0x2A 的LL_REJECT_IND_EXT PDU。否则，若接收方为 Slave，其回复 LL_CONECTION_PARAM_RSP PDU（其内容需要和LL_CONECTION_PARAM_REQ PDU 保 持 一 致 ）， 然 后 等 待 MASTER 发 LL_CONNECTION_UPDATE_REQ PDU 触发新的 CONNECTION 参数生效；若接收方为MASTER，则其直接发送 LL_CONNECTION_UPDATE_REQ PDU 触发新CONNECTIO参数生效。
• 需 要 特 别 强 调 的 是 ， 该 过 程 中 MASTER 和 SLAVE 都 可 以 发 送LL_CONNECTION_PARAM_REQ PDU 触发 CONNECTION 参数更新，但只有 MASTER 才
  能发送 LL_CONNECTION_UPDATE_REQ PDU 触发新的 CONNECTION 参数生效。
• 新的 CONNECTION 参数生效时间由 LL_CONNECTION_UPDATE_REQ PDU 中的
  Instant 字段确定，该字段指示了新参数生效的 connEventCount，如下图所示，
• connEventCount的含义：对于每个链路层连接，主设备和从设备都应具有16位连接事件计数器（connEventCounter），其中包含值connEventCount。 它应在连接主机发送的第一个连接事件上设置为零。 对于主设备发送的每个新连接事件，它应加1; connEventCounter将从0xFFFF溢出到0x0000。 此计数器用于同步链路层控制过程。（BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B]）

• 若在接收到 LL_CONNECTION_UPDATE_REQ PDU 的 Connect Interval 里， SLAVE 发现 Instant<(connEventCount-6) 或 (Instant-connEventCount)mod65536>32766 ， 则 判 断 当 前CONNECTION 中断，需立即进入 STANDBY 状态。在新参数生效的第 connEventCount 个 Connect Interval 里， SLAVE 需要使用 Transmit Window 机制重新确定 Connect Interval 的起始时刻

           

若参数在connect下更新了， Master 和 Slave 需要像初始建立连接一样，使用Transmit Window 的机制重新确定 connect interval 的起始时间点，如下图所示：

• connIntervalOLD和 connIntervalNEW分别表示更新前后的 connInterval。
• 为进一步降低 Slave 的功耗，协议在 Connection Parameter Request Procedure 中引入了Offset0~5 和 ReferenceConnEventCount 等字段指示新的 Connect Interval 的起始位置

3.3重传机制

处于连接态的两个 BLE 终端使用简单的"停等"机制进行通信，如下图所示，

• 每个 BLE 终端都维护两个 1 bit 参数： transmitSeqNum 和 nextExpectedSeqNum，分别指示当前传输的数据包序号和下一个期待接收的数据包序号，它们与 Packet 中的 SN 和 NESN字段一起维护 Master 和 Slave 之间的重传机制。 transmitSeqNum 和nextExpectedSeqNum 在 connect 建立时都初始化为 0。
• 发送数据包时，对于 SN 字段，若数据包为新传，则设置为自身 transmitSeqNum 取值，否者与上一次传输一致；对于 NESN 字段，始终设置为自身 nextExpectedSeqNum 取值。
  接收数据包时， transmitSeqNum 和 nextExpectedSeqNum 按照如下原则进行更新，若 SN 字 段 与 自 身 nextExpectedSeqNum 一 致 ， 则 表 明 该 数 据 包 为 重 传 ，nextExpectedSeqNum 不变；否者为新传，并且需要将自身 nextExpectedSeqNum 取反。若 NESN 字段与自身 transmitSeqNum 一致，则表明接收到 NACK，即上一次自己
  发送的数据包失败，需要重发；否者表明收到 ACK，需要发送新的数据包，并且
  将将自身 transmitSeqNum 取反。若接收到的数据包 CRC 错误，则不更新 transmitSeqNum 和 nextExpectedSeqNum，并重发上一次自己发送的数据包（判定收到了 NACK）

简单总结：

• Master只更新SN
• Slave只更新NESN
• 当Slave收到一包，NESN == SN时，认为是新包；
• 当Master收到一包， NESN和SN不同，认为是新包；
• 当Slave收到一包，NESN != SN时，认为是重发包；
• 当Master收到一包， NESN和SN相同时，Master重传上一包；

   

4.退出链接

4.1无数据关闭

         

• MD 字段置 1，表示发送方还有数据需要传输，否者表示没有数据传输。
• 在一个 Connect Interval 内，若 Master 和 Slave 都将 MD 字段置 0，则当前 Connect Interval 为最后一个 Connect Interval，它们将关闭此 Connect；否者 Master 和 Slave 在下一个 Connect Interval 继续数据传输。

4.2 Termination Procedure 关闭

• Master（或 Slave）发送 LL_TERMINATE_IND PDU 到 Slave（或 Master），同时启动定 时器（Tterminate）；
• Slave（或 Master）收到后回复 ACK，同时关闭 connect；
• 收到 ACK 的 Master （或 Slave）则判定 connect 关闭。
• 若 Master（或 Slave）没有收到 ACK，其在 Tterminate 超时后仍然判定 connect 关闭，不在 发送数据包。
• 若 Slave（或 Master）一直没有收到 LL_TERMINATE_IND PDU，则可由于SUPERVISION TIMER 超时而关闭 connect。

4.3 SUPERVISION TIMER 超时关闭

具体介绍在第1章第5小节。

4.4 异常关闭

主要是信令流程中 Master 和 Slave 的信令交互出现了异常，它们都默认退出 connect。 除此之外，本章中提到的计算 windowWidening 超出范围也会导致退出 connect。