iBeacon / 低功耗蓝牙（BLE 设备）- 信标的最大数量

Posted 2023-03-05

【中文标题】iBeacon / 低功耗蓝牙（BLE 设备）- 信标的最大数量

【英文标题】：iBeacon / Bluetooth Low Energy (BLE devices) - maximum number of beacons

【发布时间】：2013-10-11 10:35:53

【问题描述】：

我想通过 iPhone (5s) 上的应用程序在 50-100 m 半径范围内一次跟踪大量信标 (~500)。我查看了规范和在线，我看不出您可以使用 BLE 一次跟踪的信标数量是否有任何限制。有谁知道您可以跟踪的信标数量是否存在限制，或者 iPhone 5s 是否可以完成跟踪这么多信标的任务？

【参考方案1】：

你用了track这个词，但是ios有两种不同的方法：监控和测距。

您最多可以设置 20 个区域进行监控。 （在 startMonitoringForRegion: 方法的文档中找到。）如果您的应用程序在后台，则区域限制主要发挥作用。当您进入或离开您正在监控的区域时，操作系统会提醒您的应用程序（几分钟或几分钟）。操作系统甚至会启动您的应用，只是为了让它知道发生了什么（虽然只是很短的时间）。

另一种方法是测距，即查找设备蓝牙范围内的所有信标（通常在 100 英尺左右）。如果您的信标分布在 100 英里以上，那么您可能不会在此处遇到任何实际限制。我还没有找到任何文档，而且我只有四个要测试的信标，并且一次有四个可以工作。

这是处理您的情况的一种方法。让所有 500 个信标使用相同的 UUID，并使用 initWithProximityUUID:identifier: 方法创建一个信标区域。 （标识符仅供您使用——它不会影响任何东西）。开始监视该信标区域。这样一来，只要找到 500 个信标中的一个（几分钟或几分钟），您的应用就会收到通知。收到通知后，您可以使用 startRangingBeaconsInRegion: 查找该区域周围的所有信标，然后使用主要和次要值来确定用户靠近哪些信标。

【讨论】：

但请记住，当您的应用在后台收到 iBeacon 通知时，您的应用只会收到有限的时间来采取行动（很可能以秒为单位）。根据您希望采取的操作，也许提示用户（使用 UILocalNotification）打开应用程序，然后在应用程序打开时开始测距可能是正确的解决方案。一个例子可以在here找到。

蓝牙应该有哪些限制，GPS？

【参考方案2】：

我将补充 Tim Tisdall 的答案，该答案列出了正确的框架。我无法谈论 iPhone 5s 或 iOS 的具体功能，但我看不出它为什么不返回它收到的每个 ADV_IND 数据包（即信标传输）。

问题是，这 500 个信标能否在不发生冲突的情况下传输其 ADV_IND 数据包？

传输一个 ADV_IND 数据包大约需要 0.128ms。广告传输之间的时间可配置为 20 毫秒到 10240 毫秒（间隔为 0.625 毫秒），因此冲突的概率取决于信标的配置。

基于泊松分布，任何给定 ADV_IND 数据包的冲突概率为 1-exp(-2*N*(0.128/AI))，其中 N 是范围内的信标数量，AI 是时间以广告间隔的毫秒为单位（假设所有信标配置相同），0.128 是发送 ADV_IND 数据包所需的时间（以毫秒为单位）。 （如果需要解释，请参阅http://www3.cs.stony***.edu/~jgao/CSE590-fall09/aloha-analysis.pdf。）

对于最大广播间隔约为 10 秒的 500 个信标，大约每 81 个数据包（或大约 500 个数据包中的 6 个）将发生一次冲突。如果您愿意等待几个间隔（即 30 秒），您很有可能会收到所有 500 个 ADV_IND 数据包。

另一方面，如果广告间隔更小，例如 500 毫秒，您将有大约 23% 的时间发生冲突（或 500 次中的 113 次）。您必须再等待几个间隔才能提高您看到来自所有信标的广播的可能性。

