Bluetooth Low Energy (BLE) Beacons – There are several types available, each with its own standards and advantages. Some are open and free, some are closed and cost money. This article will cover the three main types of beacons available, their advantages, disadvantages, derivatives, and some low-level implementation details on how beacons work.

General Overview:

Bluetooth Low Energy has the ability to exchange data in one of 2 states: connected or advertising mode. Connected mode uses the GATT layer to transfer data in a one-to-one connection. Advertising mode uses the GAP layer to broadcast data to anyone who is listening. Advertising mode is a one-to-many transfer and has no guarantees about data coherence.

BLE Beacons take advantage of the GAP Advertising mode to broadcast data out in periodic specially formatted advertising packets. Each type of beacon uses a custom specification to partition up the advertising data to give it meaning. I’m going to take a look at the three existing types of beacons, URI Beacons, iBeacons, and AltBeacons.

iBeacon

Description:

Apples iBeacon was the first BLE Beacon technology to come out, because of this most beacons take their inspiration from the iBeacon data format. iBeacons are enabled in the Apple SDK and can be read and broadcast from any BLE-enabled iDevice. The downside is iBeacons are a proprietary closed standard and thus are behind a pay-wall. So while there is a large ecosystem around iBeacons and a large pool of resources for developers it also has a cost to play ball.

Data Spec:

iBeacons broadcast 4 pieces of information, a UUID  that identifies the beacon, a Major/Minor number and a TX power level in 2’s compliment. The UUID, Major number and Minor number are read by a scanning application and referenced against a database somewhere to get information about the beacon. The beacon itself carries no descriptive information, it requires an external database to be useful. The TX power field is used with the measured signal strength to determine how far away the beacon is from the smartphone. Please note that the TxPower must be calibrated on a beacon-by-beacon basis by the user to be accurate.

The iBeacon “Prefix” contains the hex data : 0x0201061AFF004C0215 . This breaks down as follows:
0x020106 defines the advertising packet at BLE General Discoverable and BR/EDR high speed incompatible. Effectively it says this is only broadcasting, not connecting.
0x1AFF says the following data is 26 bytes long and is Manufacturer Specific Data
0x004C is Apples Bluetooth Sig ID and is the part of this spec that makes it apple dependent
0x02 is a secondary ID
0x15 defines the remaining length to be 21Bytes (16+2+2+1)

The remaining fields are rather self-explanatory. The proximity UUID is a standard 16byte/128bit BLE UUID. The proximity UUID is typically unique to a company. The Major / Minor number are used to denote assets within that UUID, common uses are Major numbers being stores (so 65,536 stores possible) with Minor numbers being individual tags within the stores (again 65,536 possible tags per store).

Examples:

1) A coffee shop has iBeacons on a rack of coffee  and by a register. When a customer walks in and gets close enough their coffee shop smartphone app see’s the iBeacon, searches the coffee shop iBeacon database, recognizes the iBeacon as belonging to coffeeShop X and then see’s there is a valid coupon for ground coffee and then notifies the user of the coupon.

2) iDevices can broadcast an iBeacon, this can be used to automate check-ins at events and track movements throughout venue’s.

3) See the embedded device code on the mbed iBeacon device page.

Thoughts:

iBeacons are cool, they’re widely supported, and because they’re an Apple product every one is working with them and the ecosystem is as robust as possible. The problem is they are just really limited in what they can do. Without the database on the back end iBeacons are just spewing random useless data. They may be useful, but really making them awesome requires both serious time and a good bit of money and is pretty easy to do poorly.

Derivatives:

A popular derivative is to replace the 0x004C with a different company code, say for example the 0x0059 that is assigned to Nordic Semiconductor. The nRF Beacon application and nrf51822 Bluetooth Smart Beacon Kit are great examples of this. They are just shy of using the iBeacon specification directly, having only swapped out the CompanyID field.

AltBeacon

Description:

AltBeacons are an open spec free to use beacon design provided by Radius Networks and looks to be gaining some momentum (Nordic and some others seem to like the free aspect of the spec). This spec seems to be a direct response to the closed source paywall blocked iBeacon spec that Apple is pushing. The AltBeacon spec is just different enough from iBeacons to be legally acceptable. Essentially it covers the same functionality that an iBeacon has but is not locked down to a individual company as iBeacons are. That said it is not as widely supported, yet. It is worth noting that while iBeacons have 20 of 27 Bytes available for user data (UUID+Major+Minor) the AltBeacons have 25/28 Bytes available for meaningful user data (MFG ID, BeaconCode, BeaconID, MFG RSVD). This means there can be more meaningful data delivered per message.

Data Spec:

The AltBeacon spec is 28bytes (26B are user modifiable) (iBeacon are 27B with 20B user modifiable). The first 2 bytes of the AltBeacon are not user modifiable but are set by the BLE stack. ADV Length is 0x1B and ADV Type is 0xFF which will specify the length of the advertising data packet and the type as manufacturing data respectively. After that everything is up to the user and can be shoved into a advertising manufacturer data field. Note that in most cases the MFG ID will coorelate to the Bluetooth Sig assigned numbers document.

Examples:

The same examples that are used for iBeacons apply to AltBeacons. The only unique thing about the AltBeacons is the ability to have different Manufacturer ID’s, different Beacon codes, and the 1byte of reserved data at the end that holds specific manufacturer information.

