Service UUID Discovery before connectivity

[TechGeek]

Hey All -

My team is new to Bluetooth development and so this may be a naïve question. Pardon us for this, if so.

We are trying to create an Android App that would scan for the current advertising BT devices and identify the one with our custom service UUID for pairing and connecting. Is this possible? In summary, my question is that does BT as a technology support the query of Service UUIDs from peripheral devices when it hasn't paired before and hence is not currently connected to those devices.

[endnode]

Hi,

Just to complete John's answer (which is correct): in some cases you might have problem to put your 16-byte UUID into Advertising (or Scan Response) data. It could be either because it has space only for 31+31=62B where some are already occupied by mandatory AD objects and overhead or because you have access only to GATT Server but don't have priority or access to Adv. data (e.g. there are several Primary Services and yours isn't considered the most important). But BT Smart (BLE) allows you to connect to any connectable peer (GAP Peripheral) so you can connect and do full service discovery (if it supports GATT) without need of bonding or security. At least this is my understanding of the standard and observation from the practice. Sure it isn't very efficient because you need to exchange several dozens of packets and if you would like to optimize it by caching then it doesn't scale (you simply don't have space to build unlimited DB of all BLE devices you ever met) but on the other hand it will work and no BT SIG certified device should complain.

And one more note: pairing/bonding isn't really requirement for BT Smart (neither in Android nor iOS, assuming Windows and other platforms doing similar) and in fact for many applications it's pretty much useless. If you have "one to many" or "many to many" architecture then it's even blocking point because it makes every encounter longer and BLE stacks typically don't support more than dozen of keys for cached peers. You can easily live with "open" GAP and GATT roles and there are plenty of mobile applications out there which are designed like that. In fact BT Smart security is pretty weak unless you use out-of-band (OOB) sharing of 128bit AES key or you implement latest asymmetric scheme from BT specification 4.2 (but if I'm not mistaken that's not supported by nRF5x Soft Devices yet and there aren't many competitors who would offer it - I even don't know if it's supported by iOS and Android already). However application layer offers "unlimited" space to implement security properly (if you need to secure the link). So verify carefully your design whether you are using BT Smart in the most efficient way.

Cheers Jan

[TechGeek]

Thanks Jan for the detailed explanation. I like your proposal of implementing APP layer security. However, that would add additional engineering cost unless there is some open source implementation that we can adopt to.

As for the advertising the service UUID in the scan response, do you have any info about the over head size? Currently my device name is 9 character (= 9 bytes assuming 8 bit representation)+16 bytes for custom service UUID + overhead (if we know it earlier). SInce we have only 1 primary service, I assume there is no contention/prioritization with rest of the services and so we should hopefully be well within the advertising upper bound limit of 62B.

[endnode]

Hi, sure I can give you more details, e.g. BT SIG 4.0 (or any higher) has lovely 2,300 pages full of interesting insides into Bluetooth technology;) But as you suggested that time of your engineers is valuable I suggest to go though tutorials and BT SIG training slides I'm referring in this post.

Putting it simply Advertising and Scan Response data are formatted into so-called "AD" objects where each has 2B header (LENGTH and TAG). The only really mandatory AD object are "FLAGS" which consume 3B and should be at the beginning of each Advertising packet. So then you have another 28B for "free" AD objects + 31B in Scan Response field. Continue... (1/2)

[endnode]

...(2/2) However some vendors (e.g. Apple) mandates some other AD objects such as "Partial list of 128-bit Service UUIDs" or "Complete list of 128-bit Service UUIDs", "Transmit power level" and "Short local device name" or "Complete local device name". Still at least one 16B UUID should fit and if you control the access to BLE stack on that device (e.g. when it is embedded thing with your FW;) then you can count on it.

Btw. searching for Service UUID in advertising data during passive/active scanning before BT Smart connection is used by 95% of BLE apps. You can use any example of Android source code posted by Nordic at github or your engineers can google some other. It shouldn't take more then 10 mins;)

Cheers Jan

[John]

Great additional detail!