Allow iOS apps to transmit full 128-bit TCNs in both Foreground and Background without full BLE Connections

[mikew67]

The TCN Protocol document, in the section on TCN Sharing with BLE states:

• iOS 13.4 (and older) does not support the broadcasting of small advertisement data of third-party apps, ...

There are two iOS app situations to consider here: Foreground and Background

• Foreground: It is actually possible to transmit a full 128-bit TCN in an iOS app Advertising Packet.

• Background: An Advertising Packet sent by an iOS app in background mode does not contain any direct user data, but only an encoded/hashed representation of the app's Service UUIDs. The Core Bluetooth docs say that this data is saved in an "overflow area" , but doesn't indicate how it might be conveyed to scanning BLE devices. (Conventional wisdom is that the scanning device has to also be an iOS device, leading to the premise that it needs to have access to the same Service UUID hashing algorithm so that it can match on the hash, not the raw UUID number).

Subdivided into Issues 2, 3, 4:

• Document process for conveying full 128-bit TCNs in FG-mode iOS app Advertising Packets, with test code

• Determine handling by iOS of "overflow data" from Advertising Packets, by apps in both FG and BG mode, e.g., does iOS automatically respond to Scan Requests with the data in a Scan Response?

• Find a minimal-BLE-traffic workaround to transmitting a full 128-bit TCN from a BG-mode iOS app which has been advertising (but with iOS-limited Adv. Packets)