Beaconing

Bluetooth beaconing is a secondary effect of BLE; however, it is an important and significant technology for IoT. Because beacons are not necessarily sensors, we didn't cover them explicitly in the Chapter 3, Sensors, Endpoints, and Power Systems (although some do provide sensing information in an advertisement packet). Beaconing is simply using Bluetooth devices in LE mode to advertise on some periodic basis. Beacons never connect or pair with a host. If a beacon were to connect, all advertisements would stop and no other device could hear that beacon. The three use cases important to retail, healthcare, asset tracking, logistics, and many other markets are:

• Static point of Interest (POI)
• Broadcasting telemetry data
• Indoor positioning and geolocation services

Bluetooth advertising uses a message to contain further information in the broadcast UUID. An app on a mobile device can respond to this advertisement and perform some action if the correct advertisement is received. A typical retail use case would make use of a mobile app that would respond to the presence of a beacon advertisement in the vicinity and pop up an ad or sale information on the user's mobile device. The mobile device would communicate over Wi-Fi or cellular to retrieve additional content as well as provide critical market and shopper data to the company.

Beacons can transmit their calibrated RSSI signal strength as an advertisement. The signal strength of beacons is calibrated by manufacturers typically at a one-meter length. Indoor navigation can be performed in three different ways:

• Multiple beacons per room: This is a simple triangulation method to determine a user's location-based on the advertised RSSI signal strength collected from numerous beacons in a room. Given the advertised calibrated level from each beacon and the received strength from each beacon, an algorithm could determine the approximate location of a receiver in a room. This assumes all beacons are in a fixed place.
• One beacon per room: In this scheme, one beacon is placed in each room, allowing a user to navigate between rooms and halls with the fidelity of the location being a room. This is useful in museums, airports, concert venues, and so on.
• Few beacons per building: In combination with accelerometers and gyros in a mobile device, multiple beacons in a building can allow for dead reckoning ability in a large open space. This allows a single beacon to set a starting location and the mobile device to reckon its location based on user movement.

There are two fundamental beaconing protocols used: Eddystone by Google and iBeacon by Apple. Legacy Bluetooth devices can only support a beacon message of 31 bytes. This restricts the amount of data a device can convey. Elaborate schemes have been used to help reduce the packet size and encode the message.

An entire iBeacon message is simply a UUID (16 bytes), a major number (two bytes), and minor number (two bytes). The UUID is specific to the application and use case. The major number further refines the use case and minor extends the use case to an even narrower case.

iBeacons provide two ways to detect devices:

• Monitoring: Monitoring works even if the associated smartphone application is not actively running
• Ranging: Ranging works only if the application is active  

Eddystone (also know as UriBeacons) can transmit four different types of frames with varying length and frame encoding:

• Eddystone-URL: This is the uniform resource location. This frame allows a receiving device to display web content based on the location of the beacon. An app does not need to be installed to activate the content. The content is variable in length and applies unique compression schemes to reduce the size of the URL to a limit of 17 bytes. 
• Eddystone-UID: 16-byte unique beacon ID with a 10-byte namespace and six-byte instance. Uses Google Beacon Registry to return attachments.
• Eddystone-EID: A short-lived identifier for beacons requiring higher levels of security. No fixed namespace and ID, the identifiers constantly rotate and require an authorized app to decode. Uses Google Beacon Registry to return attachments.
• Eddystone-TLM: Broadcasts telemetry data about the beacon itself (battery level, time since power-on, advertisement count). Broadcasts alongside URI or URL packets. 

The following diagram illustrates the Bluetooth BLE advertisement packet structure for Eddystones and iBeacons. The iBeacon is simplest with a single type of frame of consistent length. Eddystone consists of four different types of frames and has variable lengths and encoding formats. Note that some fields are hard-coded such as the length, type, and company ID for iBeacon, as well as the identifier for Eddystone.

The scanning intervals and advertising intervals attempt to minimize the number of advertisements necessary to convey useful data within a period of time. The scanning window is usually a longer duration than the advertisement as scanners essentially have more power than a coin cell battery in a beacon. The following figure shows a process of a beacon advertising every 180 ms while the host scans every 400 ms. 

The beacon advertises every 150ms on the dedicated channels 37,38,39. Notice the ordering of the advertising channels isn't consecutive as frequency hopping may have adjusted the order. Some advertisements have failed to reach the host since the scan interval and advertising interval is out of phase. Only a single advertisement in the second burst reach the host on channel 37, but by design, Bluetooth advertises on all three channels in an attempt to maximize the chance of success. 

There are two fundamental challenges with architecting a beacon system. The first is the effect of advertising intervals versus the fidelity of location tracking. The second is the effect of advertising intervals versus the longevity of the battery powering the beacon. Both effects balance each other and careful architecture is needed to deploy correctly and extend the life of the battery.

