Bluetooth BLE beacons communication for IoT edge devices

The Internet of Things (IoT) has several technologies which improve the functionality of IoT devices that can connect and communicate with each other. IoT, along with various advanced technologies and devices is carrying out a rapid transformation of modern society, into a simpler and smarter one.

According to a recent survey, amongst all the other wireless technologies available, Bluetooth Low Energy (BLE) beacons turned out to be a very promising short-range wireless communication technology, because they appear very frequently or are very common in Bluetooth-compatible technology.

The BLE Beacon typically consisits of a 32-bit ARM Cortex-M0 processor and a RF transmitter clocked at 2.4 GHz with Bluetooth 4.0 Smart. The Bluetooth SIG ( Special Interest Group) manages several versions of Bluetooth Smart devices. SIG claims these beacons can transmit up to 70 meters (230 feet). According to our studies, users have practically experienced a range of about 40-50 meters in real-world conditions due to the effect of noise and obstacles. BLE smart devices can detect the frequency of the transmitted signal and calculate the distance by measuring the strength of the received signals (RSS). BLE beacons are small devices that periodically send specific packets of data to indicate the presence or transmission of specific information. A Beacon is generally useful for internal navigation and positioning systems.

Beacon Protocols

There are currently two main types of software protocols used to track Beacon and allow Beacon to communicate with a program or browser. They can be mainly classified as:

• App based iBeacon protocol
• Browser based Eddystone protocol


Figure 1:BLE Beacon

There is some overlap as the Eddystone Universal Unique Identifier (UUID) actually works with applications, but in general each protocol is limited to working with applications or browsers. The signals themselves can be configured to work with any of these protocols and used for different purposes.

• The iBeacon protocol allows you to send notifications in the background or in the background of an application, allowing the application to be notified when a user receives a message.
• The Eddystone protocol talks to the web browser that needs to be open for the user to get the message/URL. Background notifications are supported on Android but not on iOS.

Beacon and BLE interaction

Focused on the most popular iBeacon protocol, Beacon transmits a single packet of data consisting of four types of information. UUID, Major, Minor, cal Tx Power - Combining this information allows you to find, navigate and start a conversation with the user. Here all the information is given below:

• UUID: This is a 16-byte string used to distinguish between large groups of related beacons. For example, if Coca-Cola maintains a network of billboards in a supermarket chain, all Coca-Cola billboards use the same UUID. This allows the Coca-Cola smartphone app to see which auxiliary ads are from Coca-Cola tags.
• Major: This is a 2 byte string used to mark a smaller subset of beacons within a larger set. For example, if Coca-Cola has four beacons in a particular supermarket, all four lights are the same. This allows Coca-Cola to know exactly which store the customer is in.
• Minor: This is a 2 byte string identifying each beacon. Following the example of Coca-Cola, the beacon in front of the Minor Store will have its own unique piece. As a result, Coca-Cola's special program knows exactly where the customer is in the store.
• cal Tx Power: Calibrated transmit power is used to determine the proximity of the beacon. How does it work? Cal Tx Power is the signal strength that is exactly one meter from the device. It needs to be calibrated and precoded. Tools can then use this as a basis for an approximate distance estimate. cal Tx should not be confused with the Tx power. The first is for Apple, while the second is the actual amount of Beacon transmit power, which largely depends upon the Beacon's physical settings and capabilities.

This is slightly different from Eddystone, whereby three packets of data are sent - UID, URL and TLM:

Eddystone‐UID is 16 bytes long and split into two parts:

• Namespace (10 bytes), its purpose is similar to the iBeacon UUID. With iBeacon, you typically assign a unique UUID to all your beacons to easily filter them out for signals from others. In Eddystone-UID you can do the same with the namespace.
• Instance (6 bytes), they serve the same purpose as the iBeacon of large and small numbers to identify your individual beacons. For Estimote signals that reflect the Eddystone UID, the instance is displayed as a string of up to 12 characters.

Eddystone‐URL
The Eddystone URL package contains one field URL. The size of the field depends upon the length of the URL.

Eddystone‐TLM
The Eddystone TLM package is designed to be distributed by the pilot with "data" packages (ie UID and/or URL) for fleet management purposes. Nearby Bluetooth devices can read these packets and send them to the fleet management service. For example, this service can warn the owner of the travel guide that the battery is low. The telemetry packet consists of:

