Indoor geolocation based on iBeacon. Aruba Meridian Solution
Indoor geolocation based on BLE beacons at the time of its appearance on the market attracted a lot of attention, including here, on Habré. Quite a lot of good articles have been written (the material of which I will periodically refer to), however, with the accumulation of practical experience and the discovery of pitfalls, interest in this technology has somewhat decreased. Typical problems of working with BLE beacons (see [ 4 ]) showed that the effective use of BLE navigation requires a comprehensive solution that includes both beacons and high-quality written software. An example of such a solution from a well-known vendor of network equipment will be analyzed in this article. I invite interested readers to cat.
Aruba Meridian's solution appeared about two years ago (see [ 3 ]), however, its active promotion in the domestic market began relatively recently. This option differs from many other solutions for BLE navigation primarily by the integration of beacons, maps and a smartphone application under a single control platform Meridian Editor in the cloud (for more details, see [ 3 ]). In addition, application development is maximally simplified and can be implemented in a web editor, without the need to use the SDK (in cases where there are no special requirements for customizing the application). Finally, the interaction of beacons with Wi-Fi from Aruba is possible (if there is a BLE module in the access points). All of the above made it possible to order a demo kit (Evaluation Kit) for conducting full testing.
Fig. 1. The appearance of the beacon Aruba Beacons LS-BT-20.
The demo kit is a small box with five beacons (see Fig. 1, the USB device is not part of the beacon) and a license for access to the Meridian cloud for a period of 90 days. Testing of the solution began for us with the provision of a room map for Aruba specialists: downloading the map directly to the cloud on our own is impossible, it requires preliminary processing by the vendor’s specialists. It is important to note that for each floor of the building requires its own card, subject to separate licensing.
After uploading the processed floor map to the cloud, it’s the turn of the beacon configuration. And here I would like to make a big digression and talk about BLE navigation as such. Part of the respected audience probably represents, at least in general terms, how BLE navigation works, but I would not want to send those who are not familiar with it on a journey through the Internet. Therefore, we will make a technologically-historical excursion.
The BLE-Bluetooth Low Energy standard appeared in the summer of 2010, when a number of developments under the general name Wibree were integrated into the Core Specification of the Bluetooth standard version 4.0. The first massive appearance of BLE 4.0 on the market was the launch of the IPhone 4S in 2011, and since 2012, its support has quickly become generally accepted. Devices that support the BLE standard can work in two modes: connecting mode and advertising mode [ 6 ]. Connecting mode is a point-to-point connection, while advertising mode uses the Generic Access Profile (GAP) to broadcast the so-called advertising packets, the format of which is presented below. BLE beacons, as a rule, work in advertising mode.
Figure 2. BLE advertising packet format.
In their pure form, BLE advertising packets are not used, they serve as the basis for constructing various implementations of the standard (pseudo-standards). Currently, there are three most popular implementations [ 5 , 7 ]:
Next, we will be interested in iBeacon, since it is it that is used in the solution from Aruba. At the same time, the vendor’s position is that the Meridian solution, although it is an implementation of iBeacon, does not interact with iBeacon-compatible devices from other manufacturers. As already mentioned above, iBeacon defines the only type of advertising packet that has the following format (see Fig. 3) [ 6 ].
Figure 3. The structure of the iBeacon frame.
Four fields are most interesting in this frame:
The contents of these 4 fields are directly used by the software part of the solution. The Bluetooth listening application receives a frame, reads the UUID and Major / Minor numbers, and then turns to the cloud database to search for information about the beacon associated with the indicated values. The value in the TX Power field is compared with the measured power value of the received Bluetooth signal, which allows you to determine the approximate distance from the beacon to the smartphone.
The initial configuration of Aruba beacons is done using the special Beacons App, which is available only on iOS (costs of using iBeacon). You need to “wake up” the beacon, physically place it in the right place, and then attach it to a given point on the map in the application. UUID is set by the manufacturer, Major / Minor numbers are set during configuration, and TX Power depends on the mode of operation of the beacon.
Aruba beacons can work both in navigation mode (Blue Dot) and in the mode of sending notifications (Proximity). From the point of view of the beacon, a change in operating mode only affects TX Power, as in navigation mode, it remains at the level set by the manufacturer (the results of its measurements will be shown below), and in the notification mode, the power can be adjusted, thereby adjusting the maximum radius for receiving notifications.
Fig. 4. Interface settings beacons. Navigation mode and notification mode.
The result of setting up the beacon is a record in the Meridian cloud database, connecting the UUID, Major / Minor numbers with the room map, coordinates on it and the mode of the beacon.
After setting all 5 demo kit beacons to the navigation mode and placing the placemark on the map, it was necessary to assemble the smartphone application in the same Meridian Editor and generate a link to download it, which took no more than half an hour. The first test devices were the IPhone 4S and IPhone 6S, and navigation worked without problems on them. The point moved along the map after the smartphone, the routes were built, in general, the decision did exactly what was expected of it.
Fig. 5. An example of the Blue Dot navigation mode and route construction.
It's time to test the solution on Android devices. Sony Z1 Compact, Samsung Galaxy S8, Xiaomi Mi 4c, Digma Optima were used - devices of different price ranges, age and features. The results were quite unexpected: the quality of navigation became worse compared to the iPhone of both models, although it differed from model to model, newer devices did better. I note that at that time we did not delve into the nuances of the beacons and did not yet know that iBeacon is used in this solution. It was the dependence of the quality of navigation on the mobile device used that made me dig deeper.
The idea came up to conduct a series of tests on the Z1 Compact and IPhone 4S to find out the reason why devices interact with beacons so differently. Firstly, the power of the received Bluetooth signal was measured. Table 1 shows the measurement results for one of the office locations. Similar data were obtained in other places: the devices received the physical signal equally efficiently.
Table 1. The results of measurements of the power received by the devices signal.
It became clear that the problem was not related to the physical level. There was an assumption that Android devices do not decode the received signal quite correctly. Accordingly, third-party applications for scanning Bluetooth broadcasts were installed: Beacon Scanner and nRF Connect. The results of their use are shown in Fig. 6 and show that, in principle, the device is fully capable of decoding the iBeacon protocol, as well as accurately determining the distance to the beacons.
Fig. 6. Decoding results of the received BLE signal in the
Bluetooth Scanner and nRF Connect applications .
In an attempt to learn something else useful, we studied the signal exchange path of a smartphone with beacons in Wireshark (Fig. 7). Unfortunately, this did not give any additional information.
Fig. 7. Tracing signal exchange Sony Z1 Compact with beacons.
It was found that Wireshark can decode the iBeacon protocol, but at present it incorrectly determines Major / Minor numbers, and the UUID received an increase of two digits in the higher digits, apparently due to incorrectly set frame field boundaries. Perhaps members of the community who have experience fine-tuning Wireshark will tell you how to adjust the results.
The set of tests convinced us that at the moment the problem of different quality of navigation on devices with iOS and Android OS lies primarily in the plane of software and the nuances of support for the iBeacon protocol in Android. The Aruba official community came to similar conclusions .
Triangulation when using Meridian takes place directly on the device [ 8 ], and accordingly significantly depends on both Meridian software and the drivers for the Bluetooth adapter. Any problems in at least one of these components, or in their interaction lead to a significant decrease in the quality of navigation on a particular device, which we observed.
I hope I did not tire the reader by "digging in the insides" of the Aruba beacons. I note that, in general, the decision left a good impression on us, giving also a lot of funny moments. I especially remembered the arrangement of marks on the office map and the subsequent routing from the “Do not fit, kill!” Switchboard to the flowers in the main room of one of the departments.
The statistics collection functions in the Meridian Editor turned out to be quite interesting: according to the privacy policy, the solution cannot collect and transfer the coordinates of users to the cloud, however, it remembers the most frequently routed routes, brands and OS of user devices.
Customization of the application using the SDK and / or embedding Meridian navigation software elements in third-party applications would deserve detailed testing, but this requires the connection of qualified programmers (your humble networker) and, if implemented, is worth a separate article.
I thank all readers for their attention, I hope for feedback in the comments in the form of interesting questions, suggestions and disputes.
Bibliography
Aruba Meridian's solution appeared about two years ago (see [ 3 ]), however, its active promotion in the domestic market began relatively recently. This option differs from many other solutions for BLE navigation primarily by the integration of beacons, maps and a smartphone application under a single control platform Meridian Editor in the cloud (for more details, see [ 3 ]). In addition, application development is maximally simplified and can be implemented in a web editor, without the need to use the SDK (in cases where there are no special requirements for customizing the application). Finally, the interaction of beacons with Wi-Fi from Aruba is possible (if there is a BLE module in the access points). All of the above made it possible to order a demo kit (Evaluation Kit) for conducting full testing.
Fig. 1. The appearance of the beacon Aruba Beacons LS-BT-20.
The demo kit is a small box with five beacons (see Fig. 1, the USB device is not part of the beacon) and a license for access to the Meridian cloud for a period of 90 days. Testing of the solution began for us with the provision of a room map for Aruba specialists: downloading the map directly to the cloud on our own is impossible, it requires preliminary processing by the vendor’s specialists. It is important to note that for each floor of the building requires its own card, subject to separate licensing.
After uploading the processed floor map to the cloud, it’s the turn of the beacon configuration. And here I would like to make a big digression and talk about BLE navigation as such. Part of the respected audience probably represents, at least in general terms, how BLE navigation works, but I would not want to send those who are not familiar with it on a journey through the Internet. Therefore, we will make a technologically-historical excursion.
The BLE-Bluetooth Low Energy standard appeared in the summer of 2010, when a number of developments under the general name Wibree were integrated into the Core Specification of the Bluetooth standard version 4.0. The first massive appearance of BLE 4.0 on the market was the launch of the IPhone 4S in 2011, and since 2012, its support has quickly become generally accepted. Devices that support the BLE standard can work in two modes: connecting mode and advertising mode [ 6 ]. Connecting mode is a point-to-point connection, while advertising mode uses the Generic Access Profile (GAP) to broadcast the so-called advertising packets, the format of which is presented below. BLE beacons, as a rule, work in advertising mode.
Figure 2. BLE advertising packet format.
In their pure form, BLE advertising packets are not used, they serve as the basis for constructing various implementations of the standard (pseudo-standards). Currently, there are three most popular implementations [ 5 , 7 ]:
- iBeacon - the first pseudo-standard, defines only one type of advertising packet, which has a simple structure. Developed in 2013 by Apple and fully controlled by it, natively supported in iOS.
- AltBeacon - developed by the Radius Networks consortium, since its inception it has been positioned as an open, accessible to everyone and compatible with any device standard. Functionally similar to iBeacon.
- Eddystone - developed by Google, is positioned as a cross-platform open source standard. It is supported on both Android and iOS devices. Unlike other pseudo standards, it defines several types of advertising packet.
Next, we will be interested in iBeacon, since it is it that is used in the solution from Aruba. At the same time, the vendor’s position is that the Meridian solution, although it is an implementation of iBeacon, does not interact with iBeacon-compatible devices from other manufacturers. As already mentioned above, iBeacon defines the only type of advertising packet that has the following format (see Fig. 3) [ 6 ].
Figure 3. The structure of the iBeacon frame.
Four fields are most interesting in this frame:
- UUID is a unique identifier for a group of beacons. It is set by the manufacturer.
- Major number defines some group (subnet) of beacons.
- Minor number identifies a particular beacon in a group.
- TX Power shows the signal strength at a distance of one meter from the device. The value in this field is set during manufacture and / or calibrated when the beacon is configured.
The contents of these 4 fields are directly used by the software part of the solution. The Bluetooth listening application receives a frame, reads the UUID and Major / Minor numbers, and then turns to the cloud database to search for information about the beacon associated with the indicated values. The value in the TX Power field is compared with the measured power value of the received Bluetooth signal, which allows you to determine the approximate distance from the beacon to the smartphone.
The initial configuration of Aruba beacons is done using the special Beacons App, which is available only on iOS (costs of using iBeacon). You need to “wake up” the beacon, physically place it in the right place, and then attach it to a given point on the map in the application. UUID is set by the manufacturer, Major / Minor numbers are set during configuration, and TX Power depends on the mode of operation of the beacon.
Aruba beacons can work both in navigation mode (Blue Dot) and in the mode of sending notifications (Proximity). From the point of view of the beacon, a change in operating mode only affects TX Power, as in navigation mode, it remains at the level set by the manufacturer (the results of its measurements will be shown below), and in the notification mode, the power can be adjusted, thereby adjusting the maximum radius for receiving notifications.
Fig. 4. Interface settings beacons. Navigation mode and notification mode.
 |  |