With AltBeacon it becomes possible to have the UUID’s be application specific rather than company specific, and gives the ability to change the Company ID instead. While nothing is currently taking advantage of this I could imagine beacons that broadcast the UUID for a beacon service, say for a temperature service, which would then provide the manufacturing company info and the temperature, in this way providing a temperature value that anyone who walks by can view.

Thoughts:

AltBeacons have great possibility. They make better use of the space they have, are more or less backwards compatible with iBeacons, and best of all don’t charge a licensing fee to use. That said it is a very new spec, almost no one is using it yet and it has an uphill battle to fight against the death grip iBeacons have on the market. In time I think more and more people will move to AltBeacons simply because they can carry more data and have a wider use case, oh and the whole open spec thing.

URIBeacon (pronounced YUR-ee-BEE-kun)

Description:

URIBeacons are a Google project that is part of their Physical Web initiative. The project seems to be under heavy development and seems likely to improve greatly over time. Right now URIBeacons are essentially QR codes that are broadcast over BLE. They give short links to the internet via BLE Advertising Packets. This enables things like a movie poster that direct you to the website for the movie, or promotional codes at a coffee shop that direct you to a webpage with a coupon you can show the cashier. It is worth noting that unlike iBeacons and AltBeacons which are used primarily as a set up once and leave running forever, URIBeacons have a configuration service, they are meant to be updated with new information and change over time.

Data Spec:

The URIBeacon spec uses 28B of the 31B available in an advertising packet. Of this 28B 19B are used to encode the URI being sent. The Prefix (‘www.’,’http://’,…) and Suffix (‘.org/’,’.com/’,…) are each encoded to a single byte. This saves overhead space but has the unfortunate side effect of limiting what domains you can transmit to by the official spec. Currently only www addresses (both http and https) and UUID’s can be transmitted via a URIBeacon. Things like ssh:// and gopher:// are not supported. The suffix is also encoded to a single byte, but only if it is one of the well defined ones. This means a url of ‘http://www.google.com’ would be encoded down to 8 bytes, 1 for ‘http://www.’, 6 for ‘google’ and 1 for ‘.com’. For a full list of supported pre-fix’s and suffixes you should see the official spec. If you use the supported prefix’s it is possible to have a URL of 17 characters. It is worth noting that the URIBeacons are meant to be used with URL shortening services like goo.gl, bit.ly, tin.ly which will shorten down any long URL to ~ 8-10Bytes.

Examples:

1) Coupon Code – A business has a URIBeacon that broadcasts a link to a coupon on the website. Customers follow the link and show the coupon to the cashier. Because the URIBeacon can be updated it is possible to enable time-sensitive links, so say the coupons only show up during a certain time of day.

2) Interactivity – For interactive things it could be possible to have users follow a URIBeacon link to a webpage where they could control some third party service. Like say lights on an internet connected display. In this case the URIBeacons serve as a way to get users to the control webpage.  This could also apply to interactive historical markers, or really anything that could be enhanced by having web content attached to it.

3) Games – Because URIBeacons are modifiable they could be left open so anyone could modify them, thus lending an element of community participation or gamify the experience to see who can control how many beacons.

Thoughts:

URIBeacons are a cool piece of tech. The fact that they don’t rely on an external database to give meaning to the data they carry like iBeacons and AltBeacons do means they can be more useful with less overhead. At the moment they are essentially glorified QR Codes, just broadcasting short links to the internet and some other forms of data. However I think that the future of URIBeacons is even more interesting, the possibility of sending data through GET requests using the BLE IP service (or BLIP as i like to call it) and opening a bi-directional pipe of information from the URIBeacon to the internet opens up the possibility of using a webpage to control the beacon. This means no need for a special smartphone app for each application, just have the URIBeacon point to a website that controls it and use a smartphones native browser to control the URIBeacon. I think this is the most interesting thing about URIBeacons, not where they are, but where they can go, primarily as an enabler for a truly pervasive IoT ecosystem.

Conclusion:

Beacons are handy pieces of tech. The iBeacon and AltBeacon are very similar, and in fact, seem to be designed to be the same thing, the only difference is iBecaons you pay for and are widely supported, whereas AltBeacons are free and still not widely used. Both broadcast a UUID and a couple of bytes of data specific to the device. iBeacons have slightly less space than AltBeacons and are more heavily regulated, but ultimately both are one-way communication methods, and both require an external database and a smartphone app to be really useful.

URIBeacons however are a different animal entirely. While they still broadcast data across the same channel as the other beacons that is where the similarity ends. URIBeacons hand out links to the internet, this enables them to link to more relevant content and possibly even context-aware content. In addition, URIBeacons are meant to be easily modifiable, they are not meant to be static, but rather plastic. Further, with the adoption of the BLE IP standard, it is very possible for them to talk to the internet through the phone, this means the URIBeacons can have a two-way communication channel. I believe URIBeacons are already the most useful of the beacon lot and will become even more awesome as the spec continues to evolve.

TLDR:

iBeacons and AltBeacons are the same thing and both use external databases to give beacons meaning. iBeacons are behind a paywall and are ‘apple’ branded, AltBeacons are free and actually, provide more data fields to use, but no one uses them yet. URI Beacons are different, they don’t require an external database, instead, they use web links to either link to data directly or in the future possibly as a two-way communication method. iBeacons are currently the most widely used, but I think URI Beacons will become a bigger force in IoT and more useful than anything else so far.