Is it a good idea to advertise a Bluetooth GATT Service solely via the 'service data' data type?

Question

We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).

As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.

A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.

We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.

The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:

The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:

• Flags
• TX Power Level
• Local Name
• Services

[...]

The primary services should always be advertised in the advertising PDU.

However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.

With this context my questions are:

• Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
• Would this even comply to the Bluetooth Core Specification?
• Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
• Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
• What is the best practice in such a case, given the limited size of the advertising PDU?

Thank you for your thoughts!

question from:https://stackoverflow.com/questions/65910314/is-it-a-good-idea-to-advertise-a-bluetooth-gatt-service-solely-via-the-service

Answer 1

Waitting for answers