This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Service UUID Discovery before connectivity

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.

Parents
  • 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

Reply Children
No Data
Related