Is using a random 16-bit Service UUID allowed, or can we use Nordic's UUID?

[Otso Jousimaa]

Hello,

Our product advertises data in manufacturer specific payload and we have assigned company ID for the manufacturer specific data. 

We ran into an issue with iOS devices, applications cannot scan all Bluetooth devices on the background but they can scan for devices with a specific Service UUID. 

Since we have our actual payload in the manufacturer data, we cannot fit a 128-bit UUID in the advertisement and we need to pick a 16-bit UUID. 

There is not really any suitable existing UUID for our use case, which is "this advertisement contains manufacturer specific data and should be read by application". 

The way I see things, we have 3 options:

 1) Get our own service UUID and use it.

 2) Use some random, unassigned UUID. Is this allowed?

 3) Use Nordic UUID 0xFEE4 or 0xFEE5. Is this allowed? Our device implements Nordic UART Service and buttonless DFU service in case that matters.

[Hieu]

Hi,

We ran into an issue with iOS devices, applications cannot scan all Bluetooth devices on the background but they can scan for devices with a specific Service UUID. 

You would probably want to double check on the API availability. Our nRF Connect app on iOS and various other BLE development app can scan for all type of devices, so I don't think you are limited to scanning for specific service UUID.

 1) Get our own service UUID and use it.

If you must have a unique 16-bit UUID, this is a valid option.

 2) Use some random, unassigned UUID. Is this allowed?

 3) Use Nordic UUID 0xFEE4 or 0xFEE5. Is this allowed? Our device implements Nordic UART Service and buttonless DFU service in case that matters.

Update: these are not allowed. See my next reply.

My initial thought is no for both of these, because the Bluetooth SIG does maintain and centralized 16-bit UUID list.. However, upon reviewing the Bluetooth Core Specification, it is not clear to me yet that this is forbidden... 

From Bluetooth Core Specification 5.4, Vol 3, Part B, Section 2.5.1:

A UUID is a universally unique identifier that is expected to be unique across all
space and all time (more precisely, the probability of independently-generated
UUIDs being the same is negligible). UUIDs can be independently created in a
distributed fashion. No central registry of assigned UUIDs is required. A UUID
is a 128-bit value.
To reduce the burden of storing and transferring 128-bit UUID values, a range
of UUID values has been pre-allocated for assignment to often-used,
registered purposes.

However, regardless of whether there is any prohibition, the Bluetooth SIG does maintain centralized assignment of 16-bit UUIDs, and those are to be used with their Bluetooth Base UUID. The use of such UUID imply a specific purpose and association with the organization that registered it.

I would recommend you against either of these options.

[Hieu]

Update: Regarding usage of 16-bit UUID that was not assigned to your organization, Bluetooth Core Specification 5.4, Vol 1, Part E, Section 2,6 says:

All 16-bit and 32-bit UUIDs as defined in [Vol 3] Part B, Section 2.5.1, are
considered assigned numbers. All other UUID values may be used in any
context where a UUID is permitted provided they are generated according to
the recommendations in ITU-T Rec. X.667(10/2012), alternatively known as
ISO/IEC 9834.8:2014.

That means it is actually forbidden to use a 16-bit UUID unless it has been assigned to your organization.

[Otso Jousimaa]

Thanks, this clears the permission issue for us.

Regarding the scanning, scanning works just fine as long as app is in the foreground. The problem starts when the app is closed / in the background and we'd still need the user to receive the data to their iOS phone. 

We will consider our options and decide if it is easier to fix the iOS background scanning with some other solution or by registering an UUID for ourselves.