Figure 1: Bluetooth Low Energy (BLE) is particularly suitable for the interaction of a Bluetooth transmitter with a smartphone app and cloud service: The transmitter periodically sends radio beacons, which are received by a corresponding app and communicate with a cloud service in a context-related manner. The resulting information is presented to the smartphone user.

© SSV

Any smartphone with a corresponding app that is within radio range of the transmitter can receive the UID. In many applications, the smartphone app transmits the UID received via BLE beacon to a cloud service, which responds with context-related information. The app can present this to the respective user or use it for other purposes. In other cases, instead of the unique identification number, the beacon contains sensor readings, for example, which can be processed directly by the app.

Another application scenario is the periodic sending of service advertising beacons via BLE transceivers: in this case, a device uses a UID to indicate that a certain service exists and that a smartphone app, for example, can establish a bidirectional BLE connection and use the service if required. Using this method, a smartwatch, for example, informs the corresponding app that new fitness data is available for reading. Bluetooth beacons are sent with the help of so-called Advertising Protocol Data Units (Advertising PDUs, or ADV PDU). The Bluetooth protocol specifications from version 4.0 define the roles of the beacon sender (GAP Peripheral) and receiver (GAT Central) as well as the structure and mandatory elements of an ADV PDU. However, depending on the counting method, up to 26 bytes of any user data (e.g. freely selectable IDs or sensor data with measured values) can be sent as a broadcast in an ADV PDU.

Determine the distance

The received signal strength of the beacon radio signal (Received Signal Strength Indication, RSSI) is often measured and evaluated to determine the distance between the transmitter and the smartphone app. An important aspect here is the selected transmission power of the BLE transmitter. In practice, it is a compromise between the required range and the energy requirements of the transmitter level. BLE battery operation in particular is a major challenge.

Bluetooth technology supports transmission powers between 0.01 mW and 100 mW. The appropriate value for the respective application must be selected from this relatively large setting range. Other range-relevant parameters are the antenna gain (a combination of directivity and efficiency) and the respective conditions of the environment. The path loss (also known as path attenuation) is generally derived from this. This attenuation is initially caused by the propagation of the radio signal over the air (the greater the distance, the greater the signal attenuation). In addition to the distance in meters, existing obstacles between the transmitter and receiver are important negative influencing factors.

Such unwanted attenuators are anything that can reflect and scatter radio waves. These include moisture, precipitation, walls, windows and other obstacles made of glass, wood, metal or concrete, including metal towers or plates. As radio waves can penetrate some obstructions depending on the wavelength, the level of attenuation and effective path loss also varies depending on the type and density of the obstructions.

Versatile and safe to use

BLE beacons can be used with and without a smartphone app for numerous tasks. In the simplest case, they are used to wirelessly transmit weather sensor data to a base station. Together with an app, shopping applications as well as navigation and information systems in buildings and positioning solutions for intralogistics can be implemented. A very complex and well-known beacon-based solution is the Corona-Warn-App (CWA), which was developed in 2020 on behalf of the government to combat the pandemic. It is primarily intended as a digital tool for automatic contact tracing to inform app users about their personal risk of infection on a daily basis. The CWA beacon ID required for this is generated using a day key based on a random number.

The CWA includes an encounter recording function that runs in the background. It collects BLE beacon IDs of other CWA smartphones in the vicinity of the respective app user and creates an encounter list for a period of 14 days. The IDs of all encounters above a certain duration and a certain minimum distance are recorded in this list. RSSI values are used to determine the distance. In simplified terms, the RSSI values are divided into three different distance categories: near, medium and far. Longer encounters in the near and medium range are saved in the internal list. To calculate the individual infection risk, the CWA performs a daily comparison of its own IDs (daily key) with a cloud service that knows the IDs of app users with a positive coronavirus test result through corresponding messages.

In practice, however, the RSSI measurement method is relatively inaccurate: it is quite possible that the ID of a neighbor in an apartment or terraced house will end up in your own encounter list, even though you have never met this person in the past 14 days. As a result, the CWA may generate false alarms in the form of warnings about increased infection risks.

What the CWA developers have done brilliantly, however, is to anonymize the beacon data: Together with a BLE beacon, the Bluetooth hardware address of the sender is normally also sent. If the sender is a smartphone, this is personal information from a data protection perspective (smartphones can be assigned to an owner). CWA contact lists could therefore be used to determine who has been where and when. To solve this problem, a random value is used as the sender address, which is generated from the tag key every 10 to 15 minutes using a cryptographic process.

An idea: machine beacon applications

The "BLE beacon plus smartphone app" function combination is now used billions of times in practice. However, this proven and versatile technology stack is not yet very widespread in industrial automation. This should be changed. After all, almost every practitioner is familiar with the following situation: you are standing in front of a machine that is not working properly. A red light flashes and a relatively small LCD displays a message in the category "Error 4711 ...". What exactly should be done? Very often the way to an answer is quite laborious.