Can I have any 16-bit/32-bit UUID in advertisement packet for like filtering purpose?
Is it mandatory to have the list of service UUID listed in advertisement packet to be available in service discovery after connection?
Can I have standard GATT services to have unrelated service data in advertisement packet?
Can manufacturing data be made with custom manufacturer ID and data?
Where can i find the legality on these questions on both commercial and non-commercial purposes?
I want to make a BLE server in both android/iOS and also on a development board and I can't find relevant sources stating the legality on these standards.
The relevant source to look at is the Bluetooth Core Specification Supplement (CSS) which you can find here: https://www.bluetooth.com/specifications/bluetooth-core-specification/.
As you can see, it is very loosely specified. The Core Specification also does not say so much about the different AD types.
The spec says in the description "The Service UUID data type is used to include a list of Service or Service Class UUIDs." The spec then describes the different formats 16/32/128-bit UUIDs, incomplete or complete list. Other than that the spec doesn't say where this list comes from or what it represents. It however uses the formulation "If a device has no Service UUIDs of a certain size, ..." at one place. The spec though says that "16-bit and 32-bit UUIDs shall only be used if they are assigned by the Bluetooth SIG" so you can't pick any unassigned 16- or 32-bit UUID. So no you can not just pick any random 16- or 32-bit UUID, it must be an assigned one.
As in 1. the spec doesn't say which list should be advertised. But it is common knowledge that it should represent the list of GATT services that are present in the device's GATT database.
The spec for "Service Data" is very short. The description consists of one sentence: "The Service Data data type consists of a service UUID with the data associated with that service". For the data format it then says the data consists of the UUID followed by "additional service data". It is here, again common knowledge (I guess?) that the associated data must be defined by the specification of the particular service. for example, the Cycling Power Service defines the data as follows: "Cycling Power Service UUID followed by the Cycling Power Measurement characteristic value". So usually the associated service data consists of the characteristic value of a characteristic that has the Broadcast property enabled.
If the CSS is strictly followed (word by word), you could argue that it's possible to use a different list of service UUIDs than the ones in your GATT database. You could also argue that the manufacturer could put in its own "associated data" with a service in a Service Data record. I would say these are possible interpretations, but it's not what the one who wrote the spec intended.
The spec for "Manufacturer Specific Data" has the following description: "The Manufacturer Specific data type is used for manufacturer specific data. The first two data octets shall contain a company identifier from Assigned Numbers. The interpretation of any other octets within the data shall be defined by the manufacturer specified by the company identifier." This means you cannot "steal" another company's identifier and use a data format defined by you.
Note that Bluetooth is way older than the smartphone era. In the beginning, everyone that implemented Bluetooth was for the purpose of selling a product that uses Bluetooth technology (earphones, speakers, phones). Still at this day, when making a Bluetooth "product", you need to be a Bluetooth SIG member (which is free but only companies can be Bluetooth SIG members) and when you use any of the Bluetooth trademarks with the product you need to get it qualified and listed at Bluetooth SIG. You can read at https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/ what actions and enforcements are taken if you fail to qualify a product. To qualify a product, you must follow the spec. There is a full test suite for qualification that you must pass. I'm pretty sure though it wouldn't catch if you use the wrong service list or "steal" a manufacturer's company id in manufacturer data. Developing software apps that run on already Bluetooth qualified smartphones is something that Bluetooth SIG hasn't thought of in my opinion. They have an option of qualifying as a "GATT-based Profile Client (app)" that costs $100 (https://www.bluetooth.com/develop-with-bluetooth/qualification-listing/qualification-listing-fees/), but that apparently isn't for you since you implement the Server profile. I have so far not heard of anyone that has done this app qualification. So to me it's a bit unclear how smartphone apps should be treated.
In the end the idea is that everyone should follow the spec to ensure proper interoperability between different products.
For your particular case, if you just want to minimizie the Advertisement data, just request a Company ID from Bluetooth SIG (it's free) and use Manufacturer Specific Data.
Related
What is the difference between broadcaster and beacons? From what I understand a broadcaster is a role in the GAP which sends out advertisements which contain data and are unable to make connections. They usually work in tandem with observers. Beacons do the same thing so what is the difference?
It's a bit like asking what is the difference between a HTTP server and a Web Server. A Web Server is a computer that stores web sites which it makes available over the internet, while a HTTP server is a piece of software that implements the server part of the HTTP protocol.
A Broadcaster is a role in the GAP specification which simply sends out advertisements, just as you say. It's defined in section 2.2.2.1 of the GAP chapter (in the Core v5.3 specification). Observer is the opposite role.
The word "beacon" is not present anywhere in the >3000 pages long Bluetooth Core specification. It's a term made up by industry, presumably because it works good in marketing or is generally a good name to describe this type of product. Beacons typically send out their positions using BLE advertisements for location tracking purposes but can also be connectable for various purposes.
Broadcaster is just a technical term and Broadcasters do not have a specific product purpose, which beacons on the other hand usually have. For example, iBeacon is a product which uses a specific data format containing identifiers. This product then uses the Broadcaster role and sends this data over BLE.
There is no difference. While broadcaster is a technical term used in the Bluetooth specification, beacon is simply the name of a class of products based on Bluetooth LE technology.
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!
Among the various officially registered Bluetooth device services, which are listed on the Bluetooth.org website, there is no mention of F002 or F003. But I recently was scanning for BLE in public and some unnamed device had these two services. Does anyone here know what device uses F002 or F003? Thanks.
Services in BLE can be adopted or custom. They have UUIDs that are 128bit long but are usually identified by their 16-bit offset:-
Adopted services are those listed by the Bluetooth SIG as
standard Bluetooth UUIDs. They're given a unique number and you have
probably already seen them here. Examples of those include the
Heart Rate (offset 180D), Health Thermometer (offset 1809), Battery
(offset 180F), etc. Those UUIDs are universal and if you see 180D
anywhere it should mean that it's the heart rate service.
Custom UUIDs on the other hand are undefined and in many cases can be just randomly generated. F002 is not an identified offset and therefore can belong to anyone using it for any random service.
I do remember coming across TI sensor tags with a similar UUID so it's worth investigating if you have any of those lying around.
A good read of UUIDs and BLE in general can be found here:-
https://www.safaribooksonline.com/library/view/getting-started-with/9781491900550/ch04.html
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.
In iOS 7, I am writing a core bluetooth app to get advertising packets from a series of peripherals. Each peripheral has an unique UUID in its advertising packet and is shown in the LightBlue sniffer app.
When I detect the peripherals in a central manager it assigns an UUID that is different from the UUID in the advertising packet.
According to the docs:
"The first time a central manager discovers a peripheral, the system assigns the peripheral a UUID, represented by a new NSUUID object. Your app can store this UUID and later provide it to a central manager for use in retrieving this specific peripheral. Peripherals are identified by NSUUID UUIDs instead of by the CBUUID objects that identify a peripheral’s services, characteristics, and characteristic"
Why does it do this?
Can I read the real peripheral UUID without connecting to the device?
How?
I think there is no such thing as a "real peripheral UUID". My understanding is that UUID (for the device/peripheral) is an Apple-specific concept, not a BLE concept. Take note of this discussion:
Corebluetooth, How to get a unique UUID?
OTOH, it appears that BLE devices do hold a IEEE-defined, unique MAC/BDADDR address. I was looking for a way to deploy platform-independent, static configurations of BLE devices. I was getting discouraged (Apple's UUIDs being +/- meaningless, and the MAC/BDADDR which can be obtained on most/all other platforms not being accessible from CoreBluetooth). Fortunately, I noticed that the "Device Information Service" profile (0x180A) contains a "System ID" attribute (0x2A23) which encodes the device's unique MAC/BDADDR address. I don't know if it is mandatory for a BLE device to expose this service, however.
As you can see from the specification System ID is optional in the Device Information Service
Link https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml
And in fact DIS itself is also an optional service, e.g. The Environmental Sensing Profile defines DIS as an optional service.