另一种看待它的方式是，您拥有的信标越多，您需要等待的时间越长，以确保您收到它们的所有数据包。 （根据信标的数量和广告间隔来计算以一定概率接收数据包的延迟的数学对我来说今天太多了。）

一个警告：如果您想连接到这些信标，而不是仅仅接收 ADV_IND 数据包，则需要在广告通道上再交换两个数据包，并且广告通道中发生冲突的概率会上升位。

【参考方案3】：

如果我没看错您的问题，您希望将所有 500 个 iBeacon 放在彼此相距 100 米的范围内，这意味着它们的传输将重叠。在遇到 iOS7 或手机的任何限制之前，您很可能会遇到无线电拥塞问题。

我已经成功地近距离测试了 20 个 iBeacon 没有问题，但 500 个 iBeacon 是一个极端的密度。 this discussion 在硬件问题上建议您可能会遇到麻烦。

至少，500 个 iBEacon 的传输冲突会使您的 iOS 设备需要更长的时间才能看到每个 iBeacon。通常，iOS7 会为每台 iOS 设备提供每秒一次的测距更新，但您可能会发现获得更新的频率要低得多。这完全取决于您的应用程序是否可以接受较低频率的更新。

即使延迟是可以接受的，我也绝对会先测试一下，然后再指望它能正常工作。不幸的是，这意味着要获得大量 iBeacon。

【参考方案4】：

我不同意。 ble beacons确实只传输广告数据，但这种数据的传输持续大约3ms（考虑三个广告通道）。 拥有 500 个信标，在不考虑任何碰撞的情况下，扫描仪将需要 1.5 秒才能看到所有信标。 但是，如果所有信标都以相同的方式配置（相同的广告间隔），则不可避免地会发生冲突，从而导致未发现的信标。即使信标之间的广告间隔不同，也会发生冲突。为了避免冲突概率，应该使用更长的广告间隔，但这会导致更长的发现延迟。 这个推理很原始，没有考虑很多效果，只是一个数量级的计算。

顺便说一句，这个问题并不容易，有很多参数在起作用，有些是已知的，有些是未知的。但我与 ble 合作大约一年了，对我来说，500 是一个巨大的数字，而且由于冲突，您可能看不到大多数节点。

【讨论】：

我刚刚编写了一个估计碰撞次数的 matlab 脚本。它假设使用 ble，因此使用三个 adv 通道，并且 tx 阶段的持续时间为 466us，假设没有其他类型的干扰（wi-fi、zigbee、其他蓝牙设备）。

使用 1 秒的广告和 500 个节点，平均我有 186 个节点有冲突，可能不会在 1 秒内被发现。当然如果发现继续，在发现的下一秒将再次出现 186 个不可发现的节点（有些是相同的，有些不是），下一秒会有其他 186 个，依此类推。

这是一个非常有趣的回应，我想进一步了解您对 BLE 冲突估计建模的分析。您愿意为您的分析发布要点或来源吗？

老实说不，但分析很简单。它需要一个广告间隔（即发送广告数据包的间隔）并在该间隔内随机分散每个节点的传输时隙。任何与其他任何重叠的数据包都将被破坏。您只需要多次重复此随机化并计算平均值

@DavideGiovanelli 我可以用你的短语the transmission of such data lasts about 3ms 回答问题theoretically, what is the maximum number of advertisements that could be heard by a given listening beacon in a second?

333

【参考方案5】：

因为这个问题，我正在对 iBeacon 进行一些研究（我不知道它是关于什么的）。

似乎在事情的“信标”方面，所发生的只是一般的广告数据包被发送出去。这类似于设备宣传您可以连接到它的方式。但是，您实际上并没有连接到 iBeacon，它只是读取那些广告数据包。设备可以接收多少广告包没有内置限制。

所以，如果 500 个 iBeacon 能够毫无问题地运行，我不会感到惊讶。广告包很小并且间隔开（时间方面，它们每 X 毫秒重复一次）。从电话到 iBeacon 没有通信，电话只是接​​收它听到的数据包。如果一个数据包受到干扰，它可能会设法获得下一个数据包。