BLE：来自后台iOS应用程序的UUID广告 [英] BLE : Advertising of UUID from background iOS app

问题描述

正如iOS文档所述，当使用BLE作为外围设备的iOS应用程序转移到后台模式时，不会公布本地名称，并且所有服务UUID都放在溢出区域中。该文档指出它们只能由iOS设备发现。

我的整体问题是如何在较低级别上发生这种情况。使用非iOS蓝牙数据包嗅探器，当我处于前台和后台模式时，我检查了我的iOS外围应用程序中的广告数据结构。前台模式中的广告数据结构看起来是预期的，类似于来自非iOS设备的其他广告数据，例如我来自Android设备的那些。

当iOS应用程序为后台模式时，此结构会更改，并且服务UUID不明显。我没有看到任何暗示溢出区域的内容。

如果UUID不是其中一部分，iOS中央设备如何发现处于后台模式的外围设备广告数据包？

解决方案

根据

时间在x轴上（过了几天）。
消息之间的间隔绘制在y轴上。您会看到有时间隔是0.2秒的倍数。但是，你也看到这是在三个iPhone上共享的（一个广播 1000 ，一个广播 FFFF ，一个在后台广播 3333 。这意味着这是接收消息的笔记本电脑中的工件。 iPhone可能比这更强大。在整个周末，电池电量下降就像 25％，这很可能与BLE广播之外的其他事情有关。

As the iOS documentation states, when an iOS application that utilizes BLE as a peripheral moves to background mode, the local name is not advertised and all service UUIDs are placed in the overflow area. The documentation states that they can only be discovered by an iOS device.

My overall question is how exactly this happens on a lower level. Using a non-iOS bluetooth packet sniffer, I examined the advertisement data structure from my iOS peripheral app when it was in foreground and in background modes. The advertisement data structure in foreground mode looks to be what was expected, similar to other advertisement data from non-iOS devices, such as those I have coming from an Android device.

When the iOS app is background mode, this structure changes and the service UUID is not apparent. I do not see anything suggesting an "overflow" area.

How does a iOS central device discover a peripheral device that is in background mode if the UUID is not a part of the advertising data packet?

解决方案

There is a so-called overflow area according to Apple documentation. More information can be found in this archive page about Core Bluetooth concepts.

I've sniffed the packets over the air. You can read the details on github. What iOS does is broadcasting custom packages with particular bits representing UUIDs. For example UUID 3333 is represented by a bit going up in the BLE package.

04 3E 24 02 01 00 01 8C 91 A0 AD 8F 40 18 02 01 1A 14 FF 4C 00 01 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 D3

You see here 02 somewhere surrounded by zeros (preceding D3 the 8-bit RSSI value).

Every UUID is one-hot encoded to a bit in this range. This will lead to collisions. You will notice that if you send 1001 by one iPhone and scan for 3333 by another iPhone you will receive the advertisements as if UUID 3333 is sent.

Note, there is a lot of nonsense written about this. It's just a regular undirected BLE packet. It's not a scan response. When running this on the background I've reliable gotten BLE packets every 0.2 seconds.

Time is on the x-axis (over a couple of days). The interval between messages is plotted on the y-axis. You see that at times the intervals are a multiple of 0.2 seconds. However, you also see that this is shared across the three iPhones (one broadcasting 1000, one broadcasting FFFF, and one broadcasting 3333 in the background). This means that this is an artifact from the laptop receiving the messages. The iPhones are probably even more robust than this. Over the entire weekend the battery drop is like 25%, which has very likely to do with other things than the BLE broadcasting.

这篇关于BLE：来自后台iOS应用程序的UUID广告的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！