Indoor geolocation based on iBeacon. Aruba Meridian Solution
Indoor geolocation based on BLE beacons (BLE beacons) at the time of its appearance on the market attracted a lot of attention, including here at Habré. Quite a lot of good articles have been written (for which I will periodically refer to the material), however, as I gained experience in practical application and detection of pitfalls, interest in this technology somewhat decreased. Typical problems of working with BLE beacons (see [ 4 ]) have shown that effective use of BLE navigation requires a comprehensive solution that includes both beacons and well-written software. An example of such a decision from a well-known vendor of network equipment will be analyzed in this article. Interested readers invite under cat.
The Aruba Meridian solution appeared about two years ago (see [ 3 ]), but 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 applications for smartphones under the single Meridian Editor control platform in the cloud (for more, see [ 3 ]). In addition, application development is simplified as much as possible and can be implemented in a web editor without having 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 module at the BLE access points). All of the above led to order a demo kit (Evaluation Kit) for full testing.
Fig. 1. Appearance of Aruba Beacons LS-BT-20.
')
The demo kit is a small box with five beacons (see Fig. 1, a USB device is not part of the beacon) and a license to access 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: uploading the map directly to the cloud is not possible on its own, it requires preliminary processing by vendor specialists. It is important to note that each floor of the building requires its own map, which is subject to separate licensing.
After loading the processed floor map into the cloud, the turn of the beacon configuration has arrived. And here I would like to make a big digression and talk about BLE navigation as such. Part of the distinguished audience probably represents, at least in general terms, how BLE navigation works, but I would not like to send those who are not familiar with it on a journey across the expanses of the Internet. That is why we will make technical and historical excursus.
The BLE-Bluetooth Low Energy standard appeared in the summer of 2010, when a series of developments under the general title Wibree was integrated into the Core Specification of the Bluetooth 4.0 standard. 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, I 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) for broadcasting so-called. advertising packets whose format is presented below. BLE beacons, as a rule, work in the advertising mode.
Figure 2. Format BLE advertising packet.
Pure advertising packet does not apply in its pure form, they serve as the basis for building 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 he who 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 mentioned above, iBeacon defines the only type of advertising packet that has the following format (see Figure 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 “listening” Bluetooth broadcast application receives a frame, reads the UUID and Major / Minor numbers, and then accesses the cloud database to find the information about the beacon associated with the specified 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 the Aruba beacons is performed using the special Beacons App, which is available only on iOS (the cost of using iBeacon). It is necessary to “wake up” the beacon, physically place it in the right place, and then bind it to this point of the map in the application. The UUID is set by the manufacturer, Major / Minor numbers are set during configuration, and TX Power depends on the mode of the beacon.
Aruba beacons can work both in navigation mode (Blue Dot) and in notification mode (Proximity). From the beacon point of view, changing the operating mode affects only TX Power, since in the 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 of receiving notifications.
Fig. 4. Interface setting beacons. Navigation mode and notification mode.
The result of the beacon setup is an entry in the Meridian cloud database, which connects the UUID, Major / Minor numbers with the room map, coordinates on it and the beacon operation mode.
After setting up all 5 democomplete beacons in the navigation mode and placing marks on the map (placemark), it was necessary to build a 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 the 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. Were used Sony Z1 Compact, Samsung Galaxy S8, Xiaomi Mi 4c, Digma Optima - 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 coped better. I note that at that time we did not go deep into the nuances of the work of the beacons and did not yet know that this decision uses iBeacon. It is the dependence of the quality of navigation on the mobile device used that made us “dig deeper”.
The idea arose 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. First, the power of the received Bluetooth signal was measured. Table 1 shows the measurement results for one of the office locations. Similar data was obtained in other places: the devices received the physical signal equally effectively.
Table 1. The measurement results of the power received by the device signal.
It became clear that the problem is not related to the physical level. It has been suggested that Android devices do not quite correctly decode the received signal. Accordingly, third-party applications have been installed to scan the Bluetooth broadcast: 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 applications
Bluetooth Scanner and nRF Connect.
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. Trace signal exchange Sony Z1 Compact c beacons.
It was found that Wireshark can decode the iBeacon protocol, but currently does not correctly identify Major / Minor numbers, and the UUID received an increase of two digits in the high-order bits, apparently due to incorrectly defined frame margins. Perhaps members of the community with experience fine tuning Wireshark, suggest how to adjust the results.
The set of tests performed convinced us that at the moment the problem of different navigation quality on devices with iOS and Android OS lies primarily in the software plane and the nuances of supporting the iBeacon protocol in Android. Similar conclusions have been reached by the official Aruba community .
Triangulation when using Meridian occurs directly on the device [ 8 ], and accordingly significantly depends on both the 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 strong decrease in the quality of navigation on a particular device, which we observed.
I hope that I did not tire the reader by “digging into the insides” of the Aruba beacons. I note that, in general, the decision left us with a pleasant impression, having also presented many funny moments. Especially memorable was the placement of marks on the office map and the subsequent construction of the route from the switchboard "Do not fit, kill!" To the flowers in the main room of one of the departments.
The functions of collecting statistics in the Meridian Editor turned out to be quite interesting: according to the privacy policy, the solution cannot collect and transmit user coordinates to the cloud, but it remembers the most frequently laid out routes, brands and operating systems of user devices.
Detailed testing would deserve application customization using the SDK and / or embedding elements of Meridian navigation software into third-party applications, but this requires the connection of qualified programmers (your humble network servant) and, if implemented, is worthy of 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 Aruba Meridian solution appeared about two years ago (see [ 3 ]), but 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 applications for smartphones under the single Meridian Editor control platform in the cloud (for more, see [ 3 ]). In addition, application development is simplified as much as possible and can be implemented in a web editor without having 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 module at the BLE access points). All of the above led to order a demo kit (Evaluation Kit) for full testing.
Fig. 1. Appearance of Aruba Beacons LS-BT-20.
')
The demo kit is a small box with five beacons (see Fig. 1, a USB device is not part of the beacon) and a license to access 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: uploading the map directly to the cloud is not possible on its own, it requires preliminary processing by vendor specialists. It is important to note that each floor of the building requires its own map, which is subject to separate licensing.
After loading the processed floor map into the cloud, the turn of the beacon configuration has arrived. And here I would like to make a big digression and talk about BLE navigation as such. Part of the distinguished audience probably represents, at least in general terms, how BLE navigation works, but I would not like to send those who are not familiar with it on a journey across the expanses of the Internet. That is why we will make technical and historical excursus.
The BLE-Bluetooth Low Energy standard appeared in the summer of 2010, when a series of developments under the general title Wibree was integrated into the Core Specification of the Bluetooth 4.0 standard. 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, I 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) for broadcasting so-called. advertising packets whose format is presented below. BLE beacons, as a rule, work in the advertising mode.
Figure 2. Format BLE advertising packet.
Pure advertising packet does not apply in its pure form, they serve as the basis for building 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, characterized by a simple structure. Developed in 2013 by Apple and is fully controlled by it, natively supported in iOS.
- AltBeacon - developed by a consortium of Radius Networks, since its inception, it has been positioned as open, accessible to everyone and compatible with any device standard. Functionally similar to iBeacon.
- Eddystone - developed by Google, is positioned as an open-source, cross-platform standard. 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 he who 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 mentioned above, iBeacon defines the only type of advertising packet that has the following format (see Figure 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. Set by the manufacturer.
- Major number identifies a certain group (subnet) of beacons.
- Minor number identifies a specific 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 “listening” Bluetooth broadcast application receives a frame, reads the UUID and Major / Minor numbers, and then accesses the cloud database to find the information about the beacon associated with the specified 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 the Aruba beacons is performed using the special Beacons App, which is available only on iOS (the cost of using iBeacon). It is necessary to “wake up” the beacon, physically place it in the right place, and then bind it to this point of the map in the application. The UUID is set by the manufacturer, Major / Minor numbers are set during configuration, and TX Power depends on the mode of the beacon.
Aruba beacons can work both in navigation mode (Blue Dot) and in notification mode (Proximity). From the beacon point of view, changing the operating mode affects only TX Power, since in the 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 of receiving notifications.
Fig. 4. Interface setting beacons. Navigation mode and notification mode.
 |  |
The result of the beacon setup is an entry in the Meridian cloud database, which connects the UUID, Major / Minor numbers with the room map, coordinates on it and the beacon operation mode.
After setting up all 5 democomplete beacons in the navigation mode and placing marks on the map (placemark), it was necessary to build a 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 the 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. Were used Sony Z1 Compact, Samsung Galaxy S8, Xiaomi Mi 4c, Digma Optima - 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 coped better. I note that at that time we did not go deep into the nuances of the work of the beacons and did not yet know that this decision uses iBeacon. It is the dependence of the quality of navigation on the mobile device used that made us “dig deeper”.
The idea arose 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. First, the power of the received Bluetooth signal was measured. Table 1 shows the measurement results for one of the office locations. Similar data was obtained in other places: the devices received the physical signal equally effectively.
Table 1. The measurement results of the power received by the device signal.
It became clear that the problem is not related to the physical level. It has been suggested that Android devices do not quite correctly decode the received signal. Accordingly, third-party applications have been installed to scan the Bluetooth broadcast: 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 applications
Bluetooth Scanner and nRF Connect.
 |   |
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. Trace signal exchange Sony Z1 Compact c beacons.
It was found that Wireshark can decode the iBeacon protocol, but currently does not correctly identify Major / Minor numbers, and the UUID received an increase of two digits in the high-order bits, apparently due to incorrectly defined frame margins. Perhaps members of the community with experience fine tuning Wireshark, suggest how to adjust the results.
The set of tests performed convinced us that at the moment the problem of different navigation quality on devices with iOS and Android OS lies primarily in the software plane and the nuances of supporting the iBeacon protocol in Android. Similar conclusions have been reached by the official Aruba community .
Triangulation when using Meridian occurs directly on the device [ 8 ], and accordingly significantly depends on both the 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 strong decrease in the quality of navigation on a particular device, which we observed.
I hope that I did not tire the reader by “digging into the insides” of the Aruba beacons. I note that, in general, the decision left us with a pleasant impression, having also presented many funny moments. Especially memorable was the placement of marks on the office map and the subsequent construction of the route from the switchboard "Do not fit, kill!" To the flowers in the main room of one of the departments.
The functions of collecting statistics in the Meridian Editor turned out to be quite interesting: according to the privacy policy, the solution cannot collect and transmit user coordinates to the cloud, but it remembers the most frequently laid out routes, brands and operating systems of user devices.
Detailed testing would deserve application customization using the SDK and / or embedding elements of Meridian navigation software into third-party applications, but this requires the connection of qualified programmers (your humble network servant) and, if implemented, is worthy of 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
- Experience choosing and ordering iBeacon
- iBeacon: Guide to Action
- Configuring the internal navigation system using the tools Aruba
- iBeacon. Myths and Reality
- Physical web concept. Bluetooth beacons. Comparison of iBeacon, AltBeacon and Eddystone standards
- Understanding the different types of bleu beacons
- Bluetooth BLE Beacon Standards from iBeacon, Eddystone, and AltBeacon
- Aruba official community
Source: https://habr.com/ru/post/353134/
All Articles