我们是否必须在应用程序级别处理蓝牙 LE 通信中的 MTU



我正在用 C# 构建一个低功耗蓝牙测试应用程序,以使两个 Windows 10 应用程序进行通信(中央应用程序使用商业 .NET Framework SDK,外围应用程序使用 UWP),我正在尝试在应用程序级别围绕 MTU(最大传输单元)的影响。这是我到目前为止的理解:

在蓝牙堆栈的L2CAP层中,"大"数据包会发生一些分段和重组。因此,如果数据超过 MTU,它将以块的形式发送。在 UWP 中,我们使用GattLocalCharacteristic.WriteRequested回调来处理接收到的数据。在我正在处理的示例中,当发送 2-3K 数据时,每块 522 字节(可能是协商的 MTU?)都会调用它,因此似乎我必须在应用程序级别处理重组,尽管它应该在 L2CAP 级别完成(如果我理解正确的话)。这意味着我必须检测数据何时完整(使用某种长度字段、"EOF"或任何机制),这给协议增加了一些负担,对我来说感觉非常低级。我本以为WriteRequested事件只会触发一次,其中包含所有数据。

最重要的是,UWP SDK(Windows.Devices.Bluetooth命名空间)似乎没有提供一种了解实际MTU(类似于Android上的requestMtu)的方法,因此我将不得不再次制作一些自定义管道。

所以我想问题是:我是否必须检测协商的 MTU(如何在 UWP 中?)并自己对数据包进行分段和重新组合?

您不必在 Windows 10 上协商 MTU。

它仅取决于所使用的蓝牙版本。
BLE4.0/4.1 的最大 MTU 为 23 字节,BLE4.2 的最大 MTU 为 251 字节。
对于 windows 10 上的其他版本,我不知道最大值。
MTU 由 L2CAP 定义,可以介于 23 和无穷大之间。蓝牙堆栈的实现是确定客户端和外设上的 MTU 的关键因素。
Windows 10 设备将始终尝试协商最大 MTU。

ATT 数据包可以跨越多个 LL 数据包。ATT 数据包中数据单元的大小称为最大传输单元 (MTU)。默认大小为 23 字节(允许数据包放入一个 LL 数据包中),但可以通过 Exchange MTU 请求和响应协商大小。

根据蓝牙核心规范,属性值(ATT 有效负载)的最大允许长度为 512 字节3。虽然这在技术上意味着 MTU 大小可以略大于 512 字节(以适应 ATT 协议开销),但大多数蓝牙堆栈支持的最大 MTU 值为 512 字节

最新更新