Technical Basics of Bluetooth Beacon Infrastructure

Table of Contents
Beacon Infrastructure

In this article, we primarily want to deal with the implementation and planning of corresponding applications and the beacon infrastructure. Applications based on BLE beacons are becoming increasingly common. These applications, in particular, are currently driving the need for structured planning. In this way, Bluetooth continues to develop as a topic in our projects and continues to become more important.

Except for such justified reservations, the use of Bluetooth applications can offer real added value. As with every application, the individual case must be considered. In contrast to much of what we consider in our classic day-to-day consulting, for example, beacon applications in industry and especially in production are rather rare. In other areas, for example, where a smartphone is a central tool, such as in the office environment, this can look significantly different. Therefore, a look at the scope, the benefit and the planning approach of such applications, which may be necessary, is relevant and useful.

For Bluetooth itself, the smartphone or the connection with a correspondingly widespread and available system is usually an important basis. The selection of the available applications, therefore, goes beyond the smartphone connections to the hands-free system or the headset or from the laptop to various peripheral devices. There are more and more applications that are finding their way into modern buildings on a Bluetooth basis.

If more and more applications (e.g. smartphone apps) are based on BLE beacons and require an appropriate beacon infrastructure, the planning of the Bluetooth supply is becoming increasingly important. Structured planning should always be carried out, especially if production-critical requirements apply here.

In this context, this does not only concern the basic aspects such as the placement of the transmitter and receiver. Other aspects that we know from classic network planning are also playing an increasingly important role.

Perhaps the most important example here is security. In view of the currently published security gaps in many Bluetooth implementations, this becomes obvious once again. The encryption used under Bluetooth is vulnerable. In typical beacon applications, this may often not be as relevant. However, as soon as other uses of Bluetooth play a role, security management is of corresponding importance.

Technical basics of beacon infrastructure

There are currently a large number of different beacon standards, the four best known of which are iBeacon, Eddystone, uiBeacon, and ALT-Beacon. The first two standards are particularly relevant because they are supported by Apple (iBeacon) and Google (Eddystone). It doesn’t matter whether the user is using an iPhone, Android or Windows operating system on their mobile device. The signals are understood by all devices. The iBeacon protocol has been supported since Android version 4.3.

Since the different beacon protocols are all part of the Bluetooth Low Energy Standard, the structure is very similar. The iBeacon data package is therefore illustrated in more detail. This is part of the Bluetooth Low Energy Payload, which in turn is part of the Protocol Data Unit (PDU) of the actual BLE frame. This means that 31 out of 47 bytes can be used for the iBeacon data within one BLE frame. The amount of data seems small,  but the concept of beacons requires that the intelligence is in the app and not in the beacon itself.

The data structure of the iBeacon frame within Bluetooth Low Energy

beacon infrastructure

Regardless of the individual protocols, beacons always offer several pieces of information that they send out at fixed intervals. These are the values ​​for the Universally Unique Identifier (UUID), Major, Minor, and TX Power. The former has a data volume of 128 bits. This results in 160 bits of user data that can be transmitted using a beacon. This enables a good structuring of different information for a variety of applications. For example, the UUID can refer to the company, major to a building and minor to a specific position within the building.

The TX Power value is responsible for the end device being able to estimate the distance to the beacon. There, the device transmits the information about its own signal strength in the form of two’s complement. Thus, for example, the value 0xC8 = 200, two’s complement = 256-200 = 56 and thus a coded signal strength of -56 dBm of the beacon signal. This is an indicator of the received signal strength indicator (RSSI) and indicates how strong the signal should be when it is measured one meter from the object. Of course, the really existing circumstances are not taken into account here. A wall or a person between the beacon and the receiver can strongly influence the measured field strength. For the receiver of the signal, it cannot be seen whether the signal is far away, whether it is the echo of a signal that is actually closer, or whether there is an obstacle between the transmitter and the receiver. Nevertheless, this value allows an improved positioning accuracy for the position determination in relation to the position of the beacon.

Beacon applications in modern buildings

In modern buildings, there are more and more applications that require a data connection in addition to classic office communication. Here we do not only mean the connection of the periphery of the workplace, such as the mouse, keyboard or the headset.

