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屋！