The result of setting up the beacon is a record in the Meridian cloud database, connecting the UUID, Major / Minor numbers with the room map, coordinates on it and the mode of the beacon.
After setting all 5 demo kit beacons to the navigation mode and placing the placemark on the map, it was necessary to assemble the smartphone application in the same Meridian Editor and generate a link to download it, which took no more than half an hour. The first test devices were the IPhone 4S and IPhone 6S, and navigation worked without problems on them. The point moved along the map after the smartphone, the routes were built, in general, the decision did exactly what was expected of it.
Fig. 5. An example of the Blue Dot navigation mode and route construction.
It's time to test the solution on Android devices. Sony Z1 Compact, Samsung Galaxy S8, Xiaomi Mi 4c, Digma Optima were used - devices of different price ranges, age and features. The results were quite unexpected: the quality of navigation became worse compared to the iPhone of both models, although it differed from model to model, newer devices did better. I note that at that time we did not delve into the nuances of the beacons and did not yet know that iBeacon is used in this solution. It was the dependence of the quality of navigation on the mobile device used that made me dig deeper.
The idea came up to conduct a series of tests on the Z1 Compact and IPhone 4S to find out the reason why devices interact with beacons so differently. Firstly, the power of the received Bluetooth signal was measured. Table 1 shows the measurement results for one of the office locations. Similar data were obtained in other places: the devices received the physical signal equally efficiently.
Table 1. The results of measurements of the power received by the devices signal.
It became clear that the problem was not related to the physical level. There was an assumption that Android devices do not decode the received signal quite correctly. Accordingly, third-party applications for scanning Bluetooth broadcasts were installed: Beacon Scanner and nRF Connect. The results of their use are shown in Fig. 6 and show that, in principle, the device is fully capable of decoding the iBeacon protocol, as well as accurately determining the distance to the beacons.
Fig. 6. Decoding results of the received BLE signal in the
Bluetooth Scanner and nRF Connect applications .
 |   |