The connection for many other end devices often does not require the classic wired network. A connection via WLAN is now often the standard case here. And even in customer projects where the wired network still predominates, the tendency towards wireless applications is often evident. Already today, but especially in the building of the future, it can be assumed that more and more end devices are connected wirelessly. One consequence of this development is, in particular, that extensive WLAN coverage is often required. Based on this fact, a whole series of Bluetooth applications based on BLE beacons require a second data connection using cellular or WLAN.

A typical BLE beacon application is not alone but requires an additional data connection. Services and services available on the network can be reached as shown. In case of doubt, this connection must be planned and provided.

A location-dependent application is the most obvious application for beacons. For this purpose, for example, in the retail area with many beacons, an attempt was made to analyze and influence the buying behavior of customers. This “proximity marketing” has had little success, at least in Europe, and more and more indoor navigation systems are now appearing instead, which should make it easier for users to find their way around in an unknown building.

The idea in the building of the future goes so far that the elevator uses its sensors to report that it expects a defect soon and notifies the service technician. This comes into the building and automatically receives the required locking authorizations for the electronic door locks and is guided by the app to the corresponding service room using Bluetooth beacons. Once there, a beacon on the elevator links to the device’s current service manual and the technician can call up the history of previous maintenance and repairs.

The areas of application of the technology are diverse and, due to the ease of retrofitting, also interesting for existing beacon infrastructure.

Anyone who has ever visited the clinic in Aachen will appreciate the value of indoor navigation in order to find their way around the winding corridors. There, some stations have been equipped with beacons and thus enable partial navigation for the patient. Unfortunately, the entire clinic was not equipped with beacons, but only in very few areas. As a proof-of-concept, an interesting project, but without a comprehensive expansion, user acceptance will hardly be achievable.

Similarly, a museum can easily be expanded with beacons on the exhibits and the previous audio guides can be replaced by a museum app. This also enables customer loyalty beyond the individual visit. Research shows that many users leave the app on their mobile device after visiting. This, in turn, enables the operator to inform the visitor about new exhibitions or promotions.

A trade fair can also benefit from this technology. A trade fair app with BLE technology not only enables indoor navigation or trade fair guidance for the user but also offers the operator the opportunity to analyze and control the flow of visitors. If a hall is overcrowded, users may be grateful to be informed that another hall currently has hardly any visitors.

Of course, it can then be experienced for the app user that in the supposedly empty hall all the users are romping around without the smartphone and trade fair app, which the system has not “seen”. On the basis of the typical user behavior (or according to the statistical mean) and with the appropriate software, however, a correspondingly good prediction can often be made.

The area-wide supply of a building with beacon technology also offers a multitude of new usage concepts. A meeting room that has not been used does not need to be cleaned (or less often). And a meeting room that is never used could perhaps be put to better use. Anonymous data could be used for this in order to gain a usage profile of the corresponding area.

Location using bluetooth beacons

There are three different use cases when using beacons devices, which are explained in more detail below and are shown schematically.

Different ways of using the beacon; left: navigation through stationary beacons; middle: tracking by moving beacons on objects; right: the combination of both methods

A possible setup for indoor navigation assumes that the beacons are firmly positioned and the application knows where each beacon is located. The position within the beacon infrastructure can be determined by trilateration. As a rule, the additional sensors of the mobile devices are used. The position determination can be supported by the acceleration sensors, which are installed in all current mobile phones.

With asset tracking, you want to know where the beacons are located. Components that are to be localized are therefore equipped with beacons and can then be located within the infrastructure. In the healthcare sector, for example, this is currently a very relevant application that has to be planned more and more frequently. The operator would like to know where certain resources are located.

The idea behind this is that you can use it to plan resources better and spend less time looking for the corresponding component. An additional side effect is that you also get information about the actual use. In this application, WLAN access points with additional BLE technology are often used.

