在一个连接间隔内，无论是从设备还是主设备发送的数据包（LE_DATA）是否存在数量限制？
如果存在限制，是否有任何特定条件适用于此限制（例如仅限于x个ATT数据包）？
是否根据规范要求或允许主/从设备施加此类限制？
4个回答
3
(希望我没有唤起一个已经过时的帖子。但我认为4.5.1节比4.5.6节更适合回答这个问题。)
规范没有定义数据包的限制，只是说明了以下内容:
4.5.1 连接事件 - 蓝牙规范版本4.2 [卷6，B部分]
(...)
连接事件的开始被称为基准点。在基准点，主设备开始向从设备传输数据通道PDU。连接事件的开始以connInterval时间间隔定期间隔，并且不应重叠。 主设备应确保连接事件至少在下一个连接事件的基准点之前T_IFS关闭。从设备会在基准点监听其主设备发送的数据包。
T_IFS 是“帧间距”时间，应为150微秒。简单来说，解决这个问题是主设备的工作。据我所知，例如iOS将每次连接事件的数据包数量限制为4个。根据操作系统版本，Android可能有其他硬编码限制。
- vvombat
5
实际上，这是蓝牙控制器（手机中的专用芯片）决定的。首先，在一个连接间隔内发送许多数据包需要确保同时没有其他连接或WiFi设备想要使用无线电。其次，在HCI协议中，主机可以提示所需的连接事件长度。Android将此设置为0，这意味着它允许控制器决定此事。不确定iOS设置了什么。然后完全取决于控制器的智能程度。一些控制器在给出CE_len为0时简单地将其限制为4个数据包。 - Emil
@Emil 谢谢你的补充！我在这个情境中想知道的是：控制器是否真正计算连接事件结束时的时间是否适合另一个 T_IFS，或者他们选择值以使最大数据包数量即使在最大数据包长度的情况下也不会发生冲突？ - vvombat
谢谢您的回答，但我在寻找规范所施加的限制，而不是实现。根据规范，在一个CI中的传输会在双方重置其MD位时停止，因此规范对每个设备在一个CI上可以传输的数据包数量没有限制，除非通过每个数据包传输所需的时间来限制。规范不禁止自我施加更严格的限制，这也是我后来发现大多数BLE控制器都会实施的。 - GPS
@GPS 要么我没有理解你的观点，要么你的整个评论是对我的回答的概括...第一句话是“规格没有定义数据包的限制” - 这就是答案，没有限制。至少没有直接的限制。 - vvombat
我们都同意规范没有直接限制。我想我们可以结束讨论了。 - GPS
1
根据我的理解，限制条件为：min{主设备事件最大长度、从设备事件最大长度、连接间隔}。为了澄清，主设备和从设备（特别是BLE堆栈）通常都有事件长度或“GAP事件长度”时间。此时间限制可用于允许中央和/或广告者和/或广播者安排一个以上的BLE无线电活动的“相位偏移”，和/或限制BLE堆栈的CPU使用率以满足应用处理需求。例如，Nordic SoftDevice堆栈可能具有默认事件长度为3.75毫秒的时间，该时间可以根据SoftDevice调度程序的其他需求无限延长（最多达到连接间隔）。在Android和iOS BLE实现中，此值可能不透明或未指定（例如，Android可能将此值设置为“0”，这使得决策取决于与该设备的BLE芯片相关联的控制器实现）。
请注意，主设备或从设备在连接事件期间如果其TX/RX缓冲区已满（例如，Nordic SoftDevice堆栈的缓冲区大小为6个数据包/帧），则可以有效地提前“退出”。这可能是通过不设置MD位（如果TX缓冲区耗尽）和/或使用NESN位进行“nacking”（如果RX缓冲区已满）来实现的。但是，虽然主设备可以通过结束连接事件（不再发送任何数据包）来实际“退出”，但只要主设备和从设备中至少有一个设备设置了MD位并且主设备继续传输数据包（例如，从设备可以持续告诉主设备它没有更多数据，并继续对主设备数据包进行NACK处理，因为它没有更多的缓冲空间用于当前连接事件，但主设备可以在连接间隔期间尽可能长时间地尝试发送数据包；我不确定控制器堆栈是否实现了任何“智能”来处理此类情况）。
如果两个设备在堆栈指定的事件长度或缓冲区大小方面没有限制，那么假设至少一侧有数据要发送并因此设置了MD位，则数据包可以在整个连接间隔内来回传输。请注意，为了进行吞吐量计算，每个数据包之间以及连接间隔结束前都有T_IFS间隔（当前规定为150us）。
请注意，主设备或从设备在连接事件期间如果其TX/RX缓冲区已满（例如，Nordic SoftDevice堆栈的缓冲区大小为6个数据包/帧），则可以有效地提前“退出”。这可能是通过不设置MD位（如果TX缓冲区耗尽）和/或使用NESN位进行“nacking”（如果RX缓冲区已满）来实现的。但是，虽然主设备可以通过结束连接事件（不再发送任何数据包）来实际“退出”，但只要主设备和从设备中至少有一个设备设置了MD位并且主设备继续传输数据包（例如，从设备可以持续告诉主设备它没有更多数据，并继续对主设备数据包进行NACK处理，因为它没有更多的缓冲空间用于当前连接事件，但主设备可以在连接间隔期间尽可能长时间地尝试发送数据包；我不确定控制器堆栈是否实现了任何“智能”来处理此类情况）。
如果两个设备在堆栈指定的事件长度或缓冲区大小方面没有限制，那么假设至少一侧有数据要发送并因此设置了MD位，则数据包可以在整个连接间隔内来回传输。请注意，为了进行吞吐量计算，每个数据包之间以及连接间隔结束前都有T_IFS间隔（当前规定为150us）。
- abc
3
这是一个非常好的答案！唯一让我有点怀疑的是关于“提前退出连接事件”的部分，我认为这是错误的。例如，“NACKing”数据包绝对不会导致早期终止。此外，如果RX数据缓冲区已满，并不意味着您应该停止监听，因为链路层数据包仍然可以接收，因为它们不会放在同一个RX缓冲区中。 - Emil
@Emil 谢谢。实际上，是的，NACK本身并不会停止连接事件（我会更新答案），但只要它NACKs，它就会阻止NACKer接收更多数据（因为对等方将继续重发，直到通过NESN获得ACK）。我确信许多实现都有链路层缓冲区限制，这可能有效地限制每个连接事件（因此每个连接间隔）的吞吐量。 - abc
@Emil 关于提前终止连接，完全由主设备决定。因此，即使从设备已满，它也必须继续侦听，但是即使双方仍有数据要发送和接收能力，主设备也可以终止连接事件。 - abc
1
在蓝牙和低功耗蓝牙上都可以实现最大数据传输速率。您可以通过改变MTU（最大传输单元-数据包大小）来调整此数据传输速率，直到双方都能处理最大MTU为止。但据我所知，除了由数据传输速率强加的物理限制之外，没有对数据包数量的直接限制。
您可以在规范中找到更多信息。
您可以在规范中找到更多信息。
- morynicz
2
我特别想知道每个CI的数据包数量限制。我观察到我的主设备每个CI从不发送超过4个数据包。这可能是由于某些协商（例如仅允许有限时间传输）或硬件缓冲区数量有限，或驱动程序编码不良等原因引起的吗？ - GPS
我在Android和BLE外设上遇到了类似的问题。我连接到一个BLE外设并在大约20-30秒内交换数十个数据包（比如300个），然后通信变得非常缓慢，写入特征并获取其响应需要1.5秒。这样的时间对于我的应用程序来说是不可接受的。如果我每隔几百个数据包断开并重新连接，然后从那里恢复过程，它就永远不会变慢或停止工作。这个问题是否与每个连接的数据包限制或连接的时间持续时间有关。请帮忙解决。 - Bilal Rabbani
1
我在蓝牙规范v4.2中找到了以下内容:
“4.5.6关闭连接事件”
数据通道PDU的报头中的MD位用于指示设备还有更多数据要发送。如果两台设备都没有在其数据包中设置MD位，则从从设备发出的数据包将关闭连接事件。如果其中一台或两台设备设置了MD位，则主设备可以通过发送另一个数据包来继续连接事件，而从设备应在发送其数据包后侦听。如果主设备未收到从设备的数据包，则主设备将关闭连接事件。如果从设备未收到主设备的数据包，则从设备将关闭连接事件。
在连接事件中接收到两个连续的具有无效CRC匹配的数据包将关闭该事件。
这意味着从设备和主设备都有自我限制，限制它们在CI期间要传输的数据包数。当任何一方不想再发送更多数据时，它们只需将此位设置为0，另一方就会理解。这通常由任一侧的待处理数据包数量驱动。
由于我正在寻找由规范或协议导致的逻辑限制，因此这可能回答了我的问题。
“4.5.6关闭连接事件”
数据通道PDU的报头中的MD位用于指示设备还有更多数据要发送。如果两台设备都没有在其数据包中设置MD位，则从从设备发出的数据包将关闭连接事件。如果其中一台或两台设备设置了MD位，则主设备可以通过发送另一个数据包来继续连接事件，而从设备应在发送其数据包后侦听。如果主设备未收到从设备的数据包，则主设备将关闭连接事件。如果从设备未收到主设备的数据包，则从设备将关闭连接事件。
在连接事件中接收到两个连续的具有无效CRC匹配的数据包将关闭该事件。
这意味着从设备和主设备都有自我限制，限制它们在CI期间要传输的数据包数。当任何一方不想再发送更多数据时，它们只需将此位设置为0，另一方就会理解。这通常由任一侧的待处理数据包数量驱动。
由于我正在寻找由规范或协议导致的逻辑限制，因此这可能回答了我的问题。
每个CI能够承载的数据包数量受数据速率限制，正如@morynicz所提到的，还受MTU等因素影响。
- GPS
1
这个内容有点老，但是为了明确起见，我认为这并没有真正回答你的问题，而是解释了一个回答你的问题的机制。引用部分的要点是主设备对于连接事件是否会在给定的连接间隔内继续具有最终决定权（假设主从包中至少有一个包设置了MD位）。然而，真正的问题是链路层是否提供了一个旋钮来影响MD位是否被设置。 - abc
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接