The longer the interval between beacon advertisements, the less accuracy a system will have on a moving target. For example, if a retailer is tracking the location of patrons in a store and the patrons move at walking speed of 4.5 feet/second and a set of beacons advertises every four seconds versus another deployment that advertises every 100 ms, it will reveal different paths of motion to the retailer gathering market data. The following figure illustrates the effects of slow and fast advertising in a retail use case.

A four-second advertising interval loses accuracy of the customer as they move about a store. Additionally, the amount of time spent at a particular point can only be tracked at discrete intervals of 4 seconds. The time spent at position B and C (as the customer leaves the store) may be lost. In this case, the retailer may want to understand why the customer spent 7.8 seconds at location B and why the customer went back to point C on their way out.

The counter effect of frequent advertising is the impact on beacon battery life. Typically, the batteries in beacons are Li-ion CR2032 coin cells. The Hitchhikers Guide to iBeacon Hardware: A Comprehensive Report by Aislelabs. Web 14 March, 2016 (https://www.aislelabs.com/reports/beacon-guide/) has performed an analysis of battery life for some common beacons and altered their advertising interval (100 ms, 645 ms, and 900 ms). They also used different batteries with increasing stored energy. The results show that the average life ranges from 0.6 months to over one year depending on the chipset, but more importantly on the advertising interval. Along with the advertising interval, Tx power certainly affects the overall battery life, but so does the number of frames transmitted. 

A valuable exercise for the IoT architect is to understand the cost of transmission in terms of power. Essentially, the IoT device has a limited number of PDUs it can send out before the battery reaches a point where it will not be able to power the device unless refreshed or energy is harvested (Chapter 4, Communications and Information Theory). Assume an iBeacon is advertised every 500 ms and the packet length is 31 bytes (it may be longer). Additionally, the device uses a CR2032 coin cell battery rated at 220mAh at 3.7V. The beacon electronics consume 49uA at 3V. We can now predict the life of the beacon and the efficiency of the transmission:

• Power consumption = 49uA x 3V = 0.147mW
• Bytes per second = 31 x (1 second/500 ms) x 3 channels = 186 bytes/second
• Bits per second = 186 bytes/second x 8 = 1488 bits/second
• Energy per bit = 0.147 mW / (1488 bits/second) = 0.098 uJ/bit
• Energy used for each advertisement = 0.098 uJ/bit x 31 bytes x 8 bits/byte = 24.30 uJ/advertisement
• Energy stored in battery: 220mAh x 3.7V x 3.6 seconds = 2930 J
• Life of battery = (2930 J x (1,000,000 uJ/J)) / ((24.30 uJ/advertisement) x (1 advertisement / 0.5 seconds)) x 0.7 = 42,201,646 seconds = 488 days = 1.3 years

The constant 0.7 is used for allowances in the decline of battery life, as described in Chapter 4, Communications and Information Theory. 1.3 years is a theoretical limit and most likely will not be obtained in the field due to factors such as leakage current as well as other functionalities of the device that may need to run periodically.

A final note on beacons with respect to Bluetooth 5. The new specification extends the length of beacon advertisements by allowing for advertisement packets to be transmitted in the data channels as well as the advertisement channels. This fundamentally breaks the limit of an advertisement being limited to 31 bytes.

With Bluetooth 5, the message size can be 255 bytes. The new Bluetooth 5 advertisement channels are called secondary advertisement channels. They ensure backward compatibility with legacy Bluetooth 4 devices by defining a specific Bluetooth 5 extended type in the header. Legacy hosts will throw out the unrecognized header and simply not listen to the device. 

If a Bluetooth host receives a beacon advertisement that indicates there is a secondary advertisement channel, it recognizes that more data will need to be found in the data channels. The payload of the primary advertisement packet no longer contains beacon data, but a common extended advertising payload that identifies a data channel number and a time offset. The host will then read from that particular data channel at the indicated time offset to retrieve the actual beacon data. The data could also point to another packet (this is referred to as multiple secondary advertisement chains).

This new method of transmitting very long beacon messages ensures large amounts of data could be sent to customer smartphones. Other use cases and features are now enabled as well, such as the advertisement being used to transmit synchronous data such as audio streams. A beacon could send audio lectures to a smartphone as a visitor walks around a museum and looks at various art pieces. 

Advertisements can also be anonymized, meaning the advertisement packet does not need to have the transmitter's address bound to it. Thus, when a device produces an anonymous advertisement, it does not transmit its own device address. This can improve privacy and reduce power consumption.

Bluetooth 5 can also transmit multiple individual advertisements (with unique data and different intervals) nearly simultaneously. This will allow Bluetooth 5 beacons to transmit Eddystone and iBeacon signals at nearly the same time without any reconfiguration. Additionally, the Bluetooth 5 beacon can detect if it is scanned by a host. This is powerful because the beacon can detect if a user received an advertisement and then stop transmitting to conserve power.