If such an infrastructure is used, you can also combine both methods and enable both indoor navigation and asset tracking, thus creating added value for the use of the building. Due to the low price of the beacons, this is not associated with high investment costs. You can start to roll out this technology in one area and then expand it bit by bit. However, it must be noted that more beacons do not necessarily improve location accuracy. If there are too many beacon signals, the accuracy decreases again [Li 2015]. To achieve widespread usability, careful planning of the beacon infrastructure is sensible and necessary.

Planning basis of beacon asset tracking

In this context, asset tracking means a beacon-based tracking of objects, etc. The basis for this is usually the tracking of moving Bluetooth beacons that are placed on objects to be tracked. These beacons are localized by appropriate Bluetooth receivers. So you need an infrastructure of BLE receivers that receive the beacons. An underlying beacon infrastructure can evaluate the data and ultimately determine the position of the beacon.

Position determination using trilateration

Position determination using trilateration

From a technical and planning perspective, this is very reminiscent of the location of WLAN end devices based on the signal strength of their packets using the WLAN access points. In contrast to the location using WLAN, the number of receiving stations required for BLE is often lower. In the end, however, this depends on the structural environment, the accuracy requirements of the application and other framework parameters. Part of the planning is therefore comparable to WLAN planning. Similar to radio cells, corresponding coverage areas must be defined and planned.

It is therefore hardly surprising that many of the WLAN access points available in professional environments are now also a blue
Bring a tooth radio module. A corresponding Bluetooth beacon infrastructure is thus already created through the WLAN infrastructure. To a large extent, planning for asset tracking applications is an almost classic infrastructure planning.

WLAN planning tools now support the first basic functions for Bluetooth planning []. BLE coverage similar to WLAN can be simulated in the popular Ekahau Site Survey tool. The functionality is currently limited to displaying radio cells in which a minimum number of beacons with sufficient signal strength can be received. Unfortunately, a direct conclusion about the location accuracy is not yet possible in the current version.

A corresponding platform is required for the administration of the beacons, the position determination and possibly other management functions. Here too, there are corresponding solutions from WLAN manufacturers.

Such an architecture also makes it possible to monitor the battery-operated beacons. The battery replacement to be expected a few years after implementation can be simplified as the system can return the status of the installed beacons. Depending on the manufacturer’s information and the configuration, the batteries may need to be replaced after a period of between 3 and even 8 years. Other operational tasks also result from the fact that beacon infrastructure must be documented and the entire architecture must be maintained. In addition, safety-relevant aspects, such as updates to current software and firmware versions, must be taken into account and carried out. The corresponding effort must be taken into account.

In addition to the architecture, another important task is the planning of the application based on it. Overall, it is therefore not only necessary to provide structured planning for the conception of the infrastructure, but also for the implementation of the application. This then includes requirement analysis, a rough concept, the definition of the requirements for the beacon infrastructure (from the required accuracy to the area coverage or the coverage areas) and the corresponding specifics of the application and user interface.

Since an asset that is permanently installed serves as the basis of the Bluetooth architecture for asset tracking, planning analogous to classic WLAN planning is useful. The result is a procedure comparable to WLAN planning. It should be borne in mind here that planning beacon positions typically require less draft. One reason for this is the low price of the beacons and the mostly low infrastructure requirements. In addition, in the case of tracking and tracing applications, a certain proportion is already predetermined by the WLAN planning if the WLAN infrastructure is to be used as well.

The individual aspects of planning shown in Figure 5 thus resemble classic WLAN planning without requiring the same depth. When planning the infrastructure, it is already important to know and take into account the parameters of the application, such as the required location accuracy. It is therefore often useful to interlink with application development. Important requirements for planning an infrastructure-based Bluetooth architecture are in particular the requirements of the application to be implemented with Bluetooth. In connection with asset tracking, these include the area coverage and the accuracy of the required location. It is to be determined in which building (or terrain) areas a corresponding accuracy is required. This then results in the required density of the BLE receivers that are used for location.

Structure of Bluetooth planning analogous to WLAN planning

Planning basics navigation / app-based applications

In contrast to the location of objects equipped with a beacon described above, the typical navigation or location determination in a smartphone app does not require extensive beacon infrastructure.

