16bit UUID Misunderstandings

[Marius Heil]

Hello,

I have quite some difficulties understanding the 16 / 24 / 32 / 128 bit UUID concept. My understanding is as follows: All BLE Assigned Services / Characteristics / Descriptors / ... use the Bluetooth SIG Base UUID which is as follows: xxxxxxxx-0000-1000-8000-00805F9B34FB if they use a 16 bit UUID, they insert it into the Base UUID where the xxxx are: 0000xxxx-0000-1000-8000-00805F9B34FB. Now, there are some special UUIDs, e.g. the Assigned Characteristics (www.bluetooth.com/.../characteristics). These all seem to start somewhere around 0x2A##. Assigned Services on the other hand seem to start at 0x1800.

Now, there is the Member Program where each Member can buy one or more 16bit Service UUIDs for custom use (www.bluetooth.com/.../16-bit-uuids-for-members). This UUID is probably inserted the same way as other 16bit UUIDs for standardized services.

Vendor UUIDs are probably free to use any UUID, that does not clash with the Bluetooth SIG Base UUID (The part without the x has to be different)

Now my Problem is, what happens if the GATT table comes into play.

• How can I add a standardized Characteristic (e.g. the Battery level 0x2A19 ) to my custom Service? E.g. I have a vendor specific service with this UUID: 00000000-e19a-4fb1-9706-de71d7e28e9b, can I now add the following attribute: 00002A19-0000-1000-8000-00805F9B34FB to my service? If yes, how would I do this using the sd_* calls? Adding a 16bit UUID used my vendor UUID as a template, how can I tell it to use the BLE SIG Base UUID?
• What happens if I have my custom 16bit service (e.g. 0xFF00), the Service UUID will probably look like this 0000FF00-0000-1000-8000-00805F9B34FB. But how will I add my custom Attributes? DO I have to watch out that they do not clash with the BLE SIG defined attributes? Which range am I allowed to use?

Thanks a lot, Marius

[endnode]

Hello Marius,

On SD side it's again just set of 16-bit UUIDs + reference to 128-bit base where only BT SIG default 128-bit base UUID is hardocoded and available at SD start. All others you need to provision as new custom 128-bit UUID bases.

Now when you want to init GATT Server object (being it service or characteristic) you always use 16-bit value + base reference. So you can indeed define custom object with BT SIG UUID because you can reference BT SIG base in the call (see these defines in SD API and ble_uuid_t structure definition which is used in sd_ble_uuid_vs_add function call).

I would personally try to avoid using BT SIG allocated UUIDs (on top of their base) because only 512 values were allocated for proprietary values in that range and BT SIG is charging for them. You can see actual list of commercial and non-profit UUIDs allocated. If you really want to steal some numbers from BT SIG range I would go for something in 0xFF00-0xFFF0 (stealing part of SDO range) or 0xFC00-0xFCFF (anticipating BT SIG extension of commercial UUIDs to 0xFD00-0xFDFF range).

[Marius Heil]

Thanks, I got most of the questions figured out now, however I am still wondering this: If I bought a 16bit UUID, my service will be something like this: 0000FF00-0000-1000-8000-00805F9B34FB (Using the BL SIG Base UUID). Now if I register this service, I will do so by using the base UUID. Next, if I want to add a custom characteristic to my service, what will I do? Should I register a custom vendor UUID and use the returned index (returned in the type field) to this UUID to register my custom characteristic?

[endnode]

As some other guys mentioned on this forum UUIDs are completely unctructured in the way that Service and its sub-ordinate Characteristics/Descriptors/whatever don't need to use same 128-bit UUID base or have anything in common. All will work without problems. So I'm afraid it means: if you want to have special Service and Characteristic(s) with 16-bit UUIDs mapped to BT SIG base then you need to purchase as many as you need (it's also a question if BT SIG checks what exact name/meaning these should have or if it's just matter of money and they will give you any number you want). But normally most of vendors are find to have their encapsulating service with standardized/registered 16-bit UUID (e.g. because that goes to GAP AD elements in advertising data where the space is limited) and underneath they use proprietary UUIDs in full 128-bit form.

[Marius Heil]

ok, makes sense. Thanks a lot for clarification :-)

[jagath]

is all the 16-bit registered UUID, part of the OS kernel what is the advantage on spending 2500$ for it. Is that gives the privilege form the central device side (IOS / android OS) to the peripheral device which having that.