BLE适应症

Question

据我了解，BLE适应症是一种可靠的通讯方法。你怎么知道你的指示是否没有传达。我正在为外围设备/服务器编写代码，目前当我发送通知时，我会从中心获得手动响应。我读到，如果我使用指示，则自动在L2CAP层中进行确认，因此通信速度更快，但我的嵌入式控制器如何知道蓝牙模块未能成功通过链路获取数据包？我们正在使用Microchip RN4030蓝牙模块。

Answer 1

让我们说清楚。

BLE堆栈看起来大致如下。堆栈按以下顺序包含这些层：

• 链接层
• HCI（如果控制器和主机分开）
• L2CAP
• ATT
• GATT
• 应用

链路层是一种可靠的协议，因为所有数据包都受CRC保护，并且每个数据包都由接收设备确认。如果未确认数据包，则重新发送数据包直到收到确认。也可能只有一个未完成的数据包，这意味着不可能重新排序数据包。致谢通常不会呈现给上层。

HCI层是控制器和主机之间的通信协议。

如果您使用23的标准MTU大小，L2CAP层几乎不会执行任何操作。它具有长度标头和类型代码（＆＃34; channel＆＃34;），它指示正在发送的数据包类型（通常为ATT） ）。

在ATT级别，从服务器发送的有两种类型的数据包未作为对客户端请求的响应而发送。这些是通知和指示。发送一个通知或指示具有相同的＆＃34;性能＆＃34;因为类型只是通过较低层发送的数据包的标记。差异如下：

适应症：

• 当指示包被发送到客户端时，客户端必须通过在收到指示包时发送确认包来确认该包。即使指示包无效，也应发回确认信息。
• 不涉及上层发回确认。
• 在收到前一个确认之前，服务器可能不会发送新的指示。
• 在指示之后，您唯一一次获得确认是否链接被删除（然后您应该获得断开连接的事件），或者某些BLE堆栈中存在一些错误。
• 在应用程序发送指示后，大多数BLE堆栈向应用程序确认客户已收到确认，因为指示操作已完成。

通知：

• 没有发送ATT层确认。
• ＆＃34;由于缓冲区溢出或其他原因而收到但无法处理的命令和通知应被丢弃。因此，必须认为这些PDU不可靠。＆＃34;但是，我从未注意到实际遵循此规则的实现，即所有通知都已传递给应用程序。或者我从未达到最大缓冲区大小。

GATT层主要是如何使用属性协议的定义，并定义了特征的DB结构。

<强>启示

根据我的观点，BLE标准存在一些缺陷或问题。有两件事可能会使指示在实践中变得毫无用处和不可靠：

• 无法发回错误回复而非确认。
• 事实是ATT层在收到指示时直接发回确认，而不应用程序成功处理指示后。

这意味着，例如，如果某些错误或其他问题导致BLE堆栈无法向应用发送指示，或者您的应用崩溃，或者您的应用发现您的价值无效，那么就没有你的外围设备可以意识到这一点。由于它得到了确认，它认为一切都很好。

我无法理解他们为何以这种方式定义适应症。由于应用程序没有发送确认但下层确实发送，因此在进行ATT层确认而不仅仅使用链路层确认时似乎没有任何意义。两者都只是承认数据包已经到达目的地的一半。

如果我们绘制与HTTP POST和Internet的并行，我们可以考虑链接层确认，因为目标的网卡收到请求和ATT确认，作为TCP堆栈收到数据包的确认。您无法知道您的Web服务器软件确实收到了您的请求，并且已成功处理它。

接收方允许通知的事实也很糟糕。通常，如果外围设备想要将大量数据流式传输到中央，然后您不想丢弃数据包，则会使用通知。他们应该设计流量控制，以便链接层停止确认传入的数据包，直到应用程序准备好处理下一个通知。这甚至已经在LL + HCI +主机层实现。

<强>窗

至少Windows BLE堆栈的一个有趣的事情是，如果它接收的指示比应用程序处理它们的速度更快，它也开始丢弃指示，即使只有通知应该被允许丢弃，因为＆＃34;缓冲区溢出或其他原因＆＃34;。它在我的测试中缓冲了大多数512个指示。

那说

只需使用通知，如果您需要某种确认，请让客户端在收到您的数据并成功处理数据后发送一个写入数据包。