In an attempt to learn something else useful, we studied the signal exchange path of a smartphone with beacons in Wireshark (Fig. 7). Unfortunately, this did not give any additional information.
Fig. 7. Tracing signal exchange Sony Z1 Compact with beacons.
It was found that Wireshark can decode the iBeacon protocol, but at present it incorrectly determines Major / Minor numbers, and the UUID received an increase of two digits in the higher digits, apparently due to incorrectly set frame field boundaries. Perhaps members of the community who have experience fine-tuning Wireshark will tell you how to adjust the results.
The set of tests convinced us that at the moment the problem of different quality of navigation on devices with iOS and Android OS lies primarily in the plane of software and the nuances of support for the iBeacon protocol in Android. The Aruba official community came to similar conclusions .
Triangulation when using Meridian takes place directly on the device [ 8 ], and accordingly significantly depends on both Meridian software and the drivers for the Bluetooth adapter. Any problems in at least one of these components, or in their interaction lead to a significant decrease in the quality of navigation on a particular device, which we observed.
I hope I did not tire the reader by "digging in the insides" of the Aruba beacons. I note that, in general, the decision left a good impression on us, giving also a lot of funny moments. I especially remembered the arrangement of marks on the office map and the subsequent routing from the “Do not fit, kill!” Switchboard to the flowers in the main room of one of the departments.
The statistics collection functions in the Meridian Editor turned out to be quite interesting: according to the privacy policy, the solution cannot collect and transfer the coordinates of users to the cloud, however, it remembers the most frequently routed routes, brands and OS of user devices.
Customization of the application using the SDK and / or embedding Meridian navigation software elements in third-party applications would deserve detailed testing, but this requires the connection of qualified programmers (your humble networker) and, if implemented, is worth a separate article.
I thank all readers for their attention, I hope for feedback in the comments in the form of interesting questions, suggestions and disputes.
Bibliography
- The experience of choosing and ordering iBeacon
- iBeacon: Guide to Action
- Customizing your internal navigation system with Aruba tools
- iBeacon. Myths and Reality
- Physical web concept. Bluetooth beacons. Comparison of iBeacon, AltBeacon and Eddystone Standards
- Understanding the different types of BLE Beacons
- Bluetooth BLE Beacon Standards from iBeacon, Eddystone, and AltBeacon
- Aruba official community