• Battery voltage that can be used to estimate beacon battery level
• Beacon temperature
• Number of packets sent since the last beacon was powered on or restarted, the uptime of the beacon, i.e. the time elapsed since it was last powered up or restarted.

There are other types of protocols, but these are the two main protocols that are used commercially. In addition to iBeacon and Eddystone, there is also Altbeacon (developed by iBeacon after a patent infringement case by Radius Networks, i.e. an open standard). Before Eddystone, Google worked on URI flags, a standard that later led to the Eddystone URL package. At present, the Eddystone protocol is still relatively new and is therefore likely to improve rapidly in its application and performance. Kindly refer to the Wireless Connectivity Solutions for the IoT whitepaper to know more about BLE.

Research opportunities of BLE beacon

After a long study/research on the BLE beacon, we can be assured of the feasibility and suitability of IoT applications. Flexibility, low-cost hardware, and ease of implementation with BLE give developers more leeway and make the infrastructure more cost-effective and scalable. However, I noticed that there are still some bugs, such as e.g. limited battery life, interoperability between different BLE profiles, poor security, and so on. In order to overcome the above disadvantages, after discussing some capabilities of BLE beacon, they suggested future research directions.

Beacon must support both protocols (iBeacon and Eddystone) simultaneously

BLE detector protocols support only one protocol type at a time. There are two frameworks for iBeacon and Eddystone. The log graphs are different. Some developers have built Beacon to support both protocols, but in practice, it can only support one protocol at a time. Developers or users must manually switch between protocols. Whilst most designers integrate this circuitry to facilitate either protocol, the switching must be done during the development or configuration phase. When a trainer is deployed with a specific protocol, it is very difficult to change the protocol mode. There is currently no specific design on the market that supports both protocols at the same time. There is the potential for R&D in this area to propose a design for the BLE beacon that supports both protocols at the same time.

Beacon must perform many-to-many interactions

In the age of the Internet of Things, it was important to have multiple interactions in a given area with multiple Beacon deployments. However, in a high-beam installation environment, interference is an issue that detracts from smooth, uninterrupted interaction. In such an environment, signals can only interfere with each other if they are close to each other. We consider the above problem as a research opportunity, i.e. work, and propose a design for the BLE beacons that allows interaction between many people on the network.

Energy Efficiency of BLE Beacon

With wireless sensor networks, this is possible, although low-power devices have been well studied. BLE Energy harvesting is only useful in the outdoor environment. In the case of the indoor environment, it doesn't make much sense, the study of energy accumulation in indoor environments is required. Due to such limitations in indoor energy storage, IoT devices typically require lightweight data transmission protocols that optimize resource utilization and energy consumption. We consider the above issue as a potential for more research , ie we propose work and design for lightweight protocols in different layers of the IoT stack. A lightweight approach to data transfer increases device battery life and reduces latency, ie Quality of Service (QoS). The lightweight protocol approach transmits only small amounts of data, reducing communication requirements, computational effort, and small storage capacity. The use of standard protocols in the current IoT system ensures scalability, interoperability and system performance. Therefore, such lightweight protocols have to be:

• Compatibility with every other already existing protocol
• Flexibility to implement into beacons, wearable or more robust gateways
• Scalability to support its applications in a newly upgraded platform.

Better Distance Estimation

As per the reviewed studies, due to the instability of BLE signals, it was very difficult to achieve accurate distance estimation. The closest signal sources could be identified easily, as the signal sources were not in close proximity to each other, unlike in a beacon infrastructure. Hence, an inaccurate RSS measuring creates problems to estimate the beacons distance. The fluctuation in RSS value is a new challenge in developing beacon related applications. In the future, the RSS measurement needs to stabilize to avoid a fluctuation in distance values. We consider the above problem as a research opportunity i.e. to work and propose a design for BLE beacon, which will achieve a better accuracy assumption as a beacon's RSS will vary for different devices.

BLE beacon Kit

The CYALKIT-E02 Solar-Powered BLE Sensor Beacon Reference Design Kit (RDK) is designed to help you create tiny, solar-powered IoT devices with BLE wireless connectivity. The RDK comes with a Solar BLE Sensor, as well as a BLE-USB Bridge and Debug Board. The Solar BLE Sensor is based upon the Cypress’ Energy Harvesting Power Management IC (PMIC) S6AE103A and EZ-BLE™ PRoC™ Module. The sensor is designed to harvest energy from the sun or indoor lights and operate without a battery.