BLE : Advertising of UUID from background iOS app

6
votes

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?

1
iosobjective-cbluetoothbluetooth-lowenergy
There is some information here - stackoverflow.com/questions/21284226/… My guess is that when the Apple specific manufacturer data advertisement is detected by iOS it initiates a connection to the device to retrieve the advertised service UUIDs – Paulw11
My experience has strictly been with central mode, but I was curious about the key CBCentralManagerScanOptionSolicitedServiceUUIDsKey that you specify as an option for scanForPeripheralsWithServices:options mentioned in the docs, and wondered if that's how you pass in the service UUIDs for discovering peripherals in that mode. – Marcus Adams
Thank you both for your help. I am still unable to get this work out if the scanning device (central) is a non-iOS device. Based upon what I have read in other posts, I understand that if the central is an iOS device, didDiscoverPeripheral is called twice, with the second containing the scan response. Is there any delegate / callback that I can implement on the peripheral side where I can detect these two events? – cnbecom
Hello, I'm also pretty much having the same issue, where i'm using the raspberry pi to sniff the bluetooth packets. Since the app is advertising in the background raspberry couldn't recognize the which device is emitting the received ble packet. Have you got any information or luck working on this problem? – prasad1250
CBCentralManagerScanOptionSolicitedServiceUUIDsKey is helpful if you have a set of peripherals that you want to look for. Here you can provide the service uuid's that are might be published by the peripherals as an array and then provide that array in the scanForPeripheralsWithServices call with CBCentralManagerScanOptionSolicitedServiceUUIDsKey set to true. With this, ios informs you app whenever a peripheral discovered that is publishing anyone of the uuid's that we mentioned in the above array. Hope it helps!!! – prasad1250

1 Answers

7
votes

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.

enter image description here

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.