The Bluetooth beacons typically form the infrastructure here. This, supplemented by a corresponding service in the network, is sufficient for location determination. The smartphone or app receives several beacons. On this basis, a corresponding service can then calculate the position via a data connection, such as WLAN or mobile radio. Even if an infrastructure comparable to WLAN access points is not required, a certain architecture is still required. Availability requirements arise accordingly on the backend. These may be comparable to the requirements for other network infrastructure.

To determine the exact position, the smartphone must receive and evaluate a sufficient number of BLE beacons. Depending on the manufacturer, it can also make sense here to use the Bluetooth modules installed in WLAN access points to monitor the beacons in order to control the operating expenditure by monitoring the beacons.

Likewise, the Bluetooth transmitters in access points can often be used as beacons. The WLAN infrastructure, therefore, fulfills an additional purpose and thus forms a non-battery-operated basic supply with beacons. Special manufacturer-specific special shapes are also worth mentioning. For example, Cisco offers so-called beacon points. In combination with the backend infrastructure from the same manufacturer, this enables the flexible placement of “virtual” beacons by means of a corresponding wired BLE infrastructure. Sector antennas with corresponding reception characteristics and hardware and software are used to make different beacons receivable depending on the position in the room. The system behind it then calculates the position.

In any case, planning and testing should take place before implementation. The different accuracy requirements make a corresponding difference in implementation. When planning the beacon positions in the case of classic app-based location and navigation, there is a clear difference to the planning procedure for WLAN planning. This is mainly due to the fact that typically no classic infrastructure or that is only built up to a limited extent (depending on the manufacturer).

This eliminates points such as the planning of the passive infrastructure as part of position planning. Nevertheless, framework parameters and requirements have to be defined, since the area coverage and the requirements for location accuracy have to be taken into account when choosing the beacon positions. It should also be noted here that in many cases, in particular in the case of battery-operated beacons, subsequent adaptation or supplementation by additional beacons is possible with comparatively little effort.


It clearly shows that Bluetooth is becoming increasingly relevant due to the associated applications. And even though the technology works quite detached from other network beacon infrastructure technologies in many applications, a closer look, and thus structured planning is useful and useful.

This starts with the planning of the applications and continues through to the planning of the influence on network technologies such as WLAN. Bluetooth planning cannot ignore the classic aspects of network planning, such as requirements analysis, the definition of supply areas, etc.

If you are currently planning a WLAN infrastructure, you should deal with beacon technology, since it can represent great added value for use with low investment costs. The classic planning software is currently only partially able to create a realistic simulation of BLE infrastructures. However, this will soon be possible with increasing frequency and, above all, gain in level of detail. The first approaches to the required planning options can now be found in the corresponding software.

Depending on the application, the beacon infrastructure planning for applications can be lower than for a classic network, since the focus is often on the software or smartphone app. It should therefore not be underestimated that operational responsibility is often seen in IT. At the latest when a connection via WLAN or BLE support through the WLAN infrastructure is required, a new responsibility arises in the IT department. Overall, there is an additional effort. For this reason, too, Bluetooth should play a role in current planning and the strategic orientation of IT and be taken into account.

Written by ——
Nick He
Nick He
Nick, a seasoned project manager in our R&D department, brings a wealth of experience to MOKOSMART, having previously served as a project engineer at BYD. His expertise in R&D brings a well-rounded skill to his IoT project management. With a solid background spanning 6 years in project management and get certifications like PMP and CSPM-2, Nick excels in coordinating efforts across sales, engineering, testing, and marketing teams. The IoT device projects he has participated in include Beacons, LoRa devices, gateways, and smart plugs.
Nick He
Nick He
Nick, a seasoned project manager in our R&D department, brings a wealth of experience to MOKOSMART, having previously served as a project engineer at BYD. His expertise in R&D brings a well-rounded skill to his IoT project management. With a solid background spanning 6 years in project management and get certifications like PMP and CSPM-2, Nick excels in coordinating efforts across sales, engineering, testing, and marketing teams. The IoT device projects he has participated in include Beacons, LoRa devices, gateways, and smart plugs.
Share this post
Empower Your Connected Need with MOKOSmart loT Device Solutions!