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.
Related
I've been pouring over the BT 4.x (LE) spec trying to figure out if this is possible or not (events without pairing/boding).
Does anyone have an insight (and link to the spec preferably) if it's possible?
As Mike Petrichenko commented, GATT communication is definitely possible without pairing. In fact most GATT servers/clients out there function without the need for pairing/bonding. The only exception is when some characteristics require authentication/authorisation in order to read some data (e.g. a medical device with a Heart rate characteristic).
If you want a specific reference to where this is mentioned in the Bluetooth spec, then I recommend looking at the Core Specification version 5.2, Vol 3, Part C, section 10.2 (LE Security Modes):-
The security requirements of a device, a service or a service request
are expressed in terms of a security mode and security level. Each
service or service request may have its own security requirement. The
device may also have a security requirement. A physical connection
between two devices shall operate in only one security mode.
It is then mentioned that LE security mode 1 has the level No security, and many GATT servers/clients work in this level.
You can test this yourself if you have two phones available. You can use the nRF Connect app to run a GATT server on one and a GATT client on the other. You will see that you can browse the GATT table and read data without having to pair.
Below are a few links that contain more information:-
Is pairing/encryption mandatory to allow a peer to write in GATT
Bluetooth Low Energy GATT security levels
How GAP and GATT work
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!
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.
I am trying to write a little Zephyr OS runtime system that uses BLE to communicate between my two nrf52840dk boards. I have spent the past couple of days reading up on BLE and have gotten acquainted with GATT servers/clients.
The API I would preferably have looks something like this:
/* Send a message to conn */
void send(struct bt_conn *conn, void* data, u16_t len);
/* Callback which is invoked when a message is received from conn */
void recv(struct bt_conn *conn, void* data, u16_t len);
What I have managed to do is achieve something similar by limiting my system to two devices, one being a GATT server and one a GATT client.
The server exposes one attribute which the client scans for and subscribes to. The server can 'send' a message to the client by notifying it about a change to the attribute, and it can be sent messages by the client issuing a write request to the attribute.
The client can send messages to the server by writing to the attribute, while it can receive messages by the server notifying it of an update to the subscribed attribute.
I am thinking that primitives such as these ones must exist underneath the GATT layer (in the HCI layer?), but the Zephyr documentation is quite sparse at most places. Following this, I have two questions.
Is my understanding of BLE correct, that most communication between BLE devices happen through such GATT server/client relationships, or through BLE mesh networks?
Any pointers to information regarding where I can read up on writing the more generic API I described above (or if it already exists, pointers to that) would be helpful.
edit: I've accepted Youssifs answer. His answer together with the comments beneath it adequately answers my question.
Is my understanding of BLE correct, that most communication between BLE devices happen through such GATT server/client relationships, or through BLE mesh networks?
You are correct in that most applications out there will be using the GATT server/client relationship. This is because when Bluetooth Low Energy was introduced in 2010 (and later launched with iPhone 4s through CoreBluetooth in 2011), this was the only method of communication. Since then, subsequent releases of BLE introduced newer methods of communication:-
LE L2CAP (introduced in BT v4.1, 2013) where lower level communication channels were used for fast and direct data transfer.
LE Mesh (introduced in 2017) where most of the communication is based on BLE adverts and therefore any device that is on v4.0 can theoretically support it.
The problems with both of these methods are the relative complexity and the slow adoption by vendors. As such, my recommendation is to continue using GATT examples/applications until you're more familiar with BLE and then proceed to using the other methods of communication.
Any pointers to information regarding where I can read up on writing the more generic API I described above (or if it already exists, pointers to that) would be helpful.
You've probably already seen this, but the Getting Started Gudie of Zephyr is quite useful. You can then use the Central HR example on one board and the Peripheral HR example on the other to get two way communication. Once this is done you can start customising your applications to match your needs. A list of all Bluetooth examples can be found here.
Below are further resources on BLE development in Zephyr:-
https://www.novelbits.io/zephyr-getting-started-bluetooth-low-energy-development/
https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started
https://electronut.in/getting-started-with-zephyr-rtos-on-nordic-nrf52832-hackable/
I hope this helps.
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